#snappy 2015-06-15
<dholbach> good morning
<fgimenez> good morning
<dholbach> hey ogra_ - how's life?
<ogra_> monday morningish :)
<dholbach> :)
<dholbach> ogra_, I just had a long weekend, so I thought I'd just give you a ping and suggest we have a chat whenever you feel like working on the py-snapper :)
<ogra_> dholbach, i'm still in the middle of experimenting
<dholbach> ogra_, cool - let me know how it goes :)
<ogra_> essentially we'll just use PYTHONUSERBASE ... but i'm still fiddling on scriptery to get the interpreter shipped and used too
<ogra_> (since python will eventually be gone from the images)
<ogra_> if apps define #!/usr/bin/python we're screwed with that ... i have no clue how to get around this
<damjan> ogra_: report bug upstream to use console_scripts entry point :)
<damjan> ogra_: PYTHONUSERBASE FTW!
<ogra_> damjan, against all packages in the ubuntu/debian archives ?
<ogra_> i think the only solution would be to bind or overlay mount the shipped interpreter on top of /usr/bin/python ... and only do that insode the confined space
<JamesTait> Good morning all; happy Monday, and happy Nature Photography Day! ð
<ricmm> ogra_: that last one sounds kind of volatile
<ricmm> ogra_: if they *ship* the interpreter in the snap, isn't it ok to assume that they would also modify the shebangs accordingly?
<ogra_> not really
<ricmm> why not
<ogra_> i wouldnt assume the packager to be fluent in that if he uses a script to roll some upstream project into a snap
<ricmm> they are already going through the work of shipping the interpreter
<ogra_> like not everyone installing from a tarball on linux does need to know C fopr "configure, make, make install"
<ogra_> they are running a script that ships the interpreter
<ogra_> (at least thats the plan .. )
<ricmm> right so they arent shipping anything thmselves
<ricmm> you are
<ogra_> exactly
<ogra_> and my problem is to make it work without mangling their shebang lines
<ricmm> I guess its ok to do what you said then
<ricmm> considering it is also your script which will be bundling the interpreter
<ricmm> so the possible paths are all accounted for, and chosen by you
<ogra_> <ricmm> I guess its ok to do what you said then
<ogra_> ?
<ogra_> i gave three options :)
<ricmm> the overlay/bind mount
<ogra_> ah
<ogra_> well, how would i do that so it only affects the snap ?
<ogra_> is there some cgroup stuff i can use ?
<ricmm> I dont think so
<ogra_> (overlay mount is out of discussion as long as we want to support BSP kernels, needs to be a bind mount )
<ricmm> right
<ogra_> which doesnt make it easier :)
<ricmm> ogra_: thinking
<ricmm> what other options do you have?
<ricmm> so, python is an important part of snapcraft and so on
<ogra_> loop over all files in our snap and patch the shebang with a variable if we find it ...
<ogra_> i dont think there are more
<ricmm> ogra_: what if we remove python from the snap, but instead replace the interpreter with one of your awesome shell scripts
<ricmm> one that sets up the env for the calling snap
<ogra_> not sure what you mean ... replace the interpreter of the snappy installation ?
<ricmm> yea
<ogra_> phew
<ogra_> that might make barry unhappy :)
<ricmm> what we dont want is people using the shipped interpreter, but that doesnt mean we cant catch their usage with a script of our own
<ricmm> unhappier than removing python altogether?
<ogra_> well, that will happen eventually ... what do we do then ?
<ogra_> once my shell script is gone the packages have the same prob again
<ricmm> why would your shell script be gone
<ricmm> I'm talking about *removing* python
<ricmm> and shipping your /usr/bin/python shell script instead
<ogra_> and i'm not sure we want to ship such scripts for all possible interpreters out there (i assume we'll have the same issue with other script langs)
<ricmm> I don't see why not, if we want to provide a generic way of doing things
<ogra_> hmm
<ricmm> either we provide something, or we dont provide anything at all
<ricmm> sorry, either we provide everything or nothing :p
<ricmm> but anywhere in between might be confusing and chaotic
<ogra_> right
<ogra_> thats a lot of maintenance work :/
<ricmm> well, someone made a choice about this somewhere ;)
<ricmm> lets think a bit more
<ricmm> short of having something in /usr/bin/python be it a script, a bind mount of an interpreter, or the actual distro one... theres nothing we can do
<ricmm> besides catching a call to open()
<ricmm> and stat
<ricmm> ogra_: maybe its time to discuss a libsnappy.so :)
<ricmm> that is always preloaded
 * ricmm has goosebumps
<ogra_> haha
<rsalveti> morning
<rsalveti> ricmm: libsnappy? :-)
<rsalveti> really wish we had a proper overlay support
<ricmm> rsalveti: :)
<ogra_> rsalveti, tell that to the BSP kernels :P
<rsalveti> ogra_: we don't even have a proper overlay story with upstream
<ogra_> yeah
<ogra_> well, the live iso uses it, no ?
<ogra_> so we have some story there
<longsleep> My snappy has a problem to get a DHCP address after i changed ethernet to another network. Dhclient loops with send_packet: Network is unreachable while trying to send DHCPREQUEST to the previous DHCP server.
<rsalveti> ogra_: not with apparmor
<ogra_> ah
<longsleep> ogra_: Does socker work on your rpi2 image? On my odroid i just get BUG: scheduling while atomic: docker.armhf/1227/0x00000002 when running a container :/
 * longsleep just realized that he has to start armhf images on arm platform
<ogra_> longsleep, yep, running the owncloud package here
<ogra_> on top of docker
<ogra_> (thats usually my definitive test for the image, snapy install docker ... snappy instrall owncloud .... wait 10-15min ... test owncloud)
<ogra_> (teh owncloud install downloads stuff in bg for 10-15min before first start)
<longsleep> ogra_: mhm ok - so its probably the kernel then. I get plenty of scary messages when running a docker container
<ogra_> i havent tried running a docker container directly though
<ogra_> i always only install these two snaps
<ogra_> ou need some modules in your kernel for docker to work though
<longsleep> if anyone wants to take a look http://paste.ubuntu.com/11719136/
<ogra_> http://paste.ubuntu.com/11719142/
<longsleep> can you try docker run -i -t armv7/armhf-ubuntu_core /bin/bash
<ogra_> Unable to find image 'armv7/armhf-ubuntu_core:latest' locally
<ogra_> latest: Pulling from armv7/armhf-ubuntu_core
<ogra_> ffb007497c55: Downloading 2.751 MB/44.71 MB
<ogra_> ...
<ogra_> now it downloads
<longsleep> yeah that works for me too, but it just hangs with kernel bug message in log
<longsleep> when it starts after download
<ogra_> ffb007497c55: Already exists
<ogra_> Digest: sha256:f9678f50148f8461bec2593967e62aa1e2a95184eb1adb74c299c1399bf4e99b
<ogra_> Status: Downloaded newer image for armv7/armhf-ubuntu_core:latest
<ogra_> root@e198690d2cce:/#
<ogra_> looks fine to me
<longsleep> yeah good thanks - this means i need to look at the kernel again ..
<rsalveti> ogra_: I'm trying to write a general status for our all team, and looking for the snaps that got uploaded/updated to the store, and I know you updated at least chatroom last week
<rsalveti> ogra_: is there any other snap that you uploaded/updated over the past 2 weeks?
<rsalveti> I might just write a script for that, since it seems there is even a changelog in there now
<ogra_> rsalveti, no, i was working a bit on Os.js but havent finished it yet ... and i plan to re-upload the fhem-demo one too but same thing ... the pi image ate nearly all of my last week
<rsalveti> yeah, no worries
<seb128> sergiusens, hey, did you get anywhere on friday with the personnal image issues?
<sergiusens> seb128: sorry, its taking longer than expected
<sergiusens> given I took the opportunity to change things and not hack something in
<seb128> sergiusens, did you find things wrong?
<seb128> great
<sergiusens> seb128: no, no real issues, I just don't want to code dup ;-)
<seb128> sergiusens, k, but should hacking a different partition size should be enough to write the image? do you know what's the "issue while mapping partitions: more partitions then expected while creating loop mapping" is?
<sergiusens> seb128: that should be kpartx doing something weird (dmsetup clear might work around it)
<seb128> sergiusens, not sure I understand what you mean there ... what should I try and how?
<sergiusens> seb128: kpartx -avs [outfile]; parted [loop returned] print // should be 5
<seb128> sergiusens, kpartx returns nothing on the img...
<seb128> well I'm unsure what that .img is now, since the udf command fails on the loop map error
<sergiusens> seb128:  sudo DEBUG_DISK=1 ubuntu-device-flash ...
<seb128> sergiusens, does it work locally for you?
<sergiusens> seb128: u-d-f in general yes; what won't work for you is that you have no packages in the store for personal
 * sergiusens thought he mentioned this on Friday
<seb128> sergiusens, unsure what it's downloading as well, the device tarball is < 100 mb that doesn't match the tarball from the cdimage builder
<seb128> sergiusens, you mean "package"?
<sergiusens> seb128: I mean all packages in the store are for core; snappy sends out the release name (and flavor) to the store to get packages
<seb128> sergiusens, I've been tried with the local hack from http://paste.ubuntu.com/11700710/
<seb128> sergiusens, well, packages are a matter once you have a working base img you can boot no?
<seb128> I'm not trying to install packages, just to get an image that starts
<sergiusens> seb128: the oem package needs to be in the store at least for personal (not that this is blocking you now)
<sergiusens> beuno: ^
<sergiusens> seb128: I'll give that patch a go and tell you what's wrong with it
<beuno> what what?
<sergiusens> beuno: we need the personal counterpart for core-rolling
<beuno> sergiusens, ack. nessita ^
<seb128> sergiusens, thanks
<seb128> sergiusens, you need to UDF_UBUNTU_CORE_NAME=ubuntu-personal but I guess you saw that from the code ;-)
<sergiusens> seb128: yup
<jdstrand> kgunn: regarding lchown... apps don't currently have lchown cause apps don't know what user to chown things to, however, it can be added to you framework in the file you specify for seccomp to "security-policy"
<sergiusens> seb128: I see a 900MB ~ download here
<seb128> sergiusens, only one download? or do you cumulate tarballs?
<seb128> sergiusens, that doesn't match the sizes from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next/+build/29728
<sergiusens> seb128: err sorry, 456 and 99
<seb128> sergiusens, right, same here, but that doesn't match the tarballs from ^
<seb128> even recompressing the device one in .xz it's 120M
<seb128> unsure if the channel tarballs are identical to the livefs build ones though
<nessita> seb128, not sure what you need, how can I help?
<sergiusens> seb128: it's 100MB on the s-i server
<sergiusens> it's just M so not sure it's MiB or MB
<ogra_> seb128, well, i think slangasek had a valid point with the /system dir prefix
<sergiusens> seb128: here too -rw-r--r-- 1 sergiusens sergiusens 100M jun 15 10:45 /home/sergiusens/.cache/ubuntuimages/pool/device-9a06d62b4fe6485e22b0ae9f1d7da08aed8605b0286a63b6fa5639bc6e1f1187.tar.xz
<ogra_> you might need to re-package the cdimage tarball
<ogra_> (not sure that is your actual issue here )
<seb128> nessita, hey, I want to build a snappy personnal image ;-)
<ogra_> just do it then ... dont hold back
 * ogra_ hides
<seb128> but I think sergiusens is looking at helping, so probably no need to have more people looking at the same thing
<seb128> ogra_, oh, why didn't I think of that! :p
<ogra_> :D
<seb128> nessita, we have tarballs built on https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next and slangasek got those in a system-image channel for personnal, but bits are missing still to be able to get u-d-f to build a working img, trying to figure out what those bits are exactly
<nessita> seb128, hi! sorry I meant sergiusens before, autocomplete failure :-)
<seb128> nessita, oh ok ;-)
<nessita> sergiusens, so what do you need from me/the store?
<nessita> seb128, sorry sorry, I'm not that skilled in snappy to help you there
<seb128> nessita, no worry
<sergiusens> nessita: releases today are core-15.04 and core-rolling, we need personal-rolling
<sergiusens> or the other way around with flavor / release
 * sergiusens always forgets
<nessita> sergiusens, currently we have rolling-core
<nessita> 15.04-core
<nessita> sergiusens, shall I add rolling-personal then?
<sergiusens> nessita: yeah
<nessita> sergiusens, done
<elopio> good morning
<tedg> Morning elopio!
<seb128> nessita, sergiusens, just trying to understand what's going on/how thing work, what are those server release? what is "personal-rolling" now, a channel name or...?
<ogra_> elopio, such a beautiful game on the weekend !!
<sergiusens> seb128: the store filters on releases, it's like frameworks from the click world
<seb128> sergiusens, ah, I see
<sergiusens> seb128: so when you start to publish snaps that only work for personal we won't see them in core and vice versa
<seb128> sergiusens, who/what defines on what release you are? can you see that info from the command line?
<sergiusens> although I suspect everything in core would work on personal
<seb128> it should
<sergiusens> seb128: right now snappy info (but it's derived from the channel name)
<seb128> k
<sergiusens> seb128: the current u-d-f patch doesn't have the right release setting right now, but once it's used it will affect you
<elopio> fgimenez: https://plus.google.com/hangouts/_/g6uj5z3fgt7ybmm4ltyadiyqima
<elopio> ogra_: wait, the one agains korea?
<elopio> *against
<ogra_> yeah
 * ogra_ loved it 
<sergiusens> seb128: http://paste.ubuntu.com/11719625/
<sergiusens> seb128: so it works for me, the mapping error you see needs to be signalled to the kernel somehow; but I don't really know how to get out of it sometimes without a reboot
<seb128> sergiusens, hum, unsure what you did differently?
<sergiusens> it sometimes keeps showing 2 partitions even though it has 5 (according to parted on the .img at least)
<seb128> mvo has the same mapping error than me when he tried
<seb128> so it's a random failure issue, need to reboot and retry?
<sergiusens> seb128: I rinsed and repeated twice already and no mapping errors (this time without --install webdm)
<seb128> sergiusens, k, let me try again locally, thanks
<seb128> sergiusens, I see a grub error in your log though, did that make the img generation fail?
<sergiusens> seb128: your image is missing /usr/lib/grub/x86_64-efi/modinfo.sh in any case steve would know how to get that in
<sergiusens> seb128: yeah
<seb128> slangasek, ^
<sergiusens> seb128: that's run with 'chroot' so it needs to be either seeded or mungled in from livecd-rootfs
<zyga> re
<seb128> sergiusens, right, I see that livecd-rootfs/auto/config has "add_package install grub-pc"
<seb128> I guess we need that in desktop-next
<sergiusens> seb128: that's seeded as well
<seb128> mvo was right, we should merge those sections :p
<sergiusens> seb128: grub-pc, grub-efi-amd64-bin and grub-efi-ia32-bin (for amd64)
<mvo> ha! I like to be right
<seb128> mvo, :-)
 * mvo has no idea what he was right about
<seb128> sergiusens, oh, right
<seb128> Get:1019 http://ftpmaster.internal/ubuntu/ wily/main grub-pc amd64 2.02~beta2-25ubuntu1 [221 kB]
<seb128> on https://launchpadlibrarian.net/209103030/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
<seb128> hum
<mvo> seb128: oh, yeah, we need some sort of inheritance in that script indeed
<elopio> ogra_: that was good, yes! I thought nobody watched women football games.
<ogra_> i watch a lot of them
<davmor2> ogra_: is the watchman
<ogra_> :D
<tedg> Ha, in the US we do, it's where we win sometimes :-)
<ogra_> yeah, your team is pretty awesome
 * ogra_ relaly hopes for germany vs USA
<slangasek> sergiusens, seb128: see the core seed, which includes both grub-efi-amd64-bin and grub-pc.  Ultimately, you actually want to have shim-signed, grub-efi-amd64-signed, and grub-pc-bin seeded, so maybe you want to seed those now and see if udf keeps up
<seb128> slangasek, https://launchpadlibrarian.net/209105327/buildlog_ubuntu_wily_amd64_ubuntu-core_BUILDING.txt.gz doesn't mention grub-efi...
<slangasek> seb128: I don't know that that's the right build log, then?
<seb128> slangasek, that's one from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core
<seb128> isn't that ubuntu-core?
<slangasek> seb128: no, that's the old ubuntu-core
<slangasek> (ubuntu-core doesn't build on powerpc or arm64)
<seb128> slangasek, hum, that's all confusing to me :-/
<seb128> slangasek, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/touch-core isn't the right seed either?
<slangasek> lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily
<slangasek> grep -rl snappy --> system-image
<slangasek> but again this is /not/ what I'm recommending you seed for the personal image; instead I'm recommending that you seeed:
<slangasek> shim-signed [amd64]
<slangasek> grub-efi-amd64-signed [amd64]
<slangasek> grub-pc-bin [i386 amd64]
<slangasek> grub-efi-ia32 [i386]
<ogra_> seb128, FYI https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/
<seb128> slangasek, yeah, I'm just wondering if we based/derived from the wrong seed
<seb128> Laney, ^ do you think we got confused?
<seb128> slangasek, thanks
<slangasek> seb128: quite possibly.  The touch seeds being a separate seed pod, not tied to main, is a bug
<ogra_> well, you want the seed content from the touch-desktop seed
<ogra_> but not necessarily the same setup in the end ...
<ogra_> (since ... snappy vs system-image)
<seb128> ogra_, yeah, I though we wanted ubuntu-core + desktop_bits
<Laney> seb128: Sorry, confused about what?
<seb128> so that we wanted to inherit from core
<seb128> rather than duplicate
<Laney> Where do we get the core bits from now?
<seb128> Laney, core seems to be http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily/view/head:/system-image
 * ogra_ doesnt actually know where the ubuntu-core-system-image seed lives ... 
<slangasek> ogra_: the touch-desktop seed being outside of ubuntu.wily is a bug
<ogra_> mvo, ? ^^
<slangasek> I already pointed them to the source of the ubuntu-core system-image seed
<ogra_> ah, k
<seb128> Laney, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop is the "Task-Seeds" wrong then?
 * seb128 confused
<sergiusens> can we rename that file to core or snappy-core?
<ogra_> slangasek, oh, btw, do yoou think it is ok to move the /system prefix creation into livecd-rootfs (i understood your mail comment like that)
<ogra_> sergiusens, "that file" ?
<zyga> hey
<sergiusens> ogra_: system-image in the seeds
<Laney> seb128: I think that means that we get the packages from Task: touch-core too
<ogra_> sergiusens, ah
<ogra_> i guess we can
<Laney> seb128: Not sure what your question is - do you want to include that system-image seed?
<slangasek> ogra_: it's ok, but needs to be properly coordinated across both sides of the infrastructure
<seb128> Laney, it seems like it would make sense, what do you think?
<Laney> seb128: probably, would touch-core need splitting up then?
<seb128> Laney, I'm unsure what my question is ;-) trying to figure out what's the right way to do what we need
<seb128> should be seed grub&co like slangasek recommended
<seb128> or somehow makes our seed include the system-image (ubuntu-core) one
<seb128> which already brings those in
<seb128> Laney, unsure, why would it?
<Laney> It has click and some of the same core utilities
<slangasek> sunsetting the ubuntu-touch seed pod would not be a bad idea
<slangasek> it was only ever separate because we needed something that worked while the touch packages were not yet in the archive
<slangasek> it has long outlived its usefulness
<ogra_> slangasek, well, most touch packages are still universe ... the initial plan back then was to merge the touch seed into the official ubuntu branch once they have migrated to main
<slangasek> ogra_: that's upside-down
<ogra_> but then we were told to not push for main inclusion anymore and the whole thing fell off the table
<slangasek> packages move to main *because* they're in the seed
<seb128> Laney, I'm unsure to understand, what would you split touch-core into?
<slangasek> who said not to push for them in main?
<ogra_> slangasek, right, once they are ready for that
<ogra_> slangasek, product team iirc ... i dont know who exactly, back then asac forwarded the info
<ogra_> (when he was still a phone guy... thats all long ago)
<Laney> seb128: Do you want click on this image?
<ogra_> slangasek, all main inclusion efforts have stopped since (beyond stuff like Mir which is used on the desktop too)
<seb128> Laney, not especially, I don't think click is going to work in the image is ro?
<Laney> It's in touch-core
<seb128> Laney, in any case http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.wily/view/head:/system-image has click-apparmor and some other bits
<seb128> Laney, right, but is that right that we derivate from touch-core
<seb128> rather than from system-image ^
<slangasek> ogra_: I don't know what you think "once they're ready" means... getting them ready for main means going through the MIR process
<ogra_> slangasek, exactly that :)
<ogra_> having MIRs, making sure the deps are migrateable etc
<seb128> Laney, sorry, it's all confusing ... I think the easiest first change would be to add the grub depends slangasek recommended to http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop
<seb128> we can see about re-organizing later I guess
<seb128> slangasek, is system-image (ubuntu-core) not including shim-signed [amd64] on purpose?
<ogra_> slangasek, point is, i was the guy nagging people to get their stuff into main and at some point i was told to stop nagging since that wouldnt be wanted ... so i stopped ... and thats the status quo
<ogra_> ask asac for details ...
<Laney> seb128: OK, I guess it would fine to reorganise it in conjunction with moving everything to 'ubuntu'
<Laney> I imagine the MIR team is going to have to grow first
<ogra_> that too
<noise][> sergiusens: or ogra_:  hi, have a minute to help me figure out why that latest rpi2 image I installed has an old/messed-up webdm?
<ogra_> noise][, not only that but you also have a clock at 1970 ... and thats tecnically impossible with the recent image
<ogra_> noise][, did you try flashing it again ?
<ogra_> does smell a bit like your flashing failed
<noise][> ogra_: yes, reflashed, and: cat /etc/ubuntu-build
<noise][> 3
<ogra_> system-image-cli -i
<Laney> seb128: You might want to know if they add things to system-image to mirror those over to desktop
<noise][> and there's recent (jun 11) files
<Laney> i.e. maybe consider subscribing to that branch
<ogra_> thats the better way to find your version
<noise][> k
<ogra_> (but will indeed output 3 too)
<noise][> http://pastebin.ubuntu.com/11719922/
<ogra_> yeah, that looks all fine
<seb128> Laney, yeah
<noise][> but getting that same snappy list output i stuck in the email
<noise][> w/ webdm 0.1
<ogra_> i'm not really sure what to say ...
<noise][> i feel like i must be doing/have done something silly but not seeing what it is :)
<ogra_> there cant be a 0.1 version
<ogra_> and the image clearly ships 0.9
<noise][> i checked the md5sum of the image I dd'd and clearly i'm on #3
<noise][> maybe i'll try to build an image for kicks
<mvo> mterry: have you looked if go generate might be helpful for the gettext stuff?
<ogra_> well, if you use my oem snap and my device tarball and the latest ubuntu-devlce-flash you most likely get an identical image, but try it :)
<ogra_> noise][, you could try to zero the card first or some such
<mterry> mvo, no, let me see what that's about
<noise][> ogra_: I totally wiped it before last dd :(
<ogra_> do you ahev a serial cable so you could capture a full boot with screen -L ?
<ogra_> *have
<ogra_> screen /dev/ttyUSB0 115200 -L
<ogra_> that will create screenlog.0 in your current dir
<noise][> yes, will do
<mterry> mvo, hmm, no probably not super useful.  It's easier to extract strings from all files at once
<genii> Need sudo with screen if you want to set the speed
<ogra_> genii, ug, on gentoo perhaps
<ogra_> :P
<mvo> mterry: aha, if it does not do wildcards, then yeah, probably not. it would also have to run automatically at least during package build which it seems is currently not done
<ogra_> genii, a proper ubuntu should be using udev-acl and give you full access to ttyUSB0
<elopio> sorry I missed the last part of the meeting.
<elopio> crappy internet here.
<ogra_> no sudo needed
<mterry> mvo, yeah, it doesn't run automatically, and it seems oriented towards doing something to *this* file or *this* package.  Whereas I want it to work on all project go files
<genii> ogra_: Interesting, I found without sudo before, and parameters passed don't take. But this is with 12.04
<mterry> Not much convience over a tiny shell script
<ogra_> genii, hmm, even 12.04 should allow that ... sounds like a bug
<mvo> mterry: *nod*
<mterry> mvo, if it ran automatically, that would be nice.  Is there a concept like "install hook"?
<mterry> mvo, btw you can see what I proposed here: https://code.launchpad.net/~mterry/snapcraft/gettext/+merge/261965
<mvo> mterry: I look at it, thanks
<elopio> fgimenez: https://code.launchpad.net/~elopio/snappy/go-tests2/+merge/261982
<elopio> fgimenez: and I think you can remove the python code, your go version works nicely.
<fgimenez> elopio, awesome thx!
<elopio> fgimenez: this one fails: FAILED: ./_integration-tests/tests/80_test_failover. Because of the no reboot file we are touching, right?
<fgimenez> fgimenez, i haven't executed it yet but it'll likely be because of that, we should look into the adt-run error while rebooting
<awojo> is snappy ready to be used as your daily driver on a laptop?
<ogra_> as a server perhaps
<beuno> yeah, not yet
<elopio> fgimenez: it's a little before the reboot. rm: cannot remove â/writable/cache/system/etc/rc.localâ: No such file or directory
<elopio> I'll dig more to see what's that about.
<fgimenez> elopio, i'm getting this http://paste.ubuntu.com/11720144/ it seems that it's rebooting ok?
<elopio> fgimenez: I hate it when it fails only for me
<fgimenez> elopio, yep very frustrating :) there are other tests that also reboot, 07_test_install_framework is working?
<elopio> fgimenez: yes, I was wrong. My error is after the reboot, on the last step.
<noise][> well I can't explain it, but I re-flashed a 3rd time and now I've got the correct webdm 0.9. system-image-cli -i output is exactly the same before/after. very strange. In any case thx ogra_ for the help.
<elopio> fgimenez: http://paste.ubuntu.com/11720208/ the first thing that seems different on mine is that it says "another snappy is running".
<elopio> mvo, sergiusens: any idea what can cause that? ^
<ogra_> noise][, \o/
<ogra_> hooray !!!
<noise][> now to take over the world!
<ogra_> +1
<fgimenez> elopio, i've seen something similar when executing commands at the same time that snappy-autopilot was doing its thing, don't know if it's applicable here
<fgimenez> have a nice evening everyone o/
<sergiusens> elopio: disable autopilot
<ogra_> *sniff*
 * ogra_ sees the vido conferencing thread and notes that nobod even thought about snappy chatroom 
<ogra_> *video
<ogra_> ToyKeeper, did the MAC address fix work for you ?
 * ogra_ needs to get some additional data from other RPis
<ToyKeeper> ogra_: Yes, it did.  Thanks.  :)
<ToyKeeper> ogra_: I tried the snappy chatroom, actually.  :)
<ogra_> could you tell me your MAC ?
<ToyKeeper> b8:27:eb:ec:38:8d
<ogra_> i'm not sure it is actually unique (i only have one Pi)
<ogra_> damn !
<ToyKeeper> Same?
<ogra_> yeah
 * ogra_ will need to talk to the Pi people then ... seems this one is hardcodd into u-boot ... we need the start.elf to hand us the actual info 
<ogra_> ToyKeeper, chatroom is likely not for connferencing with customers indeed ... but every time that discussion comes up i wonder why people dont just run a snappy cloud instance and use it :)
<ToyKeeper> I showed it to Samantha to make a point, and she was quite impressed that "that little thing" could host a video-conferencing service.
<ogra_> :D
<ToyKeeper> (she's trying to find a service to use for a network of private support groups for her nonprofit)
<ogra_> well, in fact your browser hosts it (but dont tell her) :)
<ogra_> the snappy part is only establishing the connections
<ogra_> (and serving the website indeed)
<ToyKeeper> BTW, any suggestions for a relatively easy way to build binaries for the orange box?
<ogra_> plars, hmm, i think  the beagle guys took some effort to make latest beagles not require the S2 button after you booted from the SD once
<ToyKeeper> I'm pondering possibly setting up a lxc host configured to cross-compile, or maybe running a native build environment under docker on the box itself.
<ogra_> the easiest is using qemu-debootstrap to just create an armhf chroot ... but not as fast as real cross compiling
<plars> ogra_: yeah, I really don't want it to behave like that though
<ogra_> plars, but thats upstreams default
<ogra_> we should better deal with it instrea of reverting it
<plars> ogra_: I have a modified emmc image that fixes this for the most part
<ogra_> *instead
<plars> ogra_: that way we can test snappy without having to mess with the snappy image
<ogra_> plars, well, but that way we break fixes that upstream did to their default board setup
<plars> ogra_: the patch that zyga sent for set the bootpart is useful regardless of what I'm trying to do, since it helps deal with the fact that you don't know what's on the emmc
<ogra_> i wouldnt want to do that for the general public
<plars> ogra_: no, the image I'm running is just for me
<ogra_> what if they want to go back to their default debian image
<plars> ogra_: that's the point, you can't do that in any automated way if you have an sd card in there
<plars> ogra_: the only way to do it is to eject the sd card right now
<plars> ogra_: I want a way to get back to the image running on the emmc even if there's something in the sd slot
<ogra_> right, i just got stuck on "I can reliably boot into the emmc when s2 is not held down, and boot to the sd card when it is held down." ... that sounds like you always need to press the button now
<ogra_> which is not upstreams behavior
<plars> ogra_: ah, sorry. that's *only* if you are running my emmc imge
<ogra_> it stores the info if you pressed that button and keeps the setting
<plars> *image
<ogra_> ah, cool  then
<ogra_> zygas case is different because he completely zeroed the MMC
<plars> ogra_: the funny thing right now, is with the default debian image, you can boot snappy without ever touching s2
<ogra_> (including the preinstalled bootloader)
<plars> ogra_: and if you just boot with the snappy sd card, it loads uboot off the emmc and boots the sd card with it - so you could break uboot in the snappy image and nobody would know most likely
<ogra_> heh, yeah
<ogra_> well, the fix is fine then
<plars> ogra_: right, zyga's patch is useful because we currently assume that the user is running the stock debian image. But if they've replaced it, or destroyed it in some weird way, then snappy won't boot
<ogra_> it was just that sentence that made me wonder
<ogra_> yup
<plars> ogra_: sorry for the confusion, I was mostly just trying to add that I had tested it, and it does not even interfere with my automation plans :)
<ogra_> plars, np
<n00b> hi there
<ogra_> yo
<kgunn> jdstrand: hey, just wanna clarify something...i saw where if you goof with apparmor policy and install same snap version you need to
<kgunn> sudo aa-profile-hook
<kgunn> to regenerate the profile, but for seccomp, is there something similar
<kgunn> or is if fine to just keep adding to the list and installing
<kgunn> ....and do i even have to build the snap? or can is there a file i can modify in place on the filesystem (to cut down on the build/install time)
#snappy 2015-06-16
<slangasek> ogra_: system-image doesn't include shim-signed because you can't have both grub-pc and grub-efi-amd64-signed; we want the latter but it's been an incremental process, requiring changes to udf first.  Has udf efi support landed in all the right ppas?
<slangasek> only once it has should we change the grub seeding
<fgimenez> good morning
<dholbach> good morning
<mvo> lool: I love your snappy shell idea (as you know) and couldn't help stating a simple branch that gives it some life:  lp:~mvo/snappy/snappy-console
<ogra_> mvo, i love it too, but please not on port 22 :)
<mvo> ogra_: :) I love the idea of snappy console / repl / cli /shell and being able to interact with it this way. I also like the possiblities it opens up. the points raised in the mail thread are indeed good ones, so by default maybe not
<lool> mvo: awesome  :-)
<ogra_> well...
<ogra_> you could have a "shell" command though :)
<ogra_> that gives you a shell session
<lool> ogra_: this is already in the proposal
<lool> "snappy cli" as a (hidden?) way to start the snappy shell, and "shell" from the cli as a way to start a real shell
<ogra_> lool, yeah, though pitti's argument still stands, ssh remote scripts would fail
<lool> I'm not sure about this
<lool> first, it would work with snappy commands, second, we could implement what people feel is important to get from a running snappy system there, third, there might be ways to reach a shell to run real commands
<ogra_> longsleep, image 0.3 ? not 3.0 ? :)
<JamesTait> Good morning all; happy Fresh Veggies Day! ð
<Chipaca> mvo: is it possible you forgot a prereq on the console branch?
<mvo> Chipaca: maybe, let me double check
<mvo> Chipaca: indeed I did, sorry for that
<Chipaca> mvo: apology accepted
<Chipaca> mvo_: the comment i made in your decorator2 is for addressing in a later branch if at all :)
<Chipaca> mvo_: you know what i'd like? 'snappy verify' to run verify hooks for the apps
<rsalveti> morning
<rsalveti> Chipaca: welcome back
<Chipaca> rsalveti: hey :)
<rsalveti> slangasek: the udf efi branch landed everywhere already
<Chipaca> mvo__: ETOOMANYMVO
<Chipaca> mvo__: commit messages
<mvo> Chipaca: thanks, yeah, adding those now, thanks a bunch for your reviews
<Chipaca> mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface
<Chipaca> oh dear
<Chipaca> mvo: wrt verify, i'm +1 on most of it, but uncomfortable with growing the already-too-large Part interface
<mvo_> Chipaca: makes sense, let me try to think about alternatives then
<Chipaca> mvo_: installed from a local meta already returns only SnapParts
<Chipaca> mvo_: so a jfdi approach would be to do .(*SnapPart) on the parts returned by instlled
<Chipaca> mvo_: a less jfdi approach would split Part into two interfaces, embed the local in the bigger one, and change Installed to return those
<Chipaca> mvo_: another jfdi approach would be to tell me i'm wrong (or pyrrhically right) and go with the branch as writ
<mvo_> Chipaca: I dislike option (3) because you are right and ignoring that is bad(tm). the two-interfaces approach sounds like the cleanest, wdyt?
<Chipaca> mvo_: i think you'll find it's a lot more code :)
<mvo_> Chipaca: heh :) probably I will hate myself for not taking the easy option
 * mvo_ will try to fix his dsl before diving into the branch
<Chipaca> mvo_: may i suggest you set a time limit, take a prod on the interfaces, and bail to the jfdi if it snowballs out of time?
<mvo_> Chipaca: ok, that sounds sensible
<Chipaca> mvo_: and next time i embark on a refactor, remind me to do the same :)
<mvo_> heh :-D
<mvo_> promised!
<sergiusens> Chipaca: \o/ thanks for bringing up the Part interface again :-)
<Chipaca> sergiusens: the price of readable code is eternal vigilantism, or something like that
<sergiusens> Chipaca: yup
<sergiusens> mvo_: so, if you do this, can you add the Ports interface to the local interface?
<sergiusens> it's not part of Parts today and doing the .(*SnapPart) check
<mvo_> sergiusens: yes
<Chipaca> sergiusens: Frameworks might also be moved over, although i do envision a future in which remote parts have Frameworks() and thus the installer can be more helpful wrt that
<sergiusens> Chipaca: i say we request the store to add support for it
<sergiusens> and do nicer things
<Chipaca> sergiusens: yeah, but you know the store guys
<rsalveti> mvo_: any reason for https://trello.com/c/6n9Q3tVh/109-core ?
<Chipaca> they're all like "oh no we can't break things because people will get upset"
<Chipaca> :)
<rsalveti> :-)
<mvo_> rsalveti: that looks like trello was playing tricks on me
<rsalveti> mvo_: :-)
<mvo_> rsalveti: I removed it
<rsalveti> mvo_: thanks
<sergiusens> Chipaca: adding stuff doesn't break anything :-P
<sergiusens> Chipaca: unless you add too much and make it unbearable :-)
<lord4163> How do I list all available snappy packages to install?
<sergiusens> lord4163: snappy search
<lord4163> sergiusens: and then after I installed a package?
<sergiusens> lord4163: snappy list
<lord4163> sergiusens: what can't I use the package now?
<lord4163> holy f*, I typed reboot in my kvm instance and it rebooted the host machine!?!?!?!?!?!?
<lord4163> So this snappy thing is for people missing Windows 95 I guess?
<sergiusens> lord4163: it cetainly isn't for end users (core at least)
<lord4163> for who is it then?
<rsalveti> lord4163: atm it's mainly for builders, which is why sergiusens said core
<rsalveti> once we have more applications and so on, end users can simply consume that from the store
<Chipaca> lord4163: typing reboot in your kvm instance can't reboot the host machine, fwiw
<Chipaca> lord4163: if it can, i hear there's good money in selling the exploit
<lord4163> Chipaca: It did :P
<Chipaca> lord4163: i believe you think it did, but i don't believe it did :)
<lord4163> Chipaca: Let's try it again then.
<Chipaca> lord4163: how'd it go?
<lord4163> Chipaca: didn't work this time
<lord4163> Chipaca: but happened the first time? :P
<Chipaca> sure it did
<lord4163> Now whole GNOME Boxes died
<lord4163> Chipaca: According to journalctl Fabian-PC login[1456]: FAILED LOGIN 1 FROM tty1 FOR kvm guest reboots host
<mterry> mvo_, you mentioned duplicating a i18n.go file in each package.  Does go tolerate sources that are symbolic links?  Cause then you could avoid actual copies of the code at least
<Chipaca> lord4163: i'm not sure what that means
<Chipaca> sergiusens: why isn't setupCloudInit part of first boot?
<mvo_> mterry: nice idea, I don't know, I guess the package statement in the header is the problem
<mterry> mvo_, ugh right
<mterry> mvo_, i18n.G() is better than gettext.Gettext() though
<mterry> but not as good as G()
<sergiusens> Chipaca: because when I proposed to do that I was told not to
<Chipaca> sergiusens: by whom, and why?
<sergiusens> Chipaca: I wanted an oem snap entry to say cloud: on/off
<sergiusens> Chipaca: and just disable the cloud-init job
<Chipaca> cloud: very yes
<Chipaca> cloud: extra strawberry
<Chipaca> sergiusens: that seems sensible to me
<Chipaca> sergiusens: what was the problem with it?
<mterry> mvo_, you could add a i18n package, include a "InjectGettext()" function, then have every package's init() entry point set up a package-wide var for G?
<mterry> mvo_, still copied code, but just a one-line init() maybe
<Chipaca> mvo_: mterry: why not â. "yadda/yadda/i18n"â?
<Chipaca> as long as i18n only exposed a single well-known function, that would seem ok to me
<mterry> Chipaca, oh right!  I forgot you could inline a package.  Maybe that's good enough
 * Chipaca would suggest using some non-ascii char for i18n's function, to avoid clashes and because it's extra twisted
<Chipaca> mterry: mvo_: a function called ê would be nice (it's a capital broken l, because localization! :-p)
<mterry> Chipaca, that'll catch on!
<Chipaca> inorite
<Chipaca> mterry: and then we can move tzdata to ê¨!
<ogra_> there are explicit broken letters in utf-8 ?
<ogra_> wow
<Chipaca> ogra_: ð
<ogra_> hah
<Chipaca> as letters just the L, though
<mterry> Chipaca, there's potential here for a whole programming language, akin to brainfuck
<Chipaca> mterry: dude. APL.
<mterry> Chipaca, hah, yikes
<Chipaca> mterry: on the other hand, finding all primes in APL is: (~RâRâ.ÃR)/Râ1âÎ¹R
<Chipaca> mterry: so we might be on to something
 * Chipaca adds APL to the list of things to never, never learn
<Chipaca> sergiusens: ...?
<mvo_> lol@Chipaca and mterry
<sergiusens> Chipaca: the ... means?
<Chipaca> <Chipaca> sergiusens: what was the problem with it?
<seb128> sergiusens, hey, I tried again u-d-f, using DEBUG_DISK=1, I get a "(parted) mkpart system-a ext4 147456s 147455s" which errors out because the start is after the end (first number bigger)
<seb128> sergiusens, that's on i386 if that makes a difference
<sergiusens> seb128: --size 10?
<seb128> sergiusens, no, why is that needed? isn't that for the writable partition?
<sergiusens> seb128: well each of your a/b parts is now 4GiB instead of 1
<seb128> sergiusens, I don't have 10G free space on that machine, trying again on my other box which has more disk but that's on vivid and trying to build goget-u-t fails on undefined logger.Panicf
<sergiusens> seb128: build as a deb? you need to build on wily
<seb128> sergiusens, shrug, that box is vivid ... do you know what I need from wily?
<seb128> I tried to update golang* and ubuntu-snappy-cli but that's not enough
<sergiusens> seb128: golang-snappy-dev
<seb128> sergiusens, I've the wily version of that
<elopio> fgimenez: I'll be with you in a couple of minutes.
<seb128> sergiusens, I'm trying a clean build
<rickspencer3> hi all
<rickspencer3> I'm writing a snap in Go
<rickspencer3> I am trying to open a yaml file that is at /apps/go-uploader.sideload/0.3/cnf
<rickspencer3> os.Getenv("SNAP_APP_DATA_PATH") send me to
<fgimenez> elopio, ack
<rickspencer3> /var/lib/apps/go-uploader.sideload/0.3/cnf/
<rickspencer3> any idea what I what I am doing wrong?
<sergiusens> rickspencer3: you want another envvar
<rickspencer3> sergiusens, are the envvars documented somewhere?
<Chipaca> rickspencer3: https://developer.ubuntu.com/en/snappy/guides/security-policy/
<sergiusens> Chipaca: thanks, was searching every doc
<Chipaca> rickspencer3: listed, not documented, though
 * sergiusens finds developer.ubuntu.com hard to navigate
<rickspencer3> nice
<rickspencer3> lol
<rickspencer3> Chipaca, do I want SNAP_APP_PATH ?
<sergiusens> rickspencer3: yes
<sergiusens> that one
<rickspencer3> ok
<rickspencer3> tbhanks
<rickspencer3> maybe someone could, you know, list out what each is for ;)
<sergiusens> rickspencer3: or 'snappy install hello-world' and run hello-world.env
<sergiusens> that was in one of the guides I can't seem to find
<rickspencer3> that sounds quite indirect
<Chipaca> rickspencer3: i'll add that to the doc i'm writing :)
<sergiusens> Chipaca: wrt yur question, we need this anyways for backwards compat (setupcloud)
<elopio> ogra_: are you coming to the meeting?
<ogra_> elopio, yes :)
<slangasek> rsalveti: ok, if the udf efi has landed, then we should also make the seed changes to add shim - probably retroactively to 15.04 as well?
 * tedg watches carefully
<tedg> Which seed exactly?
<tedg> :-)
<sergiusens> slangasek: didn't we add all that to 15.04 already a while back?
<slangasek> sergiusens: 'seed changes to add shim'? no
<sergiusens> seb128: personal doesn't have cloud-init seeded, right?
<plars> rsalveti: do you think https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 will be merged at some point soon? It sounds like it causes no harm if you are running the typical debian install on your emmc with bbb, but helps enormously if you do not run the default image on emmc
<fgimenez> elopio, i've pushed the latest changes https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748, ready for review?
<elopio> fgimenez: I see output :)
<fgimenez> elopio, at last! :)
<elopio> fgimenez: yes, ready for review, thanks.
<elopio> fgimenez: maybe you can add the newline here:
<elopio> 256	\ No newline at end of file
<fgimenez> elopio, ok done
<seb128> sergiusens, it has, why?
<dholbach> balloons, elopio, fgimenez, ogra_: mail sent
<elopio> thanks dholbach
<sergiusens> seb128: hmm, I am now missing context
<seb128> sergiusens, <sergiusens> seb128: personal doesn't have cloud-init seeded, right?
<seb128> sergiusens, https://launchpadlibrarian.net/209185916/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz
<seb128> it's installed
<sergiusens> seb128: is it inherited, planned or $reason?
<seb128> sergiusens, http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.wily/view/head:/desktop#L68
<seb128> sergiusens, I guess we copied that from the ubuntu-core seed, we started from there
<tedg> mvo_, Why does apt-cache show have seemingly two sections of data?
<mvo_> tedg: local and remote maybe?
 * mvo_ needs to leave for dinner
<tedg> Hmm, okay. Enjoy!
<stgraber> ok, so I'm working on making a snap for LXD, which for those who haven't heard about it is a container manager based on LXC. That means it's not going to be the simplest snap package in the universe :)
<Chipaca> stgraber: :)
<ogra_> stgraber, dont look at the docker snap ... i heard people say thats a very bad example :)
<Chipaca> perhaps the different kvm-launching snaps would be better
<stgraber> currently my main problem is that LXC contains hardcoded paths. I can obviously get it rebuilt to change those, but I just want to make sure I can rely on stuff being at a fixed filesystem location, say /apps/<snap entry>/current/ and use that in my buil process
<Chipaca> stgraber: note you can't write to /apps/<snap entry>/current though
<ogra_> we have lvm snaps ?
<ogra_> *kvm
<stgraber> and if so, it looks like I'll need two builds, one for local dev (sideloaded) and one for the real thing, as one will have the .sideload suffix
<stgraber> Chipaca: yeah, that's fine
<Chipaca> stgraber: it would be a lot better if you used the environ for those
<Chipaca> how hardcoded are the paths?
<stgraber> configure args which wind up hardcoded in a .so
<Chipaca> ugh
<ogra_> yeah, just de-hardcode them and allow them too be overridden by the $SNAP_* vars
<stgraber> yeah, not quite looking forward to have to carry patches against upstream for that though (and having upstream be aware of SNAP_ isn't acceptable)
<Chipaca> that would be ideal :) or some LXD_* vars, and set those from these
<Chipaca> stgraber: wrt upstream, LXD_ env vars should be ok with them?
<ogra_> right, just translate them :)
<ogra_> you need a shell wrapper anyway
<Chipaca> stgraber: i hear they're a friendly bunch :)
<stgraber> Chipaca: "maybe"
<kgunn> jdstrand: hey i'm trying to modify my seccomp file for mir in place on the vm, but seems to fail on the same syscall...is there a way to update?
<stgraber> Chipaca: the problem is that part of usptream is setuid so we usually wipe our env clean
<kgunn> or do i have to rebuild/reinstall the snap?
<kgunn> tyhicks: ^
<Chipaca> stgraber: that makes sense
<tomconte> ogra_: what's bad about the docker snap?
<ogra_> tomconte, it is just a bad example i heard ...
<stgraber> anyway, will poke around some more, might end up just writting a quick LD_PRELOAD hack for those
<ogra_> since it has a bunch of exceptions a normal snap wouldnt be allowed to use
<Chipaca> stgraber: do keep us updated if you can
<Chipaca> and holler if you get stuck
<tomconte> ogra_: ah, I see, but is there a way to package docker in a "clean" way then?
<ogra_> tomconte, not sure ... i assume the existing docker snap will be updated at some point ... it comes from a time where not much was working in snappy ... nowadays you can get most features you need for a proper docker snap i suspect
<Chipaca> ogra_: it'd still need custom security bits though
<ogra_> well, but a lot less hacks already i guess :)
 * kgunn wonders, isn't it b/c docker is a framework....
<tyhicks> kgunn: you can temporarily update the seccomp whitelist for your snap
<ogra_> kgunn, that too ... but it actually comes from very early snappy days ... we didnt have any story for hardware access and the like back then
<tyhicks> kgunn: what is the failing syscall?
<Chipaca> kgunn: sc-logresolve might help
<Chipaca> jdstrand: when does sc-logresolve print usage()?
<ogra_> Chipaca, when your patch landed that enables it ?
<Chipaca> noted
 * Chipaca branches it
<Chipaca> but if i suddenly disappear it's because somebody found my runaway dog, not because security gremlins took me down
<stgraber> so if I set security-override, does that also turn off any cgroup config that's going on with snappy or is there some other thing I need to set to turn that off?
<stgraber> (LXC has code which will escape the cgroup, so even if I can't turn that off, the cgroup stuff won't apply to me, but that may confuse some things when my process moves out of the cgroup ;))
<tomconte> ogra: thanks, asking b/c we were thinking of a snappy+docker image in azure instead of current full_ubuntu+docker
<Chipaca> stgraber: i'd ask jdstrand that one
<stgraber> jdstrand: heya
<stgraber> jdstrand: so I'm doing an initial LXD packaging. That's obviously a framework and that's coming with more craziness that docker :)
<stgraber> jdstrand: so as a first pass, I'm trying to have everything run without any of the security stuff applied to it. So apparmor unconfined, no seccomp policy and no moving stuff into cgroups.
<stgraber> jdstrand: how do I do that?
<stgraber> jdstrand: (the client itself just needs networking, so that bit will be confined using default policies + networking)
<stgraber> jdstrand: eventually the daemon should be running under an apparmor policy, allowing to transition out to any profile we want (same as lxc-start) but still without any seccomp policy.
<ogra_> tomconte, well, i think you can just go ahead with that ... if docker gets updated it should be transparent to you
<tyhicks> stgraber: the 'unconfined' security template is what you want for running without apparmor or seccomp confinement
<tyhicks> stgraber: I don't recall a way to prevent the launcher from setting up the cgroup - let me look at that code
<ogra_> note that you need to bribe the store people to let your snap into the store then :)
<tyhicks> I think stgraber is just wanting to get something running locally
<tyhicks> and then we can decide on what to do for the confinement
<tyhicks> (prior to uploading to the store)
<stgraber> yeah and that thing will be a framework anyway, so manual review was kinda always the plan :)
<tyhicks> stgraber: it looks like the launcher is unconditionally applying the devices cgroup
<tyhicks> I don't have a good workaround for you there
<stgraber> tyhicks: ok, well, as long as it doesn't get terribly confused when its cgroup ends up being empty, that should be fine
<stgraber> tyhicks: LXC has code that will trigger an absolute cgroup move for all controlers, so it'll escape whatever cgroup the launcher creates for it
<tyhicks> ok
<jdstrand> stgraber: sorry, was in a meeting
<jdstrand> stgraber: so the launcher decides when it is going to do the cgroup thing
<Chipaca> ogra_: https://code.launchpad.net/~chipaca/ubuntu-core-security/usaaage/+merge/262115 just for you :)
<jdstrand> tyhicks: are you looking at the code now for that ^
<jdstrand> tyhicks: my comment, not Chipaca's :)
<jdstrand> Chipaca: oh gosh, sc-logresolve patch. that thing is barely more than back-of-a-napkin as it is :P
<Chipaca> jdstrand: :)
<tyhicks> jdstrand: I already looked at the code - it sets up the devices cgroup unconditionally
<tyhicks> jdstrand: st graber says that shouldn't be a problem for him at the moment
<jdstrand> tyhicks: hmmm, what was I thinking of then... seccomp?
<jdstrand> I know it is making a choice about something, cause docker was grumpy about said something
<jdstrand> or at least, it was making a choice
<tyhicks> I'm not sure about that
<tyhicks> let me look again
<ogra_> Chipaca, LOL !
<tyhicks> stgraber, jdstrand: I guess if ("/var/lib/apparmor/clicks/%s.json.additional", appname) is empty it won't set up the devices cgroup
<jdstrand> that's ringing a bell
<tyhicks> it doesn't have to be empty - it just can't match a hardcoded string in the launcher
<jdstrand> actually I think I documented that
<tyhicks> but creating an empty file is the easiest
<jdstrand> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Cgroups
<jdstrand> "Note: because device names are not always static and due to limitations in AppArmor (1350598, 1444679), the device cgroup mechanism is only used when hardware is assigned to a snap, at which point a general write rule for... Conversely, when no hardware is assigned to the app, then the strict AppArmor rules are in effect and an app-specific cgroup is not used. "
<tyhicks> ah
<tyhicks> right
<tyhicks> so just make sure that ("/var/lib/apparmor/clicks/%s.json.additional", appname) doesn't exist
<jdstrand> I knew there was a reason I wanted to write that down :)
<jdstrand> tyhicks: right, and it won't by default
<jdstrand> an oem snap or hw-assign needs to be used
<tyhicks> got it
<jdstrand> I <3 documentation :)
 * lborda asks: any idea how do I get python-smbus in snappy ? i didn't find the package in the ports repo.
<Chipaca> lborda: there isn't a python-smbus in ubuntu, even
<Chipaca> lborda: but you could probably use the one from debian as a starting place
<ogra_> huh ? how can it be in debian but not ubuntu
<lborda> Chipaca, yes there's only in debian https://packages.debian.org/wheezy/python-smbus
<lborda> Chipaca, i am trying to get the pyglow working on the snappy image... have any of you tried with the pyglow ?
<ogra_> http://ports.ubuntu.com/pool/universe/i/i2c-tools/
<Chipaca> ogra_:
<Chipaca> ï½ï½ï½ï½ï½
<ogra_> there is definitely a python-smbus
<Chipaca> ogra_: but then why isn't there a python-smbus?
<ogra_> even my phone sees it
<Chipaca> john@fogey:~$ apt-cache search python smbus
<Chipaca> john@fogey:~$
 * Chipaca wonders
<ogra_> no universe ?
<lborda> i would thought the the python-smbus package would have to be found inside the universe/p/ folder and not inside pool/universe/i/i2c-tools/
<ogra_> the folders are sorted by source package name ;)
<Chipaca> deb http://archive.ubuntu.com/ubuntu vivid universe
<ogra_> python-smbus is a binary
<ogra_> http://paste.ubuntu.com/11726399/
<ogra_> Chipaca, oh, you have an archive.u.c entry on an armhf machine ?
<Chipaca> no, this was on my desktop
<Chipaca> amd64
<ogra_> ah
 * Chipaca just noticed there is still a debian ia64 port
<ogra_> well, my amd64 laptop finds it too
<ogra_> ogra@styx:~$ apt-cache policy python-smbus|grep archive
<ogra_>         500 http://archive.ubuntu.com/ubuntu/ vivid/universe amd64 Packages
<Chipaca> ok, i'm going to close my computer and go have dinner and pretend weird things are not going on
<Chipaca> because the gammon smells very good and i'm not going to let some silly smbus weirdness ruin it :)
<kickinz1> Just to add to this, I used rmadison against python-smbus:
<kickinz1> http://pastebin.ubuntu.com/11726413/
<ogra_> (which is actually the right tool ... yay us ... )
<kgunn> tyhicks: sorry, was out to lunch...yep, so this is what i'm seeing https://www.youtube.com/watch?v=dbl81P2Vae4
<kgunn> and its munmap
<kgunn> that's the syscall
<mterry> mvo__, so I guess with these gettext branches, we need to push a deb package for the gettext module to wily?
 * mterry was just looking into adding a debian/ dir for snapcraft
<tyhicks> kgunn: something's not right there - munmap is allowed in the default seccomp template (many things would break if we didn't allow munmap)
<tyhicks> kgunn: the resolution isn't great but it looks like you're modifying a seccomp filter file in /apps/mir/snap1/meta/mir.seccomp - is that right?
<kgunn> tyhicks: correct
<kgunn> and i see it showing up in that copy as well as the one at
<kgunn>   /writable/system-data/apps/mir/snap1/meta/mir.seccomp
<tyhicks> kgunn: odd - the launcher looks for seccomp filter files in /var/lib/snappy/seccomp/profiles/
<kgunn> tyhicks: ahha, i see that now...and it's missing, but it's filename is just mir_system-compositor-snap1
<kgunn> i was expecting it to be mir.seccomp
<kgunn> tyhicks: so i'm guessing this is the file to modify...
<tyhicks> kgunn: yeah, give that one a shot and let me know if it works
<kgunn> tyhicks: awesome thank you!....got a new syscall failure....perfect
<kgunn> tyhicks: at your earlier statement at it being strange, is it b/c i'm a framwork and having to create my own policy ?
<kgunn> e.g. i lose all the defaults out of the box when i create my own
<kgunn> tyhicks: and should i just start by copying some particular default file (template) of syscalls permitted ?
<tyhicks> kgunn: ah, yes - now it makes sense
<tyhicks> kgunn: this is the default template: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/view/head:/data/seccomp/templates/ubuntu-core/15.04/default
<jdstrand> kgunn: ah, I meant to follow up with you
<tyhicks> jdstrand: is there any way for a framework to reuse the default template?
<tyhicks> (for seccomp)
<jdstrand> what I have been recommending is installing hello-world.canonical from the store, then scp'ing /var/lib/snappy/seccomp/profiles/hello-world*env into meta/foo.seccomp then referencing foo.seccomp in "security-policy"
<jdstrand> kgunn: so, in your case, on the device, do "sudo snappy install hello-world.canonical"
<jdstrand> kgunn: then do: cd /var/lib/snappy/seccomp/profiles/
<jdstrand> kgunn: then, sudo cp  hello-world.canonical_env_1.0.17 ./<your mir seccomp profile>
<kgunn> perfect guys...thanks, but struggling has helped it make sense
<jdstrand> kgunn: then see if it works. if it doesn't, just add syscalls to the end of ./<your mir seccomp profile> until it does
<jdstrand> one could also do: sed 's/^deny/# EXPLICITLY DENY/' /usr/share/seccomp/templates/ubuntu-core/15.04/default > your.seccomp
<jdstrand> that is harder to remember
<jdstrand> kgunn: iirc, that was all you needed from me yesterday (sorry I didn't see until you were eod)
<ogra_> jdstrand, regading rickspencer3's bug i actually wonder what image he runs there ... (might be one of the broken RPi ones for example)
<rickspencer3> ogra_, if you are talking about my net_admin  denial ... it's an update amd64 image
<jdstrand> ogra_: I confirmed it on amd64 snappy, vivid desktop and precise desktop
<jdstrand> it is something else
<ogra_> (including system-image-cli -i should be mandatory for bug reporting on snappy ;) )
<ogra_> jdstrand, ah, k
<ogra_> rickspencer3, thanks
<jdstrand> ogra_: note, I advised rickspencer3 on what to put in the bug. This seems to be a golang thing but until we know what is tickling that denial, I didn't know where to put it, so we put it in the snappy project for now
<ogra_> ah
<Chipaca> ogra_: kickinz1: fwiw, an apt-get update fixed it, whatever it had been
<rickspencer3> Chipaca, you seem like you would know
<rickspencer3> when do I use SNAP_APP_USER_DATA_PATH,
<rickspencer3> vs. SNAP_APP_DATA_PATH
<rickspencer3> ?
<Chipaca> rickspencer3: i'm not particularly clear on the difference myself, *however*
<rickspencer3> nice
<rickspencer3> lol
<Chipaca> rickspencer3: i do know that SNAP_APP_USER_DATA_PATH is owned by the user
<Chipaca> rickspencer3: and SNAP_APP_DATA_PATH is owned by not-the-user
<rickspencer3> Chipaca, ok, if I wrote a program that saved files from sensor data, which envvar would I use for saving the file in?
<rickspencer3> (and consequently for uploading the file to the cloud service)
<Chipaca> rickspencer3: is that a daemon, or a one-off?
<Chipaca> rickspencer3: daemons will run as root
<rickspencer3> daemon
<rickspencer3> Chipaca, oh
<rickspencer3> well, it is a service
<rickspencer3> don't know if it is daemon per se
<Chipaca> rickspencer3: so SNAP_APP_DATA_PATH should work
<Chipaca> i meant service, yes
<rickspencer3> I declare it as a service, and then use for{time.sleep()}
<rickspencer3> ok
<rickspencer3> thanks Chipaca
<Chipaca> use a time.Ticker, but yes
<rickspencer3> ?
<Chipaca> rickspencer3: go?
<rickspencer3> Chipaca, yes, but the samples I saw said for{time.sleep()} ... time.Ticker sounds somewhat more sensible, though
<Chipaca> rickspencer3: for long-lived processes, inside a loop, a time.Ticker is better
<rickspencer3> ok, I'll do some Googling and fix that up
<Chipaca> time.Sleep is straightforward, but will incurr a higher gc overhead over time
<rickspencer3> we should really have an app template
<rickspencer3> create a stubbed out service for you (or binary if that's what you need)
<Chipaca> rickspencer3: ideally, we'd be exposing systemd timers
<rickspencer3> oh goodness
<Chipaca> rickspencer3: so you wouldn't need the for loop
<rickspencer3> that sounds groovy, yeah
<Chipaca> just tell us how often you want calling, and if you want to wake up the device when the time comes
<rickspencer3> but hard
<Chipaca> not at all
 * Chipaca is tempted to show *how* not-hard it is by jfdi'ing it, but needs to keep to a sane schedule
<olli> how do I unpack a .snap locally?
<Chipaca> olli: dpkg-deb ?
<Chipaca> olli: or ar if you're hardcore
<Chipaca> olli: or renamed it to .deb and use mc to browse it
<ogra_> olli, dpkg-deb -x foobar_0.1_all.snap extracted
<ogra_> olli, cd extracted
<ogra_> ... fiddle ... fiddle ... fiddle ...
<ogra_> cd ..
<olli> hm
<ogra_> snappy build extracted
<olli> thx guys
<awojo> Can you convert to snappy after the fact? I'm installing 15.04 VM right now, but I'd like to use snappy
<ogra_> awojo, no, ther are completely different (snappy is assembled from debs, but then all deb functionality is removed)
<ogra_> s/ther/they/
<tedg> So the code using apt-cache and such is getting brittle. Thinking about switching to the python module.
<awojo> So I'd have to download the snappy iso, and rebuild my VM?
<tedg> Haven't used it before, anyone giving warnings? :-)
<ogra_> rickspencer3, SNAP_APP_DATA_PATH is /var /lib/apps/<app>/<version> ... SNAP_APP_USER_DATA_PATH is ~/apps/<app>/<version>/
<rickspencer3> ogra_, so, if I am capturing sensor data into files, where would I store it?
<rickspencer3> i.e. into which dir should I save the file?
<ogra_> rickspencer3, if it is a service SNAP_APP_DATA_PATH ... if it is an app the enduser runs perhaps in the USER_DATA_PATH
<rickspencer3> it is a service
<rickspencer3> interesting distinction
 * ogra_ never had the need to use the latter yet
<rickspencer3> oh, i guess if it is a multi-user system
<ogra_> well, you need to have $USER for the latter
<Chipaca> awojo: no
<Chipaca> awojo: what're you wanting to do?
<ogra_> awojo, the img is a ready made VM already ... nothing to do ... just download, uncompress and start it with kvm
<tedg> We probably named those DATA_PATH variables wrong. We should have made it easier to store in the USER directory than the system one.
<ogra_> tedg, well, you need a user for that ...
<ogra_> tedg, most bits we have/had in the store are actually services
<ogra_> (only pastebinit is an enduser app  i think)
<tedg> ogra_, Sure, so for services they should be the same value, no?
<ogra_> for services you cant user them
<ogra_> s/them/SNAP_APP_USER_DATA_PATH/
<ogra_> there is no user ... where would it point to ?
<plars> rsalveti: Not sure if you saw this earlier: do you think https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 will be merged at some point soon? It sounds like it causes no harm if you are running the typical debian install on your emmc with bbb, but helps enormously if you do not run the default image on emmc
<tedg> So perhaps we shouldn't have USER_DATA_PATH at all. If there is a user point to the user's home, otherwise the system dir.
<plars> or anyone else that might know? ogra_ I think you were looking at that MP also?
<tedg> Nobody needs both.
<Chipaca> tedg: +1 i think
 * sergiusens is back
<ogra_> well, not sure, someone surely had a usecase in mind when adding it
<ogra_> (i havent found one where i could make any use of it yet though)
 * tedg goes on record: Nobody will ever use more than one directory
<rsalveti> plars: sure, I can take a look
<ogra_> if you have an app that stores config data per user SNAP_APP_USER_DATA_PATH is your place
<plars> rsalveti: not a super big rush, just wondering, and it's a one-liner
<ogra_> plars, i would feel comfortable if elopio could give it a quick shot
<rsalveti> yeah, just need further testing
<ogra_> (after all its a one line change ... quickly done and tested)
<rsalveti> elopio: care to stamp https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833 ?
<ogra_> boot, rollback, auto-rollback
<rsalveti> otherwise I can take a look earlier tomorrow
<sergiusens> tedg: USER_DATA_PATH is user accessible while SNAP_APP_DATA_PATH root accessible (initially one was for binaries and the other for services)
<sergiusens> I didn't come up with it and I didn't read the backlog either :-)
<tedg> sergiusens, The question is whether there'd ever be an app snap that would do both. It seems services need one while user apps need a different one. Seems like there could be one variable depending on how it is executed.
<ogra_> but that could be confusing
<ogra_> for the packager
<sergiusens> tedg: my camlistore snap (which is currently unpublished) used both
<tedg> sergiusens, How did it use both?
<ogra_> sergiusens, yeah, where is it ... fix that !
<ogra_> :)
<tedg> It seems like the service couldn't ever expect to use USER, but I could see an app share with the service through the SYSTEM one.
<ogra_> the webdm store on armhf makes me cry currently ...
<ogra_> it used to be so niecely filled already
<tedg> Not sure if that isn't just bad design though :-)
<ogra_> tedg, what about a service that serves an app shipped in the same snap
<ogra_> you'd want one path for the root owned files and the other for user settings
<tedg> ogra_, There's also be multiple users, so it couldn't really use the USER directory.
<ogra_> why ?
<ogra_> teh app knows who executed it
<ogra_> (the service doesnt indeed)
<tedg> Yes, I don't think the service ever needs to know the USER one.
<ogra_> i.e. i have a service and a management app ...
<tedg> Though I could see a app accessing the system one. For instance if there was a service that updated a cache.
<ogra_> no, the service doesnt need to know the user one
<ogra_> but the app does
<ogra_> to store per user settings
<ogra_> so your snap needs to use both
<ogra_> but that setup comes from a time wheer we didnt have a launcher :)
<ogra_> might indeed be obbsolete if the launcher can handle it based on $knowledge (whatever $knowledge is)
<tedg> Not sure exactly what that should be. But yes, it is interesting. Seems that we'd want DATA_PATH to be "where we want you to write your files" where that is contextual.
<jdstrand> kgunn: hey, ok, based on what you've been experiencing and the questions you've had, I wrote up: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy
<kgunn> cool jdstrand
<sergiusens> tedg: right camlistore's binaries were executed by the user
<jdstrand> kgunn: there may be info in there that you might still find helpful
<kgunn> will read
<tedg> sergiusens, So then what did you use the system directory for? The user wouldn't have access, no?
<kgunn> jdstrand: perfect the development tips is effectively the workflow i'm in at the moment
<jdstrand> great :)
<sergiusens> tedg: the client and server communicated over http
<sergiusens> tedg: server config in /var and user config into /home (the client could talk to other servers and the server could be talked to with other clients, but that is obvious I guess :-P)
<tedg> sergiusens, I see. So some binaries were executed under the user and then the service was executed under systemd.
<sergiusens> tedg: yup
 * ogra_ can imagine there will be many such snaps in the future
<ogra_> services and management tools in the same package ...
<tedg> Wonder if we could make that easier. Like setup a socket for them that was also in the environment.
<ogra_> that wont help if your management app needs to write a config file
<tedg> How is that going to work on a mobile device, will we allow services?
<ogra_> (which it reads on next startup)
<ogra_> no idea, but surely on a desktop and on appliances
<tedg> ogra_, I was more thinking in addition to.
<ogra_> i can imagine that we want to allow things like an upnp service on a phone
<tedg> Not that we'd remove the other mechanisms, just provide an easy way for them to build that app/service architecture.
<ogra_> or a streaming service
<ogra_> did you know that the first ubuntu phone hack by some external guys was to run a tomcat server on a nexus4 ? ... so i guess we will see that kind of insanity too :)
<tedg> Wow, I don't even want Java in browser, much less Tomcat :-)
<ogra_> http://community.bonitasoft.com/blog/bonita-platform-running-smartphone
<ogra_> oh !
<ogra_> i was wrong ... they even ran it on a galaxy nexus !
 * ogra_ just noticed the uname in the screenshot 
<sergiusens> ogra_: wow, that brings back memories :-P
<ogra_> yeah :)
<rsalveti> maguro, wow
<rsalveti> that brings back memories indeed
<elopio> rsalveti: ogra_: plars: sure, let me check it.
<ogra_> wow, SUI vs CMR just got interesting .. cameroon leads
<rsalveti> sergiusens: ogra_: snappy on ppc? http://linuxgizmos.com/powerpc-based-iot-gateway-com-ships-with-linux-bsp/
<rsalveti> :-)
<sergiusens> rsalveti: well we do have powerpc support :-)
<ogra_> no prob :)
<rsalveti> yeah
<ogra_> (though i shouldnt speak to loud, we dont even manage to produce arm64 atm :P )
<sergiusens> ogra_: rsalveti we need to get out of fat packaging :-P
<ogra_> yeah, who came up with that insanity :)
<sergiusens> we can blame Chipaca :-P
<Chipaca> why do we need to get out of fat packaging?
<Chipaca> we're doing a lousy job of it right now, fo sure :)
<sergiusens> Chipaca: i dunno N arches and N gets bigger every day
<sergiusens> Chipaca: we can be smart once we have the store list the files with hashes and tags them with arch (with automagic header reading)
<Chipaca> sergiusens: yes, but on the one hand the app binaries are not what take up most of the disk space in many scenarios
<sergiusens> Chipaca: well camlistore is ~10MB for each arch
<Chipaca> sergiusens: and on the other hand nothing stops the store from stripping the non-arch things out (other than signage maybe?)
<Chipaca> in my mind ideally we support both cases well
<Chipaca> people that care package each arch separately
<Chipaca> people that don't make a fat one and live simpler lives
<sergiusens> Chipaca: probably
 * sergiusens likes to live a simpler life
<Chipaca> that'd probably make the "store does magic" thing not be necessary
 * ogra_ too
<Chipaca> so the answer is simpler
<Chipaca> make a fat one
 * Chipaca runs
<sergiusens> Chipaca: the WHO would have something to say about that
<sergiusens> ... not the band :-P
 * Chipaca moves to the netherlands
<Chipaca> on a more serious note, if we can agree on some conventions we can have the launcher do LD_PRELOAD and select the right arch binary if multiple are present
<Chipaca> not LD_PRELOAD
<Chipaca> LD_LIBRARY_PATH
<Chipaca> i think that'd be a good first step :)
<ogra_> doesnt it do that already ?
<sergiusens> Chipaca: conventions make things easy, that's how we quickly got things going with click (when moving away from deb)
<Chipaca> ogra_: no
<ogra_> oh
 * sergiusens stole the convention trick from go
<Chipaca> ogra_: yeah
<sergiusens> ogra_: you can't LD_LIBRARY_PATH if you don't define where that will be
<ogra_> ubuntu-app-launch does it on the phone ... i thought that feature was in the snappy launcher too
<sergiusens> ogra_: no, not there
<ogra_> sergiusens, yeah, i thought there was a default like on the phone
<sergiusens> we can do it for binpath too
<sergiusens> ogra_: that's why the magic script became popular
 * sergiusens wonders if the channel will go silent in 40'
<ogra_> on the phone is is <installpath>lib/<triplet>/
<ogra_> why in 40
<Chipaca> ogra_: something something copa amÃ©rica, i'm guessing
<ogra_> pffft regional stuff
<sergiusens> ogra_: Argentina vs Uruguay :P
 * ogra_ watches the *world* cup instead 
<sergiusens> ogra_: is that world as the US defines it? "The world series"
<ogra_> cameroon switzerland was really great right now
<ogra_> switzerland actually lost ... completely unexpected and dramatic :)
<ogra_> sergiusens, nope
<Chipaca> cameroon-switzerland is just as regional as argentina-uruguay
<ogra_> womens world cup ;)
<Chipaca> ah, ok :)
<Chipaca> (i was going to make a joke about them both being in the africa-eurasia region/continent, but didn't)
<sergiusens> Chipaca: while you are at it... https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865
<Chipaca> afro-eurasia*
<Chipaca> yeah, bring it on
<Chipaca> gasp! installYaml is ready to go?
<sergiusens> Chipaca: yeah, been ready for a while
<Chipaca> sergiusens: took me a while to realise Boot was not a verb in diskimage
<Chipaca> sergiusens: anything else? otherwise it's a wrap from me
<sergiusens> Chipaca: wrap it up, personal is still downloading here...
<Chipaca> k
<sergiusens> thanks
<ogra_> sergiusens, good luck !!
#snappy 2015-06-17
<rsalveti> sergiusens: sorry I forgot to put my test results at https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/beBetter/+merge/261804
<rsalveti> sergiusens: but yeah, it's a +1 for me as well
<rsalveti> Chipaca is a review machine
<fgimenez> good morning
<dholbach> good morning
<mvo> Chipaca: hey, I think you had a idea how to make https://code.launchpad.net/~mvo/snappy/snappy-gettext nicer (?) i.e. how to get a import so that we can use G() or something similar short, or am I misremembering(?)
<longsleep> sergiusens: Hey - do you have any update on the review process for the ODROIDC OEM snap? It seems like it's stuck and i got no reply to my latest comments.
<JamesTait> Good morning all; happy Eat Your Vegetables Day!
<Chipaca> mvo: hey
<Chipaca> mvo: yes
<Chipaca> mvo: but only if you promise it'll only export one function (and ideally not something as collisiony as G(), but maybe i'm overthinking it) :)
<mvo> Chipaca: we need two :) G() (or L() i don't care) and NG() (ngettext)
<Chipaca> mvo: fair enough
<Chipaca> i guess G and LG don't clash with anything right now
<Chipaca> mvo: very easy to do, tbh; just import it with a . as we do with gocheck in the tests
<mvo> Chipaca: heh, sure! great suggestion, thanks!
<mvo> Chipaca: its one of these ideas thats obvious *once* you had it
<mvo> \o/
<Chipaca> tyhicks: love your work on the CAP_NET_ADMIN thing, thank you!
<rsalveti> longsleep: dholbach might be able to help you with the review related questions
<dholbach> rsalveti, hum... how=?
<ogra_> rsalveti, so mzanetti just asked me an interesting question ... how will phone devs develop system components on the phone once we have no dpkg support at all anymore ?
<rsalveti> dholbach: store related review questions, thought you had review permission as well
<dholbach> rsalveti, yes, I do - I just wasn't sure if we had a process figured out for reviewing OEM snaps already
<rsalveti> hm, right, that I don't know
<longsleep> dholbach: well i received some comments, but now the process seems to be stuck as nobody did answer lately :)
<rsalveti> ogra_: I fail to related developing system components and dpkg here
<rsalveti> *relate
<dholbach> "Supported architectures:Architecture independent" is likely wrong
<ogra_> rsalveti, today you build your stuff in a silo and then install the debs
<dholbach> let me take another look at the comments
<longsleep> dholbach: the only request i got was to rename it to odroid-community - i renamed it in the store only and i am not sure if that is the correct way of action
<ogra_> or re-build the packages locally
<rsalveti> ogra_: right, if an app I'd imagine it would just be a simple snap, if part of core, I'd imagine you'd need to rebuild/reinstall the framework
<ogra_> and then install them ...
<ogra_> rsalveti, if the phone bits including the UI are in the core image ?
<ogra_> (which is how i understood the planned setup)
<mzanetti> rsalveti, so if I want to test a small patch on unity I need to rebuild the framework?
<mzanetti> ok, the severity of that really depends on what the framework is :D
<ogra_> i dont think it will be a framework ... unless rsalveti knows something new ...
<rsalveti> for personal you would indeed just follow the current dev steps you do for phone
<rsalveti> dpkg will be available
<dholbach> ah, "Architecture independent" might actually be right
<ogra_> rsalveti, so we will have special developer images that ship dpkg ?
<rsalveti> once we move away from personal and get just core + snaps, then we'd need to find the right spot for your piece
<ogra_> i thought the masterplan was to completely get rid of it
<mzanetti> can you elaborate on the "move away from personal" thing?
<ogra_> to me it looks like a dev changing core would have to re-build the whole image every time
<rsalveti> ogra_: that is the masterplan, but I don't think that will be removed from personal
<ogra_> ok
<ogra_> as i understood some desktop discussions the plan was to only have dpkg fenced inside an lxc container we ship by default
<rsalveti> mzanetti: so personal is a shortcut atm, since transforming everything into a snap (framework and apps), is a lot of work
<dholbach> jdstrand, beuno, sergiusens: regarding the odroidc oem snap decision: are you aware of anything else that needs to be done? is "arch independent" correct in this case?
<rsalveti> so instead of doing that now, we created another base image that includes everything
<ogra_> (so you wouldnt have it available on the actual core system)
<ogra_> but if we keep it i guess thats fine then
<dholbach> longsleep, ^ I just went ahead and pinged some other folks who should know more
<rsalveti> moving away from personal would mean start using the core + snaps (framework and apps)
<dholbach> longsleep, sorry for not being of more help here
<mzanetti> rsalveti, you mean converting unity into a snap itself?
<rsalveti> mzanetti: yup
<longsleep> dholbach: ok great thanks - no worries i am not really in any hurry as long as there is no way to handle the device part with the store.
<rsalveti> mzanetti: how that will be done is not clear yet
<mzanetti> rsalveti, ok. thanks for clarifying.
<seb128> rsalveti, but personnal is still a snappy image and ro, so you can't dpkg things there
<rsalveti> seb128: right, but that restriction already exists on phone images
<rsalveti> the use case is for people already remounting things with rw
<seb128> rsalveti, you can turn the phone rw by touching a file and rebooting, is that going to work on snappy?
<rsalveti> seb128: that is still an open question (if we're going to offer something similar), but I'd imagine we don't want to do that
<rsalveti> the logic is currently inside the initrd
<rsalveti> not sure if for personal this is something you might want to offer
<seb128> rsalveti, but you can mount -o remount rw?
<rsalveti> seb128: if you have sudo access, sure
<ogra_> seb128, sure, why not
<ogra_> seb128, the initial question was just "what do we do if dpkg is gone" .... in which case you would have to install binary tarballs or some such
<seb128> oh ok
<Chipaca> mvo_: when tarmac complains about "there are additional revisions yadda yadda", it's the timestamp of the top-approval it's complaining about
<seb128> well the snappy image is still built from debs
<seb128> so no reason dpkg is gone
<ogra_> but since we will keep it for now even though the masterplan is to have it not in the images, we are fine
<seb128> do we plan to stop using debs to build the images?
<ogra_> long term it will be gone, but by that time the desktop/phone will have switched to frameworks and snaps
<ogra_> no
<rsalveti> not necessarily, but there is no need for dpkg to be installed
<ogra_> but we will likely remove dpkg at the end of the build
<rsalveti> if we're not using it
<ogra_> (and a lot more)
<ogra_> i would imagine out core image to have only a third of the current size once we are done
<ogra_> if not even less
<rsalveti> right
<rsalveti> there is a card to investigate that
<rsalveti> https://trello.com/c/JdwIFPwn/57-investigate-if-we-can-remove-apt-dpkg-from-the-image
<ogra_> yeah
<seb128> rsalveti, right, it's just difficult to convince a deb system to remove dpkg :p
<ogra_> rm :)
<seb128> well then no need to debs anymore
<seb128> you can also cp
<ogra_> sure
<ogra_> perhaps we'll do that one day
<ogra_> but our infra is still built around packages today
<seb128> right
<ogra_> so why not use them
<ogra_> on an embedded system where you are only interested in getting enough OS to boot, you dont really want the bloat
<seb128> sure
<ogra_> the core image i envision will only have dash, systemd and a few snapp tools installed (and whatever is needed to make these run)
<Chipaca> beuno: you around?
<rsalveti> Chipaca: mvo_: I know sergiusens was having this issue the other day, but do you guys know why we cna't use --install=docker when creating images? looking at bug https://bugs.launchpad.net/snappy/+bug/1465879
<ubottu> Ubuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed]
<Chipaca> rsalveti: check snappy-devel
<Chipaca> rsalveti: or, https://bugs.launchpad.net/snappy/+bug/1464486
<ubottu> Ubuntu bug 1464486 in goget-ubuntu-touch (Ubuntu) "frameworks that install policies cannot be preinstalled" [Undecided,New]
<Chipaca> rsalveti: we should confirm whether it happens with trunk snappy, as it's merged there
<Chipaca> ah! maybe it's still needing u-d-f work
 * rsalveti checks
<mvo_> rsalveti, Chipaca: it may just need a rebuild of u-d-f against current snappy (shared libs ftw :/)
<rsalveti> guess also backporting https://code.launchpad.net/~sergiusens/snappy/policyRoot/+merge/261802 ?
<rsalveti> or just udf would be enough? (the rebuild)
<gatisp> Hello, I think there is a mistake in https://developer.ubuntu.com/en/snappy/guides/porting/ under "Snappy enablement basics and the device tarball."
<gatisp> it says: "system: directory shipping kernel modules that are only needed after the rootfs has been mounted;"
<ogra_> that is correct
<ogra_> what would you expect it to be ?
<gatisp> shouldn't it say modules that are needed before mounting rootfs?
<ogra_> no, these have to go into the initrd
<gatisp> ah, right
<ogra_> (though i'd always recommend that if you use a custom kernel you simply compile that stuff in, it is usually just something like ext4 support and the like)
<ogra_> The following packages have unmet dependencies:
<ogra_>  ubuntu-snappy : Depends: ubuntu-snappy-cli (= 1.1.2-1+510~ubuntu15.10.1) but it is not going to be installed
<ogra_> E: Unable to correct problems, you have held broken packages.
<ogra_> ... from this mornings image build ...
<ogra_> did anyone look into that yet ?
<ogra_> (armhf and i386 images failed it seems)
<sergiusens> rsalveti: it should work with the latest build already
<sergiusens> rsalveti: or a rebuild of u-d-f I mean
<rsalveti> sergiusens: morning :-)
<sergiusens> we can check with Built-Using tags
<sergiusens> good morning :-)
<rsalveti> sergiusens: cool, guess we just need to upload a new udf and copy it over to our ppas
<rsalveti> ogra_: hm, that version is in our ppa
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image
<rsalveti> sergiusens: care to upload a new version once https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 gets merged?
<ogra_> amd64 built fine
<rsalveti> tarmac is currently complaining about it
<ogra_> probably a timing error where the arch all side had not migtared
<rsalveti> ogra_: yeah
<ogra_> i guess someone should just trigger a new build
<sergiusens> rsalveti: yeah, gofmt, no sure how it happened, but it happened
<sergiusens> rsalveti: maybe due to the files I just rebased but did not edit (I have goimports run as a PreWrite or whatever it was called in vim)
<rsalveti> hm, but amd64 is failing quite frequently
<rsalveti> https://launchpadlibrarian.net/209210238/buildlog_ubuntu-wily-amd64.ubuntu-snappy_1.1.2-1%2B511~ubuntu15.10.1_BUILDING.txt.gz
<rsalveti> FAIL: touch_test.go:30: HTestSuite.TestUpdateTimestamp
<rsalveti> mvo_: seems those unstable tests showing up again
<rsalveti> this time for amd64
<sergiusens> rsalveti: heh, time based test failures ftw
 * ogra_ triggers a new image
<rsalveti> ogra_: amd64 is still ftbfs
<ogra_> sure, but that shouldnt make armhf and i386 fail
<rsalveti> we we only care about armhf and amd64 atm
<ogra_> that package comes from the PPA ...
<ogra_> no proposed-migration there
<rsalveti> so one of the main archs will fail
<ogra_> (or do we have it)
<ogra_> damn !
 * ogra_ read arm64 
<rsalveti> there is another build in progress
<rsalveti> someone triggered it
<ogra_> silly silly silly naming !!!!!
<rsalveti> haha, /me does that all the time
<ogra_> well, i triggered one ... might be me
<rsalveti> :-)
<ricmm> armd64
<ogra_> well, at least they fail fast :)
<ogra_> (i386 is already done)
<ogra_> ricmm, on compiler level the naming is even worse ...
<ogra_> aargh64
<ogra_> err
<ogra_> aarch64
<ogra_> oh
<ogra_> amd64 succeeded
<sergiusens> fgimenez: elopio where should I add an acceptance test for https://trello.com/c/PJE5oYAF/84-disabling-updates-and-auto-update-when-using-sideloaded-kernel-snaps ?
<sergiusens> can any of you two help me get started?
<ogra_> sergiusens, oh, has that landed ?
 * ogra_ needs to not forget to re-enable autopilot 
<sergiusens> ogra_: in process of
<ogra_> k, thanks
<sergiusens> ogra_: got stuck in the pipeline
<fgimenez> sergiusens, currently we are adding them in _integration_tests/tests, see https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748
<fgimenez> sergiusens, i'll push changes shortly to allow adding more than one test file, all of them are now in snappy_test.go
<sergiusens> fgimenez: this doesn't drive image creation though, right?
<fgimenez> sergiusens, yes, calling it with "go run _integration_tests/main.go" should do it all, compile debs, create image and call adt-run on it
<sergiusens> fgimenez: nice, I need to create the image in a different way though
<sergiusens> fgimenez: hmm, maybe for E2E but I can tamper with the image to set what I need
<fgimenez> sergiusens, yep, it's not very configurable atm :)
<sergiusens> fgimenez: should I go with the half test?
<sergiusens> I would like to have E2E eventually though
<fgimenez> sergiusens, how could this be setup?
<beuno> Chipaca, hola
<Chipaca> beuno: hola!
<Chipaca> beuno: in CPI, the description is described as âFull description of the app's functionality.â. Is that one of the things entered via the online form, or is it extracted from the package?
<beuno> Chipaca, yes.
<beuno> Chipaca, extracted from the package, can be edited in the form
<Chipaca> beuno: i'm confused a little, then
<Chipaca> beuno: where is it extracted from?
<Chipaca> beuno: "snappy build" loads it with the description from the readme
<Chipaca> beuno: that is, it sets the manifest's description entry to the readme
<Chipaca> to the second+ line of the readme
<beuno> Chipaca, it parses it from the json
<Chipaca> to all the non-blank lines after the first non-blank line in the readme
<Chipaca> beuno: from the json manifest, yes?
<sergiusens> beuno: can we make it not editable?
<Chipaca> beuno: same place you get all the other metadata from?
<sergiusens> Chipaca: for when time happens https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/personalCmd/+merge/262174
<Chipaca> beuno: because i'm confused, therefore, by the results from the store which seem to prepend the title to the description in the description
<beuno> sergiusens, no, because then you need to re-upload a 800mb snap to fix a typo in the description
<beuno> Chipaca, same place, es
<beuno> Chipaca, I think it might merge 2 fields into the description
<beuno> jayteeuk knows the details
<Chipaca> beuno: also the title is not the title, it's the name?
<Chipaca> seriously confused :)
<JamesTait> It wasn't me!
<sergiusens> beuno: right, but then the data is inconsistent as well
<Chipaca> JamesTait: ehlo :)
<rsalveti> sergiusens: holy, there are at least 5 branches waiting to be merged in goget
<Chipaca> if you GET 'https://search.apps.ubuntu.com/api/v1/search?fields=title%2Cdescription&q=hello-world'
<rsalveti> ubuntu-touch
<sergiusens> beuno: or in other words, the local data is useless
<JamesTait> Chipaca, 501 Syntax: EHLO hostname
<JamesTait> ð
<rsalveti> sergiusens: can we have an upload after merging https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/installYaml/+merge/261865 ?
<Chipaca> JamesTait: ehlo chipaca
<rsalveti> to split the personal stuff in another upload
<sergiusens> rsalveti: yeah, didn't I says yes already :-P ?
<rsalveti> sergiusens: just wanted to double confirm :P
<Chipaca> JamesTait: if you GET the above uri
<beuno> sergiusens, correct
<Chipaca> JamesTait: and look at hello-world.canonical
<sergiusens> rsalveti: split is new though... so one sec I'll set to needs review
<beuno> sergiusens, the idea always was to take whatever the store told you instead of what the package says
<Chipaca> JamesTait: or any of the others really
<sergiusens> beuno: so why do all this packaging format if we don't need it?
<beuno> sergiusens, initial seeding of the information
<sergiusens> let's just remove icon. description, title, readme.md from the packaging
<Chipaca> JamesTait: it seems to be setting title to ... something? and description to something else, neither of which match the title and description in the click manifest as far as i can tell
<sergiusens> beuno: we can seed with an external file
<sergiusens> no need for it to be part of the packaging if it's going to be useless data
<sergiusens> mvo_: ^
<JamesTait> Chipaca, without having clicked on those links, let me first put pad.lv/1303354 out there.
<JamesTait> Now let me click on the links and see what else I can add.
<JamesTait> Chipaca, so, "look at hello-world.canonical" where?
<Chipaca> JamesTait: in particular, the title is ... dunno what; the description is the \n-glomming of title and description
<Chipaca> JamesTait: http://pastebin.ubuntu.com/11730186/
<Chipaca> beuno: sergiusens: easy way to fix that is to "fix" the package when edited
<JamesTait> Chipaca, right, so the latter part of that is addressed by the bug I pasted above.
<JamesTait> Chipaca, do you have a devportal link to that package?
<Chipaca> JamesTait: i'll believe you, but i have no idea what the "app summary" or the "tagline" is, in this context
<beuno> Chipaca, ew ew ew
<beuno> no!
<beuno> ew
<Chipaca> JamesTait: id 1999 <- is that good enough?
<beuno> no touching the binaries!
<Chipaca> beuno: you'd rather confuse the user by letting them download things that when downloaded do not describe themselves as the things they chose to download did?
<JamesTait> Chipaca, indeed it is. âº
<beuno> Chipaca, or, you download the store's json when downloading the app and use that to display
<Chipaca> beuno: you don't have to edit the binary, of course; you can also modify it on the fly when the user downloads it :-p
 * beuno dims his laptop's screen to the minimum
<JamesTait> The "Sorry, can't hear you!" approach.
<Chipaca> beuno: that makes the client a lot harder, especially wrt uniformity of behaviour wrt sideloaded apps; it also n-uplicates information (we'd have the package.yaml, the click manifest, and the store manifest)
<sergiusens> beuno: the data needs to be consistent though
<sergiusens> I think it's bad design
<Chipaca> beuno: and moves work to the client, which is underpowered and numerous
<JamesTait> Chipaca, bear in mind that these models evolved from the old software centre ones, which were based on .deb packages. So tagline is the one-line description and app-summary is the full description.
<Chipaca> JamesTait: http://www.brainlesstales.com/images/2013/Jul/bear-in-mind.jpg
<JamesTait> Chipaca, in snap package terms, that maps to... hang on, checking. âº
<Chipaca> deb-control(5) does not call it a tagline nor an app summary, either
<beuno> Chipaca, so we make people upload 800mb to fix a typo or set a promo for their app?
<Chipaca> short description and long description
<sergiusens> beuno: we can also split the packaging if it's useless data as you said
<sergiusens> the "metadata" doesn't need to be there
<Chipaca> sergiusens: how is that different from downloading the store json?
<sergiusens> beuno: but keep in mind the no caching rule, the store would be spammed by thousands of clients
<sergiusens> Chipaca: oh, I'm talking about "on upload"
<Chipaca> sergiusens: i'm talking about not understanding how that would be different for the client :)
<sergiusens> Chipaca: the initial seeding problem
<Chipaca> sergiusens: you mean the server would assemble the package from these bits?
<sergiusens> Chipaca: oh, if the store stays this way the client gets more logic, and the store gets more load
<Chipaca> ok, i'm going to move on for now, but this is a problem and needs addressing at some point
<sergiusens> Chipaca: we'd download two bits; the store json (and icon) and the actual package (which would be a list of hashed files)
 * Chipaca comes back
<Chipaca> sergiusens: k
<sergiusens> Chipaca: but let's break the lie about package.yaml and readme.md if it is just to "seed"
<Chipaca> sergiusens: i didn't quite follow you there
<Chipaca> beuno: tbh i'm starting to wonder whether having the click and snappy stores conjoined is still a good idea
<Chipaca> we seem to be making things harder for ourselves as we go
<beuno> Chipaca, I asked if I could double the team size and they counter-offered with taking away half
<Chipaca> beuno: just in case it sounded that way, i'm not saying you or your team messed up; i do believe we've at each step collectively taken the shortest path to get places
<Chipaca> as we should
<beuno> Chipaca, :)
<beuno> Chipaca, so what would you propose?
<beuno> splitting away from parsing the json?
<Chipaca> beuno: i'd propose coffee
<Chipaca> :)
<beuno> Chipaca, SOLD!
<JamesTait> I like proposals like that.
<Chipaca> beuno: wrt the store, is it the case that it and the cpi is getting riddled with click-vs-snappy complications? or is it still relatively unified?
<Chipaca> JamesTait: ^ might be for you actually
 * Chipaca puts on the kettle
<beuno> Chipaca, I haven't seen keeping that backwards compatibility force us to make compromises
<beuno> but JamesTait and nessita would have a more boots-on-the-ground answer
<JamesTait> I'm a little out of touch with the big picture, tbh, but unless things have changed drastically the differences between handling a click package and a snap package are miniscule.
<Chipaca> on the client side it is a little fiddly, and that's without trying to make the remote-vs-local thing go away
<JamesTait> Like, we parse a yaml file instead of a json file, and we set the is_snap flag to True.
<beuno> Chipaca, the phone went through the same remote-vs-local phase, FWIW
<Chipaca> ....
<Chipaca> JamesTait: you parse a yaml file?
<beuno> JamesTait, we still parse the json
<JamesTait> * May be simplifying slightly.
<beuno> and snap packages copy over the yaml to json  :)
<Chipaca> âcopyâ
<Chipaca> âyamlâ
<beuno> Chipaca, so, for the most part, we can't split the stores
<beuno> because most of our deliverables apply to both
<Chipaca> it sounds like the store is doing the least work, and we're all muddled on the client
<Chipaca> which is not terrible, as long as we can resolve the local-vs-remote without further muddling (and which might explain why we didn't really jump at the download-another-json idea)
<beuno> Chipaca, so I think the idea of downloadind a metadata blob from the store is a recurring thing
<beuno> the flat namespace is a good example
<beuno> another one will be the apparmor profile
<beuno> which we'd like to split out and have the store attach to apps at some point
<beuno> my guess is we'll end up downlading and storing a separate blob of metadata anyway
<ogra_> hello apt lists
<ogra_> :P
<beuno> ogra_, you mean, parsing out of a file on one path instead of another?  :)
<ogra_> well, i thought the scope of snappy was to get right of index files
<beuno> also, if we're re-implementing apt, lets bring back dependencies!  I think that's what makes it fun
<ogra_> *rid
<Chipaca> beuno: i am not opposed to downloading and storing separate metadata*; i'm opposed to having three different metadata sources :)
<beuno> ogra_, index files *with all apps in the archive*
<beuno> ogra_, not the ones you have  :)
<beuno> Chipaca, SO PICKY!  :)
<beuno> Chipaca, agreed
<Chipaca> * i'd quesiton whether it needs to be separate on disk, or could be on-the-fly glommed into an ar (to make debugging easier maybe)
<sergiusens> +1 on having one source of information
<beuno> Chipaca, so my naive mental model here is that you download the json blob from the store on download, refresh it every now and then, always query that for any metadata
<mvo_> fwiw, I dislike the idea of having metadata that is not reflected in the package. mostly on philosophical grounds right now (can not be version controlled for example and packages are no longer self-contained). but thats just me
<mvo_> plus its something we need to authenticated seperately, ideally having a gpg signature for the blob too
<sergiusens> mvo_: that's why I asked for the store not to allow edits
<Chipaca> beuno: "refresh it every now and then" is problematic
<mvo_> sergiusens: I like that better than the alternatives
<Chipaca> beuno: otherwise, with you
<sergiusens> beuno: mark said no caching
<beuno> Chipaca, I'm sure cron accepts "now and then" as a parameter
<mvo_> especially since when we have delta downloads it won't matter if someone uploads a new version
<Chipaca> mvo_: problem is delta uploads :)
<beuno> sergiusens, I don't think he meant that. We've discussed downloading a metadata blob separate from the package many times
<beuno> mvo_, it won't matter to the user
<mvo_> Chipaca: is it ;) we could make that work easily via snappy upload
<beuno> mvo_, it'll matter to the developer uploading 800mb
<sergiusens> beuno: right, but caching on the client he said no; ask lool ;-)
<beuno> mvo_, and spamming 100k users with a no-op download to s/downlod/download
<mvo_> beuno: if we sign hashes.yaml thats a solvable problem
<mvo_> beuno: we spam even more users if we cron a apt-get update like snappy run
<beuno> sergiusens, I'll bring it up, I think it will have been a different context
<mvo_> don't get me wrong I'm not totally opposed but I dislike it
<Chipaca> i think there is a workable way
<mvo_> and I think it will come back and hunt is in bad ways
<beuno> mvo_, I wouldn't cron, I'd update the list whenever you talk to the store, snappy update, etc
<lool> there will always be metadata outside of the package though
<lool> like reviews
<beuno> right
<beuno> and, again, we already have the flat namespace
<lool> all the metadata that the client might require while offline needs ot be in the package
<beuno> well
<beuno> that's the issue here
<beuno> we disagree on that
<Chipaca> ummm
<Chipaca> maybe :)
<Chipaca> lool: there is metadata you don't have when you're offline
<lool> Chipaca: yeah, like reviews, that's fine
<Chipaca> yep, and all those don't need to live with the package
<lool> but you need things like the icon, the translated name
<Chipaca> on disc
<Chipaca> however, the package when the user creates it is a series of metadata chunks, and the binary itself
<Chipaca> that's then sliced and diced into a .snap file
<Chipaca> and signed
<sergiusens> webdm ad click scope see a lot of problems with the current model fwiw
<Chipaca> so you have a file that is, conceptually at least, a series of blobs and their signatures
<beuno> s/see a lot of problems/haven't implemented separate metadata storage
<Chipaca> when you download the package, the blobs get put in certain places, and you get the original package back again
<lool> maybe it's just confusing to have a general discussion on metadata and we only need to list the actual data and use cases
<Chipaca> currently, the store treats the package itself as a single blob
<Chipaca> however that does not need to stay that way
<Chipaca> the store could treat it as a series of blob,sign pairs
<Chipaca> and stream those
<Chipaca> and then on unpack we'd put the metadata blob wherever, and would be none the wise
<beuno> right
<beuno> indeed we could
<Chipaca> while on the server the metadata blob was stored in a database, instead of in disc, and editing happens right there
<beuno> there is metadata that the store will provide that the package won't, like UUID
<beuno> so the file you give the store might not match exact what is served back
<Chipaca> and the overall signature also
<Chipaca> but that gives an on-disc and on-the-wire format that are the same, and an in-store format that lets us edit metadata
 * beuno nods
<Chipaca> and it's all *almost* there
<sergiusens> beuno: it's fine for the store to provide more data; it's bad for it to modify provided data
<Chipaca> we've just not been thinking about it in these terms
<Chipaca> sergiusens: why is it bad?
<beuno> sergiusens, it isn't, the user is!
<Chipaca> gosh this coffee is strong :)
<beuno> and I don't want to force the user to re-upload 800mb to fix a typo, or even generate a new file and upload that
<beuno> there's a nice web ui for them to do that
<sergiusens> Chipaca: the packaging layout is meant to be navigateable so the user can browse what's installed easily, if I look at package.yaml it will be all wrong
<Chipaca> sergiusens: you weren't following me maybe
<Chipaca> sergiusens: or maybe i wasn't clear
<sergiusens> Chipaca: if we delete package.yaml (or most of it) then fine
<sergiusens> and please lets get rid of readme.md
<Chipaca> sergiusens: the on-disc (and on-the-wire) format of the snap package has all the metadata in one place; call it the package.yaml
<sergiusens> Chipaca: that's _$version
<sergiusens> which we talked about
<Chipaca> sergiusens: the store streams out the package.yaml from the database, and the binary blob from wherever; the client just gets a stream with package.yaml in there
<sergiusens> Chipaca: ok, and does that need constant updating?
<Chipaca> sergiusens: that is a separate discussion i have no horse in
<beuno> Chipaca, sergiusens, another example of out-of-package metadata is release
<Chipaca> sergiusens: it could be, it could not be
<Chipaca> sergiusens: also, this might make _$version not necessary
<Chipaca> but we are talking something that is not jfdi-level of change
<beuno> and one that is convenient, because we can re-target the same binary to newer releases without changing it
 * JamesTait heads off for lunch
<sergiusens> beuno: I know of all these extras, I just don't like the sources being mangled with
<Chipaca> beuno: while we're at it, if in the store a binary is a stream of (data,signature) pairs, you could store and stream deltas instead of whole packages
<sergiusens> beuno: if the source is the store and the only reason we have a package.yaml is to seed, then it shouldn't be there at all
<beuno> Chipaca, not sure I follow, deltas is still being pondered by mvo, on where to slice
<beuno> per file, binary deltas, etc
<Chipaca> beuno: i'm not sure we're talking of the same level of deltas; what i mean is you could xdelta v1 and v2 and only store/stream the xdelta between them (looking at the binary blob alone)
<Chipaca> but that's probably exactly what mvo is looking at :)
<Chipaca> and it's even more pie-in-the-sky than the rest of the above
<Chipaca> sergiusens: i'm not sure i understand your "seeding" argument
<sergiusens> Chipaca: that was martin's initial argument, package.yaml is in the package just to seed the initial store configuration.
<sergiusens> Chipaca: and that it shouldn't be relied upon
<Chipaca> sergiusens: but that's not where we finished, is it?
<sergiusens> Chipaca: if we stream the files as you say, this may be not relevant but is considered "tampering" with the packaging
<sergiusens> Chipaca: changing uploaded files is weird, but then again it's not as the same user is changing them from a webform
<sergiusens> unless they do package signing themselves...
<Chipaca> sergiusens: we could build and sign the binary blob (and by binary blob here i mean everything-user-provided-but-meta/) with the user's key, and sign the meta blob with our key
<Chipaca> sergiusens: because meta is âoursâ
<Chipaca> that's the whole point
<Chipaca> well, it's one of the whole points :-p
<nessita> beuno, Chipaca , JamesTait: correct that the store treats snaps and clicks 95% equally. And yes, for now we only support .json files for the package metadata on upload
<sergiusens> Chipaca: your idea makes me happy; well anything that gets us out of N sources of information makes me happy
<Chipaca> sergiusens: note my idea is 95%* reinterpreting what we already have
<Chipaca> * some statistics copied from nessita
<sergiusens> lol
<Chipaca> and then following up those reinterpretations, but nothing "new" really there
<Chipaca> anyway, somebody should write this down before we forgot we agreed on something
<sergiusens> Chipaca: that's why we have architects; let's leave that to th people about to sprint :-P
 * beuno hits control + p > A4 > Print
<Chipaca> i'll send an email
<Chipaca> beuno: +1 :)
<sergiusens> Chipaca: I sent a short one to rsalveti to start discussing during the architecture meetings
<sergiusens> Chipaca: before I thought the conversation would stop short (as it did most of the time)
 * sergiusens now feels hungry after what just happened
<seb128> sergiusens, hey, I saw that you have goget changes up for review for personnal, any idea when that should land?
<sergiusens> seb128: in a bit
<sergiusens> seb128: but the images I create go into a boot loop (kvm)
<sergiusens> seb128: did you have a succesful build yet?
<seb128> sergiusens, yeah, I don't understand
<seb128> grub has 4 entries
<seb128> the first one which is snappy boot and goes back to grub
<seb128> the "ubuntu" one fails to boot/hang in the middle of init jobs
<seb128> I tried to boot on upstart, it stops on what seems like cloud-init's job having issues with the fs being ro
<seb128> exceptions about creating a dir
<seb128> sergiusens, yeah, I got it to work on amd64, doesn't work on i386 though (it's still giving me the partitions error, even with the 10G)
<sergiusens> seb128: there shouldn't be differences there
<sergiusens> seb128: also try sudo losetup -d /dev/loop[0-9] before starting
<seb128> sergiusens, thanks
<seb128> sergiusens, anyway the amd64 issue is having those boot issues, I'm trying to have a look but didn't find anything useful so far
<seb128> did you?
<sergiusens> seb128: no, this was late last night
<dholbach> hey JamesTait - I have a question :)
<dholbach> JamesTait, if I use the app store APIs, can I filter for certain snap types?
<JamesTait> dholbach, "certain snap types"?
<dholbach> JamesTait, like a gadget snap, a framework snap, etc
<dholbach> https://developer.ubuntu.com/en/snappy/guides/package-metadata/ â 'type'
<JamesTait> dholbach, I don't know if we have that metadata available. The analogue in click packages would be content: app|scope I think.
<sergiusens> JamesTait: we do
<dholbach> JamesTait, can I filter for snaps right now, as opposed to clicks?
<sergiusens> JamesTait: dholbach https://search.apps.ubuntu.com/api/v1/package/docker "content" in there
<sergiusens> as an example
<nessita> JamesTait, we do have it, in the same field
<nessita> allowed types for far are application, framework
<nessita> (for snaps)
<sergiusens> nessita: and oem
<JamesTait> nessita, right, I was just trying to find one. âº
<sergiusens> here's an oem one https://search.apps.ubuntu.com/api/v1/package/beagleblack
<sergiusens> dholbach: to filter pass X-Ubuntu-Framework: ubuntu-core-15.04-dev1 (when can we rid ourselves from this? :-P)
<JamesTait> dholbach, https://search.apps.ubuntu.com/api/v1/search?q=content:"framework"
<sergiusens> dholbach: and also X-Ubuntu-Release: [15.04-core|rolling-core|rolling-personal]
<nessita> sergiusens, what do you mean with getting rid of the framework header?
<sergiusens> JamesTait: can we do that with release and framework as well?
<sergiusens> nessita: as in ubuntu-core-15.04-dev1
<sergiusens> nessita: it's a meta question, I know it was set back in due to some apparmor issues as well ;-)
<JamesTait> sergiusens, yes, you can.
<sergiusens> kyrofa: do you have time to meet today?
<sergiusens> JamesTait: neat, which is more efficient? as query param or http header?
<sergiusens> rsalveti: https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu1 (why it is in no pocket I don't know)
<JamesTait> sergiusens, they're slightly different. As an HTTP header makes it a filter, so the index will only return results that depend *only* on frameworks that are in your list.
<rsalveti> sergiusens: in a vortex :-)
<rsalveti> sergiusens: thanks
<JamesTait> sergiusens, if you send "X-Ubuntu-Frameworks: ubuntu-core-15.04", then packages that declare 'framework: ["ubuntu-core-15.04", "docker-1.0"]' won't be returned.
<JamesTait> sergiusens, whereas just putting it in the query string will return them regardless.
<sergiusens> JamesTait: so http header is all or nothing? You make me ask questiong about our code base now :-P
<JamesTait> sergiusens, HTTP header filters out stuff you can't install (due to missing frameworks).  So phones don't see packages targered at core, for example.
<JamesTait> Yet, anyway.
<sergiusens> JamesTait: but it's an || and not and && right?
<sergiusens> JamesTait: as in you have to satisfy at least one of the declared frameworks
<JamesTait> sergiusens, you have to satisfy all of the frameworks that the package declares. It's neither || nor && because you might have a bunch of other frameworks installed that make no difference to the package. As long as what's in the package metadata is a subset of what you send in the header, you'll see the package.
<JamesTait> sergiusens, there's an example in https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex#Frameworks
<elopio> fgimenez: meeting
<fgimenez> elopio, omw
<sergiusens> JamesTait: shouldn't this http://paste.ubuntu.com/11730647/ only return docker?
<JamesTait> sergiusens, it should return packages where framework is one of: ["docker"] ["docker", "ubuntu-core-15.04-dev1"] ["ubuntu-core-15.04-dev1"]
<sergiusens> JamesTait: ah, so that was an || in my mind :-P
<fgimenez> sergiusens, adding a 'img' flag would help? something like 'go run _integration-tests/main.go -img /path/to/img'
<sergiusens> fgimenez: well, I need to test the u-d-f output too
<sergiusens> fgimenez: stdout should warn about --device
<sergiusens> rsalveti: we need an ubuntu-snappy release and to rebuild u-d-f after that to allow --install docker :-/
<rsalveti> sergiusens: sure
<rsalveti> sergiusens: anything waiting to be merged in ubuntu-snappy or can we just release current trunk?
<sergiusens> @activereviews
<nothal> sergiusens: No such command!
<sergiusens> @activereview
<nothal> sergiusens: No such command!
<sergiusens> @help
<nothal> "list" To see the available commands ; "help cmd" for specific command help
<sergiusens> @list
<nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
<sergiusens> @reviewlist
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-gettext/+merge/262202 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-console/+merge/262061 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~fgimenez/snappy/go-functional-tests/+merge/261748 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-verify/+merge/261718 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~mvo/snappy/snappy-improve-developer-mode-detection/+merge/261646 | No reviews (6 days old)
<ogra_> @tellsergiuenstostopplaying
<nothal> ogra_: No such command!
<sergiusens> ogra_: I was tied to lp speak
<ogra_> heh
<sergiusens> rsalveti: no, nothing in queue
<rsalveti> let me release that then
<JamesTait> sergiusens, sorry to disappear; other people needing attention, school run, I need a clone. âº
<JamesTait> sergiusens, so a query string like ?q=framework:ubuntu-sdk-15.04-dev1,framework:docker would give you an ||
<sergiusens> fgimenez: maybe update _integration-tests/README with the go run comment
<rsalveti> sergiusens: https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.2-0ubuntu1
<sergiusens> rsalveti: thanks
<JamesTait> Also, sergiusens, by default query-string search terms are analysed and do prefix matching, so ?q=framework:docker will also match packages with framework: ["docker-1.3"]. Wrapping the term in quotes should prevent that and make it a literal phrase search, but that doesn't seem to be the case any more. I'll need to dig a bit to work out why.
<sergiusens> JamesTait: it does literals for package names at least as nessita showed me
<sergiusens> JamesTait: so I want headers and not query strings for this and that last comment settles it
<nessita> sergiusens, yes you do
<sergiusens> nessita: err, what
 * JamesTait grabs a drink
<sergiusens> nessita: in any case I know what I mean :-)
<seb128> sergiusens, I found issues on the iso build which explain the hang, fixing them in livecd-rootfs now
<sergiusens> seb128: oh nice, any reason why the image is so big?
<seb128> sergiusens, define "so big"?
<seb128> it's 2.5G
<ogra_> compressed ?!?
<seb128> ogra_, well, the ubuntu desktop iso is likge 1G
<sergiusens> ogra_: 2.5 uncompressed
<seb128> and the snappy image is x2 because of the a-b partitions
<seb128> so seems about right to me?
<ogra_> ah, uncompressed
<ogra_> that sounds rather sane
<fgimenez> sergiusens, sure thx! elopio suggested changing the way we build images depending on the type of test being executed
<kgunn> jdstrand: tyhicks thanks for help y'day, i made good progress....last thing i'm struggling with is a script that is part of the snap that launches the server
<kgunn> i'm getting ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted
<fgimenez> sergiusens, elopio we still need to define how to group tests tough
<kgunn> but i've already add /bin/pidof to may aa file, which took care of the denial
<kgunn> any ideas?
<kgunn> http://bazaar.launchpad.net/~kgunn72/mir/snappy-packaging-with-secprofile/view/head:/server
<kgunn> that's the script ^
<kgunn> is it b/c it's outside of the mir binary itself ?
<sergiusens> kgunn: add u or U (I forget which one is the more correct one)
<sergiusens> kgunn: /bin/pidof Umrix,
<kgunn> sergiusens: thanks! i'll try that
<kgunn> sergiusens: i had added everything but that i think :)
<sergiusens> kgunn: I have that a plenty; uU is for run unconfined
<sergiusens> one cleans up the env while the other doesn't
<tyhicks> Ux scrubs the environment
<kgunn> tyhicks: what means "scrubs"
 * kgunn grunts like caveman
<tyhicks> kgunn: it attempts to remove any risky environment variables
<ogra_> kgunn, audio or it didnt happen !
<kgunn> :)
<ogra_> :)
<tyhicks> I don't like the idea of snaps being able to do unconfined transitions while calling out to external binaries
<tyhicks> I'm not sure if that's what jdstrand has been recommending for situations like this or not
<tyhicks> using Ux will get you unblocked for now but we may end up wanting to do something more secure
<kgunn> tyhicks: no problem....i'm game to be a guinea pig
<kgunn> i am getting a little heat to get mir in the store tho :)
<mvo_> mterry: my work on the debian stuff https://github.com/mvo5/gettext/tree/debian
<kgunn> tyhicks: do you consider using u on pidof ok for store use ?
<longsleep> Hey folks, can someone explain the strategy how snappy can use the full disk / resizing automatically on first boot or something?
<tyhicks> kgunn: well, jdstrand is the one that has been defining those boundaries so I'll defer to him
<mterry> mvo_, I don't have a branch for mine  -- sorry we collided, I tried to ping you but I think I got a stale copy of your irc client (mvo__ with two underscores if I recall)
<mterry> mvo_, we used the same source and binary names, so at least we won't get two copies
<mterry> mvo_, I fixed the test issue though by copying example files into the obj-* dir
<barry> mvo_: yep, i'm confused :)  can you elaborate on what you want for LP: #1466124 ?
<ubottu> Launchpad bug 1466124 in system-image (Ubuntu) "Please provide a way to get the progress in used from a plugin" [Undecided,New] https://launchpad.net/bugs/1466124
<mvo_> mterry: oh, nice! I thanks for fixing the tests. lets just merge it together
<mvo_> barry: meh, I figured I did not express myself very well
<mterry> mvo_, just add
<mterry> override_dh_auto_test:
<mterry> 	# copy data files in
<mterry> 	cp -r examples/*/ obj-*/src/github.com/gosexy/gettext/examples/
<mterry> 	dh_auto_test
<mterry> mvo_, to yours
<barry> mvo_: s'okay :)
<mvo_> barry: once sec, I'm in a meeting right now, won't help with being consistent
<mvo_> eh or understandable or anything really
<mvo_> mterry: \o/
<mterry> mvo_, and then maybe switch your deletion of those files to dh_auto_install rather than dh_auto_build
<jdstrand> sergiusens: your 'U's and 'u's are not necessarily recommended
<jdstrand> kgunn: can you paste the full denial?
<jdstrand> kgunn: can you use 'rmix' (ie, don't use 'U') and try again, showing me the denial?
<jdstrand> kgunn: is this something that can run in a kvm ubuntu-core image?
<tyhicks> note that pidoff isn't as innocent as it may seem, from the pidof(8) man page:
<tyhicks> "pidof is actually the same program as killall5"
<jdstrand> yes
<jdstrand> so I'd prefer ix so we can then use signal mediation
<tyhicks> agreed
<mvo_> tedg: hi, so what exactly is it you need? the uri of the source package?
 * jdstrand notes this is a framework, but frameworks are privileged and we should stop using demo policy and do real policy for these things
<tedg> mvo_, This is what I did. Get from binary packages to the list of dev packages associated with them: http://paste.ubuntu.com/11731018/
<tedg> mvo_, The list is hardcoded in that example.
<mvo_> tedg: thanks, let me have a look
<mvo_> tedg: http://paste.ubuntu.com/11731045/ is slightly shorter but yeah, srcpkg stuff is not the strength of python-apt
<mvo_> tedg: this examle needs updating in the api docs :/ it does not reflect the latest features of python-apt. thanks for finding that
<tedg> mvo_, The other example that is really bad is this one, as it is camel case and the functions aren't: https://apt.alioth.debian.org/python-apt-doc/library/apt_pkg.html#apt_pkg.PackageRecords.lookup
<tedg> mvo_, That's where I came up with the stuff that you deleted :-)
<mvo_> mterry: hm, if your package has this already fixed, we could simply use your version?
<mvo_> tedg: uh, indeed, that needs fixing
<mvo_> barry: ok, so â¦ let me try again. we "hook" into the upgrade (the apply hook) with our custom upgrader. when that is run we currently check the options if the user requested to use machine-readable output
<mterry> mvo_, other differences I see: I add misc:Built-Using, and I do actually ship the examples folder (since go seems to like to ship the _test.go files, and they are needed to make it work
<mvo_> barry: our branch set this in the global config object
<mterry> mvo_, but I'm not convinced the examples folder should be shipped, so yours might be doing the right thing there
<mvo_> mterry: right, lets keep yours if its actually more complete, or is there a downside?
<mterry> mvo_, just the examples folder
<mterry> mvo_, and no source tree
<mterry> mvo_, in vcs that is
<mvo_> barry: but it seems like with the current 3.0 I can not get the information if the user has requested a machine-readable output
<kgunn> jdstrand: hey, sorry, was on a HO...
<kgunn> yeah so i ran last night with
<mterry> mvo_, how would we stop one of our uploads?
<kgunn> /bin/pidof mrix,
<mterry> I'm  not used to cancelling an upload
<kgunn> and the error was ubuntu-core-launcher:/apps/mir/snap1/bin/server.real pidof: Operation not permitted
<mvo_> mterry: ok, no vcs is ok, mine is just a single commit so far. and if yours does not need further changes I'm in favour of keep it :)
<mterry> mvo_, alright
<jdstrand> kgunn: what is the apparmor denial? grep DEN /var/log/syslog
<barry> mvo_: oh, do you just mean that the hook doesn't know whether --progress=json was provided on the cli?
<kgunn> jdstrand: that's just it....there's not one
<mvo_> mterry: we can just reject my upload, I can ask the archive admins to do that
<mvo_> barry: yeah, exactly that
<mvo_> barry: so it might be as simple as setting it as a transient config in the global config object
<mvo_> barry: thats what I did in the fork we are currently using
<barry> mvo_: ah, okay, that should be easy to expose in the global config
<barry> yeah
<jdstrand> kgunn: is there a seccomp denial?
<kgunn> jdstrand: nope
<barry> mvo_: thanks, i'll update the bug description.  is it worth holding up 3.0.1 into wily to actually do a quick 3.0.2, or can i target that at 3.1?
<jdstrand> kgunn: did you disable kernel rate limiting?
<kgunn> jdstrand: nope, but i can try that now
<mvo_> barry: its not blocking us, I just always spit out json to stdout now
<barry> mvo_: cool, thanks
<mvo_> barry: which is bad but its only snappy thats driving it right now, so its not too terrible
<barry> mvo_: ack
<mvo_> thanks! and sorry that it was so confused
<barry> no worries!
<barry> mvo_: thanks.  description updated.  please sanity check
<mvo_> barry: yes, thats it
<barry> mvo_: \o/
<kgunn> jdstrand: so diabled kernel rate limiting (with sudo sysctl -w kernel.printk_ratelimit=0)
<kgunn> run via systemctl start mir-blah.service
<kgunn> the syslog just shows
<kgunn> "systemd started system compositor"
<kgunn> no seccomp or aa denial error
<kgunn> but...system compositor doesn't appear in process list
<ogra_> hack it to spit out more info ?
<ogra_> (the systemd unit i mean)
<jdstrand> kgunn: does the service try to drop privs and then regain them?
<kgunn> jdstrand: i don't think so, the system compositors run as root....
<kgunn> mterry: ^ any privlegde changes ?
<jdstrand> kgunn: try using @unrestricted as the seccomp policy
<mterry> kgunn, I don't think so
<mterry> kgunn, is it waiting for agetty?
<mterry> kgunn, or did the server shell script bail for some reason?
<kgunn> mterry: sorry to bother you this is all about getting sec policy for mir correct (as  fmwk) to get in store....
<mterry> kgunn, right (pidof stuff still?)
<kgunn> worked through all the aa & seccomp errors, now stuck on pidof in the launching script
<kgunn> brb
<elopio> ogra_: do you want to top-approve? https://code.launchpad.net/~zyga/snappy-hub/fix-1464275/+merge/261833
<kgunn> jdstrand: ok, so running with bin/pidof & bin/sleep :q
<ogra_> elopio, done
<kgunn> oops ignore the :q
<kgunn> pidof and sleep with mrux, and syslog shows both "Opertation not permitted" just like before
<kgunn> note, that was without the kernel rate liimiting denial disabled
<rsalveti> ogra_: sergiusens_: mvo_: one interesting problem: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/
<rsalveti> the azure device tarball is not getting updated from the build, since 9-jun
<rsalveti> but from the build log, it seems it was created
<rsalveti> how to find out what is going on at the cdimage side of things?
<ogra_> there should be cdimage logs
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/
<ogra_> hmm, no mention of azure in there at all
<ogra_> could it be that they need to have manual intervention ?
<rsalveti> maybe we're not building it
<rsalveti> # now build the azure device tarball by adding walinuxagent
<rsalveti> if [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ];
<rsalveti> the check
<rsalveti> this is for vivid
<rsalveti> yeah, we're not building it
<ogra_> right
<rsalveti> # now build the azure device tarball by adding walinuxagent
<rsalveti> if [ -e binary/boot/filesystem.dir/var/lib/dpkg/info/walinuxagent.list ];
<rsalveti> argh
<ogra_> if it exists cdimage downloads it as seen in http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/daily-preinstalled-20150609.log
<rsalveti> daily-preinstalled-20150609.log
<rsalveti> the last one that had it
<rsalveti> yeah
<rsalveti> daily-preinstalled-20150612.log already failed to generate it
 * rsalveti looks for walinuxagent related changes
<ogra_> hmm http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/daily-preinstalled-20150610.log ... that downloaded it as well
<rsalveti> ogra_: right, that's wily
<rsalveti> for vivid we don't have 0610
<ogra_> oh
<rsalveti> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/vivid/?C=M;O=D
<ogra_> right
<ogra_> i missed the "vivid" in the url above
<rsalveti> https://launchpadlibrarian.net/209278613/buildlog_ubuntu_vivid_amd64_ubuntu-core-system-image_BUILDING.txt.gz
<rsalveti> but it seems it was actually created ^
<rsalveti> + tar -c -z -f /build/device.tar.gz system assets hardware.yaml
<rsalveti> this from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<rsalveti> checking the latest amd64 image
<jdstrand> kgunn: can you try with seccomp policy as @unrestricted?
<jdstrand> kgunn: (sorry, been in a meeting)
 * jdstrand is still in the meeting
<sergiusens_> rsalveti: ogra_ we are probably not building it for wily and porbably don't want it either (to be replaced with gadget snaps)
<rsalveti> sergiusens_: right, wily is fine to not build it
<rsalveti> my concerned is that we're not building it for vivid
<rsalveti> *concern
<rsalveti> launchpad says we're building it, but the cdimage log is not showing that it copied it over
<sergiusens_> rsalveti: but, but, but we released a few weeks ago
<rsalveti> sergiusens_: yeah, failed the next day
<rsalveti> after the release
<rsalveti> since the release day, we didn't get any other update
<rsalveti> and nothing really changed on our side
<sergiusens_> rsalveti: system image's index says something different http://system-image.ubuntu.com/ubuntu-core/15.04/edge/azure_amd64/index.json
<sergiusens_> last entry, version_detail
<rsalveti> sergiusens_: right, that is fine, since cdimage is publishing the tarball, but the older one
<sergiusens_> ah, the device tarball is stuck
<rsalveti> that's the usual issue with the cdimage side
<rsalveti> if something fails, it will just copy the older ones
<rsalveti> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/
<rsalveti> sergiusens_: check the date ^
<sergiusens_> rsalveti: let's blame ogra!
<sergiusens_> rsalveti: yeah, that's why I said device tarball is stuck :-P
<sergiusens_> I'll brb
<ogra_> yeah, just blame me
<rsalveti> ogra_: where can I find the previous live-build logs?
<rsalveti> since we moved that to launchpad
<rsalveti> slangasek: maybe you can help with this ^?
<rsalveti> basically I'm trying to figure out why device-azure.tar.gz wasn't published as part of cdimage for the last few images
<slangasek> rsalveti: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core for instance?
<rsalveti> slangasek: I'm looking at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/
<rsalveti> but I can only see a few
<rsalveti> and not easily go back in time
<slangasek> ah
<slangasek> rsalveti: if you know which build you're looking for (from cdimage's POV), you can find the url to the exact build log in the log on nusakan
<rsalveti> would be 20150609
<rsalveti> slangasek: do you know where to look?
<slangasek> rsalveti: /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150609.log
<slangasek> ubuntu-core-system-image-amd64 on Launchpad starting at 2015-06-09 04:56:02
<slangasek> ubuntu-core-system-image-amd64: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/29185
<rsalveti> slangasek: awesome, thanks!
<rsalveti> yeah, build seems fine
 * rsalveti looks for the cdimage cdo
<rsalveti> code
<ogra_> slangasek, any idea why we stopped mirroring them to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ ?
<ogra_> it is quite handy to have all of them in one place
<slangasek> no idea, no
<rsalveti> ogra_: slangasek: so there is no 'azure' at all in the cdimage code
<rsalveti> and the only update, that happened at last 11, was to add the personal
<rsalveti> and that probably caused a sync
<rsalveti> who added the azure logic in there?
<ogra_> well, i had the impression the cloud stuff was some manual process
<seb128> hum, so I got an image to boot in kvm
<ogra_> seb128, yay
<seb128> lightdm fails to start though
<ogra_> oooh :(
<rsalveti> ogra_: the manual part is after it gets in system-image
<ogra_> rsalveti, ah, k
<seb128> "Error using VT_ACTIVATE 7 on /dev/console: Inappropriate ioctl for device"
<seb128> does that ring a bell to anyone?
<slangasek> rsalveti: I don't think there were any changes required to the cdimage code for the azure device tarball.  I thought the changes were only in livecd-rootfs
<seb128> I can starts gallery-app with xinit though :p
<seb128> so xorg is working
<ogra_> seb128, kgunn had fun with agetty and mir wrangling around a tty all day i think
<rsalveti> slangasek: was thinking about cdimage because we need to copy the tarball over
<rsalveti> after it gets published
<rsalveti>                 if config.project in ("ubuntu-core", "ubuntu-desktop-next"):
<rsalveti>                     device = "%s.device.tar.gz" % live_prefix
<slangasek> rsalveti: right; so I never made any changes to the cdimage code to accomodate this, and if I had it would have been in the bzr branch
<rsalveti>                     if os.path.exists(device):
<rsalveti>                         shutil.copy2(
<rsalveti>                             device, "%s.device.tar.gz" % output_prefix)
<rsalveti> this is the piece that copy it over
<rsalveti>             live_prefix = os.path.join(live_dir, arch)
<rsalveti>             rootfs = "%s.rootfs.tar.gz" % live_prefix
<rsalveti> so unless I'm not reading it right, there is indeed nothing copying it around
<ogra_> well, that code is pretty generic
<ogra_> do we perhaps have an architecture called "amd64.azure" ?
<ogra_> (would be odd to have a dot in there, but who knows)
<rsalveti> right
<rsalveti> ogra_: slangasek: I fail to see how this ever worked =\
<slangasek> rsalveti: indeed, I don't know either.  I think mvo_ may have been the one doing the work on the azure device tarball at the time, maybe he remembers something?
<rsalveti> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944
<rsalveti> the tarball is there
<rsalveti> mvo_: if still around ^?
<rsalveti> at least the problem is consistent with both vivid and wily, and also started at last 11
<ogra_> rsalveti, asac, some clarification about the support status in the RPi thread "Snappy RPi2 stable image #3 now available" would be appreciated ...
<ogra_> (seems he is rather grumpy about our communication and marketing)
<sergiusens_> rsalveti: azure is built from livecd-rootfs
<rsalveti> sergiusens_: right, and it's there
<rsalveti> just not imported/copied in cdimage
<rsalveti> ogra_: sure
<ogra_> sergiusens_, and how is it getting onto cdimage.u.c ?
<sergiusens_> ogra_: that's all black magic and I only wish someone explained it so we could simplify it ;-)
<rsalveti> for some reason I only had your reply and not the original email, which is now there (and was unread)
 * sergiusens_ winks
<rsalveti> my gmail is kind of going crazy lately
<sergiusens_> ogra_: http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-move-kernel-to-device-tar.binary
<ogra_> sergiusens_, ha, wishful thinking
<sergiusens_> rsalveti: I started using mutt again
<rsalveti> sergiusens_: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944
<rsalveti> right, see the azure is there
<rsalveti> sergiusens_: mutt + google imap?
<sergiusens_> I only go to gmail to search
<sergiusens_> rsalveti: yup, offlineimap
<rsalveti> right, might be better indeed
<ogra_> evolution FTW :)
<ogra_> has still the fastest search tools
<sergiusens_> rsalveti: searching is good in gmail; organizing and cleaning up the queue and not missing content is better in a proper MUA
<sergiusens_> ogra_: makes you need a revolution in RAM though
<ogra_> my XPS copes fine with its 8G
<ogra_> and i dont have any device in use with less anymore
<ogra_> (for desktop that is)
<sergiusens_> rsalveti: so the build is there; what is missing?
<ogra_> sergiusens_, the code in cdimage that copies it
<ogra_> we dont know how it got from here to there
<ogra_> (the logs show it gets copied)
<ogra_> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/vivid/daily-preinstalled-20150609.log
<ogra_> 2015-06-09 14:18:50 URL:https://launchpadlibrarian.net/208661665/livecd.ubuntu-core.azure.device.tar.gz [142562062/142562062] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-core/vivid/daily-preinstalled/live/amd64.azure.device.tar.gz" [1]
<rsalveti> yeah, was looking at the code, but can't see to find how it was copying ti before
<rsalveti> sergiusens_: check lp:ubuntu-cdimage
<rsalveti> grep for "Downloading live filesystem images"
<rsalveti> that is where the magic happens
<ogra_> ogra@styx:~/Devel/branches/cdimage$ grep -r azure *
<ogra_> ogra@styx:~/Devel/branches/cdimage$
<ogra_> thats the weird part
<rsalveti> that copy the files from launchpad into /srv/cdimage.ubuntu.com/scratch/ubuntu-core/vivid/daily-preinstalled/live
<rsalveti> which is the missing link, because it's not copying over the azure tarball
<ogra_> well, i dont get how it would even know about azure at all
<mvo_> rsalveti: let me read scrollback and look at the code. so the problem started on the 11th this month?
<ogra_> given it is neither mentioned in the code nor in the config
<rsalveti> mvo_: yes
<ogra_> (or in any bzr changelog)
<mvo_> how confusing, my first guess is a livecd-rootfs upload
<rsalveti> mvo_: it's not livecd-rootfs, since it's there: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-core-system-image/+build/29944
<mvo_> I'm sure the ubuntu-personal guys broke it
<ogra_> mvo_, not really, livecd-rootfs does what it should
<rsalveti> the device tarball was built
<mvo_> meh
<ogra_> cdimage doesnt import it
<mvo_> there goes my theory and the blame I wanted to assign :/
<ogra_> i got blamed already, find someone else :P
 * ogra_ only takes the blame once a day
<rsalveti> mvo_: so it might be connected with personal
<rsalveti> mvo_: there was a personal change in cdimage at 11
<rsalveti> which would probably cause a sync in the bzr repo
<rsalveti> so if the azure change was done outside trunk, then it would be lost
<ogra_> uh
<ogra_> but who would do that
<ogra_> https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ...
<rsalveti> that's just a theory
<ogra_> (in case people dont use that way ... )
<rsalveti> unless I'm missing some magic in lp:ubuntu-cdimage
<seb128> mvo_, nice blame try!
 * mvo_ hugs seb128
 * seb128 hugs mvo_ back ;-)
<ogra_> and so subtle :)
<rsalveti> yeah, the branch was pushed at 11 by Laney
<rsalveti> reflecting the personal changes, but that has nothing to do with azure
<slangasek> rsalveti: we wouldn't normally do a 'bzr pull --overwrite'; if someone did that, that's quite bad
<ogra_> right, makes your theory more plausible
<slangasek> the usual protocol is 'bzr pull'; notice conflicts; yell at cowboys
<rsalveti> right
<ogra_> and the branches are bound you wouldnt ever be able to commit
<ogra_> OH !
<ogra_> but perhaps the config is in debian-cd, not cdimage
 * ogra_ goes checking
<ogra_> hmm, no
<ogra_> ogra@styx:~/Devel/branches/debian-cd$ grep -r azure *
<ogra_> ogra@styx:~/Devel/branches/debian-cd$
<rsalveti> another funny thing I noticed because of this
<rsalveti> the kernel config seems to be available via the rootfs
<rsalveti> after creating the azure image I had vmlinuz-3.19.0-18-generic and config-3.19.0-21-generic
<rsalveti> at /boot
<ogra_> yeah
<mvo_> rsalveti: yeah, we keep it in /boot because our grub needs it this way, we want to consolidate this
<ogra_> well, we dont have /proc/config.gz enabled
<ogra_> they are on the arm images too
<ogra_> needs cleanup ...
<rsalveti> mvo_: right, but why is this part of the rootfs?
<rsalveti> yeah, will open a bug in a few
<mvo_> rsalveti: oh, right, we don't want it there
<sergiusens_> mvo_: ogra_ rsalveti so is this what is needed? http://paste.ubuntu.com/11731958/
<sergiusens_> I just blindly added that
<mvo_> sergiusens_: could well be, I'm trying to understand why it worked before :/
<ogra_> not sure you want azure hardcoded there
<rsalveti> sergiusens_: something similar to that is what I had in mind, but the question is indeed what mvo_ just said
<rsalveti> for now I just manually copied over the new tarball and triggered a new image
<rsalveti> see if it will show up at system-image, so I can unblock people (that were waiting for an updated initrd)
<mvo_> rsalveti, sergiusens_: it seems like your change is exactly what was there and is no longer, the logs even have "Publishing amd64 azure device tarball " (I guess you know that already). really strange
<rsalveti> yeah
<rsalveti> too bad this is not git
<rsalveti> git reflog would explain it all
<ogra_> rsalveti, even if someone forcefully overwrote it ?
<rsalveti> ogra_: yup
<ogra_> (including history)
<ogra_> interesting
<sergiusens_> rsalveti: mvo_ a bzr push --overwrite to lp or a bzr pull --overwrite on the client explains most of this to me
<rsalveti> it's my solution when I do git reset --hard HASH
 * ogra_ guesses some day he wont get around looking at git :P
<sergiusens_> ogra_: as soon as we move to it ;-)
<rsalveti> and then omg omg omg I forgot to save a patch
<ogra_> (i must admit i'm surprised that i still do :) )
<rsalveti> git reflog gives me the complete history
<rsalveti> sergiusens_: yeah
<mvo_> sergiusens_: yeah, I think thats it
<mvo_> and someone *cough* *cough* cowboyed it in
<mvo_> before without a proper branch
 * mvo_ hides in shame
<mvo_> but to be fair, that azure enablement was really on a super tight deadline
<ogra_> mvo_, https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ... for next time :)
<ogra_> though still, while you cowboyed it in, someone overwrote it ignoring the error
<ogra_> bzr definitely complained
<mvo_> sergiusens_: this may need a additional download_live_items() in lib/cdimage/livefs.py
<mvo_> ogra_: indeed
 * ogra_ blames Laney in absence :) 
<ogra_> finally we can pass on the blame :)
<rsalveti> yeah, the push --overwrite was even worse
<sergiusens_> mvo_: like http://paste.ubuntu.com/11732046/ ?
<sergiusens_> I don't really follow this code base :-P
<ogra_> i still think it should somehow be injected into source_prefix instead of hardcoding it
<mvo_> sergiusens_: yeah, I think something like this
<sergiusens_> ogra_: I would leave that to you :-P
<sergiusens_> well I pushed here: lp:~sergiusens/ubuntu-cdimage/azure
 * rsalveti hands the cowboy hat to mvo_ 
<mvo_> sergiusens_: \o/
<sergiusens_> in case you want to merge
 * sergiusens_ wants the cowboy hat
<ogra_> sergiusens_, noh, go ahead if we need it now ... i'm being "studio_'ed" and annoyed enough to not want to write on code ...
<sergiusens_> will use it Clint Eastwood style
<ogra_> (i can take annother look tomorrow to see if i find another way)
<sergiusens_> ogra_: heh, so I don't mind this azure device as it will go away as soon as we solve the update-grub issue
<mvo_> sergiusens_: heh, so you cowboy^Wmerge it for testing?
<ogra_> sergiusens_, ah, well, then leave it ...
<sergiusens_> mvo_: do I have permissions? I forget :-P
<ogra_> mvo_, sergiusens_, make sure to follow the wiki doc though (./run-tests etc)
<mvo_> sergiusens_: I think so, but I know that I have
<ogra_> sergiusens_, you do
<ogra_> you got them together with rsalveti back then
<sergiusens_> ogra_: heh, I was playing dumb :-P
<ogra_> yeah, cant cheat me :P
<sergiusens_> ogra_: the tests fail here even without my changes!
<mvo_> sergiusens_: lol
<ogra_> oh man
<ogra_> Laney, !!!
<mvo_> his change does not look like it would break tests
<mvo_> but who knows
 * mvo_ does not
<sergiusens_> mvo_: coincidentally I have
<sergiusens_> mvo_: http://paste.ubuntu.com/11732086/
<sergiusens_> but there are 4 failures regardless
<jdstrand> kgunn_: did it work with @unrestricted?
<mvo_> sergiusens_: http://paste.ubuntu.com/11732091/ <- this is what I had to do back in the day to add support for device.tar.gz
<mvo_> sergiusens_: oh, I mean the changes that Laney did do not look like they would break stuff, but again, who knows
<mvo_> sergiusens_: it seems like item in live_item_path() might also want .azure in there :/
<sergiusens_> mvo_: let me check; but I do have test parity now
<kgunn_> jdstrand: i definitely get some app armor denials..but the way the script is written is kinda spins outta control...so i'm gonna fix that real quick and run again
<sergiusens_> mvo_: I have a good feeling about this one http://paste.ubuntu.com/11732146/ thanks for your base branch for device
<mvo_> sergiusens_: yay, lets give it a try!
<sergiusens_> mvo_: ok, let me do an actual checkout
<Chipaca> sergiusens_: mvo_: when can we have a coven about changes to snaps for 16.04?
<sergiusens_> tomorrow?
<mvo_> yep
<ogra_> 16.04 ? thats so far out !
<Chipaca> ogra_: far out, man!
<Chipaca> sergiusens_: mvo_: +1
<sergiusens_> ogra_: I don't need to pull -d debian-cd nor production, right?
<ogra_> sergiusens_, if you didnt make any changes to it, no
<ogra_> only cdimage should be enough
<sergiusens_> ogra_: just in case; gets out of the server asap
 * mvo_ is very curious
<sergiusens_> ogra_: mvo_ that's all I did http://paste.ubuntu.com/11732185/
<fikse> is there an argument for snappy ubuntu + consule + ...
<fikse> vs coreos?
<Chipaca> mvo_: about changes to snaps?
<sergiusens_> so I guess we can trigger a build now
<fikse> consul, not consule
<Chipaca> fikse: what's consul?
<ogra_> sergiusens_, perfect
<sergiusens_> consult maybe?
<fikse> a tool for service discovery https://consul.io/
<mvo_> Chipaca: about changes to snaps?
<Chipaca> mvo_: * mvo_ is very curious
<mvo_> sergiusens_: now its time to run a build, no?
<sergiusens_> mvo_: yup
<mvo_> Chipaca: mostly about if sergiusens_ saved the day, I think he did!
<sergiusens_> is that nusakan?
<mvo_> Chipaca: but the snap stuff is interessting as well
<mvo_> sergiusens_: yes
 * sergiusens_ logs back in
 * sergiusens_ gets goosebumps
 * ogra_ grins
<sergiusens_> mvo_: last time I was in there we were fixing that crazy system image server indexing problem :-P
<Chipaca> fikse: depending on what you do, it might be perfect, or it might be too early for snappy :)
<sergiusens_> ogra_: mvo_ which one should we try wily or vivid?
 * sergiusens_ goes for wily
<ogra_> yeah
<mvo_> +1
<fikse> Chipaca: i'm afraid it might be too early
<elopio> sergiusens_: can you get your server running the snapcraft tests?
<sergiusens_> too early it is then
<sergiusens_> elopio: if it's in the .tarmac.sh, yes
<ogra_> geez, we have tests already ?
<ogra_> snapcraft doesnt even exist !
<ogra_> you guys are so ahead
 * ogra_ makes a note to check the test code to know what he will develop in a few months 
<elopio> tdd baby!
<elopio> sergiusens_: yes, there's a .tarmac.sh.
<sergiusens_> elopio: just add it there
<sergiusens_> ogra_: I don't see the build here https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image
<ogra_> whats the line you ran ?
<sergiusens_> ogra_: SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image for-project ubuntu-core cron.daily-preinstalled
<ogra_> hmm, looks fine
<sergiusens_> ogra_: generally do crontab -l |grep something
<ogra_> oh
<ogra_> --live
<Chipaca> fikse: give it a try if you want; there's a couple of non-framework services (e.g. the xkcd-webserver) in lp:~snappy-dev/snappy-hub/snappy-examples
<sergiusens_> ogra_: I thought you told me way back not to use that :-P
<ogra_> you should always use whats in the crontab
<sergiusens_> ogra_: ok; but I'll search for that conversation :-P
<kgunn_> ubuntu
<kgunn_> oops
<kgunn_> ww
<ogra_> now change your password
<sergiusens_> kgunn_: we now know your password!
<ogra_> quick !
<ogra_> (make it ubuntu1 ... nobody will guess that)
<sergiusens_> ogra_: mvo_ rsalveti ok, building here now https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image
<sergiusens_> ubuntu123
<ogra_> yay
<sergiusens_> ubuntu123!
<sergiusens_> or maybe password :-)
<ogra_> nah, i use that already ... he cant take that
<mvo_> sergiusens_: ooooohhhh
<sergiusens_> ogra_: where is our powerpc build? :-)
<ogra_> sergiusens_, you just changed the cdimage code ... why didnt you add it !
<fisch246> will snappy personal eventually merge back to the current branch of Ubuntu Desktop when it's deemed ready?
<ogra_> merge back ?
<fisch246> so for example when 16.10 comes out for example, and everyone decides snappy and unity8 is ready, everyone running Ubuntu desktop will upgrade to snappy and unity8 in 16.10
<ogra_> you mean if there will be a deb based desktop install with unity8 ?
 * ogra_ guesses thats a question for #ubuntu-desktop actually
<fisch246> nah it would be snappy
<ogra_> i suspect though that we wont auto-migrate users from deb based systems to snappy
<fisch246> so  basically would the deb based version be dropped
<fisch246> ah okay
<fisch246> so if people want to stick with deb they will stay deb for good if they wish
<ogra_> no, there are too many people using the deb archive ... (flavours and such) ...
<fisch246> well for now at least
<ogra_> for a snappy install you will most likely do an install from scratch
<fisch246> cool thanks that answers my question :)
<sergiusens_> ogra_: I wasn't thinking straight, we need powerpc urgently for the device I don't have!
<sergiusens_> :-D
<ogra_> and also snappy is built from debs from the archive
<ogra_> sergiusens_, well, its a one line change in the config :)
<ogra_> (modulo image build failures etc indeed)
 * rsalveti reads backlog (back from a meeting)
<DarwinF> what's the process for adding/removing/modifying users?
<ogra_> DarwinF, there is no proper process yet ... /var/lib/extrausers/ has the user data though
<sergiusens_> rsalveti: btw https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu2
<ogra_> sergiusens_, your images are done btw
<ogra_> well, the livefs build
<DarwinF> ogra_: thanks
<rsalveti> sergiusens_: nice, so you fixed cdimage?
<rsalveti> fixededed
<sergiusens_> rsalveti: I'm not sure yet :-P
<ogra_> rsalveti, but he forgot to add powerpc while doing that
<rsalveti> lol, alright
<rsalveti> that's super important
 * rsalveti hands a few beers to sergiusens_ 
<ogra_> hmm
<sergiusens_> rsalveti: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending still shows June 11 for azure
<ogra_> daily
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.3/
<sergiusens_> not sure if I need to wait for all builds to finish here
<sergiusens_> ogra_: wily-preinstalled-core-amd64.azure.device.tar.gz 11-Jun-2015 05:13  140M
<ogra_> no, thats up to date i think
<sergiusens_> 11 and not 17
<ogra_> yes
<ogra_> before it was 09
<rsalveti> wily was 11
<rsalveti> 09 was vivid
<ogra_> oh
<rsalveti> and for vivid I manually replaced earlier today http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/
<rsalveti> as a workaround
<rsalveti> but, it seems the importer still didn't see the new image
<sergiusens_> ogra_: where is that "Publishing " message supposed to be logged?
<rsalveti> which is super annoying
<rsalveti> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/20150617.2/
<sergiusens_> rsalveti: I suspect that, but I don't know :-)
<kgunn_> jdstrand: ok...sorry, wanted to make sure and double check everything...so yeah, with @unrestricted i see aa denial for /sbin/killall5
<rsalveti> man, so many paths
<kgunn_> which makes sense based on what tyler said earlier
<kgunn_> e.g. pidof is actually part of killall5
<rsalveti> yeah, for wily it's still not there http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/pending/
<ogra_> http://paste.ubuntu.com/11732394/
<ogra_> sergiusens_, /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.3.log on nusakan
<rsalveti> http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-core/wily/?C=M;O=D
<rsalveti> yeah, more up-to-date log
<ogra_> no trace of azure there :(
<rsalveti> no azure
<jdstrand> kgunn_: ok, so use /sbin/killall5 ixr,
<rsalveti> ogra_: how many hours is the importer taking nowadays?
<ogra_> the "publishing" actually comes from debian-cd i think
<kgunn_> ack, was doing as you typed
<ogra_> rsalveti, not long for core
<rsalveti> seems there is one importer running atm
<kgunn_> jdstrand: so i should revert the /bin/pidof and bin/sleeps to ix  as well ? (as i have them ux atm)
<sergiusens_> ogra_: I added Publishing logs in ubuntu-cdimage
<ogra_> yeah, and the word doesnt appear in a grep in debian-cd
<ogra_> only in cdimage
<sergiusens_> ogra_: something tells me this doesn't seem to be working if os.path.exists("%s.azure.device.tar.gz" % source_prefix)
<ogra_> yeah, i guess source_prefix is somehow a bit different
<sergiusens_> ogra_: different? livecd.ubuntu-core.azure.device.tar.gz  vs livecd.ubuntu-core.device.tar.gz
<ogra_> i think it is more than just  livecd.ubuntu-core ... moght be a full path
<ogra_> *might
<jdstrand> kgunn_: yes please. we want to get rid of any ux's
<jdstrand> kgunn_: is this something I could run in a vm?
<sergiusens_> ogra_: I grabbed those names from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-core-system-image/+build/29997
<ogra_> well, if you look at http://paste.ubuntu.com/11732394/ ... source_prefix might have a stamp and all
<kgunn_> jdstrand: yeah it is
<ogra_> https://launchpadlibrarian.net/209363495/livecd.ubuntu-core.rootfs.tar.gz ...
<sergiusens_> ogra_: oh, I found an issue in my diff
<jdstrand> kgunn_: if you give me instructions, then I can maybe expedite this
<kgunn_> jdstrand: sure....let me clean up and push and i'll share
<jdstrand> that said, I do have something I'm working on atm and won't be able to get to it for a little while
<jdstrand> but certainly full-force in the morning if not later today
<kgunn_> jdstrand: i'm making some headway now...but i'll share later
<jdstrand> kgunn_: ok, however you want to do it
<kgunn_> i think the tricky bit was not realizing that @unrestricted would lead to more aa denials to add
<sergiusens_> ogra_: http://paste.ubuntu.com/11732451/
<ogra_> sergiusens_, uuuh
<ogra_> yeah :)
<sergiusens_> ogra_: I could just make that amd64 as well :-P
<ogra_> haha
<ogra_> yeah
<sergiusens_> ogra_: is that an ack?
<ogra_> well it is only temporary anyway
<ogra_> sure, do it
<sergiusens_> ogra_: so just like http://paste.ubuntu.com/11732463/
<sergiusens_> ?
<ogra_> yup, looks fine
<sergiusens_> ogra_: rsalveti ok, new build triggered
 * ogra_ crosses fingers
 * sergiusens_ takes a break to walk the dogs
<rsalveti> sergiusens_: awesome
<rsalveti> importer still not finished
<rsalveti> wtf
<mvo_> sergiusens_: good luck, I need to go to bed, if it still not workss, please let me know by mail and I continue in the morning
<sergiusens_> rsalveti: build not done yet (I think all builds need to finish)
<rsalveti> no, this was one importer from more than one hour ago
<rsalveti> that was still running
<rsalveti> sergiusens_: importer is another cronjob
<rsalveti> everything is pull based
<rsalveti> :-)
<kgunn_> Jun 17 20:33:59 localhost kernel: [ 1905.624951] audit: type=1400 audit(1434573238.995:14269): apparmor="DENIED" operation="ptrace" profile="mir_system-compositor_snap1" pid=4484 comm="pidof" requested_mask="trace" denied_mask="trace" peer="unconfined"
<kgunn_> jdstrand: so this is one i'm confuddled about ^
<kgunn_> denied mask "trace" ?
<ogra_> sergiusens_, rsalveti still 11th
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.4/
<Laney> ogra_: what I do? :)
<ogra_> Laney, how did you make your changes to cdimage ?
<ogra_> did you follow https://wiki.ubuntu.com/ReleaseTeam/CDImageSetup ?
<Laney> more or less
<ogra_> seems there was some cowboyed code in there and it was overwritten
<ogra_> and usually cdimage screams loudly if thats the case to prevent you from merging
<Laney> well maybe someone ran bzr revert or whatever
<Laney> it'll only complain if there are conflicts, not sure I touched the same areas
<ogra_> yeah
<kgunn_> reading, this looks related...
<kgunn_> https://github.com/docker/docker/issues/7276
<ogra_> Laney, thanks ...
<Laney> sorry if it was me, didn't do it on purpose
<Laney> is the code still alive?
<ogra_> no, seemingly not ... well, not the code we need
<ogra_> and nobody seems to have a backup
<ogra_> sergio is just trying his best and i dont feel awake enough to hack into it right now (i'll do it in my morning if there is no solution over night though)
<jjohansen> kgunn_: what confuses you about it? mir_system-compositor_snap1 is trying to trace an unconfined peer process
<kgunn_> jjohansen: i'm quite new to these concepts, and i'm going through the process of getting the security profile correct for
<kgunn_> mir in order to be able to upload it to the store, so in my caveman brain i think "how can i make this go away"
<jjohansen> kgunn_: well, generally speaking we don't allow a confined process to trace unconfined
<jjohansen> kgunn_: do you know what it is trying to trace?
<kgunn_> jjohansen: yeah, so this stems from some mir weirdness where there's a race between it and agetty, so there's a script that handles the race...
<kgunn_> it's using pidof
<kgunn_> that's where this is coming from
<jjohansen> kgunn_: hrmm, so my initial reaction is don't do that :)
<jjohansen> kgunn_: it can be worked around by giving the ptrace peer=(label=unconfined), rule to the profile but I'm not sure what is required to get that kind of rule into the store
<kgunn_> jjohansen:  :) i just found the line in docker
<jjohansen> jdstrand: ^ any suggestions
<sergiusens_> rsalveti: yeah :/
<sergiusens_> oops, ogra_ :-P
<kgunn_> jjohansen: i'm sure jamie will spank me :)
<ogra_> sergiusens_, rsalveti ... erm ...
<jjohansen> :)
<ogra_> sergiusens_, so your cdimage code is fine, it actually copied it over ... but i suspect livecd-rootfs isnt rebuilding it actually
<sergiusens_> ogra_: progress http://paste.ubuntu.com/11732678/
<ogra_> 2015-06-17 20:50:58 URL:https://launchpadlibrarian.net/209366564/livecd.ubuntu-core.azure.device.tar.gz [147294112/147294112] -> "/srv/cdimage.ubuntu.com/scratch/ubuntu-core/wily/daily-preinstalled/live/amd64.azure.device.tar.gz" [1]
<sergiusens_> ogra_: heh, shared the same :-P
<ogra_> yeah :)
<ogra_> great minds and all that ;)
<ogra_> i see "+ tar -c -z -f /build/device-azure.tar.gz system assets hardware.yaml" in the build log
<ogra_> and no error
<sergiusens_> ogra_: well, it's getting the wrong link from librarian
<ogra_> hmm
<sergiusens_> ogra_: latest build is https://launchpadlibrarian.net/209363535/livecd.ubuntu-core.azure.device.tar.gz
<ogra_> ah, ok
<sergiusens_> slangasek: do you know why that can be? ^
 * ogra_ wishes back the days where cdimage was shell :/
<ogra_> find_live_filesystem() was so much easier
<sergiusens_> ogra_: heh
<ogra_> it is all cody-summervilles fault !
<jdstrand> jjohansen, kgunn_: sorry, reading backscroll
<rsalveti> just check the lp job, it should tell if the azure tarball is in there
<ogra_> rsalveti, yeah, that bit is fine
<sergiusens_> rsalveti: it's there, the librarian link is wrong
<ogra_> but we're not finding the right url
<rsalveti> how that
<sergiusens_> rsalveti: well it's logged now ;-)
<sergiusens_> rsalveti: http://paste.ubuntu.com/11732678/ but the latest build's link is https://launchpadlibrarian.net/209363535/livecd.ubuntu-core.azure.device.tar.gz
<rsalveti> but https://launchpadlibrarian.net/209366564/livecd.ubuntu-core.azure.device.tar.gz is also valid (just not the one you're looking for)
<ogra_> it is not publishing it though
<ogra_> according to the log
<kgunn_> hmmm, but now i hit trace denied for all sorts of bespoke peers (webdm, docker, mir itself)
<rsalveti> ogra_: sergiusens_: /srv/cdimage.ubuntu.com/scratch/ubuntu-core/wily/daily-preinstalled/live
<sergiusens_> ogra_: rsalveti I think I found one more location
<rsalveti> it's there
<ogra_> yes, it is not publishing it
<rsalveti> -rw-r--r-- 1 cdimage cdimage 147294112 Jun 17 20:34 amd64.azure.device.tar.gz
<ogra_> right
<rsalveti> well, takes a while for it to be public
 * ogra_ was just looking at the same file :) 
<ogra_> rsalveti, cdimage logs when it publishes it
<ogra_> there is no azure in the log
<ogra_>  /srv/cdimage.ubuntu.com/log/ubuntu-core/wily/daily-preinstalled-20150617.4.log
<rsalveti> yeah
<rsalveti> not at /srv/cdimage.ubuntu.com/www/full/ubuntu-core/daily-preinstalled/pending
<rsalveti> man, this is so much more complicated than it should be
<ogra_> yep
<ogra_> i want shell back !
<rsalveti> involves 3, 4 different servers
<ogra_> would have taken me minutes
<jjohansen> kgunn_: sure, ptrace is dangerous. you will need specify each of them
<jjohansen> kgunn_: and the reverse relation as well, that is those apps have to declare the relationship as well
<jdstrand> kgunn_: so, yes, use the rule jjohansen mentioned for now, but I'm pretty uncomfortable with the technique and the rule. I think we should figure out something better. the docker policy is not something to model your policy after, btw :)
<sergiusens_> ogra_: rsalveti  http://paste.ubuntu.com/11732716/
<jjohansen> this prevents an attacker app being able to declare its allowed to ptrace without the peers saying yeah we know and trust him
<jdstrand> kgunn_: the problem is that if you you are allowed to trace unconfined, unconfined allows anything to trace it
<rsalveti> sergiusens_: looks ok
<jjohansen> jdstrand: right, so no better suggestion for now
<ogra_> sergiusens_, yeah
<jjohansen> jdstrand: really we need to fix that
<jdstrand> jjohansen: fix the mir policy or that unconfined allows tracedby?
<jdstrand> or both :)
<jjohansen> both :)
<jdstrand> so, I will probably make this a little better with a child profile for pidof
<jdstrand> that way even if mir has an issue, it would need pidof to allow something unexpected
<jdstrand> once kgunn_ gets through the initial policy, he'll give it to me to review and I can play with it
<sergiusens_> ogra_: rsalveti ok, this one is the one
<stgraber> jdstrand: hey, so what do I need to do for a snappy binary to be able to write to its user data dir (HOME)?
<ogra_> building ?
<sergiusens_> ogra_: yes
<ogra_> yay
 * sergiusens_ starts to use http://whatthecommit.com/ again
<rsalveti> lol
<stgraber> jdstrand: I was hoping I wouldn't have to also make our client tool unconfined :)
<jdstrand> stgraber: it should be allowed by the policy. You need to look in SNAP_APP_USER_DATA_PATH
<ogra_> stgraber, snappy binaries can not write to $HOME ...
<ogra_> right
<stgraber> error: mkdir /root/apps/lxd/0.11-0/.config: permission denied
<ogra_> SNAP_APP_USER_DATA_PATH is a subdir for the app in $HOME
<jdstrand> yes
<rsalveti> sergiusens: seems we're good regarding the --install=docker issue: https://bugs.launchpad.net/snappy/+bug/1465879/comments/5
<ubottu> Ubuntu bug 1465879 in Snappy "docker framework does not install via ubuntu-device-flash" [High,Confirmed]
<jdstrand> you don't get all of home, you get SNAP_APP_USER_DATA_PATH
<sergiusens> Chipaca: http://whatthecommit.com/bf057fb0e2e7a4450250ebf7d6e1d084 :-P
<stgraber> sure sure, but clearly I don't even get write access to SNAP_APP_USER_DATA_PATH
<rsalveti> lol
<jdstrand> stgraber: is that an apparmor denial?
<ogra_> stgraber, because /root is readonly perhaps ? ;)
<stgraber> ogra_: isn't
<jdstrand> and then there is that :)
<stgraber> [94170.804198] audit: type=1400 audit(1434576560.135:55): apparmor="DENIED" operation="mkdir" profile="lxd_lxc_0.11-0" name="/root/apps/lxd/0.11-0/.config/" pid=6085 comm="lxc" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<Chipaca> sergiusens: ?
<sergiusens> Chipaca: I am just fooling around :-)
<Chipaca> sergiusens: http://whatthecommit.com/0041a2c1bcc6d21895a46d0b92f64a88 then :)
<sergiusens> \o/
<ogra_> heh
<jdstrand> stgraber: oh, that is because we are using @{HOMEDIRS}/*/ instead of @{HOME}. @{HOMEDIRS}/*/ does not include /root.
<jdstrand> stgraber: I remember I asked other snappy devs about this
<stgraber> that probably ought to be fixed :)
<jdstrand> and it was decided that /root/ was not needed. apparently that needs to be revisited
<jdstrand> stgraber: before I fix it, I think there might need to be a discussion. can you file a bug agount snappy, the project?
<jdstrand> stgraber: you can add an ubuntu-core-security task
<jdstrand> stgraber: I have questions around /root, the FHS, rollbacks, etc
<stgraber> jdstrand: says that ubuntu-core-security doesn't use LP for bugs so can't add a task
<stgraber> jdstrand: anyway, bug 1466234
<ubottu> bug 1466234 in Snappy "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,New] https://launchpad.net/bugs/1466234
<jdstrand> stgraber: sorry, snappy the project and ubuntu-core-security under Ubuntu
<jdstrand> I can add it
<stgraber> ah, done
<jdstrand> stgraber: ok, I asked my questions. if the snappy devs are comfortable with it and respond in the bug, I'll adjust the policy
<stgraber> jdstrand: next question for you :)
<stgraber> (amd64)root@localhost:~# /usr/bin/ubuntu-core-launcher lxd lxd__0.11-0 /apps/lxd/0.11-0/bin/lxd.start
<stgraber> aa_change_onexec failed with -1
<stgraber> . errmsg: No such file or directory
<stgraber> what does that mean? ^
<jdstrand> stgraber: it couldn't find the profile 'lxd__0.11-0'
<jdstrand> 'lxd__0.11-0' is not formatted well btw'
<jdstrand> so either the yaml has an issue or the launcher isn't calculating the appname part correctly
<jdstrand> there should be something between the '__'
<jdstrand> it should be the name of the service (from services) or the binary (from binaries)
<stgraber> oh, also, that thing is a framework, not sure if that's relevant
<jdstrand> it isn't relevant to what should be happening. it might be a contributing factor to a bug
<jdstrand> stgraber: can you paste /apps/lxd/current/meta/package.yaml?
<stgraber> oh, I think I know what's wrong in the yaml, testing
<stgraber> jdstrand: so a missing name attribute on the service was the source of the problem. Kinda surprised the tool isn't validating this though.
<stgraber> now to figure out the next problem
<Chipaca> tedg: your opinion wrt SNAP_APP_USER_DATA_PATH might be relevant to #1466234
<Chipaca> bug #1466234 that is
<nothal> Bug #1466234: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root <Snappy:New> <ubuntu-core-security (Ubuntu):Incomplete> <http://launchpad.net/bugs/1466234>
<ubottu> bug 1466234 in ubuntu-core-security (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Undecided,Incomplete] https://launchpad.net/bugs/1466234
<jdstrand> stgraber: yes, the review tools are currently disabled (they would have caught)
<stgraber> jdstrand: so, http://paste.ubuntu.com/11732810/, any idea why I'm getting apparmor denials with that for the service?
<stgraber> Jun 17 21:50:22 localhost.localdomain audit[787]: <audit-1400> apparmor="DENIED" operation="pivotroot" profile="lxd_lxd_0.11-0" name="/run/cgmanager/root/" pid=787 comm="cgmanager" srcname="/run/cgmanager/root/"
<stgraber> doesn't look unconfined to me :)
<jdstrand> Chipaca: is there a bug to re-enable the review tools?
<ogra_> Wed Jun 17 21:53:12 UTC 2015
<ogra_> Publishing amd64 ...
<ogra_> Publishing amd64 live manifest ...
<ogra_> Publishing amd64 device tarball ...
<ogra_> Publishing amd64 azure device tarball ...
<ogra_> \o/
<ogra_> sergiusens, rsalveti ^^^
<sergiusens> \o/
<sergiusens> ogra_: it just just just finished :-P
<ogra_> i was tailing the log :=)
<sergiusens> ogra_: http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/20150617.5/ is up to date as well
<jdstrand> stgraber: the unconfined template isn't trruly unconfined. http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/view/head:/data/apparmor/templates/ubuntu-core/15.04/unconfined
<ogra_> yippiie
<jdstrand> stgraber: it is missing a 'pivot_root,' rule
<stgraber> jdstrand: ah, what do I do to get something that's completely unconfined?
 * kgunn realizes no one likes being confined
<stgraber> because no pivot_root is going to be a bit of a problem for us :)
<jdstrand> stgraber: I can add that
<stgraber> jdstrand: anyway I can easily do that locally so I can see what fails next?
<Chipaca> jdstrand: nope
<jdstrand> stgraber: in the mean time you can either just add the rule to /var/lib/apparmor/profiles/... or you can use 'security-policy' (https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy) and use the unconfined template with pivot_root added
<stgraber> jdstrand: ok, I'll add the rule locally for now
<jdstrand> kgunn: well, yes, but lxd is quite a different beast :)
<kgunn> :)
<stgraber> jdstrand: will that profile with this addition let me switch profile, specifically to real unconfined?
<kgunn> jdstrand: quick one i hope, so i worked through to the point now where i need to add "binaries" to my yaml for the actual mir-demo-server
<kgunn> and the question is about paths...
<ogra_> E=mcÂ²
<ogra_> ;)
<kgunn> since mir-demo-server is actually in debs/usr/bin
<ogra_> (all relative to your SNAP_APP_PATH)
<kgunn> ogra_: ta
<kgunn> see i knew it was easy
<kgunn> jdstrand: ok, and with aa profile on this binary...since it's part of the framework, do i also need to do a seperate security pollicy on it ?
<elopio> I need some go help in here. When I run go test ./... I get cmd/snappy/common.go:28: undefined: priv.WithMutex
<elopio> but it is defined, and I don't get that error from my desktop.
<kgunn> since it needs some paths not needed by the main service
<elopio> go is drunk.
<Chipaca> elopio: tell me more
<Chipaca> elopio: i have a good guess as to what's happening
<Chipaca> elopio: in whatever you're running this, this not-your-desktop environ, has the GOPATH pointing at a snappy different from the one you're running the tests on
<elopio> Chipaca: I don't know what else to tell you. I've pulled trunk and ran the tests.
<Chipaca> elopio: because you're running the tests with ./... you're not picking up that snappy for the test runner
<rsalveti> ogra_: sergiusens: lovely
<Chipaca> elopio: but the imports in files under test use absolute paths
<Chipaca> elopio: e.g. launchpad.net/snappy/potato
<Chipaca> elopio: so those are coming from your GOPATH
<jdstrand> kgunn: this is where framework-policy comes into play I think, or maybe not
<kgunn> well, i see i can add the client policies that the framework publishes
<kgunn> for use as a cap by  the binaries
<kgunn> but, don't want to expose more through that than is needed....
<elopio> Chipaca: it works now Â¬Â¬
<Chipaca> elopio: ð
<jdstrand> kgunn: right. so we want to expose the minimum in the framework-policy. are you saying that the mir-demo-client binary needs more than the minimum?
<elopio> I removed my link from the GOPATH to my workspace. Then made it again...
<elopio> Chipaca: how do you handle different branches in src/launchpad.net/snappy ? Do you use ln ?
<Chipaca> elopio: you use a pipeline?
<kgunn> jdstrand: nope, sorry... so there's a binary mir-demo-server which is launched by (the service) mir-compositor
<Chipaca> elopio: bzr gets confused by symlinks
<jdstrand> kgunn: if it can use the minimum with the default template, then you can refer to your framework-policy
<kgunn> this is before clients actually show up...
<jdstrand> kgunn: ok, in that case, you need to write "security-policy" for your binary
<elopio> Chipaca: no, I have a workspace with all the branches as dirs. I put a link in src/launchpad.net to the one I want to test.
<kgunn> jdstrand: ok, so follow the same construct/form...
<kgunn> ta
<jdstrand> kgunn: yes
<Chipaca> elopio: ok
<kgunn> jdstrand: frighteningly i may understand this before i'm all done :)
<Chipaca> elopio: that'll confuse either go or bzr, depending how you're doing it
<Chipaca> elopio: you can make it work if you're careful
<jdstrand> kgunn: I'll also (hopefully) helpfully remind you that https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy has boilerplate
<Chipaca> elopio: me, i gave up using symlinks and just move stuff around
<Chipaca> elopio: when i'm not using pipelines that is
<elopio> this is the first time it failed, so I guess I wasn't careful.
<elopio> Chipaca: do you mean http://wiki.bazaar.canonical.com/BzrPipeline ?
<Chipaca> elopio: yes
<kgunn> yessir
<elopio> ok, I'll try that.
<kgunn> ok...nuff for now, maybe more later
<Chipaca> elopio: and in bazar.conf,
<Chipaca> n = swp :next
<Chipaca> p = swp :prev
<Chipaca> ps = pipes
<elopio> Chipaca: those are alias, right?
<Chipaca> elopio: in [aliases] i mean
<Chipaca> yes
<elopio> cool. Sounds less insane than links.
<Chipaca> elopio: until it throws a stacktrace at you, sure :)
<sergiusens> heh
<sergiusens> I recall those
<sergiusens> del-pipe has some issues
<Chipaca> sergiusens: just switching with new files added but not committed seems to tickle it
<Chipaca> anyway
<sergiusens> Chipaca: oh, that works fine for me
<Chipaca> elopio: everything is terrible.
<Chipaca> elopio: we're moving back to C, and CVS
<slangasek> sergiusens: sorry, I have no brain state relevant to the azure files/builds/downloads.  If you're stuck I'd suggest tagging the launchpad team
<elopio> :) let me first hate pipeline before making the move.
<sergiusens> slangasek: fixed 30' ago, but thanks :-)
<slangasek> sergiusens: hah, ok
<sergiusens> rsalveti: do you plan to copy https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.24-0ubuntu2 to tools-proposed?
<rsalveti> sergiusens: already there
<rsalveti> sergiusens: and utlemming just confirmed that it worked for him
<rsalveti> so all good
<sergiusens> rsalveti: oh neat :-)
<sergiusens> one more thing to cross off the list :-)
<sergiusens> rsalveti: are you moving it to tools per se?
<sergiusens> or waiting on that one?
<rsalveti> sergiusens: not now, want to migrate things at the same time we get to test our next stable image
<rsalveti> so we can all be testing the same thing all together
<sergiusens> rsalveti: sounds good
<sergiusens> elopio: btw, the bzr bd command there doesn't play nice with my --builder option in bazaar.conf
<elopio> sergiusens: we initially copied bzr-buildpackage from the original script, but it didn't work for me.
<elopio> sergiusens: can you try that?
<sergiusens> Building the package in /home/sergiusens/go/src/launchpad.net/build-area/ubuntu-snappy-1.1.2, using sbuild -d wily --arch=amd64 -c wily-amd64 -j9 -uc -us
<sergiusens> Unknown option: u
<sergiusens> I'm on trusty
<sergiusens> oh, being called for dinner
 * elopio goes to watch the game.
<stgraber> [ 5298.277754] audit: type=1400 audit(1434583615.201:38): apparmor="DENIED" operation="change_profile" profile="lxd_lxd_0.11-0" pid=4690 comm="lxd" target="lxc-container-default"
<stgraber> jdstrand: should be added to the unconfined profile too ^
<jdstrand> hmm
<jdstrand> I'll add it to the list
 * jdstrand heads out
 * rsalveti also heads out, dinner and football
#snappy 2015-06-18
<stgraber> working LXD snap: https://plus.google.com/+St%C3%A9phaneGraber/posts/aX6vogzEQ1X
<stgraber> just got to work on making a more restrictive policy so that it's acceptable for the store
<miken> Wow, that's pretty exciting stgraber . Nice work!
<sergiusens> elopio: for later lp:~sergiusens/snappy/upgradeBlockedSelfTest
<sergiusens> elopio: but I can't run adt on trusty
<sergiusens> elopio: 2015/06/17 23:49:21 Error while running [adt-run -B --setup-commands touch /run/autopkgtest_no_reboot.stamp --setup-commands mount -o remount,rw / --setup-commands dpkg -i /tmp/snappy-debs/*deb --setup-commands sync; sleep 2; mount -o remount,ro / --override-control debian/integration-tests/control --built-tree /home/sergiusens/go/src/launchpad.net/snappy --output-dir /tmp/snappy-test/output --copy=/tmp/snappy-test/debs:/tmp/snappy-debs --- ss
<elopio> sergiusens: you probably need adt from the ppa.
<elopio> https://packages.debian.org/sid/autopkgtest
<elopio> not the ppa, the deb ^
<elopio> sergiusens: I don't fully understand everything you are doing in your test, but instead of writing the installYaml file, can't we call ubuntu-device-flash with a device-part and deploy that to the testbed?
<elopio> snappy team, for when you get up, we seem to have a regression: https://bugs.launchpad.net/snappy/+bug/1466311
<ubottu> Ubuntu bug 1466311 in Snappy "selftests fail with: ubuntu-core-launcher: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory" [Undecided,New]
<elopio> @nothal help
<nothal> elopio: No such command!
<elopio> nothal -h
<elopio> @nothal -h
<nothal> elopio: No such command!
<elopio> @nothal info
<nothal> elopio: No such command!
<dholbach> good morning
<fgimenez> good morning
<JamesTait> Good morning all; happy International Picnic Day! ð
<Chipaca> picnic \o/
<dholbach> hey JamesTait - picnic today would be fantastic :)
<dholbach> JamesTait, I'm looking at the oem snap bits again today and I'm not quite sure how I'm supposed to use the API :)
<dholbach> JamesTait, http://pastebin.ubuntu.com/11734613/ is the bits of information I extracted from our discussion yesterday
<dholbach> but I'm not quite sure where to go
<ogra_> bah, couldnt they pick a day with better weather at least :P
<JamesTait> dholbach, what is it you're wanting to find, exactly?
<dholbach> all snaps of the type oem
<dholbach> (not sure if we're going to rename them to gadget snaps at some stage?)
<JamesTait> dholbach, I think `curl https://search.apps.ubuntu.com/api/v1/search?q=content%3Aoem -H 'X-Ubuntu-Frameworks: ubuntu-core-15.04-dev1'` should get what you want?
<dholbach> cool thanks JamesTait - I'll play around with that a bit more
<JamesTait> dholbach, it's a bit awkward, because we want queries to be additive - adding more terms to the query should match more documents, with those matching more terms scoring higher so coming first in the results (simplifying a bit) - but filters need to be subtractive - i.e. "don't show me anything I can't use with these frameworks/this architecture/etc."
<dholbach> yep, ok
<Chipaca> anybody know what restrictions apparmor places on package names / versions / etc, if at all?
<jjohansen> Chipaca: apparmor it self? minimal if any, however the are guides for what is allowed in the name
<jjohansen> https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<Chipaca> jjohansen: yep, i'm aware of what we've documented
<Chipaca> jjohansen: i'm documenting what we actually restrict
<jjohansen> Chipaca: apparmor does have a few limits on its profile names, the first character is restricted and // is used as name separator similar to how / is used in filenames
<jjohansen> Chipaca: so I am not sure the exact mapping of snap name to profile name
<Chipaca> jjohansen: ok, ta
<jjohansen> Chipaca: currently profile names, require an alpha-numeric or '/' start character
<jjohansen> \0 is not allowed as a valid character in the name, and // is interpreted as a name separator
<jjohansen> eg.  profile_name//child_name
<Chipaca> jjohansen: alphanumeric is [a-zA-Z0-9], yes?
<jjohansen> +, &, : are allowed as a leading character in some cases (as compound labels) but not actual profile names
<jjohansen> so you might seem them reported by say ps -Z
<jjohansen> Chipaca: its actually wider than that
<Chipaca> what even is ps -Z
<Chipaca> not in the manpage :)
<jjohansen> Chipaca: ps -Z will show the security label on a process
<jjohansen> $ ps -Z
<jjohansen> LABEL                             PID TTY          TIME CMD
<jjohansen> unconfined                       3253 pts/1    00:00:01 bash
<jjohansen> unconfined                       6951 pts/1    00:00:00 ps
<Chipaca> yep
<Chipaca> jjohansen: how is the security label connected to the apparmor profile?
<jjohansen> that label is mostly likely a profile name, but it could be a compound label
<jjohansen> a profile is a label, but a label could be composition of multiple profiles
<jjohansen> A//&B
<jjohansen> is the intersection of profile A and profile B
<Chipaca> woh
<Chipaca> interesting
<jjohansen> this can show up on stacked tasks (not landed yet)
<Chipaca> i'm going to just leave it at "starts with alphanumeric or /", and pretend the other cases are for people who know what they're doing
<jjohansen> but also on sockets, and files that have been shared between apps
<Chipaca> as what i'm trying to document are the limitations and checks put on a package from its metadata
<jjohansen> Chipaca: that is a good idea, at least for now
<Chipaca> k
<rsalveti> sergiusens: ogra_: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/pending/ seems all good for vivid as well
<Chipaca> mvo_: sergiusens: documenting what we actually do with metadata is making me sad
<rsalveti> Chipaca: lol, why?
<Chipaca> `name`: documented as `[a-z0-9][a-z0-9+-]`. The `package.yaml` parser requires it to be non-empty (all-whitespace is ok) and that it doesnât contain a `.`, but otherwise doesnât care. `ubuntu-core-launcher` requires that appname match `^[a-z0-9][a-z0-9+._-]+$` (this includes the origin though). Apparmor requires the profile name (derived from the package name) start with an alphanumeric (or /). Click review checks against `^[a-z0-9][a-z0-9+-]+$`
<mvo_> Chipaca: meh, sounds like a good opportunity to fix it
<Chipaca> mvo_: concentrating on writing it out
<Chipaca> mvo_: then we can see what/how we fix
<Chipaca> it's not just name :)
<mvo_> Chipaca: ok, thanks for finding that
<Chipaca> and arguably, maybe the checks do belong just in the review tools and snappy should be laxer?
<Chipaca> i don't know
<Chipaca> i'm just documenting so we can have the discussion :)
<Chipaca> trying not to get too bogged down though
<rsalveti> yeah
<Chipaca> but things like the service's name not being required by the tools are already catching people off guard (because things break)
<ogra_> rsalveti, yeah !
<sergiusens> elopio: that's what I mentioned in the standup; I wanted a full e2e test but how do I trigger this, where do we store the alternate device.tar (it's not small), etc...
<sergiusens> elopio: shouldn't we have adt in a ppa?
<mvo_> barry: good morning! I'm curious, what happend here https://code.launchpad.net/~barry/ubuntu-system-image/trunk ? it says "
<mvo_> This branch has not been pushed to yet." - I wantd to look at fixing this one bug we talked about yesterday
<Chipaca> jdstrand: you around?
<sergiusens> hmm, I can't run our integration tests/adt on trusty, it logs me out
<ogra_> might be a security feature :)
<sergiusens> ogra_: right...
<sergiusens> fgimenez: any ideas?
<sergiusens> fgimenez: btw lp:~sergiusens/snappy/upgradeBlockedSelfTest
<sergiusens> fgimenez: but elopio wants to run the E2E test from the start (I guess he wasn't paying attention to what I said during standup :-P)
<jdstrand> Chipaca: I am here but I am heading into a meeting in a few minutes. can I circle back to you?
<fgimenez> sergiusens, no ideas atm :( we can talk with elopio later
<fgimenez> sergiusens, your branch looks great! now we can split the related tests in different files for instance https://code.launchpad.net/~fgimenez/snappy/failover-tests/+merge/262191
<sergiusens> Chipaca: you should go back to square one until he circle's back with you :-P
<mvo__> rsalveti: could you commit the recent changelog entries from the upload to trunk please? or if you don't have it I handy can do it too, but currently the daily builds are not updated because of the version number difference
<rsalveti> mvo__: oh, creap
<rsalveti> crap
<rsalveti> I always do that
<rsalveti> give me a minute
<rsalveti> mvo__: done, sorry for that
<mvo__> rsalveti: no worries
<rsalveti> you get that feeling that dput is the end result and forget to run bzr push :-)
<rsalveti> would be better if a bzr push would automatically cause a dput (or similar)
<rsalveti> but well :-)
<mvo__> rsalveti: yeah or if we could simply sync our ppa version to hte archive or something
<mvo__> rsalveti: fwiw, I'm starting the 16.04 filesystem and packaigng format docs, I noticed they are in the sprint agenda with my name on them
<Chipaca> sergiusens: you dieded
<Chipaca> sergiusens: hangouts don't like people talking nasty things about grub
<mvo__> Chipaca: haha - oh grub
<mvo__> Chipaca: anything interessting that is more interessting than trying to write about fs layouts?
<Chipaca> mvo__: https://plus.google.com/hangouts/_/canonical.com/theGoodTheBadAndTheUgly?authuser=1
 * sergiusens suggests mvo__ to run /nick mvo
<barry> mvo__: i'm a bad person: https://code.launchpad.net/ubuntu-system-image/+git
<davmor2> sergiusens: but he has been growing that pony tail for so long
<mvo> barry: heh, excellent
<rsalveti> mvo: the problem with package sync is that the archive police will complain that the changelog contains only "auto build"
<rsalveti> maybe we could improve that with our build scripts
<rsalveti> mvo_: the problem with package sync is that the archive police will complain that the changelog contains only "auto build"
<rsalveti> seems you're having a personality issue
<rsalveti> barry: nice
<rsalveti> mvo: thanks, got a link for the doc?
<barry> rsalveti, mvo: yep, it's great until i tried to land the package through the train.  i feel like i've derailed, or more accurately, tried to drive on a railroad with a different gauge ;)
<rsalveti> oh right, not train compatible
<barry> rsalveti: except that i have a separate packaging branch and that is still bzr.  the problem is that `bzr merge-upstream` on the resulting orig.tar.gz doesn't do the same thing if you can't merge in the upstream branch too, and that's where i'm going off the rails.  I've got one or two more things to try and then i'm going to punt and do a "normal" distro upload
<rsalveti> barry: looks painful, wonder how hard would be for the train to actually support git
<barry> rsalveti: i got the impression from robru that it wouldn't be terribly difficult, it's just that they really, really, really need to kill the spreadsheet first
<rsalveti> hahaha
<rsalveti> indeed
<sergiusens> killing the spreadsheet is getting old :-P
<rsalveti> don't think it will die
<sergiusens> seems like a myth
<rsalveti> yeah
<barry> naw, it just has enough lives to keep 3 or 5 kittens dancing on rainbows
<kyrofa> sergiusens, ping
<sergiusens> kyrofa: pong
<kyrofa> sergiusens, morning! Quick question: the webdm api uses both DownloadSize and InstalledSize. Knowing which to use if the package is either installed or not installed is easy, but which do I use when Installing/Uninstalling?
<kyrofa> A quick glance at the code makes me think installed -> InstalledSize, everything else -> DownloadSize
<kyrofa> But I wanted to double-check
<sergiusens> kyrofa: that is the right logic
<sergiusens> kyrofa: btw, do you have time today to discuss the new api?
<kyrofa> sergiusens, sure! I have standup at in about 45 minutes, but I'm free otherwise
<sergiusens> kyrofa: so in 10'?
<kyrofa> sergiusens, sounds good
<kyrofa> sergiusens, I sent you an invite with a video link
<mvo> hrm, we really need to kill this global lock, autopilot preventing instlaling apps is anoying
<sergiusens> kyrofa: one more sec
<kyrofa> sergiusens, no hurry :)
<sergiusens> kyrofa: btw, you can make up links as you go
<kyrofa> sergiusens, you mean for the hangouts? Yeah, I'm still new at this :P
<sergiusens> kyrofa: https://plus.google.com/hangouts/_/canonical.com/[whateveryouwant]
<kyrofa> sergiusens, heh, good to know, thanks :)
<elopio> good morning
<elopio> fgimenez: I'm in the call. talky.io seems nicer than firefox hello.
<fgimenez> elopio, mine says connecting...
<elopio> fgimenez: I can see you... So not much better.
<elopio> fgimenez: yes, I can hear  you.
<elopio> well, not anymore.
<fgimenez> elopio, wait, i'll try again
<alecu> tedg: hi! Is there something similar to click hooks in the snap installer?
<alecu> tedg: also, is there something preventing snaps from shipping old fashioned .desktop files?
<elopio> fgimenez: it could be talky killing my connection :(
<tedg> alecu, Not yet, I've made a proposal on that, but it hasn't be ratified.
<tedg> alecu, It will definitely be needed for the Ubuntu Personal use-cases
<elopio> Team, can you please look at this: https://bugs.launchpad.net/snappy/+bug/1466311
<elopio> breaks the selftest
<ubottu> Ubuntu bug 1466311 in Snappy "selftests fail with: ubuntu-core-launcher: error while loading shared libraries: libseccomp.so.2: cannot open shared object file: No such file or directory" [Undecided,New]
<elopio> rsalveti: ^
<tedg> alecu, They can ship a desktop file in the package, but it's not clear whether they have to or not. The thing that won't be possible is to write the temporary ones to ~/.local/share/applications/, those will die.
 * tedg does a happy dance
<rsalveti> elopio: against which image/channel?
<elopio> rsalveti: rolling edge.
<elopio> doesn't happen on stable 15.04 that was the other I tried.
<elopio> Chipaca: you said building the snappy for arm was simple. How do you do it?
<Chipaca> elopio: you mean snappy the commandline tool?
<elopio> Chipaca: yes.
<Chipaca> elopio: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/cross-build.md
<elopio> I was looking in the readme :)
<Chipaca> elopio: quÃ© bruto, pÃ³ngale cero
<elopio> :D
<elopio> Chipaca: but to get the arm deb, well have to make a chroot, right?
<Chipaca> elopio: unless you _really_ enjoy playing with ar, yes
<Chipaca> well, dpkg-deb could probably do it :)
<alecu> tedg: sounds good, thanks!
<jdstrand> Chipaca: hey, what's up?
<Chipaca> jdstrand: hey! um.... i think i got my questions answered :) thanks!
<jdstrand> ok
<sergiusens> fgimenez: elopio maybe you ca merge my branch into yours
<sergiusens> fgimenez: elopio or maybe move that branch you are working on to be owned by snappy-dev
<Chipaca> jdstrand: i think the last one was about click-review, wrt what ran check_framework, but i found the inspect call
<elopio> fgimenez: sergiusens: +1 to merge this rev: http://bazaar.launchpad.net/~sergiusens/snappy/upgradeBlockedSelfTest/revision/510
<elopio> I would like to keep the test in a separate MP.
<sergiusens> elopio: sure
 * elopio gets a trusty vm
<sergiusens> Laney: http://paste.ubuntu.com/11735924/
<sergiusens> can you take a look and fix that please?
<fgimenez> sergiusens, elopio ok merged into lp:~fgimenez/snappy/go-functional-tests
<roadmr> hey snappers! I hooked up a webcam to my rpi2 and installed the webcam snap but it gives a permission denied error. I already 666'd /dev/video0, where else could I look? http://paste.ubuntu.com/11735959/
<sergiusens> roadmr: you need to hw-assign to the snap
<sergiusens> roadmr: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/
<roadmr> sergiusens: oh! cool, let me do that
<roadmr> sergiusens: haha thanks, that was my next question: "where would one find out about this?"
 * roadmr just deleted the webcam snap by mistake - reinstalling haaha
<sergiusens> roadmr: I fear we don't have specific docs about security things at a user level, do we jdstrand ?
<elopio> sergiusens: but I still need the -uc -us to avoid the signing.
<sergiusens> elopio: sure, add that back
<jdstrand> sergiusens: we do not afaik. hw-assign should be documented somewhere
<jdstrand> (in all its forms)
<elopio> fgimenez: and we need a better handling on the command line arguments. For now we could support running in beaglebone by passing the debDir.
<sergiusens> elopio: I added the "provide my own bzr bd'ed debs" since this did something weird with my system (http://paste.ubuntu.com/11735996/)
<plars> elopio: so I was thinking more about our discussion and got to wondering... could we use the a-b booting of snappy to try new images with automatic recovery if things go badly? Do we have enough control from within snappy to make that happen?
<sergiusens> elopio: just use the flags package or what we use
<fgimenez> elopio, i had a branch somewhere that used flag, worked pretty well
<sergiusens> elopio: http://golang.org/pkg/flag/ or http://godoc.org/github.com/jessevdk/go-flags (which we use everywhere now)
<plars> elopio: so in other words, keep system-a as a stable image that we never really need to change, use it to flash the new stuff (even possibly a different channel, release, etc) to system-b, reboot, see if we are in the new one, run tests, and force it back to system-a when we are done?
<fgimenez> elopio, http://bazaar.launchpad.net/~fgimenez/snappy/cross-compile-debs/view/head:/_integration-tests/main.go
<elopio> plars: we want to test upgrades, so we need to put in a version n-1 and in b version n.
<jdstrand> sergiusens: I was going to do an MP for hw-assign and then decided not to because I didn't feel I had all the details for the oem part bits and wasn't sure if there was something beyond oem and the hw-assign command
<plars> elopio: oh I see, that would break upgrade testing
<elopio> plars: for that to work, we would need a c partition, with the pristine factory approved image. Which is something I think sergiusens is planning for.
<roadmr> sergiusens: thanks, it works \o/ I'm now reading that doc you pointed me to
<plars> elopio: can we have a system-c for that? :)
<plars> hah, that's what I was just wondering
<plars> so the pristine image in c would be our "stable" image that we always go back to for flashing the other ones?
<plars> sergiusens: how would all that work exactly?
<elopio> plars: https://docs.google.com/document/d/15nqsGbqxSzArRoqjnydsUYfbqHDYNtVayo6WlrmVGG0/edit#
<plars> sergiusens: right now I'm planning some hard-wired boot control with relays to select whether we boot from emmc or sd on bbb, but something like this would give us a better mechanism that could work even in the absence of emmc
<sergiusens> plars: my plan is for a snappy-factory partition
<sergiusens> plars: elopio and now I get to say ricmm has ignored my proposal so far ;-)
 * sergiusens drops a smoke bomb to go get some lunch
<elopio> sergiusens needs a hug. He's feeling ignored often these days :)
<Laney> sergiusens: ok, done
<sergiusens> Laney: thanks
<plars> sergiusens: it sounds like this would give me exactly what I'm looking for, as long as I could force booting into recovery somehow, it can even be used to flash a completely new image on the non-recovery part right?
<sergiusens> plars: yeah, it can be a deploy/installer thing as well
<sergiusens> plars: and no more u-d-f complications either :-P
<plars> ricmm: how many beers can we bribe you with to look at this? ^ :)
<plars> sergiusens: elopio: so how does that work if it fails to boot the image that you flash (or upgrade to)? Does it automatically failover or do you have to take some action?
<ogra_> plars, beers dont work, try lagavulin
<plars> ogra_: that works too, as long as I can help drink it :)
<ogra_> :)
<elopio> plars: currently, you have to reboot to failover to the good image.
<elopio> I think that should happen automatically.
<sergiusens> plars: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/
<ricmm> ricmm: this is being looked at and spec'd
<ricmm> the factory partition that is
<plars> elopio: that could be handled by waiting a reasonable amount of time to boot and triggering the reset if you don't hear back in time. And on reboot it would automatically boot the other one somehow? /me looks at the post
<elopio> plars: yup. Or you could even perfor a factory reset by pressing buttons if the board is unresponsive.
<fgimenez> nice evening everyone o/
<zyga> ogra_: what's needed to get raspberry pi to upgrade normall?
<ogra_> zyga, all kernel code upstream, all uboot code upstream
<zyga> ogra_: hmm, but if I have a normal os snap and rpi specific snaps for the rest
<zyga> ogra_: should it not be possible to upgrade in-image?
<zyga> ogra_: I see that the kernel code is not in mainline kernel
<ogra_> you could update these two parts manually perhaps
<zyga> ogra_: I see, thanks
<ogra_> but snappy upgrade will still not give you an upgrade of ubuntu-core via the store
<zyga> ogra_: btw, for beagle, have you tried USB-booting?
<jkridner> zyga: with BBBlfs?
<zyga> jkridner: yes
<ogra_> nope, Pi kept me busy the last weeks, i havent touched my beagle for a while
<zyga> jkridner: there are other tools but that's the one I thought about
<jkridner> zyga: yeah. that's the one I think has the most attention now...
<jkridner> I'm in the process of trying to setup a test bench using bbblfs.
<ogra_> zyga, it shouodnt be a prob to switch the writable partition to USB actually
<ogra_> the initrd mounts everything by labels ...
<zyga> ogra_: no, not like that
<zyga> ogra_: flash remotely via usb-otg
<ogra_> oh
<ogra_> like the panda
<zyga> jkridner: what are you doing this for?
<zyga> ogra_: yes
<zyga> ogra_: probably _exactly_ the same ;-)
<longsleep> ogra_: Have you looked into available entropy on the RPi2 when it generates ssh keys on first boot?
<ogra_> :)
<zyga> jkridner: I'n looking at working with a few people to set this up for the testing lab
<ogra_> longsleep, not yet, nope
<ogra_> i'm still figthing with dtb overlay support ...
<ogra_> why cant every board be as nice as the beagle *sniff* :(
<longsleep> ogra_: DTB overlay - what do you need it for?
<zyga> jkridner: what is your goal?
<zyga> jkridner: perhaps we can work together
<jkridner> zyga: I'm also looking at using the BeagleBone Black's ability to cut power to the USB.
<ogra_> longsleep, the Pi doesnt allow using the extension headers with i2c if you dont add the right dtb overlay ... etc etc ... (there are more overlays for other HW parts)
<longsleep> ogra_: well i guess Snappy needs a way to handle any messy U-Boot and Kernel :)
<ogra_> yeah
<ogra_> thats what i'm fighting with
<zyga> ogra_: actually, I was meaning to ask you about one thing
<jkridner> I'm trying to build a test infrastructure for the http://github.com/beagleboard/linux and http://builds.beagleboard.org with a bunch of capes attached.
<jkridner> beaglebone-per-cape.
<zyga> ogra_: can we try to formalize remote flashing for snappy core
<jkridner> so that we can make sure all the capes are supported in the mainline kernel.
<zyga> ogra_: we'll need that a lot for the lab
<zyga> jkridner: oh, fantastic
<longsleep> ogra_: I see - i have a similar "problem" - i need to remove certain stuff from the DT based on boot settings - can that be done with overlay too?
<zyga> jkridner: so I have to ask, have you tried lava?
<zyga> [I used to hack lava a lot in the past]
 * jkridner looks around for rcn-ee
<ogra_> zyga, well, you wont do it fully remote unless you have some MMC or other storage with the bootloader onboard
<zyga> ogra_: for beagle and some others that's true
<zyga> ogra_: but let's think big
<zyga> ogra_: for products
<ogra_> yes, thats the prob :)
<zyga> ogra_: something we could require at snappy level
<ogra_> thinking big means taking tons of cases into account
<zyga> ogra_: android wouldn't go far without fastboot/adb
<zyga> ogra_: or forcing standards
<ogra_> so we need to start actually small to be flexible ;)
<jkridner> we plan to overwrite the bootloader in eMMC using the ROM bootloader.
<rcn-ee> jkridner, never touched lava. ;)
<ogra_> rcn-ee, its hot !
<longsleep> I will be adding a couple of issues to the Snappy tracker soon, regarding entropy, customization of boot and such - or is it too early to push for stuff like this?
<zyga> jkridner: I'm starting to build a lab-as-a-service
<zyga> jkridner: with a few other people
<ogra_> longsleep, no, keep the bugs coming
<ogra_> longsleep, we might not solve it immediately, but having it tracked is important
<zyga> jkridner: our first use case is exposing beagle's for testing anything
<jkridner> right now, we are just trying to establish we can power cycle and boot/flash a downstream board.
<ogra_> longsleep, i need to try your image on my odroid too :)
<jkridner> trying to minimize cost and complexity, leveraging whatever Beagles give us.
<zyga> jkridner: we have a lot of experience with that, plars can tell you about it :)
<longsleep> ogra_: Great - then i will just keep adding them once i have understanding what i would need
<zyga> jkridner: there's a trick that we used in lava and that works well for mostly anything
<longsleep> ogra_: Yeag that would be awesome. I heard reports from all over the world that it seems to be working.
<ogra_> well, plars wrote lava ... essentially :)
<zyga> jkridner: all that you need is a way to power the board
<zyga> ogra_: hey, I wrote a lot of it too :P
<ogra_> oh, right :)
<plars> indeed, zyga was right there sharing the blame :)
<ogra_> i always forget that you were on the other side of the fence for a while
<zyga> ogra_: (and gave it the failed launch-control name)
<zyga> ogra_: nah, there was no fence
<jkridner> rcn-ee: if I reflash bone1 with the 5/1 image, I should at least have a gserial connection, so I'm going to do that now.
<ogra_> lol
<plars> ogra_: in fact, that's where he started
<zyga> yeah
<ogra_> oh
<ogra_> i thought you started in canonical :)
<rcn-ee> jkridner, correct..
<jkridner> zyga: yeah, we need some ideas for power.... we can cut USB power, but we'll need some additional juice a couple boards down the test chain.
<zyga> ogra_: well, I kind of did start in linaro and canonical but back then linaro didn't have a nme
<zyga> name*
<ogra_> oh, i remember
 * ogra_ is getting old 
<zyga> jkridner: I think if you are serious about it you should just get a controllable power strip and focus on the hard bits
<Chipaca> hmm, ssh doesn't let me in in rolling/edge #80
<plars> jkridner: what are you trying to do exactly? I'm trying to sort through the backscroll. Right now I have a modified uboot on my emmc to use the gpio connected to s2 to boot from the right place. The default gave me some funny behavior where if you pressed s2 it would load uboot from the sd card, and boot the image on emmc, with s2 unpressed it would load
<plars> uboot from emmc and boot the image on the sd
<plars> zyga: but for snappy purposes, it looks like we may soon have a WAY easier solution to all this, that works even if you don't have emmc
<jkridner> rcn-ee: ugh, I just realized 5/1 is a 4GB image. :(
<zyga> plars: oh, tell me?
<zyga> plars: a-b?
<zyga> plars: or something else
<plars> zyga: right, I was discussing earlier
<plars> zyga: a-b-c actually
<zyga> plars: but for
<zyga> oooooh
<zyga> yes
<zyga>  yes
<zyga> I see this
<plars> zyga: with c being recovery
<zyga> well
<jkridner> zyga: why shouldn't I try to find something cheaper?
<zyga> abc is just master
<plars> zyga: http://blog.sergiusens.org/posts/Snappy_rolling_back_on_kernel_panic/
<zyga> proper
<rcn-ee> jkridner, i'm setting up a 2gb image right now. ;)
<zyga> jkridner: it's not expensive and your time is probably always more expensive
<plars> zyga: right, done officially rather than hacking around it and screwing with the images like we had to do in linaro
<rcn-ee> jkridner, flasher is here: https://rcn-ee.com/rootfs/bb.org/testing/2015-06-17/lxqt-2gb/BBB-eMMC-flasher-debian-8.1-lxqt-2gb-armhf-2015-06-17-2gb.img.xz
<zyga> plars: I wrote about something like this
<zyga> plars: let me find a link
<zyga> (for snappy actually)
<zyga> a few months back
<plars> zyga: istr at the time telling people it wasn't so crack as they wanted to think - it's what android does too really
<jkridner> rcn-ee: downloading.
<jkridner> 4.1?
<rcn-ee> yeap! ;)
<jkridner> sweet.
<zyga> plars: do you know when it will be ready
 * zyga looks for the link
<plars> zyga: no, sergiusens has a proposal but I don't think it's actually been reviewed/approved yet
<elopio> Chipaca: let me know if you figure out the ssh in rolling edge. It works from my laptop, but doesn't from my desktop.
<plars> writeup of the proposal, not a merge proposal :)
<Chipaca> elopio: you broke it!
<Chipaca> elopio: personally, i think it's a sign from olympus that i should go get dinner moving
<sergiusens> plars: so ricmm owns the solution, I just had a proposal to make thing look a lot simpler from a builders perspective
<elopio> some things are broken on my laptop, some things are broken on my desktop.
<ogra_> so you just painted it over ?
<elopio> why can't they just break equally, so I can go to sleep?
<sergiusens> elopio: siesta time?
<elopio> sergiusens: no, too early.
<sergiusens> lol
<zyga> sergiusens: is the solution any different from what plars talked about?
<rcn-ee> jkridner, pushed, so the x15 is now set for 2gb/jessie/v4.1.x *.img builds ;)
<zyga> gaah
<zyga> how do I find a bug
<zyga> that I commented on
<zyga> a while ago
<sergiusens> elopio: I have my siesta when Europe has dinner; but that was when I was the only team member in the americas
<zyga> not on checkbox
<zyga> probably system-image-server
<zyga> google
<zyga> damn you
<sergiusens> zyga: I can't even find bugs by title sometimes
<ogra_> geez ...
<sergiusens> zyga: it's like commenting into the void
<ogra_> go to your own LP page
<sergiusens> or irc... :-P
<ogra_> click on bugs ...
<ogra_> and then invest 2h
<sergiusens> ogra_: bugs you commented on?
<zyga> hahahaaha
<zyga> ogra_: I've been there
<sergiusens> or created?
<zyga> ogra_: 2 of 276 pages
<zyga> right
<ogra_> sergiusens, yes
<elopio> sergiusens: I have my siesta after lunch, which should be in an hour.
<elopio> but I might have to change my schedule, it feels lonely to work here during my night. I miss veebers.
<plars> elopio: what's up with ssh? it's not just the /etc/ssh/sshd_not_to_be_run thing right?
<plars> Chipaca: ^
<sergiusens> elopio: lol; yeah, rsalveti always wondered why I started to wake up earlier, he's doing the same now :-P
<roadmr> zyga: https://bugs.launchpad.net/~zyga/+commentedbugs and then click on "date last updated" to see more recent updates first?
<sergiusens> plars: if cloud init runs and ssh: on is not set in meta-data you get that file
<sergiusens> fyi
<sergiusens> ogra_: Chipaca simple MP https://code.launchpad.net/~sergiusens/goget-ubuntu-touch/warnDevice/+merge/262369
<zyga> roadmr: I'm there now, I just also added some advanced options to show closed bugs
<roadmr> zyga: awesome :)
<zyga> I only wish I could _not_ see checkbox bugs
<sergiusens> zyga: please, I want out of that team, it's too verbose :-P
<ogra_> sergiusens, approved
<zyga> sergiusens: do you get checkbox email traffic?
<zyga> found it
<zyga> https://bugs.launchpad.net/ubuntu-system-image/+bug/1371703/comments/4
<ubottu> Ubuntu bug 1371703 in Ubuntu system image "No fallback if the system update process fails at any point" [Wishlist,Triaged]
<zyga> plars: ^^
<rcn-ee> jkridner, can we glue s2 down? or short a pin to always force s2, (for BBBlfs)
<zyga> rcn-ee: yes
<roadmr> sergiusens: next time you get a checkbox bug, check the headers and let us know the x-launchpad-rationale, we can figure out why you get it and if you can be spared (assuming you really don't want it :)
<zyga> roadmr: x-launchpad-rationale: it's a bug
<roadmr> x-launchpad-message-rationale zyga haah but yes it'll tell us why he is getting notifs for checkbox bugs. Is he in the checkbox team? he may want out. Is he part of a subteam? he may be in trouble :)
<sergiusens> roadmr: I think zyga added me to the team
 * sergiusens checks
<zyga> sergiusens: I stopped reading most email because of the insane volume of email this generates
<plars> rcn-ee: jkridner: I just use a jumper (or relay if I want control) from the lcd_data02 gpio to gnd
<zyga> plars: what's the current that this sinks?
<rcn-ee> thanks plars, i'm shoving a jumper in it..
<jkridner> rcn-ee: like plars said, I think we can tie something else on the board....
 * zyga should move his @ss and check
<jkridner> but....
<zyga> plars: do you think that a small resistor would be safer there?
<jkridner> if we just corrupt the image, we should get a USB boot attempt, I believe.
<zyga> jkridner: usb and serial boot always take priority
<zyga> jkridner: the boot order is AFAIR serial -> usb -> emmc -> sd
 * jkridner would need to look at the boot order.
<zyga> jkridner: with s2 pressed it is  serial -> usb -> sd -> emmc
<jkridner> oh!
<jkridner> nice.
<zyga> jkridner: the reference manual is huge so I cannot check unless I remember how I found that
 * jkridner wonders if bbblfs will catch the USB boot in time.
<rcn-ee> weird, i was just referencing bbblfs readme.. ;)
<rcn-ee> adding bbblfs to the default build too...
<zyga> jkridner: no, I think you need to have something more automated to do that
<zyga> jkridner: you have very little time to do the serial boot handshake
 * jkridner is dealing with stupid uSD adapter not working on laptop. :(
<jkridner> zyga: we are doing USB.
<zyga> jkridner: usb is just serial protocol over usb really
<jkridner> zyga: not true.
<jkridner> zyga: it uses RNDIS.
<jkridner> it shouldn't, but it does.
<jkridner> it was a silly design decision.
<zyga> jkridner: hmm, I'm pretty sure that the usb boot protocol sends a few magic packets
<jkridner> it is essentially TFTP over RNDIS.
<zyga> jkridner: and later on you do anything from the payload you copied over
<jkridner> zyga: if it does, then it'd be breaking RNDIS, but I guess that is possible.
<zyga> jkridner: the low level stuff is probably identical to the serial boot
<zyga> jkridner: at least it was on panda
<jkridner> either way, agreed something has to happen fast.
<zyga> jkridner: AFAIR
<jkridner> zyga: this is a different bootloader. :(
<zyga> (at least TI pulled out of APs so that won't be a problem :P)
<zyga> I would worry about all the allwiner, mediatek and whatever boards
<jkridner> k, my dd has finally started.
<rcn-ee> jkridner, bmap! ;)
<rcn-ee> real	2m23.500s
<zyga> plars: I think we need to stay on top of this
<zyga> plars: the a-b-r model is perfect for our needs
<zyga> plars: for certification and automation
<zyga> plars: and we should mandate that
<zyga> plars: and get it into stone
 * jkridner wishes http://www.amazon.com/Mikrotik-5VUSB-power-injector-USB/dp/B00D84L5IQ would cut power when USB power was cut.
<plars> zyga: indeed, I just learned about it after asking if it was a possibility this morning. I'm hoping that sergiusens will keep me in the loop :)
<zyga> plars: I think he mentioned that ...
<zyga> someone
<zyga> I cannot find it now
<zyga> http://linux-sunxi.org/FEL/USBBoot
<zyga> allwinner is good for remote booting
<jkridner> rcn-ee, zyga: here's what I want: http://www.eeweb.com/blog/extreme_circuits/usb-power-injector-for-external-hard-drives
<jkridner> hmmm... http://www.altronics.com.au/p/k2910-usb-power-injector-kit/
<plars> jkridner: these shut down the port completely when you remove the external power source?
<jkridner> they shut off power to the port when the upstream power goes away.
<jkridner> this way, I can inject one of these every 2-3 boards when power starts to run low and still use BeagleBone's ability to cut power to the USB port to control power to the downstream board.
<jkridner> this makes it easy for people to reproduce the test setup in a one-off condition, without buying any special hardware....
<jkridner> and still allows me to scale up to as many boards as I want to test.
<plars> oh, so you are chaining these together?
<jkridner> yes.
<plars> interesting
<jkridner> i have about 40-50 capes to test.
<jkridner> so, I will use a BeagleBone-per-cape.
<plars> but what does chaining them together do for you?
<jkridner> I really don't want to get a whole mess of expensive power switches.
<plars> ah, I see
<jkridner> saves me on Ethernet cables, switches, etc.
<plars> but if you have problems with an upstream one, that risks taking down everything downstream from it right?
<jkridner> yeah, first failure brings down the rest of the chain.
<jkridner> so, we'll only know about the first failure...
 * plars suddenly has flashbacks of christmas lights
<jkridner> then have to fix it before we can test down the line.
<jkridner> but, we'll know exactly where the failure is.
<plars> true
<jkridner> rcn-ee: I'll switch back over to #beagle for more follow-up. Was just thinking for a second there might have been some overlap in what zyga was asking.
<stgraber> jdstrand: so say I wanted to make the lxd snap official with the next LXD release (on Tuesday), what would you need from a security point of view to make it acceptable for the store?
<stgraber> jdstrand: I can't really give you any seccomp filtering since we need to be able to set our own (and in fact do by default). But I can do something similar to the lxc-start profile and so restrict the lxd process itself.
<stgraber> jdstrand: with the understanding that this profile does allow change_profile, so it's of limited value
<stgraber> jdstrand: I'd also need to know how to ship extra apparmor profiles as we'll need the usual set of LXC profiles and abstractions in there (currently my hack is to run everything unconfined in userns only, but I'd like to have apparmor support there if possible)
<jdstrand> stgraber: I don't think there is anything we can really do for confining lxd itself-- it needs the permissions it needs. however, are you shipping framework-policy for apps to consume?
<jdstrand> stgraber: that said, what we did for docker is have a quite lenient policy that I will say 'encourages' honoring the snappy fhs. ie, normal usage under the profile wouldn't allow writing into app directories
<jdstrand> stgraber: abviously, 'encourages' because with change_profile, you can hop out of confinement
<jdstrand> stgraber: is lxd creating/using apparmor profiles that are named a particular way? eg, we can limit what lxd can change_profile to (but, since these are system containers, that policy is going to be wide open anyway), but it would encourage that it is doing the right thing
<stgraber> jdstrand: so we usually ship profiles named lxc-* and that's what we allow in the lxc-start profile
<stgraber> jdstrand: however we also do allow unconfined
<stgraber> jdstrand: so in effect you can switch to whatever profile you want, or none at all
<jdstrand> alright, so bare change_profile
<jdstrand> stgraber: what about framework-policy?
<jdstrand> are you shipping policy for apps that depend on your framework to consume?
<stgraber> jdstrand: not at this point, but we probably should. The only thing we'd have to allow is communication with our unix socket.
<jdstrand> so, for tuesday, ok good
<jdstrand> stgraber: however, is that unix socket give you full range over lxd? ie, can it handle untrasted, malicious apps?
<jdstrand> untrusted*
<jdstrand> ie, are you assuming the process connecting to it is trusted?
<jdstrand> (eg, an admin on the system)
<stgraber> yeah, so I'm not sure about that part yet, we may want to only let apps talk to the tcp socket and not allow communication with the unix socket except for the local shell itself
<stgraber> because indeed, having access to the unix socket, lets you reasonably easily escalate to root
<stgraber> as you can create containers, execute command in them, change their configuration (including apparmor profile, bind-mounts and turn off userns)
<jdstrand> right
<stgraber> over the tcp socket, you have to be trusted by using a ssl client certificate which the user has to add to LXD (or provide the client with a password so they can do it themselves)
<jdstrand> stgraber: what you expose in framework-policy needs to prevent that. right now, docker is doing that wrong and it needs to be fixed
<stgraber> ok, so specifically deny all access to the framework path and data path in the profile?
<jdstrand> it sounds like the tcp socket allows everything if the cert verifies?
<stgraber> right, protocol is identical but the tcp socket requires SSL auth
<jdstrand> stgraber: well, today, you don't have to do anything. apps are already blocked from your socket
<jdstrand> stgraber: it is just that when you want to say something like 'We should allow app-store apps to add a container' that things get interesting
<stgraber> ok, so not even providing a framework policy would be fine for now
<jdstrand> you would probably want a reduced api or something. ie, don't want to allow a malicious app to escalate via lxd
<jdstrand> stgraber: yes, exactly
<stgraber> we define tcp/8443 as an external port, so presumably apps can talk to this already if they want to and if they have been specifically allowed by the local administrator
<jdstrand> stgraber: right, that would all work
<jdstrand> and that is fine
<stgraber> ok, I think the only question I still have is how do I ship additional raw apparmor profiles
<jdstrand> I'm talking about the cool integration stuff people will want to do
<jdstrand> like, I'm going to upload this 'app' to the store that will talk to lxd to create a container for me and run stuff
<jdstrand> for now, everything is fine
<jdstrand> to support that use case, then need to have something that can deal with untrusted users
<jdstrand> users, apps, etc, etc
<stgraber> so I expect the initial use case to be people using snappy+lxd as a sort of compute node, so install lxd on it, then drive it remotely, using regular LXD images from a LXD image store.
<jdstrand> but, thumbs up for no framework-policy and uploading on tuesday
<stgraber> jdstrand: ok and how do I ship and get apparmor to load, extra apparmor profiles? Do I need to call apparmor_parser and the usual stuff manually from my startup script?
<jdstrand> stgraber: yes
<jdstrand> let me get you a link to the docker policy
<stgraber> ok
<jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/docker/files/head:/package-dir/meta/
<jdstrand> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/docker/view/head:/package-dir/meta/docker-daemon.apparmor
<jdstrand> line 109 should give you a head start
<jdstrand> oh but you are unconfined
<jdstrand> yeah, you are probably fine. if you go the 'encourage fhs' route, see that ^
<stgraber> ok, will look at those, thanks!
<jdstrand> np :)
<stgraber> I vaguely remember running into troubles manually loading our apparmor profiles in the past, but I'll bug you when I get the error message again :)
<barry> mvo: whenever you see this, si 3.0.1 is landing in wily right now
<jjohansen> stgraber: it could be that for manual load you need to make sure its a single atomic write
<Chipaca> plars: about ssh, i see a sshd running so i presume not
<sergiusens> plars: Chipaca check if the host keys were generated
<Chipaca> sergiusens: yes, they're there
<Chipaca> sergiusens: this was after an upgrade, so i would've hoped so anyway :)
<bschaefer> hello, so has there been any work or issues someone has ran into getting a session dbus daemon setup?
<tedg> bschaefer, That's not really as much a snappy thing as something that would be implemented by a framework on top. Like Unity8.
<tedg> bschaefer, So that's probably handled in the Ubuntu Personal image that is being worked on.
<bschaefer> but in a sense we want a bare bone system that runs qml/sdk apps... we'll need a dbus session for that
<rsalveti> elopio: yeah, I'm waking up at 6am now (done for 4 days already, big win)
<tedg> bschaefer, I'm not sure what state it is in, but it should get to the point of a desktop, which needs a session manager.
<bschaefer> tedg, right... is there a simple way to hack a session dbus daemon to start up :)?
<tedg> bschaefer, That's a different problem. If it is dependent on system services (i.e. dbus services) it'll need to those to exist in frameworks.
<rsalveti> sergiusens: plars: we're going to discuss next week (iom sprint) about the factory image/reset and so on
<rsalveti> check the requirements and such we have from other projects, and then try to identify the path we want to take
<bschaefer> tedg, i see, yeah that'll have to be looked at...
<plars> rsalveti: awesome!
<rsalveti> then we can just implement it :-)
<bregma> bschaefer, Snappy Personal is using LightDM right now, so it works like the regular desktop in that respect
<tedg> bschaefer, So I think that your best bet is to use the personal image today. It should do that for you.
<bschaefer> tedg, bregma sweet, thanks! Ill have to find this personal image...
<bregma> tedg, we can't use the personal image, that's the whole point
<bschaefer> but this will be an issue on arhmf
<tedg> bregma, Why not?
<bregma> bschaefer, shouldn;t be (any more of) a problem on armhf
<bschaefer> bregma, true...i suppose the main issue being getting a bare bone system to run what we need
<bschaefer> would be more of the issue here vs a full fledge desktop
<bregma> tedg, because we're trying to raise the red-headed bastard stepchild of Snappy Core and Snappy Personal
<tedg> bregma, I'm confused, who let them date?
<bregma> they kept digging a hole under the fence
<tedg> bregma, So what are you trying to build, I'm confused. A snappy core that installs an app that runs in the session?
<bregma> tedg, pretty much: a Snappy Core that runs a dedicated GUI-based app, probably in a session because root, well, because root
<bregma> no Unity 8, no general-purpose user shell
<olli> mterry_, are you around
<bschaefer> nothing, just mir + sdk + qml/qt app
<mterry_> olli, sure am
<tedg> bregma, So I think that kgunn has an app that does that
<bschaefer> tedg, its missing the SDK
<tedg> I don't think it's running the sdk parts though.
<bschaefer> (which requires the session dbus i guess)
<bschaefer> yeah
<tedg> Yes, the SDK won't really work without the services that it needs behind it.
<bschaefer> thats what im working on :)
<bregma> tedg, kgunn has a team putting it together.....
<olli> mterry_, gto a couple of qmlscene questions/issues, want to do here or in /query?
<tedg> So either you have those services (Ubuntu Personal) or you don't (Ubuntu Core)
<mterry_> olli, either works
<mterry_> olli, there's already a convo here
<tedg> I mean if you just want it to error and say "services not found" you could just use dbus-test-runner
<bregma> we'll shut up
<bschaefer> tedg, i mean...there has to be a way to run a dbus session...or figure out if the SDK *needs* it
 * bschaefer be quites
<tedg> And that'll wrap it in a session bus, it just won't have the services to make things work.
<bschaefer> tedg, cool ill try the test runner...no clue how it works but something will happen :)
<bschaefer> thanks!
<olli> mterry_, gathering some information, brt
<olli> wasn't there a pastebinit on the core image?
<tedg> bschaefer, I think it comes down to your desired behavior, if you just want a dummy session bus that's easy. If you need all the services, I think you'll want Ubuntu Personal.
<bschaefer> im not sure what the services are
<bschaefer> like...talking with unity8? Then i dont need them
<bschaefer> or if its talking with the net, then ill need it
<tedg> bschaefer, Yes, all the trusted services that are part of a standard unity8 session. Content hub, URL dispatcher, etc, etc
 * bschaefer isn't 100% sure what dbus is used for in unity8/sdk
<bschaefer> URL dispatcher could be an issue for say, weather
<bschaefer> if thats what i think the url dispatcher does... the weather app will fail
<tedg> bschaefer, Those features are built into the SDK, so when the SDK has a feature to say "share" it knows how to talk to content hub.
<bschaefer> tedg, but requires dbus :) (to work)
<tedg> bschaefer, It's just "requires dbus" it is "requires content hub and dbus and configuration" basically "requires a Unity 8 user session".
<tedg> DBus is the easiest part of that
<bschaefer> tedg, sooo the weather app does not expect to work outside of a unity8 session?
<bschaefer> unless a dbus/content hub are all configured correctly?
<tedg> bschaefer, I would say no, but it might work for some cases.
<bschaefer> out side of the session?
<tedg> The SDK is designed to work in a Unity8 session.
<bschaefer> tedg, well that'll be the fun part i suppose :)
<tedg> Doesn't mean you couldn't use some of the widgets successfully. But it's going to be touch-and-go.
<bschaefer> right
<tedg> bschaefer, So if you need a Unity8 session, that's what Ubuntu Personal is.
<bschaefer> we could attempt to make a new content hub wrapper..
 * bregma doesn't like the phrase "touch and go" it sounds like it needs gesture recognition first
<bschaefer> tedg, ... well i dont think we *can*
<bschaefer> if we want a bare bone kiosk system image
<bschaefer> we dont want a unity8 shell session
<tedg> You still want to swap out Unity8 for another Mir Server.
<tedg> I guess you could use the system compositor.
<tedg> But you'll need to avoid the widgets in the SDK that do integration stuff.
<tedg> So a "standard app" won't work. That doesn't mean a custom app won't work.
<bschaefer> so the system compositor would start up the session but wont do anything kind of unity8 stuff
<tedg> No, the system compositor doesn't start a session.
<bschaefer> it just starts the server?
<tedg> Yes, it just provides a socket that gets routed to HW.
<bschaefer> tedg, soo we'll need to figure out what parts of the SDK are off limits
<bschaefer> in a sense...
<bschaefer> but guessing that a button depends on dbus ... i would assume almost all of the SDK depends on it
<tedg> Yeah, you should be fine with buttons and the such, but "smarter" widgets will fail.
<tedg> The base application class tries to init dbus.
<tedg> So for that you can just do a dbus-test-runner wrap
<bschaefer> right cool, ill give that try for now
<tedg> It'll init and be happy.
<bschaefer> soo pretty much a clock should work
<bschaefer> tedg, awesome thanks for all the info! (was missing a pretty bug chunk there)
<tedg> Maybe, it sets alarms and such in EDS
<tedg> So not the standard clock we ship, but a custom clock would.
<bschaefer> hmm
<bregma> bschaefer, were you using the Mir demo server?
<bschaefer> this will have to be discussed a bit more
<bschaefer> bregma, yeah
<bregma> ah
<bschaefer> bregma, but i have dbus session on my main machine
<bschaefer> (which still works
<bschaefer> )
<bschaefer> on the snappy image the mir demo server fails with the SDK
<tedg> Basically if it is an app that we ship on the phone, it probably uses session services as we've fleshed a bunch of those out with those apps :-)
<bregma> yeah, there is no argument we'll need a session D-Bus
<bschaefer> yeah
<bschaefer> some how...
<bregma> and all the fun frameworks like content hub
<bschaefer> yeah :(
<tedg> Do you need content hub?
<bregma> tedg, content hub is magically going to appear as a snappy framework
<tedg> I mean, it is a pretty advanced interaction.
<tedg> bregma, Not anytime soon. 1+ years atleast.
<bregma> so if an application snap needs it, it will just add it in its manifest
<bregma> and it will all just work
<tedg> It's unclear whether content-hub will be it's own framework or we'll just have a mega-Unity8 framework.
 * bregma is waving his hands in a "not my job" fashion
<bschaefer> haha
<tedg> (which would include content-hub)
<bregma> we'll worry about niceties like content hub if and when we get paid to worry about that
 * tedg saves his loonies
<bregma> right now I just need to turn my BBB or Raspi2 into a clock so I can tell the time
<kgunn> improvement from paperweight
 * bregma needs a nixie tube driver for the BBB
<bschaefer> haha
<bschaefer> how easy is it to get chrome working on mir?
<bschaefer> pretty easy? Try to get netflix working haha...
<tedg> Mir â XMir â Chrome
<bschaefer> haha, i thought racarr had chrome working directly on mir
<bschaefer> maybe that was a long time ago
<rickspencer3> Chipaca, https://code.launchpad.net/go-service-template
<rickspencer3> ParseDuration turned out to be really useful
<rickspencer3> thanks for your help earlier
<kgunn> bschaefer: that was ozone-mir, and yeah you could get chrome on mir, chad miller took that over, i know it requires active updates
<kgunn> bschaefer: i'm pretty sure willcooke mentioned it was being actively worked too
<bschaefer> kgunn, would be interesting to see that on a beaglebone or a raspi
<bschaefer> with netflix
<kgunn> :)
<bschaefer> kgunn, thats just my out side of work want atm haha
<olli> not sure if the drm blob is available on arm
<bschaefer> :( yeah
<olli> kgunn, may I distract you
<kgunn> olli: yo
<olli> kgunn, nevermind for now
<olli> mterry_, ^
<mterry_> olli, hah
<mterry_> olli, what was the question?
<olli> where to export the mir socket env var
<mterry_> olli, --mir does that for you
<mterry_> olli, did you export LC_ALL=C.UTF-8?
<olli> mterry_, I did
<mterry_> olli, you will get a socket error if you don't
<mterry_> oh huh
<mterry_> olli, in your bin/digitalsign that deb2snap put in for you, do you see a mir-run script being used?
<mterry_> It should be inserted on your behalf
<olli> yep, it's there
<Chipaca> rickspencer3: what editor do you use?
<olli> kgunn, I got mir running as a process but no socket in /run
<olli> from a mir snap that I created from your blog
<olli> any thoughts?
<kgunn> olli: you're lauching with the "server" script
<kgunn> ?
<kgunn> olli: you see the black mouse cursor  in the vm ?
<olli> kgunn, actually I don't
<olli> I have not actively started mir in the vm
<olli> I used deb2snap --mir
<kgunn> olli: so you didn't build through make ? but did the deb2snap command line ?
<olli> kgunn, I built mir.snap as per your blog
<olli> kgunn, upon reboot, I have the process running but no socket
<kgunn> olli: ok, so you branched lp:~mir-team/mir/snappy-packaging and did make
<kgunn> olli: what's the process name running ?
<olli> 721 ?        Ss     0:00 /bin/sh /apps/mir/snap1/bin/server.real
<kgunn> olli: ok, that's just the script trying to launch it
<olli> got a "good" mir.snap lying around?
<kgunn> actually :)
<kgunn> olli: this should be good
<kgunn> https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFeHVxN0t5UFpua3c/view?usp=sharing
<kgunn> olli:  just curious when did you pull and update that branch ?
<olli> ~Mo
<olli> maybe Tue
<olli> kgunn, with your snap I see the same process running
<kgunn> ok...there was a moment where i had it confined....
<olli> and ... with your .snap I also don't have a /run/*mir* socket
<kgunn> olli: what bzr commit are you on ?
<kgunn> ok...lemme replicate
<olli> I am on your .snap
 * kgunn can almost do it in sleep
<olli> :)
<olli> kgunn, do I need to start the vm differently?
<kgunn> olli: did you get any erros when you installed VMM and loaded a vm into it?
<kgunn> i do recall getting an odd error, reboot fixed it
<kgunn> upon installing VMM and first use
<olli> hah
<olli> I was using kvm cli
<kgunn> olli: ah, yeah, VMM has some gfx voodoo in it
<kgunn> vmware also has nice gfx voodoo i believe
<olli> yeah
<olli> betcha there is no GFX card in my vm ;)
<olli> face.palm
 * kgunn halts replicant effort
<kgunn> and changes dirtied britches
<olli> at least we ahve established a POC of gg drive as archive replacement
<kgunn> lol
<kgunn> olli: call it "kg's store"
<olli> beuno, ^
<beuno> free store for kgunn?
<olli> kgunn, and now we are in business
<olli> mterry_, ^
<mterry_> olli, yay
<mterry_> olli, you see a pretty qml app now?
<olli> I see mir
<olli> babysteps
<olli> mterry_, close
<olli> I see a lot of qt modules I am missing
<olli> mterry_, I guess that's some additional -p magic for deb2snap
<olli> i.e. install/bundle the modules via -p $Mymodule
 * olli wanders off for today
<olli> will play with it tonight
<olli> think I can figure it from here
<olli> thx guys!
<rickspencer3> Chipaca, gedit
<Chipaca> ah
<Chipaca> mterry_: you didn't find a good gofmt plugin for gedit in the end?
<mterry_> olli, oh yeah, deb2snap doesn't know enough to search your qml files for imports and match them up to debs
<mterry_> olli, that would be magic!
<mterry_> Chipaca, oh naw didn't try super hard, but no I didn't
<Chipaca> k
<Chipaca> rickspencer3: you know 'gofmt'?
<rickspencer3> Chipaca, nope
<sergiusens> gofmt is THE thing!
<Chipaca> rickspencer3: check you've got it in your path
<rickspencer3> cool
<Chipaca> rickspencer3: and then, in the source tree, find -type f -name \*.go -print0 | xargs -0 gofmt -w
<Chipaca> rickspencer3: and look at the resulting diff
<rickspencer3> Chipaca, ok, I'll check it out tomorrow
<rickspencer3> trying to eod here :)
<Chipaca> fair :)
<rickspencer3> Chipaca, thanks for the tips, though
<rickspencer3> Chipaca, what did you think of my code?
<rickspencer3> other than the formatting?
<Chipaca> only looked at main.go
<Chipaca> not bad though
#snappy 2015-06-19
<dholbach> good morning
<fgimenez> good morning
<elopio> hey fgimenez: I think I've tried it all to get this working: https://code.launchpad.net/~elopio/snappy/go-tests5/+merge/262418
<elopio> no luck.
<fgimenez> elopio, hey still around? np, i'll take a look
<fgimenez> elopio, the first time i tried i was getting http://paste.ubuntu.com/11739031/ did you get something like that?
<fgimenez> elopio, i'll merge your changes and we can work from there
<elopio> fgimenez: yes, I can't sleep when I get stuck.
<elopio> and yes, that's what I get when I try to sbuild.
<fgimenez> elopio, nw, i'll give it another try, go and get some sleep! :)
<JamesTait> Good morning all; happy Friday, and happy Sauntering Day! ð
 * Chipaca saunters off to get coffee
<elopio> fgimenez: yes, I'm going to sleep now.
<elopio> I got adt-run working on my beagle. The tests don't pass, but they run.
<fgimenez> elopio, awesome!! thx a lot, we'll talk later
 * Chipaca now in wily \o/
<ogra_> crazy
<mvo> Chipaca: yay!
<mvo> Chipaca: its much more fun this way, isn't it :-D
<Chipaca> well, awesome changed its configuration in incompatible ways (new lua, i guess), so that was fun
<Chipaca> but at least it wasn't xmonad :)
<Chipaca> ogra_: not at all crazy; if i didn't do this, how could i be condescending to people running old software?
<Chipaca> in bad faith, that's how
<ogra_> lol
<zyga> hmm
<zyga> so how does snappy work
<zyga> how do you build the os snap
<zyga> is it based on debootstrap
<zyga> followed by rm -rf /var/lib/dpkg
<zyga> or is it something entirely different
<ogra_> live-build builds it
<zyga> I'm trying to understand if contributions to ubuntu archive have an impact on spappy
<ogra_> based on config and extra scripts that live in livecd-rootfs
<zyga> ahh
<zyga> offspring lives forever, it seems ;-)
<zyga> is that stable or constantly evolving?
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<zyga> like the scripts that do magic after the base packages are installed
<ogra_> no, luckily it isnt offspring or anyhow related
<ogra_> sadly though to make parts of it offspring compatible we had to re-write the whole infra around it in python ... since then it got really hard to maintain
 * ogra_ is still grumpy about that after years ... makes life so much harder ... 
<zyga> ogra_: is there a high-level description of what goes into the os snap?
 * ogra_ shakes his fist at cody-sommerville in absence
<zyga> ogra_: (what was it written in originally?)
<zyga> ;D
 * zyga still has that memory of cody 
<zyga> driking only after you are 21 and all that ;-)
<zyga> fun days
<ogra_> yeah, he was nagfging about the re-write for two years or so ... then the rewrite itself took about 6 months ... and just as it was done he left !
<zyga> ogra_: I'm trying to picture this against debootstrap
<ogra_> live-build uses debootstrap
<zyga> ogra_: to understand where my assumptions are wrong, etc,
<ogra_> for the initial chroot ...
<zyga> ogra_: is there any input to the whole process other then the packages?
<ogra_> and then installs/removes and modifys packages as needed
<zyga> "modifies"?
<ogra_> yes, there are chroot hooks that get run
<ogra_> sure
<ogra_> (it doesnt modify anything for the deb based images indeed, only for stuff that doesnt use dpkg at the enduser)
<zyga> ogra_: thanks
<zyga> ogra_: so the os snap is a preinstalled chroot
<zyga> ogra_: with some cherries on top
<Chipaca> zyga: also keep in mind the split between os, kernel and device snap
<Chipaca> so not the whole chroot
<ogra_> zyga, apt-get source livecd-rootfs ... live-build/auto/build and live-build/auto/config have the generic build parts ... live-build/ubuntu-core/hooks has the extra scripts
<mvo> for some value of "generic"
<mvo> (SCNR)
 * Chipaca always thinks of french trains when he reads SCNR
<ogra_> zyga, and built in a special way (i think we use --buildd-minimal or some such for deboostrap, the apt policy doesnt install recommends and so on)
<zyga> Chipaca: s/device/gadget/ right
<Chipaca> zyga: yes indeed
<zyga> right
 * ogra_ wonders if bug 1466672 isnt actually a feature :)
<ubottu> bug 1466672 in Snappy "webdm failed to start / Failed to listen 224.0.0.251:5353" [Undecided,New] https://launchpad.net/bugs/1466672
<ogra_> though i guess it should print some meaningful error message in the log
<ogra_> "cant run network service with no network attached" or some such
<zyga> ogra_: hmm, why should webm not start?
<ogra_> zyga, it runs an avahi daemon ... what should that attach to with no network up ?
<zyga> ogra_: nothing, but then the avahi daemon will attach to each network as it shows up
<zyga> ogra_: one of the bad things about many linux gizmos is that they misbehave if you boot without network and plug network later
<ogra_> yep
<mvo> Chipaca: quick brainstorm - what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here?
<olli> snap masters, do we have some documentation how to "debug" in snappy... tools but also "strategies", i.e. how to check whether it's an app vs system issue etc
<mvo> olli: unfortunately not, its complicated by the fact that we do not have snaps for many of the useful tools (like strace) :/ - do you have a specific example where you need debugging help? maybe that could be the start of such a doc :)
<olli> mvo, mterry & kgunn were holding my hand when creating a qmlscene snap
<olli> got issues loading a lib at runtime
<olli> which is there, suppose the preloader doesn't catch it
<mvo> olli: anything in the usual places (dmesg, syslog) - might be somethin with appamror/seccomp
<olli> alrighty
<olli> mvo, are there any existing pointers / docs how to deal with confinement issues, i.e. I see a apparmor denial, what's next?
<mvo> olli: could you pastebinit
<mvo> olli: maybe jdstrand has pointeres to the security wiki
<ogra_> olli, syslog is your best bet
<olli> ogra_, I see the issue, just don't know what to do with it ;)
<olli> mvo,  http://paste.ubuntu.com/11739849/
<ogra_> olli, you could indee dship things like strace and such in a special version of your snap ... i.e. $app-debug.snap ... so that you could have these tools apply to the startup wrappers
<olli> that's the runtime err
<olli> and that's dmesg | tail -n 10 http://paste.ubuntu.com/11739855/
<ogra_> olli, well, your app should ship its own /usr/share/applications ... or wait until that setup can be provided by some framework
<ogra_> (wrt the DENIED messages there)
<olli> ogra_, don't even know what it's trying to access there
<olli> what's the best strategy to figure out what it's trying to access so I can bundle that stuff?
<ogra_> well, you likely want to look at the code of your app then :)
<ogra_> it might just want to read the .desktop file
<ogra_> (which usually live in that dir)
<olli> you are suggesting I read all of Qt?
<Chipaca> mvo: i'm afraid i didn't pay too much attention, but (or because) sergio did :)
<ogra_> all of qmlscene code i guess
<sergiusens> Chipaca: what did I do again?
<Chipaca> should kvm be bringing up an eth0?
<Chipaca> sergiusens: what additional meta/meta.yaml do we need that is not part of the package.yaml. I have "origin" (mvo, sideloaded) on my list right now, what else will we want to store here?
<mvo> Chipaca: I had this problem with latest wily too, no eth0
<Chipaca> sergiusens: ^^ that was mvo asking, earlier today
<mvo> Chipaca: rollback to a previous version worked
<sergiusens> Chipaca: part of meta/package.yaml?
<mvo> Chipaca, sergiusens: maybe its not relevant anymore my question, I'm drafting the FHS
<Chipaca> sergiusens: i think he's asking about _$version
 * Chipaca translates
<sergiusens> mvo: if Chipaca's idea flies wrt dynamic creation f manifest.yaml from store data we need...
<sergiusens> Chipaca: mvo video and screenshot url (and maybe even the shots), release is rather important (to deal with upgrades), icon downloaded, binary_filesize (which is the download size), developer name, company name, website, price, publish date, download sha
<sergiusens> mvo: Chipaca and reviews would be one of those on demand queries
<sergiusens> download sha is of little sense if we explode the package and expose hashes.yaml
<sergiusens> oh, and changelog
<sergiusens> and one of the bigger things coming our way, the translations entry
<mvo> sergiusens: indeed
 * sergiusens feels he just made too much words to just say everything
<sergiusens> mvo: Chipaca I think we will be putting this in _$versions initially and then move over to the dynamically created manifest.yaml
<sergiusens> we can have a hangout to go over it and get the big picture
<sergiusens> I just need to cut off 30' after standup today though and then I'll be back by your bed/beer o clock ;-)
<Chipaca> who's working on translations? i'd like to add my 2Â¢ to that work
<sergiusens> Chipaca: the store already has that option
<Chipaca> on the client
<Chipaca> i don't mind if the store loads all translations in memory
<sergiusens> Chipaca: and then you get a translations entry in the json
<Chipaca> because it's the store :)
<sergiusens> Chipaca: no one is yet
<sergiusens> Chipaca: there's only mvo's branches which I'll look at again now
<seb128> sergiusens, mvo, hey, maybe you know, but how/when is the "cdimage build" to "channel image" conversion done? is that a cron job? or does it trigger when need cdimage build are done?
<sergiusens> seb128: all of Ubuntu's infra is poll based :)
<mvo> seb128: system-image.u.c is doing that, its a cron job that runs every 5min
<sergiusens> that was a snarky smiley
<mvo> seb128: but it can run for a long time
<mvo> seb128: so the 5min is not accurate
<mvo> Chipaca: what specifically do you have in mind? other than adding gettext ? how to requested the languages from the store?
<seb128> mvo, it's like the publisher, 5 minutes if there are not previous job overunning right?
<seb128> sergiusens, mvo, thanks
<ogra_> seb128, see the crontab on nusakan
<sergiusens> seb128: btw, I still get reboot loops with amd64 and i386 just stalls during boot
<ogra_> seb128, last line ...
<sergiusens> seb128: and the personal branch made it to trunk btw
<seb128> ogra_, thanks
<ogra_> (well, the crontab of the cdimage user that is)
<seb128> sergiusens, \o/ for personal to trunk
<Chipaca> mvo: translations of snappy itself i'm less worried about; gettext already uses one-file-per-language and is (or was when i looked at it) fairly smart wrt not using more memory than it had to to hold unused translations
<seb128> sergiusens, amd64 boots since yesterday for me, it just loops on lightdm
<seb128> sergiusens, oh, you need to pick the "ubuntu" entry in grub
<Chipaca> mvo: my fear is if we dump app-side translations into a single json or yaml or what have you, we'll load it all in memory all the time always
<seb128> not the snappy system-a one
<seb128> sergiusens, unsure why there are those different ones
<seb128> sergiusens, I hope that with this morning fixes and the new image build we get lightdm to work
 * ogra_ glares at jonos last blog post ...
<ogra_> ... insane
<ogra_> (he suggests we rebase ubuntu on android)
<sergiusens> seb128: we are working on getting rid of update-grub fwiw and have very fine tuned grub.cfg's
<Chipaca> ogra_: oh no! the person we were taking technical leadership from has lost their mind! what can we do?!?
<Chipaca> ogra_: oh, wait
<ogra_> haha
<ogra_> well, we'd finally get all the great android security !
<ogra_> and their battery life too ...
<Chipaca> and their juicy, juicy init system
<ogra_> oh, yeah !
<sergiusens> Chipaca: I prefer manifest_en-ES.yaml or something like that
<sergiusens> or dir separated
<ogra_> bright the future would be
<mvo> Chipaca: yeah, good point
<ogra_> :)
<sergiusens> whatever makes sense
 * sergiusens wants the init system
<ogra_> uuuh
<sergiusens> and the on disk initrd
<ogra_> thats the only one thing i like in android
<ogra_> (though there is prior art to that in the terminal server area)
<seb128> sergiusens, so for your reboot loop, what grub item do you select?
<sergiusens> seb128: I just let the first one to go and go and go, didn't do any manual selection
<seb128> sergiusens, btw I keep hitting the loop partition error, unsure why, I need to reboot and retry, it works like 1 every 10 tries, same on my 2 machines :-/
<seb128> sergiusens, k, you need to pick "ubuntu" in the list, that's not the top one
<sergiusens> seb128: did you try the losetup -d command?
<seb128> yes
<seb128> but I had deleted the .img when I tried
<seb128> and losetup -d didn't seem to work
<seb128> loop0 was still listing the deleted image
<ogra_> kpartx ;)
<ogra_> and dmsetup ...
<seb128> and users should have to do that
<ogra_> it defaults to a device-manager setup iirc
<seb128> the tools should do it for them if that's needed
<sergiusens> ogra_: yeah dmsetup clear /dev/mapper/loop0p* ; kpartx -ds /dev/loop0; losetup -d /dev/loop0
<ogra_> right
<sergiusens> seb128: the dmsetup and kpartx parts are done
<ogra_> seb128, yeah, it is a bug that the tool does stop before being able to cleanup
<sergiusens> seb128: the losetup isn't, which is why I asked if it helped
 * ogra_ hugs the trap function in shell 
<sergiusens> ogra_: it is being run, if it was mapped, the unmapping always runs
<sergiusens> seb128 try trunk
<ogra_> well, it didnt for me when we had the issue recently
<seb128> sergiusens, k, going to try in a bit
<seb128> sergiusens, but no, losetup didn't help when I tried
<ogra_> i had to use dmsetup each time after the error
<seb128> but typically I used the tools, hit the error, rm-ed the .img
<sergiusens> ogra_: hmm, sometimes dmsetup doesn't work for me either
<seb128> in which point loop0 is blocked on the deleted img and losetup seems to do nothing
<seb128> ogra_, the same invalid partition count loop error?
<sergiusens> ogra_: and I indeed need to reboot and there is no way out of it that I know of
<seb128> k, so I'm not alone in the situation ;-)
<ogra_> for me dmsetup always worked after making sure i loosely unmounted
<seb128> loosely unmounted what?
<seb128> how?
<ogra_> umount -l
<ogra_> (the image)
<seb128> k, I guess my error was to delete the buggy img
<seb128> to run the command again
<seb128> then reboot is needed
<ogra_> ah, yeah, but umount -l should still work, ebven with the image gone
<seb128> I'm going to try next time
<seb128> but why are we hitting those issues in the first place?
<seb128> was is flacky?
<ogra_> (it will just alter mtab and /proc/mounts ... )
<Chipaca> ogra_: you know how the latest wily things aren't bringing up network in kvm?
<Chipaca> ogra_: it's because eth0 is now ens3
<ogra_> Chipaca, nope, havent heard of that
<ogra_> ah, blame pitti !
<Chipaca> yep yep
<Chipaca> i already do
<Chipaca> always
<Chipaca> ogra_: i'm not sure why i pinged you, but i thought maybe you'd have ideas as to how to fix it :)
<Chipaca> the problem is, of course, that we ship an eth0 interfaces file
<Chipaca> when it should be ... something else, i presume
<Chipaca> mvo: the good news is, there's an easy workaround to get your kvm wily image working again wrt network
<Chipaca> elopio: ^ et vous
<ogra_> Chipaca, well, if i knew where that file comes from ...
<Chipaca> sergiusens: /etc/network/interfaces.d/eth0 is written by u-d-f
<Chipaca> ogra_: ^ i mean you
<Chipaca> no way for u-d-f to know the name of the device though
<sergiusens> Chipaca: huh?
<sergiusens> Chipaca: are you not reading code used by the ubuntu-emulator by any chance?
<Chipaca> sergiusens: goget-ubuntu-touch/diskimage/customization.go
<sergiusens> Chipaca: yeah, that's ubuntu-emulator
<Chipaca> ah
<Chipaca> sorry then :)
<Chipaca> where does that eth0 file come from then?
<sergiusens> Chipaca: on a kvm image?
<Chipaca> sergiusens: yes
<ogra_> i would suspect something like ubuntu-core-config
<ogra_> or a systemd unit thats shipped somewhere
<sergiusens> ogra_: Chipaca doesn't look lke ucc http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/ubuntu-core-config/wily/files/head:/etc/
<sergiusens> Chipaca: ogra_ dpkg -S says no one owns it
<mvo> sergiusens, Chipaca: so gdoc looks mostly sane? I'm a bit torn on /data for system data vs /home/system/data
<ogra_> live-build/ubuntu-core/hooks/04-configure_network.chroot
<ogra_> there is is i think
<ogra_> http://paste.ubuntu.com/11740076/
<sergiusens> mvo: I don't like either; it seems /writable/data works better and rids us of a bind mount
 * sergiusens wants to just move all refs to /writable
<mvo> sergiusens: hm, we would still need the bind mount, unless we move /home/* to /writable/user-data/* (which is probably a good idea in itself)
<ogra_> Chipaca, hmm, i fear we need to move that to the boot somehow to detect the actual interface names now
 * Chipaca wonders why /writable isn't /var
<sergiusens> mvo: I don't mind /writable/home either ;-)
<sergiusens> Chipaca: because /var has a lot of read only stuff :-P
<sergiusens> maybe /therealvar works bettwe
<sergiusens> *better even
<Chipaca> sergiusens: it doesn't have that much read only stuff that we don't want to get rid of
<ogra_> Chipaca, hyterical raisins ... on android we have /userdata and needed to use that due to not being able to change partitioning on some devices
<Chipaca> it's 14M, of which 12M is dpkg/info
<mvo> Chipaca: that can be killed, we could do that right now via livecd-rootfs
<ogra_> (and we need to share the writable bits with the android container since many bits need to be accessibe by both OSes)
<Chipaca> anyway, in the sense that /writable is /var without the things that shouldn't be in /var anyway, we wouldn't be the first unix-like people to put homes in var anyway
<ogra_> s/neede/need/
 * ogra_ always has home in var on his servers
<ogra_> since over a decade :)
<sergiusens> Chipaca: ogra_ fwiw, latest images left me without networking on kvm as well
<Chipaca> ogra_: i don't know if that should be seen as encouragement or a sign of trouble
<ogra_> but that wouldnt help the HW requirements android puts upon us on personal
<Chipaca> sergiusens: yes, because of the above
<Chipaca> sergiusens: you do have networking, you just don't know it :-p
<ogra_> or rather the setup reqs. not the HW reqs
<ogra_> we cant change paths of binary blobs
<Chipaca> sudo sed -i -e "s/eth0/$(ls /sys/class/net/ | grep -vx lo | head -n1)/g" /etc/network/interfaces.d/eth0
<Chipaca> sergiusens: ^
<Chipaca> sergiusens: and reboot
<sergiusens> mvo: Chipaca let's do that now (remove /var/lib/dpkg) before more people exploit it and then becomes a req to have
<Chipaca> sergiusens: or restart networking, but reboot is quicker without ocmpletion :-p
<Chipaca> sergiusens: +1.33
<ogra_> sergiusens, yes, we hardcode the interface name in livecd-rootfs (pretty bad idea)
 * Chipaca is going to run out of .33's if people carry on having good ideas
<sergiusens> Chipaca: oh, the iface name change reached us
<ogra_> cant we remove dpkg altogether ?
<ogra_> even the binary
<Chipaca> the whole thing, afaik
<sergiusens> ogra_: yes we CAN!
<Chipaca> although elopio will be sad
<ogra_> JUST DOIT !
<Chipaca> we can even remove dpkg-deb
<ogra_> JUST DOIT !
<ogra_> :)
<Chipaca> fuck yeah! break things on fridays!
<sergiusens> Chipaca: right,  but the reason we can't remove it on the phone is beacuase QA became entrenched with it
<Chipaca> and it isn't even beer o'clock
<ogra_> on edge ...
<Chipaca> remove it yesterday, then
<ogra_> living on the edge you can fall at times :)
 * Chipaca puts on a bit of aerosmith
<sergiusens> there https://www.youtube.com/watch?v=7nqcL0mjMjw
 * ogra_ headbangs 
<Chipaca> pitti: you around? wondering if you have bright ideas wrt figuring out the name of the first network device now that it's not static
<Chipaca> pitti: currently we have a (now non-functional) static file that brought up eth0 with dhcp
<mvo> Chipaca: dmesg|grep eth
<Chipaca> mvo: see above for sed that works :)
<mvo> Chipaca: oh, sorry
<pitti> Chipaca: what is "static" in this context?
<Chipaca> mvo: asking because we can't be the first ones, so maybe there's already a known-good soltion
<Chipaca> mvo: otherwise we can cook :)
 * mvo nods
<ogra_> mvo, livecd-rootfs http://paste.ubuntu.com/11740076/ ...
<ogra_> but interface names are dynamic now ... on boot ...
<Chipaca> pitti: livecd-rootfs writes /etc/network/interfaces.d/eth0 with allow-hotplug eth0\niface eth0 inet dhcp
<Chipaca> pitti: see ogra's pastebin for the code that writes it out
<mvo> Chipaca: I think apparmor may break without dpkg, the aa-clickhook was iirc calling dpkg for something
<ogra_> so we need to move the file cration somewhere into the boto process
<ogra_> *boot
<ogra_> after we know the name
<Chipaca> ogra_: no, no boto! jdstrand will get upset
<pitti> Chipaca: and what is "first"?
<ogra_> haha
<pitti> Chipaca: for ethernet, pick any match in /sys/class/net/en*
<pitti> Chipaca: I guess in many cases there will be just one, but as the old persistant-net-generator just randomly picked one to become eth0, you can also just pick the asciibetically first one
<pitti> i. e. ls /sys/class/net | head -n1
<pitti> ?
<Chipaca> pitti: good to know they're en*
<ogra_> pitti, is that generator gone ?
<mvo> just out of curiosity, why is it erenamd in the first place?
<mvo> dmesg tells me it was eth0 before and then got renamed
 * ogra_ wonders if we could abuse it to create an alias name for the moment ... as quick fix)
<pitti> Chipaca: yes, and wlan is wl*
<Chipaca> mvo: i assume, because it's fake anyways, and at least this way it's consistent and you can find it in /sys/ and elsewhere, but i don't know :)
<Chipaca> i think there are three different names for the device? or something like that
<mvo> but only one that works with ifconfig it seems
<seb128> sergiusens, mvo, so we had a new build on https://launchpadlibrarian.net/209509553/buildlog_ubuntu_wily_amd64_ubuntu-desktop-next_BUILDING.txt.gz a bit over an hours ago
<pitti> ogra_: yes, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html
<seb128> I just created a personal image using udf, but that seems to have given me an outdated version
<seb128> like ubuntu-core-config was not at 0.22 which it is in this log ^
<seb128> is that normal?
<Chipaca> mvo: i mean, the same device is called (potentially) different things in different parts of the system
<ogra_> pitti, "this wont affect upgrades" ... also on readonly system-image installs ? :)
<seb128> is there a way to check if there a channel image update ongoing and what's the status?
<pitti> Chipaca: your sed will also catch wlan, wwan, vlan, and other devices -- I suppose you don't want that, or do you? (I said en* as you had eth0 before)
<ogra_> (where the upgrade is actually replacing bits of the system instead of using dpkg)
<Chipaca> pitti: the sed was strictly just for our images, running in kvm
<Chipaca> pitti: not a general solution
<pitti> ogra_: well, upgrades in the apt sense :)
<ogra_> pitti, right
<sergiusens> seb128: there are logs on nusakan, but I don't recall where to find them
<ogra_> so it will break phones and snappy
<pitti> we can't have maintscripts on s-i upgrades
<ogra_> we need to take that into account i guess
<jdstrand> mvo: fyi, click-apparmor doesn't care about anything dpkg-y per se. we have this (rather crappy) mechanism for system-image based systems to discover when click-apparmor (and apparmor and ubuntu-core-snappy-apparmor and apparmor-easyprof-ubuntu) is updated that looks at the dpkg debsums
<seb128> ogra_, you might know (logs on nusakan)
<pitti> ogra_: how so? there we wouldn't have a writable /etc/ anyway, do we? i. e. we couldn't write the persistant rules?
<ogra_> seb128, rootfs build ?
<pitti> or firewall rules and stuff which refer to the names?
<ogra_> pitti, well, on phones it might not be an issue ... NM cares for the interfaces
<seb128> ogra_, no, wondering how to know when the image from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/wily/ubuntu-desktop-next is going to make it into the personal channel
<jdstrand> mvo: the idea is that goes away when snappy stops using aa-clickhook, but we need to figure out another mechanism for detecting these things
<ogra_> seb128, /srv/cdimage.ubuntu.com/log/
<seb128> ogra_, it built over an hour ago and I just use udf to build and image but get the old content
<pitti> ogra_: right, and NM doesn't care about the name
<seb128> ogra_, in fact I don't have ssh access to that box so nevermind, I can't look there
<ogra_> seb128, there is no logging for system-image
<ogra_> (at all)
<seb128> I guess I just have to wait and retry?
<ogra_> only for cdimage and livefs builds
<seb128> version is at 10, I guess I need a 11...
<seb128> sergiusens, mvo, you are sure channel images are autoupdated?
<sergiusens> seb128: well, slangasek said he added it to the list
<sergiusens> seb128: once it's in the list for consumption, it's automatic; only reason it failed could be due to an error
<seb128> slangasek, hey
<mvo> seb128: import-image is still running
<seb128> mvo, how long does that take?
<seb128> mvo, is there some UI where I can see the status?
<mvo> seb128: TMPDIR=/srv/system-image.ubuntu.com/tmp /srv/system-image.ubuntu.com/bin/import-images -vvvv
<mvo> 2015-06-19 13:27:14,522 INFO Something else holds the global lock. exiting.
<sergiusens> seb128: from http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/index.json it seems it was last updated today
<seb128> sergiusens, today this morning or today an hour ago?
<mvo> seb128: lsof -p 4196 tells me there is no log
<sergiusens> seb128: very early Fri Jun 19 06:02:00 UTC 2015
<seb128> sergiusens, k, so likely the daily build, no the retry with the fixes from this morning
<sergiusens> maybe the phone guys are fooling around with s-i?
<seb128> mvo, is that lock warning something I should be concerned about? ;-)
<mvo> seb128: no, it means its working
<seb128> k
<mvo> seb128: ls -lh /srv/system-image.ubuntu.com/tmp/tmpSW4IWr/
<mvo> total 3.2G
<mvo> -rw-rw-r-- 1 cdimage cdimage 1.8G Jun 19 13:20 source.tar
<mvo> -rw-rw-r-- 1 cdimage cdimage 1.4G Jun 19 13:28 target.tar
 * seb128 waits then
<mvo> seb128: that might help
<sergiusens> big images with s-i :)
<seb128> mvo, thanks
 * seb128 would like to see an image booting before eow!
<mvo> seb128: but I share your pain, +1 for logs
<sergiusens> and super tight xz compression levels
<mvo> seb128: you have 2.5 more days ;)
<seb128> mvo, lol
<ogra_>  4196 ?        R     28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images
<ogra_> runs since 30min
<ogra_> (or rather "had 30min f CPU cycles)
<ogra_> *of
<Chipaca> f works too
<Chipaca> short for the same thing as it was in fvwm
<sergiusens> mvo:  golang-gettext-dev is not in the archives yet
<mvo> sergiusens: I guess some archive admin needs to get active
<mvo> sergiusens: like seb128 â¦
<sergiusens> heh :-P
<seb128> lol
<seb128> I own you some... sure I can do that ;-)
 * mvo hugs seb128
 * seb128 hugs mvo back
<ogra_> huggers
<sergiusens> mvo: another reason to use http://getgb.io/ ;-)
<mvo> sergiusens: haha, indeed, it would make all the packaging irrelevant
<sergiusens> mvo: I might try and switch webdm given it's not even a debian package :-P
<seb128> sergiusens, mvo, NEWed, I'm going to watch for the build and NEW the binaries then
<sergiusens> ty
<seb128> yw
<mvo> \o/
<mterry> mvo, golang-gettext landed in wily
<ogra_> seb128, oh man, adding your gigantic image makes the system-image importer run forever ...
<ogra_> (still busy ... that used to be 10-15min max ... )
 * ogra_ thinks we'll need separate s-i servers soon ... image build times wont be bearable anymore at some point
<seb128> mvo, read backlog :p
<seb128> ups
<seb128> mterry, read backlog :p
<seb128> ogra_, yeah, sorry about that ...
<mvo> ogra_: once we move the os into a snap it will be a different system doing the imports
<ogra_> seb128, not your fault, our infra sucks on that level
<ogra_> mvo, sure ... but til then every new image and arch adds up
<mterry> seb128, thanks!  :)
<seb128> mterry, yw ;-)
<seb128> mterry, miiiike
<seb128> https://launchpad.net/ubuntu/+source/golang-gettext/0~git20130221-0ubuntu1
<ogra_> mvo, and phone kind of needs more rapid turnaround time than waiting 3h for an image build
<seb128> ftbfs
<seb128> mvo, ^ fail to build
<mterry> seb128, haha
<mterry> seb128, guh those stupid tests
<sergiusens> mterry: lol, funny how tests are always stupid when they fail :-)
<sergiusens> especially on a Friday!
<longsleep> Hey folks, is there a way to run my own image-server and have my images use that one?
<sergiusens> longsleep: yes there is
<mterry> sergiusens, it's not that they are stupid tests, they are just *being* stupid  :)
<longsleep> sergiusens: Ok great - then i have a project for the weekend :(
<longsleep> wrong smily - meant :)
<sergiusens> longsleep: https://wiki.ubuntu.com/ImageBasedUpgrades/ServerSetup
<longsleep> sergiusens: awesome - thanks!
<longsleep> currently my images pull generic_armhf - is there a way to make it pull say odroidc_armhf ?
<longsleep> i mean i saw that config somewhere in /etc/system.. but can it be set from the oem snap or something?
<sergiusens> longsleep: that's the leaf node in system image /etc/system-image/channel.ini
<longsleep> sergiusens: Right, but how can it be changed automatically - like when building the image file?
<sergiusens> longsleep: that's all part of the server setup, is it not there? if not it is described one level up
<longsleep> longsleep: didn't see it - let me look again
<ogra_> it will stop working once we switch to snap only upgrades
<ogra_> (and away from s-i )
<ogra_> no idea whats the ETA on this though
<elopio> good morning.
<longsleep> ogra_: right - but the base system still needs to come from some place?
<ogra_> longsleep, from a snap package ...
<ogra_> (in the future scenario)
<longsleep> ogra_: mhm i fail to see how this is going to work - then that snap package is not mutch different from a tar.xz
<ogra_> it comes from a different place
<longsleep> right now i am looking into possibilities how i can let people upgrade their ODROIDC's if i roll a new kernel without flashing
<ogra_> right, running your own s-i server is the solution then
<sergiusens> elopio: u-d-f should test this combination release_used_to_build release_built release_built_revision $target_device
<ogra_> but it wont presist
<ogra_> *persist
<longsleep> ogra_: right - i understand that - but how long would that actually be? Weeks, months?
<ogra_> at one point all three image parts are snaps ... and u-d-f will assemble the image from the store
<ogra_> see above: <ogra_> no idea whats the ETA on this though
<ogra_> it is on the roadmap ... but i dont know for when
<ogra_> (surely before april ... no idea if before october)
<longsleep> ogra_: ok :) i see what i can do then with my own system-image-server and it becomes obsolete once its obsolete - i am fine with that
<longsleep> the interesting question is if there will be a upgrade path from current system-image installs to store only installs
<elopio> fgimenez: I'm joining the talky.
<ogra_> that i cant tell
 * sergiusens takes a short break
<jdstrand> olli: re docs> https://developer.ubuntu.com/en/snappy/guides/security-policy/ (has Debugging at the end), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement#Debugging, https://developer.ubuntu.com/en/snappy/guides/frameworks/ (discusses framework-policy), https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy (tips for framework authors)
<fgimenez> elopio, ok, i'm already there
<ogra_> seb128, the importer seems to be done now
<seb128> ogra_, indeed, 11 on http://system-image.ubuntu.com/ubuntu-personal/rolling/edge/generic_amd64/
<seb128> ogra_, thanks!
 * seb128 starts udf build
<olli> jdstrand, thx!
<elopio> Chipaca: I won't be sad if we can build the image with the ubuntu-snappy-tests deb.
<Chipaca> elopio: i have no idea what a deb is. you're talking nonsense.
<Chipaca> elopio: there has never been dpkg
<elopio> Chipaca: http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/integration-tests/selftest#L50
<elopio> that's the ugly workaround we need to solve in a clever way.
<elopio> sergiusens: can we pass the ~/.ssh/id_rsa.pub to the image from ubuntu-device-flash ?
<elopio> oh, that's --developer-mode.
<rickspencer3> jdstrand, I have a much smaller reproducer for the net_admin issue I hit
<rickspencer3> I think it might be from reading a yaml file locally
<elopio> fgimenez: I was just saying that maybe we need to return to hangouts for the time being.
<Chipaca> rickspencer3: i don't know if you saw, but tyhicks narrowed it down quite a lot more
<rickspencer3> I saw that
<rickspencer3> thanks Chipaca
<Chipaca> rickspencer3: to the point there's a kernel patch and all
<Chipaca> ah, k
<rickspencer3> I put my smaller listing in for good measure, though
<Chipaca> rickspencer3: also, stop breaking the kernel :-p
<rickspencer3> if by that you mean, "stop using snappy"
<rickspencer3> no chance
<rickspencer3> I love this stuff
<rickspencer3> it's like developing for the phone, but on steroids
<Chipaca> oooh, that's nice, kernel dumps on usb unplugs
<seb128> sergiusens, mvo, k, new personal build boots to a working unity-greeter ;-)
<seb128> with a guest session button
<ogra_> seb128, yay
<seb128> now I need to try out of a vm for the session because unity8 doesn't work in kvm
<ogra_> why didnt you copy the autologin logic from touch ?
<seb128> because we started from ubuntu-core
<ogra_> (i mean, i know you wont use that in the final thing ... but its likely helpful during porting)
<seb128> I should review the diff with touch now
<ogra_> yeah, you kind of do a three way merge
<jdstrand> rickspencer3: thanks for the extra info
<mvo> seb128: \o/
<Chipaca> why does eth0 say it's eating 14W when i'm not using it
 * Chipaca 's seeing 40W drain on his laptop
 * Chipaca would recommend wily to people in colder seasons
 * longsleep 's laptop is currently using less power than Chipaca's eth0
<Chipaca> :'(
<longsleep> :) sorry
<Chipaca> well, 18W of that is my hd webcam
<sergiusens> seb128: yay
<mvo_> sergiusens: there will be conflicts with the noUpdate branc hand the snappy-improved-developer-mode branches - if the that could land I can help with the resolving of conflicts
<sergiusens> mvo_: no worries
<Chipaca> sergiusens: you're leaving for 5h really?
<sergiusens> Chipaca: yes, doctor and errands
<Chipaca> sigh
<Chipaca> also, damn
<ogra_> stop being sick !
<sergiusens> Chipaca: 5hr is a stretch
<Chipaca> sergiusens: i'll poke mvo, and then poke you
<Chipaca> no worries
<ogra_> doctors earn enough without you supporting them ...
<sergiusens> Chipaca: we can meet after standup
<seb128> is there a -v mode to "snappy"?
<seb128> "snappy internal-run-hooks" fails on personnal
<mvo_> seb128: on wily? that should provide the output of the failed hooks
<seb128> "hook command /usr/lib/ubuntu-push-client/click-hook failed with exit status 1 (output: "")"
<seb128> mvo_, ^
<bschaefer> hello is there a way to make the snappy core system writable to test some packages and doing session stuff? (such as touch /userdata/.writeable?)
<seb128> bschaefer, mount -o remount,rw /
<bschaefer> seb128, cool thanks!
<seb128> yw
<seb128> if you want to use apt just rm /usr/local/bin/apt*
<seb128> that's handy for local debug
<seb128> I used that to install things on personal
<bschaefer> o cool sweet!
<Chipaca> seb128: bschaefer: but do know that's even less supported than on touch
<seb128> Chipaca, "supported"? it helped me to understand why lightdm doesn't start, then I threw away the image and uploaded the ubuntu-core-config fixes neded
<seb128> Chipaca, which is just what I needed
<bschaefer> its mainly for debuging and to figure out if its possible or not
<bschaefer> to do what im trying :)
<Chipaca> seb128: yes. I'm wondering how much we learned from people breaking their phones because we publicized things like this.
<seb128> Chipaca, discussion development here is not really publicizing to users...
<seb128> discussing*
<seb128> Chipaca, btw, do you have any idea how to figure out why /usr/lib/ubuntu-push-client/click-hook fails on snappy personal/how to debug?
<seb128> it returns "1"
<seb128> but without any error/output
<ogra_> writability is sadly essential for porting ... on phones at least ...
<ogra_> but i agree, we should have never documented it at all
<seb128> right
<seb128> well, we are discussing on a dev channel
<seb128> it's not really documenting
<ogra_> well, mount -o remount,rw / is everywhere in phone blogs and docs
<seb128> that command existed before ubuntu ...
<ogra_> and it isnt hard to adapt that concept to snappy if you look close enough
<ogra_> heh, indeed
<elopio> Chipaca: so, for when you have some time: http://paste.ubuntu.com/11740844/
<Chipaca> elopio: in a hangout right now, but on this right after (will ping you)
<sergiusens> elopio: try making it a multi target
<elopio> sergiusens: I need a for-dummies explanation of that.
<elopio> what should be multi target? the chroot, or the deb, or the command?
<mvo_> mterry: is something like https://code.launchpad.net/~mvo/snappy/snappy-binary-ld-library-path-wrapper/+merge/252560 part of snapcraft now? or we just go ahead with that on the snappy side?
<fgimenez> nice weekend everyone o/
<mterry> mvo_, we envisioned that as something snapcraft did
<mterry> mvo_, and especially since we would probably have multiple, namespaced lib dirs
<mterry> mvo_, I am also leery as sergiusens of hardcoding layout of a snap
<mvo_> mterry: thanks, thats great, if its on your radar thats good enough for me :)
<sergiusens> elopio: Multi-Arch: same iirc
<sergiusens> elopio: https://wiki.ubuntu.com/MultiarchCross
<slangasek> seb128: I'm off today, but if you have a question ask and I'll try to answer :)
<seb128> slangasek, no, it's fine, enjoy your day off ... I was wondering if the s-i server would pick new tarballs from cdimage builds, it does
<slangasek> seb128: yep, sure does :)
<seb128> slangasek, it just took ages
<slangasek> ah, it should only take 5 minutes to pick it up, and sometime longer than that to process them
<seb128> where ages is like 3 hours
<seb128> right
<slangasek> so maybe the importer was disabled at the time because of something happening for the phone
<seb128> seems like the s-i server mangling is having lot to chew with the personal image ;-)
<seb128> slangasek, <ogra_>  4196 ?        R     28:56 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images
<ogra_> slangasek, when i last checked the process it had 48 min on the counter ...
<seb128> slangasek, well, maybe 3 hours is exagerated but it was easy > 1.5 hours, seems the imported was eating cpu for over half an hour
<ogra_> before it finished
<slangasek> ok
<slangasek> may not have been just because of the personal images, there may have been other images to import at the same time
<ogra_> i was wondering before if we could split phone and snappy imports somehow
<seb128> I guess adding the personal images doesn't help, they are not small
<ogra_> when we started it was under 10min
<seb128> slangasek, also I was unsure what was going on, there is no place to see if an import is ongoing and what's the status afaik
<seb128> slangasek, anyway, we eventually got the image out of it and it's booting to a working lightdm, so all good ;-)
<ogra_> and it grew by ~5 min for each phone arch we added, i imagine thats similar on the snappy side now
<seb128> next step is to test the session, but mir doesn't like my vm so need to switch to real hwd for that, it's for next week
<slangasek> Well, yes.  The server where this happens contains sensitive keys; not something that we'd be keen to add a webservice to to let people publically track the importer status
<ogra_> right, "ps ax|grep import" on nusakan is the best you can do ...
<ogra_> would eb nice to have a constant log from the importer though ... that sets a stamp or some such when itz starts and finishes a run
<slangasek> however, any of sil2100, rsalveti, mvo, ogra, myself etc can check the status for you
<ogra_> hmm, i guess that would be easy to achieve by just adding -v >>$logfile to the crontab line
<seb128> slangasek, yeah, well now I know that it's reacting to new builds and that it takes some time, so it's fine
<seb128> slangasek, thanks for the reply, enjoy your day off work ;-)
<elopio> not much luck using same. But with python3:any on the dependencies I got a little further.
<elopio> http://paste.ubuntu.com/11741070/
<Chipaca> elopio: that looks like a bug in python3.4's packaging
<Chipaca> elopio: maybe barry can confirm?
<Chipaca> /var/lib/dpkg/info/python3.4-minimal.postinst: 46: /var/lib/dpkg/info/python3.4-minimal.postinst: python3.4: not found
<Chipaca> barry: ^
<Chipaca> that's in wily
 * longsleep wants to see Snappy to ship only a single Python and does not care if it is 2 or 3
<olli> snappy gods... I am seeing the following issue - http://paste.ubuntu.com/11739849/
<olli> with that n dmesg
<olli> http://paste.ubuntu.com/11739855/
<olli> mterry says access denial to /usr/share/applications might be a red herring however
<ogra_> olli, LD_LIBRARY_PATH not set ?
<ogra_> (for the first line in the first post)
<olli> http://paste.ubuntu.com/11741043/ - line 5083 shows successful access to the library
<olli> and the lib exists in the fs
<ogra_> /usr/lib/x86_64-linux-gnu/ is definitelky nothing you can ship in a snap
<ogra_> not without $SNAPP_APP_PATH prefix
<olli> ah
<olli> it's deb2snap where it's coming from
<olli> but...
<ogra_> ah ... mterry terrytory then :)
<olli> seems like qt assumes access to the lib in the standard path
<ogra_> yeah, while yu would want /apps/mir/snap1/debs/usr/lib/x86_64-linux-gnu
<olli> the strace shows successful access due to deb2snap LDpreload magic
<olli> ogra check the last pastebin
<olli> line 5083
<olli> just seems that Qt is printing the err msg
<olli> and the printf doesn't know about LDPRELOAD
<ogra_> yeah, butu i wonder what else internally doesnt :)
<ogra_> *but
<olli> ogra_, all access to libdeclarative_multimedia is successful according to the lib
<olli> s/lib/strace
<ogra_> i think for the /usr/share/application issue there is actually some XDG_* variable you can set to point to the prefixed versin of the dir ...
<ogra_> (if qmlscene accepts freedesktop standards :) )
<olli> right, not worried about that
<mterry> olli, still no luck?
<olli> mterry, I got the strace
<olli> shows access to the right .so
<olli> so I am rtfc
<olli> mterry, for the ldpreload redirections, shouldn't I be able to run that locally on my regular system
<olli> assuming I am setting the Snappy env vars accordingly?
<mterry> olli, I think so?
<olli> then I could at least pretend to debug outside of the confined core system
<mterry> should work..
<olli> will try
<barry> Chipaca: i noticed some problems w/ py3.4 in armhf just earlier today and sent an email to doko
<olli> does snappy allow me to install snaps outside of "core", eg into a chroot?
<elopio> barry: thanks. Please keep me on posted if you get news so I can retry this.
<barry> elopio: will do
<skay> I think I flashed a beagleboneblack with snappy, and I'm wondering if I should see a new network interface show up when it's plugged in to my computer
<Nissyen> Hi, I filed a bug report, but I am not sure if I just rediscovered bug #1460152 .
<nothal> Bug #1460152: apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates) <Snappy:Fix Committed> <apparmor (Ubuntu):New> <http://launchpad.net/bugs/1460152>
<ubottu> bug 1460152 in apparmor (Ubuntu) "apparmor cache not updated when apparmor.d rules change (breaks 15.04/stable -> 15.04/edge updates)" [Undecided,New] https://launchpad.net/bugs/1460152
<Nissyen> The bug I filed was #1466682
<Nissyen> Does anyone know if a unix socket permission issue would be another manifestation of apparmor not rebuilding the cache?
<jjohansen> Nissyen: maybe, is apparmor denying access to the socket
<jjohansen> Nissyen: if the cache is out of date and you are using old policy it is possible
<Nissyen> Yeah, the dmesg is: [   72.230872] audit: type=1400 audit(1434397079.776:12): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="docker_docker_1.6.1.002" name="run/docker.sock" pid=1025 comm="docker.x86_64" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0
<jjohansen> Nissyen: you can always just delete the cache and force a policy reload
<Nissyen> I reloaded the framework in question, but actually let me try updating ubuntu-core from 2 to 3 on a VM and then rebuilding the cache and see if that fixes it.
<jjohansen> Nissyen: I would have to see the policy, but my guess if this requires a policy update
<Nissyen> It's the docker policyâ¦ I am unfortunately not that familiar with it.
<jjohansen> Nissyen, I am not really familiar with the docker policy either
<jjohansen> that being said, since this is failing with "Failed name lookup" the policy requires, flags=(attach_disconnected) in it
<jjohansen> that would look something like
<jjohansen> profile X flags=(attach_disconnected) { ... }
<Nissyen> ok, I am setting up a new Vagrant snappy VM, let try to find the policy.
<Nissyen> ir has a line "/eun/@{APP_PKGNAME}.sock rw,
<Nissyen> sorry, The line is as follows:
<Nissyen>  /run/@{APP_PKGNAME}.sock rw,
<Nissyen> let me try rebuilding and see what happens, I did a core update to cause the permission issue.
<Nissyen> sudo apparmor_parser --skip-cache -r /etc/apparmor.d/usr.bin.ubuntu-core-launcher did not resolve the issue. Maybe this is a new apparmor related bug
<Nissyen> Aha! I found that running the command "sudo aa-clickhook -f" worked
#snappy 2015-06-20
<ogra_> sergiusens, if i put something like assets/changelog-vmlinuz.gz and assets/config-vmlinuz into my device tarball, will u-d-f copy them into the image ? (if not, do we have a way to include such extra files ?)
<sergiusens> ogra_: maybe we need entries for this; the hack is to put it in /system/boot/uboot
<sergiusens> but that's a hack
<ogra_> well, but that will do for now ... i really want to ship the config and changelog
<ogra_> (and technically we should also ship the license
<ogra_> )
#snappy 2016-06-20
<fusion809> Hi, I'm attempting to build (using snapcraft) the Atom package in the snappy-playpen repo of Ubuntu (https://github.com/ubuntu/snappy-playpen/tree/master/atom) on Arch Linux but I'm getting the error message: 'Loaded local plugin for nodejs
<fusion809> Could not find a required package in 'build-packages': "The cache has
<fusion809> no package named 'fakeroot'"'
<fusion809> Guessing it's related to my OS. Do I have to adjust the dependencies in snapcraft.yaml to the corresponding ones on Arch Linux?
<fusion809> I know I can download the finished snap package for Atom and without a need for building it manually, but I'm attempting to build this package to get some practise in building snaps
<qengho> fusion809: fakeroot is indeed a Debian-specific package. That cross-distro package-name problem is still in progress, so I'm sad to say you might have to use a tweaked YAML to build on various systems. Sorry.
<fusion809> I tweaked the package names from Ubuntu -> Arch package names and now I'm getting the error: 'Loaded local plugin for nodejs
<fusion809> Could not find a required package in 'build-packages': "The cache has
<fusion809> no package named 'npm'"'
<fusion809> even though npm is a valid Arch package
<fusion809> in the [community] repo
<fusion809> it doesn't seem to be downloading packages to the cache
<fusion809> I set up a Ubuntu 16.04 Docker container and tried out building it and it's working fine. So I think that snapcraft is having difficulty working with pacman to download dependencies
<tsimonq2> fusion809: weird, I'll play with it when I have the time
<samerY> hello! how does one include an older release of python as part of a snap that runs a simple python program?
<samerY> would I need to create a separate plugin (aside from python2 & python3)?
<fusion809> I also have a query. How do I run sed and otherwise modify (or in other words, prepare for the build) source files before building from them in a snapcraft.yaml? The only way of doing this I have come up with is by adding lines like self.run('prepare.sh') to a plugin script in parts/plugin so that a shell script called 'prepare.sh' is run before th
<fusion809> e build. In this prepare.sh file I would have my sed commands
<tsimonq2> samerY: what release?
<tsimonq2> fusion809: what are you trying to modify?
<fusion809> Well I'm working on the Atom package still and I want to edit its package.json file. There's so many different package versions listed there that it would be impractical for me to use a patch
<fusion809> so it's more efficient to use sed
<tsimonq2> fusion809: I honestly don't know how you would go about doing that, it would be wise to wait around for someone tomorrow to answer that question :)
<fusion809> tsimonq2: Thanks, I may be able to solve this myself, but do you know if I can specify more than one source? If I can specify a shell script as a second source I may be able to get somewhere with this.
<jaygeeth> hello
<dholbach> hey hey
<fusion809> I just created my first snap package, atm the only way I can make it publicly available for download is using a file storage service / GitHub. So I chose to store it on GitHub https://github.com/fusion809/snapcraft/releases
<fusion809> How else can I share it? Is it possible to contribute these packages to the official snappy repo?
<dholbach> Yes
<dholbach> and it's actually quite easy: https://developer.ubuntu.com/en/snappy/build-apps/upload-your-snap/ :-)
<fusion809> Ah. I already tried that method (sorry I should have said, I was just assuming the method I was using had to not be the official one, but now I see this guide I see I was using the official method rofl) and it gave the error https://gist.github.com/fusion809/c7f14595e29af20d3c422a3e4638029f
<fusion809> It is a 165MB snap though. Maybe that's too large for it?
<dholbach> No it should be fine
<dholbach> can you go to https://myapps.developer.ubuntu.com/dev/account/?
<dholbach> and set something in "Developer namespace"
<zyga> good morning
<Doc_> was hoping someone could stupify the explanation of snap by telling me if in broad terms a snap and an .exe on windows are teh same .... ish o.O
<fusion809> dholbach: Just set something and now I'm getting a different error: https://gist.github.com/fusion809/0ae01640ea318dbff8c93834e4c17006
<dholbach> Doc_, no, they're not - a snap would be more like a special .zip file
<zyga> Doc_: snaps are compressed, read only filesystems that contain one or more application and services and run in a special environment that is not tightly coupled with the host distribution
<dholbach> fusion809, we're getting closer
<dholbach> fusion809, can you go to https://myapps.developer.ubuntu.com/dev/click-apps/register-name/?
<dholbach> I think there's a bug open for the store/snapcraft to give you better instructions about this
<dholbach> the doc could be more explicit here too
<dholbach> let me file a bug for this
<dholbach> I filed https://bugs.launchpad.net/snapcraft/+bug/1594273 if you want to subscribe to it
<ubottu> Launchpad bug 1594273 in Snapcraft "Docs: upload-your-snap article should point out myapps URLs to get stuff done" [Undecided,New]
<fusion809> Is there any temporary workaround for this problem? Like is it possible to upload the snap in the web browser
<Doc_> sweet thank you for the concise explanation dholbach
<dholbach> fusion809, yes, you can upload it there too
<dholbach> fusion809, just register the name of the app
<fusion809> How? Which website do I go to in order to do this?
<fusion809> https://uappexplorer.com/?
<fusion809> https://uappexplorer.com/ ?
<fusion809> dholbach if https://uappexplorer.com/ is the URL then I keep getting redirected to https://uappexplorer.com/me and this is what I see there http://i.imgur.com/g88rhUx.png. I'm working on Arch Linux (running snapcraft in a Docker container for 16.04 Ubuntu) and from what I can tell I can't get Caxton
<fusion809> on Arch
<dholbach> I have no idea what Caxton is
<dholbach> ^ can anyone else help?
<dholbach> Ah no..
<dholbach> it's https://myapps.developer.ubuntu.com/dev/ - sorry
<dholbach> myapps, always myapps
<dholbach> uappexplorer is a 3rd party site which just lists all the available click and snap apps
<fusion809> Thanks
<zyga> fusion809: o/ -- it is great to see snaps originating from the arch community!
<fusion809> Yeah. My current PC is a HP Envy 17 laptop with two HDDs, one has Arch installed and the other has Ubuntu 16.04 installed. Ubuntu was the first distro I ever used (and I started in mid 2012), but Arch is my favourite.
<fusion809> Solus OS uses a similar build file to snapcraft's yaml file.
<Chipaca> morning all
<hamiltino> can somone help me i installed snap hello but when i run the command hello it says command not found
<fusion809> Aha, just published my first snap package https://myapps.developer.ubuntu.com/dev/click-apps/5248/
<zyga> woot!
<Chipaca> hamiltino, can you pastebin the output of "snap list"?
<zyga> fusion809: tha'ts something that only you can see
<zyga> fusion809: what is the name of the snap?
<hamiltino> yes here
<hamiltino> http://pastebin.com/iW6YBNQB
<fusion809> atom-fusion is its name.
<Chipaca> hamiltino, what distro are you on?
<hamiltino> debian
<Chipaca> hamiltino, have you logged in since you installed snapd?
<hamiltino> jessie but added sid repo and installed snapd
<Chipaca> hamiltino, otherwise /snap/bin might not be in your path
<Chipaca> hamiltino, if starting a new shell, or logging in again, doesn't end up with /snap/bin in your path, then we need to figure out why :-)
<zyga> hamiltino: which shell do you use?
<Chipaca> ah, good q
<hamiltino> hey i just added /snap/bin to /etc/profile and then ran source /etc/profile. Its working now thanks
<Chipaca> hamiltino, the snapd package should have done that already
<Chipaca> hamiltino, via /etc/profile.d
<Chipaca> hamiltino, /etc/profile.d/apps-bin-path.sh in particular
<Chipaca> bah, that's what it is in ubuntu; in debain it might be /etc/profile.d/snapd ? not sure
<Chipaca> hamiltino, dpkg -L snapd | grep profile
<hamiltino> yeah i see apps-bin-path.sh
<hamiltino> it has PATH=$PATH:/snap/bin
<hamiltino> wonder why it didn't work
<zyga> hamiltino: are you running bash or some other shell?
<hamiltino> gnome-terminal
<zyga> hamiltino: echo $SHELL
<hamiltino> yea running bash
<zyga> ok
<zyga> hmmmm
<zyga> can you please source /etc/profile.d/apps-bin-path.sh (. /etc/profile.d/apps-bin-path.sh )
<zyga> and then try to run any of the snaps you've installed
<hamiltino> ok
<hamiltino> ahh that works thaks
<hamiltino> thanks
<fusion809> Is my atom-fusion package published now cause I think it is
<tsimonq2> fusion809: you made an Atom snap? :)
<fusion809> Yeah, but I had to use an inpractical method see I created a fork of the official Atom repo to https://github.com/fusion809/atom-1/ and applied my edits to it so I could create a source code tarball for it.
<fusion809> It's impractical as everytime a new release comes out it'll be a bit of a nuisance to update.
<fusion809> But hopefully someone will come up with a way of sedding the source
<zyga> fusion809: I don't think it is yet
<zyga> fusion809: I just did a lookup with 'snap find atom' and only found atom-cwayne
<fusion809> Ah, thanks.
<zyga> fusion809: double check the myapps website
<zyga> fusion809: last time I looked there was a publish button at the bottom but afair the UI changed
<fusion809> I published it, it says "Package status is Published".
<fusion809> Been published for an hour or more.
<matteo> hi all
<matteo> hi zyga
<matteo> zyga: I have a problem with download from the store
<zyga> matteo: what kind of proble
<matteo> http://pastebin.ubuntu.com/17586014/
<zyga> fusion809: did you publish it to the 16 series?
<zyga> fusion809: and if so, to which channel?
<zyga> fusion809: I cannot download it yet
<zyga> matteo: hmm, not sure, maybe cdn issue
<zyga> matteo: are you using a proxy?
<1JTAAFARK> Hi - I want to try delta updates. Is there a resource where I can read up on them?
<matteo> zyga: no proxies
<fusion809> http://i.imgur.com/4DSzVP6.png
<fusion809> That screenshot hopefully answers that question
<zyga> OK
<pandaadb> (managed to rename myself to something normal) - don't know if I missed it. I wanted to read up on delta updates for snappy packages if someone can point me to a resource :)
<zyga> pandaadb: today snaps are not using delta updates, given the snap architecture this is very natural and we have some experiments but this is not released yet
<matteo> zyga: how can we know if it's a CDN issue?
<matteo> it happens every time
<zyga> matteo: no idea really, I'll ask around
<pandaadb> zyga, ah okay. I was reading an article mentioning that that feature exists. Next update then :)
<pandaadb> thanks!
<pandaadb> For completeness, that's what I've been reading: http://www.omgubuntu.co.uk/2016/04/ubuntu-16-04-lts-snap-packages
<slvn> Hello, I have tried to add the interface "pulseaudio" to my snap, but it doesn't seem to play sound
<slvn> I have message from app armor
<ogra_> does it play if you install the snap with --devmode ?
<slvn> \me is trying ...
<ogra_> just to verify it works at all :)
<slvn> yes
<slvn> it's working with --devmode
<ogra_> good, then it is definitely an interface problem ...
<slvn> in fact there is two issues (for me), I need to add the stage-package "libpulse0" to have acces to the libpulse, then it's blocked by app armor ...
<slvn> it tries to open/mknod the file /dev/shm/pulse-shm-1888657987 according to the log
 * ogra_ sees bug 1593558
<ubottu> bug 1593558 in Snappy "sox not configured for pulseaudio when packaged in a snap" [Undecided,New] https://launchpad.net/bugs/1593558
<zyga> pandaadb: I think there are some misconceptions about this, we never announced it yet
<pandaadb> That's interesting. I also saw that info on some answers on stackexchange
<pandaadb> well actually, they just link to the article so that makes sense
<zyga> pandaadb: since snaps are read only squashfs files that are always present on the device all you need is an xdelta to get get another revision
<zyga> pandaadb: we'll release it when everything is ready
<pandaadb> Sounds great :)
<zyga> slvn: currently pulseaudio gives you the followng permission:
<zyga> /{run,dev}/shm/pulse-shm-* rk,
<zyga> so you cannot create buffers there
<zyga> svij: can you please do a small tweak, edit /var/lib/snapd/apparmor/profiles/snap.$snap.$app
<zyga> svij: and patch a line that looks like the one I pasted above
<zyga> svij: to read
<zyga> svij:  /{run,dev}/shm/pulse-shm-* rwk,
<zyga> slvn: then run sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.$snap.$app
<svij> zyga: ?
<zyga> svij: sorry, I meant slvn
<svij> ah ok
<zyga> slvn: ^^ then see if your app works
<slvn> ok I try!
<zyga> slvn: and report a bug wiht this information please, we should be able to fix it quickly
<slvn> zyga, I have less message from app armor, but it's still doesn't work:
<slvn> I have this message
<slvn> Jun 20 12:17:47 jupiter kernel: [14994.957426] audit: type=1326 audit(1466417867.433:1620): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=12090 comm="PulseHotplug" exe="/snap/mahjong/x1/bin/Mahjong" sig=31 arch=c000003e syscall=141 compat=0 ip=0x7efe3a8ed4a7 code=0x0
<slvn> syscall 141= 	setpriority	sys_setpriority ?
<slvn> also an access to "/etc/timidity/freepats.cfg"
<slvn> not sure if it's pulse audio, or SDL2 which access to this ..
<zyga> slvn: that's setpriority
<zyga> slvn: that will only work after syscall argument filtering works :/
<zyga> slvn: if you want to ship timidity in your snap you will have to change its configuration to look at some other place
<zyga> slvn: timidity is the midi thing
<slvn> I don't use midi, so probably no needed for me
<slvn> so I open a bug for the pulse app armor configuration ?
<slvn> it wont work, but it's needed ..
<matteo> zyga: I've added a line in snapcraft
<matteo> print ("Downloading from" + package['download_url'])
<matteo> before downloading the snap
<matteo> now I'll try to download it to see if it's a CDN issue
<slvn> zyga, https://bugs.launchpad.net/snapcraft/+bug/1594318
<ubottu> Launchpad bug 1594318 in Snapcraft "pulseaudio interface is missing permissions" [Undecided,New]
<zyga> slvn: thanks
<zyga> jdstrand: hey
<zyga> jdstrand: ^^ if you agree with the proposed policy change I will make it happen
<slvn> zyga, also I need to add to my snapcraft.yaml the line "stage-packages: [libpulse0]" to have access to libpulse0
<slvn> whereas I could be granted to have acces to the system lib
<slvn> libs are : /usr/lib/x86_64-linux-gnu/libpulse.so and /usr/lib/x86_64-linux-gnu/libpulse-simple.so ( I guess)
<centy> Hi all
<centy> Whats a good resource to understand how snap works? - I would like to see what it would take to make it work on CentOS.
<zyga> slvn: can you report that as a bug, I'll add this to the pulseaudio interface documentation
<zyga> centy: hey
<zyga> centy: I'd love to get snappy on centos
<zyga> centy: I can help you out
<centy> zyga: I'm targeting more like Cent5 not sure if that is even possible.
<centy> Thanks
<zyga> centy: so snappy has two components, snap-confine that's written in C and snapd that's written in go
<zyga> centy: I have a bunch of spec files for fedora, I think they can be a good starting point for centos and EL distros
<zyga> centy: one thing I dind't figure out is how to proceed with snapd and go in that environment
<zyga> centy: should I use something that provides golang-go, what does software like docker do/
<slvn> https://bugs.launchpad.net/snapcraft/+bug/1594324
<ubottu> Launchpad bug 1594324 in Snapcraft "pulseaudio interface needs access to pulse libraries" [Undecided,New]
<zyga> slvn: thanks
<matteo> zyga: while : ; do [ "$(curl -sL https://public.apps.ubuntu.com/anon/download-snap/b8X2psL1ryVrPt5WEmpYiqfr5emixTd7_123.snap |sha512sum)" = '44752755393319233917bfbd6c7802c3c3810ddb3f94091acf16f8ca0c9afaf6c6746eb33f3911d1aaaad52d2045bf9ba6af8e25b49cf5bc3d413d8d13046b45  -' ] && echo correct || echo fail; done
<matteo> I have this running for a while
<matteo> never had a fail until now in about 30 downloads
<centy> zyga: I guess go would need a runtime installed, but what kind of kernel support (if any) would snap need (stuff like cgroups and things?)
<seb128> mvo, hey, did you see my message the other day about i386 snaps still not working?
<zyga> centy: snappy can run in two modes, in devmode, that is easy to get up and running and in non-devmode
<zyga> centy: for devmode pretty much nothing special is required
<zyga> centy: for non-devmode you need seccomp and apparmor
<zyga> centy: snappy is modular and it is possible to add a selinux backend but nobody started this work yet
<zyga> centy: I would suggest starting with devmode and then looking at how to either enable apparmor or what needs to happen in snapd to enable selinux
<centy> zyga: I guess I'm looking for some documentation on how it accomplishes sandboxing to see even if that is possible on my target platform
<zyga> centy: it is but full selinux support will not happen overnight
<zyga> centy: AFAIR centos ships with selinux and apparmor is not available along with selinux
<zyga> centy: without apparmor you can still enable seccomp but some part of the confinement will not work
<zyga> centy: all of the confinement bits are defined in snapd source code, in the interfaces/ directory
<zyga> centy: look at interfaces/apparmor/template.go and at particular interfaces/builtin/*.go files
<zyga> centy: each interface defines confinement and other security details for a given backend
<zyga> centy: there are numerous backends, most interfaces use seccomp and apparmor today
<zyga> centy: note that none of this affects actual snaps, if you have a snap that declares it needs networking, it can be made to work just by patching snapd
<centy> zyga: looks like I'll just have to read through the code and figure this out. I'm more on the administration side and not very in to c/go coding. I was mainly interested in the ability to package newer apps using snapd and deploy to hundreds of existing cent5 system.
<zyga> centy: I can work with you on this
<zyga> centy: but I'm not very used to centos, if you can help me with packaging
<zyga> centy: I can help you out with the security bits
<zyga> centy: does centos5 have docker?
<zyga> centy: and if so, are those spec files for docker available anywhere to read?
<centy> zyga: what kind of help you need with packaging? Building RPMs?
<zyga> centy: mostly figuring out how to support go on centos/rhel
<zyga> centy: the snap-confine .spec for feodora is here;
<zyga> https://github.com/zyga/snapcore-fedora/blob/master/snap-confine.spec
<zyga> centy: the same repository has a few other specs files that were prerequisties for snapd and the snapd.spec itself
<zyga> centy: I've also created where I'd like to put spec files for centos https://github.com/zyga/snapcore-centos
<zyga> centy: I also have a copr repo that works for fedora 23 and 24 at https://copr.fedorainfracloud.org/coprs/zyga/snapcore/packages/
<centy> zyga: apparently go isn't supported on Cent5 http://dave.cheney.net/2013/06/18/how-to-install-go-1-1-on-centos-5
<zyga> centy: since snapd is just one binary, it would be possible to ship a copy built on fedora for centos
<zyga> centy: does centos5 have systemd?
<zyga> centy: reading the article I see that it might be difficult to support because of older userspace and kernel
<centy> zyga: apparently lost my connection - sorry
<zyga> no worries, this is irc ;)
<ogra_> zyga, does the home interface not auto-connect when sideloading a snap ?
<zyga> ogra_: it should, are you on yakkety by any chance, AFAIR we didn't release anything there yet because of unrelated regression
<ogra_> zyga, i got a gitter snap that works fine in devmode ... but dropping it i get http://paste.ubuntu.com/17588690/
<ogra_> and no, i'm on xenial
<zyga> ogra_: dconf, hmmm, looks like gsettings interface to me
<zyga> ogra_: if you remove the snap entirey and reinstall it, does it auto-connect
<ogra_> oh, wiat, snap interfaces shows all gitter connections
<ogra_> seems i'm missing some interface
<zyga> hmm?
<ogra_> well, home, x11 and network and network-bind are apparently not enough :)
 * ogra_ rebuilds with more added
<ogra_> hmm, still not starting ... but the set of errors changed
<willcooke> Hi gang, the snap I'm working on hosts some of its data in Github which then needs to be cloned and copied in to (I think) $SNAP_USER_DIR.  Can I do this with existing plugins or will it need a custom one?
 * ogra_ would use a launch-wrapper for that 
<zyga> willcooke: you can also copy it to $SNAP_DATA btw
<willcooke> zyga, $SNAP_DATA is not writable by the user is it?  The app updates its data from github on some cadence so would need to be writable
<zyga> hmm, AFAIR snaps can write there
<ogra_> servers ... but can the UID ?
<willcooke> ah, yeah, SNAP_DATA should be writable, and is a better location
<willcooke> so question remains; whats the correct way to get files from Github -> $SNAP_DATA.  Really I only want to do this once at build time, then the app takes care of keeping it up to day
<willcooke> *date
<zyga> hmmm
<zyga> willcooke: that's not sensible
<zyga> willcooke: that's a snapcraft side (building)
<zyga> willcooke: do you want the app to download stuff at runtime?
<willcooke> indeed it is a snapcraft thing.  The app does download things during its lifecycle, that's just how it works.
<didrocks> why wouldn't the app proceed the first download?
<didrocks> (when it starts)
<zyga> willcooke: so snapcraft, not sure, write a makefile, write a custom plugin, in either case that's not $SNAP_DATA becausethat only exists at runtime
<willcooke> zyga, ahh!  I see,  I'll have a play.  thanks zyga
<didrocks> willcooke: see my question about first download on first service start
<mvo> seb128: still not working at all? what example snap? or not working for network? or network-bind?
<seb128> mvo, not working for snaps not using the network plug since that's where you defined socketcall
<seb128> or maybe I should make my snap use that
<mvo> seb128: so this also affect snaps that do not use the network  :/ ?
<ogra_> well, loopback network is also network :)
<seb128> mvo, let me redo a round of testing, but I think I tried to start bash on friday
<seb128> which wasn't working
<seb128> but maybe that requires the network?
<mvo> seb128: heh, that would be odd :)
<mvo> seb128: its more a jdstrand or tyhicks question really, I'm not sure I fully grasp the implications of opening this syscall up
<seb128> mvo, yeah, ideally somebody needs to fix bug #1576066
<ubottu> bug 1576066 in libseccomp (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,Confirmed] https://launchpad.net/bugs/1576066
<Perry____> hi,there, can you guys know how to install snappy to x86 machine? from the official site, only try through USB.
<croepha> snapcraft.io not loading
<croepha> :(
<didrocks> croepha: it does here :) (but layout broken)
<didrocks> Perry____: if you have Ubuntu desktop 16.04 LTS, it's already installed
<didrocks> Perry____: you can have a look at http://snapcraft.io/ for other distros (mind the layout, temporarly broken for now)
<croepha> what is snapcraft.io resolving to for you guys? for me its 162.213.33.140, 162.213.33.142
<Perry____> didrocks do you means snappy tool? or snappy os?
<croepha> nevermind, now mine is loading
<didrocks> Perry____: snapd
<didrocks> croepha: ah, was transient
<didrocks> Perry____: which is to install/use snappy technology
<croepha> didrocks, yep, YAY! now I can snap all the things
<didrocks> sweeet! :)
<Perry____> ubuntu also have a IoT OS snappy
<didrocks> Perry____: there is no release 16 images available yet though, you can use a server image and install snapd on it
<didrocks> to experiment
<ogra_> i think snapd is actually seeded on server images
<ogra_> so you dont need to separately install it
<Perry____> didrocks ok, thank you
<didrocks> yw ;)
<didrocks> ogra_: oh, you're right
<ogra_> :)
<Perry____> i just wanna try the IoT :)
<carif> now that several other distros might adopt snap as a packaging format, does that mean they will run their own app stores?
<ogra_> perhaps
<croepha> There are going to be multiple stores, even if the distros don't want their own
<carif> I've always been somewhat hazy on this, does a store mean a different snap repository? or some "segment" of the official canonical one? the wisdom when last I looked was that you "sideloaded" your own snaps otherwise you installed from the one official place
<ogra_> thats still the case ... until someone implements another store ...
<ogra_> the APi is open and i would expect that other distros prefer to have their own, so it is likely you see more stores at some point
<zyga> joc_: hey
<zyga> joc_: do you plean to make any changes to https://github.com/snapcore/snapd/pull/1301/files
<joc_> zyga: no plans to, unless you have anything that needs to change
<zyga> joc_: I left a few comments that I don't think you've addressed
<zyga> ah, wait
<zyga> stale tab, thanks
 * zyga reads for real :)
<joc_> hehe, phew :)
<pstolowski> zyga, hey
<carif> ogra_, can a company run its own snap repo internally? does snappy have something like /etc/apt/sources.list.d/?
<zyga> joc: joc_ https://github.com/snapcore/snapd/pull/1301/files#r67690850
<zyga> pstolowski: hey
<zyga> pstolowski: how can I help you? :)
<didrocks> kyrofa: FYI, I just tried integration_tests/snaps/simple-make-filesets, which is using organize:, snap:
<didrocks> kyrofa: typed snapcraft stage
<didrocks> changed stage/new/dir2/file1 and append something
<didrocks> then "snapcraft"
<didrocks> prime/new/dir2/file1 contains my changes
<kyrofa> didrocks, indeed, files are pulled from stage
<didrocks> so it really seems that prime is pulling files from stage
<didrocks> wasn't the contrary you were telling with seb128 the other day?
<kyrofa> didrocks, but fileSETS (i.e. WHAT it pulls) is determined from each part
<pstolowski> zyga, thanks for your comments to scopes as snapps doc! can you help me understand point #1 a little better?
<kyrofa> didrocks, no, but I perhaps wasn't explaining it well
<zyga> pstolowski: sure
<didrocks> kyrofa: you mean, before organize, the reference?
<didrocks> ah
<didrocks> so, if in snap: I'm using fileset
<pstolowski> zyga, actually, HO would be best. do you have a moment now?
<didrocks> that would be from install/ ?
<zyga> yep, lets do it
<kyrofa> didrocks, so: a file travels from parts/foo/install -> stage -> prime
<kyrofa> didrocks, however, the WAY it travels is not "copy from parts/foo/install -> stage -> prime"
<kyrofa> didrocks, instead snapcraft keeps track of all files provided by part foo, and moves them from parts/foo/install -> stage, and then moves them from stage -> prime
<ogra_> carif, no, not atm
<kyrofa> didrocks, that makes it possible to UNstage or UNprime something with snapcraft clean -s stage|prime
<kyrofa> didrocks, but it means that if you move files around in stage, snapcraft won't be able to find the collection of files it expects
<pstolowski> zyga, https://hangouts.google.com/call/mvw6y5n4wnf6titz4hjodeyldee
<kyrofa> Because it pulls the files themselves from stage, but uses what the part provided in parts/foo/install to determine what it's supposed to migrate from stage -> prime
<didrocks> kyrofa: ok, I see what you mean, but if we only use the snapcraft feature, with organize and such, those moves/renamed are tracked as expected
<kyrofa> didrocks, indeed
<didrocks> but yeah, messing directly with the stage/ dir won't reflect the change if files are added or move/renamed
<didrocks> that makes sense :)
<kyrofa> You got it
<didrocks> thanks for clearing that up kyrofa!
<kyrofa> didrocks, hey any time. I still think at the very least the `snap` keyword should by default inherit the `stage` keyword
<didrocks> I wonder if we have cases with new files created into stage/ that we want to ship
<didrocks> as per another build
<didrocks> yeah
<didrocks> we need to find a real use case for this though
<didrocks> kyrofa: however, so, if snap: is refering to a filesets
<kyrofa> didrocks, well that means whatever is creating those files is totally bypassing the snapcraft lifecycle of putting things in parts/foo/install first
<didrocks> and you renamed those via organize
<didrocks> that's going to be difficult if you copy directly from stage/
<didrocks> like, what should it refer to?
<didrocks> kyrofa: correct
<kyrofa> didrocks, first, a warning: you've probably used organize and filesets more than I have
<croepha> carif: by looking at the code, it looks like you can specify a store via environmental variables (https://github.com/snapcore/snapd/blob/edc1296463ab8e12c464f7c436d390bbeb5dc117/store/store.go) but I cant find any documentation, so its off the beaten path
<kyrofa> didrocks, but I believe organize happens first, then the stage or snap keywords are applied, which means they should refer to the organized named
<kyrofa> names*
<didrocks> kyrofa: indeed, I just mean: if we have snap referring to stage/ directory, and you set snap: - $fileset1, then this filesets1 (source) doesn't exist
<didrocks> only the dest
<kyrofa> didrocks, heh, sorry, I need more coffee-- you lost me :P
<kyrofa> didrocks, man this is complicated
<kyrofa> didrocks, "snap referring to stage/ directory" isn't making sense to me
<didrocks> kyrofa: I need to head out
<didrocks> will be back in 30s
<didrocks> I'll take an example :)
<didrocks> get your coffee meanwhile!
<kyrofa> didrocks, yeah good idea!
<didrocks> ;)
<kyrofa> didrocks, oh I am ;)
<didrocks> :p
<mhall119> no sergio today?
<kyrofa> mhall119, I believe he's on holiday until tomorrow
<kyrofa> mhall119, can I help you with something? Or are you still stuck on pkg-config stuff?
<mhall119> kyrofa: still the pkg-config stuff, can't figure it out for the life of me, but I'm pretty sure it has something to do with the PKG_CONFIG* env variables that snapcraft is using
<kyrofa> mhall119, yeah I suspect it's something related as well
<mhall119> I can *almost* get it to find the right packages if I manually muck with those
<kyrofa> Haha, it fails less badly?
<mhall119> well, it fails differently, and I *think* further down the road
<mhall119> it fails on trying to find different dependencies anyway
<matteo> what differs go from gccgo?
<hguant> kyrofa, some one said yesterday that you were the person to ask about building custom plugins/where to find docs on such a thing
<kyrofa> hguant, hey there! I am indeed
<kyrofa> hguant, this should get you started: https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md
<kyrofa> hguant, I also have many examples for you to check out if you're interested, though you should be able to also refer to the plugins included within snapcraft itself
<hguant> kyrofa nifty! Thanks very much
<kyrofa> hguant, which are here: https://github.com/ubuntu-core/snapcraft/tree/master/snapcraft/plugins
<kyrofa> hguant, no problem, please let me know if you have any questions
<hguant> kyrofa will do, thanks again. be back after I read through all this
<samerY> kyrofa - thanks also!
<kyrofa> hguant, samerY any time
<kgunn> zyga: hey, made significant changes to my PR
<kgunn> https://github.com/snapcore/snapd/pull/1299
<kgunn> might be ready for another pass
<didrocks> kgunn: ohhhh, organize is actually applied in parts/part/install
<didrocks> sorry
<didrocks> kyrofa: ^
<kgunn> :)
<didrocks> kyrofa: so, it would work, even if snap: only refers to stage/
<kyrofa> didrocks, ah, that makes sense
<kyrofa> didrocks, indeed
<didrocks> yeah, I don't know why it doesn't then, it's counter-intuitive, and I don't see good reason for not doing it that way
<zyga> kgunn: I'll review them today, thank you for iterating on it
<kgunn> zyga: thank you for your patience !
<croepha> btw, I was having some wierd issues that I think were related to running snapcraft in a network mounted dir, I moved it out, and now im getting much more sensible errors :) I filed a bug (https://bugs.launchpad.net/snapcraft/+bug/1594374) with some ideas
<ubottu> Launchpad bug 1594374 in Snapcraft "Use a user directory for temporary files" [Undecided,New]
<jdstrand> seb128, mvo: we'll fix 1576066 but it is prioritzed after other work since people should be unblocked now that we added socketcall
<seb128> jdstrand, we added it only to the network interface though
<seb128> jdstrand, should we add network to the plugs in i386 even when not needed as a workaround?
<jdstrand> zyga: re bug #1594318, that was the small pulseaudio change I mentioend over the weekend
<ubottu> bug 1594318 in Snappy "pulseaudio interface is missing permissions" [Undecided,In progress] https://launchpad.net/bugs/1594318
<jdstrand> seb128: I would prefer to add it to the default template as a work around by why is it so onerous to add "plugs: [ network ]"? are you sure it doesn't actually need network?
<jdstrand> if it actually needs it, then adding to default policy with a huge comment makes more sense
<seb128> jdstrand, I'm rebuilding with a modified wrapper to test, but I think it was hitting the bad syscall even when trying to start bash
<seb128> jdstrand, it's not onerous to add network, just a non obvious workaround to make your snap work
<jdstrand> snappy-debug would tell you to do so. if the app actually doesn't need network except for socketcall, then yes, it should be in template.go
<elopio> ogra_: mvo: is this OK for you? https://github.com/ubuntu-core/snappy-jenkins/pull/179/files
<jdstrand> I'm actually off today, so feel free to comment in backscroll and I'll get back to you
<seb128> jdstrand, k, no worry, I hope you had a nice travel back, enjoy your day off!
<mvo> elopio: yes, this actually makes more sense
<seb128> jdstrand, you are back to work tomorrow?
<mvo> elopio: sorry that I did not propose/catch this earlier
<jdstrand> thanks!
<ogra_> elopio, yeah, that looks a lot better
<jdstrand> yes back tomorrow
<seb128> jdstrand, I want to talk to you about getting dconf to work if we can
<seb128> great
<seb128> talk to you tomorrow then :-)
<elopio> mvo: not your fault, at all. /me updates the live job.
<elopio> beowulf: do you have some time for me today? :)
<beowulf> elopio: what's up? :)
<beowulf> elopio: have you seen https://github.com/snapcore/snapweb/pull/17
<elopio> beowulf: you are too fast for me!
<elopio> thanks!!!
<beowulf> elopio: np
<beowulf> elopio: check it does what you want first though :)
<seb128> jdstrand, mvo, yeah, verified, /bin/bash fails to start on i386 without the network plug, hiting the syscall error, adding socketcall fixes it
<jdstrand> seb128: if there isn'
<elopio> I will try, but looks way better than mine already.
<jdstrand> t a bug, file it, add snap-interface tag, mark it Triaged and assign to me please
<seb128> jdstrand, k
<jdstrand> I'll have a PR tomorrow then
<seb128> and on that I let you to your day off work ;-)
<seb128> thanks
<pdurbin> https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/ is interesting. It was linked from http://irclog.perlgeek.de/crimsonfu/2016-06-20
<elopio> ogra_: There's now new package in there: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge
<ogra_> elopio, perfect, and all of a sudden it is newer :)
<matteo> where the snap t
<matteo> download is actually done?
<croepha> you guys are really trying to sell the "package for any Linux platform" feature, but I think the real boon is transactional updates and delta transfers...  The benefit for snappy that I see, is that I can (hopefully) be able to push apps to devices without having to worry about issues related heterogeneous states of those devices
<ogra_> there are many strong points about snappy ... indeed transactional updates fall into that catregory too
<ogra_> like rollbacks do
<croepha> yea
<joc_> zyga: hey, i made a change for your last comment and pushed, the checks appear to have failed but with some error related to access to go repositories
<zyga> joc_: hmm
<zyga> joc_: looking
<samerY> hello, how does one include an older release of python to run a simple python program?
<samerY> I've been able to unpack release with copy plugin
<croepha> samerY: what version of python?
<samerY> say 2.6.9
<zyga> samerY: I guess you could look at "oldsnakes" ppa
<zyga> samerY: and perhaps somehow use that
<zyga> samerY: ideally someone would make a part for each version of python
<zyga> samerY: that is built straight from upstream tarballs
<croepha> can you specify a PPA for a stage-packages?
<zyga> croepha: I don't know but I know there's a way to use your host PPA settings somehow
<zyga> croepha: ask kyrofa; maybe he knows
<croepha> kk, thanks
<croepha> ill dig some more
<kyrofa> zyga, croepha indeed, snapcraft will by default use your host settings
<kyrofa> samerY, did you download debs then and copy them in via the copy plugin?
<samerY> kyrofa: yes, I've been able to do that
<kyrofa> samerY, does it not work?
<samerY> oh wait, I feel like I'm overcomplicating this.. let me see
<samerY> never mind..
<samerY> I guess my next problem is how would I build Python2.6.9
<samerY> as on host computer, I'd have to run "./configure" and then run make to produce interpreter
<kyrofa> samerY, wait... why are you building it? I thought you got it from debs?
<samerY> I'm not sure.. I assume to run a python file, I need to have python executable produced by building it
<zyga> cwayne, joc: https://github.com/snapcore/snapd/pull/1301 merged :)
<samerY> all I have are the 2.6.9 files from tarball?
<cwayne> zyga <3
<cwayne> joc_: ^
<zyga> I'm sorry it took so long
<zyga> let's do another :)
<cwayne> zyga: no need to apologize, thanks for getting it done (and sorry for bugging you so much :P)
<cwayne> zyga: joc's workin' on the next one already :)
<joc_> thanks zyga
<matteo> zyga: is possible to build snap with gccgo?
<ayan> it is possible for a program to properly call seccomp() from within a snap?
<Chipaca> jdstrand, do you know the answer to ayan's question without going and testing it?
<Chipaca> jdstrand, he's trying to package the tor browser i think? (not 100% sure)
<croepha> being able to run a shell in the same context of snapcraft stage would be useful for debugging
<mhall119> hi all, is there a generic gtk-launch script like we have for qt?
<Beornmar> Is there any way to get snapd on a Debian system other than downloading the source and building it?
<josepht> Beornmar: there's a version in universe for sid: https://packages.debian.org/sid/snapd
<Beornmar> josepht: Thanks!
<josepht> Beornmar: np
<croepha> is snappy-remote still a thing?
<croepha> so, is current snapcraft incompatible wth 15.04 snappy ?
<svij> croepha: yes
<croepha> ok, thanks, that explains some things :)
<croepha> if I wanted an updated (16) version of ubuntu core to test my snapcraft images, would I want to use ubuntu-device-flash with these files: http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/20160620/ ?
<ehbello> where is `snappy service [start|restart|stop|etc]` command in last snapd???
<mhall119> kyrofa: do you know how I can get a Gtk snap to send it's window menu over dbus to unity7?
<kyrofa> mhall119, e.g. for the global menu?
<Trevinho> mhall119: indeed it can
<Trevinho> mhall119: just ensure you've proper libs in it and unity-gtk-menu lib installed
<Trevinho> mhall119: check the hello-unity/calculator snaps
<mhall119> Trevinho: ah, ok, and if I include that in the snap, will it be smart enough not to use is when running in non-unity DEs?
<Trevinho> mhall119: sure
<Trevinho> mhall119: it's up to u-p-s to enable or disable that
<mhall119> ok
<tedg> jdstrand: I'm getting a weird error that I think is coming from snap-confine
<tedg> jdstrand: It is "failed to create user data directory. errmsg: Permission denied"
<tedg> jdstrand: Could it be because of my encrypted home directory?
<tedg> jdstrand: Jun 20 15:11:29 roku kernel: [195193.397698] audit: type=1400 audit(1466453489.213:95): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/ted/.Private/" pid=28973 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1001 ouid=1001
<tyhicks> tedg: see bug #1592696
<ubottu> bug 1592696 in ubuntu-core-launcher (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,Fix released] https://launchpad.net/bugs/1592696
<tyhicks> tedg: a workaround is listed in the comments
 * tedg is reading
<swartzr> Snapcraft seems to be manipulating my shebang line at the start of a script, hardcoding my home directory into it. Am I missing something or is this not supposed to be happening?
<swartzr> Is preventing my snap from running on other systems
<tedg> tyhicks: Cool, that works for me. Thanks!
<tyhicks> np
<croepha> ubuntu-device-flash says it cant make an image for 16... any workarounds?
<ehbello> croepha: https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
<croepha> ehbello: Thanks very much!
<ehbello> croepha: np ;)
<johnsel> hello everyone
<johnsel> i want to ship a device with an openvpn client + configuration
<johnsel> what would be the high level tasks to integrate it?
<johnsel> I see there's a gadget snap that supposedly can do system configuration
<johnsel> not sure how i should approach it though
<example6> Hi all -- I was wondering what would be the best way to connect to a wireless network from the command line, since /etc/network/interfaces seems to be on a readonly mount. I've read up a bit on wpa_supplicant, but am not sure where the best place to keep the file would be
<zyga> example6: /etc/network/interfaces.d
<zyga> example6: put a file in there
<zyga> example6: it looks like typical ifupdown file
<ehbello> I have a question... can we put a source block to build boot files inside a gadget snap package?
<wililupy> Question--Has anyone seen this before? When I type my command for my snap, I get the proper command line output, but the command needs to run as sudo, so when I try that, it says it can't find the command. Any ideas?
<kirkland> where can I find a beta image of Ubuntu Core 16, for 64-bit intel?
<kirkland> to download
<kirkland> basically, I want the latest test image of Ubuntu 16 equivalent, of http://people.canonical.com/~platform/snappy/ubuntu-core-15.04-intel-nuc.img.xz
<wililupy> kirkland: you look in http://people.canonical.com/~mvo/all-snaps?
<wililupy> kirkland: or you can build it with ubuntu-device-flash from the same location
#snappy 2016-06-21
<wililupy> I usually do that latter with sudo ./ubuntu-device-flash core 16 --channel=edge --gadget=canonical-pc --kernel=canonical-pc-linux --os=ubuntu-core -o ubuntu-core-16.img
<qengho> wililupy: It sounds like your "su" method to become root is not running as a login shell, and so not reading /etc/profile to set PATH to find snaps.
<qengho> wililupy: compare $PATH from two environments.
<wililupy> Thanks qengho. I started digging into it some more and I have some other issues with the snap as well. Upstart seems to not like it either and it's not loading the services properly.
<qengho> It? snapd?
<wililupy> the snap has a service that runs for console redirection and ASIC driver communication with kernel drivers.
<wililupy> When I run the console command to get into the ASIC programming console, I get an error Unable to connect to Upstart: Failed to connect to socket com/ubuntu/upstart: Connection Refused
<wililupy> If I try to run sudo snap.console it says command not found, but if I run it from /snap/bin I get the above error about Upstart and a missing file that I have never heard of.
<wililupy> ...Gremlins....
<qengho> wililupy: what file?
<fusion809> My atom-fusion package still doesn't seem to be publicly available for download. I uploaded it to the store 16 hours ago. Anyone have any ideas how I can make it available? I took a screenshot of its publish history if that helps http://i.imgur.com/gYJWbap.png
<qengho> fusion809: installing from same machine as where you built it?
<fusion809> Installing it isn't the problem, it's getting the package available from the official snap repository.
<fusion809> I am installing it just fine, and I'm working on Arch Linux so that's a feet in itself.
<fusion809> feat^
<qengho> fusion809: yep. Are you installing on the same machine as where you built?
<fusion809> I built it in a Docker container (for Ubuntu 16.04) that I'm running on the same machine as where I installed it.
<qengho> fusion809: is that the same architecture? Not amd64 vs i486?
<fusion809> AMD64, I'm pretty sure Docker doesn't even run on 32-bit platforms, nor does it provide containers for 32-bit systems
<qengho> fusion809: what's the name?
<qengho> "atom-fusion"
<qengho> ?
<fusion809> Exact snap package name is atom-fusion_1.8.0_amd64.snap. So yeah atom-fusion is the package's name
<qengho> fusion809: it can take a few minutes to publish, but there could be something wrong. At bottom, file a bug report.
<fusion809> It's been 16 hours, so yeah probably need a bug report.
<wililupy> qengho: /usr/sbin/console.fp
<fusion809> Done reporting the bug https://bugs.launchpad.net/snapcraft/+bug/1594622
<ubottu> Launchpad bug 1594622 in Snapcraft "Package Uploaded via web browser not being added to public repository" [Undecided,New]
<wililupy> qengho: I'm going to try rebuilding my snap with confinement: devmode to see if I can get more logs.
<wililupy> qengho: Thank you so much!
<qengho> wililupy: Are you acessing $SNAP/usr/bin/console.fp?
<qengho> wililupy: I think that's your problem. /something instead of $SNAP/something .
<johnsel> hey
<johnsel> anyone around?
<tsimonq2> o/
<tsimonq2> !help | johnsel
<ubottu> johnsel: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<tsimonq2> :)
<johnsel> alright, fair enough
<johnsel> ./openvpn: error while loading shared libraries: libpkcs11-helper.so.1: cannot open shared object file: No such file or directory, any clues?
<johnsel> it's in the snap itself
<johnsel> at ./usr/lib/x86_64-linux-gnu/libpkcs11-helper.so.1
<tsimonq2> hmm weird
<tsimonq2> johnsel: stick around, maybe someone else has a better answer :)
<johnsel> I will, meanwhile I'm going to try and compile it from source
<johnsel> See if that helps
<sergiusens> elopio hey, what is the easiest way to debug the fake servers? Seeing this https://github.com/ubuntu-core/snapcraft/pull/584
<elopio> sergiusens: could you paste the error?
<tsimonq2> elopio: could you look at my PR again?
<elopio> tsimonq2: I can review it tomorrow.
<tsimonq2> elopio: thank you :)
<qengho> tsimonq2: are you running the tests locally, for your subversion patch?
<tsimonq2> qengho: yeah, but I can't figure it out
<tsimonq2> qengho: see anything I'm missing?
<seb128> hey there
<seb128> does anyone know if it's possible to tell snapcraft to stage some packages from a ppa or a local dir?
<qengho> seb128: not possible, last time I checked.
<seb128> qengho, thanks, I'm going to file a bug against snapcraft I guess
<qengho> seb128: while you're at it, please ask for APT-like source semantics.  foo=version, foo/release, with whatever you think is best for PPA and whatnot. Maybe "foo@ppadescription"
<didrocks> hum, if I remember some discussion, snapcraft was supposed to take your source.list
<didrocks> and so, yours ppa
<didrocks> instead of rewriting it
<didrocks> that was in february
<didrocks> (however, that ofc, won't work in cleanbuild or launchpad, which is an issue)
<qengho> It does, didrocks, but that only works for your machine. the yaml isn't very portable.
<didrocks> right!
<seb128> good enough for today, I'm going to play with that, but first coffee
<zyga> o/
<dholbach> hey hey
<tsimonq2> hey it's dholbach! o/
<tsimonq2> dholbach: how are you?
<dholbach> hey hey - doing well - how about you? :-)
<tsimonq2> qengho: do we have a Chromium snap?
<tsimonq2> dholbach: awesome :)
<qengho> tsimonq2: Yes. Its security policies are almost available, and it works pretty well in devmode.
<tsimonq2> qengho: do you have code somewhere that I could take a peek at?
<seb128> hey dholbach
<dholbach> salut seb128
<qengho> tsimonq2: Well, the recent parts will be in snapd, but the snapcraft that uses it will be something like  https://code.launchpad.net/~chromium-team/chromium-browser/snappy-packaging
<tsimonq2> oh cool, thanks qengho :)
<ogra_> hmm, whern i use the mak plugin, shouldnt snapcfat clean call make clean ?
<ogra_> *snapcraft
<zyga> ogra_: make clean make :)
<zyga> my faviourite solution to WTF issues
<ogra_> zyga, well, i want snapcraft to clean up when i call clean
<zyga> yeah
<qengho> hmm, is discarding the build dir enough?
<tsimonq2> !info python-magic
<ubottu> python-magic (source: file): File type determination library using "magic" numbers (Python bindings). In component universe, is extra. Version 1:5.25-2ubuntu1 (xenial), package size 5 kB, installed size 53 kB
<tsimonq2> \o/
<matteo> hiall
<tsimonq2> hello matteo :)
<tsimonq2> !info gplugin
<ubottu> Package gplugin does not exist in xenial
<tsimonq2> !info gplugin-dev
<ubottu> Package gplugin-dev does not exist in xenial
<tsimonq2> :(
<tsimonq2> !info help2man
<ubottu> help2man (source: help2man): Automatic manpage generator. In component universe, is optional. Version 1.47.3 (xenial), package size 108 kB, installed size 420 kB
<tsimonq2> \o/
<tsimonq2> !info gobject-introspection-1.0
<ubottu> Package gobject-introspection-1.0 does not exist in xenial
<tsimonq2> !info gobject-introspection'
<ubottu> gobject-introspection (source: gobject-introspection): Generate interface introspection data for GObject libraries. In component main, is optional. Version 1.46.0-3ubuntu1 (xenial), package size 261 kB, installed size 1412 kB
<tsimonq2> !info default-mta
<ubottu> Package default-mta does not exist in xenial
<tsimonq2> !info mail-transport-agent
<ubottu> Package mail-transport-agent does not exist in xenial
<tsimonq2> grr
<tsimonq2> !info urlview
<ubottu> urlview (source: urlview): Extracts URLs from text. In component universe, is optional. Version 0.9-20 (xenial), package size 19 kB, installed size 65 kB
<tsimonq2> !info aspell
<ubottu> aspell (source: aspell): GNU Aspell spell-checker. In component main, is optional. Version 0.60.7~20110707-3build1 (xenial), package size 77 kB, installed size 360 kB
<tsimonq2> mvo: hey, I'm trying to make a mutt snap and I'm getting thrown a build error, would you be able to test if my snap works locally? dholbach says that you use mutt. https://github.com/ubuntu/snappy-playpen/pull/98
<mvo> tsimonq2: mutt!
<mvo> tsimonq2: \o/
<ogra_> heh
<tsimonq2> mvo: I'm going to bed, weird sleep schedules, so if you have any suggestions, comment on the PR
<tsimonq2> but yes, mutt! \o/
<tsimonq2> :P XD
<tsimonq2> o/
<mvo> tsimonq2: will do. mutt! I'm excited :) I love my mutt
<seb128> is that known that a "cp -a" triggers an invalid syscall under restricted snaps?
<kyrofa> seb128, yeah, chown I think
<seb128> kyrofa, is that a bug or a feature?
<kyrofa> seb128, I assumed a feature, but jdstrand would know more
<seb128> k
<seb128> kyrofa, thanks for your replies on the channel btw ;-)
<kyrofa> seb128, haha, of course!
<ogra_> kyrofa, do you have an idea why snapcraft clean doesnt trigger a make clean call when using the make plugin ?
<kyrofa> Who's stealing all the armhf and arm64 launchpad builders!?
<ogra_> i kind of expected it would
<ogra_> kyrofa, doko most likely
<kyrofa> ogra_, because it's not the smart :(
<kyrofa> ogra_, remember make isn't the only build system it supports
<ogra_> ah
<kyrofa> ogra_, its version of cleaning the source is to blow it away
<kyrofa> ogra_, since that was the shortest path to success
<ogra_> right ... my makefile copies something to ../src
<kyrofa> ogra_, I full intend on making that better
<kyrofa> fully*
<ogra_> which i would like to clean along
<kyrofa> Agreed. It would also be awesome if it actually noticed changes to the source
<kyrofa> And just ran make again
<ogra_> yeah
<kyrofa> But I need to come up with a generic way to do that for all build systems
<kyrofa> Something that can be extending via local plugins
<seb128> is there a way to do the pull/build again on some parts and not others?
<kyrofa> seb128, yeah, but the inconsistency would be confusing
<seb128> like to not redo a full source build everytime just because you changed the wrapper or the stage packages
<matteo> anyone here with a 32 bit distro?
<ogra_> stop building that giant stuff :P
<seb128> matteo, _o/
<matteo> seb128: http://pastebin.ubuntu.com/17638846/
<matteo> can you run this?
<kyrofa> seb128, yeah that should be possible. You have to rebuild the part on which you changed the stage packages though... no way around that I don't think
<kyrofa> seb128, if you have stage packages on a part that's building something, and it doesn't actually need or use the stage packages, you might be better off putting those stage packages in their own part, even if using the nil plugin
<seb128> kyrofa, right, that's fine, it's "deb" part ... how do I do that? how do I tell it to repull the debs part only?
<kyrofa> seb128, yeah it's not that fine-grained. The stage packages are pulled during the pull step
<kyrofa> Along with the source code
<seb128> can I pull only one part?
<kyrofa> seb128, so you might want to have them in separate parts
<kyrofa> seb128, oh certainly!
<kyrofa> seb128, `snapcraft pull <part>`
<kyrofa> seb128, that applies to all steps: `snapcraft build <part>`
<kyrofa> seb128, `snapcraft clean <part> --step=build`
<seb128> ah
<kyrofa> seb128, note that "snap" is not a valid step though, since it's what creates the image. i.e. `snapcraft snap <part>` is not a valid command
<seb128> kyrofa, thanks, seems obvious now the mention it, I sort of got lost between the steps and parts for some reason
<kyrofa> seb128, heh, no problem. Our `help` could probably use a little love
<seb128> matteo, is there anything specific you are looking for/any error you hit? that's just on a normal system or under snappy? xenial?
<matteo> seb128: does it download the whole file?
<matteo> normal system
<matteo> seb128: I get this: http://pastebin.ubuntu.com/17639303/
<killua99> snappy on arc isn't full supported yet, right ?
<ogra_> killua99, zyga should be able to tell you
<killua99> I mean the arc aur package did install. I did just install krita over snap, but I can't find the app :D
<ogra_> you might need to re-login after installing snapd ... it ships an /etc/profile.d snippet to enhance your PATH
<ogra_> though krita also has a .desktop file, if you use some desktop with menu, it should show up there too
<kyrofa> killua99, indeed, as ogra mentioned /snap/bin needs to be in your PATH
<ogra_> ogra@styx:~$ which krita
<ogra_> /snap/bin/krita
<ogra_> thats what i get on ubuntu
<ogra_> i would assume arch does something like that too
<ogra_> unless zyga didnt finish up that part yet
<killua99> aha, re-login might be the missing part. Thanks ogra_ I'll try that later ;D
<jdstrand> ayan (and Chipaca): re seccomp syscall-- yes, in 2.0.9
 * Chipaca hugs jdstrand 
<Chipaca> wb dude
<sergiusens> good morning
<jdstrand> tedg: snap-confine-- that is precisely it. 1.0.30 in yakkety will have all the fixes. xenial will once zyga/mvo transitions to snap-confine. I think that is imminent
<Chipaca> hey sergiusens, 'sup
<seb128> matteo, seems to always return 64823296 here compiled or not
<jdstrand> seb128, kyrofa: chown is bug #1581310. will be fixed with seccomp arg filtering
<ubottu> bug 1581310 in snapd (Ubuntu) "ubuntu-core doesn't allow sed -i (fchown syscall)" [Medium,Triaged] https://launchpad.net/bugs/1581310
<jdstrand> well, fixed for many apps
<kyrofa> jdstrand, excellent, thank you :) . How far out is argument filtering, by the way? That will solve many issues
<sergiusens> didrocks qengho seb128 launchpad builders allow you to setup PPAs for the build
<seb128> jdstrand, ah ok, thanks
<sergiusens> and yes, ppa support for cleanbuild is the only thing really missing
<kyrofa> Morning sergiusens!
<seb128> sergiusens, k, good to know, I didn't even know that snapcraft was using the system config
<seb128> sergiusens, is there any way to give it a specific apt config?
<jdstrand> kyrofa: waiting for (hopefully) final review from tyhicks. things got pushed back due to holidays and sprint
<Chipaca> matteo: can you also print err in that program? ie the last line, make it 	fmt.Printf("%d copied; %v\n", n, err)
<kyrofa> jdstrand, awesome :)
<sergiusens> seb128 not today; I went back and forwars with Colin on this some time ago and we agreed to make it an out of snapcraft thing
<sergiusens> although for cleanbuild it would need to be supported
<jdstrand> seb128: there is a workaround. snappy-debug tells you to do: cp -r --preserve=mode
 * jdstrand hugs Chipaca back :)
<sergiusens> kyrofa how is it going?
<kyrofa> sergiusens, not bad, how was the extended weekend?
<ogra_> have you been fathering a lot ?
<seb128> jdstrand, thanks, I don't know about snappy-debug, I should give it a try :-)
<jdstrand> sudo snap install snappy-debug
<jdstrand> sudo /snap/bin/snappy-debug.security scanlog
<jdstrand> that will tail /var/log/syslog, dereference syscalls and make suggestions
<seb128> k
<jdstrand> (and first run will tell you the proper snap connect command to run
<jdstrand> )
<sergiusens> kyrofa turns out I had the flu for 2 weeks and did not notice until the weekend when some dry coughing kicked in :-P
<kyrofa> sergiusens, blech, so a lovely extended weekend then
<sergiusens> it was good still ;-)
<ayan> jdstrand: sorry -- what do you mean by 'yes'?
<jdstrand> ayan: yesterday someone asked if the seccomp syscall is allowed. the answer is 'yes' in 2.0.9
<ayan> jdstrand: ah, okay.  is 2.0.9 available now?
<jdstrand> ayan: it is released, yes. If you are using Ubuntu, it is in xenial-proposed
<jdstrand> https://launchpad.net/ubuntu/+source/snapd/2.0.9
<matteo> Chipaca: it's nil
<matteo> Chipaca: sorry
<matteo> 34651558 copied, err: unexpected EOF
<Chipaca> matiasb: there you go
<matteo> but, why EOF?
<seb128> jdstrand, mvo, do you know if anyone gave some consideration on letting snaps claiming mimetypes and how that could work?
<joc_> zyga: hi, can you provide any advice for debugging an interface which includes udev snippets? are the snippets stored in a file somewhere when they are registered?
<jdstrand> seb128 (and mvo): I think someone mentioned it at some point as something we'd want to support in the future. I think that needs proper design. I can sort of see it as an extension to interfaces, but we'd likely need to coordinate with tvoss or others from personal since they have something similar in url-dispatcher
<seb128> jdstrand, mvo, would you see an objection on running update-desktop-database on /var/lib/snapd/desktop/applications so applications show as handler in e.g nautilus on unity7? maybe as a temporary thing until we figure out something better
<jdstrand> seb128: otoh, I would, yes. that is too automagical since the snaps could take over mime handling and that should be an explicit choice. I suspect I'll be overruled on that
<jdstrand> that gets back to design
<zyga> joc_: hi
<jdstrand> the design should involve discussion regarding how to transition to the new system
<zyga> joc_: yes, they end up in /etc/udev/rules.d
<seb128> jdstrand, the mailing list would be the right place to start that discussion I guess?
<jdstrand> seb128: I'm not sure. I guess. it depends on if people feel it should be an interface. I guess the mailing list and then someone might ask to file a bug
<seb128> k, thanks
<jdstrand> seb128: you might want to wait for mvo to respond though
<seb128> I'm getting close from a working evince
<jdstrand> I'm not necessarily up on all the latest decisions
<seb128> like I've it opening pdf even in restricted mode
<jdstrand> nice
<seb128> but it's a bit less useful if you can't double click on documents
<seb128> like if you need to start evince from the dash and then browse to the file you want
<Chipaca> seb128: well, there is the xdg-open thing
<Chipaca> seb128: which is a toe in the water
<seb128> Chipaca, the xdg-open things is the other way around though, right?
<Chipaca> seb128: ah!
<seb128> having code from inside the snap calling e.g your system browser
<Chipaca> seb128: that's what happens when i skim the backlog and try to be helpful :-)
<seb128> lol
<seb128> thanks for the reply though ;-)
<joc_> zyga: the system /etc/udev/rules.d i.e. not just from the confined app's perspective?
<zyga> joc_: yep, the real one
<zyga> joc_: if we put udev rules in place we reload udev and re-trigger the rules
<zyga> joc_: so you should see stuff happening
<joc_> hmm, not sure why i'm not seeing anything
<seb128> jdstrand, so mime handling would be nice, but my real blocker is dconf atm I think ... do you still have that one on your todolist?
<mvo> seb128: sounds ok
<jdstrand> seb128: I am not actively working on that. there are 3 parts: 1) create a global gsettings interface that allows access to the global db by the sandbox (assigned to me, I did that) 2) gsettings apparmor backend-- multiple teams, in progress, behind a couple other things wrt security team) 3) making a snap find and use gsettings at all (ie, the HOME issue)
<jdstrand> seb128: '3' is what you need. that seems to me to be a snappy team and/or desktop team thing (ie, it has nothing to do with the sandbox and I have no insight as to the proper fix)
<jdstrand> maybe it is a snapcraft thing
<seb128> jdstrand, I can figure 3 out but we also need access to the system XDG_RUNTIME_DIR
 * jdstrand isn't sure
<seb128> jdstrand, which is where I'm blocking
<seb128> I don't even know if it's ok from a security point of view
<jdstrand> are you saying the sandbox is blocking access to the XDG_RUNTIME_DIR? is there a bug for the system XDG_RUNTIME_DIR?
<jdstrand> what is that dir?
<seb128> jdstrand, XDG_RUNTIME_DIR=/run/user/1000
<seb128> jdstrand, I get a permission denied when I try to access /run in a confined snap
<jdstrand> seb128: what is the apparmor denial?
<seb128> l[30316.913854] audit: type=1400 audit(1466518291.070:296): apparmor="DENIED" operation="open" profile="snap.gnome-logs-udt.gnome-logs-udt" name="/run/user/1000/" pid=9158 comm="ls" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<jdstrand> well, that is for 'ls'
<jdstrand> but what is the denial when you use gsettings?
<jdstrand> becuase we allow access to /{,var/}run/user/*/dconf/user already in the gsettings plug
<didrocks> jdstrand: hey! Small question/remark/needs your brain. We are thinking about introducing best practices for shaping snapcraft.yaml for our developers via some rules set (order of stenzas, and so on). This tool would be a linter which may be extended as an helper for IDE for autocomplete as well.
<didrocks> so it means it needs to be fast to execute (as autocomplete on temporary file in the IDEs) and work on snapcraft.yaml source
<seb128> jdstrand, ok, I think I just got confused and assumed that if I couldn't ls to it it was not available, I see no deny
<seb128> jdstrand, I'm going to try to figure out 3) then, sorry for the nois
<seb128> jdstrand, and thanks for the replies!
<jdstrand> seb128: np
<didrocks> I was first thinking about about the click-reviewer-tools (that we will integrate on package built from the ide ofc), but I'm a little bit more vary on using/extending it for snapcraft.yaml + introducing our best practice rule then
<didrocks> having some experience on linter written in python integrated in IDE and their speedâ¦ wdyt?
<jdstrand> didrocks: I think the tools could be extended to read a specific snapcraft.yaml on the fs and run fast enough
<didrocks> jdstrand: so you would probably be in favor of us going that road instead of trying to get something in go?
<jdstrand> didrocks: the thing that can be slow now is unpacking the snap, going through all the files, etc. just parsing snapcraft.yaml would be fast
<jdstrand> didrocks: yes-- otherwise the test will diverge and maintenance would be a problem
<jdstrand> tests*
<didrocks> jdstrand: yeah, but it means for every character typed in the IDE, the python interpretor would be executed by the IDE plugin
<didrocks> (for autocomplete for instance)
<jdstrand> it is already hard enough keeping snapcraft and the tools in sync. adding another thing would be hard
<didrocks> yeah, that's why I prefer talking about it to you beforehand :)
<jdstrand> didrocks: hmmm, for every character? that sounds slow now matter how you do it. I mean, if you could keep the interpreter running, then it would be fast, but invoking the interpreter over and over will likely be too slow
<didrocks> jdstrand: I'm afraid that out extending most of IDEs are working though
<didrocks> that's* how
<didrocks> but in theory, you have nothing against us extending the click-reviewer-tool for those functionality? (parsing snapcraft.yaml + introducing autocomplete)
<didrocks> functionalities*
<jdstrand> I do not-- it has a ton of lint tests already
<didrocks> jdstrand: great! the LP project is still the main branch, right ? (nothing on github?)
<jdstrand> how to integrate would be the interesting bit
<jdstrand> all LP
<didrocks> yeah, I'll have a look on some ides and how this works, but from a quick look, it's similar to what you do with the tool already: returning some json (where you have the line numberâ¦)
<jdstrand> you'd need to extend that part. we don't track line number-- we track by key/value
<didrocks> yeah, but I think it's another binary anyway
<jdstrand> (not that line number would be difficult to add)
<didrocks> as it's not meta.yaml
<didrocks> by another file, with other rules (some are commons)
<jdstrand> you might want to create a 4th category-- 'bestproactice' or something. error, warn and info are likely not enough for what you need (something between info and warn)
<didrocks> indeed
<didrocks> I'll have a look in the next days and keep you posted!
<didrocks> thanks for your feedback :)
<jdstrand> np
<matteo> zyga: maybe I have found the download issue
<zyga> matteo: yes? what is it?
<matteo> the connection is resetted when the network is faster than the disk
<swartzr> I'm trying to run a snappy app as a service account but get the following message: failed to create user data directory. errmsg: Permission denied. Anybody have a workaround?
<zyga> re
<zyga> swartzr: re
<zyga> swartzr: so can you tell me more about your issue
<swartzr> zyga: installed a snap that I built on one of our servers although the service account that will run it (jenkins) throws that error message when it tries to run it.
<swartzr> I looked in jenkin's home directory and i see a snap directory so I assume it is created successfully
<joc_> abeato: i take it you tested that the udev rules were definitely be created for modem-manager?
<abeato> joc_, yep
<zyga> swartzr: can you tell me what the error is in more detail
<zyga> swartzr: what is the host? (where does snapd run)
<joc_> abeato: do you have an amd64 snap i can install? looks like your recent builds failed
<abeato> hmm, weird
<swartzr> zyga: The host is an ubuntu server 16.04 x86_64 when i run the snap via /snap/bin/ftptransfer I get the message: "failed to create user data directory. errmsg: Permission denied" nothing more
<swartzr> zyga: the snap is also installed in devmode
<abeato> joc_, http://people.canonical.com/~abeato/snappy/modem-manager_1.4.0-1_amd64.snap
<kyrofa> swartzr, do you have an encrypted home directory?
<joc_> abeato: boo, yours works here too :p
<abeato> joc_, lol
<swartzr> kyrofa: no although it is in a different spot than normal /var/lib/jenkins
<kyrofa> swartzr, interesting. Any chance $HOME/snap is owned by root?
<swartzr> zyga: Actually I forgot to look at syslog. I have a apparmor deny does this help? http://paste.ubuntu.com/17646112/
<swartzr> kyrofa: no it is owned by the user jenkins
<kyrofa> swartzr, yep, that'll do it
<swartzr> kyrofa should it be owned by root?
<kyrofa> swartzr, it's the denial. The profile under which u-c-l runs won't let it create $HOME/snap if $HOME is in /var
<kyrofa> At least, that's what it looks like
<kyrofa> jdstrand, can you take a look at that? ^^
<jdstrand> which that?
<jdstrand> the /var/ denial is likely from zyga's recent changes
<jdstrand> and so it would need to be allowed
<kyrofa> jdstrand, $HOME is /var/lib/jenkins, getting http://paste.ubuntu.com/17646112/ and permission denied when creating user data directory
<kyrofa> Ah
<kyrofa> swartzr, ^^
<zyga> hmm
<zyga> hmm
 * jdstrand is assuming the flipped mounts work is causing that ^
<zyga> swartzr: home has to be in /home/$foo, or apparmor will have a few issues
<zyga> jdstrand: which changes are you referring to?
<swartzr> zyga: ok I might have to change the way I'm deploying this then
<zyga> jdstrand: ubuntu still ships the old ubuntu-core-launcher
<zyga> swartzr: quick idea
<zyga> swartzr: vm /var/lib/jenkins /home/jenkins
<zyga> er
<zyga> mv
<zyga> then ln -s it back
<zyga> and try
<zyga> so the real home is /home/jenkins
<zyga> and /varlib/jenkins is a symlink to /home/jenkins
<jdstrand> zyga: if this is in the old code, then the profile is lacking the rules to create HOME dir for daemons. That said, I thought something else was creating that directory in /var/lib
<zyga> jdstrand: my memory is hazy
<zyga> jdstrand: AFAIR the per-user thing is created by the launcher
<zyga> jdstrand: and the /var/snap/$SNAP_NAME thing is created on install by snapd
<swartzr> zyga let me look at that. I have to make sure that it won't mess anything else up first.
<swartzr> zyga: Thank you
<jdstrand> zyga: if /var/snap/$SNAP_NAME is created on install, then the launcher arguably shouldn't be creating dirs in there even if HOME is set to /var/snap/...
<zyga> jdstrand: I think the launcher was doing the $HOME-derived (SNAP_USER_DATA) one
<jdstrand> zyga: but they said that home was /var/lib/jenkins. I think I' confused now
<jdstrand> how was HOME set to /var/lib/jenkins?
<jdstrand> that isn't right in any scheme
<zyga> jdstrand: I suspect jenkins package does that
<zyga> jdstrand: it's not a snap, jenkins is just a regular package
<jdstrand> I'm really confused now. why is the launcher getting denials for launching something that isn't a snap?
<zyga> jdstrand: jenkins runs a snap
<zyga> jdstrand: and the snap has a non-default HOME
<zyga> jdstrand: and that falls out of the policy
<zyga> jdstrand: that's how I understand it
<jdstrand> how does the snap have a non-default HOME?
 * zyga wonders if "falls out of sth" means anything
<jdstrand> how is that even possible?
<zyga> jdstrand: I mean the user running the snap doesn't have a normal home
<zyga> jdstrand: that particular user happens to be jenkins
<zyga> jdstrand: cat /etc/passwd and look for home directories
<jdstrand> I see what you're saying now
<jdstrand> this seems like a failing of the jenkins job that runs the snap
<jdstrand> it should set HOME to something else
<zyga> jdstrand: like?
<ogra_> hmm, how can i tell snap find to show me snaps from beta
<ogra_> seems it doesnt accept a --channel arch
<ogra_> *arg
<jdstrand> zyga: the user it is running the snap as
<zyga> jdstrand: it is running as the jenkins user
<zyga> jdstrand: not as anyone else, jenkis isn't root
<jdstrand> I'm saying that isn't a valid test
 * zyga is confused
<jdstrand> cause no one is the jenkins user
<zyga> why do you say that? jenkins runs as jenkins :)
<jdstrand> this is for the testsuite, right? it should run the tests as a user that is not special
<zyga> no, this is for whatever someone is using jenkins for
<zyga> it runs some jobs (arbitrary)
<zyga> that run commands
<zyga> some of which come from snaps
<jdstrand> this seems too arbitrary
<zyga> what is?
<jdstrand> of course we could just allow the launcher to create any directory on the system
<zyga> I know this isn't great
<zyga> but this is the reality :)
<jdstrand> it isn't though
<jdstrand> it may be the reality of jenkins
<jdstrand> but jenkins is a test runner
<jdstrand> or script runner
<jdstrand> or whatever
<zyga> yes
<zyga> I know
<jdstrand> that isn't a normal user
<zyga> I wonder if we should make the launcher ...
<zyga> well
<zyga> no :/
<zyga> it'd have to use a policy that understands $HOME
<MichaelTunnell> so snapcore doesnt accept issues on github. What is the best branch in launchpad to submit a bug for issues with Snappy's CLI actions and responses?
<jdstrand> and for the test to be valid, the test should reflect how things are actually run
<zyga> is that doable in apparmor?
<zyga> MichaelTunnell: please report it on launchpad.net/snappy
<jdstrand> the policy cannot interrogate the env for adjust policy no. that would allow trivial escapes
<MichaelTunnell> that makes sense . . . assumed it would be more specific than that :) thanks
<zyga> jdstrand: right
<jdstrand> zyga: you also need to consider that if we allowed this access, what is the next step?
<zyga> jdstrand: we could make a trusted helper :), that runs as the user (not setuid) that just mkdir's the right thing
<zyga> jdstrand: and that would not be confined
<jdstrand> zyga: ie, we get snap denial because @{HOME} doesn't match /var/lib/jenkins
<zyga> right
<zyga> (I get that)
<jdstrand> as it happens, there are ways around that with apparmor, by dropping a file into /etc/apparmor.d/tunables/home.d
<jdstrand> but I think the underlying assumption that we should change policy is wrong. we should change the test env to reflect what real users are doing
<jdstrand> looking at the policy, to make jenkins work we probably only need: '/var/ r, /var/lib/ r,' then I think the jenkins specific stuff isn't needed
<zyga> jdstrand: can you tell me more about tunables?
<jdstrand> but I maintain jenkins should have a proper home and not a special home
<zyga> jdstrand: I agree that we can solve jenkins easily by allowing /var/lib in addition to home
<zyga> jdstrand: /var/lib is debian policy
<jdstrand> zyga: there is no Debian policy for running snaps :)
<jdstrand> we have daemons and commands
<zyga> jdstrand: look at your /etc/password
<jdstrand> daemons run as root. commands as the user. the user in snappy has been defined as a login user
<zyga> jdstrand: most of those are not /home
<zyga> jdstrand: I mean for jenkins
<zyga> jdstrand: jenkins is a valid thing
<jdstrand> zyga: I know what is in /etc/passwd
<jdstrand> we're talking past each other
<zyga> jdstrand: remember that jenkins is not a snap here, anything can be running snaps
<jdstrand> I know what jenkins does
<zyga> jdstrand: I'm sorry, I didn't mean that
<jdstrand> I know Debian policy
<zyga> my point was that I think this is normal and we should find a solution that works in general
<jdstrand> I'm talking about how to properly run tests
<croepha> are you supposed to run snapcraft clean between each revision of snapcraft.yaml ?
<jdstrand> what is another example of a deb running a snap?
<zyga> jdstrand: cron
<zyga> jdstrand: anything really
<jdstrand> zyga: and cron sets HOME to the user's HOME
<jdstrand> cron is about running stuff as a specific user
<jdstrand> zyga: as for tunables, see /etc/apparmor.d/tunables/home and /etc/apparmor.d/tunables/home.d/ubuntu
 * zyga looks
<zyga> ah, so it is a compile-time mechanism
<jdstrand> I'm not sure why it is so contentious to run snaps as a login user since that is what we defined cli commands for
<jdstrand> and that is the best way to ensure the tests are testing real-world scenarios
<jdstrand> changing the policy for jenkins just makes sure it runs for jenkins
<zyga> mmm
<zyga> yep
<zyga> I agree
<zyga> swartzr: what is your use case? were you using jenkins to test your snap or were you using the snap as a part of some jenkins flow?
<ehbello> hello! I have a question... hoy can I build a gadget snap? I followed the 'Gadget snappy package' guide but after run snapcraft 2.11 I get an error because I does not recognize the gadget type :-/
<ehbello> s/hoy/how/
<zyga> ehbello: can you share the URL of the guide you read?
<zyga> ehbello: gadget snaps are not finalized and are prone to change
<ehbello> zyga: https://developer.ubuntu.com/en/snappy/guides/gadget/
<zyga> ehbello: in fact, they are changing very much right now
<zyga> oh
<zyga> mhall119, dholbach: ^^
<dholbach> zyga, ok... maybe file a bug on https://bugs.launchpad.net/developer-ubuntu-com/+filebug for anything more specific?
<dholbach> I'm not quite sure what to do now
<zyga> dholbach: we should not have a guide for gadgets
<zyga> dholbach: gadgets don't exist yet
<zyga> dholbach: anyone following that is wasting their time working on moving base
<dholbach> ok
<dholbach> can you file a bug and we'll remove it?
<zyga> yep
<dholbach> thanks
<dholbach> it'd be good to have a paper trail for this
<dholbach> so I know what to respond when people ask me why we deleted it :-)
<zyga> ehbello: we can work with you but you have to understand that image building and gadget semantis is not finalized yet
<dholbach> thanks zyga
<dholbach> ok, need to run now
<dholbach> see you tomorrow!
<ehbello> zyga: I understand. I just want to develop applications and gadgets for "snapd" and that my work is useful for the future. So I'm working on ubuntu-core 16 all-snap images and reading the latest documentation possible.
<zyga> ehbello: so depending on what your gadget snap is doing you may or may not be affected by those changes
<zyga> ehbello: we're iterating on ubuntu-image, the tool to make images, and the responsibilities of gadget snaps are changing in result
<zyga> ehbello: also some things will be added to support assertions
<zyga> ehbello: for now it's best to stick around and ask around on IRC/mailing list to know where things are heading
<zyga> ehbello: you will find that some things are not perfectly documented
<zyga> ehbello: but we're friendly so we'll gladly help you out :)
<ehbello> zyga: thank you ^^
<dusty_> Hi :) is there a way to point python interpreter (made from autotools) to include a list of python-packages brought in from python3 plugin?
<zyga> dusty_: hmm
<zyga> dusty_: can you rephrase that?
<kyrofa> dusty_, yeah I'm not quite sure what you're asking there either
<zyga> dusty_: you have a python (say python 3) binary built from source
<zyga> dusty_: and some python projects (say like those you can find on pypi)
<zyga> dusty_: and you want them to see each other?
<dusty_> okay, from kyrofa's integration tests - https://github.com/ubuntu-core/snapcraft/blob/master/integration_tests/snaps/pip-requirements-list/snapcraft.yaml
<dusty_> is there a way to have a python binary (say 2.6) include those packages as part of its path?
<dusty_> I hope that made more sense :\
<dusty_> not sure if that would have to do with environment variables?
<kyrofa> dusty_, probably using PYTHONPATH
<zyga> dusty_: set PYTHONPATH and
<zyga> ;:)
<ehbello> zyga: I guess of your words I should download the latest version of snapcraft from github to work with the development version of ubuntu-core, right?
<zyga> ehbello: no, snapcraft doesn't support gadget snaps much
<zyga> ehbello: for those are hand-made
<zyga> ehbello: we're working on tooling around that and stock gaget snaps in source form to fork as a base
<zyga> ehbello: the thing you will run into is that soon ubuntu-image will replace ubuntu-device-flash and the gadget will have to have additional data to be built
<dusty_> kyrofa, zyga: alright thanks
<zyga> slangasek: snap-confine synced to yakkety from debian
<zyga> slangasek: and now we get upgrade bugs because it somehow conflicts with ubuntu-core-launcher
<zyga> slangasek: can you please release snap-confine 1.0.33 to debian
<zyga> slangasek: and use the rules as they are spelled out in the package today
<zyga> slangasek: (!legacy mode)
<zyga> slangasek: please ping mvo to ack this
<zyga> slangasek: If you want I can make the package but I need a sponsor
<swartzr> zyga: Sorry was out to lunch. My use case is that the jenkins job is running the snap as part of a workflow. More specifically the snap is downloading files over SFTP (with some custom logic) which then the rest of the job will load the files onto a file share
<zyga> swartzr: thanks
<zyga> jdstrand: ^^
<zyga> jdstrand: so it's not about testing the snap
<zyga> swartzr: make sure this is reported on launchpad.net/snappy and we'll get it fixed
<kyrofa> jdstrand, it's easy to validate that an apparmor profile was loaded correctly by checking /sys/kernel/security/apparmor/profiles. Is there anything similar for seccomp filters?
<zyga> kyrofa: seccomp filters are loaded each time
<kyrofa> zyga, alright, I'll just check for file presence then
<kyrofa> zyga, thanks :)
<zyga> kyrofa: there might be something in /proc but I'm not sure (in the particular pid)
<ehbello> zyga: ouch... so, snapcraft lost support for gadgets since snappy tool?
<zyga> ehbello: officially it never really had support
<zyga> ehbello: I'm sure snapcraft will support gadgets
<zyga> ehbello: it's just that right now that's not being used so it might not work in practice
<zyga> ehbello: there are a few things that are unique to gadget snaps
<ehbello> zyga: ok, I understand
<swartzr> zyga: Bug is reported at https://bugs.launchpad.net/snappy/+bug/1594904
<ubottu> Launchpad bug 1594904 in Snappy "Snaps fail to run when user's home directory is not under /home" [Undecided,New]
<zyga> thanks!
<zyga> swartzr: I'll see if we can get it fixed for 2.0.10
<sgclark> hi all, I am having a terrible time getting sound to work, any tricks I need to be aware of?
<jdstrand> kyrofa: re seccomp> no. the launcher loads them into the kernel and there is nothing to introspect that afaik
<kyrofa> jdstrand, alrighty, I'll just check for the file then. Thanks!
<jdstrand> kyrofa: as was mentioned, use the files in /var/lib/snapd/seccomp/profiles
<jdstrand> right, yes :)
<swartzr> zyga: in the meantime is the best workaround to mv the directory to /home and then symlink it? Or is there a better workaround that you found in my absense?
<zyga> swartzr: I think that will work
<zyga> try it
<swartzr> zyga: Will do thank you so much.
<ehbello> zyga: do you know where are the sources of beagleblack and canonical-* gadget snaps?
<zyga> ehbello: I think so
 * zyga checks
<zyga> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<ehbello> zyga: thanks! =D
<slangasek> zyga: snap-confine 1.0.33> this package can't be in sync between Debian and Ubuntu because of the changes to the build for confinement being on or off
<zyga> slangasek: oh, good point
<zyga> slangasek: what should we do then?
<zyga> slangasek: I mean, we can . /etc/os-release
<zyga> slangasek: and then do it conditionally
<zyga> slangasek: would that be sensible?
<zyga> slangasek: (then it could sync okay)
<slangasek> zyga: I assumed that the team would continue uploading directly to Ubuntu and that I would pick them up from there for merging back to Debian
<slangasek> zyga: however, if we do want it in sync, the way to do it is using dpkg-vendor in debian/rules to manipulate the build
<zyga> slangasek: right now we have a problem, I don't know what the solution is, the problem is that the version we have in yakkety apparently synced from debian and fails to upgrade
<slangasek> zyga: that's version 1.0.30 in yakkety-proposed?
<slangasek> or which version?
<zyga> slangasek: hmm, I see upgrade bugs that cite the +2 version
<zyga> and +2 AFAIK only went into debian
<zyga> maybe I'm mis-iterpreting things and that is not true
<slangasek> zyga: ok. +2 made it into yakkety-proposed; then I removed it knowing that it would be a problem
<slangasek> so it's no longer in Ubuntu
<slangasek> and I've blacklisted it from syncing because of the confinement issue
<zyga> ah, that's good
<zyga> thanks for explaining that
<slangasek> but if we decide to get it into sync, we can drop the blacklist
<zyga> slangasek: I'll discuss with mvo, ideally using the vendor thing might mean we have less maintenance to do
<zyga> slangasek: as snap-confine is gaining new essential features quickly
<zyga> slangasek: thanks :)
<slangasek> zyga: well, how much do we care about having up-to-date snapd+snap-confine in yakkety, currently?  Because to date, we haven't had a version of snapd since 2.0.2 clear proposed-migration due to test failures
<slangasek> if that's a temporary blip and we want current snapd in yakkety, then we might also not want the delays of uploading to Debian + syncing to Ubuntu (which is always at least a 6 hour delay because of the Debian publisher cycle)
<zyga> slangasek: ideally we'd be able to release it easily to all the various distributions as cheaply as possible, yakkety is not special here, I think that right now it is not critical but we should be keeping it in sync as the release date closes
<zyga> s/closes/approaches/
<zyga> slangasek: I think it will stabilize over time
<zyga> slangasek: there's a finite set of features we want there
<wililupy> Is there a quick reference to snap environment variables?
<zyga> wililupy: some, I can also guide you :)
 * zyga looks
<wililupy> Like $SNAP_DATA?
<zyga> wililupy: that's writable data that's not specific to a user
<wililupy> I'm thinking my snap may be using old snap environment variables that no longer being used.
<wililupy> Sorry, not my snap, my code.
<zyga> (this is not documented)
<wililupy> I have a script that runs as a daemon, if it doesn't find the correct directory structure, it creates it by mkdir -p ${SNAP_DATA}/mnt/fastpath
<slangasek> zyga: ok; so we certainly need to settle on a version scheme for the packages in all of this, if we're going to be possibly syncing from Debian
<zyga> slangasek: do you think we should de-couple packaging?
<zyga> slangasek: and do upstream releases
<zyga> (as we started to for the past 5-or-so)
<zyga> slangasek: then release to debian (and optionally ubuntu if required urgently) and other distros
<slangasek> zyga: having an upstream tarball separate from the Debian packaging makes the Debian packaging part easier, but I'm not sure if there are other factors to consider
<zyga> slangasek: note that this is how fedora/arch/gentoo packaging is done today
<slangasek> which way?
<zyga> slangasek: as a typical package with decoupled upstream tarabll and downstream packaging
<slangasek> ok
<zyga> slangasek: eg. https://github.com/snapcore/snap-confine/releases/download/1.0.33/snap-confine-1.0.33.tar.gz
<zyga> that's an autotools "make dist" tarball
<slangasek> zyga: so, if we were to exclude debian/ from the 'make dist' target, and change debian/source/format to 3.0 (quilt), that should all work just fine for me
<zyga> slangasek: release tarballs don't ship debian/
<zyga> slangasek: so I guess I could make a branch that makes packaging separate
<zyga> slangasek: do you want to keep it in the repository?
<slangasek> zyga: it should be kept in the repository, and I already have a separate branch that's authoritative for the Debian packaging
<zyga> slangasek: do you want me to propose a pull request that switches to non-native packaging then?
<zyga> slangasek: and I'll let you do the rest?
<slangasek> zyga: I can work through that today along with the other packaging changes needed to have it syncable
<zyga> slangasek: thank you
<zyga> slangasek: so I'll do nothing and I'll keep doing upstream releases and downstream releases in other distros
<slangasek> zyga: zyga and that tarball is now called 'snap-confine' instead of 'ubuntu-core-launcher' - previously there was a rename of the binary package but not the source package?
<zyga> slangasek: we backed that out from debian/{changelog,control} because it would be easier to ship at the time, the package should be called snap-confine upstream as ubuntu-core-launcher is going to be removed entirely soon (likely next week, pull requests for this are pending)
<zyga> slangasek: when that happens snap-confine won't have any executables in bin
<kyrofa> zyga, jdstrand I want to write a test verifying that dbus .conf files are placed correctly for plugs, but it seems the only interface that would do such a thing is location-control/observe. Do either of you know of any snaps that provide those slots?
<zyga> kyrofa: mmm, network manager
<zyga> kyrofa: try it, it should have a policy
<kyrofa> zyga, ah very good, checking now
<kyrofa> zyga, wait, you mean the interface network manager?
<zyga> kyrofa: yes
<zyga> kyrofa: the network-manager interface
<zyga> kyrofa: you can stick it on a dummy snap
<kyrofa> zyga, no, it seems that's only for a slot
<zyga> kyrofa: just to show that it is used
<zyga> kyrofa: ahh
<zyga> kyrofa: no wait
<zyga> kyrofa: for plugs too
<zyga> kyrofa: you just have to connect it
<kyrofa> zyga, perhaps I'm misunderstanding, but both `*PlugSnippet` functions return nil,nil for dbus
<zyga> hmm
 * zyga looks
<zyga> (that's odd btw)
<kyrofa> zyga, indeed, I wonder if that's broken :P
<kyrofa> Or perhaps unfinished?
<zyga> ah
<zyga> sorry
<zyga> no
<zyga> plug side is handled with apparmor
<zyga> because that's how we can see and use the apparmor labels
<zyga> plug side won't be used by dbus much I think
<kyrofa> Ahh, oay
<kyrofa> okay*
<zyga> if you really want a test, you'd have to create a dummy interface
<kyrofa> I guess I don't want a test that bad ;)
<kyrofa> It's already unit tested with dummies
<zyga> yep
<kyrofa> Hey zyga, would you mind adding your thoughts here? It's regarding the APP_NAME variable question I asked you last week https://github.com/snapcore/snapd/pull/1373#discussion-diff-67917045
<slangasek> zyga: fyi https://github.com/vorlonofportland/snap-confine/tree/debian (will move soon to alioth.debian.org)
<zyga> slangasek: thank you
<slangasek> zyga: do you think we need mvo to weigh in on the native v. non-native packaging question, or should I JFDI from here?
<kyrofa> jdstrand, it doesn't seem that APP_NAME is being used in any of the interfaces today. Do you envision a use-case for it?
<JohnAgosta> Hi, i have a newbee question... I have a bzr branch that I can successfully 'snapcraft build' into a part. There is a script in the part's /src that I would like to expose as an app in the snap. How do I do that? I can't seen to get the snapcraft to copy it to the /install tree.
<ehbello> zyga: how can I build this beagleblack snap and others?
<jdstrand> kyrofa: I can imagine it being used. I don't have something otoh
<kyrofa> jdstrand, so if the hooks being developed also have apparmor profiles, would you suggest having a HOOK_NAME variable as well? Or perhaps we should generalize to EXECUTABLE_NAME (just throwing ideas out there)?
<kyrofa> jdstrand, but if we have no use-cases, there's a case to be made for dropping it all together
<kyrofa> jdstrand, your thoughts would be appreciated here if you have a minute: https://github.com/snapcore/snapd/pull/1373#discussion-diff-67917045
<jdstrand> kyrofa: I'll add it to my list of things to look at. I can say we used APP_NAME extensively on touch and may with personal. I'd prefer not to drop it until we know we don't need it, and I can't say we won't for personal
<jdstrand> kyrofa: but may not get to that review today (trying to get the mpris interface in order)
<kyrofa> jdstrand, alright, thank you
<sergiusens> elopio why are all our tests broken/
<sergiusens> ?
<swartzr> zyga: moving the home directory still results in the same behavior and the same error in syslog. I'm going to try reconfiguring jenkins to look to the home directory. Unless you have any other ideas?
<kyrofa> jdstrand, how is APP_NAME used on touch?
<jdstrand> kyrofa: to differentiate between apps in the same package so they may have different policy. this is all changing for snappy but I can't predict how
<kyrofa> jdstrand, interesting... they aren't separate files as they are on snappy?
<kyrofa> niemeyer1, FYI ^^
<kyrofa> niemeyer, is niemeyer1 also you? :P
<niemeyer> kyrofa: Yeah, we're a family
<jdstrand> kyrofa: they are separate files. but for example scopes and gui apps aren't supposed to share data. this is because network scopes aren't supposed to have access to the filesystem since the scopes infrastructure can't prevent data theft
<niemeyer> jdstrand: We already differentiate interfaces based on app, right?
<jdstrand> yes
<jdstrand> that isn't what I'm talking about
 * niemeyer misses the "Typing..." note :)
<jdstrand> I'm talking about using @{APP_NAME} in the policy. we don't (yet) in snappy. we do in click. without designing the migration of click to snaps and what policy would look like now, I can't predict that we will never use @{APP_NAME} in snappy
<niemeyer> jdstrand: Well, how's that not what I just said?
<jdstrand> I thought you were talking about the file name
<jdstrand> which was kyrofa's previous question
<jdstrand> we are talking about template_vars.go, right?
<kyrofa> jdstrand, indeed
<niemeyer> jdstrand: I'm talking about your point that we may want to use the app name in policy to differentiate apps in the same package
<niemeyer> jdstrand: We already do that for several interfaces
<niemeyer> jdstrand: Practical example:
<niemeyer>    peer=(label=###SLOT_SECURITY_TAGS###),
<jdstrand> in the various existing interfaces code we don't rely on template_vars.go for @{APP_NAME}
<jdstrand> yes
<niemeyer> This is binding to a particular name
<niemeyer> So my theory about why we're not seeing the application name is because we have something better
<jdstrand> but that doesn't mean we won't *ever* use @{APP_NAME} in the apparmor policy
<jdstrand> maybe
<jdstrand> like I said. we haven't designed the touch migration
<jdstrand> and I can't predict we will *never* need it since all the touch policy needs to be converted to interfaces for personal
<niemeyer> jdstrand: Well, I also can't say we won't *ever* use something :)
<kyrofa> Can we add them when we need them?
<jdstrand> so I'm just playing it safe
<jdstrand> it sounds like you want to use it for hook name
<jdstrand> which is not the app name
<kyrofa> jdstrand, I don't care one way or the other-- we could also add HOOK_NAME
<niemeyer> Can we please drop it?  We have the whole context inside the interface to cook whatever we want when we need to
<jdstrand> so removing it now to add it to be used by hook name to possibly add it later sounds weird to me
<niemeyer> We are already using security tags on interfaces, which is effectiely *exactly* the app name
<niemeyer> snap.<snap>.<APP NAME>
<niemeyer> Except it's properly namespaced, which means better
<jdstrand> sure, but app name might be used for other things, like file paths
<niemeyer> jdstrand: WE have the app name too..
<niemeyer> jdstrand: We have both the plug and the slot
<niemeyer> jdstrand: and in fact.. I suspect APP_NAME will likely not work as we want it to
<jdstrand> look, it can be removed. people asked my opinion. I would prefer to not remove it cause I don't know the migration path since we aren't anywhere near migrating to personal. it seems harmless to leave it
<niemeyer> jdstrand: Because it doesn't consider the problem of aggregating the several app names
<jdstrand> I wasn't suggesting we use APP_NAME in security labels. we do that fine in interfaces
<jdstrand> I'm talking about other policy in the filesystem
<jdstrand> where perhaps we want to differentiate between apps. we had a need for that on touch. I don't know if that need (or others) goes away yet
<swartzr> zyga: moving the home directory still results in the same behavior and the same error in syslog. I'm going to try reconfiguring jenkins to look to the home directory. Unless you have any other ideas?
<zyga> swartzr: hmm
<zyga> swartzr: no, I don't have any ideas
<zyga> swartzr: did you restart jenkins?
<zyga> swartzr: and perhaps also change the home in /etc/passwd
<zyga> swartzr: then restart jenkins
<zyga> swartzr: (set it to /home/jenkins for example0
<niemeyer> jdstrand: Okay, thank you.. the context is indeed appreciated
<jdstrand> zyga: can you enlighten me on something. I'm looking at all.go and all_test.go. Why do some interfaces have New with DeepContains and others lack New, use &builtin and use Contains?
<kyrofa> Indeed, thank you jdstrand
<niemeyer> jdstrand: I'd prefer to remove it though, based exactly on security concerns.. we have hooks and apps, and we don't know the right thing to put there because we don't have a use case
<niemeyer> jdstrand: This may easily be a serious bug, with a string that should be filled ending up empty, or having a name that conflicts with a real app
<niemeyer> jdstrand: So, on that basis, let's remove and re-add when we know more
<jdstrand> if it is better to remove-- that's fine. it seems clear that so far on snappy we haven't needed it. I'd prefer that we not conflate hook name with the app name though
<zyga> jdstrand: that's just a go thing, some of those use a NewFoo method to create an instance while others have no state at all and are just a simple object
<niemeyer> jdstrand: Removing is dropping one line, and that variable cannot be used without also changing the code, so no real damage
<zyga> jdstrand: for the former you have to use DeepContains, for the latter you can use Contains
<zyga> jdstrand: maps, slices and pointers want you to use DeepContains AFAIR
<niemeyer> jdstrand: Right, precisely.. the names are not conflated, except for that one case
<niemeyer> jdstrand: They have different security tags, different paths in the FS, different entries in snap.yaml
<niemeyer> jdstrand: On this case we don't know what to do because there's no use case for that variable
<jdstrand> zyga: interesting. what is also interesting is that it seems to correspond to os supplied interfaces and slot-providing snaps
<zyga> jdstrand: thats just accidental today
<jdstrand> ok
<jdstrand> zyga: thanks!
<zyga> just depends on what the type has inside
<zyga> jdstrand: deep contains works always
<jdstrand> :w
<jdstrand> meh
<zyga> jdstrand: I saw your comments on the interfaces, I'm currently taking my evening slack but I'll go around and update and merge the two new interfaces
<jdstrand> zyga: cool. I'm working on mpris
<swartzr> zyga: I'll try that thanks
<swartzr> zyga: and yes I did restart jenkins
<jdstrand> so far it seems it closer to a slot side and plug side thing. working through those details
<zyga> jdstrand: I thought that mpris coudl be a new interface
<jdstrand> yes
<zyga> jdstrand: e.g. a front-panel device that does mpris slot
<jdstrand> that is what I am thinking
<zyga> jdstrand: classic exposing mpris
<zyga> etc
<zyga> and apps would do auto-connectable plugs
<jdstrand> the is the player side (slot) and the controller side (plugs)
<zyga> jdstrand: note that we have a nice way to change auto-connect candidates
<zyga> jdstrand: hmm
<zyga> jdstrand: actually I was thinking the reverse
<zyga> jdstrand: but to be hones, this feels that it can be any
<zyga> honest*
 * zyga cannot type
<jdstrand> well, let me continue my investigation and we can discuss in the PR
<zyga> jdstrand: anyway, the point about auto-connect is for later :)
<zyga> jdstrand: but we could even auto-connect to any viable target if there's no slot (or plug) on the core snap
<elopio> sergiusens: I don't really know what else to do with the microphone, it worked this morning. Want to talk about registration here?
<sergiusens> elopio so about jenkins, can you take over making sure trunk passes?
<sergiusens> elopio about registration, just wondering what you meant by simple
<sergiusens> kyrofa a review of this would be nice https://github.com/ubuntu-core/snapcraft/pull/588/files (aside from josepht)
<jdstrand> zyga: I think you had a patch for this, but fyi: this still doesn't work: sudo /tmp/snap connect vlc:mount-observe :mount-observe
<jdstrand> zyga: I mention it cause this works: sudo /tmp/snap connect vlc:mount-observe ubuntu-core:mount-observe
<elopio> sergiusens: yes, I'm updating the parts and waiting for the last two jobs to restart. And about simple, I mean that the branch only registers or fails. The full workflow involves to error when trying to upload an unregistered snap, to provide nice feedback when the name is reserved, and the private flag which I don't yet know what is for.
<jdstrand> zyga: and 'ubuntu-core' is not cross-distro-friendly. perhaps that becomes core:mount-observe? anyway-- not blocked. fyi
<swartzr> zyga: That worked! Thank you so much! I can now scrap this "Yeah this isn't going to work" email to my boss.
<sergiusens> elopio oh, that's fine, we can create wishlist bugs for those
<zyga> swartzr: sweet, thank you for your patience!
<zyga> jdstrand: yep, I know
<zyga> jdstrand: it will be just core and :
<zyga> (name not required)
<ehbello> zyga: before you disconnected, I asked you.... what tool or version of snapcraft I need to build this beagleblack snap and others?
<zyga> ehbello: I think those are not built with snapcraft
<zyga> ehbello: just look at the source, they are built with the raw lower level tools
<mhall119> sergiusens: are you still around?
<sergiusens> mhall119 yes
<mhall119> sergiusens: I'm stuck on pkg-config stuff with https://github.com/ubuntu/snappy-playpen/tree/pantheon-mail/pantheon-mail
<mhall119> tl;dr, the latest Pantheon Mail client needs Granite 0.4, but the archives only have 0.3, so I build 0.4 from upstream source and need the "mail" part to find it, but it doesn't
<zyga> mhall119: pantheon mail snap?! :)
<mhall119> zyga: well that depends on whether or not sergiusens can help me :)
<mhall119> zyga: if he can, I'll be proposing a new interface for snapd later
<sergiusens> mhall119 can't you build pkg-config from source?
<mhall119> sergiusens: build pkg-config itself?
<sergiusens> as a part that gets staged
<sergiusens> yeah
<mhall119> sergiusens: it's not that I'm missing pkg-config, it's that when pkg-config runs on the "mail" part it doesn't find libgranite 0.4 what is built in the "granite" part
<mhall119> so ./configure on the "mail" part fails saying it needs libgranite
<zyga> mhall119: ignore pkg-config, you don't need any newer verion, you need granite itself
<mhall119> yes
<sergiusens> mhall119 oh, ic, I thought you needed a newer pkg-config
<mhall119> I need the version of granite built by the part
<mhall119> sergiusens: no, well I hope not anyway, I just need it to look in the right places
<mhall119> sergiusens: run that snapcraft.yaml in a cleanbuild and you'll see
<mhall119> granite appears to build fine and get installed into ./stage/
<mhall119> then when it moves on to the "mail" part it fails saying pkg-config can't find the granite dependency
<zyga> mhall119: how is granite configured
<mhall119> if I add the 0.3 granite into build-packages instead of building 0.4 in a part, everything builds fine but panteon-mail crashes when run because it needs the newer version
<zyga> mhall119: is --prefix=/usr
<zyga> mhall119: if not you won't find pkg-config information file in the right spot
<mhall119> zyga: -DCMAKE_BUILD_TYPE=Release, -DCMAKE_INSTALL_PREFIX=/usr, -DCMAKE_INSTALL_LIBDIR=/usr/lib
<zyga> mhall119: oh, cmake (/me barfs)
<zyga> mhall119: anyway, look where the .pc file is
<sergiusens> zyga yeah -DCMAKE_INSTALL_PREFIX=/usr
<zyga> mhall119: and check where snapcraft sets PKG_CONFIG_SYSROOT_DIR
<sergiusens> mhall119 is that required btw ^?
<mhall119> zyga: PKG_CONFIG_SYSROOT_DIR was /root/stage/ I believe
<mhall119> sergiusens: is what required?
<sergiusens> zyga no need, mhall119 run ./parts/<part-name>/bin/pkg-config <options> <module-name>
<sergiusens> mhall119 if setting the install prefix is required
<mhall119> sergiusens: I don't know if it is or isn't
<sergiusens> mhall119 you know that once in the snap it won't be at that prefix, right?
<mhall119> yes
<mhall119> let me re-run so I can see where the files are
<mhall119> sergiusens: but if you run it you will be able to see it faster
<mhall119> sergiusens: ./stage/usr/lib/pkgconfig/granite.pc
<sergiusens> mhall119 you have high expectations of me working in "convergence" mode on the tablet ;-)
<sergiusens> sure, I'll look
<sergiusens> also, my bandwith is 3Mbps ;-)
<zyga> sergiusens: \o/
<sergiusens> mhall119 the build just fails for me
<sergiusens> http://pastebin.ubuntu.com/17661758/
<mhall119> huh, doesn't do that for me....
<mhall119> sergiusens: try a cleanbuild?
<sergiusens> elopio so how long do we wait for the jenkins bring up?
<mhall119> sergiusens: http://paste.ubuntu.com/17662567/ is the error I get, btw
<mhall119> sergiusens: I've also pushed a new version of the yaml to github, it removes some package dependencies that weren't really needed
<mhall119> http://paste.ubuntu.com/17662693/ is the .pc file in ./stage/
<mhall119> sergiusens: I assume that it's something wrong in my snapcraft.yaml but for the life of me I can't figure out what
<sergiusens> mhall119 maybe not, pkg-config isn't the best thing when it comes to multiple sysroots
<croepha> what do you put for "Project contact" in the contributor agreement?
<elopio> sergiusens: it is up. I'm monitoring the first run.
<mhall119> croepha: which project are you contributing to?
<croepha> snapcraft
<mhall119> croepha: put Jamie Bennett then
<mhall119> jamiebennett: ^^ is that correct?
 * mhall119 notes it's 10pm his local time, so he's probably not going to respond
<jamiebennett> mhall119, Sure
 * mhall119 notes his surprise that he's still online
<jamiebennett> (I'm in a different TZ this week)
<mhall119> oh, are you in Boston?
<jamiebennett> yes
 * mhall119 waves from down south
<croepha> cool, thanks
<mhall119> croepha: thank you for contributing :)
<croepha> no prob :)
<croepha> is there a requirements.txt for dev?
<croepha> nvm, its in the travis file
<sergiusens> croepha is this snapcraft? We are waiting to discover why it kills our packaging (to add a install_requires entry)
<croepha> yes for snapcraft
<sergiusens> croepha great, can't wait to see what you propose
<croepha> it looks like there already is install_requires in setup.py, but thats the run time deps, I was hoping there was a quickstart guide for development, but the travis.yaml file looks like its got all the info on how to get tests running
<sergiusens> croepha I just do `sudo mk-build-deps -i`
<sergiusens> which creates a fake deb with all the deps
<croepha> ahh, nice trick
<sergiusens> mhall119 ok, my cleanbuild is stuck pulling granite
<mhall119> stuck?
<sergiusens> mhall119 yes, bzr ftw ;-)
<sergiusens> going to leave it there for a bit
<sergiusens> mhall119 in the meantime here is a thought; if this .pc file for granite depends on other .pc files they need to all live under the same sysroot
<mhall119> oh, really?
<sergiusens> mhall119 as I said, pkg-config is sort of dumb in this aspect and cannot handle multiple sysroots
<mhall119> so, um, how do I accomplish that with separate parts?
<sergiusens> mhall119 if it is all in parts it is mostly fine, the problem comes more so when those .pc files come from the main installation (build-packages)
<sergiusens> so if you are keen on using ubuntu, a start would be to transform those to either proper parts built from source or to change them to stage-packages (the `-dev` ones and use filesets so your snap doesn't get huge)
<mhall119> sergiusens: make the -dev packages stage-packages in which, the granite or the mail part?
<tedg> sergiusens: If I want to use an organize rule for my desktop file in the snap should it go in setup or meta?
<sergiusens> mhall119 the one that provides the .pc files as it probably needs them for building anyways
<sergiusens> tedg `organize` cannot touch meta nor setup
<mhall119> sergiusens: the granite part provides the granite.pc, the rest were being pulled in the mail part's build-packages
<tedg> sergiusens: Hmm, so how do I get the snap to use the desktop file after translations have been merged?
<sergiusens> tedg I am inclined to remove all the "by convention" stuff in snapcraft (which was to follow a snap/d trend) and just go and make it all declarative
<sergiusens> tedg you cannot do that today
<sergiusens> tedg unless your snapcraft.yaml lives in the root of the sources, therefore you could link to setup
<sergiusens> mhall119 can I see granite.pc?
<mhall119> sergiusens: http://paste.ubuntu.com/17662693/
<sergiusens> mhall119 try stage-packaging all of these cairo gee-0.8 glib-2.0 gio-unix-2.0 gobject-2.0 gthread-2.0 gdk-3.0 gdk-pixbuf-2.0 gtk+-3.0 in the granite part
<mhall119> sergiusens: those packages, or their -dev equiv?
<sergiusens> mhall119 the -dev's
<tedg> sergiusens: Reread that twice, and I'm confused :-) I agree that it shouldn't be by convention. While I do have my snapcraft.yaml in the root of the source, I don't know how that changes things.
<sergiusens> tedg is the desktop file generation a build time thing?
<tedg> I'd also agree that snapd shouldn't copy them to a random directory, but that's another story :-)
<sergiusens> or is it already there comitted to source?
<tedg> sergiusens: Yes, merges with the po files. Starts as desktop.in
<sergiusens> oh, then my subtle suggestion won't work
<mhall119> tedg: https://bugs.launchpad.net/snapcraft/+bug/1588359 mark it as affecting you :)
<ubottu> Launchpad bug 1588359 in Snapcraft "No way to add setup files at build time" [Undecided,New]
<tedg> sergiusens: FWIW, I think everyone with a desktop file merges it at build time with translations.
<sergiusens> tedg what is a translation?
<sergiusens> :-)
 * sergiusens jokes
<tedg> sergiusens: It's how we make people in Texas use the phone.
<tedg> ;-)
<tedg> mhall119: Done and added a comment about the desktop file.
<sergiusens> tedg by declaration I hope ;-)
<tedg> Gun point, like everything in Texas.
<mhall119> sergiusens: ok, I've a whole mess of .pc files in ./stage/usr/share/pkgconfig/ now, but still getting the same error
<mhall119> including a .pc file for everything listed in the Requires line of the granite.pc
<mhall119> sergiusens: http://paste.ubuntu.com/17665800/
<sergiusens> elopio want tp update https://github.com/ubuntu-core/snapcraft/pull/586 ?
#snappy 2016-06-22
<numa> hola! how to install snapd on centos-7 ?
<sergiusens> elopio do we have a bug for register
<Son_Goku> numa, you don't yet
<Son_Goku> zyga didn't enable EL7 in his Copr: https://copr.fedorainfracloud.org/coprs/zyga/snapcore/
<numa> Son_Goku: womp womp... thanks :)
<elopio> sergiusens: we have one for upload without register. That's what I was trying to say in the standup. I'll file a new one.
<sergiusens> elopio to late, but feel free to make it bug sru friendly
<ddellav> im having an issue running the snapcraft tour. I installed the hello snap i created but the "hello" command is not available. I get command not found in zsh and in bash it suggests I install hello or hello-traditional
<ddellav> im running xenial
<elopio> ddellav: hello. What if you run /snap/bin/hello ?
<ddellav> elopio i get: failed to create user data directory. errmsg: Permission denied
<ddellav> should i use sudo?
<elopio> ddellav: no, you shouldn't. Maybe, your user directory is not in /home ?
<ddellav> elopio pwd = /home/david/snapcraft-tour/00-SNAPCRAFT/01-easy-start
<elopio> ddellav: so, maybe your home is encrypted ?
<ddellav> elopio hmm, i may have selected that when I first installed months ago but right now it's in use so it's not currently encrypted or doesn't that matter
<elopio> ddellav: I'm asking those questions because those are the two bugs open that print your error. The encrypted home is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696
<ubottu> Launchpad bug 1592696 in ubuntu-core-launcher (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,Fix released]
<qengho> Hmm. I have ecryptfs home.
<elopio> ddellav: can you check your /var/log/syslog to confirm that?
<ddellav> elopio yes i see in the bug report there's a workaround for apparmor
<ddellav> and this is in my syslog: Jun 21 22:00:22 loki kernel: [ 1626.709398] audit: type=1400 audit(1466560822.050:49): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/david/.Private/" pid=17745 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<elopio> ddellav: the bug says fix released, so maybe first try to upgrade before applying the workaround
<ddellav> elopio i actually just installed snap and snapcraft less than an hour ago
<ddellav> so perhaps it's not published yet
<ddellav> or maybe i need to modify my repos
<elopio> ddellav: the bug is not in snapd, it's in ubuntu-core-launcher. So there's still a chance that you have an old one. Or it hasn't been published. Or the bug is still open :)
<ddellav> elopio gotcha, well thanks for the direction, at least i know im not crazy now :)
<elopio> ddellav: np. Welcome to the snappy world. Please let us know if you have any other problems.
<ddellav> will do
<qengho> ddellav: If you're feeling brave, you can work around it pretty easily and not wait for the release that fixes it for everyone.
<ddellav> qengho yea, im messing with the apparmor stuff now heh
<ddellav> i might just disable it entirely if this doesn't work
<qengho> ddellav: In /etc/apparmor.d/usr.bin.ubuntu-core-launcher, near "@{HOME}/snap/{,*/,*/*/} rw,", add a new line "/home/.ecryptfs/david/.Private rw," and then "apparmor_parser -r /etc/..." to reload it.
<qengho> It's not the Right Way, but it will get you to a place you can play.
<ddellav> qengho for some reason that didn't work but i just copied and pasted the apparmor changes from the bug report and that seemed to do it
<ddellav> and now i get: Hello, world!
<ddellav> woot
<ddellav> now I have to figure out why it wont run when i just to use the command
<ddellav> i guess somewhere along the line my path wasn't updated or something
<qengho> Hrm. I have a snap with a service that has been installed many times. Runs well. Just installed on new 2.0.9 armhf machine. There is no systemd "service" for it. $ systemctl |grep tor-middle-relay.*service  #shows nothing on new machine
<tsimonq2> elopio: you said you would look at my PR again?
<qengho> ddellav: On snapd install, log-in profile is updated, so no visible until next shell init. Try "bash -l".
<ddellav> qengho yea, no dice :(
<qengho> ddellav: Try ". /etc/profile"
<ddellav> i dont see any modifications to .profile or .bashrc so maybe it failed because of the apparmor problem
<qengho> ddellav: it would never touch personal files. :)
<ddellav> qengho . /etc/profile works but it puts me into a prompt with only a $
<qengho> ddellav: What shell do you use?  $ echo $SHELL
<ddellav> qengho zsh
<qengho> ddellav: you alien!
<ddellav> lol
<ddellav> i tried it with bash too and it didn't work. When i did bash -l it still didn't include the path
<ddellav> this is obviously a config issue on my side. I must not be including the system wide config somehow
<qengho> ddellav: $ grep PATH= ~/.??*
<ddellav> ah ha
<ddellav> that was it
<ddellav> the .zshrc was not including the existing $PATH
<ddellav> eh, now i've got a bunch of duplicated directories in my $PATH
 * ddellav sighs
<ddellav> ok, i did away with setting the path in zsh altogether
<ddellav> thanks qengho for getting me squared away
<qengho> Welcome!
<qengho> (Incidentally, I found my problem is same as LP: #1584456)
<ubottu> Launchpad bug 1584456 in Snappy "apparmor denial using ptmx char device" [Undecided,Confirmed] https://launchpad.net/bugs/1584456
<ddellav> i may be asking this too quickly, im still going through the tour and learning but it looks like  snaps have built-in plugs for things like make, node, python, etc. Is there any way to add plugins? For something like composer perhaps?
<qengho> ddellav: A plugin is only for building things. And you can add your own, yes, in parts/plugins/x-ddellavsomething.py
<ddellav> qengho yes, i want to try to build a snap package for a project i run which is currently using composer so it would be awesome to package that together as a composer install is an annoying process
<ddellav> requiring a curl bang
<qengho> I don't know "composer".
<ddellav> it's npm for php
<qengho> tld?
<qengho> tla. Ugh.
<ddellav> sorry, node package manager
<ddellav> composer is a package manager for php apps
<ddellav> similar to pip as well. instead of requirements.txt you have a composer.json
<qengho> ddellav: okay. Sure. Beware that it might not make sense, unless it's installing packages inside its $SNAP_DATA dir. Snap programs can't write just anywhere.
<ddellav> qengho i think it will work as intended but we shall see
<qengho> :)
<ddellav> eventually I want to try to get snaps working for openstack packages as well
<ddellav> though that will be a much larger job lol
<slangasek> zyga: FYI snap-confine 1.0.33-1 has been uploaded to the Debian NEW queue now (will at some point show up at https://ftp-master.debian.org/new.html); Vcs-Git moved to git://anonscm.debian.org/collab-maint/snap-confine.git
<zyga> slangasek: \o/ thank you
<zyga> slangasek: did you do the dpkg-vendor thing you mentioned?
<zyga> mvo: ^^ FYI
<mvo> zyga: in what way are we using a different configuration? just curious
<hamiltino> i have a .snap file, any know how to install it?
<zyga> hamiltino: sudo snap install ./path/to/that/snap
<zyga> mvo: debian doesn't have all the confinement bits enabled
<zyga> mvo: but snap-confine unlike snapd does a compile-time decision
<zyga> mvo: slangasek propsed using dpkg-vendor to configure snap-confine differently on ubuntu
<hamiltino> i get: cannot read snap file: cannot open snap: unknown header: "!<arch>\ndebian-binar
<zyga> hamiltino: that's a snap from 15.04
<zyga> hamiltino: that snap won't run on 16.04 system, you have to rebuild it
<zyga> dholbach: good morning
<hamiltino> can a 16.04 snap work on a 15.04 system?
<zyga> hamiltino: no
<zyga> hamiltino: you would have to rebuild it from source
<zyga> hamiltino: the format changed significantly
<dholbach> hey zyga
<tsimonq2> mvo: could you take a minute to test my Mutt snap please?
<mvo> tsimonq2: I get http://paste.ubuntu.com/17686195/ at the end - i woder if a fakeroot somewhere is missing
<mvo> tsimonq2: i.e. I think "chmod 2755 /tmp/mutt/parts/mutt/install/bin/mutt_dotlock" needs to be run via fakeroot, maybe its fine to run the entire build with fakeroot even
<tsimonq2> mvo: what's fakeroot? :)
<mvo> tsimonq2: its a clever program that makes build systems believe they are running as root :)
<mvo> tsimonq2: "apt show fakeroot" has some more info
<mvo> tsimonq2: ha! fakeroot snapcraft makes it work
<mvo> tsimonq2: and it works, how neat!
<mvo> tsimonq2: hm, almost
<tsimonq2> 03:51:24 AM < mvo> tsimonq2: ha! fakeroot snapcraft makes it work
<tsimonq2> 03:52:15 AM < mvo> tsimonq2: and it works, how neat!
<tsimonq2> 03:53:47 AM < mvo> tsimonq2: hm, almost
<tsimonq2> whoops
 * tsimonq2 kicks his terminal
<mvo> tsimonq2: it does work
<mvo> tsimonq2: it is just a bit confused because ubuntu-core-launcher changes HOME
<tsimonq2> Qterminal has this nice "Paste selection" function that is really awesome, except in IRC :P
<tsimonq2> anyways
<mvo> tsimonq2: so yeah, run `fakeroot snapcraft` and its there :)
<zyga> tyhicks`, jdstrand: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1595092
<ubottu> Launchpad bug 1595092 in Snappy Launcher "rpmlint complains about POS36-C" [Critical,New]
<tsimonq2> mvo: so I should leave a note that snapping it should be done with fakeroot?
<didrocks> I think you need to change the build system to have it running under fakeroot
<didrocks> or you will never be able to get it build under builders
<didrocks> for instance
<didrocks> so, I think it's something about have "make" replaced with "fakeroot make" and adding a build-packages: [fakeroot]
<tsimonq2> didrocks: so I might just write a custom plugin that just takes the autotools plugin and puts fakeroot in front of make and make install, that might work
<tsimonq2> right?
<didrocks> tsimonq2: yeah, if you can inherit from the autotools plugin, and even, maybe patch is to make is more generic so that your custom plugin is just a 3 or so linesâ¦ :)
<tsimonq2> :)
<mvo> tsimonq2: yeah
<ePierre> didrocks, hi!
<ePierre> didrocks, I saw your e-mail on the snapcraft ML quoting https://lists.ubuntu.com/archives/snapcraft/2016-June/000235.html
<ePierre> didrocks, so the Ubuntu store will support devmode-snaps?
<zyga> ePierre: yes
<didrocks> indeed
<ePierre> zyga, didrocks but isn't devmode... well, for developers/testers only? :D
<didrocks> be aware about the restriction on the stable channel
<didrocks> and people will have some warnings if installing devmode snaps from another channel
<didrocks> this will help you to distribute to testers :)
<ePierre> didrocks, ok I see! Thanks
<didrocks> yw ;)
<willcooke> didrocks, should I be able to write to $SNAP_DATA if I run bash in my launcher script instead of the actual application binary?
<willcooke> e.g. qt5-launch bash
<willcooke> $ touch $SNAP_DATA/hello
<joc_> willcooke: pretty sure SNAP_DATA is only writable by root
<willcooke> joc_, that ties in with what I'm seeing, thanks
<didrocks> yep, only root can write to it
<ogra_> willcooke, you want $SNAP_USER_DATA
<willcooke> got it
<ogra_> also use /bin/sh ... there is no guarantee that bash will stay in the core snap
<willcooke> ack
<matteo> zyga: it was a CDN issue!
<gouchi> hi
<zyga> hey
<gouchi> any update on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860 ?
<ubottu> Launchpad bug 1570860 in snapd (Ubuntu) "Love2D needs udev access" [Medium,Triaged]
<gouchi> To make some test I can try to edit snapd interface rules ?
<gouchi> https://github.com/snapcore/snapd/tree/master/interfaces/builtin in here ?
 * zyga looks
<zyga> gouchi: you can help, for sure :)
<zyga> what is the actual device that is being accessed?
<zyga> is that a GPU or some other thing?
<gouchi> zyga: same as /run/udev/data/cXX so related to gamepad and joystick
<jdstrand> zyga: I'm pretty sure that was an active decision (setgroups). I'll let tyhicks` comment cause I think he and sarnold reviewed that code
<jdstrand> qengho: you mentioned bug #1584456 as your problem. Can you sync with tyhicks` when he comes online (he was looking at that)
<ubottu> bug 1584456 in Snappy "apparmor denial using ptmx char device" [Undecided,Confirmed] https://launchpad.net/bugs/1584456
<ogra_> hmm, wasnt the /dev/shm fix in snapd 2.0.9 ?
 * ogra_ still sees it with the package from proposed
<jdstrand> what fix are you referring to?
<zyga> jdstrand: thanks
<ogra_> jdstrand, chromium based apps need it
<zyga> jdstrand: please keep this in the bug report there, it will be referenced by other packaging systems
<ogra_> i thought there was a fix in the works for it
<jdstrand> ogra_: not for chrome
<ogra_> to treat it like /tmp
<jdstrand> not for chrome
<ogra_> hmm, k
<jdstrand> there was a fix that allows snaps to have access to stuff in /run/shm
<ogra_> olli__, pinging again for putting back the bug links into the topic :)
<jdstrand> but chrome needs to modify its path to do that
<ogra_> right, but i only have a binary for the app
<jdstrand> or someone needs to write the preload library that is in the bug
<jdstrand> olli__: hence the 'not for chrome' :)
<ogra_> and by default all chromium wrapped apps use /dev/shm/.XXXXX
<jdstrand> I've talked to upstream. there is a bug on this. there is a plan if upstream doesn't change. I don't think anyone is assigned to that bug
<ogra_> jdstrand, well, the app is based on chromium, not chrome ...
<jdstrand> same difference
<ogra_> (i dont have the source for the wrapper bit thoough)
<ogra_> ok
<jdstrand> there appears to not be consensus if snapcraft should own that library or snapd. so no one is working on it. iirc, zyga has some poc code
 * jdstrand is just reporting the issue and is not working on that
<ogra_> yeah
<jdstrand> mvo: hi, are you in charge of snapd 2.0.10 release? I ask cause I think it is very important that mpris interface is in 2.0.10
<mvo> jdstrand: I can wait for this to land
<mvo> jdstrand: 2.0.9 is not in updates yet, I am chasing this right now
<jdstrand> zyga: do you have a moment to talk about your mpris comment?
<jdstrand> pindonga (cc noise][1): hey, can you sync r680 to the store for home autoapprove? (fyi niemeyer1)
<jdstrand> morphis, nessita: hey-- I see a bunch of bluez packages in the store. 4 from 20 days ago and 2 from 5 months ago. nessita since you are up on this issue, would you mind handling the store review?
<nessita> jdstrand, the bluez package was moved from a private store to the public store, maybe that's why is showing now?
<jdstrand> nessita: that's my guess, but I'd rather not guess in the review and let someone close to the issue have a look :)
<jdstrand> nessita: unless you tell me its fine, then I'll just push approve
<nessita> jdstrand, let me check
<morphis> jdstrand, nessita: the ones from 20 days ago should be the current ones
<morphis> jdstrand, nessita: but maybe we should drop those and let me redo the upload process to get everything into a sane state
<zyga> jdstrand: yes
<zyga> jdstrand: let's talk about mpris
<nessita> morphis, I was going to ask, the failures i was seeing from the review process do not seem harmless
<zyga> jdstrand: we can also talk about the shm thing next
<zyga> jdstrand: I'd like someone to own that thing
<nessita> morphis, if you confirm
<nessita> reserved interface 'bluez' for vetted applications only security-snap-v2_plug_safe (client, bluez)
<zyga> attente_: hey, where are the patches required for gnome-software to install snaps?
<nessita> morphis, is OK I can approve those
<jdstrand> nessita: that's fine. it came from Canonical
<morphis> nessita: let me have a quick look
<jdstrand> zyga: I left a comment in the mpris PR for you
<nessita> jdstrand, right, so your doubt was mainly about those appearing now (all the sudden)
<jdstrand> nessita: yes
<morphis> jdstrand, nessita: https://myapps.developer.ubuntu.com/dev/click-apps/3595/rev/9/ should be the latest one
<attente_> zyga: it's on this branch at git.gnome.org: https://git.gnome.org/browse/gnome-software?h=wip/ubuntu-xenial
<morphis> nessita: just one quick thing, can I migrate a snap in the store to another channel?
<zyga> attente_: is that heading upstream?
<nessita> morphis, yes, just click the "Edit" link next to the channels line in a revision details page
<morphis> nessita: ok, done
<nessita> morphis, so we should approve revision 9 and reject 3 to 8?
<morphis> nessita: for bluez, yes
<nessita> on it
<mvo> jdstrand: if you could have a look at https://github.com/snapcore/snap-confine/pull/43 that would be great! part of the new content-sharing work
<jdstrand> mvo: my plan was to move to content sharing after mpris. mpris is almost done. does that work for you? iirc, both of these are for 2.0.10///
<morphis> nessita: and for network-manager it is https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/
<jdstrand> mvo: oh, actually, I think tyhicks` may want to look at that particular PR. iirc, he had some thoughts on parsing mountpoints
<zyga> jdstrand: we've used his idea (glibc parser)
<zyga> jdstrand: FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=986050
<ubottu> bugzilla.opensuse.org bug 986050 in Audits "AUDIT-0: snappy: snap-confine setuid root" [Normal,New]
<zyga> jdstrand: that bug is about auditing snap-confine so that it can be setuid root
 * jdstrand nods
<jdstrand> zyga: did you see my comment in the mpris PR?
<zyga> jdstrand: no, let me refresh
<jdstrand> zyga: also, the continuous integration test is failing for something unrelated to the PR AFAICS
<nessita> morphis, this is the final mapping https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/
<attente_> zyga: i don't think robert proposed it yet, but i assume it'll apply upstream
<zyga> attente_: is robert going to work on that?
<nessita> jdstrand, so bluez is no handled. For network-manager, I'm unsure about approving https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/
<nessita> a couple of unknown interfaces there
<zyga> jdstrand: ok, let's talk about mpris now; my reasoning was that since unity provides one of the mpris elements (the controller) it would gain an implicit slot so that players could auto-connect to it (on classic)
<jdstrand> nessita:  i can do the nm review. there might be a tooling issue
<zyga> jdstrand: the actual sides are somewhat arbitrary IMHO (unless I'm missing something) and it could be either a plug or a slot equally well
<zyga> jdstrand: for the slot it would be easier to support since the code in snap/implicit.go only adds implicit slots today
<morphis> nessita: now I see what I did, we have to publish rev 5-8 for bluez too, those are the other architectures
<zyga> jdstrand: but if you feel strongly about it I could extend it to handle implicit plugs as well
<jdstrand> zyga: my mental map is that a slot provides something for things to use. flipping it in this manner is confusing to me. also, I allow, on classic, for unconfined to control the player
<jdstrand> I think it sounds weird to connect to a remote
<jdstrand> I think a remote connects to a player
<nessita> morphis, ok, let me see if I can approve the one I already rejected ;-)
<zyga> jdstrand: you assume people know what mpris is :)
<zyga> jdstrand: for me it is the thing in the top-right corner, in the sound menu
<morphis> nessita: :-)
<jdstrand> I read the spec-- I picked the sides that seemed to best work with it
<zyga> jdstrand: while I simplify, I doubt many people know what that stands for and which side is which
<zyga> jdstrand: but users will be used to connecting plugs to slots on the classic core snap
<zyga> jdstrand: again, this is all a "feeling" observation, I'm fine with it being a plug too, it just needs more work
<jdstrand> zyga: note that vlc doesn't show up in indicator sound at this time. also note, that people don't have to do anything on classic for it to work. on classic, I add rules that let's unconfined connect
<jdstrand> actually, I may need to adjust where I do that now that we are talking about it
<zyga> jdstrand: hmm
<zyga> jdstrand: I think it should still be a connection, let me check what you wrote there again
<nessita> morphis, does this look OK? https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/
<zyga> jdstrand: (so that when you disconnect it shouldn't be possible to control)
<jdstrand> zyga: I think this is the main point-- how to let unconfined control the player
<morphis> nessita: checking
<jdstrand> zyga: in my mind, unconfined should be able to control it without a connection (it is unconfined)
<zyga> jdstrand: hmmm
<zyga> jdstrand: I think this is not intuitive though perhaps this is just my pov
<jdstrand> zyga: this is not about giving vlc something, it is about giving something else access to vlc
<zyga> jdstrand: it would be more interesting if we had two snaps here
<zyga> jdstrand: (controller and player)
<jdstrand> the player side just screams slot to me
<jdstrand> zyga: I implemented that locally
<jdstrand> mpris-client is a controller
<zyga> jdstrand: so dbus-wise, the player is a dbus service that stuff talks to
<jdstrand> zyga: yes
<jdstrand> like bluez
<jdstrand> like location-service
<zyga> jdstrand: still, with this I would expect to have control over which controller can actually talk to my player
<jdstrand> therefore, it seemed naturally a slot
<jdstrand> zyga: you do :)
<zyga> jdstrand: but perhaps this is a gray area
<zyga> jdstrand: (including unconifned unity)
<jdstrand> snap connect mpris-client:mpris vls:mpris
<jdstrand> that is the point
<zyga> jdstrand: but I cannot disconnect the classic one
<morphis> nessita: hm, rev 8, 7, 6, 5 should be published for all channels
<jdstrand> if we want to put unconfined into that limitation
<jdstrand> I would argue we do not
<jdstrand> on classic we let snaps talk to unconfined. no reason we can't let unconfined talk to snaps on classic
<zyga> jdstrand: why cannot that be explicit rather than implicit?
<jdstrand> it could be. I just don't think that is particularly useful
<zyga> jdstrand: btw, can a single player be sensibly controlled by many controllers?
<jdstrand> zyga: I don't see why not. It is just hitting dbus API
<jdstrand> play/pause
<jdstrand> ff
<jdstrand> rew
<jdstrand> it is simple
<zyga> jdstrand: ok
<zyga> jdstrand: so we don't need a plug on the core snap
<jdstrand> zyga: I'll put this another way. let me move the classic code to a permanent plug for now, with comment saying we may revisit this in the future?
<zyga> jdstrand: as there's no connection really
<jdstrand> we do on the core snap
<jdstrand> we need a controller snap
<zyga> hmm
 * zyga is tired, sorry let me re-read the code
<zyga> jdstrand: if there's a plug we have to patch snapd to create the plug
<zyga> jdstrand: currently it only creates slots
<jdstrand> zyga: note that as written, the unconfined OnClassic bit is in the wrong place. I am describing here that it should be in permanent plug conditionally OnClassic
<jdstrand> zyga: on core, this operates exactly like bluez
<jdstrand> zyga: if a player that slots mpris is not installed, nothing to connect to
<jdstrand> zyga: it just happens that it operates very similarly on classic. there is no implicit slot. a remote must control a player. the only difference is that what I'm proposing is that on classic we allow unconfined to control the player snap unconditionally
<jdstrand> zyga: as implemented, we do not handle a snap that is a remote to control an unconfined player. that could be a future improvement
<nessita> morphis, you can edit that yourself
<zyga> jdstrand: ah, ok
<morphis> nessita: without republishing? let me check ..
 * zyga reads the diff carefully
<nessita> morphis, when you change the channels the update propagates automatically to the index
<morphis> nessita: I see, thanks
<nessita> np
<jdstrand> meh, I said I need to move mprisConnectedSlotAppArmorClassic to connected plug earlier here. I meant conditionally add it to mprisPermanentSlotAppArmor
<morphis> nessita: did you approve network-manager too?
<jdstrand> zyga: ^
<nessita> morphis, jamie is with that one
<morphis> nessita: aye!
<nessita> o/
<jdstrand> morphis: there are a number of weird errors with nm. not sure if that is a review tools bug or something else.
<jdstrand> nessita: if we assume that those are review tools bugs, nm would be ok to approve? (ie, you've confirmed this is just a normal review and not something to treat special?)
 * zyga goes to a meeting
<zyga> jdstrand: let's continue this soon
<jdstrand> zyga: let me move mprisConnectedSlotAppArmorClassic while you are in the meeting
<zyga> OK
<zyga> Thank you
<jdstrand> then you can see what I actually mean
<nessita> jdstrand, hum, no, I haven't confirmed anything other than I moved the existing nm from a private store to the ubuntu store
<morphis> jdstrand: what exactly?
<nessita> jdstrand, let me run the review tools again, with the latest version
<jdstrand> nessita: that is the bit I'm talking about. that move is all correct, right?
<jdstrand> nessita: ah, if you run the review tools again, it might look better
<nessita> yeah, let me try
<nessita> jdstrand, just ran it for revision 10, using
<nessita> 678 click-reviewers-tools version
<nessita> the same 3 failures
<nessita> jdstrand, the move from one store to the other is as correct as I can possibly make it :-)
<jdstrand> nessita: all I need answered is that the move worked right and it is in the right spot
<jdstrand> ok, cool
<jdstrand> then I'll look at that in a moment
<nessita> jdstrand, the move worked right and is in the right spot. Thank you!
<jdstrand> morphis: ok, this is what you have:
<jdstrand> apps:
<jdstrand>   networkmanager:
<jdstrand>     slots:
<jdstrand>     - service
<jdstrand> slots:
<jdstrand>   service: network-manager
<jdstrand> morphis: (and you do something similar for plugs)
<morphis> jhodapp: yeah, whats wrong with that?
<jdstrand> morphis: based on the specification, that should be:
<jdstrand> slots:
<jdstrand>   service:
<jdstrand>     interface: network-manager
<jdstrand> unless the code has evolved beyond the spec
<morphis> jdstrand: service: network-manager is the short form of this which snapcraft allows you
<jdstrand> why do we have so many short forms...
<jdstrand> morphis: I'm curious why you chose this format over:
<jdstrand> apps:
<jdstrand>   networkmanager:
<jdstrand>     slots: [ network-manager ]
<jdstrand> and skip the toplevel slots and plugs
<morphis> because that would then not give the user any hint of what he connects
<morphis> with this he knows he connects "service" to "nmcli"
<jdstrand> zyga: can you confirm that the top-level plugs and slots declaration here is valid: http://paste.ubuntu.com/17695654/
<jdstrand> morphis: the other bit is: lib64/ld-linux-x86-64.so.2, usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service lint-snap-v2_external_symlinks
<jdstrand> morphis: those are going to dangle and may indicate a problem with the snap
<jdstrand> zyga: nm, I see it now in the spec
<jdstrand> morphis: I'll fix the tools for that abbreviated format
<zyga> almost done with the meeting
<jdstrand> zyga: ok, refresh and you can more easily see what I'm talking about
<morphis> jdstrand: I have a MP for that one to fix, can we upload with or should I push the fix first?
<jdstrand> morphis: if it is in progress, I'll just approve for now and you can fix in your next upload
<jdstrand> morphis: can you request a manual review?
<sergiusens> kyrofa the ros test fails consistently now :-/
<kyrofa> sergiusens, what the heck...
<kyrofa> elopio, have you managed to make any progress in downloading that stuff?
<sergiusens> kyrofa I say consistently in a 2 out of 2 test, I am not lying but my population is too small for it to be meaningful ;-)
<kyrofa> sergiusens, hahaha
<sergiusens> kyrofa is this the error you see http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1153/testReport/junit/demos_tests.test_ros/ROSTestCase/test_ros/
<sergiusens> kyrofa that comes out of this btw https://github.com/ubuntu-core/snapcraft/pull/574 which cannot be related :-P
<kyrofa> sergiusens, yeah that's it
<kyrofa> ROS, you sadden me
<kyrofa> sergiusens, I'll investigate as soon as elopio is able to pull stuff off of it. Tests pass locally, manual tests pass on the jenkins machines... something must be going on in the test infrastructure somewhere
<sergiusens> kyrofa I bet we just run out of RAM
<morphis> jdstrand: will do
<kyrofa> sergiusens, that's an interesting theory. What makes you say that?
<kyrofa> sergiusens, it doesn't look like an enomem, it looks like a garbled file
<sergiusens> kyrofa it only happens sometimes, it is either RAM or load; running out of files to create is another one; not sure how performant these machines are. But I've seen many random errors happen when RAM gets low
<sergiusens> kyrofa you know how people do those malloc checks, right? ;-)
<kyrofa> sergiusens, heh, fair point
<kyrofa> sergiusens, admittedly the only time I did was for ubuntu core launcher :P
<morphis> jdstrand: requested for rev 8, 9 and 10
<dholbach> davidcalle, mhall119, popey: I started work on https://github.com/ubuntu/snappy-playpen/wiki/Examples - what do you generally think? more detail? better overview of chapters? (I'll add much more content to it...)
<jdstrand> nessita: fyi, I approved the nm snaps, but there was a server error for each of r8, r9 and r10. Eg, for r8: OOPS ID: OOPS-26f562e1911f49328a44c89c8924d65c
<jdstrand> Sentry ID: 9c66fdb409bf4131985225e707017749
<jdstrand> morphis: fyi, I approved all of them. I think you have to manually publish (at least for r10)
<nessita> jdstrand, let me check
<morphis> nessita, jdstrand: clicking publish gives me an "Server Error"
<nessita> morphis, yeah, there are issues in our code with the interfaces
<nessita> something is not right, let me follow up
<jdstrand> the web interface indicates it was published
<jdstrand> (now, it didn't before)
<nessita> jdstrand, but that may not be true, actual publishing is in an async task
<jdstrand> nessita: also, I'm looking at the comment history and I left comments in all three, but I don't see them
<nessita> jdstrand, that was before the oops?
<nessita> jdstrand, I mean, did you write the comment, hit approve and you got the oops?
<jdstrand> nessita: yes
<jdstrand> nessita: that was what I did for all three. same thing each time
<nessita> jdstrand, so the comment was not stored because of the crash, let me unapprove those
<jdstrand> nessita: if it helps, this is the comment for each: http://paste.ubuntu.com/17697843/
<nessita> morphis, please hold publishing the revisions for nm until we debug server side
<jdstrand> nessita: ok, at this point I'll hand off to you. feel free to approve with that pastebin comment
<nessita> jdstrand, will do, thank you!
<jdstrand> np
<popey> dholbach: i like
<morphis> nessita: aye!
<dholbach> popey, so nothing you'd change apart from adding more stuff to it?
<popey> yeah, that's exactly the kind of thing I'd be looking for
<dholbach> cool
<kyrofa> sergiusens, I have a python question
<kyrofa> sergiusens, I have a PYTHONPATH that contains two packages. I can import one, but not the other. How do I figure out what's wrong?
<jdstrand> mvo: fyi, tyhicks` will look at https://github.com/snapcore/snap-confine/pull/43/files
<mvo> ta
<jdstrand> mvo: would you mind looking at https://travis-ci.org/snapcore/snapd/jobs/139481053 ?
<jdstrand> mvo: this is a spread testsuite failure that seems unrelated to my mpris PR
<elopio> sergiusens: do you want to give this a try? https://github.com/elopio/snapcraft/blob/launchpad_scripts1/scripts/launchpad/add_series.py
<jdstrand> mvo: mostly I just want to know if this issue is known
<kyrofa> jdstrand, yes, it's known
<kyrofa> jdstrand, https://github.com/snapcore/snapd/pull/1382/files/7ceced8912257c2468003c1eb7554f4018e3ea81#r68051608
<kyrofa> jdstrand, looks like some PRs landed in the wrong order
<jdstrand> mvo: beyond that mpris PR testsuite failure, I looked through all the content sharing stuff and it makes sense to me. using bind mounts means don't have to worry about updating the apparmor policy
<kyrofa> Morning elopio!
<jdstrand> kyrofa: ack, I'll merge again and see if it is resolved
<jdstrand> hrmm, up to date
<sergiusens> elopio thanks! Will try it soon
<kyrofa> jdstrand, it's not fixed :(
<jdstrand> ah, 1367 is not merged
<jdstrand> gotcha
<kyrofa> jdstrand, https://github.com/snapcore/snapd/pull/1367 needs to be... yeah
<kyrofa> jdstrand, the PR page is a sea of red right now
<sergiusens> kyrofa are your python packages properly setup?
<elopio> hello kyrofa.
<kyrofa> sergiusens, I assumed so. This is using the launchpadlib as a stage package, which pulls in lazr.restfulclient. I'm getting import errors for lazr
<elopio> sergiusens: I tried on staging, but I don't have permission to try on production. If it works for you I will capture the milestone from an argument, and deduplicate. Then let me know what else you would like to have in the script.
<jdstrand> mvo: it may also mean that binaries will just work since we have ix rules in apparmor policy for where the bind mounts are going to, assuming that the slot side is written to look for libraries in the right places
<jdstrand> mvo: I made a couple teensy comments in the spec. with tyhicks looking at the PR, is there anything else you need to expedite this?
<mvo> jdstrand: the spread failure looks like something for fgimenez :)
<mhall119> sergiusens: have you had a chance to play anymore with my pantheon-mail snap?
<mvo> jdstrand: thanks, I have a look into the spec now, I this work is on a good track, the review for snap-confine and then hopefully in the next couple of days this can land
<sergiusens> mhall119 no sorry, rushing with commitments after a week of flu
<jdstrand> mvo: cool, thanks! holler if you need me :)
<mvo> jdstrand: will do, thanks !
<jdstrand> ratliff: fyi, ^
<mhall119> dholbach: I think it could use some more explanation of what the use case is that the example is showing, and how the individual parts of the example support it
<sergiusens> mhall119 I will need to spend a complete evening on this one (pkg-config)
<kyrofa> sergiusens, here: http://pastebin.ubuntu.com/17698671/
<jdstrand> ratliff: (content sharing)
<mhall119> sergiusens: when you do, give me a ping and I'll go through it with you
<kyrofa> sergiusens, both folders have an __init__.py, both are in the pythonpath
<kyrofa> sergiusens, or does the lazr directory also require an __init__.py?
<sergiusens> kyrofa can you import lazr directly?
<sergiusens> kyrofa all packages require one
<kyrofa> sergiusens, no, same problem with `import lazr` or `import lazr.restfulclient.resource`
<kyrofa> sergiusens, ah! On my system lazr contains an __init__.py... staged, it does not
<mhall119> oh god, not lazr
<dholbach> mhall119, like?
<kyrofa> sergiusens, that must be the issue
<kyrofa> But how...
<dholbach> mhall119, could you make up an example? so I know what you're talking about?
<jdstrand> zyga: hey, are you ready to talk about mpris again?
<mhall119> dholbach: let me think on it and I'll propose something
<dholbach> thanks
<dholbach> just add it to the wiki
<sergiusens> kyrofa btw, xnox wrote python3 bindings for launchpad a while back iirc
<kyrofa> sergiusens, good to know
<sergiusens> elopio can you help me out with http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1050/console
<sergiusens> not sure what the problem is
<kyrofa> sergiusens, looks like it sets that stuff up in postinst, argh
<kyrofa> I'll try using pip
<zyga> jdstrand: re, yes
<elopio> sergiusens: yes, look in #ubuntu-devel. I asked Martin, he gave me ideas of how to get more information about the error.
<matteo> anyone ever compiled snapd with gccgo?
<zyga> matteo: ppc uses gccgo AFAIR
<zyga> matteo: there are some issues that we whack-a-mole fix
<matteo> how to do it? go build -compiler gccgo or gccgo directly?
<zyga> matteo: I'd suggest looking at the ubuntu/debian packaging
<zyga> matteo: that's how it is built there
<matteo> thanks
 * ogra_ would grab the source pakcge from the archive and take a look at debian/rules ;) 
<zyga> matteo: I don't have the hardware to experiment so I cannot help more
<sergiusens> elopio I'll add a no_proxy fixture to those tests. We already saw this which is why I asked you and you jogged my memory :-)
<zyga> jdstrand: could you add a docs/interfaces.md entry for mpris please
<matteo> https://packages.debian.org/sid/snapd
 * ogra_ notes thaat this could run snaps with a xenial install ;) https://www.raptorengineering.com/TALOS/prerelease.php
<ogra_> 12 core 256GB ram ... i guess you dont need any disks anymore on a workstation like this :)
<ogra_> (just for copying your OS to a ramdisk on boot)
<zyga> ogra_: 190TDP, it is good to know power stands for "I still suck power'
<zyga> ;)
<ogra_> :)
<ogra_> saves heating in winter at least
<jdstrand> zyga: well, that is an interesting point. we don't have anything in docs/interfaces.md for bluez, network-manager, etc (ie, things that aren't implicit slots). this isn't an implicit slot, so I didn't add it
<zyga> ogra_: not applicable to spain
<jdstrand> zyga: should explicit slots be documented in there?
<zyga> jdstrand: I'd document it because all the interfaces should be, the ones you mentioned are just omissions
<ogra_> well, you could attach a sterling engine that powers your AC
<jdstrand> I see
<zyga> jdstrand: I mean we should document all interfaces
<zyga> jdstrand: their purpose, type, etc
<zyga> jdstrand: ideally how to use them later on
<jdstrand> I was thinking the same thing, but it seemed like an implicit vs explicit, so...
<mhall119> sergiusens: is there a bug report for the snapcraft pkg-config not being able to find .pc files in different locations?
<mhall119> if not, I can create one
<matteo> zyga: you know that if you use gccgo on x86 the binary is half the size?
<zyga> matteo: I didn't try to use gccgo yet but perhaps it is because of the supprt for shared libraries?
<matteo> zyga: /usr/lib/x86_64-linux-gnu/libgo.so.9, damn
<mhall119> sergiusens: is my problem related to https://bugs.launchpad.net/snapcraft/+bug/1531481 or is it different?
<ubottu> Launchpad bug 1531481 in Snapcraft 1.x "snapcraft should setup search paths/flags for parts built after parts" [Undecided,New]
<sergiusens> mhall119 maybe, a new bug might be better though
<sergiusens> matteo zyga there is shared library support for gc-go for x86 fwiw
<elopio> congrats tsimonq2! I see your svn branch made it for 2.12.
<jdstrand> zyga: note, I need to prepare for and attend a meeting now. I'll check backscroll
<zyga> jdstrand: ack, I'll merge your interface shortly
<sergiusens> tsimonq2 yup as elopio said, it will make it to 2.12; thanks for putting up with our quality standards!
<sergiusens> josepht hey, have you had a chance to look into OrderedDicts?
<slangasek> zyga: yes, that was using dpkg-vendor
<ogra_> mvo, so looking at the PPA build, what from the go packages from https://launchpad.net/~snappy-dev/+archive/ubuntu/image do i need to copy over to the edge PPA, are any of them used in the image build ?
<ogra_> mvo, so far i would copy
<sergiusens> elopio this might need a rebase/merge https://github.com/ubuntu-core/snapcraft/pull/591
<ogra_> initamfstools-ubuntu-core ... livecd-rootfs, squashfs-tools (is that still needed ?), ubuntu-core-config
<ogra_> (plus your last shadow upload)
<mvo> ogra_: most should not be needed, the go stuff should be in sync
<mvo> ogra_: aha, please do copy the shadow bit, I tripped over this
<ogra_> mvo, right, i think only these four are needed ... what about squashfs-tools ?
<mvo> ogra_: uploaded to the wrong ppa
<ogra_> did that get SRUed already
<ogra_> mvo, no, you didnt ... livecd-rootfs hanst moved to the edge one yet
<mvo> ogra_: that is in xenial too
<mvo> ogra_: I guess I will just delete the ones that have identical version in xenial and the ppa to avoid further confusion
<ogra_> and since you are fiddlign with builds i'll keep the switch for toomorrow so i dont step on your toes with livecd-rootfs changes
<ogra_> that would help
<mvo> ogra_: yeah, I need an image with a new passwd
<ogra_> mvo, right, build system is all yours then, i'll do the switch tomorrow
<mvo> ta
<josepht> sergiusens: not yet, I'll see if I can get that done today.
<slangasek> elopio, mvo: snapd 2.0.9 is still missing verification-done on bug #1593201; is this SRU good to release?
<ubottu> bug 1593201 in snapd (Ubuntu) "[SRU] 2.0.9" [Undecided,New] https://launchpad.net/bugs/1593201
<jdstrand> zyga: thanks!
<elopio> fgimenez: ^
<jdstrand> zyga: fyi, I'm incorporating tyhicks feedback on arg filtering, will merge with trunk and hopefully this can be part of the next upload
<fgimenez> elopio, slangasek i'm about to post a comment and change the tag, the verification is done
<zyga> jdstrand: fantastic
<zyga> jdstrand: btw, we'll release 1.0.34 soon :)
<zyga> jdstrand: release early and often as they say :>
<jdstrand> zyga: working on it as we speak
<slangasek> fgimenez: thanks, publishing then!
<fgimenez> slangasek, thank you :)
<mhall119> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1595243
<ubottu> Launchpad bug 1595243 in Snapcraft "pkg-config fails to find dependencies built from other parts" [Undecided,New]
<slangasek> zyga, mvo: how should I upstream bug reports filed in Debian about the snappy packaging? (I.e. for cases where I'm not just submitting an MP because I don't immediately know the correct fix)
<mvo> slangasek: just report here https://bugs.launchpad.net/snappy and let me know
<slangasek> mvo: got it, thanks
<mvo> yw
<jdstrand> zyga: dude, I think every change I made has a conflict :|
<sergiusens> elopio ok, so I got pass the no_proxy issue, now wrt integration tests, do I need some specific proxy setup http://pastebin.ubuntu.com/17704844/ ?
 * jdstrand scratches head and wonders why the snap-confine tests aren't running on i386
<roadmr> hey jdstrand . Am I correct in assuming we need a new click-reviewers-tools to auto-approve packages using the serial-port interface?
<jdstrand> roadmr: yes. I just added it in r681. note I pinged pindonga and noise][ earlier about pulling r680
<roadmr> jdstrand: ah, added minutes ago ;) pindong-a is out sick today, I'll take care of this then :)
<jdstrand> roadmr: I added it when I saw your ping :)
<roadmr> jdstrand: sneaky you ;)
<jdstrand> hehe
<jdstrand> tyhicks: dang it-- you're too good :)
<elopio> sergiusens: yes, let me ask IS for the exception in the firewall.
<tyhicks> jdstrand: regarding the disabled tests for snap-confine on !amd64 architectures?
<jdstrand> yes
<tyhicks> :)
<jdstrand> I looked and missed it
<tyhicks> I saw that PR go by a few days ago and disabling tests caught my eye
<jdstrand> tyhicks: they used to be disabled in common.sh. this is better, but I fixed common.sh to work with i386...
<jdstrand> anyway, I'll see if I can adjust that
<jdstrand> zyga: fyi, https://github.com/snapcore/snap-confine/pull/7#issuecomment-227828658
<palasso> mhall119: in the geany snapcraft you forgot to place 2 dashes in -disable-html-docs in the configflags
<zyga> jdstrand: looking
<zyga> jdstrand: I saw mvo merged mpris
<jdstrand> \o/
<jdstrand> zyga: this would be nice to merge for 2.0.10: https://github.com/snapcore/snapd/pull/1387
<jdstrand> especially for socketcall
<jdstrand> (trivial PR)
<tedg> zyga: Looking at the interfaces rest call, and it looks like to me that the connection should have an "apps" field with the apps from the snap. But I'm not seeing that.
<tedg> Is there some case where that gets dropped that I'm not seeing?
<jdstrand> zyga: you said "just install the package on your system". what package? the new ubuntu-core-launcher? it will work without an updated snapd?
<zyga> yes
<zyga> it's designed to be an upgrade
<zyga> it ships ubuntu-core-launcher symlink
<jdstrand> ok, I'll try that real quick
<zyga> tedg: mmmm
 * jdstrand tried to symlink manually be it didn't work. I probably missed something
<zyga> tedg: not sure, maybe just an omission
<zyga> jdstrand: just dpkg-buildpackage
<zyga> jdstrand: and debi
<jdstrand> yeah, I understand. doing that now
<tedg> zyga: It looks there to me, https://github.com/snapcore/snapd/blob/master/interfaces/json.go#L48
<tedg> zyga: Is there somewhere else I should be looking?
<zyga> tedg: that's not what is being sent, look at daemon/api.go please
<zyga> tedg: do you see the mapping?
<tedg> zyga: Yeah, the mapping seems fine. I wonder if the flattening code is somehow effecting it. Looking there now.
<tedg> zyga: So I think the repo is putting a "slot ref" in there and then the api.go isn't dereferencing it.
<jdstrand> zyga: ok, confirmed the deb worked as expected
<tedg> zyga: So then the JSON only has the snap name and snap instead of providing more information.
<zyga> jdstrand: I saw, great news
<zyga> tedg: I think that was the intent of the interfaces call, maybe the docs are stale
<zyga> tedg: another call should profile all the information about apps
<MichaelTunnell> You can have your own repo/ store. snapd just manages the snaps it's given. The snap client does the store integration, but someone could patch that or make their own store or their own client to poke snapd with snaps. - so question: is there any documentation on this so that I can learn more about this?
<tedg> zyga: It seems then that I can't distinguish between an interface for the whole snap and one for an individual app.
<croepha> TIL/ pro tip for debugging purposes, you can just add bash to your .snap, and then you can use that to get a shell to test things in your snap environment
<tedg> zyga: I think I can use the plugs object for what I need though.
<tedg> I still need revision info, but that's a smaller issue.
<tedg> MichaelTunnell: You can use the REST inteface to install snaps or otherwise manage snapd: https://github.com/snapcore/snapd/blob/master/docs/rest.md#v2snaps
<jdstrand> morphis: hey, can you comment on bug #1583057?
<ubottu> bug 1583057 in pulseaudio (Ubuntu Xenial) "Deny audio recording for all snap applications" [Undecided,Triaged] https://launchpad.net/bugs/1583057
<MichaelTunnell> tedg: lets say someone from another distro wanted to make their own "repo" of snaps, would that be the link to provide them?
<tedg> MichaelTunnell: It depends a lot on the architecture of what they want to build. So, I'd have a conversation with them, not provide a link :-) That is how to manage snaps in snapd from an external service. It applies to some solutions, specifically the one you asked about.
<mhall119> palasso: thanks, upstream already pointed that out to me, and in fact I'm removing that config flag completely now
<palasso> nice
<greentea_> within a snap, is there a way to modify command-<snap>.wrapper ??
<tedg> greentea_: It is built by snapcraft by the parts that you're using. So, kinda, but by using snapcraft parts, not directly. You can insert another wrapper though if you want to add variables.
<greentea_> tedg: do you know I could modify pythonpath so it could find packages?
<tedg> greentea_: If you use the python part it'll install pip packages and adjust the path to find them.
<sergiusens> greentea_ that wrapper thing is an implementation detail for snapcraft
<tedg> greentea_: For info: $ snapcraft help python3
<greentea_> tedg: ahh, yes. I specified a list of packages using python3 plugin, but since I'm using a different python runtime, its path is short of sight
<greentea_> how to set destdir using autotools plugin?
<zyga> greentea_: it's set by snapcraft, why do you want to change it?
<greentea_> ohhh, I see
<greentea_> zyga: oops, I meant how do we include it in .yaml under autotools part
<greentea_> I'm confused with the specs and keep getting errors
<greentea_> never mind - got it
<example6> Any advice on available packages / workarounds for getting any sort of lite desktop on snappy core?
<example6> Say, on a raspberry pi
#snappy 2016-06-23
<tsimonq2> elopio, sergiusens: thanks for taking the time to make sure my code worked and fit the standards, that is much appreciated :)
<tsimonq2> and elopio, I'm glad we have quality standards, it ensures things don't break ;)
<ayan> jdstrand: how do i allow seccomp() with the latest version of snap & snapcraft?  is there an interface i have to use (like x11 or unity7 etc.)?
<elopio> tsimonq2: :) how is it going with the textwrap branch?
<tsimonq2> elopio: I'm getting there :)
<tsimonq2> elopio: I hope to have it done for tomorrow
<tsimonq2> elopio: it *seems* like the only thing blocking it are the unit tests failing because they expect a text wrap
<sergiusens> elopio fixed https://github.com/ubuntu-core/snapcraft/pull/584
<sergiusens> elopio I had to manually review the vendored implementation and noticed that the upstream one is actually nicer :-P
<elopio> tsimonq2: yes, that's what I think too.
<sergiusens> elopio am now fighting this http://paste.ubuntu.com/17728277/
<sergiusens> elopio all green https://github.com/ubuntu-core/snapcraft/pull/588 !
<elopio> sergiusens: nice! I'll review it after dinner.
<elopio> that tweetnacl error, I have no idea.
<sergiusens> elopio I do, we need newer libraries and packages than what we have in trusty :-/
<sergiusens> elopio might be time to bring back that xenial lxd monster again
<tsimonq2> elopio: well it keeps failing, the unit tests
<sergiusens> elopio already reviewed, but I will let you take a stance at it, is dinner over soon? If not I am going to bet
<sergiusens> bed
<elopio> sergiusens: go for it. I'm about to start.
<elopio> I'll review it when it is SRU time.
<tsimonq2> elopio: could you peek at the build errors on https://github.com/ubuntu-core/snapcraft/pull/592 when you have the chance? I don't know what's wrong
<sergiusens> elopio for dessert! https://github.com/ubuntu-core/snapcraft/pull/590
<ConfusedIntern> I  was wondering if anyone knew about the current status of 64-bit Ubuntu Snappy Core on the Raspberry Pi 3?
<ConfusedIntern> The most recent info I can find on it is that you can run the Pi 2 32 bit image with a 64 bit version in the works. I wondered if that had been released yet or if anyone knew when it's expected?
<zyga> ConfusedIntern: hey
<zyga> ConfusedIntern: I think everyone is waiting for the pi foundation to release required files for the pi to use 64 bit code
<zyga> ConfusedIntern: from our end we will update the kernel snap when that happens
<zyga> ConfusedIntern: and we already have the userspace (because it is shared)
<zyga> ConfusedIntern: but right now the question is to the raspberry pi foundation, not ubuntu
<zyga> ConfusedIntern: ogra can correct me if I'm wrong but IMHO this is how things look like today
<ConfusedIntern> zyga: Ah ok then. Thanks!
<fusion809> Anyone come up with a way of editing source files (like with sed) before building a snappy package from 'em?
<morphis> jdstrand: will have a look
<zyga> jdstrand: https://bugs.launchpad.net/snap-confine/+bug/1595444 FYI
<ubottu> Launchpad bug 1595444 in Snappy Launcher "current working directory is always /" [High,In progress]
<jdstrand> ayan: re seccomp> you don't need to do anything except have snapd 2.0.9 installed when you installed your snap. eg:
<jdstrand> $ grep '^seccomp' /var/lib/snapd/seccomp/profiles/snap.hello-world.sh
<jdstrand> seccomp
<jdstrand> zyga: it looks like setup_snappy_os_mounts() isn't chdir()'ing back to the user's pwd after it does its thing
<jdstrand> zyga: see the changes to setup_private_mount() that I did recently that does do that
<jdstrand> zyga: were you planning on committing the arg filtering branch today? (I'd just like it in place for the snapd 2.0.10 landing if possible)
<ysionneau> any example of a snapcraft.yaml using systemd socket activation feature for a daemon? thx
<ysionneau> I thought I found some yaml syntax doc about that on ubuntu website before ... but I cannot find it anymore
<ysionneau> ah, found it: https://developer.ubuntu.com/en/snappy/guides/meta/ !
<zyga> jdstrand: yes
<zyga> jdstrand: but after spread works
<zyga> jdstrand: btw, I have a fix for the chdir thing
<zyga> jdstrand: I'm just going through the process where we get real system tests for this
<jdstrand> zyga: awesome :)
<jdstrand> thanks! :)
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/49/files
<zyga> jdstrand: simple smoke test for debian and ubuntu :)
<jdstrand> zyga: nice!
<jdstrand> though, the curl bit is a bit weird. are all the spread tests doing that?
<zyga> jdstrand: yes, spread is not available anywhere
<jdstrand> hrm
<jdstrand> hopefully spread-amd64.tar.gz doesn't get trojaned
<jdstrand> surely one could at least snap the snap from the store and unsquash it?
<jdstrand> s/snap the snap/snag the snap/
<zyga> jdstrand: perhaps but TBH this wouldn't be any different
<jdstrand> sure it would
<zyga> I need to ask gustavo about more debian hosts
<zyga> niemeyer1: can you please add another debian-8 node to our spread pool
<jdstrand> I don't know how well that instance is protected. we know how well the store is protected
<jdstrand> anyway, I expressed my concern
<zyga> jdstrand: yeah, I get your point
<zyga> jdstrand: spread is one tarball, we could perhaps check the hash
<jdstrand> even just an upload to LP in universe wuld help, then you could apt-get source it)
<zyga> jdstrand: that's better than unsquashfs as it is universally easier to get without sudo
<jdstrand> unsquashfs doesn't need sudo. did I misunderstand something?
<jdstrand> anyway, I see you are thinking about it. that was all I wanted to have happen
<jdstrand> :)
<zyga> I mean sudo to install unsquashfs
<zyga> this is just a travis limitation
<zyga> if you want sudo you wait longer for a test slot
<jdstrand> ah, that isn't on the node?
<jdstrand> I don't know how those are setup
<zyga> jdstrand: those are typically old ubuntu (trusty)
<zyga> jdstrand: + loads of modifications by travis
<zyga> jdstrand: we don't do anything there apart from getting spread
<zyga> jdstrand: and running it
<jdstrand> I'm surprised snapd tests are going to work there
<jdstrand> I would think there would be kernel patches, etc that are needed
<zyga> jdstrand: snapd doens't do much there
<zyga> jdstrand: and we mock everything
<zyga> jdstrand: real tests are spread tests
<zyga> jdstrand: those run on lindode on the real ubuntu kernel
<jdstrand> oh, these aren't for integration tests? I thought that was part of the allure of spread
<zyga> jdstrand: no no, those are integration tests but there are layers
<zyga> jdstrand: travis picks up github events
<zyga> jdstrand: travis is then configured to download and run spread
<jdstrand> ok, clearly I should stop distracting you. I find it interesting, but there are better things we can be doing than getting me up to speed on the test infrastructure :)
<zyga> jdstrand: spread distributes the code to linode vms
<zyga> jdstrand: and then real stuff happens on linode vms
<zyga> :D
<jdstrand> I see. neat :)
<zyga> no worries, I'm looking at the build log
<jdstrand> zyga: though while I have you-- have you seen the various fail to upgrade bugs on yakkety for the launcher? oh, maybe 1.0.30ubuntu1 fixes that...
<zyga> jdstrand: yes
<zyga> jdstrand: I think will be fixed with 1.0.33
<zyga> jdstrand: or perhaps one of the earlier ones
<zyga> jdstrand: I don't release to debian so I feel pretty helpless about it
<jdstrand> it will be nice when snapd on yakkety passes autopkgtests. so many bugs at fix committed...
<zyga> jdstrand: do you know what's blocking it there?
<jdstrand> zyga: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html . search for 'snapd'
<jdstrand> the launcher has some always failed tests (though not sure why on armhf) and autopkgtests fail for all archs for sanpd
<kyrofa> Hey ogra_ you're building os snaps for s390x, right?
<ogra_> indeed
<zyga> jdstrand: the launcher should have 0 tests on !amd64
<zyga> jdstrand: this is now made so upstream
<zyga> jdstrand: perhaps older tests
<zyga> kyrofa: *core* :)
<kyrofa> zyga, has that actually happened yet?
<kyrofa> ogra_, does the store allow uploading snaps of that arch?
<jdstrand> zyga: note my arg filtering branch re-enables i386 because I fixed the tests for it
<stgraber> is there anything I should be doing to have https://github.com/snapcore/snapd/pull/1380 re-reviewed and ideally, merged?
<ogra_> kyrofa, yep
<jdstrand> zyga: talking about the internal testsuite of course, not autopkgtests
<zyga> jdstrand: for snap-confine? yes that's what I was talking about as well
<jdstrand> zyga: yes, for snap-confine. there isn't really any reason to not do it for all, but I felt strongly we needed at least 32 bit and 64 bit represented in the testsuite
<zyga> stgraber: yep, someone has to look and review them
<zyga> jdstrand: I'll add 32bit ubuntu to the linode mi
<ogra_> kyrofa, there are ubuntu-core snaps in the store for all arches except the 32bit powerpc
<zyga> mix
<kyrofa> ogra_, I'm gonna see if launchpad will open that for me then. Wait, the store accepts ppc64 as well?
<kyrofa> It didn't last time I tried
<ogra_> it did when i uploaded the snap ... but thats a while ago
<kyrofa> ogra_, well I tried probably a while before that, so nice
<ogra_> it is a hard requirement that we support these two arches on classic
<ogra_> so if it got dropped it has to come back :)
<sergiusens> kyrofa mind moving your wiki part entry to the new wiki format?
<kyrofa> sergiusens, you need to the new wiki page?
<kyrofa> s/need/mean/
<kyrofa> sergiusens, done
<sergiusens> kyrofa yeah
<sergiusens> kyrofa thanks
<skay> hi, I made my first snap, just a python based cli. is there advice for getting a smaller file size?
<didrocks> skay: hey! you can filter with some stenza like snap: prime: or others that output to the snap file
<didrocks> skay: see those keywords in https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
<skay> didrocks: thanks!
<didrocks> yw ;)
<croepha> so, why would a path be present in  /snap/my-app/current/ and not be present when I run a shell in the snap?
<croepha> or any command, not just a shell
<jdstrand> is there a way to run a single unit test? './run-checks --unit' is better than without '--unit' but still a bit long
<mhall119> sergiusens: now that snap-confine works on Elementary 0.4, it sure would be nice if we could get the Panteon-Mail snap working for them
<jdstrand> 'go test github.com/snapcore/snapd/interfaces/builtin' seems to do what I want
<olli__> ogra_, I just asked jamiebennett to help with the bug links
<ogra_> kyrofa, is your nextcloud.occ a wrapper script (or could you make one for it and simply put in "sudo -i" in there ?)
<ogra_> that should fix the issue and even call sudo transparently
<ogra_> olli__, gracias ... i'd do it myself but i'm no OP here afaik
<kyrofa> ogra_, it is. I'm not a huge fan of forcing sudo upon the users without warning, but that's not a bad idea
<ogra_> well, does it make any sense to run it without sudo ?
<ogra_> then building it in is indeed bad
<kyrofa> ogra_, honestly no :P
<ogra_> but if you need sudo anywy that is a nice way of just getting it
<kyrofa> ogra_, yeah, I think I'll do that, thank you :)
<ogra_> you simply get a password prompt
<kyrofa> ogra_, but: this bug is still valid, yes?
<ogra_> (and could put an echo before it if you feel like ... to tell the user whats going on)
<sergiusens> kyrofa ogra_ or check euid and provide feedback on why sudo is needed
<ogra_> well, i'm not sure, i think sudo does what it should ... we mangle the path in a place it cant use
<kyrofa> sergiusens, the problem is actually that sudo doesn't have /snap/bin in the path, so just running with sudo doesn't work
<ogra_> right ... you need to use -i to make it process the pam login process
<kyrofa> ogra_, not every app will have the use-case I have (i.e. where it makes no sense to run without sudo)
<ogra_> so /etc/profile.d gets read
<ogra_> kyrofa, yes, indeed
<ogra_> the prob is the other place to mangle it would be ~/.bashrc or /etc/environment ... of the host machine
<mhall119> hi all, is there a way for me to upload a snap (geany in this case) under my developer namespace, while reserving the canonical (little c) name for the upstream?
<ogra_> i think both would solve it but both are a no-no
<mhall119> or do I need to do like cwayne did and put my name into the package name, like: mhall119-geany
 * ogra_ would put his name last 
<mhall119> geany-ogra then?
<kyrofa> mhall119, I've been using canonical names expecting to transfer them
<mhall119> kyrofa: ok, but what will show in Gnome Software for Geany if I do that?
<ogra_> mhall119, yeah
<kyrofa> mhall119, I'm not sure I understand the question
<kyrofa> mhall119, oh, you mean because it has both debs and snaps named geany?
<ogra_> mhall119, i suspect it pullls the name from the .desktop file ... but ask Laney, he knows the magic behind this
<mhall119> kyrofa: if I open the Software app on Ubuntu and search for "Geany", I don't want users to think that my snap is the official one to use
<kyrofa> mhall119, why not? Does Geany package its debs? What is official?
<sergiusens> Keep it in a non stable channel
<sergiusens> And what kyrofa said
<sergiusens> People will see you are the publisher
<ogra_> except that you cant see non-stable channels anywhere
<ogra_> (yet)
<ogra_> (my gitter snap is in beta and edge ... there is no way to see it with "snap find")
<kyrofa> ogra_, yeah channels aren't very useful right now. No way to change channel without removing first, etc
<ogra_> yep
<kyrofa> ogra_, verified, ppc64 accepted! Awesome
<ogra_> :D
<kyrofa> ogra_, now I just need the LP team to unlock s390x for my snap recipes
<ogra_>  hah
<mhall119> kyrofa: no, geany does not package it's debs
<mhall119> they rely (happily) on distros to package and published geany
<jcastro> so will there be a way to browse unstable/edge snaps in the store or is the intent to keep them user invisible for QA reasons?
<elopio> didrocks1: ping. I
<elopio> I'm copying your travis/docker setup from playpen, but I'm failing to collect a file afterwards.
<elopio> didrocks1: can you give me a hand? https://travis-ci.org/ubuntu-core/snapcraft/jobs/139686897 (take a look at the coveralls statement)
<dholbach> davidcalle, https://github.com/ubuntu/snappy-playpen/wiki/Examples is taking some time to put together, but I said to didrocks1 earlier that I'm getting to the first items in the playpen where I'm like "ok, I documented something like this already" - maybe it's going to be quicker now ;-)
<kyrofa> mhall119, right, that's my point. So what is official?
<davidcalle> dholbach: I'll wait for it to be in a state you are comfortable with before sending the weekly update, can wait tomorrow! :)
<dholbach> cool
<sergiusens> josepht found a little nit in the parser, if `source` is not there, we shouldn't fail
<mhall119> kyrofa: what's in the archive is official
<mhall119> mine is experimental
<kyrofa> mhall119, if you don't anticipate getting it stable enough to be "the Geany snap" then yes, perhaps you should name it something else
<mhall119> kyrofa: it's not just that it's a snap, it's also using gtk3 which upstream hasn't switched to by default yet
<josepht> sergiusens: 'source' in the snapcraft.yaml from 'origin'?
<kyrofa> mhall119, I guess what I'm saying is that, until upstream wants to publish their own snaps, I don't see a problem with claiming the official name and trying to get something stable out there, just like we do with the archives.
<kyrofa> mhall119, there is of course no problem with naming it something different either
<elopio> didrocks1: ah, nevermind. I think I got it.
 * ogra_ melts
<didrocks1> elopio: ah sorry, didn't see the ping
<didrocks1> glad you sorted it out
<elopio> fgimenez: let's skip today, to see if I finish something before my swimming class.
<fgimenez> elopio, ok, i was going to porpose the same to you :) (without the swimming part)
<elopio> fgimenez: :D
<stgraber> jdstrand: is there some env variable or config I can set to temporarily entirely turn off apparmor in snapd?
<stgraber> jdstrand: I'd be fine with masking paths in /sys and/or /proc if that works as a way to have that code skipped (basically pretending the kernel doesn't have apparmor support)
<jdstrand> stgraber: you can boot with apparmor disabled. you can install the snap with --devmode. you can modify the profile in /var/lib/snapd/apparmor/profiles/snap... to be in complain mode. you can compile ubuntu-core-launcher with --disable-confinement
<jdstrand> stgraber: but why are you doing that?
<stgraber> jdstrand: running snapd inside an unpriv lxd container
<jdstrand> so it is the snapd inside the container you want to disable apparmor?
<kyrofa> ogra_, sudo is denied :P . I should have guessed that, of course it is
<jdstrand> if so, I think the easiest you can do until the nesting work is done in lxd is to compile ubuntu-core-launcher without confinement
<ogra_> ah, crap, indeed
<stgraber> jdstrand: I've sorted out the squashfs part of the problem and tych0 is looking at apparmor namespacing but trying to see if there's any other issue we'll have to take care of after that
<stgraber> jdstrand: ok
<kyrofa> ogra_, who's problem is that? snapd?
<jdstrand> stgraber: go here: https://github.com/snapcore/snap-confine
<ogra_> kyrofa, that sudo doesnt work ? thats a feature :)
<ogra_> you would have to ship sudo and a sudoers file inside
<kyrofa> ogra_, no no, I mean the environment thing, sorry
<jdstrand> stgraber: see PORTING on how to use --disable-security. modify debian/rules for that. build the deb and use that in the container
<kyrofa> ogra_, since I can't workaround it, I'd like to push it a little
<stgraber> jdstrand: ok, thanks
<elopio> sergiusens: any idea about this error? https://travis-ci.org/ubuntu-core/snapcraft/jobs/139791578
<jdstrand> stgraber: I think that should work (if you have trouble with --disable-security, talk to zyga since he has been in charge of the cross distro story)
<kyrofa> ogra_, but I don't know if it's something to be fixed in the snapd packaging or what
<ogra_> well, as i said, not sure we can actually call it a problem ... sudo behaves as advertised and snnapd cant really mangle the other configs that would enhance $PATH
<jdstrand> stgraber: that should work with snapd 2.0.9 that is in xenial now, so I think that is the only thing to change
<ogra_> kyrofa, probably someone from the security team can elaborate if the sudo behaviour is correct
<kyrofa> ogra_, alright, thanks
<ogra_> (i think it is though ... this is a tricky one)
<stgraber> jdstrand: yeah, my snapd was built from current git as I needed my squashfuse support patch
<jdstrand> you should be doubly ok then :)
<kyrofa> jdstrand, currently /snap/bin is in the user's path, but the `sudo` secure path doesn't include it, which means `sudo snapname.appname` doesn't work. Can you think of a secure way to fix that?
<jdstrand> that is an old bug
<kyrofa> jdstrand, I know, but I didn't see any bugs actually logged about it
<kyrofa> jdstrand, maybe there was and I just duped it
<kyrofa> jdstrand, I seem to remember it working in 15.04 though
<sergiusens> elopio yeah, just discussing that with josepht right now, already have a fix. Let me push
<jdstrand> I think there is one, however, I'm going to defer to mdes laur since he looked at secure path for something else recently on 16.04. he is on holiday though. is this something you can circle back on (I would think so, this bug is ancient)?
<elopio> sergiusens: cool, I'll rebase mine.
<kyrofa> jdstrand, oh certainly
<jdstrand> I think he'll have most of the considerations at hand
<kyrofa> jdstrand, I'm going to forget though, so I'm going to send out an email if that's okay?
<jdstrand> kyrofa: please send to security@ubuntu.com and you might get people responding sooner :)
<kyrofa> jdstrand, you got it! Is that an open list?
<jdstrand> it's an email exploder for just the security team
<kyrofa> Okay very good
<kyrofa> jdstrand, do you know if a bug was ever logged about that issue?
<kyrofa> jdstrand, I know it's old
 * jdstrand looks
<jdstrand> kyrofa: bug 1411671. it looks like we did fix it in 15.04 core images via ubuntu-core-config, but I think it needs to be revisited, esp. for changing this on classic
<ubottu> bug 1411671 in Snappy "/apps/bin should be added to sudoer's secure_path" [Wishlist,Fix released] https://launchpad.net/bugs/1411671
<kyrofa> jdstrand, ah, that explains why it used to work!
<kyrofa> jdstrand, still worth a security email?
<kyrofa> Also, I figure that bug should just be re-opened and mine marked dupe, but I'm not sure how to track a bug that's fixed in 15 and valid in 16. Just target to series?
<zyga> jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/48/files
<zyga> tyhicks: thanks for your comment
<ogra_> jdstrand, hmm, do you know if adding to secure_path via a sudoers.d snippet would work ?
<ogra_> ah
<ogra_> seems += will work
<sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/598
<ogra_> argh
<ogra_> or not
 * ogra_ just killed sudo on his laptop
<ogra_> damned
<zyga> ogra_: :D
<zyga> ogra_: when fiddling with sudo config, have a root session around
<ogra_> well, i havent seen recovery mode in years ...
<ogra_> zyga, if i actually plan to work on it i do that too ... damned spontanity at 34â²C
<dholbach> all right my friends - I call it a day - see you all tomorrow again!
<seb128> dholbach, enjoy!
<dholbach> you too
<zyga> ogra_: 34!! where are you?
<zyga> ogra_: still in greece?
<jdstrand> morphis: hey
<morphis> jdstrand: so what are we doing with pulseaudio and the recording on xenial
<morphis> I may can spend and hour or so on monday to get this started
<jdstrand> morphis: the agreement was to sru blocking recording and then work on pulseaudio/trust-store/interfaces migration to express recording in interfaces
<jdstrand> morphis: sru is phase 1. interfaces phase 2
<morphis> right
<morphis> phase 1 is what I meant
<jdstrand> the meeting yesterday was for phase 2, but the meeting didn't happen and I need to reschedule
<morphis> aye, I mainly meant the bug you pinged me about yesterday
<jdstrand> morphis: yeah, that is part of phase 1
<morphis> jdstrand: so what is left for this is proper testing and then getting the SRU out
<jdstrand> sounds great :)
<morphis> jdstrand: I can do the testing on monday
<morphis> maybe someone else can then help with the SRU
<jdstrand> awesome! I'll make a note in the card. thanks! :)
<jdstrand> morphis: what kind of help are you looking for? helping through the process?
<morphis> either that or someone taking it completely
<jdstrand> morphis: if I had a tested debdiff I could get it over the finish line
<morphis> jdstrand: sounds good
<morphis> jdstrand: then lets do it this way
<jdstrand> morphis: great, thanks!
<morphis> jdstrand: will ping you on monday then
<jdstrand> cool
<sborovkov> Hello. Doing sudo apt update on Ubuntu Mate on RPI - and getting this E: The repository 'http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial Release' does not have a Release file. - any ideas what could be happening.
<sborovkov> Also this error is the first one -  Cannot initiate the connection to ports.ubuntu.com:80 (2001:67c:1360:8001:1::2). - connect (101: Network is unreachable) [IP: 2001:67c:1360:8001:1::2 80]
<ogra_> any reason why you have this ppa enabled ?
<popey> jdstrand: what does this mean:- "adjust snap to ship 'scmp_sys_resolver'
<popey> (forgive my ignorance)
<jdstrand> scmp_sys_resolver is what is used to resolve a syscall number to a name (or vice versa). whatever snap that is should ship it as part of the snap. if it is snappy-debug, that is a known issue-- do 'apt-get install seccomp'
<popey> on the host, not in the snap?
<popey> seccomp is already the newest version (2.2.3-3ubuntu3).
<popey> on the host
<jdstrand> popey: yes, on the host. is that snappy-debug?
<popey> yes
<popey> http://paste.ubuntu.com/17754105/ is the full output
<popey> am fixing the network-bind one first
<jdstrand> popey: oh, install it in strict mode and that will go away
<popey> oh
<jdstrand> there are some issues with complain mode logging that we're working through
<popey> super
<jdstrand> snappy-debug also needs some work that will happen after some other higher priority interfaces work
<popey> I seem to be picking all the awkward apps to snap :)
<jdstrand> popey: several of those denials are fixed in 2.0.9. plug the opengl interface and reinstall and two of those will go away (it may make the ptrace go away too)
<popey> jdstrand: sorry, what do you mean by "plug the opengl interface"?
<jdstrand> popey: in qtox, make sure you have 'plugs: [ ..., opengl ]'
<popey> ah, i do
<jdstrand> popey: upgrade to 2.0.9, then uninstall and reinstall qtox then
<popey> awesome, thanks
<jdstrand> that uninstall/reinstall things is also queued up and will be resolved in the next couple of sru cycles
<seb128> jdstrand, mvo, did you see bug #1595478 ?
<ubottu> bug 1595478 in ubuntu-core-launcher (Ubuntu) "package snap-confine 1.0.30 failed to install/upgrade: trying to overwrite '/etc/apparmor.d/usr.bin.snap-confine', which is also in package ubuntu-core-launcher 1.0.29+2" [Undecided,Confirmed] https://launchpad.net/bugs/1595478
<seb128> unsure where those packages are coming from
<jdstrand> seb128: I did. I pointed it out to zyga today. I think 1.0.30ubuntu1 may fix it
<seb128> jdstrand, thanks
<sergiusens> elopio is our testing infra down?
<croepha> so ubuntu-core-launcher /is/ snap-confine?
<ogra_> seb128, jdstrand they were falsely synced from debian (and i thought removed from the archive already)
<jdstrand> croepha: re snap-confine is the name of the project. ubuntu-core-launcher is the package name for snap-confine in Ubuntu 16.04 for historical reasons
<jdstrand> source package name*
<croepha> jdstrand: gotcah
<croepha> jdstrand: I mean, thanks :)
<jdstrand> :)
<mhall119> jdstrand: can you look at https://bugs.launchpad.net/snappy/+bug/1595649 and see if this is a confinement thing (I don't think so, because it fails in --devmode too) or not?
<ubottu> Launchpad bug 1595649 in Snappy "Audio playback fails for KDE apps with Phonon" [Undecided,New]
<d_ed> mhall119: it'll be failing to find a phonon backend, it's based on a hardcoded path at compile time
<d_ed> by default ${CMAKE_INSTALL_PREFIX}/${PLUGIN_INSTALL_DIR}/plugins
<croepha> so, im assuming that if I snap install with --devmode then i am essentially bypassing all the Apparmor/interfaces access control stuff right, i should essentially have all the rights as if I was running not in a snap right?
<mhall119> sgclark: ^^ see above.
<mhall119> d_ed: is there a configuration work-around for that, or does it require a patch to some upstream code?
<mhall119> croepha: I believe so, yes
<zyga> croepha: yes, except that you still run in a different filesystem
<sgclark> mhall119: d_ed that is what I thought. I tried setting several env vars in qt5-launch without luck.
<d_ed> as far as I can see, no
<d_ed> however, it does also search the Qt install path - so one /could/ change phonon backends to install where Qt does or maybe add symlinks
<d_ed> ..or we fix upstream code
<d_ed> see ensureLibraryPathSet() in Phonon
<sgclark> ok
<sgclark> thanks
<croepha> mhall119, zyga: Thanks
<jdstrand> popey: fyi, I updated snappy-debug for the new 2.0.9 policy which should help the experience a bit
<jdstrand> it's in the store
<zyga> jdstrand: hey, what is your opinion on https://github.com/snapcore/snap-confine/pull/48
<zyga> jdstrand: I'd like to move forward on that branch
<zyga> jdstrand: also a small bug in https://github.com/snapcore/snap-confine/pull/7/files#r68295578
<popey> jdstrand: thanks
<popey> is there a way to update all my snaps at once now?
<popey> uh..
<popey> alan@gort:~$ sudo snap refresh snappy-debug
<popey> error: cannot perform the following tasks:
<popey> - Download snap "snappy-debug" from channel "stable" (revision 22 of snap "snappy-debug" already installed)
<zyga> known issue
<popey> ok
<jdstrand> popey: remove and reinstall and you should be set
<popey> ah
<zyga> jdstrand: if you fix the one thing that probably leads to snap-confine crash I'll merge the seccomp filtering patch
<jdstrand> zyga: huh?
<jdstrand> what crash?
<jdstrand> is it in the PR?
<jdstrand> I see your notes
<jdstrand> meh, last minute change
 * jdstrand fixes
<zyga> jdstrand: I've commented on the pull request
<jdstrand> I see
<jdstrand> zyga: done. note the ci tests failed for something unrelated
<cwayne> zyga: have you treid running refresh-bits in yakkety?
<croepha> anyone got xserver-xorg running in a .snap that I can look at? im having all kinds of issues, currently im getting a segfault in xf86OutputClassDriverList tracking it down now
<croepha> ?
<elopio> sergiusens: we have coverage: https://github.com/ubuntu-core/snapcraft/pull/597
<elopio> if integration tests pass in travis, you can land this one and the requirement.
<jdstrand> croepha: I don't have specific details on that question (I don't know anyone who has tried that), but most people will not embed the X server in the snap and install use 'plugs: [ x11 ]' (or unity7) and install the snap on a 'classic' system (eg, a desktop system with X)
<jdstrand> croepha: now, if you are trying to run X as a snap to serve to other clients for a system that doesn't have X (eg, an iot device), that hasn't been done yet, but others on the list might be able to help
<jdstrand> s/list/channel/
<croepha> i am specifically trying to get xorg to run in core
<jdstrand> I see
<jdstrand> start with --devmode for sure since at some point the x11 interface will need to implement the slot side to allow X to run
<croepha> ok, thanks for feedback, i'll keep pushing forward, i think ive traced the issue to a null pointer, now i need to figure out why its null in my case
<jdstrand> when you are at that point, file a bug with the 'snapd-interface' tag and we can work through that
<croepha> sweet
<jdstrand> croepha: also, I'm not sure how many X devs there are here. since you mentioned xserver-org that suggests you are using Ubuntu. You might try in #ubuntu-desktop (maybe there is an #ubuntu-x channel too?)
<jdstrand> they won't know as much about snappy, but might be able to help with X-specific things
<croepha> ok, good point
<sergiusens> elopio I don't understand the docker service and the need to specify python (and why it is not 3.5)
<elopio> sergiusens: the docker service is to be able to do docker run. The need to specify python is just for coveralls. It's the same insane thing that blocked me for a week with lxc.
<elopio> it could be 3.5, I think.
<elopio> let me try.
<sergiusens> elopio nah, if it is just for coveralls and we will run 3.5 for our tests we are good
<elopio> sergiusens: we are running our tests in whatever is in that xenial image.
<elopio> which is the official one, so I'm guessing 3.5 or 3.6
<croepha> is there a way to tell snapcraft to just use apt-get source ... to get the package source ?
<niemeyer_> croepha: I don't *think* source packages has any special support yet
<niemeyer_> croepha: bin packages do, and you can always cook some custom logic to achieve what you want, of course
<croepha> niemeyer_ you mean like put my apt-get source stuff, confiugre command, ... make install  in a script and tell snapcraft to exec the script for the build ?
<niemeyer_> Something along those lines.. but if you're using autotools, perhaps using the plugin for that is easier than going through the package
<croepha> is there a way for a snap to know where something is going to be on the filesystem? like xorg needs to know at compile time the directory where xkbcomp is located, but the snap can be in a different path depending on revision... the best I can come up with is to have a script that runs and makes a link to the snap in /tmp based on the $SNAP_REVISION env variable, is there a better way?
<zyga> jdstrand: thanks for fixing that
<zyga> croepha: ideally this would be based on $SNAP from environment but we are discussing other options
<zyga> jdstrand: the chdir / cwd issue is now convincing me that snap-confine should know what is expected and yes, perhaps refusing to work is the right thing to do right now
<zyga> jdstrand: my only concern is what is the cwd of apps started from unity or gnome shell
<zyga> (I'd be bad if all of those refused to work)
#snappy 2016-06-24
<sergiusens> elopio can you check https://github.com/ubuntu-core/snapcraft/pull/584 ... I have no vpn here
<derpSauce> Dumb question, can I install snapd on ubuntu 14.04?
<dholbach> hey hey
<netphreak> Hi, guys!
<zyga> good mornig
<netphreak> morning :)
<netphreak> Any news on Rpi3 support?
<morphis> mvo: ping
<mvo> morphis: pong
<morphis> mvo: what's up with snapd 2.0.10 ? :-)
<mvo> morphis: a bit of internal debate, I will enquire about this I think we can do one today otherwise
<morphis> ok
<didrocks> zyga: hum, seems that I'm stuck at removing one snap
<didrocks> 161  Done    2016-06-24T08:31:46Z  2016-06-24T08:31:46Z  Try "atom" snap from "/home/didrocks/work/ubuntu-core/snappy-playpen/atom/prime"
<didrocks> 162  Doing   2016-06-24T09:04:17Z  -                     Remove "atom" snap
<didrocks> mount | grep atom returns nothing
<didrocks> and as there are some operations in progress, I can't do anything
<zyga> didrocks: what does 'snap change 162' say?
<didrocks> zyga: http://paste.ubuntu.com/17792496/
<didrocks> so, I was able to stop it manually (some processes were hanging the mount point)
<didrocks> however, despite unmouting it, not snapd is stuck
<didrocks> ah no, it's done
<didrocks> (after a while)
<didrocks> still the same change #
<didrocks> but snap change <this_number> still shows the error
<didrocks> (which is puzzling)
<didrocks> at least, now, the transaction is over, thanks zyga :)
<zyga> didrocks: snapd will recover after 5 minutes
<zyga> didrocks: we already know about issues when the service doesn't shut down cleanly
<zyga> jdstrand, tyhicks: i've tested the more strict version of snap-confine and it should be merged as tyhicks suggested
<zyga> I'll adjust some tests and merge it
<Snowie> Howdy all. Not sure where to report. Installing freecad on ubuntu as a snap didn't produce a working desktop shortcut or cli command. installing it from apt did. Just want to know where to let someone know?
<didrocks> I think lool followed the freecad guys on their snappy journey ^
<ogra_> well, works fine here
<ogra_> freecad.FreeCAD the cli command it installs
<ogra_> Snowie, ^^
<lool> ogra_: did you get a desktop file?
<ogra_> lool, hmm, i know ii used to have one ...
<ogra_> seems gone
<ogra_> or t least not found anymore
<ogra_> the cli command is definitely still here though and the app starts and runs fine
<Snowie> ogra_: i did try that, but let me give it another go.
<ogra_> Snowie, are you on an Ubuntu 16.04 install or is that some other distro ?
<Snowie> ogra_: standard 16.04
<ogra_> k
<ogra_> same here
 * ogra_ is off to the dentist ... (at least something positive on this horrid day :P )
<Snowie> no joy http://paste.ubuntu.com/17794309/
<Snowie> ogra_: oh. good luck, hope it's not too terrible.
<ogra_> nah, just a post surgery inspection .. all bad stuff already happened
<Snowie> ogra_: lol. ok, hope all is well then
<ogra_> Snowie, try freec<tab> ... doesnt that expand to freecad.FreeCAD ?
<Snowie> ogra_: lol, yeah that did it. thanks
<ogra_> (the binary is actually called like that, not just "freecad")
<Snowie> still no icon thought but cheers
<ogra_> yeah, thats a bug
<ogra_> the binary should also just become "freecad"
<Snowie> ogra_: and sounds like it's known by that comment too. ok cheers
<ogra_> well, probably not by the freecad developer
<ogra_> lool, ^^ can we get him that info somehow (i only know him from IRC)
<ogra_> anyway ... -> out
<lool> ogra_: I was looking for a public link to this email address but https://uappexplorer.com/app/freecad.vejmarie has a weird one
<ogra_> re ...
<zyga> jdstrand, tyhicks: I'd like a final yes/no vote on chdir branch
<zyga> jdstrand, tyhicks: after your decision I'd like to merge remaining branches and release new snap-confine
<zyga> and work on snapd changes to make policy changes automatic
<zyga> so that refreshed policy is applied when needed
<jdstrand> zyga: I responded in the PR
<jdstrand> zyga: and yay on refreshing policy as needed as being up next :)
<jdstrand> zyga: interestingly, the apparmor side of that bug (which is not needed for your work) is close to my next thing to work on :)
<zyga> jdstrand: thank you, looking now
<zyga> jdstrand: good point, I'll make the change now
<zyga> jdstrand: cross-distro concern, how can we simplify our work to not have to synchronize various apparmor abstraction across the distros
<jdstrand> zyga: this isn't actually just a cross distro concern and something we've thought about all along. a) abstractions don't change that much and b) when they do, we push the change both to apparmor upstream and to snapd policy so snapd can realize the benefits immediately
<jdstrand> we can periodically prune the duplicate rules in snapd and say snapd required apparmor userspace version x.y.z
<jdstrand> requires*
<jdstrand> zyga: and thank you for merging the arg filtering branch-- it's been a long time coming :)
<jdstrand> zyga: once snap-confine and snapd 2.0.10 land, that will allow me to fix a whole slew of policy bugs in 2.0.11+
<dpm> dholbach, good work with summarizing the knowledge extracted from the playpen :)
<ret2libc> hi! for what you know, has there been any attempt to create an opensource store/repo for snaps?
<ogra_> ret2libc, not for ubuntu .. but see the mailing list, there is a discussion about stores on other distros
<ogra_> (the "store" is just a webserver after all )
<kyrofa> ret2libc, indeed, keep an eye on the mailing list, efforts are ongoing
<zyga> jdstrand: I need to fix debian-8 builds by taking dpkg-vendor patches from alioth
<zyga> jdstrand: please ignore debian-8 build failures for now
<ret2libc> ogra_ kyrofa thanks, i'll have a look at it
<stormchaser3000> is there a way i can get my application i have installed from .snap packages to use the system theme?
<stormchaser3000> and is snapd available on debian 8?
<zyga> stormchaser3000: not in debian 8
<stormchaser3000> oh ok
<zyga> stormchaser3000: system theme support is being explored, it's not easy due to gtk instability with theming
<zyga> stormchaser3000: but we are exploring how to support this
<zyga> stormchaser3000: and there are some technical bits that landed that make it possible to do pratical experiments now
<stormchaser3000> does snapd work on OpenSUSE tubleweed?
<dholbach> dpm, thanks
<ogra_> if it doesnt yet, it will soon
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/48/commits/0e690b310d1ce4fb772fab3085015897d62bf7d0
<zyga> jdstrand: FYI, just in case I messed up something
<kyrofa> sergiusens, ping
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/50/files
<ret2libc> can snap already run on other distros?
<ogra_> ret2libc, yes, in several ( zyga has a list i think)
<ret2libc> wow, that's cool! i really hope it will be adopted by others too
<kyrofa> dholbach, I'd bring up the client cancellation (the broader issue you mentioned) in the channel, but there are too many conversations happening there right now :P
<zyga> ret2libc: yes!
<zyga> ret2libc: there are packages for fedora, arch and gentoo
<zyga> ret2libc: I'm working on packages for suse
<zyga> ret2libc: there's also a package in debian that propagates to ubuntu (snap-confine) and soon snapd too
<zyga> ret2libc: and from debian and ubuntu to many other distributions
<zyga> ret2libc: note that today snappy doesn't support confinement on distributions that don't use the ubuntu kernel, we are working on upstreaming everything and enabling other distributions to support the whole security
<ret2libc> that's really nice, zyga!
<zyga> ret2libc: if you have any questions about that I'm all ears :)
<dholbach> kyrofa, yeah :)
<dholbach> maybe a bug report would work better
<ret2libc> zyga: i didn't you were changing the kernel to add features for confinement. aren't you using cgroups?
<ret2libc> and apparmor?
<kyrofa> ret2libc, among other things
<zyga> ret2libc: we are using cgroups but that's very minor and it's not used most of the time
<zyga> ret2libc: most of the patches are apparmor features that we developed to make this really solid
<kyrofa> ret2libc, https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ if you're curious
<zyga> ret2libc: those are being upstreamed and I'm looking at building supporting kernels for gentoo and arch
<ret2libc> ahh that's nice! thanks kyrofa
<zyga> ret2libc: but this work is still some time away
<ret2libc> zyga: are those patches available?
<zyga> ret2libc: of course :)
<zyga> ttps://git.launchpad.net/~p-pisati/ubuntu/+source/linux/
<zyga> https://git.launchpad.net/~p-pisati/ubuntu/+source/linux/
<zyga> good people tell me that the apparmor features are posted to mainline but it's a process as you probably know
<zyga> ret2libc: there are snappy branches there that contain everything required
<zyga> ret2libc: it's really just the ba
<zyga> ret2libc: it's really just the brand new apparmor features + corresponding configs that make snappy security work
<zyga> ret2libc: seccomp and userspace apparmor bits are already upstream
<plars> fgimenez: elopio: Hi, did you see the error I sent when I tried to run it from the branch?
<ret2libc> zyga: i see. thanks a lot for those info
<jdstrand> zyga, niemeyer: fyi, I'm taking a few minutes to clean up/expand docs/interfaces.md
<niemeyer> jdstrand: Sweet
<niemeyer> jdstrand: Btw, there's a problem we need to sort out with the network interface.. zyga is aware of it and looking into it, but it'd be nice if you two could discuss the issue too
<jdstrand> niemeyer: see your inbox on cleaning up 'Usage'
<niemeyer> jdstrand: Apparently even a boring network client right now depends on network-bind to do DNS, which kills the point of having the separation
<jdstrand> that is surprising
<jdstrand> is this an i386 thing?
<jdstrand> cause that might be the socketcall issue
<niemeyer> jdstrand: Would be good to get that fixed, either by understanding what's going on and fixing it, or by killing network-bind altogether if we cannot avoid the dependency
<niemeyer> jdstrand: I don't know, zyga has the details
<jdstrand> is there a bug?
<niemeyer> zyga: ^
<jdstrand> ok, zyga, please fill me in and with a reproducer
<jdstrand> cause we've had the separation and its worked for a while. curious what changed
<popey> jdstrand: wrt bug 1589671 - I have 2.0.9 and still see the issue, or a similar one - http://paste.ubuntu.com/17803532/
<ubottu> bug 1589671 in Snappy "apparmor failure on udev with opengl interface" [Medium,Fix released] https://launchpad.net/bugs/1589671
<jdstrand> popey: that's a different issue
<popey> \o/
<popey> I love finding these and keeping you in work :)
<popey> do you need me to file a bug for it jdstrand ?
<jdstrand> yes please. add the snapd-interface tag and the udev denials
<popey> okay, thanks.
<popey> ok, filed bug 1595987
<ubottu> bug 1595987 in Snappy "udev denials " [Undecided,New] https://launchpad.net/bugs/1595987
<jdstrand> thanks
<gouchi> same error here : https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860
<ubottu> Launchpad bug 1570860 in snapd (Ubuntu) "Love2D needs udev access" [Medium,Triaged]
<gouchi> about /run/udev/data/c**
<arcade_droid> I created a suggestion on Steam's Github to start using Snaps or flatpaks to distribute games in Steam. https://github.com/ValveSoftware/steam-for-linux/issues/4512 Now, the question is, is it possible to partially update a snap to avoid re-downloading 8+GB of data to patch one, simple thing?
<arcade_droid> For example.
<popey> gouchi: ooh, you're looking at love2d?
<popey> awesome, I had a play with that a while back but not looked recently
<popey> would... "love" to see that snapped
<gouchi> popey: another project ;-)
<popey> :)
<popey> jdstrand: did I need to file a bug about 32-bit binaries, or was that a 'wontfix'?
<gouchi> popey: but I like also love2d ;-)
<jdstrand> popey: there is a bug already. it is likely won't fix
<popey> :(
<popey> no wine in snaps
<popey> that's a shame, having wine/libwine would be a neat way to package up some windows apps (or games) in the store
<ret2libc> zyga: what are exactly those new apparmor features that you want to add?
<zyga> ret2libc: you'd have to go through the patches, there's quite a lot I've heard
<zyga> niemeyer, jdstrand: I didn't file the bug for this yet
<jdstrand> popey: wine doesn't mean 32bit only
<zyga> jdstrand: and FYI, I don't quite know what the root problem is, I tried using spread (a go binary so it might be go specific) and it happily created variou sockets and tried to bind them on startup
<zyga> jdstrand: let me pull the strace log and report this
<niemeyer> zyga: Can we please get a bug with a reproducer?
<niemeyer> zyga: Otherwise it'll fall through the cracks
<zyga> niemeyer: yep, just doing that now
<niemeyer> zyga: Thanks!
<arcade_droid> Not sure if my previous message managed to send itself, my connection is a bit wonky. I'll ask again. I created a suggestion on Steam's Github to start using Snaps or flatpaks to distribute games in Steam. https://github.com/ValveSoftware/steam-for-linux/issues/4512 Now, the question is, is it possible to partially update a snap to avoid, for example, re-downloading 8+GB of data to patch one, simple thing?
<popey> jdstrand: only 32-bit wine can run 32-bit windows apps, only 64-bit wine can run 64-bit windows apps, and not 32-bit ones AIUI
 * popey is getting deja vu
<popey> have we had this conversation already? :)
<jdstrand> popey: sure. my point is that you can still ship 64bit wine to run 64bit wine apps
<jdstrand> popey: and 32bit wine to run 32bit wine apps
<jdstrand> architectures just needs to match
<popey> so 32-bit wine will work on ubuntu-core i386? but not on ubuntu-core amd64?
<jdstrand> I understand that doesn't address 32bit wine on 64bit machine, but I think there is still good things to be had
<jdstrand> popey: sure, why not?
<popey> we're in circles :)
<popey> my problem is that 32-bit wine doesn't run on amd64 ubuntu-core
<popey> and you said earlier that's a wontfix?
<jdstrand> popey: you were too general with this statement: "no wine in snaps"
<popey> hah, okay
<jdstrand> popey: that is not accurate. you *can* have wine if wine matches the arch
<popey> ok, so a more specific question would be "do we support 32bit binaries in 64-bit host ubuntu-core?"
<popey> this isn't a wine specific issue is it?
<popey> (so skype i386 on amd64 would be equally problematic)
<zyga> jdstrand, niemeyer: https://bugs.launchpad.net/snappy/+bug/1595993
<ubottu> Launchpad bug 1595993 in Snappy "go binary (spread) uses bind on startup, requiring network-bind" [High,New]
<jdstrand> this is a kernel limitation with seccomp
<fgimenez> plars, looking into it now
<ret2libc> zyga: ok will do!
<zyga> jdstrand: I think that bug above requires some deep dive into go to understand
<zyga> jdstrand: but I wonder if there's something we could do with seccomp filtering to let it be
<zyga> jdstrand: but I don't know, looks terribly like those very carefully profiled security things that only allow a given sequence of syscalls
<jdstrand> zyga: ok-- it seems it is pretty clearly wanting to use socket. not sure what the problem is?
<zyga> jdstrand: nothing in the code does this
<zyga> jdstrand: it's some startup thing in go or maybe libc
<jdstrand> something in the code is doing it :)
<zyga> jdstrand: and this means that all the software will require network-bind in effect
<jdstrand> but that's not true
<zyga> jdstrand: not explicitly, this might be something each executable starts to do
<zyga> jdstrand: I'll dig around, I wanted to report this first
<jdstrand> there are plenty of applications that don't need network-bind to use the network
<jdstrand> it might be a go thing, and yes, we might be able to do arg filtering somehow
<jdstrand> zyga: why is this 'high'?
<jdstrand> zyga: it only affects go and people can always specify 'network-bind' which is autoconnected
<jdstrand> I'm not saying it shouldn't be fixed, I'm saying that it probably shouldn't trump other high priority work
<zyga> jdstrand: I set it to high to investigate what the cause is; if there's something potentially causing many programs to require network-bind without knowing ti
<zyga> it*
<jdstrand> zyga: so, this application is very clearly binding to a port on the loopback: bind(4, {sa_family=AF_INET6, sin6_port=htons(0)...
<jdstrand> that says that network-bind should be used
<jdstrand> most programs don't need that
<jdstrand> a go program might, but, so?
<jdstrand> anyway, yes, it is worth investigating
<zyga> jdstrand: but it's not doing this in the go code, there's no bind there anywhere
<zyga> jdstrand: I want to check if this is endeminc to go runtime
<jdstrand> but I'm not worried by this
<jdstrand> it might be. go does all kinds of stuff
<aatchison> Heyo
<jdstrand> if you look at netstat -atuvpn, you should see it is listening on a port
<aatchison> I'm getting the encrypted user directory apparmor error!
<jdstrand> (one chosen by the kernel)
<jdstrand> aatchison: that is on the verge of being fixed with the pending snap-confine upload
<aatchison> cool
<aatchison> how soon:P I just need a workaround if I can get it
<aatchison> Can't tell what's going on
<jdstrand> aatchison: https://bugs.launchpad.net/snappy/+bug/1574556 has a workaround
<ubottu> Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu Xenial) "apparmor denials reported for encryped HOME" [Medium,Triaged]
<aatchison> awesome, thanks
<popey> jdstrand: okay, thanks for clarifying :)
<popey> I promise not to ask you about 32 bit again ã
<jdstrand> hehe
 * jdstrand -> errand
<zyga> jdstrand: the issue is now well-understood
<zyga> jdstrand: I'll look at it next week, I want to focus on bind mount support and next release of snap-confine
<zyga> jdstrand: before you EOW today, can you weight in on https://github.com/snapcore/snap-confine/pull/50 please?
<slangasek> zyga: fyi, snap-confine 1.0.33-1 has been accepted through Debian NEW now (including source package rename), so should also find its way into yakkety soon
<slangasek> oh
<slangasek> except that requires a merge
<slangasek> er, no it doesn't, because it's a new source package name so it'll just take over the binary name
<joc_> kyrofa: hi, do you how to easily go about setting default_plugin_output correctly in the list plugins tests of snapcraft? (after adding new plugin)
<kyrofa> joc_, hahaha, aren't those lovely tests?
<joc_> indeed, super lovely :)
<joc_> kyrofa: do i need to set some environment variable on my local console to make sure i have correct output width or something?
<kyrofa> joc_, honestly what I do is I copy/paste the "actual" output
<zyga> slangasek: that's great news, thank you
<kyrofa> joc_, watch the test fail, steal the output
<kyrofa> = 100% useless test
 * zyga -> dinner
<plars> fgimenez: so running from the branch still doesn't work for me, but running uner checkbox I'm seeing a lot better results running on an allsnaps image vs. classic
<fgimenez> plars, great! it would be nice anyway to have better logs in both cases, i'm not able to reproduce your error http://paste.ubuntu.com/17809595/ which version of go are you using?
<plars> fgimenez: 1.6.1
<fgimenez> plars, that should work.. are you executing from the gopath (not from a symlinked dir)? iirc we needed that when building from branch, not the case anyway
<plars> fgimenez: hmm, no I'm not sure what you mean by symlinked dir, I was running from the dir of my checkout. Which I guess go just totally ignores. As soon as the run with checkbox finishes, I'll switch to the one it pulled into my GOPATH and try from there
<fgimenez> plars, ok let me know how it goes
<sergiusens> kyrofa pong?
<kyrofa> sergiusens, I was going to ask you a question about the qmake plugin, but I asked in the PR instead
<joc_> kyrofa: please please please dont land any other plugins before me, i dont want to have rebase and do that all again :p
<kyrofa> joc_, muhahaha
<kyrofa> joc_, I've done it twice now, stop whining!
<kyrofa> sergiusens, we really need to toast those list_plugins tests
<sergiusens> kyrofa we do, but they got a whole lot more special now, didn't they ;-)
<sergiusens> elopio is the triggered on https://github.com/ubuntu-core/snapcraft/pull/566 running?
<elopio> sergiusens: no, we are redeploying jenkins again.
<jdstrand> zyga: done
<elopio> sergiusens: like 30 minutes to go.
<sergiusens> elopio yay
<sergiusens> elopio doesn't matter as I added a comment to that PR for kyrofa ;-)
<sergiusens> elopio just interested in the adt and examples on that one as snapcraft.internal was touched. If it fails and units pass we have more work to do ;-)
<sergiusens> zyga how is it going with the font interface, do you know?
<elopio> sergiusens: yes, when the branch is ready kyrofa can run adt or examples locally :) Or I can help, I have plenty of testbeds around.
<elopio> jenkins might be ready earlier.
<aatchison> Would anyone be interested in helping me hack on mycroft snap today?
<zyga> sergiusens: we have the content sharing now, with somewhat different design (only one content can be consumed at a time)
<zyga> sergiusens: with some more work and a test case we should be able to use that to share classic fonts
<zyga> sergiusens: I'm looking at finalizing the snap-confine side of content sharing now
<zyga> sergiusens: do you have a snap that can be used to test this?
<zyga> note that we don't have the global sharing part yet (we need to allow all canonical-published slots to work this way)
<kyrofa> elopio, sergiusens that branch is ready for another look. Do I need to run something locally, then?
<sergiusens> zyga there are non, maybe start big and use kde? :-P
<elopio> kyrofa: maybe ./runtests.sh snaps --skip-install
<elopio> if you have a xenial vm, you could run with the install using --ip localhost.
<kyrofa> elopio, I do, I'll use it
<sergiusens> aatchison hey, so where are you at with this?
<zyga> sergiusens: kde would be nice but I'd rather have others build something I can split
<kyrofa> elopio, though it's not localhost. Can I use user@ip instead?
<elopio> kyrofa: I think that the user is hardcoded to be ubuntu. There's a bug for that.
<kyrofa> elopio, :(
<aatchison> I'm having some issues all around, but I can build a snap. I've just included speech-dispatcher as a stage-package. I could use some help with the pulseaudio interface stuff, as I don't see the interface existing
<kyrofa> I knew making a VM without ubuntu was dumb
<kyrofa> I'll just --skip-install
<aatchison> I finally figured  out that I needed to use the app armor work around, because I have an encrypted home directory
<elopio> kyrofa: well, actually making the testbed assuming that ubuntu was the user was dumb.
<aatchison> https://github.com/MycroftAI/snapcraft-mycroft-core
<aatchison> there is my yaml, if one would like to try
<kyrofa> elopio, heh
<elopio> kyrofa: but on your vm you can clone, and run from there. I think you will have to mkdir /home/ubuntu
<kyrofa> elopio, I seem to remember there being issues using snapd from newly-created users
<elopio> please file bugs for anything that makes that experience awful. I'll fix them next week.
<sergiusens> elopio I've updated #590
<sergiusens> aatchison but does it work with --devmode, pulseaudio integration that is?
<aatchison> I'm getting this error: ALSA lib conf.c:3750:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf
<kyrofa> elopio, sergiusens crap. Ran out of hard drive space
<aatchison> I now see the pulseaudio interface when I run snap interfaces though, which didn't happen before
<sergiusens> aatchison so pulseaudio != alsa (one may use the other, but they are not the same thing)
<sergiusens> aatchison forget the interface, is that the error you get in devmode?
<aatchison> yeah, I thought that pulse would handle the alsa stuff
<elopio> sergiusens: I think it is "inexistent" or "unexisting", not "inexisting". kyrofa can confirm.
<aatchison> yeah, installed with devmode
<sergiusens> in other words, don't paint the house if the cement has not dried yet ;-)
<sergiusens> elopio yeah, I sort of knew that but kept it :-P I can change if needed
<sergiusens> elopio wait, non-existing is valid english ;-)
<sergiusens> oh, test name :-P
<kyrofa> sergiusens, elopio nonexistent
<elopio> kyrofa: I use unexisting. Is that wrong?
<sergiusens> kyrofa elopio inexisting is also valid, just checked the dictionary ;-)
<kyrofa> Hahaha
<kyrofa> Fine fine, they're all valid. Stupid english
<kyrofa> Just another reason to learn spanish I guess
<zyga> kyrofa: I'm in a bind now
<kyrofa> zyga, what's up?
<zyga> kyrofa: how come I learned english and not spanish as a kid
<kyrofa> Hahaha
<kyrofa> Yeah no kidding
<zyga> kyrofa: just reacting to your comment above :)
<kyrofa> zyga, does learning english make it harder to learn something else?
<zyga> kyrofa: yes, very
<kyrofa> I can imagine
<zyga> it made me lazy
<zyga> all the books and movies are in english
<sergiusens> elopio kyrofa there, changed it completely so no grammar flame war can happen
<elopio> :)
<sergiusens> aatchison oh, why would you need access to that; the core image where this runs on top of doesn't have alsa
<sergiusens> zyga ideas for that? ^
<aatchison> ahh, I see. I know that were is an alsa snap, but...
<sergiusens> aatchison no there is no alsa snap, just pulseaudio
<sergiusens> aatchison what code is trying to do this and why?
<aatchison> mimic, out TTS program, is trying to use an alsa audio device. I don't know why it needs to access that file though
<aatchison> There is pulse audio support in mimic as well
<zyga> sergiusens: alsa is in the kernel, it's always there but confinement refuses access
<zyga> aatchison: do you have the denial log?
<zyga> aatchison: and does the code you are working with support pulseaudio?
 * zyga is super sleepy
<aatchison> http://paste.ubuntu.com/17814234/
<aatchison> there is the audit log
<aatchison> yeah, it does support pulse audio
<zyga> looking
<aatchison> thanks:)
<zyga> aatchison: yes, that is clearly alsa
<sergiusens> zyga his application fails as it wants to access alsa's config
<zyga> sergiusens: those are harmless
<zyga> aatchison: does this application support pulseaudio as a sound sink?
<sergiusens> zyga in any case, that isn't a denial in devmode no is it?
<aatchison> I...believe so
<sergiusens> says ALLOWED
<aatchison> let me check
<zyga> sergiusens: that config file is probably just not there
<zyga> aatchison: you need libpulse or similar in your snap
<aatchison> ahh, stage-packages?
<zyga> aatchison: yes
<aatchison> awesome, ok
<aatchison> I'll pop that in there
<zyga> aatchison: and you need o use the pulseaudio plug on that application
<aatchison> like so?:  plugs: [pulseaudio]
<aatchison> under apps:
<zyga> aatchison: uner the app that needs it
<zyga> aatchison: pastebin the snapcraft yaml somewhere
<aatchison> k, I think I have that bit right
<aatchison> k
<zyga> sergiusens: we need something like jsbin for snapcraft.yaml's
<kyrofa> sergiusens, qmake look okay, then?
<zyga> sergiusens: let people paste editable yaml
<zyga> sergiusens: and others to edit that and share
<aatchison> http://paste.ubuntu.com/17814586/
<aatchison> There it is, didn't add lib pulse yet
<wligtenberg> ok, I am here as well aatchison :)
<sergiusens> zyga http://linkode.org/  seems to be down, but that is what you want
<aatchison> wahoo!
<wligtenberg> I was already lurking here :)
<aatchison> hehe
<aatchison> I'm swapping pulse sinks with pavucontrol while mimic is running, seems fine
<aatchison> I'll add that lib
<arcade_droid> > Papers, please!
<wligtenberg> aatchison, I installed it, which command to run it? mycroft-core.cli-client?
<aatchison> mycroft-core.mimic -t "hello" will run mimic
<sergiusens> kyrofa did the --skip-install tests all work ok?
<aatchison> .messagebus start, .skills-client start , .speech-client start or .cli-client start
<zyga> aatchison: so alsa is a nogo, we could add an alsa interface but the problem is that alsa is harder and more limited and also, exclusive, so you'd kill all sound on the host
<kyrofa> sergiusens, still running, I'll ping you. But the code looks okay?
<aatchison> ahh, ok
<wligtenberg> trying mimic results in: failed to create user data directory. errmsg: Permission denied
<aatchison> I'm trying with the pulse lib installed
<aatchison> oh, you have to use the workaround for encryped home dires
<sergiusens> kyrofa yeah, all good
<kyrofa> Awesome
<aatchison> https://bugs.launchpad.net/snappy/+bug/1574556
<ubottu> Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu Xenial) "apparmor denials reported for encryped HOME" [Medium,Triaged]
<wligtenberg> indeed, my home is encrypted
<wligtenberg> aatchison: now it does a core dump because it cannot access /usr/share/alsa/alsa.conf
<aatchison> ya
<aatchison> try the mycroft stuff :D
<aatchison> if I could at least get the thing to run with cli....
<wligtenberg> that is the alsa issue, that was mentioned just now?
<aatchison> yeah
<aatchison> I'm asking if there is a pulse only flag for mimic
<aatchison> added: stage-packages: [libpulse0] , no dices
<wligtenberg> aatchison, I get a permission denied on the python dist-packages but is is still referring to the snapcraft parts directory...
<aatchison> hrm
<aatchison> yeah, I had that happen before
<aatchison> I'm not sure why
<wligtenberg> aatchison: do you remember how you fixed it? :)
<kyrofa> sergiusens, elopio what on earth is this? http://pastebin.ubuntu.com/17815416/
<kyrofa> Also, sorry about the lack of line breaks. /me looks at elopio
<kyrofa> Oh there it is: "Plugin org.apache.maven.plugins:maven-resources-plugin:2.6 or one of its dependencies could not be resolved"
<aatchison> um, no.. i had that problem before I reinstalled my OS, now I don't have it anymore
<kyrofa> Dangit... now I have to start that suite all over again?!
<aatchison> I pushed a new commit to the git
<elopio> kyrofa: run just yours.
<elopio> --filter
<wligtenberg> snapping the core
<elopio> and the line breaks were solved in jenkins. I'm not sure I can do anything for the terminal. /me tries...
<sergiusens> kyrofa network error or our test just broke and we need to update deps, not related to your stuff
<sergiusens> elopio kyrofa echo interpret escape chars
<kyrofa> sergiusens, elopio both qt examples run fine
<elopio> ship it!
<elopio> kyrofa: please file a bug for that maven one so I don't forget to debug it.
<kyrofa> Yay! sergiusens sound okay?
<sergiusens> kyrofa elopio echo -e http://pastebin.ubuntu.com/17815693/
<kyrofa> sergiusens, ah! Nice
<sergiusens> kyrofa yeah, should be good; elopio find the `echo -e` equivalent for `print` in python
<aatchison> ok, compiling mimic with the --with-audio=pulseaudio flag, different results:D
<kyrofa> Shipped
<elopio> kyrofa: but wait, when you see the tests running they print newlines, right?
<kyrofa> elopio, as they're running, yes. But not for errors
<sergiusens> elopio kyrofa standup, come on!
<elopio> sergiusens: omw.
<kyrofa> Haha, sorry, got distracted pressing the button
<kyrofa> Hey wait a minute... sergiusens isn't even here
<sergiusens> kyrofa :-D
<kyrofa> Jerk
<wligtenberg> aarchison, mmm to be sure I installed all updates and rebooted... no luck...
<sergiusens> zyga http://linkode.org/ is up again
<wligtenberg> anybody else here, that would know why it tries to find a python lib from the parts directory where it got built?
<aatchison> dang
<wligtenberg> Let me set up a fresh 16.04 VM then
<wligtenberg> this is my dev machine, that got upgraded from 14.04, so it might have some old cruft in the way
<aatchison> that's actually the story of my last machine
<aatchison> o *snap I think I might have build it with pulse only support, about to push a new commit
<wligtenberg> lol, o snap :)
<aatchison> hehe
<aatchison> it's so close, I've seen it nearly run lol
<aatchison> next ... serial port stuff :P
<aatchison> mimic with pulse worked!
<aatchison> one dwon
<wligtenberg> ah, cool!
<wligtenberg> installing the vm, haven't been much help yet :)
<aatchison> hehe
<aatchison> well, since it takes so much time to find out that some bits are broken, if it builds at all, the more people building the better!
<aatchison> I updated the mycroft-core branch to use the correct cli entry point, if that will fly, we have mycroft ala cli
<wligtenberg> aatchison: but from the version numbering it seems this was still using 0.6.x instead of 0.7
<aatchison> ahh, yeah, it's actually not building from a release anymore
<aatchison> I had to modify mycroft-core
<aatchison> so, it's on the branch feature/snapcraft
<wligtenberg> ah, I see
<wligtenberg> so no popey yet?
<aatchison> actually, it can have that
<aatchison> The mimic folks are working on a release with the precompiled voice
<wligtenberg> L) did you hear the latest Ubuntu UK podcast?
<aatchison> so we don't have to cludge in this giant, slow flitevox file anymore
<wligtenberg> snapcrafting again
<aatchison> ok, I effed it up
<aatchison> clean the pull!
<popey> you making a mycroft snap?
<aatchison> made another commit. I had my entry point all wring
<aatchison> yuuup:P
<popey> sweet
<popey> i had a go at that
<popey> not straightforward
<aatchison> yeah, kinda complex
<aatchison> I just got mimic working though!
<aatchison> so, at the very least we can snap that up and your voice can live in snapspace
<wligtenberg> aatchison, do I need to fully rebuild it? (it is still building the first run...)
<aatchison> snapcraft clean
<aatchison> that will clean all the way to the pull stage
<aatchison> snpacraft clean -s build if you only want to clean to the build stage, etc
<wligtenberg> ok, running snapcraft (again)
<aatchison> it's running! no mimic voice for some reason, but hey
<wligtenberg> ah, can't wait
<aatchison> sweet
<sergiusens> elopio why does this https://github.com/ubuntu-core/snapcraft/pull/590 not have examples in it, did you disable them?
<sergiusens> elopio and 'waiting for status' for a while
<elopio> sergiusens: jenkins is still not up, I'm testing it.
<elopio> it shows autopkgtest because we have it configured in the github settings as required.
<aatchison> ok, anything special that I might have to do to enable network connectivity?
<wligtenberg> aatchison: did mimic work for you? I get an xcb_connection_has_error, shm_open() failed: permisson denied
<aatchison> did you try sudo snap install --devmode ?
<wligtenberg> ah, nope
<wligtenberg> ok, that helps, I got an hello from mimic
<aatchison> aha! plugs , network
<sergiusens> aatchison network fr client side things or network-bind for servery ones
<aatchison> so glad to be at the "it's running at least" stage
<sergiusens> kyrofa question about https://github.com/ubuntu-core/snapcraft/pull/580/files
<aatchison> client side to reach the net
<sergiusens> kyrofa seems the primed_set is not really used for anything now, is it?
<aatchison> but, actually we will need server side too
<kyrofa> sergiusens, true, it doesn't need to exist, but I thought the need might arise to actually track them so I made it
<kyrofa> sergiusens, not necessary though
<sergiusens> kyrofa ok, was really confused on how primed_dependencies made things work
<kyrofa> Hahaha, just the extra "if" is what solves the problem
<sergiusens> kyrofa but it was actually the elif :-P
<kyrofa> Yeah... if it's misleading I'll remove it
<sergiusens> kyrofa it is fine
<wligtenberg> aatchison: ok, I can start the messagebus and cli-client, but it doesn't seem to be doing anything
<kyrofa> sergiusens, okay
<aatchison> make sure you start the skills too
<aatchison> bus -> skills -> client
<wligtenberg> ah, I thought the cli-clinet did that as well
<wligtenberg> aatchison: speechclient fails
<aatchison> yeah, it's looking for pocketsphinx still
<sergiusens> elopio http://162.213.35.179:8081/ghprbhook/  (issue_comment and pull_request) has a "is timing out" message on github
<elopio> sergiusens: yes, jenkins is not up yet :D
<aatchison> but cli is giving me a message that device isn't paired, but gives no code. Wondering if it can reach the server
<elopio> give me a few minutes. I got one green examples execution. Waiting for the autopkgtest one before enabling.
<wligtenberg> aatchison: yeah, I also get that, would that also prevent it from going into listening mode?
<aatchison> it should still be able to detect the wakeword locally, it needs pocketshpinx though
<aatchison> it should also be able to operate with cli only
<wligtenberg> and how would I then interact with it?
<plars> Is there a good solution to running a snap, but not have it think it's running as root? Something I'm working on detects that and helpfully exits telling me I shouldn't run it as root
<plars> I don't see anything in the snapcraft schema that allows this to be specified, but then I also wondered about whether it would even have access to $SNAP_DATA and things like that
<kyrofa> plars, I'm afraid not. Many projects do that unfortunately, for reasons that are not valid within a snap
<kyrofa> plars, however, in my experience (two projects, apache and php-fpm) there are ways to say "please do as I ask"
<kyrofa> plars, indeed, SNAP_DATA is owned by root
<plars> kyrofa: a --just-do-it-dont-warn-me flag? :) I'll check, thanks!
<aatchison> wligtenberg, you should be able to just type into the cli whatever question you like
<aatchison> eg. 2 + 2
<aatchison> eg. what's the weather
<kyrofa> plars, yeah, something like --let-me-shoot-myself-in-the-foot-already
<aatchison> but until it pairs, it will just ask you to pair
<wligtenberg> aatchison: ok, that issue with no access to python libs, was also because I hadn't used dev-mode when installing. That does mean (if I understand it correctly) that it actually does a weird thing, because it tries to access the python lib from where it is built...
<kyrofa> plars, for php-fpm it was -R
<aatchison> ahh, maybe that's the del
<wligtenberg> aatchison: indeed it asks me to pair :)
<aatchison> I'll try that
<aatchison> yeah, I have to check the server to see if it's actually trying to connect
<wligtenberg> aatchison: that's the del?
<wligtenberg> at least now I can work on my normal machine, instead of a vm
<aatchison> *deal
<wligtenberg> ah, ok :)
<monsterjamp> Hello
<aatchison> hello!
<wligtenberg> hi
<monsterjamp> I'm having trouble understanding how the snapcraft.yaml files are formatted and all the examples for the snapcraft.yaml files use make or autotools without passing any arguments. So my question is how would a snapcraft.yaml file look like using make with a target. e.g. on bash I would type "make release"
<wligtenberg> wouldn't dev-mode also give it access to networking? I thought it would basically remove isolation
<aatchison> well, it's not hitting the server for sure, that I ca nsee
<aatchison> hmm
<kyrofa> monsterjamp, does `make` not use the `release` target?
<kyrofa> monsterjamp, regardless, you can use the `make-parameters` option
<kyrofa> monsterjamp, see `snapcraft help make` for more information
<kyrofa> monsterjamp, but in most cases, it's just make -> make install, so that's what snapcraft does out of the box
<monsterjamp> I see, I haven't tried to make a snap yet, I was just following the "tour" and the tour seemed to avoid my question.
<kyrofa> monsterjamp, ah ha. Well there you go!
<monsterjamp> :D
<kyrofa> monsterjamp, similarly, cmake and autotools have `configflags`
<kyrofa> monsterjamp, you can run `snapcraft help <plugin>` to learn more about any of them
<monsterjamp> I see, thanks for the help. I'm gonna try to make a snap and see how it goes.
<kyrofa> monsterjamp, any time! Let us know if you have any questions :)
<popey> feel free to poke us if you have questions
<wligtenberg> popey, quick question. installing with --dev-mode removes all isolation, correct?
<popey> you can also do "confinement: devmode" in the yaml
<kyrofa> My gift to the world (mainly sergiusens): http://pastebin.ubuntu.com/17820191/
<popey> but i dont think it removes all isolation,no
<monsterjamp> Also I noticed that installing snaps doesn't need sudo, is that intentional?
<wligtenberg> ok, so would we still have networking isolation?
<wligtenberg> mycroft has issues calling home :)
<aatchison> kyrofa, hahaha
<kyrofa> aatchison, I have a recursion problem somewhere :P
<aatchison> sure looks pretty though
<elopio> hum, I thought that it was slow building the snaps, when it's actually slow executing snap remove :/
<kyrofa> wligtenberg, devmode snaps still get installed in /snap/ and thus are isolated in that manner, but it doesn't require interfaces anymore
<kyrofa> wligtenberg, so it's completely unconfined
<wligtenberg> kyrofa, so no limitations to network access then?
<kyrofa> wligtenberg, indeed
<wligtenberg> ok, aatchison, so no confinement issue then...
<aatchison> hmm
<aatchison> I added the network and network-bind plugs, and they are interfacing I can see
<kyrofa> wligtenberg, aatchison but you still have the fact that you're in an isolated container, with your dependencies bundled
<kyrofa> isolated = dependencies bundled in that case, I guess
<kyrofa> sergiusens, figured out my problem
<aatchison> wligtenberg, I added the home plug, so mycroft can create those folders at least
<wligtenberg> good idea, I have to go now, but I will look at it later. You can always ping me on slack if you want me to check something
<aatchison> cool:) thanks for helping me check this out!
<sergiusens> kyrofa do  tell
 * sergiusens i going type slowly as he has popcorn grease on his other hand
<sergiusens> elopio snapcraft/tests/test_yaml.py in the define PR, what gives?
<elopio> sergiusens: sorry, I need more information. What is your question?
<monsterjamp> So snapcraft makes the snap and I can install it but when I try to run my program via bash it returns "Bad system call"
<monsterjamp> snapcraft.yaml: http://paste.ubuntu.com/17823434/ makefile: http://paste.ubuntu.com/17823441/
<elopio> sergiusens: oh, I see. For some reason in #590 you removed the subversion lines: https://github.com/ubuntu-core/snapcraft/pull/590/files#diff-8dac611ed32f1d2128779826f0337076L207
<sergiusens> elopio is it ok to readd it in this one?
<elopio> sergiusens: sure, why not.
<sergiusens> elopio this was me trying to work from the tablet and settling with vimdiff
<sergiusens> elopio also confusing is merging versus rebasing, the panes swap :-P
<elopio> sergiusens: no harm done.
<elopio> sergiusens: speaking of confusing, I'm making a mess with this store integration test. It will only be able to run from an ubuntu-core branch, so when we land PRs. And I in order to test it, I need to propose two PRs. Ignore me for now.
<josepht> monsterjamp: the Debugging section here might help: https://developer.ubuntu.com/en/snappy/guides/security/
<monsterjamp> I think I'm gonna make a really program and see if I can make a proper snap of it
<sergiusens> elopio I guess this needs an update branch to at least trigger adt https://github.com/ubuntu-core/snapcraft/pull/600
<elopio> sergiusens: it sucks that we can't run update in other people's branches.
<elopio> I guess that would be too much power. But I would trust you to use it for good :)
<sergiusens> elopio well I am more for just using the main project when its a team thing
<sergiusens> elopio just like I'd push to ~snappy-dev on launchpad for the team to be able to take over if required
<sergiusens> elopio example tests failed now... so soon, so fast
 * sergiusens connects to the vpn
<sergiusens> elopio I haven't seen the openstack "too many security groups" error in a while!
<elopio> maybe I didn't recover the cleanup job properly.
<monsterjamp> Well I was able to get a simple snap to build/run
<elopio> damn, yes, that's not doable in lgw01. I will need more bash superpowers to parse the output there.
<monsterjamp> I can't get my other project to work though
<monsterjamp> When I run it via bash it still says "Bad system call
<monsterjamp> I really wish there was a good offline makefile example they had
<monsterjamp> Why does every example need a remote :/
<monsterjamp> People on ##linux are saying I'm getting "Bad system call" since the snap I'm making uses a different glibc version than what's supported by my kernel
<monsterjamp> So I figured it out, I completely missed the part where you have to add interfaces for the snaps to work
<sergiusens> monsterjamp might want to install your snap with --devmode to play around a bit
<monsterjamp> What does devmode allow me to do?
<monsterjamp> Is it the same as using snappy-debug?
<sergiusens> monsterjamp it runs without confinement
<monsterjamp> Oh, now I understand what confinement is
<sergiusens> elopio seems master is no broken :-/ I'll crank up some fixes (adt)
<sergiusens> elopio https://github.com/ubuntu-core/snapcraft/pull/604
#snappy 2016-06-25
<bogusjokes> hello
<bogusjokes> can someone tell me how i change in files inside of a snap package and add/remove file within them?
<tedg> bogusjokes: Snap packages are compressed, you'd have to uncompress it and rebuild it.
<tedg> bogusjokes: You can use "unsquashfs" to decompress
<jaymell> Greetings: I'm wondering what the best approach is for simply building a part by running a shell script. For instance, meteor.js: their installer is just a shell script (https://install.meteor.com/) that does some OS checks and otherwise just unzips a tar file to $HOME/.meteor... I could easily just do that myself using the 'copy' module and skip the script, but it seems just as useful to be able to just run a script directly during the 'build' stage and
<jaymell> let it handle the unpacking. Is there a best approach for doing this?
#snappy 2016-06-26
<Sargun> Can I have concurrent versions of snappy installed?
<Sargun> and use a directory that's not /var/lib?
<Sargun> Ah, yes, SNAPPY_GLOBAL_ROOT.
<popey> gouchi: you managed to get love2d building on 16.04? it fails at link time here. http://paste.ubuntu.com/17902490/ which I think is bug 1568899
<ubottu> bug 1568899 in gcc-5 (Ubuntu) "ld: a.out: hidden symbol `__cpu_model' in /usr/lib/gcc/x86_64-linux-gnu/5/libgcc.a(cpuinfo.o) is referenced by DSO" [Undecided,Confirmed] https://launchpad.net/bugs/1568899
<gouchi> popey: I need to try to build it
<popey> it builds find here. it just dails at link, which is annoying
<gouchi> :(
<popey> might have to patch the build plugin I made to tweak the build
#snappy 2017-06-19
<mup> PR snapd#3477 closed: tests: fix snap create-key by restarting automatically rng-tools <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3477>
<zyga> o/
<morphis> zyga: hey!
<morphis> zyga: can you merge https://github.com/snapcore/snapd/pull/3470 ?
<mup> PR snapd#3470: interfaces/builtin: sync connected slot and permanent slot snippet <Created by morphis> <https://github.com/snapcore/snapd/pull/3470>
<mvo> zyga: hm, the idea of using snap-update-ns to fixup the permissions of /var/lib will unfortunately not work because it looks like we don't run that for the snaps when snapd itself (e.g. fro mthe deb) is updated. context is the incorrect permissions of /var/lib inside the namespace
<mvo> zyga: and good morning :) - and good morning to morphis too!
<morphis> mvo: morning!
<mvo> zyga: I suspect this needs to go into snap-confine itself (the fixup code). slightly sad about this
<morphis> mvo: can you have a look at https://github.com/snapcore/snapd/pull/3449 and merge if it is fine for you?
<mup> PR snapd#3449: tests/lib: generalize RPM build support <Created by morphis> <https://github.com/snapcore/snapd/pull/3449>
<mvo> morphis: sure
<zyga> morphis: done
<zyga> mvo: hey
<mup> PR snapd#3470 closed: interfaces/builtin: sync connected slot and permanent slot snippet <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3470>
<morphis> thanks!
 * zyga is sitting amids boxes and unpacked things everywhere
<mvo> morphis: sure
<mvo> zyga: woah, you are back?
<mup> PR snapd#3449 closed: tests/lib: generalize RPM build support <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3449>
<zyga> mvo: I won't be much help this week
<mvo> zyga: no worries
<zyga> mvo: I'm sick (cold) *and* sunburned
<mvo> zyga: have you moved too?
<zyga> mvo: yesterday we had a surprise party from our closest friends
<zyga> mvo: no, I'm moving on Thursday
<zyga> mvo: extra family members are here to help us move
<zyga> mvo: we'll land in Poland on Friday at 1 AM or something like that
<mvo> zyga: woah, good luck
<mvo> zyga: and get well
<zyga> mvo: I'll aks you for a review of the initrd test support soon
 * mvo takes a short break
<morphis> mvo, zyga: if you have another min, https://github.com/snapcore/snapd/pull/3450
<mup> PR snapd#3450: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <https://github.com/snapcore/snapd/pull/3450>
<mup> PR snapd#3450 closed: packaging/{opensuse,fedora}: allow package build with testkeys included <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3450>
<morphis> mvo: thanks!
<mvo> morphis: yw!
<mup> PR snapd#3487 closed: tests: reenable help test on ubuntu and debian systems <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3487>
<ogra> mvo, any opinion on bug 1698107 ?
<mup> Bug #1698107: Ubuntu Core images should include ntfs-3g <Snappy:New> <https://launchpad.net/bugs/1698107>
<mup> PR snapd#3222 closed: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3222>
<mvo> ogra: sounds reasonable, it seems like its pretty small
<mup> PR snapd#3391 closed: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3391>
<mvo> if someone could have a look at 3482 that would be cool, very straightforward review
<morphis> mvo: yeah!
<zyga> re
<morphis> zyga: you wont believe it: https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3222>
<mvo> morphis: ha! great job for getting it in :)
<zyga> morphis: nice, very nice
 * zyga just got rid of the 1st aquarium
<zyga> now quick breakfast and back to work
<ogra> mvo, yeah.1.5MB uncompressed
 * ogra will add it 
<zyga> mvo: done
<mup> PR snapd#3482 closed: asserts: support timestamp and optional disabled header on repair <Created by pedronis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3482>
<ogra> zyga, i see weird "cookie not found" errors on all my core boards since about last week ... is that snap-confine ?
<zyga> ogra: that's the new context thing
<zyga> pstolowski: ^^
<zyga> pstolowski: something you may want to know about
<zyga> ogra: are those actual errors or just messages that are logged but stuff still works?
<ogra> we should at least fix the error message to have a final newline if we want to chow it all the time :)
<mup> PR snapd#3467 closed: interfaces/greengrass-support: add support for Amazon Greengrass as a snap <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3467>
<ogra> *show
<zyga> ogra: oh, indeed
<mvo> zyga: 3441 has a comment from pedronis, do you think you can address it or shall I have a look, looks like a trivial change
<ogra> zyga, it seems to happen if the app actually takes a while to start up ... i can pretty reliably reproduce it by running classic (and initially though it was only there) ... but yesterday i ran htop on a heavy loaded board and saw it for htop as well
<ogra> pstolowski, ^^
<zyga> mvo: I'll do it now
<zyga> mvo: thank you for spotting that
<mvo> zyga: thank you, I think its pretty close
<mvo> zyga: 3464 probably needs an ok from gustavo, wdyt? pr itself looks fine (assuming everything is identical just split up :)
<pstolowski> zyga, ogra right. we will complain for already installed snaps that don't have the cookie (since we generate cookies only when snap is installed). but it's a warning only, everything should work
<ogra> pstolowski, prefixing it with a "W:" or some such might help ... and the message should really get a final newline/linewrap at the end
<zyga> mvo: yes, I have a informal +1 from jdstrand and once we have formal reviews it should go in
<zyga> pstolowski: can you check about that newline
<zyga> pstolowski: probably error is doing that, error is not used in the code much
<ogra> in classic i always like:
<ogra> ogra@sabrelite:~$ sudo classic
<ogra> cannot open cookie file /var/lib/snapd/cookie/snap.classic(classic)ogra@sabrelite:~$
<ogra> *i always end up like
<mvo> zyga: great, if there is agreement I will try to review today
<pstolowski> zyga, ogra ok, will add a new line. but i don't think we use 'W:' to signify warnings anywhere?
<mvo> fgimenez: quick question about 3474 - if /etc/gai.conf is not writable on core, why didn't the tests explode on core when it tries to write to /etc/gai.conf ?
<zyga> pstolowski: W: ?
<ogra> well ... indicate somehow that it isnt an error ... doesnt need to be "W:"
<ogra> else we'll get bugs about it
<mvo> pstolowski: is this warning helpful in any way to the user? I mean, is there anything that the user can do to get rid of if?
<mvo> pstolowski: I guess what I'm asking is - can we somehow fix things so that we don't have to print this message and explain something to the user?
<pstolowski> mvo, reinstall affected snap would remove this warning
<pstolowski> mvo, an alternative would be to generate all the missing cookies (for snaps installed before the feature was introduced) on snapd start
<mvo> pstolowski: if its not too much hassle that sounds much better than to ask all $users to do this manually
 * ogra tries ... 
<mup> PR snapd#3466 closed: tests: extend core-revert test to cover bluez issues <Created by fgimenez> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3466>
<zyga> pstolowski: I think you just said what has to be done
<zyga> pstolowski: it's ain internal implementation deatail
<zyga> pstolowski: similar in principle to security refresh
<pstolowski> ogra, if you're trying the reinstall, make sure you don't have any old revisions of that snap installed
<ogra> bah, you tell me now :P
<pstolowski> zyga, mvo ok, i'll do that
<fgimenez> hey mvo welcome back! on linode the core system follows a different path than on the external backend, the former starts with a classic system (/etc/gai.conf is writable at that stage) which eventually reboots into a core system, the latter is a core system from the start (with /etc/gai.conf in a read-only partition from the beginning)
<ogra> popey, hey ... you recently asked abotu that https://github.com/ogra1/nanopi-neo-gadget (and also https://github.com/ogra1/orangepi-zero-gadget) ... still struggling with a kernel atm ... but i have both boards now
<ogra> ogra@sabrelite:~$ sudo classic
<ogra> (classic)ogra@sabrelite:~$
<ogra> pstolowski, confirmed ... ^^^
<pstolowski> ogra, warning is gone, that is?
<ogra> yeah
<mvo> fgimenez: aha, so this fails when you run it against a real ubuntu-core extrenal device like a pi2?
<pstolowski> ok. ill fix it
<mvo> pstolowski: thank you!
<popey> ogra: nice!
<ogra> the nanopi is soooo cute!
<mvo> zyga: I added one more comment into 3441 (hopefully trivial)
 * ogra is in love :)
<zyga> mvo: looking
<zyga> mvo: replied
<mvo> zyga: thank you. and do let me know if I can take any burden of your shoulder, it sounds like you have a bit of a stressful week ahead of you. i.e. I can fixup anything for you in the PRs
<fgimenez> mvo: yes, exactly
<zyga> mvo: just running tests there
<fgimenez> mvo: with kvm it should fail too, any core system using the external backend
<mvo> zyga: ta
<zyga> mvo: the encoding is done by the response codec I suspect, I'm not doing that myself
<mvo> fgimenez: thats fine, I was just wondering why we have not seen it in spread
<zyga> mvo: I could just convert it to a string, I think it's not any harm
<mup> PR snapd#3474 closed: tests: fix ipv6 disable for ubuntu-core <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3474>
<mvo> if 3317 gets a second review it can go in too - we may need a gustavo review for this though
<fgimenez> mvo: yes, we need core spread test on actual systems to contrast linode results and prevent the tweaking we do there to mask potential problems, hopefully as soon as we have the jenkins instance up this will be automated
<fgimenez> mvo: thx! :)
<popey> ogra: which one did you get?
<ogra> nanopi neo
<ogra> i'm pondering to also get the air
<ogra> my prob is currently that you cant cross compile our aarch64 kernel and the armhf build doesnt seem to boot
<popey> the air is the super tiny one, right?
<ogra> they are both super tiny .. 2cmx2cm or so
<ogra> the air is the one with additional wlan ... i think its a tad bit larger
<ogra> (due to the wifi chip)
<popey> yeah, I'm interested in the wifi enabled one
<mup> PR snapd#3476 closed: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3476>
<pstolowski> mvo, thanks ^ I was waiting for tests to pass but you were faster ;)
<mvo> fgimenez: another silly question - why do we see the issue with 3488 only on opensuse?
<mvo> pstolowski: all the relevant ones passed ;)
<ogra> popey, https://www.voelkner.de/products/940892/Nanopi-Neo-Allwinner-512-MB-ohne-Betriebssystem.html is the one i got
<pstolowski> mvo, right. i didn't expect any surprises anyway, the last commit just fixed the comments
<mvo> pstolowski: but yeah, sorry for that, I'm in a bit of ocd mode right now, the queue felt a bit overwhemling and we have a lot of low-hanging fruits
<popey> very cute
<ogra> thats the air https://www.voelkner.de/products/966493/Nanopi-Neo-Air-512-MB-ohne-Betriebssystem-microSD-Bluetooth-Micro-USB-OTG.html
<Vamsi> Is it possible to install snaps on an ubuntu host from my phone?
<mvo> pstolowski: on the bright side, we are down to 27 PRs
<ogra> Vamsi, you could install snapweb ... or use a terminal and ssh on your phone
<mup> PR snapd#3445 closed: tests: add linode-sru backend <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3445>
<zyga> Vamsi: we have a REST API for snapd but it is not yet exposed
<pstolowski> mvo, good stuff
<mup> PR snapd#3485 closed: tests: fix nightly suite <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3485>
<ogra> ppisati, do you happen to know how i can cross-build an aargh64 kernel ? i get complains about missing stack protector support in the compiler when i try
<fgimenez> mvo: no idea, it's super strange, here is one of the logs with the failure , http://paste.ubuntu.com/24898301/ "flag provided but not defined: -tags withstagingkeys"
<ppisati> ogra: sounds like you are trying to compile a recent kernel with an old toolchain
<ogra> ppisati, yeah, the nanopi and orangepi are only supported in 4.11 onwards
<ogra> ppisati, but i attempted the build inside an artful chroot ... so it should be the latest tootlchain we have (unless there is something in proposed that i'D need)
<ppisati> ogra: uhm, that should be fine
<ppisati> ogra: what's the error?
<ogra> something about "no support for -fstack-protector-strong"
<ogra> i dont have the exact error handy atm
<zyga> mvo: look at 3441 again please
<zyga> pedronis: ^ as well please
<pedronis> mvo: zyga: thanks for merging the repair PR,  IÂ updated the forum topic to reflect these small tweaks
<mup> PR snapd#3488 closed: tests: prevent quoting error on opensuse <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3488>
<ogra> ppisati, http://paste.ubuntu.com/24898399/ eher is the exact error
<ogra> ppisati, the command i'm running is " ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- fakeroot debian/rules binary-headers binary-generic binary-perarch"
<ppisati> ogra: but there you are actually compiling an amd64 kernel
<ogra> ppisati, huh ?
<ogra> is CROSS_COMPILE not respected anymore ?
<ppisati> ogra: that's what i usually use
<ppisati> ogra: 'export ARCH=arm64; export $(dpkg-architecture -aarm64); export CROSS_COMPILE=aarch64-linux-gnu-'
<ppisati> and then 'fdrc etcetc'
 * ogra slaps forehead ... 
<ogra> export $(dpkg-architecture -aarm64) ....
<ogra> sorry for the noise ... building now
<mvo> jdstrand: good news, the seccomp-bpf PR is green! but still quite a few comments to address
<ppisati> ogra: np
<mvo> pedronis: thank you!
<ogra> ppisati, oh, and FYI ... i couldnt get armhf generic to boot on my nanopi or orangepi ... (thats why i try arm64 now)
<ppisati> ogra: 4.11?
<ogra> yep
<ppisati> ogra: ouch
<ogra> i get "Loading kernel ..." and thats it
<ppisati> ogra: do you have uboot running? you could dump the location of the printk buffer
<ogra> how do i do that
<ogra> i have earlyprintk and the right console= arg on the cmdline (verified a thousand times) ... so if it prints anything there it should show up
<ppisati> ogra: http://elinux.org/Debugging_by_printing
 * ogra reads
<ppisati> ogra: after the conversion do DT, i never got earlyprintk to work
<ogra> ah
<ogra> k
<ppisati> ogra: but i didn't try hard, honestly
<ogra> i'll resort to the printk hacker if arm64 doesnt work either
<ogra> *hack
<ogra> seemingly the allwinner toolchains are all aarch64 ...  so i have some hope that an arm64 build might work better
<mup> PR snapd#3441 closed: cmd,daemon: add debug command for displaying the base policy <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3441>
 * zyga -> break
<ogra> bah crap ...
<ogra> ls unpack/lib/firmware/4.11.0-6-generic/device-tree/allwinner/
<ogra> sun50i-a64-bananapi-m64.dtb  sun50i-a64-pine64.dtb  sun50i-a64-pine64-plus.dtb
<ogra> not so helpful :/
<kalikiana_> zyga: Can you confirm if /var/lib/snapd/snaps exists on all snapd systems? Or if there's an API to get that path (analogous to snap-mount-dir)?
<Chipaca> kalikiana_: dirs.SnapBlobDir?
<Chipaca> is that what you mean?
<zyga> kalikiana_: it exists on all systems AFAIK
<Chipaca> kalikiana_: what do you need it for?
<Son_Goku> it should exist everywhere
<Son_Goku> it's the snap download dir
<kalikiana_> Chipaca: This doesn't have SnapBlobDir https://github.com/snapcore/snapd/wiki/REST-API
<kalikiana_> Chipaca: I'm injecting snaps from the host into a LXD container
<kalikiana_> I'd like to know that this can work on different snapd systems other than Ubuntu
<kalikiana_> Son_Goku: Is that documented anywhere?
<Son_Goku> the only location that differs is /var/lib/snapd/snap vs /snap
<Son_Goku> Debian and Ubuntu and openSUSE use /snap
<Son_Goku> Fedora and Arch use /var/lib/snapd/snap
 * zyga feels worse and breaks
<zyga> mvo: I may miss standup, tomorrow should be a saner day
<ogra> koza, how is the humminngboard ?
<morphis> mvo, zyga: next one is ready: https://github.com/snapcore/snapd/pull/3455
<mup> PR snapd#3455: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455>
 * Chipaca ~> lunch
<niemeyer> Morning all
<Vamsi> zyga: Thank you
<Vamsi> ogra: Thank you
<pstolowski> good morning niemeyer !
<pstolowski> mvo, to test the new logic for generating cookies on start I may need to write a spread test that stops snapd, removes some data from state.json and starts snapd back, but that sounds a little big ugly... but I can't think of any other way of simulating coming from an old snapd in a test. do you know any tests where we do anything like that?
<pedronis> pstolowski: the upgrade tests should also test it,  but we do have some tests that delete state.json at least
<pedronis> or play with other /var/lib/snapd stuff
<mvo> pstolowski: was about to suggest the upgrade suite
<pstolowski> pedronis, ok. if I delete state.json, doesn't this make snapd unaware of installed snaps?
<pedronis> pstolowski: sorry, that wasn't my point, just sayign we do play with state.json sometimes
<pedronis> don't remember punctual edits
<pstolowski> pedronis, ah, I see
<pedronis> but probably because we didn't need them
<pstolowski> pedronis, I see
<pedronis> pstolowski: but as mvo said, the upgrade tests should grow some checks about this as well
<pcercuei> I have a bug report for Snapcraft on Debian, but it looks like I can't log into launchpad with a newly created Ubuntu One account
<pedronis> pstolowski: tests/upgrade/basic/task.yaml
<pcercuei> so I guess that means I have two bug reports now :)
<cjwatson> pcercuei: what's the error?
<cjwatson> pcercuei: (with Launchpad login)
<pstolowski> pedronis, mvo thanks, looking
<pcercuei> cjwatson: Ubuntu One requests some personal information (my full name + email), I select both and click "Yes, log me in"; back on launchpad.net I get a "Oops" page, error ID  OOPS-72c555d0a37007d571cd18978befd04a
<cjwatson> Thanks, the OOPS ID was all I needed.
<cjwatson> I'll chase that up for you.
<pcercuei> thanks!
<pcercuei> the actual bug I wanted to report: running latest 'snapcraft' on my Debian ends up with this:
<pcercuei> "dpkg-query: error: --listfiles needs a valid package name but 'libc6' is not: ambiguous package name 'libc6' with more than one installed instance"
<pcercuei> and that's because "dpkg -L libc6" is confused, because I have i686 and x86_64 versions
<mvo> pcercuei: this is something for kyrofa - the fix is probably simple, we need to teach snapcraft to always use the dpkg full name (i.e. pkgname:arch)
<mvo> pcercuei: thanks a lot for finding this
<pcercuei> mvo: should I still create a ticket?
<mvo> pcercuei: yes please, this will make tracking easier
<koza> ogra, hey. still in this pity state. seems that your unit is somewhat special because somebody at Linaro tried other board they had in the office and it just as much as mine that is just a red led.
<ogra> koza, hmm, well, i didnt do anything to my unit, i got it from madper as is and only stuck the SD in and booted it after creating the image
<ogra> who at linaro did you talk to (do we have any hummingboard specialist i could ping in #linaro ?)
<koza> ogra, whatever has been done you might have the only working hummingboard as of today ;-)
<ogra> well, you should at least get some output on serial
<ogra> koza, did you try any other image ?
<koza> ogra, serial is dead silent; yeah I have tried the debian image
<ogra> same issue ?
<koza> ogra, just a red led
<ogra> bah
<ogra> koza, another thing ... are you still responsible for bluetooth ? we need to get the Pi3 stuff going at some point
<ogra> (first of all hciattach needs to be allowed to talk to the BT device, the gadget is ready, but the bluez package needs adjustments for that i think)
<koza> ogra, I know, have this still in the back of my head; I will prioritize this so that it does not slip again; so when I'm done with the failing bluez kernel tests I will be on it
<ogra> koza, ok, no hurry, just wanted to know if thats still in your set of responsibilities (wasnt sure after the re-org)
<fgimenez> niemeyer: the board at https://github.com/resin-io/autohat-board has been developed with kicad http://kicad-pcb.org/, this site compares prices from pcb manufacturers https://pcbshopper.com/
<fgimenez> and has a good list of them
<niemeyer> fgimenez: Yeah, I think that's one of the most well known open source suites for PCB design.. what I wonder is how far along the manufacturing pipeline this is
<ogra> and as a bonus ... we do have a kicad snap in the store ;)
<Chipaca> popey: why does wethr sometimes take ages to 'detect my location'?
<fgimenez> niemeyer: from a random search in https://pcbshopper.com/ it seems that the shipping days range from 5 to 43 http://imgur.com/a/brd4h
<niemeyer> fgimenez: I think we should find out how many boards have been manufactured with those plans so far, and whether they actually work
<jdstrand> mvo: nice! :)
<fgimenez> niemeyer: ok, i'll ask around, will keep you posted
<niemeyer> fgimenez: Thanks!
<mup> PR snapcraft#1368 opened: cli: get_project_options must not discard kwargs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1368>
<Vamsi> ogra: snapweb is meant only for Ubuntu right? Is it possible to do so even from an Android phone or iOS phones?
<ogra> Vamsi, snapweb is a web UI for the snapd running on the other machine
<ogra> you just open it in your phone browser
<ogra> (any browser should work ... https://<ip of the machine running snapd>:4200/
<Vamsi> ogra: So I install snapd on the host and then on the web browser of my android phone I just put the IP address of this host and then install the snaps I need. Is my understanding right?
<ogra> Vamsi, scroll down to "Installing snapweb" http://www.lieberbiber.de/2017/02/22/basic-management-of-an-ubuntu-core-installation/  (a little old but still valid for snapweb)
<ogra> and indeed you dont want to go to "localhost:8041/" but to your IP
<Gunther_> Hello!
<mup> PR snapd#3490 opened: client, daemon: using oddjobstate, implement service operations <Created by chipaca> <https://github.com/snapcore/snapd/pull/3490>
<Gunther_> Serious request: Would it be possible to download  https://public.apps.ubuntu.com/anon/download-snap/canonical/generic-amd64.canonical/generic-amd64.canonical_1.4_all.snap from another source.
<Gunther_> Our build system is broken because of 403 permission denied.
<Gunther_> Sorry to bother you with this old stuff, but we depend on it
<Chipaca> Gunther_: what's giving you a 403?
<Gunther_> the link i posted
<Chipaca> Gunther_: but what is it? why do you want to download it?
<Gunther_> Accessed from ubuntu-device-flash on our jenkins build server. I know this is old and deprecated stuff, but its the way we generate the image for our devices
<Gunther_> we will have to migrate to 16.04 lts, but we did not have time for it :-/
<ogra> wow, thats a very old kernel... full of security holes i bet
<ogra> (or was that a gadget ?)
<Gunther_> I know, but we need a custom kernel module too that only works with this one ....
<Chipaca> Gunther_: I'm afraid I don't know how to help you
 * ogra isnt sure that old stuff even exists anymore 
<Gunther_> it was accessable until 3 days ago ...
<ogra> i definitely cant see it in my packages dashboard (and i see "canonical-pc" and such which was created around the same time (though canonical-pc is also unpublished)
<ogra> mvo, do you still see "generic-amd64" anywhere in the dashboard for the shared store account or is that gone for good ?
<ogra> i actually thinnk that was a gadget
<ogra> (for 15.04 images )
<Chipaca> Gunther_: what is the thing that's being built with this?
<ogra> likes some 15.04 image ...
<ogra> given ubuntu-device-flash was mentioned above
<Chipaca> ogra: I mean what device
<ogra> *likely
<Gunther_> OS image for a measurement system.
<Chipaca> is this something that is going to go onto shelves
<Chipaca> that is, is this a product?
<Gunther_> yes
<ogra> ugh
<ogra> so you plan a contribution to the next bigger botnet attack ?
<ogra> :)
<Gunther_> :-D
<ogra> (seriously ... if that device is anywhere on a network you will likely be vulnerable)
<Chipaca> Gunther_: does your company have some kind of commercial relationship with canonical?
<Gunther_> Thats the master plan ;-). No this kind of device is usually not in the internet
<ogra> ok, that makes it less awkward
<Gunther_> Not that I know off.
<Chipaca> rats
<Gunther_> Ogra, I will forward you warning to my manager
<ogra> :)
<Gunther_> Not that I didnt warn him/them before ...
<popey> Chipaca: good question, I don't know why it takes ages.
<popey> Chipaca: I find sometimes if I kill it and run it again, it works. Maybe some upstream API issue
<popey> emoj shrug
<ogra> open the window shades ... perhaps it knows your location if it can see where you are ;)
<Chipaca> Gunther_: I'd have to ask somebody that actually knew to be sure, but I *think* ubuntu-device-flash will work less and less as ubuntu's phone backend things are turned off
<Chipaca> Gunther_: unless it's a bug -- I'll ask, in any case
<Gunther_> It would help a lot if it would work for additional 2 to 3 months to give us a chance to migrate
<Gunther_> but sometime a hard cut is good too :).
<ogra> i think deadline for the system-image server was july
<ogra> then it will be shot down
<ogra> (there was a mail to the phone ML ... nobody bothered about 15.04 snappy because thats unsupported since ages already)
<ogra> (so nobody informed about the shutdown in that area)
<Gunther_> Well thanks guys. I think I know what I will do the next weeks .......
<Chipaca> roadmr: so, Gunther_ here is getting a 403 when trying to get https://public.apps.ubuntu.com/anon/download-snap/canonical/generic-amd64.canonical/generic-amd64.canonical_1.4_all.snap
<Chipaca> roadmr: AIUI it worked until ~2 days ago
<roadmr> Chipaca: he's just hitting that URL with curl or something?
<Chipaca> Gunther_: ubuntu-device-flash I *think*, but ask him ;-)
<Gunther_> yes this is. but i also get the 403 ith chrome
<Chipaca> roadmr: ^ sorry, meant to tell you to ask Gunther_ and got my wires crossed
<roadmr> ok
 * ogra notes that Gunther_ opened a forum task too at https://forum.snapcraft.io/t/old-generic-amd64-canonical-image-403-error/1047
<morphis> mvo: can you merge https://github.com/snapcore/snapd/pull/3455 ?
<mup> PR snapd#3455: tests/main: use pkgdb function in more test cases <Created by morphis> <https://github.com/snapcore/snapd/pull/3455>
<mvo> morphis: yes, looking good
<mup> PR snapd#3455 closed: tests/main: use pkgdb function in more test cases <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3455>
<morphis> thanks
<mvo> jdstrand: I addressed all the seccomp-bpf PR comments, thanks a lot for your careful review. please do let me know if there is anything I might have overlooked. if you are happy, you can pass it to gustavo for a second review. we need to backport it to the 2.26 branch too, but I will take care of this (it is probably going to be quite a bit of work :/)
<mvo> thank you morphis
<morphis> zyga: there?
<niemeyer> mvo: Out of curiosity, why will the 2.26 merge be problematic?
<jdstrand> mvo: I'll take a look at it after my next meeting
<jdstrand> mvo: thanks for addressing all that! I saw your comments on the testsuite. I'll give it some more thought
<mvo> niemeyer: mostly because the branch has a lot of commits by now and probably some conflicts with 2.26, but I have not invesitgated the details yet, will check tomorrow morning
<mvo> jdstrand: thanks a lot, happy about suggestion how to make this tessuite easier to read
<Chipaca> niemeyer: any objection to moving the logic for 'snap tasks --last foo' into the daemon?
<pedronis> Chipaca: any particular reasons?  (though I suppose it's saner)
<Chipaca> pedronis: it's a little saner, and I'm wanting to add --last foo to two other commands (abort and watch)
<pedronis> ah
<Chipaca> using them in anger for services made it clear to me it's needed
<pedronis> yes, I think it's saner
<pedronis> (because of needing to know about task names)
<pedronis> though the reverse is true, needing to know about commands, but commands change less than task names I suppose (though even the latter are kind of stable)
<Chipaca> OTOH... watch itself might not benefit too much from this
<Chipaca> bah, easy enough to fix i guess :-) but need to make it a little chummy
<Chipaca> pedronis: i had thought i'd do the translation from commands to changes on the client though
<pedronis> mmh
<Chipaca> OTOÂ²H i could just reuse the existing --last impl, and suggest moving it in-server once that is done
<Chipaca> same work, maybe clearer motiviation this way
<niemeyer> Chipaca: No objections
<niemeyer> Chipaca: snapd#3480 reviewed btw.. just that one suggestion for the package name
<mup> PR snapd#3480: overlord/oddjobstate: new package for running commands as tasks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3480>
<mup> PR snapd#3491 opened: snapd: generate snap cookies on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/3491>
<pstolowski> ogra, ^ this should fix the warning from snap-confine we discussed this morning
 * ogra hugs pstolowski 
<roadmr> Gunther_: are you around?
<ogra> roadmr, https://forum.snapcraft.io/t/old-generic-amd64-canonical-image-403-error/1047 (if he isnt anymore)
<roadmr> ogra: thanks
<mup> PR snapcraft#1369 opened: Handle I/O errors in os.link (LP: #1689956) <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/1369>
<Chipaca> niemeyer: two questions for you: any reason we don't make "change" an alias for "tasks" instead of its current hidden snowflakiness? (makes maintenance harder this way)
<Chipaca> niemeyer: 2. should i just alias search to find
<niemeyer> Chipaca: +1 on both counts
<Chipaca> ok
<niemeyer> Chipaca: I can't possibly see any other meaning for search that isn't the same as find without it being a reason for LOLs
<niemeyer> Chipaca: We could also tell people that the command is find rather than search, but that's the sort of thing that seems unnecessarily pedantic.. if we know what the user means, we can just do it
<Chipaca> niemeyer: cmdstate seems fine to me
<mup> PR snapd#3492 opened: `--last` for abort and watch, and aliases (searchâfind, changeâtasks) <Created by chipaca> <https://github.com/snapcore/snapd/pull/3492>
<Chipaca> ruh roh
<Chipaca> niemeyer: is everything ok in linode-land?
<niemeyer> Chipaca: More auth issues?
<Chipaca> niemeyer: https://travis-ci.org/snapcore/snapd/builds/244618152
<Chipaca> (spoiler: yes)
<niemeyer> There are no open tickets ATM
<niemeyer> Let me ping them
<Chipaca> niemeyer: otoh https://travis-ci.org/snapcore/snapd/builds/244621777 seems to be proceeding fine
<niemeyer> I've opened a ticket
<Chipaca> âdear gustavo, plz less hammering of the api, kthxbyeâ
<niemeyer> Probably
<Chipaca> :-p
<Chipaca> ok i'm going to eod about here
<Chipaca> if i stay i'm going to either (a) melt, or (b) get dragged into working on the go patch thing until it's too late to do anything more
<Chipaca> o/
<niemeyer> cachio: They've dropped a suspect IP from their firewall
<niemeyer> cachio: Please drop me a note if you see the auth issue again
<cachio> niemeyer, ok
<cachio> niemeyer, could you please take a look through the console to the machine (Spread-26): 45.79.159.108 ?
<cachio> it did not start anymore after the reboot
<niemeyer> cachio: Looking
<niemeyer> cachio: Spread-26 is powered off and unallocated
<cachio> niemeyer, is it any way to recover the disk?
<cachio> niemeyer, it was discarded before I told you
<cachio> niemeyer, I'll need to use reuse next time
<niemeyer> cachio: Not just the disk.. the issue is also having the system powered off.. the console is gone at that point
<cachio> niemeyer, ok
<mvo> jdstrand: thanks a bunch for the extra review, when you have a moment, a reply to https://github.com/snapcore/snapd/pull/3431#discussion_r122786010 would be great, I am working through the other comments now (good stuff btw)
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<azubieta> Hello Guys! I'm a developer of NXOS  (http://nxos.org/), whish aims to be a fully snap based linux distribution. Currently we are attempting to port some of the kde plasma apps to snaps in order to make them avalable from our "software center". But we are having serious issues with the connections betwen our snaps and the kf5-frameworks snap. We already get in touch with the kf5-frameworks snaps and he comment us that the problem might be a restriction
<azubieta> imposed by snapd at the time of the connectin. Would you please assist us in this. Thanks
<mvo> hm, 4min ago I got "authentication failed" for all the allocated spread systems
<mvo> fwiw https://travis-ci.org/snapcore/snapd/builds/244657462?utm_source=github_status&utm_medium=notification
<mvo> cachio: -^
<cachio> mvo, thanks
<cachio> niemeyer, mvo reported that 13 mins ago https://travis-ci.org/snapcore/snapd/builds/244657462?utm_source=github_status&utm_medium=notification
<cachio> niemeyer, authentication failed again
<niemeyer> cachio: Thanks
<jdstrand> mvo: I commented
<mvo> jdstrand: for some reason I don't seen an update for the question about `setpriority 1\n2`. maybe GH is slow today?
<niemeyer> cachio: Can you please add that at the top of our travis.yaml, so we can tell the public IP of the build system?
<niemeyer> cachio: curl -s -o - http://canihazip.com/s
<cachio> niemeyer, sure
<niemeyer> cachio: Travis provides a pretty unhelpful "hostname" at the top of the log, but I haven't managed to map that to a real IP yet
<niemeyer> Need to figure that out so i have some substance to present to Linode
<cachio> niemeyer, you mean in the script?
<cachio> section
<niemeyer> cachio: Or install, I suppose?   What's the first section to run?
<jdstrand> mvo: gh has been weird with this pr for me too. let me get you the answer
<mvo> jdstrand: it finally appeared
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3431#discussion_r122806724
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<jdstrand> heh
<mvo> jdstrand: I think we are driving it to its limits :)
<jdstrand> mvo: seems so :)
<cachio> niemeyer, ok
<jdstrand> mvo: actually I pasted you an answer to something else. anyway, I'm answering stuff :)
<cachio> niemeyer, PR 3493
<mup> PR snapd#3493 opened: tests: showing the ip in the .travis.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3493>
<cachio> niemeyer, 35.188.99.113
<mvo> jdstrand: I also replied to your question about seccomp/profiles vs seccomp/bpf
<niemeyer> cachio: Oh, already?
<niemeyer> cachio: That's from a failure?
<cachio> but, no, for the PR run
<cachio> are you going to merge it
<cachio> ?
<niemeyer> cachio: Ah, cool.. yeah, let's merge it once it goes green so we can get the IP for a failure case
<cachio> niemeyer, or we should re_run it until we are able to reproduce the error?
<jdstrand> mvo: yeah, replaying
<jdstrand> replying
<niemeyer> cachio: We should probably have added an || true or something similar so we don't get failures out of that line.. but we can do that later
<cachio> niemeyer, echo ip: $(curl -s -o - http://canihazip.com/s) || true
<cachio> I can make the change right now
<mvo> jdstrand: ta
<jdstrand> mvo: what happens to /var/lib/snapd/seccomp/profiles once the last version of core that uses it is garbage collected?
<mvo> jdstrand: currently nothing, but we can add cleanup code
<niemeyer> cachio: It's okay, let's try to get it in without yet another round
<jdstrand> I meant the plan going forward
<niemeyer> cachio: We can polish it later
<cachio> niemeyer,  sure
<niemeyer> This one will already take ~30 mins
<jdstrand> mvo: this makes documentation and auditing icky. 'if you are using snapd < 2.26, then look here, otherwise look there'
<jdstrand> I was thinking the bpf stuff would fix that, but it only does going forward from 2.26
<jdstrand> also, images that start with 2.26+ end up with /var/lib/snapd/seccomp/bpf which doesn't align with /var/lib/snapd/apparmor/profiles
<jdstrand> mvo: maybe /var/lib/snapd/seccomp/profiles.bpf and don't name the input files with .in but do name the bpf files with .bpf?
<mvo> jdstrand: sounds good
<mvo> jdstrand: I can tweak that, I like that suggestion
<jdstrand> eg, snap-seccomp /var/lib/snapd/seccomp/profiles.bpf/snap.foo.bar /var/lib/snapd/seccomp/profiles.bpf/snap.foo.bar.bpf
<jdstrand> at least it feels similar to what we currently have and it is mostly discoverable
<mvo> jdstrand: sounds good, could you please comment in the PR? I will work on that first thing in the morning.
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3431#discussion_r122815064
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<jdstrand> mvo: (I was :)
<mvo> jdstrand: great, thanks a lot. I will call it a day now but will read the PR comment in my morning and work on the dir name change then
<jdstrand> mvo: ok. thanks for getting to all these things! we are getting closer and closer :)
<codeplug_> Hi, is anyone familiar with using bluez in the Snappy Ubuntu Core environment? I'm trying to understand why this bluez stack doesn't come with gatttool...
<mvo> jdstrand: indeed, it feels good
 * mvo waves
<mup> PR snapd#3493 closed: tests: showing the ip in the .travis.yaml <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3493>
<cachio> niemeyer,  the automatic restart of the rng-tools service seems to not be enough
<cachio> niemeyer, https://travis-ci.org/snapcore/snapd/builds/244673127#L3493
<cachio> entropy = 138
<codeplug1> ???
<Chipaca> codeplug1: !!!!
<Chipaca> niemeyer: more auth issues: https://travis-ci.org/snapcore/snapd/builds/244700389
<mup> PR core-build#14 opened: initramfs/testing: add unit tests for initrd scripts <Created by zyga> <https://github.com/snapcore/core-build/pull/14>
<azubieta> https://forum.snapcraft.io/t/issues-building-kde-plasma-applications-snaps-for-nxos/
<niemeyer> Chipaca: Thanks, and this time we have the source IP
<niemeyer> cachio: We'll need to find out what's actually broken there then
<cachio> niemeyer, yes, working on that
<niemeyer> I'm running out of ideas.. Linode is apparently getting requests without the key in some cases, but on the Travis end there's no apparent distinction between the calls :(
<niemeyer> The failing and the working setup look pretty alike
<mup> PR snapcraft#1370 opened: integrations: add the snapcraft Dockerfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1370>
<niemeyer> and now everything seems to work fine..
<Chipaca> niemeyer: so... maybe it's not linode? https://travis-ci.org/snapcore/snapd/builds/244733765
<niemeyer> Chipaca: Yeah, I don't think it is
<niemeyer> Chipaca: It feels like something out of our control is running concurrently with the usual scripts
<niemeyer> Chipaca: Perhaps it's not a coincidence that Travis is working on their images
<Chipaca> niemeyer: should I switch the 'beta' thing on to see if it improves at all?
<Chipaca> 'group: edge' i think it is actually
<niemeyer> Chipaca: Worth a shot, although it's awkward that it's breaking on what in theory is the old stuff
 * Chipaca nods
<niemeyer> Chipaca: But this is software, soooo
<Chipaca> and not consistently either
<Chipaca> I'll give it one retry
<Chipaca> niemeyer: no difference
<Chipaca> reverting the change
 * Chipaca gives up and goes back to trying to sleep
#snappy 2017-06-20
<mup> PR snapd#3494 opened: tests: Restart rng-tools services after few seconds <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3494>
<mwhudson> hey guyz snapcraft fails tests with python 3.6
<mup> PR snapcraft#1318 closed: tests: refactor the travis jobs using stages <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1318>
<mup> PR snapcraft#1291 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1291>
<mup> PR snapcraft#1331 closed: integrations: use the snapcore/snapcraft docker image in travis <Created by filibtester> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1331>
<mup> PR snapd#3495 opened: tests: remove snapd before building from branch <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3495>
<Chipaca> fgimenez: morphis: I'm running off to physio, but I thought I'd ask you guys if you could look into why spread on debian (when travis gets past the auth issue) is failing with âgo: command not foundâ
<morphis> Chipaca: you have a link?
<Chipaca> https://travis-ci.org/snapcore/snapd/builds/244733765#L653
<fgimenez> Chipaca: sure, looking
<fgimenez> Chipaca: morphis maybe the problem happens a bit earlier "Cannot install 'libudev-dev'"
<morphis> yes, that looks like what it is
<morphis> if the install command in pkgdb gets a list of packages it aborts on the first error
<Chipaca> aborts but doesn't return an error?
<morphis> ah, but this is really gdebi
<morphis> AFAIK it does
<Chipaca> anyway, i really need to run
<Chipaca> o/
<morphis> hm, https://packages.debian.org/sid/libudev-dev is in all debian archives
<ogra> version issue ? (we used to have that with the core snap wehn we used too ship our own systemd version, people building something with libudev-dev in build-packages had their builds fall over ... the version is a == one iirc
<ogra> )
<zyga> re
<zyga> ogra: hey
<ogra> yo
<zyga> ogra: do you have a moment?
<ogra> sure
<zyga> ogra: how can I run test-init without it being init
<zyga> ogra: I don't want to use break=... and then script the shelll that spawns (unreliable)
<ogra> zyga,  i meant the other way around
<ogra> and no, you shouldnt use break :)
<zyga> ogra: can you tell me what you mean then?
<ogra> zyga, you boot with boot=/test-init ...
<ogra> that simply runs /init
<ogra> so that you get all the env bits you need
<zyga> aha
 * zyga tries
<zyga> hmm
<ogra> the environment and available devices differ between the stages
<ogra> and init makes sure to exec each bit in its assignedf stage
<zyga> ogra: so kernel command line would have boot=test-init
<ogra> right
<zyga> ogra: that wants to run /scripts/test-init
<zyga> ogra: how do I pass arguments to my init program?
<ogra> and test-init somehow needs toexec the scrip snippets at the step that init would use
<ogra> take a look at it ... it read env vars
<ogra> *reads
 * zyga looks
<ogra> every ubuntu install has the script in /usr/share/initramfs-tools/init
<ogra> so no need to dig into the source ;)
<zyga> TBH the whole exercise only made me want to write /init in C more than anyhting
<ogra> well, thats something you should discuss with debian :)
<zyga> all the complexity there and all the fragility
<zyga> why? is debian doing ubuntu-core? :D
<zyga> ogra: btw, I think I found a bug in the script
<ogra> no, but we use their inittamfs-tools package
<zyga> ogra: have a look at the FIXME I added
<ogra> yeah
<ogra> we should just fix it ;)
<zyga> ogra: I'd like to do a pass and document and test some of those functions better
<ogra> (well, we use debians package with ubuntu sauce on top indeed)
<zyga> ogra: right but I didn't want to bring that in with this patch, I want this to land
<zyga> ogra: I don't know if anyone else is doing this
<zyga> ogra: (testing initrd this way)
<zyga> ogra: but I wanted to show it is doable
<ogra> nope
<ogra> and it would be way coooler to actually do it in the distro :)
 * zyga was super slow because python3 async was a learning curve and several small details stopped me mid-process
<zyga> also I'm sick
<ogra> so that we could just use it from there (and have someone else maintain the core part of it ;) )
<zyga> and moving out day after tomorrow
<zyga> and also sunburned and on painkillers
<ogra> :(
<zyga> so some adverse factors towards productivity
<zyga> ogra: I wrote the code to be modular and reusable, with some more polish this could be used to test any early boot scenario
<ogra> well, we're not on a race, are we ?
<zyga> ogra: I'm mostly fond of the snapshot approach, which means this is blazingly fast
<zyga> ogra: well, I feel some pressure to finish this and move to snapd
<ogra> zyga, yeah, and i think you should show it to infinity and slangasek and ask them if they want to take it over into the initramfs-tools package
<zyga> ogra: I had a look at a redhat paper describing qemu and kernel optimizations that allows them to boot a kernel i 150ms
<zyga> ogra: sounds like a good idea, I will
<ogra> (alongside with landing it in our branch)
<ogra> if they take over we only need to care for the tests in the end
<ogra> and not for the framework
<ogra> and they get testing for free ;)
<zyga> ogra: yeah
<zyga> ogra: well, let me try that change you suggested
<ogra> to set the env vars you want executed in /init, just drop a file into /conf/conf.d// with the values set you want ... /init will read them from there
<zyga> ogra: I'm not yet sure if that's the approach to take but let me experiment and see what I can come up with
<ogra> and if you do that you can drop a lot of your code ... i.e. the bits that populate /dev and mount all the filesystems
<ogra> (and use what /init does at the top)
<zyga> INFO:qemu:(console) Begin: Mounting root file system ... /init: /scripts//test-init: line 1: syntax error: unexpected word (expecting ")")
<zyga> ogra: it seems that boot=test-init assumes everything is written in shell
<ogra> it shouldnt, that would be a kernel bug
<zyga> INFO:qemu:starting: ['qemu-system-x86_64', '-enable-kvm', '-snapshot', '-m', '64', '-kernel', 'kernel', '-initrd', 'initrd.back-to-back.cpio.gz', '-append', 'console=ttyS0 boot=/test-init -- testio=ttyS1', '-chardev', 'pipe,id=console,path=/tmp/consolefrqqj0e0', '-chardev', 'pipe,id=monitor,path=/tmp/monitoror3qf2oy', '-chardev', 'pipe,id=testio,path=/tmp/testio5zk4mizt', '-display', 'none', '-monitor',
<zyga> 'chardev:monitor', '-device', 'isa-serial,chardev=console', '-device', 'isa-serial,chardev=testio', '-device', 'isa-debug-exit,iobase=0xf4,iosize=0x4', '-drive', 'file=disk.img']
<ogra> (and systemd wouldnt work either ... unless there is a secret shellscript wrapper we dont know about )
 * zyga feels dizzy again
<zyga> what a day :/
<ogra> take a sick day ...
<ogra> seriously
<zyga> one sec
<ogra> no, one day :P
<ogra> not curing it just makes it last longer
<zyga> ogra: just sent you a pic
<zyga> ogra: everything looks like this around me
<zyga> downstairs is mostly packed now
<ogra> you picked the angle where i dont see the mountain of napkins around you :)
<zyga> ogra: they are behind me in the rubbish bin
<ogra> yeah, thought so :)
<pstolowski> fgimenez, hey, i'm seeing a bunch of auth errors from linode on travis
<fgimenez> hi pstolowski, do you have a link to the errors? sounds like something we can't help with, just to confirm
<pstolowski> fgimenez, https://travis-ci.org/snapcore/snapd/builds/244606124?utm_source=github_status&utm_medium=notification
<fgimenez> pstolowski: mm that error comes from spread itself, it can be caused by a missing or wrong SPREAD_LINODE_KEY env var, let me check locally using the same spread binary as travis
 * zyga de-conflicted https://github.com/snapcore/snapd/pull/3464
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<fgimenez> pstolowski: the same binary works fine locally with a valid SPREAD_LINODE_KEY, the errors you get can be caused by a transient error on linode, changes in how the binary behaves on travis, changes on the encryption keys... if the errors keep happening you need gustavo to look into this
<pstolowski> fgimenez, ack, thanks for looking into this!
<fgimenez> pstolowski: yw :)
<zyga> hey pstolowski
<zyga> how are you doing?
<pstolowski> hi zyga! good, thanks! what's up?
<zyga> pstolowski: could you have a look at https://github.com/snapcore/snapd/pull/3464
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<zyga> pstolowski: patch by patch, it should be trivial to review as each diff fits on screen (just moves code from a to b)
<pstolowski> zyga, very nice, i will
<zyga> pstolowski: dziÄki :)
<cjwatson> Could somebody please retry the xenial-i386 test on https://github.com/snapcore/snapd/pull/3475 ?  It looks suspiciously not-a-problem-with-my-branch
<mup> PR snapd#3475: store: change main store host to api.snapcraft.io <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3475>
<mvo> actually, can someone do a second review on 3475 please? should be straightfoward (and an easy win)
<zyga> cjwatson: I don't know if anyone can do this easily
<zyga> cjwatson: I was talking to mvo about it a few days ago, that it is not easy to re-trigger those tests
<pedronis> mvo: I'll look at it in a bit
<cjwatson> zyga: What options do I have?
<mvo> cjwatson: no worries, once this has a second review it can go in
<mvo> cjwatson: the autopkgtests are "extra", the only hard requirement is that travis is green which we have more control over. autopkgtest is still very useful as a canary for problems we may otherwise only see after a snapd deb upload
<zyga> cjwatson: force push again, not sure
<cjwatson> Ah, sounds like maybe I can just ignore the failing test then ...
<mvo> cjwatson: yes, this is our problem, not yours :)
<cjwatson> OK :)
<cjwatson> I like the sound of that.
<mup> PR snapd#3496 opened: cmd/snap-repair:  start of Runner, implement first pass of Peek and Fetch <Created by pedronis> <https://github.com/snapcore/snapd/pull/3496>
<pedronis> mvo: ^
<mvo> pedronis: yeah, just peeked (no pun intended) at it. I'm looking at debian unstable right now, breaks all our tests
<pedronis> mvo: just a heads up really, IÂ understand getting 2.26 out is out first priority
<mvo> pedronis: thanks for this
<mup> PR snapd#3497 opened: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>
<Chipaca> morphis: fgimenez: any luck with the debian thing?
<morphis> Chipaca: can you drop the quiet around that gdebi call so we can see why it fails to install libudev?
<Chipaca> morphis: if the gdebi call failed the quiet would print the output. Is it not failing?
<Chipaca> or rather, is it not returning with exit_failure?
<morphis> it should as it prints out it can't install libudev for whatever reason
<Chipaca> i can also disable debian and let you dig; it's not just my PR that's failing in this way
<morphis> no, don't disable debian
<morphis> so something has changed which breaks this now
<Chipaca> ah, you mean the --quiet
<fgimenez> Chipaca: morphis snapd#3497 from mvo fixes it
<Chipaca> not a prefix quiet but gdebi's --quiet itself
<mup> PR snapd#3497: spread: help libapt resolve installing libudev-dev <Created by mvo5> <https://github.com/snapcore/snapd/pull/3497>
<Chipaca> at what point did we regress prepare to run apt-get install eleventyfour times, once for each package we wanted to install?
<morphis> ah!
<Chipaca> we'd got it reduced to a single call or two at most :-(
<Chipaca> because it added several minutes to the prepare time
<morphis> Chipaca: I have a change pending to improve the pkgdb for that
<Chipaca> morphis: what's the idea behind pkgdb? i mean, other distros will have differently-named packages for the same thing, yet last i looked at it it was still handling things at the package level
<morphis> Chipaca: it abstracts package installation
<Chipaca> morphis: yes, i get that
<morphis> Chipaca: you give it something "cups" and it will figure out the right thing to do
<Chipaca> morphis: but does it make sense, given package names are going to be different?
<morphis> it will map "cups" to the right packages for each distro
<morphis> based on the set SPREAD_SYSTEM
<Chipaca> morphis: is "cups" a target, or a package name?
<Chipaca> dunno if "target" is the right name
<morphis> it's a name of a thing you want to install
<morphis> it can be a package name
<Chipaca> so we're going to carry around a table of package names per distro?
<morphis> yes
<morphis> that keeps these distro specific things out of the test cases
<morphis> and you just have to express "I want cups"
<morphis> Chipaca: but doing more than on apt-get call per distro_install_package call isn't what we should do
<mup> PR snapd#3498 opened: hooks: support for install and remove hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3498>
<mup> PR snapd#3497 closed: spread: help libapt resolve installing libudev-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3497>
<morphis> mvo: btw. what is the state of the 2.26 release?
<pedronis> Chipaca: I'm getting repeated mail from github all the time about this checkin of yours: osutil: unexport KillProcessGroup until we have a use case (f67bedb)
<pedronis> are you doing anything strange?
<pedronis> or it's a github bug
<mvo> morphis: seccomp-bpf needs to get merged, then we are unstuck again
<morphis> mvo: ah
<morphis> mvo: any timeline for this?
<mvo> morphis: jamie and I are working on this as quick as possible, the goal is before the end of this week
<mvo> hopefully sooner
<morphis> ok
<morphis> not pressure from my site, was just curious :-)
<morphis> mvo: would be good to have an update on https://forum.snapcraft.io/t/in-progress-snapd-2-26-4/514/15 so everyone else knows too
<zyga> pstolowski: small review of 3498
<pedronis> cjwatson: reviewed that PR, +1  , couple small remarks
<niemeyer> Mornings
<niemeyer> How's Travis behaving this morning?  Still issues?
<zyga> hey niemeyer
 * zyga hasn't seen any issues yet
<zyga> niemeyer: have you seen this?
<zyga>   
<zyga>   
<zyga> This job ran on our Trusty, sudo: required environment which will be updated on Wednesday, June 21st. Please add group: edge to your .travis.yml file to try the new images and check our blog for more details about this update.
<niemeyer> zyga: Yeah, but that's just a note.. we were having some issues yesterday about authentication issues on Linode, which apparently is actually about Travis itself not being quite sane
<niemeyer> We also saw at least once a message of packaging problems very early on in Travis setup land, before travis.yaml takes over
<zyga> niemeyer: I saw a patch from mvo about debian and udev update, maybe that's that
<zyga> (and also saw my branch fail on debian prepare)
<pedronis> yes, things are failing on debian atm
<cjwatson> pedronis: thanks, pushed fixes
<fgimenez> hey niemeyer, yes, we had authentication issues from travis to linode, seems to be better now
<niemeyer> fgimenez: Any news from this morning?
<fgimenez> niemeyer: we were getting this morning auth errors like https://travis-ci.org/snapcore/snapd/builds/244823012?utm_source=github_status&utm_medium=notification, recent executions don't show this error (i'm about to retrigger that one btw)
<morphis> zyga: ping
<zyga> morphis: hey, what's up?
<morphis> zyga: I am currently looking into a failure of tests/main/interfaces-content on Fedora, https://paste.ubuntu.com/24907862/
<morphis> effectively I don't see the bind mount in place so wondering what I should look at
<zyga> morphis: looking
<zyga> with master, I presume
<zyga> morphis: any SELinux denials?
<morphis> no
<morphis> but wait, maybe I have a clue
<zyga> morphis: it's a new program, perhaps the policy is stale
<morphis> the bind mount is in place, /var/lib/snapd/snaps/test-snapd-content-slot_2.snap on /snap/test-snapd-content-plug/2/import type squashfs (ro,nodev,relatime)
<morphis> hah
<morphis> $ echo $SNAP
<morphis> /var/lib/snapd/snap/test-snapd-content-plug/2
<morphis> that is the reason why
<mvo> morphis: updated the forum
<morphis> mvo: thanks!
<zyga> morphis: I think we spoke about that
<zyga> morphis: that $SNAP is wrong on Fedora
<morphis> zyga: we did
<zyga> morphis: I thought we fixed that but ... well :)
<zyga> morphis: good catch
<morphis> zyga: we fixed the content interface impl
<morphis> but as it seems not the part which sets up SNAP
<niemeyer> fgimenez: That's the same we were observing yesterday
<niemeyer> fgimenez: Please let me know if you see it again.. I'll tweak spread to debug the problem if so
<fgimenez> niemeyer: sure, thx
<jdstrand> mvo: hey, yesterday I had some ideas on the testsuite but I forget to click 'Review changes' so they were pending til just now. Let me know if you have questions
<Chipaca> jdstrand: o/
<mvo> jdstrand: cool, let me read it now
<Chipaca> jdstrand: did you see me point you at a snap the other day?
<mvo> jdstrand: I think all your other suggestions are now implemented, thanks again
<jdstrand> Chipaca: I don't recall otoh. which snap?
<Chipaca> jdstrand: test-snapd-service-notify
<jdstrand> mvo: thank you :) once you are ready, I wanted to go through it one more time top to bottom
<jdstrand> oh I definitely didn't see that
 * jdstrand looks
<mvo> Chipaca: I can also approve snaps fwiw
<Chipaca> mvo: it's published :-)
<Chipaca> mvo: it's about it getting DENIEDs because it's notify
<jdstrand> Chipaca: ok, yes, it is in the store and published. what do you need?
<jdstrand> ah
<Chipaca> jdstrand: if you install it, you'll see denies
<Chipaca> jdstrand: so first a question: is it a bug in the snap, ie is it expected, or is it a bug in our confinement?
<jdstrand> Chipaca: is this as script or compiled code? if compiled code, where is the source?
<Chipaca> if the latter, i can file a bug and all :-)
<Chipaca> jdstrand: it's not compiled
<Chipaca> jdstrand: it's python, using the system python, and a sdnotify.py included in the snap
<jdstrand> let me look at it. I feel like I remember this was intentional
<mvo> Chipaca: aha, sorry, then I misunderstood
<jdstrand> I remember we did talk about how you were seeing denials and would get back to me
<Chipaca> mvo: I don't know how you could've possibly misunderstood my vague insinuations at the half-formed predecessors of ideas
<Chipaca> jdstrand: this is that :-)
<jdstrand> yeah, c'mon mvo
<jdstrand> Chipaca: yep :)
<mvo> Chipaca: lol
<mup> PR snapd#3480 closed: overlord/cmdstate: new package for running commands as tasks <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3480>
<mvo> jdstrand: thanks for your comments, that looks very nice. I have the standup now, I will get back to it. I'm not sure I understand the "runimentary" part in the simulateBpf suggestion. unless I miss something (and modulo bugs) this should be exactly the same bpf environment that the kernel is using. we can talk after the standup if you want, maybe I'm missing something
<jdstrand> mvo: it isn't the same bpf vm as the kernel and we can't launch programs under it
<jdstrand> and so*
<jdstrand> by using the kernel, we can prove to ourselves it will work (well, at least on those kernels) and by running a program under it, even if it is /bin/true, we can prove to ourselves that the bpf is sane enough to be useable as a seccomp filter
<jdstrand> you are right that the fact that it compiles and is usable under the bpf vm shows a good deal (since the tested bpf needs to be good enough for both the vm and the kernel to use)
<jdstrand> mvo: ^
<jdstrand> Chipaca: ok, this needs a new interface because in 'man sd_notify' we see that sd_pid_notify() and sd_pid_notifyf() allow specifying a pid as the originating pid of the message, so a snap would be able to send status messages to systemd-notify for other processes not part of the snap
<jdstrand> Chipaca: this interface would consist of a comment along the lines of what I just mentioned and this rule '/run/systemd/notify w,'
<jdstrand> Chipaca: were you planning on using this mechanism by default?
<jdstrand> Chipaca: it looks like that interface could also include this rule: /{,usr/}bin/systemd-notify ixr,
<Chipaca> jdstrand: the only mechanism i think we wanted to support is notifying systemd itself (ie the READY=1 thing i think, plus the watchdog one?) but I think you're saying that you can't separate these things?
<mvo> jdstrand: thanks, yeah. I think both tests complement each other nicely, the nice thing aobut the VM is that we can easily test the KILL works and the whole thing is more controlled. but +1 for both tests
<mvo> jdstrand: I look into this now
<Chipaca> jdstrand: that last "you" was meant in the same generic "we"/"one" voice I was using before, I'm not saying you personally can't separate them :-)
<jdstrand> Chipaca: apparmor cannot-- it either gives access to the socket or it does not. access to the socket means that only DAC permissions will protect you, so if you are a root daemon, you can send status messages for other root daemons, based on the man page. I did not test this with code
 * Chipaca nods
<jdstrand> mvo: yes, not advocating for removing the vm (though a fork/exec could handle the kill ok)
<jdstrand> but yeah
<Vamsi> Hi, is it possible that the localhost has 2 login IDs?
<jdstrand> Chipaca: do you want me to dive deeper on that?
<jdstrand> Chipaca: I suspect I will only prove my assertion since the man page says that is what the api is designed to do
<Chipaca> jdstrand: and in any case we'd want the interface to support the broader use
<Chipaca> jdstrand: so, maybe jot it down to do in your copious free time
<Chipaca> Vamsi: pardon?
<Chipaca> jdstrand: it==the deeper dive i mean
<jdstrand> Chipaca: systemd could be updated to mediate that better since it says 'provided the appropriate privileges are available'. it could query the LSM (eg, AppArmor) to do more than just check DAC/capabilities
<Vamsi> Chipaca: to login the local host is showing two ssh IDs.
<jdstrand> Chipaca: how about I just create the interface and then detail everything in comments?
<Chipaca> jdstrand: A+
<jdstrand> I don't have any problem with the interface since users get to decide (or snap decls)
<Chipaca> yup
<jdstrand> Chipaca: when do you need this?
<Vamsi> For example: blah@172.18.0.65 and blah@172.19.0.65
<Chipaca> jdstrand: no present urgency
<Chipaca> Vamsi: where are you seeing this? What is the system running?
<jdstrand> Chipaca: ok, after the bpf and profile regeneration mvo is working on, and after password-manager-service, I'll do this (that puts it ahead of getting back to wayland, but this shouldn't take too long so I think that is ok. I might be able to squeeze it in somewhere sooner
<jdstrand> )
<Chipaca> jdstrand: perfect, thank you
 * Chipaca watches Vamsi go off and is left wondering
<Vamsi> Chipaca: I have connected my Ubuntu core local host to a monitor and that's where I see this.
<Chipaca> ogra: do you know if we print both addresses if you have more than one live interface?
<ogra> i think we do, yeah
<Chipaca> Vamsi: does your device actually have two network interfaces?
<ogra> they both need to be up and have an assigned IP
<Vamsi> Chipaca: I was initially using it on another network. And now changed the network.
<Chipaca> that shouldn't cause it
<ogra> so ssh in ... run sudo console-conf and de-confiigure the unused interface
<Chipaca> or should it?
<Chipaca> ogra: ?
<ogra> Chipaca, well, if he used a fixed IP that IP would still be set
<Chipaca> ogra: right, but if it were fixed it wouldn't pick up a new one
<Chipaca> ogra: and if it's dynamic it should just pick up the new one
<ogra> on that device
<Chipaca> Vamsi: I didn't see you answer: do you actually have two network interfaces on this device?
<niemeyer> mvo, Chipaca: What builds were failing on the auth issue?
<Chipaca> niemeyer: aw, i just restarted one
<Chipaca> niemeyer: but, chances are it'll be back
<niemeyer> Chipaca: np, goal was to restart indeed.. do you have a link?
<Chipaca> (travis is slow so it'll take a while to start)
<Vamsi> Chipaca: No. only one at a time. I had to change to a different because of some reasons.
<niemeyer> I've pushed an initial debug build of spread
<Chipaca> niemeyer: https://travis-ci.org/snapcore/snapd/builds/244930470 is the one i just restarted
<niemeyer> THanks
<Chipaca> niemeyer: seems to be 1:4 success rate right now, so you should see it fail again soon
<Chipaca> it just started, in fact
<niemeyer> mvo: Looks like yours passed
<mup> PR snapd#3475 closed: store: change main store host to api.snapcraft.io <Created by cjwatson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3475>
<Chipaca> niemeyer: it failed again
<mvo> niemeyer: yeah, I had a bunch of issues this morning but the current one seems to be ok
<niemeyer> Chipaca: Great, let me see
<Chipaca> Vamsi: are you able to access the device?
<Chipaca> Vamsi: over the network to one of those two addresses?
<Chipaca> Vamsi: actually, could you open a forum topic with all this? that way the console-conf people will also be able to help (i think they're in APAC tz)
<Chipaca> niemeyer: does that tell you anything?
<niemeyer> Chipaca: It does.. the environment seems right, which puts the doubt back on Linode.. I'll print out part of the actual key right before sending to be 100% sure
<Chipaca> niemeyer: maybe do a 'printenv'-like thing?
<Chipaca> i thought we had a printenv but i guess we ditched to save space in the logs
<niemeyer> Chipaca: We do that already
<niemeyer> Chipaca: Right before the call to spread
<niemeyer> Chipaca: (it's folded)
<Chipaca> ah so we do
<niemeyer> Okay, there we go again.. hold tight
<zyga> jdstrand: hey, can you review https://github.com/snapcore/snapd/pull/3464 please
<mup> PR snapd#3464: interfaces: put base policy fragments inside each interface <Created by zyga> <https://github.com/snapcore/snapd/pull/3464>
<zyga> jdstrand: ideally before new interfaces land :)
<Chipaca> niemeyer: -_- are you printing it at every api call?
<niemeyer> Chipaca: Oh no... it passed.. that's going to be a long log :)
<Chipaca> niemeyer: that's a lot of api calls
<jdstrand> zyga: yes it is on my list. it is after the bpf stuff atm
<Chipaca> niemeyer: cancel the build, i'm told spread loves that
<niemeyer> Chipaca: Yeah, we monitor the machines to see if they go down
<zyga> jdstrand: perfect, thank you
<niemeyer> Chipaca: Because they take a very long time to restart..
<niemeyer> I should optimize that so it uses less calls
<niemeyer> Alright.. future runs won't print sooo much data
<roadmr> niemeyer: hello :)
<roadmr> niemeyer: when you have a sec we'd love your feedback in https://forum.snapcraft.io/t/edge-case-scenarios-for-snap-validations/1036
<mup> PR snapd#3499 opened: Spi patch <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
<niemeyer> Chipaca: It passed, despite a reaaaaaaaly long log
<Chipaca> niemeyer: I'm sorry
<niemeyer> Chipaca: :P
<niemeyer> roadmr: Heya
<Chipaca> niemeyer: maybe when somebody reviews it I'll have to change something and you'll get another chance
<niemeyer> roadmr: Will look, thanks
<Chipaca> niemeyer: meanwhile I've had fun making go throw errors I'd never seen before
<Chipaca> like âwrite barrier prohibited by callerâ
 * Chipaca has all the fun
<niemeyer> Chipaca: Wow, never seen that either
<Chipaca> niemeyer: https://go-review.googlesource.com/c/43713/#message-52f9575a6a2544ad52ddaa588bfb29fb2e9feb3f
<Chipaca> âdance for me, little robot-hamster-thingâ âNO.â
<niemeyer> Chipaca: This seems closely related to the issue:
<niemeyer> https://www.irccloud.com/pastebin/Tru74bnx/
<niemeyer> https://www.irccloud.com/pastebin/tu7rft1h/
<Chipaca> niemeyer: ah, sorry, i didn't mean to send you down that rabbithole
<niemeyer> Chipaca: I'm not down into it.. was just overlooking it from afar.. :P
<Chipaca> niemeyer: it's SEP; I wrote it with a mutex, Ian copied over rwmutex and asked me to use that, but rwmutex is a lot more complex (to the point where it interacts wiht the gc), which things from newm can't do
<niemeyer> Meanwhile, all PRs I try to debug are passing.. maybe that's the solution.. I just need to keep looking
<mup> PR snapd#3500 opened: store: talk to api.snapcraft.io for assertions <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3500>
<zyga> niemeyer: typical quantum CI bug
<mvo> jdstrand: I was trying to make you prctl suggestions work with golang but its tricky with golang, it seems the only way is to add a C helper just for these kinds of tests, not sure its worth the work over spread tests
<niemeyer> Oh, sweet.. some interesting debug info now.. the bug is definitely on the spread end..
<zyga> mvo: which prctl call do you need?
<jdstrand> mvo: I was wondering if the goroutines would get in the way. so, the C helper is already there and there is C test code and C code in snap-confine so it shouldn't be hard to get that building. what I've been somewhat uncomfortable with is that the old tests ran through the kernel and the new don't. because we would build snap-confine everywhere, the tests in the profiles always went through all the different kernels in our test matrix
<mvo> zyga: I have all the prctl stuff, I just get hangs and zombies when I apply it
<jdstrand> mvo: the new implementation dropped that, but tested more, so it was kinda a wash. with my suggestion, we get better coverage in the new
<mvo> jdstrand: ok, I will create a tiny C helper for that then
<jdstrand> mvo: I guess it could be in a follow-up PR if you feel strongly about it (I'd like to not lose the kernel bpf loading tests for new rules, etc)
 * mvo takes a break first
<jdstrand> mvo: to be clear, you did see the C helper I pasted, right?
<jdstrand> (in the PR)
<jdstrand> it works so steal away
<mvo> jdstrand: its fine, I want the PR in ASAP, but I also want it to be as good as possible as it changes one of our fundamental things :)
<jdstrand> mvo: yes, I feel the same. with this we will have super-charged testing, which is always a good thing :)
<mvo> jdstrand: yeah, I saw it. I'm more thinking about the bits around it, like how/when to build this C helper from the unit tests etc
 * jdstrand nods
<jdstrand> I'm going to step away for a little exercise but will be back in a bit
<mvo> jdstrand: let me ponder a little bit, I whish golang would give me more control over the runtime
<mvo> jdstrand: enjoy
<jdstrand> mvo: yeah :\
<zyga> mvo: welcome to my shoes :)
<zyga> mvo: I really really wish golang had a "system" mode but it would run counter to the threading and io model
<cjwatson> Can https://travis-ci.org/snapcore/snapd/builds/244975993 be retried?
<zyga> yep
<zyga> done
<cjwatson> ta
<ogra> ppisati, http://paste.ubuntu.com/24908787/ ... got the nanopi neo  booting with master-next (still a lot of =y that i need to sort, but getting there )
<mup> PR snapd#3501 opened: store: orders API now checks if customer is ready <Created by cjwatson> <https://github.com/snapcore/snapd/pull/3501>
<ogra> elopio, hey
<pedronis> cjwatson: is api/v2 also going to be api/v2/snaps/assertions ?
<pedronis> or we don't know yet
<cjwatson> pedronis: so eventually I expect yes, but I've been taking the approach that any API that I've basically just transcribed from something existing goes under /api/v1/snaps/ for now
<cjwatson> pedronis: (following a discussion with William)
<cjwatson> pedronis: v2 might get e.g. bulk endpoints
<cjwatson> pedronis: and we can easily copy things over if we decide we remain happy with them
<pedronis>   /snaps/assertions readds a bit weird to me
<cjwatson> pedronis: so the policy is basically /api/v1/<anything else> -> old, legacy, busted, please don't use, only on search.apps.ubuntu.com; /api/v1/snaps -> current generation, may need work; /v2 -> new, not defined yet
<cjwatson> pedronis: the api.s.i frontends disallow everything under /api/v1 that isn't /api/v1/snaps, because there was a bunch of other legacy stuff there
<cjwatson> that we didn't want to expose on api.s.i
<pedronis> because of things like account or account-key
<cjwatson> for v2 I'd expect it to be /v2/assertions, not /v2/snaps/assertions
<pedronis> ok
<cjwatson> the snaps segment there is basically just so that we don't have to juggle too many haproxy rules for v1
<cjwatson> it really means /api/v1/nottotalcrap
<ogra> elopio, HAPPY BIRTHDAY !
<koza_> orga, hey, there might be solution to hummingboard issue
<koza_> ogra, fyi one has to blow USB fuses to force microSD boot
<roadmr> happy birthday elopio \o/
<ppisati> ogra: yeahhh! :)
<ppisati> ogra: what are the boards you are working on?
<ogra> koza_, blow ?
<ogra> ppisati, orangepui zero and nanopi neo ... i also have an old bananapro lying here ... and popey said he was planning to get a nanopi air so i'll have a guineapig to make the wlan variant work as well
<pedronis> cjwatson: I think this is something you wondered about in the past: https://forum.snapcraft.io/t/unify-asserts-errnotfound-and-store-assertionnotfounderror/1065
<ogra> koza_, yoou mean like "physically break" or is that a SW thing
 * zyga goes to pack
<ogra> ppisati, also https://github.com/ogra1/orangepi-zero-gadget and https://github.com/ogra1/nanopi-neo-gadget for the u-boot gadgets ...
<cjwatson> pedronis: It sounds like the sort of thing that might well have annoyed me when I was doing account-key stuff, though I don't remember for sure
<koza_> ogra, irreversible change, take a look by yourself https://wiki.solid-run.com/doku.php?id=products:imx6:microsom:imx6-fuse
<ogra> koza_, woah
<ogra> thats really awful
<ogra> koza_, so i cant get my board back to original state then :(
<mup> PR snapcraft#1368 closed: cli: get_project_options must not discard kwargs <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1368>
<koza_> ogra, yeah it is, where am I going to find windows based pc? ;-)
<ogra> koza_, in a VM i guess :)
<koza_> most probably there
<ogra> oh man ...
<ogra> why do people design such stuff ... /me shakes head
<genii> ogra: Yes, I often wonder that also. Why not just have it so you can always choose what to boot from and screw fuses and other irreversible things
<ogra> genii, the fun part is that the board has a bunch of jumpers for exactly that ...
 * genii goes back to struggling with his NanoPi M3 now
<ogra> genii, well, i just got my neo booting ubuntu core ;)
<genii> Ah, nice
<ogra> working on a generic allwinner kernel snap
<popey> ogra: if you're gonna work on it, I'll absolutely get a nanopi air! :D
<mvo> niemeyer: unless jdstrand disagrees I think 3431 is ready for a second review
<niemeyer> mvo: Sweet, thanks!
<ogra> popey, well, i got the neo booting ... afaik the air is identical with just an additional wlan chip
<niemeyer> Getting to the bottom of the API key issue, I think
<mvo> niemeyer: one of the very last questions/answers is about the testing, thats an area we are currently exploring, jamie prefers the kernel bpf for the testing instead of the bpf VM
<mvo> niemeyer: but its all in the PR hopefully and I can answer any questions after dinner
<niemeyer> mvo: Thanks again
<popey> ogra: ordered
<ogra> ha!
<ogra> awesome
<popey> expect weeks from china tho
<Chipaca> niemeyer: in looking at this I'm wondering again about "snap start --enable foo" vs "snap enable-service --now foo"
<Chipaca> niemeyer: should i resuscitate the forum thread?
<niemeyer> Chipaca: You just did I think :D
<Chipaca> not in the forum per se :-)
<pedronis> in the total conversation space
<popey> can I please point snapd people at https://forum.snapcraft.io/t/why-do-devmode-snaps-not-auto-update/1028
<Chipaca> niemeyer: pedronis: in the forum now: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262/23?u=chipaca
<Chipaca> popey: I can say for sure that it isn't a bug; it's very much intentional
<Chipaca> popey: that is, it isn't a _code-level_ bug
<Chipaca> popey: it might be a design-level bug :-)
<Chipaca> pie-in-the-sky bug
<Chipaca> mmm pie
 * Chipaca takes a break that will not involve pie
<niemeyer> popey: Let me try to find the prior discussion to copy there
<mup> PR snapcraft#1370 closed: integrations: add the snapcraft Dockerfile <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1370>
<jdstrand> mvo: I'm going to go through it top to bottom. I expect to give an Approved
<niemeyer> jdstrand: Thanks for your attention on this one
<jdstrand> np
<niemeyer> ALRIGHT
<Chipaca> INNIT
<niemeyer> I think the auth issue is sorted
<Chipaca> niemeyer: what was it?
<niemeyer> Chipaca: Bug on the key reading logic.. bug surfaced after a second Linode backend was introduced in spread.yaml
<Chipaca> niemeyer: heh. ok then :-)
<Chipaca> EOD o'clock for me
<Chipaca> ogra: https://bash.rocks/ just for you
<ogra> hahaha
<niemeyer> Chipaca: "bashing rocks" is exactly how I feel when writing shell
<mup> PR snapcraft#1352 closed: Allow source-type to specify local <Created by jocave> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1352>
<ondra> ogra ping
<ogra> ondra, hey
<ondra> ogra it's working for both
<ondra> ogra dd and fastboot
<ogra> oh, i didnt notice that
<ondra> ogra that fastboot blob will create part table identical to when you dd
<ondra> ogra just to have both options if anybody cares
<ogra> ondra, yeah, as long as i can still just use ubuntu-image and get a single partitioned img file out, thats fine
<ondra> ogra BTW I defo think step to convert u-boot to boot.img is missing in read me, without that it just does not work
<ondra> ogra ubuntu-image works just like before, and up to you what method to install you choose
<ogra> well, i want to re-work the gadgets anyway ... we can add that setp to the build
<ondra> ogra and I think we can also use upstream u-boot
<ogra> i dont think db410c was ever submitted upstream
<ogra> (happy to be wrong though)
<ondra> ogra I think it was
<ogra> well, if it was we should definitely swithc over
<ondra> ogra so v2017.5 tag does boot uboot. but fails to power mmc
<ogra> i'll check that when i re-work the gadget
<ondra> ogra give me sec, checking one thing
<ogra> ah
<ogra> btw, i got nanopi and oragepi zero roughly working ...
<ondra> ogra nice!
<ondra> ogra will confirm tomorrow, but I think tag v2016.05 from upstream will work
<ogra> still a little work to do but the hard parts are done
<ondra> ogra it has dragonboard410c config
<ogra> ondra, yeah, no hurry ... i'll be in the office next week btw
<ondra> ogra I wonder more how to support it more officially
<ogra> what exactly ?
<ogra> the db ?
<ogra> cant be more official than now :)
<ondra> ogra as we do not update u-boot now anyway, once you flash, you can actually use gadget for mmc
<ondra> ogra emmc boot
<ogra> well, an initrd with a dd script ... wrapped around the image
<ogra> as one blob on an SD
<ondra> ogra BTW how are dtb handled on dragonboard, do they need to be loaded by lk before u-boot?
<ogra> boot the SD ... UI offers install
<ogra> no
<ogra> such awful design only exists on RPi
<ondra> ogra does not matter how we install. it's more how we create image
<ogra> for normal boards uboot is responsible for loading the dtb
<ondra> ogra cool, as to build u-boot into boot.img it uses "fake dt and fake ramdisk"
<ondra> ogra so lk is happy
<ogra> are you in bluefin next week ? lets sit down and brainstorm some plans for installers ;)
<ondra> ogra so yeah, we sort of need two gadgets, to build image for mmc and for emmc
<ondra> ogra yeah I will be
<ogra> yep
<ogra> cool
<ondra> ogra BTW u-boot has installing facility
<ogra> yep
<ogra> like dd
<ondra> ogra I try to patch it a bit already with right files
<ondra> ogra no, it uses actually that fastboot blob to repartition and then flash each partition from supplied file
<ondra> ogra it has defined partition <> file map there
<ogra> did you actually try that yet ?
<ogra> the resize code might fall over
<ogra> (during first boot)
<ogra> HOOORRRRAAAAYYY !
<ogra> https://code.launchpad.net/~ogra/+snap/linux-generic-allwinner/+build/48484
<ogra> it built !!!
<jdstrand> roadmr: would you mind pulling r884 of CRT? it isn't urgent
<roadmr> jdstrand: not a problem, here I go
<jdstrand> roadmr: thanks!
<ogra> http://paste.ubuntu.com/24911070/
<ogra> :D
<jdstrand> ogra: nice! :)
<ogra> yeah ... not sure what to do with the kernel package though ...
<ogra> it is based off master-next from the kernel team ... i'm pondering if i actullay want to be responsible for that :)
<ogra> (it can only build on artful ... due to a hard gcc6 requirement of the allwinner bits ... so i have to jump through pkenty of hoops for every update currently)
<ogra> OTOH thats probably fine for a developer community image ...
<Chipaca> niemeyer: o/
<niemeyer> Chipaca: o_/
<Chipaca> niemeyer: what's the reasoning behind "restart --reload" instead of just "reload"?
<niemeyer> Chipaca: The second part of the sentence.. "Daemons that do not support reloading are restarted instead as long as they were already running (systemd's try-reload-or-restart)."
<Chipaca> niemeyer: tbh neither sits comfortably
<niemeyer> Chipaca: That sounded like the best compromise when considering the options
<niemeyer> Chipaca: The reload option that does nothing if the daemon doesn't support it feels bad, and using reload to restart without notice also feels bad
<niemeyer> Chipaca: "restart --reload" doing the best it can out of both seems reasonable
<Chipaca> niemeyer: documenting it is weird: restart restarts it if it's running, starts it if not; restart --reload reloads it if it is running and supports it, restarts it if running and does not, does nothing if not running
<niemeyer> Chipaca: You're trying pretty hard to be confusing there :)
<niemeyer> Chipaca: The sentence per the original forum post seems much simpler
<Chipaca> niemeyer: i didn't mean "this is how you document it", i meant, these things don't mesh, and in documenting we'd try to describe them as a single thing
<Chipaca> niemeyer: the sentence in the forum post tells the user to go read man systemctl
<niemeyer> Chipaca: No, that was an implementation hint
<niemeyer> This seems pretty clear:
<niemeyer> snap restart <snap>[.<app>] â Restarts all daemons in the snap, or only the selected one if specified. Daemons which are not yet running will be started as well.
<niemeyer> snap restart --reload <snap>[.<app>] â Reloads all daemons in the snap, or only the selected one if specified. Daemons that do not support reloading are restarted instead as long as they were already running.
<Chipaca> niemeyer: but that's not how the 'snap restart --help' would get printed
<Chipaca> snap restart: <does this thing> --reload <changes this thing into this other thing>
<niemeyer> Chipaca: It can similar to that. We have other commands that provide examples and document them under snap.
<niemeyer> Chipaca: I can also try to help on the review if you want
<Chipaca> niemeyer: I'll implement it this way, but i'm pretty sure we're going to come back and tweak it later
<Chipaca> niemeyer: don't review just yet, i'm about to push a change to the pr that's up
<Chipaca> because i forgot to expose try-reload-or-restart
<niemeyer> Chipaca: Sounds good, and thanks for the care being put on those commands. Appreciated.
<Chipaca> niemeyer: one thing that's bothering me a little is the cute summary
<Chipaca> niemeyer: in snapd it's fine, we don't i18n that
<Chipaca> niemeyer: but as the status for the command, which would print something similar, it gets iffy
<Chipaca> because we want to i18n those
<Chipaca> and I don't know how to handle that properly
<Chipaca> i'm pretty sure our i18n thing doesn't support plurals enough to do it 'right'
<Chipaca> i worry too much; we don't have arabic nor belarusian nor welsh translations yet :-)
<Chipaca> niemeyer: basically, languages where knowing which plural form to use requires a formula
<niemeyer> Chipaca: Yeah, we'll need to worry about that at some point :)
<Chipaca> niemeyer: e.g. polish has singular, then a plural for 2,3,4; then a plural for 5-21, a different one for 22-24, then 25-31, â¦
<Chipaca> and i can't find anywhere that says how to do a list of e.g. "x, y, and z"
<niemeyer> Chipaca: There are tricks we can use
<niemeyer> Chipaca: Such as not using plural forms at all
<Chipaca> like, never translate to polish
<niemeyer> Chipaca: and that
<niemeyer> :)
<Chipaca> :-D
<Chipaca> "your language is too complicated, so from now on you speak spanish"
<niemeyer> zyga might agree
<niemeyer> "We've upgraded your country to portuguese.. wait, no.. that was a downgrade.. esperanto!"
<Chipaca> if we did that, there'd be *so* many smug people
<niemeyer> Anyway, I should find dinner
<niemeyer> In portuguese
<niemeyer> Have a good night there
<Chipaca> niemeyer: buen provecho! i'll probably be gone by the time you get back :-)
<niemeyer> Gracias, una buena noche a usted
<Chipaca> igualmente!
<_28Kb> is there any visual tool for creating snaps yet? even anounced...
<_28Kb> 21st century... extremely overrated
<nacc> _28Kb: "visual tool"?
<_28Kb> software for making snaps
<ogra> a bit overkill give you create a single yaml file
<ogra> *given
<nacc> _28Kb: yeah, i think that's the wrong approach
<nacc> _28Kb: what ogra describes is certainly the ideal, but generally
<ogra> yeah, i'm an optimist ;)
<nacc> heh
<_28Kb> snappy promises new age of app managing... and basically stays same as traditional
<nacc> _28Kb: i'm not sure what you're talking about?
<nacc> _28Kb: yes, you still have to write code(ish) to package something, but snaps are way less and it's yaml
<_28Kb> you make something with plugs and slots... and then time passes, your hair turn white and you see no progress
<nacc> _28Kb: i'm not sure what a GUI would help with plugs and slots?
<ogra> interface management in gnome-software is actively being worked on
<nacc> ogra: i assume that's allowing you to manage what slots/interfaces various snaps are allowed to use?
<ogra> yes
<nacc> ogra: or something correct in the terminology :)
<nacc> ogra: cool, that will be nice to see
<ogra> but that has still nothing to do with creating a snap
<nacc> right, that was going to be my next point :)
<ogra> for which most people like to use github and build.snapcraft.io
<nacc> but even then, i think _28Kb was referring to making the snap itself (like writing the code?). I'm not sure
<ogra> that said ... if you have an idea how to do snap cration in a GUI way, nobody will block you _28Kb
<_28Kb> i just wanted to create some opengl program... i must be a scientist for that i assume now
<nacc> _28Kb: you don't have the program already?
<_28Kb> i don't even have a platform
<ogra> snap is a packaging and delivery mechanism ... you still need the app ... completely independent from the way you deliver it to users
<_28Kb> i understand that, and i'm sad :)
<ogra> (well, also a security mechanism etc ... there is definitely more to it than just delivery and such ... but still you need an app first :) )
<ogra> integration snap building in various IDEs would surely make sense though
<_28Kb> for me, it's ok for system to be read only... then i saw this snappy ideas.. i thought i'd be like in the ocean just swimming
<ogra> well... you will drown if you dont learn to swim first
<ogra> nobody "just jumps into the ocean"
<ogra> and mind the sharks ...
<ogra> ... with lasers ...
<ogra> ;)
<_28Kb> it's easier to make a better world with rifle and bullets
<ogra> nah, violence is never the right answer
<ogra> (well ... except in games :) )
<_28Kb> it's easier to create your own framework than use existing ones...
<_28Kb> people will help you by giwing the fish.. nobody learns you to do it yourself
<_28Kb> surface everywhere.. nowhere the essence
<ogra> so did you already try to package your opengl app as a snap ?  ... you wont learn it if you dont try it ...
<_28Kb> i will
<ogra> well, if you run into concrete problems, we are here to help ...
<_28Kb> i found some snap similar to your nickname earlier... ogre or ogra (green dude)
<ogra> heh
<_28Kb> i thought i could play with OpenGL right away
<ogra> you would play with opengl right away ... but outside of the snap ... once your app works, you snap it up
<ogra> by simply creating a snapcraft.yaml
<ogra> it is two separate things
<_28Kb> i't like snap daddy... and you connect child snaps to it?
<_28Kb> it's*
<ogra> not really ... its more like a kindergarden full of children and you control the access to the play equipment on the playground
<ogra> so first of all ... make children ;)
<ogra> then build the kindergarden (snap) ...
<ogra> then contol the access with interfaces (slots/plugs)
<_28Kb> i'll try... ty for info
<ogra> come back if you have more questions ...
<_28Kb> ok :)
<ogra> (not today anymore for me though ... 1:40 here, i'll go bedwards)
#snappy 2017-06-21
<Chipaca> mwhudson: https://github.com/golang/go/commit/91139b87f776a553524b022753981e7909386777
<Chipaca> and good night
<yo_> shouldn't the "requires classic or confinement override
<yo_> " error be a "do you want to install classic mode which is blah blah Yes/No" ?
<mup> PR snapcraft#1371 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1371>
<icey> is it possible to get builds.snapcraft.io to build a package for which you are not a maintainer? the project has a snapcraft.yaml
<icey> I've just invited the owner of the repository to collaborate on the snap, but wondering what I can do to help move things forward
<mpt> icey, GitHub requires someone to be a repo admin (or an organization owner) to set up âwebhooksâ, which is how build.snapcraft.io detects commits. So youâll need to persuade a maintainer.
<mpt> (Details here: <https://help.github.com/articles/about-webhooks/>)
<icey> lett about persuading mpt, more about coordinating; I think he's in Pacific time, I'm Central European
<mpt> icey, in the meantime, maybe you could build the snap on your own machine, to make sure it will work when it is set up. :-)
<icey> mpt I've been building it, I just invited the maintainer to collaborate on it :) `snap install --edge --classic alacritty` ;-)
<mpt> Ah, good stuff
<mup> PR snapd#3502 opened: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<Chipaca> moin
<mup> PR snapd#3503 opened: tests: add browser-support interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3503>
<mvo> fgimenez: hey, quick question - do you have a suggestion how we could test the seccomp-bpf branch against the nested revert test that uncovered the network-manager and bluez issues? its not merged yet but before we merge it it would be great to verify that the bug is actually fixes
<mvo> fixed
<fgimenez> hey mvo, sure, the changes in the test for covering the bluez issue are already on master, just merging it in your branch (maybe the changes are already in your branch and this step is not needed) and running after setting the env vars should be enough, i can give it a try
<fgimenez> wait, we need a core with your changes..
<mvo> fgimenez: yeah, thats the issue, could we simply revert to a saved copy of the self-build core or something?
<mvo> fgimenez: or maybe we need to do it manually, but it would be great to get confirmation
<fgimenez> mvo: yep after your changes are in master and an edge core is built from it it should be easy but before... we could build a core changing the ppa from wich it picks the debs and uploading there the debs built from your branch (maybe we could do this in the edge branch too?)
<fgimenez> mvo: once we have a core with the changes from your branch i can change the test to sideload it, should that work (instead of refreshing)?
<mvo> fgimenez: hm, it all sounds brittle, maybe the best is to do some basic testing manually and then once it is merged to the proper nested run, we want this merged anyway so it should be fine
<fgimenez> mvo: ok sgtm, how can we test this manually?
<fgimenez> instead of sideloading we could also upload the core built from your branch to staging and do a proper refresh
<jacekn> hello! Quick question - I can "snap set <snap> key=val". How do I remove certain config option? There is no "unset"
<ogra_> you set it to nothing
<bloodearnest> so, when installing a snap, systemd units start up before the initial configure hook is run, correct?
<bloodearnest> is there an install hook or similar thing that runs first, before systemd units are set up?
<jacekn> ogra_: so that does not seem to work for the kube-apiserver (I used snap set kube-apiserver runtime-config="")
<jacekn> ogra_: I end up with something like this: --min-request-timeout 300 --runtime-config  --service-account-key-file
<bloodearnest> am I right in thinking that snapctl only works in the configure hook, currently? It seems to fail in any other context anyway
<mup> PR snapd#3504 opened: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>
<mvo> jdstrand: you will like this one -^ :)
<Chipaca> pstolowski: i think you're the one for answering bloodearnest's question there
<pstolowski> bloodearnest, hey. correct, services are started before configure hook. install hook that runs before services are started is being reviewed currently - https://github.com/snapcore/snapd/pull/3498
<mup> PR snapd#3498: hooks: support for install and remove hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3498>
<bloodearnest> pstolowski, great, thanks. Any rough idea of when that might be in a release?
<pstolowski> bloodearnest, also, last week support for using snapctl also from other contexts (from apps in your snap) landed into master
<bloodearnest> pstolowski, awesome
<pstolowski> bloodearnest, not sure when the next release is, probably 2-3 weeks from now if it lands soon; mvo?
<mup> PR snapd#3505 opened: PLEASE IGNORE: Enable more tests for suse and fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3505>
<Facu> Chipaca, et al, I'm running snapd like this: sudo SNAP_TESTING=1 SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 SNAPPY_USE_STAGING_STORE=1 /usr/lib/snapd/snapd
<Chipaca> Facu: using it to install things, or just to query?
<Facu> however, I'm not seeing the body responses in the logs, shouldn't I? this is an excerpt of the response: http://linkode.org/#IiLRuuty0L54FkOAgtvKb7
<Facu> Chipaca, it's inside a VM, it works! but I lack logging
<Chipaca> ah
<Chipaca> Facu: not related: it's SNAPPY_TESTING, not SNAP_TESTING
<Chipaca> that _should_ work
 * Chipaca tries it
<Facu> Chipaca, but no body logged :/
<Chipaca> Facu: can you show me?
<Chipaca> Facu: i mean, show me the logs you can see
<Facu> Chipaca, note that I'd want also body in the requests, not only in the responses
<Facu> Chipaca, yes!
<Chipaca> Facu: you're not expecting to see the body of a snap download in the logs, are you?
<Facu> Chipaca, http://linkode.org/#LhT7ABi0DterA4v7hEpZT4 , the activity triggered by a "snap refresh foobar40"
<Facu> Chipaca, nah, just jsons
<Chipaca> Facu: I'm seeing the response bodies in the logs, running it the same way you are
<Facu> :o
<Chipaca> and 2.22.2 is old, but not _that_ old
<Chipaca> Facu: in particular: 2017/06/21 12:44:41.973596 logger.go:75: DEBUG: < "HTTP/1.1 404 Not Found\r\nContent-Length: 380\r\nCache-Control: private, max-age=0, no-cache\r\nContent-Type: application/problem+json\r\nDate: Wed, 21 Jun 2017 11:44:42 GMT\r\nServer: Apache/2.4.7 (Ubuntu)\r\nStrict-Transport-Security: max-age=15768000; includeSubDomains; preload\r\nX-Bzr-Revision-Number: 138\r\nX-Vcs-Revision: 138\r\n\r\n{\"detail\":\"no assertion with type
<Chipaca> \\\"snap-declaration\\\" and key {\\\"series\\\":\\\"16\\\",\\\"snap-id\\\":\\\"99T7MUlRhtI3U0QFgl5mXXESAiSwt776\\\"}\",\"error_list\":[{\"code\":\"not-found\",\"message\":\"not found: no assertion with type \\\"snap-declaration\\\" and key {\\\"series\\\":\\\"16\\\",\\\"snap-id\\\":\\\"99T7MUlRhtI3U0QFgl5mXXESAiSwt776\\\"}\"}],\"status\":404,\"title\":\"not found\",\"type\":\"assertions:v1:not-found\"}\n"
<Facu> logger.go in DEBUG, I have those
<Chipaca> yes
<Chipaca> i can clearly see your log truncated at the \r\n
<Chipaca> which is strange
<Chipaca> ie just before the body
<Chipaca> Facu: what happens if you run the snapd from core directly?
<Chipaca> iei instead of /usr/lib/snapd/snapd, /snap/core/current/usr/lib/snapd/snapd
<Facu> Chipaca, let me check; also, for considering... I'm in the VM after doing "lxc exec snapd-staging bash", may it be that my terminal is weird, and the golang library behaves differently?
<Chipaca> what "golang library" dude
<Chipaca> :-)
<Chipaca> all the go bits are static i mean
<Chipaca> â¦
<Chipaca> oh, i got what you meant
<Facu> Chipaca, logger.go, don't know
<Chipaca> Facu: try sending it to a file to check that
<Chipaca> but i seriously doubt it
<Facu> it logs to stderr
<Chipaca> yes
<Facu> Chipaca, no luck (running core and/or into a file)
<Chipaca> grmbl
<Facu> this are the situations where I value a lot editing some /usr/lib/whatever system file and putting a print() there :p
<Chipaca> Facu: this should be just as easy once you've got it set up to build
<Chipaca> ie something like 'go build -o /tmp/srv ./cmd/snapd && SNAPPY_yadda â¦ /tmp/srv'
<Chipaca> but, yes, not python
<Facu> Chipaca, yes, but in that case I'm not using *what is installed*
<Chipaca> well... you're using 2.26.3+git410.g6e6bfcc which is pretty funky
<Chipaca> :-)
<Chipaca> Facu: what happens if you force it to use the one in /usr/lib?
<Facu> Chipaca, isn't that what I'm doing when running /usr/lib/snapd/snapd ?
<Chipaca> Facu: sudo SNAP_REEXEC=0 SNAPPY_TESTING=1 SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 SNAPPY_USE_STAGING_STORE=1 /usr/lib/snapd/snapd
<Facu> still no luch
<Facu> *luck
<Chipaca> phew
<Chipaca> Facu: can you check whether this works outside of the vm (but not pointing to staging)?
<Facu> Chipaca, it works fine in my host machine
<Chipaca> o...k
<Facu> Chipaca, maybe updating snapd?
<Chipaca> Facu: updating to what?
<Facu> Chipaca, latest version? no idea
<Chipaca> Facu: you ran the one from core already
<Chipaca> that's the latest
<Chipaca> Facu: and i have never seen this behaviour since I added support for the 3rd bit
<Chipaca> give me a bit though
<mup> PR snapcraft#1372 opened: cli: Containerbuild clean <bug> <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1372>
<Chipaca> Facu: what distro is snapd-staging?
<Facu> Chipaca, I'm not *blocked* for this right now (may really needed it later) but I'm happy to help you testing and trying stuff
<Facu> Chipaca, xenial, 16.04.2
<Chipaca> Facu: no idea then
<Chipaca> Facu: if you can give me steps to reproduce this i'll give it a poke this afternoon
<Facu> Chipaca, created an lxc as specified in https://docs.google.com/document/d/1MSThKrO762SgeY2lw74R5lcA7oQjTtq1ifYNut18bho/edit#heading=h.7f3zvinx0gcg under "snapd" and entered into it with "lxc exec snapd-staging bash"
<Facu> Chipaca, and thanks
<Chipaca> Facu: the github gist that doc points to is 404 for me
<Facu> Chipaca, why people uses gist and not linkode!?
<Chipaca> Facu: access control? revision history? group and team membership? Faster page loads? https by default?
<Facu> Chipaca, oh, I wonder why linkode does not redirects to 443
<mvo> bloodearnest: we are currently working on an important fix in snapd, once that lands (the goal is this week), then normal 2 week schedule for snapd releases resumes
<bloodearnest> mvo, ack, tx
<ogra_> ppisati, when i patch a dts in the tree and re-build the package, is anything in the build env reverting my change ? i dont get the new devices in the dtb
<ogra_> (i didnt run "fdr clean" to save time, would that be needed ?)
<ppisati> ogra_: nothing reverts stuff in the tree, and it should call 'make dtb' at the end, so you should get the 'new' dtb
<ppisati> unless there's a bug, of course
<ppisati> ogra_: which tree?
<ogra_> master-next ... i'm trying to add a sun8i-emac driver http://paste.ubuntu.com/24916775/
<ppisati> ogra_: artul?
<ppisati> *artful?
<ogra_> yep
<ppisati> ogra_: let me try that
<ogra_> ppisati, well, fdr clean seems to have helped, now i see ethernet0
 * ogra_ checks if he also sees it after u-boot :P
<ogra_> [   12.387103] sun8i-emac 1c30000.ethernet (unnamed net_device) (uninitialized): No associated PHY
<ogra_> aha
<ogra_> seems i'm close :)
<mup> Bug #1699504 opened: "network" plug does not allow outbound ping <Snappy:New> <https://launchpad.net/bugs/1699504>
<ogra_> hmm,, thats a bit annoying that it makes everything so time consuming
<abeato> ppisati, ogra_ is it possible to force building with a given gcc version a kernel snap?
<ogra_> abeato, i guess you can force one in build-packages
<ogra_> but indeed only the ones available in xenial
<mup> PR snapcraft#1373 opened: Add support in snapcraft yaml for reload-command directive <Created by bloodearnest> <https://github.com/snapcore/snapcraft/pull/1373>
<abeato> ogra_, ok, will give a try, thanks
<mup> PR snapd#3490 closed: client, daemon: using oddjobstate, implement service operations <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3490>
<ppisati> abeato: uhm, not that i'm aware
<abeato> ppisati, ok, nw
<davidcalle> Chipaca: hey, I've just noticed a store snap with an empty publisher field in snap info, is that supposed to happen in some edge cases?
<Chipaca> davidcalle: what snap?
<davidcalle> snap info peek
<fgimenez> mvo: quick question, is SNAPPY_USE_STAGING_STORE enough for ubuntu-image to use staging? the underlying prepare-image is going to honor it, right?
<jdstrand> mvo: hey, so I'm going to flesh out the password-manager-service policy next. you have a PR already that I figured I'd build on. how do you want to coordinate that work?
<pedronis> fgimenez: it needs snap built for staging
<pedronis> because of keys for checking assertions
<fgimenez> pedronis: aha, great thx, i'll change the test to have that into account to (and eventually build snap if needed)
<mvo> fgimenez: I think so, yes
<mvo> jdstrand: you can have the password-manager-service, either branch from it and push a new PR and I close mine - or just push to my PR. but if its a lot of churn I think branch, new PR is better
<Chipaca> niemeyer: taking this logs things to its natural conclusion, i think i'll make systemd.Logs (which nobody else uses) return an io.Reader
<jdstrand> mvo: ack, thanks. I'll do a new PR I think
<Chipaca> davidcalle: I don't see it having an empty publisher here
<Chipaca> davidcalle: what are you seeing?
<niemeyer> Chipaca: Yeah, that seems reasonable
<niemeyer> Chipaca: The other option would be to pass in a writer, but that's perhaps less natural
<davidcalle> Chipaca: I think I figured out what happened. I had a homemade snap of the same name locally installed, which gave me:
<davidcalle> https://usercontent.irccloud-cdn.com/file/ZZJolLOW/Screenshot%20from%202017-06-21%2016-09-10.png
<Chipaca> davidcalle: yep, x revisions don't have a publisher
<Chipaca> because they're not published :-)
<davidcalle> Chipaca: yeah, but snap info picked up channel data from the store snap :)
<Chipaca> yeah
<davidcalle> Hence, the confusion
<Chipaca> davidcalle: suggestions for making this difference clearer very much accepted
<davidcalle> Chipaca: what about "tracking: local" when there is no tracking info available, hence not in the store ?
<Chipaca> that kinda makes sense :-)
<Chipaca> niemeyer: what do you think?
<niemeyer> It's not actually tracking local.. it's not really tracking anything since it won't ever update without manual action
<niemeyer> Chipaca: Given the above picture, the magic dash seems fitting
<niemeyer> As in, it's what we used to mean "there's nothing there" in the channels
<davidcalle> +1
<Chipaca> niemeyer: consider it done
<Chipaca> and by "it" I obviously mean using âã½( Í¡Í¡ Â° Í Ê Í¡ Â°)âââï¾. * ï½¥ ï½¡ï¾â to signify the above
<mup> PR snapd#3472 closed: interfaces, tests: add mising dbus abstraction to system-observe and extend spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3472>
<Chipaca> niemeyer: hopping subjects again, what needs to happen so shellcheck is available on the linode that runs the static tests? (that's a ubuntu-16.04-64)
<niemeyer> Chipaca: Is that a deb package in the archive?
<Chipaca> niemeyer: yes but not in xenial (we'd need the one from yakkety at least)
<Chipaca> niemeyer: (it's usable directly, if you install the deb in the image directly for example)
<Chipaca> niemeyer: http://mirrors.kernel.org/ubuntu/pool/universe/s/shellcheck/shellcheck_0.4.4-2_amd64.deb
<niemeyer> Chipaca: Okay, so best route is likely to wait for cachio's PR to go in, so he doesn't need to fix that again (it's centralizing all package installs), and then it'll get included in the big image rebundling that I'll need to do for moving those installs out of the suite altogether
<Chipaca> niemeyer: neat
<Chipaca> niemeyer: this will make master fail right now
<Chipaca> because a number of things have crept in
<Chipaca> still, easy to fix once we're there
<Chipaca> some are actual bugs :-/
<mup> PR snapd#3506 opened: asserts: introduce NewDecoderWithTypeMaxBodySize <Created by pedronis> <https://github.com/snapcore/snapd/pull/3506>
<mvo> Chipaca: hey, zyga pointed me to you for this issue https://forum.snapcraft.io/t/edge-beta-revert-fails/1072 - he said you know more about this
<mvo> Chipaca: this will be a blocker for 2.27
 * Chipaca looks
<Chipaca> mvo: I think he confuses "it happened to me a lot and drove me bonkers" with "knows more"
<mvo> Chipaca: lol
<ogra_> ogra@orangepi-zero:~$ snap list
<ogra_> Name                     Version                   Rev   Developer  Notes
<ogra_> core                     16-2.26.4+git245.a96842e  2212  canonical  -
<ogra_> linux-generic-allwinner  4.11.0-7.12               x1               -
<ogra_> orangepi-zero            16-0.1                    x1               -
<ogra_> \o/
<Chipaca> mvo: but i thought he'd fixed this?
<pedronis> I thought it was fixed as well
<mvo> Chipaca: well, he said he did but then he said he did not
 * Chipaca looks at his prs
<Chipaca> mvo: ah
<mvo> Chipaca: he said the wrong snap-update-ns is used, but I'm not fully understanding why, at this point current should still point to the "good" snap-update-ns from edge with his fix
<Chipaca> mvo: in what scenario is "current" the wrong one to use?
<mvo> Chipaca: in my failure scenario I go from edge to beta and edge is supposed to have the latest code but maybe something else is going on, I stumbled over this by accident I really want to test my seccomp-bpf work
<mvo> Chipaca: i.e. the latest code that contains the fix
<mup> PR snapcraft#1316 closed: Run unit tests on Travis with mock armhf <Created by kalikiana> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1316>
<mup> PR snapd#3507 opened: many: backport of seccomp-bpf branch (#3431) to the 2.26 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3507>
<morphis> mvo, pedronis, niemeyer: where does snapd take the CA certificates from? Is it tied with openssl and the ca-certificates database for HTTPS access?
<morphis> and I guess you don't use certificate pinning yet, right?
<ogra_> ogra@localhost:~$ snap list
<ogra_> Name                     Version                   Rev   Developer  Notes
<ogra_> core                     16-2.26.4+git245.a96842e  2212  canonical  -
<ogra_> linux-generic-allwinner  4.11.0-7.12               x1               -
<ogra_> nanopi-neo               16-0.1                    x1               -
<ogra_> and the next one :)
<niemeyer> morphis: I recall a recent change that moved CA lookup into the core snap
<morphis> ah!
<niemeyer> morphis: It's been such a long time since we managed to get a release all the way into stable due to the revert issues being worked on that I don't know if that's there or not
<morphis> niemeyer: I just have somebody who does certificate substituion on a proxy and wonders why things aren't working :-)
<morphis> he claimed to have extended ca-certificates but if it's in the core snap that does help
<niemeyer> morphis: Wait.. certificate substitution on a proxy?
<morphis> don't ask me, a bad idea
<morphis> which will break anyway once we pin the certificates
<niemeyer> Yeah, we should probably do that sooner now that you mention it :)
<morphis> niemeyer: hehe
<Chipaca> pedronis: if you're still there, what content type do you use for "a series of json documents"?
<Chipaca> application/json-seq
<pedronis> Chipaca: we don't  anywhere
<pedronis> atm, afaik
<niemeyer> Yeah, that sounds suspect
<pedronis> we return objects with arrays inside
<pedronis> Chipaca: what had you in mind?
<Chipaca> pedronis: streaming journalctl output
<pedronis> we don't stream json anywhere
<pedronis> atm
<Chipaca> right
<Chipaca> i think we'd looked into this a bit, but probably for long poll or whatever it's called
<Chipaca> niemeyer: suspect how?
<pedronis> Chipaca: ah, we might have done something for u1db but it was fully adhoc I think
<pedronis> with our own mimetype
<mvo> morphis: there is a PR that needs to be resurrected for cert pinning https://github.com/snapcore/snapd/pull/2316 - its mostly about how we distribute the cert updates at this point, probably via assertions but we need to flesh out details
<mup> PR snapd#2316: store: add basic certificate pinning <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2316>
<ogra_> erm
<ogra_> ogra@nanopi-neo:~$ ps ax|grep user
<ogra_>  1742 ?        Ss     0:00 /lib/systemd/systemd --user
<ogra_> we do spawn a --user session on core ?
 * ogra_ wonders why
<mup> PR snapd#3508 opened: tests: shellcheck improvementes for lib scripts <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3508>
 * ogra_ glares at https://forum.snapcraft.io/t/certificate-substitution-and-snaps/1077 ... 
<ogra_> i suspect we'd need the ability to add certificates to the core snap dynamically
<pedronis> mvo: also wgrant had a counter proposal on that
<pedronis> at the last sprint
<niemeyer> pedronis: mvo isn't here
<niemeyer> Chipaca: It was just a dumb gut feeling which I shouldn't have mentioned.. it probably makes sense to do that if you want to stream logs
<Chipaca> niemeyer: i agree it's weird and strange and i'm not super enamoured with it
<Chipaca> niemeyer: but streaming json leaves few options
<Chipaca> so, yeah
<mup> PR snapcraft#1374 opened: tests: set up the spread execution in linode <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1374>
<niemeyer> Chipaca: Yeah, I think it's nice.. it means we can have more interesting semantics through that pipeline
<niemeyer> Chipaca: We just need to be a bit careful to establish a nice pattern that can be reused for other cases soon
<niemeyer> But it's worth going over it
<Chipaca> semantics, schmemantics, i want icecream
<Chipaca> :-)
<Chipaca> but, yes. consciously not working on it now though (hadn't realised my irc was still connected)
<niemeyer> Chipaca: It wasn't until recently :)
<mup> PR snapd#3435 closed: interfaces: add password-manager-service implicit interface <Created by mvo5> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3435>
<cachio> Chipaca, are you able to rerun the failed autopkgtest on there? https://github.com/snapcore/snapd/pull/3494
<mup> PR snapd#3494: tests: restart rng-tools services after few seconds <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3494>
<mup> PR snapd#3494 closed: tests: restart rng-tools services after few seconds <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3494>
<mup> PR snapd#3509 opened: tests: shellcheck improvements for tests/nested tasks <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3509>
<mup> PR snapd#3510 opened: tests: shellcheck improvements for nightly upgrade and regressions tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3510>
#snappy 2017-06-22
<mup> PR snapd#3511 opened: tests: shellcheck improvements for unit and completion tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3511>
<mup> PR snapcraft#1375 opened: tests: allow to filter tests in docker <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1375>
<ppisati> guys, is there a way to use a ppa in snapcraft?
<Chipaca> ppisati: https://forum.snapcraft.io/t/how-to-add-a-custom-ppa-to-snapcraft/266/4
<Chipaca> ppisati: short version: no
<Chipaca> ppisati: longer version: mmmm... no
<Chipaca> :-p
 * ppisati cries in a corner...
<mvo> Chipaca: fwiw, I think I found the issue with the cannot update namespace error we talked about yesterday
<mvo> Chipaca: I think the hardest part is fixing the tests :/
<mvo> Chipaca: anyway, I'm on it
<mvo> I think
 * Chipaca hugs mvo
 * Chipaca hugs ppisati too
 * Chipaca goes back to beating streaming json chunks into submission
<mvo> Chipaca: enjoy ! sounds like more fun than fighting tests
<mvo> in the heat
<Chipaca> I cannot confirm nor deny
<Chipaca> it's actually cooler today
<mvo> Chipaca: ha! lawyer?
<Chipaca> overcast
<Chipaca> mvo: :-) (also: no)
<mvo> Chipaca: lucky you, its blazing hot here, hottest day of the year according to the forecast
<pstolowski> fgimenez, hey, any idea about 'jq command not found' error on travis? afaict we always install this as a dependency?
<fgimenez> pstolowski: nope, do you have a link?
<pstolowski> fgimenez, https://travis-ci.org/snapcore/snapd/builds/244895313?utm_source=github_status&utm_medium=notification
<fgimenez> pstolowski: it failed on ubuntu-core, you need to install the snap for it to work there, as in https://github.com/snapcore/snapd/blob/master/tests/main/auto-refresh/task.yaml#L4
<pstolowski> fgimenez, ah, thank you. let me try that
<mup> PR snapd#3512 opened: cmd: rework how cmd.InternalToolPath() works to ensure the right tool is used <Created by mvo5> <https://github.com/snapcore/snapd/pull/3512>
 * Chipaca throws hands up in despair
<Chipaca> mvo: it was going to be the hottest day, but then it changed its mind
<Chipaca> it went with option B, thunderstorm
 * pedronis early lunch + errands
 * Chipaca wishes he could select on a reader and a writer
<mvo> Chipaca: when you had the issues with snap-update-ns, did you had a reliable way to reproduce?
<mvo> Chipaca: or was it happening at random for you? in manual testing or in spread as well?
<Chipaca> mvo: not in spread
<Chipaca> mvo: it'd happen when running snapd from master without installing all the bits from master, some of the time
<Chipaca> mvo:
<Chipaca> 017-05-24 12:02:59 <Chipaca>   - Remove security profile for snap "http" (x1) (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserve
<Chipaca> d namespace of snap "core": cannot update snap namespace: not implemented)
<Chipaca> 2017-05-24 12:03:22 <zyga>      Chipaca: you are using snapd from master but the rest from package
<Chipaca> 2017-05-24 12:03:31 <zyga>      Chipaca: just buind and install snap-update-ns
<Chipaca> 2017-05-24 12:03:35 <Chipaca>   ah ok
<mvo> Chipaca: ta
 * Chipaca gives up and goes for lunch
<mup> PR snapd#3513 opened: asserts: open up and optimize Encoder to help avoiding unnecessary copying <Created by pedronis> <https://github.com/snapcore/snapd/pull/3513>
<pedronis> it seems either there's a codecov bug or there's some code with non determinstic tests resulting in non-deterministic coverage
<pedronis> I see coverage of interfaces/sorting.go for example going up and them depending on runs
<pedronis> s/and them/and down/
<mvo> jdstrand: niemeyer suggests "seccomp/bpf/*.src for the source files and "seccomp/bpf/*.bin"  for the binary files in the seccomp-bpf review. if you are happy with this as well, I will make it so. WDYT?
<Chipaca> pedronis: standup?
<niemeyer> mvo: Can you quickly jump back in the hangout for us to cover a detail in the bpf pr?
<mvo> niemeyer: sure, joining
<jdstrand> mvo: I commented in the pr a moment ago
<jdstrand> mvo: https://github.com/snapcore/snapd/pull/3431#discussion_r123503280
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<popey> morphis: do you know when the migration of snap-xdg-open will land? I have an app which depends on external links which breaks on non-ubuntu
<morphis> popey: I would guess 2.28
<niemeyer> jdstrand, mvo: Replied the reply
<niemeyer> IRC-as-a-notification-service
<niemeyer> IaaNS
<jdstrand> mvo: that said, I didn't think that EnsureDirState() would be cool with a dir in there, but I see the seccomp code passes a glob that does not match 'bpf', so seems ok
<jdstrand> hehe
<mvo> jdstrand, niemeyer: so it would be /var/lib/snapd/seccomp/bpf/*.{src,bin}  (AIUI the original suggestion in https://github.com/snapcore/snapd/pull/3431#discussion_r123396337) *or* /var/lib/snapd/seccomp/profiles/bpf/*.{src,bin} ?
<mup> PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<niemeyer> mvo: The former, /bpf/*.src/bin
<niemeyer> Argh
<niemeyer> .../bpf/*.{src,bin} :)
<mvo> niemeyer: thanks
 * mvo will make it so
<niemeyer> mvo: Otherwise you'd have to invent a new mechanism to not remove the old files
<niemeyer> (as EnsureDirState takes on a single glob)
<mvo> niemeyer: yes, was wondering about this too, I'm happy that we are in agreement)
<popey> morphis: do you know when 2.28 will be released?
<zyga> o/
<morphis> popey: nope
<zyga> o/
 * zyga waves everyone good-bye from Spain
<zyga> see you in Poland on Friday morning
<morphis> zyga: safe trip!
<zyga> morphis: sorry for being absent earlier, I forgot to notify you that I'm moving
<morphis> zyga: np
<zyga> morphis: thank you :)
<morphis> popey: PR is still pending https://github.com/snapcore/snapd/pull/3260
<mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<popey> morphis: ok, this is blocking a developer we've been talking to for some weeks now. :(
<morphis> popey: I see
<morphis> popey: does his snap work otherwise on other distros?
<zyga> niemeyer, mvo, Chipaca, pedronis, fgimenez, pstolowski, cachio: see you all on Friday!!!
<Chipaca> zyga: o/~
<niemeyer> zyga: Have a great trip, and good luck with the move!
 * zyga will miss spain a lot
<popey> morphis: mostly, yes. xdg-open is the final thing blocking AIUI
<cachio> zyga, enjoy it :)
<zyga> niemeyer: thank you, I hope to land at home safely late after midnight
<pstolowski> zyga, o/
<niemeyer> morphis, popey: Will look into this today still
<zyga> niemeyer: see you at the snandup tomorrow
<niemeyer> zyga: o/
<popey> it's a mail client, so it needs to do things like open file attachments
<popey> thanks niemeyer
<morphis> niemeyer: a code review would be nice but I need to a fix a few last things
<niemeyer> morphis: Ah, okay, please ping me once you feel like it's ready then
<fgimenez> zyga: enjoy and good luck! safe travels, see you soon
<cachio> mvo, do you have the link to the snap-notify error?
<mvo> cachio: yes, sorry, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170622_120316_4e91a@/log.gz
<cachio> mvo, tx
<mvo> cachio: I'm not sure how widespread this actually is, I think I saw it twice recently
<cachio> ok, failing on yakkety
<cachio> mvo, I'll take a look
<cachio> mvo, which yakkety image do you use for the autopkgtests?
<mvo> cachio: it comes from the machinery we use in autopkgtest, afaik it is created via buildvm-ubuntu-cloud
<cachio> mvo, ok, tx
<fgimenez> cachio: here are some details about how to generate images for different releases  and use them with the qemu backend https://github.com/snapcore/snapd/blob/master/HACKING.md#running-the-spread-tests
<cachio> fgimenez, nice
<cachio> thanks for the ingo
<cachio> info
<mup> PR snapd#3514 opened: wrappers: add SyslogIdentifier to the service unit files <Created by chipaca> <https://github.com/snapcore/snapd/pull/3514>
<mvo> jdstrand: if you could have a look at the last few commits for seccomp-bpf, especially    	02a6d3f - that would be great. tests are still running but locally spread is almost finished (183/190) and happy so far
<mvo> jdstrand: I also updated the snap-confine.rst a bit more to better reflect what its doing
<jdstrand> mvo: sure
<mvo> jdstrand: thanks for your comment, I don't have a strong opinion either
<jdstrand> mvo: +1
<mvo> fgimenez, cachio: do you have an idea why https://travis-ci.org/snapcore/snapd/builds/245474489?utm_source=github_status&utm_medium=notification fails? this is the seccomp-bpf-2.26 branch, it fails with some shellcheck errors, did we change something there recently?
<mvo> jdstrand: \o/
<fgimenez> mvo: no idea sorry, looking
<mvo> fgimenez: thank you, maybe I just need to disable shellcheck for this particular file, slightly strange but I can also dig
<fgimenez> mvo: there are a few PRs by cachio related to shellcheck up https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aopen%20shellcheck but nothing seems to have landed lately https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Aclosed%20shellcheck
<mvo> fgimenez: thanks, I see what I can figure out
<pedronis> mvo: we weren't running shellcheck at all IÂ think until recently
<gouchi> hi
<gouchi> where is the source for ubuntu core for creating the db410c image ?
<niemeyer> fginther: Didn't we move the static checks into a spread task as well?
<niemeyer> fginther: Sorry, bad tab completion on the nick
<gouchi> it should be here https://code.launchpad.net/~ubuntu-core-dev ?
<nacc> gouchi: that's the code page for the ubuntu core dev team
<nacc> gouchi: unrelated to 'ubuntu core'
<nacc> gouchi: confusingly :)
<gouchi> ah ok :)
<cachio> mvo, about the error in the test snappy-notify
<cachio> it is failinf bacasue for some reason sometimes is taking more time to start the service
<cachio> mvo, in the test that failed here, it tool 3 seconds from the "restart into" until it was ready
<cachio> mvo, we could retry during 5 seconds instead of make a single check
<cachio> mvo, what do you think?
<mvo> cachio: sounds good
<mvo> cachio: thanks for investigating!
<cachio> mvo, np
<pedronis> are spread tests on linode broken atm? it seems they cannot get any machines
<cachio> pedronis, seem to be broken
<cachio> I cant run neither
<cachio> Discarding linode:ubuntu-16.04-64 (Spread-33), cannot connect: cannot connect to linode:ubuntu-16.04-64 (Spread-33): ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain
<cachio> pedronis, do you see that error?
<pedronis> yes
<cachio> niemeyer, any idea?
<mup> PR snapd#3515 opened: tests: fix snapd-notify when it takes more time to restart <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3515>
<kyrofa> niemeyer, can I have the power to make a forum post a wiki?
<kyrofa> Or would you prefer that we ask?
<niemeyer> kyrofa: Done.. as a general recommendation, wiki posts are generally not phrased in personal terms, otherwise even being a wiki people will end up not touching them
<niemeyer> cachio: Yeah, on it already
<niemeyer> cachio: Linode is broken
<niemeyer> cachio: Their support is looking into the issue
<kyrofa> niemeyer, thanks
<cachio> niemeyer, thanks
<niemeyer> mvo: I don't have news from Linode itself, but retrying seems to have worked now
<niemeyer> https://travis-ci.org/snapcore/snapd/jobs/245873418
<mvo> niemeyer: nice
<mup> PR snapd#3516 opened: asserts: implement FindManyTrusted as well <Created by pedronis> <https://github.com/snapcore/snapd/pull/3516>
<mup> PR snapd#3431 closed: interfaces: simplify snap-confine by just loading pre-generated bpf code <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3431>
<mup> PR snapcraft#1350 closed: rust plugin: Add support for cross-compilation <Created by kalikiana> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1350>
<madprops> Hi
<madprops> I have a question
<madprops> What happens when applications installed through snappy, like Telegram, have automatic updates?
<madprops> Their own updater
<madprops> Does it update, and then snappy tries to update it again?
<kyrofa> madprops, it probably depends on how the updater is written. Snaps are read-only, so they won't be able to self-update in place, for example
<madprops> So it brakes all autoupdates
<madprops> autoupdaters*
<madprops> breaks*
<madprops> something doesn't feel right about that
<madprops> unless linux versions by convention don't come with autoupdaters
<kyrofa> madprops, how would it work if one were to install telegram from, say, a deb?
<madprops> Well I'm not sure but, I can tell you that in Windows I just install an exe, and autoupdaters work, they ask you for admin permissions to upgrade
<madprops> It would be cool if snaps become like exes
<madprops> big applications have autoupdaters ... and the other ones you just upgrade when needed (downloading a new exe)
<kyrofa> madprops, the idea is to bring that auto-update goodness to everyone, not just those who create the infrastructure for it
<madprops> yes that's nice too
<madprops> something that surprised me though
<madprops> was there there seemed to be no way to disable autoupdates, just select "good hours" to update
<madprops> very windowslike
<kyrofa> Yeah I'm not sure why that is either, honestly
<niemeyer> If you open a forum topic I'm happy to provide details
<kyrofa> Perhaps this is the thread to read: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707
<mup> PR snapd#3513 closed: asserts: open up and optimize Encoder to help avoiding unnecessary copying <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3513>
<niemeyer> kyrofa: Nice, it's even there already :)
<niemeyer> forum++
<kyrofa> niemeyer, here's a nuanced version: https://forum.snapcraft.io/t/delaying-snap-refreshes-programatically/1085
<mup> PR snapcraft#1345 closed: deltas: Improved message returned when delta is too big <Created by gsilvapt> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1345>
<mup> PR snapcraft#1366 closed: cli: Add --version command <Created by sparkiegeek> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1366>
#snappy 2017-06-23
<mup> PR snapcraft#1367 closed: catkin plugin: add support for ROS Lunar <Created by kyrofa> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1367>
<mup> PR snapcraft#1332 closed: cli: provide a whoami command <Created by sergiusens> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1332>
<mup> PR snapcraft#1363 closed: tests: use pyramid as a router for the fake servers <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1363>
<mup> PR snapd#3517 opened: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>
<fgimenez> good morning mvo, i'm already running the core-revert stable -> edge -> stable test but it seems to get stuck after the first refresh, this will be addressed by snapd#3517, is that correct?
<mup> PR snapd#3517: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <https://github.com/snapcore/snapd/pull/3517>
<fgimenez> mvo: the error i get is "Jun 23 07:15:00 localhost snap[1685]: cannot open cookie file /var/lib/snapd/cookie/snap.network-managercannot stat /var/lib/snapd/seccomp/bpf/snap.network-manager.networkmanager.bin: No such file or directory"
<fgimenez> mvo: fwiw we got a new edge core built from the edge ppa this morning, maybe there are bits in there that shouldn't be part of 2.26.last
<mvo> fgimenez: thank you, I was able to reproduce, the cookie error is a red herring, the real issue is that we have a race, I think #3517 will fix it
<fgimenez> mvo: great thank you, let me know if i can be of any help
<mvo> fgimenez: no worries, I just need reviews
 * zyga waves from Poland
<mvo> zyga: welcome home!
<zyga> mvo: hey, thank you :)
<zyga> how are things?
<zyga> I'm pretty sleepy but eager to wake up, the plane was delayed by two hours and departed after midnight...
<zyga> but it's all behind us now, the day awaits
<mup> PR snapd#3516 closed: asserts: implement FindManyTrusted as well <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3516>
<mvo> zyga: things are good
<mvo> zyga: if you want to review stuff, 3517 might be an interessting one
<zyga> yes, I think that's a good use of my time today
<mvo> zyga: 3512 as well
<mvo> zyga: I think I will merge the shellcheck ones with a single reivew only, those are pretty mechanical and tests ar efine
<mvo> zyga: 3514 is an easy win
<zyga> mvo: am I reading 3512 right that it will re-exec tools on distros that don't reexec?
<zyga> mvo: I think this is very undesirable and will break if used today
<mup> PR snapd#3511 closed: tests: shellcheck improvements for unit tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3511>
<mvo> zyga: unless I made a mistake it should not do this. it will look at the running snapd, if that is re-execed it will use the reexecd path
<zyga> mvo: ah, ok, let me read that in detail
<zyga> mvo: but that should be good
<mup> PR snapd#3514 closed: wrappers: add SyslogIdentifier to the service unit files <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3514>
<pstolowski> zyga, hey! :)
<mvo> zyga: the code could actually be even simpler, it could just always use $dirname("/proc/self/exe")+tool-name
<pstolowski> fgimenez, ping
<mvo> zyga: but I think that would break some tests so the way its written now should be ok
<zyga> pstolowski: hey :)
<zyga> mvo: mmmm, indeed
<fgimenez> hey pstolowski and zyga :)
<zyga> hey fgimenez :)
<zyga> mvo: nice way to solve the current symlink issue btw
<pstolowski> fgimenez, hey, advice needed
<fgimenez> zyga: how was your trip?
<mup> PR snapd#3509 closed: tests: shellcheck improvements for tests/nested tasks <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3509>
<mvo> zyga: thank you!
<fgimenez> pstolowski: sure, how can i help?
<pstolowski> fgimenez, i'd like to create a spread test for revert-hook that I implemented; looking at our revert spread test, we use test-snapd-tools from the store and then switch to the fake store to simulate refresh, so that we can revert. but for my test I need a new custom snap with revert hook inside
<pstolowski> fgimenez, so question is, how to do that with minimum hassle
<zyga> fgimenez: exhausting, the trafic on costa brava was very heavy in anticipation of the holidays
<zyga> fgimenez: the plane was delayed because of thunderstorms in France
<zyga> fgimenez: plus lots of stress with packing everything on the very last moment
<zyga> fgimenez: but it's all over now so that's all behind me :)
<fgimenez> pstolowski: we have been creating the test snaps required by specific tests and, when needed, uploading them to the store under the shared account, i think in this case that should be the right thing to do
<pstolowski> fgimenez, sounds good. I think it would be fine to add this new hook to test-snapd-tools; this hook will be a simple one liner that e.g. drops a file somewhere so I can verify it was run. what do you think?
<fgimenez> zyga: that's the spirit! :) happy to hear that all went well after all, also tonight is "noche de san juan", good moment to burn the old and embrace new things :)
<pstolowski> fgimenez, btw, i'm going to Spain for my vacation in ~3 weeks, reportedly close to where zyga lived ;)
 * zyga stops reviews for a moment and goes to make coffee
<fgimenez> pstolowski: it's a very beautiful place, you'll enjoy for sure :)
<pstolowski> fgimenez, :)
<fgimenez> pstolowski: about test-snapd-tools i'd personally prefer to have an specific snap for this test, something like test-snapd-with-configure, test-snapd-with-revert in this case, so that the purpose of each one is clear
<niemeyer> Heya
<pstolowski> fgimenez, ok, fine by me
<pstolowski> niemeyer, hey!
<pstolowski> fgimenez, do we use our tests/lib/snaps/ as a source for building these snaps for the real store?
<niemeyer> zyga: Happy to hear the move went fine, despite the unavoidable stress it entails :)
<zyga> niemeyer: hey!
<zyga> niemeyer: yes, it's all good now
<zyga> niemeyer: kids are running around the place re-discoveing early childhood items
<mvo> zyga: 3464 probably needs a merge of master to make spread work
<oSoMoN> what happens when a snap previously published in the store with strict confinement gets an update that declares classic confinement? will the update be applied silently?
<ppisati> 'Snap 'ubuntu-core' for 'powerpc' cannot be found in the 'edge' channel.'
<ppisati> we have a ppc64el ubuntu-core but no powerpc? how come?
<mvo> zyga: a quick look at 3517 would be great, then I can (hopefully) merge and get a new core over lunch for the nested tests
<zyga> mvo: ack, looking
<zyga> mvo: I have spotty network here, I need to fix it (after the sprint) so don't feel discouraged if I dissapear for a moment
<niemeyer> zyga: Lots of nostalgia :)
<niemeyer> mvo: Just trivials on snapd#3512
<mup> PR snapd#3512: cmd: avoid using current symlink in InternalToolPath <Created by mvo5> <https://github.com/snapcore/snapd/pull/3512>
<mvo> niemeyer: nice, thank you
<mvo> ppisati: I think we don't have powerpc because we can not (or could not back then) build snaps for powerpc
<niemeyer> mvo: np, review queue looks quite nice today actually :)
<niemeyer> fgimenez: Didn't we decide to drop the static tests from within Travis?
<niemeyer> mvo, fgimenez: Btw, any more issues on Linode?
<niemeyer> It's sort of amazing that we managed to have a bug on our end and a bug on their end on the same week
<mvo> niemeyer: linode was fine for me in the last few hours
<mvo> (including last night)
<niemeyer> mvo: Phew
<fgimenez> niemeyer: afaik they are moved to a spread task let me check
<niemeyer> fgimenez: That's what I thought as well, but looking through logs recently they seemed to be back
<fgimenez> niemeyer: i've seen some authentication errors like "ssh error 2017-06-22 16:39:58 Discarding linode:debian-unstable-64 (Spread-04), cannot connect: cannot connect to linode:debian-unstable-64 (Spread-04): ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain"
<mvo> niemeyer: indeed :)
<zyga> mvo: two nitpicks on 3517
<niemeyer> fgimenez: Ok, but that's from yesterday.. there was a real bug on the Linode side this time around
<niemeyer> fgimenez: They fixed it late yesterday
<mvo> sure, I will reply inline, thanks a bunch
<fgimenez> niemeyer: great, about the static checks they are currently run here https://github.com/snapcore/snapd/blob/master/tests/unit/go/task.yaml#L17
<mvo> zyga: atoi(getenv("not-exist")) will segfault :) atoi crashes when oyu feed it a NULL
<fgimenez> niemeyer: and travis only runs spread https://github.com/snapcore/snapd/blob/master/.travis.yml#L22
<zyga> mvo: I meant under the first if
<zyga> mvo: just on the line I commented
<niemeyer> fgimenez: Okay, it must have been some old code that hasn't merged back from master in a while then
<niemeyer> fgimenez: Thanks for checking
<zyga> mvo: or just use variables and be less fancy, I wanted to avoid the repeated getenv and atoi
<mvo> zyga: aha, ok
<mvo> zyga: I'm inclinded to merge and do a followup mostly to avoid waiting for the tests again, is that ok with you?
<mvo> zyga: i.e. when I return from lunch I want to have a new core snap :)
<zyga> mvo: certainly, I can follow up as well if you want
<zyga> mvo: small bite for the troubled voyager
<mvo> zyga: sure, even better
<fgimenez> niemeyer: np, thank you, another weird error from linode this morning "cannot boot linode:ubuntu-16.04-32 (Spread-50): linode disk /dev/sda not ready to boot. Please contact support." https://travis-ci.org/snapcore/spread-cron/builds/246018927#L669
<mup> PR snapd#3517 closed: snap-confine: ensure snap-confine waits some seconds for seccomp security profilese <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3517>
<niemeyer> FFS
<niemeyer> fgimenez: This is the CI infra bug week
<fgimenez> niemeyer: :) and the ssh issue seems to be still around, this build has it and is currently running https://travis-ci.org/snapcore/snapd/builds/246132571#L908
<zyga> niemeyer: about that, did you see those scaleway 128GB ram 64 core VMs that are on sale now?
<zyga> niemeyer: I wonder if we could get really solid arm server spread tests this way
<niemeyer> fgimenez: Thanks, will look into the console to see if it's the same issue and reopen the ticket
<zyga> niemeyer: not pi-like tests, just serious arm server snapd
<niemeyer> zyga: The problem with arm is that in general we want to test the actual device
<zyga> niemeyer: it _is_ the actual device, this is not the old arm but the new big-iron arm that is not device specific
<niemeyer> zyga: That's why those magic SD muxes are so interesting
<zyga> niemeyer: modern x86_64 server
<zyga> niemeyer: just with arm now :)
<niemeyer> zyga: Sorry, I don't get the point
<zyga> niemeyer: we test x86 extensively in VMs
<zyga> niemeyer: and we test arm on hardware (IOT devices)
<niemeyer> zyga: Do you mean this 128GB RAM and 64 core server is actually a Raspberry Pi behind the scenes?
<niemeyer> :P
<zyga> niemeyer: but we don't have any automated ARM tests like we do for x86 because we don't have arm server hardware (with virtualization and everything)
<zyga> niemeyer: I'm saying we could run the very same suite of tests we use on x86 VMs on that arm system for better coverage
<niemeyer> zyga: Yeah, and that's what I meant above
<zyga> plus, it's beefy and on sale
<zyga> niemeyer: arm is not just the pi's
<niemeyer> zyga: The problem is that this doesn't really solve the question of whether the supported devices are broken or not
<zyga> niemeyer: yes and I'm not saying it does
<niemeyer> zyga: Yes, it's one more testing platform, that will need custom kernels, custom gadgets, custom everything
<zyga> niemeyer: no, no custom kernels
<niemeyer> zyga: Unless someone is working with us to support that, we can't just add more platforms
<zyga> niemeyer: arm servers use one kernel
<zyga> niemeyer: all acpi and standards based like x86 servers
<niemeyer> zyga: That hasn't been my experience with anything arm
<zyga> niemeyer: because you deal with non server hardware
<niemeyer> zyga: Ok, so which of our kernels will this use?
<zyga> niemeyer: stock ubuntu kernel for aarch64
 * zyga has to fix his wifi, signal dropping every few seconds
 * zyga -> brb
<niemeyer> zyga: Okay, so classic Ubuntu rather than Ubuntu Core
<zyga> niemeyer: yes, I'd start with that
 * Chipaca ~> lunch
<zyga> mvo: https://github.com/snapcore/snapd/pull/3518
<mup> PR snapd#3518: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
<mup> PR snapd#3518 opened: cmd/snap-confine: various small fixes and tweaks to seccomp support code <Created by zyga> <https://github.com/snapcore/snapd/pull/3518>
<mvo> zyga: ta
<Vamsi> Hi. I had previously asked about a web app store for snaps. And I was suggested to use snapweb. I am facing a problem with snapweb though. I am able access my Ubuntu desktop using the web app store on a browser on the same PC. But I am unable to access my raspbery pi (running on ubuntu core) from the browser on the PC :|
<mup> PR snapd#3519 opened: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3519>
<Vamsi> Also if it helps, both the PC and the pi are on the same network.
<zyga> Vamsi: what kind of error are you seeing?
<zyga> mvo: +1
<zyga> mvo: consider merging my branch too if we lost that slot anyway
<mvo> zyga: ta
<Vamsi> zyga: the browser says that the accsess token is invalid.
<zyga> Vamsi: I see
<zyga> unfortunately I don't know much about snapweb internals
<Vamsi> but it accepts the access token from the PC though.
 * Chipaca ~> really lunch
 * zyga knows the feeling very well Chipaca  :)
<zyga> mvo: reviewed 3512
<zyga> mvo: let me know if you want me to change that
<zyga> mvo: otherwise I'll work on base updates
<mup> PR snapd#3520 opened: asserts: add enterprise-store assertion type <Created by atomatt> <https://github.com/snapcore/snapd/pull/3520>
 * zyga focuses on base snaps
<niemeyer> fgimenez: "In this case there was a problem with how the host was reserving disk space while creating new disks. However, one of our administrators was able to fix the problem, and it shouldn't occur again in the future."
<fgimenez> niemeyer: \o/ ? not sure if that souds really well :)
<niemeyer> fgimenez: I think it's fine :)
<niemeyer> Yesterday the response was "The previous message yesterday was "It looks like this one was a fluke. I've been able to thaw out the same image on your Linode just fine. Please let us know if it happens again and we'll be glad to look into it further."
<jacekn> hello. Is https://bugs.launchpad.net/snapd/+bugs the right place for snapd bugs? I filed one yesterday but nobody was subscribed to it and it's still in "New" state
<niemeyer> Which is less fine :)
<niemeyer> jacekn: If you want quick feedback, the forum is the best place to report issues and discuss them
<jacekn> niemeyer: ack. In this case it looks like a bug so I reported it. It's not super critical
<jacekn> niemeyer: but is https://bugs.launchpad.net/snapd/+bugs the right place or there is somewhere else I should be reporting bugs?
<niemeyer> jacekn: If it's about snapd, that's the right place
<jacekn> great, thanks for confirmation
<niemeyer> np
<jacekn> niemeyer: that location looks dead BTW, there are many old bugs that were not even triaged
<niemeyer> jacekn: I really mean it when I said the forum is the place to discuss and get quick feedback
<jacekn> niemeyer: as in you prefer people to open forum threads about bugs rather than file them in LP?
<niemeyer> jacekn: As in that's where all the daily activities happen, and that's where we discuss issues most frequently.. if you file a bug in Launchpad, it's tracked and will be eventually looked at, but there are many more eyes in the forum every single day
<niemeyer> jacekn: If you want to talk about the bug today, please open a forum thread
<mup> PR snapcraft#1376 opened: options: fix s390 kernel arch <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1376>
<ogra_> ppisati, wow, do we ever exect to support s390 UbuntuCore installs ?
<ogra_> expect
 * ogra_ thinks s390x and ppc64el should simply not be built by the plugin by default ... it is unlikely that anyone will ever actually boot UbuntuCore on such systems
<ogra_> (kernels that is)
<jacekn> niemeyer: thanks for explaining. I don't want/need to talk about the bug, totally happy to wait. I wanted to make sure that LP bug tracking was not dead (because that's what it may look to people without context abotu forums)
<mup> PR snapcraft#1377 opened: kernel plugin: add default targets per powerpc, ppc64el and s390x <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1377>
<xnox> ogra_, our contracts says different =)
<ogra_> xnox, you mean there will be people booting off an UbuntuCore image natively ?
<xnox> ogra_, and core is very much usable in kvm / openstack on both s390x and ppc64el.
<xnox> ogra_, yes.
<ogra_> wow
<niemeyer> jacekn: It's not dead, but it's not well maintained today either, as you've noticed. That's something we need to fix.
 * ogra_ notes that he just triaged two snapd bgs that were filed today ... definitely not dead, just not moving super fast since many issues are resolved in forum discussions before even becoming actual bugs
<Chipaca> pedronis: question about aliases: in the json you get from the store, is the 'target' the name of the app?
<pedronis> Chipaca: which json?
<Chipaca> pedronis: ah, maybe this doesn't come to you as json yet
<Chipaca> but in the declaration itself i guess?
<pedronis> Chipaca: it's in the assertion
<pedronis> is not json
<Chipaca> that'd explain why a quick search didn't find me the json bits of this :-)
<Chipaca> pedronis: ok. I'll be getting a list of aliases from the store, in json
<pedronis> ok
<Chipaca> pedronis: [{"name": "foo", "target": "bar"}, ...]
<pedronis> but that's unrelated to how we do aliases
<pedronis> for actually installed snaps
<pedronis> those comes from the signed snap-declaration
<Chipaca> pedronis: right, this is for command-not-found, ie for non-installed snaps
<pedronis> I know nothing about that (atm)
<Chipaca> ok
<pedronis> but yes, internall we keep things as name, taget
<pedronis> I mean in the internally in the store
<Chipaca> pedronis: and target is the app name?
<pedronis> yes
<Chipaca> ok
<pedronis> it's a plain app name
<pedronis> not snap.app
<Chipaca> just double-checking with nessita_ that things are sane :-)
<Chipaca> that's fine, it'll be "inside" a snap
<Chipaca> {"package_name": "some-snap", "aliases": [...]}
<Chipaca> so i'll know the snap :-)
<mvo> fgimenez: yay, good news. the nested core-revert test seems to be working now with current edge
<fgimenez> mvo: \o/ wonderful news!!! congrats for all the hard work
<fgimenez> mvo: shall i start with the full validation?
<mvo> fgimenez: some smoke testing for edge with the core revert would be great, or just an independant re-run, I need to get this all backported to 2.26, then we can do te real validation
<fgimenez> mvo: sure, i have the core revert already running locally, in fact it was started automatically too by spreadcron when the new core was detected but  it was killed because of the time restriction https://travis-ci.org/snapcore/spread-cron/builds/246175108
<fgimenez> i'll run some additional smoke tests
<fgimenez> cachio: we are still getting create-key timeout errors, have all the fixes landed? https://travis-ci.org/snapcore/spread-cron/builds/246175157
<cachio> fgimenez, ouch
<cachio> fgimenez, it is failing to restart the service
<cachio> fgimenez, the manual was working better than the automatic restart
<cachio> did you merge your branch with the latest changes in master?
<cachio> fgimenez,
<fgimenez> cachio: yes, this is executed from the current master
<fgimenez> cachio: https://github.com/snapcore/spread-cron/blob/snapd-core-i386-edge/run-checks
<cachio> fgimenez, ok, thanks for the info, I'll research more
<fgimenez> cachio: ok thx
<jdstrand> mvo: nice speed improvement in https://github.com/snapcore/snapd/pull/3502. Thanks for doing that PR (fyi, I commented)
<mup> PR snapd#3502: snap-seccomp: add more tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3502>
<zyga> jdstrand: hey
<zyga> jdstrand: greetings from Poland :)
<jdstrand> zyga: hi! :) nice to be back?
<zyga> jdstrand: it's a big change in our lives, not sure yet :)
<jdstrand> mvo: I also notice https://github.com/snapcore/snapd/pull/3504 isn't committed yet. isn't it needed to truly test the revert regression that the bpf fixes?
<mup> PR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>
<zyga> jdstrand: thank you for the review on the cleanup, I'll follow up shortly
<jdstrand> zyga: oh, permanently? wow
<jdstrand> zyga: thanks you for doing it :)
<zyga> jdstrand: yes, all our stuff is packed into ~60 boxes now
<zyga> jdstrand: (most haven't arrived yet)
<jdstrand> some quick example code went through as is and then I missed the NULL checks :\ that's why we have more than one reviewer! :)
<zyga> jdstrand: yep, it's always possible to miss something
<zyga> jdstrand: but I'm very happy with the changes towards precompiled bpf
<jdstrand> zyga: does this mean you will attend (in part or in whole) the Warsaw sprint?
<zyga> jdstrand: it's going to be safer and faster
<zyga> jdstrand: I plan to but I didn't talk to JamieBennett about it yet
<zyga> jdstrand: if anything I'll drop by to get a coffee and say hi :)
<jdstrand> zyga: if you do, we can visit (I'll be there)
<fgimenez> mvo: core-revert succeeded with the edge core snap \o/ I'm currently generating images for running the full suite on them, will keep you posted
<zyga> jdstrand: I'd never miss the only sprint in warsaw :)
<jdstrand> hehe :)
<zyga> jdstrand: that's great to hear :-) I'll show you around Warsaw (except I need to catch up after 6 years of living in Spain)
<jdstrand> fgimenez: note my above question to mvo re https://github.com/snapcore/snapd/pull/3504
<mup> PR snapd#3504: interfaces: bring back seccomp argument filtering <Created by mvo5> <https://github.com/snapcore/snapd/pull/3504>
<fgimenez> jdstrand: aha thanks, good to know, all seems to be working fine now fwiw, anyway will keep running it in a loop to try to catch racy results
<jdstrand> fgimenez: I guess there was the netlink revert failure that never had the policy reverted. I don't know if you are testing that snap, but if you are, then that PR isn't strictly needed to demonstrate the fix
<mvo> jdstrand: hey, thanks for the review of 3502. re 3504 - our test also failed without the reverts, but I agreee, we should do the test with that one merged too. we had a failure with bluez that hit exactly the same issue so I'm quite confident that the fix is there. but then, I'm much in favour of double checking :)
<mvo> jdstrand: it needs a second review, then it can go in
<jdstrand> mvo: yeah, I just remembered netlink wasn't reverted
<fgimenez> jdstrand: exactly, the test includes bluez, which was failing after revert with "hsearch_r failed for NETLINK_KOBJECT_UEVENT: No such process", with the current core at edge this problem is gone
<jdstrand> ok, perfect
<jdstrand> perhaps zyga would want to peek at 3504 :)
<mup> PR snapd#3519 closed: arch: the kernel architecutre name is armv7l instead of armv7 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3519>
<niemeyer> It's getting to that point where I type "snap install blah" and then wonder why nobody has snapped blah yet
<mup> PR snapcraft#1378 opened: Integration tests for snap command with target arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1378>
<mvo> fgimenez: hm,hm, it looks like #3519 got merged 4h ago but its not part of the snapd-vendor branch (and hence not in the ppa) yet, any idea?
<mvo> fgimenez: can I manually trigger this?
<fgimenez> mvo: mm maybe the build after merging on master didn't succeed, the sync is done after merge + green build
<fgimenez> mvo: i'll check, anyway you can retrigger from #mupmock on tg, this will get the current master no matter if the test passed or not, let me show you
<mup> PR snapd#3521 opened: snap-seccomp: make sure snap-seccomp writes the bpf file atomically <Created by mvo5> <https://github.com/snapcore/snapd/pull/3521>
<fgimenez> mvo: i got two errors executing the suite from master on the latest edge http://paste.ubuntu.com/24933366/, if you could take a look that would be great, i'm trying to reproduce both of them now
<mvo> fgimenez: thanks, 2017/06/23 16:52:12 Error executing external:ubuntu-core-16-64:tests/main/server-snap:goServer :  is strnage, no denials or anything
<mvo> fgimenez: the snapd-notify is hopefully fixed with 3515
<mvo> cachio: could oyu please check 3515 why the testsuite fails?
<fgimenez> mvo: ok thx, i'll focus on server-snap:goServer then
<mvo> Chipaca: 3521 is something for you, the best thing is that we probably caught it via one of the tests :)
<mvo> (spread tests)
<fgimenez> mvo: it fails consistently, adding -v to the nc call i get "nc: connect to ip6-localhost port 8081 (tcp) failed: Cannot assign requested address", the session is open in case you want to get anything else
<mvo> fgimenez: is the service itself running?
<fgimenez> mvo: yep, it's up and listening on 8081 http://paste.ubuntu.com/24933471/
<fgimenez> mvo: i think this is probably related to the changes to the way we manage ipv6 when /etc/gai.conf is not writable http://paste.ubuntu.com/24933600/
<mvo> fgimenez: aha, puhhh, that a) makes sense b) means I did not break it .)
<fgimenez> mvo: yep :) http://paste.ubuntu.com/24933635/ i'll prepare a PR for fixing it
<mvo> fgimenez: I broke master bug 35212 should fix that
<mup> Bug #35212: unable to compose messages <Mozilla Thunderbird:Fix Released> <mozilla-thunderbird (Ubuntu):Fix Released by adconrad> <https://launchpad.net/bugs/35212>
<fgimenez> mvo: thx, np
<fgimenez> mvo: anyway, it won't affect the backport to 2.26, we didn't have any changes related to /etc/gai.conf there
<mup> PR snapd#3522 opened: tests: do not disable ipv6 on core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3522>
<mup> PR snapcraft#1374 closed: tests: set up the spread execution in linode <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1374>
<mup> PR snapcraft#1379 opened: blank version not allowed in snapcraft.yaml <Created by roxyd> <https://github.com/snapcore/snapcraft/pull/1379>
<mup> PR snapcraft#1380 opened: release changelog for 2.32 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1380>
<mup> PR snapd#3523 opened: tests: fix for create-key task to avoid rng-tools service ramains alive <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3523>
<mup> PR snapd#3524 opened: asserts,overlord/devicestate: allow and support serials signed by a trusted authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3524>
<mup> PR snapd#3522 closed: tests: do not disable ipv6 on core systems <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3522>
<mup> PR snapcraft#1381 opened: tests: install pyramid in autopkg integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1381>
<cachio> mvo, sorry for the delay
<cachio> the 3515 is failing due to the reboot error
<cachio> mvo, it is one of the most difficult tests to fix
<cachio> mvo, it always happens on ubuntu-core-16-64 and the issue is that after the core image is created and the system rebooted, the machine does not start anymore
<cachio> mvo, I also pushed a fix for the create-key issue, this should be the final one
<mvo> cachio: nice, thank you
<cachio> mvo, if you can retrigger it should be fine
<mvo> cachio: yeah, I noticed the that the ubuntu-core-16-64 issue is tricky
<mvo> cachio: sure, let me do that
<cachio> mvo, then if you can trigger also 3523
<cachio> if failed because of the snapd-notify
<cachio> it failed
<mvo> cachio: sure thing
<mvo> cachio: I can not (easily) retrigger autopkgtests, we need to ignore those for now. sorry for that
<cachio> mvo, np
<mup> PR snapd#3525 opened: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3525>
<cachio> niemeyer, could yo please take a look to Spread-14
<cachio> in the console
<cachio> niemeyer, 50.116.52.47
<cachio> niemeyer, in case it is powered off, could yo uplease try to start it and see the screen output?
<mup> PR snapcraft#1381 closed: tests: install pyramid in autopkg integration tests <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1381>
#snappy 2017-06-24
<mup> PR snapcraft#1380 closed: release changelog for 2.32 <Created by kyrofa> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1380>
<mup> PR snapcraft#1371 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1371>
<mup> Bug #1616629 opened: could not unmarshal state entry "snap-type" <Snappy:Confirmed> <https://launchpad.net/bugs/1616629>
#snappy 2017-06-25
 * Chipaca looks around
#snappy 2018-06-18
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: last week of school
<zyga> any "holiday" plans?
<mborzecki> yeah, i'm taking 2 weeks off in the beginning on july
<zyga> and your kids/
<mborzecki> we're going away for a while together
<zyga> nice
<zyga> good morning mvo
<mvo> hey zyga
<mvo> zyga: good morning
<mborzecki> damn, my emacs setup fell apart :(
<mborzecki> mvo: hey
<mvo> mborzecki: good morning to you as wlel
<zyga> mvo: when does school finish for your family?
<mvo> well
<zyga> mborzecki: what happened with your emacs?
<mborzecki> zyga: updated spacemacs and not it complains that there's no gocode, godef et al, probaly PATH messed up, or something special about zsh env files zshenv/zshrc
<mvo> zyga: this is the last week - but its different for the different regions in germany, some finish later
<mborzecki> yay, turns out i had to fix the spacemacs init file only :)
<mup> PR snapd#5330 closed: snapstate: support restarting snapd from the snapd snap on core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5330>
<mvo> getting a second review for 5324 would be great! it has one review already
<zyga> mvo: looking now
<zyga> mvo: we should discuss what to do today, should I finish the work on system or is that premature and it needs more review and discussion
<mvo> zyga: a good question, I would love to see it but maybe worthwhile to wait until the meeting after the standup
<zyga> mvo: sounds good, I have other things I can finish meanwhile
<zyga> mvo: if you merge it with your WIP branch and disable tests in ifacestate you can perhaps run spread and see how "far" it can go
<mvo> zyga: cool idea, with 5324 I think I can almost propose a spread PR, I think there is just one trivial change for core18 left to get very basic spread working
<mvo> zyga: and yeah, will be fun to run the entire thing :)
<mvo> zyga: part of the challenge will be to review the tests to see which really need core and which just pull it in for no good reason
<zyga> currently core is pre-installed before tests run
<zyga> so most tests just blindly assume core
<zyga> but yeah, it will be interesting to review tests to see what we ought to get
 * mvo nods
<zyga> I also wonder if we want to have tests/main be tests/main-on-core
<zyga> that is, shall we specialise some suites for a given core
<zyga> I don't know honestly
<mvo> zyga: quick question about 5250 - do you think it needs an extra review? it has two +1 now, so we can (squash)merge it I think. I'm a little bit nervous about it but it looks very good and solves a real problem
<zyga> hmm mhmm it's a tricky one
<zyga> maybe ask someone from foundation that knows udev for a last look
<mvo> zyga: yeah, I have the same feeling, tricky
<mvo> zyga: good idea!
<zyga> mvo: or, just ask lennart
<mvo> xnox: if we needed to ask a udev expert in foundations for a review, what would be your recommendation? we would love to get a high level review of #5250
<mup> PR #5250:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Squash-merge> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250>
<mvo> zyga: *cough* you are joking, right?
<zyga> no, really
<zyga> just ask a direct question, "is this and this sequence of udev calls" a safe thing to do
<zyga> mvo: reviewed
<pstolowski> mornings
<mvo> zyga: yay, thank you
<mvo> pstolowski: good morning
<mborzecki> pstolowski: hey
<mvo> zyga: I like your idea, very nice, will do that now
<mvo> zyga: hm, with the change the glob becomes a bit useless, right? snap-confine.core.111* basicly? but no issue as we just write a single file anyway
<mvo> zyga: right?
<zyga> hmm, let me look
<zyga> yeah, the glob would just match that one fine
<zyga> *file
<mvo> zyga: the change makes the test much nicer to read
<mvo> zyga: good stuff
<mvo> zyga: i.e. all this crazy "strings.Replace("/", ".") etc is gone
<zyga> yeah
<zyga> it's more obvious what is going on
<mvo> zyga: hm, but the glob needs to be something else or than snap-confine.core.111*  because .111* also matches .1111 which we don't want
<zyga> the glob doesn't need to use *
<mvo> zyga: aha, nice
<zyga> it can be literally the name of the file you want to create
<zyga> the glob is there in case we want to "own" a namespace
<zyga> since (AFAIK, correct me if I'm wrong) we also have a bit of code that cleans those up when a snap is removed
<zyga> ... or do we?
<mvo> zyga: yeah, we clean those up
<mvo> zyga: and we  have tests for that
<mborzecki> https://paste.ubuntu.com/p/j3g5RqxFPZ/ iirc Chipaca saw something similar
<zyga> error: e-book-client-error-quark[2] Conflicting UIDs found in added contacts, hmmm
<zyga> address book persists between runs?
<zyga> mvo: are you sure we can use * for revision?
<zyga> this means that a setup for snapd 123 will remove profiles for snapd.122
<zyga> as the system will find a file matching the glob that is not described by the content map
<mvo> zyga: yes, that is was we are currently doing
<mvo> zyga: its not a regression but its not great either
<zyga> mmm, I see
<zyga> let's do it and see
<mvo> zyga: its not ideal, we need to think how to improve it
<mvo> zyga: I was also thinking it might be racy because we update the current symlink and then when snap run runs it will not yet have profiles for snap-confine
<mvo> zyga: but fortunately the system-key fixes this, i..e we have code in snap run that waits for profile re-generation on system key mismatch
<zyga> I agree, ultimately I think the profile ought to be removed only when the snap is removed
<zyga> since for various reasons it can persist longer, even while the snap is inactive
<mvo> zyga: +1
<mvo> zyga: I will do a followup with this
 * zyga breakfast
<Chipaca> moin moin
<zyga> good day to you sir, on this lovely morning
<Chipaca> finally got a test run that failed with econnreset with the new extra debug yesterday
<Chipaca> if anybody's interested
<Chipaca> :)
<Chipaca> also didn't get more than a couple of hours of sleep last night, so i'm not seeing straight right now
<mvo> Chipaca: I am interessted
<Chipaca> mvo: I'll send you my  paypal address
<Chipaca> mvo: https://api.travis-ci.org/v3/job/393403309/log.txt
<Chipaca> i also have a local copy of that if it goes away
<mvo> Chipaca: the latest theory of cachio is that this happens when there is a "snap userd" leftover from previous tests
<mvo> Chipaca: then "kill $(pidof snap)" fails
<zyga> maybe killall instead of kill?
<Chipaca> I mean, that might be one source of failures
<Chipaca> but it's not this one
<Chipaca> this one is definitely the 'no match' error
<zyga> what I would really like is my measure patches to spread
<zyga> so that we could put up walls around each test to ensure it doesn't leak
<mvo> Chipaca: aha, looking
<mborzecki> hm #5353 looking good so far, 5 runs, all but one green, that one was unrelated though (eds thing i pasted above)
<mborzecki> #5335
<mup> PR #5335: tests: fix for the download of the big snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5335>
<mvo> Chipaca: hm, this log does not (yet) contain the output of "ls -lh test-snapd-huge_*", right? or am I just missing it?
<Chipaca> mvo: it does not contain output of that sort, no
<Chipaca> mvo: where was that added?
<mvo> Chipaca: thats slightly sad, it would be nice to know if the download simply finished, this is not logged yet, is it?
<Chipaca> mvo: it does contain logs that say what it did though
<Chipaca> mvo: yes it does say when it's finished
<Chipaca> let me get that
<mvo> Chipaca: is where the partial file output got added
<mvo> Chipaca: https://github.com/snapcore/snapd/pull/5333
<mup> PR #5333: tests: show status of the partial test-snapd-huge snap in econnreset test <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5333>
<Chipaca> mvo: that's on master, and i merged that master into thsi pr
<Chipaca> mvo: so maybe i was wrong and it does include the ls
<Chipaca> didn't see it tho
<mvo> Chipaca: I don't see it
<mvo> Chipaca: it would be good to know if the download finished successfully, I think this is what happend
<mvo> Chipaca: oh nooooo
<mvo> Chipaca: we have two debug: | in the test now
<Chipaca> mvo: given it doesn't start downloading the assertion until the download is finished, I'd say you are correct
<mvo> Chipaca: must be a double merge, this is why the debug output is missing
<mvo> Chipaca: let me push a PR
<Chipaca> mvo: I might add to that PR :) but yes
<Chipaca> mvo: in any case: assertion download doesn't start unless snap download succeeded
<Chipaca> so, fastly is _too_ good :)
 * Chipaca wants to make it clear that this is not a complaint
<mvo> Chipaca: haha
<Chipaca> it's downloading 500MB in less than .1 seconds
<mvo> Chipaca: maybe - or iptables is really slow appying the filter
<mvo> Chipaca: I push something that adds more timestamps
<zyga> Chipaca: we could make another episode of "speed" with this
<Chipaca> mvo: I think it's time to add a slow writer debug thing
<Chipaca> e.g. have a SNAPD_DEBUG_HTTP value of 8 mean 'be slow'
<Chipaca> hmmm
<mup> PR snapd#5336 opened: tests: remove double debug: | entry in tests and add more checks <Created by mvo5> <https://github.com/snapcore/snapd/pull/5336>
<mvo> Chipaca: lets see if the times add up. I saw 50mb/sec download speed in tests so far but that means (even if it becomes more speedy) that the download will take ~10sec, even if its actually only 5sec but still a bit strange. so I would love to see logs
<mvo> Chipaca: maybe we can even add a log in httpclient "fetched %q with size %v in %v seconds" or something?
<mvo> Chipaca: anyway, a fun test issue to track down :)
<Chipaca> âfunâ
<zyga> mvo: I asked this last week but I think I missed the response if any
<zyga> what is inside that 1GB snap?
<zyga> is it 1GB of random data?
<mvo> zyga: I think so
<mvo> zyga: I don't remember, let me check
<zyga> what's the name?
<mvo> zyga: I think /dev/urandom because otherwise it compresses too well
<mvo> zyga: test-snapd-huge
<zyga> thanks
<zyga> fetching now
<mborzecki> hm 536MB
<zyga> I"m getting ~8MB/s
<mborzecki> is it an electron app? :)
<zyga> mborzecki: just the splash screen featuring 4K video
<mborzecki> zyga: haha wish that technology exited in the 90s :P
<zyga> offtopic, I recall my Samsung times when the Samsung website, when viewed in Korea, would display a 1080P full screen feed as the _background_
<zyga> the huge snap is actually 0.5GB as mborzecki noted
<mborzecki> hmm my tiny user service for tmux was supposed to remain on logout, i guess it didn't :/
<mvo> zyga: so 0.5gb is not huge enough ;)
<mup> PR snapd#5324 closed: snap: run snap-confine from the re-exec location <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5324>
<Chipaca> mvo: should I go ahead with the limiting writer?
<mup> PR core18#27 closed: run-snapd-from-snap: start snapd after seeding <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/27>
<Chipaca> that is, having httputil's logger client slow things down for us
<mvo> Chipaca: I would say lets wait a tiny bit to see what logs with timestamps show, i.e. I'm keen to learn what is going on, if e.g. ipstables takes 10s to run. or if it runs and then just does nothing for whatever reason to the running tcp stream
<Chipaca> mvo:
<Chipaca> 2018/06/18 08:44:37.358695 logger.go:82: DEBUG: < "HTTP/1.1 200 OK\r\nContent-Length: 536875008\r\nAccept-Ranges: bytes\r\nAccept-Ranges: bytes\r\nAge: 43918\r\nCache-Control: max-age=86400\r\nConnection: keep-alive\r\nContent-Disposition: attachment; filename=YVl7fwoQCPqOE2PGt5wxZnhu1lSJhvki_1.snap\r\nContent-Type: application/octet-stream\r\nDate: Mon, 18 Jun 2018 08:44:37 GMT\r\nEtag: cee7a99d-0a0d-4981-b2d6-563c667c332c\r\nLast-Modified: Sun, 17
<Chipaca> Jun 2018 20:32:12 GMT\r\nServer: TwistedWeb/14.0.2\r\nStrict-Transport-Security: max-age=2592000\r\nVary: Accept-Encoding\r\nVia: 1.1 varnish\r\nVia: 1.1 varnish\r\nX-Bzr-Revision-Number: 7463\r\nX-Cache: MISS, HIT\r\nX-Cache-Hits: 0, 0\r\nX-Request-Id: WybFTH8AAQEAAC3@nDwAAAB61\r\nX-Served-By: cache-lcy19224-LCY, cache-iad2645-IAD\r\nX-Timer: S1529311477.354131,VS0,VE1\r\n\r\n" [ 58ms; 9.26GB/s]
<Chipaca> ^^^ 9 YIGAWATTS
<mvo> Chipaca: wuuuut?
<mvo> Chipaca: thats crazy
<Chipaca> mvo: so, er, that's faster than we'll see if we blink
<Chipaca> also, hot damn, i'm moving to wherever this is :)
<mvo> Chipaca: sounds like we need a limiting writer :)
<Chipaca> (it's probably in the USA so heck no)
<mvo> Chipaca: well, I'm sure this is fastly inside GCE
<mvo> Chipaca: but even then, *amazing*
<Chipaca> mvo: here's hoping it's not fastly from somebody's garage
<mvo> Chipaca: I will rent that garage
<mvo> Chipaca: I'm sure they make apples there
<mvo> Chipaca: anyway, nice find! that is amazing
<Chipaca> I'll push a PR that adds those two bits of info, as it's useful to have
<Chipaca> hm, maybe together with the limiting writer
<mvo> Chipaca: aha, I was wondering where it comes from
<mvo> Chipaca: did you try this in a gce machine?
<Chipaca> mvo: yes, this is in gce
<Chipaca> this is not my home network
<Chipaca> i don't even get that speed from the switch
<mvo> Chipaca: so "snap download test-snapd-huge" in a fresh machine?
<Chipaca> mvo: yes
<mvo> Chipaca: amazing
<mvo> Chipaca: thanks, I think we have the answer then to the conundrum
<Chipaca> mvo: it's s till up if you want me to try anything further
 * mvo hugs Chipaca and hands him the hero-of-the-day medal
<zyga> Chipaca: any chance our CDN is in google?
<zyga> so two box spawn on the same rack because google updated the Borg with some AI
<mvo> Chipaca: you could download some other big snaps just for fun
<zyga> and then then RDMA some memory across
<mvo> Chipaca: firefox, some electron apps
<Chipaca> zyga: fastly.cdn.snapcraft.io is at least 3 hops away, on a different ip range
<zyga> wow
<zyga> then wow :)
<Chipaca> zyga: still 18ms end to end
<Chipaca> mtr thinks it's 5 hops
<Chipaca> (18 ms ping, that is)
<Chipaca> mmmmmm, maybe i was too hasty
<Chipaca> mvo: ^
<Chipaca> i'm printing the response before reading the body :-(
 * Chipaca needs a brown paper bag, now
<zyga> Chipaca: so google doesn't have transwarp internet links?
<Chipaca> zyga: disappointed
<Chipaca> drat
<mvo> Chipaca: heh :)
<Chipaca> shoudl've used my head
<mvo> Chipaca: I think you mentioned earlier you didn't sleep enough, I would hand you a cup of tea now in a real office :)
<Chipaca> 'time' says snap download takes ~15s
<mvo> Chipaca: hm, that *should* be plenty of time
<mvo> Chipaca: same if you run it again?
<mvo> Chipaca: I mean after "rm *.snap"
<Chipaca> mvo: if I run it again, _without_ removing the snap, it takes 7s
<mvo> Chipaca: hm, hm, even that should be enough
 * mvo scratches his head
<zyga> tcpdump
<zyga> and see what happens
<Chipaca> it takes ~3s to heck the hash
<zyga> wow
<zyga> HDD IO slow?
<zyga> are we checking the hash in-flight?
<Chipaca> zyga: not for the 'already there' case
<Chipaca> zyga: when downloading, yes
<zyga> mhm
 * zyga zeroes on another layout fix
<zyga> brace for a simple but boring review (large diff)
<zyga> well, *test* diff
<zyga> actual diff not large :)
<Chipaca> 2018/06/18 09:15:36.223438 store.go:1546: DEBUG: Download succeeded in 5.264175609s ( 102MB/s).
<Chipaca> mvo: ^ a little bit more believable
<mvo> Chipaca: yeah, thank you
<mvo> Chipaca: still really fast
<Chipaca> i still want that 9GB/s world tho
<mvo> heh, indeed
<zyga> this is an interesting failure
<zyga> https://travis-ci.org/snapcore/snapd/builds/393533806
<zyga> "network availability confirmed"
<zyga> then bzzzt and silence
<ogra_> mvo, zyga, did you guys see the last post on https://forum.snapcraft.io/t/missing-information-in-the-documentation/5969
<ogra_> that looks very weird
<ogra_> (given he is root ... )
<zyga> I replied
<ogra_> thx
<zyga> but I won't look for a while, need to focus
<Chipaca> ogra_: looks like they installed lxd, have running vms, and trying to 'apt remove' everything without uninstalling lxd first
<ogra_> ah !
<Chipaca> on the other hand that's just a guess, because they're not telling us what they did
<ogra_> yeah, it would have helped if he has kept the package names in the paste
<Chipaca> they purposely have edited the output of some stuff, and are hiding or altering info without saying
<ogra_> *had
<Chipaca> so it's not worth my time to debug further
 * Chipaca might be particularly short of patience today
<Chipaca> also, what, the 'apt remove snapd' produced no output at all?
<Chipaca> it reads like a bad work of fiction
<Chipaca> :shrug:
<mup> PR snapd#5337 opened: store: log a nice clear "download succeeded" message <Created by chipaca> <https://github.com/snapcore/snapd/pull/5337>
<mborzecki> Chipaca: would love to see those YB/s downloads
<Chipaca> mborzecki: from quantity.go: // zetta and yotta are me being pedantic: maxuint64 is ~18EB
<mup> PR snapd#5337 closed: store: log a nice clear "download succeeded" message <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5337>
<cachio> mvo, niemeyer hey, I have a school meeting today, perhaps I'll arrive a bit late to the standup
<mvo> cachio: ok
<mup> PR snapd#5338 opened: interfaces: move assertions around for better failure line number <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5338>
<zyga> pstolowski: ^ quick ack please
<pstolowski> +1
<zyga> thnx
<zyga> opensuse failed twice on zypper network operation
<zyga> mborzecki: small conflicts in https://github.com/snapcore/snapd/pull/5314
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mup> PR snapd#5339 opened: tests: initial core18 spread image building <Created by mvo5> <https://github.com/snapcore/snapd/pull/5339>
<zyga> mvo: ^ reviewed
<zyga> 2nd review for simple https://github.com/snapcore/snapd/pull/5315
<mup> PR #5315: cmd/snap-update-ns: introduce mimicRequired helper <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5315>
<mup> PR snapd#5338 closed: interfaces: move assertions around for better failure line number <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5338>
<ads20000> Wimpress: Skype segfaults on startup on my Ubuntu 18.04 Wayland install but there's no clear place to report the bug given in the `contact` field of `snap info skype`?
<ads20000> *segfaults GNOME Shell
<popey> ads20000: does it work under x?
<ads20000> (so it plonks me back to the login screen)
<ads20000> I'll give it a go :)
<Chipaca> I'm going to be a git and say if an app crashes your wayland (or x11), it's a wayland (or x11) bug
<ads20000> popey: seems to be OK on X, was crashed back to GDM once but I wonder if it's the Polari Flatpak... journalctl didn't seem too clear on that one
<popey> ads20000: you can file a bug now you have it running :)
<cjwatson> ads20000: I had the same symptom with skype on wayland, and no Polari involved
<popey> Help -> Report a problem.
<ads20000> ah nice thanks popey! :)
<popey> np :)
<cjwatson> but I agree with Chipaca that this is surely a gnome-shell/wayland/something bug (either exclusively, or in addition)
<ads20000> ah right I can't see those messages since I was logged out
<ads20000> until they're logged in a couple of hours...
<zyga> pstolowski: maybe you again, pretty please: https://github.com/snapcore/snapd/pulls/zyga
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1760487 but expired for lack of requested info
<zyga> the first one there
<zyga> mimic required, green
<mup> Bug #1760487: Shell crashes when I start skype under Wayland session <amd64> <apport-bug> <bionic> <wayland-session> <gnome-shell (Ubuntu):Expired> <https://launchpad.net/bugs/1760487>
 * tomwardill -. lnch
<cjwatson> ads20000: maybe you could follow the instructions in the bug above?  I do have a crash from a few days ago but am not completely sure that it was from trying to start skype and I don't want to nuke my session right now ...
<mvo> zyga: woah, that was quick :)
<ads20000> here's my log https://paste.ubuntu.com/p/K8KK65ftbk/ submitted via the form in Skype :)
<cjwatson> reporting to Skype isn't the same as reporting the bug in Xwayland, though
<cjwatson> you should hopefully have a .crash file in /var/crash/ that you can report as per the bug above
<cjwatson> (it may not be a skype bug at all ...)
<ads20000> cjwatson: on it :)
<cjwatson> great
<mup> PR snapd#5340 opened: cifs-mount-control interface (discussed in snapcraft.io forum post 5689) <Created by datenhahn> <https://github.com/snapcore/snapd/pull/5340>
<ads20000> cjwatson: please can you mark yourself as affected by https://bugs.launchpad.net/bugs/1777425 ? I've linked back to it in the other bug report :)
<mup> Bug #1777425: Skype snap segfaults GNOME Shell on Wayland <amd64> <apport-bug> <bionic> <ubuntu> <wayland> <gnome-shell (Ubuntu):New> <wayland (Ubuntu):New> <xorg-server (Ubuntu):New> <https://launchpad.net/bugs/1777425>
<cjwatson> ads20000: done
<ads20000> ty
<mup> PR snapd#5315 closed: cmd/snap-update-ns: introduce mimicRequired helper <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5315>
<mborzecki> that skype taking down wayland bug is awfully like the slack thing on fedora
<pstolowski> pedronis: hey, added a comment to your gadget PR
<mup> PR snapd#5336 closed: tests: remove double debug: | entry in tests and add more checks <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5336>
<pedronis> pstolowski: they are a sort of auto-connection, we can also store the gadget flag in conns, if it will help in the future keeping this under control
<om26er> Wimpress: Hi! Need review on https://github.com/snapcrafters/android-studio/pull/28 -- its mostly inspired by your similar pull request for sublime.
<mup> PR snapcrafters/android-studio#28: Embed autodownloads <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/28>
<mup> PR snapd#5341 opened: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5341>
<mborzecki> zyga: ^^
<zyga> yeah, looking
<zyga> queued, I'll do it soon
<mborzecki> zyga: thanks
<mborzecki> any PRs in need of a 2nd review?
<zyga> mborzecki: I don't think so, though I'm working on one more
<zyga> (at least not mine)
<mup> PR snapd#5081 closed: interfaces/apparmor: add chopTree <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> I suspect there are some things to review around
<niemeyer> Mornings
<niemeyer> mvo, pedronis, zyga: Our core18 meeting in 2h today is atop a weekly cross-team one.. same time tomorrow is empty atm
<niemeyer> (every week)
<zyga> ok
<zyga> I should break for dog/lunch
<pedronis> pstolowski: IÂ commented in the PR too, let me know what you think
<pedronis> mborzecki: there are again conflicts with #5314, it's looking good otherwise
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<pstolowski> pedronis: yep, i saw that, thanks; why not single flags then and treat by-gadget appropriately? is it important to know it was coming from gadget at a later time?
<pedronis> pstolowski: you just said it is, to do the right thing with reconnect, no?
<mborzecki> pedronis: thanks, pushed again, it should merge cleanly now
<pedronis> mborzecki: made a small comment now and  before answered some of yours, overall +1
<pstolowski> pedronis: no, if there was no auto flag in conns on reconnect we would apply regular connect policy (which is what we want for these gadget connections). but if we decide to set auto on these connections then i think we need what you suggest about having 'by-gadget' in conns
<pstolowski> pedronis: to summarize, i thinkfor gadget connections we need to either 1) set auto+bygadget in conns or 2) not set auto in conns
<pstolowski> 1 sounds cleaner and more explicit
<pedronis> yea,  given that the want most of the behavior of "auto" and it is a kind of "autoconnection"Â from the POV of the user
<pedronis> that seems the best
<mborzecki> pedronis: thanks!
<pedronis> mborzecki: it's not a blocker, but we need to discuss the snap-name ==Â app-name case though (it has influences also on aliases checks/rules later)
<mborzecki> pedronis: yes, it's a bit confusing, i think i'd go with short app name only iff snap-name == instance-name, leaving others with snap-name.app-name
<mborzecki> pedronis: damn, instance-name == store-name
<mborzecki> names everywhere
<pedronis> I read snap-name as store-name
<zyga> ok, break time, see you at the standup
<mvo> niemeyer: thank you, I push it tomorrow then
<pedronis> mvo: there's again an overlap for Gustavo, aÂ new meeting
<mup> PR snapd#5335 closed: tests: fix for the download of the big snap <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5335>
<mvo> pedronis: aha, let me check with his calendar
<mvo> pedronis: I pushed it 30min later and we can shorter it to 30min
<mvo> pedronis: maybe we can talk about the model assertion question (how to specificy channels in there) during the standup
<pedronis> mvo: yes, though I don't think we want channels as such, but I understand about tracks
<Chipaca> brb, getting tea
<mup> PR snapd#5342 opened: tests: shellchecks part 4 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5342>
<ads20000> I have an interview with a temping agency using Skype so hopefully it doesn't crash _crosses fingers_! xD
<pedronis> mvo: related to the issue we discussed  I created this:  https://forum.snapcraft.io/t/evolving-prepare-image-syntax/5988 based on an old mail thread
<mvo> pedronis: thank you
<mvo> cachio: pardon my ignorance but is there a way to see the console of a machine in GCE? I pushed 5339 which runs a core18 spread test. this works locally when I run the qemu backend but for some reason it seems to not make it past the reboot and I wonder if the console gives any clues
<cachio> mvo, yes
<cachio> mvo, go to https://console.cloud.google.com/compute/instances
<cachio> select the instance you want
<smoser> hi. when using 'stage-packages' how do you indicate what distro/release will be used ?
<mvo> cachio: cool, looking
<cachio> thne you can see -> Serial port 1 (console)
<Elion321> Hallo. Installed the snap package "Ktube Media Downloader". it doesn't start. is this the right place for help?
<smoser> and my second question.. when i try to build snap via https://build.snapcraft.io/user/smoser snapcraft.io says 'the snapcraft.yaml can't be used because it isnt valid.'
<mvo> cachio: its jun181349-260204 I will try to find it in the dashboard
<smoser> but local testing is fine.
<mvo> cachio: hm, hm: " You do not have sufficient permissions to view this page. "
<cachio> https://console.cloud.google.com/compute/instancesDetail/zones/us-east1-b/instances/jun181349-260204?project=computeengine&authuser=0&organizationId=888541318771&supportedpurview=project
<smoser>  branch is https://github.com/smoser/pdftk/tree/snap/snap
<ogra_> smoser, curretly you can only use 16.04
<ogra_> (for stage-packages that is)
<cachio> mvo, https://paste.ubuntu.com/p/4PmfrHnZ8W/
<mvo> cachio: looks like I have no permissions, is that something that gustavo can fix?
<smoser> ogra_: ok... thanks i thought i had heard somewhere that you could use something else. i wanted to be specific though in my snapcraft.
<mvo> cachio: thank you, reading the pastebin
<smoser> er... snap.yaml
<ogra_> smoser, yeah, base snap support is in full flow atm
<cachio> mvo, yes gustavo is the right person
<smoser> but stage packages isn't really realted to base snap
<ogra_> that will allow you to get 18.04 or fedora or whatever as the backing release for the stage-packages
<smoser> or maybe i'm misunderstanding how that works (quite likely)
<smoser> i thoguht it essentially just grabbed a bunch of binaries and actted as if you had built all those things and then collected them up.
<mvo> cachio: hm, this looks good, I wonder if there is an issue with the network, maybe the netplan config does not match for whatever reason, do you happen to have the "ifconfig" output on a gce system?
<cachio> mvo, no
<ogra_> well, stage-packages currently pull in from the archive your build host uses ... but then your snap binary will run on top of the core snap (or later the base snaps) ... so your libc and stuff needs to match
<smoser> ie, i should be able to pull a bunch of debs from bionic and run it on core snap of xenial. no ?
<ogra_> this is where the connection between base and stage-packages lives
<cachio> mvo, which config do you need?
<cachio> mvo, perhaps we can get it from other side
<smoser> ogra_: ok. i can see that.
<mvo> cachio: the ifconfig output (the output from the comand). I wonder if maybe the machine does not get network
<mvo> cachio: aha, nevermind, found some info
<cachio> mvo, you can log in and see it if you want
<cachio> do you have the credentials for that?
<smoser> ogra_: do you see an obvious thing i've done wrong in https://github.com/smoser/pdftk/blob/snap/snap/snapcraft.yaml such that snapcraft.io github build stuff would say 'isnt valid' (it gives no other info)
 * zyga dreams of air conditioning 
<ogra_> zyga, so ameriacn of you
<zyga> ogra_: is that a good thing or a bad thing
<ogra_> smoser, whats that first part supposed to do (it looks like a complete no-op)
<smoser> ogra_: it is. :)
<ogra_> also i'm not sure you can have a toplevel "parts:" twice at all
<smoser> if its not necessary, i can remove it. followed https://larry-price.com/blog/2016/12/07/creating-a-snap-from-existing-deb-packages/
<smoser> oh. well yeah... ok that makes sense. i didn't realize i  had
<ogra_> i guess thats the thing the validator chockes on
<smoser> and yeah, that is undefined behavior
<smoser> in yaml
<ogra_> right
<ogra_> funny that it works locally
<ogra_> should be the same validator that runs
<smoser> hm..
<smoser> it worked fine on xenial
<ogra_> are you using the snapcraft snap or the deb ?
<smoser> but it coudl be that arbitrary differences make my local "find" the second 'parts'
<smoser> and on the build server it does the first
<ogra_> (i'd use the snap since thats guaranteed to be the same version everywhere)
<smoser> the yaml.load()
<smoser> i installed snapcraft from deb
<pedronis> mborzecki: could you add a note the parallel install topic about the "postgres_foo" installing the "postgres_foo" app ?
<ogra_> the snap is typically more up to date since it doesnt need to go through the whole SRU cycle
<smoser> yeah.. i didn't even think of that
<smoser> (using the snap for snapcraft)
<ogra_> (and you can quickly switch to the beta or edge channel and back in case you need some upcoming feature in your build)
<smoser> thanks ogra_ i'm all settled now.
<ogra_> :)
<mvo> cachio: I think I don't have permissions for login at this point, especially since I would have to log into a running core18 that has no netowrk - at least that is my theory. its very strange, core16 and core18 use the same kernel snap and same gadget and yet it looks like core16 loads the virtio kernel module and core18 does not for some reason
<cachio> mvo, ohhh
<cachio> mvo, let me check if I can login from the page
<cachio> mvo, the last thing I see in the console output is "Press enter to configure"
<mvo> cachio: yeah, maybe its just cloud-init missing
<cachio> it is like netplan didn't run yes
<cachio> yet
<mup> PR core18#28 closed: Fix the UID/GID mapping <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/28>
<mup> PR core18#29 opened: hooks: add cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/29>
<mvo> cachio: yeah, it looks like there is no network interface, the kernel output of core18 has no ens4 but classic has that. I will add cloud-init and see if that helps (we need this anyway I think)
<Elion321> Hallo. trying it again. Installed the snap package "Ktube Media Downloader". it doesn't start. is this the right place for help? OS: Ubuntu mate 18.04 x64.
<Elion321> where to report bugs for a specific snap package?
<Elion321> snap is from snapcraft.io
<cachio> mvo, are we going to unify the snap names to avoid having jq and jq-core18?
<zyga> cachio: I suggested to use 18 track for that
<mvo> cachio: yeah, using a track seems to make sense
<cachio> zyga, good
<zyga> maybe use the track that matches the base
<zyga> so core18 rather than core
<zyga> would help with some f29 work we need to do this cycle
<smoser> well, i guess i'm not all set...
<smoser> ogra_: http://paste.ubuntu.com/p/dfZm7xDjwV/ the snapcraft.io build failed to publish, but it looks incorrect to me.
<mup> PR core18#30 opened: hooks: clenup /etc/{passwd,shadow,group,gshadow}.orig <Created by mvo5> <https://github.com/snapcore/core18/pull/30>
<smoser> (thanks for your help... sorry to pester you)
<mvo> smoser: silly question, will cloud-init help with network module (kernel) loading? I am working on core18 right now and it looks like on GCE I don't get a virtio-net based network-interface but core18 has no cloud-init yet
<zyga> mvo: can you add me as a co-developer of core18
<mvo> zyga: sure
<ads20000> Skype for Linux didn't work - didn't pick up my webcam, but not sure the Deb does either. Had to do it on my mum's Win10 PC...
<smoser> mvo: cloud-init doesn't intenrally help at all with kernel module loading.
<smoser> mvo: you're saying our kernel on gce does not recognize virtio nics ?
<smoser> that is possible... but i thought that on gce nics provided *were* virtio
<mvo> smoser: thats what it looks like which is very odd because its pretty much the same kernel works on core16
<smoser> so.. that'd imply that it was busted out of the gate. which is not the case (our cloud images do work there)
<mvo> smoser: yeah, I think its virtio based networking that is used there
<mvo> smoser: they work with 4.4-130.156 as well?
<smoser> oh.
<smoser> xenial i think doesn't use ga (-generic) kernel there.
<smoser> i think theres is something esle.
<smoser> i'd have to check to be sure
<smoser> launch a gce and look
<smoser> but bionic is going to use 4.15 i'd expect (but would have to check that for sure)
<mvo> smoser: aha, thank you. no worries, I will dig some more
<mvo> smoser: yeah, support for installing 4.15 is not there yet
<mvo> smoser: and I think we also don't have kernels snaps :/
<thresh> virtio is probably in an -extra kernel package
<thresh> so.. check if you have it installed
<ogra_> smoser, well, the build looks fine to me ... not sure why it would fail to upload ... thats a store team question i guess
<smoser> well, it gives that error about a danling symlink
<smoser> (which surely does not appear dangling to me)
<smoser> er... extrenal. which still doesn't seem to be the case.
<ogra_> it dangles outside of the snap
<smoser> no
<ogra_> but i dont think that will prevent the upload, it creates a snap after all
<ogra_> so the build finishes successfully
<smoser> right it says
<cjwatson> That sort of thing is usually due to missing build-packages:
<smoser> Build failed to release:
<smoser>   Error:package contains external symlinks: usr/lib/security/classpath.security
<cjwatson> And I think the reviewer tools do reject on dangling symlinks
<ogra_> aha
<cjwatson> Yes, that
<smoser> but the link is present ... didn't i show that clearly ?
<ogra_> the target too ?
<smoser> its *not* dangling, nor outside the root
<smoser> at least readlink -f agrees with me
<ogra_> so it points to something inside the snap ?
<ogra_> (not n core or the rootfs)
<cjwatson> If you're certain it's not external, then a bug on click-reviewers-tools, I'd guess
<smoser> http://paste.ubuntu.com/p/dfZm7xDjwV/
<zyga> mvo: did that check PR land?
<zyga> I could use the diffs now
<smoser> see lines 10 -> 22
<smoser> (ignore the confusing paste fail on line 17)
<cjwatson> smoser: ls -l /mnt/var/lib/security/classpath.security ?
<cjwatson> just to check
<smoser> -rw-rw-r-- 1 root root 2489 Jun 18 14:53 /mnt/var/lib/security/classpath.security
<mvo> zyga: unfortunately no
<zyga> no worries, thank you for the PRs
<zyga> I'll keep using my 27" screen to spot the diffs ;)
<mup> PR core18#29 closed: hooks: add cloud-init <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/29>
<smoser> interestingly enough, there *are* danling and outside symlinks
<smoser> http://paste.ubuntu.com/p/ft8FBgZxj6/
<cjwatson> smoser: I am not sure how you're getting the results you claim.  I downloaded your snap from the link on https://launchpad.net/~build.snapcraft.io/+snap/5f9c9f30f64adbeb1aed583265f7c8ae-xenial/+build/252508, looked at it, and it's clearly wrong.
<smoser> but the one it complained about is not one of them.
<cjwatson> $ ls -l /mnt/usr/lib/security/classpath.security
<cjwatson> lrwxrwxrwx 1 root root 36 Feb 11  2016 /mnt/usr/lib/security/classpath.security -> /var/lib/security/classpath.security
<smoser> huh.
<cjwatson> smoser: I think you're checking a different snap than the one that LP built.
<smoser> i am
<smoser> i tested the locally built one
<cjwatson> smoser: Which supports my theory that this is due to missing entries in build-packages.
<cjwatson> smoser: This is usually a matter of finding the package that delivers /var/lib/security/classpath.security and adding that to build-packages, so that snapcraft can copy the contents into the snap.
<smoser> cjwatson: how did you download ?
<cjwatson> smoser: wget
<smoser> is there a link ? i dont see that in build.snapcraft.io ur
<smoser> ui
<cjwatson> smoser: I gave the link above
<cjwatson> smoser: The first line of the build log is a URL to the LP +build page
<cjwatson> smoser: And on that there's a "Built files" section
<smoser> ah.
<smoser> yeah. ok. i didn't look at closely at the build logs orry.
<cjwatson> I wish BSI just linked to the LP page but there's a bit of a religion going on about not having that expose the implementation
<P4> Hello. I cannot start my rocketchat-server with systemctl and snap logs reports that it sudenly started to look for configs in rocketchat-serve and not rocketchat-server... I did not intentionally renamed that and I cannot easily find any references anywhere in the config trees on my system. Do you know what to look for by that hint from logs? How to recover? I don't think the apt-get {dist-,}upgrade in the
<P4> meantime made it. I'm on Ubuntu 18.04 with kernel 4.15.0-23-generic and snap 2.32.9 :-(
<zyga> P4 you can always "snap revert" to get to the previous revision (and blacklist this one). I would suggest that you get in touch with rocket chat people as well
<P4> I made backupdb and even started to symlink things, eh.
<zyga> I don't think we changed anything that would cause this
<zyga> can you get me some error logs you referred to?
<P4> thanks, zyga. will try
<P4> cannot revert "rocketchat-server": no revision to revert to :( but how come it got renamed hmpf.
<zyga> hmm
<zyga> can you look at snap changes
<zyga> and see if there was anything related to that snap?
<P4> I'm pretty new to snappy. I believe I should look with git somewhere around /var/snap/rocketchat-server/current
<zyga> no, don't look there
<zyga> look at what snapd did
<zyga> that is stored internally and exposed as "snap changes" and "snap tasks NNN" (where NNN is the number of the change)
<P4> oh
<P4> the CLI! <3
<P4> still there are  no changes found
<Chipaca> P4: what's the output of 'snap list' (pastebin it)
<Chipaca> P4: also, 'snap version'
<P4> it's https://paste.debian.net/1029731/
<Chipaca> P4: which snaps log say it's started looking for 'rocketchat-serve'?
<Chipaca> P4: also please pastebin 'snap info rocketchat-server'
<mvo> cachio: its jun181349-035780 this time, if you could paste me the dmesg output that would be great
<cachio> mvo, no instance with this name
<cachio> mvo, is it alive?
<mvo> cachio: ups, typo jun181539-035780
<mvo> cachio: and yes, should be alive
<cachio> mvo, https://paste.ubuntu.com/p/Bghqq5KCQF/
 * cachio lunch
<P4> Chipaca: https://paste.debian.net/1029735/ there in the logs
<mvo> cachio: thank you
<P4> maybe it is worth to mention that I was trying to change the listening port by adding Environment=PORT=80 in the /etc/systemd/system/snap.rocketchat-server.rocketchat-server.service file with some comments. then issued dist-upgrade and rebooted OS finding the problem. and now commenting out the line does not help. :| will try to run it by hand for a test
<P4> oh my god, the /etc/systemd/system/snap.rocketchat-server.rocketchat-server.service defined indeed ExecStart=/usr/bin/snap run rocketchat-serve and that looks totally like a user mistake... must be that. how come I oversaw it! :||||
<P4> darn, I'm sorry about the rumour. Thank you very much for your reactions, zyga && Chipaca. You are all amazing supporing great things the great way here on IRC. Thanks <33
<zyga> P4 good luck :)
<zyga> Chipaca: so, question to you sir
<zyga> shall snapd use ensureDirState-like functionality for services and mount units?
<zyga> we could _at leats_ warn (hint hint) about discrepancy
<zyga> and offer a way to "snap amend" it
<zyga> how do you feel about that?
<smoser> snaps in strict confinement can open files in ~user right ? (ie, /home/smoser) ?
<kyrofa> smoser, only if using the home interface
<smoser> itneed home plug.
<smoser> yeah.
<smoser> thanks kyrofa
<kyrofa> smoser, of course
<zyga> I need a break, back to apparmor rules after a shower
<zyga> I actually am terrible at any break taking business
 * cachio afk
<zyga> really afk
<_b_b> hi
<_b_b> i would like to test auto connection of gtk-theme
<_b_b> i've posted a question on the forum but i don't got any anwser about it
<_b_b> is it testable for now ?
<_b_b> https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122/6?u=b_b
<b_b> back with my nickname :)
<Chipaca> zyga: could be
<Chipaca> zyga: your 'snap amend' is probably just 'snap disable && snap enable'
<zyga> Yes. I think so
<zyga> Although with ensure directory state we could tell the user about the fixes
<Chipaca> zyga: 'snap fsck'
<Chipaca> P4: glad you figured it out, and happy to have been of assistance in getting you there!
<Chipaca> and now i think i'm eod, nothing is on fire etc etc (well my local snapd is panic()ing but that's me breaking it :) )
<Luke> hey guys is there a comprehensive list of the $SNAPCRAFT_PART_BUILD/INSTALL etc variables?
<Luke> also are there updated docs for the snapcraft syntax? It seems a lot of things are deprecated (like install:) in favor of override-build etc
<binarycreations> Hi
<binarycreations> I am still having trouble creating a snap of the anki desktop client. Thank you to those who have taken a look at this thread already. I have recently updated it (https://forum.snapcraft.io/t/help-required-packaging-anki-desktop-client-as-a-snap/5950) with more details.
<binarycreations> I am having some trouble understanding how to inspect the container environment that is created by snapcraft.
<binarycreations> I don't particularly understand what shell you get from snap run --shell and how to get more detailed debugging or logging information from snapcraft and when you run your snap
<binarycreations> Thanks in advance for any help or assistance. Sorry if this appears to be a desperate nag, however I do really want to snap this app.
<zyga> binarycreations: hey
<zyga> you get regular /bin/bash
<zyga> but running inside the sandbox
<zyga> so enforced permissions apply
<mup> PR snapd#5343 opened: tests: adding extra check to validate journalctl is showing current test data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5343>
<binarycreations> zyga: Thanks - what seems odd is the dir I get
<binarycreations> I think I found my issue - only found the desktop launch and other desktop support
<binarycreations> Under the "Languages" section you might want to consider having a desktop or GUI application section
<binarycreations> Or even a different section
<binarycreations> I have been shooting down the wrong alley for a while now
<binarycreations> zyga: I have updated the forum post again. Now I am stuck with getting libgl1-mesa-dri to install when running snapcraft.
<binarycreations> I feel one step closer
<binarycreations> I need some sleep so will catch up with the forum later
<qwebirc28961> I'm having problems with snapcraft handling of command line arguments containing non-ascii chars. From my research, it seems related to snap's use of "click"
<qwebirc28961> How should I handle command-line arguments in a Py3 script without getting "surrogates not allowed" errors?
<qwebirc28961> Should I set "LANG" in the snapcraft.yaml?
<qwebirc28961> As per the instructions on http://click.pocoo.org/5/python3/, print(sys.argv[1].encode('utf-8')) does not work either...
#snappy 2018-06-19
<zyga> good morning
<mborzecki> morning
<mborzecki> starting a bit later today, had to take my wife's car to the shop
<mup> PR core18#31 opened: hooks: move 003-writable-paths.chroot to static/etc/system-image <Created by mvo5> <https://github.com/snapcore/core18/pull/31>
<mvo> hey mborzecki - good morning
<mborzecki> mvo: hey
<mborzecki> any fires today?
<mup> PR core18#32 opened: writable-paths: add needed paths for cloud-init <Created by mvo5> <https://github.com/snapcore/core18/pull/32>
<mvo> mborzecki: no fires, I'm a little bit frustrated with core18 in gce, spread tests does not work there yet but they work fine in qemu and I'm scratching my head why
<mvo> mborzecki: but no fires afaict
<mborzecki> mvo: hmm that's interesting, anything in particular that fails int he tests? or does it not boot at all?
<mvo> mborzecki: it boots and cachio pasted me the console output which looks fine (for some reason I don't have enough access in the gce console to see it myself). so I think it does not get network
<mborzecki> mvo: do the new images use netplan or sth?
<mvo> mborzecki: yeah, it is, it *should* be the same config as the core16
<mborzecki> mvo: interface naming then?
<mvo> mborzecki: my current straw is that cloud-init is not working yet on core18 and maybe it is doing some magic here
<mvo> mborzecki: its a pretty generic config, one sec, let me find it
<mvo> mborzecki: https://github.com/snapcore/core18/blob/master/static/etc/netplan/00-snapd-config.yaml
<mborzecki> mvo: looks pretty straightforward
<mvo> mborzecki: yeah, I need to learn if I can get a OOB shell with gce somehow
<mborzecki> mvo: there is a dhcp client in the image?
<mvo> mborzecki: systemd-networkd
<mvo> mborzecki: I don't think there another
<mborzecki> mvo: ok, that should be fine, networkd does it's own dhcp
<mvo> mborzecki: yeah
<mborzecki> mvo: hm you could try and ship your own config file for networkd in case netplan doesn't do it's thing
<mvo> mborzecki: thats an interessting idea
<mborzecki> heh, got another update to shellcheck, now it complains about not quoting variables when sourcing files, iirc this wasn't strictly needed
<mvo> mborzecki: heh
<mvo> mborzecki: nice find on your latest shellcheck PR in the framebuffer test
<mborzecki> mvo: yeah, looking into it right now
<mvo> mborzecki: shell is just not the best language, really good we run the checker now
<mvo> mborzecki: I wish there was something like "-o strict" or somesuch that would at least protect against all the basic mistakes. anyway
<mborzecki> mvo: shperl
<mvo> mborzecki: heh
<mvo> mborzecki: btw, gustavo added some comments to github.com/go-check/check https://github.com/go-check/check/pull/100
<mup> PR go-check/check#100: many: return kr/pretty:Diff when Equals/DeepEquals check fails <Created by mvo5> <https://github.com/go-check/check/pull/100>
<mvo> mborzecki: the first question about "if result { clear error message" is from your diff, this is a test failing, right? I wonder if we should test this more explicitly, wdyt?
<mborzecki> mvo: ah interesting, i can look into this later
<mvo> mborzecki: thank you, I will look at his other points
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> mvo: ok, i think i remember now, there may not be an explicit test for this, but the clearing was added there to prevent the Not() checker from raising false positives
<mborzecki> mvo: a vague recollection, that if you did say, Not(DeepEqual()) and the Not checker left the error message intact it would still come up as an error in the tests
<mborzecki> zyga: how's your SLED work?
<zyga> Stuck
<zyga> Look at that twitter post
<mborzecki> zyga: boo :(
<mborzecki> zyga: slightly surprised those are still behind paywall
<zyga> well, those are like RHEL
<zyga> but... I have a license
<zyga> something is wrong on the website
<mborzecki> https://forum.snapcraft.io/t/nvidia-cuda-on-ubuntu-core/292/24 heh, nice pattern from nvdiia
<mborzecki> ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x2, 0x18), 0xbeb00fc0) = 0 this does some magic
<mborzecki> and works outside of snap
<mborzecki> but inside it fails, the driver apparently trues to do another little poke ioctl(12, _IOC(_IOC_READ|_IOC_WRITE, 0x41, 0x3, 0x10), 0xbee73f28) = -1 EINVAL
<mborzecki> in either case, the device accessed is open("/dev/nvhost-as-gpu", O_RDWR|O_DSYNC) = 12
<mup> PR core18#31 closed: hooks: move 003-writable-paths.chroot to static/etc/system-image <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/31>
<zyga> I'm looking into opensuse releases
<zyga> something is not working well on LEAP
<zyga> and this is blocking a high-priority snap apparently
<mborzecki> zyga: when a device is not in device group, then will open() fail? or would other operations, eg. ioctl() fail but open() will succeed?
<mborzecki> s/group/cgroup/
<zyga> I believe open would fail, yes
<mborzecki> hmm, i'm thinking about that nvidia on ubuntu core on TK1 problem, the snap is accessing some special devices there, eg. /dev/nvhost-as-gpu and ioctl() fails, but open() works
<mborzecki> zyga: we don't seem to add any of those devices, but it's likely that the board is runnign some old(ish) kernel, maybe without device cgroup even
<zyga> mborzecki: we need to further differentiate leap and tumbleweed
<zyga> :/
<zyga> 42.3 cannot use any apparmor
<zyga> leap 15 and tumbleweed can
<mborzecki> zyga: what's missing there?
<zyga> apparmor userspace is at 2.10
<zyga> that's far too old
<zyga> it cannot even parse our snap-confine profile
<mborzecki> well, we don't have much choice then
<zyga> I will check leap 15 to be sure
<zyga> and then patch this in the distro
<zyga> and then send the patches to master
<mborzecki> hm the framebuffer test was probably not executing on ubuntu-* because there's no /dev/fb* node
<mborzecki> then on others, it was just an echo due to missing "
<zyga> yeah
<mborzecki> and looks like write to a frame buffer is hitting a region outside of available memory, hence 'file too large' error
<zyga> I'm building 2.33 opensuse packages here https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<zyga> I will be patching that as I get builds and test them on my machines
<zyga> but now I need to go and pick up a package from downtown, I will commit my apparmor work and continue on the way there
<zyga> hmm
<zyga> tests fail on opensuse
<zyga> failed test in the state somewhere https://www.irccloud.com/pastebin/Aeu5glwF/
<mborzecki> fun fact, ubuntu-{16.04,18.04,-core-16} do not have /dev/fb so the apparmor rules are not really tested anywhere
<Son_Goku> :D
<Son_Goku> fun fact, fun facts aren't usually fun
<mborzecki> barrels of fun ;)
<Chipaca> Son_Goku: fun fact: ketchup was once medicine
<Son_Goku> Chipaca, really?
<Chipaca> well, sold as such
<Son_Goku> that's actually an interesting fact, if that's true
<Chipaca> (but then so was cocaine)
<Son_Goku> well, _that_ I knew
<mborzecki> Chipaca: so was mercury
<Chipaca> also fun fact: tin (can) openers were invented 48 years after food was being canned
<Chipaca> in the interim people just stockpiled the stuff*
<Chipaca> * may not be true
<pedronis> Chipaca: hi, I'm working on exposing publisher,  am I confused? we don't seem to have a test that checks the details of unmarshaling  of search results
<pedronis> (the last thing using details.go)
<Chipaca> pedronis: it's probably covered indirectly, but probably no unit tests
<mborzecki> another fun fact, our 16.04 image has minix module loaded even before the test using that module starts
<Son_Goku> wut
<pedronis> Chipaca: I mean store_test.go (IÂ know we don't have details_test.go), I don't see the indirect bit either but maybe I'm confused
<Son_Goku> mvo, do you know when 2.33.1 is going to be tagged?
<Chipaca> pedronis: 1 sec
<mborzecki> along with xfs, ntfs, hfs, qnx4 and so on :?
<Son_Goku> qnx4?!
<Chipaca> mborzecki: something is trying really hard to mount a filesystem
<Chipaca> maybe the gce initrd?
<mborzecki> Chipaca: no clue
<mborzecki> well, fwiw the rmmod-or-not part of the test did not work before shellchecks and it would always rmmod it
<Chipaca> pedronis: it seems you're correct, there are individual tests for specific aspects of details, but nothing whole hog
<pedronis> Chipaca: I suppose I should add something, maybe its own PR tough
<Chipaca> kjackal: that's a lot of yous
<Chipaca> pedronis: ok
<Chipaca> I should go do some work on my back an' stuff
 * Chipaca very comfy tho
<pedronis> Chipaca: probably your info branch removed a details one that can reuse
<pedronis> *that I can reuse in some form
<Chipaca> pedronis: I like your optimism :-)
<pedronis> heh, I do think we had some tests (but with /details apparently)
 * pedronis is hopeful
<Chipaca> Son_Goku: last fun fact for a while: colgate beef lasagne didn't sell well
 * Chipaca ~> physio
<Son_Goku> I'm going to go with "eww" for that
<Chipaca> a solid choice
 * Chipaca ~> really afk now
<mvo> zyga, sil2100: a quick look at #32 (in core18) would be great
<zyga> Ack
<sil2100> mvo: on it now
<mvo> sil2100: thank you
<sil2100> Ah, already saw it in the morning, didn't manage to +1 it then
<mup> PR core18#32 closed: writable-paths: add needed paths for cloud-init <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/32>
 * mvo hugs sil2100 
<joc> zyga: are new interface PRs waiting on 2.33 going out before landing? just checking not waiting for anything from me
 * zyga is in the underground
<zyga> They are waiting for jdstrand
<zyga> He is off this week
<zyga> I think 33 is branched already so there is nothing blocking master
<joc> zyga: the PR has your and Jamie's +1s but the tests have not yet run successfully, looks like there was provisioning error
<zyga> Iâll look into it soon
<zyga> Returning home now
<mborzecki> zyga: do you remember if firmware loading is done directly in the kernel now or still through a udev helper?
<mup> PR snapcraft#2160 closed: many: refactor snapcraft.yaml loading out of load_config <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2160>
<mborzecki> zyga: pinged you in the forums, there's an interesting case regarding firmware loading and interaction with mount namespace
<zyga> mborzecki: replied there
<zyga> mborzecki: as for firmware loading, it AFAIK changed from userspace to kernel but I could be wrong and it could be backwards
<zyga> mborzecki: given that it fails I suspect it's userspace and the firmware cannot be found
<mborzecki> idk, haven't touched that really since 2.6.x days
<zyga> mborzecki: also on core vs classic?
<mborzecki> zyga: the topic is about core
<zyga> mborzecki: on core, unless you use bases, you are using the same filesystem as before
<zyga> there's a mount namespace but it is largely the same
<mborzecki> zyga: confinement-options:  classic devmode
<zyga> that's ... weird
<zyga> classic devmode is meaningless
<zyga> does it work outside of a snap
<zyga> ?
<mborzecki> zyga: the thing works outside of snap
<zyga> strace it
<mborzecki> zyga: and if you start the app outside of snap, then it will work inside too
<mborzecki> zyga: there's starce logs attached 2-3 messages up
<zyga> ah, let me see then
<zyga> mborzecki: well
<zyga> confinement options is what is *supporteD*
<zyga> not what is used
<zyga> mborzecki: so this could be a strict snap
<zyga> but I see there's no apparmor at all
<mborzecki> zyga: ther's no aa
<zyga> so it's somewhat meaningless
<zyga> some funky errors at the end of snap_directly_log.txt https://www.irccloud.com/pastebin/qOLUGDob/
<zyga> note that it closes -1
<zyga> probably missing error checking
<zyga> mborzecki: is there /dev/nvidiactl inside the cgroup?
<zyga> (device cgroup)
<mborzecki> zyga: yes, we add it, we're adding nvidiactl, nvidia-uvm, nvidia-modeset and then some nvidia<num> devices
<zyga> 1811  open("/dev/shm/cuda_injection_path_shm", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<zyga> this looks related
<zyga> is it there on the outside?
<mborzecki> zyga: don't know, i don't have access to this host
<mborzecki> zyga: it's also funny taht if you run the app outside once, it will work inside the snap too
<zyga> until reboot, right?
<zyga> please ask for a strace -f, after reboot, of the app running _outside_
<zyga> then for a similar strace but on the inside, also after reboot (where it will fail)
<zyga> if we have that we can investigate
 * zyga is about 10-20 minutes away from home
<zyga> cannot wait to get back really
<zyga> it's so damn hot today
<zyga> my son's computer broke and I had to get a part that was faulty
<zyga> he needs it for classes today
<mvo> niemeyer: hey, good morning. could you give me permission so that I can see "jun191112-575930" in GCE? I would love to see the terminal and ideally login if possible (there is a problem with getting the network working right now on core18 so an oob login would be great to figure out what is going on)
<zyga> mvo: ouch, still fighting that?
<zyga> mvo: did you look at diffing /etc between core18 and core?
<mvo> zyga: yeah
<mborzecki> zyga: btw. notice that there's a log in dmesg that getting firmware failed, given that it's kepler, iirc those already required a blob to work
<zyga> it may be something that was added to current system
<mvo> zyga: I poked around a bit, added some more cloud-init bits
<zyga> mvo: and something in /etc/modules.d or modprobe.d?
<zyga> mborzecki: it would be good to ask some nvidia people how this is supposed to work
<zyga> it's a bit silly that when you want to use the hardware then each app actually goes to load firmware into the hardware
<mborzecki> zyga: i bet many people in open source had the same thought :)
<mborzecki> zyga: i think it's the first use
<mvo> zyga: not afaict
<zyga> m
<mvo> zyga: it might be something silly
<mborzecki> zyga: so you try to do something with the hardware for the first time and the driver goes to load the firmware
<mvo> zyga: but without access to the machine its hard to diagnose :/
<zyga> yeah
 * mvo gets lunch instead
<zyga> mvo: netplan has
<zyga> mvo: netplan has two patterns, one matches en* and the other matches eth*
<zyga> maybe on a newer core you get veth or something silly like this
<zyga> becuase newer systemd
<zyga> and then stuff falls apart
<zyga> suggestion
<zyga> as a hack change /etc/netplan/00-snapd-config.yaml
<zyga> and mach on *
<zyga> fingers crossed
 * zyga walks home, cannot wait to have A/C next season 
<mborzecki> zyga: there's 19C in oslo right now, ever considered moving?
<Chipaca> oslo with 19C must be melting
<zyga> Hahah
<zyga> Well, Iâm not *that* crazy
<Chipaca> zyga: [citation needed]
<mborzecki> pedronis: shall we land #5314 once it's green?
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mup> PR snapd#5334 closed: tests: show executed tests on current system when a test fails <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5334>
<zyga> Chipaca: hehe :)
 * zyga is home now
<zyga> geez, outside is not fun
<pedronis> mborzecki: you should ask mvo if there is something high prio from him that could conflict
<mborzecki> mvo: is there?
<mborzecki> i can help resolving conflicts if needed
<mup> PR snapd#5344 opened: store: have a basic test about the unmarshalling of /search results <Created by pedronis> <https://github.com/snapcore/snapd/pull/5344>
<pedronis> Chipaca: ^ , not beautiful but better than nothing
<Chipaca> will look in a bit
<Chipaca> currently reviewing shellcheck
<mborzecki> Chipaca: thank you!
<zyga> mvo: any luck with that etherent change?
<Chipaca> mborzecki: don't thank me until the fat lady sings
<Chipaca> I ask Questions
<mborzecki> Chipaca: right, i might as well cleanup the \- now that i'm doing the changes anyway
<mborzecki> Chipaca: looks like it was copy pasted pretty much everywhere :P
<Chipaca> mborzecki: I understand it's easier to think of it as a pure shellchecking change, but yeah
<Chipaca> I'd have to read the docs on too many things to find out if that \- actually matches what we want it to match
<Chipaca> mborzecki: there's also a bunch of the PWD ones
<niemeyer> mvo: Heya, yeah, can definitely do it
<cachio> zyga, hey
<zyga> hey
<cachio> interfaces content if failing sporadically https://api.travis-ci.org/v3/job/393533314/log.txt
<zyga> checking
<cachio> did you see that one?
<zyga> cachio: yes,
<zyga> it's not related to content really
<zyga> it's related to mount exploiding
<zyga> - Mount snap "test-snapd-content-slot" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dslot-2.mount failed.
<zyga> See "systemctl status "var-lib-snapd-snap-test\\x2dsnapd\\x2dcontent\\x2dslot-2.mount"" and "journalctl -xe" for details.
<zyga> Jun 18 09:29:29 arch snapd[12112]: Jun 18 09:29:28 arch kernel: print_req_error: I/O error, dev loop3, sector 0
<zyga> there's a thread about it
<cachio> zyga, ah, ok, good to know
<cachio> tx
<zyga> https://forum.snapcraft.io/t/unexplained-mount-failure-protocol-error-what-we-know-so-far/5682
<pedronis> mborzecki: sorry, I  just merged something that probably needs a remerge for your PR
<mup> PR snapd#5344 closed: store: have a basic test about the unmarshalling of /search results <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5344>
<pedronis> Chipaca: IÂ got a +1 from zyga, happy to tweak in a follow up though if you find something that merits changes
<Chipaca> pedronis: LGTM
<Chipaca> pedronis: also thank you for updating the json
<pedronis> Chipaca: which reminds me, we can remove MockDetailsJSON
<pedronis> but something of another PR
<pedronis> s/of/for/
<Chipaca> pedronis: there's a lot of unused stuff, according to 'unused'
<Chipaca> pedronis: I can propose a removal pr in a bit :)
<pedronis> thx
<CyberShadow> Hello. I submitted two pull requests last August, and got 0 feedback. Could someone please have a look at them?
<CyberShadow> https://github.com/snapcore/snapd-xdg-open/pulls?q=author%3ACyberShadow
<zyga> CyberShadow: hello
<zyga> I think that repository is dead now, let me see
<zyga> we should archive it
<zyga> we re-wrote that code significantly since
<CyberShadow> I found the software useful for use outside of snaps. How do you solve that problem now?
<zyga> let me show you
<zyga> https://github.com/snapcore/snapd/tree/master/userd
<zyga> https://github.com/snapcore/snapd/blob/master/userd/launcher.go this is what the old code did
<mup> PR snapd#5345 opened: store: drop unused: channel map types, and details fixture <Created by chipaca> <https://github.com/snapcore/snapd/pull/5345>
<Chipaca> pedronis: ^ +0 -115 :)
<zyga> CyberShadow: this runs on the outside and sits on the bus
<zyga> CyberShadow: the one that runs on the inside ...
<zyga> CyberShadow: is here https://github.com/snapcore/snapd/blob/master/cmd/snapctl/main.go#L50
<zyga> and more completely here: https://github.com/snapcore/snapd/blob/master/xdgopenproxy/xdgopenproxy.go
<mvo> cachio: is there a way to log into a gce instance when there is no ssh/network ? some magic via serial console etc?
<CyberShadow> I see, thanks! So you consolidated everything into one daemon rewritten in Go.
<zyga> CyberShadow: one codebase, there's more than one process
<CyberShadow> I think I'll maintain my fork of the old snapd-xdg-open then, it's still useful with Firejail/Bubblewrap.
<zyga> CyberShadow: I will close your PRs now, sorry
<CyberShadow> Right, that hasn't changed.
<CyberShadow> No problem. Consider adding a note that the repository is EOL.
<cachio> mvo, you should to send all the info to the console, then we can check that
<cachio> mvo, let me research a bit about other ways to do it
<mborzecki> zyga: github allows repos to be archived now, no clue though who can mark that one as such
<zyga> mborzecki: yeah, I know
<zyga> mborzecki: I will ask during the standup
<Chipaca> CyberShadow: if the two bits were still go but separate, would you contribute to them?
<Chipaca> CyberShadow: or is the hacky aspect of the previous incarnation part of their appeal :)
<zyga> kyrofa: https://forum.snapcraft.io/t/update-all-python-snaps-not-working-with-classic-confinement-even-with-cleanbuild/5971
<Chipaca> CyberShadow: I ask because the new things support stuff the old ones do not, like apps autostart
<Chipaca> so there might be value in them for you as well
<CyberShadow> Chipaca: Sure, language doesn't matter
<CyberShadow> Sorry, I'm not sure how autostart fits in with the Firejail/Bubblewrap flow...
<Chipaca> CyberShadow: I don't know either :)
<Chipaca> CyberShadow: how would an app go around setting up autostart in that world?
<CyberShadow> It doesn't, it's something that would break encapsulation :)
<CyberShadow> The user would need to do that manually. They would need to create the container manually too, so it's not unexpected.
<Chipaca> CyberShadow: I'll raise separating it in the standup
<Chipaca> CyberShadow: is it the inside-the-container thing that you use, or the outside one, or both?
<CyberShadow> Both
<Chipaca> k
<CyberShadow> Here is the user-facing documentation: https://wiki.archlinux.org/index.php/Bubblewrap#Opening_URLs_from_wrapped_applications
<CyberShadow> Just to clarify, I think everyone involved would be quite happy with maintaining a fork, so don't feel obligated to support this use case :)
<mup> PR snapd#5345 closed: store: drop unused: channel map types, and details fixture <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5345>
<Chipaca> CyberShadow: yep yep
<Chipaca> CyberShadow: the old one was attractively simple so I get that
<Son_Goku> CyberShadow, I suggest renaming the application, but yeah, go for it
<CyberShadow> Good idea :)
<Son_Goku> CyberShadow, talk to the guys in #atomic about hosting the program under their banner
<Son_Goku> that way it sits adjacent to bubblewrap ;)
<CyberShadow> True, though it looks like they have their own higher-level snapd equivalent to use with Flatpak (which uses Bubblewrap): https://github.com/flatpak/xdg-desktop-portal
<Son_Goku> CyberShadow, well, that's why I suggested projectatomic and not flatpak org ;)
<CyberShadow> Ah, right
<Chipaca> CyberShadow: the conclusion in the standup is that most of the new features are very snap-specific in their approach, and maybe it's not that useful outside of this
<Chipaca> CyberShadow: so fork away, with our blessing
<CyberShadow> Thanks!
<pedronis> mvo: I'll be a couple of minutes late
<zyga> ah, the core18 meeting is still in 29 minutes
<zyga> I thought it was back to back
<pedronis> ah, same, was confused
<zyga> uh
<zyga> I ran out of disk space
<zyga> sigh
 * zyga moves stuff around
 * ogra_ hands zyga a paperbasket
 * zyga throws lumps of lead and cement inside
<ogra_> *thump*
<zyga> look, the bucket is now a pipe
<mvo> niemeyer: the compute.instances.reset permission for image debug would be great
<zyga> downloading chrome
<mborzecki> mvo: will landing #5314 conflict with any stuff that you have open atm?
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<mvo> mborzecki: its fine, I will deal with any conflicts
<niemeyer> mvo: (done, for our record)
<mvo> niemeyer: thank you (also for the record ;)
<zyga> I must say that the google meet thing has better video quality
<zyga> or mvo changed his camera to some high-def one
<zyga> it looked much sharper than before
<zyga> I will break for dinner now, back in one hour when I also have my disk space free
<mvo> mborzecki, pstolowski: hey, I got a question about the new snapd.seeded service and I think I need help looking at this. the issue is https://pastebin.canonical.com/p/thJBrCX4wr/ i.e. it looks like this starts too early for some reason. do you think one of you have some minutes (tomorrow is fine too) to look into it?
<pstolowski> mvo: sure, i can look at it tomorrow
<sergiusens> niemeyer: hi there, are you joining?
<niemeyer> sergiusens: Yep, sorry
<zyga> mvo: is 2.33 in general a go?
<zyga> or are there any issues warranting a .1
<mvo> zyga: no issues but we will most likely do a .1 to fix some autopkgtests in the distro
<zyga> only autopkgtests?
<mvo> zyga: but no real issues, all tests related
<zyga> ok
<zyga> good, I'll make sure we can release to opensuse tomorrw
<mvo> zyga: thank you
<zyga> and I need to buy a disk or a NAS maybe
<mvo> zyga: if you want we can coordinate with a .1
<zyga> sure, that's fine
<zyga> changing the tarsal is all we need I suspect
<zyga> though
<zyga> we can merge my packaging fixes for .1 too
<mvo> cachio: interessting datapoint - I just got a econnreset test failure where we got a 503 from fastly
<zyga> hmm, any gas recommendations
<zyga> NAS
<zyga> silly spellchecker
<mvo> pstolowski|afk: thank you, lets talk tomorrow, I will forward you two mails about it
<mvo> zyga: depends on how much you want to hack it :)
<cachio> mvo, do you have any log?
<mvo> cachio: I have it still open, I can save/pastebin it
<cachio> mvo, yes please
<mvo> cachio: http://paste.ubuntu.com/p/x58ZnRZW3Y/
<cachio> mvo, do you have the error itsrf?
<mvo> cachio: this is the full log http://paste.ubuntu.com/p/2PryTk8nZs/
<cachio> mvo, tx
<cachio> mvo, I don't see any error
<mvo> cachio: uh, sorry, hold on
<mvo> cachio: http://paste.ubuntu.com/p/GjXcPvxmPF/ this is hopefully the right one this time
<mvo> yay, core18 spread did a successful run (with a single test) in gce - cleanup of this tomorrow
<cachio> mvo, nice
<cachio> it received a 503 and didn't retry
<cachio> and also failed to kill the snap download process
<cachio> mvo, well, the ShouldRetryError method is not returning true if it receives a 503
<cachio> it is retrying on timeout, syscall.econnreset, dial error and unexpectedEOF
<cachio> pedronis, is it ok? should er retry the download when we get a 503 from the cdn?
 * zyga thinks the idea is "if the user would retry, so should we'
<cachio> zyga, in this case we should change the ShouldRetryError to support other errors
<cachio> this is why in some cases the econnreset is not downloading the snapd
<cachio> snap
<cachio> ans it is not retrying neither
<cachio> mvo, thanks for the logs, it was really usefull
<mvo> cachio: my pleasure
<mborzecki> zyga: qnap or netgear maybe? i personally have netgear, had to rma it once because the eth port got burned, i've sent them ethtool output, and sent me another unit
<zyga> I think I will just buy a HDD for now
<zyga> nas boxes look very expensive
<zyga> and I would like to actually use the one I've built some time ago (it's not something I can use today because it has old / crappy drives)
<mvo> zyga: I got a relatively cheap synology
<mborzecki> zyga: yeah you buy a box, then the disks, it adds up :)
<zyga> (I built an ivy bridge i3 box with 5 HDD cages on backplane)
<zyga> the problem with that box is that it weighs a lot and is not a mobile in any way
<zyga> and I want something I can take with my laptop next month
<zyga> anyway, I'll just get a USB HDD
<zyga> not perfect
<zyga> but yeah, low cost
<cachio> I see the error in the code
<cachio> mvo, why it is not retrying in 50X
<cachio> mvo, core snap 2.33 in stable channel
<noise][> cachio: will you be updating the forum post? (https://forum.snapcraft.io/t/snapd-2-33-release-cycle-started/5585)
<cachio> noise][, yes
<cachio> noise][, let me complete the smoke test
<zyga> \o/
<mvo> cachio: yay, thank you
<mvo> cachio: iirc the idea behind not retry on 500 was that sometihng is broken on the server
<mvo> cachio: but if its a real world scenario maybe we need to rethink that
<zyga> mvo: but the CDN is ... big
<zyga> so maybe retrying is sensible
<zyga> another server might just work
<mvo> zyga: yes
<cachio> zyga, mvo https://paste.ubuntu.com/p/Tx9WgCW9nR/
<cachio> based on ShouldRetryHttpResponse we should retry
<mvo> cachio: yes, I remember this code
<cachio> but based ton ShouldRetryError we shouldn't
<cachio> so we never check the response becasuse we don't retry and break based on the errorr
<cachio> mvo, is it ok?
<mvo> cachio: yeah, we probably just need to update ShouldRetryError
<cachio> mvo, ok
<gouchi> hi
<gouchi> to test the fix for  https://forum.snapcraft.io/t/nvidia-gl-libs-access-broken-on-ubuntu-18-04
<gouchi> I need to update snapd or using core snap to edge branch is enough ?
<pedronis> cachio: that code doesn't expect a 503  to reach ShouldRetryError, we are probably misunderstanding something about the library
<mup> PR snapcraft#2162 opened: tests: new codespell, narrowed checks and better execution order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2162>
<mup> PR snapcraft#2163 opened: tests: add lifecycle ordering tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2163>
#snappy 2018-06-20
<mup> PR snapcraft#2162 closed: tests: new codespell, narrowed checks and better execution order <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2162>
<tooijar> Is it possible to remove old revisions from the store?
<Son_Goku> zyga: https://flocktofedora.org/#cfp
<mborzecki> morning
<mup> PR snapd#5346 opened: cmd/snap: add a backup handler for snap:// URIs that prompts the user to install the gnome-software snap <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5346>
<zyga> hey
<zyga> irccloud is down, hmm
<mborzecki> zyga: heh, looks like it
<zyga> ok, let me push those suse PRs
<zyga> oh, drat
<zyga> master has even better integration
<zyga> let me take some of that too
<zyga> I wish the snapd.apparmor.service was in 2.33 :/
<mborzecki> zyga: can't you backport it?
<zyga> yeah, that's what I'm looking at now
<zyga> it's not a large change
<zyga> I'm building 2.33 as is to see what it lacks from the packaging in master
<zyga> I don't love cherry picking our patches when they are not squashed
<zyga> I guess I can branch off 2.33 and cherry pick the lot
<zyga> then squash and export
<zyga> right?
<zyga> tumbleweed is on 4.17,
<zyga> that's ... fast :)
<mborzecki> zyga: 4.17.2-1-ARCH
<mborzecki> probably fedora too
<zyga> ok, patches prepared, one more build
<zyga> Pharaoh_Atem I need to thank you for the fantastic rework of the opensuse package!
<zyga> it makes things much easier
<mborzecki> zyga: did you get a chance to look at #5341 ?
<zyga> the C changes?
<mup> PR #5341: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5341>
<mborzecki> zyga: yup
<zyga> not in detail,
<mborzecki> probably good if jdstrand could take a look too when he comes back
<mborzecki> btw. if nobody minds i'll be landing #5314 soon
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<pstolowski> mornings
<zyga> pstolowski hey
<zyga> mborzecki I asked one question on the validate PR
<zyga> https://pastebin.ubuntu.com/p/y3kjK4zXGS/ <- rpmlint report so far
<mvo> hey pstolowski ! good morning
<mborzecki> zyga: not sure i follow, the pr splits instance name to snap name and instance key and validates both already
<pstolowski> mvo, mborzecki any new developments re snapd.seeded service issue? you haven't forwarded me those emails, have you?
<zyga> yes but you _already_ have a function for splitting it
<mborzecki> zyga: right but that code is supposed to work with validated input and dies instead of returning nice errors, i could probably rework it to use sc_error
<zyga> ah
<mborzecki> zyga: it will die if sc_error is unset right?
<zyga> this makes sense
<zyga> yes
<zyga> sc_error was designed so that errors are either propagated or the program dies
<mborzecki> zyga: i can look into it
<mborzecki> mvo: do yu have any high priority pending PRs that use info.Name() that would conflict if i merge #5314?
<mup> PR #5314: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<zyga> mborzecki btw, I want to simplify sc_error
<mvo> mborzecki: nothing with priority, feel free to land this
<zyga> I wrote some personal code and I evolved (simplfied) error handling a bit
<mborzecki> mvo: ack
<zyga> we could talk about this on Friday
<mup> PR snapd#5314 closed: many: rename snap.Info.Name() to snap.Info.InstanceName(), leave parallel-install TODOs <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5314>
<zyga> [   43s] FAIL: booted_test.go:218: bootedSuite.TestUpdateBootRevisionsOSErrorsLate
<zyga> [   43s]
<zyga> [   43s] booted_test.go:253:
<zyga> [   43s]     c.Assert(chg.IsReady(), Equals, true)
<zyga> [   43s] ... obtained bool = false
<zyga> [   43s] ... expected bool = true
<zyga> random test failures are best
<mborzecki> zyga: does it fail when ran isolated?
<zyga> it didn't fail for the last N runs I did
<zyga> I'm only tweaking linter errors so it's just random
<zyga> I didn't try isolated yet
<mborzecki> zyga: trid go test -c -o foo.test && while true; ./foo.test -check.f || break; done ?
<mborzecki> mvo: do you have the log from  snapd.seeded failure? (or is pstolowski already looking into it)
<pstolowski> mborzecki: https://pastebin.canonical.com/p/thJBrCX4wr/ ; i haven't looked at it yet but about to, mvo has some more info in emails, looking forward to them
<mvo> mborzecki: pstolowski said he will look into it last night, I can mail the logs to both of you
<mvo> pstolowski: I sent the mail a bit earlier is it not there yet?
<pstolowski> mvo: nope, no emails
<zyga> most lint errors are gone now
<zyga> just a few more..
<mborzecki> mvo: pstolowski: looks like snapd.seeded could use Requires=snapd.socket at least
<pstolowski> indeed
<mvo> mborzecki, pstolowski sent it to both of you again
<mup> PR snapd#5347 opened: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5347>
<mvo> mborzecki: did you get the mail?
<mborzecki> mvo: yup, got it
<mborzecki> mvo: thanks!
<mvo> mborzecki: thank you, interessting, pstolowski did not get it, we were wondering if my fastmail provider has a problem but apparently its more complicated :/
<pstolowski> interesting :)
<mborzecki> mvo: yeah, got a nice fat warning from gmail about possible spoof
<mborzecki> mvo: similar to a name in your organization but the email address does not belong to your domain or the email is not authenticated. Avoid clicking links or replying with sensitive information unless you reach out to the sender by another means to ensure that this email is legitimate
<pstolowski> mvo: so yes looks like Requires=.. will do it, but i'd test it; how do i play with seeding?
<mborzecki> hm i'm wondering if there could some unwanted side effect
<mborzecki> pstolowski: mvo: maybe we should have Restart=on-failure too?
<mvo> mborzecki: yeah, that sounds reasonable
<mvo> mborzecki: restart on failure
<pstolowski> allright i see some spread tests for seeding
<mborzecki> hmm got 14% of battery left, need to find a power outlet
<pstolowski> mvo, mborzecki okay, i'll try to amend existing spread tests to reproduce and then will apply the above plan
<mborzecki> pstolowski: sounds good
<mvo> pstolowski: \o/
<mup> PR snapd#5348 opened: packaging/opensuse: snap-confine should be 06755 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5348>
<pstolowski> mvo: ok, the problem reproduces nicely with just examining systemctl snapd.seeded service status in existing spread test, onto fix now
<mvo> pstolowski: yay, thank you
<mvo> pstolowski: I will pull that into 2.33.1
<pstolowski> ok
<mborzecki> ok, i'm moving back home, bbiab
<mup> PR snapd#5349 opened: packaging/opensuse: add missing bits for snapd.seeded.service <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5349>
<Chipaca> mvo: pstolowski: which problem?
<pstolowski> Chipaca: https://pastebin.canonical.com/p/thJBrCX4wr/
<pstolowski> Chipaca: snapd.seeded service not waiting for snapd.socket
<Chipaca> pstolowski: it should wait for snapd.service I'd think
<Chipaca> unless that creates a loop
<mup> PR snapd#5350 opened: packaging/opensuse: don't use %-macros in comments <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5350>
<zyga> Chipaca hey sir
<zyga> quick question
<zyga> $(reverse complete.sh) needs to be executable, correct?
<mup> PR snapd#5351 opened: packaging/opensuse: build position-independent binaries <Created by zyga> <https://github.com/snapcore/snapd/pull/5351>
<Chipaca> zyga: hmm... let me remember
<Chipaca> zyga: it doesn't need to afaik
<zyga> it is on ubuntu
<zyga> it isn't on opensuse
<zyga> shall I unify some way?
<Chipaca> zyga: we run essentially 'bash etelpmoc.sh'
<zyga> and it is in the tree
<Chipaca> zyga: if you have the 'http' snap installed, and you run: snap run --command=complete http 9 9 6 1 ' ' "http -" http -
<Chipaca> zyga: if that prints a bunch of stuff, it works :)
<Chipaca> (by a bunch of stuff i mean a list of options)
<zyga> yes, it works
<zyga> ok, I'll remove the +x bit then
<Chipaca> zyga: er
<zyga> hm?
<Chipaca> zyga: note it's the one in the core you want to tweak
<zyga> oh
<zyga> bummer
<Chipaca> :)
<zyga> that's more work ;)
<zyga> Chipaca ok, that works too
<Chipaca> zyga: also it's rev <<<complete
<Chipaca> $(rev <<<complete).sh
<Chipaca> clearly
<mup> PR snapd#5270 closed: snap,client: show "publisher" in `snap list` and expose in client API <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5270>
<mup> PR snapd#5352 opened: many: expose full publisher info of the snapd api <Created by pedronis> <https://github.com/snapcore/snapd/pull/5352>
<Chipaca> hah! in github the way you tell it utf is ok is with 'utf8=â'
<pedronis> Chipaca: hi,  5352 follows your suggestion about expanding publisher in the snapd API to the same object as the v2 store API
<Chipaca> pedronis: reviewing it already
<Chipaca> (toggled whitespace to see the struct diffs properly which is when i noticed the utf8=â thing)
<mup> PR snapd#5353 opened: data/completion: remove shebang and +x from etelpmoc.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/5353>
<Chipaca> pedronis: had we agreed on changing the column name in list?
<Chipaca> pedronis: (that's a bigger 'we' than you and me)
<mvo> Chipaca: for publisher instead of developer? I think we did
<Chipaca> mvo: schweet
<mup> PR snapd#5354 opened: packaging/opensuse: ship apparmor integration if enabled <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5354>
<zyga_> https://code.facebook.com/posts/605721433136474/accelerate-large-scale-applications-with-bolt/ is interesting
<zyga> Chipaca: I pushed the opposite approach, we should also perhaps look at those shellcheck warnings I posed
<zyga> nothing there screams critical though
<zyga> I will address those separately
<Chipaca> zyga: sure. be careful though :)
<pedronis> Chipaca: answered some of your comments
<pedronis> Chipaca: also do you really meant adding output related code to the client pkg? that feels strange
<mup> PR snapd#5355 opened: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355>
<zyga> Chipaca: I decided not to touch that last one
<zyga> feel free to do so
<zyga> my bash is not that fantastic to do it comfortably
<pedronis> Chipaca: also IÂ notice that client/packages.go imports  snap nowadays, do you know what's the expected boundary?  IÂ could move to shared snap.StoreAccount under you unflatten request
<pedronis> *your
<mborzecki> re
<zyga> 2018-06-20 09:13:55 Cannot allocate google:arch-linux-64: cannot allocate new Google server for arch-linux-64: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1.
<zyga> google hates us todaty
<zyga> or just me
<mborzecki> ayy
<pedronis> mmh
<zyga> ETOOMANYIPV4ADDRESSESWHATWEREYOUTHINKING
<pedronis> do we have machines left over
<mborzecki> something not cleaning up the machines?
<pedronis> zyga: to be fair you created a tons of small PRs it seems
<zyga> or perhaps the many small PRs consumed too much
<zyga> yeah, I think that's it
<zyga> let's wait for this to settle in ~20 mintues
<pedronis> like another round and we are in review sprint territory
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5342 can be merged now
<mup> PR #5342: tests: shellchecks part 4 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5342>
<Chipaca> pedronis: I'm +1 for shared, but gustavo has sometimes objected to it
<zyga> I hope my small packaging fixes can mostly land very fast
<Chipaca> pedronis: but I think we're moving towards mostly-shared, see snapshots for example
<mup> PR snapd#5342 closed: tests: shellchecks part 4 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5342>
<Chipaca> mborzecki: when is the cutover for your shellchecks work?
<Chipaca> mborzecki: by this i mean, when would an 'exceptions' list be shorter than a 'must' list :)
<mborzecki> Chipaca: i think we're at ~40%
<mborzecki> i'll open another batch today
<pedronis> Chipaca: ok, IÂ kept it flat because is flat atm, and also there would be more churn but I can do that if you feel it's better
<pedronis> Chipaca: did you see my questions/comment on ForTerminal ?
<Chipaca> pedronis: I did not
<Chipaca> got the gas inspector in, got a little sidetracked
<pedronis> Chipaca: also if it's snap.StoreAccount it seems even a worse place for ForTerminal, I think we'll have a function with flags or functions in cmd/snap itself instead
<mvo> mborzecki: if you want you can review your/our go-check PR, I tweaked it a little bit to address the concerns that gustavo had and I think its quite nice now
<Chipaca> pedronis: ok
<mborzecki> mvo: i see you've pushed the fix for basic types
<mborzecki> nice
<Chipaca> mborzecki: we need a 'basic types starter pack' meme now
<mvo> mborzecki: yeah, I think/hope its good now
<mvo> mborzecki: it still has the properties we want, i.e. big structs/long strings are nicely diffed
<zyga> https://github.com/snapcore/snapd/pull/5350 is green and trivial, please review
<mup> PR #5350: packaging/opensuse: don't use %-macros in comments <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5350>
<mvo> mborzecki: if it looks good to you I will ask gustavo (either here or in the standup) for a quick look
<zyga> https://github.com/snapcore/snapd/pull/5347 is in the same spot
<mup> PR #5347: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5347>
<zyga> mvo: trivial action on https://github.com/snapcore/snapd/pull/5331
<mup> PR #5331: snapstate: sort "snapd" first <Created by mvo5> <https://github.com/snapcore/snapd/pull/5331>
<mvo> zyga: thanks, will do
<mup> PR snapd#5356 opened: packaging: require snapd.socket in snapd.seeded.service; make sure snapd.seeded.â¦ <Created by stolowski> <https://github.com/snapcore/snapd/pull/5356>
<pstolowski> mvo, mborzecki ^
<pstolowski> btw, systemd didn't like Restart=on-failure, perhaps because it can't be combined with oneshot?
<mvo> pstolowski: silly question, why is the after=snapd.socket not enough?
<pstolowski> mvo: that's a little bit vague, see https://serverfault.com/questions/812584/in-systemd-whats-the-difference-between-after-and-requires
<mborzecki> mvo: after is just ordering, if both seeded.service and snapd.socker are started together, seeded will be ordered after
<pstolowski> "After= configures service order (do X only after Y), while Requires= state dependencies. If you don't specify an order, a service depending on another would be started at the same time as the one it is depending on"
<mborzecki> but if you start seeded.service and socket is not active then it will not be started
<pstolowski> "After= is a "loose coupling"
<mvo> zyga: should your rpm stuff go into 2.33.1 as well?
<mborzecki> pstolowski: right, it may nee to be one of the 'daemon' modes
<zyga> well, the packaging/ directory can be master only
<zyga> there are a few things we could cherry pick once everything lands
<zyga> but I have patches in the tree so not a hard requirement
<zyga> I'm happy if they land in master only
<mvo> mborzecki, pstolowski thanks, I guess I'm missing something. if snapd.seeded is ordered after snapd.socket (which it currently is afaiui) then when snapd.seeded runs it should simply socket activate on snap system-info snapd. or are sockets and services started by systemd in different "runs" ?
<zyga> mvo: thank you for the reviews!
<zyga> https://github.com/snapcore/snapd/pull/5349 needs a 2nd review now
<mup> PR #5349: packaging/opensuse: add missing bits for snapd.seeded.service <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5349>
<zyga> (green and ready)
<mvo> mborzecki, pedronis I guess my question is "why are snapd.seeded, snapd.socket" not started togehter :)
<mup> PR snapd#5350 closed: packaging/opensuse: don't use %-macros in comments <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5350>
<mvo> mborzecki, pstolowski is it because of the different "WantedBy"?
<mvo> mborzecki, pstolowski sorry for the questions, just trying to understand the why behind it
<mborzecki> mvo: my guess is that the seeded target is ordered independenly of the sockets target
<mvo> mborzecki: yeah, I think that makes sense. I would have assumed socket targets run before the normal multi-user though. but its the best theory so far :)
<mvo> as an experiment we could make snapd.seeded wantedby socket.target to see if that also solves the issue
<mborzecki> mvo: or make snapd.socket wanted by seeded target
<pstolowski> i can experiment with that
<Chipaca> why wanted by and not before/after?
<Chipaca> also note wantedby and requires do not imply before/after
<pstolowski> fwtw the spread tests are happy after requires= fix
<Chipaca> so i guess you need both
<Chipaca> requires= and after=
<Chipaca> or wantedby= and before=
<pstolowski> Chipaca: atm (with my PR) we have after= and requires=, yes
<Chipaca> (probably the former)
<Chipaca> good
<pedronis> pstolowski: hi, btw can your disconnect hooks PR be re-reviewed?
<pstolowski> pedronis: not really, there is a spread test failure that may be related to conflict-checks change
<pedronis> ok, ping me when you think IÂ should look again
<pstolowski> pedronis: but if you could take a look at https://github.com/snapcore/snapd/pull/5323 that would be great
<mup> PR #5323: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323>
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/5353 -- I also re-worded the branch description to match the final state
<mup> PR #5353: data/completion: fix inconsistency in +x and shebang <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5353>
<zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5349
<mup> PR #5349: packaging/opensuse: add missing bits for snapd.seeded.service <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5349>
<mvo> I noticed we hit a GCE quota limit for IN_USE_ADDRESSES
<zyga> likely due to the number of PRs in flight
<mup> PR snapd#5349 closed: packaging/opensuse: add missing bits for snapd.seeded.service <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5349>
<zyga> we discussed that above with pedronis a moment ago
<pstolowski> oh wow that's a massive failure https://api.travis-ci.org/v3/job/394476948/log.txt
<pstolowski> cannot allocate new Google server for ubuntu-16.04-32: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1
<pstolowski> etc.
<pstolowski> ah that's what you discussed above
<zyga> mborzecki: thank you for the idea, https://github.com/snapcore/snapd/pull/5347 is now a one-liner
<mup> PR #5347: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5347>
<pedronis> pstolowski: will look at that after lunch
<pstolowski> thx
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5341#pullrequestreview-130331441 is reviewed :)
<mup> PR #5341: cmd/libsnap-confine-private: intoduce helpers for validating snap instance name and instance key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5341>
<mborzecki> zyga: thanks!
<jamesh> mborzecki: for your shellcheck work, what do you think of listing the spread tests that are allowed to fail rather than the ones that are required to pass?
<jamesh> mborzecki: I ask, because I've added new spread tests in some of my branches that failed shellcheck and didn't error out because they weren't listed in the "must" file
<Chipaca> what's the default terminal on kubuntu, xubuntu, lubuntu, mate? <- popey?
<mborzecki> jamesh: hm something to consider, looks like an easy change
<popey> uh
<popey> konsole, dunno about the others
<jamesh> mborzecki: it seems like a check that new tests should be required to pass
<Chipaca> popey: do you have a konsole handy? (as in already installed, at your fingertips)
<popey> yes
<Chipaca> popey: could you run http://paste.ubuntu.com/p/WkK7GSvhfC/ ?
<mborzecki> jamesh: yes, that would be helpful, i could stop reminding people to add their files to must-pass list
<jamesh> mborzecki: it would also make it easier to tell when the job was finished: you'd have an empty file listing the tests allowed to fail.
<mup> PR snapd#5357 opened: firstboot: mark essential snaps as "Required" in the state <Created by mvo5> <https://github.com/snapcore/snapd/pull/5357>
<popey> https://usercontent.irccloud-cdn.com/file/DtIIptAt/Screenshot_20180620_114053.png
<popey> @Chipaca ^
<Chipaca> zyga: what's the easiest way for a machead to run a core image?
<zyga> machead?
<Chipaca> zyga: person with a mac and no ubuntu
<zyga> aaah
<Chipaca> popey: what
<zyga> Mac head
<zyga> :D
<zyga> lol, sorry, I didn't parse that at first
<popey> Chipaca: screenshot above
<zyga> well, those raspberry pi's, Mac-heads love to buy stuff I suspect ;)
<Chipaca> popey: no i mean what happened to the utf8
<popey> no clue
<zyga> Chipaca: more seriously, if you need a VM there are several popular choices
<zyga> VMware fusion, maybe parallels (but I didn't use it and it's a subscription now so bleh)
<Chipaca> popey: all those should be Â«[â¦] Green ââââð¸ð¹Â»
<popey> my bad
<mborzecki> kinkpad ;)
<popey> kde thinkpad -> kinkpad :)
<zyga> kinky
<popey> https://usercontent.irccloud-cdn.com/file/hCiOpnNQ/Screenshot_20180620_114603.png
<popey> better
<Chipaca> thank you
<Chipaca> popey: 18.04?
<popey> sorry, i used the raw text from the pastebin, which was my error
<popey> 16.04
<popey> kde neon
<Chipaca> popey: ok
<Chipaca> popey: and those strings are now the right utf8 thing, in that order?
<popey> i copypasted from the pastebin, so should be as you wrote them
<Chipaca> IOW konsole in 16.04 renders â and â the same?
<zyga> emoji support is much later
<zyga> so that's expected
<popey> yeah, i dont think I've fiddled much with the fonts or anything
<zyga> is cachio around today
<Chipaca> zyga: all of those work acceptably on gnome terminal in 16.04, fwiw
<zyga> I wonder if spread somehow forgets to release IP addresses
<Chipaca> zyga: no, cachio  is not around today
<zyga> maybe after the issue we had lately
<zyga> we killed all the stray VMs
<zyga> but not their addresses
<zyga> sseessesses
<zyga> ss... ss..
<zyga> I need a coffeee
<zyga> eee
 * zyga stops
<Chipaca> Wimpress: are you around?
<zyga> mvo: do you have permissions to see IP address allocations?
<popey> Chipaca: he's on a call
 * Chipaca installs mate-terminal
<mvo> zyga: I don't think so
<mup> PR snapd#5358 opened: tests: add spread test to ensure snapd/core18 are not removable <Created by mvo5> <https://github.com/snapcore/snapd/pull/5358>
<ogra_> do we ignore user preferences if interfaces do autoconnect (and do we have a bug for that if this is the case) https://forum.snapcraft.io/t/snap-premissions-automatic-resets/6021
<pedronis> ogra_: we had a bug about that what pstolowski landed a fix I think (don't remember when)
<ogra_> well, smells like this user didnt get the fix yet ... unless it is really a UI only issue
<pstolowski> ogra_, pedronis it landed in master on may 18th - https://github.com/snapcore/snapd/pull/4551
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<ogra_> ah, so not in any stable release yet, that explains it
<zyga> I guess PRs are stuck in limbo now
<zyga> waiting to go over 49 minute mark
<zyga> let's not open new PRs
<zyga> or re-start anything
<zyga> until this clears
<mup> PR snapd#5250 closed:  interfaces/udev,misc: only trigger udev events on input subsystem as needed <Reviewed> <Squash-merge> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5250>
 * zyga -> lunch
<mup> PR snapd#5359 opened: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5359>
<mborzecki> jamesh: ^^
<mup> PR snapd#5360 opened: tests: fix shellcheck 0.5.0 warnings <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5360>
<zyga> hmm
<zyga> I think gce is very unhappy now
<zyga> mvo: I'll postpone suse work until I can land the rest of the things to master
<zyga> mvo: switching to interfaces in core18
<mvo> zyga: yay!
<zyga> as we discussed yesterday
 * mvo hugs zyga 
<mup> PR snapd#5361 opened: snapstate: allow removal of snap.TypeOS when using a model with a base <Created by mvo5> <https://github.com/snapcore/snapd/pull/5361>
<pedronis> yes, gce issues are a bit blocking work atm
<zyga> Murphy strikes :)
<zyga> when Sergio is off, clouds rain
<zyga> Pharaoh_Atem: can you please have a look at a suse packaging change: https://github.com/snapcore/snapd/pull/5351
<mup> PR #5351: packaging/opensuse: build position-independent binaries <Created by zyga> <https://github.com/snapcore/snapd/pull/5351>
<mup> PR core18#33 opened: hooks: install net-tools package <Created by mvo5> <https://github.com/snapcore/core18/pull/33>
<zyga> mvo: I'm -1 on that
<mborzecki> hm sergio off, but argentina plays their match only tomorrow ;)
<mvo> zyga: yeah, thats fine. I was a bit split about it myself
<zyga> mvo: I replied on the thread
<pedronis> is a national holiday today there
<mborzecki> i'm contemplating switching the shellcheck test to run on arch instead of 18.04, i don't really feel like building shellcheck from source
<mborzecki> pedronis: what kind of holiday?
<pedronis> IÂ don't know
<mup> PR core18#33 closed: hooks: install net-tools package <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core18/pull/33>
<mborzecki> :D
<ogra_> chocolate appreciation day :)
<pedronis> Flag Day apparently
<ogra_> (or was it cheese)
<mborzecki> ogra_: fondue?
<zyga> mborzecki: cough, snap it, cough
<ogra_> lol
<mup> PR core18#30 closed: hooks: clenup /etc/{passwd,shadow,group,gshadow}.orig <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/30>
<zyga> mvo: as I'm thinking about core18
<zyga> mvo: can we please ship locales-all and see how big that becomes
<sil2100> mvo: what do you think about https://github.com/snapcore/core18/pull/24 now ?
<mup> PR core18#24: Add the systemd-sysv package for tools like shutdown and reboot <Created by sil2100> <https://github.com/snapcore/core18/pull/24>
<zyga> mvo: I can take that if you don't NACK it
<zyga> mvo: locales sans .mo files, that is
<mvo> zyga: I tried that and it was huge, let me try again
<zyga> if you teach me how to try I could do too
<mvo> sil2100: let me check, thanks for the update
<zyga> mvo: I'm only after the locale catalogs
<zyga> mvo: since apps can relatively easily ship .mo files
<zyga> (eventually)
<mborzecki> zyga: that might not be such a bad idea after all, only nit is that it's in haskell probably pulls in several GB of packages just for the build
<sil2100> zyga: just modify the hook for additional packages and you can add locales-all there - then just build it
<zyga> but shipping basic locale would let us fix a class of bugs
<sil2100> mvo: you doing that or should I check how the size changes?
<sil2100> (to save you time)
 * zyga hugs sil2100 and mvo
<zyga> seems this is in good hands
<Wimpress> Chipaca: I am now
<zyga> I'll go back to interfaces
<Chipaca> Wimpress: too late har har, too late har har
<Wimpress> Sorry.
<mvo> sil2100: feel free to test it yourself, I have a meeting in 3min
<sil2100> mvo: building with locales-all to compare the size
<mvo> sil2100: thank you!
<mvo> sil2100: I also update the cleanup PR now
<zyga> Pharaoh_Atem: thank you! I'll update that
<sil2100> mvo: same here, although depends if I'll have my sprint load at the same time or I'll be able to get to the snappy one
<sil2100> mvo, zyga: by installing locales-all just the snap size increased by 11 MB
<zyga> \o/
<zyga> that's _neat_
<zyga> thank you
<zyga> and if you strip the .mo files?
<sil2100> Checking!
 * Son_Goku still bemoans the poorly named core* snaps
 * zyga hugs Son_Goku agreeing 
<Son_Goku> that's probably going to be one of those things I'm not ever going to let go
<Son_Goku> like the dumb thing with /snap
<zyga> mvo: comment https://github.com/snapcore/snapd/pull/5361#pullrequestreview-130386914
<mup> PR #5361: snapstate: allow removal of snap.TypeOS when using a model with a base <Created by mvo5> <https://github.com/snapcore/snapd/pull/5361>
<mup> PR snapd#5362 opened: tests: use "ss" instead of "netstat" (netstat is not available in cor18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5362>
<mvo> thanks zyga :)
<mvo> zyga: will reply after the standup
<zyga> ok
<mup> PR snapcraft#2163 closed: tests: add lifecycle ordering tests <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2163>
<zyga> sil2100: did you get that number without .mo files?
<mborzecki> Chipaca: yay, getting consistent results with shellchek from snap :P
<sil2100> zyga: not yet! We're still eh, sprint loading
<zyga> no worries
 * zyga wonders what is "sprint loading"
<zyga> in a bus waiting to fly?
<sil2100> zyga: I'll have it in a few, just need to run the build
<sil2100> zyga: it's like, loading tasks we're going to work on during the next 2 week 'sprint' ;)
<mup> PR snapcraft#2164 opened: add support for the "website" field in snapcraft <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2164>
<zyga> aah
<sil2100> 'loading' == 'committing to working on them'
<om26er> Wimpress: ping
<sil2100> zyga: oh, there's actually no .mo files installed
<sil2100> Not by this package or it's dependencies
<zyga> sil2100: thank you
<mup> PR snapd#5354 closed: packaging/opensuse: ship apparmor integration if enabled <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5354>
<sil2100> I was wondering why my hook wasn't changing the size, and well, it's because it wasn't removing anything
<zyga> Thank you for checking. This is useful data
 * zyga -> afk
<Chipaca> mborzecki: huzzah
<mborzecki> Chipaca: if you feel like reviewing a bit then #5359 and #5360 need some attention :)
<mup> PR #5359: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5359>
<mup> PR #5360: tests: fix shellcheck 0.5.0 warnings <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5360>
<Chipaca> mborzecki: I never* don't feel like reviewing
<Chipaca> mborzecki: question: why not parser.add_argument('--can-fail', default=os.getenv('CAN_FAIL', None)) ?
<mup> PR snapcraft#2165 opened: many: automatically detect dependency changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2165>
<pedronis> mvo:  Chipaca: using "-"  for no publishers break yaml parsing, which we use in  the snap info test
<Chipaca> pedronis: hah
<Chipaca> pedronis: we use em dash for that in yaml output
<Chipaca> pedronis: :)
<mborzecki> hm a list item
<pedronis> Chipaca: in info ?
<Chipaca> pedronis: yes
<pedronis> ah
<Chipaca> pedronis: sorry, an en dash
<Chipaca> 					version = "â" // that's an en dash (so yaml is happy)
<mvo> Chipaca: nice
<pedronis> Chipaca: only in info though, right? the other places use "-"
<Chipaca> pedronis: yes
<pedronis> Chipaca: thx
<Chipaca> that, and uparrow, and horizontal ellipsis, are all in the default linux console font
<Chipaca> mvo: :-)
<mborzecki> Chipaca: thanks for the reviews
<Chipaca> mborzecki: thanks for the code :)
<Chipaca> the switch from whitelist to blacklist makes me happy
 * Chipaca is easy to please
<niemeyer> Okay, spread -gc seems to be working well, and spread in Travis was updated so it reports properly the job it's running for..
<niemeyer> Please let me know if you see any bugs there
<niemeyer> Lunch
<mup> Issue core18#4 closed:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#24 closed: Add the systemd-sysv package for tools like shutdown and reboot <Created by sil2100> <https://github.com/snapcore/core18/pull/24>
<mup> Issue core18#4 opened:  Crash qt gui aplication (build with core 18 on ubuntu 18.04(LXD))  <Created by EndrII> <https://github.com/snapcore/core18/issue/4>
<mup> PR core18#24 opened: Add the systemd-sysv package for tools like shutdown and reboot <Created by sil2100> <https://github.com/snapcore/core18/pull/24>
<kyrofa> mvo, regarding https://github.com/snapcore/snapcraft/pull/2164, is that actually supported in snapd? The thread to which you linked leads me to believe something isn't quite done there
<mup> PR snapcraft#2164: add support for the "website" field in snapcraft <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/2164>
<cachio> niemeyer, hey, last change in spread is breaking axecutions
<kyrofa> pedronis, what do you mean when you say website is not fully exposed to snapd?
<cachio> niemeyer, https://travis-ci.org/snapcore/snapd/builds/394581202#L791
<pedronis> kyrofa: the  APIs that snapd use don't all habe website as  a field
<cachio> it is making fail all the travis builds
<pedronis> kyrofa:  it's not a snapcraft side issue afaiu
 * cachio afk
<kyrofa> mvo, pedronis, jdstrand will the review tools let website through?
<pedronis> that IÂ don't know, likely not
<pedronis> jdstrand is on holiday this week
<kyrofa> We need to start using cross-project bugs for this stuff, we need to coordinate better
<pedronis> to be fair this was a bit mvo chomping at the bit
<kyrofa> Yeah... and it doesn't work, but I'll ignore that ;)
<mvo> kyrofa: its not there on the snapd side yet either
<kyrofa> mvo, haha!
<pedronis> afaiu  this is partly supported by the store and metadata api, but not snapcraft ? or is supported by snapcraft but not over snap.yaml?
<kyrofa> pedronis, snapcraft doesn't support a website field at all right now. Other than that, this is the first of heard of it, so I don't know the rest
<kyrofa> Note that passthrough is available if folks are just wanting to test it out
<pedronis> there's a forum topic with some discussion it (and store does support it)
<pedronis> but don't think there was even agreement on the topic itself
<kyrofa> Indeed, I read it, and came away shrugging :P
<mborzecki> 2018-06-20 14:50:44 Cannot allocate google:ubuntu-18.04-64: cannot allocate new Google server google:ubuntu-18.04-64 (jun201446-697464): cannot find ready marker in console output for google:ubuntu-18.04-64 (jun201446-697464)
<mup> PR snapcraft#2164 closed: add support for the "website" field in snapcraft <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapcraft/pull/2164>
<Chipaca> mborzecki: that's google speak for "EOD byeeee"
<pedronis> Chipaca: I updated #5352
<mup> PR #5352: many: expose full publisher info over the snapd API <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5352>
<Chipaca> pedronis: oh no
<Chipaca> :)
<Chipaca> pedronis: thank you
<Chipaca> pedronis: wee, you even did the 'be more structured' thing :-D
<abeato> niemeyer, hi, a new review is needed in https://github.com/snapcore/snapd/pull/5309 :)
<mup> PR #5309: overlord/configstate: add watchdog options <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5309>
<mup> PR snapd#5348 closed: packaging/opensuse: snap-confine should be 06755 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5348>
<pedronis> niemeyer: gce has started given a different kind of error, what mborzecki posted above
<niemeyer> Oops.. will have a look shortly
<Chipaca> mborzecki: is there a 'glxgears'-like snap?
<popey> omgiraffe is the new glxgears
<popey> :)
<Chipaca> :)
<Chipaca> popey: what's missing is that ohmygiraffe has a lot of dependencies that a simple GL thing doesn't have
<popey> yeah, true
<Chipaca> i'm not after a "is gl working", but rather a "minimal snap that works with opengl that i can steal from"
<Chipaca> :)
<Chipaca> my usual technique of copying stuff until ldd stops complaining is not working
<Chipaca> it's almost as if I should use snapcraft
 * Chipaca ponders that
<popey> http://paste.ubuntu.com/p/kYpjSMWWnd/
<popey> lddtostage  script
<popey> point it at a binary, it tells you what packages you need in stage-packages
<Chipaca> heh :)
<Chipaca> popey: it says I should stage 'nvidia-384'
 * Chipaca doubts
<niemeyer> I see the bug
<niemeyer> mborzecki, pedronis: Please give it another shot
<niemeyer> abeato: Thanks for the changes
<niemeyer> abeato: Submitted a last round of details there
<mborzecki> Chipaca: graphics-debug-tools-bboozzoo, it includes glxinfo, eglinfo, vulkaninfo and xrandr
<Chipaca> mborzecki: i'd forgotten about those! thanks
<abeato> niemeyer, great, thanks
<niemeyer> mborzecki: Is it working now?
<thiras> https://github.com/snapcrafters/discord/issues/35
<mborzecki> niemeyer: yup, PRs are slowly getting green
<niemeyer> \o/
<zyga> re!
 * zyga is done with doctors for a while
<zyga> and all is good
<zyga> and I can (I think) focus on work now
<niemeyer> zyga: Congrats! :)
<zyga> niemeyer: haha, thank you :)
<zyga> we are all happy and now much calmer
#snappy 2018-06-21
<mborzecki> morning
<mup> PR snapd#5360 closed: tests: fix shellcheck 0.5.0 warnings <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5360>
<zyga> good morning
<zyga> I will be here shortly
<mborzecki> zyga: hey
<zyga> hey, just getting a coffee
<zyga> can I get an ack for https://github.com/snapcore/snapd/pull/5347
<zyga> ready and green just needs a review
<zyga> well
<zyga> an ack
<mup> PR #5347: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5347>
<mup> PR snapd#5347 closed: data: remove /bin/sh from snapd.sh <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5347>
<zyga> hey sil2100
<zyga> mborzecki: can you have a quick look at https://github.com/snapcore/snapd/pull/5355
<mup> PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355>
<mborzecki> anyone wants to do a 2nd review on #5359 ?
<mup> PR #5359: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5359>
<mborzecki> once this lands i have another pr that uses shellcheck from snap, although in --devmode because of our setup
<zyga> I can :)
<zyga> I restarted various failed PRs from yesterday
<zyga> mborzecki: can I add type annotations to spread-shellcheck?
<zyga> in a follow-up
<zyga> and make it mypy clean?
<zyga> nothing like static typing :
<zyga> :)
<mvo> zyga: pfff, you work on interfaces for core ;)
<mvo> core18
<zyga> mvo: yes, that's almost done though :)
<zyga> but good point :P
<mvo> zyga: aha! thats cool
<mvo> zyga: first the chores, then the fun :P
<mborzecki> zyga: sure
<pstolowski> mornings
<mvo> zyga: but thats great to hear, I look forrward to working tests and then we can run spread again on core18
<mvo> hey pstolowski ! good morning
<zyga> hey pawel
<pedronis> mvo: hi, could you re-review 5352 when you have a bit some time
<mborzecki> btw. it'd be nice to have an interface that allows access to arbitrary paths, and have those paths added/configured as a list per connection
<zyga> mborzecki: I had something like this planned a while ago
<mborzecki> pedronis pstolowski: morning guys
<mvo> pedronis: absoutely, thank you!
<mvo> pedronis: and good morning :)
<zyga> my desire then was to have an snapctl api where a snap could talk to snapd and create interfaces
<zyga> so "hot plug" like but snap (not snapd) driven
<mvo> pedronis: its even green! how did you manage that given the stormy spread weather we had :) ?
<zyga> that idea died though, we could do something different with a new interface
<pedronis> mborzecki: the problem is that unless we tied it down in the snap declaration (but gets annoying), is really access to any path
<zyga> pedronis: my idea was that you could only select a subset of home
<zyga> so it would be like scoped home
<pedronis> ok, that's different from what mborzecki proposed
<pedronis> though
<pedronis> mvo: thanks, marked it blocked until IÂ can discuss something with the store people, mostly wondering if there's a chance client StoreAccount and then one internal/from store can diverge
<mvo> pedronis: heh, I almost merged it. good that I was unusually not trigger happy this morning
<pedronis> mvo: nothing too bad if it was merged, mostly wondering if we need to StoreAccounts or using just one is ok
<pedronis> in most uses of client should be immaterial either way
<pedronis> s/to/two/
 * mvo nods
<pedronis> mvo: when will we cut 2.34 ?  from discussions from yesterday it seems there was a couple of things still desired for it
<mvo> pstolowski: did you got a chance to play a bit with 5356, i.e. the bits we brainstormed yesterday to figure out why exactly its is not working
<mvo> pedronis: I think early next week
<mvo> pedronis: we need a 2.33.1 with some adt fixes
<pedronis> ok
<mvo> pedronis: so maybe middle next week even
<mvo> pedronis: what is pending from your pov?
<pedronis> mvo: afaiu understand  work to get better errors if a snap is missing from arch or channel,  and expanding searches to other risks
<pstolowski> mvo: no, i wanted to have full spread tests suite run first (which wasn't possible due to gce)
<pedronis> mvo: the first bit should be in store prod now, the 2nd soon
<pedronis> but need snapd work
<pedronis> mvo: and I have  my gadget connect PR that needs a review from you :)
<mvo> pedronis: thats exciting - is the store read for the better errors?
<mvo> pedronis: aha, you replied, cool
<mvo> pedronis: yeah, I need to do that review, will do it this morning
<mvo> pstolowski: heh, yeah, a bit of a storm yesterday
<mvo> pstolowski: thank you
<mvo> pedronis: I'm quite excited about the error messages, where can I learn more where we stand and what changed?
<pedronis> mvo: we have a bit of a problem there though,  related to our own API errors,  we set Value just to snapName in the relevant errors, so a bit unclear where to stick the extra info... we can put in the better message but is not ideal for all clients
<mborzecki> zyga: pedronis: hm i thought about arbitrary, user set, paths, as in something that neither fits the removable-media, nor home interfaces and the location is kind of oustide of your control
<pedronis> mborzecki: as I said, it's doable but unless we have corresponding control in the snap-declaration, is really a blank check. the developer controls what goes into her snap.yaml
<mborzecki> in case of shellchecks, shellcheck snap comes with home and removable media interfaces, but the tests are run as root and the source code is at /home/gopath, i could probably hack around with some bind mount or just use --devmode (and open up everything?)
<pedronis> mborzecki: ah, user set
<pedronis> mmh, we don't have anything like that
<pedronis> it would add quite a bit complexity to the machinary
<mborzecki> pedronis: yes
<mborzecki> we can discuss it over a glass of beer while in BRU :)
<pedronis> mvo: about your question, we get a bit like this:                               'extra': {
<pedronis>                                   'releases': [{'architecture': 'amd64',
<pedronis>                                                 'channel': 'beta'}]}
<pedronis>                               },
<pedronis>  in revision-not-found errors
<mvo> pedronis: nice!
<pedronis> mvo: as I said, the problem is that we don't have a place to stick it in our own API errors
<pedronis> mvo: https://github.com/snapcore/snapd/blob/master/daemon/response.go#L368 the way we set directly Value: snapName is the problem, changing that is backward incompatible
<mvo> pedronis: in our own snapd api errors? hm, hm, ok. could we just invent an "extra" field as well (just thinking out loud)?
<pedronis> yes, but it a bit of a kludge, basically we had one (Value) but we used it a bit naively
<mvo> pedronis: could we invent new types? errorKindSnapRevisionNotAvailableWrong{Arch,Channel} - I guess old clients would not show a nice error with that but usually snap/snapd will be in sync so its just ugly for a minority ?
<pedronis> we can also do that
<mvo> pedronis: what approach do you like best :)?
<pedronis> none :)
<mvo> heh
 * mvo scratches head then
<mvo> pedronis: sounds like something to talk about during the standup to figure out the least disliked option
<pedronis> yes
<pstolowski> mborzecki: can you take another look at https://github.com/snapcore/snapd/pull/5323 ?
<mup> PR #5323: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5323>
<pedronis> mvo: fwiw  snapd-glib doesn't support yet explicity snap-revision-not-available
<pedronis> also doesn't seem to use "value" at all from errors
<Chipaca> zyga: good morning. Chinese is not a language.
<zyga> yeah I know, it's a simplification ;)
<Chipaca> zyga: :)
<zyga> how do I spell the M... thing?
<Chipaca> zyga: Mandarin
<Chipaca> zyga: unless you meant Mapudungun
<zyga> hehe
<zyga> does it have as many users? :)
<zyga> fixed
<Chipaca> zyga: Mapudungun has 260k native speakers
<Chipaca> approx
<zyga> that's still more than the people who refuse to use systemd ;P
<Chipaca> zyga: but like the non-systemd users, they're being oppressed
<Chipaca> ok that turned the wrong way and I shall go sit in silence and think about my sins for a bit
<Chipaca> zyga: how hard would it be to have a script that you ran on a system and it told you all the ways in that snapd would fail to run?
<zyga> Chipaca: that's interesting,
<zyga> well, some of that is in the new self-test work that mvo started
<zyga> no systemd, wonky kernel
<Chipaca> like, "your apparmor was not shipped in slackware 1.0 because it was too old", etc
<zyga> old apparmor userspace is another thing to check for
<zyga> or "Slackware hates systemd, sorry"
<Chipaca> non-linux kernel
<zyga> are you after a shell script?
<zyga> over golang?
<Chipaca> zyga: ideally :)
<Chipaca> android userspace
<zyga> mmm
<pedronis> mvo: tried to answer your questions
<Chipaca> 2MB usable ram
<zyga> Chipaca: we could try
<zyga> Chipaca: eventually that script could wget snapd.snap ;)
<Chipaca> ssshhh
<Chipaca> all the squashfs stuff, the mount crashes fixes
<Chipaca> dunno how to test for the latter
<Chipaca> anyway. Good morning.
<zyga> good morning :)
 * Chipaca brought donuts to the office
<zyga> oh, you are at the office today?
<Chipaca> â¦ ok, my bedroom
<Chipaca> FINE
<zyga> ah :(
<zyga> well
 * zyga looks around at his "office"
<Chipaca> :)
<zyga> I just envied you for a brief moment
<Chipaca> ah, no, i'm happy like this, mostly
<mup> PR snapd#5323 closed: ifacestate: prevent running interface hooks twice when self-connecting on autoconnect <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5323>
<zyga> I sometime miss the office
<zyga> if we had one in Warsaw I'd use it a few days a week
<zyga> (lugging my iMac on the bus ;)
<Chipaca> me too, but it takes one morning to commute in and i'm over it
<Chipaca> (every ~6 months or so)
<zyga> I need to try
<zyga> I'll find some cheap flight to UK and commute once ;)
<Chipaca> OTOH, I could totally build an office in a van and go visit people
<zyga> hahaha
<mvo> pedronis: thank you! as for the second resolveSnapIDToname, I was mostly wondering if we should have a gadget-connect test that uses the "system" name explicitly but maybe overkill
<mborzecki> Chipaca: feel like tackling the traveling salesman problem irl?
<Chipaca> mborzecki: I suck at sales
<Chipaca> mborzecki: but other than that, sure :)
<pedronis> mvo: well, it is explicit  for that level of code,  already the parsing makes all entries non empty
<mvo> pedronis: ok
<Chipaca> "yeah i'm here to show you this thing we built, which is cool, it's got all these issues [ three hours later ] pay me
<pedronis> mvo: that is code from the previous PR
<pedronis> slot is really system:network-control at that point of the code
<mvo> pedronis: aha, that was the missing piece then - I remember now
<pedronis> mvo: adding the comment, IÂ need to merge master anyway because of Name vs InstanceName
<mvo> pedronis: thank you
<Chipaca> zyga: in distros that don't have /snap/bin, what's added to PATH?
<zyga> Chipaca: /var/lib/snapd/snap/bin
<zyga> it's the same
<zyga> I mean, the same script
<zyga> ugly, no?
<Chipaca> zyga: dunno if you're talking about #5355 but I was
<mup> PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355>
<zyga> ah
<zyga> I'll do that
<zyga> thanks, I'll push this branch in a moment
<zyga> I'm moving all suse machines from drive to drive so they are suspend now
<Chipaca> zyga: you have way too much fun for it to be legal
<zyga> such as?
<Chipaca> zyga: moving suse machines around
<zyga> I can hear the disks clicking
<mup> PR snapd#5351 closed: packaging/opensuse: build position-independent binaries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5351>
<Son_Goku> zyga, dammit I'm blind
<zyga> oh?
<Son_Goku> https://github.com/snapcore/snapd/commit/e21034320459354b8acd9d1c194946ceda363a6e#diff-36a23153f5bbd7bffd11c24597ac50fdR146
<Son_Goku> I don't know _how_ that's valid shell
<Son_Goku> it should have barfed again this time
<zyga> thanks!
<zyga> I'll fix it... in about 10 minutes when the copy is over
<Son_Goku> haha
<mup> PR snapd#5363 opened: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
<mborzecki> pedronis: this should be fairly uncontroversial ^^
<mborzecki> gnome shell actively not taking input because it's too busy dumping backtraces from js :(
<mup> PR snapd#5364 opened: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5364>
<zyga> mborzecki: review on https://github.com/snapcore/snapd/pull/5363#pullrequestreview-130726810
<zyga> Pharaoh_Atem: fixed, thank you!
<mup> PR #5363: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
<mborzecki> zyga: thanks!
<mup> PR snapd#5359 closed: spread-shellcheck: use a whitelist of files that are allowed to fail validation <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5359>
<mup> PR snapd#5357 closed: firstboot: mark essential snaps as "Required" in the state <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5357>
<mvo> reviews for 5361 would be great, should be straightforward and unblocks some more spread runs
<mvo> 5339 is also updated but that is a bit annoying to reivew (too much shell) :/
<zyga> Chipaca: one final look at https://github.com/snapcore/snapd/pull/5355/
<mup> PR #5355: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <https://github.com/snapcore/snapd/pull/5355>
<mvo> pedronis: a quick look my comment in 5331 would be great, if it captures enough information why we sort snapd first
<pedronis> mvo: which reminds that sorting is not enough
<pstolowski> mborzecki: thanks for the inisght into systemd seeded PR
<pedronis> mvo: we need to tweak also the code here  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L806
<pedronis> to consider snapd in both sides of the if
<mborzecki> pstolowski: iirc we stop all snapd* services in prepare, maybe that's why it's inactive/dead in your test
<mvo> pedronis: indeed
<zyga> mvo: done
<mvo> zyga: thank you
<zyga> mvo: conflict on https://github.com/snapcore/snapd/pull/5358
<mup> PR #5358: tests: add spread test to ensure snapd/core18 are not removable <Created by mvo5> <https://github.com/snapcore/snapd/pull/5358>
<mvo> zyga: thanks, looking
<mvo> mborzecki: thank you as well for the review!
<mup> PR snapd#5353 closed: data/completion: fix inconsistency in +x and shebang <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5353>
<mup> PR snapd#5365 opened: spread-shellcheck: use the latest shellcheck available from snaps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5365>
<mup> PR snapd#5317 closed: overlord: introduce a gadget-connect task and use it at first boot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5317>
<pedronis> pstolowski: hi, IÂ merged my gadget-connect branch, that means I fear conflicts for the disconnect hooks one
<pstolowski> pedronis: ack, thanks for heads up
<mvo> 5361 needs a second revie wnow
<mvo> (really simple :)
<mup> PR core18#24 closed: Add the systemd-sysv package for tools like shutdown and reboot <Created by sil2100> <Merged by mvo5> <https://github.com/snapcore/core18/pull/24>
<mvo> zyga: you asked about locales all - when I just add this package the snap grows by 12mb
<zyga> yeah, sil2100 did the experiment yesterday
<mvo> zyga: aha, I missed the results
<zyga> I would like to consider it, for the sake of making locale not suck again
<zyga> snap authors cannot really do it inside snaps, from what I know
<sil2100> I'll try looking into slimming down the core18 snap
<sil2100> Maybe then we'll feel less sad with the additional 11-12MB
<sil2100> (hello btw. o/)
<mvo> sil2100: yay, please do
<zyga> sil2100: is the new data _solely_ inside /usr/share/locale?
<zyga> sil2100: a diff of list of files would be awesome if you have one handy
<sil2100> zyga: yes, it's just /usr/lib/locale/*
 * sil2100 goes AFK now to argue with some bad people
<mvo> zyga: and its massive, du -s | sort -n shows that its a whole lot of 1-3mb files
<zyga> mvo: iff 11MB is what we need to make snaps talk languages maybe that's not _so_ bad
<zyga> I mean, the size is tiny in comparison to anything modern, just the download size is a problem
<zyga> we should have a hello-i18n snap
<zyga> that uses python and get text
<zyga> or something that was problematic lately
<zyga> (or actually have one set of .mo files and use many implementations to test stuff)
<Son_Goku> zyga, unrelated, but...
<zyga> yeah?
<Son_Goku> from #fedora-devel:
<Son_Goku> [05:58:33 AM]  <sfix>	the selinux kernel code is slowly growing support for namespaces, so we might see policies in flatpak sometime in the future.  i think the existing container-selinux package could be used to create flatpak-specific policies though, but would probably need some upstream support to determine how you label the process
<mvo> pstolowski: 5356 seems to be failing, I guess that is on your radar?
<mvo> pstolowski: the fix for snapd.seeded
<Son_Goku> zyga, my understanding is that namespaced labels are the key to making selinux confined snaps work
<pstolowski> mvo: yes i'm looking at right now. it's interesting
<mvo> pstolowski: (sorry for being a bit pushy here)
<zyga> Son_Goku: no, I don't think that's critical
<Son_Goku> no?
<zyga> Son_Goku: note that apparmor and namespaced labels are not important either
<zyga> just when you have multiple containers
<zyga> then it is important
<Son_Goku> wouldn't it be necessary for running LXD or Docker as a snap?
<zyga> the most important first step on the topic of snapd and selinux is how the hell to get started :)
<zyga> Son_Goku: I don't know
<Son_Goku> well, mvo, lvrabec, and pmoore are in a mail convo about that
<Son_Goku> though mvo has been bad about not responding to them :/
<Son_Goku> I finally bit the bullet and did yet another response that I feel was probably not terribly helpful :/
<mborzecki> zyga: iirc we've discussed overlayfs some time ago
<mvo> Son_Goku: yes - sorry for that
<Son_Goku> zyga, the SELinux warnings and denials have reached the point that the Red Hat SELinux guys would like to help us
<Son_Goku> but I can't do anything to make this better, because I'm too incompetent to figure out how the security model works
<Son_Goku> and I'm stretched really thinly right now
<zyga> Son_Goku: oh, interesting,
<zyga> Son_Goku: do you have any names I could ping?
<Son_Goku> mvo has them
<zyga> cool, I didn't know about this
<Son_Goku> mvo, please reply to them with some useful info and CC zyga
<zyga> eventually we could patch our test suite so that no _new_ warnings are introduced
<Son_Goku> zyga, are you not following selinux@ and devel@ on lists.fp.o?
<zyga> Son_Goku: I'm subscribed but man, I'm not following my inbox much
<zyga> too many things lately
<Son_Goku> zyga: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/U6JJ3IIJNNGGDZECSIMZC5UODAECCWPT/
<zyga> mborzecki, mvo: what about instance installation of snapd?
<mborzecki> zyga: what do you mean?
<zyga> can we snap install snapd_foo
<zyga> and if so, what shall that mean?
<mborzecki> no, it will be blocked
<mborzecki> kernel, gadget, core & snapd snaps are non parallel installable
<mborzecki> s/core/os/
<Chipaca> mborzecki: but you can parallel-install base snaps?
<mborzecki> i suppose not, don't think that would be useful
<Chipaca> mborzecki: maybe just clamp it to apps and ""
<Son_Goku> I think you're inviting trouble with instance installs of snaps
<Son_Goku> what problem are you trying to solve here?
<Chipaca> Son_Goku: it's our 3rd most requested feature afaik
<Chipaca> Son_Goku: after world peas and universal healthcare
<Son_Goku> I don't know if we should make "world peas"
<Son_Goku> :)
<Chipaca> :D
<Chipaca> Son_Goku: split pea and ham soup tho
<Son_Goku> haha
<Chipaca> or just split pea soup
<mborzecki> mvo: what was the failure with parsing losetup output?
<zyga> ohh
<zyga> mvo: fun issue
<zyga> https://www.irccloud.com/pastebin/ACep9bL8/
<zyga> base policy needs love now
<zyga> mvo: to fix this it would be _really_ nice to have slot-snap-type: snapd
<zyga> that is, a dedicated type for snapd snap
<zyga> WDYT?
<zyga> pedronis: ^
<Son_Goku> zyga, can I not have a snapd snap installed?
<Son_Goku> it's going to be dead code on my system
<zyga> Son_Goku: no, it's mandatory because otherwise the code would be even more hairy
<zyga> and it's not dead code entirely, as it interacts with snap-exec and snapctl at runtime
<zyga> (they are taken from the snapd snap)
<Son_Goku> but using the snapd you guys build breaks things :/
<Son_Goku> that's why we have to disable re-exec for every distro except Ubuntu
<mvo> mborzecki: it will give me /dev/loop4 but I need /dev/mapper/loop4p3
<zyga> we won't use snapd but we will use other files from the snapd.snap
<Son_Goku> does that mean that patches against those binaries on the host are basically ineffective, then?
<zyga> they are today
<Son_Goku> :/
<zyga> there's a lot of non-trivial stuff involved
<zyga> and edge cases that are easy to miss
<pedronis> zyga: we need to discuss, adding a type like that doesn't make a lot of sense. really in that context "core" means system
<mvo> mborzecki: don't get me wrong, I'm not opposed to fix it, just want to get this PR landed to make the followups smaller (and its not worse than before arguable at least)
<zyga> pedronis: it's that or patching the policy checker to imply   that snap name "snapd" has magic type "core"
<pedronis> zyga: well, we cannot use the name
<zyga> ?
<pedronis> we really need to use the snap id at that level
<zyga> woah, so what can we use?
<zyga> that won't fly
<mborzecki> mvo: no worries, just wondered if there's something fishin in losetup output there, and if so i can take a look at it later
<zyga> store changes and all that
<zyga> I mean, staging vs prod
<zyga> I really like the simplicity of snap type
<zyga> if name is a no-go then we need to discuss how this ought to work
<pedronis> snap type needs store changes too
<pedronis> and review-tools changes
<zyga> when I said store changes I meant snapd talking to prod store or staging store
<zyga> I agree that a new type needs store side changes
<pedronis> I know
<zyga> hmm
<zyga> mvo: ^ this blocks further work for now unless there's some magic way I can patch the policy for now
<zyga> virtual system snap was not blocked this way because it was never installed and thus never verified
<mvo> zyga: hm, hm, ok, lets discuss in the standup, but that is unfortunate. I'm not familiar enough with the details yet so I'm not sure what to do. I guess we can't simply add an exception at this point?
<mvo> zyga: special case I mean
<zyga> not sure where
<pedronis> we can cheat for a bit, but to be honest even the old system with type was a bit fragile
<zyga> my plan was to simply allow snap name "snapd"
<pedronis> the fact you can have different things installed
<pedronis> in different cases
<pedronis> doesn't make it better
<zyga> mvo: I can add the snapd id of "snapd" to all the built-in interfaces for now
<zyga> but that's ugh
<pedronis> don't think we want to change the policies
<pedronis> themselves
<mvo> zyga: yeah, that sounds not nice(tm)
<zyga> pedronis: do you mean the built-in policy?
<pedronis> IÂ mean whatever we do
<pedronis> IÂ don't think we want to change the snippets
<pedronis> (too annoying)
<zyga> pedronis: so what would you change?
<mborzecki> zyga: where was that check for partial apparmor support on tumbleweed?
<pedronis> zyga: we have lots of options
<zyga> mborzecki: interfaces/apparmor/backend.go
<zyga> pedronis: like?
<mborzecki> zyga: got it, thanks!
<pedronis> zyga: we can some change in policy/helpers.go
<zyga> right, I was asking for the idea what to look for; my initial instinct was to just look at snap name but I think you said that would be invalid (since we cannot trust it)
<zyga> one more idea is to perhaps tag implicit interfaces somehow
<zyga> and skip validation
<pedronis> zyga: you can use the relevant snap ids in the place we check for type
<pedronis> will create problems for tests tough
<zyga> so would that be hard-coding the well-known ID of snapd in the policy?
<pedronis> zyga: not in the policy
<pedronis> in the policy code
<zyga> right
<zyga> that's what I meant (policy/)
<pedronis> for a bit at least
<pedronis> we might in the end need a type
<pedronis> then we just translate that type to core
<pedronis> or the other way
<pedronis> around
<pedronis> or something
<zyga> hmmm
<zyga> I think we ought to either introduce snapd type or track and ignore implicit interfaces explicitly
<pedronis> ingnore based on what?
<pedronis> the name?
<zyga> no no
<zyga> if slotInfo.Implicit == true
<zyga> just set Implicit on the interfaces we create
<pedronis> ignore in the sense that any snap can get them?
<zyga> (a new attribute)
<pedronis> there is something fishy in this concept of ignore
<zyga> and by ignore I mean skip the checks for _those_ interfaces
<pedronis> that means any snap can get their slot
<zyga> well, it's just formality, we add them,
<zyga> no
<pedronis> that doesn't make any sense
<zyga> it's not an attribute
<zyga> it's something only snapd could set
<pedronis> yes, but if it's in the interface
<pedronis> what prevent a random snap
<pedronis> to declare the slot?
<zyga> I mean in SlotInfo
<zyga> not in Interface
<pedronis> based on what again?
<pedronis> the snap name
<pedronis> we attach them based on name
<pedronis> the checks right now though are on type
<zyga> well, today we _add_ the implicit interfaces based on snapInfo.Name() == "snapd"
<zyga> if we disagree about that we need to take a step back and fix that
<pedronis> but it doesn't work
<pedronis> because there are checks
<zyga> once we agree there it's trivial to add mark the interfaces as implicit
<pedronis> I disagree
<pedronis> I think we need a little more than a name
<zyga> why do you think so?
<zyga> because of side-loading?
<pedronis> no not sideloading
<pedronis> because it gets very messy
<pedronis> in the old world there was core snap and only one
<pedronis> and it was hard not to have it
<pedronis> now we are allowing various combinations
<zyga> in the old world _any_ snap with type="core" would get the implicit interfaces
<zyga> now I'm doing what we discussed yesterday
<zyga> if we have snapd snap installed it gets the implicit interfaces, otherwise we do as before (any type="core" does)
<pstolowski> i feel that what you're discussing is interesting for hotplug too, although i haven't followed all details... i'm currently adding hotplug slots to "core"
<mvo> mborzecki: your comments on 5339 are not a +1 yet, right? it looks like it still needs a second review
<zyga> pstolowski: yes, I asked this question yesterday on the standup but didn't realise you left by then
<pstolowski> zyga: ah. ok.
<zyga> hmmmm
<zyga> one more twist
<zyga> snap.Info.UseNick("core") returns "system"
<zyga> and DropNick has the reverse logic
<zyga> this is very annoying TBH
<zyga> because it is stateless
<zyga> mvo: ^
<zyga> so at the API level it's not any different
<zyga> but "snap interface network" shows "system" as the slot
<pedronis> zyga: that is what I was mentioning the other day, it was a bit unclear that we wouldn't need reverse translation in the repo, or extra code in the api
<zyga> I think that since we tell the user "system" all the time that we should have used system as a snap, it's just cleaner
<pedronis> zyga: anyway the change I have in mind in policy is not that big, also we never invoke policy code for snaps that don't have snap id
<pedronis> (we assume dangerous)
<zyga> that's a good point
<zyga> pedronis: I didn't get your response on the previous question, how shall we identify snapd-the-snap in general
<zyga> to add interfaces to it
<zyga> if the name check is wrong what is the right check
<pedronis> in policy, with the snap ids
<pedronis> but we can hide that mostly in a helper
<zyga> not in the policy
<zyga> in the interface manager
<zyga> since that's where it starts
<pedronis> name is fine, given that it will be blocked by policy
<pedronis> if it's not installed with dangerous
<zyga> mmm, ok
<Chipaca> I'm off to have lunch, and then I've got a meeting at the boys' school
<Chipaca> I don't think I'll make it to the standup
<Chipaca> let me know if I said "yes" to anything in my absence :-D
<zyga> Chipaca: we'll tell you what you have volunteered to do tomorrow ;-)
<pedronis> zyga: let me try to propose a diff of what I have in mind
<zyga> pedronis: thanks, I'm looking at that code but if you have something that's super nice :)
<pstolowski> Chipaca: we will assume "yes" to everything you don't explicitely nack
<zyga> mvo: can you please merge https://github.com/snapcore/snapd/pull/5364
<mup> PR #5364: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5364>
<zyga> it failed twice on random junk
<pedronis> zyga: something like this is what I had in mind  https://pastebin.ubuntu.com/p/KbsqbVN9by/  of course needs a couple of tests in policy_test.go to go with it
<zyga> mmm, thanks, let's see where I can take this
<mborzecki> heh, pushed to the wrong PR branch, quick reset & force push, maybe nobody will notice :)
<mup> PR snapd#5366 opened: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
<mborzecki> mvo: shall we land #5362 ?
<mup> PR #5362: tests: use "ss" instead of "netstat" (netstat is not available in core18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5362>
<zyga> mvo: what's the id of snapd snap in staging?
<zyga> hmm, we don't restart snapd.service when installing snapd.snap yet, do we?
<jamesh> zyga: I ran into this weird spread test failure in my PR: https://api.travis-ci.org/v3/job/394938067/log.txt -- I think it is down to incomplete cleanup in tests/main/xdg-open (it touches a file and then Arch's package manager refuses to overwrite it when I try to install a package)
<zyga> mvo: with pedronis' patch I can install snapd and (since it doesn't restart) we get duplicated interfaces
<zyga> after snapd restart things are ok
<jamesh> so I wonder if that test is using a bit of an anti-pattern
<zyga> jamesh: looking
<zyga> hmmm
<zyga> I'm puzzled
<zyga> what's the xdg-open in the filesystem that this conflicts with?
<jamesh> zyga: in tests/main/xdg-open, it touches /usr/bin/xdg-open and then bind mounts a fake version of the script over the top, and then undoes the bind mount in the restore script
<zyga> ah
<jamesh> presumably this is intended to make the test work on systems with or without xdg-open installed before hand
<pedronis> zyga: I think we do have code to restarted but only if the model has a base
<mborzecki> pacman refuses to overwrite files
<zyga> IMO the main/xdg-open test must clean up after itself
<zyga> instead of touching it could mv to .orig or something
<mborzecki> zyga: it supposedly does
<jamesh> but it means it leaves an empty file around if xdg-open wasn't around before hand
<zyga> mborzecki: does it?
<mborzecki> but does not remove the file if it wasn't there
<zyga> mborzecki: I'm looking at the restore section
<zyga> yes
<zyga> exactly
<zyga> so to properly clean up it should unlink /usr/bin/xdg-open
<mborzecki> i can do a quick fix
<zyga> and if /usr/bin/xdg-open.orig exists mv it over
<jamesh> alternatively, it could install xdg-utils to ensure a real xdg-open is available to bind mount over
<zyga> this is safe regardless of whether xdg-open existed or not
<mup> PR snapd#5339 closed: tests: initial core18 spread image building <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5339>
<zyga> mvo: ping
<mvo> zyga: pong
<zyga> mvo: can you shed some light on the expected behaviour of snapd the process when one "snap install snapd"
<zyga> should snapd restart?
<mup> PR snapd#5364 closed: packaging/opensuse: fix typo, missing assignment <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5364>
<mvo> zyga: a great question. I think today on !core18 it should do nothing but on core18 it should restart
<mvo> zyga: iirc it will do that already (restart in core18)
<mvo> mborzecki: re 5363 (ss instead of netstat) - if it looks good lets land it. it evolved a bit since your first review, sorry for that, the output is slightly different so I had to tweak a bunch of greps
<mup> PR snapd#5355 closed: data/complete: fix three out of four shellcheck warnings in data/complete <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5355>
<zyga> mvo: mmmmm
<zyga> mvo: thank you
<zyga> mvo: so
<zyga> well, actually, so installing snapd.snap on classic
<zyga> what does that do?
<zyga> s/do/should do
<zyga> in the world without core
<mvo> zyga: in a future world it will restart into snapd
<mvo> zyga: into the snapd snap
<zyga> future as in far into the future
<mvo> zyga: but we are not there yet
<zyga> or soon (week)
<mvo> zyga: ~4-6 weeks
<zyga> k
<mborzecki> jamesh: opening a PR in a minute
<zyga> so then we need to discuss what to do about implicit interfaces again
<zyga> should the new logic only apply if model.Base is core18?
<zyga> and otherwise things are as they are now
<mvo> zyga: I think for now we focus on model.Base != ""
<zyga> I think with _that_ extra logic (and noting that no new tests are present) I could propose my branch to see what happens
<mvo> zyga: but eventually we will be in a new world with core16 and no snapd in there on classic
<zyga> ok, I'll do that
<zyga> thanks
<mvo> zyga: and a snapd snap on classic that will have the role of core
<mvo> zyga: *but* one step at a time :)
<zyga> hhmmm
<zyga> hold on
<zyga> actually, let me have lunch
<mborzecki> wow, econnreset
<mborzecki> https://api.travis-ci.org/v3/job/394933199/log.txt
<pstolowski|lunch> 2018/06/21 12:14:46.074136 store.go:1555: DEBUG: Download succeeded in 4.935s (109MB/s)
<mup> PR snapd#5367 opened: tests/main/xdg-open: restore or clean up xdg-open <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5367>
<mborzecki> jamesh: zyga: ^^
<mborzecki> pstolowski: nice, that's fast :)
<pstolowski> i guess iptables rule is not immediately effective (as suspected by mvo)
<abeato> mvo, I'm getting some snapd errors related to not having GNU build ID in the binary, how can I add that to the binary?
<mvo> abeato: those should just be warnings
<mvo> abeato: did you see my comment in the PR? was that helpful? I also wanted to write a small spread test but I didn't had time yet, I think it would be a nice addition
<abeato> mvo, hm, does not this have side effects?: https://paste.ubuntu.com/p/sdkwXp3nV4/
<abeato> mvo, yes, thanks for that, I have cherry-picked your commit and added it to the branch
<mvo> abeato: those warnings are ok, it just means you get an unneeded profile-generation. maybe we need to phrase them differently so that they sound less scary
<abeato> mvo, ok, was just wondering
<abeato> thx
<zyga> mvo: do you have some time to hop on the standup HO now and talk about core18?
<mvo> zyga: yes, one minute, just finishing a small PR
<zyga> ok
<zyga> mvo: hmm,
<zyga> hangouts/meet don't want to let me in
<mup> PR snapd#5368 opened: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5368>
<zyga> mvo: ok, managed to join via regular hangouts
<mborzecki> pstolowski: ok if i restart that build with econnreset?
<pstolowski> mborzecki: yep, i made a copy
<mborzecki> ack
<pstolowski> thanks
<mborzecki> pstolowski: download is run by the client only right? snapd is not proxying anything there?
<pstolowski> mborzecki: correct
<pstolowski> mborzecki: (in this particula case, e.g. on 'snap download ..')
<mborzecki> right
<mvo> zyga: look at your video ;)
<mup> PR snapd#5362 closed: tests: use "ss" instead of "netstat" (netstat is not available in core18) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5362>
<mup> PR snapd#5365 closed: spread-shellcheck: use the latest shellcheck available from snaps <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5365>
<mup> PR snapd#5369 opened: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369>
<zyga> I need to break now and take the dog out
<mvo> zyga: thank you!
<zyga> mborzecki: I will resume suse work when I'm back, looking forward to your testing :)
<mvo> zyga: anything you need in 2.33.1 for suse?
<zyga> Hmmm, yes but i am afk
<zyga> 32C now, ufff
<mborzecki> zyga: at least you know that it's almost summer :)
<mup> PR snapd#5370 opened: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
<mup> PR snapd#5371 opened: tests/main/interfaces-firewall-control: shellcheck fix <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5371>
<mborzecki> mvo: ^^
<mvo> mborzecki: \o/ thank you
<mup> PR snapd#5356 closed: packaging: require snapd.socket in snapd.seeded.service; make sure snapd.seeded.â¦ <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5356>
<mup> PR snapd#5372 opened: many: improve udev trigger on refresh experience (2.33) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5372>
<mup> PR snapd#5372 closed: many: improve udev trigger on refresh experience (2.33) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5372>
<zyga> re
 * zyga tried to read a paper but ended up talking to mvo and then to family members 
<zyga> anyway, back now
<zyga> mvo: hey
<zyga> did you look at the RFC PR yet?
<zyga> it fails on core 18 with
<zyga> + snap install --channel=edge snapd
<zyga> error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet
<zyga> did I mess up or is the core18 somehow ending up without a model yt
<zyga> *yet
<zyga> in any case, please look at the branch, it's very small so far
<zyga> I will focus on suse release for the rest of the day
<mup> PR snapd#5373 opened: release: 2.33.1 <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5373>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/5368 needs a 2nd review
<mup> PR #5368: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5368>
<pstolowski> looking
<pstolowski> +1
<mup> PR snapd#5331 closed: snapstate: sort "snapd" first <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5331>
<pedronis> as IÂ remarked to mvo this morning 5331 is not sufficient to solve the related problems
<zyga> pedronis: shall I revert it?
<pedronis> it's not harmful by itself
<pedronis> but I would like to understand if the other problem is being tracked
<sergiusens> mvo: pedronis is there any reason for why the actual snap file on /var/lib/snapd/snaps would be 600 when installed with --dangerous but 644 otherwise?
<pedronis> I don't think is --dangerous
<pedronis> is local vs from from store
<pedronis> the involved files are created differently
<pedronis> I see the 0644
<pedronis> the 0600 (for local installs) comes from ioutil.TempFile
<niemeyer> pstolowski|afk: #5326 reviewed
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<mvo> cachio: 2.33.1 is in the beta channel now - just fyi - mostly small fixes and test tweaks for autopkgtest
<cachio> mvo, nice, I'll make a run today
<mborzecki> wow, opensuse really hates my nvidia, the graphical installer refuses to start, textual yast wants to do something (besides being super inconvenient to use) but i doubt that matches what i want it to do, wish i could just mount the target fs and bootstrap everything by hand, probably possible just havent found the way yet
<zyga> mvo: offtopic, did you know about git cherry-pick -m 1 ...
<zyga> it's very useful, I found it by accident
<zyga> pick a merge commit sha and cherry pick the whole lot
<zyga> mborzecki: which release are you on?
<zyga> mborzecki: try tumbleweed if you can, it's the most interesting to test for me
<mborzecki> tw, pulled today's current
<zyga> good
<zyga> (and bad, sorry about your card)
<mborzecki> i'm quite sure that vesa works, just no clue why it's not even tried
<mvo> zyga: oh, neato, I was not aware of this
<zyga> storm is coming!
<zyga> 32C is falling quickly and it's all dark now
<mborzecki> zyga: 16C here
<zyga> !!!
<zyga> how can it be twice as cold there as it was here a moment ago
<zyga> it's barely an hour away
<mup> PR snapd#5374 opened:  tests: disable core tests on all core systems (16 and 18)  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5374>
<mup> PR snapd#5371 closed: tests/main/interfaces-firewall-control: shellcheck fix <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5371>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/5370
<mup> PR #5370: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
<mborzecki> zyga: hm?
<zyga> look at my comment please
<mup> PR snapd#5367 closed: tests/main/xdg-open: restore or clean up xdg-open <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5367>
<mup> PR snapd#5368 closed: tests: disable core tests on all core systems (16 and 18) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5368>
<mborzecki> zyga: restarted the build, it's alreayd fixed in master
<zyga> Thank you!
<zyga> mvo: the 2.33.1 PR fails for the same reason
<zyga> + something that looks like journalctl skew
<mborzecki> zyga: that test log is a bit misleading, the most interesting part is just the last few lines which gives a summary of what failed and why (expectedly/unexpectedly and so on)
<zyga> aha
 * Chipaca EODs and goes to find a place with a tv
<Chipaca> o/
<zyga> uh-oh
<zyga> fire nearby
<zyga> I see lots of smoke and hear the sirens
<zyga> I have a love-hate relationship with "orc"
<zyga> "osc"
<zyga> it sucks as a VCS
<zyga> but it really rocks as a builder
<zyga> it's way too big (CLI is insanely complex)
<zyga> but the build part is really flawless
<zyga> smoke intensifies
<zyga> I'll go to check it out
<zyga> an old house is on fire
<zyga> and a 2nd building now, a block of flats next to it, still under construction
<zyga> I need to add three directory ownership lines to snapd.spec on opensuse
<zyga> %dir /usr/lib/systemd/system-generators
<zyga> %dir /usr/share/dbus-1
<zyga> %dir /usr/share/dbus-1/services
<zyga> Pharaoh_Atem: ^
<zyga> first question, should I own them (build fails on leap without it, works on tumbleweed without them)
<zyga> and second question, what's the abbreviated name for those (with variables and such)
<zyga> mborzecki: ^
<zyga> more fire
<zyga> and more sirens nearby
<zyga> https://www.facebook.com/photo.php?fbid=1939797056064540&set=gm.10160553222185322&type=3&theater
<zyga> mborzecki: I have this interesting output from the build service:
<zyga> [  132s] /usr/lib/snapd/snap-mgmt: line 25: systemd-escape: command not found
<zyga> we have Requires: systemd
<zyga> I wonder what else might be missing
<mvo> zyga: yeah, the failure of the changelog PR is strange
<zyga> I see this failure often while building the package
<zyga> panic in snap state tests https://www.irccloud.com/pastebin/zP4C8oCp/
<mvo> is it just me or is travis very slow?
<mvo> I mean, giving me data for the test results
<zyga> mvo: it's unusably slow
<zyga> the page is so js-heavy it renders very very slowly
<zyga> I always click on the button to show raw log but even getting there is painful
<zyga> mborzecki: do you have suse ready?
<zyga> I sent my build to https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<zyga> I will break now
<zyga> after this builds I will test it on my machines
<zyga> and update the forum
<zyga> I still have a small diff to send
<zyga> (to master)
<Pharaoh_Atem> zyga: %{_systemdgeneratordir}
<Pharaoh_Atem> zyga: %{_datadir}/dbus-1/services
<zyga> it would be awesome if some python script could do that
<zyga> thank you!
<zyga> Pharaoh_Atem: let me know if you need any testing on Fedora
<Pharaoh_Atem> zyga: will do
<Pharaoh_Atem> I'm planning on updating Fedora to 2.33.1
<Pharaoh_Atem> I'm trying to coordinate updating xdg-desktop-portal to 0.11 there too, though
<zyga> Pharaoh_Atem: re
<zyga> Pharaoh_Atem: do you have any idea what failed on https://build.opensuse.org/package/show/home:zyga:branches:system:snappy/snapd
<zyga> the tumbleweed builds failed
<zyga> they enable apparmor
<zyga> I don't quite get it what happens at build time, is the build machinery somehow _executing_ scripts? (%post, etc)
<zyga> ah
<zyga> fixed it :)
<zyga> sheesh
#snappy 2018-06-22
<mborzecki> morning
<mborzecki-suse> hmm found an interesting error: `error: store.RevisionNotAvailable with 2 snaps`
<mborzecki-suse> well, nvidia seems to work just fine
<mborzecki-suse> apparmor denials are not logged in dmesg, so it's easy to miss those
<mborzecki-suse> type=AVC msg=audit(1529645643.115:406): apparmor="DENIED" operation="open" profile="snap.ohmygiraffe.ohmygiraffe" name="/etc/pulse/client.conf.d/" pid=10207 comm="love" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<zyga> hey
<zyga> mborzecki-suse: hey
<mborzecki-suse> zyga: hey
<zyga> I was up till 2AM iterating on the packaging
<mborzecki-suse> zyga: so far so good, no issues with package from your repo
<zyga> found a few annoying bugs and fixed them
<zyga> and learned a few things that we need to change in our build system
<zyga> (not having a central build system sucks)
<mborzecki-suse> but man, textual yast installer is awful, didn't manage to install it the way i'd like, gave up and went with the defaults at some point, ended up with gpt partitioned disk, no efi, no luks, no lvm, btrfs on rootfs, xfs on home and non-blacklisted nouveau (what made xorg unusable)
<snaphelp> hey
<snaphelp> so how do I go about backing up a snap's data
<snaphelp> Like nextcloud.
<zyga> snaphelp: fantastic question
<zyga> you can do it manually today
<zyga> but we are also working on a feature that makes it easy
<snaphelp> zyga: Snaps aren't auto updating are they?
<mborzecki-suse> don't know why people even bother building such installers, what i really need is creating partitions myself, mounting them in the layout i want, bootstrapping the system, update fstab, crypttab, rebuild initramfs, install some bs pacakges, install bootloader (the way i want)
<zyga> all snap data is held in /var/snap/$SNAP_NAME and $HOME/snap/$SNAP_NAME
<zyga> mborzecki-suse: hmm?
<zyga> snaphelp: the upcoming feature will allow you to snapshot this state easily from the snap CLI
<snaphelp> zyga: is the snap directory in my home directory just a symlink to /var/snap?
<zyga> snaphelp: no
<zyga> snaphelp: those are separate data sets, one is per user and the other is global for the system
<snaphelp> hmm
<mborzecki-suse> zyga: just being grumpy about distro installers :|
<zyga> hey mvo
<mborzecki-suse> mvo: morning
<mvo> hey zyga and mborzecki
<snaphelp> zyga: so the global data is in /var
<snaphelp> and there's no auto updating correct?
<zyga> snaphelp: per-snap global data is in /var/snap/$SNAP_NAME
<zyga> snaphelp: I don't understand the question about auto-updating
<snaphelp> Do snaps automagically update themselves
<snaphelp> or is it snap update <snap>
<zyga> snaphelp: it is snap refresh but you don't have to do it explicitly, snapd automatically refreshes everything periodically
<snaphelp> Can I disable automatic refreshes?
<zyga> you can set a schedule but you cannot turn it off
<zyga> mvo: I'm a bit tired, I spent half of the night on this packaging
<zyga> mvo: I will be sending patches when I'm consistently awake
<snaphelp> zyga: any plans to allow disabling?
<zyga> snaphelp: no, there are no such plans
<snaphelp> hm
<snaphelp> zyga: I'm torture testing a snap
<snaphelp> heh wow it's handling being beat with 40gb of data
<zyga> mvo: we need to have a makefile in data/
<zyga> and stop installing files by hand in packaging
<zyga> it's easy to miss files
<zyga> and it's silly to do this
<mborzecki> need to go to kids school for a while, bbl
<mup> PR snapd#5352 closed: many: expose full publisher info over the snapd API <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5352>
<mvo> zyga: ok
<mup> PR snapd#5375 opened: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Created by mvo5> <https://github.com/snapcore/snapd/pull/5375>
<zyga> oh, interesting
<mup> PR core18#34 opened: hooks: make /usr/bin/snapctl available in the base <Created by mvo5> <https://github.com/snapcore/core18/pull/34>
<mvo> zyga: one more commit to 5375 (apparmor default update)
<mup> PR core18#34 closed: hooks: make /usr/bin/snapctl available in the base <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core18/pull/34>
<pstolowski> morning
 * zyga is super sleepy 
<zyga> sorry folks, this day will be hit-and-miss
<mvo> hey pstolowski, good morning
<mup> PR snapd#5376 opened: tests: skip security-udev-input-subsystem without /dev/input/by-path <Created by mvo5> <https://github.com/snapcore/snapd/pull/5376>
<mvo> zyga: just get some rest :) it will be better i'm sure
<mup> PR snapd#5373 closed: release: 2.33.1 <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5373>
<zyga> mvo: thank you
<zyga> I'm chopping final bits of packaging updates
<zyga> thank you for 2.33.1
<pstolowski> re https://forum.snapcraft.io/t/gnome-calculator-failed-to-create-symbolic-link/5742/10 , the after-install seeding doesn't look good in cosmic, gets stuck on autoconnect and in the meantime an update of snapd arrives through deb and gets stuck on deb configure step
<mup> PR snapd#5377 opened: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377>
<zyga> mborzecki: ^
<zyga> mborzecki: which distributions did you test?
<zyga> popey: do you have a suse box for some testing?
<zyga> popey: I'd like to update snapd in openSUSE
<zyga> mborzecki: I also have one issue I don't know how to solve
<zyga> mborzecki: the new snapd.apparmor.service needs to be enabled manually
<zyga> mborzecki: I don't know what to do about it
<zyga> mborzecki: could you please have a look at https://build.opensuse.org/request/show/618441
<zyga> Pharaoh_Atem: ^ if you have the time
<zyga> Pharaoh_Atem: this syncs the package in system:snappy with the package in snapd master
<zyga> remaning diff is: patches, small change in path used to get packaging overrides (we don't have a symlink for packaging/opensuse in 2.33 _yet_).
<zyga> in 2.34 the delta should be empty
 * zyga -> walk
<pstolowski> mvo, pedronis it appears that seeding+prerequisites explode in cosmic on autoconnect, also with 2.33.1 (i've built the deb manually)
<pedronis> pstolowski: explode in which sense?
<pedronis> we have no support atm if the seeding is not sorted right
<pstolowski> pedronis: autoconnect is in state Doing, never completes
<pedronis> pstolowski: is this a spread test or something else?
<pstolowski> pedronis: there are 6 gnome packages + core in seed/
<pstolowski> pedronis: no, a fresh install of cosmic daily
<pedronis> if they are sorted wrong
<pedronis> no good
<pedronis> given that seeding is serial
<pedronis> we should teach seeding to do some sorting
<pedronis> but that hasn't really changed much
<pedronis> pstolowski: I'm not even sure what autoconnect code is exactly in 2.33.1
<pedronis> IÂ suppose is not like master
<pstolowski> pedronis: correction, i actually build and tested with current master
<pedronis> pstolowski: can you print seed.yaml there
<pedronis> pstolowski: we might have made something worse
<pedronis> but it was probably working by chance
<pedronis> or I'm missing something, which could be
<pstolowski> pedronis: http://pastebin.ubuntu.com/p/pPZkdHhp9B/
<pedronis> themes is wrong
<pedronis> there was even a bug
<pedronis> we told them to move
<pedronis> not sure why is still like that
<pstolowski> pedronis: i don't think we made it worse, i started with fresh cosmic image (it has 2.28.x), the problem was already visible
<pstolowski> pedronis: oh ah
<popey> zyga: i have a suse vm, but not sure how much time i will have today to help test
<Chipaca> morning all
 * Chipaca having a weird day (but a good'un)
<pedronis> pstolowski: is still open, though there was a fix:  https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844
<pedronis> bit confused
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<pstolowski> pedronis: right, clearly not landed
<pedronis> pstolowski: we can teach either seeding or autoconnect to do something in that case, I want to have a clearer big picture related to conflicts before going there
<pedronis> though
<pedronis> the manual fix seems easy enough, not sure why is not landed
<pedronis> or is just different teams building different images
<pedronis> mvo: do you understand  what is happening with that bug ? #1772844
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<mborzecki> re
<mborzecki> took longer than i expected
<searedvandal> Hi. I just installed snapd on Antergos from the AUR, and I set it up following the instructions for Arch. Installed the hello snap, and tried to run it. I get this error "cannot locate the core or legacy core snap (current symlink missing?): No such file or directory". snapd version 2.33, kernel 4.17.2-1-ARCH. Any ideas to what may be the issue?
<Chipaca> searedvandal: does Antergos use systemd?
<searedvandal> Chipaca, yes
<Chipaca> phew
<Chipaca> searedvandal: 'snap list' lists nothing?
<Chipaca> searedvandal: can you pastebin the output of 'snap tasks --last=install'
<mborzecki> searedvandal: and pacman -Qi snapd
<searedvandal> Chipaca, https://ptpb.pw/_0LP
<searedvandal> mborzecki, https://ptpb.pw/iJb7
<Chipaca> hmmmm
<searedvandal> Chipaca, and snap list shows core and hello
<Chipaca> searedvandal: yep. I'm guessing something is expecting /snap instead of /var/lib/snapd/snap or viceversa
<mborzecki> mvo: there's somethign wrong with the 2.33.1 release on github
<Chipaca> searedvandal: what's in /etc/os-release?
<mborzecki> mvo: it doesn't have a tag (?)
<searedvandal> Chipaca, my /etc/os-release https://ptpb.pw/xFrR
<mborzecki> ID_LIKE=archlinux chceks out
<searedvandal> mborzecki, the AUR has the 2.33 build, not the 2.33.1
<mborzecki> searedvandal: yeah, i'm updating to 2.33.1 now ;)
<niemeyer> Mornings
<searedvandal> mborzecki, ah :)
<searedvandal> when I do 'snap version' the antergos line has this - , is that correct? https://ptpb.pw/rOFw
<Chipaca> searedvandal: probably
<searedvandal> alright
<Chipaca> searedvandal: because it's a rollin' release
<Chipaca> so no 'version'
<searedvandal> ah, yeah
<searedvandal> Chipaca, and I have the /snap directory and the /var/lib/snapd/snap directory
<mborzecki> searedvandal: yes, it's the same on arch
<mborzecki> searedvandal: /snap is just a symlink in your system right?
<Chipaca> searedvandal: can you pastebin find /{var/lib/snapd/,}snap/ -maxdepth 2 -ls
<searedvandal> mborzecki, Chipaca here is the paste https://ptpb.pw/Qp_i
<mborzecki> searedvandal: ls -l /
<Chipaca> mborzecki: that looks like /snap is not a symlink but the real thing
<Chipaca> mborzecki: and /var/lib/snapd/snap has nothing
<searedvandal> mborzecki, https://ptpb.pw/Pj_e
<searedvandal> oh, you're right
<Chipaca> that is very strange
<Chipaca> something's askew (gesundheit)
<mborzecki> searedvandal: yeah, the package ships with /var/lib/snapd/... only
<searedvandal> strange. I have not created any directories or changed anything
<mborzecki> it used to ship /snap -> /var/lib/snapd/snap symlink a while ago but we got rid of that
<mborzecki> searedvandal: can you pacman -Qo /snap ?
<Chipaca> mborzecki: I suspect distro detection being confuse
<searedvandal> mborzecki, no package owns /snap
<Chipaca> in hindsight, we should print a summary of directory info on startup, at least in debug
<mborzecki> searedvandal: ok, if there's any snap mounted, unmount it and remove the package, remove /snap and install the package again
<mborzecki> Chipaca: +1
<mborzecki> snap debug distro :)
<Chipaca> and now i need to stop myself from doing that and getting back to figuring out why warnings has my snapd all panicky
<mvo> mborzecki: let me check, it should have a tag
<searedvandal> alright, you're right, it gets confused on os-detection. I removed a pacman hook that sets the antergos info and updated the filesystem package to revert to identifying as regular arch. now everything seems to work just fine
<searedvandal> snap run hello gives me a nice hello world output
<mborzecki> mvo: https://github.com/snapcore/snapd/releases/tag/untagged-ec50ee5bfb45daefc236  <-- untagged-...
<mborzecki> searedvandal: yay
<mvo> mborzecki: better now? sorry, no idea what happened there, github glitch
<searedvandal> so snap doesn't like it when the system is identified as antergos, but when it's identified as arch it's all good :)
<mborzecki> hm otoh we do release.DistroLike(..., "arch", ..) this should probably be "archlinux" to catch the derivatives
<searedvandal> ah, probably :)
<Son_Goku> mvo, zyga, I just realized that next week will be the two year anniversary of me working on snappy on Fedora
<mborzecki> mvo: yay!
<zyga> :)
<zyga> Time flies!
<mborzecki> Son_Goku: we should get you some cake
<Son_Goku> two years ago next week, I agreed on a lark to go to the first snappy sprint
<ogra_> \o/
<Son_Goku> I had received the email while (ironically) being at the Red Hat Summit
<mvo> Son_Goku: woah, congrats \o/
<ogra_> great to still have you here !!
 * mvo hugs Son_Goku 
<Son_Goku> and Josh Bressers and Thomas Cameron both told me I should go ahead and do it
<Son_Goku> so I did
<Son_Goku> (Josh: https://twitter.com/joshbressers; Thomas: https://twitter.com/thomasdcameron)
<Son_Goku> at the time, I was really unsure if I was the right person to go to this
<Son_Goku> of course, technically, I started two years ago next month, but...
<mborzecki> searedvandal: could revert back to identifying as antegros and rebuild the package with this little fix https://ptpb.pw/Oo6u ?
<Son_Goku> because the Heidelberg sprint was July 22, 2016
<niemeyer> Interesting.. we're importing from the snap package inside client
<niemeyer> This is something we should avoid as otherwise importing the client will depend on importing snapd entirely
<niemeyer> Son_Goku: That reminds me that we need a dev sprint soon
<Son_Goku> niemeyer, I was wondering if we were going to go without one this year :)
<mup> PR snapd#5378 opened: dirs: improve identification of Arch Linux like systems <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5378>
<niemeyer> Son_Goku: We just need to think about what would be the best time and place.. we have non-dev sprints in July and September.. So either August or later in the year
<Son_Goku> so I'm going to be at DevConf.us Aug 17-19, so please don't schedule it then
<mborzecki> searedvandal: just opened a PR with this change, if it works in our test suite I'll include it as a patch in 2.33.1 package, so your next rebuild should work fine
<Son_Goku> niemeyer, Flock is actually going on in Dresden, Germany on Aug 8-11: https://flocktofedora.org/
<Son_Goku> if zyga wants to talk about snaps at Flock, now would be a good time ;)
<niemeyer> Son_Goku: Ah, interesting
<zyga>  Very likely
<niemeyer> Son_Goku: Are you going?
<Son_Goku> I can't afford to, so sadly no
<Chipaca> niemeyer: we've been depending on snap from client for a long long time
<Son_Goku> zyga: almost anything goes for CfP: https://flocktofedora.org/#cfp
<Chipaca> niemeyer: snap is where Revision and Epoch live
<niemeyer> Chipaca: Yeah.. my memory is weak by now, but IIRC the agreement we got about this kind of thing was to revert the dependency, having such types in client itself
<niemeyer> Chipaca: So that importing the client becomes isolated
<niemeyer> Chipaca: The snapd/snap package by now spreads its legs through quite a few bits
<niemeyer> As in, importing deps
<Son_Goku> niemeyer, but it'd be cool if Snapcraft was listed as a sponsor for Flock :P
<niemeyer> Which is not a problem for it, to be clear.. it's just that the transitive dependency from client becomes weird
<Chipaca> niemeyer: I thought it just used dirs and the different *util
<niemeyer> Son_Goku: We can check that.. I haven't been involved in sponsorings for a while, so I'm not sure about what the current rules are
<Chipaca> Son_Goku: this Flock is distinct from the flock that is a startup and an app?
<Son_Goku> yes...
<Son_Goku> Flock is the name for the Fedora contributor conference
<Son_Goku> which used to be called FUDCon
<Chipaca> I can see how a contention mechanism is a better name than FUDCon
<Chipaca> but it's not a wide margin :)
<mup> PR snapd#5378 closed: dirs: improve identification of Arch Linux like systems <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5378>
<mborzecki> mvo: i think the tag can be removed:
<mborzecki>  * [new tag]             untagged-ec50ee5bfb45daefc236 -> untagged-ec50ee5bfb45daefc236
<mborzecki> suprising github actually allowed creating this
<zyga> re
 * zyga picked up the coffee he made at 7
<zyga> mborzecki, Pharaoh_Atem: can you please eyeball https://github.com/snapcore/snapd/pull/5377
<zyga> it's the last of the bunch
<mup> PR #5377: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377>
<zyga> mvo: hey
<zyga> did you have a chance to look at https://github.com/snapcore/snapd/pull/5369
<mup> PR #5369: overlord,interfaces,cmd: WIP early support for interfaces on core18 <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5369>
<mvo> hey zyga
<mvo> zyga: looking at it currently
<zyga> :-D ok, let me know once you've read it
<zyga> I'll write something on the forum now
<searedvandal> oh my how smooth TrackMania runs, I'm impressed
<mvo> zyga: ok
<mborzecki> snap downloads capped at 100kBps again?
<zyga> mborzecki: hmm, not for me
<zyga> 7MB/s
<mborzecki> hmm 2 times hit 100kBps, another restart and 1.2MB now
<zyga> over my LTE link
<zyga> I looked at stats and I still cannot stop being impressed by how I can effortlessly live on LTE with 100s of GB of data used monthly
<zyga> for the price of a meal in spain
<zyga> (one meal, for one person)
<mup> PR snapd#5379 opened:  overlord/snapstate: disallow installing snapd on baseless models  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5379>
<mvo> zyga: I split the snapd prevention bits (and added a trivial test) - I think we deefinitely want this
<zyga> prevention bits?
<zyga> the snapd.snap removal/installation?
<mvo> zyga: disallow installing the snapd snap
<zyga> note that it breaks the tests today :/
<mvo> zyga: it does? which one?
<zyga> just look at the test failures, all the core 18 tests exploded
<zyga> I asked if this was expected (perhaps the way we install snapd is not right) but we didn't talk about it since
<mvo> zyga: aha, I will debug it :)
<mvo> zyga: "all the core18 tests" - all two of them ;) ?
<mvo> zyga: aha, I see what is going on
 * mvo scratches head
<mvo> zyga: testing a fix now, and then I will go over the rest. thanks in any case!
<mborzecki> searedvandal: changes are in AUR now
<searedvandal> mborzecki, nice, thanks!
<Son_Goku> mvo, wait, does that mean it'd be possible to make snapd snap either-or if a base snap provided snapd?
<Son_Goku> I'm confused what PR#5379 actually does
<Chipaca> Son_Goku: we're transitioning from having snapd in core to having snapd in snapd
<Son_Goku> :/
<Chipaca> Son_Goku: we're special casing the special case so we can special case while we special case
<Chipaca> Son_Goku: why :/?
<Son_Goku> because I don't understand what's going on here
<Son_Goku> I'm confused
<Chipaca> Son_Goku: core 18 won't  have snapd
<Chipaca> rather
<zyga> Son_Goku: because of core18 and core16 the idea of having snapd in _a_ core is gone
<Chipaca> Son_Goku: core18 does not have snapd
<Chipaca> Son_Goku: neither will core16
<zyga> so snapd moves to its own proper package
<zyga> eventually the only snap that ships snapd will be snapd.snap
<Chipaca> Son_Goku: today, core does; core will become core16 and snapd
<Son_Goku> hmm
<zyga> this will simplify and unify various special cases
<Son_Goku> there were special cases?
<zyga> and will make it natural to have bases
<Chipaca> Son_Goku: but as core and core16 will co-exist, we want to put little yellow "don't step on the bubbling lava" signs
<zyga> yeah, plenty of them
<zyga> still are but this will help to remove it
<zyga> core wil transition to core16
<Chipaca> Son_Goku: the end game is _less_ special cases, not more, fwiw
<Son_Goku> okay, I think I get it
<Chipaca> Son_Goku: where there must be a snapd snap, but you can have any base (and that base evolves separately from snapd itself)
<zyga> Son_Goku: snap-confine will hopefully shrink a little thanks to this
<Son_Goku> most of this doesn't really affect me though, since we don't allow re-exec on Fedora
<zyga> and snap-run/snap-exec/snapd code will drop some if name == "core" code
<Son_Goku> since your snapd breaks things
 * Chipaca hopes Son_Goku doesn't ask what base snapd will use
<Son_Goku> I think I have a feeling that snapd will use base snapd
<Son_Goku> or worse, base ubuntu-core16
 * Chipaca votes it uses base 'bo'
<zyga> Son_Goku: snapd won't use any base
<Chipaca> or maybe base 'politically-incorrect-inanimate-object'
<zyga> it's not a snap that ships apps or services in the traditional sense
<zyga> more like a vehicle for runtime bits for any base
<zyga> (snap-confine/exec/snapctl chain)
<Son_Goku> so it pretty much doesn't affect me
<Son_Goku> since we don't use those bits
<zyga> no, you are slightly mistaken
<Son_Goku> it'd only become a problem once we have a fedora bootable base :/
<zyga> you do use snap-exec and snapctl from core
<zyga> that's always been the case
<zyga> you don't use snap-confine from core when running snaps from the outside
<Chipaca> Son_Goku: bootable fedora base is happening though, right?
<Son_Goku> that's something zyga and I are working toward, yes
<Son_Goku> I already know that we're in for hell because I can't swap the snapd :/
<zyga> Chipaca: yes, eventually, I think this cycle we will get fedora29 base for apps and future development though
 * Son_Goku really wishes core16 / core18 would be ubuntu-core16 / ubuntu-core18
<Son_Goku> that's what they actually are, after all
<Chipaca> Son_Goku: I think it's that until there are other bases realistically out there being used, we don't want to have people think they're downloading all of ubuntu just to run tmnationsforever
<Son_Goku> well there's already other bases in use
<Son_Goku> at least ikey has the one for steam
 * Chipaca misses ikey
<Son_Goku> and _a_ fedora base snap will be available by Fedora 29 GA
<Son_Goku> I can almost nearly guarantee it
<Son_Goku> primarily because I can make one whenever I want
<zyga> Son_Goku: one good thing is that "core" will go away and become core{16,18} and those will shrink
<Son_Goku> the work zyga and I will be doing this development cycle is integrating this into the infra tooling so it's literally part of the compose
<Chipaca> Son_Goku: I'll raise it in the standup (unless zyga does it first)
<Son_Goku> that is, part of the process to make all the release artifacts
<zyga> we also considered (though not scheduled to do it) a bootless core which would be even smaller by a large amount
<Chipaca> I think the bootless split was kicked to 20
<zyga> yeah
<Chipaca> too many moving parts
<zyga> yep
<zyga> Chipaca: raise what exactly?
<Chipaca> zyga: ubuntu-core18 instead of just core18
<Son_Goku> zyga, what does snapd.seeded.service do?
<Chipaca> Son_Goku: wait until snapd is seeded
<zyga> Son_Goku: tells you that the system has installed all of the snaps that are in the seed (from the model)
<zyga> Son_Goku: it basically tells you that it is ready after first boot
<Son_Goku> ah
<Son_Goku> so is this something we need to have enabled in the fedora preset?
<zyga> before that snapd is busy doing stuff and not really responding
<Son_Goku> because right now, it ai't
<Son_Goku> *ain't
<zyga> Son_Goku: it's useful as target of "after snapd is there"
<Chipaca> Son_Goku: shouldn't hurt, and would let you play with seeds
<zyga> we added it because someone needed this kind of thing for another piece of software
<zyga> I added it to suse
<zyga> it's not core specific, I think it could be in fedora as well
<mborzecki> though maybe not enabled by default right?
<zyga> why not?
<mborzecki> because it will wake up snapd
<zyga> mmmm
<zyga> interesting
<mborzecki> seeded -> snapd.socket -> snapd.service
<zyga> can we write the unit in a way that would make it do stuff only if snapd was enabled?
<Son_Goku> no
<Son_Goku> because you added Requires
<zyga> I see
<Son_Goku> you forced it on
<zyga> then I agree with mborzecki
<Son_Goku> yeah, so probably should stay off by default
<mborzecki> i mean, once you know you need it you'll enable it :)
<Son_Goku> it's only needed for firstboot if we had them preloaded, right?
<Son_Goku> maybe the unit can be adjusted to have firstboot condition
<zyga> mmm, interesting
<zyga> how could we do that?
<zyga> I think that's a pretty good idea
<Son_Goku> ConditionFirstBoot= takes a boolean argument. This condition may be used to conditionalize units on whether the system is booting up with an unpopulated /etc directory (specifically: an /etc with no /etc/machine-id). This may be used to populate /etc on the first boot after factory reset, or when a new system instance boots up for the first time.
<Chipaca> zyga: that's a very particular "first boot" condition
<Son_Goku> from systemd.unit(5): https://www.mankier.com/5/systemd.unit#ConditionFirstBoot=
<mborzecki> econnreset again, 2018/06/22 11:12:14.534944 store.go:1555: DEBUG: Download succeeded in 5.257s (102MB/s).
<Son_Goku> alternatively, you could do ConditionPathExists= and do some custom logic here in the seeding code: https://www.mankier.com/5/systemd.unit#ConditionPathExists=
<zyga> like the presence of /var/lib/snapd/{seed} or model or something
<zyga> not sure but something like that
<Son_Goku> yeah
<Son_Goku> something that would make it far less penalizing to have it
<Son_Goku> zyga, ConditionPathExists also takes a negation operator
<Son_Goku> so !/var/lib/snapd/seeded would also work
<zyga> pedronis: hey
<zyga> pedronis: I wrote the post that I was supposed to, about the refresh + restart issue
<zyga> https://forum.snapcraft.io/t/issue-with-using-snapstate-active-for-interface-repository/6065
<zyga> could you please read it and ensure I didn't miss anything critical or didn't skew the facts
<Son_Goku> mborzecki, zyga , what happens if xdg-desktop-portal < 0.11 is installed on fedora for snapd?
<zyga> Son_Goku: I don't know the version specifically
<zyga> is that the old portal that was not aware of snapd?
<Son_Goku> yes
<Son_Goku> xdg-desktop-portal 0.9 is in Fedora 27
<Son_Goku> 0.11 is in Fedora 28+
<zyga> portals would not know they are used by a confined app
<mborzecki> zyga: pushed an update to 5370
<zyga> so they would not trigger the portal-specific file open dialogs
<zyga> (in cooperating apps)
<zyga> the UX would suck
<Son_Goku> :/
<zyga> (like it does now, not a regression)
<Son_Goku> so it's no worse than today?
<zyga> I believe it would be exactly like today
<Son_Goku> so I don't need to add a "Conflicts: xdg-desktop-portal < 0.11"?
<zyga> one sec
<zyga> no no
<zyga> https://github.com/snapcore/snapd/pull/5271
<mup> PR #5271: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271>
<zyga> scroll to the bottom
<zyga> there's some talk about this exact issue
<Son_Goku> so the answer is, openSUSE is fucked but not Fedora
<mborzecki> tumbleweed to?
<Son_Goku> yes
<Son_Goku> openSUSE has been shipping Flatpak by default for a while now
<Son_Goku> it's also shipping in SLE 15, too
<zyga> Son_Goku: tumbleweed will probably get the latest version soon
<zyga> it has 0.11.7
<zyga> Son_Goku: note that I enabled apparmor on tumbleweed
<zyga> Son_Goku: so there's way more confinement than before :)
<Son_Goku> eh
<Son_Goku> I'm slightly annoyed you didn't merge my changes entry into the OBS package
<zyga> I can do that in the final sync
<zyga> it is not out yet
<Son_Goku> I'm building snapd 2.33.1 and snapd-glib 1.41 now
<Chipaca> niemeyer, mvo: I've got a meeting that I need to be in instead of the standup today
<niemeyer> Chipaca: Ack, thanks for the note
<Chipaca> niemeyer, mvo: it should be short, but if not --- i'm working on warnings, fixing all the tests in daemon/ that i've broken :-)
<Chipaca> figured out the source of the panic, also
<Chipaca> so huzzah
<mborzecki> anyone wants to look at #5363 and #5366?
<mup> PR #5363: snap: introduce the instance key field <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5363>
<mup> PR #5366: snap: helper for validating snap instance names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5366>
<Son_Goku> zyga, also, xdg-desktop-portal will now supplement either flatpak or snapd
<Son_Goku> err, the gtk and kde portals will
<Son_Goku> https://src.fedoraproject.org/rpms/xdg-desktop-portal-gtk/blob/master/f/xdg-desktop-portal-gtk.spec#_22
<Son_Goku> https://src.fedoraproject.org/rpms/xdg-desktop-portal-kde/blob/master/f/xdg-desktop-portal-kde.spec#_40
<zyga> Thank you pedronis !
<pedronis> zyga: your description was not too wrong, but seemed to me a bit still too high level
<zyga> yes, you got the specific details in place, thank you
<pedronis> mvo: https://launchpad.net/bugs/1772844
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<mvo> pedronis: thank you!
<mvo> sil2100: does foundations have https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1772844 on the radar? if not, who should I ask about this? the bug is most likely that the seed.yaml needs to be tweeaks and things needs to be around a bit. happy to talk about the details once I know with whom :)
<mup> Bug #1772844: snapd didn't initialize all the seeded snaps <amd64> <apport-bug> <bionic> <package-from-proposed> <third-party-packages> <OEM Priority Project:Confirmed for swem> <snapd:New> <ubuntu-meta (Ubuntu):New> <https://launchpad.net/bugs/1772844>
<sil2100> mvo: hmm, first time I hear about this! Let me read it up
<mborzecki> niemeyer: experimental.parallel-instances then?
<pedronis> pstolowski: what's the status of disconnect hooks?
<niemeyer> mborzecki: +1
<mborzecki> ack
<pedronis> pstolowski: this is a strange error:  Disconnect bluez:client from bluez:service (snapd changed, please retry the operation: cannot disconnect bluez:client from bluez:service, it is not connected)
<pstolowski> pedronis: i think i know why that is, i forgot to disable discard-conns, at the very least
<pedronis> we do need to  keep it though
<pstolowski> pedronis: i'll ping you when it's ready
<pstolowski> pedronis: i know
<pedronis> but making it idempotent
<pstolowski> pedronis: handler needs to stay, but task shouldn't be created for new changes
<pedronis> ok, I'm still a bit confused
<pedronis> I would have expected it to come before, not after
<pedronis> pstolowski: also notice that these strange error seems about self connections
<pedronis> pstolowski: are we trying to disconnect them twice?
<pstolowski> pedronis: ah, i didn't think of it, might be the same issue we had with autoconnect
<pedronis> I doubt because the code would be different
<pedronis> but maybe the connect does strange things
<pedronis> anyway an interesting datapoint
<pedronis> IÂ would expect the discard-conns to do nothing, assuming it happens last
<Chipaca> I'm going offline for a while, will check in tonight again (with moar warnings)
 * Chipaca -> school stuff and such
<pedronis> pstolowski: ah, mayb repo connections in this case return the same connection twice ?
<pedronis> pstolowski: yes, the issue is repo.Connections,  self connections are reported twice
<pstolowski> pedronis: heh, indeed! i wonder if there is any undesired effect if i fix this centrally (in the repo.Connections)
<pstolowski> it shouldn't afaict, don't think it has a use case
<pedronis> pstolowski: it shouldn't, it's kind of weird/unexpect to get the same conn twice
<ali1234> should i install snapcraft from apt or from snap?
<mborzecki> niemeyer: rename to parallel-instances pushed to #5370
<mup> PR #5370: overlord/{config,snap}state: introduce parallel-installs feature flag <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5370>
<niemeyer> mborzecki: Thanks!
<pstolowski> ali1234: there is no reason not to use the one from snap; go for the snap; it also makes it easy to switch to a beta version (and back) in case of an important fix coming
<popey> ali1234: i use the snap, personally.
<pstolowski> pedronis: pushed the repo fix but discard-conns still needs work (undo for single disconnect)
 * zyga fixed all the entries in the opensuse snapd.changes changelog to have non-fake copy/pasted/tweaked dates 
<zyga> Pharaoh_Atem: ^ that's for you :)
<Pharaoh_Atem> :)
<zyga> apparently copy/pasting and tweaking seconds is ... popular
<Pharaoh_Atem> :/
<mvo> zyga: my bad - I need an emacs mode or something of this. or obs-dch or whatnot
<zyga> mvo: "ons vc"
<zyga> er
<zyga> "osc vc"
<zyga> (sorry, spellchecker doesn't love acronyms)
<zyga> that edits the changelog
<mborzecki> well, to be fair it'd be nice if changelog included package version/release, otherwise rpm -q --changelog is not really that useful
<mvo> nice, thank you
<mvo> I hope I remember
<zyga> the changelog is still wrong
<zyga> sigh
<zyga> someone wrote a tool that returns false
<zyga> rather than "on line 123, ..."
<mborzecki> zyga: on line 123, .. false :)
<zyga> gah, the bugzilla email apocalypse
<Pharaoh_Atem> :D
<mborzecki> btw emacs' rpm-mode can add changelog entries, but it's not aware of opensuse's *.changes file split
<Pharaoh_Atem> which is actually annoying
<Pharaoh_Atem> and also I'm working on fixing `osc vc` to properly generate entries with full author identities
<Pharaoh_Atem> zyga, mborzecki, niemeyer, mvo: https://forum.snapcraft.io/t/snapd-updates-in-fedora/4342/5?u=conan_kudo
<mvo> zyga: I found the issue with 5369 - ERROR installation not allowed by "daemon-notify" slot rule of interface "daemon-notify"
<mvo> zyga: this is when it tries to mount the core snap
<pedronis> mvo: zyga's RFC branch has code for that
<zyga> yeah
<zyga> you need to take that patch (that really pedronis wrote :)
<mvo> pedronis: yeah, thank you, I figured it out by now, I added a fix that should make these tests work
<mborzecki> mvo: shall i land #5374 or do you plan to push more patches?
<mup> PR #5374:  tests: disable core tests on all core systems (16 and 18)  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5374>
<ali1234> when i run snapcraft: E:Failed to fetch copy:/home/al/.cache/snapcraft/stage-packages/apt/.../var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_bionic-security_main_dep11_icons-48x48.tar.gz  Hash Sum mismatch
<ali1234> "..." is a very long hex string
<mup> PR snapd#5374 closed:  tests: disable core tests on all core systems (16 and 18)  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5374>
<zyga> mvo: https://github.com/snapcore/snapd/pull/5379 can land as well
<zyga> shall I?
<mup> PR #5379:  overlord/snapstate: disallow installing snapd on baseless models  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5379>
<mvo> mborzecki: 5374 should be good
<mvo> zyga: same for 5379
<zyga> there is a comment on 5374
<mup> PR snapd#5379 closed:  overlord/snapstate: disallow installing snapd on baseless models  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5379>
<zyga> Pharaoh_Atem: I wrote a tool for checking changelog entries
<zyga> that's much nicer than the original
<b_b> hi
<zyga> niemeyer: where is the meeting taking place?
<niemeyer> zyga: We're in the standup
<b_b> i'm having this bug on snapcraft.io website
<b_b> https://github.com/canonical-websites/snapcraft.io/pull/687
<b_b> but it seems resolved by this PR
<b_b> i've tried to upload a 48px icon to a snap => 502
<mvo> 5309 is hopefully ready now if someone wants to do a second review
<b_b> commented the PR
<b_b> anyway, i'm happy/proud, my first snap is released on stable :) https://snapcraft.io/timeline
<b_b> with a ridiculus small icon, but the dev team can't find the source file :p
<b_b> see u ++
<diddledan> why am I being denied access to files in core? Log: apparmor="DENIED" operation="open" profile="snap.mycroft.bus" name="/snap/core/4830/lib/x86_64-linux-gnu/liblzma.so.5.0.0" pid=16522 comm="python3" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<Pharaoh_Atem> zyga: oh?
<zyga> yeh
<zyga> one moment
<zyga> I'm in a call
<pstolowski> zyga: can you take another look at #5326 (doesn't have to be today, Monday is fine)?
<mup> PR #5326: api/snapctl: allow -h and --help for regular users <Created by stolowski> <https://github.com/snapcore/snapd/pull/5326>
<mup> PR snapd#5380 opened: tests: blacklist more main tests for core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5380>
<zyga> Pharaoh_Atem: wanna see it?
<zyga> niemeyer: have a good weekend too :)
<zyga> Pharaoh_Atem: halp
<zyga> %{!?systemdgeneratordir: %global systemdgeneratordir %{_prefix}/lib/systemd/system-generators}
<zyga> this doesn't produce a path that is absolute
<pedronis> zyga: running setup-profiles twice is not a problem right?
<zyga> no, not a problem
<zyga> Pharaoh_Atem: undo help, I see the typo now
<Pharaoh_Atem> zyga: the answer is yes
<zyga> cool, just polishing a bit
<zyga> Pharaoh_Atem: https://gitlab.com/zygoon/rpmtools/blob/master/changes-checker
<zyga> Pharaoh_Atem: I need to take a break from work and ... buy some DVD-RWs
<zyga> (don't ask why)
<zyga> I should actually hop on my bike and go to a mall nearby
<pedronis> zyga: now a remember though there is wrinkle which that  setup-profiles and the active managing *link* tasks are not symmetrics at the moment
<pedronis> zyga: on the Do path we have unlink-current-snap and link-snap  but only one setup-profiles doing both
<zyga> hmm hmm
<zyga> pedronis: I will think about this over weekend
<pedronis> we really to split the tasks over those two somehow
<pedronis> or we get again a misaligned state
<pedronis> zyga: what I mean for example   on undo  the undo of unlin-current-snap should resetup the profile of the old revision
<pedronis> that's not how it works now though
<pedronis> is done much earlier in the undo of setup-profiles
<pedronis> zyga: conceptuall the sequence should have been (but isn't also because of optimisation):  unlink-current-snap -> remove-profiles -> ... -> setup-profiles -> link-snap
<zyga> mmm
<pedronis> that's really the sequence we want to collapse into the *link* tasks
<pedronis> to get correct state behavior
<pedronis> otherwise we still the bug on undo
<zyga> setup profiles has correct undo handling _now_ but I see how the collapse needs to change that
<pedronis> yes, it doesn't work
<pedronis> because again we would on undo setup profiles
<pedronis> while the snap is inactive
<pedronis> it needs to be done in the undo of unlink-current-snap
<zyga> right, I agree; when I said correct I meant undo (if it has the right state) does the setup for the correct revision
<zyga> yep
<zyga> mborzecki, Pharaoh_Atem: can you ack https://build.opensuse.org/request/show/618540
<zyga> (if you agree :)
<zyga> this is up-to-date with master and https://github.com/snapcore/snapd/pull/5377
<mup> PR #5377: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <https://github.com/snapcore/snapd/pull/5377>
<zyga> so please review 5377 first
<zyga> and if that is ok, ack the sync request
<mup> PR snapd#5329 closed: DON'T REVIEW: tests: Adding debug information to know why econnreset is failing <Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5329>
 * cachio akf
<zyga> re!
<zyga> Pharaoh_Atem: how do you like it?
 * zyga feels much better today, having spent a few hours outside
<zyga> I should plan an active outdoor weekend
<zyga> Son_Goku: how do you like my rpmtools script?
<Son_Goku> zyga, hadn't seen it, sorry
<Son_Goku> wasn't at my desk
<zyga> no worries
<zyga> I will play with it to be more full-featured
<niemeyer> pstolowski: Sorry, the meeting has overrun
<niemeyer> pstolowski: I'm available to do it now if you still want to
<Son_Goku> zyga, it looks nice!
<zyga> I'll make it read the rest of the changelog and model it
<zyga> stick a license on top
<zyga> and then look at spec files
<pstolowski> niemeyer: yep, let's
<zyga> to read embedded changelogs from fedora-like systems
<niemeyer> pstolowski: Cool, heading to the standup
<Son_Goku> zyga: nice
<zyga> pstolowski: what's the topic?
<Son_Goku> note that RPM now supports two time styles
<zyga> hotplug?
<pstolowski> zyga: yes
<mup> PR snapd#5381 opened: interfaces: make findSnapdPath smarter <Created by mvo5> <https://github.com/snapcore/snapd/pull/5381>
<zyga> can I listen?
<Son_Goku> the one in changes files, and the one you've seen in spec files
<pstolowski> zyga: sure
<zyga> Son_Goku: oh? they are different?
<zyga> I didn't notice
<zyga> well
<zyga> some testing required :)
<zyga> I'll write a spec file _for_ this tool
<zyga> cool, I'll keep you in the loop
<zyga> Son_Goku: I also plan to see how gitlab CI works
<zyga> to see if I can do a pipeline with mypy/tests, package builds and maybe even publishing
<pedronis> zyga: niemeyer: there is another thing to consider with the plan we discussed, which is what to do about things guaranteed by ifacemanager Runner blocked predicate, now we would have potentially tasks across two managers/runners
<zyga> ah, because setup-profiles would block in the old world but not in the new one (naively) without extra help, correct?
<pedronis> yes
<pedronis> and blocking is messy because two managers/runners
<pedronis> unless we set them up with one runner
<pedronis> which is theoritecally possible
<pedronis> but the predicate would be more involved than the current one
<pedronis> zyga: I wrote something in the topic about what IÂ understand of the plan and also describing this issue
<zyga> Thank you, I will look at it after the call
<zyga> Pharaoh_Atem: do you want to review the changes to opensuse packaging?
<zyga> or shall I pull the trigger and just merge it?
 * zyga merges it
<mup> PR snapd#5377 closed: packaging/opensuse: remaining packaging updates for 2.33.1 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5377>
<ondra> kyrofa ping
<kyrofa> Hey there ondra
<ondra> kyrofa hey
<kyrofa> You're up late!
<ondra> kyrofa just quick question :)
<kyrofa> Hit me
<ondra> kyrofa I know :(
<ondra> kyrofa is there plan to support layouts definitions natively or we will rely on passthrough?
<kyrofa> ondra, oh certainly, just using passthrough while layouts are unstable
<ondra> kyrofa I have situation where I need to overlay ust/lib/<arch>/something
<kyrofa> ondra, feel free to experiment using passthrough, it won't suddenly break once we introduce official support
<ondra> kyrofa and struggling to come up with syntax to make it combined with "- to armhf:"
<kyrofa> Oh, that'll be problematic indeed
<ondra> kyrofa so I use passthrough for this in other projects
<kyrofa> ondra, your concern is the <arch> I'm assuming?
<ondra> kyrofa but here I'd need in top level support for "to <arch>:
<kyrofa> Yeah, no such thing I'm afraid
<kyrofa> This is just to support the <arch> in there, right?
<ondra> kyrofa I guess I cannot use "to <arch> in top level right?
<ondra> kyrofa well there could be two ways
<kyrofa> Correct. But try replacing <arch> with $SNAPCRAFT_ARCH_TRIPLET
<ondra> kyrofa ah that is there?
<ondra> kyrofa let me try
<ondra> this could solve it
<kyrofa> ondra, only in snapcraft, but it'll should turn into a text replacement for the resulting snap.yaml
<mup> PR snapd#5382 opened: tests: add halt-timeout to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5382>
<ondra> kyrofa damn close
<ondra> kyrofa so it replaces only one
<kyrofa> I'm not sure I understand
<ondra> kyrofa https://paste.ubuntu.com/p/QWpVVsk6MC/
<kyrofa> ondra, nooo, that's terrible
<kyrofa> :P
<kyrofa> Let me look into that real quick
<ondra> kyrofa how's that possible? :D
<ondra> kyrofa thanks bunch!
<kyrofa> I suspect a naive search/replace
<ondra> kyrofa no I think I know why
<ondra> kyrofa it's deliberate
<ondra> kyrofa because when you for example use there $SNAP_COMMON
<ondra> kyrofa this cannot be replaces there it has only meaning on actual install
<ondra> kyrofa so I guess there is some rule
<ondra> kyrofa but you do not expect this to be used in actual target, as there is no point overlay your own files, since you have control over those anyway
<ondra> kyrofa but may be we should treat snapcraft's own environment variables differently as those on opposite have no meaning on actual install
<kyrofa> Indeed, and we do. The replacement isn't very smart, it seems
<kyrofa> We pass everything through except these specific types of things
<ondra> kyrofa is there easy fix for this?
<kyrofa> ondra, yes, but it's a snapcraft fix, working on it now
<kyrofa> ondra, I can give you a branch once I'm done, if that's helpful
<ondra> kyrofa ah, thanks buch!
<ondra> kyrofa yeah
<kyrofa> Okay give me a few
<ondra> kyrofa sure :)
<zyga> kyrofa: note, layout spec is stable
<zyga> it's the implementation that varies
<zyga> I think it'd be nice if we could get layouts yaml into snapcraft proper now
<zyga> and hey :)
<zyga> yes, it's late
 * zyga experiments with opensuse 
<ondra> zyga :)
<ondra> zyga so need for snap set core has been removed?
<kyrofa> ondra, any chance you could log a bug for me? Got it licked
<zyga> ondra: not yet
<zyga> but that's the implementation
<zyga> not the yaml
<zyga> kyrofa: licked?
<ondra> kyrofa sure, I can do that
 * zyga burns some recovery DVDs 
<kyrofa> zyga, snapcraft can't break backward compat. As long as you have it behind a feature flag, you can. Until you can't, seems imprudent to bake it into snapcraft
<zyga> mm
<zyga> k
<zyga> I'll do my best to get it off feature flags
<kyrofa> If we didn't have passthrough, it would be different
<kyrofa> zyga, you've never heard someone say "licked" before?
<zyga> no, that's why I'm curious
<zyga> I recall some cartoon
<ondra> zyga I'm all for that feature, I have even git snap pending for release :D
<zyga> when it was clear that this has a second meaning
<kyrofa> zyga, it's a colloquialism, just meaning to beat a problem
<zyga> I see
<zyga> neat
<ondra> lol
 * zyga mutters something about midnight petroleum 
<ondra> kyrofa https://bugs.launchpad.net/snapcraft/+bug/1778287
<mup> Bug #1778287: snapcraft not replacing all occurrences of $SNAPCRAFT_ARCH_TRIPLET <Snapcraft:New> <https://launchpad.net/bugs/1778287>
<ondra> kyrofa I had even evil hack idea to fix it on LP, unfortunately not working
<ondra> kyrofa I called from one override-build: sed -i 's/\/usr\/lib\/.*\/ondra/\/usr\/lib\/'"$SNAPCRAFT_ARCH_TRIPLET"'\/ondra/g' ../../../snap/snapcraft.yaml
<ondra> kyrofa but one can't cheat snapcraft :)
 * cachio afk
<kyrofa> Death, taxes, and snapcraft
<mup> PR snapcraft#2166 opened: project_loader: replace dict keys as well as values <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2166>
<kyrofa> ondra, that's ^ the one you want. I'm building a snap of it now
<ondra> kyrofa how can I test with snapcraft-pr?
<kyrofa> snapcraft-pr.init 2166
<kyrofa> Then use `snapcraft-pr 2166` instead of `snapcraft` in any command
<mup> PR #2166: snap: stop using ubuntu-core-launcher, use snap-confine <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2166>
<ondra> kyrofa running clean build now
<kyrofa> ondra, snapcraft-pr will get angry if you try to cleanbuild. It's the same as running from source: you can't cleanbuild, it'll just pull in the deb
<kyrofa> ondra, if you want to cleanbuild, wait for the snap, or install snapcraft-pr inside a clean container and run it normally in there
<kyrofa> LP claims the amd64 snap is 8 minutes away
<ondra> kyrofa worked :D
<ondra> kyrofa this is simple snap, only stage packages + dump plugin
<kyrofa> Awesome! Mind mentioning that on the PR?
<kyrofa> ondra, would releasing the snap in a branch be helpful to you, or should I cancel that?
<ondra> kyrofa you can cancel that
<ondra> kyrofa I'd need it in LP more
<ondra> kyrofa but not super urgent
<ondra> kyrofa I can manually repack
<kyrofa> ondra, yeah, sorry, not a log I can do about that, but it'll be in the next release
<ondra> kyrofa yeah I know for that we need LP start using snapcraft as snap
<ondra> kyrofa but apparently in works
<ondra> kyrofa but nothing urgent for me now, so I can wait for next release :)
<ondra> kyrofa thanks bunch for quick fix though :)
<cjwatson> ondra: you can select it manually
<ondra> cjwatson how can I do that?
<cjwatson> ondra: currently API-only - see auto_build_channels on https://launchpad.net/+apidoc/devel.html#snap, or channels on https://launchpad.net/+apidoc/devel.html#snap-requestBuild
<ondra> cjwatson this is awesome,  I can see one can choose edge of core :D
<cjwatson> (I have a patch in the review queue to add web UI for it, but you can use it without that)
<cjwatson> yeah, that's mostly intended for QA
<ondra> cjwatson pretty cool
<cjwatson> thanks
<kyrofa> ondra, of course!
#snappy 2018-06-23
<mup> PR snapcraft#2165 closed: many: automatically detect dependency changes <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2165>
<mup> PR snapcraft#2167 opened: many: detect local source changes <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2167>
<davido_> Is there a solution for the inconvenience of snaps filling df output with /dev/loop* lines?
<davido_> I understand that it is correct behavior, just unfortunate correct behavior. :)
<mup> PR core18#35 opened: hooks: add netcat package <Created by mvo5> <https://github.com/snapcore/core18/pull/35>
<mup> PR snapd#5383 opened: tests: make snap-connect aware of snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/5383>
<mup> PR snapd#5384 opened: tests: update interfaces-timeserver-control to core18 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5384>
<mup> PR core18#36 opened: hooks: set timezone to Etc/UTC <Created by mvo5> <https://github.com/snapcore/core18/pull/36>
<Son_Goku> zyga, I went through some of the old SELinux warning bugs and attached them to the Fedora updates as appropriate
<Son_Goku> all those bugs will automatically close upon those updates making it through to stable updates
#snappy 2018-06-24
<taaperotassu> I installed hugo with snap.  When I try using hugo in right directory I get "-bash: /usr/bin/hugo: No such file or directory" putting export PATH=$PATH:/snap/bin/ in my .bashrc didnt fix the problem. How should this be used as?
<taaperotassu> Oh I just had to reopen my terminal.
<cjwatson> hash -r probably would've done it too
<cjwatson> taaperotassu: ^-
<taaperotassu> cjwatson: thanks
<jpleau> Hi. On snapcraft.io/store, is there a way to list all available snaps without installing anything on my machine? I'd like to browse what's available but not sure where to go
#snappy 2019-06-17
<mborzecki> morning
<zyga> Good morning
<zyga> I will have to swap today
<jamesh> hi zyga.  How was Montreal?
<zyga> Too many things overlap (passport, doctor, another doctor)
<zyga> jamesh: hello!
<zyga> Very successful
<zyga> Unbelievably so I would say
<mborzecki> zyga: jamesh: hi
<jamesh> that's good to hear
<mborzecki> zyga: you're swapping today?
<zyga> Yes
<zyga> I have to
<mborzecki> zyga: ack
<zyga> jamesh: there are details on the forum
<zyga> Mborzec mborzecki during last week we noticed that bash completion is broken on centos
<zyga> No bug report yet because the principal centos user is from Australia and I believe has even more jet lag
<mborzecki> zyga: hah ok, i can look into this
<mborzecki> zyga: could have gone unnoticed, i'm using zsh usually and the cloud images don't come with bash completion installed
<mborzecki> hmm but we have sprewa tests for this
<zyga> Maybe is is not broken per se
<zyga> Just not working something
<zyga> Somehow
<zyga> Worth just trying it out interactively
<mborzecki> zyga: yeah, will do
<zyga> I have some thoughts to share about other topics but I am too jet lagged now I
<mborzecki> zyga: bash completion for snap command or snaps?
<mborzecki> mvo: morning
<mborzecki> btw. does completion ignore hidden flag of commands?
<mvo> hey mborzecki !
<mvo> mborzecki: idk, john probably does
<mborzecki> mvo: try snap remo<tab><tab>
<mvo> mborzecki: I just did a quick test - it does not afaict
<mborzecki> mvo: mhm, remodel pops up :/
<mvo> mborzecki: yeah, annoying
<mvo> mborzecki: we could could into an upstream fix for this one
<zyga> mborzecki: I think for the snap command
<zyga> Hey mvo
<mvo> hey zyga ! how are you?
<zyga> mvo: I am sorry but I need to swap today out, two doctor visits and passport (in person) pick ups
<zyga> mvo: apart from jet lag
<mvo> zyga: sure, thats fine, good luck
<zyga> And +15C
<zyga> Okay :-)
<mvo> zyga: woah, yeah
<zyga> I have some things to share from last week
<zyga> (As in *additional* +15C)
<mvo> zyga: looking forward to hear what you have to share
<mvo> zyga: good luck adjusting to the new climate :)
<mborzecki> mvo: looks better now https://paste.ubuntu.com/p/DGT6k9DhhW/
<mvo> mborzecki: oh, what did you do?
<mborzecki> mvo: https://paste.ubuntu.com/p/vXZYYy7C9m/
<mborzecki> mvo: hoped we could do it in custom CompletionHandler but there does not seem to be a way to tell what is the kind the completion (commmand, argument etc.)
<mvo> mborzecki: aha, I see! thanks. will you submit upstream?
<mborzecki> mvo: yes
<mvo> ta
<mborzecki> mvo: fwiw they fixed it for options back in 2016: https://github.com/jessevdk/go-flags/commit/32811b87051d3e1dc77d2c9925473f2a4a07abdf
<mborzecki> mvo: https://github.com/jessevdk/go-flags/pull/312
<mvo> mborzecki: cool, thanks!
<mvo> mborzecki: funny how sort the test is :)
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> hey pstolowski ! good morning
<mborzecki> zyga: hm completion seems to work on centos just fine
<pedronis> mvo: hi, I proposed the re-registration PRs
<mvo> pedronis: nice!
<Chipaca> ð
<Chipaca> pedronis: you around?
<pedronis> Chipaca: yes
<Chipaca> pedronis: can we talk about the direction for health?
<Chipaca> pedronis: (or schedule it)
<pedronis> Chipaca: we can do a quick chat yes
<Chipaca> pedronis: ok. AIUI what we want is to be able to call set-health in an arbitrary hook, and when not in a hook
<Chipaca> pedronis: anything else?
<pstolowski> ha, 'Invalid PR title: "state-inspect debug utility"'. it works :)
<pedronis> Chipaca: not particularly
<pedronis> Chipaca: about the other point,  I see two options always writing to state directly,  or set an OnDone if the context doesn't have a "health" entry yet
<pedronis> the first approach means the systema always sees health immediately
<pedronis> the 2nd means for hooks is set only once at the end
<pedronis> *two options:
<Chipaca> pedronis: hmm
<pedronis> Chipaca: I think I prefer the 2nd option
<Chipaca> pedronis: i'll dig into what it entails
<Chipaca> pedronis: should be simple enough (famous last words)
<pedronis> Chipaca: yes, it should be simple,  for why I prefer it, a bit more consistent with how snapctl set works
<pedronis> also not sure we want people to rely on set-health being immediate
<Chipaca> yeah, we're not a cheap message passing thing :)
<mborzecki> opensuse repos broken again?
<pedronis> Chipaca: you'll need to see how interacts with setting of the check-health hook also based on weather it was set at all or the hook failed
<pedronis> but should be workable
 * Chipaca adds a note to have check-health look at the weather
<Chipaca> pedronis: :) no worries, i think i got what you mean
<pedronis> *wether
<Chipaca> :)
<Chipaca> pedronis: *whether
<Chipaca> pedronis: a wether is a castrated ram
<Chipaca> pedronis: probably not what you meant
<Chipaca> cf widder vs weder
 * Chipaca shuts up and goes to work hacking health into submission
<Chipaca> mvo: btw I re-opened #6582 and tagged it for 2.40, robert_ancell confirmed (as you can read in the pr) that things are ready for this
<Chipaca> pedronis: any opinion on snapd-hook-no-health-set vs snapd-no-health-set-in-hook?
<zyga> mborzecki: https://bugs.launchpad.net/bugs/1833043 from cmake developer on centos
<zyga> Completion inside sandbox, not for snap itself
<mborzecki> zyga: ah, so it's completion for snap apps
<Chipaca> looks like a tweak's needed in complete.sh
<Chipaca> although it already tries to grab it from core
<Chipaca> â¦ with the wrong path for it there
<Chipaca> sigh
<Chipaca> so it's a bug :)
<Chipaca> no, sorry, misread, it's something else
<Chipaca> gah, CoreLibExecDir
<Chipaca> â¦ but that's ok, right? it should be 'inside'?
<mborzecki> Chipaca: CoreLibexecDir should be fine
<Chipaca> mborzecki: should it still be fine in a classic snap?
<mborzecki> Chipaca: [pid 11525] execve("/bin/bash", ["/bin/bash", "/usr/lib/snapd/etelpmoc.sh", "/var/lib/snapd/snap/cmake/12/sha"..., "9", "9", "11", "2", " ", "cmake -G Ni", "cmake", "-G", "Ni
<mborzecki> "], 0xc00006b080 /* 45 vars */ <unfinished ...>
<mborzecki> Chipaca: hm that should prepend snap mount path for classic, shouldn't it?
 * Chipaca has 0.0â¦0 idea
<mborzecki> Chipaca: hm so snap run will run snap-confine --classic --base .. snap.cmake.cmake /usr/libexec/snapd/snap-exec .. , but then snap-exec calls etelpmoc.sh as if it is inside the mount ns, which it isn't
<mborzecki> Chipaca: we should probably have CompletionHelperInCore and CompletionHelper, then looking at NeedsClassic() pick the right one
<mborzecki> Chipaca: i can look into the fix
<mborzecki> shoudl be quite simple
<Chipaca> mborzecki: thanks
<mborzecki> Chipaca: yay, seems to work now
 * Chipaca hugs mborzecki 
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7008
<Chipaca> mborzecki: thank you
<mborzecki> Chipaca: wondering whether we should assume core/current, what if snap has a different base?
<Chipaca> mborzecki: magic pixies fly in the window and fix it?
<mborzecki> xD
 * pstolowski lunch
<pstolowski> pedronis: thanks for the 2nd pass over base validation PR
<pedronis> np, thank you
<mborzecki> off to pick up the kids
<pedronis> Chipaca: I reviewed #7001, thank you
<pedronis> Chipaca: I asked you for another pass in #6680
<diddledan> kenvandine: or willcooke: with the snapd support for fontconfig caches being build up-front, do we need to change the desktop-helpers and the gnome extension PR to match?
<kenvandine> diddledan: i don't think so
<diddledan> ok, cool
<Chipaca> pedronis: thanks for the review, will fix that messaging
<diddledan> jdstrand_: gimp requires gvfs access (over dbus) to org.gtk.vfs.Daemon which I think is on the session bus in order to open it's internal help documents. I don't see from a quick glance any interfaces covering this
<jdstrand_> diddledan: there is some stuff for gvfs in desktop-legacy, but not org.gtk.vfs.Daemon. why is it talking to the daemon? what is it trying to access?
<diddledan> I'm not sure
<diddledan> this is the message I get in a dialog when I try to open the internal help:
<diddledan> Could not open 'https://docs.gimp.org/2.10/en/gimp-help.xml' for reading: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.448" (uid=1000 pid=13202 comm="/usr/lib/gimp/2.0/plug-ins/help/help -gimp 14 13 -" label="snap.gimp.gimp (enforce)") interface="org.gtk.vfs.Daemon" member="GetConnection" error name="(unset)" requested_reply="0" destination=":1.95"
<diddledan> (uid=1000 pid=8614 comm="/usr/lib/gvfs/gvfsd-http --spawner :1.22 /org/gtk/" label="unconfined")
<diddledan> it looks like it's using gvfs to download the help document
<jdstrand_> diddledan: ok, right, it is using gvfs for http access. that is indeed not currently supported. the Daemon apis give a sandbox escape since you can specify a (file) url on the command line and gvfsd, which is unconfined, will give the snap the file
<jdstrand> diddledan: gimp should be adjusted to use xdg-open
<mborzecki> opensuse repos still flaky
<Chipaca> mborzecki: <surprised electric mouse poket monster>
<mborzecki> Chipaca: sounds like you caught a pikachu :)
<Chipaca> mborzecki: more like a dedenne
<mborzecki> hahaha
<Chipaca> * this conversation is being supervised by 14-year-olds
<Pharaoh_Atem> mborzecki: openSUSE's mirrorbrain crashed and burned this morning
<mborzecki> Pharaoh_Atem: as in literally or just some random outage?
<Pharaoh_Atem> random outage
<mborzecki> hah, there it is: https://status.opensuse.org/
<Chipaca> Pharaoh_Atem: if it's any consolation, so did all of Uruguay, most of Argentina, and a good chunk of Brazil
<mborzecki> Chipaca: still around? can you take another look at https://github.com/snapcore/snapd/pull/6680 ?
<albertosottile> jdstrand: sorry to bother you, are we supposed to do anything else for the alias request?
<jdstrand> albertosottile: no. there is a 7 day voting period. people were travelling thu/fri so just haven't gotten the votes yet is all
<albertosottile> jdstrand: thanks :)
#snappy 2019-06-18
<zyga> Hello
<zyga> hey mvo
<zyga> mborzecki asked me to make the dragonboard available so I'm starting the day with that
<zyga> I will then switch to some administrative tasks and write down my notes from the summit
<zyga> I will then switch to the branch that explains sandbox status in a more readable manner
<zyga> and will follow up with the surgeon at 13:30
<zyga> I will be back for the standup but unlikely to be able to speak (I can type though)
<mvo> hey zyga
<mvo> zyga: thanks, good luck!
<pstolowski> morning
<zyga> pstolowski: hello
<mvo> hey pstolowski
<zyga> does anyone know where we store wifi data?
<pstolowski> mvo: hey, shall i take over #7000?
<zyga> is it natively in netplan
<zyga> or is it compiled into something else and netplan is just a snapshot from the past?
<zyga> I need to change wifi settings on a dragonboard
<zyga> I took the card out
<mvo> pstolowski: if you don't mind, +1
<pstolowski> mvo: allright
<mvo> pstolowski: I'm poking at some uc20 things right now :/ (tpm in qemu seems to be a bit tricky)
<pstolowski> mvo: sure, i figured you may be busy with other stuff, and 7000 turned out to be more involved than expected
<mvo> pstolowski: indeed, thanks for taking it!
<zyga> hey, dragon works!
<mvo> dragons work!
<zyga> :)
<zyga> here be dragons (for sureA)
<mvo> :)
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mborzecki> mvo: hey
<zyga> mborzecki: hello
<mborzecki> mvo: some simple PRs if you could take a look: https://github.com/snapcore/snapd/pull/7009 https://github.com/snapcore/snapd/pull/7008
<mvo> mborzecki: sure, let me check
<mvo> 6691 needs a second review as well fwiw
<mvo> zyga: do you want to quickly double check 6327?
<zyga> looking
<Chipaca> I just told a user that 'their expectations were not founded in reality', and feel bad
<mborzecki> Chipaca: harsh reality check for snap apps?
<Chipaca> ye
<Chipaca> to offset feeling bad about telling them that, I had to manually approve that thing, so it â¦ evens out? maybe?
<mborzecki> Chipaca: tbh looks like a highly motivated user
<mborzecki> screenshots even, wow
<zyga> mborzecki: reviewed https://github.com/snapcore/snapd/pull/7008
<mborzecki> zyga: thanks
 * Chipaca halts his move to a completely different packaging format, at popey's suggestion
<popey> :)
 * Chipaca instead gets coffee
<pedronis> mvo: I finally did a pass on #6839, some things to improve/fix
<mvo> pedronis: thank you
<Chipaca> zyga: who are you and why did you think we wouldn't notice you were a Java developer masquerading as the real zyga
<zyga> Chipaca: BUSTED :)
<zyga> Chipaca: I feel dizzy
<zyga> need coffee
<zyga> I cannot sleep
<zyga> it's too hot here
<Chipaca> zyga: you must have picked the wrong ZygaRelaxingStrategyFactory
<zyga> Chipaca: just wrap it in LooksLikeGoFacade
<mborzecki> osx travis job failed with: error: cannot pack "tests/lib/snaps/test-snapd-tools/": mksquashfs call failed: exec: "mksquashfs": executable file not found in $PATH
<mborzecki> Chipaca: do you remember if mksquashfs was already there in travis osx images or is it rather sth installed via brew?
<Chipaca> mborzecki: pulled in by brew
<Chipaca> mborzecki:       addons:
<Chipaca>         homebrew:
<Chipaca>           packages: [squashfs]
<Chipaca> mborzecki: in the .travis.yml
<mborzecki> Chipaca: mhm, see that :/ i've restarted the job, maybe something broke there
<mborzecki> Chipaca: obviously homebrew is broken :/
<Chipaca> mborzecki: yay
<mborzecki> https://paste.ubuntu.com/p/7jBZbTPfD5/
<Chipaca> mborzecki: you can manually trigger the rest fwiw
<mborzecki> zyga: completion tests are not disabled on centos, there's just no test that does that with classic snap
<zyga> mborzecki: ack
<mborzecki> zyga: so manjaro went with /snap -> /var/lib/snapd/snap symlink eventually?
<zyga> yes
<zyga> I made coffee but I feel so tired anyway
<zyga> eh
<zyga> well
<mborzecki> ehh, so we cannot use cmd.InternalToolPath("etelpmoc.sh") when looking up completion helper, bc it'll break confined snaps on centos/amzn as /etc/os-reelase is not a symlink
<zyga> hmmm
<zyga> mborzecki: because we need to know late, in snap-exec?
<mborzecki> yeah
<mborzecki> zyga: i'll do a similar thing, just picking up the tool from the same dir as snap-exec, without fallback to distrolibexecdir
<zyga> mborzecki: could we describe the distribution in /var/lib/snapd/ somewhere?
<zyga> mborzecki: a text file with key=value fields
<zyga> libexecdir=...
<mborzecki> zyga: we could, but it feels like something that needs to be discussed and so on
<zyga> (perhaps reexec policy later on)
<zyga> mborzecki: yeah, but I think that's unavidable
<zyga> *unavoidable
<zyga> Going for the tooth removal surgery now
<zyga> Wish me luck
<zyga> I will try to join the standup but will be most likely unable to talk
<zyga> See you
 * pstolowski lunch
 * pedronis reboots
<mborzecki> https://github.com/snapcore/snapd/pull/7012 anyone?
<mborzecki> Chipaca: ^^
<zyga> Me looks
<mborzecki> zyga: looks like a bug in homebrew and somehow it went unnoticed by travis :/
<mborzecki> dupadupa
<mborzecki> damn, my super secure password just leaked out :)
 * Chipaca confirms that mborzecki is an oompa loompa
<pedronis> mborzecki: did another pass on 6922
 * Chipaca creates a core base called "laughable" that ships with telnetd and the whole r-commands running
<Chipaca> (this in reference to nearly 15% of all routers shipping with ftp and/or telnet open and with default creds)
<pedronis> pstolowski: I have a question in 6977
<pstolowski> pedronis: uhm. need to think
<pedronis> pstolowski: my proposal because of that was to this at a lower level
<pedronis> s/to this/to do this/
<pedronis> pstolowski: we can chat again
<pstolowski> pedronis: i think SnapID was the problem, but maybe i'm missing something
<mborzecki> pedronis: thanks, https://github.com/snapcore/snapd/pull/6922 updated
<mborzecki> obviously osx PR failed in some random spread test :/
 * Chipaca takes a break
<zyga> Going Home
<zyga> Teethâ
<pedronis> pstolowski: we should chat after standup if it's not too long
<pstolowski> pedronis: ok
<mborzecki> hhmmmm Jun 18 12:42:05 jun181214-025479 snapd[20228]: stateengine.go:102: state ensure error: cannot decode new commands catalog: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/names?confinement=strict%2Cclassic"
<mvo> mborzecki: I merged your squashfs unblocker
<mborzecki> mvo: yay, thank you!
<mvo> so everyone can go wild with merging master into the failing ones (like 7009 which is ready except not green)
<mborzecki> https://paste.ubuntu.com/p/3wRmybfq5t/ apt-hooks failing
<mvo> mborzecki: this usually indicates a store problem
<mvo> Jun 18 12:42:05 jun181214-025479 snapd[20228]: logger.go:74: DEBUG: < "HTTP/1.0 403 Forbidden\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n"
<Chipaca> mborzecki: 403 is storespeak for 420
<mborzecki> Chipaca: teapot?
<mborzecki> ah, enhance your calm, fair enough ;)
<mborzecki> degville: that manjaro thread is pure gold, hilarious ;)
<degville> mborzecki: yeah! :)
<Chipaca> mborzecki: degville: what was the link again? :)
<degville> Chipaca: https://forum.manjaro.org/t/manjaro-planning-to-support-snaps-officially/81972/99
<Chipaca> degville: thanks
<Chipaca> why
<mborzecki> why why?
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7008#pullrequestreview-251115435
<mborzecki> zyga: hah, i'll move the line up a bit
<Chipaca> mborzecki: I mean, it's good that there exists corners of the internet where the discussion could be cut-and-pasted into a forum from 20 years ago and nobody would tell the difference
<mborzecki> zyga: the indents there are 1 space per level
<Chipaca> mborzecki: it's just not good _for me_
<zyga> ah
<zyga> ok :)
 * dot-tobias says hi
<jdstrand> hey dot-tobias :)
<pedronis> mborzecki: it would be great to land #6922 so to make #6890 a bit more reviewable
<mborzecki> pedronis: yeah, already pinged zyga, want to land as many PRs as i can today
<Eighth_Doctor> zyga, mborzecki: need fc29 update karma: https://bodhi.fedoraproject.org/updates/FEDORA-2019-91c0be0cc5
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6922/files#diff-7c4a0d9bd3c13f6d1c75144f29cafdc6R34 is contentsDir the place where the filesystem is mounted?
<zyga> mborzecki: sent partial review
<zyga> be back in an hour, hopefully the painkillers work
<dot-tobias> How can I call a script file in my snap's local source *without* copying it to the final snap? Use case: I have a script to determine the snap's version number from source (which is not currently supported by snapcraft's app info parsers). I don't want to add a separate part for it and then remove it after use, but hardcoding the path to <snapcraft-dir>/src/<scriptname> seems finicky.
 * Chipaca takes a break
<mborzecki> brb, kernel update
 * cachio afk
 * mborzecki afk too
<Chipaca> EOD ð
#snappy 2019-06-19
<zyga> Good morning
<zyga> It rains, finally
<amurray> zyga: how's your mouth?
<mvo> hey zyga and amurray
<mvo> zyga: yeah, how are you today?
<mvo> good morning sil2100
<sil2100> Morning o/
<pstolowski> mornings!
<zyga> Hey. It hurts and bleeds but I think it is better than yesterday evening
<zyga> Had a rough night but I am trying to get back to my feet
<pstolowski> zyga: sounds scary, hope it's not too terrible.. get some rest
<pstolowski> mvo: hey, ok to close #7000? i'll propose a new one
<mvo> pstolowski: yes, thats fine
<jamesh> pedronis: hi.  Re: the user session agent PR, I was able to put something together to have xenial's dbus-daemon launch a systemd version of "snap userd" with the right environment.
<jamesh> pedronis: the problem comes when adding unix socket activation, since that provides a new method of starting the service that bypasses the environment load
<pedronis> jamesh: I see, we should be able to do something about that, no?
<jamesh> pedronis: the normal way the environment gets populated is through /etc/X11/Xsession.d/95dbus_update-activation-env
<jamesh> pedronis: and the dbus-update-activation-environment helper program doesn't seem to handle the case when the systemd user instance is not present on the bus
<mvo> pstolowski: looking forward to see the new one, but fwiw, I think we should not make the perfect the enemy of the good, just dealing with missing "core/current" will already help even though we don't deal with "snapd" yet
<pedronis> jamesh: my point, can't setup something that runs on sessions that can talk to the systemd userd ?
<pedronis> sorry
<jamesh> it's not clear where we should get the environment from in this case
<pedronis> jamesh: ?
<jamesh> hmm.  maybe within the "snap userd --autostart" call?
<pedronis> for example
<jamesh> pedronis: systemctl can talk to the user instance because it has some private back channel for this case
<pedronis> jamesh: my main point is that exept userd instances to be able to somehow setup talking to each other
<pedronis> they could talk over sume /run files
<pedronis> or something else
<pedronis> *some
<jamesh> pedronis: I'm still not entirely sure what the benefit of having these two separate tasks colocated in the same process is though.
<pedronis> jamesh: how do we do user notifications if they are not?
<pedronis> it one of the things you said we cannot do we they aren't
<pedronis> maybe I misunerstood you
<jamesh> pedronis: we can do that with just the session bus address, which I think I can work out a way to get
<pstolowski> mvo: in the new version of 7000 i'm simply comparing snapd version string and got rid of the entire current symlink & refresh time logic
<jamesh> being able to do xdg-open relies on a lot more
<pedronis> jamesh: but in bionic we could have signle process though?
<pedronis> *single
<jamesh> pedronis: yes.
<pedronis> jamesh: as I said I'm a bit worried to have a design that is more meant to accomodate xenial, than bionic
<pedronis> but I understand there a trade offs
<jamesh> pedronis: I'd see it more as allowing existing functionality to continue as is.
<mvo> pstolowski: sweet
<mvo> pstolowski: that sounds like the right approach, thank you!
<jamesh> pedronis: also, having some separation between a service performing actions on behalf of untrusted apps and a service performing actions on behalf of snapd doesn't sound like a bad thing
<pedronis> jamesh: you wrote this: "This also means that we will likely wonât be able to have the REST service post desktop notifications on Xenial. "
<pedronis> you are saying this doesn't need to be true?
<jamesh> pedronis: yes.  I noticed afterwards that the Upstart job is writing the bus address to $XDG_RUNTIME_DIR/dbus-session
<jamesh> pedronis: so a hack sufficient to get notifications working on Xenial would be to check for that file when $DBUS_SESSION_BUS_ADDRESS is not set
<pedronis> jamesh: if it's to fiddly to get one process on xenial, I'm ok with two processes, as long as we keep it can keep their functionality clearly separate, we don't have things we want to do that we can't
<jamesh> that doesn't generalise to the xdg-open case though (I don't think)
<pedronis> notifications and getting user input on them is one of them
<pedronis> pstolowski: thanks for #7014
<pedronis> I'l try to look at it soon
<pstolowski> yw, ty
<jamesh> that's another issue: Unity 7's notifications design explicitly doesn't support actions
<pedronis> I imagine it's fairly mechanic
<pedronis> ^ this was about #7014 (to be clear)
<jamesh> that said, I don't think popping up dialogs will be particularly popular as an alternative
<jamesh> anyway.  That's something to test down the road
<pedronis> yes, in theory it would be better if it was up to the snaps
<pedronis> to display things
<pedronis> not snapd itself
<pedronis> but we'll have to see
<pedronis> jamesh: can you write something about notifications and how to get hold of the session dbus on xenial and bionic in the forum topic
<jamesh> sure.
<jamesh> I need to check what notify-osd actually does if I post a notification with actions.  At one point it converted it to a dialog itself.  Not sure about now.
<pedronis> jamesh: thank you
<seb128> jamesh, it still does that, notify-osd didn't change for like 7 years :)
<jamesh> seb128: that's probably a good thing in this case.  Thanks
<seb128> yw!
<jamesh> pedronis: fwiw, it looks like CentOS 7 doesn't have a user instance of systemd at all, so it is like Ubuntu 14.04 in that respect
<pedronis> jamesh: ok, we'll need to think about degradation of these features
 * zyga just spilled coffee over *everything* on his desk
<zyga> this is not my day
<jamesh> pedronis: if you only care about CentOS 7 on servers it is probably fine.  CentOS 8 is just around the corner too
 * pstolowski school end & early lunch, bbl
<Chipaca> pedronis: should 'snapctl set-health' be usable as non-root?
<pedronis> Chipaca: do we even have that concept for snapctl commands ?
<pedronis> Chipaca: anyway if the cookie is right I don't see why not
<pedronis> Chipaca: am I missing something?
<Chipaca> pedronis: I'm not sure what you're wanting to ask wrt your 1st question
<Chipaca> pedronis: currently 'snapctl set-health' fails with 'error: cannot use "set-health" with uid 1001, try with sudo'
<pedronis> Chipaca: mmh ?
<pedronis> did we change something
<pedronis> was it always like that?
<pedronis> I thought for snapctl we used a different socket
<pedronis> and only the cookie counted
<Chipaca> overlord/hookstate/ctlcmd/ctlcmd.go:	return &ForbiddenCommandError{Message: fmt.Sprintf("cannot use %q with uid %d, try with sudo", f.Name, f.Uid)}
<Chipaca> (which is funny because how is sudo going to work 'inside')
<Chipaca> (from a hook i mean)
<Chipaca> bah, hooks are run as root i guess?
<pedronis> yes
<pedronis> hooks are run as root
<Chipaca> pedronis: there's a whitelist of not-root things
<Chipaca> right now it's "get" and "services" that are whitelisted
<pedronis> where is it?
<pedronis> apparently I didn't know about this
<Chipaca> pedronis: overlord/hookstate/ctlcmd/ctlcmd.go line 124
<pedronis> interesting
<pedronis> but ok
<pedronis> Chipaca: I sort feel like setting healt should be ok not from root
<pedronis> though
<pedronis> *health
<Chipaca> ok done
<Chipaca> hmm, revision is _not_ getting set :-(
 * Chipaca hmms
<pedronis> Chipaca: ephemeralContext sets snap name but not revision
<pedronis> see hookmgr.go
<Chipaca> pedronis: but I'm also getting unset when it's not ephemeral (ie when it's a hook)
<pedronis> ah
<pedronis> I feared that, I thought we discussed that
<Chipaca> yeah
<Chipaca> I got a revision in there at some point
<Chipaca> oh wait
<Chipaca> pedronis: i'm using 'try', which don't do revisions there
<alan_g> sergiusens, we thought (apparently wrongly) that the LP builders could handle "layouts", so we dropped "passthrough" for the Mir related snaps and started seeing "Issues while validating snapcraft.yaml: Additional properties are not allowed ('layout' was unexpected)". Any thoughts?
<alan_g> Here's an example: https://launchpadlibrarian.net/429275346/buildlog_snap_ubuntu_bionic_i386_mir-test-tools-edge_BUILDING.txt.gz
<cjwatson> alan_g: This doesn't sound like something where Launchpad has much of an opinion either way ...
<cjwatson> alan_g: Looks like you're not using a base?  In that case you'll be using the snapcraft .deb package rather than the snap
<cjwatson> alan_g: That probably accounts for whatever difference you're seeing
<cjwatson> alan_g: Oh, huh, you are using a base.  How are you requesting these builds exactly?
<cjwatson> I think you're probably using an old API method
<alan_g> Saviq, ^ you probably know how we're starting these
<Saviq> that's very likely
 * Saviq waits for github
<Saviq> cjwatson: https://github.com/MirServer/mir/blob/master/tools/process_snaps.py#L247
 * Saviq missed the memo that there's new API
<cjwatson> OK, so the problem with the API you're using is that it's synchronous so we can't fetch snapcraft.yaml from the source repository and inspect it to decide what to do without a serious risk of timeouts
<cjwatson> (This was a mistake but we didn't realise it when we designed that API the first time round)
<cjwatson> Saviq: You want https://launchpad.net/+apidoc/devel.html#snap-requestBuilds - so instead of "builds = snap_recipe.requestAutoBuilds()", use "snap_recipe.requestBuilds(archive=snap_recipe.auto_build_archive, pocket=snap_recipe.auto_build_pocket, channels=snap_recipe.auto_build_channels)"
<cjwatson> (Or different values of archive/pocket/channels if you like, but that will preserve existing behaviour)
<Saviq> cjwatson: ack, thank you
<cjwatson> Note that this doesn't and can't return the list of created builds (because it's asynchronous), but you weren't using them anyway
<Saviq> indeed
<zyga> I collected my notes from the sprint and published them to the forum: https://forum.snapcraft.io/t/snapcraft-summit-2019-montreal-a-snapd-perspective/11905
<zyga> Wimpress: ^  feedback welcome, I specifically made this separate from the main thread because those are things that are mainly of interest to the snapd development and design team
<zyga> break for some water
<zyga> mvo: ^ more less complete
<popey> zyga: tweet out a link with a nice description and a photo of your montreal summary and I'll get it shared from snapcraftio
<zyga> popey: sure, will do :-)
<Wimpress> Nice write up zyga :-)
<popey> ok, just ping us a link when done
<pstolowski> re
<sergiusens> zyga: nice, typo alert (Gotod)
<zyga> sergiusens: thanks! I will fix that shortly
<zyga> popey: https://twitter.com/zygoon/status/1141316717899071489?s=21
<popey> haha.. that's an interesting photo!
<Wimpress> Eye catching you might say :-)
<zyga> Eye popping
<Wimpress> I've replied to my post on the internal mailing list with a link to your forum post zyga
<popey> thanks!
<cwayne> it feels like zyga is staring into my soul
<cwayne> and im worried he doesn't like what he sees
<Wimpress> Well, it me stood behind him; so a fair assessment.
<cmatsuoka> mvo: did you just resolve a comment in the slides?
<cmatsuoka> (it disappeared in front of my eyes)
<Pharaoh_Atem> zyga: you look like you've drank too much coffee
<mvo> cmatsuoka: I didn't, at least not just now, just returned from lunch :)
<cmatsuoka> mvo: hm, strange, perhaps I deleted it by mistake but undo can't bring it back so -- it was the one about the separate recovery kernel
<cmatsuoka> mvo: I added that because we would need a separate extracted kernel for u-boot, otherwise selecting a new kernel for recovery would affect the next normal boot
<cmatsuoka> (if it overwrites the existing extracted kernel)
<cmatsuoka> does it make sense? otherwise I can just remove that entry from the slides
<mvo> cmatsuoka: aha, I think I know what you mean - but please update and mention it only affects uboot at this point
<cmatsuoka> mvo: done that already
<mvo> ta
 * cachio lunch
<abeato> jdstrand, hey, I have a couple of minor MPs related to interfaces: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975
<jdstrand> abeato: done, thanks! :)
<abeato> jdstrand, thank you!
<mvo> pedronis: just fyi, I'm triggering a new edge core build now (will take a little bit until all the bits are ready)
#snappy 2019-06-20
<pedronis> Chipaca: seems github is not fully happy atm
<pedronis> yes: https://www.githubstatus.com/
 * Chipaca reboots github
 * popey tickles zyga with https://forum.snapcraft.io/t/snapd-on-suse-linux-enterprise/5991/6
<popey> (I was asked by a consultant who uses SLES, specifically on s390x)
<pedronis> Chipaca: seems to have worked now: https://github.com/snapcore/snapd/pull/7018
<Chipaca> nice
<popey> https://bugs.launchpad.net/snappy/+bug/1833523
<popey> I thought that would already be filed, but couldn't find one, so filed it
<Chipaca> popey: at that point, why not 'apt purge snapd'?
<Chipaca> (that will remove core)
<popey> removing an entire package manager to remove a package I don't want seems overkill
<popey> and no, it doesn't
<popey> 389M    /var/lib/snapd
<popey> still 2 cores in there
<popey> Oh, my bad, it does remove them, sorry.
<popey> (still not ideal)
<Chipaca> popey: commented on the bugs itself
<Chipaca> for posterity
<Chipaca> bug*
<Chipaca> popey: one thing we could do is change the condition to just 'is snapd running from this snap'
 * Chipaca dunnos
<Eighth_Doctor> it'd be nice to be able to purge those snaps on Fedora systems when they're not needed
<Eighth_Doctor> we don't ever run snapd from a snap, since reexec is disabled
 * Chipaca nods
<Chipaca> #6582 could use a second review
<pedronis> Chipaca: it's a bit unclear to me from what robert says if 2.40 is ok for this, or 2.41 would be better
<Chipaca> pedronis: it's 'as ready as it's going to be'
<pedronis> but he said some things were in progress
<pedronis> otoh 2.40 will land in a while
<Chipaca> pedronis: the phased update should be done already (we can check)
<Chipaca> pedronis: and yeah 2.40 in stable is a while away still
<Chipaca> pedronis: the snap-store snap in stable is newer than his comment :)
<pedronis> I'll look it at it again in a bit
<pedronis> I'm going a bit over thinsg that have at least an approved and see if there are some easy wins there
<Chipaca> pedronis: https://gist.github.com/chipaca/911a8a4905b091c10caa9854bf7ea4b4
 * Chipaca takes a break
<popey> ogra: your qemu-virgil snap - i made a snap which has qemu-system-x86_64 stock from ubuntu and uses kvm interface.. but fails to launch can't access KVM module...
<popey> ogra: did you have to do any voodoo or such other than connect the interface?
<popey> oh, looks like I bugged you about this 2 years ago :D https://forum.snapcraft.io/t/seeking-feedback-qemu-virgl-fully-3d-accelerated-qemu/6836/
<popey> (still doesn't work)
<popey> (in my snap)
<diddledan> I love when you discover that you gave up in the past and forgot all about it
<popey> the annoying thing is, his snap works and mine doesn't and I can't see what's different.
<diddledan> yeah ogra's snap doesn't look to be doing anything particularly magic
<popey> hm, weird
<popey> wonder if it matters that I'm doing snap try
<Chipaca> popey: if it does, let us know as it'd be a bug
<popey> ooh, hang on, I've got virtualbox running, that won't help
<diddledan> aaah
<popey> nope, not that
 * popey snapcraft packs
<popey> hm, not that
<popey> no apparmor denials
<Chipaca> popey: core vs core18?
<popey> i have both installed
<popey> it connects to core
<popey> but i said core18 in the yaml
<Chipaca> popey: if you snap run --shell, can you check the permissions of /dev/kvm?
<popey> will do, otp
<Chipaca> popey: it's probably not that (i checked)
<popey> $ ls -l /dev/kvm
<popey> crw-rw---- 1 root kvm 10, 232 Jun 20 16:28 /dev/kvm
<popey> ^ that is from inside the snap, and "groups" shows I'm not in the kvm group. Wonder if it's just that
<Chipaca> popey: that wouldn't explain ogra's version working
<Chipaca> popey: as you'd need to be in group kvm in both places
<popey> true
<popey> how confusing
<Chipaca> I blame â¦
<Chipaca> Lawn mower blade in your fan need sharpening
<popey> -_-
<Chipaca> no? ok try again
<Chipaca> Just pick up the phone and give modem connect sounds. "Well you said we
<Chipaca> should get more lines so we don't have voice lines."
<popey> I'll take that
<Chipaca> ok i think bofh might be showing its age
 * Chipaca puts down his keyboard and goes for a run
<popey> someone needs to add "systemd" to bofh
<popey> or "Lennart" :D
<Chipaca> <surprised pikachu + steve jobs head asplode merged gif>
<zyga> hello everyone
<zyga> greetings from Dresden
<ogra> popey, i dont do any magic but try apt install qemu-system-common, that might bring a udev rule to help with kvm
<popey> ogra: i have that installed
<popey> i am just stuffing qemu-static-x86_64 in $SNAP/bin and all the libraries manually in usr/lib/triplet
<ogra> well, i dont, perhaps thats an issue
<ogra> might be that building from source brings different handling of kvm ... not sure
<popey> ah, the deb of qemu-system-common has stuff in it
<popey> thanks!
 * diddledan parties to some popeycore
<popey> untz untz untz untz
<diddledan> :-)
<diddledan> https://www.youtube.com/watch?v=dbIEamupKLw
#snappy 2019-06-21
<stgraber> sergiusens: around by any chance?
<stgraber> ah, I think I may have figured out my issue
<sergiusens> stgraber: I sort of am
<stgraber> sergiusens: looks like I got confused by LP deciding to use the snapcraft deb when manually triggering builds, making me wonder wth was happening to my arm builds
<sergiusens> stgraber: oh, there's an lp-build-snap snap that makes it easy to trigger if interested and LP has a bug where you MUST set the channel for core and snapcraft for the snap to be used.
<stgraber> ah, interesting. We don't seem to have the issue when the builds are triggered by git commits though, will just have to keep in mind for when doing manual builds.
<sergiusens> stgraber: vcs triggered builds dtrt
<stgraber> got a link to the LP bug by any chance
<stgraber> if not, I can go dig
<zyga> good morning!
<zyga> I'm off today, just need to do the paperwork
<zyga> ok, paperwork done
<pstolowski> morning
<pedronis> pstolowski: hi, are you working today?
<pstolowski> pedronis: yes
<pstolowski> pedronis: thanks for udevmonitor stop PR, will review in a bit
<pedronis> pstolowski: thx, was about to ask about that
<pedronis> pstolowski: also I tried to land #6960, fixed some GetType issues but it seems to be red always for unrelated reasons :/
<pstolowski> pedronis: uhm, thank you
<pstolowski> i'm having a slow start today, switching ISP this morning and still having a technican here
<zyga> Hey hey
<zyga> I will do some reviews today
<zyga> 7 hours more to go today
<zyga> I will look at the race PR from pedronis now
<pedronis> zyga: pstolowski will look at it
<zyga> aha, it already has one review
<zyga> good
<zyga> I'm still interested, things like that are tricky and I could learn a thing or two
<pedronis> zyga: not stopping you, 6959 is probably something that would be good to unblock
<pstolowski> pedronis: +1 for 7018
<zyga> pedronis: indeed, I'll look at that too
<zyga> pedronis: question about https://github.com/snapcore/snapd/pull/7018/commits/3ff9725feb595f78d8bcbee0df3c621af9de6419
<zyga> pedronis: is this where a thread will see the channel IO arriving but not yet see the value being set to "opinion"?
<zyga> pedronis: or did I misunderstood it?
<zyga> did I misunderstand*
<pedronis> zyga: it fixing go test -race
<pedronis> to be honest for those tests I mostly looked at making it happy
<pedronis> sometimes tests get extra locking for free that make some things work even if they strictly shouldn't
<pedronis> but those weren't that lucky
<zyga> mmm, indeed
<zyga> pedronis: reviewed, 7018, looking at the other oen
<zyga> *one
<cjwatson> sergiusens: Could you explain the bug you're describing here?  AFAIK you don't have to explicitly set channels if you're using a base, unless you're using obsolete API methods
<pedronis> @zyga: Wait exists basically only for tests
<zyga> aha
<sergiusens> cjwatson this was the question I asked in Lyon. If channel setting is now longer required that is great and maybe stgraber was using the obsolete API. Does the launchpad webui use the new API?
<cjwatson> sergiusens: There's much confusion because there are various different paths (because bases were retrofitted).  The Launchpad web UI uses the new interfaces *unless* you explicitly select architectures
<cjwatson> I have a branch in progress to fix that exception that I started in Lyon, so I should probably finish that off
<cjwatson> That branch will mean that if you explicitly select architectures then they get passed through and intersected with any other applicable constraints
<pedronis> Chipaca: hi, did that comment pointer help?
<Chipaca> pedronis: i think so yes
<pedronis> pstolowski: 6960 is green
<pstolowski> pedronis: great, ty, landing
<cjwatson> sergiusens: OK, https://code.launchpad.net/~cjwatson/launchpad/snap-request-build-explicit-arch-consistency/+merge/369162 should fix this weirdness (just FYI, not asking you to review it)
<cjwatson> stgraber: ^-
<Chipaca> pedronis_: are we done wrt simplifying retries?
<Chipaca> pedronis: are we done wrt simplifying retries?
<Chipaca> :)
<pedronis> Chipaca: I cannot post anymore as pedronis_ and then it's a dance
<pedronis> Chipaca: you mean https://trello.com/c/9GcOfcEG/32-improvement-to-retries-and-request-patterns-for-store ?
<Chipaca> pedronis: I meanthttps://trello.com/c/e5wx44jZ/151-simplify-our-retries-for-auto-refreshes-so-not-to-have-fleet-stampeding-at-regular-intervals-on-store-errors
<Chipaca> pedronis: but i think i must've been mistaken about it being in Doing
<pedronis> Chipaca: but yes, there is still work in that area, if nothing else because as I mentioned retry.v1 works a bit differently than we though it seems and our current param are a bit silly
<pedronis> therefore
<Chipaca> pedronis: right, but that's the WIP, isn't it?
<pedronis> yes
<pedronis> if you mean that's why the card I referenced is still in WIP
<abeato> pedronis, hey, I am seeing these errors lately: "udevmon.go:146: udev event error: Unable to parse uevent, err: no buffer space available". Is it worth opening a bug?
<pedronis> abeato: yes, please
<pedronis> ^ pstolowski
<abeato> it looks like the size is one page
<abeato> ok, let me do that
<abeato> (the buffer size)
<abeato> pedronis, pstolowski https://bugs.launchpad.net/snapd/+bug/1833707
<pstolowski> abeato: interesting, thank you
<pstolowski> abeato: when you see it happening, can you also run 'udevadm monitor -p' and capture corresponding event(s)?
<abeato> pstolowski, sure I can do that
<abeato> pstolowski, also, I actually have run in this sort of issues long time ago. The size for these buffers tend to be huge: https://github.com/systemd/systemd/blob/master/src/udev/udevadm-monitor.c#L73
<abeato> 128*1024*1024
<pstolowski> abeato: oh wow, indeed. fwtw the go module we use for this is from 3rd party
<abeato> I remember of an issue in Android init related to udev rx buffer size in the UT times :D
<pstolowski> abeato: thanks, we can patch it locally quickly since we have own copy of the module, and i'll also report this upstream
<abeato> pstolowski, awesome, thanks!
<pedronis> Chipaca: standup?
<Chipaca> ye
<stgraber> cjwatson: thanks!
<zyga> online again, will do another review
 * cachio lunch
 * Chipaca weeps at today's xkcd
<albertosottile> jdstrand: thanks for granting us the syncplay-server alias. Just a quick question: do I have to update our snapcraft recipe or is the alias automatically installed now that itâs granted?
<jdstrand> albertosottile: you're welcome! you don't have to do anything. I'm stepping away for a little bit but feel free to ask other questions if you have them and I'll answer when I get back
<popey_> ogra: ok, I have forked your qemu-virgil, added a vm to the snap and updated to core 18, and even after connecting kvm, it refuses to work, permission denied on KVM kernel module
<popey_> jdstrand: is there anything weird about the kvm interface that would prevent a 'side-loaded' snap from working?
<popey_> (ogras qemu-virgil snap works fine when loaded from the store, but my side-loaded fork of it doesn't work)
<popey_> Could not access KVM kernel module: Permission denied
<popey_> qemu-system-x86_64: failed to initialize KVM: Permission denied
<albertosottile> jdstrand: the snap should be released on the store now -> https://snapcraft.io/syncplay
<kyrofa> zyga, I understand that snaps on Debian aren't confined (at least, not with apparmor). However, even in a snap that sets the PATH in apps, the snap ends up running stuff off the host
<kyrofa> zyga, like snapd doesn't reset the PATH like it does elsewhere
<kyrofa> Is that possible?
<kyrofa> zyga, specifically Nextcloud will run mysql from the host if it's installed on Debian, and I have no idea why
<kyrofa> Shouldn't the hostfs be isolated off in /var/lib/snapd/ or something?
<kyrofa> zyga, anyway, it's been biting us since the beginning, some love on this bug would be great: https://bugs.launchpad.net/snapd/+bug/1819734
<jdstrand> albertosottile: nice!
<jdstrand> popey_: does your user have access to the device?
<popey_> jdstrand: the same user using qemu-virgil works though.
<jdstrand> popey_: the interface is incredibly simple. the is one apparmor rule and one udev rule, and some logic for loading the right kernel module. that's it
<jdstrand> popey_: make sure the interface is connected; look at ls -l /dev/kvm and see the perms and if your user is in that group (use 'id'); see if there are any policy violations; see if the snap is in the device cgroup with udevadm info /dev/kvm (look at the TAGS)
#snappy 2019-06-22
<zyga> kyrofa: looking
<zyga> kyrofa: around?
#snappy 2019-06-23
<bulldog68> hi
<bulldog68> hi, i need a little help with content snap - when am trying to connect consumer snap plug to provider snap slot i get this error :- error: snap "core" has no "content" interface slots
<bulldog68> =L
<jamesh> bulldog68: what command are you executing when you get that error?
<bulldog68> jamesh snap connect webengine-app:webengine513
<jamesh> bulldog68: if you only pass one argument to "snap connect", it will assume you are trying to connect to a slot on the "core" snap
<jamesh> what is the other snap you want to connect to?
<bulldog68> webengine513 is name of provider snap
<jamesh> you want to run something like "snap connect snap1:plug snap2:slot"
<bulldog68> oh let me try :)
<jamesh> okay.  You need to specify the names of the plugs and slots you want to connect
<bulldog68> okay
<bulldog68> am connected but i don't want  users to do this command line stuff manually
<bulldog68> jamesh am connected but i don't want  users to do this command line stuff manually
<jamesh> bulldog68: in general, they shouldn't have to
<bulldog68> okay thanks :]
<jamesh> bulldog68: if you're the publisher for both the plug and slot snaps, snapd should automatically perform the connection if the snaps are installed from the store (i.e. not from local files with "snap install --dangerous")
<bulldog68> okay
<jamesh> If you need autoconnection in cases where they have different publishers, you can ask on the forum for a store assertion to be created
<jamesh> this is what e.g. allows snapd to automatically connect apps to the gtk-common-themes snap
<bulldog68> hmm
<bulldog68> i have many snaps in store but content interface is new for me
<bulldog68> one more question, i have desktop-gtk3 in my provider snap and i want lauch my app using desktop-launch in consumer snap how we do that ?
<jamesh> it doesn't happen automatically for snaps with different publishers because it can allow the slot snap to have code executed in the context of the plug snap
<bulldog68> jamesh what am trying to do is package my qt binary in one snap (consumer) and the runtime/libs etc in provider snap
<bulldog68> both snaps are mine and am testing them locally on my machine
<jamesh> bulldog68: I don't know if there is a simple answer to that: you could probably modify the script to work with the locations you mount things into on the plug side though.
<jamesh> bulldog68: that's basically what happens for snaps using desktop-gnome-platform
<bulldog68> in the plug side i added target: $SNAP/webengine513 but after connecting the directory wont appear in the plug snap
<bulldog68> in slot side i have read:  - $SNAP
<jamesh> bulldog68: the mount only happens within the snap's mount namespace: you won't see anything from a host system shell
<jamesh> try doing "snap run --shell webengine-app" and then look in $SNAP/webengine513
<jamesh> (this starts a shell within the sandbox of the named snap application
<bulldog68> okay let me chk
<bulldog68> yes i can see things there
#snappy 2020-06-15
<mup> PR snapd#8854 closed: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8854>
<mup> PR snapd#8850 closed: dirs: delete unused Cloud var, fix typo <Cleanup :broom:> <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8850>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1858636 is interesting
<mup> Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed for anonymouse67> <https://launchpad.net/bugs/1858636>
<mup> PR snapd#8837 closed: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8837>
<zyga> Hey guys
<zyga> Unclear if I will work today, depending on ability
<mborzecki> zyga: hey
<zyga> Hey :-)
<mvo> zyga: good morning
<zyga> Hey mvo
<zyga> I will file time of for Friday
<mvo> zyga: yeah, please do
<pstolowski> morning
<mborzecki> pstolowski:hey
<mborzecki> heh, even without font cache, spotify snap still segfaults on my host
<pedronis> hello
<pedronis> pstolowski: hi, I left some comments/questions in #8812
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pedronis> pstolowski: on a different note: is/can be #8532 useful or should we just close it?
<mup> PR #8532: tests: install new snapd deb into preseed image <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8532>
<pstolowski> pedronis: saw your comments, thanks for looking at it!
<pstolowski> pedronis: 8532 might be useful, i need to think
<pedronis> pstolowski: ok, on a 3rd note: do you want to look at #8823 more ?
<mup> PR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
<pstolowski> pedronis: yes, i'll conclude this review today
<pedronis> mvo: mborzecki: hi, we were having issues with centos on Fri, are we looking into it?
<mborzecki> pedronis: what kind of issues?
<mborzecki> let me check the most recent prs
<pedronis> mborzecki: https://github.com/snapcore/snapd/pull/8855/checks?check_run_id=766170841 selinux/package related
<mup> PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>
<mborzecki> pedronis: yeah, it's the same as https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310/28?u=mborzecki
<pedronis> mborzecki: do we need to mark them unstable?
<pedronis> 7 is also failing and marked required
<mborzecki> pedronis: maybe, i need to poke around a bit more, had some trouble refreshing rhel vms in the morning
<mup> PR snapd#8858 opened: asserts,daemon: add support for "serials" field in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>
<mborzecki> heh, so centos is lagging behind again
<mborzecki> and snapd 2.45 installs fine on rhel8
<mborzecki> hm a build of selinux-policy for centos in a sufficient version was done a couple of days ago https://koji.mbox.centos.org/koji/buildinfo?buildID=11412 but no clue where to find it
<mup> PR snapd#8859 opened: tests: enable snap-auto-mount test on core20 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8859>
<mborzecki> pedronis: mvo: yeah, so with some info from folks in #centos it is lagging behind, 8.2 is in the oven so no updates are being pushed, and in general there is no clear solution for the latency of updates from rhel (which is used for epel builds) appearing in centos
<pedronis> mborzecki: mvo: so short term we shoul mark both centos unstable?
<mborzecki> perhaps we should make that test smarter, rather than dumping whole centos to unstable
<pedronis> mborzecki: that sounds ok, but if is not trivial we should first unblock landings
<pedronis> mborzecki: also it's a bit unclear is a good use of time, I don't know. I agree that the fact that we have fully unsable systems, instead of unstable tests is a bit of a problem
<mborzecki> otoh, how do we mark the system unstable right now?
<mvo> mborzecki: I can mark it unstable (I uncheck "required test" in the settings box for this)
<mborzecki> mvo: please do
<mvo> mborzecki: done, centos-7 is no longer required
<mborzecki> mvo: centos-8 :)
<mvo> mborzecki: that is already not-required
<mvo> mborzecki: should I make -7 required again?
<mborzecki> mvo: yeah, sorry, centos-7 is good, only 8 needs to be non-mandatory
<mvo> mborzecki: updated again, thank you :)
<mborzecki> sil2100: hey, can you take a look at https://github.com/CanonicalLtd/ubuntu-image/pull/189 ?
<mup> PR CanonicalLtd/ubuntu-image#189: ubuntu_image: do not overwrite the files that snap prepare-image has created <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/189>
<mup> PR snapd#8823 closed: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8823>
<mup> PR snapd#8860 opened: overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8860>
<mborzecki> quick errand
<zyga> starting work
<zyga> pedronis: thank you for the changes to https://github.com/snapcore/snapd/pull/8829 - they look good
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<zyga> pedronis: I will prepare the next chunk in a moment
<zyga> mborzecki: what is up with centos-8?
<zyga>  Problem: package snapd-2.45-1.el8.x86_64 requires snapd-selinux = 2.45-1.el8, but none of the providers can be installed
 * zyga reads backlog
<pedronis> pstolowski: thanks, I expanded a bit my considerations: https://github.com/snapcore/snapd/pull/8812#discussion_r440038759
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> pedronis: thank you
<zyga> mborzecki: do you think you could do a 2nd review for 8829?
<zyga> it's the same code, just split out and polished a little
<mborzecki> re
<mborzecki> pstolowski: which snap did you try to debug with --gdbserver?
<pstolowski> mborzecki: hello-world
<mborzecki> ok, let me try that
<mborzecki> meh, python 3.5 vs 3.8
<mup> PR snapd#8861 opened: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<mborzecki> zyga: centos-8 should be marked as unstable, even if it fails it should be possible to merge a PR
<zyga> I see
<zyga> are we waiting for something to migrate?
<mborzecki> zyga: and i'll be adding some details about centos-8 and epel to the standup docs
<zyga> ok
<pedronis> mborzecki: hi, I updated https://github.com/snapcore/snapd/pull/8844 to keep only the benchmarks as we discussed previously
<mup> PR #8844: asserts/internal: add some iteration benchmarks <Created by pedronis> <https://github.com/snapcore/snapd/pull/8844>
<mborzecki> pedronis: thanks!
<pedronis> mvo: I reviewed #8858, missing some bits (format is a bit complicated)
<mup> PR #8858: asserts,daemon: add support for "serials" field in system-user assertion <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>
<mvo> pedronis: thank you, looking
<pstolowski> mborzecki: are you checking my remark about seond 'continue'?
<mborzecki> pstolowski: yeah, that was my intention, but got into a fight with py35 in ubuntu-image :/
<pstolowski> haha
<mup> PR snapd#8784 closed: snap: add new `snap run --experimental-gdbserver` option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8784>
<jamesh> mborzecki: would you have any idea of what sort of changes I'd need to fix this error? https://github.com/snapcore/snapd/pull/8861#issuecomment-644048833
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<mborzecki> jamesh: looking
<jamesh> mborzecki: in short, I need to make a couple of directories under /var/lib/snapd readable by dbus-daemon
<jamesh> while being writable by snapd
<mborzecki> jamesh: should be fairly simple, i can push a patch there
<jamesh> mborzecki: thanks.  That seemed like the only legitimate failure in the logs so far.
<jamesh> good thing you added that regression test :-)
<mborzecki> jamesh: mhm, yeah we need to updae the policy, system_dbusd_t (used dbus-daemon) does not have read access to /var/lib/snapd
<jamesh> mborzecki: I suppose we can't just label /var/lib/snapd/dbus in a way to give it access if it can't read /var/lib/snapd :(
<jamesh> or traverse it at least
<popey> I have updated a snap (atom) which now complains that "- Mount snap "atom" (256) (cannot find required base "core")" - but i have core installed. https://paste.ubuntu.com/p/kMNzw3Jj8v/   any ideas?
<popey> you can "snap install atom --edge --classic" to try for yourself.
<mborzecki> jamesh: we could use the same label as /usr/share/dbus/services.d but then quite likely we'd need to update the snapd policy to allow snapd write access there
<mborzecki> jamesh: either way, a change is needed
<mborzecki> i wonder why there was no error on fedora though
<zyga> jamesh: hi
<zyga> sorrym I'm not around during the calls much
<zyga> not the best moment in my life
<jamesh> mborzecki: it should be similar label to /usr/share/dbus-1/{services,system-services} -- not sure if that differs to session.d/system.d
<zyga> I left a pair of small comments on https://github.com/snapcore/snapd/pull/8861
<mup> PR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>
<jamesh> zyga: no problem
<zyga> jamesh: sorry to nickpick about the name but I really wonder why we use "services" and not "session-services"
<jamesh> zyga: I followed the naming scheme that D-Bus uses, as mentioned in the comment.  I'm not sure it is worth being different
<zyga> I see, I missed that when jumping through the diff
<jamesh> zyga: and as always, thanks for the review feedback :-)
<mborzecki> jamesh: do we need to reload dbus-daemon to have it pick up those extra conf files?
<mborzecki> i would guess that system dbus got reloaded/restarted on centos 7 and that triggered the denial
<zyga> Interesting, I recall a bug where it would only work if a directory was present to start with
<zyga> as otherwise dbus would not establish some inotify watch
<zyga> I don't recall the details
<jamesh> mborzecki: there is a restart method you can send, but I think it generally picks things up via inotify these days
<jamesh> mborzecki: we don't currently do it when adding/removing system bus policy, but probably should.
<jamesh> perhaps that should be a new PR
<mborzecki> jamesh: isn't inotify only for service.d system.d directories?
<jamesh> mborzecki: once it reads the new config file from /usr/share/dbus-1/system.d or session.d, it should start monitoring the new directory for service activation files
<zyga> core20 prepare fails, has anyone looked at that?
<pedronis> that's recent
<mborzecki> jamesh: heh, the test is fine in isolation as suspected
<clmsy> hi everyone, quick question, were there any known changes to gadget structure for core20 builds?  my ubuntu-image cli fails on the last step of building a core20 based image with "cant find boot config".
<clmsy> in the gadget's stage folder i can see all the grub related files
<clmsy> ooh one sec i realized something... snapcraft clean actually never removes gadget and parts folder somehow, i manually deleted them, did another build and the gadget snap is created but there is no stage or parts folder hmm
<zyga> mborzecki: o/
<zyga> mborzecki: I opened a small tweak and another chunk carved out of the refresh tracking logic
<zyga> mborzecki: the tweak is https://github.com/snapcore/snapd/pull/8862 and is really small apart from mv'ing some code around - I did this to allow the diff in cgroup.go (in subsequent branches) to be readable
<mborzecki> zyga: trading PR for PR https://github.com/snapcore/snapd/pull/8864 :)
<mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
<mup> PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
<zyga> mborzecki: and to make sure I didn't break anything in conflict resolution
<mup> PR snapd#8862 opened: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
<mup> PR snapd#8863 opened: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> mborzecki: gladly :)
<mup> PR snapd#8864 opened: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
<zyga> mborzecki: the only new change is that I simplified PidsInGroup
<zyga> compare https://github.com/snapcore/snapd/pull/8862/files#diff-a44752c174bd4af51ccc892ed5bc15b4L212 and https://github.com/snapcore/snapd/pull/8862/files#diff-a5c0640204de19f988a6d5446e6108e6R32
<zyga> it was a simple code reuse as everything was exactly the same
<zyga> the https://github.com/snapcore/snapd/pull/8863 is a bigger PR that involves one main new function in the form taken verbatim out of refresh app awareness v2 branch - again split to a new file for readability
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<mborzecki> mhm
<zyga> comments there probably need tweaking but the logic is what I wanted it to be
<zyga> the comment on the PR is more accurate than than the comments inside
<zyga> ok, that's that
<zyga> going to look at your PR :)
<zyga> mborzecki: is there a spread test that shows this warning?
<mborzecki> zyga: afaik there isn't one
<zyga> ok
<zyga> btw, I found one thing over weekend
<zyga> grep -x
<zyga> very useful for line matches
<zyga> especially as grep -qFx
<zyga> quiet, literal, whole line matches
<zyga> it's essentially a line in open("fname").splitlines() in shell
<zyga> mborzecki: could you add a test, I think it's going to be useful to let us know the list is stale
<zyga> apart from that and the nitpick inline +1
 * zyga reviews services changes from pawel
<mup> PR snapcraft#3170 closed: repo: decouple fetch and unpack stage-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170>
<pedronis> clmsy: yes, gadget look different/have different details in UC20 (and some details are still in flux), I recommend ATM looking at the 20 branches of https://github.com/snapcore/pi-gadget and https://github.com/snapcore/pc-amd64-gadget for an idea
 * zyga lunch break (ha ha, in bed :()
<roadmr> zyga!!! hope you get better! I'm too far to help but let me know if I can in any way
<zyga> thanks Daniel, being here and working keeps me sane
<roadmr> ð
<roadmr> just don't work too much :)
<Saviq> ijohnson: confirmed the classic â strict refresh issue https://bugs.launchpad.net/snapd/+bug/1883538
<mup> Bug #1883538: Classic to strict refresh requires manual intervention <snapd:New> <https://launchpad.net/bugs/1883538>
<Saviq> almost looks like staged refreshâ¦
<Saviq> we only have about 10% of the people tracking stable on the most recent revision (that's out for a week now)
<Saviq> mvo: FYIÂ â
<mvo> Saviq: oh, interessting. thank you, will look after my current meeting
<ijohnson> thanks Saviq
<ijohnson> we will look in a bit, I too have a meeting now :-)
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8812#pullrequestreview-430673354
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> zyga: thank you
 * zyga debugs the core 20 prepare failure
<abeato> has anybody tried running UC20 on kvm + TPM (simulated or passthrough) for disk encryption?
<ijohnson> abeato: yes not passthrough, but simulated
<abeato> ijohnson, cool - any special issue with that or things just work?
<ijohnson> abeato: yes it should just work, what issues are you running into?
<abeato> ijohnson, none, just double checking before I enter a rabbit hole :)
<ijohnson> abeato: for now, I use the swtpm-mvo snap + socket to provide to qemu
<abeato> ijohnson, will try that, thanks
<ijohnson> abeato: this is my qemu cmdline I use with a copy of the OVMF_VARS.ms.fd from the ovmf package:
<ijohnson> https://www.irccloud.com/pastebin/I4HPR8u9/
<mborzecki> zyga: should probbaly land https://github.com/snapcore/snapd/pull/8863 first
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<mborzecki> zyga: w8, not this one, this one: #8862
<mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
<zyga> looking
<zyga> yeah
<zyga> with one review?
<zyga> maybe pawel can do a quick one
<zyga> it's just moving a few lines around
<zyga> mborzecki: thanks for this!
<mborzecki> zyga: or ijohnson/cmatsuoka maybe?
<zyga> yeah
<zyga> anyone who's around
<zyga> sorry, I'm kind of out of touch
<zyga> ah I see ijohnson is around
<ijohnson> whats up
<cmatsuoka> which PR?
<zyga> https://github.com/snapcore/snapd/pull/8862
<mup> PR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>
<zyga> 2nd review, just moving code around _and_ simplifying the main function since it had a common implementation with a private function already present
<zyga> it's good to chat to you guys btw
<zyga> I'm sorry for not joining the standups now
<zyga> I really want to get over this part of my life
<mborzecki> ijohnson: zyga: if https://github.com/snapcore/snapd/pull/8864 is green, i'll merge it and add a test in a follow up
<mup> PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
<ijohnson> k, sounds good to me
<zyga> mborzecki: that's okay
<zyga> mborzecki: the test is mainly to see it break over time
<zyga> :)
<zyga> kind of distro-sensors
<pedronis> is spread on core 20 working now?
<ijohnson> pedronis: it seems that preparing it intermittently fails because there are snaps in the classic 20.04 image we use to prepare it
<zyga> yeah
<ijohnson> I saw some reds preparing on Friday, some greens preapring on Friday
<zyga> I'm running a loop to get a shell and look around
<pedronis> is this the issue that we seem not to get the same image all the time?
<ijohnson> I think it's really the problem that mvo described is that we don't get the same image all the time
<ijohnson> pedronis: yes
<ijohnson> at least afaict
<pedronis> :/
<ijohnson> maybe it's something else too
<zyga> woah
<zyga> interesting
<zyga> do we have hard proof that this happens?
<zyga> (!same image)
<ijohnson> zyga: the hard proof is that we sometimes get an image with snaps installed in it, and sometimes we get an image without snaps installed in it
<zyga> hmm
<zyga> maybe we always get an image with a seed inside
<ijohnson> iirc mvo added a check to make preparing fail if it detects snaps installed in the image
<zyga> and we sometimes manage to seed
<zyga> and sometimes dont
<ijohnson> zyga: you approved the PR :-)
<ijohnson> https://github.com/snapcore/snapd/pull/8849
<mup> PR #8849: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8849>
<zyga> yeah but I didn't know it turned something up
<cmatsuoka> zyga: so from what I see 8862 is just reorganization, without any feature changes?
<zyga> cmatsuoka: yes
<zyga> cmatsuoka: one tiny code change, if you look at the public function
<zyga> but it's 100% identical after, just calls a helper that happens to do the common tail
<cmatsuoka> zyga: yes, I noticed that, and it looks better this way
<zyga> yeah, it's easy to follow top to bottom
<zyga> thanks guys!
<cmatsuoka> zyga: how are you feeling? getting better?
<zyga> cmatsuoka: not actually
<zyga> cmatsuoka: more news on Wednesday after doc visit
<cmatsuoka> zyga: I hope you get well soon
<zyga> thanks, I really want to
<mup> PR snapd#8865 opened: workflow <missing-colon> test PR title as part of the static checks again <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8865>
<zyga> https://github.com/snapcore/snapd/pull/8863 is now ready for review
<mup> PR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>
<zyga> broken out of the refresh-app-awareness-v2 branch
<mup> PR snapd#8862 closed: sandbox/cgroup: improve pid parsing code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8862>
<ijohnson> hey folks, could I get reviews on https://github.com/snapcore/snapd/pull/8519, it is green now after I debugged it more and fixed the test
<mup> PR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
<mup> PR snapd#8844 closed: asserts/internal: add some iteration benchmarks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8844>
<mup> PR snapd#8864 closed: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>
<mup> PR snapd#8866 opened: tests/main: add spread test for running svc from install hook <Services âï¸> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>
<mup> PR snapd#8867 opened: interfaces: add uinput interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8867>
<mup> PR snapd#8868 opened: interfaces: add system-source-code for access to /usr/src <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8868>
<mup> PR snapd#8869 opened: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8869>
<mup> PR snapd#8317 closed: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8317>
<mup> PR snapd#8870 opened: interfaces: add gconf interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8870>
<mup> PR snapd#8871 opened: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8871>
<mup> PR snapd#8872 opened: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8872>
<mup> PR snapd#8873 opened: interfaces: misc small interface updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8873>
#snappy 2020-06-16
<mborzecki> morning
<mup> PR snapd#8874 opened: spread: use find rather than recursive ls, skip mounted snaps <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8874>
<mup> PR snapd#8875 opened: tests/main/sudo-env: check snap path under sudo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
<mborzecki> heh, debian sets secure_path too
<mborzecki> wierd things happening in google:centos-8-64:tests/main/selinux-clean
<zyga> Good morning
<zyga> Hey Maciek
<mup> PR snapd#8859 closed: tests: enable snap-auto-mount test on core20 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8859>
<zyga> Ha, is the spread test immediately useful?
<zyga> I just took meds, should be able to work in 30 minutes
<mborzecki> zyga: there's some denials coming from systemd-logind trying to read 'linger' file (whcih we created?)
<mborzecki> trying to make sure it's not us doing something wrong
<pstolowski> morning
<zyga> Heh
<zyga> Linger is tests.session
<zyga> It is a systemd feature
<zyga> But probably underused and missing in selinux profiles
<mborzecki> pstolowski: hello sir
<zyga> Hey PaweÅ :-)
<mborzecki> zyga: hm i'm seeing this:
<mborzecki> type=SYSCALL msg=audit(1592291609.858:541): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=55ce2c1a6420 a2=f0000 a3=0 items=0 ppid=1 pid=39430 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(d-logind)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null)
<mborzecki> type=AVC msg=audit(1592291609.858:541): avc:  denied  { read } for  pid=39430 comm="(d-logind)" name="linger" dev="sda2" ino=17559683 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:systemd_logind_var_lib_t:s0 tclass=dir permissive=1
<mborzecki> H
<zyga> which os is this?
<mborzecki> which seems fine, because /var/lib/systemd/linger is labeled as systemd_logind_var_lib_t (correct & confimed with semanage fcontext), the pid is systemd-logind, which has systemd_logind_t and policy allows modifing that location
<mborzecki> zyga: centos-8
<mborzecki> zyga: so for some short while, init_t (systemd itself?) tries to read the linger directory
<zyga> hmmmm
<mborzecki> afair yesterday centos 8.2 was released, and looking at dnf log, the test pulled in a bunch of upgrades
<mborzecki>      9 | -y --refresh install /us | 2020-06-16 07:03 | I, U           |   35 EE
<mborzecki>      8 | -y --refresh install --s | 2020-06-16 07:01 | I, U           |  278 EE
<mborzecki> perhaps the policy changed, and we just need to update the image
<zyga> grep for linger in systemd shows only logind and related things
<mborzecki> and the selinux-policy package got updated too
<zyga> though
<zyga> login also uses it
<mborzecki> hm i'll try adding daemon-reexec in test prepare
<zyga> not surem, maybe it just is used in init itself too
<mborzecki> zyga: btw. debian uses sudo secure_path
<zyga> mborzecki: commented on https://github.com/snapcore/snapd/pull/8875/files
<mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
<zyga> su -l is nearly always dangerous
<mborzecki> zyga: ha, ok will fix that
<mup> PR snapd#8872 closed: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8872>
<mup> PR snapd#8873 closed: interfaces: misc small interface updates <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8873>
<mup> PR snapd#8874 closed: spread: use find rather than recursive ls, skip mounted snaps <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8874>
<pedronis> mborzecki: should we close or try to land #7414 ? it seems ok to me, one question is whether should we purge packages or just remove them?
<mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<pedronis> mborzecki: I commented in it directly
<mborzecki> pedronis: thanks, will chekc in a minute
<mup> PR snapd#8871 closed: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8871>
<zyga> mvo is on a merging spree :)
<mvo> zyga: I was shocked to see 80(!) open PRs when I woke up
<mvo> zyga: and figured I need to do something :)
<zyga> :D
<mup> PR snapd#7417 closed: interfaces/wayland: on classic systems only consider the OS slot for auto-connect <Needs Samuele review> <â Blocked> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7417>
<mup> PR snapd#8789 closed: interfaces/docker: use implicitOnClassic: true <Needs Samuele review> <â Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8789>
<mborzecki> zyga: hm this looks like a bug in the policy or our setup, what happens is that we set StateDirectory=systemd/linger, then systemd tries to set up (create?) that directory for systemd-logind, but gets blocked by the policy
<mvo> pedronis: in 8870 the interface name "gconf" is uncontroversial I assume? or is that something you want to review ?
<zyga> hmm
<zyga> mborzecki: up-to-date systemd has StateDirecty=systemd/linger
<zyga> maybe centos-8 is just too old
<zyga> it works fine on fedora
<mvo> pedronis: other than the name 8870 is ready to get merged
<zyga> I mean, the policy is probably too old
<pedronis> mvo: I probably need to double check it
<mvo> pedronis: sure thing, added the label
<mvo> zyga: I updated 8865, it's a bit annoying that we can't use a pre-canned action but it should be simple enough, hopefully the comment explains enough
<zyga> thanks, I'll check it in a moment
<zyga> digging into some kernel bit for uinput
<mvo> pedronis: I assume you also want to double check 8867 (uinput) ? if so I will add the label
<mvo> zyga: oh, nice
<pedronis> mvo: yes
<mvo> a second review for 8857 would be great, should be quick and an easy win
<zyga> mvo: added some comments there
 * zyga small break
<mborzecki> heh, so one of the tests moves xdg-open aside
<mborzecki> zyga: and for now i have no clear solution for that selinux problem, feels like a policy bug, maybe if i can procure the ame state on rhel8 i could file a bug
<mvo> zyga: nice, thanks!
<mup> PR snapd#8855 closed: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8855>
<mborzecki> zyga: do i need tests.session {prepare,restore} if i don't need anything or can i just tests.session exec in the test?
<zyga> I would do it just in case
<zyga> you probably just want restore
<zyga> as using test.session without prepare still gives you a session
<zyga> just makes it die briefly
<zyga> I found it more reliably with prepare restore
<zyga> as otherwise stuff starts and stops and may overrun
<zyga> Gah thinkpad died again
<mborzecki> i think i see the problem with xdg-open disappearing
<zyga> I will use this as an excuse to eat breakfast
<zyga> Hmmm?
<mborzecki> zyga: xdg-open-compat overwrites /usr/bin/xdg-open, and then removes it
<zyga> Ahhh
<zyga> Nice catch!
<mborzecki> i know we're not supposed to open new PRs but this one is super simple and fixes the problem ijohnson found https://github.com/snapcore/snapd/pull/8876
<mup> PR #8876: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
<mborzecki> zyga: mvo: ^^
<mup> PR snapd#8876 opened: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8876>
<mvo> mborzecki: thanks
<zyga> Looking
<mup> PR snapd#8846 closed: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
<pstolowski> mvo: thank you! ð
<mvo> pstolowski: thank you!
<pedronis> pstolowski: I'm looking at it to, it needs a follow up
<pstolowski> pedronis: thank you. it's quite possible i overlooked something, or some tests can be re-ordered
<pedronis> pstolowski: https://github.com/snapcore/snapd/pull/8846#issuecomment-644637199
<mup> PR #8846: tests: move update-related tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8846>
<pedronis> pstolowski: yes, the order is a bit weird of some tests, but not sure is the main worry at this point
<pstolowski> pedronis: right, i was pondering about sequence tests in the PR description
<pstolowski> pedronis: will prep a followup
<pedronis> thank you
<pedronis> pstolowski: once we have split more we can consider if reordering is worth it, I agree is a bit strange that for example TestInstallTasks or TestUpdateTasks are not among the first tests one encouters in those files, same more the main run through ones
<pedronis> more of an issue for people reading these for the first tiem
<pstolowski> sounds good
<zyga> I will work on existing PRs and reviews today
<zyga> Need to relocate to another room though
<mborzecki> zyga:  i've updated https://github.com/snapcore/snapd/pull/8875
<mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
<zyga> ack
<mup> PR snapd#8814 closed: sanity: check for unsynchronized real time clock <â Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8814>
<zyga> hmm
<mborzecki> hm?
<zyga> mborzecki: commented
<zyga> I missed that you are running sudo to become root, not the test user
<zyga> lets merge it
<zyga> and if it shows up in any scans we can react
<zyga> we MIGHT enable disable linger for root
<zyga> but tests.session -u root restore does not do the same as it does for test user
<zyga> so the protection is weaker
<mborzecki> zyga: mhm, fwiw it needs to be run via sudo, otherwise that part of the test does not make sense
<zyga> yeah, I understand
<mvo> zyga: sorry for being pushy but a quick look at 8865 would be appreciated
<zyga> sure
<zyga> done
<zyga> I think this is fine for now, we can look for how to support this better but it is not high priority
<mvo> zyga: \o/
<mup> PR snapd#8865 closed: workflow: test PR title as part of the static checks again <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8865>
<mup> PR snapd#8876 closed: tests/main/xdg-open-compat: backup and restore original xdg-open <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8876>
<mborzecki> yay
<zyga> degville: hi
<zyga> degville: I wasn't sure how to covey this otherwise
<mborzecki> zyga: unexpected failure in the PR with sudo env: https://paste.ubuntu.com/p/85m38SNbGm/ idk if it's related though
<zyga> there are three new pull requests that add interfaces
<zyga> I "assigned" them to you to make sure you are at least aware
<zyga> mborzecki: looking
<zyga> mborzecki: interesting, let me try
<degville> zyga: yes, I saw - and did a little +1 on your comments to let you know. I think it's a great idea and I'll make sure they're documented when they land.
<zyga> mborzecki: checking some more
<zyga> sigh
<mborzecki> zyga: hm?
<zyga> wifi range
<zyga> I don't know what's in the walls here
<zyga> but feels like tinfoiil
<mborzecki> zyga: lots of reinforced concrete maybe?
<zyga> I think so
<zyga> so
<zyga> I managed to get a debug shell
<zyga> I started simple
<zyga> tests.session -u prepare
<zyga> then tests.session -u test exec id
<zyga> then
<zyga> tests.session -u test exec sudo id
<zyga> so that all worked
<zyga> I wonder if the OS matters, I picked xenial
<zyga> I also tried sudo env
<zyga> what was broken was sudo -l, right?
<zyga> hmm
<zyga> and that gave odd output
<zyga> it just printed /usr/bin/id (I ran sudo -l id)
<mborzecki> zyga: no it failed in a different test
<mborzecki> zyga: but that sudo-env PR nonetheless
<zyga> hmm?
<zyga> can you remind me please
<zyga> mborzecki: but sudo --login works
<zyga> sudo -l doesn't
<zyga> WTH?
<mborzecki> zyga: thoght you're looking into https://paste.ubuntu.com/p/85m38SNbGm/ in the context of that sudo-env pr
<mborzecki> zyga: sudo --login != sudo -d
<mborzecki> pff -l
<mborzecki> sudo --login == sudo -i :)
<zyga> ah
<zyga> stupid font
<zyga> sorry!
<zyga> I didn't notice
<zyga> mborzecki: sorry, I was confused, i see what you mean now
<mborzecki> we should land https://github.com/snapcore/snapd/pull/8761 once it's green
<mup> PR #8761: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
<mup> PR snapd#8877 opened: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8877>
<pstolowski> pedronis: ^ i'll handle sequence tests separately
<pedronis> pstolowski: yes, should probably wait until we have closed more PRs
<pstolowski> ð
<zyga> Heh, debugged my x240 shutdown problem
<zyga> There is a âemergency reset holeâ on the bottom
<zyga> Which instantly powers of the unit
<zyga> With a physical button
<zyga> Those tiny clicker type
<zyga> Squeezing the unit close to the right hinge just puts enough pressure to press it
<zyga> Let me see about that
<zyga> And I didnât invent the name https://support.lenovo.com/us/en/solutions/pd029569
<zyga> i will be around shortly, my wife is removing that button
<zyga> done
<zyga> no more emergency reset hole
<zyga> no more annoying shutdowns
<zyga> just popped that button off the motherboard
<zyga> sorry, mborzecki back to your review
<mvo> second review for 8857 would be nice, should be an easy win, thanks to mborzecki  for the tweaks
<zyga> mvo: in a moment
<zyga> mvo: added a comment
<zyga> but LGTm
<zyga> back to https://github.com/snapcore/snapd/pull/7414
<mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<ijohnson> morning folks
<ijohnson> in the interest of merging small PR's, could I get a review on https://github.com/snapcore/snapd/pull/8519 ?
<mup> PR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>
<ijohnson> the only test failure there is the current ongoing one about not being able to prepare uc20 systems due to failure to cleanup after snapd
<zyga> mborzecki: added comments to 7414 that I think should be changed, I'll review the rest so please hold on :)
 * zyga needs painkillers, brb
<ijohnson> mvo: 8519 is ready for a sudo git merge and will take us back to the 60's (in terms of open PR's, time travel side effects are unknown)
<pstolowski> hi ijohnson !
<ijohnson> o/ pstolowski
<ijohnson> I updated the install hook spread test PR btw
<ijohnson> please have a look when you have a chance
<pstolowski> +1
<mup> PR snapd#7982 closed: o/snapstate, wrappers: enable services on start <Complex> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7982>
<pedronis> pstolowski: I looked again at #8812, and I have a few more questions there
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> pedronis: ty
<mup> PR snapd#8519 closed: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8519>
<mup> PR snapcraft#3169 closed: package-repositories: allow empty component list <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3169>
<mup> PR snapd#8878 opened: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8878>
<mborzecki> zyga: looks like deskto portal activation is failing quite consistently now in 18.04 https://github.com/snapcore/snapd/pull/8875/checks?check_run_id=776173782
<mup> PR #8875: tests/main/sudo-env: check snap path under sudo <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
<zyga> mborzecki: looking
<zyga> mborzecki: I think we should silence that line, it's just a fact that we kill dbus-monitor from awk when we see the stuff we care about
<zyga> mborzecki: wonder how it didn't show up before
 * zyga lunch 
<mup> PR snapd#7414 closed: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
<mup> PR snapd#8857 closed: tests/lib/prepare: increase the size of the uc16/uc18 partitions <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8857>
<mup> PR snapd#8366 closed: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <Needs Samuele review> <UC20> <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
<mborzecki> mvo: shall we land https://github.com/snapcore/snapd/pull/8761 or do we need more input from jdstrand?
<mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
<mup> PR snapd#8856 closed: [RFC] tests/main/install-fontconfig-cache-gen: for bionic, focal use broken font <Precious Logs> <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8856>
<jdstrand> mborzecki: fyi, I'd like jamesh to comment on https://github.com/snapcore/snapd/pull/8761#issuecomment-639674545 for the xdg-desktop-portal code since he was involved in PR 8269's review
<mup> PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <https://github.com/snapcore/snapd/pull/8761>
<mup> PR #8269: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8269>
<jdstrand> mborzecki: but aside from that PR 8761 has a LGTM for allowedURLSchemes so it doesn't need to wait on me
<mborzecki> jdstrand: got it
<jdstrand> also, do we expect centos-8-64 to pass atm?
<jdstrand> I keep mashing retry but that one doesn't seem to pass
<ijohnson> jdstrand: I think centos 8 has some selinux problems right now
<jdstrand> ok, I'll stop mashing retry then :)
<mborzecki> jdstrand: there's some pending updates on centos, and the recent batch of package updates they pushed broke systemd/systemd-logind/selinux-policy
<jdstrand> mborzecki: yikes
<mborzecki> jdstrand: i hope that when cachio updates the image this may go away, but from what i could tell going through selinux policy and systemd it's bug
<cachio> mborzecki,  when I update the image the test still fails
<cachio> mborzecki, this is the error I see https://paste.ubuntu.com/p/Z9KRsbh7vG/
<mborzecki> cachio: ok, let's push the image image then, and i'll try to make the test smarter
<cachio> mborzecki, sure, thanks
<mborzecki> cachio: thank you!
<mborzecki> time to run some errands
<cachio> mborzecki, image updated
<ogra> zyga, hmm, cn layouts live in /run ?
<ogra> File: /run/utmp (read)
<ogra> Suggestions:
<ogra> * adjust program to use $SNAP_DATA
<ogra> * adjust program to use /run/shm/snap.$SNAP_NAME.*
<ogra> * adjust program to use /run/snap.$SNAP_NAME.*
<ogra> * adjust snap to use snap layouts (https://forum.snapcraft.io/t/snap-layouts/7207)
<ogra> (i thought they could not)
<zyga> no
<ogra> then snappy-debug should perhaps not suggest it ð
<pstolowski> pedronis: it seems you were somehow involved already in https://bugs.launchpad.net/snapd/+bug/1882665 ; do you know if the length restriction for snap name is ok on our side and will be fixed in the store?
<mup> Bug #1882665: single-letter snaps are available in the store, but not installable <snapd:Triaged> <Snap Store:Confirmed> <https://launchpad.net/bugs/1882665>
<pedronis> pstolowski: there's a conversation going on with the store about that
<ijohnson> mvo: https://github.com/snapcore/snapd/pull/8866 is ready to be merged, but note that it failed on other tests in interesting ways so I have saved the logs in a pastebin
<mup> PR #8866: tests/main: add spread test for running svc from install hook <Services âï¸> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>
<ijohnson> mvo: specifically we got a little bit of info on what is left behind preparing uc20 sometimes insofar as there is still stuff in the /var/lib/snapd dir when purging the snapd deb
<ijohnson> mvo: and your google:ubuntu-core-20-64:tests/core/snap-auto-mount changes seem to not have worked
<ijohnson> mvo: it seems that the imported assertion was not trusted or was wrong? I'm not sure, the test failure output is quite unclear
<ijohnson> mvo: the full log is in https://pastebin.ubuntu.com/p/NbKty2yd3k/
<mvo> ijohnson: thank you, I have a look in a wee bit, in a meeting right now
<ijohnson> ok, no rush
<mvo> ijohnson: looking at the log now, strange that snap-auto-mount does not work - oh well
<mup> PR snapd#8866 closed: tests/main: add spread test for running svc from install hook <Services âï¸> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8866>
<mvo> ijohnson: woah, this is very confusing, the /var/lib/snapd is stull of stuff
<ijohnson> mvo: yes I'm not sure how it's leftover tbh
<mvo> ijohnson: yeah, that looks more like it was not run at all or something
<ijohnson> unless somehow because the google-cloud-sdk snap is classic it breaks things ?
<ijohnson> or possibly the lxd snap too because the lxd snap is effectively classic as well
<mvo> ijohnson: yeah, I'm poking at it now
<mvo> ijohnson: same failure in 8877 it seems, fun
<ijohnson> mmm at least we can see some stuff now
<mvo> ijohnson: yeah but we run the apt-get remove -y --purge snapd with quiet so we loose some information :(
<ijohnson> oh yeah maybe we shouldn't do that ...
<mup> PR snapd#8877 closed: tests: move a few more tests to snapstate_update_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8877>
<mvo> ijohnson: yeah, it looks like this is the next step
<mup> PR snapd#8879 opened: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
<mup> PR snapd#8608 closed: configcore: issue a warning on core16 when journal.persistent option is set <Squash-merge> <â Blocked> <Created by stolowski> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8608>
<mup> PR snapd#8609 closed:  Adds missing paths to desktop, solves lp:1876804 <â Blocked> <Created by sklei4> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8609>
 * cachio lunch
<mup> PR snapcraft#3171 opened: snap: debug enabled by default <do-not-merge> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3171>
<pstolowski> cachio: #8558 has a conflict
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<mup> PR snapd#8880 opened: tests/lib/prepare.sh: adjust comment about sgdisk <Simple ð> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
<mup> PR snapd#8878 closed: tests: fix how gadget pc is detected when the snap does not exist and ls fails <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8878>
<mup> PR core18#155 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core18/pull/155>
<mup> PR core20#73 opened: hooks: fix broken symlink /etc/sysctl.conf.d/99-sysctl.conf <Created by mvo5> <https://github.com/snapcore/core20/pull/73>
<mup> PR snapcraft#3172 opened: cli: restore --target-arch with warning for LXD and Multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3172>
<ijohnson> pedronis: #8794 is ready for re-review (I added the requested unit tests)
<mup> PR #8794: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
<mup> PR snapd#8761 closed: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8761>
<mup> PR snapd#8880 closed: tests/lib/prepare.sh: adjust comment about sgdisk <Simple ð> <Skip spread> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8880>
<mup> PR core20#74 opened: .travis.yml: use snapcraft w/ lxd to build the snap <Created by anonymouse64> <https://github.com/snapcore/core20/pull/74>
<mup> PR snapd#8869 closed: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Skip spread> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8869>
<mup> PR snapd#8881 opened: interfaces: simplify rules of multiple connected iio plugs <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<Intelo> Hi
<Intelo> I connected to vnc, all fine, firefox from console opens. I installed chromium-browser but when run, it says 'Client is not authorized to connect to server. Unable to open x display
<mup> PR snapd#8576 closed: tests/main/lxd: add test for snaps inside nested lxd containers not working <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8576>
<roadmr> hi jdstrand  :) we got a write request for system-files, for /run/lock. Is this covered by another interface maybe?
<jdstrand> roadmr: no, but that is a directory. you wouldn't want to grant it for /run/lock, but rather for /run/lock/something /run/lock/somethingelse
<jdstrand> roadmr: but really their snap should be updated to use SNAP_COMMON/lock or similar
<mup> PR snapd#8875 closed: tests/main/sudo-env: check snap path under sudo <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8875>
<roadmr> jdstrand: right, I think the advice they themselves posted pointed in that direction
<jdstrand> roadmr: of even better: /{dev,run}/shm/snap.@{SNAP_INSTANCE_NAME}.something
<jdstrand> or*
<roadmr> jdstrand: ok, I'll try to nudge them in that direction (it also suggested using layouts) and leave system-files as a last resort if they can point me to the specific files they need
<jdstrand> roadmr: a layout won't work for /run
<roadmr> ok, noted :( bummer heh
<cachio> cmatsuoka, ijohnson thanks for the review on #8879, I already update the test
<mup> PR #8879: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple ð> <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8879>
<jdstrand> roadmr: but they can use /run/snap.<snapname>.something all day every day :)
<ijohnson> cachio: thanks I'll look again
<cmatsuoka> cachio: thanks, checking again
<cachio> ijohnson, just matching 0600 0000 01
<ijohnson> cachio: why can't you match the whole pattern ?
<cachio> ijohnson, I did it just to avoid to check too much
<ijohnson> if there was garbage data for example xxd could output something like `0600 0000 0000 0600 0000 01` and the test would be wrong
<cachio> not sure if the format could change
<ijohnson> cachio: the correct format should not change it's in the UEFI spec IIRC
<cachio> MATCH "00000000: 0600 0000 01\s+....."
<cachio> ijohnson, that should be the correct one?
<cachio> the match
<ijohnson> cachio: yes that should be correct
<cachio> ok
<cachio> ijohnson, updated
<ijohnson> thanks let me look again
<cachio> ijohnson, thanks for checking
<ijohnson> cachio: can you also specify the full SecureBoot variable name ?
<cachio> ijohnson, is it fixed?
<ijohnson> cachio: because there could be devices with random uefi firmware implementations that also define some kind of SecureBoot variable, but those will never be the same as SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
<ijohnson> cachio: I really would like to see us be as specific as possible here
<ijohnson> cachio: so instead of doing `SecureBoot-*` I think we should do `SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c`
<cachio> ijohnson, sure
<ijohnson> thank you
<cachio> ijohnson, so the filename SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c is not gonna change right?
<ijohnson> cachio: yes that name is part of the spec
<cachio> ijohnson, ah, ok
<cachio> in that case makes sense
<cachio> thanks for the explanation
<cmatsuoka> the uuid is the vendor uuid and in this case it's the EFI consortium or something like that
<ijohnson> yes
<cmatsuoka> cachio: I think there's an extra space in the middle of the file name now
<cmatsuoka> SecureBoot-8be4df61-93ca-11d2 <space> -aa0d-00e098032b8c
<roadmr> wow
<cmatsuoka> cachio: please ignore the comment about the shell expansion
<cachio> cmatsuoka, nice
<cachio> I am wating for test results for the latest change yet
<cmatsuoka> my mistake there, I tested the regexp using plain grep but then I noticed that MATCH uses grep -E
<cmatsuoka> so the match didn't work in my first test
<cmatsuoka> but with grep -E it's fine
<pedronis> ijohnson: sorry about https://github.com/snapcore/snapd/pull/8340#discussion_r434490285 but basically my original comment/proposal wasn't possible, I probably misread some bit of the code and then the change applied was something else
<mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<ijohnson> pedronis: no worries
<ijohnson> I mean with large PR's that are open for months there's bound to be back and forth
<ijohnson> I'm almost done addressing feedback for that PR and will push up the changes in a little bit
<ijohnson> pedronis: PR is updated if you're still around and want to look at it
 * ijohnson small break
<mup> PR snapd#8794 closed: boot/bootstate16.go: clean snap_try_* vars when not in Trying status too <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8794>
<mup> PR snapd#8879 closed: tests: simplify the tpm test by removing the test-snapd-mokutil snap <Simple ð> <Skip spread> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8879>
<cmatsuoka> ijohnson: when a new kernel snap is installed on arm, where do we trigger kernel extraction?
<cmatsuoka> ijohnson: never mind, I just found it :)
<mup> PR snapcraft#3173 opened: cli: use snap pack instead of mksquashfs <maintenance> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3173>
<ijohnson> cmatsuoka: you found the ExtractKernelAssets functions?
<ijohnson> Whoops
<cmatsuoka> ijohnson: yes, I followed it to backend/setup
<cmatsuoka> ijohnson: now I'm thinking how to get model information from there
<cmatsuoka> but I'll continue tomorrow
 * cmatsuoka EODs
#snappy 2020-06-17
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> 56 prs, nice
<mvo> sweet
<mvo> and 3 easy wins once samuele had a chance to look at the interface prs from jamie
<mup> PR snapd#8882 opened: tests: use the "jq" snap from the edge channel <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8882>
<pedronis> mborzecki: hi, #8340 needs a 2nd review,  and if possible also to look at #8813 again
<mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<mup> PR #8813: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<mborzecki> pedronis: hi, yes, i'll be looking at those in the morning
<pedronis> thank you
<pstolowski> morning
<mup> PR snapd#8882 closed: tests: use the "jq" snap from the edge channel <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8882>
<abeato> hey, I'm having some problems when connecting an interface:
<abeato> $ snap connect mysnap:network-control
<abeato> error: cannot perform the following tasks:
<abeato> - Conectar mysnap:network-control a snapd:network-control (cannot update mount namespace of snap "mysnap": cannot update preserved namespace of snap "mysnap": cannot update snap namespace: device or resource busy)
<abeato> any idea on what might be going wrong?
<mup> PR snapd#8724 closed: interfaces/block_devices: add NVMe subsystem devices, support multipath paths <Needs security review> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8724>
<mborzecki> pedronis: heh, that isTrySnapErr does not work indeed, perhaps that's why the tests were not hitting that code path
<pedronis> I don't think we use new* either from the tests
<mborzecki> pedronis: i've added a test case for that, and it wasn't handled in the right if branch
<mborzecki> pedronis: anyways i'll push a patch there
<pedronis> thx
<mborzecki> pedronis: pushed now
<mborzecki> btw. we used to have something added to the snapd repo that showed test coverage of go code
<mborzecki> was that codecov?
<mborzecki> mvo: pedronis: do you think we could try enabling https://github.com/marketplace/codecov/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW4xNg== on snapd repo?
<mborzecki> there's also https://github.com/marketplace/coveralls
<mvo> mborzecki: we had coveralls a while ago, I would love to have coverage reports again
<mvo> mborzecki: it was a bit cumbersome to setup in the past
<mborzecki> it'd be nice to build & test the C bits too, even if the coverage is orders lower than the go code
<pedronis> mvo: I re-reviewed #8858, some things to tweak
<mup> PR #8858: asserts,daemon: add support for "serials" field in system-user assertion <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>
<mup> PR snapd#8802 closed: spread.yaml: update secure boot attribute name <Simple ð> <â Blocked> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8802>
 * Chipaca peers in
<mup> PR snapd#8883 opened: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<Saviq> mvo: bump on https://bugs.launchpad.net/snapd/+bug/1883538 :)
<mup> Bug #1883538: Classic to strict refresh requires manual intervention <snapd:New> <https://launchpad.net/bugs/1883538>
<mvo> Saviq: meh! sorry, put it on my list again
<mborzecki> pedronis: #8813 probably needs a pass from you regarding the naming of things
<mup> PR #8813: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<mborzecki> otherwise, it looks quite ok to me
<pedronis> mborzecki: anything in particular, the new structures?
<mup> PR snapcraft#3174 opened: link_or_copy: do not try to create hardlinks to symlinks <Created by hpoul> <https://github.com/snapcore/snapcraft/pull/3174>
<mborzecki> pedronis: yes, the new structures, OnDisk*
<pedronis> mborzecki: I'm not completely a fan of those tbh
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/8883#discussion_r441422472
<mup> PR #8883: packaging: stop snapd early on purge <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8883>
<mvo> mborzecki: right, I can go a different route, i.e. stop just snapd right before we remove the snapd dirs
<mvo> mborzecki: but I think this is the reason we see the 20.04 failures, we remove the dirs while snapd is running so it will just re-addd stuff there
<mvo> mborzecki: but yeah, I guess it's safer to keep it running until late
 * mvo changes the PR
<mborzecki> mvo: yeah, a middle ground is probaly the safest bet
<mborzecki> mvo: otoh, once we start stopping the mount units and removing directories snapd could get confused, but it's a part of purge anyway
<mvo> mborzecki: should I also snapd in snap-mgr or is that not needed there because snpad will not run at this point when snap-mgr purge is used?
<mborzecki> mvo: hmm, snap-mgmt is run after snapd is stopped, so if that does not leave anything behind, maybe we could go with your initial version?
<mborzecki> mvo: the fedora and arch packaging stops snapd (and sockets) before the purge
<mvo> mborzecki: cool, I updated the PR now
<pedronis> mborzecki: basically I'm a bit unhappy that we need to have Structure LaidOutStructure and OnDiskStructure
<pedronis> I know why they each exist but is a bit much
<mborzecki> pedronis: perhaps we can address that once we're done with snap-bootstrap -> gadget/install move
<mborzecki> then the change should be fairly mechanical
<mup> PR snapd#8884 opened: cmd/snap: Debian does not allow $SNAP_MOUNT_DIR/bin in sudo secure_path <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8884>
<ijohnson> morning folks
<pstolowski> hi ijohnson !
<ijohnson> hey pstolowski
<ijohnson> thanks mborzecki for the patches to those PR's
 * ijohnson looks at his only 3 open PR's :-D
<pedronis> mborzecki: if I see it correctly #8813 is mostly mechanical right?
<mup> PR #8813: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<pedronis> mborzecki: I mean I'm lookin at it, there is not subtle changes in it?
<mborzecki> pedronis: there are some tweaks in the few recent commits
<mborzecki> pedronis: i mean, we could very well do a single pr with renames (provided it's renames only)
<pedronis> in which sense?
<pedronis> my plan is not renames only
<pedronis> mborzecki: my question was really more is this simple enough that we should just try to get it in quickly, or does it need careful looking over anyway?
<pedronis> my plan to avoid some many struct involve more than renames
<mborzecki> pedronis: maybe let's have a chat with cmatsuoka then?
<pedronis> anyway reducing the structs is not a priority
<pedronis> but you asked me if I had opinions about names
<pedronis> and it's complicated :)
<mborzecki> haha
<mvo> Saviq: can you please "snapcraft release multipass 2114 edge/snap-test-classic" for me? this way I can actually try to test your exact scenario
<Saviq> mvo: done, and invited you as collaborator
<mvo> Saviq: thank you I think I can reproduce, let me dig into this
<mvo> 8858 needs a second review, should be simple
<mvo> well, not that simple but I should not say this or it won't get reviewed :P
<mup> PR snapd#8885 opened: data/sudo: drop a failed sudo secure_path workaround <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8885>
<popey> ogra your mjpg streamer snap, how do you control the webcam resolution? mine is only grabbing at 640x480
<popey> ah, there's an option for the .so
<ogra> its in the config file
<ogra> i have a half done branch that uses snapctl but that has been sitting for a while (it has many users, switching over the config without breaking them is a little work)
<popey> found https://community.octoprint.org/t/available-mjpg-streamer-configuration-options/1106
<pedronis> mborzecki: I think zyga asked you to review #8829 ?
<mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
<ogra> popey,  mjpg-streamer --help ... and  mjpg-streamer -i "input_uvc.so --help"
<ogra> it comes with documentation builtin too ð
<ogra> (not all controls work with all webcams though ... watch journalctl output)
<ijohnson> pedronis: so can I merge #8340 ?
<mup> PR #8340: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<ijohnson> it's green now
<pedronis> ijohnson: yes, any concerns?
<ijohnson> nope, just wanted to be extra suer
<ijohnson> *sure
 * ijohnson clicks the button
<mborzecki> and boom
<mup> PR snapd#8340 closed: boot, snap-bootstrap: move initramfs-mounts logic to boot pkg <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8340>
<mvo> Saviq: found the issue, WIP in https://github.com/snapcore/snapd/compare/master...mvo5:classic-to-strict-is-fine?expand=1 but need to write a proper test after lunch
<mvo> Saviq: but with your testcase it seems to work
<pedronis> pstolowski: is #8812 ready for re-review?
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> pedronis: yes, thank you
<pedronis> pstolowski: ok, thx, putting it back in the queue
<ijohnson> pedronis: remind me, can *util packages import other *util packages ?
<ijohnson> i.e. can I import strutil from osutil/disks ?
<pedronis> ijohnson: usually yes
<pedronis> I mean we should be reasonable and avoid circular deps, but there is no sense to a general rule
<pedronis> that they can't
<pedronis> pstolowski: I finally got to #8395, I didn't something is missing but maybe I'm confused (could be)
<mup> PR #8395: o/ifacestate: handle interface hooks when preseeding <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8395>
<ijohnson> pedronis: ack sounds good
<ijohnson> thanks for the clarification
<pedronis> pstolowski: s/I didn't/I think/
<pstolowski> pedronis: thanks, will need to refresh my memory, it's been a while
<pedronis> pstolowski: it's not urgent for you to go back to it, don't context switch for me, but I wanted to reduce my own queue a bit more
<mup> PR snapd#8886 opened: gadget: mv encodeLabel to strutil.EncodeHexBlkIDFormat <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8886>
<pedronis> ijohnson: ^ why strutil and not osutil itself though?
<pedronis> or even osutil/disks
<ijohnson> pedronis: it seems like a string function ?
<ijohnson> pedronis: I mean sure it can live in osutil/disks if you want that's fine
<pedronis> ijohnson: it's a very very specific string function
<ijohnson> true...
<pstolowski> pedronis: ok, thanks, i've read your comment, i'll definitely  need to think deeper, so will get back to it later
<ijohnson> pedronis: mmm ok I'll move it to osutil/disks, but it will make more messy git history in my existing PR
<pedronis> ijohnson: heh
<pedronis> ijohnson: that is not a good reason in particular
<pedronis> ijohnson: anyway except for Version stuff most of strutil is quite quite generic
<pedronis> is not a meant to be a repository of any sort of side-effect free things that produce strings
<pedronis> PathIterator is also a bit borderline there
<ijohnson> apparently you can't change branch names in a PR on github which also is maybe a bit expected
<pedronis> names are hard (in more than one sense)
<ijohnson> alright re-opened as 8888
<pedronis> mborzecki: does #8887 supersede #8775 ?
<mup> PR #8887: bootloader: pull recovery grub config from internal assets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8887>
<mup> PR #8775: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<mup> PR snapd#7570 closed: [RFC] snap-mount-dir: add mount unit for snap-mount-dir <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7570>
<mup> PR snapd#8886 closed: gadget: mv encodeLabel to strutil.EncodeHexBlkIDFormat <Simple ð> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8886>
<mup> PR snapd#8887 opened: bootloader: pull recovery grub config from internal assets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8887>
<mup> PR snapd#8888 opened: gadget: mv encodeLabel to osutil/disks.EncodeHexBlkIDFormat <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8888>
<mborzecki> pedronis: i think i'll close 8875 and will be open smaller bits as we go (always one less PR to remember)
<pedronis> mborzecki: sounds good
<mup> PR snapd#8775 closed: [RFC] bootloader, boot: boot scripts, edition <Needs Samuele review> <UC20> <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8775>
<cjp256> anyone have a suggestion for what to do when kswap0 and snapd (and in this instance canonical-livepatch) lock up CPU?  i've been using the default 1GB swap and have run into this a fair bit again recently.  it locks up hard enough the only recourse is usually to hard power-off unless you wait long enough for OOM killer to do something, if it even does (laptop was unusable for at least 10-15 minutes in my case).
<mvo> cjp256: do you have the output of "journalctl -u snapd" when this happens? and snap changes ideally? would love to know how to reproduce
 * mvo is actually in a meeting
<cjp256> mvo: the journal https://pastebin.ubuntu.com/p/NqtJryXrwc/  shows a trace.  last `change` was a few hours beforehand, not canonical-livepatch fwiw
<pstolowski> cachio: have you seen my comment re early core20 config test?
<cachio> pstolowski, no, I didnt, sorry
<cachio> just got disconnected
<pstolowski> cachio: in standup notes
<mvo> cjp256: thanks, do you have a timestamp for me when the OOM happend?
<mvo> cjp256: also - how many snaps are installed there?  anything special about the machine this run on?
<cjp256> mvo: relevant journal log chunk https://pastebin.ubuntu.com/p/ynj57trvfg/
<mvo> cjp256: cool, thanks
<cjp256> interesting that the logs seem to be out of order :D
<cachio> pstolowski, ok, I'll take a look again
<cachio> ijohnson, if you make a try with uc20-recovery test please tell me
<ijohnson> cachio: yes sorry got distracted with doing reviews, but will try that real soon
<pedronis> ijohnson: nitpick on #8888, feel free to apply it on a follow up or something
<mup> PR #8888: gadget: mv encodeLabel to osutil/disks.EncodeHexBlkIDFormat <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8888>
<ijohnson> pedronis: ack I think I'll take it in a followup
<pstolowski> pedronis: small nitpicks under #8852
<mup> PR #8852: asserts: introduce new assertion validation-set <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8852>
<ijohnson> pstolowski: reviewed 8812 for you
<pedronis> pstolowski: thank you
<pstolowski> ijohnson: thanks!
<pstolowski> ijohnson: updated
<cachio> pstolowski, I run twice and both times saw the same error https://paste.ubuntu.com/p/5wfwC7kNbc/
<ijohnson> pstolowski: re-approved
<pstolowski> ijohnson: thank you!
<mup> PR snapd#8888 closed: gadget: mv encodeLabel to osutil/disks.EncodeHexBlkIDFormat <Simple ð> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8888>
<pstolowski> cachio: i'll take a look. wasn't something like this happening when things were changing in core20 and it wouldn't boot? i saw similiar problems before when i worked on this and it would automagically work again another day after things landed
<cachio> pstolowski, ahh, because it is the only test on which it fails to sdo shpass
<pstolowski> cachio: yes, it fails in prepare already, cannot ssh into the nested system
<mup> PR snapd#8858 closed: asserts,daemon: add support for "serials" field in system-user assertion <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8858>
<mup> PR snapd#8885 closed: data/sudo: drop a failed sudo secure_path workaround <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8885>
<cachio> in my case it could ssh
<cachio> but fails trygin to create the test user
<cachio> it is weird bacause all the other uc20 tests are passing
<pstolowski> cachio: ah, wait, i think i misread the log (too many ssh attempts), indeed it seems it's test user password issue
<pstolowski> why would it start failing, did we change something?
<pstolowski> cachio: did it start failing last night?
<cachio> pstolowski,  let me check
<cachio> pstolowski, 2020-06-15 passed
<cachio> 2020-06-16 failed
<cachio> with the same error
<cachio> so, yesterday was the first fail
<pstolowski> cachio: ok, thanks, i'll try to find out what/if something changed
<cachio> pstolowski, nice, thanks
<mvo> fwiw I pushed a new "test-snapd-classic-confined" to candidate, please let me know if that causes any issues, I will revert in this case (but should be fine)
<ijohnson> cachio: mmm I see a potential issue with uc20 and self signed models, need to investigate more but it would explain your issue
<ijohnson> cachio: can you show your model assertion you used to build the external image ?
 * ijohnson needs to step out for few minutes
<cachio> ijohnson, https://github.com/sergiocazzolato/validator/blob/master/images/models/pc-amd64-20.model
<cachio> this is for amd64
<pedronis> I'm not sure what Ian meant
<cachio> ijohnson, it is hte same we use for nested tests on snapd projecy
<cachio> project
<cachio> ijohnson, what I see is that after reboot /home/gopath does not exist anymore
<ijohnson> cachio I thought the issue was that you couldn't login to the device via ssh?
<cachio> ijohnson, I can login
<mup> PR snapd#8889 opened: snapstate: fix autorefresh from classic->strict <Bug> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889>
<cachio> ijohnson, is that the spread path is not there anymore after the reboot
<cachio> ijohnson, then I see this https://paste.ubuntu.com/p/VNbk5hjCXf/
<pedronis> as we said in the standup, I think the issue is that the system comes up
<pedronis> in recovery mode
<pedronis> not run mode
<pedronis> after the test
<pedronis> cachio: can you see what's in /var/lib/snapd/modeenv in the system without the path?
<cachio> pedronis, mode=recover
<pedronis> yea, so what I said
<cachio> so, why it fails here and is not failing on each PR?
<pedronis> something is different
<pedronis> but I don't know the test well
<cachio> here I am testing with secboot and tpm enabled
<pedronis> just making sure we understand the problem the same way
<ijohnson> Ah sorry well the issue I'm seeing is a different one then
<cachio> pedronis, ok, thnaks, I'll compare the systems with the one running on gce after lunch
 * cachio lunch
<ijohnson> ah sorry I actually need to step out now for longer
<pstolowski> cachio: i just run that test two times and it passed on second run. something is wonky
<pedronis> cmatsuoka: I did a pass on #8813
<mup> PR #8813: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<pedronis> cmatsuoka: I marked it changes requested mostly because of the not glued up tests
<cmatsuoka> pedronis: thanks, looking
<mup> PR snapcraft#3172 closed: cli: restore --target-arch with warning for LXD and Multipass <bug> <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3172>
<mup> PR snapcraft#3175 opened: cli: restore --target-arch with warning for LXD and Multipass <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3175>
<mup> PR snapcraft#3176 opened: tools: fix environment-setup to work on aarch64 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3176>
<mup> PR snapd#8852 closed: asserts: introduce new assertion validation-set <Skip spread> <validation-sets :white_check_mark:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8852>
<cmatsuoka> pedronis: added missing glue and todo notes, left some of the changes to follow-ups
<pedronis> cmatsuoka: thanks, probably deploy.go => install.go and other things still called deploy should be called install, like deployMountpoint
<cmatsuoka> pedronis: yes, adjusting that
<pedronis> some test names as well
<cmatsuoka> pedronis: the mountpoint itself looks a bit strange, do you have a suggestion for a better name?
<cmatsuoka> hmm, renaming to install.go now could be a problem because there's a file with the same name in the next PR
<pedronis> cmatsuoka: then call it content.go I suppose
<cmatsuoka> pedronis: content.go is good, thanks
<pedronis> cmatsuoka: about the mountpoint,  maybe /run/snapd/gadget-install
<pedronis>  /run/snapd is dirs.SnapRunDir
<cmatsuoka> yes, good, I'll use it, thanks
 * cachio at kinesiologist
<pedronis> cmatsuoka: if you do something like what with do for FreezerCgroupDir in sandbox/cgroup/freezer.go, maybe you don't need the Mock but dirs.SetRootDir is enough, you'll have to see
<pedronis> ah, it's only local anyway
<pedronis> so doesn't matter
<cmatsuoka> pedronis: so can I just declare an uninitialized var and initialize it on init() to use dirs.SnapRunDir?
<pedronis> yes, and if you setup a callback you can also have if follow to root in dirs.go
<cmatsuoka> interesting solution
<pedronis> as I said, you might not need it here
<pedronis> I thought you were exporting the Mock but is only in export_test.go
<cmatsuoka> yes. well, I'll use a simple initialization and then if need arises we can use the callback
<pedronis> cmatsuoka: you lost deploy_test.go somehow instead of it getting commited as content_test.go now
<pedronis> https://github.com/snapcore/snapd/pull/8813/commits/6245b309270ee00b818ccfea45a84522c3f11499
<mup> PR #8813: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8813>
<cmatsuoka> that's... strange, let me see here what's happening and I'll push a fix along with the content mountpoint change
<mup> PR snapd#8884 closed: cmd/snap: Debian does not allow $SNAP_MOUNT_DIR/bin in sudo secure_path <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8884>
<cmatsuoka> pedronis: pushed. I think the missing test was caused by mistakingly using mv instead of git mv
<pedronis> cmatsuoka: reviewed
<cmatsuoka> pedronis: thank you!
<pedronis> cmatsuoka: a TestWriteFilesystemContent like the TestWriteRawContent would be good
<pedronis> if possible
<cmatsuoka> pedronis: ok, will do
<pedronis> thx
<mup> PR core18#156 opened: Add motd and issue to writable /etc files <Created by WillNilges> <https://github.com/snapcore/core18/pull/156>
<mup> PR snapcraft#3177 opened: repo: consider virtual pkgs for cache invalidation <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3177>
<cachio> ijohnson, cmatsuoka hey
<ijohnson> hey cachio
<cachio> https://paste.ubuntu.com/p/NKNc4SQB8q/
<cachio> I see this
<ijohnson> cachio: this is on uc20 yah ?
<cachio> in the uc20-recovery test
<cmatsuoka> cachio: let's see...
<ijohnson> cachio: snap-repair is known to be broken on uc20
<ijohnson> it needs to be fixed but is somewhat non-trivial to fix
<cmatsuoka> well I don't know what snap-repair is
<MrSassyPants> Whats the current version of this command: snap set system.service.rsyslog disable=true
<MrSassyPants> snap + discord is ddosing kernel log
<ijohnson> MrSassyPants: do you mean how to silence denials AppArmor denials in the system journal ?
<MrSassyPants> snap connect discord:system-observe :system-observe ; snap connect discord:unity7 :unity7
<MrSassyPants> did it
<ijohnson> cool
<MrSassyPants> I googled more
<ijohnson> there's also some AppArmor config to turn denied messages off entirely
<MrSassyPants> idk about such things
<MrSassyPants> I tried the first cli thing that google spat out
<MrSassyPants> the system.service.rsyslog thing
<MrSassyPants> and then proceeded to ask
<ijohnson> MrSassyPants: that command is only applicable to Ubuntu core, not classic Ubuntu systems like desktop or server
<mup> PR snapd#8890 opened: seed: fix LoadEssentialMeta when gadget is not loaded <Created by pedronis> <https://github.com/snapcore/snapd/pull/8890>
#snappy 2020-06-18
<mup> PR snapcraft#3175 closed: cli: restore --target-arch with warning for LXD and Multipass <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3175>
<mup> PR snapcraft#3178 opened: extensions: add gcc to GNOME 3.28 extension part <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3178>
<guiverc> chromium snap:  a post on askubu (https://askubuntu.com/questions/1184357/why-cant-chromium-suddenly-access-any-partition-except-for-home/1251289#1251289) claims they can bypass what I suspect is intended security; should it be reported, if so where?  snapcraft.io  (it maybe nothing; a quick look and I didn't re-create but didn't really try)
 * guiverc adds it's the new added answer by Dan Dasc.
<jamesh> guiverc: it's true that running random binaries from within a snap rather than the public entry points will not be sandboxed.  There's no guarantee that such an invocation will work though.
<guiverc> so not an issue, or known issue... I'll ignore.  thanks jamesh
<mborzecki> morning
<mborzecki> hm weird failure in google:ubuntu-core-20-64:tests/core/snap-auto-mount
<mborzecki> and debug section is buggy in that test too
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mup> PR snapd#8890 closed: seed: fix LoadEssentialMeta when gadget is not loaded <Bug> <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8890>
<pstolowski> morning
<mvo> good morning pstolowski
<mup> PR snapd#8813 closed: gadget,cmd/snap-bootstrap: move partitioning to gadget <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8813>
<zyga> Good morning
<zyga> Iâm back home
<zyga> Tired but okay
<zyga> I just dropped in to say hi
<zyga> And tell you all I will take today and tomorrow off to rest
<zyga> Surgery cannot be done yet, and I need to wait for a few weeks on new
<zyga> Meds that decrease the problem
<zyga> I will resume work next week
<zyga> And will work mostly normally for the next two to four weeks
<zyga> I may have the surgery after that, when my condition improves
<zyga> So that is that
<zyga> Iâm really tired today, had a very painful and long day and night
<zyga> mvo: I will file yesterday today and tomorrow into the system
<mvo> zyga: thank you, get well
<zyga> Thank you, good luck with apparmor and secure boot and everything :)
<mvo> zyga: yeah, slowely working my way forward there, almost no progress yesterday because of other things but I'm somewhat hopeful for today :)
<mvo> mborzecki, pedronis any concerns to merge 8675? it has two +1 now
<pedronis> mvo: I think mborzecki should look at it again
<mborzecki> pedronis: mvo: finishign with some tweaks to u-i, will that a look at that pr next
<mvo> mborzecki: ta
<mwhudson> does something in snapd set LC_ALL to C?
<mwhudson> hm doesn't look like it
<mvo> mwhudson: hey, I don't think so - thanks for updating go/edge !
<mvo> pstolowski: I added an idea to your comment in https://github.com/snapcore/snapd/pull/8881/files#r441360886 - please let me know what you think, zyga is out so I want to push this forward a bit
<mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<pstolowski> looking
 * zyga needs to disable phone notifications
<zyga> mvo: I would not drift away from ###PARAM###, just handle it without panic
<mvo> zyga: haha - sorry
<zyga> as it makes use of map nicer
<zyga> mvo: no worries, I really feel better already
<mvo> zyga: if you want and feel good have a look at my comment, it still uses ###PARM### internally just make the interface for the caller slightly different
<zyga> mvo: yeah I like the interface a lot
<zyga> I misunderstood that it also changes the backend
<zyga> if that's the same backend that's a brilliant way out
<zyga> nice work!
<mvo> zyga: no worries, just comment there if you prefer the []string or "prefix,postfix" either way is fine, you know more about this than me (I slightly prfer []string)
<zyga> I prefer [] as it may be needed to insert this many times
<mvo> zyga: +1
<mvo> thank you zyga
<zyga> really sweet way out of this :)
<zyga> thank You :)
<mvo> :) my pleasure
<zyga> if you park it ping me on irc/tg and I will iterate some more and add tests/i2c support
<zyga> my family is helping me to adjust the bed to a better workspace
<zyga> with "floating" laptop so that I don't need to strain my neck
<zyga> and a split keyboard so that my hands don't have to be in the air while typing
<zyga> I just ordered https://ultimatehackingkeyboard.com/
<mvo> zyga: I did some of the cosmetic changes that jamie asked for, 1.5 unit tests and can push the diff and then it's all yours if you want :) , I have code-review and meetings today
<mvo> zyga: I wonder if a bed breakfast tray would help?
<zyga> mvo: we tried but I really want something that's more less at 45 angle
<zyga> above my head
 * mvo nods
<zyga> some wood and duck tape will work as a prototype
<zyga> I'll send pics when it works :)
<zyga> mvo: I'm afk again, ping me when you are done with the PR
<mborzecki> pedronis_: https://github.com/snapcore/snapd/pull/8887#discussion_r442077693 i was wondering whether there should be any fallback, but i gues when you're generating an image with some version of snapd, the asset must exist
<mup> PR #8887: bootloader: pull recovery grub config from internal assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8887>
<pedronis> mvo: so it seems there was an almost fix of 8889 in the codebase
<pedronis> mvo: there's probably more code to cleanup there
<mvo> pedronis: yeah, it was 2 steps forward, one step back. I did not dig super deep but my feeling is the same, there is more hidding there
<mvo> zyga: pushed the tweak to the signature, feel free to tweak further or change as needed, I'm done with the PR for a couple of hours now (meeting, code-review, lunch etc). keep me updated please and fwiw, really nice job there
<zyga> thanks!
<pedronis> mvo: I left comments there
<pedronis> mvo: I think the issue with the original fix is that we didn't write an UpdateMany tests perhaps?
<pedronis> if don't have many of those, or maybe we did but is not quite right?
<pedronis> s/if don't/we don't/
<pstolowski> mvo: i like your idea, i meant to comment under the PR but it seems this comment is gone
<mvo> pedronis: thanks, I have a look
<mvo> pedronis: but yeah, missing test(s) seems very likely
<mvo> pstolowski: sorry, my fault probably, I resolved it (but it should still be there, just collapsed)
<mvo> pstolowski: anyway, "like it" is enough :)
<pstolowski> mvo: ah indeed it's there, i got confused, sorry
<mborzecki> quick errand, back in a bit
<zyga> mborzecki: woah
<zyga> snap just broke a non-snap app fonts
<zyga> that was *open*
<zyga> surreal
<zyga> I opened telegram
<zyga> and the ebook reader app got messed up
<mborzecki> re
<pedronis> mvo: I made a remark in #8881 that that method needs a doc comment
<mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<mvo> pedronis: thank you!
<mvo> pedronis: also thanks for your comment in 8889, I had no idea we look at flags in so many place, +100 for the unit test(s)
<mvo> s/comment/comments/
<clmsy> did anyone experience "no such device: ubuntu-boot" from trying to boot this: https://github.com/snapcore/pc-amd64-gadget (20 branch)
<mvo> clmsy: I don't remember this but if you used qemu, did you boot it in UEFI mode?
<clmsy> I will double check and comeback mvo, thx
<mvo> ijohnson: I merged 8675 but there is a small suggestion for a followup that is worth checking
<ijohnson> mvo: sure I will take a look in a bit, trying to wrap up my presentation this morning :-)
<mup> PR snapd#8675 closed: osutil: add disks pkg for associating mountpoints with disks/partitions <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8675>
<mvo> ijohnson: no worries
<mvo> ijohnson: it's not urgent, just wanted to mention it :)
<mvo> pstolowski: 8812 looks ready, if you get unrelated failures just ping me and I can sudo merge
<pstolowski> mvo: yes i'm super keen to land it and have been monitoring it; failed on project- on core20 and i restarted the tests
<mvo> pstolowski: ok
<mvo> pstolowski: thanks for being on top of this!
<pstolowski> mvo: let's wait a little bit for current run
<mvo> sure
<mvo> in related news: down to 50 PRs again!
<pstolowski> mvo: failed on centos 8 only, on selinux-clean. cannot be related because this functionality is not yet hooked anywhere
<pstolowski> mvo: so i'd say go ahead an merge
<pstolowski> cachio: hi, #8558 still has unaddressed comments, do you plan to add the doc?
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<cachio> pstolowski, hi, yes, but still applying some improvements to that one
<cachio> pstolowski, I'll push today the update
<pstolowski> cachio: ah, sure
<cachio> pstolowski, there were many changes in nested recently :)
<pstolowski> cachio: yes.. btw, is the core20 early config still failing?
<cachio> pschecking
<cachio> pstolowski, today I see the nested/core20 suite failed with that error https://paste.ubuntu.com/p/fqVwCSZDGf/
<cachio> seems to be a race I think
<mup> PR snapd#8891 opened: o/servicestate: add updateSnapstateServices helper (5/6) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8891>
<mborzecki> https://github.com/snapcore/snapd/pull/8455 could use some reviews
<mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<pedronis> pstolowski: should we merge #8812 ?
<mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pstolowski> pedronis: yes, i pinged mvo earlier but he seems busy. unrelated failure on centos
<cachio> pstolowski, added the sectino to HACKING file
<pedronis> pstolowski: you can merge, centos is marked not required
<cachio> still testing hte lib with different variables
<pstolowski> cachio: would it be possible to add it as --help ?
<pedronis> pstolowski: you don't need mvo
<pstolowski> pedronis: ah, indeed
<cachio> pstolowski, yes let me add that
<pstolowski> the grey merge button is confusing
<pstolowski> done
<pstolowski> that's great. i pushing the last PR then
<mup> PR snapd#8812 closed: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services âï¸> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8812>
<pedronis> pstolowski: yes, the button can be green, grey, or greyed out
<pedronis> something like that afair
<mvo> yeah, centos-8 is no longer required because it's a bit unstable right now
<pedronis> pstolowski: great, not sure I'll get to them immediately though
<mup> PR snapd#8892 opened: o/snapstate,servicestate: use service-control task for service actions (6/6) <Complex> <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8892>
<pstolowski> pedronis: np, i'll probably push some tests to #8892 still
<mup> PR #8892: o/snapstate,servicestate: use service-control task for service actions (6/6) <Complex> <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8892>
<pedronis> pstolowski: is still fairly large?
<pstolowski> pedronis: yes, the 5th one will reduce it a bit
<pstolowski> pedronis: +1,082 â573
<pstolowski> pedronis: maybe I can find some small bits to extract into separate PR(s), but it got really hard at this point
<pedronis> pstolowski: we'll need to see it might get hard to get in one go
<pedronis> it seems to touch a lot of places
<pedronis> pstolowski: there might be things we can do
<pedronis> some things are also inherited messiness
<pstolowski> pedronis: i'll look at the entire diff again and try to find something to propose separately. the main problem was change in semantics of wrappers, it affects a lot
<pedronis> pstolowski: yea, I think we should discuss a bit
<pstolowski> pedronis: and at some point when i was trying to split this i was lost and managing conflicts was nightmare
<pstolowski> because i was trying to do some things "dummy" in preparation for something upcoming, but that just diverged too much
<pstolowski> pedronis: i see a few smaller things that i can extract and propose independently without extra work, so i can prep them to start with
<cachio> mvo, this is the log https://paste.ubuntu.com/p/6jmQQRkpCD/
<cachio> there is another similar
<cachio> do you want it?
<mvo> cachio: looking, one is probably fine for now
<mvo> cachio: I noticed test-snapd-sh-coe20 is missing, building that now
<cachio> mvo, yes, thnaks
<cachio> in most cases we build it
<cachio> in the test
<pstolowski> pedronis: do you have a moment now?
<pedronis> pstolowski: I'm available in the standup HO
<pstolowski> coming
<zyga> mvo: I'm less sleepy now, I will pick up that branch in an hour or two
<mvo> zyga: \o/ thanks!
<mup> PR snapcraft#3178 closed: extensions: add gcc to GNOME 3.28 extension part <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3178>
<ogra> xnox, so we got  UC20 demo from ian today ... systemd in initrd is seriously shiny, you rock !!!
<xnox> ogra:  it's held by duct-tape and lots of hacks from everyone ian maciej michael etc.
<xnox> ogra:  i'm glad that it _appears_ rock solid =)
<ogra> still super shiny and long overdue ... duct tape or not ... kudos !
<abeato> jdstrand, hey, is primed-staged-packages already used to find CVEs for snaps in the store?
 * cachio lunch
<mup> PR snapcraft#3179 opened: Maven plugin: improve error message when target libs are not found <Created by edumucelli> <https://github.com/snapcore/snapcraft/pull/3179>
<jdstrand> abeato: not yet. emitorino got assigned to do that but then some urgent stuff came up. it'll happen 'soonish'
<jdstrand> 'ish' since I'm not quite sure when, but it is the first review-tools item she'll pick up when she gets back to the review-tools :)
<emitorino> abeato, yes, it's on my list as jdstrand mentioned. I plan to work on that feature next week. Let me know if you need it earlier and we can coordinate
<abeato> jdstrand, emitorino great, thanks for the update - no, not in a hurry, I was just wondering if it was already there
<emitorino> abeato, cool, I will let you know as soon as it is ready
<abeato> awesome, thanks
<pstolowski> ijohnson: hey, i've updated services PR
<pstolowski> ijohnson: and i think the loop is correct, please take a look
<ijohnson> Okay, thanks pstolowski
<mup> PR snapd#8893 opened: osutil/disks: refactor diskFromMountPointImpl a bit <Cleanup :broom:> <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8893>
<zyga> jdstrand: I've updated https://github.com/snapcore/snapd/pull/8881
<mup> PR #8881: interfaces: optimize rules of multiple connected iio and spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881>
<zyga> jdstrand: I think everything is addressed now, with one important exception
<zyga> jdstrand: if you review it today it can be cherry picked into the release branch by mvo tomorrow
<zyga> jdstrand: I'm officially off today and tomorrow
<zyga> but I may show up for a moment
<mup> PR snapcraft#3177 closed: repo: consider virtual pkgs for cache invalidation <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3177>
#snappy 2020-06-19
<mborzecki> morning
<mup> PR snapd#8893 closed: osutil/disks: refactor diskFromMountPointImpl a bit <Cleanup :broom:> <Simple ð> <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8893>
<zyga> Hey
<zyga> Not going to be around today
<zyga> Please relay to mvo that the fix is ready
<zyga> And needs reviews
<zyga> That is 8881
<mborzecki> zyga: mvo is off today and on monday
<zyga> I see
<zyga> I think jamie will +1 it
<zyga> so it needs 2nd review
<mborzecki> zyga: jdstrand already did, i can apply the little tweaks he suggested
<zyga> oh, super
<zyga> I didn't check
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8455 ?
<mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Simple ð> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<pstolowski> mborzecki: hi! sure
<mborzecki> thanks!
<pedronis> hello
<pstolowski> hi pedronis
<pedronis> pstolowski: mborzecki: when you have a moment a re-review of #8702 would be great, I pushed some changes and added a spread test to it
<mup> PR #8702: overlord/configstate: add system.kernel.printk.console-loglevel option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8702>
<mborzecki> ack
<pstolowski> pedronis: sure
<mup> PR snapd#8455 closed: tests/lib/cla_check: expect explicit commit range <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<pedronis> pstolowski: you remember at some point we had to snap.Info.Type -> snap.Info.GetType ?
<pedronis> to make a change safely
<pstolowski> pedronis: yes.. we wanted to avoid surprises with go silently accepting function instead of struct member
<pedronis> pstolowski: yes, now that we are down to 50 PRs it might be time to finally undo that, I'll work on this, super mechanical PR but need to land a bit quickly
<pstolowski> pedronis: ok, shouldn't be too annoying hopefully
<mborzecki> pstolowski: any of your servies PRs need a 2nd review?
<pstolowski> mborzecki: #8991 only atm, thanks
<mup> PR snapd#8894 opened: many: rename back snap.Info.GetType to Type <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8894>
<pedronis> pstolowski: mborzecki ^
<pstolowski> thank you
<mborzecki> btw. has anyone switched to the new github ui?
<pstolowski> yeah, it's surprising go is happy with "func (s *Info) Type() Type {.." ;)
<pedronis> mborzecki: I get 500s if I try
<pedronis> or maybe I'm just getting 500s right now
<pedronis> now thery status says there are issues
<pedronis> mborzecki: pstolowski: is github working for you atm?
<pstolowski> pedronis: yes. got 500 once, then work
<pstolowski> *works
<pedronis> ok, it 500s quite consistenly here
<mborzecki> hmm
<mborzecki> https://www.githubstatus.com/
<mup> PR snapd#8895 opened: tests: mock servicestate in api tests to avoid systemctl checks  (6/8) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8895>
<pstolowski> pedronis: ^
<pstolowski> hmm got FAIL: cmd_sign_build_test.go:108: SnapSignBuildSuite.TestSignBuildWorksDevelGrade
<pstolowski> "cannot sign assertion: cannot sign assertion: bad GPG produced signature: it does not verify:
<pedronis> pstolowski: we are getting those sometimes, I haven't had a chance to dig, or anybody else afaik so far
<pstolowski> i see. couldn't repro locally
<mborzecki> and another thunderstorm
<mborzecki> heh, summer weather
<pstolowski> mborzecki: #8895 needs a 2nd review if you have a moment
<mup> PR #8895: tests: mock servicestate in api tests to avoid systemctl checks  (6/8) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8895>
<mborzecki> pstolowski: looking at 8702, then 8891, after that 8895 :)
<pstolowski> thanks
 * pstolowski lunch
<mborzecki> pedronis: have you tried systemd-sysctl --prefix .. --prefix .. on xenial?
<mborzecki> afaic the spread test executes the call with just one --prefix
 * mborzecki spins up a xenial node
<pedronis> mborzecki: no,  I straced it only on 20
<mborzecki> pedronis: and it works there too
<pedronis> mborzecki: good, thanks for thinking about this
<pedronis> I suppose we could have done multiple calls if it didn't work
<mborzecki> yeah, but we're good so meh, one call is fine
<mborzecki> yet another thunderstorm, 2nd today, looking at weather radars there's 2 more coming :/
<pedronis> mborzecki: seems we have archive issues with fedora ?
<mborzecki> that's unfortunate
<mborzecki> maybe dl.fedoraproject.org is hosted on some of the hosts that are being moved
<pedronis> mborzecki: see https://github.com/snapcore/snapd/pull/8895/checks?check_run_id=787745417
<mup> PR #8895: tests: mock servicestate in api tests to avoid systemctl checks  (6/8) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8895>
<mborzecki> pedronis: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/MAGJJTVR777ARZ4TVMBQQ3YK6RC7ODE6/
<mborzecki> pedronis: can you switch fedora-* to unstable for now?
<mborzecki> i know mvo can, but i'm not sure anyone else has the permissions to do that
<pedronis> I don't think I can
<pedronis> mborzecki: we can turn them manual as suppose
<pedronis> or ping him on tg
<mborzecki> 3rd thunderstorm
<mborzecki> pstolowski: left a comment in #8891
<mup> PR #8891: o/servicestate: add updateSnapstateServices helper (5/8) <Needs Samuele review> <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8891>
<pstolowski> ty
<mup> PR snapd#8894 closed: many: rename back snap.Info.GetType to Type <Cleanup :broom:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8894>
 * cachio lunch
<sergiusens> jdstrand:
<sergiusens> any ideas about disconnect failing "- Disconnect gtk3-hello:gnome-3-28-1804 from gnome-3-28-1804:gnome-3-28-1804 (cannot update mount namespace of snap "gtk3-hello": cannot update preserved namespace of snap "gtk3-hello": cannot update snap namespace: cannot create writable mimic over "/usr/share": no such file or directory)"
<sergiusens> that is on https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-snappy-dev-snapcraft-daily/bionic/amd64/s/snapcraft/20200619_061338_41454@/log.gz
<jdstrand> sergiusens: otoh no. I recommend filing a bug with steps to reproduce. it looks a bit curious since a) /usr/share should be in the snap's base runtime and b) not sure why in the snap disconnect it is *creating* a writable mimic (I would think that would happen during connect, not disconnect; but this may not be an error depending on how it is unraveling the mount namespace as part of disconnect)
<sergiusens> jdstrand: this only happens on autopkgtest infra
<jdstrand> sergiusens: this is a normal snap install, not snap try?
<jdstrand> (it shouldn't matter, but curious)
<sergiusens> jdstrand: yes, normal install it is
<sergiusens> jdstrand: this is what we do https://github.com/snapcore/snapcraft/blob/master/tests/spread/extensions/gnome-3-28/task.yaml and this works just fine on spread/google
<cmatsuoka> cachio: hi, are you aware of this error? https://github.com/snapcore/snapd/pull/8824/checks?check_run_id=788996098
<mup> PR #8824: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
<ijohnson> cmatsuoka: that looks like a result of mborzecki's CLA fix from this morning
<ijohnson> cmatsuoka: have you merged master to this PR ?
<cachio> cmatsuoka, checking
<cmatsuoka> ijohnson: hummm I think I didn't, let's do it
<cmatsuoka> ijohnson, cachio: hmm, I have a different cla error now, but that one is gone at least :)
<ijohnson> cmatsuoka: what's the new one :-) ?
<cmatsuoka> now it's verifying the CLA for all email addresses in my launchpad account, it seems
<ijohnson> :-/
<cmatsuoka> I'm doing it again just be sure it's deterministic
<cmatsuoka> so this is what I'm getting now: https://github.com/snapcore/snapd/pull/8824/checks?check_run_id=789109680
<mup> PR #8824: many: move encryption and installer from snap-boostrap to gadget <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824>
<ijohnson> cmatsuoka: which email is configured as your contact address?
<cmatsuoka> the canonical one
<ijohnson> hmm yeah me too
<ijohnson> let me see if the CLA check fails for me now too
<cmatsuoka> I think, /me double checks
<ijohnson> cmatsuoka: ahh seems I can't test it because both of my email addresses are already on master
<cmatsuoka> hmm, git shortlog -se only lists my canonical email
<ijohnson> which also implies I may have been a bit sloppy with some previous commits using my personal email ...
 * cmatsuoka investigates how cla_check.py works
<ijohnson> cmatsuoka: for reference this is what happened for me https://github.com/snapcore/snapd/pull/8896/checks?check_run_id=789123625
<mup> PR #8896: README.md: make changes to test CLA checker <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8896>
<mup> PR snapd#8896 opened: README.md: make changes to test CLA checker <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8896>
<mup> PR snapcraft#3180 opened: build providers: nice message on bad base <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3180>
<ijohnson> cmatsuoka: did you ever figure anything out ?
<cmatsuoka> ijohnson, cachio: this is interesting: if I run it locally, I get:
<ijohnson> cmatsuoka: if it's not working anymore I can submit a PR reverting mborzecki's PR so that you can land things
<cmatsuoka> Need to check 1 emails:
<cmatsuoka> â claudio.matsuoka@canonical.com already on master
<cmatsuoka> but in the tests it lists 2 addresses, for some reason
<cmatsuoka> let me check what that PR changed...
<cmatsuoka> humm, unless a regular expression is failing there...
<cmatsuoka> no, it can't be a regexp failure :|
<cmatsuoka> I'll check the PR
<cmatsuoka> ijohnson: well it's not urgent, I'll check that with maciek on Monday
<ijohnson> cmatsuoka: ok
<mup> PR snapcraft#3181 opened: cli: don't warn about --target-arch if target_arch is None <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3181>
<cmatsuoka> cachio: it seems that git shortlog -se master..HEAD in the test machine is listing more email addresses than it used to do, and more than what I see locally in the same branch. Does it make any sense to you?
<cmatsuoka> cachio: Did we change anything in the repository clone process, or the git version, or something like that?
<ijohnson> cmatsuoka: I see the same as you, 5 commits by your canonical email
<ijohnson> on my machine locally with your branch that is
<cmatsuoka> that's very odd
<cmatsuoka> I mean, not what you're seeing, but what the test is seeing
<cachio> cmatsuoka, checking
<mup> PR snapd#8896 closed: README.md: make changes to test CLA checker <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8896>
<cachio> cmatsuoka, dont see any change, not sure why it is failing
<mup> PR snapcraft#3181 closed: cli: don't warn about --target-arch if target_arch is None <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3181>
<mup> PR snapcraft#3182 opened: build providers: improve warning for unknown base <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3182>
<cachio> cmatsuoka, hi
<cachio> cmatsuoka, testing the nested lib I see secboot_tpm.go:392: TPM provisioning error: the TPM is in DA lockout mode
<cachio> any idea why it could be happening?
<mup> PR snapcraft#3180 closed: build providers: nice message on bad base <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3180>
<cmatsuoka> cachio: no idea, it seems very weird
<cmatsuoka> cachio: Re: TPM error message: let me see here what could be happening
<cmatsuoka> cachio:  is it happening in a normal test that used to work before, or is it a new test?
<cmatsuoka> cachio: our number of tries for DA is set to 32, it shouldn't lock that easily
<cachio> I am starting a vm using the swtpm-mvo snap
<cachio> in my machine
<cachio> cmatsuoka,
<cmatsuoka> cachio: so is it a new installation?
<cachio> cmatsuoka, yes
<cmatsuoka> cachio: are you clearing the tpm?
<cachio> cmatsuoka, no
<cachio> should I ?
<cmatsuoka> cachio: in a new installation yes, but if you're rebooting an existing system, no
<cmatsuoka> cachio: to clear it delete /var/snap/swtpm-mvo/current/tpm2-00.permall
<mup> PR snapcraft#3183 opened: static: prepare for update to black 19.10b0 <tooling> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3183>
<cachio> cmatsuoka, I'll try that
<cachio> thnaks
<cmatsuoka> cachio: yaw, if the problem persists we can investigate more
<cachio> cmatsuoka, sure, thanks
<mup> PR snapcraft#3182 closed: build providers: improve warning for unknown base <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3182>
<mup> PR snapd#8897 opened: tests: trying to debug the weird cla problem <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8897>
#snappy 2020-06-20
<mup> PR snapcraft#3183 closed: static: prepare for update to black 19.10b0 <tooling> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3183>
<mup> PR snapd#8897 closed: tests: trying to debug the weird cla problem <â Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8897>
