#snappy 2015-09-28
<beuno> ogra_, it does not
<beuno> (include types)
<dholbach> good morning
<davidcalle> Morning o/
<clobrano> Morning :)
<clobrano> Chipaca: thank you ;)
<longsleep> Good morning snappy!
<ogra_> moin moin
<longsleep> ogra_: nice release for the rpi2 - i whish i also could use a recent kernel :/
<longsleep> btw, i found why recent u-d-f stopped working for me - bug #1499993
<ubottu> bug 1499993 in Snappy "U-d-f uses hardcoded names for kernel and initrd instead of the ones defined in hardware.yaml" [Undecided,New] https://launchpad.net/bugs/1499993
<ogra_> longsleep, sadly the verioned approach didnt work properly ... not sure what we can do (beyond finally getting a kernel snap), i guess we need to discuss that
<longsleep> ogra_: you mean the webdm issue cannot be fixed?
<ogra_> webdm ?
 * ogra_ reads the bug again
<longsleep> the problem that webdm did not work for side loaded oem snaps?
<ogra_> oh, i belive Chipaca already has a fix for that, just needs some testing
<longsleep> ogra_: no my issue has nothing todo with webdm, but that could be fixed by adding a way to define the names for kernel and initrd files
<longsleep> ogra_: ok good, but you think the issue with the file name has todo with versioning?
<longsleep> i guess i can name the uImage vmlinuz and the uInitrd initrd.img but that feels wrong
<ogra_> indeed it does ... i didnt say its not a bug :)
<longsleep> and i miserably failed to get the odroid boot a zImage on the weekend ..
<longsleep> Nny suggestions on how to debug early kernel load errors without having hardware support for to dump printk buffer on the console would be most welcome :)
<ogra_> there is an android option to support /proc/last_kmesg .... i have seen that function in non android kernels in the past
<ogra_> hmm, though that wouldnt help in this particular case (where you cant boot at all)
<longsleep> ogra_: how would that work when the kernel fails to boot
<ogra_> yeah, sorry, brainfart
<longsleep> ogra_: yeah - the problem is that the kernel seems to crash or stop in uncompress - at least before flushin the printk buffer for the fist time
<longsleep> essentially i see nothing until u-boot gave over to the kernel
<ogra_> probably ppisati has an idea ... but i think he is out for another week
<longsleep> and i "think" i got the zImage and initrd patch right - the bytes for the kernel image look right
<longsleep> but it just crashes
<ogra_> he might know a trick to make uboot more verbose or some such
<longsleep> well, in u-boot i have added debug and everything looks good
<ogra_> i assume you already use "earlyprintk" on your cmdline ?
<longsleep> yes but that does not help so much when the arm hardware does not have a kernel debug driver to log this stuff to the serial console
<longsleep> i currently think it is some crazy thing which is missing in u-boot when using bootz instead of bootm, though i did debug this and did not find any :/
<longsleep> ogra_: this means for now the only way seems to be to use the hardcoded names for kernel and initrd even if they have different formats. My fear is that they would be overwritten on update - or is that prevented somehow then a custom kernel was used during image creation?
<ogra_> no, that was solely because we ended with duplicated kernels on upgrades when we used versioned binaries (i think nobody took uImage into account when that was hacked in)
<ogra_> not supposed to be or stay like that ...
<longsleep> ogra_: ah you mean that was the reason to hardcode the file name?
<ogra_> yes
<longsleep> i see - so you think i can just use those file names and they would be overwritte on ubuntu-core update?
<ogra_> and whoever landed it had already worked an 18h day and was focused on amd64 for the last days :)
<ogra_> we need to look at it again and see how to get the old support back in
<longsleep> mhm the patch was made by sergiusens but it was in July already
<ogra_> hmm
<longsleep> "Normalize kernel and initrd with proper templating. by sergiusens approved by chipaca"
<ogra_> i think u-d-f calls snappy at some point during installation ...
<ogra_> i'd rather suspect a snappy patch from mvo from the last two weeks that broke it
<longsleep> no http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/revision/195
<longsleep> look at the changes in core_uboot.go
<longsleep> before it took whatever filename it got and copied to destination folder
<ogra_> hmm, right
<longsleep> now it copies not to the folder but to the hardcoded filename
<longsleep> so it does not seem to be related to the changes from the last weeks
<ogra_> indeed
<ogra_> well, i'll bring it up with the team ... thouh everyone is at a sprint in budapest this week
<ogra_> response time might not be great
<longsleep> no worries - i will experiment with using these names for uInitrd and uImage and might eventually get the device to boot zImage as well
<JamesTait> Good morning all; happy Monday, and happy Drink Beer Day! ð
<Chipaca> good morning people
<Chipaca> longsleep: if it's broken, it might be my fault, whatever it is :)
<Chipaca> longsleep: I seem to have fixed webdm, but haven't uploaded it; I can give it to you to try if you want.
<Chipaca> ogra_: what's uImage?
<longsleep> Chipaca: uImage is the same as zImage but with a u-boot compatible container
<Chipaca> ah
<Chipaca> longsleep: ogra_: when we did that boot simplification we knew we were most likely missing some ... *ahem* ... "corner cases"
<Chipaca> but the good news it should now fit in our puny little brains and let us extend it
<Chipaca> (note i haven't read all the backlog so i might be missing something ;) )
<longsleep> Chipaca: http://www.denx.de/wiki/view/DULG/UBootImages
<longsleep> Chipaca: well - yeah i was not able to follow the changes in july so closely as i should have
<Chipaca> what's "unity os"? :)
<longsleep> i have no idea
<Chipaca> neither does wikipedia
<Chipaca> anyway. gotcha wrt header.
<longsleep> Chipaca: u-boot learned to boot linux zImage and initrd without u-boot container on 2012-03-30
<longsleep> as lots of arm devices use u-boot from 2011 they do not support it and need uImage and uInitrd :/
<Chipaca> that's relatively recent compared to lead times in getting uboot on the hardware
<Chipaca> yeah
<Chipaca> hard to argue when getting a newer uboot means having to use a more expensive provider
<longsleep> the patches are small, but i failed to get the ODROID boot a zImage so far ..
<Chipaca> (or is uboot firmware?)
<longsleep> yes u-boot is firmware
<Chipaca> ah! we should be able to fix that then :)
<longsleep> the soc manufacturer usually ships a tree
<longsleep> err no
<Chipaca> aw
<longsleep> those trees are very messy and most often do not share common git history with upstream u-boot
<longsleep> for the aml meson8 platform the patch set is about 10000 lines of terrible patch code
<longsleep> which will never be upstreamed to u-boot head
<longsleep> and also cannot be rebased on upstream because u-boot has changed a lot since 2011
<longsleep> imho snappy should be able to work without too much pain when u-boot does not support bootz command
<Chipaca> ogra_: do you know offhand where the generic-* snaps are built from?
<Chipaca> CPI seems to think they are architecture:all
<Chipaca> which is probably wrong :)
<ogra_> Chipaca, https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<Chipaca> ogra_: ta
<Chipaca> ah, indeed, no architecture header
<Chipaca> need to query mvo & sergio about that
<Chipaca> s/header/package.yaml top-level line/
<Chipaca> ogra_: echo "config: {ubuntu-core: {autopilot: false}}" | sudo snappy config ubuntu-core -
<Chipaca> i find the yaml spec hard to read as a quick reference, but the above works \o/
 * ogra_ finally managed to file bug 1500375
<ubottu> bug 1500375 in Snapcraft "inconsistent build results due to wrong usage of recommends" [Undecided,New] https://launchpad.net/bugs/1500375
<ogra_> Chipaca, oh, no -- - anymore ?
<Chipaca> ogra_: yeh, not sure when we picked that one up :)
 * ogra_ makes a mental note
<Chipaca> ogra_: but what i was pointing at was the lack of \ns and faffing with indentation for a single value
<ogra_> yeah !
<Chipaca> turns out, yaml has something it calls json-compatible maps
<Chipaca> which i should look into sometime
<Chipaca> not today tho :)
<Chipaca> ogra_: now, because it's yaml, the whitespace there is needed :-/
<Chipaca> but a single space is tolerable
<ogra_> yeah, definitely better than before
 * ogra_ notes that nobody from the budapest crowd is online ... must have been good beer last night :) 
 * ogra_ grumbles about bug 1500020 
<ubottu> bug 1500020 in ubuntu-core-config (Ubuntu) "/var/lib/opencryptoki needs to be in /etc/system-image/writable-paths" [Undecided,New] https://launchpad.net/bugs/1500020
<ogra_> i dont get why i dont see it on amd64
<ricmm> ogra_: we are all online
<ricmm> well not all I guess
<ogra_> :)
<biezpal> asac, hey, is there any updates about https://bugs.launchpad.net/snappy/+bug/1498396 ?
<ubottu> Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New]
<biezpal> asac, it's really important for us..
<ogra_> biezpal, the "current" link for data paths is supposed to re-appear
<ogra_> but i doubt that will happen before the next stable release
<ogra_> Chipaca, ^^^ do you knwo if anyone already works on this ?
<biezpal> ogra_, cool, thanks
<Chipaca> ogra_: it's next in my list, i think
<ogra_> (also note that most of the snappy team is at a sprint this week ... quick answers might be rare :) )
<biezpal> hmm, maybe it's a right time to participate in snappy development :)
<ogra_> every time is the right time for that :)
<ogra_> don't hold back :)
<longsleep> this reminds me, my boss told me he signed the Ubuntu Contributor Agreement, anyone can check?
<Chipaca> longsleep: when did he do it?
<longsleep> Chipaca: Friday maybe or on the weekend, though it might be possible he already did it a month back (quote)
<Chipaca> longsleep: basically, you (or your company? not sure how it works for companies -- i should check) would appear in https://launchpad.net/~contributor-agreement-canonical
<Chipaca> longsleep: if it's been processed, that is
<longsleep> let me check
<Chipaca> longsleep: there was a bit of a backlog but it should be cleared now (the person that used to do it left, and we bungled the transition)
<longsleep> Chipaca: Companies should appear there too?
<Chipaca> that's what i don't know :)
<longsleep> Chipaca: anyhow neither company nor name on the list, but i do not see any companies there
<Chipaca> yep
<Chipaca> and the person that i'd ask is not on irc right now; poking up the chain
<Chipaca> hah! had her timezone wrong. she should be around soon.
<longsleep> Chipaca: ok great thanks - i will resume work on snapcraft later this week and i would like to be produce mergeable patches this time
<ogra_> these slackers in the US only start working in the afternoon ...
 * Chipaca understands
<ogra_> they should take the chinese as example ! they start working in the middle of the night already :)
<longsleep> but they leave at 4
<ogra_> true
 * longsleep wakes up at 4
<longsleep> p.m.!
<ogra_> crazy
<ogra_> hah
<Chipaca> so, i should adopt the best of both worlds
<longsleep> <<< nick name
<Chipaca> start working in the afternoon, leave at 4
<Chipaca> \o/
<ogra_> perfect !
<longsleep> Chipaca: best would be to add our https://launchpad.net/~strukturag team to the cla team if any such thing is possible
<Chipaca> longsleep: i'll check
 * Chipaca ~> lunch
 * ogra_ takes a bit of Chipaca 
<ogra_> *bite
<Chipaca> ogra_: ow
<ogra_> well, if you turn into lunch you shoudl expect that :)
<Chipaca> ogra_: not my fault you can't tell apart a "transforms into" arrow from a "begets" arrow
<ogra_> haha
<sergiusens> zyga, https://wiki.ubuntu.com/Snappy/Parts
<ogra_> sergiusens, if the beer at the bar gets boring in the evening ... bug 1500375
<ubottu> bug 1500375 in Snapcraft "inconsistent build results due to wrong usage of recommends" [Undecided,New] https://launchpad.net/bugs/1500375
<ogra_> ;)
<sergiusens> ogra_, oh, we used to do no recommends, I guess it got lost when we moved to our private apt cache
<ogra_> well, i dont care either way, only the consistency counts
<ogra_> (i gues without recommends is generally better for this use case though)
<ogra_> apw, hmm, is rtg on vacation too (i know ppisati is)
<T-mon> hello everybody! Since the last update my sideload snappy packages get some kind of uuid as version
<T-mon> is there a possiblilty to keep the snap version?
<ogra_> nope
<T-mon> I see the pros/cons of that concept...but it would be helpfull if this could be configurable :)
<ogra_> T-mon, there sill be a "current" link in the /apps/<package>/<version> dir
<ogra_> err
<ogra_> in the ~/apps/<package>/<version> dir
<ogra_> regenerating the version at install time is necessary because you can keep the same version when generating a sideload snap ... installing the same version again wouldnt update the confinement profiles
<T-mon> ogra_: yes, but my confs are gone with each new upload and I have to figur out the name of the sevice bfore i can follow the service log
<ogra_> the UUID enforces that
<T-mon> yes :) that is one of the benefits
<T-mon> it makes the development harder...and easier, depending on what you are doing
<ogra_> well, it makes sure security cant be broken ...
<ogra_> which was the case before
<T-mon> is this only for sideloads or also for store versions?
<ogra_> only sideloads
<ogra_> in the store you can upload the same version twice
<T-mon> so i loose the configs in every new version?
<T-mon> if I use /var/lib/apps/...
<ogra_> why would you ?
<ogra_> existing configs get forward copied since forever on upgrades
<T-mon> I am using the SNAP_APP_DATA_PATH for configs
 * ogra_ too
<ogra_> never had issues with it
<T-mon> ok, have to check that again...
<T-mon> I always remove the old version before uploading the new one...maby I sould not do that? :D
<ogra_> ah, yeah, then snapp cant really forward copy anything
<ogra_> *snappy
 * T-mon testing
<T-mon> ok :) not removing did the trick :D
<T-mon> thx
<ogra_> :D
<tedg> sergiusens: Idea: What if we had a global debug flag that would install debug symbol packages and compile things with debug symbols.
<tedg> sergiusens: Or, I guess, we should have some way to pull the symbols out of a package to generate our own symbols packages.
<ogra_> tedg, uhm, that might make you end up with gigantic snaps
<tedg> ogra_: Sure, but for developer debugging, not for release.
<ogra_> well, we should be pretty clear about what it does
<tedg> But it would be interesting if you could strip all those symbols out as a whole and then interpret crashs with *all* the symbols.
 * ogra_ imaines someone packaging wget and using that flag ... and then ending up with a 50MB wget snap while he just wanted to debug a wrapper script for the deb wget
<apw> ogra_, i thought he was about
<ogra_> apw, yeah, i catched him on the internal channel
<tedg> ogra_: I think it shouldn't be a flag that is used lightly :-)
<tedg> And we shouldn't take them in the store.
<elopio> tedg: it sounds really useful for snapcraft run.
<ogra_> tedg, and we should have detailed documentation about it :)
<tedg> And a big warning: <blink>DEVELOPER MODE ENABLED, MAY CAUSE A BLACK HOLE, BE VERY CAREFUL</blink>
<ogra_> also <red></red> ... <blink> alone is rarely enough :)
<sergiusens> rickspencer3, install godd :-)
<rickspencer3> lol
<jdstrand> sergiusens: are you still around?
<jdstrand> sergiusens: I have a two quick questions on snapcraft and the review tools. I want to file a bug but not sure who is at fault
<sergiusens> jdstrand, I'm still here
<sergiusens> jdstrand, you can default to affecting both and we can later invalidate one or maybe none if both are wrong :-)
<jdstrand> let me get a paste
<jdstrand> right, but if it is in the review tools I wanted to fix it today
<ogra_> just file it against https://launchpad.net/~sergiusens and it will get fixed :)
<jdstrand> sergiusens: http://paste.ubuntu.com/12603461/
<jdstrand> sergiusens: in the past, we said that 'architectures' was deprecated and people should use 'architecture' now. snapcraft is using 'architectures'
<jdstrand> sergiusens: is that intentional? (ie, should I change the review tools?)
<jdstrand> sergiusens: the other is the external symlinks check (external symlinks are where an app has a symlink to something outside of its app dirs). are external symlinks something that is supposed to be allowed? I can say in the case of this snap, /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/security/cacerts would be a dangling symlink
<jdstrand> sergiusens: the security policy handles this fine, but the check is there to try to alert people to issues in their snap, since a symlink out to a minimal system like Ubuntu Core is likely dangling
<sergiusens> jdstrand, architectures is deprecated? I thought it was the other way around
<jdstrand> sergiusens: the tools enforce 'architecture' and have for a while
<sergiusens> hmm, Chipaca can you chime in?
<Chipaca> whu?
<Chipaca> sergiusens: context?
<sergiusens> Chipaca, architectures and not 'architecture'
<jdstrand> ./go-example-webserver/meta/package.yaml:architecture: [amd64, armhf]
<jdstrand> ./hello-dbus/package-dir-fwk/meta/package.yaml:architecture: [amd64, armhf, i386]
<jdstrand> ./hello-dbus/package-dir-app/meta/package.yaml:architecture: [amd64, armhf, i386]
<Chipaca> yech
<jdstrand> snappy-examples use 'architecture'
<jdstrand> snapcraft uses 'architectures'
<sergiusens> Chipaca, yech?
<Chipaca> sergiusens: ugly
<jdstrand> the review tools know about 'architecture' and complain on 'architectures'
<Chipaca> let me confirm it's the right way around at least :)
<sergiusens> jdstrand, yeah, the examples have this big problem of always lagging on change :-/
<Chipaca> no, that's backward
<Chipaca> "architecture" is the deprecated one
<ogra_> and the format seems different
<ogra_> architectures:
<Chipaca> 	DeprecatedArchitecture deprecarch `yaml:"architecture"`
<ogra_> - amd64
<Chipaca> 	Architectures          []string   `yaml:"architectures"`
<ogra_> thats what i have in snapcraft-built snaps
<Chipaca> and that is correct
<ogra_> (no brackets and a dash)
<sergiusens> jdstrand, what we do do, is have manifest.json write 'architecture' to not break the store, but in package.yaml, 'architectures' is preferred
<ogra_> (and also on a new line)
<jdstrand> is architectures still a list?
<jdstrand> sergiusens: ^
<jdstrand> ok, so I'll fix the tools for architectures
<sergiusens> jdstrand, architectures is a list and only a list (contrary to architecture which would be both a string and a list)
<jdstrand> sergiusens: can you comment on the symlinks issue?
<jdstrand> sergiusens: re list> ack, I'll fix
<jdstrand> sergiusens: but note, 'snapcraft' produced a snap with the architecture warning in the past, so if it is meant to be compliant with the store, it isn't
<jdstrand> s/past/paste/
<sergiusens> jdstrand, wait, what symlink issue?
<jdstrand> sergiusens: http://paste.ubuntu.com/12603461/
<sergiusens> jdstrand, that's a bug!
<sergiusens> :-)
<jdstrand> ok, so there is a review tools bug and a snapcraft bug
 * jdstrand files
<sergiusens> jdstrand, thanks
<jdstrand> sergiusens: note, these are going to block store uploads (which is why I'm fixing the review tools one today)
<sergiusens> jdstrand, I'll be fixing these fast
<sergiusens> jdstrand, if you have a part that generates this bug please put it in the bug and I'll fix
<jdstrand> sergiusens: just so we're clear, I'll fix the review tools
<jdstrand> sergiusens: for architectures
<fgimenez> elopio, some progress on https://bugs.launchpad.net/snappy/+bug/1498293
<ubottu> Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New]
<elopio> fgimenez: haven't looked at it yet.
<fgimenez> elopio, this is the patch i used to get the grubenv contents http://paste.ubuntu.com/12603681/
<elopio> fgimenez: I thought it was reproducible, but  as you said it seems random. I got two good and one bad today.
<jdstrand> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500505
<ubottu> Launchpad bug 1500505 in Snapcraft "snapcraft produces snaps with dangling external symlinks" [Undecided,New]
<elopio> it might be a real bug. I'll do more runs on the evening.
<fgimenez> elopio, ok, i'll catch up tomorrow, nice evening everyone
<vmayoral|pc> chipaca: ping
<Chipaca> vmayoral|pc: pong
<Chipaca> *just* :)
<vmayoral|pc> chipaca: do you know if there's a tool to make a snap inactive (disable it)?
<Chipaca> vmayoral|pc: no, but it's easy to do
<ogra_> vmayoral|pc, there is an "unpublich" button in the store page of each app
<ogra_> *unpublish
<Chipaca> well, easy-ish
<Chipaca> vmayoral|pc: what's your use case?
<Chipaca> vmayoral|pc: or, in clearer language, what're you trying to do?
<vmayoral|pc> chipaca: so we'll have snaps that are several MBs and we'd prefer not installing them every time
<vmayoral|pc> if the "disable" tool from webdm doesn't get rid of the packages then that works
<Chipaca> i'm not sure, but "disable" might mean turn off services, in that context
<Chipaca> vmayoral|pc: i'm not sure i understand the connection between "installing them every time" and not getting rid of the packages
<Chipaca> i'm missing something :-/
<vmayoral|pc> Chipaca: i'm probably not making it clear, sorry. Let me put it differently:
<vmayoral|pc> Imagine i've got two facial recognition algorithms abstracted as snaps the first one's size is 10 MB and the second one is 15 MB. I'd like to have both installed in my device and enable one or the other depending on the scenario (without access to the cloud) thereby i need them both installed but one disabled. Is this possible now?
<Chipaca> vmayoral|pc: it is possible.
<Chipaca> vmayoral|pc:
<Chipaca> mmm
<Chipaca> vmayoral|pc: well, that's a half-lie, actually :-/
<Chipaca> vmayoral|pc: all the bits are there to do this, but there isn't an easy way to bring it about
<Chipaca> so
<Chipaca> vmayoral|pc: could you file a bug requesting this feature?
<Chipaca> whoops
<vmayoral|pc> moving to a different room ,sorry
<vmayoral|pc> i'll do that
<Chipaca> vmayoral|pc: do these snaps require hardware access?
<vmayoral|pc> they might, for our intentions they will since our goal will be to embed different robot behaviors (with different peripherals) on each snap
<Chipaca> vmayoral|pc: so, there is a workaround
<Chipaca> sigh
<asac> biezpal: if its about the current link one, then yes, we decided to land this change asap
<ogra_> asac, well, from a stable POV asap would be in ~4 weeks
<ogra_> (or 6 ... or whenever we plan the next release)
<asac> yes
<asac> still asap
<asac> think 3
<asac> -4
<ogra_> yeps
<Chipaca> vmayoral|pc: you there?
<vmayoral|pc> Chipaca: back again
<Chipaca> vmayoral|pc: hi again :)
<Chipaca> vmayoral|pc: i was saying, there is a workaround
<Chipaca> vmayoral|pc: but it's a bit of a kludge
<Chipaca> vmayoral|pc: interested? :)
<vmayoral|pc> sure
<Chipaca> vmayoral|pc: you install the snap, and then fake-install the skeleton of an old version of the snap
<Chipaca> vmayoral|pc: and then 'sudo snappy set $snapname active=$skeletonversion'
<vmayoral|pc>  thanks. I'll give it a try.
<vmayoral|pc> It'll be great though to have this functionality implemented at some point. I'll file a bug as advised. Thanks!
<Chipaca> vmayoral|pc: yes, please; a feature request from a user carries more weight than if I just say "this'd be cool to have" :)
<asac> ogra_: do i need to select a size for udf still or does it create the most minimal one now so it resizes?
<beuno> Chipaca, also, here's here with us this week
<beuno> so he has... lets say, leverage
<Chipaca> beuno: hah!
<ogra_> asac, i think it still hardcodes 4GB by default ... thats a sergio question
<Chipaca> beuno: fwiw, if you discuss it at all, it's a very very easy one to implement unless a lot of things change :)
<Chipaca> beuno: POST {"action":"disable/enable"} to the package url (same place you already install/remove)
<Chipaca> or was that a PUT
<ogra_> asac, it would be nice to have Bug 1485306 fixed, then we could create an 1byte writable partition by default
 * beuno nods
<ubottu> bug 1485306 in Snappy "ubuntu-device-flash should not create data in writable partition" [High,Triaged] https://launchpad.net/bugs/1485306
<Chipaca> anyway, that's the idea
<ogra_> or 512byte rather ... i.e. 1block
<asac> ogra_: i am running udf for latest pi2
<asac> WARNING: this option should only be used to build azure images
<asac> is showing
<asac> bug?
<ogra_> yeah, UDF needs to suppress the warning for the rpi arch
<ogra_> or it should say "azure and rpi" or some such
<asac> ogra_: did you put the pi2 in a stable channel?
<asac> seems not?
<ogra_> asac, i had to
<ogra_> else u-d-f wouldnt work with system-image
<ogra_> (to produce a stable img)
<asac> ogra_: it doesnt work for me
<asac> stable just fails
<ogra_> sudo ubuntu-device-flash core --channel stable --oem pi2.canonical --enable-ssh --install webdm -o rpi-edge.img --device raspi2_armhf 15.04
<ogra_> asac,  thats how i built the image that was released
<ogra_> still hgave the command inn my history
<ogra_> well ... -o rpi-stable.img :)
<asac> ogra_: can i create a chroot on the pi2?
<ogra_> asac, why wouldnt you ? scp http://cdimage.ubuntu.com/ubuntu-core/daily/current/wily-core-armhf.tar.gz to it ... untar in a "wily-chroot" subdir in /home/ubuntu ... copy resolv.conf in place and chroot away
<ogra_> thats what i do here ...
<ogra_> asac, http://paste.ubuntu.com/12604190
<ogra_> works just fine here
<ogra_> ogra@anubis:~/datengrab/rpi/preloader/newstable/tmp$ ls -lh rpi-edge.img
<ogra_> -rw-r--r-- 1 ogra ogra 3,7G Sep 28 19:48 rpi-edge.img
<ogra_> ogra@anubis:~/datengrab/rpi/preloader/newstable/tmp$ dpkg -l |grep ubuntu-device-flash
<ogra_> ii  ubuntu-device-flash                                   0.31-0ubuntu1                                          amd64        Flash supported devices with Ubuntu
<ogra_> sergiusens, i assume asac poked you in person already ... can we suppress the azure warning when --device raspi2_armhf  is used ?
<ogra_> i.e. http://paste.ubuntu.com/12604190
<ogra_> would also be nice if the oem snap could be enabled to define the subarch so i dont need the --device option at all in udf
<sergiusens> ogra_, just create an azure oem snap and get rid of that device channel ;-)
<ogra_> sergiusens, i'm talking about rpi
<sergiusens> ogra_, oh, as soon as I thought I could get rid of device channels...
<ogra_> sergiusens, to have u-d-f pick the right subarch on system-image i need to use --device
<sergiusens> ogra_, you bring them back :-P
<ogra_> well
<ogra_> tell me a solution that allows a different device tarball without using a device channel :)
<ogra_> that no-device-channels idea only works if everyone uses the same device tarball ... which isnt possible with rpi
<asac> ogra_: the piglow does not glow out of box
<ogra_> asac, how would it ?
<ogra_> asac, and how would i even test it ... i dont have one :P
<asac> ogra_: it just worked for me
<asac> last time
<asac> on image 4
<ogra_> asac, install the piglow snap and call the right hw-assign bits for it
<asac> it uses i2c
<asac> right
<ogra_> then it shoudl work
<ogra_> though i had to enable more than i2c OOTB for rickspencer ... that might have regressed the I2C behavior
<ogra_> (we shouldnt enable anything beyond i2c by default, but rick insisted ...)
<asac> ogra_: hw-assign doesnt work
<asac> tells me invalid device
<ogra_> what device ?
<asac> all
<asac> ttySO
<asac> and i2c-1
<ogra_> should be /dev/i2c-1
<ogra_> what would ttySO be =
<ogra_> ?
<ogra_> i guess you mean ttyS0
<ogra_> asac, seriously, make sure ppisati and I get an orangematchbox, that the only way for him and me to make sure these bits work
<asac> it worked :)
<ogra_> :D
<asac> ricmms mistakes
<ogra_> so typical !
<ogra_> :P
<asac> so we have a npm/node plugin for snapcraft yet?
 * ogra_ doesnt know 
<ogra_> i have htop and wget snapcraft trees for unconfined snaps though :)
<ogra_> (and bip indeed ... but confined)
<asac> Processing triggers for systemd (225-1ubuntu4) ...
<asac> Failed to get D-Bus connection: No such file or directory
<asac> dpkg: error processing package systemd (--unpack): subprocess installed post-installation script returned error exit status 1
<asac> /bin/df: cannot read table of mounted file systems: No such file or directory
<asac> Errors were encountered while processing: systemd
<asac> E: Sub-process /usr/bin/dpkg returned an error code (1)
<asac> pitti: any idea what to do about that?
<asac> i am in an lxc/d container
<ogra_> asac, wow, one would mean you have a valid /dev, mounted /proc and /sys in that container
<ogra_> sounds like an issue with lxc actually
<asac> yeah its buggy wily in lxc
<ogra_> thats update-initramfs printing all these errors btw
<ogra_> (from the /bin/df on)
<ogra_> (at least i dont know about any other package calling df from postinst)
 * pixel_ ping facebook o_O
 * pixel_ he dead?
#snappy 2015-09-29
<Chipaca> elopio: you around?
<elopio> Chipaca: o/ here
<Chipaca> elopio: hiya
<Chipaca> elopio: http://pastebin.ubuntu.com/12607030/
<Chipaca> elopio: halp :)
<Chipaca> elopio: i don't even know what failed :-/
<elopio> Chipaca: we still have some work to do to improve that report. It doesn't tell you where it failed.
<Chipaca> exactly! :)
<elopio> you need to scroll back and search for a FAILED: message.
<Chipaca> elopio: and then it panics
<elopio> I'm willing to bet that it's this one: https://bugs.launchpad.net/snappy/+bug/1498293
<ubottu> Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New]
<Chipaca> FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd
<Chipaca> elopio: ^ is that it?
<elopio> um, no, damn it. I lost the bet.
<elopio> Chipaca: are you running that in a published branch?
<Chipaca> no, but i can publish it
<elopio> I've been running tests all day and that one hasn't failed.
<Chipaca> elopio: lp:~chipaca/snappy/current-data-dir
<elopio> Chipaca: publish it and I'll check if it's a real bug or something to fix on the test. It's late for you, right?
<elopio> Chipaca: also, you can run only that test: go run ./_integration-tests/main.go --snappy-from-branch --filter failoverSuite.TestZeroSizeInitrd
<elopio> something like that.
<Chipaca> yeh, i think i'm stopping here
<Chipaca> elopio: it failed again, and i'm off to bed
<Chipaca> elopio: it's entirely possible it's my branch that broke it; i haven't dug
<elopio> Chipaca: I'm running it. We had problems with that test last week. Not sure what's going on, but I'll find out.
<elopio> have a good night.
<Chipaca> k
<Chipaca> g'night :)
<Guest34947> hi everyone.. could you help me..? how to install ubuntu OS on Samsung Galaxy S3
<Guest34947> i'm a new to ubuntu, and remember that ubuntu have an OS for mobilephone... that's why i wan to try install it on my Galaxy S3.. btw last day i just service my Galaxy S3 (no Samsung service center cause no guarantee more for the device) and then one-chip/peripheral already change causes Galaxy previously sundently dead..
<Guest34947> hope somebody help me here... i really want to try have ubuntu and become a familiar with this beautiful OS
<Guest34947> o yey... btw the OS on my Galaxy S3 now already the default; "Factory Reser"
<Chipaca> elopio: no news about that test?
<elopio> Chipaca: I've run it like 20 times on it's own, like 5 times on the whole suite. It always passes here.
<elopio> I tried some in vivid, some in wily.
<Chipaca> elopio: with my branch?
<elopio> Chipaca: yes, of course.
<elopio> Chipaca: I looked at your changes and they have nothing to do with that test.
<elopio> Chipaca: where you found that FAIL: /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go:172: failoverSuite.TestZeroSizeInitrd
<elopio> you should have also an assertion error. Do you still have that trace around?
<Chipaca> elopio: i do
<Chipaca> a ver ...
<Chipaca> http://pastebin.ubuntu.com/12609009/
<elopio> ... 0 files matching /boot/grub/a/snappy-selftest-initrd*, 1 expected
<elopio> that's an error I supposedly fixed already.
<Chipaca> branch is up to date with trunk fwiw
<elopio> Chipaca: yes, the fix is in your branch too. I don't understand, but your branch looks good, everything passes here, so you can ignore it.
<Chipaca> elopio: it almost sounds like you could review https://code.launchpad.net/~chipaca/snappy/current-data-dir/+merge/272691 :)
<elopio> I might give you a branch tomorrow with some more prints to understand what's going on in your machine. It sucks that it's a kvm and it still behaves differently.
<Chipaca> open /home/john/canonical/snappy/src/launchpad.net/snappy/_integration-tests/tests/failover_zero_size_file_test.go: no such file or directory
<Chipaca> ^ what's that about?
<elopio> Chipaca: http://paste.ubuntu.com/12609025/
<Chipaca> ah well
<elopio> Chipaca: that one is https://bugs.launchpad.net/snappy/+bug/1468958
<ubottu> Launchpad bug 1468958 in Snappy "selftests print "no such file or directory" on error" [Low,Triaged]
<Chipaca> ah! got it
<elopio> Chipaca: and yes, let me review your branch...
<Chipaca> oh, i dunno if i'll let you... i'll have to think about it
<elopio> well, you better think fast. I have a long queue of people eager to get my approval.
<Chipaca> also, i should mod goctest to also work with the integration tests
<Chipaca> finding red is a lot easier than finding "FAIL"
<elopio> that would be nice.
<elopio> Chipaca: but you shouldn't need to search fail. At the end of the run, we are printing the subunit result.
<Chipaca> elopio: here it just panics
<elopio> there are two problems with that. One that I was dumb and made it print only if the test passes.
<Chipaca> elopio: which is almost, but not quite, entirely not the same
<elopio> the second that it happens only when you run it from ./runtests.
<elopio> we will integrate the _integration-tests/main.go with go-subunit, so everything will be super awesome :)
<elopio> of course, the goctest pretty print will be faster.
<zyga> ogra_: hey, while building a snappy image for rpi2 according to your instructions I've got
<zyga> WARNING: this option should only be used to build azure images
<clobrano> morning :)
<elopio> Chipaca: why do you create the symlink twice? once in line 120, and again in 128.
<elopio> oh, nevermind, they are different.
<Chipaca> elopio: one is the /apps/$APP/current symlink, the other is the /var/lib/apps/$APP/current symlink
<Chipaca> was there a bug for this?
 * Chipaca goes looking
<pitti> asac: df failing> hm, /proc missing or so? are you doing this in a chroot or so?
<dholbach> good morning
<elopio> Chipaca: +1.
<elopio> Chipaca: when you remove a snap that has an empty data dir, should the dir be removed?
<Chipaca> elopio: not necessarily, no
<Chipaca> elopio: data dirs are left alone, for now
<Chipaca> elopio: at some point we want garbage collection to remove the n+1th
<elopio> ok, just wondering.
<elopio> I'm going to bed now. See you soon.
<Chipaca> elopio: take care, que descances
<Chipaca> it's not yet 9am and i've already done a carnaugh map
<Chipaca> today is going to be interesting
<guest42315> it's 10:51am :P
<guest42315> you are -3 h, portugal?
<Chipaca> I'm -1, you're +1 :)
<Chipaca> or something
 * Chipaca checks
<guest42315> :D
<Chipaca> yeh, I'm +1
<Chipaca> so you'r +3
<guest42315> right
<Chipaca> vmayoral|pc: got enable/disable working in branch locally. Need to add tests :)
<Chipaca> but first, coffee
<Chipaca> vmayoral|pc: turns out it's going to be very easy to also add it to the snappy command right now, so i'll probably do that as well
 * Chipaca ~> coffee
<JamesTait> Good morning all; happy Tuesday, and happy World Heart Day! ð  <3
<vmayoral|pc> Chipaca: that's great, thanks
<Chipaca> JamesTait: u+1f491 through u+uf49f
<JamesTait> Chipaca, â¤
<Chipaca> JamesTait: that's ctrl+shift+u, the hex code, space-or-enter
<Chipaca> and the second one should've read u+1f49f, not u+u...
 * Chipaca goes back to his coffee
<vmayoral|pc> ogra_: ping
<zyga> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1500759
<ubottu> Launchpad bug 1500759 in Snapcraft "Add support for overriding the Makefile location in makefile part type" [Undecided,New]
<longsleep> Is there some documentation how the u-boot scripting should look like and how the partitions are named? Seems like my old stuff does use root=/dev/disk/by-label/system-a which does not seem to work anymore
<asac> pitti: doing it in lxc container
<asac> pitti: mtab wasnt created and also the /run/resolvconf link didnt have an existing target
<asac> Chipaca: did we land the current link for APP_DATA_PATH yet by any chance? would mvo do that?
<Chipaca> asac: branch is on trunk as of a couple of hours ago
<asac> neat
<Chipaca> asac: but i don't think it's released anywhere
<asac> Chipaca: waiting for review and then landing it on devel and 15.04?
<Chipaca> asac: *on trunk*
<asac> oh review is done already
<asac> yeah
<asac> so just landing...
<Chipaca> :)
<Chipaca> asac: what's "landing" in this context?
<Chipaca> asac: also note it does _not_ keep a symlink in the SNAP_APP_USER_DATA_PATH, just in SNAP_APP_DATA_PATH
<Chipaca> ... we don't currently create SNAP_APP_USER_DATA_PATH ourselves, so it's all up to the app
<longsleep> ah my u-boot was broken, root=/dev/disk/by-label/system-a still works fine after all
<ogra_> hey vmayoral|pc
<vmayoral|pc> ogra_: morning
<vmayoral|pc> ogra_: what do you think about https://bugs.launchpad.net/snappy/+bug/1500755?
<ubottu> Launchpad bug 1500755 in Snappy "vchiq not working on 4.2" [Undecided,New]
<ogra_> vmayoral, see the bug :)
<ogra_> (will milestone it for 15.04.5 as soon as someone created the milestone)
 * Chipaca grovels for reviews of https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716
<vmayoral> ogra_: do you have any ideas for a quick fix that unblocks ourselves?
<ogra_> you could re-build your own pi2 snap
<ogra_> http://people.canonical.com/~platform/snappy/raspberrypi2/pi2_0.16_all.snap
<ogra_> (there is "Rebuilding the oem snap" in the RPi2 section on https://developer.ubuntu.com/en/snappy/start/)
<ogra_> make sure to keep the dtb's in place, they come from the kernel build (including overlay.tgz)
<pitti> asac: /etc/mtab should be a symlink to /proc/mounts
<ogra_> it is :)
<davidcalle> ogra_, hey, in the raspi2 doc email, are you talking about future install instructions or is it for the image you just released?
<ogra_> davidcalle, thats for current ... and i think i updated the doc accordingly
<ogra_> current stable is in the /~platform location ... dail/edge doesnt get actual img builds (like all other arches)
<ogra_> *daily
<davidcalle> ogra_, thanks!
<vmayoral> ogra_: got the oem snap and ready to rebuild it, just don't quite understand what are the things that i need to change
<vmayoral> ogra_: i guess i need to compile http://kernel.ubuntu.com/git/ubuntu/ubuntu-vivid.git/ and replace dtbs and overlay.tgz?
<vmayoral> ogra_: master branch seems to be at 3.19, shouldn't it be 4.2 since last snappy image uses that kernel?
<ogra_> why would you recompile the kernel
<vmayoral> ogra_: is it just a matter of regenerating the pi2 snap?
<ogra_> vmayoral, you want all of https://github.com/raspberrypi/firmware/tree/master/boot except for the dtb files and the overlay dir, they should be kept in place
<vmayoral> all right, any shortcut to replace the pi2 snap on an existing image or should i create a new snappy image?
<ogra_> create a new one and make sure to use --developer-mode, else u-d-f will refuse to use local oem snaps
<Chipaca> beuno: happy birthday!
<ogra_> vmayoral, oh, i'm silly, you can do it without a snap by just replacing the files /boot/uboot/ if you want to test it
<vmayoral> ogra_: will try that out, thanks
<ogra_> (essentially the start* fixup* and bootcode.bin files)
<zyga> sergiusens: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720
<sergiusens> elopio, fgimenez hey, can you check if something is wrong with tarmac?
<sergiusens> seems stuck; and I am missing an MP
<fgimenez> sergiusens, sure, i'll take a look
<sergiusens> fgimenez, ah, nevermind
<sergiusens> fgimenez, I was just confused
<fgimenez> sergiusens, ok np :) seems to be working fine http://paste.ubuntu.com/12610492/
<sergiusens> fgimenez, oh, we need to update tarmac with the latest plainbox
<sergiusens> Chipaca, good morning; mind reviewing something? https://code.launchpad.net/~sergiusens/snapcraft/1500758/+merge/272728
<Chipaca> sergiusens: trade you?
<sergiusens> Chipaca, sure
<fgimenez> sergiusens, done, now it has plainbox 0.23+ppa~ubuntu14.04.1 installed
<sergiusens> fgimenez, great, thanks
<sergiusens> fgimenez, also, zyga is here and willing to share all the setup for using git and merging/testing
<sergiusens> fgimenez, not sure how to coordinate that, but it would be nice to have this :-)
<sergiusens> Chipaca, just note that my MP says 'simple' ;-)
<Chipaca> sergiusens: you get to choose!
<fgimenez> sergiusens, indeed :) let me know if we can do anything from our side
<Chipaca> sergiusens: simple: https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430
<Chipaca> sergiusens: short: https://code.launchpad.net/~chipaca/snappy/activate-package/+merge/272716
<Chipaca> :)
<Chipaca> sergiusens: LGTM, with a question :)
<sergiusens> Chipaca, approved dirs with a suggestion :-)
<Chipaca> sergiusens: it already is snappy/dirs
<Chipaca> as in launchpad.net/snappy/dirs
<Chipaca> launchpad.net/snappy/snappy just feels wrong already :)
<sergiusens> Chipaca, oh, :-)
<sergiusens> Chipaca, I guess it is fine, we just need to move launchpad.net/snappy/snappy/*.go to lanuchpad.net/snappy :-D
<Chipaca> sergiusens: ... sooon ... :)
<sergiusens> or use vendoring ;-)
<sergiusens> Chipaca, ok, so I wait for you to approve my MP now ;-)
<Chipaca> d'oh :)
<Chipaca> sergiusens: where does vendoring come into the equation there?
<sergiusens> Chipaca, nice filepaths and GOPATH goodies
<ricmm> vmayoral: https://launchpad.net/ubuntu/+source/linux-raspi2
<ricmm> vmayoral: here too http://kernel.ubuntu.com/git/ubuntu/ubuntu-wily.git/log/?h=raspi2
<vmayoral> ricmm: got it
<clobrano> Finally got time to finish work on Bug #1496319. One question: is <snapname>.json.additional file content fixed for any reason? I mean, could I add a new field to it?
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
 * clobrano thinks it should have used the QUESTION tag
<clobrano> QUESTION: Finally got time to finish work on Bug #1496319. One question: is <snapname>.json.additional file content fixed for any reason? I mean, could I add a new field to it?
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<sergiusens> clobrano, using QUESTION is only a thing when some live broadcast is happening
<sergiusens> if not it generally is, fire and wait or get the right person
<sergiusens> ;-)
<clobrano> sergiusens: I wasn't sure :), thanks
<sergiusens> so... Chipaca maybe? ^
<Chipaca> what's the question again?
<clobrano> Chipaca: hi :), I was thinking about adding a new field to <snapname>.json.additional file
<clobrano> trying to implement Bug #1496319
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<Chipaca> please don't implement bugs! :-p
 * Chipaca reads
<clobrano> Chipaca: I expected that :D
<Chipaca> clobrano: let me check wrt reworking of hw-assign
<Chipaca> clobrano: right! so there will be a redesign, but not for a while, so let's do this :)
<Chipaca> clobrano: what is it you propose to fix that?
<clobrano> Chipaca: I'm thinking about adding a symlink_path field, to keep information about which path links to which HW device
<clobrano> Chipaca: this way, when using hw-unassign on a hw device, I can see that there is also a symlink to unassign
<Chipaca> clobrano: now i understand your question and everything!
<Chipaca> clobrano: no issues with adding an additional field to the .additional json
<clobrano> Chipaca: yep, I took a long way to explain it :D
<clobrano> Chipaca: fine then
<clobrano> Chipaca: thanks
<zyga> fgimenez: https://code.launchpad.net/~zyga/snapcraft/plainbox-app/+merge/272720
<zyga> fgimenez: not entirely done (but it's safe to land if it doesn't blow up as it's not the default)
<zyga> fgimenez: I'll go and do unit tests next
<zyga> fgimenez: but I need to patch something first around in another project
<zyga> fgimenez: the idea behind hat branch is to get rid of the shell script that does unholy things with plainbox and just use proper APIs
<fgimenez> zyga, yes we need that :)
<zyga> fgimenez: (the apis in plainbox are not in plainbox.public yet but they will be soon and the ones used here are the candidate APIs anyway)
<zyga> fgimenez: please have a look at the UX there
<zyga> fgimenez: I tried to make it better than the old script
<fgimenez> zyga, ok thanks i'll ping you back
<zyga> fgimenez: after you look at the basics I'd like to discuss how to integrate unit tests -- there are two ideas I have
<zyga> fgimenez: thanks :)
 * guest42315 ubuntuonair in 20 min http://ubuntuonair.com/
<longsleep> Chipaca: Hey, i just got forwared a mail that christine seem to have added us to the contributor agreement, while i am still not seeing it in the members list i now wonder how you folks know that i am contributing for this company
 * zyga stands up
<Chipaca> longsleep: that's yet another good question I don't know the answer to.
<Chipaca> longsleep: maybe because the one that filled out the cla for the company tells us somehow?
 * Chipaca is asking elsewhere as well :)
<vmayoral> sergiusens:  http://paste.ubuntu.com/12613213/
<longsleep> Chipaca: well, at least the confirmation mail did not say anything helpful in that regard.
<Chipaca> longsleep: turns out, there wasn't a process
<longsleep> :D
<Chipaca> longsleep: so, the person that signed the cla on behalf of the company
<Chipaca> longsleep: needs to create a group
<Chipaca> longsleep: and let us know what group that is
<longsleep> aha - can it be a existing group?
<Chipaca> longsleep: and then we add that group to the CLA group
<longsleep> and how do we let you know
<ogra_> well, and it should be a controlled group ... not one everyone can join ;)
<Chipaca> longsleep: sure, as long as membership in that group implies they can submit code in the company's name
<longsleep> group is strukturag - already is there
<longsleep> yes
<longsleep> ok, but the one who has submitted is not in that group yet
<longsleep> oh my let me fix that
<longsleep> Chipaca: ok, so how can we let you know that it is this group?
<Chipaca> longsleep: you should've received an invite
<Chipaca> longsleep: (in future we might ask that the person signing is owner of the group; for now, this'll do)
<sergiusens> zyga, https://code.launchpad.net/~sergiusens/snapcraft/scons_options/+merge/272817
<vmayoral> sergiusens:  https://gist.github.com/vmayoral/0ddc3b9c50198cb182a4
<longsleep> Chipaca: ok great, worked perfectly - thank you !
<rickspencer3> ogra_ hey
<ogra_> yo
<rickspencer3> soooo, pwm, we  followed your instructions to enable it, but, errr
<rickspencer3> not sure it is working
 * rickspencer3 gets a pastebin
<ogra_> cat /sys/firmware/devicetree/base/soc/pwm@7e20c000/status
<ogra_> if that says "okay" it is enabled
<rickspencer3> http://pastebin.ubuntu.com/12615323/
 * rickspencer3 looks
<rickspencer3> it says "okay"
<ogra_> well, then it should work ...
<ogra_> there is another pwm overlay (twochannel) you could tyr editing config.txt and use that instead of the basic one from ym instructions
<ogra_> pwm-2chan-overlay.dtb
<ogra_> perhaps  that behaves differently
<ogra_> https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README#L419
<ogra_> so you can obviously use: dtoverlay=pwm,pin=18
 * ogra_ tries 
<ogra_> rickspencer3, the export node is a toggle ... only takes 0/1
<ogra_> rickspencer3, if i echo 1 into it i see a /sys/class/pwm/pwmchip0/pwm1 being created
 * ogra_ doesnt have the slightest clue what he is doing
<rickspencer3> ogra_ ok, we'll keep banging on it here and see where we get
<ogra_> root@localhost:~# ls /sys/class/pwm/pwmchip0/pwm1/
<ogra_> duty_cycle  enable  period  polarity  power  uevent
<ogra_> does that look like what you want ?
<ogra_> looking at online docs it seems the interface has changed with 4.2 ... seems in older versions there were nodes like "frequency" as well
 * ogra_ assumes thats replaced by "period" 
<sergiusens> elopio, mind looking at scons again?
<elopio> sergiusens: sure.
<sergiusens> elopio, I even added the missing test I forgot the first time around :-/
<elopio> sergiusens: excuses :p
<sergiusens> elopio, I blame zyga
<sergiusens> elopio, thanks
<elopio> np
<sergiusens> elopio, btw, did you see zyga's branch?
<elopio> sergiusens: por encimita.
<sergiusens> elopio, it is good because we can autocomplete and select tests specifically or with a filter
<elopio> ah, that's cool.
<elopio> he says it doesn't yet support the unittests. But that's ok, we only need to clean up the weird script we use to launch the plainbox tests.
<elopio> I'll give it a try after lunch.
<victorp> kyrofa, ping
<kyrofa> Hey victorp :)
<victorp> hi kyrofa
<sergiusens> zyga, lp:~sergiusens/snapcraft/1501035
<victorp> I am just playing with the rpi and installed your piglowtop snap
<victorp> \o/
<victorp> v awesome
<victorp> I was wondering if you had a bzr branch for it, that I can use as an example to learn a bit more about snappy
<kyrofa> victorp, not bzr, but git
<kyrofa> victorp: https://github.com/kyrofa/piglowtop
<victorp> kyrofa, :P
<kyrofa> victorp, there are two READMEs-- the main one is for the software itself, and the snappy-specific one is in meta/
<victorp> kyrofa, awesome!
<victorp> thanks
<kyrofa> victorp, any time!
<zyga> sergiusens: it doesn't work
<sergiusens> zyga, because of python3?
<zyga> sergiusens: py3versions
<zyga> http://pastebin.ubuntu.com/12617891/
<sergiusens> zyga, yeah, skip those on wily, it depends on the MP you reviewed earlier
<zyga> sergiusens: py3versions itself crashes
<zyga> sergiusens: I think it's different
<sergiusens> ah
<zyga> sergiusens: it crashes because py3versions is a dh-thing
<zyga> sergiusens: and I suspsecy you don't have that in the stage python
<zyga> sergiusens: (python3-minimal) hmm
<sergiusens> zyga, snappy shell and try it maybe
<zyga> I wonder what is error 2
<zyga> oh!
<zyga> cool
<zyga> snappy shell -- no such command?
<sergiusens> snapcraft shell
<sergiusens> sorry
<sergiusens> zyga, ^
<zyga> ah
<zyga> sergiusens: that doesn't work
<zyga> (venv.x200t)zyga@x200t:/tmp/1501035/integration-tests/data/pip-requirements$ snapcraft shell
<zyga> py3versions -i
<zyga> pyversions -i
<zyga> it needs py3versions itself :)
<zyga> /tmp/tmpgzjdflwl: 7: export: python3.5/dist-packages: bad variable name
<sergiusens> oh, python 3.5
<sergiusens> darn wily
<plars> "write /tmp/diskimage045123107/boot/a/dtbs/r8a7791-henninger.dtb: no space left on device"
<plars> I get this when trying to create the raspberry pi image
<plars> ah, nm, I didn't specify the device
<ogra_> how do you create it ?
<ogra_> phew
<plars> ogra_: I got it now, but what really surprised me is that udf didn't exit with a non-zero rc
 * ogra_ feels like he had enough disasters tonight :P dont shock me 
<plars> haha, sorry :)
<ogra_> :)
<ogra_> plars, well, if you dont specify --device it simply tries the generic tarball on top
<ogra_> its not an error so it doesnt exit nonzero
<ogra_> (the space issu is indeed)
<ogra_> (and probably worth filing a bug)
<plars> ogra_: I'd like to chat (not urgent, sometime when you're having a better day), about rpi2 automation
<ogra_> yeah
<plars> ogra_: it mostly works right now, but I wasn't able to handle reading the environment from the actual image partition that I'm testing
<plars> ogra_: so it won't cope well if we try to test upgrade/rollback
<ogra_> you mean uboot.env ?
<plars> ogra_: mostly just trying to work around the fact that rpi2 can only boot from one place
<plars> ogra_: yeah, I'm booting an ubuntu image off the SD card, with a lot of uboot bits from snappy. It reads a gpio to decide whether to keep booting from the sd card, or pull the kernel/initrd from usb (where I wrote the new image) and simulate the snappy boot process from the bits that are on usb
<plars> ogra_: so obviously there's a big downside that we don't actually test the bootloader from the new image, but given that we can't chainload and only have a single boot location, I don't see any way around that
<ogra_> yeah
<ogra_> well ... the rpi has config.txt ....
<ogra_> you could mangle the kernel=uboot.bin line
<plars> ogra_: but the other issue is that if we do an update/rollback, those settings get written to uboot.env on the usb stick, and I don't know of a good way to selectively read in just the values I care about from there
<plars> ogra_: but how do I get it back if things go wrong?
<plars> ogra_: I need to know that it will fall back to the right place no matter what
<ogra_> so you would still use the pre-loader from SD but could point to a different uboot
<plars> ogra_: but I don't think I could point it to the one on usb, it would still have to be on the sd card somehow
<plars> which I can't safely overwrite
<ogra_> yeah
<ogra_> you would need both uboots on the SD and duplicate the uboot config
<plars> there may not be any good options, but I figured if anyone would have ideas, it would probably be you :)
<ogra_> heh
<plars> ogra_: if anything comes to mind, just let me know what your thoughts are
<ogra_> well, i think what yu do is the sanest you can do ...
<plars> wow, did I just get accused of being sane?
<ogra_> you can indeed edit uboot.env from anywhere using fw_setenv ...
<plars> I guess I'm making progress
<plars> :)
<ogra_> hahaha
<plars> ogra_: it works pretty reliably for most things, just a few limitations that are annoying
<ogra_> what you need for fw_setenv is the right config ... we ship that in /etc/fw_env.config ...
<plars> ogra_: there's some strange magic there
<plars> ogra_: which entries end up getting modified when you do an update?
<ogra_> snappy_ab and snappy_trial_boot
<ogra_> err nnno
<ogra_> snappy_ab and snappy_mode
<plars> ogra_: yeah, if that's all, then I could possibly let it just modify the one on the sd card, but I'd have to remount after booting, and I've kind of lost control at that point (nor do I want it updating the kernel for me or any other files at that location)
<ogra_> well, the kernel will always only be updated on the other partition
<ogra_> or in case of uboot the "other dir"
<plars> ogra_: but it's still under /boot/uboot/{a,b}
<plars> ogra_: if I simply remount /boot/uboot after booting and force it to point to the mmc, then I really haven't accomplished anything
<plars> in fact, I could be causing more problems, since it won't persist after the reboot
<ogra_> if i'm booted into the system-a partition the kernel from /boot/uboot/a is used as well ... the update switches snappy_ab=b and snappy_mode=try ... then it reboots into system-b ... systemd sets snappy_mode=regular at the end of the boot process and you are fine ...
<plars> I don't have control after provisioning happens, from that point forward it's completely up to the test to do the right thing (which will come from somewhere else)
<ogra_> ... or you fail and snappy_mode is still set to try ... so the script recognizes it should switch back to a and does that
<zyga> ogra_: you're still up?
<plars> no, he should be sleeping, and I should quit bothering him :)
<ogra_> zyga, i rarely go to bed before 2am ... worse is that i'm still working :P
<plars> :(
<zyga> ogra_: well, what can I say
<ogra_> not your fault
<zyga> me too
<zyga> guys are having beer next to me though
<zyga> nope, though that's not bothering me :)
<ogra_> it is one of these days where you recognize "oh, i forgot to seed that minor package, lets quickly do that and finishe the day" ... you seed it and the world explodes in your face :P
<ogra_> and now i'm still mopping up the mess
<zyga> ogra_: what did you seed?
<zyga> ogra_: bootchart?
<ogra_> fwupd ...
<ogra_> zyga, and this is what changed in the image .... http://paste.ubuntu.com/12617877/
<ogra_> rather unexpected
 * zyga looks
<zyga> useless laggy hotel wifi
<zyga_> ogra2: considering that upstream does glib+gtk apps that's not unexpected, why did it explode?
<zyga_> ohh
<zyga_> libGDK is there too
<zyga_> that's curious ;0
<zyga_> ogra2: it's 2015, daemons come with guis ;)
<ogra_> zyga_, well, not sure you wnat your drone to be capable of convertingjpeg to tiff and provide the ic via XDMCP
<zyga_> ogra_: heheh
<ogra_> *provide the pic
<ogra_> but at least you could store all the info about that in dconf then :P
<zyga_> ogra_: dconf I understand but x11
<zyga_> ogra_: how did that package get through review?
<ogra_> it didnt yet
<ogra_> comes from our PPA
<zyga_> ogra_: ohhh
<ogra_> this is vivid
<zyga_> ogra_: yeah, that's trustworthy and safe ;)
<zyga_> ogra_: is that your ppa or 3rd party?
<ogra_> the official snappy ppa
 * zyga_ should stop bothering ogra and just let everyone go to bed
<zyga_> ogra_: O_o
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<plars> sleep ftw!
<ogra_> heh
<plars> oh, still a bit early here I guess :)
 * ogra_ still needs to revert the mess and build a test image 
<zyga_> ogra_: good luck
<ogra_> :)
<ogra_> well, its mostly waiting
#snappy 2015-09-30
<tgm4883> Are snappy apps able to play audio?
<fgimenez> good morning
<davidcalle> Morning o/
<dholbach> good morning
<zyga> yashi_: hey
<zyga> yashi_: how are you, do you have a moment to talk about https://code.launchpad.net/~yashi/snapcraft/snapcraft/+merge/272337
<sergiusens> vmayoral|pc, lp:~sergiusens/snapcraft/catkin
<sergiusens> vmayoral|pc, I'm still stabilizing it though
<vmayoral|pc> sergiusens: awesome, thanks
<JamesTait> Good morning all; happy Wednesday, and happy International Translation Day! ð
<ogra_> Guten Morgen; einen schÃ¶nen Mittwoch, und einen schÃ¶nen Tag der Internationalen Ãbersetzung! ð
<ogra_> JamesTait, appropriate ?
<JamesTait> ogra_, ja, sicher!
<ogra_> :)
<JamesTait> I never quite grasped German (I struggled with ein, einer, einem and all that), but my son is learning it at school now, so I'm having another go. ð
<ogra_> good luck :)
<JamesTait> Danke. ð
<lool> sergiusens: are build-packages from yaml inherited across plugins?
<lool> sergiusens: it seems not
<lool> sergiusens: so if I'm extending python3-project, and python3-project said build-packages: python3-pip, my plugin wont pull pip
<lool> I need to repeat build-packages
<sergiusens> lool, no
<sergiusens> lool, that requires the refactor
<lool> sergiusens: do you agree python3-project should install pip3?
<sergiusens> lool, yes
<sergiusens> lool, oh, don't install the ubuntu pip, it won't work
<vmayoral|pc> ricmm: https://github.com/gnab/rtl8812au
<ricmm> vmayoral|pc: thx
<longsleep> ogra_: either you or my IRC client has a problem with Umlauts. Test ÃÃâÃÃÂ¤ÃÂ¶ÃÂ¼ÃÂ¤
<longsleep> ah - my client :)
<ogra_> yeah, utf8 :)
 * longsleep wonders how that is possible in UTF-8 land
<ogra_> what client ?
<longsleep> somebody screwed up my console setup on this host
<longsleep> irssi
<ogra_> ah
<ogra_> xchat here
<longsleep> mhm must be irssi, in the console it works just fine
<longsleep> funny, looks like i did not use german in IRC since a very long time
 * ogra_ finds it really hard to switch his brain to erman on IRC ... 
<longsleep> lol, the command-not-found helper has unicode issues
<ogra_> *german
<longsleep> File "/usr/lib/python3/dist-packages/CommandNotFound/CommandNotFound.py", line 41, in lookup key = key.encode('utf-8')
<longsleep> UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' in position 5: surrogates not allowed
<tbr> longsleep: IIRC zyga's statement was "send patches if you want it fixed"
<longsleep> :D
 * tbr CBA to look for the g+ post
<longsleep> ogra_: Is there somewhere a description what the difference is between developer mode and no developer mode when building a image with u-d-f?
<ogra_> user visible is that your ssh key gets copied into /home/ubuntu ...
<ogra_> beyond that it allows you to provide a lical oem snap ... i think thats all
<longsleep> ok, nothing else?
<ogra_> *local
<longsleep> yeah - i want to release an image without development mode - it just seems to work fine so i was wondering if there are other differences
<ogra_> not sure, i think a local device tarball can be used without it, i'd have to test
<longsleep> yes i already tested that
<longsleep> device tarball can be used
<longsleep> and the image boots fine when loading the oem from store
<vmayoral|pc> ricmm: recompiling the kernel succeeded this time
<ricmm> vmayoral|pc: ah, perfect
<vmayoral|pc> ricmm: driver works now, all good
<ricmm> excellent
<ogra_> ricmm, did you guys get anywhere with the changing MAC address ?
<ricmm> ogra_: mac is fine
<ogra_> ricmm, could you ask vmayoral to close the bug then ?
<longsleep> I always wanted to ask you folks, why Snappy uses a FAT partition to store the boot files. Is there any particular reason i should be aware of?
<mvo_> longsleep: ogra or ogra_ probably knows better, my understanding is that we need it because its what uboot supports best to store the uboot environment on a filesystem
<ogra_> not really, i didnt make the decision for FAT
<ogra_> i think the BBB requires it to find the SPL
<ogra_> beyond that i personally would rather have gone with some extX
<ogra_> but the decision pre-dates my snappy involvement
<tbr> you can also put the MLO at a fixed offset
<ogra_> in RAW space, yeah ...
<ogra_> but that would mean to special case ... or to have all boards set up like that
<Maxxi> why is there no .iso for ubuntu snappy?
<tbr> depending on how you partition things
<Maxxi> i want to install it on my vmplayer
<ogra_> theer are plenty of VM images ... not sure there is one for vmplayer though
<tbr> could qemu-img help here? :)
<ogra_> (KVM, qemu, vagrant, virtualbox and i think lso vmware itself should eb available)
<ogra_> and yes, you might be able to convert one
<longsleep> mvo_, ogra_ thanks for the details, i might consider building a snappy based image without fat - uboot has plenty of ways to store the env / might not even use a boot partition at all
<longsleep> (i am doing this for normal ubuntu already)
<ogra_> longsleep, well,, you would have to patch ubuntu-device-flash ... after all it creates the partitions
<ogra_> and you would have to patch snappy too, since it changes the vars after boot
<ogra_> to notify about a successful update/rollback
<longsleep> ogra_: yeah sure, i am aware of this - but i would have to do this anyways to support own infrastructure for os and snap sources
<longsleep> ogra_: we are not quite there yet, but we will need this for corporate environments
<ogra_> k
<clobrano> tbr: this might help http://ubuntuforums.org/showthread.php?t=2260169
<tbr> clobrano: I don't have that problem and frankly IDGAF. I suggest you reread scrollback.
<clobrano> tbr: LOL sorry, misread nicknames
<elopio> Chipaca: we need help here: https://bugs.launchpad.net/snappy/+bug/1498293
<elopio> any idea what could cause a successful boot to leave snappy_mode=try and snappy_trial_boot=1 ?
<ubottu> Launchpad bug 1498293 in Snappy "fake rollback integration test fails" [Undecided,New]
<Chipaca> elopio: systemd fubar'ed?
<Chipaca> elopio: sudo jouralctl -x, look for things (usually in red) about cycles
<elopio> checking...
<peacememories> huh... seems ubuntu-device-flash doesn't like being run inside a docker container
<peacememories> kernel mismatch
<Chipaca> elopio: in any case, search for ubuntu-snappy.boot-ok.service
<Chipaca> elopio: (or boot-ok for short :) )
<Chipaca> elopio: it's possible also that you're running your test too early, before boot-ok ran
<elopio> Chipaca: I don't think that's it. When it fails, I can ssh and the grubenv is still wrong.
<Chipaca> elopio: ok. When it fails, ssh in, and inspect the journal
<elopio> Chipaca: you might actually be right, who would have thought...
<elopio> I added a wait for mode=regular, and the test passed.
<fgimenez> elopio, Chipaca that makes a lot of sense, i haven't been able to reproduce manually on kvm, only when the test runs
<Chipaca> elopio: i'm shocked
<elopio> Chipaca: so what would be the bug? you can't rollback before boot-ok has run?
<Chipaca> elopio: can you log in before boot-ok has run?
<Chipaca> that'd be a bug
<Chipaca> the tests running before boot-ok has run, that's a bug also
<elopio> Chipaca: I print the /boot/grub/grubenv as soon as I can ssh, and it shows mode=try.
<Chipaca> aha
<elopio> let me do more runs to confirm. This could have been a lucky execution.
<Chipaca> that might be a bug in our unit ordering, then
<elopio> fgimenez: you are leaving now, right?
<Chipaca> _might_ :)
<Chipaca> i'd be interested to know whether snapd is running as soon as you can log in
<fgimenez> elopio, yep, in a few minutes
<fgimenez> elopio, let me know if i can help you, i can stay a bit yet
<elopio> fgimenez: ok, nevermind. I'll do runs in my other machine to confirm.
<ricmm> Chipaca: what versio of snappy are you using to build?
<elopio> fgimenez: no no, please don't stay after your EOD.
<elopio> I will make two boot tests, one to check that mode is regular and one to check that snapd is running.
<Chipaca> launchpad.net/snappy    bzr     snappy_tarmac-20150925153317-7acittvlm7idwcwl   718
<Chipaca> ricmm: ^
<ricmm> thx
<fgimenez> elopio, i can put it to run, still 20min left, any special command?
<ricmm> Chipaca: yup thats what I had built with
<elopio> fgimenez: lp:~elopio/snappy/wait-boot-ok
<fgimenez> Chipaca, elopio from this log http://paste.ubuntu.com/12603352/ you can see in line 141 that snappy_trial_boot is 1 after calling snappy list and snappy rollback, not sure if it can be a timing issue
<elopio> fgimenez: after calling snappy rollback, it must be try
<elopio> before calling rollback, it must be "regular"
<fgimenez> elopio, snappy_mode yes, but not snappy_trial_boot
<ogra> snappy_trial_boot is only used internally
<ogra> dont touch it
<elopio> ah, right. That's what I think that happens when you call rollback before boot-ok. Things go crazy.
<elopio> but just a theory.
<fgimenez> elopio, yes, it seems that when it reboots it switches the partitions without rolling back http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/generic-amd64/grub.cfg#L24
<elopio> fgimenez: after 3 successful runs, I reverted the waits and got the same failure. Chipaca has won the QA smiley sticker today.
<ogra> elopio, well, you cant really call rollback before boot-ok in real life :)
<fgimenez> elopio, great! :) mine is stuck updating
<ogra> boot-ok runs way before the login service
<elopio> ogra: I think that's the bug we are hitting.
<ogra> make your unit wait for getty or the login bits then
<peacememories> if building a custom oem snap, can i use local snappy images or do i have to create a store?
<elopio> ogra: we are running this through ssh, and we are seeing snappy_mode=try.
<ogra> elopio, then ssh comes up earlier than boot.ok i'd guess
<fgimenez> elopio, finished without errors :)
<ogra> peacememories, you need to use --developer-mode in your ubuntu-device-flash command to build the image ...
<fgimenez> elopio, leaving, i'll catch up tomorrow
<elopio> fgimenez: bye, thank you.
<ogra> peacememories, beyond that there are no further restrictions
<peacememories> ogra, so if i use a file path in my oem-snap definition file it will use that when building it? (i haven't tried yet, just thought i'd ask beforehand)
<ogra> a file path ?
<ogra> you mean for something you ship inside the oem snap ?
<peacememories> yes, for preinstalled snaps
<peacememories> i can understand if that doesn't work. it goes a bit against the update philosophy i guess
<ogra> ah, i have never installed any local snaps ... i guess the --install option should work for that for a local build
<peacememories> hm, i don't relaly see how i would, for example, set the default username and password of a snappy install
<ogra> you cant
<ogra> (yet)
<peacememories> um
<peacememories> oh, i just noticed that with my own oem package i apparently also need to supply my own boot images?
<Chipaca> does the intel compute stick do sse?
<Chipaca> wait, not the compute stick, that's an atom
<Chipaca> what was the weird one, the edison?
<Chipaca> intel quark. on the galileo. no sse.
<tbr> also depending on the silicon you need to rebuild your whole userspace
#snappy 2015-10-01
<fgimenez> good morning
<davidcalle> Good morning o/
<clobrano> morning :)
<elopio> fgimenez: hello. I did this: https://github.com/elopio/go-subunit/pull/7
<elopio> which was a little hard and confusing for me. Could you please review it with extra care?
<fgimenez> elopio, hey, sure i'll take a look. now get some rest! :)
<elopio> yup, bed time \o/
<elopio> see you later.
<clobrano> Chipaca: if you have time, I'd like to hear your opinion about a change to hw-assign
<guest56723> is it possible to "install"  wily-preinstalled-desktop-next-amd64.tar.gz   on a spare partition?
<vmayoral|pc> sergiusens, ricmm: can you guys look at https://bugs.launchpad.net/snapcraft/+bug/1501651. We can't go that path to generate the snaps. Any ideas?
<ubottu> Launchpad bug 1501651 in Snapcraft "ARM chroot issues: fatal error: rt_sigaction failure" [Undecided,New]
<vmayoral|pc> we'll try getting snapcraft working in a native way on the RPi2 images but that seems a hack. Let us know if you come up with something else
<Chipaca> clobrano: i don't have time right now, but if you write it out i can read it when i do have time
<Chipaca> clobrano: OTOH this might be mailing-list fodder
<clobrano> Chipaca: sure, no problem
<sergiusens> vmayoral|pc, yeah, I thought you were using python and c
<sergiusens> vmayoral|pc, qemu arm static doesn't play well with go
<sergiusens> we should push ogra to fix it ;-)
<vmayoral|pc> sergiusens: i'm using python
<sergiusens> ah Chipaca already replied
<sergiusens> vmayoral|pc, oh, I see
<sergiusens> vmayoral|pc, so while you can't snapcraft all the way, you have reached the snap stage for everything
<sergiusens> vmayoral|pc, you can run 'snappy build' from your host targetting the ./snap dir, it should just work (TM)
<Chipaca> anything that tries to catch signal NSIG-1 breaks in qemu
<sergiusens> vmayoral|pc, we will be moving 'snappy build' to 'snapcraft' as we mentioned yesterday
<Chipaca> including, apparently, an unnamed threading implementation? dunno
 * vmayoral|pc trying out "snappy build"
<vmayoral|pc> sergiusens: similar result with "snappy build" https://gist.github.com/vmayoral/c248de02f8cc79c53548
 * Chipaca afk for a while
<Chipaca> vmayoral|pc: if it's just python, why are you building it in a qemu?
 * Chipaca leaves with that
<vmayoral|pc> Chipaca: trying to get a .snap for the demo
<vmayoral|pc> not sure, but, would i be able to intall a .snap generated in x86? (even if it's just python?
<vmayoral|pc> that's why
<sergiusens> vmayoral|pc, from OUTSIDE the chrrot I said ;-)
<sergiusens> Chipaca, he is using snapcraft; he needs to get the right python runtime!
<vmayoral|pc> sergiusens: that did it, thanks
<sergiusens> \o/
<sergiusens> :-)
<sergiusens> asac, http://paste.ubuntu.com/12630697/
<longsleep> vmayoral|pc: did you see my https://code.launchpad.net/~longsleep/snapcraft/snapcraft-debs-plugin - i use that to generate armhf snaps on x86_64 by using rebuilt debian packages - the branch is outdated now, but i will continue working on it soon
<dholbach> sergiusens, do we have a good example for a scons project we could add to snapcraft's source?
<sergiusens> dholbach, yeah, coming soon ;-) sabdfl is playing with it
<dholbach> cool!
<JamesTait> Good morning all; happy Thursday, and happy International Coffee Day! ð  ðµ
<sergiusens> tedg, are you up yet?
<zyga> ogra: hey
<zyga> ogra: how do you feel?
<zyga> ogra: I have a thing you could help me with
<zyga> ogra: let's say I have a raspberry pi
<zyga> ogra: and I'd like to build the image with my magic sauce inside
<zyga> ogra: I'd like to build a patched version of snappy itself (snapd)
<zyga> ogra: patched CLI
<zyga> ogra: some extra systemd units that start
<zyga> ogra: how would I go about this?
<zyga> ogra: I would really love to have a call with you and try to get to a point where I can make my own image (or iterate in some way)
<asac> mvo: https://sigquit.wordpress.com/2009/03/13/the-core-pattern/
<sergiusens> tedg, you around? can you get your catkin branch code polished for an MP?
<sergiusens> tedg, would be great to use os.walk instead of 'find' or shutil.rmtree and so on and so forth
<sergiusens> hmm, I'll create an MP and add comments
<sergiusens> tedg, code looks good
<sergiusens> asac, http://paste.ubuntu.com/12630697/
<tedg> sergiusens: Awake :-)
<tedg> sergiusens: Cool, I was waiting to see if you guys needed stuff from it.
<sergiusens> tedg, \o/
<sergiusens> tedg, I'll send an email :-)
 * tedg is glad to know he was missed :-)
<sergiusens> tedg, done, two emails
<tedg> Haha, on the Erle Spider: https://twitter.com/pierredewet/status/649549049780158465
<jdstrand> ogra2: hey, couple questions I have a feeling you might know the answer to: a) if I set a static ip address via snappy config ubuntu-core (easy enough), how do I setup the resolver? b) what is the recommended way to setup remote logging (ie, a snappy system sending to remote 514/udp)?
<DexterF> greetings
<DexterF> how "vanilla" is the Snappy Ubuntu 4.2 kernel? 4.2 has spanking new code for a certain DVB receiver I'd like to run on a Pi2, but will it be just like vanilla? are dev files like headers just like on x64, i.e., can I install build-essential and build fancy kernel modules against it like linuxtv?
<vmayoral|pc> sergiusens: we can use your help for the camera snap
<sergiusens> vmayoral|pc, is that also ros?
<vmayoral|pc> no, it's not
<sergiusens> vmayoral|pc, I'm down stairs
<sergiusens> vmayoral|pc, want to come
<sergiusens> ?
<vmayoral|pc> yeap, thanks
<tomconte> Hi everyone! Playing with snapcraft here and having strange Permission issues
<tomconte> I suspect some kind of AppArmor problem but not sure how to troubleshoot it
<elopio> plars: I need your help with the agent test script. Please ping me when you have time.
<plars> elopio: sure, what's up?
<elopio> plars: first, the deb that we are using needs to be updated daily to keep track of the changes in trunk.
<plars> elopio: which deb?
<elopio> could we somehow install it from the ppa? Or do you have an alternative way to make sure that we always get the daily deb?
<elopio> currently it is just a hardcoded link.
<elopio> plars: http://people.ubuntu.com/~elopio/spi_scripts/snappy-tests-job.sh
<elopio> https://code.launchpad.net/~snappy-dev/+archive/ubuntu/tools-proposed/+files/snappy-tests-job_1.0.0ubuntu1-0%7E64%2B201510010310%7Eubuntu15.10.1_amd64.deb
<plars> elopio: why died this need to be a deb? This would potentially destabilize the host for that test device
<plars> elopio: couldn't this be an artifact that gets downloaded and runs binaries from a local extracted path?
<elopio> plars: the alternative was to set up the GOPATH in the agent and get it from trunk. But you didn't like it that way, so we went for the deb.
<elopio> plars: it is an artifact that gets downloaded and runs binaries. The problem is that the artifact changes the path every day.
<plars> elopio: I installed all the go dependencies you asked for so that you could do that, remember?
<elopio> yes, but then you told me to downlod, extract and run.
<elopio> plars: if it's ok for you, I'll switch to source code and go run.
<plars> elopio: I thought that was the plan all along, and I think you have golang and the other deps you need there to do it. You just need a script that sets the path, pulls your branch, and does the build
<elopio> good. I'm on it.
<elopio> plars: second problem. If you look at the script, now I'm pushing the results summary to the json.
<plars> elopio: let me know if you need anything from me, happy to help however I can
<elopio> the tests should currently fail because there's a bug. And attach the error.
<elopio> but they all pass, and the payload is empty.
<elopio> I'm not sure what's going on here.
<plars> One minute, let me look
<plars> elopio: '/bin/sh: 1: ./snappy-tests-job.sh: Permission denied\n'
<plars> elopio: it doesn't seem to be getting very far
<elopio> oh, ok. And what should I do for it to fail instead of pass if I have that error?
<elopio> ev: ^ here's a case where I need to deactivate the test and create a new one.
<ev> elopio: noted; and huh, we seem to have slightly screwed up and never documented that
<ev> getting that on the board
<plars> elopio: what does your spec look like?
<plars> elopio: I would think that the spi agent should pick up that failed run of the script, and call it a fail, unless you have it running some other command after that
<elopio> plars: wget ...; ./script...
<plars> and the later command passes
<elopio> It's missing the chmod +x
<plars> elopio: right, but that should exit non-0
<plars> elopio: if that's the last command in your spec, then I would think it should get called a fail, but perhaps I'm doing something that eats it
<plars> let me look
<vmayoral|pc> tedg: http://wiki.ros.org/cmake_modules
<tedg> Cool, I'll use that then
<plars> elopio: ah yeah, I think the spi agent would depend on the provisioning kit to pass that exit value along, but we don't want to end abruptly
<ev> elopio: I stand corrected - we just need to generate a new PDF
<plars> elopio: I could probably set a flag somewhere that if any command in your test_cmds list fails, we should exit non-zero, does that make sense to you?
<ev> incoming
<elopio> ev: great, thanks.
<vmayoral|pc> tedg: awesome!
<elopio> plars: makes sense.
<elopio> the other problem would be how to collect that error.
<sergiusens> tedg, also meet ahcorde
<tedg> Howdy ahcorde !
<ahcorde> Hi tedg ;)
<elopio> ev: and I have a feature request. Not sure how to send it. When I create a new test opportunity, it gives me an id. But then I can't use that id to query for the results.
<sergiusens> ahcorde, http://paste.ubuntu.com/12632171/
<sergiusens> tedg, so ahcorde is going to try and save you time checking if you have all the deps
<ev> elopio: all feature requests to me (or Ursinha when I'm away)
<sergiusens> tedg, you can remove demos, spider_imu_dev from the list
<tedg> This is my new favorite command: find . -name package.xml -exec grep _depend {} \; | grep -v \<\!-- | cut -d \> -f 2 | cut -d \< -f 1 | sort -u
<tedg> :-)
<Ursinha> me
<sergiusens> Ursinha, you!
<Ursinha> sergiusens: happy belated birthday!
<elopio> ev: by mail?
 * Ursinha hugs sergiusens
<ev> elopio: is there anything more to your request than that? If we just made it so that you could use the ID returned in a test opportunity to retrieve results for just that opportunity, would that be enough, or is there more to it?
 * sergiusens hugs Ursinha 
<ev> elopio: generally, yes :)
<Ursinha> \o/
<elopio> ev: that's just what I want, thanks.
<ev> getting it on the board
<tedg> vmayoral: ahcorde: cppunit? libcppunit?
<vmayoral> tedg: not needed (i believe)
<Ursinha> elopio: email is generally a good idea, makes it harder to miss the request :)
<ev> Ursinha: hm, I wonder if elopio's request is a facet of this https://trello.com/c/EIgSVwFy/65-story-search-test-results-data
<elopio> ev: Ursinha: that seems to involve a lot more. I just need another key to be allowed when querying for results.
<Ursinha> let me see
<elopio> and not urgent. I added a UUID to the image_unique_id, and I'm querying that.
<elopio> works ok.
<ev> I remember we discussed this with noise ages ago and had a card on such filtering
<ev> I've added https://trello.com/c/jbxyvqec/188-story-filter-test-results-by-test-opportunity-id until we can otherwise prove we don't need it
<vmayoral> sergiusens: https://github.com/ament
<plars> elopio: I'll have a patch up for that later after I get through some other stuff, but in the meantime, just ignore the pass/fail status and chmod +x your script and I think you'll get a lot farther :)
<tedg> vmayoral: ahcorde: eigen? eigen-containers?
<elopio> plars: yes, I'll add the +x and change the script to run from source.
<elopio> I'll probably mess it up and have to ask you again to copy the error for me :)
<plars> elopio: and great idea on the results query by test id, I think that would be useful as well - you can kind of hack around it by giving your image a unique id every time, but more options for query would always be better
<plars> elopio: no problem, I have a much easier way of looking at the trace now
<elopio> plars: specially now that my client that requests stuff is in python.
<elopio> it's really easy to capture the result from the previous call.
<plars> cool
<ahcorde> tedg: libeigen3-dev
<Ursinha> ev: I've tagged the story accordingly, and moved to the "progress and result reporting" lane -- feel free to reorder the priority
<ev> thanks Ursinha
<Ursinha> ev: thanks for creating the card
<ev> elopio: the latest PDF now has the instructions for deactivating
<sergiusens> ogra, hey, mind testing the latest snapcraft in tools-proposed with your snapcraft.yaml's?
<longsleep> i just switched to latest snapcraft trunk to work on my plugins, seems it now requires jsonschema which i do not have yet, is trunk supposed to work?
<plars> elopio: oh, another dirty trick you might want to consider (I find it helpful) is to save off all your output during your test script, pastebin it at the end of the job, and post the pastebin link in the results json for spi to pick up, then you can easily see a few more details
<elopio> plars: smart smart.
<tedg> longsleep: You'll need to grab python3-jsonschema
<tedg> longsleep: It validates the YAML now using that
<elopio> fgimenez: you have one ExecCommand in the config-test that needs to be udpated for the cli branch.
<longsleep> tedg: sure, but i thought i have the daily ppa - shouldnt it just give me the dependencies
 * longsleep checks apt sources
<tedg> longsleep: I'm not sure if the PPA has moved to version 0.2 yet.
<tedg> sergiusens: ^
<tedg> It was "not daily" there for a while to avoid breaking people.
<longsleep> tedg: yes - the ppa seems to have 0.2.1 or 0.2.2 but for some reason my system has 0.1-0~135~ubuntu14.04.1
<tedg> You should upgrade, it's better now ;-)
<longsleep> the ppa i use is http://ppa.launchpad.net/snappy-dev/snapcraft-daily/ubuntu
<sergiusens> longsleep, trunk works as long as you install what is in debian/control
<fgimenez> elopio, ok thanks, i'll merge from trunk once it's landed
<sergiusens> longsleep, daily ppa is dead, ppa:snappy-dev/tools is what we use
<longsleep> ah there is indeed an update - you folks pushed that recently?
<sergiusens> longsleep, 0.2, a long while ago
<sergiusens> longsleep, 0.2.2 I just staged in the daily ppa
<sergiusens> longsleep, if you want the next tentative thing, use ppa:snappy-dev/tools-proposed
<sergiusens> longsleep, don't use http://ppa.launchpad.net/snappy-dev/snapcraft-daily/ubuntu
<longsleep> sergiusens: ah ok thanks - i will remove the daily and add the proposed then. I got the spappy-dev/tools ppa already.
<elopio> fgimenez: do you have any idea why the prints of my python script in jenkins appear only when the script finishes?
<sergiusens> longsleep, hmm, if you have /tools you should of at least gotten 0.2.1
<longsleep> sergiusens: yeah, seems like have not updated for a while
<longsleep> i get python3-jsonschema now when doing an upgrade so i think i am good thanks
<fgimenez> elopio, nope, didn't notice that, i thought it was due to the connection with spi
<elopio> fgimenez: no, it should print: results not found, trying again...
<elopio> there's a plugin for python scripts in the build which might do it better.
<longsleep> sergiusens: another question, do you have plans to make it possible for snapcraft to use local plugins?
<sergiusens> longsleep, it already can
<sergiusens> longsleep, just x- it
<longsleep> sergiusens: oh thats great
<sergiusens> longsleep, there's a test inside integration_tests, which implements a nothing plugin
<longsleep> sergiusens: found it - that is local to a snap though. What if i need the same plugin for multiple snaps?
<sergiusens> longsleep, ah, upstream submission
<sergiusens> longsleep, are you asking about the deb one?
<longsleep> sergiusens: yes that one
<sergiusens> longsleep, else I need to still work on some path overriding bug/task still open somewhere
<longsleep> sergiusens: i will sync it to the latest tree
<sergiusens> longsleep, sounds good, also if you can, unit tests and / or integration tests
<longsleep> sergiusens: Yeah sure, it worked well for me so far - i am building 20 snaps or so with it.
<fgimenez> nice evening all o/
<tedg> vmayoral:
<tedg> vmayoral: Looking at catkin_make vs. catkin_make_isolated
<tedg> vmayoral: It seems I have to use isolated because of orocos?
<longsleep> Mhm seems like snapcraft needs meta-data now in snapcraft.yaml
<vmayoral> yes
 * longsleep has some snaps to upgrade
<vmayoral> tedg: yes
<tedg> vmayoral: Is there a reason I wouldn't want to use isolated all the time?
<vmayoral> we use isolated all the time
<vmayoral> tedg: i can't come up with a reason not to use it
<tedg> K
<tedg> I will too :-)
<elopio> plars: this time the run took more than 15 minutes, but I still get no result_payload.
<plars> elopio: looking
<plars> elopio: https://pastebin.canonical.com/140981/ sorry for the poor formatting, I just get the full string out in a log
<plars> elopio: from a quick glance, it looks like it might want hg installed?
 * plars wonders who uses hg still
<elopio> plars: yes. code.google.com. Can you please install it?
<plars> elopio: will do
<elopio> I will make the script smarter so it doesn't fail if summary is not there. And send this to pastebin.
<plars> elopio: and I'll add it to the extra packages to get installed in the environment too
<elopio> plars: you have pastebinit installed, right?
<plars> elopio: yes
<plars> elopio: the bbb ones have mercurial now at least
<plars> elopio: you aren't doing anything on rpi at the moment right? There's something wrong with that one that I'm trying to sort out, possibly a bad usb stick again
<elopio> plars: no rpi yet.
<longsleep> whats the latest syntax in snap yaml? architecture or architectures?
<tedg> longsleep: architectures, and it's an array of architectures
<DexterF> heya
<DexterF> put 15.04 on a pi2. so.. does core have the same packages as standard ubuntu? can I just snappy install build-essential and compile fancy kernel modules?
<DexterF> hmm, obviously not
<elopio> plars: is the CWD on the agent is new every time I run it?
#snappy 2015-10-02
<plars> elopio: yes
<elopio> plars: could you please check what's the latest error?
<elopio> I'm not yet catching the good stuff in the payload. Butt when I test it here it works.
<plars> elopio: sure, just a minute
<plars> elopio: this seems to be the interesting bit: cat: /results/output/log: No such file or directory\nYou are trying to send an empty document, exiting.\ncat: /results/output/summary: No such file or directory\n./snappy-tests-job.sh: 9: ./snappy-tests-job.sh: cannot create /spi_test_result.json: Permission denied
<elopio> plars: hum. The docs say that there is an env var $CWD.
<elopio> I was using that. I'll take it out.
<elopio> thanks. Another try...
<plars> elopio: $PWD perhaps?
<elopio> plars: no, the docs say $CWD. But it's not entirely clear what they meant with that.
<plars> elopio: which docs?
<elopio> plars: spi-user-docs-latest.pdf
<plars> could be a misprint, but I would think $PWD should work
 * elopio needs better bash superpowers.
<yashi_> regarding to bug #1499429, what's a proper workflow to reflect review comment to my launchpad branch?  force push or another branch?
<ubottu> bug 1499429 in Snapcraft "snapcraft dies with "export: python3.5/dist-packages: bad variable name"" [Critical,Confirmed] https://launchpad.net/bugs/1499429
<elopio> yashi_: hello.
<elopio> I replied on the merge proposal. Just make the change, bzr commit and bzr push.
<yashi_> elopio: thanks!
<elopio> you use the same branch, but are not forcing anything. It will keep the previous commits.
<elopio> yashi_: thanks a lot for finding this, and fixing it. Have you signed the contributors agreement?
<elopio> http://www.ubuntu.com/legal/contributors/submit
<yashi_> elopio: nop, reading....
<elopio> yashi_: Here's the faq: http://www.ubuntu.com/legal/contributors/licence-agreement-faq
<elopio> please let me know if you want to know something else.
<yashi_> elopio: the submission ask me to put a project contact.  what is it?
<yashi_> elopio: hmm.  do i need to print the pdf, sign it, and snail back to canonical?
<elopio> yashi_: the contact is asac. Alexander Sack <alexander.sack@canonical.com>
<elopio> yashi_: and no, afaik you don't have to send the pdf. Let me confirm.
<elopio> yashi_: it says that you can send the pdf if you don't have a launchpad account. You are good with filling the form.
<elopio> sigh, I suck at bash. I can't even capture the error.
<elopio> plars: again, please, whenever you see this.
<yashi_> elopio: done
<elopio> yashi_: thank you!
<elopio> welcome to snapcraft. If you ever get bored, we have tons of things funny things you can do ;)
<yashi_> elopio: will push a fix today
<elopio> sergiusens: hey, you are up.
<elopio> sergiusens: these are the problems I had:
<elopio> ttps://bugs.launchpad.net/snapcraft/+bug/1499429
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1501980
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1501977
<ubottu> Launchpad bug 1501980 in Snapcraft "the error message when a plugin is not found is not good" [Undecided,New]
<ubottu> Launchpad bug 1501977 in Snapcraft "py2-project example fails to snap" [High,New]
<elopio> other than that, looks good.
<elopio> haven't tried the minecraft one yet.
<clobrano> morning :)
<fgimenez> good morning
<davidcalle> asac, thanks for the heads-up, that's an impressive team effort :) Are there any sections you'll still want to keep under wraps or can I assume (after today eod) everything is ready for a first publication?
<dholbach> good morning
<davidcalle> Hey dholbach, how are you?
<dholbach> hey davidcalle
<dholbach> good good - how about you?
<davidcalle> dholbach, life is good
<davidcalle> dholbach, nice work with the snappy doc propositions, I agree with everything :)
<dholbach> yeah, I was trying to find a balance between: more useful for certain demographics and not too much new maintenance work for us :)
<dholbach> ... and leaving IA intact
<clobrano> Chipaca: I'll drop here my hw-assign question (I wrote on the mailing list too), please have a look at it, when you've got time :)
<JamesTait> Good morning all; happy Friday, and happy International Day of Non-Violence! ð
<clobrano> Chipaca: about the possibility to assign a symlink to a device node using hw-assign command (Bug #1496319), I had everything done and ready to be submitted for something like: "snappy hw-assign <device> <symlink>"  but, then, I thought that it's more common to create a symlink only if some conditions are met (like VID/PID, etc.), so I've got the idea to change it in: "hw-assign <device> <properties>" where <properties> would be a string containing part of
<clobrano> the Udev rule to append to the newly created rule, like "ATTRS{idVendor}==...". This way one can add different rules, not only symlinks. What do you think?
<ubottu> bug 1496319 in Snappy "Could not create symlink to hw device with udev rules" [Undecided,New] https://launchpad.net/bugs/1496319
<Chipaca> clobrano: hmm. first thought is whether udev has been audited enough to have people safely write rules
<clobrano> Chipaca: yep, that was my first idea too
<clobrano> Chipaca: like with great power comes great responsability :)
<clobrano> Chipaca: but at the same time, it's common symlinking to a generic /dev/ttyUSB* and then add conditions to narrow down the list of possible device nodes
<lool> vmayoral|pc: ssh root@212.47.227.205
<clobrano> Chipaca: however, that things can be done at different times. First try and add the first implementation and then see if/when we can move to the second one
<Chipaca> clobrano: so which would the first implementation be?
<clobrano> Chipaca: just hw-assign <device-node> <symlink>
<clobrano> Chipaca: where <symlink> is optional
<asac> davidcalle: not sure yet. lets see how it looks like
<Chipaca> clobrano: and how would the move to the second phase work?
<lool> tedg, sergiusens: ssh root@212.47.227.205 for the ARM buildd
<lool> vivid, installing snapcraft there now
<clobrano> Chipaca: that's depend on you all I think :), I can't decide if/when that change will be applicable
<Chipaca> clobrano: no, i mean
<Chipaca> clobrano: let's say we implement hw-assign <device> [<symlink>]
<Chipaca> clobrano: document taht
<Chipaca> clobrano: people use it
<Chipaca> clobrano: how do we introduce the new thing without breaking the old?
<clobrano> Chipaca: ooh, right
<clobrano> Chipaca: well, it's not that hard to recognize a symlink (valid) from a string defining a udev rule, just to keep the backward compatibility
<clobrano> Chipaca: but I got your point
<lool> vmayoral, tedg, sergiusens: please use ubuntu@212.47.227.205 instead, sorry
<lool> root will go away on reboots, and we should not use root
<lool> ok, sudo works now, removing your root SSH keys guys
<lool> yeah, building!
<dholbach> fgimenez, elopio: does "python3 setup.py test" crash for you in lp:snapcraft too?
<fgimenez> dholbach, let me try
<fgimenez> dholbach, yes, pip-requirements is failing http://paste.ubuntu.com/12637380/
<dholbach> fgimenez, http://pastebin.ubuntu.com/12637392/ is what I'm seeing
<dholbach> zyga, ^ do you know what's happening here?
<zyga> dholbach: looking
<zyga> dholbach: yes, it's fixed with a branch that didn't land yet
<zyga> dholbach: it's a one-line fix
<zyga> dholbach: but I'm not sure if someone fixed it because the original contributor did the fix in a werid way but didn't respond to feedback
<zyga> sergiusens: ^^
<zyga> dholbach: it happens because wily has two versions of python3
<dholbach> zyga, are http://paste.ubuntu.com/12637380/ and http://pastebin.ubuntu.com/12637392/ the same issue?
<zyga> dholbach: no, that seems different
<zyga> dholbach: the 2nd one looks like a bug elsewhere, how did you get it?
<zyga> dholbach: is that trunk, any released version, something else?
<dholbach> trunk
<zyga> dholbach: on wily?
<dholbach> yes
<dholbach> I just ran    python3 setup.py test
<zyga> dholbach: one sec
<zyga> dholbach: I'll just fix the bug that the contributor tried
<zyga> dholbach: and see if I get to the 2nd one
<dholbach> <3
<zyga> dholbach: I should have fixed it earlier but I really wanted yashi_ (AFAIR) to reply
<dholbach> no worries
<zyga> dholbach: https://code.launchpad.net/~yashi/snapcraft/snapcraft/+merge/272337 this is the thing
<dpm> dholbach, looking at the developer manual, trying to do 'sudo apt-get install snapcraft-examples' does nothing for me. I'm on 15.04, and I've got the ppa:snappy-dev/tools installed
<dpm> anything I'm missing?
<zyga> yashi_: around?
<dholbach> dpm, not sure if anyone updated the ppa - let me check
<dholbach> dpm, https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+sourcepub/5408454/+listing-archive-extra
<dholbach> dpm, it should be there
<dholbach> are you sure you have the ppa enabled and your apt sources updated?
 * dpm apt updates to be sure
<dpm> that might have been it
<dpm> yeah, that was it, thanks dholbach
<dholbach> cool
<zyga> fg
<dholbach> zyga, what does force-push mean in the MP=
<dholbach> ?
<zyga> dholbach: bzr push --overwrite
<zyga> dholbach: before it lands that's the best way to do it
<dholbach> ah, so you're asking yashi to push --overwrite to his branch?
<zyga> dholbach: lp tracks past in case someone wants to do data mining but for everyone else it gets rid of "fixup stuff" commits that are just noise
<zyga> dholbach: ys
<zyga> yes*
<dholbach> ok
<zyga> dholbach: if you want I can fix and land this myself in 5 minutes
<zyga> dholbach: do you want me to fix that quickly?
<dholbach> zyga, I don't know - I just noticed that the test was broken
<zyga> dholbach: yes, we know about it, I think I will just fix it now
<dholbach> ok
<victorp> pitti, hey - got home and I am able to ssh over wifi to the pi. Thanks!
<pitti> victorp: cool!
<pitti> victorp: wipi!
<victorp> hehe
<mvo> vmayoral: this will work  lp:~mvo/snappy/snappy-classic-mode  but its not the final on-disk layout and the comandline will be slightly diffrent
<vmayoral> mvo: great, thanks a lot. I'll have a look
<mvo> vmayoral: happy to give you a binary and/or talk more later
<vmayoral> mvo: that'll be great! let's do that
<Chipaca> mvo: tell me about that branch; does it need reviewing, or is it in progress?
<mvo> Chipaca: it needs to actually go back to WIP
<Chipaca> done :)
<mvo> Chipaca: because there were some changes during the sprint how its constructed etc
<mvo> Chipaca: thanks!
<vmayoral> sergiusens: getting https://gist.github.com/vmayoral/b3ea80d53d5fe25e3ed2 when trying to upload the snap to the store
<vmayoral> sergiusens: the framework doesn't exist so it just rejects it
<sergiusens> vmayoral, I'll accept it
<sergiusens> vmayoral, do you have the link?
<jdstrand> beuno: hey, pindonga was working on the issues found here: https://myapps.developer.ubuntu.com/dev/click-apps/3560/review/r/2/. it turned out to be that the server isn't setting the proper local and it has nothing to do with my snap. he approved the last one but isn't here now. would you mind approving this one?
<vmayoral> sergiusens: so i actually don't think that the snap get's even submitted
<vmayoral> sergiusens: it gets rejected before the review process complaining about the missing framework
 * jdstrand -> gone for a few hours
<beuno> vmayoral, I think you can click and ask for a manual review
<vmayoral> sergiusens, beuno: stucked at this form https://myapps.developer.ubuntu.com/dev/click-apps/upload/?format=snap
<vmayoral> i believe the manual review process is available in a later step, but let me know if i'm not looking at the right place
<beuno> ah
<beuno> so we need to add that framework first
<beuno> nessita, ^
<beuno> vmayoral, what's the string?
 * Chipaca hopes it's vmayoral-the-magnificent
<vmayoral> beuno: the framework has been named "raspivid"
<nessita> beuno, hello
<sergiusens> beuno, fyi, they use a framework, I guess we just need to add it to the framework list
<beuno> vmayoral, done
<sergiusens> beuno, I think i can do that
<beuno> sergiusens, indeed
<beuno> done already
<nessita> even better
<vmayoral> beuno: trying again, thanks!
<vmayoral> beuno, sergiusens: it got in https://myapps.developer.ubuntu.com/dev/click-apps/3591
<vmayoral> beuno, sergiusens: remaking the snap to fix the errors
<sergiusens> vmayoral, awesome, no inlfight installation ftw ;-)
<sergiusens> vmayoral, oh, run click-review from your host/laptop
<vmayoral> sergiusens: in the store already, we were missing a "description" field.
<sergiusens> vmayoral, great
<lool> vmayoral: I found the issue with ros/cmake/tests
<lool> vmayoral: in the process, I found it hard to move the directory around, clean didn't clean up enough
<lool> vmayoral: that is, I copied to a different dir, ran snapcraft clean, and then snapcraft build failed because of a ton of generated files hardcoding the previous path
<lool> vmayoral: this was really hard to fix, would you know a clean way?
<lool> oh shit, I take it back, the error is still there  :-(
<vmayoral> lool: so generally, "cakin_make clean" does a good job on that. Wanna join us in the room or should i "screen -x"?
<plars> elopio: sorry, I had already gone to sleep when you sent that
<plars> elopio: elasticsearch seems to have blown up on me, so I can't see much right now, let me sort out what happened with that and get you to retry
<olli> ueh
<dholbach> sergiusens, https://code.launchpad.net/~dholbach/snapcraft/fix-pep8-and-doc-indentation/+merge/273195 updated
<plars> elopio: when you have a chance, could you try again?
<elopio> plars: I've launched a new run.
<jdstrand> popey: hey, you around? (quick store review)
<popey> jdstrand: ya
<jdstrand> popey: would you mind taking a look at https://myapps.developer.ubuntu.com/dev/click-apps/3560/r/2/? there are two review failures but it is due to a server side issue that pindonga has the fix for bt that hasn't rolled out yet. the snap is fine
<jdstrand> popey: he approved 0.1 and it had the same to review failures
<popey> okay
<jdstrand> two*
<plars> elopio: It looks like it's done, but I didn't see it execute any test commands, last I saw it was trying to boot the test image
<plars> elopio: perhaps the test image didn't boot?
<elopio> plars: can you take a look at the script to see if I'm doing something stupid?
<plars> elopio: I really think the test image didn't boot
<elopio> plars: if that happens, there will be a ssh timeout and the test will fail.
<jdstrand> popey: thanks! :)
<elopio> but it always says pass. And I get no payload.
<plars> elopio: no, it won't even get that far if it can't confirm that the image booted
<plars> elopio: it won't even try to run the tests
<plars> elopio: I'm kicking off a test job of mine to see if something else could be causing this
<elopio> ok
<plars> grr... logstash broke again
<plars> this was supposed to work
<victorp> anyone knows if I have to include a .service file on a snap service or if that is taken care on its own?
<Chipaca> victorp: you do not have to include a .service file
<Chipaca> victorp: in fact it will be ignored :)
<victorp> Chipaca, so any idea why when I restart the service I have sideloaded as a snap I get an error ...ICLGcNeLFEPe.service failed to load: No such file or directory
<Chipaca> victorp: that's a bug
<Chipaca> victorp: in particular, one we've fixed
<victorp> hehe
<Chipaca> victorp: but i'm bad at tracking where it is in the pipeline to you
<victorp> ok, I shall ignore then
<victorp> Chipaca, np, I was just thinking I might be doing something wrong, I will ingore it for now and continue
<Chipaca> the error is real, but if it's not blocking you, sure
<victorp> is not blocking
<Chipaca> ok :)
<victorp> service runs fine from a restart of the pi
 * Chipaca nods
<Chipaca> victorp: and you can probably find the right service and restart it using systemctl, if i remember that bug correctly
<Chipaca> hmm
<Chipaca> victorp: just reproduced in latest stable, so the fix isn't there
<victorp> ack
<Chipaca> ... this might be a different bug
<Chipaca> victorp: um. What I'm seeing is that it's not forgetting about the old service
<Chipaca> victorp: that is, "snappy service status" shows the old one and the new one
<victorp> oh
<victorp> yeah I saw that too
<Chipaca> victorp: but the new one is running alright
<fgimenez_> have a nice weekend o/
<Chipaca> pitti: you around?
<mwenning> Hi snappy team, I did a sudo snappy update and then rebooted, grub comes up with system-b , goes thru a certain amount of booting, then gets a kernel panic and starts over.  Is there a way to manually switch back to system-a?
<Chipaca> mwenning: it should switch back on its own
<Chipaca> mwenning: what system is this?
<Chipaca> of it *isn't* switching on its own, i'd love to have a look at the system, if it is image'able
<mwenning> Chipaca, switch to snappy-internal
#snappy 2015-10-03
<yashi_> elopio: pushed with --overwrite
<DexterF> hi
<DexterF> I'd like to have the 4.2 kernel from snappy in ubuntu-mate pi2 edition, is there a deb package I can download and install there?
<DexterF> heya
<DexterF> does anybody have core 15.04 running right now and could get me the .config file of the latest kernel, or tell me where I can get it?
#snappy 2015-10-04
<hadeska> im trying to add a physical network interface to a lxd container on ubuntu core but it doesnt seem to work , anyone could help ?
<shuduo> anyone has run Victor Palau's glowapi on RPi2? I always got 404 error with the REST api link (replaced with real IP).
<yashi_> Chipaca: thank you for merging my change
<yashi_> Chipaca: however, merge seems to be done only for python3.
<yashi_> Chipaca: http://bazaar.launchpad.net/~yashi/snapcraft/snapcraft/revision/210 has both 2 and 3, though.
<Chipaca> yashi_: i merged sergio's branch, which was a branch of yours
<DexterF> hi
<Chipaca> yashi_: not sure if that answers it
<Chipaca> DexterF: hi
<Chipaca> shuduo: i haven't, but, what rest api link?
<DexterF> I'd like to run the snappy kernel on Ubuntu Mate for Raspi2. My idea was get the snappy kernel source and just dpkg-buildpackage it, but I cannot find the src. help?
<Chipaca> DexterF: there aren't snappy kernels
<Chipaca> DexterF: just kernels
<Chipaca> DexterF: that are used by snappy
<DexterF> https://developer.ubuntu.com/en/snappy/ <- what would you call the kernel that the pi2 image here contains?
<DexterF> or rather this one http://people.canonical.com/~platform/snappy/raspberrypi2/ubuntu-15.04-snappy-armhf-rpi2.img.xz
<DexterF> either way, the kernel that that image boots, I'd like to port that to ubuntu-mate/pi2. pointers appreciated.
<Chipaca> DexterF: i presume ubuntu-mate/pi2 is ubuntu?
 * Chipaca downloads ogra_'s rpi2 image to take a look
<DexterF> no, it's slackware with a ported GNU/Herd kernel running on a Sun.
<DexterF> that's why it is called ubuntu-something
<Chipaca> DexterF: in that case, the kernel it uses is an ubuntu package, from an ubuntu archive
<DexterF> Chipaca: I had a look at the ubuntu git tree but could not find it.
<Chipaca> DexterF: couldn't find what?
<Chipaca> the kernel used in ubuntu-mate/rpi2, or the kernel used in snappy ubuntu core for rpi2?
<DexterF> the ubuntu package for that kernel.
<Chipaca> the kernel used in ubuntu-mate/rpi2, or the kernel used in snappy ubuntu core for rpi2?
<DexterF> the one used in snappy
<DexterF> or snappy ubuntu core if you prefer
<Chipaca> DexterF: did you find the other one, then?
<DexterF> Chipaca: is the plain linux-source package that comes with the distro, so yes. but that's a 3.18 kernel so making a config from that is a bit tedious, plus I don't know if I could just like that port it to a vanilla 4.2 src
<Chipaca> DexterF: can you point me at where that package comes from?
<Chipaca> DexterF: apt-get --print-uri would probably help
<DexterF> apt-get install linux-source. wherever it gets those.
<DexterF> sec
<DexterF> E: Command line option --print-uri is not understood
<Chipaca> --print-uris
<DexterF> neither
<Chipaca> tab is your friend
<DexterF> apt-get --print-uris linux-source
<DexterF> E: Command line option --print-uris is not understood
<Chipaca> apt-get install --print-uris linux-source
<DexterF> linux-source is already the newest version. :) I try and force, sec
<Chipaca> --reinstall
<DexterF> did that, does not become any more verbose either. I'll uninstall, if that don't help...
<DexterF> ill wireshark...
<DexterF> no, not even now. let me check sources..
<Chipaca> hold on
<Chipaca> what are you doing, exactly
<DexterF> trying to get apt to tell me where it gets the linux-source package, since you asked for that
<Chipaca> DexterF: show me the command you are entering
<DexterF> apt-get install --print-uris linux-source
<DexterF> after purging the package
<Chipaca> and what is the output? pastebin it please
<DexterF> http://pastebin.com/ThshALLL
<Chipaca> this is what you *should* be getting:
<Chipaca> apt-get -qq install --print-uris  --reinstall linux-source
<Chipaca> 'http://archive.ubuntu.com/ubuntu/pool/main/l/linux/linux-source-4.2.0_4.2.0-12.14_all.deb' linux-source-4.2.0_4.2.0-12.14_all.deb 107776972 MD5Sum:fa90f64d3f1132715605b64e146ff992
<Chipaca> 'http://archive.ubuntu.com/ubuntu/pool/main/l/linux-meta/linux-source_4.2.0.12.12_all.deb' linux-source_4.2.0.12.12_all.deb 2184 MD5Sum:68331205b67b02230581fe26a54ffd52
<Chipaca> no purging necessary
<Chipaca> this is for an amd64 box, but it shouldn't make a difference
<Chipaca> can you, in fact, install that package?
<DexterF> Chipaca: the package installs fine
<Chipaca> strange
<Chipaca> DexterF: the reason i'm asking is because until very recently we didn't have an ubuntu kernel that worked properly on the raspberry pi 2
<Chipaca> DexterF: so I don't know where ubuntu-mate/rpi2 is getting its kernel
<Chipaca> DexterF: but it's not an ubuntu kernel
<DexterF> Chipaca: who is "we"?
<Chipaca> DexterF: humanity
<DexterF> ...
<Chipaca> DexterF: so that's probably a linux kernel from e.g. raspbian
<DexterF> I'll ask them. what you say is a bit strange, though, a gernem IT newspage (still one of the better ones) announced that snappy ubuntu core now has a spanking new 4.2 kernel with full raspi2 support. hence my question who "we" was, assuming you are a snappy developer
<Chipaca> I am
<Chipaca> ogra_ will know more about the kernel without having to dig -- sorry i wasn't able to help you dig further
<Chipaca> however he is off today
<Chipaca> DexterF: i don't see why you say it's strange
<Chipaca> DexterF: what I'm saying is completely compatible with what you say that newspage says
<DexterF> Chipaca: maybe I get somethign wrong here: for a moment assume I know linux for a bit and then tell me, what is snappy and what is ubuntu core?
<Chipaca> DexterF: ubuntu core is a minimal ubuntu flavour, aimed mostly at people building appliances or single-purpose servers
<Chipaca> more or less :)
<DexterF> ok. and snappy?
<Chipaca> DexterF: snappy is a new way of packaging a distribution that uses transactional updates on a mostly readonly system
<DexterF> transactional mainly means: there are rather images than packages that get mounted over an existing tree?
<Chipaca> DexterF: evolved from the tech we (ubuntu) developed for the phone
<Chipaca> DexterF: transactional meaning the system updates as a whole, or fails to update as a whole
<DexterF> mmmmmhnope, don't get it
<Chipaca> DexterF: what don't you get?
<DexterF> the "updates or fials as a whole" thing.
<DexterF> at tech level, how are snappy... "packages" different from say deb packages
<Chipaca> ah
<Chipaca> DexterF: snaps have a much simplified dependency structure; no libaries, no conflicts, just a dependency on frameworks can be expressed. Snaps are not extracted into a common directory, but into their own little place, and when the services and binaries in them are run, they do so in their own little jail
<DexterF> Chipaca: how is that different from Docker or LXC?
<Chipaca> DexterF: how is that the same?
<DexterF> well, put everything required to run the package in a sandbox that does not depend on much
<Chipaca> DexterF: aren't those entire systems? don't you actually boot those?
<DexterF> but anyway, maybe I'm not doing this right: all I need is a minimalistic distro that brings me the comfort of central package management like apt, zypper, yum or whatever and a kernel running on a raspi2 including i2c and all, which would be 4.2 and higher.
<DexterF> Chipaca: uh, no, those are container concepts, these run against the same kernel as the host system
<Chipaca> DexterF: but you boot the container
<Chipaca> DexterF: with its own init and all
<DexterF> so maybe I should rather look at ubuntu core? but 4.2 is a must, hence that news item got my attention
<DexterF> Chipaca: good question, I actually only read up on docker and lxc but never implemented a setup
<Chipaca> DexterF: https://lists.ubuntu.com/archives/snappy-devel/2015-September/001058.html
<Chipaca> DexterF: that answers several of your questions, i think
<Chipaca> including the name of the source of the kernel package
<giminni> hello I have a problem to execute "docker exec -ti <progname> bash the message output is "type=1400 audit(1443969471.682:30): apparmor="DENIED" operation="open" profile="docker_docker-daemon_1.6.2.003" name="/" pid=<pid-#> comm="docker.x86_64" requested_mask="r" denied_mask="r" fsuid=0 ouid=0  How can I exec into a running container? even docker attach is hanging arount, appreciate any hints on that
<giminni> I am running the latest snappy & updates
<giminni> (amd64)ubuntu@localhost:~$ docker info
<giminni> Containers: 2
<giminni> Images: 43
<giminni> Storage Driver: aufs
<giminni>  Root Dir: /var/lib/apps/docker/1.6.2.003/aufs
<giminni>  Backing Filesystem: extfs
<giminni>  Dirs: 47
<giminni>  Dirperm1 Supported: true
<giminni> Execution Driver: native-0.2
<giminni> Kernel Version: 3.19.0-28-generic
<giminni> Operating System: <unknown>
<giminni> CPUs: 1
<giminni> Total Memory: 741.1 MiB
<giminni> Name: localhost.localdomain
<giminni> ID: 7M25:QCMT:AQJM:X5HZ:PVLW:CK7A:4VYA:7CIP:GLOK:HXA7:UGV5:L2EI
<giminni> WARNING: No swap limit support
<giminni> (amd64)ubuntu@localhost:~$ docker version
<giminni> Client version: 1.6.2
<giminni> Client API version: 1.18
<giminni> Go version (client): go1.4.2
<giminni> Git commit (client): 8f2d6e5
<giminni> OS/Arch (client): linux/amd64
<giminni> Server version: 1.6.2
<giminni> Server API version: 1.18
<giminni> Go version (server): go1.4.2
<giminni> Git commit (server): 8f2d6e5
<Chipaca> giminni: suggest you ask again tomorrow; most people are off today
<giminni> thx I'll do that tomorrow
<shuduo> Chipaca, http://victorpalau.net/2015/10/02/piglow-api-one-small-snap-for-humanity/
<Chipaca> shuduo: has the service started successfully?
<Chipaca> shuduo: "snappy service status" should tell you
<shuduo> Chipaca, i can see glowapi status is "enabled; loaded; active (running)"
<Chipaca> shuduo: ok. And can you connect to port 8000 from the board itself?
<Chipaca> e.g. by doing "telnet localhost 8000"
<shuduo> Chipaca, there is no telnet in snappy image. should i install it?
<Chipaca> ah, that's true
<Chipaca> netcat (nc)
<Chipaca> shuduo: i mean: nc localhost 8000
<shuduo> Chipaca, yes, it stuck now and no output
<Chipaca> shuduo: write "GET /" and hit enter twice
<shuduo> Chipaca, it outputs "HTTP/1.1 400 Bad Request"
<shuduo> Chipaca, btw, i just hit once then it exit with above output
<Chipaca> shuduo: so, piglow is listening to port 8000
<Chipaca> shuduo: and if you use your external address instead of localhost?
<shuduo> Chipaca, yes, i just tried again and it returns "404 page not found"
<Chipaca> shuduo: where did you try that from?
<Chipaca> because 404 is not 400
<Chipaca> it's a different response
<Chipaca> and it shouldn't be
<shuduo> i paste victor's link to my browser and replace localhost with its real ip address
<Chipaca> shuduo: ok, backpedal a bit
<Chipaca> shuduo: first, none of those urls are browser-friendly
<Chipaca> shuduo: because they all need to be POST
<Chipaca> and if you're just writing the url in your browser it won't work
<Chipaca> give me a bit
<Chipaca> shuduo: are you ssh'ing in to the board, or are you typing at it manually?
<shuduo> Chipaca, i tried to copy an example code of using nc to send POST to localhost but it returns 400 error. i guess my command is not correct.
<shuduo> Chipaca, i'm sshing
<Chipaca> shuduo: try this: python3 -c 'from urllib.request import urlopen; print(urlopen("http://localhost:8000/v1/on", data=b""))'
<shuduo> Chipaca, cool. it works now. piglow be turned on for 1 sec. thanks
<Chipaca> ah, missing a .read() there
<Chipaca> shuduo: try this: python3 -c 'from urllib.request import urlopen; print(urlopen("http://localhost:8000/v1/on", data=b"").read())'
<Chipaca> shuduo: now, that's still localhost
<Chipaca> shuduo: try it remotely, does that work now? (change "localhost" to the right ip)
<shuduo> Chipaca, with read(), it looks same. led turned on for 1 sec and exit.
<Chipaca> that's ok. It's just that if the piglow returned anything, without the read() you wouldn't see it
<Chipaca> shuduo: try it remotely; if that works, you're set, but i suspect there's something else going on as well
<shuduo> Chipaca, yes, remote accessing works good too.
<Chipaca> ah, neat
<Chipaca> i wonder why the browser was saying 404 instead of 400
<Chipaca> anyway, never mind, it works \o/
<Chipaca> shuduo: if you want to make it work with a browser, you need to write some html
<Chipaca> shuduo: and probably some javascript in the html unless you just want to hit one endpoint :)
<Chipaca> e.g. <form action="http://the.ip:8000/v1/on"><input type=submit value=on></form>
<shuduo> Chipaca, got it. i see someone can control piglow by an app from ubuntu phone on a video.
#snappy 2016-10-03
<mup> PR snapd#2054 closed: client,daemon,cmd/snap: improve create-user APIs <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2054>
<mwhudson> is it possible to get snapd to forget about an assertion?
<zyga> hey
<zyga> mwhudson: I think only with a new assertion
<zyga> mwhudson: (or with rm -f)
<mup> PR snapd#2056 opened: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2056>
<mwhudson> morning
<mup> PR snapd#2056 closed: interfaces: add Plug/Slot/Connection reference helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2056>
<mup> PR snapd#2057 opened: docs: remove references to removed buying features <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2057>
<mup> PR snapd#2058 opened: interfaces: add ofono interface <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2058>
<hikiko> hello :)
<hikiko> I need some help with an error message during dist-upgrade on X
<hikiko> http://pastebin.com/HUcC3wWg
<hikiko> the initial problem I was trying to solve was this:
<hikiko> I have 2 graphics cards intel and nvidia, but I work on the intel, the nvidia is there for testing features and during the last dist-upgrades the nvidia drivers and several other packages were automatically installed and messed up my xorg configuration so I couldn't use any of the cards. everytime I remove the nvidia drivers and the other packages they are reinstalled as a dependency of libcuda1-361 and every time I try to remove
<hikiko> it I receive that error message...
<hikiko> any ideas? :)
<mup> PR snapd#2059 opened: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <https://github.com/snapcore/snapd/pull/2059>
<didrocks> hikiko: no package I can see contain this file, I guess it's snapd creating it dynamically for system mount point. It's a question for mvo or zyga ^
<hikiko> thanks didrocks :)
<mup> PR snapd#2060 opened: many: change Connect to take ConnRef instead of strings <Created by zyga> <https://github.com/snapcore/snapd/pull/2060>
<mup> PR snapd#2061 opened: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2061>
<didrocks> zyga: hey! It seems that if a service fails to start at installation time, the snap is removed
<didrocks> zyga: that makes it hard for debugging, any tip about it?
<didrocks> davidcalle: FYI (on the doc)
<zyga> didrocks: hey
<zyga> hikiko: looking
<zyga> hikiko: that's something that was only available in -proposed
<zyga> hikiko: this is something that has to be fixed in the nvidia packaging but I believe it was removed already
<zyga> hikiko: can you check if you can downgrade to the non-proposed package and see if the problem goes away
<zyga> didrocks: I wasn't aware of it
<zyga> didrocks: I don't know what is the plan about this, sorry
<hikiko> zyga, how can I downgrade it?
<zyga> hikiko: I think you can try to install it with "apt install package=version"
<zyga> hikiko: alternatively edit the dpkg maintainer script on your disk not to touch that mount unit
<zyga> hikiko: but really, I don't fully know what is required; you probably want to ask alberto milone or mvo (try alberto first please)
<hikiko> zyga, and where can I find the version to which I have to downgrade?
<zyga> hikiko: try apt-cache policy package
<zyga> this will show you available versions
<hikiko> thanks zyga :) I'll try
<zyga> (the package in question is the one that fails because of the maintianer script)
<zyga> *maintainer
<mup> PR snapd#2062 opened: interfaces/policy: introduce InstallCandidate and its checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/2062>
<mup> PR snapd#2063 opened: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
<zyga> jdstrand: hey, you may want to review this one ^6
<didrocks> zyga: hikiko|ln: btw, easier for downgrading, you can do apt install package/<distropocket> (like package/yakkety for instance)
<hikiko|ln> didrocks, if I try to do that the proposed are selected
<didrocks> no
<didrocks> if you don't set yakkety-proposed, and only yakkety, it will select yakkety
<didrocks> (with -f to force a downgrade ofc)
<hikiko|ln> # apt install libcuda1-361/xenial -f
<hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB]
<didrocks> this is the nvidia package
<didrocks> not libcuda1-361
<hikiko|ln> yup it's a dependency
<didrocks> so ofc, the other packages follow the general scheme
<hikiko|ln> oh ok :)
<didrocks> so, you need to list it
<didrocks> # apt install libcuda1-361/xenial nvidia-367/xenial -f
<didrocks> and so onâ¦ :)
<hikiko|ln> I need to remove the dependencies and libcuda didrocks
<hikiko|ln> should I first downgrade then remove?
<didrocks> I would say yeah, first downgrade everything to remove -proposed components
<didrocks> and then remove
<didrocks> (get in a consistent state first)
<hikiko|ln> ~# apt install libcuda1-361/xenial  nvidia-367/xenial nvidia-opencl-icd-367/xenial nvidia-prime/xenial nvidia-settings/xenial -f
<hikiko|ln> Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/restricted amd64 nvidia-367 amd64 367.44-0ubuntu0.16.04.2 [69,6 MB]
<hikiko|ln> it seems to ignore my setting
<didrocks> humâ¦ that's weird
<didrocks> what if you only do apt install nvidia-367/xenial -f only?
<hikiko|ln> https://paste.ubuntu.com/23269943/ didrocks
<didrocks> hikiko|ln: I think you have another package that forces you to get that version
<hikiko|ln> I've purged nvidia* didrocks
<hikiko|ln> can I see which package it is somehow?
<didrocks> and here we go
<didrocks> https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-367
<didrocks> -367 is only available in -proposed
<didrocks> that's why he didn't follow your guidance to prefer the /xenial one :p
<hikiko|ln> and I didn't have it installed
<hikiko|ln> so what should I do?
<didrocks> I'm pretty sur eyou have something like libcuda1-367 or anything depending on it
<didrocks> well, you did purge it, right?
<hikiko|ln> the initial problem is to remove libcuda1-361
<hikiko|ln> yup
<didrocks> apt-cache rdepends nvidia-367
<didrocks> anything there? ^
<hikiko|ln> Reverse Depends:
<hikiko|ln>   libcuda1-367
<hikiko|ln>   nvidia-opencl-icd-367
<hikiko|ln>   nvidia-367-dev
<hikiko|ln>   nvidia-361
<didrocks> yeah, so you need to remove any of those installed
<didrocks> just purge them
<hikiko|ln> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
<hikiko|ln> they seem purged
<didrocks> good :)
<hikiko|ln> maybe rdepends libcuda1-361?
<didrocks> you was able to delete it as well?
<didrocks> now, try to remove it
<didrocks> as it's what you wanted IIRC
<hikiko|ln> same
<hikiko|ln> E: Sub-process /usr/bin/dpkg returned an error code (1)
<didrocks> maybe zyga telling to downgrade nvidia on the proposed didn't indicate the right package
<didrocks> (I didn't follow closely)
<didrocks> ensure you don't have snapd from proposed from what I understand
<hikiko|ln> mmm how?
<didrocks> apt-cache policy snapd
<didrocks> do you have the proposed version installed?
<hikiko|ln> yes
<didrocks> so, same
<didrocks> revert to the one on xenial
<hikiko|ln> same :/
<hikiko|ln> if I purge snapd
<hikiko|ln> remove the package and reinstall it?
<hikiko> still :p just tried that
<lool> ogra_: Hey, around?
<lool> ogra_: were you the one implementing the dragonboard boot support?  :-)
<ara> zyga, ping
<mup> PR snapd#2064 opened: Adding new AutopilotIntrospectionInterface <Created by heber013> <https://github.com/snapcore/snapd/pull/2064>
<zyga> ara: hey
<zyga> ara: how can I help you
<ara> zyga, hey! I was wondering how the snap-confine SRU to xenial was going
<ara> zyga, any news?
<ara> zyga, (what's the bug report to track it?)
<zyga> ara: the status is that we landed one SRU last week but we need to go through all the bugs and verify those
<zyga> ara: I won't have time for this today as we're freezing now and I need to finish features first
<ara> zyga, where is the bug that tracks the SRU?
<zyga> ara: if you can help by asking anyone to go through all the SRU bugs on launchpad for snap-confine, we can do this faster
<zyga> ara: there's no one bug, each bug has SRU data now
<ara> zyga, perfect, I will check on the report page
<zyga> ara: look at milestones .40, .41 an.42
<zyga> ara: .42 has two bugs that don't have SRU data but I can add that quickly; this was a tiny release
<zyga> ara: if you can get me someone to work on validation I will save a lot of time
<ara> zyga, are you sure that the SRU landed in -proposed? I don't see it in the http://people.canonical.com/~ubuntu-archive/pending-sru.html
<zyga> ara: no, ah, sorry, too many facts lately, .41 was in -proposed but we removed it and someone should upload .42 now
<zyga> ara: (there's .42.1 but it doens't have to be released now)
<ara> zyga, can you organize uploading it, please? I can help verifying it
<zyga> ara: yes, I can
<zyga> ara: thank you :)
<ara> zyga, thanks you!
<ara> zyga, *thank
<zyga> joc: ok, branch comig up, just a simple unit test to tie it together
<zyga> joc: I will need you to add this udev rule manually to your device and see if it does the right thing
<zyga> joc: (no need to build/alter snapd)
<ogra_> lool, http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files ... there is a README ... gadget code is at http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/dragonboard/
 * ogra_ goes back to uniting :)
<joc> zyga: ack
<zyga> joc: ok, pull request is up, mup will share the link in a sec
<mup> PR snapd#2065 opened: interfaces/builtin: use udev to export GPIOs to userspace <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
<zyga> joc: look at tests, get the rule there and stick it into /lib/udev/rules.d/foo.rules
<zyga> joc: look at journal and run:
<zyga> joc: udevadm control --reload-rules
<zyga> joc: udevadm trigger
<zyga> joc: the first one should not be required but it's safe to run anyway
<zyga> joc: if I got this right it will export one GPIO to userspace
<zyga> joc: if not, well, iterate :)
<joc> zyga: got it, i'll just tidy up some testing i've been doing of netplan then get right on it
<oparoz> Hello, is there a solution in the works to upgrade from one Snap to another?
<zyga> joc: thanks, ping me when you got something
<zyga> oparoz: ?
<zyga> oparoz: can you explain what you mean by this
<oparoz> zyga myappv1 to myappv2
<zyga> oparoz: and what are myappv1 and myappv2?
<zyga> oparoz: snap names, snap versions, something else?
<oparoz> zyga, we can't force people to upgrade to v2, so we need a new snap, but then how do people migrate for v1 to v2?
<zyga> oparoz: why do you need a new snap?
<zyga> oparoz: and what do you mean by "we cannot force people to upgrade"
<oparoz> zyga, let's say I offer 3 years support for v1 and every time I release a new version
<zyga> oparoz: ah I see what you mean now
<oparoz> I mean every year, I release a new version
<zyga> oparoz: right now you'd have to indeed offer a second snap if you want to have a different snap that can be concurrently updated (or not)
<oparoz> zyga, so some users will want to stay on v1 for a long time and we can't just push v2 to the current dsnap
<zyga> oparoz: using the content interface you could offer data migration
<zyga> oparoz: I actually added support for this just now: https://github.com/snapcore/snapd/pull/2063
<mup> PR snapd#2063: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <https://github.com/snapcore/snapd/pull/2063>
<oparoz> zyga, ah interesting, I'll look into that
<oparoz> Thanks
<Mirv> stupid questions again, if I extend make plugin, with eg. command.extend("INCLUDEPATH ..., why do I get "make I N C L U D E P A T H + = " / h " type of output? ...
<cjwatson> Because you probably meant command.append
<cjwatson> command.extend takes a sequence
<zyga> yep
<cjwatson> So either command.append("...") or command.extend(["...", "...", ...])
<Mirv> ah, thank you, I'm happy someone endures me :)
<niemeyer> jdstrand: ping
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Today it's a bit of a critical day for us.. we want to get all the PRs to the freeze in place by the EOD
<niemeyer> jdstrand: How're things looking on your end?
<niemeyer> jdstrand: Would you be able to prioritize work that is freeze-related today?
<jdstrand> niemeyer: those PRs pedronis mentioned already are prioritized. is there anything beyond that?
<pedronis> jdstrand: IÂ should get a couple more
<pedronis> but nothing atm
<niemeyer> jdstrand: These are the top ones
<niemeyer> e.g. #2053 might be a good starting point
<niemeyer> snapd#2053
<mup> PR snapd#2053: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2053>
<jdstrand> niemeyer: that is next on the list
<niemeyer> jdstrand: Thanks!
<mup> PR snapd#2061 closed: interfaces: add dummy implementation of ResolveConnect <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2061>
<zyga> joc: any updates
<joc> zyga: done with netplan switching over now
<mup> PR snapcraft#846 closed: Release changelog for 2.19 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/846>
<zyga> joc: thanks!
<elopio> kyrofa: can you help me understand when to use SNAP_USER_DATA and when to use SNAP_USER_COMMON?
<kyrofa> Hey elopio! I'd be happy to
<kyrofa> What kind of app are we talking, here?
<kyrofa> Or just generic?
<elopio> kyrofa: I have two. syncthing, which is peer to peer file synchronization. And the mysql database of nylas sync-engine, which is an imap thing.
<kyrofa> elopio, so obviously since snaps are often made up of many components, you often find yourself with a few different datasets that need to be saved
<kyrofa> elopio, for each one, think about what should happen to it when an upgrade occurs
<kyrofa> You want to make sure the stuff you save won't get in the way of upgrades or rollbacks
<kyrofa> For example: does my dataset need to be mutated in some way for a few version?
<kyrofa> Or is it just raw data that isn't really modified?
<kyrofa> If new versions need to modify it, it's possible that the modifications aren't backward-compatible. Such datasets should probably go into SNAP_USER_DATA instead of COMMON, since each version has its own copy of that data
<kyrofa> And rollbacks will work, even if you mutate the data in newer versions
<elopio> it's hard, because I think the distinction is not designed in the tools. For example, syncthing has a home folder, where it stores the files to sync, and metadata.
<kyrofa> elopio, another aspect to consider is how much space is taken by the dataset. Is it massive? Does it make sense to copy it for every upgrade?
<elopio> I think the files to sync should be in common, the metadata in user_data, but I can't split them.
<kyrofa> elopio, indeed
<kyrofa> elopio, is it like the owncloud client? Where you add directories to a gui client?
<elopio> kyrofa: yes.
<kyrofa> elopio, or does it have only one directory?
<elopio> you have one default directory, which probably should be in SNAP_USER_COMMON/Sync, and then you can add additional
<kyrofa> And it saves metadata specific to that folder within each folder being synced?
<kyrofa> It doesn't have any sort of central database?
<elopio> kyrofa: it has a central config xml, and some certificates.
<kyrofa> elopio, where does that central config go?
<elopio> kyrofa: you start the server with synchting --home=$DIR.
<elopio> the config ends in that dir.
<kyrofa> elopio, could that not be SNAP_USER_DATA, then?
<elopio> yes, but then the default SYNC dir would also end up in ~/snap/syncthing/rev/.
<elopio> kyrofa: maybe you can comment here: https://github.com/syncthing/syncthing/pull/3636#discussion_r81488374
<mup> PR syncthing/syncthing#3636: Add the packaging metadata to build the syncthing snap <Created by elopio> <https://github.com/syncthing/syncthing/pull/3636>
<elopio> I'm sure you can explain it better than me.
<kyrofa> elopio, hmm... yeah, you probably don't want files accumulating there
<kyrofa> elopio, it's too bad they're so tightly coupled!
<elopio> kyrofa: the guy is really nice, I thing. So if we explain the thing, probably he can add a separate flag for default sync dir.
<kyrofa> elopio, this looks like an old diff. What is SNAP_USER_DIR?
<elopio> but as I understand, the answer to his question is: the config should be in SNAP_USER_DATA, just like it's currently doing.
<elopio> kyrofa: a mistake. I just removed it.
<kyrofa> Ah, now there's no flags
<elopio> if you don't pass -home, it will use $HOME.
<kyrofa> Okay, I'll make a comment here
<elopio> thank you.
<kyrofa> Argh, firefox! I had a comment all written out...
<kyrofa> Oh it saved it. Nice
<sergiusens> elopio hint, snapcraft/xenial-proposed ;-)
<elopio> sergiusens: \o/
<elopio> ah, I don't have the tests prepared this time.
<mup> PR snapd#2063 closed: interfaces,docs: allow sharing SNAP{,_DATA,_COMMON} via content iface <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2063>
<Croepha> hi, in core 16, can you disable nplan and use the older /etc/network/interfaces.d/... files?
<kyrofa> Croepha, probably a question for ogra_
<mup> PR snapd#2057 closed: docs: remove references to removed buying features <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2057>
<Croepha> on core is /etc/passwd supposed to be writeable ?
<Croepha> kyrofa, thanks, but I think i figured out the nplan thing, it seems that if you just delete the nplan config, it will use the old config
<Croepha> now im having a dfferent issue, on reboot, I cant login or change passwd, debug console works though, so I got a root terminal of sorts
<mup> PR snapd#2041 closed: daemon: add `snap create-user --force-managed` support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2041>
<joc> zyga: it doesnt look like the command is being run
<joc> zyga: it may be because there isnt an "add" event
<joc> i don't see one if i use udevadm monitor
<mup> PR snapd#2047 closed: snap: auto mount block devices and import assertions <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2047>
<Croepha> ok, so after digging, it looks like core now uses pam_extrausers, so setting root passwd isn't going to be possible under this plan, and adding a user is adduser --extrausers ...
<mup> PR snapd#2060 closed: many: change Connect to take ConnRef instead of strings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2060>
<modprobe__> What plug should I use to get access to /dev/{,u}random?
<mup> PR snapcraft#824 closed: Add `snapcraft create-key` <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/824>
<elopio> ogra_: are you around? There's a new snapcraft release in proposed.
<sergiusens> marcoceppi or here if rocket is not possible :-)
<zyga> pitti: hey
<zyga> pitti: I'm trying to write an udev rule that will export a gpio by writing to /sys/class/gpio/export
<zyga> pitti: the constraint is that after that I call "udevadm trigger"
<zyga> pitti: is there anything sensible I can put into my rule to tie it into an event?
<zyga> pitti: it should work both immediatly after "udevadm trigger" returns and on boot
<zyga> joc: ^^
<kyrofa> jdstrand, it doesn't look lik /dev/random (and similar) are contained in the default profiles. Are they not safe for access?
<zyga> kyrofa: you can easily consume all entropy
<kyrofa> jdstrand, though getrandom is available
<zyga> kyrofa: and DOS other programs
<kyrofa> zyga, ah, sure. Do we have an interface for such things, then?
<jdstrand> kyrofa: they are safe and available in all profiles via the base abstraction
<kyrofa> jdstrand, ah ha, okay
<zyga> kyrofa: ah, jdstrand knows better :)
<jdstrand> kyrofa: you may want to look at 'apparmor_parser -p /path/to/profile' to see all the policy with the abstractions
 * kyrofa needs to read the base abstraction
<zyga> jdstrand: so I _can_ write a heatdeathoftheuniverse snap?
<kyrofa> Or that! Thanks jdstrand :)
<mup> PR snapd#2053 closed: interfaces/policy: implement snap-id/publisher-id checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2053>
<mup> PR snapd#2051 closed: many: setup snapd macaroon for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2051>
<joc> zyga: yep that is the question i was trying to ask, bad English on my part!
<joc> zyga: i just tried by removeing the ACTION= altogether
<joc> (can't spell now either)
<joc> zyga: it made sure the gpio was always exported, but you couldnt unexport as the rule was always matched
<zyga> jdstrand: hey, can you please upload .42 from yakkety to xenial, ara's team will do the valiation and work on SRU
<zyga> jdstrand: the lack of "undo" is fine for now
<jdstrand> ok
<zyga> jdstrand: thanks
<mup> PR snapd#2066 opened: many: abbreviated forms of disconnect <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/2066>
<mup> PR snapd#2067 opened: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
<elopio> kyrofa: sorry, you told me to test. I have this for you:
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1629955
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1629957
<mup> Bug #1629955: rosdistro is not documented in the catkin plugin help <Snapcraft:Triaged> <https://launchpad.net/bugs/1629955>
<mup> Bug #1629957: When I try to build a snap with the wrong catkin rosdistro, there is no good error <Snapcraft:Triaged> <https://launchpad.net/bugs/1629957>
<kyrofa> elopio, ah, very good!
<kyrofa> elopio, this is why I ask you to test ;)
<kyrofa> Man, rosdistro has been around forever, I didn't even check the docs assuming they were good :P
<kyrofa> elopio, blocking, you think? Or no?
<elopio> sometimes I get depressed. No piece of software ever works for me on the first try. /o\
<kyrofa> (I don't think these are new bugs)
<elopio> kyrofa: no, medium and low. To fix when you have some time.
<kyrofa> elopio, well good find, thank you!
<kyrofa> elopio, you're QA. Finding bugs should make your day!
<elopio> that's ok when I try to break it on purpose. Not so nice when I'm just trying to use things.
<mup> PR snapd#1970 closed: interface/builtin: add ptrace support to system-trace <Created by niedbalski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1970>
<mup> PR snapd#1945 closed: debian, tests: add trusty tests <Reviewed> <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1945>
<modprobe__> jdstrand, kyrofa: Does that mean /dev/urandom is available by default? It appears not to be working, though I don't know of an easy way to pop a shell in the sandbox to find out for sure.
<modprobe__> As to consuming all available entropy, random has that issue, but not urandom, and I understand that urandom is regarded as every bit as good of a CSPRNG as random (better, since it should always work)
<mup> PR snapd#2055 closed: interfaces/policy,overlord: check connection requests against the declarations in ifacestate <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2055>
<mup> PR snapd#2062 closed: interfaces/policy: introduce InstallCandidate and its checks <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2062>
<kyrofa> modprobe__, indeed, it should work
<mup> PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
<modprobe__> kyrofa: Hmm... Well my program indicates pretty clearly that it doesn't. Botan throws an exception saying "System_RNG failed to open RNG device" and looking at its source, the only way that exception gets thrown is if opening /dev/urandom fails.
<kyrofa> modprobe__, I'm not claiming you aren't running into issues, I'm just saying confinement shouldn't be causing it :) . Do you see apparmor denials in syslog (or from snappy-debug)?
<modprobe__> kyrofa: Ahh yes, I see this in dmesg: audit: type=1400 audit(1475513126.687:37): apparmor="DENIED" operation="open" profile="snap.stakeweightedvoting.app" name="/dev/urandom" pid=6341 comm="VotingApp" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
<kyrofa> modprobe__, it's trying to _write_ to it?
<kyrofa> Indeed, the profile is only r
<modprobe__> https://botan.randombit.net/doxygen/system__rng_8cpp_source.html (line 77) apparently, it is...
<kyrofa> modprobe__, I can't imagine why... ?
<modprobe__> Looks like a bug in botan.
<kyrofa> Agreed
<modprobe__> I'm reporting it to them. In the meantime, can you think of any workaround I can use until they release a fix?
<kyrofa> modprobe__, would it be an easy patch?
<modprobe__> Yeah, I could just use a custom build of botan...
<kyrofa> modprobe__, yeah, that's what I'd recommend
<modprobe__> Should literally just be changing that one line.
<kyrofa> modprobe__, as a plus, you can propose it back upstream ;)
<modprobe__> Yeah, I just made an issue on their github repo and I'll follow it up with a pull request soon, assuming it passes the smoke test. :)
<elopio> cprov: I don't quite understand the sign-build --local. It always replies that "A signed build assertion for this snap already exists."
<elopio> ah, I think that a previous command left the -build file. But it was empty.
<elopio> I'll try to reproduce that.
<sergiusens> elopio you only sign once per build
<elopio> sergiusens: cprov: https://bugs.launchpad.net/snapcraft/+bug/1629984
<mup> Bug #1629984: trying to sign-build without keys leaves a -build file, empty <Snapcraft:Triaged> <https://launchpad.net/bugs/1629984>
<modprobe__> kyrofa: Apparently writing to random or urandom is a way to add entropy to the kernel pool. Maybe the AppArmor profile should be updated?
<kyrofa> modprobe__, hmm interesting, jdstrand is the guy to consider that. Not sure what the ramifications would be
<jdstrand> we'd need a new interface for that
<jdstrand> I think. please file a bug
<kyrofa> modprobe__, regardless, the fact that the thing dies if it can't add entropy still seems like a bug
<mup> PR snapd#2059 closed: interfaces: add repo.ResolveConnect that handles name resolution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2059>
<modprobe__> kyrofa: Very true.
<elopio> cprov: now without a body, I get: "no assertion found in request body". Tried on staging and production with a test user.
<elopio> is that because my user is not allowed, or something?
<modprobe__> jdstrand: Is that a bug on snapd?
<kyrofa> modprobe__, indeed
<modprobe__> Alright, I'll file that soon
<cprov> elopio: thanks for filing the bug, the stray/empty -build should not be there.
<elopio> np
<elopio> ralsina: I'm getting this:
<elopio> $ snapcraft validate u1test20161003 ubuntu-core=1
<elopio> Getting details for u1test20161003
<elopio> Snap 'u1test20161003' was not found in the 'stable' channel.
<elopio> But I've just released the snap to stable on staging. Am I doing something wrong herE?
<elopio> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1629472/comments/3
<mup> Bug #1629472: [SRU] New stable micro release 2.19 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1629472>
<elopio> I'm going for lunch. I'm just missing the happy paths of gated and validate.
<marcoceppi> sergiusens: o/
<marcoceppi> sergiusens: I'm technically not working today, so I haven't been around my computer as much
<cprov> elopio: ralsina is off today, can you run `snapcraft gated u1test20161003` ?
<elopio> cprov: $ snapcraft gated u1test20161003
<elopio> Name    Approved
<elopio> prints nothing. I reported a bug about that, too.
<elopio> https://bugs.launchpad.net/snapcraft/+bug/1629991
<mup> Bug #1629991: snapcraft gated prints no message when there are no gated snaps <Snapcraft:New> <https://launchpad.net/bugs/1629991>
<cprov> elopio: I can see your rev. 1 in stable, curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.staging.ubuntu.com/api/v1/snaps/details/u1test20161003?channel=stable | jq-cprov.jq '.revision'
<elopio> cprov: yes. But the message says it's not found.
<cprov> elopio: can you try `snapcraft validate u1test20161003 ubuntu-core=1` again, so we can confirm it was hitting bad-caching in staging CPI
<elopio> cprov: done. Same error.
<cprov> elopio: okay, it will need some code changes as well, I've mentioned multiple time in the review that gating snap-id would be better resolved via the SCA account-info, somehow it slip and the code in trunk is using CPI. I will get into this asap
<cprov> elopio: is it blocking snapcraft release ?
<elopio> cprov: thanks. And I don't know if it should block it. It's ugly to release a command that doesn't work, but sergiusens can just not mention it in the release notes.
<elopio> sergiusens: your call.
<mup> PR snapd#2046 closed: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2046>
<modprobe__> kyrofa, jdstrand: Bug report filed at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1629996
<mup> Bug #1629996: Cannot open /dev/random and /dev/urandom for write <snapd (Ubuntu):New> <https://launchpad.net/bugs/1629996>
<sergiusens> cprov yeah, big branches can cause that ;-)
<mup> PR snapd#1874 closed: snap: support assertion references in `snap prepare-image` <Reviewed> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1874>
<cprov> sergiusens: good point
<mup> PR snapd#1767 closed: overlord, daemon: add collect attribute hooks <Reviewed> <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1767>
<mup> PR snapd#1613 closed: interfaces/builtin: add dbus-app interface <Blocked> <Reviewed> <Created by jdstrand> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1613>
<mup> PR snapd#2067 closed: cmd/snap: trivial auto-import and download tweaks <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2067>
<lool> ogra_: thanks, description of the boot files is pretty slick
<jgdx> what's the status on Ubuntu Core on RP3? Google returns a AskUbuntu link which is not super up to date
<jgdx> ogra_, you know? ^
<lool> ogra_: I was actually pinging because of the upcoming dragonboard 600 that you might have seen announced recently
<lool> jgdx: pi ?
<lool> jgdx: there's a beta image for rpi3 like for the other supported platforms: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
<jgdx> lool, cool, thank you
<mup> PR snapd#2068 opened: many: preparations for switching most of autoconnect to use the declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2068>
<lool> ogra_: the 600 doesn't have an u-boot port, so we can't follow the same path
<lool> ogra_: and there's worth, there might be boards requiring UFS too; at which point we will need a much more complete u-boot
<lool> *worse
<elopio> cprov: sergiusens: also branches without staging integration tests ;)
<cprov> elopio: yeah, it will definitely serve a lesson.
<mup> PR snapd#2069 opened: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2069>
<sergiusens> elopio cprov from the point of view of the project, it is already released, so not much we can do as soon as it lands on master
<sergiusens> elopio I propose to you to do this testing now for history and status ;-)
<jgdx> pi3 using that beta image gives me four berries, but nothing more
<cprov> elopio: you have to set a new env var for staging UBUNTU_STORE_SEARCH_ROOT_URL='https://search.apps.staging.ubuntu.com/' to make validation work :-/
<cprov> elopio: that's why you gating snap was not found.
<mup> PR snapd#2069 closed: overlord/auth: update CheckMacaroon to verify local snapd macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2069>
<mwhudson> niemeyer: hey, am i right to think that console-conf should not run if the device is managed?
<mwhudson> niemeyer: there is a potential hole where if you use a autoload.assert file to add a user that only has ssh keys and no password and the default network config doesn't work for whatever reason you'll be stuck
<mwhudson> the alternative is that console-conf still runs but only presents the network config screen, not the "please enter email" screen
<mup> PR snapd#2070 opened: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <https://github.com/snapcore/snapd/pull/2070>
<mup> PR snapcraft#847 opened: Implementing channel-closing <Created by cprov> <https://github.com/snapcore/snapcraft/pull/847>
<kgunn> kyrofa: you about?
<kyrofa> kgunn, I am, what's up?
<kgunn> kyrofa: curious, what is the philosophy behind something becoming an official snapcraft part ?
<kgunn> https://wiki.ubuntu.com/snapcraft/parts
<kgunn> i had someone ask about qtmir and mirclient libs becoming "snapcraft parts"
<kgunn> but unsure it makes sense
<kgunn> as these are something that are currently in the archive and can easily be listed as a part
<kgunn> in the yaml
<kgunn> under a nil plugin
<kyrofa> kgunn, anything that seems generally useful. If building qtmir for snappy takes a lot of weird config flags, for example, you could make it a part so other people could just say "build qtmir" instead of "ack, how do I build qtmir"
<kgunn> kyrofa: hmm, yeah i don't think there's anything special there...
<kgunn> definitely not weird
<kyrofa> Yeah, if they can just use the archive packages then it's less useful. Still potentially useful from the point of view that it's less typing, but it's of limited usefulness, certainly
<kyrofa> kgunn, nothing wrong with adding it, but don't feel obligated
<kyrofa> kgunn, now, if you find yourself constantly asking "how do I get mir in a snap," then you could save yourself some time
<kyrofa> Not asking, answering
<sergiusens> cprov elopio fwiw, it is in the instructions and I was succesful gating and validating a bunch of snaps (even private ones iirc)
<Pharaoh_Atem> zyga: this could be quite interesting for fedora's snappy stuff: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FUWLJQYQJAGNGSSFTCA3ZEHAX43LJ7UU/
<kgunn> kyrofa: so it can be used as a template aswell ?
<kgunn> i mean the mir-client snap is a template of sorts...but the qtmir and libmirclient are just pkg listings under parts
<kgunn> the only thing of interest is the helper file
<kgunn> that sets environ flags
<kgunn> like  http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start
<mwhudson> wheee funtimes https://github.com/snapcore/snapd/pull/2044#issuecomment-251241964
<mup> PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
<mup> Bug #1630036 opened: auto import of assertions fails for devices present at boot <Snappy:New> <https://launchpad.net/bugs/1630036>
<jdstrand> zyga: fyi, filed bug #1630040
<mup> Bug #1630040: [SRU] update to 1.0.42 <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress by zyga> <snap-confine (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1630040>
<jdstrand> zyga: will upload in a bit
#snappy 2016-10-04
<elopio> cprov: sergiusens: hey, sorry, I couldn't access quassel for quite a while. Indeed, I had a typo on my exported var :/
<elopio> sorry for the noise.
<mup> PR snapd#2071 opened: interfaces,overlord/interfaces: switch to use declaration-based checking for auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/2071>
<mup> PR snapd#2072 opened: cmd/snap: have 'snap autoimport' consider unmounted devices <Created by mwhudson> <https://github.com/snapcore/snapd/pull/2072>
<mup> PR snapd#2068 closed: many: preparations for switching most of autoconnect to use the declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2068>
<sergiusens> elopio cprov I am not oposed to a tools/staging_env.sh that one can source setting up the env and PS1 ;-)
<cprov> sergiusens: that's a grand idea
<sergiusens> cprov elopio I am on and off, but here's a bug just in case it falls off the radar LP: #1630083
<mup> Bug #1630083: Provide sourceable script to work with the staging environment <Snapcraft:New> <https://launchpad.net/bugs/1630083>
<mup> PR snapd#2073 opened: client, cmd/snap, daemon: add is-managed command <Created by mwhudson> <https://github.com/snapcore/snapd/pull/2073>
<pitti> zyga: udev rules are all about events; so both a boot aand udevadm trigger will run every rule, so just attach it to teh "add" event of a device which provides the GPIO pins?
<pitti> zyga: /sys/class/gpio/export, is that really a global thing? that doesn't sound like something you should change in udev rules then
<pitti> or was that just simplifid/a template path?
<mup> PR snapd#2074 opened: add /users endpoint and auto run `snap create-user --known` for unowned devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2074>
 * kalikiana found bug 1576303 whilst trying to listen to Japanese music on the VLC snap
<mup> Bug #1576303: Needs fontconfig integration <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576303>
<dholbach> good morning
<shuduo> morning
<zyga> pitti: it wasn't simplified, that's the actual thing
<shuduo> could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks
<mup> Bug #1615124: apps should be able to run /usr/bin/shuf by default <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1615124>
<mup> PR snapd#2073 closed: client, cmd/snap, daemon: add is-managed command <Created by mwhudson> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2073>
<mup> Bug #1630145 opened: out of disk space needs better handling <Snappy:New> <https://launchpad.net/bugs/1630145>
<mup> PR snapd#2075 opened: cmd/snap: add version command, same as --version <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2075>
<mup> PR snapd#2026 closed: client, cmd: connect fixes <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2026>
<morphis_> zyga: ping
<ara> pitti, hello! would you approve snap-confine into xenial-proposed, please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snap-confine
<zyga> morphis_: hey
<morphis_> zyga: hey!
<zyga> morphis_: sorry, I'm laggy, not slept much last night
<morphis_> zyga: np :-)
<morphis_> zyga: you already did the PR to fix the mount problem we have with the udisks2 snap?
<morphis_> was looking for it but didn't found one?
<morphis_> s/one/one?/
<zyga> morphis_: no, though almost, I need to work on the all-snap side of the problem
<morphis_> zyga: what is different there?
<zyga> morphis_: the initial fs is /
<zyga> morphis_: https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9
<zyga> morphis_: I need to finish one more bit for snapd and then I'm back to confine, we're freezing this week
<zyga> (well, today)
<morphis_> zyga: actually this is required to be fixed before the freeze
<zyga> morphis_: we can still change images after today so it will get fixed
<zyga> morphis_: it will be in the released images
<Skuggen> dpkg: error processing archive /var/cache/apt/archives/snapd_2.15.2ubuntu1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snap 2013-11-29-1ubuntu2
<Skuggen> :)
<morphis_> zyga: so by when? last week you said there will be a PR later that day
<zyga> Skuggen: I think it is a known issue, I think it was fixed but perhaps that's not the case
<zyga> morphis_: I spent literelly two weeks on this issue
<zyga> morphis_: there's lots of hard edges there
<Skuggen> zyga: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/1589037 just confirmed so far
<mup> Bug #1589037: package snap (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/snap.1.gz', which is also in package snapd 2.0.5 <amd64>
<mup> <apport-package> <package-conflict> <xenial> <One Hundred Papercuts:Confirmed> <snap (Ubuntu):Invalid> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1589037>
<morphis_> zyga: good, so do you need any further help? Lean suggested to ask Seth to help you with any further problems on the mount namespace
<zyga> morphis_: I'd love some help on that if you want to, we know how it works now but the all-snap is significantly different that someone has to sit on it and push through the issues
<zyga> morphis_: well, the mount namespace has been released, this is /media sharing
<zyga> morphis_: it's not a problem of "how do we do it" anymore, that part is solved
<zyga> morphis_: this is just some extra coding time that's required now
<morphis_> zyga: so what the actual issues?
<zyga> morphis_: take that branch and iterate on an all-snap system, it needs to be tweaked to use different rootfs_dir and the apparmor profile needs to be adjusted
<zyga> morphis_: then if it doesn't crash the kernel and /proc/self/mountinfo looks sane then we're good
<zyga> morphis_: apparmor profile needs to be cleaned up a little as it it now full of redundant rules
<zyga> morphis_: it just need polish
<morphis_> zyga: which branch?
<zyga> morphis_: https://github.com/snapcore/snap-confine/commits/media-sharing
<zyga> morphis_: I don't recommend anthing but a full blown VM
<zyga> morphis_: one line wrong and you hose your box
<zyga> morphis_: it would be amazing if we managed to run spread on master (not this branch) on an all-snap system
<zyga> morphis_: in qemu or linode
<zyga> morphis_: if you could get that, it would save me a lot of time
<zyga> morphis_: I think qemu is easier and I would find it sufficient
<morphis_> zyga: I must say I don't see where the actual rootfs change would come into this code change
<zyga> morphis_: look at the new struct
<zyga> it is called...
<zyga> rootfs_dir :)
<zyga> https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9#diff-0ec19215f6a6c97084d2e4eb5e0b54ccR546
<morphis_> ah
<morphis_> zyga: there seem to be a lot other TODO's
<zyga> morphis_: specifically?
<morphis_> I count atleast three from the commit message
<zyga> morphis_: ah, some of those are stale
<zyga> morphis_: if spread passes you're in good shape
<zyga> morphis_: I think /etc needs love on actual sharing
<zyga> morphis_: it works but I think it's setup wrong
<morphis_> zyga: so what else do you have on your plate which prevents you from finishing this?
<zyga> morphis_: just one branch on snapd, carry over from last night
<zyga> https://github.com/snapcore/snapd/pull/2066 specifically
<mup> PR snapd#2066: many: abbreviated forms of disconnect <Created by zyga> <https://github.com/snapcore/snapd/pull/2066>
<morphis_> zyga: which would mean you will get back to the snap-confine later today?
<zyga> morphis_: yes, totally
<zyga> morphis_: nothing else on my plate
<morphis_> zyga: I don't really have much time to support here and it looks like you're the best to get this fixed quickly
<morphis_> zyga: so how much more time you need to finish this?
<zyga> morphis_: I think one more day, I bet the non-all snap version will be 100% done today, including nice aa profile, the all-snap is probably trivial but maybe there are dragons, I didn't try yet
<morphis_> zyga: non-all snap is not really the problem, we need this for all-snap
<morphis_> in the end we want both but all-snap should be IMHO the priority
<zyga> morphis_: it needs to work in both cases but I think we're very very close
<morphis_> yeah
<zyga> morphis_: just figuring out the sequence of do's and don'ts was the hard part :)
<Skuggen> How does snappy figure out dependencies for simple binary inclusions? run ldd?
<mup> PR snapd#2076 opened: asserts: limit model to only lowercase until we can implement case insensitive/preserving headers <Created by pedronis> <https://github.com/snapcore/snapd/pull/2076>
<mwhudson> Skuggen: yes, i think so
<morphis_> sergiusens: ping
<shuduo> could anyone educate me how to call /sbin/ifconfig in a snap app? i see some relative discussion in https://bugs.launchpad.net/snappy/+bug/1615124 but no idea how to use and which interface is right one. thanks
<mup> Bug #1615124: apps should be able to run /usr/bin/shuf by default <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1615124>
<zyga> shuduo: hey
<shuduo> zyga: hi
<zyga> shuduo: please use the network-control interface
<zyga> :-)
<shuduo> zyga: yes, i added it but snappy-debug still report "Log: apparmor="ALLOWED" operation="create" profile="snap.connman.connman//null-/sbin/ifconfig" pid=7741 comm="ifconfig" family="unix" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create" addr=none"
<shuduo> so i guess some lines needed in snapcraft.yaml too
<zyga> hmmm
<zyga> that may depend on what you use ifconfig for
<zyga> can you pease file a bug on snappy (on launchpad) with more informatio
<zyga> it is much better than figuring it out here, most of the team is busy working on the release
<zyga> and some last few bits for it
<shuduo> zyga: okay. understand. i will. do you know if any exist snap use ifconfig then i can refer to?
<zyga> shuduo: I don't know, sorry
<shuduo> zyga: no worry. thanks.
<ogra_> ppisati, regarding the question in bug 1627643 i think you ned to ask mwhudson or pitti
<mup> Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643>
<ogra_> (not sure it is actually possible at all to run nplan on a xeianl classic install)
<ogra_> *xenial
<ppisati> ogra_: does it need yakkety?
<pitti> ogra_: it  will be soon, see bug 1627641
<mup> Bug #1627641: Backport netplan to xenial <verification-needed> <network-manager (Ubuntu):Fix Released> <nplan (Ubuntu):Fix Released> <systemd (Ubuntu):Fix Released> <network-manager (Ubuntu Xenial):Fix Committed by pitti> <nplan (Ubuntu Xenial):Fix Committed by pitti> <systemd (Ubuntu Xenial):In
<mup> Progress by pitti> <https://launchpad.net/bugs/1627641>
<ppisati> ogra_: i can build a yakkey img if needed
<ogra_> ppisati, well, the userspace would be totally different and we dont have yakkety snappy
<ogra_> (i mean snappy images ... classic + snap might work)
<ppisati> ogra_: yeah, but you said 'not sure it is actually possible at all to run nplan on a xeianl classic install' so i thought you needed some yakkety bits
<ogra_> ppisati, yes, netplan :)
<ogra_> (and its dependencies)
<ogra_> ppisati, i also have the impression it is somehow related to firstboot  i seem to not get the oops on second boot either here
<sergiusens> morphis hello hello
<ppisati> ogra_: but do you actually get an oops? because on first boot, my wifi doesn't get any ip and nothing is printed out
<ppisati> ogra_: just a generic 'Fail to blabla' from nplan
<ppisati> ogra_: and upon reboot, my wifi associated immediately
<ogra_> ppisati, i only see the wifi interface very rarely (every 10th boot or so)
<ppisati> but no oops at all
<ogra_> most of the time there is the oops and the device isnt shown at all in console-conf
<ppisati> so it's before the config phase the oops
<ogra_> the prob iss that a reboto breaks the image completely
<ogra_> *reboot
<ogra_> (the snappy firstboot stuff only runs after console-conf completed ... and it breaks if it gets re-run on an already booted image)
<ogra_> niemeyer, mvo, bug 1630145 made me think ... unrelated to diskspace, snapd should probably run with an oom_score_adj "- 500" value ... so it doesnt get killed early on OOM events
<mup> Bug #1630145: out of disk space needs better handling <Snappy:New> <https://launchpad.net/bugs/1630145>
<mup> PR snapd#2077 opened: overlord/devicestate,docs/hooks.md:  switch prepare-device/registration opts to use nesting, some hook docs  <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2077>
<ogra_> mvo, niemeyer, i filed bug 1630208 for the above
<mup> Bug #1630208: snapd should be excluded from OOM <Snappy:New> <https://launchpad.net/bugs/1630208>
<zyga> oh interesting
<mup> Bug #1630208 opened: snapd should be excluded from OOM <Snappy:New> <https://launchpad.net/bugs/1630208>
<mup> PR snapd#2064 closed: interfaces/builtin: add autopilot-introspection <Blocked> <Created by heber013> <Closed by heber013> <https://github.com/snapcore/snapd/pull/2064>
<didrocks> sergiusens: hey! small quetsion, I can't find the bug reference anymore, but I'm pretty sure there was one on organize: not supporting globbing (so that you can dump the copy plugin in favor ofâ¦ dump!), do you think you have time working on tihs?
<didrocks> this*
<sergiusens> didrocks it is already released
<didrocks> oh
<didrocks> it's the version in -proposed?
<didrocks> that's probably why I couldn't find it :)
<didrocks> didn't check for closed ones
<sergiusens> didrocks https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_pluginhandler.py#L676
<sergiusens> didrocks should be in -updates since 3 or 4 weeks ago
<didrocks> sergiusens: interesting, I was sure I tried a couple of weeks ago
<didrocks> sergiusens: so "*" : "www/" should work from what I see in the test
<sergiusens> didrocks yes
<sergiusens> didrocks if not, we have  anew bug :-(
<didrocks> sergiusens: oh, I did try ".": "www" as in the copy plugin
<didrocks> probably
 * didrocks gives it a try
<sergiusens> oh, different semantics indeed
<didrocks> I prefer *, makes more sense IMHO
<didrocks> sergiusens: so, I'm getting: Trying to organize file '*' to 'www', but 'www' already exists
<didrocks> something (I guess snapcraft) did create indeed a "www" file
<didrocks> I want to put everyting in www
<didrocks> maybe the syntax is rather: "*": "www/"
<didrocks> sergiusens: that did it! Thanks a lot :)
<sergiusens> didrocks \o/
<jdstrand> shuduo: please file a bug at https://bugs.launchpad.net/snappy/+filebug with steps to reproduce. you should be using 'plugs: [network-control]' to use ifconfig, however, connman is doing something different with ifconfig that isn't included in the policy atm
<abeato> jdstrand, hi, thanks for the thorough review. I have pushed changes to the PR, with a couple of questions too
<jdstrand> ok
<jdstrand> thanks :)
<abeato> sergiusens, I was wondering about your opinion on using config flags to set file paths when compiling using autotools snapcraft plugin
<shuduo> jdstrand: it's a customer's app intend to do what connman doing. i'm trying to get source code.
<abeato> sergiusens, we are checking $SNAP in some programs to know if it is part of a snap or not
<abeato> sergiusens, maybe using a standard configure flag would be better and make changes more palatable for merging in upstreams
<jdstrand> shuduo: it's possible to debug via irc. do you have time now?
<shuduo> jdstrand: i have time but don't have source code. is it possible? :)
<sergiusens> abeato that's what we did for click; a nice configure flag we can standarize on would be great practice; all these configure flags are just convention after all
<jdstrand> shuduo: yes, I'll give you rules to add and you tell me what you see in the logs
<shuduo> jdstrand: good
<abeato> sergiusens, promoting a couple of standard configure flags would certainly be great :)
<jdstrand> shuduo: first off, does your app require devmode for other things or are you using devmode only for this one denial?
<abeato> sergiusens, maybe paths to data, to daemon data, and to current snap
<shuduo> jdstrand: i already use devmode in yaml and also installation.
<jdstrand> shuduo: you misunderstand. must you use devmode? I'd prefer to use strict mode for policy debugging but if your app doesn't work at all in strict mode, then we can leave it
<shuduo> jdstrand: okay. let me modify it.
<shuduo> jdstrand: i thought if devmode works then i can try strict mode.
<jdstrand> shuduo: you are doing the right thing. but for security policy development I prefer strict mode
<shuduo> jdstrand: i changed it to strict and scanlog output is http://pastebin.ubuntu.com/23274922/.
<jdstrand> shuduo: can you give the output of 'snap interfaces'?
<shuduo> jdstrand: http://pastebin.ubuntu.com/23274935/
<jdstrand> shuduo: please connect the interfaces with:
<jdstrand> sudo snap connect connman:firewall-control ubuntu-core:firewall-control
<jdstrand> sudo snap connect connman:network-control ubuntu-core:network-control
<jdstrand> sudo snap connect connman:network-manager ubuntu-core:network-manager
<jdstrand> (though I wonder about that last one-- is it supposed to talk to NetworkManager?
<jdstrand> )
<shuduo> jdstrand: now output is http://pastebin.ubuntu.com/23274944/
<shuduo> seems no complain for ifconfig
<jdstrand> shuduo: ok, so your snap has a little bit of work to do to make ListOfServers.txt relocatable, but we can hopefully work around that
<jdstrand> shuduo: oh, would you have seen the ifconfig denial by this point?
<shuduo> jdstrand: no ifconfig denial now.
<jdstrand> shuduo: ok, so maybe you just needed to connect the interfaces. you need to do that in devmode too
<shuduo> jdstrand: in ubuntu desktop, the app will create a file ListOfServvers.txt in working directory.
<jdstrand> (in devmode if you don't connect, the accesses that are against policy are allowed, but logged. to make the logging go away, connect the interfaces)
<jdstrand> shuduo: you should 'cd "$SNAP_DATA"' before starting-- or choose one of the other SNAP_* variables
<jdstrand> shuduo: and by 'you', I mean your snap
<shuduo> jdstrand: so i guess i need a wrapper to 'cd "$SNAP_DATA"', right?
<jdstrand> shuduo: yes
<shuduo> jdstrand: in strict mode, the app will exit with "Failed to open default display". In devmode, it exit with "XOpenIM() failed. Unable to find fonts. check your FontConfig configuration." i claimed unity7 in snapcraft.yaml. anything missed?
<mup> PR snapd#2078 opened: daemon: fix login API to return local macaroons <Created by matiasb> <https://github.com/snapcore/snapd/pull/2078>
<jdstrand> shuduo: we are getting out of my area of expertise (I work on security policy). I suspect you need to use the desktop/gtk3 part
<jdstrand> shuduo: eg:
<jdstrand> parts:
<zyga> jdstrand: hey, how are you
<jdstrand>   something:
<jdstrand>   ...
<jdstrand>   after: [desktop/gtk3]
<jdstrand> meh
<jdstrand> parts:
<jdstrand>   something:
<jdstrand>     ...
<jdstrand>     after: [desktop/gtk3]
<jdstrand> shuduo: something like that ^, but will need others in the channel to help if that doesn't work for you
<jdstrand> zyga: hi! :)
<shuduo> jdstrand: okay. thanks a lot!
<mup> PR snapd#2079 opened: tests: use test snap from the store in the content interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2079>
<mup> PR snapd#2080 opened: daemon: do not hardcode UID in userLookup <Created by mvo5> <https://github.com/snapcore/snapd/pull/2080>
<lool> ogra_: would you by any chance now where the ubuntu-core snaps are built for stable and edge?
<ogra_> lool, we only build edge and propagate it ATM ...
<ogra_> lool, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core
<ogra_> lool, plan is to have all PPA bits SRUed by GA and then build beta/candidate without the PPA ... but keep edge on PPA with daily builds
<lool> ogra_: is there a cron scheduling this daily?
<ogra_> lool, yep
<lool> oh we even build it on s390x and ppc64el
<ogra_> ogra@lillypilly:~$ crontab -l
<ogra_> 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1
<ogra_> 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1
<ogra_> ogra@lillypilly:~$
<lool> ogra_: ah I see we do the extra ppa thing in livecd-rootfs
<lool> snappy-dev/image snappy-dev/edge
<ogra_> right
<ogra_> for beta/candidate we'll have a branch with this dropped
<lool> and edge has daily github builds of master I guess
<lool> https://launchpad.net/~snappy-dev/+archive/ubuntu/edge
<lool> ouch loads of stuff in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> lool, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<ogra_> thats the long term plan
<ogra_> lool, well, you want https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
<lool> ogra_: if I look at xenial, there are 3 uploads from you which are superseded that we might be able to drop
<lool> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
<ogra_> lool, not yet ... they are in -propposed (LP UI lies)
<ogra_> apart from snapcraft i think
<ogra_> that can actually be dropped
<ogra_> ah, no, not yet
<ogra_> but yeah, i check it every day
<lool> ogra_: ok, nice
<ogra_> for initramfs-tools i'm waiting til cyphermox and lamont are done with theit ipv6 hackery before even attempting to land the fixtrc fix
<ogra_> *their
<ogra_> i dont want to cause mid-air clashes of uploads there
<lool> I wonder if we should have snap-confine from edge too
<lool> it's recent in the image PPA though
<mvo> pitti: did you had a chance to check https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531 ? sorry for the nudge, its somewhat urgent for the team that works on that
<ogra_> lool, perhaps
<ogra_> lool, thats a zyga decision :)
<ogra_> lool, oh, and on a sidenote we also have daily images built from the edge snap http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ogra_> s/snap/snaps/
<lool> ah that's useful
<lool> albeit I can just switch to edge ubuntu-core if I need that
<ogra_> (these builds happen on my home desktop and get rsynced though ... waiting for infinity to get use dailies on cdimage)
<ogra_> s/use/us/
<mup> PR snapd#2080 closed: daemon: do not hardcode UID in userLookup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2080>
<mup> PR snapd#2078 closed: daemon: fix login API to return local macaroons <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2078>
<joc> pitti: hi, i would appreciate some feedback on this as soon as you can https://code.launchpad.net/~jocave/netplan/+git/netplan/+merge/307531
<joc> zyga: did you get the extra info you requested on the udev rules?
<mup> PR snapd#2077 closed: overlord/devicestate,docs/hooks.md: nest prepare-device configuration options <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2077>
<elopio> ogra_: have you tried the new snapcraft in proposed?
<ogra_> elopio, not yet, i'll pull it in for the next build before EODing
<ogra_> thanks for the remonder (totally forgot about that)
<ogra_> *reminder
<mup> PR snapcraft#848 opened: `sign-build` to prompt users for key selection <Created by cprov> <https://github.com/snapcore/snapcraft/pull/848>
<morphis_> kyrofa: ping
<ogra_> elopio, https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core is now building with the new snapcraft ... if s390x finishes without failure the fix is good to go
<pitti> joc: replied
<mup> PR snapd#2081 opened: snap: relax auto-import test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2081>
<elopio> ogra_: thanks. Let us know when done to add the verification-done tag
<mup> PR snapd#2082 opened: overlord,daemon,snap: support gadget config defaults <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2082>
<ogra_> elopio, done :) https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5985
<ogra_> (all arches ... so i dont think there are regressions either)
<mup> Bug #1630281 opened: fltk-based app snap exit with "XOpenIM() failed" <Snappy:New> <https://launchpad.net/bugs/1630281>
<kyrofa> morphis_, pong
<morphis_> kyrofa: hey!
<morphis_> kyrofa: I was trying the configuration hook today with one of my snaps but I somehow miss steps to see if it was actually run or if something has failed
<morphis_> kyrofa: if a hook prints something to stdout where should this appear?
<kyrofa> morphis_, I believe it gets swallowed unless the hook encounters an error. Try exiting non-zero
<morphis_> tried that
<morphis_> but snap set didn't return with an error
<mup> PR snapd#2083 opened: cmd/snap: generate account-key revocation requests <Created by cjwatson> <https://github.com/snapcore/snapd/pull/2083>
<morphis_> kyrofa: did a simple shell script meta/hooks/configuration, added #!/bin/sh exit 1 and made it executable
<kyrofa> morphis_, sounds like it's not actually running. Is the hook executable?
<morphis_> + snapcraft snap . and then tried a snap set test=1
<kyrofa> Ah, it's meta/hooks/configure
<morphis_> kyrofa: ah
<morphis_> ah, used 'configure'
<kyrofa> morphis_, some docs here: https://github.com/snapcore/snapd/blob/master/docs/hooks.md
<morphis_> yeah saw those already
<morphis_> kyrofa: all I get from snapd is:
<morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: daemon.go:174: DEBUG: uid=0;@ PUT /v2/snaps/wifi-ap/conf 14.253704ms 202
<morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: taskrunner.go:293: DEBUG: Running task 340 on Do: Run apply-config hook for wifi-ap
<morphis_> Okt 04 17:35:51 nirvana /usr/lib/snapd/snapd[31630]: daemon.go:174: DEBUG: uid=0;@ GET /v2/snaps 1.030001ms 200
<morphis_> ah wait
<kyrofa> morphis_, uh oh
<kyrofa> morphis_, that looks old
<kyrofa> The hook was renamed recently from apply-config
<morphis_> 2.15.2ubuntu1
<morphis_> hm, let me try recent edge then
<zyga> lool: get most recent release (e.g. from ppa)
<kyrofa> morphis_, yeah, might be a re-exec issue
<zyga> joc: I crashed again (ENOSLEEP), looking at that now
<zyga> joc: did you talk to pitti by any chance?
<lool> zyga: I was asking why master is not CI-ed into the PPA like for snapd
<lool> I dont actually need it
<joc> zyga: not about that
<lool> seemed like logic thing to have them both
<zyga> lool: no reason really, it was not changing much earlier, I did a one-off upload but there's currently no setup that would put master into the PPA
<lool> zyga: right, I was thinking we should copy the snapd one, but up to you
<zyga> lool: there's some work towards that end, we want to run snapd tests with master version of snap-confine
<zyga> lool: which versions are we talking about?
<lool> zyga: versions?!
<zyga> lool: sorry, perhaps my sleepiness is making me ask the wrong question, can we start over?
<lool> zyga: right now ubuntu-core snap is built from "edge" and "image" PPAs and pushed to edge channel then promoted
<lool> zyga: edge PPA has snapd from master; image PPA has snapd and snap-confine from releases; would you want to include snap-confine from master in edge PPA as well?
<zyga> not at this time
<lool> ok
<zyga> lool: I'm very careful with releases (famous last words) and there's nothing significant there, the version 42.1 that is in the image PPA is the right one to use
<zyga> lool: after I release .43 I will put it to the image PPA agai
<jdstrand> zyga: .43 will have s/ubuntu-core/core/ support?
<zyga> jdstrand: .42.1 does
<zyga> it's released already (to yakkety though)
<zyga> as it is more of a OMG images thing
<jdstrand> zyga: sure, but I was more thinking about when that would be supported in xenial
<mvo> jdstrand, ogra_: we will have a new "core" snap in parallel to ubuntu-core soon, could we make it so that the snapcraft LP builds and the reviewsers scripts consider them the same and not complain? that would be really nice
<zyga> jdstrand: with .43 I think, in one or two days
<jdstrand> mvo: that landed already
<zyga> jdstrand: I'll try to release it before flying to seoul
<mvo> jdstrand: woah - you rock!
<jdstrand> mvo: well, the review tools bits
<zyga> jdstrand: unless mvo says we need it now and then we'll upgrade the SRU to .42.1
<zyga> jdstrand: ara is working on SRU validation
<morphis_> kyrofa: ok, nevermind, go it working now
<jdstrand> mvo: Chipaca had some uploads of 'core' last friday, so I fixed the tools and roadmr got them live this week
<kyrofa> morphis_, excellent!
<morphis_> kyrofa: also any ETA on getting hook support into snapcraft?
<kyrofa> morphis_, I believe it's a sprint topic
<jdstrand> zyga: ack. fyi, I'm just curious. I much prefer how snapd behaves with just 'core' and want to remove 'ubuntu-core'
<zyga> jdstrand: hmmm
<jdstrand> cause, with the snapd from the image ppa and both core and ubuntu-core installed, you get all the interfaces twice (one set for core:* the other for :*)
<zyga> jdstrand: well, it's tagged and works OK, if ara verifies that one we can bump the SRU to .42.1
<morphis_> kyrofa: so actually no snapcraft support real soon (1-2 weeks)?
<jdstrand> zyga: to be clear, I'm not trying to create work. just curious
<zyga> jdstrand: FYI, I'm off on thursday/friday (flying)
<zyga> jdstrand: no worries :)
<kyrofa> morphis_, that's my impression, yes. There's some disagreement about how it should be implemented
<jdstrand> zyga: home?
<zyga> jdstrand: roscon
<jdstrand> ah
<morphis_> kyrofa: I see
<mup> PR snapd#2081 closed: snap: relax auto-import test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2081>
<zyga> jdstrand: and I'll be off on the following week
<zyga> jdstrand: I should send out an email perhaps ...
<jdstrand> yeah, probably
<ogra_> mvo, not sure we can do that, but i can set up a parallel build with different name
<ogra_> mvo, you need to grant me access to it in the store though
<mvo> ogra_: hats good enough
<mvo> ogra_: sure, adding you
<ogra_> cool
<ogra_> i assume we can stop ubuntu-core eventually ?
<ogra_> and just build core
<ogra_> mvo, how will snapd handle the cross-grade for already installed ubuntu-core ? ubuntu-core is at revision 800+ ... wont that become a prob if core starts at 1 ?
<mvo> ogra_: not at all right now
<ogra_> ah, k
<mvo> ogra_: we keep the two for a bit
<ogra_> well, i understood your long-term plan was to simply switch people over
<ogra_> i was just wondering how you handle the revision bits in such a case
<mvo> ogra_: this is still the case but we have not figured the details out yet
<ogra_> ah, k
<mup> PR snapd#2070 closed: all: move from ubuntu-core to core by default, but still support ubuntu-core as core <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2070>
<zyga> jdstrand, ara, mvo: https://bugs.launchpad.net/snap-confine/+bug/1628612 updated with SRU meta-data
<mup> Bug #1628612: prefer "core" rather than "ubuntu-core" if installed <Snappy Launcher:Fix Released by zyga> <https://launchpad.net/bugs/1628612>
<jdstrand> mvo: hey, so I currently have both ubuntu-core and core installed. I have snapd and snap-confine from the image ppa. how can I remove ubuntu-core?
<zyga> jdstrand: you don't have to, we're going to work on making that happen later
<zyga> jdstrand: but with the current arrangement there's no rush
<jdstrand> well, snap interfaces is annoying me
<pmcgowan> for every new snap I install I get this when I run it execv failed: No such file or directory
<pmcgowan> the snaps I installed a while back work fine
<pmcgowan> sure would like to fix that
<zyga> jdstrand: ah
<zyga> jdstrand: oh, you are seeing double?
<zyga> jdstrand: I didn't try that
<zyga> I wonder what's the plan for that (when oyu have both, do we move the connections over?)
<zyga> joc: can you please take https://github.com/snapcore/snapd/pull/2065 over
<mup> PR snapd#2065: interfaces/builtin: use udev to export GPIOs to userspace <Reviewed> <Created by zyga> <https://github.com/snapcore/snapd/pull/2065>
<zyga> joc: just change that to what you suggested and if it works get it merged
<zyga> joc: I need to take a nap
<zyga> I feel so tired today
<zyga> joc: I'll try to stay away from my computer for some time, be back when I wake up
<joc> zyga: ok, feel better
<jdstrand> zyga: I am seeing double. I don't know what the plan for that is. I don't know how that affects connections
<zyga> jdstrand: ask chipaca
<zyga> jdstrand: he's been making that work for the past few days
<jdstrand> I see
<pmcgowan> jdstrand, zyga sorry to bother you but any idea why this happens http://pastebin.ubuntu.com/23275810/
<mup> PR snapcraft#849 opened: Bugfixes for gated and validate commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/849>
<jdstrand> pmcgowan: I don't see anything wrt security policy in there. can you paste the output of 'snap list ; snap interfaces'
<jdstrand> pmcgowan: also, what version of snapd and snap-confine are you using?
<pmcgowan> http://paste.ubuntu.com/23275869/
<pmcgowan>  2.15.2ubuntu1 and 1.0.38-0ubuntu0.16.04.10
<jdstrand> pmcgowan: your ubuntu-core is ancient
<pmcgowan> oh?
<jdstrand> I don't know why that is
<jdstrand> try: sudo snap refresh ubuntu-core
<jdstrand> pmcgowan: yeah, it should be revision 423
<pmcgowan> jdstrand, do I need to periodically refresh it ?
<pmcgowan> its updating now
<jdstrand> you're not supposed to have to
<jdstrand> pmcgowan: you said that new snaps are failing. I suggest removing those failing snaps and installing again
<pmcgowan> lets see once its updated
 * jdstrand nods
<pmcgowan> I cant afford the bandwidth :)
<pmcgowan> jdstrand, Connection to the daemon failed: Get http://127.0.0.1/enable: dial unix /var/snap/canonical-livepatch/6/livepatchd.sock: connect: no such file or directory
<pmcgowan> other snaps are running now
<jdstrand> pmcgowan: you uninstalled canonical-livepatch?
<jdstrand> then reinstalled?
<pmcgowan> not yet
<jdstrand> you might be able to stop the service and restart it, but I'd prefer uninstall/reinstall
<pmcgowan> jdstrand, working now, thanks
<jdstrand> cool, np
<pmcgowan> jdstrand, what about the snap not updating?
<pmcgowan> anything to look for there
<jdstrand> pmcgowan: I don't know-- that might be a question for mvo or another on the snappy team
<pmcgowan> jdstrand, is it due to the switch from ubuntu-core to core? should I remove one and get the other?
<ogra_> mvo, https://code.launchpad.net/~snappy-dev/+snap/core ... i'll set up daily cronned builds tomorrow morning
<pmcgowan> ogra_, quassel-kalikiana in the stable channel :)
<ogra_> pmcgowan, heh, right, he talked about it (wont make me change to quassel though :) )
<ogra_> thanks !
<ogra_> jdstrand, hmm, doesnt seem like the tooools changes for "core" are live yet ...
<ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/9/
<ogra_> WOAH !
<mup> PR snapcraft#850 opened: catkin plugin: add `rosdistro` to help documentation <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/850>
<ogra_> and it seems htis one fail blocka *all* subsequent uploads of that snap
<jdstrand> oh I missed one. shoot
<ogra_> *blocks
<ogra_> thats new
<ogra_> rev 10-13 all show "Revision waiting for review of a previous upload."
<jdstrand> yeah
<jdstrand> that's new
<ogra_> given they are all for different arches thats rather bad
<ogra_> it should take that into account somehow
<ogra_> not just blindly block because a former revision failed
<jdstrand> I don't know the implementation. the idea is to easy reviews. eg, say you upload a snap that uses a special interface. the tools flag for manual review. the reviewer says it is ok and that future uploads are allowed with this interface (ie, snap declaration is used). then approve and then all the other go through without being flagged cause they use that snap decl
<jdstrand> ease*
<ogra_> well, what if an upload for ppc64el fails for some esoteric reason ...
<ogra_> that will block all amd64 uploads afterwards
<jdstrand> that is an unusual case that I think would need more information to be smarter
<jdstrand> note, I didn't implement this
<jdstrand> but I agree with the concept
<ogra_> thats totally not unsual ... regarding the design of store uploads
<ogra_> if i build in LP for all arches s390x or ppc64el are usually the first to be done and the first to be uploaded
<ogra_> if there is some ppc specific interface that i enable it will then block everything
<ogra_> so i have to say i disagree with the concept :)
<ogra_> thats like a lottery now ...
<jdstrand> roadmr: sorry, I missed a check cor 'ubuntu-core' -> 'core'. can you pull r755?
<ogra_> jdstrand, if your check was an arch specific oversight, dont forget s390x too ... (we dont have it yet for that snap since i need to apply for it at the LP team first)
<jdstrand> ogra_: it was not
<ogra_> ah, k
<ogra_> (i thought, because the other arches seem to have gone through before)
<jdstrand> though there is an arch check too
<jdstrand> this is the ubuntu-core rename to core
<ogra_> (and looking closer i see they havent at all :P ... all manually approved before)
<jdstrand> but s390x might be an issue too
<ogra_> well, it wasnt for ubuntu-core
<jdstrand> ogra_: I just checkd: s390x is considered valid by the tools. no worries there
<jdstrand> ogra_: ok, they are all approved. I see you are publishing them
<ogra_> heh ... it is funny how the revision history disagrees about the uploader with the "submitted by" field above
<ogra_> according to revision history it is the shared account ... according to "submitted by" it is me
<jdstrand> ogra_: fyi, you seem to have missed this one https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/9/
<ogra_> (and after all it is LP under the snappy-dev account ... it just happened to be me who set it up)
<mup> PR snapd#2084 opened: snap/squashfs: add -all-root flag to mksquashfs <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2084>
<ogra_> published rev9
<ogra_> roadmr, let me know when jdstrand's change was merged, then i can enable cronned daily builds for that snap
<ogra_> (still missing a few bits on my side anyway, so no hurry)
<jdstrand> roadmr: again, I apologize. I did the hard change last week, but the easy one I missed :\
<ogra_> (this above was just the first manuall test build)
<mup> PR snapd#2084 closed: snap/squashfs: add -all-root flag to mksquashfs <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2084>
<mup> PR snapd#2085 opened: many: check installation of slots and plugs against declarations <Created by pedronis> <Conflict> <https://github.com/snapcore/snapd/pull/2085>
<roadmr> jdstrand: no problem, I'll pull that now
<mup> PR snapd#2086 opened: client, cmd: prompt for password when buying <Created by pete-woods> <Conflict> <https://github.com/snapcore/snapd/pull/2086>
<ralsina> sergiusens, elopio: in a PR for snapcraft I am getting  "Coverage decreased (-0.006%)" which is funny, but also, we are checking coverage inside the tests, which makes no sense, right?
<om26er> ogra_, curious, whats the difference with ubuntu-core and core snap ? new name ?
<ogra_> om26er, yep
<ogra_> eventually we'll drop ubuntu-core
<om26er> ogra_, I assume its to make snap based systems to not be always tagged 'ubuntu' ?
<ogra_> right ...
<ogra_> the all-snap images will go on being called ubuntu-* ... but there is no need to call the core snap itsellf "ubuntu-"
<ogra_> it is simply the core execution environment for snaps ...
<om26er> understood, makes sense.
<mup> PR snapd#2075 closed: cmd/snap: add version command, same as --version <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2075>
<mup> PR snapcraft#850 closed: catkin plugin: add `rosdistro` to help documentation <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/850>
<mup> PR snapcraft#851 opened: catkin plugin: nicely handle an invalid rosdistro <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/851>
<mup> PR snapd#2076 closed: asserts: limit model to only lowercase until we can implement case insensitive/preserving headers <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2076>
<jdstrand> roadmr: thanks
<mup> PR snapd#2066 closed: many: abbreviated forms of disconnect <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2066>
<mup> PR snapd#2074 closed: client,daemon,overlord,cmd: add /v2/users and create-user on auto-import <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2074>
<mup> Bug #1629081 changed: "git clone" fails with "source-type: git" and "source-tag: x.y.z" in "snapcraft.yml" <snapcraft> <Snappy:Invalid> <https://launchpad.net/bugs/1629081>
<mwhudson> good morning
<mup> PR snapd#2087 opened: snap, daemon, store: fake the channel map in the REST API <Created by chipaca> <https://github.com/snapcore/snapd/pull/2087>
<mup> PR snapd#2079 closed: tests: use test snap from the store in the content interface test <Critical> <Created by fgimenez> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2079>
<mup> PR snapd#2088 opened: tests: fix snap-disconnect tests after core rename <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2088>
<mup> PR snapd#2089 opened: store: do not set store auth for local users <Created by matiasb> <https://github.com/snapcore/snapd/pull/2089>
<mup> PR snapd#2090 opened: wip: initial cleaning up of no arg AutoConnect related bits <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2090>
<zyga> re
<mup> PR snapd#2091 opened: interfaces: tweak wording and comment <Created by zyga> <https://github.com/snapcore/snapd/pull/2091>
<mup> PR snapd#2088 closed: tests: fix snap-disconnect tests after core rename <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2088>
#snappy 2016-10-05
<mup> PR snapd#2092 opened: store: do not set store auth for local users <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2092>
<mup> PR snapd#2082 closed: overlord,daemon,snap: support gadget config defaults <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2082>
<mup> PR snapd#2071 closed: interfaces,overlord/ifacestate: switch to use declaration-based checking for auto-connect <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2071>
<mup> PR snapd#2089 closed: store: do not set store auth for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2089>
<mup> PR snapd#2092 closed: store: do not set store auth for local users <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2092>
<mup> PR snapd#2093 opened: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2093>
<mup> PR snapd#2094 opened: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2094>
<mvo> ogra_: thanks for setting up "core". could we make it so that core is auto-triggered to build daily just like ubuntu-core? that would be great!
<dholbach> good morning
<mup> PR snapd#2094 closed: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2094>
<morphis_> zyga: ping
<mvo> pitti: quick question - what is the best way to conditionall enable a systemd service (cloud-init in my case). during boot I want to evaulate via "snap get core cloud-init.enabled" if it should run or not and based on target start cloud-init.target. should I just do that in a new snapd.cloud-init.service  ? "ExecStart=/bin/sh -c "if snap get core cloud-init.enabled; do systemctl start cloud-init.target; fi"? or is there a better way to do that?
<pitti> mvo: not sure that this works as cloud-init wants to run *very* early; you can't alter the early boot transaction while you are already in that
<pitti> mvo: I can think of two ways:
<pitti> 1) write a generator which does the get and enables cloud-init.service in the generator run dir
<pitti> (that's the "official" way)
<pitti> 2) run snapd.cloud-init.service Before=cloud-init-local.service, if enabled create a /run/somewhere/run_cloud_init, and add ConditionPathExists=/run/somewhere/run_cloud_init to cloud-init*.service
<pitti> but the latter is the same effort with a non-standard way to enable it and requires modifying cloud-init.service (you can do that with drop-ins); so I'd actually just use a generator
<pitti> mvo: I thought cloud-init already had like five different ways to enable/disable it -- none of them are suitable?
<pitti> (kernel command line, flag files, etc.)
<mvo> pitti: well, maybe I have not found the right one yet :) I want it to be totally disabled, i.e. no python running by default to not slow down boot on arm
<mvo> pitti: the /etc/cloud/cloud-init.disabled does not do that, there is still python code run afaict (mind you, I'm not a cloud-init expert)
<pitti> ah, too bad -- otherwise that could just be the flag file
<pitti> although having it in /run would be better
<mvo> pitti: yeah
<pitti> mvo: so, I'd say just write a generator
<mvo> pitti: this will run very early, right?
<pitti> mvo: yes, before any unit starts; so you can make essentially zero assumptions about r/w mounts, remote mounts, networking etc.
<pitti> but for checking a config option it should work fine
<mvo> pitti: hm, that is also going to be tricky because of the way the snapd config works. hm hm
<mvo> pitti: essentially a config get goes through snapd
<pitti> oh
<mvo> pitti: but thanks, I won't bother you more with this, let me think about this some more, this is really helpful so far
<pitti> mvo: when does snapd start?
<pitti> mvo: there is no way to get that config option without the daemon?
<mvo> pitti: in multi-user somewhere
<mvo> pitti: maybe, I need to check that out
<pitti> mvo: ok, way too late; cloud-init (the earliest is cloud-init-local) runs basically as the second thing after boot
<pitti> s/after/at/
<mvo> pitti: uhhh
<pitti> mvo: it wants to be able to change fstab entries, reformat partitions etc.
<clobrano> Hi everybody, I was looking at some bugs to fix, and saw Bug #1470661. Is it still a valid one? The code has changed a lot, this problem is still reproducible,but snapcraft schema allows tilde in version
<mup> Bug #1470661: Tilde allowed in version but systemd hates it <Snappy:Triaged> <Snappy 15.04:Won't Fix> <Snappy trunk:Triaged> <https://launchpad.net/bugs/1470661>
<mvo> pitti: thanks, tricky
<pitti> mvo: hm, I thought it had some ConditionSomething= on a file, seems not
<pitti> mvo: then again, how many features of cloud-init would actually work on snappy? most certainly not the fstab, formatting, package installation, etc. parts
<pitti> mvo: so on snappy you might actually get away with starting it later
 * pitti suggests discussing that in a hangout with smoser
<pitti> mvo: but still -- I'd say, find a way to get that flag without the daemon
<mvo> pitti: yeah, that is a good point, again, thanks for your input
<zyga> ara: hey
<ackk> hey, I think you query'd the wrong nick :)
<ackk> n/m, my client tricked me
<zyga> ara: we found this bug https://bugs.launchpad.net/snap-confine/+bug/1630479
<mup> Bug #1630479: permission denied while opening mount namespace file <Snappy Launcher:In Progress by zyga> <snap-confine (Ubuntu):In Progress by zyga> <https://launchpad.net/bugs/1630479>
<zyga> ara: this will probably fail verification (well, it's a regression compared to .38) but we already fixed it and I'll probably upload .43
<ara> zyga, thanks for the heads up
<ara> zyga, (even if it is bad news!) :)
<morphis_> zyga: ping
<mup> PR snapd#2095 opened: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <https://github.com/snapcore/snapd/pull/2095>
<zyga> morphis_: hey
<morphis_> zyga: hey!
<morphis_> zyga: you came forward yesterday with the /media share work?
<zyga> morphis_: some, I'm working on that now
<morphis_> zyga: I read yesterday here that you're out tomorrow and on friday, so you want to complete it today?
<zyga> morphis_: yes
<mup> PR snapcraft#716 closed: Add Waf plugin (LP: #1611335) <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/716>
<morphis_> zyga: ok, then please lets discuss later today where you stop with this and what the status is
<zyga> ok
<zyga> sounds good
<morphis_> zyga: I guess for the feature-freeze this needs to be done today anyway, right?
<zyga> morphis_: I don't know
<zyga> morphis_: gustavo said we might do this after ff and just treat it as a bug
<zyga> morphis_: but my plan is to do it today
<mup> PR snapd#2096 opened: tests: check for failure creating user on managed ubuntu-core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2096>
<ogra_> mvo, i was waiting for the store to support auto landing (it was still failing yesterday on "type: os")
<ogra_> but yeah, as i said yesterday, i'm plainning to set that up today
<ara> hello! can I set up any env variable so that "snap login" uses the staging SSO site?
<ogra_> zyga, a line or two in bug #1630492 would have avoided the heart attack i just had :P
<mup> Bug #1630492: /var/lib/extrausers is wrong in all-snap <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1630492>
<ogra_> (though whats wrong about it ?)
<mup> PR snapd#2085 closed: many: check installation of slots and plugs against declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2085>
<sborovkov> hmm, when I do snap revert for snap installed in devmode does it keep devmode?
<zyga> ogra_: whaaat?
<zyga> ara: pedronis would probably know this
<zyga> ogra_: it's empty :) fixing it now
<sborovkov> yeah, it does not... Does that even make any sense?
<mup> PR snapd#2097 opened: snap: add `snap is-managed` for console-conf <Created by mvo5> <https://github.com/snapcore/snapd/pull/2097>
<ara> zyga, thanks
<ara> pedronis, question was whether there was an env variable (or other method) so that snap login points to the staging SSO site
<pedronis> ara: yes, but it needs to be set of snapd, so you need some kind of  /etc/systemd/system/snapd.service.d/local.conf and setting USE_STAGING_STORE=1 there, but also you need a specially built with snapd
<pedronis> s/of snapd/for snapd/
<ara> pedronis, but does USE_STAGING_STORE set, also sets staging SSO?
<pedronis> ara: yes
<pedronis> it points everything to staging
<ara> pedronis, OK, I will try that
<ara> " but also you need a specially built with snapd"
<ara> ?
<ara> what does that mean
<pedronis> ara: if you do anything that involves getting assertions you need a snapd with the staging root key
<pedronis> otherwise it will try to verify with only the prod one and that won't work
<ara> pedronis, how do you do that? a snapd with the staging root key
<pedronis> ara: are you on classic? or using an all-snaps image?
<ara> pedronis, classic
<pedronis> ara: you need a deb of snapd built with something like  DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip or building snapd with go and replacing your system one
<ara> pedronis, OK, will try that
<ara> pedronis,
<ara> pedronis, thanks
<pedronis> ara: if you just build with go   :     go build -tags withstagingkeys ./cmd/snap and go build -tag withstagingkeys ./cmd/snapd should do the trick
 * pedronis lunch
<sborovkov> Hello. How do I revert snap revert? snap refresh does not work it seems
<ara> pedronis, cool, will try that
<zyga> sborovkov: "snap revert"
<mup> Bug #1630520 opened: snap login error message incorrect <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1630520>
<sborovkov> zyga: wait won't it revert to even more previous version?
<sborovkov> zyga: also how does that make any sense that snap revert removes devmode...
<popey> hm. I have a pi2 which auto updated overnight and now won't boot
<popey> http://paste.ubuntu.com/23279200/ hangs at Starting kernel...
<ogra_> popey, anything on screen or serial ?
<popey> yes ^
<ogra_> hmm, weird
<popey> i have two pi's (a pi 2 and a pi 3) on daily images and the pi3 came back okay, but pi2 didn't
<ogra_> well, nothing changed in the kernel
<popey> sorry, I have them the wrong way round, pi2 came back, pi3 didn't it seems
<popey> i need to put stickers on my pis to idenify them :)
<ogra_> the pi3 has a white plastic bar on the top
<ogra_> at least mine does
<zyga> sborovkov: look at --help
<ogra_> mvo, so the auto-builds are set up, but since the store still doesnt accept them i wont set up a cron entry until i heard back from roadmr that the fixes landed (like i said yesterday as well)
<zyga> sborovkov: 12:47 < popey> i need to put stickers on my pis to idenify them :)
<zyga> ogra_: plastic bar?
<zyga> ogra_: photo?
<popey> mine are in cases
<popey> i need to put a sticker on the case
<popey> I saw some nice transparent cases recently, which will help
<ogra_> mvo, also note that the store now blocks *all* subsequent uploads if there was one failure in one revision upload
<sborovkov> ogra_: oh wow. Now I know how to differentiate my RPIs. Never noticed that bar before
<ogra_> zyga, similar to the pi1 in that pic mine has that white plastic thingy (vs the same part in black on the left one) https://www.pretzellogix.net/wp-content/uploads/2015/08/flirc-rpi-3.jpg
<ogra_> next to the headphone jack ...
<sborovkov> ogra_: to be fair though it also says the model in text if you don't have it without case
<ogra_> but very fine print :)
<popey> old man eyes
<popey> http://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ is useful if you "grep Revision /proc/cpuinfo" :)
<zyga> ahh
<zyga> ogra_: you mean the flat-flex connector latch
<popey> anyway, what can I do with this pi3 that won't boot?
<ogra_> zyga, yeah, the bar :P
<zyga> :D
<nhaines> popey: well, if you leave it running it's probably nice for a small space heater.
<popey> should I get something off the sd card? logs or somesuch?
<zyga> the thing ;-)
<ogra_> popey, hard reset
<popey> ogra_: que?
<ogra_> youo wouldnt get anything off the card anyway before anything is mounted
<ogra_> so just reset it
<popey> as in, dd a new image on it?
<ogra_> you can indeed check via HDMI
<ogra_> if there is an oops or so
<ogra_> but beyond that, just do a reset
<ogra_> popey, that power plug thing ... pull it and plug it in again :P
<popey> hah, okay
<ogra_> (i would have said re-flash otherwise ;) )
<popey> I was hoping for some leet reset tool :)
<popey> indeed, "reset" has other connotations for me, "reboot" might work ;)
<popey> also as we call it in our house "Do a Daddy Pig"
 * ogra_ notes that down for next time :)
<popey> https://www.youtube.com/watch?v=fxqw0am27Fk is the episode in question
<mup> Bug #1572175 changed: change finished in status "Hold" with no error message <amd64> <apport-bug> <sdoc> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572175>
<mvo> ogra_: ok, thanks
<popey> ogra_: magically came back after a reboot :S
<mup> PR snapcraft#852 opened: Simplify the parser tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/852>
<ogra_> popey, yeah, i thought so, there is a mystical OOPS that we are still trying to debug ... ppisati didnt get further on that one either and i didnt manage to capture it yet
<popey> ogra_: ok, thanks
<ogra_> mvo, once enabled core info for the auto-builds will be at http://people.canonical.com/~ogra/core-builds/ (much like http://people.canonical.com/~ogra/ubuntu-core-builds/ was for ubuntu-core before)
<sborovkov> zyga: btw "look at help" does not have anything about devmode or whatever. Idk I might be on old version though. Not going to update until that issue that makes snaps not working becase of cross architecture stuff is fixed...
<mvo> ogra_: neato
<zyga> sborovkov: oh, yes, perhaps it is not released yet, I'm running master
<zyga> sborovkov: I think behavior changed and it should not behave as you expect
<ogra_> cjwatson, is there any specific reason why s3390x and ppc64el do not publish their manifest files (i see in the log that they built)
<ogra_> -3
<mup> PR snapd#2098 opened: store: retry store operations (WIP) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2098>
<cjwatson> ogra_: s390x hasn't been upgraded to the new launchpad-buildd because I'm lazy; ppc64el hasn't been upgraded for some mysterious reason we've yet to properly investigate
<cjwatson> (its image upgrader script is probably broken somewhere ...)
<ogra_> ah, ok ... it isnt that important anyway, just curiosity ... i doubt anyone but me cares :)
<cjwatson> ogra_: I'll take care of s390x at least, ppc64el will be a bit of a when-we-get-round-to-it
<ogra_> yeah, dont put it on to high prio, i doubt there are even many users on these arches atm
<ogra_> (i wish i could look up the numbers, but the store times out when i click on "stats" for ubuntu-core :)  )
<ogra_> hah, and saying tht, this time it didnt
<ogra_> but no downloads by arch :(
<cjwatson> Mainly I just like having production revisions of things in sync where possible.
 * ogra_ notes mvo is a busy bee manually approving stuff in the store :)
 * ogra_ thinks this new store behaviour of blocking the world is insane ... approving a set now takes ages since you have to wait for the next fail first
<mup> PR snapd#2099 opened: docs/hooks.md: fix typos <Created by pedronis> <https://github.com/snapcore/snapd/pull/2099>
<daker> hi snapcraft question, how can i tell the make plugin to run two make commands (make something then make) ?
<zyga> daker: write the make rules so that you don't have to
<daker> zyga: what do you mean ? write another Makefile that will run thoses make commands ?
<zyga> daker: if you can control the original makefile just change that
<daker> zyga: no i don't have control that's an upstream project, and the first make commands is from a submodules
<ogra_> well, a toplevel makefile would likely work ... just put your upstream project in a subdir and have the toplevel makefile drive everything
<hikiko> just for the record I found a solution for my problem with the libcuda1-361 package but it was a hack: I edited the /var/lib/dpkg/info/libcuda1-361.prerm and put an "exit 0;" at the beginning so that the script doesn't run, then I purged nvidia* and libcuda1* and then I had no issues
<morphis_> zyga: how are things going?
<zyga> morphis_: I'm having issues using all-snap systems
<zyga> morphis_: fighting console-conf
<morphis_> zyga: what kind of issues?
<zyga> i cannot log in
<morphis_> zyga: do you have a ssh key registered with your sso account?
<zyga> ah, I think I know what the problem is
<zyga> trying again
<zyga> yes, certainly, I was just using the wrong key to log in
<zyga> morphis_: I'm in :)
<mup> PR snapd#2100 opened: store: local users download from the anonymous url <Created by matiasb> <https://github.com/snapcore/snapd/pull/2100>
<morphis_> zyga: ah
 * ogra_ hands zyga a lockpick for the next time 
<mup> PR snapd#2099 closed: docs/hooks.md: fix typos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2099>
<ogra_> mvo, if someone sends me an updated set of official assertions i can also set up the dailies to use core by default btw
<ogra_> (if snapd is ready for that already indeed)
<popey> anyone seen this before:- popey@localhost:~$ sudo snap refresh
<popey> error: cannot refresh []: cannot refresh snap-declaration for "pi2": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/ZbHoNCV2YMyGLhAf1U9SLaOvuVD02Sqs: dial tcp: lookup assertions.ubuntu.com: no such host
<popey> hmm, dns issue on that box... odd.
<morphis_> ogra_: is it known that the pi3 kernel crashes quite often on edge?
<ogra_> morphis_, there is a known oops on boot, if you can capture something please give it to ppisati
<ogra_> beyond that my pi is rock solid
<morphis_> ogra_: yeah happens always at boot, something with the uart
<ogra_> rather withthe wifi
<morphis_> will take a picture next time
<ogra_> thx
<morphis_> ogra_: but it corrupts the whole firstboot so I have to reflash my sdcard
<ogra_> yep
<ogra_> annoying....
<zyga> jdstrand: hey, can you look at https://github.com/snapcore/snap-confine/pull/162/files
<mup> PR snap-confine#162: Set PATH unconditionally even if mount namespace is set up <Created by zyga> <https://github.com/snapcore/snap-confine/pull/162>
<ogra_> it works with wired networkfor me though
<zyga> jdstrand: I'm making a tiny tweak to the test but it's just polish, the semantics is okay as is
<jdstrand> zyga: yeah, I am looking at it now
<zyga> jdstrand: I need to cook a new release
<zyga> jdstrand: so those two are going in for sure
<zyga> jdstrand: I also merged this just a moment ago: https://github.com/snapcore/snap-confine/pull/163
<mup> PR snap-confine#163: Disable quirks on all-snap systems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/163>
<jdstrand> zyga: does the lxd snap continue to work on all snaps?
<zyga> jdstrand: that is irrelevant as the quirk was only meaningful in classic, /var/lib/lxd doesn't exist in the core snap
<zyga> jdstrand: AFAIK it never worked there
<zyga> but again, this is irrelevant for this reason
<jdstrand> zyga: I was thinking perhaps this did work before because this created the /var/lib/lxd directory
<zyga> jdstrand: it cannot create that directory
<jdstrand> but maybe lxd does that already. idk. seems at least worth testing if it worked before and now doesn't so you could let the lxd guys know the snap will break on all snaps
<zyga> jdstrand: on all-snap /var/lib is on the core snap, there's no mount point for /var/lib/lxd
<zyga> root@localhost:~# mkdir /var/lib/lxd
<zyga> mkdir: cannot create directory â/var/lib/lxdâ: Read-only file system
<jdstrand> well, right, which is partly what the quirk dealt with, no?
<zyga> no, the qurik only made the host's version of /var/lib/lxd show up
<zyga> if there was one
<zyga> but there's no /var/lib/lxd here and the idea of "hostfs" is meaningless
<jdstrand> hmm, I guess that's true
<ogra_> om26er, while i appreciate https://code.launchpad.net/~om26er/core-snap/improve_build_script/+merge/307640 (a lot actually, my python is usually awful) ... there is sadly no python3 on any of the servers these scripts run on
<diddledan> could someone enlighten me as to why my corebird experiment isn't showing up in the unity menu when I've installed it? I'm thinking it might be related to my use of an svg icon(?) otherwise I feel I must have seriously misunderstood the setup of the desktop file
<diddledan> https://github.com/diddledan/corebird-snap
<om26er> ogra_, oh, fun ;)
<ogra_> the datacenter runs mostly on 12.04
<om26er> ogra_, no problem, its only a matter of a few months when 12.04 goes EOL and I can resurrect my branch ;) :p
<ogra_> heh, well, i can merge it into a lp-build-core-py3 or so
<ogra_> so we are future proof
<ogra_> morphis_, bug 1627643 btw
<mup> Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643>
<morphis_> ogra_: different one here: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1630586/
<mup> Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
<ogra_> how do you know it is different ?
<morphis_> ogra_: it crashes reliable at the same point here
<ogra_> same here
<morphis_> and there is nothing which relates to wifi
<ogra_> and after the crash there is no wlan device setup possible
<morphis_> ogra_: actually you can't even get into the device with this crash
<ogra_> oh, it hangs hard ?
<morphis_> yes
<ogra_> then it actually is different
<mup> Bug #1630586 opened: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
<morphis_> ppisati: https://bugs.launchpad.net/snappy/+bug/1630586
<mup> Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
<ogra_> for me i see the oops pass by but after a while (1-2 min) i get the "please press enter" prompt and can set up the device
<ogra_> only with wired though
<zyga> jdstrand: 1.0.43 released
<zyga> jdstrand, ara: we should get it into yakkety and override the SRU to use it
<zyga> it contains two fixes, one is very important and affects xenial
<mup> PR snapcraft#852 closed: Simplify the parser tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/852>
<cjwatson> ogra_: You should get s390x manifests now.
<ogra_> cjwatson, yay, thanks !
<morphis_> kyrofa: is this expected that snapd takes authority over the current configuration settings I can set via the config hook?
<mup> PR snapd#2100 closed: store: local users download from the anonymous url <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2100>
<ogra_> niemeyer, dbarth, so just in time for the meeting i had two WiFi SD cards and an adapter arrive :)
 * ogra_ is just unpacking them here 
<didrocks> sergiusens: hey! I think I found a regression (or case that wasn't tested) in the go plugin with go-importpath
<dbarth> ogra_: ah nice
<didrocks> sergiusens: source: ., go-importpath: <matching-my-project-import-url>. I see that parts/go/src/<myproject-url> is still the git branch and not the local source
<niemeyer> ogra_: Oh, nice
<niemeyer> ogra_: Looking forward to the news there!
<didrocks> sergiusens: so, local modification aren't reflected, I guess that's a bug and that was the purpose of importpath, correct?
<ogra_> i'll report back what works and what doesnt once i had some time to play with them
 * ogra_ shakes fist at google
<ara> pedronis, I have built the debs with the parameters you mentioned and installed the new .debs, yet snap login cannot find the account that was created in staging
<ara> pedronis, (and I have USE_STAGING_STORE=1)
<pedronis> ara:  you can turn on debugging with SNAPD_DEBUG_HTTP=1  (only requests)Â or SNAPD_DEBUG_HTTP=7 (everything)
<pedronis> and look at syslog
<morphis_> zyga: you got it working already?
<ara> pedronis, trying
<zyga> morphis_: I fixed two issues in snap-confine, iterating on the problem
<zyga> morphis_: (the problem==/media)
<zyga> morphis_: I need to rebase it on top and try again, fingers crossed but outlook is positive
<morphis_> zyga: ok, you think we need a plan to accommondate you being away starting tomorrow?
<morphis_> zyga: if yes, lets bring that up in the team meeting
<kyrofa> morphis_, I'm not sure what you're asking about the configuration settings
<ara> pedronis, mmm, syslog doesn't give me a lot of info: Oct  5 16:39:01 sushirider /usr/lib/snapd/snapd[7573]: daemon.go:174: DEBUG: uid=0;@ POST /v2/login 1.734880238s 401
<ara> pedronis, (for example, whether it is correctly pointing to staging)
<pedronis> ara: seems the wway you are turning on those env var is wrong
<pedronis> you should get a lot of spam
<pedronis> with SNAPD_DEBUG_HTTP
<om26er> How do I get pip on all-snaps ?
<ogra_> you ue it in snapcraft ;)
<ogra_> *use
<morphis_> kyrofa: I started to play with it now that my hook is called and saw that the actual configuration state is stored in the snap which seems to be applied again when a new snap revision is installed
<morphis_> kyrofa: which conflicts a bit if the snap has other mechanisms to change the same configuration items
<morphis_> s/stored in the snap/stored in snapd/
<kyrofa> morphis_, how is it applied again when a new revision is installed?
<kyrofa> Are you saying the hook is called again?
<morphis_> yes
<ara> pedronis, I have them set up at /etc/systemd/system/snapd.service.d/local.conf
<ara> pedronis, what's the right way?
<pedronis> that's one of the ways
<pedronis> one sec
<morphis_> kyrofa: so "snap install my.snap" gives me a call on the configure hook where I then look into the existing config items via snapctl
<morphis_> kyrofa: however those might be already overriden by something inside the snap
<pedronis> ara: this what our tests do (just making sure we are on the same page):  http://pastebin.ubuntu.com/23280119/
<ara> pedronis, definitely different, thanks for the pointer!
<pedronis> replace SNAP_REEXEC=0 with USE_STAGING_STORE=1
<kyrofa> morphis_, huh... I only added a hook call when `snap set` is called, I'm not sure why it would be called upon install
<pedronis> ara: those conf are overrides, they follow systemd unit syntax
<morphis_> kyrofa: so I am wondering who has authoritive over the current state of the configuration, the snap itself or snapd?
<pedronis> ara: sorry I wasn't super clear when IÂ mentioned that
<om26er> ogra_, won't I be able to just pip install something ?
<ara> pedronis, no worries, thanks a lot for the help
<kyrofa> morphis_, we wanted it to be held within snapd, otherwise every snap would need some way to store it and respond to queries about it
<ogra_> om26er, nope ... and python is not even guaranteed to be on the core snap
<morphis_> kyrofa: so how can something inside the snap change the configuration? calling snap set?
<ogra_> the only things we guarantee are snapd, systemd and /bin/sh
<ogra_> everything else can change at any time
<kyrofa> morphis_, admittedly we need a way to ask the snap for its configuration so we can initialize it within snapd
<om26er> ogra_, a snap for pip, maybe ?
<ogra_> om26er, you can intall the classic snap though .... so you have a "normal" deb env
<kyrofa> morphis_, something within the snap can change config via `snapctl set`, and get it with `snapctl get`
<ogra_> sudo snap install classic --devmode --edge
<ogra_> then: sudo classic
<om26er> ogra_, is that persistent now ? I was once told here that it will be wiped on reboot.
<ogra_> that gives you a classic shell env
<morphis_> kyrofa: you mean snap set or snap get, right?
<kyrofa> morphis_, no, snapctl
<om26er> I do use classic already in virt-manager
<zyga> morphis_: snapctl is not the same as snap
<morphis_> kyrofa: as for snapctl you need SNAP_CONTEXT being set
<ogra_> it wont be wiped ... but services started in that enmv wont be started
<zyga> morphis_: it uses another socket
<morphis_> zyga: I know
<kyrofa> snap get/set is for a user, it'll cause the hook to be called
<kyrofa> morphis_, snap get/set allows one to change settings for all snaps
<ogra_> *services installed in
<kyrofa> morphis_, snapctl uses a context generated for hooks to determine the snap which is being altered, so snaps can't alter the config of other snaps
<morphis_> kyrofa: so where do I get that context from when I want to change the config for my own snap from within an application of that snap?
<kyrofa> morphis_, again though, we're missing a little bit of the picture for config, as you've noticed
<om26er> ogra_, Whats the footprint you aiming for the core snap ?
<morphis_> kyrofa: yeah, but trying to understand what you guys have in mind
<ogra_> om26er, aiming for 0 ... :P ... reality is between 60 and 75MB
<morphis_> kyrofa: as this conflicts with what we've build for a snap where snap actually has the authority over the configuration data
<ppisati> morphis_: what's the kernel version?
<kyrofa> morphis_, long-term I imagine we'll have a hook that runs upon install that the snap can use to pre-load snapd with its config
<kyrofa> morphis_, or something similar
<niemeyer> kyrofa: Not long term, today
<kyrofa> niemeyer, we have that today?
<morphis_> ppisati: added the kernel snap rev to the bug
<niemeyer> kyrofa: Yep ;)
<morphis_> niemeyer: how? :-)
<kyrofa> niemeyer, ha!
<ppisati> morphis_: 4.4.0-1023-raspi2 29 apparently
<niemeyer> morphis_: The configure hook is called on every install and every refresh of the snap
<morphis_> ppisati: yeah, just verified: 4.4.0-1023-raspi2 #29
<niemeyer> morphis_: What exactly are you looking for?
<ogra_> thats the current one
<kyrofa> niemeyer, even without a configuration?
<niemeyer> kyrofa: Right
<morphis_> niemeyer: nothing urgent we have to discuss now if you have more important things to do for feature-freeze
<kyrofa> morphis_, so upon first install, the snap can just `snapctl set` its config, basically
<niemeyer> morphis_: Well, I'd like to clarify these points now, to ensure we don't have confusion on this area
<morphis_> niemeyer: just trying to understand how these things are supposed to work as we have a snap which assume it has the authority over its configuration data which slightly conflicts with what snapd does with the config hook
<kyrofa> morphis_, the snap still has authority, it just doesn't have the responsibility of storing it all. It can still change configs and veto change requests
<niemeyer> morphis_: Every snap can continue to have authority of its configuration, and they don't even have to implement the configure hook
<niemeyer> morphis_: snap set will fail if the configure hook is not in place, telling the user that's the case
<ogra_> ppisati, perhaps i'm missing something in th config.txt for that image ? http://paste.ubuntu.com/23280174/
<morphis_> niemeyer: yeah sure, but having a generic mechanism would make sense
<morphis_> to not reinvent the wheel again and again
<niemeyer> morphis_: Yes, and we've implemented that generic mechanism..
<morphis_> niemeyer: yeah, which is great :-)
<morphis_> niemeyer: as said, I don't say its incorrect or wrong, I am just trying to understand how its supposed to work :-)
<niemeyer> morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly
<morphis_> niemeyer: yeah, that was the point I was missing
<niemeyer> morphis_: Every time snap get/set is done, the configure hook is called again, and has a chance to adjust its configuration in any way it wants, and it may also reject the configuration proposed
<om26er> ogra_, on another question, can I assume that installation of an all-snap Ubuntu Personal (read: desktop) would technically be even faster than it is today ? Just dump of the image on the partition and account setup ?
<ogra_> om26er, well, it'd be closer to a phone or the M10 tablet we have today ... but yeah, dump it to disk and a (graphical) first-setup too runs
<ogra_> *too
<ogra_> pfft
<morphis_> niemeyer: with the sync mechanism via snapctl set it makes more sense as then I can tell snapd when something else has changed the configuration item
<ogra_> *tool
<niemeyer> morphis_: The configure hook is called with the _whole_ configuration, not just the requested changes
<niemeyer> morphis_: Yes, that's what the earlier point addresses
<niemeyer> This, specifically:
<niemeyer> 12:00:34Â <niemeyer>Â morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly
<morphis_> niemeyer: what you mean with the whole configuration? I have to do a snapctl get call to get specific items in my configure hook implementation
<niemeyer> morphis_: That's right.. I just mean the whole configuration is at hand
<morphis_> ah
<niemeyer> morphis_: Not just the delta that was requested via snap set
<morphis_> niemeyer: what about the changes stored in the snapd transaction database, when I revert to an earlier revision of a snap are all configuration changes reverted back to that revision as well?
<niemeyer> morphis_: Not yet, but I'm planning to fix that for the RC
<niemeyer> Have a good idea for how to do that in a simple way already
<om26er> Whats the speed difference of reading a file from ext4 and reading from a squashfs based snap(do we use compression of some sort?) place on ext4, have we measured that ?
<elopio> sergiusens: kyrofa: does this make sense? https://github.com/elopio/QGIS/blob/snapcraft/snapcraft.yaml#L66
<elopio> I had to move the stage packages to a different part, because otherwise it wouldn't find them during build.
<kyrofa> elopio, so it only looks in stage, eh?
<kyrofa> elopio, although you don't use `after` it seems?
<kyrofa> elopio, oh nevermind, I'm blind
<kyrofa> elopio, how does qgis find deps? cmake modules? pkg-config?
<kyrofa> elopio, those deps, specifically
<elopio> lots of cmake find modules
<kyrofa> elopio, let me take a look, hold on
<ogra_> morphis_, does your pi image with the oops actually use an unmodified config.txt ? i wonder if we are missing something there, the default is http://paste.ubuntu.com/23280174/
<elopio> thanks
<morphis_> niemeyer: sounds good
<morphis_> ogra_: its the default one
<morphis_> ogra_: that what comes via ubuntu-image/snap prepare-image
<ogra_> ok ... well, i wonder i ppisati might find some missing option regarding the uart there
<ogra_> morphis_, right, straight from the gadget snap
<ppisati> ogra_: i'm flasging an image that i just preapared
<ogra_> oki
<elopio> ralsina: I think I removed the coverage checks on integration and snaps tests. But it makes sense to check the coverage of unit tests. If a line is not executed, it's very likely that it should be removed, don't you think?
<ppisati> using the model posted in lp1630586
<ppisati> let's see
<mup> PR snapcraft#853 opened: Simplify the handler from uri tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/853>
<ralsina> elopio: could be. I was just a it frustrated about being -0.006% but then I removed an unused line ;-)
<elopio> ralsina: anyway, we don't really pay a lot of attention to those numbers, because coveralls is know to be bad at math. We only care when there's a clear missing test.
<ralsina> elopio: cool with me :-)
<ogra_> morphis_, woah, reading your syslog in bug 1630586 i see a lot of errors i dont see on any standard image ... specifically the squashfs errors are interesting
<mup> Bug #1630586: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
<morphis_> ogra_: yeah possible that those come after the first boot or so
<ogra_> hmm, actually i havent ooked into my syslog of the running pi3 here for a while ... i got the same here
<ogra_> this is worrying
<ogra_> mvo, ^^^^ did anything regarding squashfs change recently in snapd ?
<ogra_> mvo, http://paste.ubuntu.com/23280252/
<ogra_> and thre are a lot more errors
<SuperJonotron> Trying to figure out the correct way to setup the environment variables for my snap to access the writable sections.  I know I can hard code the "current" version of the snap install but it seems like this should be the version number
<SuperJonotron> not sure how to dynamically grab the version number when the snap launches
<mvo> ogra_: auto-probe magic for assertion
<mvo> ogra_: harmless
<mvo> ogra_: but noisy:/
<ogra_> phew !
<ogra_> that had me shocked for a moment
<kyrofa> SuperJonotron, have you seen this? https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<SuperJonotron> I have seen that but I was unclear on whether or not just accessing those variables alone would do the trick or if they needed to be initialized
<kyrofa> SuperJonotron, just accessing them should be enough
<SuperJonotron> I'll give that a shot.  I also have to figure out how the snap can generate a configuration file within it's read only folder where it's packaged or reference it's creation in the SNAP_DATA folder
<SuperJonotron> is this possible with say a symbolic link?
<morphis_> mvo: auto-probe magic for assertions? are they stored in squashfs?
<ogra_> likely in /writable
<ogra_> but the squashfses are matched against them i guess
<kyrofa> elopio, hmm... this isn't just using cmake, it actually shells out to python scripts as well
<kyrofa> elopio, you might need to set those variables for the build
<elopio> kyrofa: but I think I'm misunderstanding stage packages. Shouldn't they be in the stage dir, before the part builds?
<kyrofa> elopio, no, they're in the part's installdir
<kyrofa> elopio, and they get migrated along with the rest of the part to stage
<elopio> kyrofa: and they get to the installdir, before the part builds?
<kyrofa> elopio, indeed
<elopio> kyrofa: so, shouldn't the installdir be added to the paths, just like the stage dir?
<mvo> morphis_: the code will probe any block device
<morphis_> mvo: ah
<kyrofa> elopio, yeah, that's what I mean to say. The find modules will need a PYTHONPATH looking in the installdir in order to find anything, it seems
<kyrofa> elopio, but I'm a bit surprised this works with the stagedir, honestly
<kyrofa> elopio, are you sure pyqt5-dev actually needs to be staged?
<elopio> kyrofa: well, I meant that it should work magically using installdir, like it does with stage dir ^_^
<kyrofa> elopio, haha, I agree! It just means we need to figure out the magic first :P
<elopio> kyrofa: as a build package, it doesn't find it.
<kyrofa> elopio, huh, that's interesting
<elopio> and qgis does some weird things on loading, with python. So I think it's also needed in the final package. But I'm not totally sure.
<kyrofa> Yeah, whenever I see -dev packages in stage-packages, I know something is off
<kyrofa> Hmm
<mup> Bug #1630652 opened: snap revert and refresh forwards and backwards causes breakage <Snappy:New for chipaca> <https://launchpad.net/bugs/1630652>
<ppisati> ogra_: did you try to generate a pi3 image?
<ogra_> ppisati, ?
<ogra_> my scripts do that every day, why ?
<ppisati> ogra_: i'm referring to morphis_ bug
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<ppisati> ogra_: and does your image have that stack trace on boot?
 * ppisati tries without the eth cable
<ogra_> ppisati, it used to last week ... i havent freshly installed since
<ogra_> but nothing changed afaik ... so it should still have it
<ppisati> ogra_: ok, me tries without the eth cable and then tries your image
<SuperJonotron> I have an application wrapped up in a snap and running but I know it lacks a license to operate fully and the application will want to write this license into a folder within the application structure (the read only section).  I have no control over changing this behavior and need to know how to give this folder writable access when it needs to update and/or create the license file
<ara> pedronis, OK, it looks now that it takes those env variables into account, as i am getting a lot more debug messages
<kyrofa> SuperJonotron, you can't tell it where to write with a cli parameter or anything?
<ara> pedronis, but it looks like it still tries to connect to login.ubuntu.com (instead of loging.staging.ubuntu.com)
<SuperJonotron> kyrofa, I am porting a piece of existing software into the ubuntu snappy os and so I have limitations on what is exposed.  I do have direct contact with the manufacturer so I can double check what I am allowed to do but as of right now, I have not found a way to overwrite this method.  What would you suggest a solution be to overwrite the apps behavior to write into the snap environment?
<ara> pedronis, Oct  5 18:10:23 sushirider /usr/lib/snapd/snapd[21445]: logger.go:66: DEBUG: > "POST /api/v2/tokens/discharge HTTP/1.1\r\nHost: login.ubuntu.com\[...]
<SuperJonotron> kyrofa, I would also imagine I would need to create a link to the file back into the application where it expects it to be?
<kyrofa> SuperJonotron, that means the application could never be installed into e.g. /usr/local/bin either, since it's owned as root
<kyrofa> SuperJonotron, if the app requires where it is to be writable, then really your only option is to copy the entire thing into writable space
<kyrofa> And run from there
<kyrofa> SuperJonotron, but that's kinda terrible
<SuperJonotron> what about just the licensing section and create a link back to the file?
<SuperJonotron> is that allowed or will the read only status block a link being made?
<kyrofa> SuperJonotron, you can't write in $SNAP, plain and simple. No files, no links
<mup> PR snapd#2101 opened: image: support gadget specific cloud.conf file <Created by mvo5> <https://github.com/snapcore/snapd/pull/2101>
<SuperJonotron> kyrofa, thanks, I'll see if I can work with the manufacturer to overwrite the default licensing folder to reference one of the writable snap locations
<kyrofa> SuperJonotron, yeah, I'd ask for either a CLI parameter or support for an environment variable
<elopio> davidcalle: ping. Did you find the mapbox contact?
<morphis_> zyga: what's the state now?
<morphis_> zyga: can you drop me a mail before you leave tomorrow on where you leave this and what the next steps are?
<elopio> kyrofa: synapse working \o/ https://gist.github.com/elopio/dffcda326f5b51feedeb09f012ac9a44
<zyga> morphis_: yes, sure
<ogra_> jdstrand, so mvo said core should auto-land in the store now ?
<zyga> morphis_: still working on it, testing is slow
<ogra_> jdstrand, i.e. i can enable the cron build now ?
<pedronis> ara: it's my fault, the env var is SNAPPY_USE_STAGING_STORE=1
<pedronis> ara:Â I totally went by memory, and it seems my brain has dropped the prefix
<zyga> jdstrand: hey, I need your review on this https://github.com/zyga/snapd/pull/2/files
<mup> PR zyga/snapd#2: Make sure gpio exported before apparmor setup <Created by jocave> <https://github.com/zyga/snapd/pull/2>
<zyga> jdstrand: joc figured out how to solve the gpio issue but it requires that the permanent slot snippet exports the gpio to userspace
<zyga> jdstrand: so by the time apparmor snippet needs to be comoputed the gpio directory already exists and we can run realpath on it (dereference all the symlinks)
<zyga> jdstrand: I think that's okay but I wante to check with you first
<zyga> joc: ^^
<zyga> joc: good work and good thinking :) (unless jdstrand disagrees) I didn't think about it
<zyga> s/about it/of it/
<ogra_> these wifiSD cards are fun !
<zyga> ogra_: do they work?
<zyga> ogra_: tell me which you got,
<zyga> I'll drop some to amazon inbox
<joc> zyga: thanks, lets see what jamie says!
<ogra_> zyga, well, i have to solder a serial port on ... seems the documented hacker backdoors hhave been fixed (some of them at least)
<ogra_> but i guess we can actually use them for flashing the pi's for testing images
<ogra_> they come with a very tiny linux
<ogra_> and AP mode ...
<ogra_> i guess i can hack the initrd on them to give us a flashsher tool
<ogra_> zyga, transcend seems to be hackeble pretty well ...
<zyga> ogra_: OMG :D
<ogra_> i got a toshiba one as well, but that doesnt seem to run linux :/
<zyga> ogra_: can you share the link to the product you think is woth getting
<ogra_> zyga, https://www.amazon.de/dp/B010MQ13E8 ... i didnt get the transcend one from amazon though
<ogra_> they only have the flashair toshiba one in germany atm
<ogra_> or eyefi ...
<ogra_> but afaik both arent easily hackeable
<zyga> joc: please add that comment and I'll merge it into my branch
<zyga> joc: this will update the pull requast
<zyga> *request
<zyga> the main one
<zyga> joc: and if jdstrand gives it a +1 we'll be good to go
<mup> PR snapd#2093 closed: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2093>
<zyga> ogra_: thanks, it is even cheaper on amazon.es
<ogra_> heh
 * zyga -> afk
<zyga> I'll be back later, I need to rest
<mup> PR snapcraft#853 closed: Simplify the handler from uri tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/853>
<mup> PR snapd#2101 closed: image: support gadget specific cloud.conf file <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2101>
<mup> PR snapd#2098 closed: store: retry store operations (WIP) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2098>
<jdstrand> ogra_: yes
<ogra_> ok, let me try that ... you will have to approve each single one if you lied ;)
<mup> Bug #1630690 opened: A snap with git fails because it can't access /etc/mailname <Snappy:New> <https://launchpad.net/bugs/1630690>
<morphis_> zyga: aye
<morphis_> zyga: please just drop me a note per mail where you leave this
<ogra_> jdstrand, GOSH ! ... IT WORKS !
<ogra_> :)
<ogra_> http://people.canonical.com/~ogra/core-builds/ ...
<ogra_> :)
<rharper> hi, looking for any docs on creating assertions, like account and account-id;  I want to test out creating assertions, signing them and acking them;  I see various assertions in the snapd source but not sure of the required key and inputs
<jdstrand> ogra_: yay :)
<om26er> I cannot set password on all-snap image on RPi, it gives me:
<om26er> om26er@localhost:~$ sudo passwd
<om26er> passwd: Authentication token manipulation error
<om26er> passwd: password unchanged
<sergiusens> om26er shouldn't it be `sudo passwd $USER` ?
<om26er> sergiusens, my bad, it worked that way.
<om26er> I am actually used to digitalocean droplets where I am root and `passwd` just works
<om26er> I have a new project https://github.com/om26er/pigpio, its specifically for the RPi but I haven't been able to find a way to build armhf snap. The only piece I found is https://developer.ubuntu.com/en/snappy/guides/cross-build/
<om26er> which doesn't help much as there is no mention of snapcraft in that. Whats the recommended way to build armhf snaps ?
<om26er> oh, btw upload to snap store was instant, much faster than I had expected.
<om26er> brb
<mup> PR snapd#2102 opened: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2102>
<mup> PR snapd#2097 closed: snap: add `snap is-managed` for console-conf <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2097>
<SuperJonotron> Is there a system variable when running a snap for the current version folder and/or the latest version number?  http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data mentions where to find the writable directories but can't seem to find where the app install directory is defined as a variable
<cjwatson> om26er: You can build armhf snaps on Launchpad
<om26er> cjwatson, do I need to register my project on launchpad for that ?
<cjwatson> om26er: Yes.  Import the repository to a Launchpad branch (either push the same git repository manually to LP, or cross your fingers and do a git->bzr import, or wait for us to finish git-to-git imports), then you can create a snap package from the LP UI
<cjwatson> om26er: We'll be automating this further in future
<cjwatson> I think the guide you found is how to cross-build snapd itself, and it's out of date anyway ...
<cjwatson> (refers to cmd/snappy, which isn't a thing any more)
<om26er> cjwatson, ok, I will try that now.
<om26er> cjwatson, is there a change in future when git becomes the primary version control for Launchpad ?
<cjwatson> om26er: what would "primary" mean, in your opinion?
<cjwatson> om26er: I mean, in what particular sense is it not that would be changed by being primary
<om26er> cjwatson, launchpad code currently rings a be of bzr in my head, while we do have git support, most docs that we see around only refer to bzr.
<cjwatson> om26er: there are probably a bunch of docs to update spread all over the place, it's a pretty Sisyphean task
<cjwatson> om26er: many of them not maintained by us either
<cjwatson> om26er: our git hosting is lacking maybe about two or three substantial features compared to our bzr hosting, but it's definitely the way forward
<cjwatson> (imports, more useful subscriptions, direct translation commits)
<om26er> cjwatson, ok, good to know.
<cjwatson> om26er: shifting ten years of perception is going to take a while no matter what way you slice it though
<mup> PR snapd#2095 closed: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2095>
<mup> PR snapcraft#851 closed: catkin plugin: nicely handle an invalid rosdistro <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/851>
<kyrofa> Hey jdstrand, I lost track of the seccomp arg filtering, particularly relating to setpriority. Is that stuff still waiting to land?
<jdstrand> kyrofa: the feature landed. the policy to use it has not. it was deprioritized in favor of a bunch of rtm interfaces and now other rtm/ga stuff. once that stuff is done, I'm back to dbus-app PR and after that, these seccomp arg policy
<jdstrand> policies
<kyrofa> jdstrand, sounds good, thanks for the update!
<jdstrand> np
<om26er> snap install gives me 401 on all-snap.
<om26er> something broken in the image or server side ?
<om26er> om26er@localhost:~$ sudo snap install classic --devmode --edge
<om26er> error: cannot perform the following tasks:
<om26er> - Download snap "classic" (17) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/QbSFwGGAgvG8zHl9nWLY7vEee8lhgFsp_17.snap)
<mwhudson> morning
<lool> kyrofa: I sense you're about to snap cartografer for ROS!  http://opensource.googleblog.com/2016/10/introducing-cartographer.html   :-)
<lool> damn, the laser seems to be 1000 USD
<lool> there are some 150 USD ones, unidirectional though
<kyrofa> lool, haha, awesome
<kyrofa> lool, yeah, stereo SLAM is usually cheaper
<kyrofa> optical, I mean
<lool> kyrofa: I wonder if we could do the same kind of mapping with just a sonic depth sensor
<lool> kyrofa: there is one on the slam dunk
<lool> NB: running ubuntu and ROS :-D
<kyrofa> lool, sonic sensors don't typically have great range though-- do you know what that one is?
<lool> kyrofa: I'm afraid not, but you're right, it was in range at about 1m and out of range at <0.5 and >2m
<lool> it was more for collisions
<kyrofa> Yeah that's a typical use-case
<kyrofa> And for some platforms, it might be enough for mapping (i.e. small and slow-moving)
<kyrofa> Resolution wouldn't be great
<rharper> mwhudson: hey;  I playing with snap ack and assertions, and I can't seem to construct anything that snap will actually ack;  I looked at the json input you used for system-user; but was hoping to have an account and account-id one so I can test out acking multiple assertions ;  any pointers to the right json format for account-id or such ?
<mwhudson> rharper: you need a model where you are the authority, do you have that bit set up?
<lool> kyrofa: did you manage to move our ros support to indigo before roscon?  :)
<mwhudson> there is a google doc with instructions for that, let me dig it up
<kyrofa> lool, indigo has been supported for ever. I'm assuming you mean kinetic? Yessir!
<lool> err sorry kinetic
<kyrofa> lool, yeah, just landed in 2.19
<lool> nice!
<mwhudson> rharper: https://docs.google.com/document/d/1cJvRnpoQyLvY6pOLFPgUxMHrFVBCDNwAlrORARBiZlU/edit
<mwhudson> hm that doc could/should probably be updated to include the unattended user creation flow
<rharper> mwhudson: yeah, I've followed that but I didn't build a new image;  I wanted to just ack the system-user (or in my case an account-id ) assertion
<rharper> mwhudson: but I think you're suggesting that I have to boot into an image with my own model assertion enabled
<mwhudson> rharper: i don't know about account-id assertions, but for system-user the authority has to be the brand, so you need an image where you can sign for the brand
<mwhudson> presumably there is/will be some way to sign system-user assertions for the canonical brand but i certainly don't know what that is
<rharper> mwhudson: right;  I'm hoping to test importing any type of assertion via the cloud-init user-data; so I was hoping to have *some* valid assertions that snap could actually ack
<mwhudson> rharper: ahh
<rharper> and right now I've got zero
<rharper> so that makes testing a bit hard
<mwhudson> rharper: use snap download to download a snap, this also downloads assertions
<mwhudson> $ snap download hello
<rharper> ok
<mwhudson> $ ls hello_20.snap*
<mwhudson> hello_20.snap  hello_20.snap.assertions
<rharper> indeed
<mwhudson> i assume snap will ack hello_20.snap.assertions ?
<mwhudson> haven't tried but seems likely
<rharper> yay
<rharper> % sudo snap ack hello_20.snap.assertions
<rharper> error: cannot assert: cannot decode request body into an assertion: assertion body length and declared body-length don't match: 3494 != 717
<rharper> I've been seeing that a lot key body not matching
<rharper> so maybe I did get one right
<rharper> hard to tell
<mwhudson> uhhh
<mwhudson> now i guess you need someone who knows what they are talking about i guess :)
<rharper> I'm one step further, so many thanks for your help
<mwhudson> snap (on my desktop) seems happy with that file
<rharper> lemme try on a fresh system
<rharper> who knows what I've got on my laptop
<caio1982> rharper, mwhudson: i am not very familiar with ack and dunno if it's a bug or by design but the assertions file download fetches contains *multiple* assertions and ack parses a single one, so you need to split it into (currently) 3: account-key, declaration and revision, then ack will work for each one of them
<caio1982> that explains the body-length mismatch above
<mwhudson> i really thought snap ack was supposed to handle that
<caio1982> me too
<mwhudson> but that would explain the problem indeed
<caio1982> but as i said, i dont even use ack right now so i dont know if it's on purpose
<rharper> caio1982: mwhudson: yes I think that's a bug;  I've been told to put multiple assertions into a single file
<rharper> the assert.Decode() code comments suggests it's similar to a multi-part MIME format, with new lines separating portions
<rharper> so certainly feels like a bug
<caio1982> i would certainly subscribe to it if it was filed ;-)
<rharper> fwiw, the 717 is the right size for the public-key
<lool> rharper: hey have you by any chance latest email from MikeB on the devices list? he brings up a bunch of cloud-init start time questions, would you think we could extract some cloud-init runtimes from his system?
<lool> run times, not runtimes sorry
<rharper> lool: do we know if the image has the cache purged or not ?
<lool> rharper: I do not
<mup> PR snapd#2090 closed: interfaces,overlord/ifacestate: initial cleaning up of no arg AutoConnect related bits <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2090>
<rharper> the python cache stuff that was discussed on the console-conf thread
<lool> rharper: https://lists.snapcraft.io/archives/devices/2016-October/000082.html
<lool> rharper: oh the missing cache creates performance issues?
<lool> rharper: that might be it, but I'd be surprized it'd be that bad; these switches are supposed to be x86-64, typically some GHz and SSD storage
<lool> the processing power is not crazy, it's more like a laptop configuration
<rharper> it's not that bad on x86;  it's more likely something to do with the cloud-config
<lool> Yes, I figured it would be more like timeouts
<lool> he mentions an instance-data http connection
<lool> you know, the AWS stuff
<rharper> and which cloud-init;  the version in yakkety until yesterday or so had issues with DNS due to ordering around systemd's dbus socket
<lool> that seemed weird
<rharper> right, if those show up, very likely that the no-cloud seed was never embedded
<lool> rharper: how about I ask these questions and Cc: you on it?
<rharper> sure
<lool> rharper: I guess you're not on the devices@ list
<rharper> I am
<rharper> I can reply
<lool> thanks, that'd be great
<rharper> and if you know how to create account-id or account assertions and be able to ack them; that'd help me work cloud-init importing snap assertions   (or point me to who does know)
<lool> rharper: I wish I knew!  :-)
<lool> rharper: let me check the snap login code
<lool> rharper: at least I can point at sample data for it; check snapd/tests/main/ack/alice.account
<rharper> heh
<rharper> yeah, I'm looking for the json format for account-id or account, so I can pipe that through snap sign, and then snap ack the output of sign
<mup> PR snapd#2103 opened: store: send correct JSON type of string for expected payment amount <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2103>
<mup> PR snapd#2102 closed: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2102>
<lool> rharper: so to dump account assertions of a system, snap known account; you can import with snap ack
<lool> rharper: but I guess you wanted to create the contents from scratch?
<rharper> that might be good enough
<tyhicks> jdstrand, zyga: I'm trying to decide if a bug I'm seeing while running a snap inside a lxd container is caused by the container environment or possibly by snap-confine mount oddness - have you seen anything like this before? https://paste.ubuntu.com/23281705/
<mup> PR snapcraft#854 opened: Decouple state handling from plugin options <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/854>
<jdstrand> tyhicks: never seen that
<jdstrand> tyhicks: but I've not tried running snaps in a container yet
<jdstrand> getting there
<tyhicks> jdstrand: no problem, I'm fairly confident that it is a container issue
<mup> PR snapcraft#855 opened: tools: script to talk to the staging servers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/855>
<zyga> tyhicks: looking
<zyga> tyhicks: interesting
<zyga> tyhicks: is 'd????????? ? ?    ?       ?            ? 27
<zyga> tyhicks: is that caused by stat failure?
<zyga> do you get any apparmor denials?
<zyga> tyhicks: to answer, I haven't seen anything like this
<tyhicks> zyga: that's what happens when a dentry in the kernel doesn't have a corresponding inode (negative dentry)
<tyhicks> zyga: I'm not sure if there are other situations where that output is display
<tyhicks> displayed*
<zyga> tyhicks: oh
<tyhicks> zyga: there are no apparmor denials
<zyga> tyhicks: I did see sooome of that
<rharper> caio1982: mwhudson: snapd 2.16  in xenial-proposed will snap ack the hello.snap.assertion just fine
<zyga> tyhicks: can you cat mountinfo please?
<zyga> tyhicks: does it contain "deleted" anywhere?
<tyhicks> zyga: no "deleted" in mountinfo
<zyga> tyhicks: I'm sure you know but there are a few pending pull requests on snap confine up
<rharper> as well as the 'snap known account' output as well ; cool
<zyga> tyhicks: it looks all sane?
<zyga> tyhicks: and they relate to lxd
<tyhicks> zyga: it does look sane
<tyhicks> zyga: hmmm
<tyhicks> zyga: btw, this is a yakkety environment with snapd from yakkety-proposed
<tyhicks> zyga: thanks for your help, I'll file a bug and get some more eyes on the report
<zyga> tyhicks: please do, I'll try to look at it when I can
<zyga> I'm off next week though
<zyga> and tomorrow/day after I'm flying
<zyga> and then roscon
<mup> PR snapd#2104 opened: debian, tests: enable spread tests on trusty <Created by vosst> <Conflict> <https://github.com/snapcore/snapd/pull/2104>
<tyhicks> stgraber: are there still any pending snapd/snap-confine changes (outside of snapd from yakkety-proposed) needed for bug #1611078? I see that you have fix-committed for the Snappy task but I'm not sure what that represents
<mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <Snappy:Fix Committed by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
<tyhicks> stgraber: I'm having trouble running snap commands as a normal user inside a container
<pedronis> rharper: yes, we changed snap ack to take streams of assertions only in 2.16
<mup> PR snapcraft#856 opened: Call organize() after building <Created by josepht> <https://github.com/snapcore/snapcraft/pull/856>
<mup> Bug #1630789 opened: normal users can't run snaps inside of LXD containers <Snappy:New> <https://launchpad.net/bugs/1630789>
<mwhudson> rharper: ah ok, good to hear
#snappy 2016-10-06
<jdstrand> kyrofa: note that process-control can be used for setpriority until seccomp arg filtering policy is available
<mup> PR snapd#2105 opened: snapstate: only import defaults from gadget on install <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2105>
<blr> for a cmake snap, is there any way I can specify which directory the source lives in within the repo I have set to 'source'?
<blr> oh nvm, found it 'source-subdir' :)
<dholbach> good morning
<didrocks> good morning dholbach
<pbek> Good morning, dholbach ^_^
<dholbach> salut didrocks, hey pbek
<morphis__> zyga: ping
<ara> good morning zyga
<ara> zyga, any updates on snap-confine 1.0.43 in xenial-proposed? is that happening?
<ara> pedronis, morning! found the issue why it wasn't connecting to staging. The env variable is SNAPPY_USE_STAGING_STORE (rather than USE_STAGING_STORE only, that we talked yesterday)
<ara> pedronis, it works that way, thanks a lot for your help yesterday!
<pedronis> ara: yes, IÂ think IÂ pinged late about that, sorry IÂ recalled from memory and memory had dropped the prefix
<mup> PR snapd#2106 opened: tests: exclude all-snap arm systems for the snap-connect test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2106>
<Chipaca> ogra_, o/
<zyga> morphis__: hey, I'm working on some more fixes, I'll be pushing code at each airport I'm at today, I'll write an update in the evening before I depart on the final connection
<morphis__> zyga: awesome! thanks a lot!
<zyga> ara: I don't know, if you can please work with jdstrand to get this into yakkety and sru https://github.com/snapcore/snap-confine/releases/tag/1.0.43
<zyga> ara: no packaging changes required
<zyga> morphis__: as a precaution I added support for offline testing so I'm good on the (long) journey ;)
<morphis__> zyga: ok
<Chipaca> silly core-m going to sleep in funky ways
<Chipaca> ogra_, i got the dragonboard working wiht the nexdock :-)
<Chipaca> ogra_, do i get a putty medal
<mup> PR snapcraft#857 opened: Document the grade option <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/857>
<ogra_> Chipaca, heh
<mup> PR snapd#2103 closed: store: send correct JSON type of string for expected payment amount <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2103>
<mup> PR snapd#2107 opened: many: add payment-declined error kind <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2107>
<mvo> mwhudson: if you or cyphermox could merge https://launchpadlibrarian.net/288530592/subiquity_0.0.19~xenial_0.0.19~xenial+mvo1.diff.gz that would be great
<mup> PR snapcraft#855 closed: tools: script to talk to the staging servers <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/855>
<sergiusens> dholbach hey hey; are you a bash completion master? I wish you are and can look into allowing file completion, it drives me nuts :-P
<dholbach> sergiusens, I'm not :-/
<dholbach> sergiusens, but I can see if I can find something
<sergiusens> dholbach heh, cwayne did the original contrib, we should pester him ;-)
<cwayne> sergiusens: uh oh what'd I do
<sergiusens> cwayne bash completion :-)
<sergiusens> you are up early ;-)
<cwayne> sergiusens: :)
<cwayne> i can take a look at expanding it, sure
<cwayne> what specifically are you lookin for?
<sergiusens> cwayne we have a bug report from dholbach LP: #1630922
<mup> Bug #1630922: Bash completion for "push" is incomplete <Snapcraft:New> <https://launchpad.net/bugs/1630922>
<sergiusens> cwayne but basically anything that takes a file as an argument has me banging the tab key to no avail :-)
<ogra_> get a new tab key :P
<ppisati> ogra_: where can i download pi2-kernel_15.snap? i need the physical file to change some of its content (and regenerate an image)
<ogra_> ppisati, https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel
<ppisati> ogra_: ta
<ogra_> (click on "Successfully built")
<mup> PR # closed: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#2107
<jdstrand> ara (cc zyga): do you want me to upload 1.0.43 to yakkety and xenial?
<ara> jdstrand, please, apparently .42 (in xenial-proposed) had a regression, so it is never going to be go to -updates
<jdstrand> I see
<jdstrand> ara: ok, I'll do that now and ping you
<ara> jdstrand, thanks!
<mup> Bug #1630976 opened: Incomplete home directory mapping <Snappy:New> <https://launchpad.net/bugs/1630976>
<mup> PR # opened: snapd#2033, snapd#2058, snapd#2065, snapd#2072, snapd#2083, snapd#2087, snapd#2091, snapd#2096, snapd#2104, snapd#2105, snapd#2106, snapd#2107
<jdstrand> ara: do you have the bug for the regression?
<ara> jdstrand, let me check, zyga mentioned yesterday on this same channel, let me check the backlog
<ara> jdstrand, https://bugs.launchpad.net/snap-confine/+bug/1630479
<mup> Bug #1630479: PATH is not set after namespace is initialized <Snappy Launcher:Fix Committed by zyga> <snap-confine (Ubuntu):In Progress by zyga> <https://launchpad.net/bugs/1630479>
<jdstrand> zyga: can you make sure this is in 1.0.44: http://paste.ubuntu.com/23284317/
<jdstrand> ara: thanks!
<jdstrand> zyga: also http://paste.ubuntu.com/23284321/
<zyga> jdstrand: sure
<zyga> jdstrand: re, .43, yes, let's please get it into yakkety and xenial
<zyga> jdstrand: will mount options=(ro rbind) /snap/{,ubuntu-}core/*/var/lib/** -> /var/lib/**,
<zyga> jdstrand: will that cover /snap/core/current//var/lib/logrotate -> /var/lib/logrotate
<zyga> jdstrand: or do I need some /**/ to cover directories?
<stub> What do I do here? https://pastebin.canonical.com/167232/ . It seems the python3 pulled in by the python plugin does not patch the python3 pulled in as a stage package in another part (that embeds a Python interpreter)
<jdstrand> zyga: /snap/{,ubuntu-}core/*/var/lib/** would cover it. is ../** needed though? can you use /snap/{,ubuntu-}core/*/var/lib/logrotate/ -> /var/lib/logrotate/ instead?
<mup> PR snapd#2108 opened: devicestate: merge overlord/boot into devicestate <Created by mvo5> <https://github.com/snapcore/snapd/pull/2108>
<zyga> well , we don't know which directories there are there
<zyga> we're seeing a failure in autopkgtests
<zyga>  cannot bind mount /snap/core/current//var/lib/logrotate -> /var/lib/logrotate with flags 0x85007. errmsg: Permission denied
<zyga> no apparmor denial log though, we'd have to reproduce it now
<zyga> I was wondering if apparmor changed in any way
<zyga> the mount happens with the following flags MS_RDONLY | MS_REC | MS_SLAVE | MS_NODEV | MS_NOSUID
<zyga> but AFAIK apparmor doesn't model all of them
<jdstrand> zyga: re don't know> this is an old conversation. is it truly dynamic now and we don't know or is it just to ease future maintenance? if the former, we need a glob rule, if the later, let's continue adding more specific rules
<jdstrand> zyga: you probably need: /snap/{,ubuntu-}core/*/var/lib/*/ -> /var/lib/*/
<stub> huh. The only difference is munged shebang lines. I think I saw the python plugin messing around with shebangs
<zyga> jdstrand: ack, I'll try to reproduce this and fix it when I'm in korea with better network
<jdstrand> zyga: ie, the trailing '/' (and you don't need **/, just */ iirc the mirrored /var/lib code
<jdstrand> )
<zyga> thanks!
<zyga> this doesn't explain why adt fails but at least I have more knowledge
<jdstrand> zyga: looking at that source mount (/snap/{,ubuntu-}core/*/var/lib/*/), we should be able to enumerate those since we know what is in the core snap. however, would we list everything in /var/lib or would we skip stuff? iirc, there are things we would skip, so a more exact match would be best (though I'd be ok with a glob rule with deny rules for what we wouldn't mount from /snap/{,ubuntu-}core/*/var/lib/*/)
<zyga> jdstrand: jdstrand overdue gift from the plane
<zyga> geeez net is slow from the phone
<zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/166
<mup> PR snap-confine#166: Allow running qemu spread tests offline <Created by zyga> <https://github.com/snapcore/snap-confine/pull/166>
<jdstrand> woo!
<zyga> Ill merge things on the plane
<zyga> just adding remotes
<mup> Bug #1616605 changed: Cannot open files from NFS drive mounted in /media <snapd-interface> <Snappy:Fix Released by ssweeny> <https://launchpad.net/bugs/1616605>
<didrocks> jdstrand: hey! I see that to be able to run the "ping" command, we need one of those interfaces: firewall-control, network-control, network-observe
<didrocks> jdstrand: so, it means, there is no interface that autoconnects to enable pinging a remote server?
<didrocks> (I guess there are security implicationsâ¦)
<mup> PR snapd#2033 closed: many: move firstboot code into the snapd daemon <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2033>
<jdstrand> didrocks: that's correct. it has to do with the fact that it is setuid and what that would mean with 'safe' policy
<jdstrand> didrocks: however, there are several things here to consider: 1) snaps can test for connectivity using other means that don't need setuid (eg, perform a GET / on http), 2) recent kernels allow ping to be used without setuid, so the snap could ship that ping, 3) snap declarations will allow autoconnecting interfaces after the snap is approved, d) I *might* be able to make something work now that the seccomp arg filtering feature landed
<didrocks> jdstrand: actually, I'm just trying to ship some toolbox for health check that consul would use. ping utility is one of them. Is there any ping tool that you know for 2)?
<didrocks> jdstrand: also, I just tried to network-observe + connect the socket, I'm still getting ping: icmp open socket: Operation not permitted
<didrocks> (but nothing in scanlogs now)
<didrocks> (and nothing in syslogs)
<jdstrand> didrocks: you mean s/socket/interface/?
<didrocks> interface, yeah, sorry
<didrocks> :network-observe                   consul
<jdstrand> tyhicks: what is the status of setuid-less ping?
<jdstrand> didrocks: note, tyhicks will be online in a bit
<didrocks> jdstrand: that would be great as a simple utility for use with health checks ;)
<didrocks> however, in the fact that there is no log in syslog and that error ^ I'm puzzled
<jdstrand> didrocks: there was this: http://tinyurl.com/h6obc5g
<jdstrand> didrocks: what ping is it using? the system ping or its own ping? if its own ping, does it work with sudo?
<didrocks> jdstrand: it's coming from a stage-package I took (can use another one if needed): iputils-ping
<didrocks> let me try with sudo
<didrocks> yep, works with sudo
<jdstrand> didrocks: the problem with that ping is it requires kernel support. I forget the details of the earliest kernels, so an old 3.10 kernel (for example) might not work with this ping
<didrocks> $ uname -a
<didrocks> Linux n1 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
<didrocks> not that old :)
<jdstrand> didrocks: right, so with stage-packages, the setuid bits are (correctly) stripped
<didrocks> ah, that's the reason whyâ¦
<didrocks> ok, making sense then
<jdstrand> didrocks: but the ping in stage-packages doesn't have the patch for setuid-lessness
<didrocks> so, I guess the setuid-less ping is the only way
<jdstrand> didrocks: well, use /bin/ping from the core snap instead of stage-packages
<jdstrand> didrocks: that will work with network-observe
<didrocks> ok, let me give it try!
<didrocks> jdstrand: indeed, works perfectly with that + network-observe
<jdstrand> it might be fun to have a part or something with the patched ping. iirc, the patch to ping went upstream and it was accepted. that patch just didn't make it into Debian/Ubuntu yet. tyhicks would need to confirm
<didrocks> thanks a lot, that would do it for now :)
<didrocks> oh ok
<didrocks> yeah, I'm creating some sort of general "utility" part/content-interface
<didrocks> to be used as health check toolbox
<jdstrand> didrocks: compiling upstream ping from source might be the way to go then if connecting network-observe is onerous
<didrocks> jdstrand: yeah, sounds like it. do you have the link for the official upstream source (I find some github and suchâ¦), and debian/copyright doesn't point to a working ftp
<jdstrand> didrocks: fyi, I added exploring 'd' (hehe, meant '4' in my list) to the card on implementing seccomp arg filtering policy. that card is down a ways cause of various critical cards
<jdstrand> didrocks: I'll defer to tyhicks there. iirc, he submitted the patch
<didrocks> oki :)
<didrocks> jdstrand: yeah, no worry, thanks for helping, at least, I have options and I am unblocked :)
<jdstrand> cool
<mbenz> ogra: I am trying to port minicom from 15.04 to UC16 and need to access tty devices, isn't there a serial-port plug?
<ogra_> mbenz, i think there is ....https://github.com/snapcore/snapd/blob/master/docs/interfaces.md look for serial
<ogra_> needs the user to manually connect though
<didrocks> ogra_: our discussion was that it's not listed via snap interfaces though, even being in the code
<didrocks> is that ubuntu-core doesn't provide the slot?
<ogra_> didrocks, hmm, thats a zyga question i fear
<mbenz> ogra: I will look at doc but some background on what I have tried. I added the plug in yaml and install but see '-' listed as slot and trying to connect gives a failure unlike using modem-manager which works but doesn't have access to /dev/ttySx
<ogra_> righ, smells like something is missing here
<ogra_> as didrocks said
<mbenz> should I work with zyga or log a bug?
<ogra_> well, perhaps it is known, i guess zyga had enough pings from us to notice the discussion once he checks IRC again ;)
<ogra_> wait for him ... then log a bug if he thinks you should
<mbenz> ok
<mbenz> for now I will just run in devmode and debug lock file and config file locations
<jdstrand> tyhicks: as it happens, I am preparing a snap-confine upload and so I can remove the owner check from '@{PROC}/*/mountinfo r,' if that would help things. please advise
<jdstrand> tyhicks: oh, I see you said to drop it in comment #4
<tyhicks> jdstrand: thanks! could you also add the rule in comment #5?
<tyhicks> jdstrand: @{PROC}/[0-9]*/attr/current w,
<tyhicks> jdstrand, didrocks: re setuid-less ping, the patches landed in upstream iputils but we don't yet have a new enough iputils in any of our releases
<tyhicks> jdstrand, didrocks: it isn't as simple as that, though
<tyhicks> jdstrand, didrocks: setuid-less ping doesn't have full functionality so there's decisions to be made about whether that loss of functionality is ok, if we need to have multiple packages (one for setuid, one for no setuid), etc.
<tyhicks> jdstrand, didrocks: also, you can't ship your own setuid-less ping in a snap until Ubuntu opens up the net.ipv4.ping_group_range sysctl to a range that includes our normal user's gid
<jdstrand> tyhicks: hmm, so a snap that build iputils from upstream still wouldn't work cause of the sysctl, which we could allow setting, but probably in network-control, a non-auto-connected interface
<jdstrand> tyhicks: yes, already done. about to upload this: http://paste.ubuntu.com/23284740/
<jdstrand> tyhicks: fyi, https://github.com/snapcore/snap-confine/pull/167
<mup> PR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/167>
<didrocks> tyhicks: hum, ok, so I'm going with the ubuntu-core ping version now, with the correct interface
<jdstrand> tyhicks: if you +1 that PR, I'll commit it
<tyhicks> jdstrand: I've +1'ed
<tyhicks> didrocks: yeah, that's your best option right now
<tyhicks> jdstrand: we wouldn't want to allow a snap to set the sysctl, we'd want to set it ourselves
<tyhicks> jdstrand: the least risky option would be set it at the distro level but continue to ship the setuid ping
<tyhicks> jdstrand: that would allow snaps to ship their own setuid-less ping
<jdstrand> tyhicks: technically, it could be at the core snap level
<tyhicks> jdstrand: yeah, it could be
<jdstrand> ara (cc zyga): uploaded snap-confine 1.0.43-0ubuntu1 to yakkety just now. aiui, autopkgtests have a long queue due to glibc upload. I'll work on xenial now
<ara> jdstrand, thanks!
<mup> PR snapd#2105 closed: snapstate: only import defaults from gadget on install <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2105>
<mup> PR snapd#2109 opened: tests: update tests now that we do not have snapd.boot-ok anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/2109>
<didrocks> hum, the consul snap is already taken, I think it's you elopio?
<didrocks> elopio: I have a working version of it (which does a little bit than --help or local dev agent) and want to upload it to the store, do you mind add me to collaborators if it's really you? :)
<jdstrand> ara (cc zyga and tyhicks): ok, snap-confine 1.0.43 with https://github.com/snapcore/snap-confine/pull/167 uploaded to both yakkety and xenial-proposed. yakkety is building, xenial-proposed needs a member of the sru team and the bugs to be done
<mup> PR snap-confine#167: drop 'owner' check on mountinfo and allow write to @{PROC}/[0-9]*/attr/current <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snap-confine/pull/167>
<jdstrand> ara: at this point, I think my part for helping zyga is done?
<ara> jdstrand, thanks!
<tyhicks> jdstrand: thank you!
<jdstrand> np
<mup> PR snapd#2106 closed: tests: enable tests related to the home interface in all-snaps <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2106>
<mup> PR snapd#2109 closed: tests: update tests now that we do not have snapd.boot-ok anymore <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2109>
<mup> PR snapd#2110 opened: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal <Created by pedronis> <https://github.com/snapcore/snapd/pull/2110>
<jdstrand> roadmr: hey. ok, I'm going to start work on the review tools for snap declarations now
<jdstrand> roadmr: and wanted to sync up. is now a good time?
<mup> PR snapcraft#854 closed: Decouple state handling from plugin options <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/854>
<zyga> jdstrand: https://launchpad.net/~command-not-found-developers/+member
<zyga> er
<zyga> bad link
<zyga> I meant this: http://paste.ubuntu.com/23285366/
<jdstrand> zyga: you mean that is what you wanted uploaded instead of what I did?
<zyga> jdstrand: no, that's just a patch we should probably add to .43's debian packaging
<zyga> jdstrand: I found this on the plane
<zyga> jdstrand: not sure why it broke, it definitely used to work
<zyga> jdstrand: maybe a fault in how tests were set up
<zyga> this is strictly packaging, the upstream release is OK
<zyga> jdstrand: I merged some of your branches on the plane
<jdstrand> zyga: fyi, 1.0.42-0ubuntu3 on yakkety has 755
<jdstrand> zyga: can you file a bug? I'd like to see the yakkety version migrate. I need to focus on snap declarations now, but can circle back to this maybe later today/tomorrow
<zyga> jdstrand: sure, thanks!
<zyga> jdstrand: I will, filing bugs on the plane is harder than sbuilding fixes :)
<roadmr> jdstrand: hello! Sorry, I was out but i'm back. Sure, let's chat
<zyga> roadmr: o/
<roadmr> hello zyga
<zyga> (just saying hi :)
<roadmr> zyga: hello :) how are you doing?
<zyga> roadmr: good, sprinting, patching, hacking :)
<roadmr> you hacker :)
<roadmr> zyga: awesome work btw, congrats
<roadmr> jdstrand: (or if you're e.g. out lunching or something, we could sync later today)
<jdstrand> roadmr: hey, so my plan is to embed the snapd base declaration for now. then take the snap declaration as a command line argument. on initial upload, the store would provide an empty snap declaration. after that, whatever is saved via the store ui. is this what you had in mind?
<jdstrand> roadmr: no, I'm here
<roadmr> jdstrand: ohai :)
<roadmr> jdstrand: no, our code would pass the meat of the plugs and slots, it's how we've coded it right now
<jdstrand> roadmr: sorry, that is what I meant
<roadmr> jdstrand: we had a call earlier today where the issue of "how is it serialized?" came up, which applies to the tools as well
<jdstrand> roadmr: can you paste me an example of what it will feed to the tools?
<roadmr> jdstrand: so on initial upload or if the snap-declaration has no plugs/slots, we call crt without the --plugs or --slots arguments
<jdstrand> that works fine
<jdstrand> roadmr: oh, you are splitting up --slots and --plugs?
<roadmr> jdstrand: yes, that's why I meant by the "meat"
<roadmr> jdstrand: because if not, I'd have to pass you a blob containing both plugs and slots which you'd have to parse...
<roadmr> jdstrand: and I'd have to massage it too, since I'd have to aggregate both headers somehow
<jdstrand> roadmr: I was thinking you'd do --decl=... and that would just have slots: and plugs:
<roadmr> jdstrand: we could modify our code to give you the snap-declaration document in its entirety
<jdstrand> well I haven't gotten very far, so I can adjust
<jdstrand> roadmr: what is in --plugs and --slots?
<roadmr> jdstrand: yea... ok so what we'd pass is a json representation of slots/plugs, as edited my the reviewer
<jdstrand> json?
<roadmr> jdstrand: yep. I guess it could be a collapsed-in-one-line json thing
<jdstrand> roadmr: so the store has 'Edit declaration assertion'
<jdstrand> roadmr: and two text areas
<roadmr> jdstrand: so the workflow is: we call crt with either --plugs/slots or not. If c-r-t says there's trouble with the payload (say, this payload would cause the snap to not install), the reviewer is expected to craft a suitable payload in those fields
<jdstrand> roadmr: what goes in there? the yaml-esque payload and you convert that to json for the tools?
<roadmr> jdstrand: then redo the crt review (there's a button for that) and once it passes, it approves the snap
<roadmr> jdstrand: no, the json payload goes there. We'll never edit the yamlesque version by hand
<jdstrand> the json payload
<jdstrand> hmm
<roadmr> jdstrand: what happens is, once the tools are happy with the json payload, we update the snap-declaration, passing a dict built from that json (essentially plugs=json.loads(the_json_payload))
<roadmr> jdstrand: then the snap-declaration will have the yamlesque thing. But the store keeps a copy of the original JSON for human editing
<roadmr> jdstrand: now, on subsequent upload, I pass the tools the json; if they're happy, then automated review just passes and I don't update the assertion at all (since it's supposed to already have that payload)
<jdstrand> roadmr: I have some concerns that the reviewer needs to enter json instead of yaml, since the declaration spec uses yaml
<roadmr> jdstrand: hehe what I keep hearing about that is "it's not really yaml" :)
<jdstrand> roadmr: plugs and slots are just dicts
<roadmr> jdstrand: that leaves us in a weird situation because we could help the reviewer by at least superficially validating json or pure-yaml syntax, but if it's some yamloid thing, the thought of crafting a custom validator sounds painful
<roadmr> jdstrand: yes; one characteristic of the json is that it has to parse to a dict. For example, '"string yay"' is valid json but won't result in a dict
<zyga> roadmr: json doesn't *have to* parse to a dict, most parses can just return any valid json type
<roadmr> zyga: yes, I meant for this particular case, because SAS does expect a dictionary/map
<jdstrand> roadmr: ok, let's backburner this discussion since it is only something the reviewer would see and for the moment, that would be me
<roadmr> jdstrand: sure
<jdstrand> roadmr: alright, so the tools gets no --plugs or --slots on initial upload. after that the store will give a json file for --plugs and/or --slots?
<jdstrand> roadmr: then the tools do its thing. if the tools are not happy, what do you want it to do, exit with error? (I can use a particular error code if that helps)
<roadmr> jdstrand: so we could give you an inline string --plugs='{"foo": "bar", ...}' *or* we could point to a file containing the separated payload --plugs=/tmp/plugs-for-snap-XXXXX.json)
<roadmr> jdstrand: yes, that sounds good, we can check for that error code and say "needs to edit the payload".
<jdstrand> roadmr: I think a file would be best. that string might get long and hit an argv limit
<jdstrand> roadmr: what should we do if there are errors/warnings in addition to a payload error?
<roadmr> jdstrand: I think the tools output a jsony thingy with the results too, right? if you could have a specific key there with a meaningful message (e.g. plugs don't allow use of interface FOO which the snap wants to use") that'd make reviewers' (you!) jobs much easier
<roadmr> jdstrand: ok, let's aim for passing you a file
<jdstrand> roadmr: the tools can do that helpful stuff no problem (we do that already). as for the json thingy, are you already passing --json to the tools?
<roadmr> jdstrand: I think we are! let me check
<roadmr> jdstrand: yes, /path/to/click-review --json /path/to/package.snap
<roadmr> jdstrand: a new invocation would be /path/to/click-review --json --plugs /path/to/plugs.json --slots=/path/to/slots.json /path/to/package.snap
<jdstrand> roadmr: if so, this is easy. I will add this code to a new file (sr_declaration.py) which means it'll automatically get put into an area you can process (eg, decl-snap-v2)
<jdstrand> ok good
<roadmr> awesome :)
<jdstrand> roadmr: these are the return codes currently:
<jdstrand> RETURN CODES
<jdstrand>   0     found no errors or warnings
<jdstrand>   1     checks not run due to fatal error
<jdstrand>   2     found errors and/or warnings
<jdstrand>   3     found warnings
<mup> PR snapd#2111 opened: snap: ignore /dev/loop addings from udev <Created by mvo5> <https://github.com/snapcore/snapd/pull/2111>
<jdstrand> roadmr: add '4  found snap declartion conflicts'
<roadmr> jdstrand: sounds good to me. It'd be for correctness only because I checked and we don't use the return code at all :(
<roadmr> jdstrand: we rely entirely on the json output
<jdstrand> roadmr: the question then is, should I return 2 if have snap decl conflicts + errors/warnings?
<roadmr> jdstrand: yes, sounds like 2 encompasses "other errors *and* snap decl conflicts" fine
<jdstrand> roadmr: ok, then I return 4 if just snap decl conflicts and 2 if other conflicts. we can revisit that
<jdstrand> ok cool
<roadmr> totally, that makes sense
<jdstrand> roadmr: what is the status of the store today? I imagine you are just waiting on me so you can uncomment the code to pass --slots and --plugs?
<roadmr> jdstrand: yes, but we also need to fix the "parse json and pass the dict to SAS" (so: please DON'T edit those plugs/slots fields :)
<jdstrand> np
<roadmr> jdstrand: the code to pass --slots/--plugs is behind a toggle so we can flip it quickly if we break something
<roadmr> jdstrand: but right now it won't work really because it passes inline strings
<jdstrand> roadmr: ok, so, is this ok as part of the json output: http://paste.ubuntu.com/23285610/
<roadmr> jdstrand: perfect!
<jdstrand> roadmr: ok, great
<jdstrand> I think that is everything
<jdstrand> at least on my end
<jdstrand> do you have questions or is there anything else I need to know about?
<roadmr> jdstrand: I think this is clear, just a few tweaks to what we were envisioning
<jdstrand> ok, I'll get to work on this. I will ask for a review when ready'
<roadmr> jdstrand: thanks! I'll summarize in the design doc we have and get cracking
<roadmr> \o/
<jdstrand> roadmr: great :)
<roadmr> this is awesome, almost as awesome as when sas started exploding due to me having created a bad payload \o/
<jdstrand> haha :)
<mup> PR snapd#2112 opened: systemd: Correct the mount arguments when mounting with squashfuse <Created by tyhicks> <https://github.com/snapcore/snapd/pull/2112>
<om26er> Hi! Where can I find documentation on how to consume the gpio interface ?
<jdstrand> roadmr: in the json output, lets use snap.v2_declaration instead of snap.v2_decl
<jdstrand>   "snap.v2_declaration": {
<jdstrand>     "error": {},
<jdstrand>     "info": {},
<jdstrand>     "warn": {}
<jdstrand>   }
<roadmr> jdstrand: sounds good, noted
<mup> PR snapcraft#844 closed: Add `snapcraft history` <Created by maxiberta> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/844>
<sergiusens> maxiberta mind fixing snapcraft#845
<mup> PR snapcraft#845: Add `snapcraft status` <Created by maxiberta> <Conflict> <https://github.com/snapcore/snapcraft/pull/845>
<sergiusens> ?
<tyhicks> zyga: thanks for the review! do you know if there's going to be another snapd release and upload before yakkety is released?
<riverloop> Hey, I tried building a snap of mpv using the examples from snappy-playpen on GitHub.
<riverloop> I successfully built the snap but mpv can't access any files when I try to play something using it.
<riverloop> I tried also playing a YouTube url. ffmpeg showed some error.
<riverloop> What may be the reason?
<tyhicks> niemeyer: hi - I'm looking for some guidance on getting https://github.com/snapcore/snapd/pull/2112 into yakkety
<mup> PR snapd#2112: systemd: Correct the mount arguments when mounting with squashfuse <Created by tyhicks> <https://github.com/snapcore/snapd/pull/2112>
<tyhicks> niemeyer: everything is in place, except for that small change, for snaps to work in unprivileged lxd containers
<tyhicks> niemeyer: I don't know if there's another snapd upload planned before yakkety's release, if I should apply that patch to what's in yakkety-proposed and make a new upload, or if you're fine with including that fix in an SRU
<mup> PR snapd#2110 closed: overlord/devicestate: don't bail out on the first error in DeviceManager.Ensure, subcalls are fairly orthogonal <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2110>
<mup> PR snapd#2111 closed: snap: ignore /dev/loop addings from udev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2111>
<niemeyer> tyhicks: I think it's fine to see it in an SRU and in master
<niemeyer> tyhicks: let me response to the PR there
<tyhicks> thank you
<niemeyer> tyhicks: Done, let me know what you think
<pedronis> jdstrand: about JSON, as IÂ understand that was the agreement in the meetings we had (there's no official tooling to parse fragments of assertion format atm)
<tyhicks> niemeyer: Thanks. We can deliver the fix in a post-yakkety-release SRU. Until then, only root inside of a yakkety container will be able to run snap commands.
<mup> PR snapcraft#858 opened: python plugin: allow usage of bzr <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/858>
<tyhicks> ratliff, jgrimm: fyi, it looks like we'll deliver the last piece of the snaps in lxd containers story (the snapd bug fix for bug #1630789) as an SRU after yakkety is released ^
<mup> Bug #1630789: normal users can't run snaps inside of LXD containers <verification-needed> <Snappy Launcher:Fix Committed by jdstrand> <Snappy:In Progress by tyhicks>
<mup> <snap-confine (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Triaged> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1630789>
<jgrimm> tyhicks, ack. thanks for following up!
<tyhicks> np!
<niemeyer> tyhicks: Hmm
<niemeyer> tyhicks: Post yakkety release?
<tyhicks> niemeyer: maybe I misunderstood what you were saying by, "I think it's fine to see it in an SRU and in master"
<tyhicks> niemeyer: I thought you were saying that we should wait until after yakkety is released and then SRU that fix into yakkety-updates as part of the next snapd SRU
<niemeyer> tyhicks: I was suggesting we can SRU this in X, probably next week
<tyhicks> niemeyer: ah! yes, we're in the process of SRU'ing everything into X
<niemeyer> tyhicks: and naturally in yakkety.. but it's October already, so I might be missing what the timeframe is for Yakkety
<tyhicks> niemeyer: today is final freeze for yakkety
<tyhicks> niemeyer: I can make a small yakkety snapd upload containing only that change, if you'd like me to
<niemeyer> tyhicks: I think this is okay.. the only point of using squashfuse is for that one case anyway, so if it breaks it won't get any worse
<niemeyer> mvo: What do you think?
<tyhicks> oh, there he is
<tyhicks> :)
<tyhicks> mvo, niemeyer: here's the debdiff that I would upload: https://paste.ubuntu.com/23286012/
<tyhicks> I've tested it with inside of a lxd container as well as outside of a container
<niemeyer> tyhicks: +1
<tyhicks> thanks, I'll wait for mvo to have a look as well
<niemeyer> tyhicks: It would be really nice to see a spread test exercising this logic (cheaply, if possible)
<mvo> tyhicks: yeah, looks fine, thank you
<tyhicks> niemeyer: would I need to mock a container environment or would the spread test set up a lxd container?
<tyhicks> I'm going to go ahead and proceed with this upload and will try to get a spread test ready for trunk
<tyhicks> thanks mvo!
<mup> PR snapd#2096 closed: tests: check for failure creating user on managed ubuntu-core systems <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2096>
<lutostag> so I have snaps installed and now there is an extra dir in my home directory 'snap' is this expected?
<nacc> lutostag: yes
<lutostag> hmm... not my favorite, any way to make it live elsewhere?
<nacc> lutostag: i don't believe so, as there are some variables that rely on it (iirc)
<lutostag> nacc: ok, thanks for the info. Appreciate it
<mup> Bug #1631159 opened: No way to simply list available snaps via snapd <Canonical System Image:New> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1631159>
<mup> Bug #1631165 opened: no ability to move snap directory out of $HOME <Snappy:New> <https://launchpad.net/bugs/1631165>
<mup> PR snapcraft#845 closed: Add `snapcraft status` <Created by maxiberta> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/845>
<SuperJonotron> I have manged to get a snap all wrapped up and deployed but when it runs it needs to run with root privelidges, I can't run the snap with "sudo snapname", doesn't recognize the snap, if i run it just as a user, it's fine but doesn't have root privelidges and when it hits those parts in the application I get "sudo: no tty present and no askpass program specified"
<SuperJonotron> is there a way to handle this kind of thing in the yaml? or during install?
<nacc> SuperJonotron: why does it need to run as root?
<SuperJonotron> some bash scripts, at least one I know of personally, needs to be run as root
#snappy 2016-10-07
<nacc> SuperJonotron: i'm not sure how that's supposed to work; my initial response would be install it as the root user, rather than as your regular user
<nacc> SuperJonotron: but that seems less than ideal
<SuperJonotron> that is actually how i have to install it but for some reason when you run the snap as sudo after that it doesn't work unless it's the user who calls it
<nacc> SuperJonotron: you *may* need to pass -H to sudo? to use root's home
<nacc> tbh, this feels like an odd corner case to me -- this doesn't sound like a normal application, if it rqeuires root
<SuperJonotron> the software is bound to hardware, the hardware it needs access to requires root access
<nacc> SuperJonotron: i believe normally you'd write/request an itnerface to the hardware
<nacc> and then connect your snap to that interface
<SuperJonotron> pass -H where in the process?  in the method calling sudo or sudo -h <snapName>
<nacc> SuperJonotron: can you run the snap (as installed by the root user) as the root user? First run `sudo -s -H` to switch to the root user's home and then try to run the snap?
<SuperJonotron> i'm rebuilding it now because I was trying something else, i'll test in just a sec
<nacc> SuperJonotron: e.g., you can see for other hardware access stuff, there are interfaces at http://snapcraft.io/docs/reference/interfaces
<nacc> my thinking is based purely on my understanding of snapcraft/snaps, not on any actual experience connecting to hardware, to beclear :)
<SuperJonotron> even when installing the snap as root and going to it's home directory, it still say command not found
<nacc> SuperJonotron: what ubuntu are you on?
<SuperJonotron> 16.04
<nacc> SuperJonotron: echo $PATH as root?
<nacc> SuperJonotron: is /snap/bin there?
<SuperJonotron> it is not
<SuperJonotron> so that's probably that problem
<SuperJonotron> I do know the bash command that is requiring the root so if you know of any of those interfaces or an equivalent non-root of dmidecode i could make this snap happy
<nacc> SuperJonotron: so you could try running /snap/bin/<snap-name> as root
<SuperJonotron> yup, that works but doesn't recognize dmidecode
<nacc> SuperJonotron: right, did you put dmidecode into the snap?
<nacc> SuperJonotron: just as quick check, do youhave /etc/profile.d/apps-bin-path.sh ?
<nacc> SuperJonotron: that's what i believe suffixes /snap/bin into $PATH for all users
<SuperJonotron> i definitely didn't put dmidecode into the snap
<nacc> SuperJonotron: then your snap won't see it :)
<nacc> SuperJonotron: your snap only has what is in the snap
<SuperJonotron> not entirely sure wha that syntax would look like at the moment
<nacc> SuperJonotron: e.g., you'd put stage-packages: dmidecode
<nacc> http://snapcraft.io/docs/build-snaps/syntax
<nacc> SuperJonotron: for a dmidecode part
<nacc> SuperJonotron: you basically can't rely on anything in the host system being present in your snap (well, you can in some cases, but for clarity it's probably best not to)
<SuperJonotron> yes, i do have that file
<SuperJonotron> yeah, i've looked through the docs quite a bit
<SuperJonotron> i just meant i don't know how to get dmidecode defined in the yaml immediately
<SuperJonotron> I can start breaking things until i get it right
<nacc> SuperJonotron: ok, not sure why root wouldn't pick that up -- you did `sudo -s -H` to switch to root?
<SuperJonotron> yup
<nacc> strange
<nacc> let's leave it for now, separate issue :)
<nacc> SuperJonotron: right, so you'd need to ensure that your yaml specifies dmidecode (and i guess any other dependencies you might have) are in the snap
<SuperJonotron> switched to root, then did /snap/bin/<snapname> and can't pick up the dmidecode
<SuperJonotron> yeah, that's the last one, just added it
<SuperJonotron> everything else works fine
<nacc> SuperJonotron: cool, I expect that shoudl work once it's built
<SuperJonotron> i meant added it to the app, not the yaml
<nacc> SuperJonotron: sorry?
<nacc> SuperJonotron: can you pastebin your yaml?
<SuperJonotron> added the dependency within the app, still haven't figured out how to include it in the yaml so it would exist in the snap
<SuperJonotron> any thoughts on including that package into snappy?
<nacc> SuperJonotron: sorry, i asked you to pastebin your yaml?
<nacc> SuperJonotron: can't really help in the abstract :)
<SuperJonotron> missed that, one sec
<SuperJonotron> name: mysnap version: 1.0 summary: A snappy implementation description:   Runs my snap confinement: devmode  apps:   niagara:     command: bin/start.sh  parts:   niagara:     plugin: copy     files:       appdata: app/       start.sh: bin/
<nacc> SuperJonotron: no
<nacc> SuperJonotron: pastebin
<nacc> SuperJonotron: paste.ubuntu.com, please
<SuperJonotron> i've never used that before i pasted it in, now paste it back here?
<nacc> SuperJonotron: ah sorry, it should provide a URL
<nacc> SuperJonotron: paste that URL here
<nacc> you can also do `cat snapcraft.yaml | pastebinit` if you have pastebinit installed
<SuperJonotron> http://paste.ubuntu.com/23286932/
<nacc> SuperJonotron: just as an fyi, i think 'application' should be 'application:' (it might just work as-is, but is non-standard)
<nacc> SuperJonotron: ok, so add under files:
<SuperJonotron> i modified it slightly to remove specifics of the application, the original has it
<nacc> SuperJonotron: stage-packages: dmidecode
<nacc> at the same level of indentation as files:
<nacc> SuperJonotron: ah ok
<SuperJonotron> so like this? http://paste.ubuntu.com/23286946/
<nacc> SuperJonotron: it might be a list, so maybe [dmidecode], or
<nacc> stage-packages:
<nacc>   - dmidecode
<SuperJonotron> it was the second one
<SuperJonotron> rebuilding now to test
<nacc> SuperJonotron: so what that will do, is ensure that the ubuntu package 'dmidecode' is installed for that 'part'
<nacc> SuperJonotron: so it will now be part of your final snap
<SuperJonotron> ran as sudo /snap/bin/<snapname>
<SuperJonotron> dmidecode: command not found still
<nacc> SuperJonotron: did you install it again?
<SuperJonotron> yup
<SuperJonotron> just did it again to make sure
<SuperJonotron> same results
<nacc> SuperJonotron: can you pastebin `unsquashfs -l <app.snap>` ?
<nacc> SuperJonotron: how are you invoking dmidecode? (absolute path versus just cmd name?)
<SuperJonotron> just command name
<nacc> SuperJonotron: ok
<SuperJonotron> what was app.snap in reference to
<nacc> SuperJonotron: when you build a snap, a .snap file is created
<SuperJonotron> i get a Read on filesystem failed because is a directory when i just put the app name
<SuperJonotron> yup
<nacc> give unsquashfs -l the path to that .snap file
<SuperJonotron> it just goes to a blank terminal line '>'
<nacc> SuperJonotron: unsquashfs -l /path/to/app.snap ?
<SuperJonotron> yup
<nacc> SuperJonotron: can you c&p the exact command you are running
<SuperJonotron> just typed it again in case it was a type-o, worked that time
<nacc> SuperJonotron: ok
<nacc> SuperJonotron: and can you pastebin the current yaml file too
<SuperJonotron> yeah, i can see the dmidecode pieces in there which i'm sure is what you wanted to see
<nacc> SuperJonotron: well, i want to see the path, etc
<SuperJonotron> http://paste.ubuntu.com/23286972/
<nacc> SuperJonotron: can you update your script to call /usr/sbin/dmidecode? (Or ensure that /usr/sbin is in PATH)
<SuperJonotron> yeah, i'll have to rebuild the application before i can rebuild the snap so it'll take a few min
<nacc> SuperJonotron: ok
<SuperJonotron> no luck, sudo: /usr/sbin/dmidecode: command not found
<nacc> SuperJonotron: wait, you're runing under sudo still?
<nacc> SuperJonotron: please run *as* root, just to be sure
<nacc> SuperJonotron: i probably have to go soon, getting late here, just fyi
<SuperJonotron> i can't switch to root with su
<SuperJonotron> don't have root password
<nacc> SuperJonotron: sudo -s -H
<nacc> SuperJonotron: as i said earlier
<SuperJonotron> sorry, long day here as well, switching between too many things
<nacc> SuperJonotron: np :)
<SuperJonotron> switched to root with sudo -s -H
<nacc> SuperJonotron: ok and now run /snap/bin/<app>
<SuperJonotron> did, same error
<nacc> SuperJonotron: can you pastebin it?
<SuperJonotron> h/o, i still had sudo in the bash script calling that
<SuperJonotron> let's see if rebuilding without fixes
<SuperJonotron> if this does at least allow it to run, any thoughts on fixing this for non root user?
<nacc> SuperJonotron: not off the top of my head probably better to ask during the day US time
<SuperJonotron> can do
<SuperJonotron> no luck
<nacc> SuperJonotron: can you pastebin the exact output?
<SuperJonotron> the whole output won't mean anything to you since it's just the applictions startup output
<nacc> SuperJonotron: the error line
<SuperJonotron> it just prints this out: sh: 1: /usr/sbin/dmidecode: not found
<nacc> SuperJonotron: so there are ways to add a shell option to your snap
<nacc> https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1615163 e.g.
<mup> Bug #1615163: shell boilerplate could be automatically added when building in devmode <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1615163>
<nacc> SuperJonotron: and then you can run <app>.shell
<nacc> which will put in bash running in the env of your snap
<nacc> you could see from there if you can run the commands you expect
<SuperJonotron> i'll bookmark that to continue testing tomorrow
<SuperJonotron> thanks for the help
<nacc> SuperJonotron: i'll be around again then to help
<SuperJonotron> awesome, thanks again
<mup> PR snapd#2113 opened: Add i2c builtin interface <Created by bergotorino> <https://github.com/snapcore/snapd/pull/2113>
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> salut didrocks
<dholbach> svij, taskwarrior can be removed from https://github.com/ubuntu/snappy-playpen/wiki/SandPit - right?
<svij> dholbach: yes
<dholbach> great, doing that now
<mup> PR snapd#2114 opened: tests: add readme about spread's external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2114>
<trijntje> Hi all, I want to snap https://github.com/broadinstitute/wdltool
<trijntje> should I build it myself, or is there a way to tell snapcraft to pull the release .jar from github directly? https://github.com/broadinstitute/wdltool/releases
<trijntje> I don't have any experience with building .jar files myself
<mup> PR snapcraft#859 opened: Set GOBIN in go plugin build environment <Created by tasdomas> <https://github.com/snapcore/snapcraft/pull/859>
<john> ogra_: o/
<john> um
<ogra_> heh
<Chipaca> ogra_: you know a lot more sh than I. Is there a way to make /bin/sh behave wrt signals?
<ogra_> one sec
<Chipaca> ogra_: case in point: a script runs a; b, you sigint, a exits on the signal, sh still runs b
<Chipaca> bash behaves properly and will exit if a doesn't catch (or catches and reraises) the signal
<ogra_> Chipaca, http://paste.ubuntu.com/23288279/
<ogra_> use trap ...
<Chipaca> that seems to be the opposite of what I want
<Chipaca> :-)
<stub> Anyone know if there is a way to set environment variables when invoking qmake? qmake FOO=bar doesn't seem to work, and I don't know the tool.
<ogra_> trap b INT
<Chipaca> ogra_: maybe I'm stating my problem wrong. Give me a while and I'll show you a testcase.
<ogra_> (a should just exit anyway, then the trap runs b on INT)
<stub> Or maybe this qmake project is just broken :-(
<ogra_> stub, try prefixing qmake with the var instead ?
<stub> yer, but I can't do that with the qmake plugin so am working around it with a custom plugin
 * ogra_ would just use the make plugin and call qmake from the build target with all env needed
<stub> I'm trying to ween myself off from that approach :D
<ogra_> heh
<stub> Although I am slightly tempted with a bash plugin, that lets you embed a shell script in the yaml.
<cjwatson> Chipaca: WFM
<cjwatson> $ sh -c 'sleep 5; echo a'
<cjwatson> ^C
<cjwatson> $
<Chipaca> yeah. test case coming soon.
<ogra_> stub, i think there are a few PRs on github with that approach
<cjwatson> Chipaca: my theory is you have process A in a different process group for some reason (or is it session?  I can never remember)
<stub> I could write a part that generates a snapcraft.yaml and calls snapcraft on it
<cjwatson> whatever terminal signals are delivered to the whole of
 * cjwatson waves hand vaguely at the copy of Stevens somewhere behind him
<Chipaca> cjwatson: ogra_: so, given the following go program (could be in C, but I had the go one closer to hand): http://pastebin.ubuntu.com/23288428/
<Chipaca> cjwatson: ogra_: and http://pastebin.ubuntu.com/23288429/
<Chipaca> cjwatson: ogra_ there are four modes, with different behaviour
<Chipaca> bash does the right thing as I understand it
<Chipaca> sh does not
<Chipaca> save 'em as /tmp/q.go and /tmp/q.sh & give it a try
<Chipaca> the idea is, run q.sh, hit ^C when it prints the first text, observe
<cjwatson> which particular arg demonstrates the difference?
<Chipaca> cjwatson: with both catch and ignore, where the script should continue, it exits instead
<ogra_> why would the script continue at all your ^C goes to the shell
<cjwatson> I think this is often what people want for scripts, in order that they can ctrl-c something they're running interactively and not have to repeatedly hammer ctrl-c to get the whole script to exit
<cjwatson> bash happens to ignore SIGINT itself for reasons I haven't unpicked
<ogra_> oh
<ogra_> i wasnt aware of that !
<Chipaca> this is about WIFSIGNALED and WTERMSIG
<cjwatson> but you can either do 'set -m' in sh to turn on job control, which has the effect of making it have the behaviour you're asking for
<Chipaca> which it seems sh isn't looking at
 * ogra_ actually hasnt used #!/bin/bash in years 
<cjwatson> or probably do something with trap
<cjwatson> to get sh to ignore SIGINT
<Chipaca> ogra_: wrt why: imagine the process you launched changed the behaviour of ^C (e.g. because you launched emacs)
<ogra_> whats emacs ?
<ogra_> :P
<cjwatson> no, it has nothing to do with WIFSIGNALED/WTERMSIG; the terminal-generated signal is being delivered to *both* processes (the shell and the Go program) and it's a question of what the shell does with the SIGINT signal that it receives itself
<Chipaca> ogra_: an embedded operating system for 128-bit arm boards
<ogra_> and i thought a backend for organist :)
<ogra_> *organists
<Chipaca> cjwatson: but bash isn't ignoring the ^C, it's correctly stopping the script if the process dies from the signal
<Chipaca> cjwatson: i.e. in the other two cases
<Chipaca> in any case, as you say "set -m" makes sh do the (imho) right thing wrt this
<Chipaca> cjwatson: thanks!
<cjwatson> Chipaca: I misspoke when I said "ignore"; bash installs a custom handler for SIGINT, I haven't quite unpicked exactly what it does
<cjwatson> it's nevertheless true that the signal is delivered to the whole foreground process group
<cjwatson> I'd suggest playing with things under "strace -I4 -f" to see more detail of what's going on
<Chipaca> cjwatson: doesn't sh also have a handler, to wait until after the running command finishes to exit?
<Chipaca> cjwatson: ok :-)
<cjwatson> yeah, I guess it has slightly different semantics.  I suspect this is not well-specified: the closest I can find so far is http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_11
<cjwatson> the relevant effect of set -m here is that the subprocess gets run in its own process group
<cjwatson> job control is really mainly for interactive shells though; I don't recall whether there's weird behaviour from trying to use it in scripts
<cjwatson> you'll probably get some spurious output at least
<ogra_> hmm, i there anything special i need to do to make ubuntu-image use core instead of ubuntu-core ?
<Chipaca> ok. Once I pop this out of academic-ish and back in to "why does systemd-activate not exit when I ^C if I'm running it via ssh" we'll see
<Chipaca> it's been fun digging into this anyway
<ogra_> i installed snapd and snap-confine from proposed and use the ubuntu-image trunk tree to build
<Chipaca> cjwatson: i got here via https://www.cons.org/cracauer/sigint.html fwiw
<Chipaca> ogra_: ubuntu-image ships its own snap
<Chipaca> ogra_: snap-the-binary
<Chipaca> ogra_: I suspect you're using an old ubuntu-image
<ogra_> hrm, so how do i build rom trunk now
<ogra_> *from
<trijntje> Hi all, I'm trying to make a snap by downloading a .jar directly, what plugin should I use? I tried 'copy' but i get a "no handler to manage source" error
<ogra_> Chipaca, i dont, i directly run out of trunk to get the very latest
<Chipaca> ogra_: how does trunk compare to the edge snap?
<ogra_> not sure
<Chipaca> ogra_: me neither
<ogra_> mvo didnt leave any docs, i thought using the proposed packages and latet trunk would suffice
<Chipaca> and I'm not about to ask mvo after the week he's just had
<ogra_> *latest
<ogra_> yeah
<ogra_> same
<cjwatson> Chipaca: looks like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671 too
<Chipaca> ogra_: when you say trunk, where're you getting it from?
<ogra_> github upstream trunk
<Chipaca> cjwatson: heh
<ogra_> the same thing that barry uploaded to the archive yesterday
<Chipaca> ogra_: and what snap is that using?
<cjwatson> Chipaca: of course there's also the underlying bug that your test shell script isn't using set -e ;-)
<ogra_> Chipaca, whatever is on the host indeed
<Chipaca> cjwatson: sssh :-D
<Chipaca> ogra_: so your snap is probably pre-core
<ogra_> well, i hopees that one was in proposed
<ogra_> *hopd
<Chipaca> ogra_: pre-core is like deathcore but with simpler chords?
<ogra_> sigh
<ogra_> this kbd didnt survive 1,5 years !
<ogra_> half the keys dont work
<Chipaca> ogra_: no, we've not started the SRU dance of the FF'ed snap yet
<cjwatson> Chipaca: sigint.html is interesting, thanks
<ogra_> Chipaca, well, given that yakkety is alreeady frozen i'd have expected that all needed bit are in there by now
<ogra_> and likewisse in proposed in xenial
<Chipaca> ogra_: i don't know
<Chipaca> (literally)
<ogra_> (else you wont be able to build images in yakkety)
<Chipaca> ogra_: that is: I don't know if the last SRU was cut with the core change or not
<ogra_> yeah
<Chipaca> ogra_: it's been crazy :-)
<Chipaca> yakkety is overrated :-p
<ogra_> well, devs use it i guess
<ogra_> (i dont though ... admittedly :P )
<ogra_> the prob is that mvo actually patches the ubuntu-image snap ... but not with all patches i fear
<Chipaca> this is the first cycle since 2008 that i haven't switched at or before the alphas, i think
<Chipaca> (because our focus was on 16.04)
<ogra_> iirc his version still builds 4GB images or everything
<ogra_> *for
<Chipaca> ogra_: if it's any help, afaik barry also can upload the snap
<ogra_> well, he wont know either which patches are used and which arent
<ogra_> the wondeful world of binary only packages :P
 * ogra_ tries to find a new kbd in the house ... half the char of my password dont work ... igh
<trijntje> How can I create a snap using an existing jar file? I keep getting "no handler to manage source"
<Chipaca> trijntje: have you read up on the java parts?
<Chipaca> trijntje: http://snapcraft.io/docs/build-snaps/parts#snapcraft-for-java-maven-or-ant seems to have some info
<Chipaca> if that's not enough, hang around for a while and somebody who knows snapcraft and/or java might be able to help
<trijntje> Chipaca: I don't want to build the .jar myself, I just want to download the .jar and put it in the snap. The project I want to use requires sbt
<Chipaca> trijntje: I think there's a "copy" plugin, maybe that works?
<trijntje> Chipaca: when I tried that it said it had been replaced by 'dump', but I can't get dump to do anything at all
<trijntje> Preparing to pull wdltool
<trijntje> Pulling wdltool
<trijntje> no handler to manage source
<trijntje> and the examples are not help either https://github.com/ubuntu/snappy-playpen/search?utf8=%E2%9C%93&q=dump
<Chipaca> trijntje: and "snapcraft help dump" doesn't help?
<trijntje> nope. I can't even find where the it supposedly pulled the .jar to
<Chipaca> trijntje: the good news is, we're needing people new to snapcraft to find these issues
<Chipaca> trijntje: the bad news is it's a little bit early for the people who could help you
<trijntje> its just frustrating that there are no simple examples that make clear how that plugin works
<trijntje> like this: https://github.com/ubuntu/snappy-playpen/blob/af7154cc9cac61d55b17c4aa9517c4d7c003a1a0/jtiledownloader/snapcraft.yaml From this, I guess dump automatically unzips stuf as well?
<Chipaca> trijntje: i wouldn't know :-)
<trijntje> Chipaca: yeah, me neither ;) Do you happen to know the best time to get help here?
<Chipaca> trijntje: usually I'd say starting about now (or in half an hour tops), but it's been a crazy week so people might be taking it slower today
<ogra_> hrm, so i have an image building now ... but that seems to hav cloud-init enabled and not configured
<ogra_> (which means the boot takes about 5min with spilling cloud-init errors to the console)
<ogra_> sigh
<Chipaca> augh
<trijntje> Chipaca: thats good to know, thanks. I'll hang around for a bit ;)
<ogra_> i really dontz know what mvo did here :/
<ogra_>  * live-build/ubuntu-core/hooks/22-disable-cloud-init.chroot:
<ogra_>     - removed, the gadget.yaml now contains an "cloud.conf" file
<ogra_>       that will create a /etc/cloud/cloud.cfg or a "cloud-init.disabled"
<ogra_>       file (if coud.conf is missing)
<ogra_> oh man
<ogra_> would be helpful if he actually had published that gadget.yaml anywhere to the world
<ogra_> (and also ... this broke all dailies ... )
<ogra_> Chipaca, do you by chance happen to know if he publisshed that gadget somewhere ... seems to have been sideloaded into the image he published
<ogra_> (there is nothing in the store nor in the gadget upstream tree)
<Chipaca> ogra_: the pc gadget in the store should be like that
<ogra_> it definitely isnt
 * Chipaca looks
<ogra_> ha not been changed since 4 weeks
<ogra_> *ha
<ogra_> *h a s
 * ogra_ curses this kdb ... thats the last expensive one i ever bought !
<Chipaca> ogra_: sorry, i don't follow
<ogra_> Chipaca, the gadget in the store has not been changed in 4 weeks
<Chipaca> ogra_: the test suite creates an image using the gadget from the store
<ogra_> (ignore my rasmbling about my broken kbd)
<Chipaca> ogra_: the resulting image disables cloud-init because it doesn't have a cloud.cfg
<ogra_> Chipaca, well, that might be ... but the pc gadget in the tore doent have any magic for cloud init
<Chipaca> ogra_: correct, the lack of magic means no cloud-init
<ogra_> no
<Chipaca> that's what you just pasted from that changelog
<ogra_> th magic *disables* cloud-init
<Chipaca> the thing you just pasted says "if no cloud.cfg, disable cloud-init"
<ogra_> the gadget in the store doent have *any* cluld handling
<ogra_> ince it is to old
<Chipaca> which means cloud-init gets disabled as wanted
<Chipaca> :-)
<ogra_> well, it doent
<Chipaca> hah
<ogra_> doe that come from an ubuntu-mage ack ?
<ogra_> ARGH
<Chipaca> ogra_: is this still with ubuntu-image master?
<ogra_> does that come from an ubuntu-image hack that waa not publihed ?
<ogra_> yeh
<ogra_> i built a local nap from mater now
<ogra_> oh man
<oparoz> Hello, is `$ snap-compose` on the roadmap?
 * ogra_ wonders where these chars go when they are missing :P
<oparoz> or should we install other snaps from the snap we install?
<oparoz> (if that's even possible)
<ogra_> technically it is, via the snapd-control interface i think
<ogra_> but thats no auto-connect one
<Chipaca> what is snap-compose?
<oparoz> docker-compose
<oparoz> as an analogy
<Chipaca> what is docker-compose?
<oparoz> For a pre-configured setup based on snaps
<Chipaca> oparoz: is the setup at the gadget level, ie you want a system with a bunch of snaps, or at the snap leve, ie you want a snap with a bunch of building blocks?
<oparoz> I'd like to make some snaps more flexible, so instead of shipping the database, per example, I'd like to be able to create a config file which comes with one option, but if you want another one, you modify the config file to load the other one and then re-launch the "bundle"
<oparoz> Chipaca, because tight coupling doesn't always make sense for server apps
<Chipaca> ogra_: ubuntu-image fails with an error from mkfs.ext4 for me
<Chipaca> ogra_: the one from master, that is
<ogra_> Chipaca, you need the foundations ppa
<Chipaca> oparoz: i'm probably too obtuse right now. Are you assuming you can make snaps explicitly depend on each other? Or do you want to have, say, a blog engine that talks to either postgres or mysql?
<ogra_> sudo add-apt-repository ppa:canonical-foundations/ubuntu-image
<oparoz> Chipaca, the latter
<ogra_> and add "- lib" and e2fslibs to snapcraft.yaml
<Chipaca> oparoz: and what's stopping you from doing that today?
<ogra_> i'm sure mvo has a good bunch of local patches for his snap
<ogra_> sadly not in his github branch
<oparoz> Chipaca, nothing is stopping me, but then I have to install every single snap and connect them
<Chipaca> oparoz: (i'm still trying to understand the problem you're having, hence all these questions, sorry)
<Chipaca> oparoz: so you want something to orchestrate your snaps?
<oparoz> Chipaca, exactly
<Chipaca> ah!
<oparoz> :)
<oparoz> Sorry
<Chipaca> oparoz: some people were looking into that, but there's nothing promised yet afaik
<oparoz> Chipaca, OK, that's what I wanted to know. Thank you
<ogra_> ogra@localhost:~$ ls /snap/pc/current/meta/
<ogra_> gadget.yaml  icon.png  snap.yaml
<ogra_> so there is no cloud.conf in the released image in the gadget
<ogra_> it is definitely the 4 weeks old one from the store ... so there must be some ubuntu-image bit missing
<Chipaca> ogra_: I'm sorry, i'm still missing something
<ogra_> error ?
<Chipaca> ogra_: your problem is that the generated image runs cloud-init?
<ogra_> Chipaca, yes ... and there must be code somewhere that disables it for mvo's
<ogra_> ogra@localhost:~$ ls /etc/cloud/
<ogra_> cloud-init.disabled
<ogra_> i.e. something that puts this file in place
<ogra_> it is definitely not the gadget though
<ogra_> (like the commit above suggested)
<ogra_> so there must be some ubuntu-image patch he didnt commit anywhere
<Chipaca> ogra_: or maybe, maybe, the patch is in cloud-init
<ogra_> unlikely ... then that would be in the archive or in the PPA
<Chipaca> wait
<Chipaca> it's in snap
<Chipaca> ogra_: it's in snap
<ogra_> i think i found it Â°
<ogra_> https://github.com/CanonicalLtd/ubuntu-image/pull/69
<mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
<ogra_> oh man ...
<ogra_> simply not merged
<Chipaca> ogra_: ogra_ https://github.com/snapcore/snapd/blob/master/image/image.go#L222
<Chipaca> ogra_: build snap from snapd master
<Chipaca> ogra_: put it somewhere in your path
<ogra_> snapcraft does that
<ogra_> when rolling the snap
<Chipaca> ah, ok
<ogra_> the missing merge is the issue, i'm sure
<Chipaca> ok fair enough
<Chipaca> i'm going to go now have lunch
<Chipaca> o/
<ogra_> enjoy
<jgdx> my snap is published to the edge channel, but it can't be found using snap install --channel=edge. Can be found using the beta channel, though.
<jgdx> disregard, may have been pebkag
<ogra_> Chipaca, hmm, still not enough ... for some reason the ect dir isnt even created
<Chipaca> ogra_: sorry, i can't quite hear what you're saying over the delicious lunch
<ogra_> i didnt mean to distract you from it (i was assuming you are afk :P )
<Chipaca> I am!
<Chipaca> i'm probably doing it wrong tho
<ogra_> with very long arms ?
<Chipaca> well, it's said my ancestors were good swimmers
<Chipaca> so maybe? i'm not sure how it works
<ogra_> heh
<ogra_> well, i see all the snapd cloud code in my ubuntu-image tree and i have hacked the etc copying in ... but i dont end up with an etc dir at all in the image build when i keep the fragments around
<ogra_> oh, wait ... i *do* see it
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls workdir/unpack/image/etc/cloud/
<ogra_> cloud-init.disabled
<ogra_> ogra@anubis:~/datengrab/images/snappy$
<ogra_> yet, the image i built still fires up cloud-init
 * ogra_ goes for a break
<rvr> https://bugs.launchpad.net/snappy/+bug/1631357
<mup> Bug #1631357: Can run multiple configure processes in different terminals <Snappy:New> <https://launchpad.net/bugs/1631357>
<rvr> Hi guys. I am trying to configure wifi, but nothing happens when I press Enter in "Use DHCPv4 on this interface". Any tip?
<mup> Bug #1631357 opened: Can run multiple configure processes in different terminals <Snappy:New> <https://launchpad.net/bugs/1631357>
<mup> PR snapd#2115 opened: tests: only stop a service if it is running or ok (eg. active (exited)) <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2115>
<kgunn> ogra_: yo, do you know if the new dragonboard image will be ready today?
<kgunn> re "Ubuntu Core 16 Feature Freeze" mail
<davmor2> rvr: ^
<ogra_> kgunn, if i ever find out which patches mvo used locally to create the images ...
<ogra_> sadly i cant build them atm
<kgunn> doh
<ogra_> and mvo is off today
<rvr> davmor2: ?
<kgunn> nw, will camp out on the beta image a bit more
<davmor2> rvr: there is a new image to come so that might help but pick on ogra_ now he is back, it'll all be his fault anyway ;)
<ogra_> there is nothing to pick on me
<rvr> davmor2: Ah, thanks
<ogra_> i cant do much until i know what mvo did to make sure cloud-init stays turned off
 * davmor2 hands rvr a pick and points ogra_ 
<rvr> ogra_: Do you publish them directly on http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ ?
<ogra_> no
<ogra_> i will only do dailies
<ogra_> (which are broken as well now)
<rvr> ogra_: What exactly is broken?
<rvr> I installed the current one
<ogra_> ubuntu-image from master or the snap doesnt create them correctly
<ogra_> there are bits missing
<ogra_> mvo seems to have used some local patches that i cant find anywhere in the trees
<ogra_> so they try to fire up cloud-init on boot and fail
<rvr> I see
<ogra_> (theoretically snap prepare-image (internal command that ubuntu-image uses) should disable cloud-init by default, but the files are not copied into the image that care forthis
<ogra_> )
<ralsina> sergiusens: I just changed the error message a couple of minutes ago, but your review comments sometimes have no 'reply' button :-P
<sergiusens> ralsina oh, that's fine, just looking at the latest diff and in theory my comment should go away if there was a change :-)
<ralsina> sergiusens: well,they didn't for some reason. GH reviews are just weird.
<ralsina> sergiusens: 1st GH feature I like better on launchpad, to be honest.
<sergiusens> ralsina all review systems have their quircks indeed
<sergiusens> ralsina I bet it is just a bug in their "one submit with all comments" new feature
<oSoMoN> didrocks, for your reviewing pleasure: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12
<mup> PR ubuntu/snapcraft-desktop-helpers#12: Install all available locales and ensure that apps can locate them <Created by oSoMoN> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/12>
<pedronis> ogra_: as far IÂ understood mvo had to teach ubuntu-image to copy /etc bits and not just /var from what prepare-image produces, but not sure where that patch lives
<ogra_> pedronis, yeah, thats the patch i added ... didnt help
<pedronis> ok
<pedronis> then not sure at all
<ogra_> i see /ect in the workdir if i build with "-w workdir"
<pedronis> didn't hear of anything else
<ogra_> but it doesnt get copied even with the patch
<ogra_> https://github.com/CanonicalLtd/ubuntu-image/pull/69 is the one
<mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
<didrocks> oSoMoN: already in! :-)
<didrocks> thanks ;)
<ogra_> i use this ammd the snap i rolled definitely also has the latest snapd from master (so it does the cloud handling)
<oSoMoN> didrocks, wow, that was fast, thanks!
<didrocks> oSoMoN: service! :-)
<ppisati> ogra_: you don't do any modification to initrd.img these days, don't you? i just tried to build an rpi3 image using a custom kernel snap, but it fails in some obscure way in initrd.img
<ogra_> <ogra_> ogra@anubis:~/datengrab/images/snappy$ ls workdir/unpack/image/etc/cloud/
<ogra_> <ogra_> cloud-init.disabled
<ogra_> <ogra_> ogra@anubis:~/datengrab/images/snappy$
<ppisati> ogra_: i alread tried the beta and edge channel FWIW
<ogra_> and it even creates everything ...
<ppisati> ogra_: http://pastebin.ubuntu.com/23289082/
<ogra_> ppisati, /bin/date: invalid date 'n/a'
<ogra_> thats the issue ...
<ogra_> there was a ga where the wrong initramfs-tools was added to ubuntu-core for a few hours ... but during that time no ubuntu-core should have been built
<ogra_> weird that you get the broken initrd
<zyga> morphis__: I could use some testing and review on https://github.com/snapcore/snap-confine/pull/168
<mup> PR snap-confine#168: Rework mount namespace support <Created by zyga> <https://github.com/snapcore/snap-confine/pull/168>
<zyga> jdstrand: ^^
 * zyga lseep
<zyga> sleep
<morphis__> ssweeny: ^^ can you look into that?
<morphis__> zyga: I am out full next week but ssweeny will have a look
<pedronis> ogra_: did you see this:  https://github.com/CanonicalLtd/ubuntu-image/pull/69  that's all I see there
<mup> PR CanonicalLtd/ubuntu-image#69: include etc/ as well <Created by mvo5> <https://github.com/CanonicalLtd/ubuntu-image/pull/69>
<ssweeny> morphis: sure
<zyga> morphis__: I'm out next week but I'll get it done tomorrow
<zyga> morphis__: gustavo helped me find an easy way to test this
<ogra_> pedronis, yes,, see above ... my ubuntu-image snap has that
<zyga> morphis__: so just first thing tomorrow, now time to sleep
<pedronis> ogra_: ok, definitely need mvo at this point
<morphis__> zyga: great!
 * zyga -> sleep
<ogra_> it obviously creates the /etc/cloud dir
<ogra_> just doesnt copy the content
<ogra_> aha, i thik i found the issue ... the patch is wrong
<ogra_> shutil.move(os.path.join(src, 'etc'), os.path.join(dst, 'etc')) should be shutil.move(os.path.join(src, 'etc'), os.path.join(dst, 'etc'), copy_function=copytree)
<ogra_> (i think)
<SuperJonotron> when I try to copy data out of the SNAP(read only area) into the SNAP_DATA area from within the snaps start process, I am receiving a permission denied response
<SuperJonotron> does a snap not have permissions to it's own file space?
<nacc> SuperJonotron: heya, were you able to get further today?
<ogra_> SuperJonotron, SNAP_DATA is definitely writable, but usually lives in a space where only root can write
<nacc> SuperJonotron: right so there's SNAP_DATA and SNAP_USER_DATA
<ogra_> what are you trying?
<SuperJonotron> ncc, for the time being, I removed the admin requirement for now
<nacc> SuperJonotron: ah ok :)
<SuperJonotron> will likely double back when time isn't as tight for this project
<nacc> SuperJonotron: makes sense :)
 * ogra_ sighs ... copytree didnt help 
<SuperJonotron> so my application needs to load a license file, the application needs to have it in a specific folder that is unchangeable (confirmed with manufacturer)
<SuperJonotron> this means I have to essentially  move the entire app from the read only space to the SNAP_DATA space and run from there
<SuperJonotron> so i need to move it during start
<mup> Bug #1631407 opened: ugly error when failed to sign because of wrong password <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1631407>
<SuperJonotron> was trying cp -R -n so it essentially only happens the first time a new version gets installed
<ogra_> well, that will only work if you start it as root
<SuperJonotron> and will likely eventually  move the license to the common space
<ogra_> a normal user cant write to SNAP_DATA
<SuperJonotron> can you install data there via the yaml file initially to prevent needing to run as root?
<ogra_> nope
<abeato> jdstrand, hi, I have removed the seccomp calls you mention in the review, and now ofono gets killed when doing getsockopt(). Maybe the default template you mention only applies on tip of master branch?
<ogra_> what you could do is create a daemon (service) ... that runs some script
<SuperJonotron> ogra, so if only a root can access SNAP_DATA, how does a snap application run not as root have any write access?
<ogra_> and does the copying only if the license doesnt exist in the target
<ogra_> and for a license you probably also want SNAP_COMMON
<ogra_> SuperJonotron, user apps write to SNAP_USER_DATA
<ogra_> thats not different to any normal linux ...
<ogra_> as a user you wont be able to write to a sibdir in /var usually
<SuperJonotron> I can move it to common only after I move the whole application because I can't create a link in the read only area but I do plan on figuring that out once I get the app in a writable area to do that
<ppisati> ogra_: ok, by reusing the initrd.img from the pi2-kernel.snap, now i can make an image that boots fine
<ogra_> well, write a small script that you declare as daemon in snapcraft,.yaml
<ppisati> ogra_: actually i ripped that snap apart and replaced the different pieces
<SuperJonotron> ogra, so if i get the snap to run as a daemon, it will have access to SNAP_DATA then?
<ogra_> have that script check if you need to copy something ... if so, copy it ...
<ogra_> right
<ogra_> ppisati, i fear mvo released an ubuntu-core that has the broken script
<SuperJonotron> ogra, thanks, i'll see what I can do to make my app a daemon
<ogra_> SuperJonotron, no, dont ... just write a small shell script, dont make the whole app a daemon
<ogra_> only for the copying
<abeato> jdstrand, nm, my fault
<SuperJonotron> that's what I am doing now on the start command of the app, but your saying, break that out into a separate app within the yaml that is the setup portion versus the start of the app?
<SuperJonotron> and that setup is a daemon?
<ogra_> right
<nacc> SuperJonotron: yeah, i think so, and that part will run as daemon (root)
<nacc> and by part, snapcraft terminology would be 'app'
<SuperJonotron> ogra, i think i got it, i'll start on that and see if I can get it to work
<ogra_> have a small script ... say "initialize.sh" ... make it a daemon and just check if SNAP_DATA is populated ... if it is, exit 0 ... if it isnt, copy $SNAP to $SNAP_DATA
<ogra_> or to SNAP_COMMON
<SuperJonotron> ogra, that sounds like what I was going to do so I think i'm on the same page
<ogra_> good :)
<ogra_> oh !
<ogra_> so for some reason the patched file doesnt end up in my ubuntu-image snap
<ogra_> argh !
 * ogra_ curses setup.py
<jdstrand> zyga: ack-- that'll have to wait til next week (working on snap declarations in review tools)
<ogra_> ogra@anubis:~/datengrab/images/snappy$ ls workdir/root/system-data/etc/cloud/
<ogra_> cloud-init.disabled
<ogra_> \o/
<ogra_> silly snapcraft !!!!
<ogra_> pedronis, thanks for trying to help ... in the end the issue was in snapcraft,yaml of ubuntu-image ("source-type: git", even when you have set "source: ." still pulls from the remote branch and overwrites all local changes ... )
<mup> PR snapcraft#857 closed: Document the grade option <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/857>
 * ogra_ dances and finally creates a set of working dailies again
<ogra_> kgunn, in about 30min there should be a new daily that you can use
<SuperJonotron> http://paste.ubuntu.com/23289279/
<SuperJonotron> ogra, added a second app as a daemon and I can run the original app by name but can't get the daemon to run, here is the part of the yaml it's defined in
<ogra_> should be identical to the beta (just a little newer)
<SuperJonotron> am i missing some simple command to make it run?
<ogra_> SuperJonotron, what do you mean ? the daemon runs on snap install or on boot usually ... from a systemd unit snapcraft creates
<ogra_> there should be nothing you need to do
<SuperJonotron> ah yes, it does do that, i knew i was forgetting something as I'd gotten a snappy daemon to work a while ago
<SuperJonotron> ogra, still ended up having to run the app as root since it needed write access to generate and save the license file
<kgunn> very cool
<ogra_> SuperJonotron, oh, i thought you have the license and want to copy it
<ogra_> you should then rather use SNAP_USER_DATA or SNAP_USER_COMMON
<ogra_> cant you teach the app itself to read/write the license in one of these ?
<ogra_> via config or so
<SuperJonotron> I think I will end up doing one of those, thanks
<ogra_> withouth even having to copy the world around
<SuperJonotron> I discussed with the manufacturer of the application i'm "snappifying" and they don't expose that capability yet
<SuperJonotron> discussed as a future release option
<ogra_> ah, k
<SuperJonotron> is SNAP_COMMON also root access only?
<ogra_> yep
<SuperJonotron> damn, trying not to make the snap too user specific
<ogra_> same thing as SNAP_DATA ... just one levelÃ¶ up in the fs
<ogra_> but there is SNAP_USER_COMMON
<SuperJonotron> i'll have to use one of them, just not sure which yet
<nacc> SuperJonotron: http://snapcraft.io/docs/reference/env
<nacc> SuperJonotron: if you haven't seen it already
<SuperJonotron> nacc, i have a similar doc up actually with a few more variables defined, just trying to figure out what's root and what's not and what I can get away with
<nacc> ogra_: i wonder if that page should be updated to say not just "writable" but writable as whom?
<ogra_> well, the window at the bottom shows the hypothetical target dirs
<nacc> ogra_: ah that's true, and i guess you would know /var is not user-writable
<ogra_> from that it should be rather clear where a user can write and where she cant
<nacc> ogra_: it "should" be versus is .... i think clarity is better :)
<ogra_> indeed
<nacc> implicit vs. explicit, etc
<SuperJonotron> from the developer page though, it is not https://developer.ubuntu.com/en/snappy/guides/security/
<stub> This application failed to start because it could not find or load the Qt platform plugin "xcb".
<stub> This is why I do backend.
 * stub looks for examples to cargo cult
<ogra_> kgunn, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has a freshly baked set of images (now using the "core" snap, not "ubuntu-core" anymore ... and all the other goodness the beta has)
 * ogra_ prefers to not do backend ... 
<ogra_> i rather do weekend ;D
<SuperJonotron> ogra, just changed my daemon to copy from $SNAP to $SNAP_USER_COMMON but when I go to /home/user/snap/app, it's just the versions, no common folder exists.  Should the copy be moved back out of a daemon now that it's user specific?
 * ogra_ wonders why rvr attaches a wifi dongle to a dragonboard in bug 1631357
<mup> Bug #1631357: Can run multiple configure processes in different terminals <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1631357>
<ogra_> :P
<ogra_> SuperJonotron, i think you need to mkdir ... iirc there was a bug
<rvr> ogra_: I was following some instructions
<ogra_> heh
<rvr> ogra_: But I reproduced that without the dongle
<ogra_> well, the dragonboard has onboard wifi ... no need for a dongle
<SuperJonotron> ogra, will do
<ogra_> rvr, yeah, it is a subiquity (console-conf) bug ... it should put a flag file somewhere when an instance has been started or so ...
<ogra_> rvr, some work for cyphermox or mwhudson
<rvr> ogra_: Ack
<dobey> any go hackers know how to force GODEBUG=cgocheck=0 from inside main() or in the source file, rather than having to set it in the env?
<oparoz_> snapd has been broken for over a week now on ARM, should I open a bug to escalate this?
<ogra_> oparoz_, ?
<ogra_> works fine here
<ogra_> ogra@pi3:~$ snap version
<ogra_> snap    2.16+ppa36-1
<ogra_> snapd   2.16+ppa36-1
<ogra_> series  16
<ogra_> ogra@pi3:~$ snap list ubuntu-core
<ogra_> Name         Version  Rev  Developer  Notes
<ogra_> ubuntu-core  16.04.1  838  canonical  -
<ogra_> oparoz_, you should always file bugs if unsure though ... it isn hard to invalidate them ;)
<mup> PR snapcraft#847 closed: Implementing channel-closing <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/847>
<mup> PR snapcraft#848 closed: `sign-build` to prompt users for key selection <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/848>
<pmcgowan> ogra_, hey, where can I find the 2.17 release? the usual places not working for me
<pmcgowan> the only place I see new images is you page
<oparoz_> ogra_, it's the bug we talked about, here, last week. snapd-confine is broken and the fixes need to be backported
<oparoz_> ogra_, when people install a snap it doesn't start
<oparoz_> one which fails per example is snapweb if you installed it this week
<oparoz_> And ogra, you must be on edge or something to have such high release numbers :P
<mup> PR snapcraft#858 closed: python plugin: allow usage of bzr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/858>
<mup> PR snapcraft#860 opened: In the downloader demo test, use https <Created by elopio> <https://github.com/snapcore/snapcraft/pull/860>
<pedronis> ogra_: not the place you would expect problems to come from, I see
<ogra_> oparoz_, yes, indeed i am ... but today edge is nearly equal to beta ... it will take a while til they diverge again
<sborovkov> oparoz_: is not that bug classic only. everything is working on core? but idk for sure
<oparoz_> sborovkov, could be that core is not affected
<ogra_> pmcgowan, 2.17 ? what do you mean by that ?
<sborovkov> oparoz_: at least if i am thinking about the same issue... go arm architecture stuff...
<oparoz_> sborovkov, exactly that one
<sborovkov> thankfully I had some image from few weeks ago.
<sborovkov> afraid to ever upgrade again now...
<oparoz_> ver 42 fixes the bug which is in version 38 I think
<oparoz_> sborovkov, the other workaround is to install snap-confine from yakketi
<sborovkov> oh alright. I tried xenial-proposed but that did not work
<oparoz_> The problem is that people using snapweb to install snaps won't understand why nothing works...
<ogra_> pmcgowan, i dont think there is any snapd 2.17 yet ... (in case you refer to snapd)
<pmcgowan> ogra_, ok maybe I am confused, jamie's last update refered to the release of 2.17 and images being on the server later that day
<cmars> is it possible to install snapcraft on 14.04, just to build snaps?
<mup> PR snapcraft#861 opened: python plugin: install from wheel for local setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/861>
<dobey> how do i build and run snapd from in tree to test a change?
<zyga> o/
<SuperJonotron> having an issue with installing a snap on 16.04 server that works on desktop version
<SuperJonotron> desktop accepts --force-dangerous and server doesn't recognize it
<SuperJonotron> that's the only difference in the two other than desktop vs server
<SuperJonotron> snap is run as root on both instances
<nacc> SuperJonotron: are they running the same version of snapd, etc?
<nacc> SuperJonotron: just wondering if one picked up an update and one didn't?
<SuperJonotron> possibly, how do you update snapd from snappy?
<nacc> SuperJonotron: these both sound like classic systems, so i meant `apt update; apt upgrade` on both
<SuperJonotron> server isn't classic, no apt-get
<SuperJonotron> only snappy
<nacc> SuperJonotron: ah, that i'm not sure then :)
<nacc> SuperJonotron: you might try --dangerous rather than --force-dangerous
<nacc> iirc, there was some disucssion about this
<SuperJonotron> nacc, no go
<nacc> SuperJonotron: although i'm not sure how that plays into the core images
<nacc> SuperJonotron: sorry, out of my depth :/
<SuperJonotron> i'm not even sure if lacking that flag is causing my issue
<SuperJonotron> i just know thats the difference and one runs fine and the other runs with security issues so...
<SuperJonotron> anybody familiar with the use of --force-dangerous during install and why it doesn't seem to be accepted on server edition?
<SuperJonotron> what's the latest release of snap?
<SuperJonotron> and/or snapd?
<SuperJonotron> anybody know what the snappy equivalent to apt udpate is?
#snappy 2016-10-08
<mup> Bug #1604848 changed: Create interface for unity8 scopes <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1604848>
<Brazza> he
<Brazza> hello
<clobrano> hello, I came back only recently to snappy world and I'm reading a lot about "interfaces". What are they and where I can find more info about them? Thanks!
<qengho> clobrano: Hi! You know how snap packages are confined to being able to access just what they need to run?
<qengho> clobrano: interfaces are the gross kinds of access that your snap can ask to use. Your end is the "plug" end, and you list the plugs you have in your description file.
<qengho> https://developer.ubuntu.com/en/snappy/guides/interfaces/
<qengho> clobrano: A good example is "network". You can't talk out to the world unless you ask to use the network interface by saying  plugs: [ network ] .
<qengho> http://snapcraft.io/docs/reference/interfaces
<haydenbjyoung> Hello.
<clobrano> qengho: thanks a lot!
<clobrano> qengho: from a software point of view, are they dbus interfaces?
<qengho> clobrano: No. It's seccomp filters and apparmor profiles and whatever else we can bring to bear in the future.
<clobrano> qengho: I see
<zyga> qengho: hey
<zyga> qengho: snap-confine applies confinement policy created by snapd
<qengho> zyga: Do you mean to be talking to me?
<zyga> qengho: sorry, I read just the bottom part of the scrollback, I realized you were answering a question from colobrano
<Son_Goku> zyga, do you plan to update snap-confine in fedora anytime soon?
<Son_Goku> or progress forward on snapd review?
<zyga> Son_Goku: (middle of the night here), yes, next week, all recent releases had flaws that were corrected
<zyga> Son_Goku: (essentially betas)
<Son_Goku> they don't look like betas... :/
<zyga> Son_Goku: snap-confine has one last feature
<Son_Goku> ah
<zyga> Son_Goku: well, if you look at release frequency, each one was made just to fix discovered bugs
<Son_Goku> so what is the remaining feature?
<zyga> Son_Goku: the soc-called /media sharing, I posted a branch yesterday and once that lands snap-confine is complete and I'll work on actually getting people to use it
<zyga> Son_Goku: pull 166 or something
<zyga> 168
<zyga> Son_Goku: you may have seen we announced beta images
<Son_Goku> yes
<zyga> Son_Goku: and that is listed as a known issue
<zyga> I should sleep :/
<zyga> I wokre up at 2AM
<Son_Goku> welp
<Son_Goku> zyga: https://github.com/zyga/fedora-core-snap/pull/2
<mup> PR zyga/fedora-core-snap#2: Add flag to indicate doc data shouldn't be installed <Created by Conan-Kudo> <https://github.com/zyga/fedora-core-snap/pull/2>
<zyga> sleep
<Son_Goku> nighty night :)
<kdeforche> Anyone knows where I can find latest news such as availability of 16.04 for the Intel NUC?
<zyga> good morning
 * zyga hacks on snap-confine
<Son_Goku> zyga, morning
 * Son_Goku checks the clock
<Son_Goku> it's been roughly 4 hours...
<zyga> hehe
<zyga> yeah
<zyga> I didn't sleep
<zyga> I tried
#snappy 2016-10-09
<zyga> I tool the subway to get here, had a nice walk in the 6C weather
<zyga> Son_Goku: how are you doing, ready for snappy sprint next week?
<zyga> well, in one week
<Son_Goku> well, I'm looking forward to seeing all my favorite people again
<Son_Goku> the thing about sprints is that I actually get to meet people
<Son_Goku> being located in the US means I rarely, if ever, get to meet the people I chat with regularly
<Son_Goku> and since I do this all in my spare time, it means that I make no money doing it, so there's no incentive for my employer to send me anywhere
<Son_Goku> so I love being able to go to things like these, because then I get to meet people
<Quacky2200> Hey guys, does anyone know if they could help me to understand snappy confinement?
<Quacky2200> I want my application to access the home folder to store settings in it's own folder within the users home folder but confinement would prevent me. Could I use some kind of plug?
<alvarolb> hi! is there any way to run a postinst script, or copy some data to SNAP_USER_DATA after install and before running the service?
<ogra_> alvarolb, try doing it from the service startup instead ;)
<alvarolb> ogra_ thanks! that seems to be the only way at this moment...
<nsg> Any experience with zenity (or a simular tool) inside a snap? I get a "...Could not load ui file /usr/share/zenity/zenity.ui: Failed to open file..", but the file is there (inside the snap).
<nsg> This is still somewhat new for me so, where do I start to debug this?
<nsg> Ah, of course ... the file referes to the path outside the snap ... Have been working with chroots/containers a lot the last weeks so I forgot that this is still a shared /
<nsg> So ... I change the question to, how do I trick zenity to load it's stuff from $SNAP/usr/share/zenity/zenity.ui
<DanKegel> snappy-playpen/ps-mem looks stale.    https://github.com/ubuntu/snappy-playpen/pull/253 seems to let it build and run here.   I literally have zero experience with snaps; anyone want to review?
<mup> PR ubuntu/snappy-playpen#253: ps-mem: update to build with 2.19 <Created by dankegel> <https://github.com/ubuntu/snappy-playpen/pull/253>
<uIPFS-BOX> Hello
<uIPFS-BOX> id like to start a project with the bananapro, but im a newbie in snappy
<uIPFS-BOX> can someone help me porting ubuntu snappy core to the BananaPro ?
<uIPFS-BOX> hello?
<popey> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<popey> :(
<uIPFS-BOX> hello popey
<popey> hello
<popey> uIPFS-BOX: I don't believe the porting guide for devices is written yet.
<uIPFS-BOX> ...
 * popey files bug 1631791
<mup> Bug #1631791: Pi 2 on ubuntu-core 845 no longer able to do anything <Snappy:New> <https://launchpad.net/bugs/1631791>
<mup> Bug #1631791 opened: Pi 2 on ubuntu-core 845 no longer able to do anything <Snappy:New> <https://launchpad.net/bugs/1631791>
<pdc_> diddledan, i like your hexchat snap :)
<pdc_> diddledan, needs a desktop file and icon
<diddledan> pdc_: quick heads-up, you need to turn-off scroll-back reloading in the settings currently because GDK can't load the files and it crashes
<diddledan> yeah, I thought I'd added a desktop and icon but it seems to not work
<diddledan> I must be doing something wonky
<diddledan> there's a copy of my previous release (I've only re-rolled it today to account for the new upstream release) in the playpen
<diddledan> if you can work-out what I did wrong with the desktop file I'd be eternally grateful :-)
<popey> diddledan: hm, that desktop file looks okay
<popey> ooh, the exec line is missing
<diddledan> really? oddness
<popey> diddledan: grep Exec /var/lib/snapd/desktop/applications/unofficial-hexchat_hexchat.desktop
<diddledan> hmm: Exec=${SNAP}/bin/hexchat
<popey> yeah, i see that in the playpen
<popey> but ^ is on my installed machine
<popey> wonder if snapcraft is gobbling it
<popey> unpack your snap and see if it's in there?
<diddledan> n0rty snapcraft
<diddledan> the desktop is in ./meta/gui/hexchat.desktop in the squashfs unmangled
<diddledan> i.e. Exec is still there
<nsg> I checked a snap that I just packaged, Exec is missing from /var/lib/snapd/desktop/applications/ but it's there in /snap/$NAME/current/meta/gui/
<diddledan> there's also the desktop which ships with upstream in the squashfs at ./share/applications/hexchat.desktop
<popey> so maybe snapd is mangling it on install?
<nsg> Did a local install and Exec is still missing, so it's not the store. So install-time is likely.
<nsg> https://github.com/snapcore/snapd/blob/98c8e937625ce3134cf17025d8f0eb3e1016259a/wrappers/desktop.go#L115
<ogra_> popey, are you sure you are on 845 ? ... (try: fw_printenv | grep ^snap_core )
<ogra_> (i have recently seen pi's switch from edge to stable out of the blue)
<ogra_> (which then causes such a behaviour)
<diddledan> nsg: popey: that function looks wonky to me
<popey> ogra_: popey@localhost:~$ fw_printenv | grep ^snap_core
<popey> snap_core=ubuntu-core_424.snap
<diddledan> it will only accept the wrapper command-line or a command which runs the wrapper command-line followed by a space and then arbitrary
<diddledan> i.e. it won't accept ${SNAP}/bin/hexchat
<popey> diddledan: please file a bug
<diddledan> popey: on the github?
<diddledan> or should it go to launchpad?
<popey> no, launchpad
<diddledan> gotcha
<popey> https://bugs.launchpad.net/snappy/+bugs
<popey> ta
<diddledan> there's a marginally similar issue already raised as 1580738 from may
<diddledan> #1580738
<mup> Bug #1580738: exec in desktop file should be app name and not include the friendly (current) package name <Snappy:New> <https://launchpad.net/bugs/1580738>
<nsg> probably broken since https://github.com/snapcore/snapd/commit/f4357d1f79616a1f03746539d81dc01791c89e95
<diddledan> aha #1616657 is filed, too
<mup> Bug #1616657: snapd install removes Unity launcher-compliant entries from desktop files <Snappy:New> <https://launchpad.net/bugs/1616657>
<diddledan> that sounds like my bug
<diddledan> aah, no that's unrelated but due to similar sanitisation
<diddledan> ok, bug filed: #1631801
<mup> Bug #1631801: snapd removes Exec lines from .desktop file on installation <Snappy:New> <https://launchpad.net/bugs/1631801>
<diddledan> I've added a small bit at the bottom suggesting that the domain might be snapcraft rather than snapd
<ogra_> popey, sudo fw_setenv snap_core ubuntu-core_845.snap && sudo reboot
<ogra_> popey, and note in the bug that it unconditionally switched to the stable channel
<mup> Bug #1631801 opened: snapd removes Exec lines from .desktop file on installation <Snappy:New> <https://launchpad.net/bugs/1631801>
<popey> ogra_: how do you know it switched to stable?
<popey> oh, 424 is stable, right
#snappy 2017-10-02
<pstolowski> mornings
<davidcalle> Good morning
<zyga-ubuntu> good morning
<kalikiana_> o/
<Son_Goku> zyga-ubuntu, can we merge this now? https://github.com/snapcore/snapd/pull/3984
<mup> PR #3984: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3984>
<zyga-ubuntu> Son_Goku: hello
<zyga-ubuntu> Son_Goku: looking
<Son_Goku> morning
<zyga-ubuntu> Son_Goku: +1'd, I'll ack with mvo and merge
<Son_Goku> mvo is probably not going to be alive for some time...
<zyga-ubuntu> Son_Goku: I'm a bit absent minded today with the news about catalan news
<zyga-ubuntu> Son_Goku: how was the event?
<zyga-ubuntu> Son_Goku: at least you didn't have to fly far :)
<Son_Goku> I didn't fly at all
<Son_Goku> it's too close to fly ;)
<Son_Goku> it was pretty good
<Son_Goku> though now I'm sick :(
<zyga-ubuntu> Son_Goku: me too :)
<zyga-ubuntu> Son_Goku: it was 3C in the morning today
<zyga-ubuntu> Son_Goku: and the temperature jumps around to 15 and back all the time
<Son_Goku> it's 8C right now
<mup> PR snapd#3966 closed: cmd/snap-seccomp,osutil: make user/group lookup functions public <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3966>
<mup> PR snapd#3988 closed: Added note in HACKING file  <Created by rmescandon> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3988>
<pstolowski> zyga-ubuntu, hey, pondering about your comment https://github.com/snapcore/snapd/pull/3972/files/46c79aed60e0b8a3cfe7d827a32af297f2d4950e#r141618790
<mup> PR #3972: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
<pstolowski> zyga-ubuntu, ie. the check if snap.SanitizePlugsSlots is not set. it's tricky considering the tests
<pstolowski> zyga-ubuntu, would you expect it to panic if already set? or just print a warning?
<zyga-ubuntu> pstolowski: hey
<zyga-ubuntu> pstolowski: I was thinking about it myself
<zyga-ubuntu> pstolowski: it'd be easier if it would allow a nil value and just handle that elsewhere
<zyga-ubuntu> pstolowski: then any non-nil value could panic
<zyga-ubuntu> pstolowski: as for tests they should be fine as they can skip that check and assign the variable directly
<pstolowski> zyga-ubuntu, I did with a global bool for a quick test, but the problem is tests seem to be creating more than one instance when they e.g instantiate overlord
<zyga-ubuntu> aha
<zyga-ubuntu> pstolowski: well, think about it
<zyga-ubuntu> pstolowski: maybe you can come up with something
<pstolowski> zyga-ubuntu, sure, will keep investigating
 * zyga-ubuntu finishes NFS spread test and picks up another topic
<zyga-ubuntu> hmm
<zyga-ubuntu> so I have 8GB of ram now and I still see swap
<zyga-ubuntu> :/
<kalikiana_> zyga-ubuntu: Same here, I can't find a way to avoid it even if to my best knowledge memory never exceeds what I have
<zyga-ubuntu> kalikiana_: I know linux swaps out unused memory just to use the RAM better but I really want to avoid that
<zyga-ubuntu> meanwhile, I'm in shell quoting hello
<zyga-ubuntu> *hell
<kalikiana_> I thought that's what "shell" stood for if you spelt it out ;-)
<zyga-ubuntu> shell hell :)
<kalikiana_> I'm already feeling the reverse jetlag... this week is not gonna be any easier to get through
<zyga-ubuntu> so I have quoting fixed, now for the other half of the test
<Son_Goku> kalikiana_: well, at least you're not sick
<zyga-ubuntu> ok, more progress, expanded the NFS test, now just to ensure it restores and I can push that
<zyga-ubuntu> woot, passed
<zyga-ubuntu> ok
<zyga-ubuntu> ok, now 14.04 to check it works too
<kalikiana_> Son_Goku: now you're making me wonder... but I sure hope it's just the jetlag, at least now I can take power naps during the day
<kalikiana_> on the sprint that was difficult, with it being a constant hallway conversation and such
<Son_Goku> I hope I can get over this cold quickly...
<zyga-ubuntu> pstolowski: hey, can you please have a look at https://github.com/snapcore/snapd/pull/3958
<mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
<pstolowski> yep
<zyga-ubuntu> thanks
<zyga-ubuntu> I need some tea and medicine, back soon
<zyga-ubuntu> (the joys of working from home is that you can work while ill)
<ogra_> hmm, are all snaopcraft.io URLs (including the store) dead or is it me ?
<Son_Goku> ogra_: well, https://snapcraft.io/ works for me
<zyga-ubuntu> pstolowski: and https://github.com/snapcore/snapd/pull/3965 is also easy to review
<mup> PR #3965: interfaces/mount: add support for parsing x-snapd-mkdir-{mode,uid,gid}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
<niemeyer> Running late, but will be in the standup in a couple of minutes
 * zyga-ubuntu joins
<ogra_> weird
<ogra_> Son_Goku, thanks ... seems it is related to the canonical VPN (my desktop got stuck)
 * zyga-ubuntu is back but needs to do another errand, I'll be online but off irc as connection will be hit/miss
<kyrofa> flexiondotorg, did that alsa fix actually end up working for you on that snap you were working on?
<flexiondotorg> kyrofa: It did.
<flexiondotorg> I want to make it a remote part because anything needing just ALSA will require that bespoke set of config files.
<kyrofa> Yes. Definitely
<kyrofa> flexiondotorg, I _think_ this is the case but want to verify: those */card/* files are generic, right? They're the entire set of config files for every card supported by alsa, not somehow specific to the hardware on which alsa is installed. Agreed?
<sergiusens> flexiondotorg wait, you got things working without the need to snapcraft-preload?
<kyrofa> i.e. it actually does makes sense to make it a remote part?
<kalikiana_> kyrofa: I'm guessing you said something like 'have a nice day' but it was slow motion robot voice :-P
<kyrofa> sergiusens, yeah baby
<kyrofa> kalikiana_, hahaha
<flexiondotorg> kyrofa: The card configuration is generic but requires the paths are modififed in each one.
<kyrofa> sergiusens, this is what happens when you go get coffee
<kyrofa> flexiondotorg, of course. Excellent
<sergiusens> I was thinking of just biting the bullet and creating snapcraft quirks logic for stage-packages
<flexiondotorg> sergiusens: Not quite. It works in classic but still needed to ALSA config work around.
<kyrofa> flexiondotorg, can I help you with the remote part? I want to make sure we don't drop that
<sergiusens> we already do it implicitly for other things, we should probably just make it an official thing
<flexiondotorg> To work in strict I have to manually add `/dev/shm/* rwl,` to the AppArmor profile.
<sergiusens> a remote part for now should be ok
<kalikiana_> flexiondotorg: that's what preload is fixing ;-)
<sergiusens> flexiondotorg that is a bit broad though
<flexiondotorg> Sadly, we couldn't get snapcraft-preload to work.
<flexiondotorg> I dicussed with sergiusens and he has some ideas about what can be added to snapcraft-preload.
<sergiusens> flexiondotorg I want to make a minimal "configurable" version of it so you do not unnecessarily have to preload everything you may not want to
<kalikiana_> sergiusens: so are my fixes still blocking on the rewrite?
<kalikiana_> or should the user of preload define stuff like /dev/shm or /tmp manually instead?
<kalikiana_> Might be worth opening a forum topic
 * kalikiana_ wrapping for today
<zyga-ubuntu> kalikiana_: o/
<zyga-ubuntu> jdstrand: thank you for the review, have you had a good trip home?
<mup> PR snapcraft#1581 opened: catkin plugin: support rosdep pip dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1581>
<kyrofa> sergiusens, that one is the last bit for one roadmap item ^^
<sergiusens> kyrofa anything pending before that needs to go in?
<mup> PR snapcraft#1420 closed: add new "no-wrapper" property to apps <enhancement> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1420>
<sergiusens> kalikiana_ if your preload fixes are already converted to c++ you should be fine and just requires a review
<kyrofa> sergiusens, that has no dependencies
<jdstrand> zyga-ubuntu: yes, it was uneventful. direct flight, home friday night. couldn't have gone better. thanks for asking :)
<Son_Goku> jdstrand: and you didn't even wind up sick :)
<jdstrand> well, knock on wood :)
<zyga-ubuntu> Son_Goku: my weirdest patch to snapd *ever*: https://github.com/snapcore/snapd/pull/3958/commits/56aaca91a5d7e7aed076703186c729a3283d4c2c
<mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
<Son_Goku> wtf
<Son_Goku> that... literally makes no sense as a patch
<zyga-ubuntu> it makes the PR green :)
<Son_Goku> also, you're really not going to like this...
<zyga-ubuntu> the previous patch failed because "exportfs" is obviously a mis-spelling of "exports"
<Son_Goku> rot13 isn't in /usr/games in Fedora
 * Son_Goku grumbles
<zyga-ubuntu> Son_Goku: I know, I know, I just made this test to run on 16.04
<zyga-ubuntu> Son_Goku: I will expand it to do better and use python to do the rot13
<zyga-ubuntu> Son_Goku: I just wanted to push something quickly not and not re-design it today
<Son_Goku> this is such a stupid PR
<Son_Goku> for such a dumb reason
<zyga-ubuntu> Son_Goku: no, I mean, the PR is nice
<zyga-ubuntu> Son_Goku: but the patch that made it green is silly
<zyga-ubuntu> (read the rest)
<Son_Goku> err, the patch I mean
<zyga-ubuntu> right, no disagreement tere
<zyga-ubuntu> *there
<Son_Goku> fixing /home on NFS is absolutely good
<Son_Goku> and necessary
<Son_Goku> zyga-ubuntu: https://github.com/SELinuxProject/cil
<Son_Goku> this looks like it'd be useful for snapd
<Son_Goku> as it has its own HLL
<zyga-ubuntu> Son_Goku: if I have a moment next week I'll update this to work with cifs
<zyga-ubuntu> thanks, I'll check it out
<Son_Goku> err: https://github.com/SELinuxProject/cil/wiki
<zyga-ubuntu> wow, a documented project
<zyga-ubuntu> I wonder how that happens
<zyga-ubuntu> are all developers a great tech writers?
<zyga-ubuntu> are the docs written ahead of code?
<Son_Goku> CIL docs were written before code
<Son_Goku> the whole thing had a huge design process ahead of time
<Son_Goku> it was explicitly designed to make writing SELinux policies and policy modules easier
<Son_Goku> and allow developing custom languages on top
<Son_Goku> and since snapd already has its own custom format, it would make sense to use CIL rather than the normal language (HLL)
<zyga-ubuntu> that does look sensible, yes
<Son_Goku> CIL stuff can be directly loaded by libselinux
<Son_Goku> and semodule
 * zyga-ubuntu sees lisp-like language
<Son_Goku> haha
<Son_Goku> intermediate languages tend to look very LISPy
 * zyga-ubuntu needs to run (not because of lisp, lisp/scheme are great)
<zyga-ubuntu> yep :)
<zyga-ubuntu> I'll be back later
<sergiusens> kyrofa heh, you changed the PR while I was looking it seemed ;-)
<kyrofa> sergiusens, just the commit, no content. Forgot to ref the bug
<mup> PR snapcraft#1582 opened: plugins: add ros2 boostrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1582>
<kyrofa> sergiusens, that one is ready as well ^^
<sergiusens> kyrofa do you have a 14.04 environment handy?
<sergiusens> kyrofa almost done that review, got distracted by someone wrong on the internet
<kyrofa> sergiusens, I'm afraid not, but I can make one. Who's wrong, let me at 'em
<sergiusens> kyrofa lol, I am sort of joking fwiw ;-)
<kyrofa> :P
<nacc> (cough relatively trivial to setup a 14.04 env with either `lxc launch ubuntu:t` or `uvt-kvm sync release=trusty arch=amd64; uvt-kvm create trusty-vm release=trusty arch=amd64`, but I suspect you knew those :)
<sergiusens> nacc it is a matter of having the correct bandwidth :-)
<nacc> sergiusens: heh
<sergiusens> diddledan does your corebird currently support wayland?
<sergiusens> kyrofa added comments to the review, looks good, tell me what you think and will do another quick round
<kyrofa> jdstrand, I'm getting "snap-confine has elevated permissions and is not confined but should be" on 14.04, using the hwe kernel. Am I missing something?
<Son_Goku> kyrofa: that's probably because it's setuid
<kyrofa> Son_Goku, well, that doesn't explain why it's not confined
<Son_Goku> probably the AppArmor profile didn't apply
<jdstrand> kyrofa: did you reboot into that kernel?
<jdstrand> it is like Son_Goku said.
<kyrofa> jdstrand, Yeah
<Son_Goku> just because I don't use AppArmor doesn't mean I don't know how it works ;)
<jdstrand> what does 'sudo aa-status|grep snap-confine' have to say?
<jdstrand> kyrofa: ^
<kyrofa> jdstrand, https://pastebin.ubuntu.com/25662590/
<jdstrand> kyrofa: hmm, what about just 'sudo aa-status'
<kyrofa> jdstrand, https://pastebin.ubuntu.com/25662599/
<jdstrand> kyrofa: and: snap version ; snap list ; cat /proc/version_signature
<kyrofa> jdstrand, https://pastebin.ubuntu.com/25662608/
<jdstrand> kyrofa: did you set SNAP_REEXEC=0 somewhere?
<kyrofa> jdstrand, no, this is a fresh install, nothing weird here
<jdstrand> let me try in a vm
<jdstrand> kyrofa: it worked here. just a simple 'sudo apt-get install snapd ; sudo reboot ; sudo snap install hello-world ; hello-world'
<jdstrand> kyrofa: what is the output of 'dpkg -l|grep apparmor'
<kyrofa> jdstrand, wait... I've rebooted several times now in order to play with VM networking settings, and all of a sudden things are working
<kyrofa> As rebooted after I installed the core snap, so I have no explanation for this
<jdstrand> kyrofa: so, that is only supposed to happen if the profile fails to load on a distro that supports apparmor
<kyrofa> Hmm
<jdstrand> so, the deb is 2.27.5~14.04
<jdstrand> but the core is 2.27.6
<jdstrand> idk
<jdstrand> hard to say what it was since it is now working. it worked right away here
<jdstrand> kyrofa: did you try to install the snap before rebooting?
<kyrofa> jdstrand, yeah I did. But I installed from the netboot image with the hwe kernel
<jdstrand> kyrofa: I don't know. I used a desktop install. maybe snapd is missing a dependency? iirc, apparmor_parser isn't in netinst (which uses ubuntu-minimal)
<kyrofa> jdstrand, that's possible
<jdstrand> I should've phrased that differently. apparmor isn't in netinst, iirc netinst uses that instead of ubuntu-standard
<kyrofa> Uh. sergiusens have you ever seen pip-installed packages get chmod'd 700?
<sergiusens> kyrofa nope
<kyrofa> It's suddenly happening to me and I have no explanation as to why
<kyrofa> I just tested this a few days ago... it's like pip updated from underneath me, but it hasn't been updated for a while
<kyrofa> sergiusens, it looks like it's expected behavior from pip install --user
<sergiusens> kyrofa new behavior?
 * sergiusens needs to run and pick up his kid from day care
<kyrofa> No, I'm seeing stuff from 2013 about this. I'm so confused
<sergiusens> kyrofa wait, check if we have any postprocessing in the python plugin itself
<kyrofa> Haha, _fix_permissions, dangit
<kyrofa> Well, easy fix at least
<kyrofa> I still can't explain why my testing ever passed, but I'll let it slide
<kyrofa> Maybe I tested as root for some odd reason
<kyrofa> In a container, perhaps
<kyrofa> sergiusens, alright, snapcraft#1581 is ready for another look
<mup> PR snapcraft#1581: catkin plugin: support rosdep pip dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1581>
<kyrofa> That was annoying
<nacc> kyrofa: yeah, containers as effective root have made of my testing in the past invalid too
<nacc> kyrofa: might be worth adding a local cloud-config snippet to ensure the ubuntu user has your ssh key and go that route
<kyrofa> nacc, yeah I actually do that. The only way I would have tested like that would have been unusual and a mistake. But it's the only way I can explain it :P
<nacc> kyrofa: ah ok
<kyrofa> sergiusens, +1 from OSRF on snapcraft#1582
<mup> PR snapcraft#1582: plugins: add ros2 boostrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1582>
<kyrofa> niemeyer, https://forum.snapcraft.io/t/error-when-updating-snap-and-cleaning-old-revisions makes for a very sad experience in lxd :(
<kyrofa> But only after one has time to get invested in it
<niemeyer> kyrofa: Thanks for the ping.. let's find someone to have a look at this so zyga can focus on layouts
<kyrofa> niemeyer, no problem, I wasn't sure if anyone else was familiar with snap-confine other than zyga or jdstrand
<niemeyer> kyrofa: zyga worked a lot on it, but we can find someone else to have a look
<kyrofa> niemeyer, excellent, thank you
<niemeyer> kyrofa: np!
 * niemeyer looks for dinner
#snappy 2017-10-03
<sergiusens> kyrofa snapcraft#1581 should be fine
<mup> PR snapcraft#1581: catkin plugin: support rosdep pip dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1581>
<mup> Bug #1577471 changed: Snap applications cannot access the user's normal XDG directories <personal> <snap-desktop-issue> <snapd-interface> <Canonical System Image:Invalid by pat-mcgowan> <Snappy:Expired> <https://launchpad.net/bugs/1577471>
<mup> PR snapd#3996 opened: snap: refrain from running filepath.Base on random strings <Created by chipaca> <https://github.com/snapcore/snapd/pull/3996>
<mup> PR snapd#3997 opened: cmd/snap: completion for alias and unalias <Created by chipaca> <https://github.com/snapcore/snapd/pull/3997>
<mup> PR snapd#3998 opened: snap-confine, snap-seccomp: Utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<mup> PR snapd#3991 closed:  wrappers: fail install if exec-line cannot be re-written <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3991>
<pstolowski> yay, my rpis3 should arrive on friday
<zyga-ubuntu> pstolowski: nice :)
<zyga-ubuntu> pstolowski: did you get any cases?
<zyga-ubuntu> pstolowski: I have a few and I can share experiences
<pstolowski> zyga-ubuntu, yeah, I got 2 different cases - https://www.amazon.de/gp/product/B01F1PSFY6/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 and https://www.amazon.de/gp/product/B00MQLB1N6/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
<zyga-ubuntu> pstolowski: I have the first one
<zyga-ubuntu> pstolowski: it's easy to assemble and disassemble but doesn't stack
<zyga-ubuntu> the second one looks very nice
<pstolowski> right, it's curved
 * zyga-ubuntu -> walk
<zyga-ubuntu> re
<zyga-ubuntu> ok, now just focus on work :)
<__chip__> zyga-ubuntu: as opposed to focus on what?
<zyga-ubuntu> __chip__: distractions that plague this morning
<ikey> heh
<__chip__> zyga-ubuntu: like https://guacamole.incubator.apache.org ?
 * __chip__ might be eviler than usual today
<zyga-ubuntu> hmm?
<zyga-ubuntu> what is that?
<zyga-ubuntu> interesting software I see
<Son_Goku> morning all
<zyga-ubuntu> Son_Goku: hey
<ikey> Morn
<Son_Goku> ikey: you're alive!
<ikey> yessir - hows it?
<Son_Goku> ikey: I got sick literally the moment I got home
<ikey> yikes
<Son_Goku> my nose is completely stuffed and I have a constant headache :(
<ogra_> Son_Goku, welcome to the club
 * zyga-ubuntu is sick just because of weather, not any fancy travel smavel
<Son_Goku> well, I think I'm sick because of the weather rather than anything else
<Son_Goku> I didn't travel very far...
<ikey> 7C here atm
 * ogra_ wonders if xnox has an idea about https://forum.snapcraft.io/t/networkd-fail-to-set-ip-address-between-leases-if-ip-address-changes/2333 ... being fluid in system-networkd
<Son_Goku> ikey: 12C here
<Son_Goku> but it was 8C a few hours ago
<zyga-ubuntu> pstolowski: hey, would you mind looking at https://github.com/snapcore/snapd/pull/3971
<mup> PR #3971: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
<pstolowski> zyga-ubuntu, will do
<sergiusens> nacc are you registered on the forum?
<zyga-ubuntu> pstolowski: thanks, there's also a small second branch if you want to look
<Son_Goku> zyga-ubuntu, so, when are you going to start writing the SELinux backend for snap-confine? :)
<xnox> ogra_, i need a dump of /run/systemd/netif/leases/* during all stages (one lease, two leases, first expired, both expired), in a launchpad bug report filed with ubuntu-bug systemd
<ogra_> xnox, no "ubuntu-bug" on core
<xnox> config for the dhcp server / interactive script to reproduce would be helptful too.
<xnox> ogra_, if a bug needs to be looked into a bug report is needed
<zyga-ubuntu> Son_Goku: not sure, I need to finish layouts still, though I'm not alone anymore so that's a big relief
<ogra_> xnox, well, the forum kind of became the bugtracker for snap, but i can ask him to file a LLP bug
<ogra_> -L
<xnox> sure but this particular part (systemd-networkd) comes from a package in ubuntu, for which bug tracker is launchpad.net/ubuntu/+source/systemd
<xnox> and lp:~ubuntu-core-dev/ubuntu/+git/systemd git repository
<ogra_> sure
<ogra_> note that there are PPAs for backported packages involved (netplan specifically)
<ogra_> (also ... i think core is the only flavour that makes use of networkd in xenial)
<pstolowski> zyga-ubuntu, I can try :). nb, I've adressed your review feedback for early-sanitize
<zyga-ubuntu> pstolowski: I saw, thank you
<pstolowski> ah, you replied, just noticed
<zyga-ubuntu> niemeyer: oh, one more thing
<zyga-ubuntu> niemeyer: we need manjaro icon on https://snapcraft.io/
<davidcalle> zyga-ubuntu: this is coming today/tomorrow
<ogra_> Mister_Q, should the UBports installer site there for a long time in "Ready to install..." (trying to switch my pro5 to ubports via the ubports-installer snap here)
<ogra_> *sit there
<ogra_> (seems to not move at all)
 * zyga-ubuntu -> break for lunch and back to small PRs that improve snap-confine
<mup> PR snapd#3999 opened: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/3999>
<niemeyer> zyga-ubuntu: And also that other one...
<sergiusens> kyrofa when you are up, can you read through this thread so we can have conversation later in the day on where/how this https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/37 ?
<zyga-ubuntu> niemeyer: indeed :)
<zyga-ubuntu> niemeyer: I'll note to do that
<zyga-ubuntu> re :)
<niemeyer> zyga-ubuntu: Although I haven't really found good references to snaps in the web page, so maybe let's not add until there's something we can explicitly point to
<zyga-ubuntu> niemeyer: I think having install instructions is a must, I'll install them and check in the evening
<zyga-ubuntu> I need to find a moment to swap my HDD, I bought a 2TB HDD as update to my laptop
<zyga-ubuntu> (I ran out of VM space)
<niemeyer> zyga-ubuntu: I wouldn't worry about it.. layouts are way more important
<ikey> i know the snap-update-ns changes bricked solus btw
<ikey> i was toying with git master last week
<zyga-ubuntu> niemeyer: ok :)
<zyga-ubuntu> ikey: oh, can you tell me more?
<ikey> ya basically i was getting no such file or directory error from it
<ikey> when it was invoked from snapd
<zyga-ubuntu> aha...
<ikey> (i straced which is how i know it came from snap-update-ns itself)
<zyga-ubuntu> ikey: is that on current solus package? I investigate
<zyga-ubuntu> ikey: do you have the strace somewhere?
<ikey> nah not on the current pkg
<ikey> we're at, um
 * ikey looks
<ikey> 2.27
<ikey> ill need to rebase it to newer master anyway as some of my PRs are in
<ikey> and i gotta figure out what strays i have left from ubuntu rally
<zyga-ubuntu> ok
<niemeyer> ikey: Thanks for letting us know. As an aside, please note we're working on major improvements around mounting  flexibility so we can support layouts and more. Following git too closely may be a bumpy ride for a while for that reason.
<zyga-ubuntu> ikey: let me know if you have some details
<zyga-ubuntu> ikey: strace is one thing
<zyga-ubuntu> ikey: but golang and strace don't work very well AFAIK
<zyga-ubuntu> ikey: you may need some prints here and there
<ikey> niemeyer, yeah this was on-the-day-git-master
<ikey> zyga-ubuntu, thats what im thinking
<ikey> just printf the hell out of it
<ikey> but if git is rocky right now then ill leave it a little while longer
<niemeyer> zyga-ubuntu: strace shouldn't care about language
<ikey> strace will just follow the underlying syscalls
<niemeyer> zyga-ubuntu: You may be thinking of ltrace?
<zyga-ubuntu> niemeyer: hmmm, last time I tried strace and golang didn't work at all, maybe it is because of the threads and I dind't specify -f and I assumed it's something broken somewhere
<niemeyer> ikey: Yeah, I suggest following the releases.. once it reaches candidate we're pretty sure we have a winner
<ikey> yeah
<ikey> then i can get the last of the needed solus PRs together
<ikey> and 2.29 would be full upstream solus support
<ikey> \o/
<niemeyer> https://www.irccloud.com/pastebin/zJXwdBQ8/
<niemeyer> zyga-ubuntu: ^
<niemeyer> zyga-ubuntu: It wouldn't really make sense for it not to work.. this traces system calls, not application logic
<niemeyer> zyga-ubuntu: It will likely be much noiser though, due to the runtime
<elopio> Good morning!
<zyga-ubuntu> elopio: o/
<elopio> I hope everybody is safe back home now. It was nice to meet you all last week.
<elopio> zyga-ubuntu: and we missed you. Hopefully next time it won't be in the US
<zyga-ubuntu> elopio: or I will be able to come
<elopio> A different country will be better ð
<zyga-ubuntu> costa rica maybe?
<ogra_> +100
<niemeyer> zyga-ubuntu: https://github.com/nomad-desktop/nx-software-center
<ikey> nx = nixos right?
<ikey> er
<ikey> nxos
<ikey> the kde desktop that looks like budgie but isnt
<ogra_> nixos
<ogra_> using the nix package manager
<ikey> right its the one that isnt that one
<niemeyer> zyga-ubuntu: Or Puerto Rico.. I've heard the gov doesn't mind as much there.. </troll>
 * ikey gets confused on that too
<ikey> https://nxos.org/#nomad-desktop
<ikey> there, nxos
<ikey> the not-budgie-budgie
<ogra_> https://nixos.org/nix/
<ogra_> :P
<ikey> not confusing at all
<ikey> lol
<niemeyer> ikey: Yeah.. I was surprised to find out about it.. seems like a curious mixture.. claims it's based on Ubuntu, but no debs, pacman, plus snaps
<niemeyer> Wonder if the author is around here
<ikey> wonder if they've jumped on the ostree bandwag.. wait.. pacman?
<ikey> what the shizz
<niemeyer> Yeah, don't ask me
<ikey> pls excuse me while i find a corner to cry in
<ogra_> ikey, funnily i was looking at nixos before because niemeyer and sergio were discussing their patchelf tool (which is a core part of the nix package manager) on the forum
<ikey> yeah the nixos approach honestly confuses me
<ogra_> seems to be nix and nx day today :)
<ogra_> (despite bein german re-unification day too :) )
<ikey> instead of actually addressing the root cause of statelessness they worked around it with yocto style sysroots and reinvented subvolumes
<ogra_> and pattching ninaries
<ogra_> *binaries
<zyga-ubuntu> niemeyer: *nice*
<ikey> ninaries
<ikey> lol
<ogra_> heh
<ogra_> hello jetlag :)
<ikey> my old friend ...
<zyga-ubuntu> we are at the golden era of OS development
<zyga-ubuntu> you sneeze and wham, an OS pops out
<ikey> accompanied by a couple dozen symlink farms
<zyga-ubuntu> and it has access to all the apps :)
<niemeyer> ikey: ninaries sounds great!
<niemeyer> ikey: it's like a bit, but has nine states
<ikey> well i mean thats kinda the "dream" right? package manager is relegated to an implementation detail
<ikey> nessita, bitField ^= &derpFace ?
 * zyga-ubuntu thinks "90s"
<ikey> er niemeyer *
<ikey> somethin somethin jetlag..
<ikey> this is what i get for poking fun. instant karma.
<niemeyer> ikey: Is there any package manager that isn't relegated to an implementation detail? :P
<ikey> pacman
<ikey> its a badge of honour
<ikey> a way of life
<niemeyer> LOL
<niemeyer> I should work on that then
<niemeyer> Because apparently we all work very hard so that our work eventually becomes invisible :)
<ikey> yea sorta backfired there on the fame plan..
<niemeyer> Yeah :P
<zyga-ubuntu> niemeyer: if you want to work on something visible
<zyga-ubuntu> niemeyer: we should make snap support wallpapers
<zyga-ubuntu> ^_^
<ikey> yes.
<niemeyer> Or we just make it crash a lot
<ikey> black and white animated tiffs.
<zyga-ubuntu> hahaha
<ikey> "why is gnome-shell using 48GB RAM"
<zyga-ubuntu> ikey: because it can :>
<ikey> oh burn
<ikey> lol
<zyga-ubuntu> it's like vista
<zyga-ubuntu> yes
<zyga-ubuntu> it sucks
<zyga-ubuntu> ram
<zyga-ubuntu> literally
<zyga-ubuntu> but then you have free ram in laptops
<niemeyer> panic: snapd word undetected by microphones in last 10 days
<ikey> the henry hoover of desktops. :p
<zyga-ubuntu> not like nowadays when windows 10 makes 4GB laptops common because it's one single time when windows actually improved memory usage so you don't need 8GB in baseline models
<ikey> ah damn you ubunturally.
<ikey> i got still-face-derp-faced from the chris fisher vlogs
<ikey> er stillframe*
<ikey> https://plus.google.com/114713706129194876663/posts/PfL3dKtdMXc :(
<ikey> "a face you can trust"
<zyga-ubuntu> OMG
<zyga-ubuntu> can you edit that to prevent mental burn-in ;D
<ikey> XD
<zyga-ubuntu> I have something appropriate
<kyrofa> sergiusens, alright, I'm up to speed
<mup> PR snapd#3973 closed: cmd/snap-confine: put processes into freezer hierarchy <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3973>
<kyrofa> elopio, are you in today?
<nacc> sergiusens: probably not :/ i'll fix that today
<nacc> sergiusens: done, as nacc
<sergiusens> great, in any case, you might be interested in https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/
<sergiusens> nacc ^
<elopio> kyrofa: I am here, yes
<nacc> sergiusens: thanks will read
<nacc> sergiusens: i would highly recommend tests added to fix this
<sergiusens> nacc it might be hard in adt, but certainly doable on travis
<kyrofa> elopio, when you get a few minutes, can I get reviews on snapcraft#1581 and snapcraft#1582?
<mup> PR snapcraft#1581: catkin plugin: support rosdep pip dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1581>
<mup> PR snapcraft#1582: plugins: add ros2 boostrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1582>
<sergiusens> kyrofa (and elopio if you want) hangout?
<kyrofa> sergiusens, sure thing
<sergiusens> the weekly
<kyrofa> omw
<elopio> The gardener is cutting the grass just now. You won't be able to hear a thing.
<elopio> I can jump in there and listen.
<rogpeppe1> so... i want to make a snap that comprises a daemon that runs all the time, and a command that talks to the daemon via a unix-domain socket. what's the best way to structure that?
<rogpeppe> do i need to declare a new interface and have two apps in my snapcraft.yaml that use it?
<rogpeppe> is network-bind sufficient to create a unix-domain socket?
<kyrofa> rogpeppe, yeah, use network and network-bind
<kyrofa> You should be set
<rogpeppe> kyrofa: that will allow me to make a unix-domain socket in $SNAP_COMMON?
<kyrofa> rogpeppe, yep. Although I suggest putting things like that in /tmp
<rogpeppe> kyrofa: i saw the listen-stream attribute in https://docs.snapcraft.io/build-snaps/syntax#apps-and-commands but that doesn't appear to be an actual thing
<rogpeppe> kyrofa: i suspect the docs might be out of date
<rogpeppe> kyrofa: so, do all apps declared in snapcraft.yaml share the same /tmp ?
<kyrofa> rogpeppe, ah, that may be new actually
<kyrofa> rogpeppe, yes indeed
<rogpeppe> kyrofa: do they all share the same SNAP_COMMON too? I'm a bit confused as to what an app actually is actually.
<kyrofa> rogpeppe, although it's namespaced when looking at it from outside the snap, so you probably don't want that if you ever want access from outside
<rogpeppe> kyrofa: in this case, it's quite nice if only the command can get access to the socket actually
<rogpeppe> kyrofa: so if I just listen on /tmp/socket and dial /tmp/socket, then i should be good?
<kyrofa> rogpeppe, a snap is just a big blob of bundled binaries. You define how the user interacts with it using `apps`, which allows you to define either services or commands that are called by the user
<kyrofa> rogpeppe, yep, should work. That's what I do
<rogpeppe> kyrofa: ok, cool. it might be nice if the docs mention that "network" means unix sockets too
<kyrofa> rogpeppe, it looks like listen-stream and socket are for socket activation, so those features must be new
<davidcalle> kyrofa: months old iirc
<kyrofa> davidcalle, hahaha
<davidcalle> sergiusens: do you recall? I think you added these ^
<davidcalle> (in the docs I mean)
<sergiusens> davidcalle not me, it was someone working on lxd that proposed a new implementation for sockets
<sergiusens> sanpcraft 2.0 never had socket support, snap.yaml had it hidden though
<sergiusens> davidcalle here's the long thread for it https://forum.snapcraft.io/t/socket-activation-support/2050/31
 * sergiusens takes a lunch break
<davidcalle> sergiusens: thank you
<kyrofa> elopio, this PR is failing the CLA check with an email I don't recognize: https://github.com/snapcore/snapcraft/pull/1580
<mup> PR snapcraft#1580: cli: setup gitignore when working from git directory at init <Created by msis> <https://github.com/snapcore/snapcraft/pull/1580>
<kyrofa> None of the commits seem to have it
<elopio> kyrofa: that is Jeff, from heroku.
<elopio> not sure where is it coming from.
<kyrofa> What the heck. Master?
<elopio> if you tell him to squash and rebase, don't they go away?
<kyrofa> I'll try updating the branch first
<kyrofa> sergiusens, elopio two OSRF +1s on snapcraft#1582
<mup> PR snapcraft#1582: plugins: add ros2 boostrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1582>
<kyrofa> Hey zyga-ubuntu, I seem to remember you poking at snapd on gentoo a while back. Did that seem to work?
<zyga-ubuntu> jdstrand: hello
<zyga-ubuntu> jdstrand: would you have the time to look at https://github.com/snapcore/snapd/pull/3999 today, I'd like to get initial feedback and iterate daily, the branch is rather small and instead of a full security review I'd like to just ack the basic principle
<mup> PR #3999: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/3999>
<rogpeppe> sergiusens: so i've made progress, but the client command gets a "permission denied" error trying to connect to the socket
<rogpeppe> sergiusens: do I need to manually chmod it after listening, do you think?
<rogpeppe> oops, kyrofa ^
<rogpeppe> kyrofa: the socket mode is Srwxr-xr-x so I think it *should* be open. I can only suspect app armor
<kyrofa> rogpeppe, if you suspect apparmor, check the syslog, or use snappy-debug
<kyrofa> (are you familiar with that handy tool?)
<rogpeppe> kyrofa: no, i didn't know about it. will take a look tomorrow
<jdstrand> zyga-ubuntu: done (I can't commit to being able to do this daily, but I'lltry)
<zyga-ubuntu> jdstrand: thank you :)
<mup> Issue snapcraft#1444 closed: catkin pip support <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1444>
<mup> PR snapcraft#1581 closed: catkin plugin: support rosdep pip dependencies <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1581>
<sergiusens> kyrofa mind taking another look at snapcraft#1565 ?
<mup> PR snapcraft#1565: cli: add the pack command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
<kyrofa> sergiusens, on it
<sergiusens> elopio mind following up on snapcraft#1567 ?
<mup> PR snapcraft#1567: recording: record the snaps installed on the machine <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1567>
<elopio> sergiusens: I'm on that after I finish with the dotnet tests.
<kyrofa> elopio, can you take another pass at snapcraft#1582? Or are you good with it?
<mup> PR snapcraft#1582: plugins: add ros2 boostrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1582>
<elopio> kyrofa: I'm good with it. I'll leave my +1.
<kyrofa> sergiusens, okay if that one goes in next?
<sergiusens> kyrofa  do you have the follow-up ready already?
<kyrofa> sergiusens, mostly
<kyrofa> sergiusens, turning the demo into an integration test
<sergiusens> \o/
<kyrofa> But yeah, I had it done for ROSCon
<kyrofa> Then the stupid lighting talks...
<kyrofa> Who raffles those
<mup> PR snapcraft#1582 closed: plugins: add ros2 boostrapper <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1582>
<kyrofa> \o/ thanks :)
<sergiusens> kyrofa mind having a second look on snapcraft#1578 ?
<mup> PR snapcraft#1578: project_loader: quote more environment variable values <Created by malept> <https://github.com/snapcore/snapcraft/pull/1578>
<kyrofa> Will do, just a minute
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR snapcraft#1583 opened: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583>
#snappy 2017-10-04
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<kyrofa> elopio, I suppose you're in bed by now
<kyrofa> elopio, but for tomorrow: I've got a problem with the ros2 snapd test: it sits with no output for more than 10 minutes, so Travis kills it thinking it stalled
<kyrofa> elopio, do we need to show some sort of output? Even a spinner would probably do it
<kyrofa> I'll comment on the PR as well
<mup> PR snapcraft#1584 opened: style: use dedent for multiline strings <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1584>
<zyga-ubuntu> good morning
<Skip> Join
<zyga-ubuntu> mvo: hello
<zyga-ubuntu> mvo: how are you doing?
<mvo> hey zyga-ubuntu
<mvo> zyga-ubuntu: I'm doing well, thank you. tired but well
<zyga-ubuntu> mvo: what's the outlook on 2.28, shall I allocate some time this week to work on releases?
<mvo> zyga-ubuntu: I need to talk to cachio but I heard of no failures so far (but I'm behind mail). so it should get released this Monday
<zyga-ubuntu> that sounds good
<mvo> zyga-ubuntu: we need a second review for 3984, then this one can go in. maybe Chipaca can have a look when he is around?
<davidcalle> good morning
<zyga-ubuntu> mvo: thank you for the review on 3971
<mvo> zyga-ubuntu: ta, #3993 also needs a second review
<mup> PR #3993: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3993>
<mvo> zyga-ubuntu: and you did the first one already so 3993 is also someting for Chipaca or pawel
<mup> PR snapd#3996 closed: snap: refrain from running filepath.Base on random strings <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3996>
<zyga-ubuntu> mvo: updated https://github.com/snapcore/snapd/pull/3971 as requested
<mup> PR #3971: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
<mup> PR snapd#4000 opened: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4000>
<zyga-ubuntu> mvo: nice
<zyga-ubuntu> mvo: I was meaning to do it, thank you for making it faster :)
<mvo> zyga-ubuntu: still slightly jetlagged so the right level of complexity for me this morning :)
<mvo> zyga-ubuntu: thanks for approving of it, I was not sure if you would like the macro or not
<zyga-ubuntu> mvo: tyler recommended it and I think he has a point
<mvo> zyga-ubuntu: I like it too
<mvo> zyga-ubuntu: I just noticed my base git branch was old and I did not caught them all, will push a new commit with the remaining ones in a minute or so
<zyga-ubuntu> mvo: sure, thank you!
<kalikiana_> o/
<zyga-ubuntu> mvo: is this intentional? https://github.com/snapcore/snapd/pull/4000/files/da0c1770f70d42b27c55a0b79c9320f250a46b77..287e8d2f2b2508c8e0e558f92aecfde30b8ce951#r142608335
<mup> PR #4000: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <https://github.com/snapcore/snapd/pull/4000>
<mvo> zyga-ubuntu: meh, no, merge conflict error :(
<mvo> zyga-ubuntu: sorry for that, fixing
<mup> PR snapcraft#1585 opened: lxd: pass SNAPCRAFT_PARTS_URI through into container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1585>
 * __chip__ takes a break
<mup> PR snapd#4000 closed: snap-confine: add new SC_CLEANUP and use it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4000>
<mup> PR snapcraft#1586 opened: repo: friendly, helpful error for unsupported distros <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1586>
<ogra_> xnox, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1721223
<mup> Bug #1721223: Networkd fail to set ip address between leases if ip address changes <systemd (Ubuntu):New> <https://launchpad.net/bugs/1721223>
<mup> Bug #1721223 opened: Networkd fail to set ip address between leases if ip address changes on UbuntuCore <Snappy:New> <systemd (Ubuntu):New> <systemd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1721223>
<ppisati_> - Mount snap "dragonboard-kernel" (unset) (cannot replace signed kernel snap with an unasserted one)
<ppisati_> is there a way to workaround it or do i need to roll a new image from scatch?
<ppisati_> ogra_: ^
<ogra_> ppisati_, i think this only works if you initially built the image with the kernel as --extra-snap
<ogra_> on regular images it is denied
<ppisati_> ogra_: i vaguely remember that if you built the image with some cli flags, then you could replace the running kernel snap
<ogra_> so if you didnt initially built it like that you will have to build a new one, yes
<ppisati_> uhm ok, i'll roll a new image
<mup> PR snapcraft#1587 opened: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587>
<ppisati_> ogra_: snapdragon image from -edge are broken
<ppisati_> ogra_: and is there a way to get the countdown back in uboot? i need to stop by and do a couple of modifications to the live dtb
<rogpeppe> i was trying to use a unix-domain socket to connect to a snappy daemon, but it seems that it's not possible. My understanding of this thread (https://forum.snapcraft.io/t/socket-activation-support/2050/12) is that it will be allowed eventually. Anyone know the likely timeline for that?
 * sergiusens waves good morning
<sergiusens> apol_ I am working on the extract info thing fwiw ;-)
<rogpeppe> sergiusens: hiya
<rogpeppe> sergiusens: i was wondering about status of unix domain sockets above
<rogpeppe> sergiusens: for the time being i've just gone with a localhost tcp port
<rogpeppe> sergiusens: (in case you're interested, I published the snap in question to "macaroon" - it's an experimental command line tool for playing with macaroons)
<mup> PR snapcraft#1588 opened: lxd: use SUDO_UID for ID mapping <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1588>
<sergiusens> rogpeppe socket support is in the snapd domain, someone like Chipaca could provide more information; this topic https://forum.snapcraft.io/t/the-snapd-roadmap/1973 has all the information
<sergiusens> on the when's, I suppose since it is under upcoming it means that it is planned for "soon" but not tied to any release yet
<rogpeppe> sergiusens: i don't see it under upcoming, but I guess I don't know what topic it counts as
<rogpeppe> sergiusens: are "wayland sockets" the same thing as unix sockets?
<rogpeppe> sergiusens: (i get "access denied" if I try to follow the topic link)
 * kalikiana_ heading out for lunch shortly, back in a bit - getting close to pushing the code from last week to GitHub
<kalikiana_> ("having pushed" I guess is the correct tense here, meh, can't English now)
<iAmSlow> hi
<iAmSlow> where can i check for packages
<iAmSlow> is there working visual studio code
<iAmSlow> ?
<ogra_> ppisati_, oh, in what way ?
<ogra_> ppisati_, we'll need to rebuild the gadget with a bootdelay value to get the countdown back, prob is that this breaks with some addon boards that send data over serial as soon as they are powered
 * zyga-ubuntu -> afk for a moment, need to get warm tea
<apol_> sergiusens: :D awesome
<ogra_> iAmSlow, try: "snap info vscode" ;)
<iAmSlow> i dont have snap atm, am on void linux
<iAmSlow> thats why i asked
<ogra_> there is uappexplorer.com as an interim web UI it allows to search for snaps (despite being a tool for the ubuntu phone)
<ogra_> a proper web frontend for the store is in the works, not sure where that stands though
<davidcalle> ogra_: iAmSlow: https://snapcraft.io/vscode
<davidcalle> Still a wip, but it's live ^
<ogra_> davidcalle, yeah, but no search iterface yet :)
<iAmSlow> ty
<ogra_> works if you know the snap name though
<iAmSlow> i found on that uappexplorer
<ogra_> davidcalle, uh ... "develope website" is a mailto link ...
<davidcalle> ogra_: there is a bug for that
<ogra_> should pehaps say "developer contact"
<ogra_> ah, great
<davidcalle> ogra_: not involved in the impl/design, but yeah, QA is ongoing
<ogra_> good
<zyga-ubuntu> niemeyer: I'd like to skip today's standup, I feel sick and haven't done much today; I'll file a day off with jamie
<jdstrand> zyga-ubuntu: hope you feel better soon
<zyga-ubuntu> thank you :)
<Chipaca> zyga-ubuntu: file a day sick, not a day off, dude
<zyga-ubuntu> oh, I didn't know we have those
<zyga-ubuntu> I never filed one
<Chipaca> zyga-ubuntu: remind me to walk through the other things we have, once you're back and better
<niemeyer> zyga-ubuntu: Ack, go get some rest
<sergiusens> zyga-ubuntu it's documented in the manual dude!
<sergiusens> get better
<jdstrand> stgraber: hey-- today I found the lxc command behaving a little weird. It is trying to access /var/lib/snapd/hostfs/usr/lib/os-release (something I happened to plan on adding this week for unrelated reasons) and it is trying to chroot to /var/lib/snapd/hostfs
<jdstrand> $ lxc list
<jdstrand> chroot: cannot change root directory to '/var/lib/snapd/hostfs': Operation not permitted
<jdstrand> stgraber: no apparmor denials (if I add something for os-release). it works under sudo
<jdstrand> stgraber: lxd r4375, core r3017 (2.28.1 from candidate)
<jdstrand> stgraber: guessing when running the lxc command as non-root, it is still trying to chroot
<jdstrand> let me try a revert
<jdstrand> stgraber: yes, if I revert to r4279, lxc starts working again
<jdstrand> stgraber: I think the /var/lib/snapd/hostfs/usr/lib/os-release denial is a red herring, that is in r4279 (I'll also fix this in the default template)
<ppisati_> ogra_: http://pastebin.ubuntu.com/25673213/
<ppisati_> ogra_: snapdragon edge image
 * kalikiana_ having (apparently) sweet greek mokka, yum
<mvo> meh, looks like the ppc build is broken currently again: https://launchpadlibrarian.net/339707110/buildlog_ubuntu-xenial-powerpc.snapd_2.28.1+git401.a19ed0b~ubuntu16.04.1_BUILDING.txt.gz :( /<<BUILDDIR>>/snapd-2.28.1+git401.a19ed0b~ubuntu16.04.1/_build/pkg/gccgo_linux_ppc/github.com/snapcore/snapd/libosutil.a: member /<<BUILDDIR>>/snapd-2.28.1+git401.a19ed0b~ubuntu16.04.1/_build/pkg/gccgo_linux_ppc/github.com/snapcore/snapd/libosutil.a(_cgo_flags
<mvo> ) in archive is not an object
<jdstrand> stgraber: fyi, https://forum.snapcraft.io/t/chroot-cannot-change-root-directory-to-var-lib-snapd-hostfs-operation-not-permitted/2355/1
<mup> PR snapd#3997 closed: cmd/snap: completion for alias and unalias <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3997>
<__chip__> i'ma going to go for a run unless somebody needs me to do something right now
 * __chip__ failed to go
<Son_Goku> mvo: yay, you're back :)
<Son_Goku> mvo: can you look at merging this? https://github.com/snapcore/snapd/pull/3984
<mup> PR #3984: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3984>
<Son_Goku> zyga-ubuntu has already approved it since tests pass now
<ogra_> ppisati_, (sorry, was in meetings) ... ouch that looks like ondra's last chaneg broke it ... i thought he tested that before submitting
<mvo> niemeyer: re 3951> did we agree on `snap pack` ?
<mvo> Son_Goku: looking
<mvo> Son_Goku: it needs two +1, maybe Chipaca can have a look at 3951 for the second review?
<mvo> Chipaca: if you also could check 3993 that would be great, should be trivial
<Son_Goku> mvo, I don't know what PR 3951 is
<mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
<Son_Goku> well.. now I do
<mvo> Son_Goku: ups, sorry
<mvo> Son_Goku: what I mean is we need two +1 for 3984 - I think its fine and just a formality. then we can squash merge it and cherry pick into 2.28
<Son_Goku> okay
<mvo> Son_Goku: lots of people out today (vac, sick, whatnot) so things are slightly slower than usual
<ondra> ogra_ what happened?
<jacekn> hello. any idea when "channels 2.0" will be available via dashboard.snapcraft.io? I'd like to create them for my snap
<ogra_> ondra, http://pastebin.ubuntu.com/25673213/ is what ppisati_ seess when booting db ... havent had the time to try yet but will before EOD ...
<ogra_> ondra, looks like sd blb and mmc blob got mixed up or so
<elopio>  mvo do you have some time this week to talk about mutt? My problem is that on my canonical gmail account, I can't see the inbox, just "all mail". This is my config: https://github.com/elopio/dotfiles/tree/master/email ð
<mvo> elopio: sure, keep reminding me about it if I don't get back to you :) but happy to help
<ondra> ogra_ no if blobs would be mixed up, you will not get to uboot at all
<ogra_> hmm, indeed
<ogra_> well, something is wrong with eading from the fat
<elopio> mvo: thanks. I will get back to you in a couple of days :)
<ondra> ogra_ ppisati_ this is booting from sd card right?
<ogra_> ondra, i woould guess so, paolo didnt reply yet... all backlog is above
<ondra> ogra_ let me try edge image
<ogra_> still setting up my board here .. i was in meetings til nw
<__chip__> cachio: snapd#3951 needs you to unblock it
<mup> PR #3951:  snap: add new `snap pack` and use in tests  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3951>
<Son_Goku> mvo: Chipaca approved :D
<cachio> __chip__, I'll take a look
<__chip__> Son_Goku: that Chipaca sounds like a cool guy
<Son_Goku> heh, indeed
 * __chip__ still working mostly on his travel computer, for some strange reason
<ppisati_> ondra: yep, sd card
<mvo> Son_Goku: yay
<kalikiana_> __chip__: I do the same, but in fairness, I don't have a non-travel computer :-P
<mvo> Son_Goku: I do the merge/cherry-pick in a little bit
<Son_Goku> mvo: awesome
<Son_Goku> I tried to do the cherry pick myself, but git got mad at me and said it can't apply
<__chip__> kalikiana_: my eyes object if i work for too long on the 12"
<Son_Goku> which is why 2.28.1 hasn't been released into Fedora yet...
<cachio> __chip__, still tests failinf on that PR
<cachio> seem to be related to the change itself
<mup> PR snapd#3984 closed: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3984>
<ondra> ogra_ strange, I get same thing as attila reported once, nothing at all on uart
<__chip__> cachio: it looks like something is reexecing when it shouldn't (or viceversa)
<mup> PR snapd#4001 opened: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by mvo5> <https://github.com/snapcore/snapd/pull/4001>
<kyrofa> Hey elopio, beyond the snapd tests lacking output, my particular test is dying with this: https://pastebin.ubuntu.com/25673818/ . Any ideas on that one?
<__chip__> mvo: where do i send the wine for the review of snapd#3964?
<mup> PR #3964: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <https://github.com/snapcore/snapd/pull/3964>
<mvo> __chip__: I am probably the right person, I can do it next
<__chip__> mvo: :-)
<__chip__> mvo: i was starting to wonder if your comment about needing to do that review with a nice glass of wine was a request :-D
<mvo> __chip__: heh, no, its a matter of just doing it, will do so in a little bit
<__chip__> mvo: okie doke
<__chip__> i think i will now once again try to go for a run
 * __chip__ hopes to make it to the door this time
<elopio> @kyrofa we need to capture the output to see what went wrong
<nothal> elopio: No such command!
<mvo> __chip__: *go* for it
<mvo> __chip__: I take a short break and attack this branch then
<mvo> __chip__: lets see what my jetlag brain can manage
<kyrofa> elopio, ah, okay
<jacekn> hello. any idea when "channels 2.0" will be available via dashboard.snapcraft.io? I'd like to create them for my snap
<elopio> Does it fail only in travis?
<kyrofa> elopio, no, I got that one locally
<kyrofa> But still don't know what it means :P
<kyrofa> elopio, so if I understand your comment on GH correctly, we just need to use pipes?
<elopio> Yes, handle the stdout and stderr on our own.
<niemeyer> mvo: Yeah, snap pack it is (and unpack)
<elopio> Print and safe in case we need to addDetails for an error.
<kyrofa> elopio, alright, I'll see if I can get that working
<kyrofa> elopio, quick question: what is the benefit of addDetails if we're printing the output?
<elopio> The output could be huge, and the error hidden somewhere. In theory, details are nicely printed in the error report at the end of the run.
<kyrofa> Ah, okay
<kyrofa> elopio, should we only addDetails stderr?
<kyrofa> Or both?
<sergiusens> jacekn creation of channels is done per request on the store category on https;//forum.snapcraft.io ... once granted it should show up on the dashboard
<jacekn> sergiusens: thanks. Do you know how to login using ubuntu SSO by any chance?
<sergiusens> jacekn you can read more about that here https://forum.snapcraft.io/t/channel-terminology-and-policy/551
<sergiusens> jacekn I am not sure about that, niemeyer might have more details on it
<niemeyer> jacekn: You mean from code to interact with the store?
<jacekn> niemeyer: no, I mean to use login.ubuntu.com openid, same as dashboard.snapcraft.io uses (requirement to create new account for snapcraft forums is an obstackle for users)
<elopio> kyrofa: after talking with mpt, it seems to me that we can make stderr good enough to understand errors, and look at the full output for details. But, we are not there, I guess for now it depends on each case. Maybe add only stderr, and if it's not good enough, file a bug?
<kyrofa> elopio, good deal
<kyrofa> And agreed
<niemeyer> jacekn: Sorry I'm a bit out of context.. what's the issue again? Do we have someone trying to login and they can't?
<jacekn> niemeyer: context is me trying to get channels 2.0 set up and I was told that to do that I have to post on forum.snapcraft.io but I can't see any option to log in with ubuntu SSO (or any other open id)
<ondra> ogra_ my dragonboard is refusing to boot at all
<niemeyer> jacekn: If you click on Sign In and enter your email and password you should be able to quickly get in
<ogra_> ondra, i have some massive issues with my SD reader ... it refuses to detect any cards
<ogra_> ondra, wsell, i suspect we need to roll back the last gadget commit then
<niemeyer> jacekn: Please let me know if you have any issues there
<ogra_> (though i'd really like to test myself first ... damned)
<niemeyer> We'll likely enable more login systems at some point
<jacekn> niemeyer: sorry but I won't enter my 3rd party password on forum.snapcraft.io, openid shoudl send me to the right place
<niemeyer> jacekn: You can enter whatever password you want...
<jacekn> niemeyer: right so I need to create an account. Understood
<niemeyer> jacekn: Yep, email and password and you're up
<jacekn> ack. Running out of time but might do that next time. I'll also try to file a bug to support SSO for convenience and consistency with the dashboard
<niemeyer> Thanks!
<mup> PR snapcraft#1589 opened: Update default node engine to 6.11.3 <Created by flexiondotorg> <https://github.com/snapcore/snapcraft/pull/1589>
<ppisati_> ogra_: please, don't rollback without reproducing my issue - if i start from an old -edge image, and i let it update, it appears to be fine
<ppisati_> ogra_: while when buiding a fresh -edge image locally, i hit the problem above
<ogra_> ppisati_, because we never update gadget content
<ogra_> its a regression in ondra's last change, i see the same issue over here
<ppisati_> ok
<ondra> ogra_ that is strange as I did test fresh image, I almost never update
<ogra_> http://paste.ubuntu.com/25674091/
<ogra_> ondra, same output that ppisati_ got above
<ogra_> well
<ondra> ogra_ let me check one thing
<ogra_> in fact ...
<ogra_> ubooot.env seems to be broken
<ogra_> printenv doesnt list a single snappy_ var
<ogra_> dragonboard410c => fatls mmc 0
<ogra_> sdhci_transfer_data: Transfer data timeout
<ogra_> mmc_init: -70, time 10653
<ogra_> ** Bad device mmc 0 **
<ogra_> dragonboard410c => fatls mmc 1
<ogra_> ** Unrecognized filesystem type **
<ogra_> ah, wait
<ogra_> dragonboard410c => fatls mmc 1:8
<ogra_>             blobs/
<ogra_>    131072   uboot.env
<ogra_>             dragonboard-kernel_37.snap/
<ogra_> it sees the file but doesnt load it
<mup> PR snapcraft#1590 opened: setuptools: conditional Debian-specific deps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1590>
<ogra_> aha
<ogra_> - #define BOOT_TARGET_DEVICES(func) \
<ogra_> - 	func(USB, usb, 0) \
<ogra_> --	func(MMC, mmc, 1) \
<ogra_> - 	func(MMC, mmc, 0) \
<ogra_> -+	func(MMC, mmc, 1) \
<ogra_> - 	func(DHCP, dhcp, na)
<ogra_> ondra, ^^^ i bet thats the issue
<ogra_> yo switched the boot devices around with your patches somehow
<ondra> ogra_ but I did not change patches
<ogra_> err
<ondra> ogra_ I only split them
<ogra_> you prretty much reworked all of them
<ogra_> https://github.com/snapcore/dragonboard-gadget/pull/6/files
<mup> PR dragonboard-gadget#6: gadget snap build improvements <Created by kubiko> <Merged by ogra1> <https://github.com/snapcore/dragonboard-gadget/pull/6>
<ogra_> ondra, are you sure "git am --3way ../../../u-boot-generic*.patch" will actually apply both generic patches ?
<stgraber> jdstrand: I believe I've got a fix for that one already, might just need promotion
<ondra> ogra_ it will
<ondra> ogra_ just testing it here
<ogra_> ondra, well ...
<ondra> ogra_ I think I found something
<ogra_> U-Boot 2017.05-dirty (Sep 21 2017 - 17:41:37 +0000)
<ogra_> Qualcomm-DragonBoard 410C
<ogra_> DRAM:  986 MiB
<ogra_> MMC:   sdhci@07824000: 0, sdhci@07864000: 1
<ogra_> Using default environment
<ogra_> it definitely doesnt read uboot.env
<ondra> ogra_ I did it manually now and there is difference, #define CONFIG_SYS_BOOTM_LEN           0x1000000 <> #define CONFIG_SYS_BOOTM_LEN           SZ_32M
<ogra_> even though i can see it with fatls
<ogra_> but bootm is way later
<ondra> ogra_ but we are not hitting that at all
<ondra> ogra_ yes and we still fit in 16M anyway
<ogra_> the issue is that it never loads the env
<ogra_> "Using default environment" is a clear indicator
<kyrofa> elopio, something else is slurping up the stdout, even the prints in the test
<kyrofa> I don't remember where that is
<ondra> ogra_ I understand, just trying to figure out what is the reason for that
<ogra_> mvo, hrm ...
<ogra_> ogra@anubis:~$ snapcraft-forum
<ogra_> udev_enumerate_scan failed
<ogra_> ogra@anubis:~$
<ogra_> mvo, my snaps dont start anymore after a reboot
<kyrofa> elopio, I suppose it's just unittest
<kyrofa> Because then it prints stdout/stderr upon failure
<ogra_> mvo, i'm on the beta core
<ogra_> ogra@anubis:~$ rocketchat-desktop
<ogra_> udev_enumerate_scan failed
<mvo> ogra_: when did this start to happen? what revision and what is in the journal/systemd status for the given snaps?
<kyrofa> Er, testtools
<mvo> ogra_: uhhh, that sounds like something from either snap-confine or kernel
<ogra_> mvo, i just rebooted, (xeniall desktop all up to date)
<mvo> ogra_: desktop even, hmmm
<ogra_> it worked befoore the reboot
<ogra_> not sure what came in with the recent updates ... surely a kernel though
<ogra_> (i had not rebooted for a while)
<ondra> ogra_ building gadget here again, to make sure all the patches are correct
<ogra_> ondra, yeah, i just did the same ... the code loks correct ...
<ondra> ogra_ yep I pulled old patch and compared and looks all as expected
<ondra> ogra_ also I did 10+ runs from sdcard here on that code
<ogra_> i was guessing that when i merged it ... yet .. it is broken
<ogra_> ondra, since fatls mmc 1:8 shoows uboot.env just fine theer must be something with the patch
<ogra_> uboot.env is definitely where it should be
 * kalikiana_ going to wrap up for the day...
<ondra> ogra_ any idea how can I restore dragoboard, my one seems to be buggered, so I can't test any
<ogra_> ondra, no idea what yoou mean ? wiping the emmc ?
<ondra> ogra_ can't boot from sd or emms, nothing at all coming on console
<ondra> ogra_ nothing even from aboot
<ogra_> ondra, hmm, inteesting fact ... building a local image with the gadget i built locally seems to boot
<ogra_> that sounds more like your mezzanine board doesnt work
<ondra> ogra_ and user led does not even show that it's trying to boor from sd card when there is sd card
<ondra> ogra_ no I connected uart directly and no luck either
<ogra_> does the led on the mezzanine board light up at all ?
<ondra> ogra_ plus I did try another mezzanine board  and same
<ondra> ogra_ yeah only red one though
<ogra_> how do you connect to uart directly ? i dnt thhink the db supports that
<ogra_> thats fine ...
<ogra_> red here too
<ondra> ogra_ not one which will show trafic
<ondra> ogra_ TX and Rx are on Pin 11 and 13
<ondra> ogra_ https://github.com/96boards/documentation/blob/master/ConsumerEdition/DragonBoard-410c/Guides/uart-serial-console.md
<ogra_> well, did you play with the dip switches at the bottom of the board ?
<ondra> ogra_ I did not wear safety glassed when installing it though :)
<ondra> ogra_ no, nothing it was here on the desk since I used it last time and then it was running fine
<ogra_> weird
<kyrofa> elopio, ah ha! runtests.sh uses -b
<kyrofa> elopio, removing it starts printing stuff
<ondra> ogra_ tell me about it, it packed itself up while it was not even connected to power
<kyrofa> elopio, is that what you have in mind?
<ogra_> mvo, hmm, even switching to stable coe ... noo luck ... and nothing in dmesg, syslog or journalctl .... all i get is "udev_enumerate_scan failed" when tying to un any snap
<ogra_> *stable core
 * ogra_ tries another rebot 
<ogra_> mvo, hrm, so whatever it was, another reboot fixed it
<mvo> ogra_: hm, so the error comes from snap-confine and it happens when enumerating udev fails, now that might be a bug on our side if we add a incorrect udev tag somehow
<ogra_> mvo, yeah, but i cant reproduce it anymore after refreshing to stable and rebooting
<ogra_> ondra, so given my locally built gadget works over here, i think i'll just upload that one by hand to the store and we can take care of the rest tomorrow
<ondra> ogra_ so if you build it locally it works fine?
<ogra_> ondra, yes
<ondra> ogra_ OK upload that one and let me check one thing
<ogra_> uploaded
<ogra_> (waiting for the store to actually release it, then i'll do another testbuild)
<ondra> ogra_ I think I know what happened
<ondra> ogra_ so when you call git am, it will commit those changes
<ogra_> why dont you just use --apply
<ondra> ogra_ which works fine on your/mine machine, as we have set up user
<ogra_> like we do in all other gadgets
<ondra> ogra_ it failed on LP, as git it not set
<ondra> ogra_ because then you need one gadget, or can you do that on multiple patches?
<mvo> ogra_: hm, strange
<ogra_> yeah, use apply :)
<ondra> ogra_ check here https://launchpadlibrarian.net/337810269/buildlog_snap_ubuntu_xenial_arm64_dragonboard_BUILDING.txt.gz
<ondra> ogra_ search for *** Please tell me who you are.
<ogra_> ondra, you use a shell script to call git am ... just make it a loop that calls apply
<ondra> ogra_ that's where it's suppose to say Applying: suport patch for dragonboard410c for ubuntu-core
<ondra> ogra_ and my dragoboard went to 96 board heaven, no fastboot, neither recovery sd card working
<ogra_> ondra, that should noot be possible, there is a ROM that should be recoverable
<ogra_> unless you caused some electrical damage
<ogra_> ask in #96boards
<mup> PR #96: Move architecture handling into its own package <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/96>
 * ogra_ whacks mup
<ondra> ogra_ lol
<ogra_> cprov, http://people.canonical.com/~ogra/snappy/dragonboard-gadget.png why do i have two edge entries there ?
<ondra> ogra_ I'm gonna prepare PR replacing am with apply, seems to working as expected
<ogra_> i assume that shouldnt be possible
<ogra_> ondra, +1 ... take your time though, we should be safe for the dalies now with the manual upload
<ogra_> so tomorrow is enough
<ondra> ogra_ well I can't even test, as my board is dead now
<ogra_> (well, we should be fine if the store behaves ... that screenshot above is a bit worrying)
<ondra> ppisati_ thanks for bringing this up! defo problem with LP build
<ogra_> yeah
<ogra_> ondra, we seem to have a user that uses our gadget as input on the forrum whoo saw it too
<ondra> ogra_ I did not know we have armhf build for dragoboard :)
<ogra_> (i was kind of assuming he broke it with his own patch ... )
<ogra_> ondra, oh,. hah
<ogra_> blind me
<ondra> ogra_ yeah that second edge is different arch
<ogra_> yeah
<ondra> ogra_ which is even more amusing :D
<ogra_> let me unrelease that
<ppisati_> ondra: not at all
<ondra> ogra_ I really want to know where that build came from
 * ppisati_ goes to the gym, back in ~1hr
<ogra_> ondra, most likely a test build of mine in snapcraft.io
<ondra> ogra_ lol
<ogra_> i was tinkering with the possibilities of auto-builds without syncing to LP
<ondra> ogra_ yeah there are only 3 builds
<ogra_> bah
<ogra_> and i cant unelease it
<ondra> ogra_ so we should have also one for amd64 then :P
<ogra_> build.snapcraft.io doesnt do arm64 yet
<ondra> ogra_ I was so many times asking id snapcraft.io can control architectures, here you have reason why
<ogra_> thats the prob ...
<ogra_> we could hardcode cross building
<ogra_> so an amd64 build would always produce an arm64 snap
<ogra_> but that seems a bit evil in case someone wants to build natively
<ondra> ogra_ yeah, but look to snapcraft.yaml, it has specifically defined only arm64 architecture, so we have fail on multiple levels
<ogra_> anyway, myth solved ...
<ogra_> well, that arm64 only applies to the snap metadata
<ondra> ogra_ so build.snapcraft.io  ignored arch in snapcraft.yaml and store does same, and takes file name instead
<ogra_> snaps doont care if the binaries actually match whats written on the box
<ogra_> b.s.io will elease an arm64 snap
<ogra_> no matter whats inside
<ogra_> snapcraft.yaml rules here
<ogra_> the trick is to make sure the binaries inside are actually arm64
<ondra> ogra_ but it build armhf, from recipe which says "arm64 only". magic
<ogra_> my nanopi gadgets all just do cross build on amd64
<ogra_> but out comes armhf as the snap
<ondra> ogra_ snapcraft.yaml says arm64 only
<ogra_> yes
<ogra_> but snapcraft doesnt care
<ogra_> it just uses the local native arch
<ogra_> now ... if you force install a cross compiler and spÃ¼rinkle some magic into the build scripts you will get an armhf or arm64 binary inside
<ogra_> anyway ... i goot called for dinner ...
 * ogra_ is afk
<ondra> ogra_ but we already have armhf binary in there :P
<ogra_> yes
<ondra> ogra_ remember we set arch to arm
<ogra_> likely a bug ...
<ogra_> anyway ... off now ...
<kyrofa> flexiondotorg, can you give me a pointer to the user-story-oriented documentation you guys have been working on? I have two to add
<kyrofa> But I can't remember where they are
<kyrofa> popey, that might be a question for you as well ^^
<kyrofa> Also, are those docs live anywhere?
<sergiusens> kyrofa https://docs.snapcraft.io/build-snaps/languages
<kyrofa> Ah ha, snappy-docs then, got it
<kyrofa> Those are not quite as findable as I expected
<flexiondotorg> kyrofa: There were on the site. But apparently are not currently?!
<kyrofa> flexiondotorg, they are, but you have to know where to look
<flexiondotorg> I mean the top level navigation.
<kyrofa> Ah indeed
<flexiondotorg> I'll raise this.
<kyrofa> The snapcraft hooks docs were blown away as well
<kyrofa> Things have been shuffling there recently
<davidcalle> Kyrofa, blown away?
<kyrofa> davidcalle, replaced with snapd docs :P
<davidcalle> Oh no, with brand new docs
<davidcalle> Kyrofa, feel free to tweak and add
<kyrofa> flexiondotorg, I was going to add MOOS/ROS docs, but they're more... technologies, not languages. Is that okay?
<davidcalle> sergiusens: kyrofa: let's move languages up in the tree, right after first snap
<kyrofa> I guess "node" isn't really a language either
<davidcalle> Kyrofa : looks like the only requirement so far is having a logo for it
<davidcalle> :p
<kyrofa> davidcalle, sounds good
<kyrofa> davidcalle, hahaha
<mup> PR snapd#4002 opened: interfaces: misc updates for default, browser-support, home and system-observe <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4002>
<kyrofa> Alright elopio, sergiusens take a look at snapcraft#1591
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<mup> PR snapcraft#1591 opened: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<mup> PR snapd#4003 opened: interfaces: deny lttng by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4003>
<mup> PR snapd#4004 opened: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4004>
<sergiusens> kyrofa I'll look in a bit
<Mikael> I have a bunch of Dell 2001 running ubuntu core and is concerned about the system time being syncronized. Is there a snap to sync time? I've seen timedatectl mentioned...
<Mikael> Dell3001
<mup> PR snapd#4005 opened: Add an exception for Firefox's access to /dev/shm, <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/4005>
<__chip__> Mikael: I think the people that can answer that are in a different timezone -- maybe use forum.snapcraft.io so you don't miss eachother
<Mikael> Thanks Chip
<kyrofa> davidcalle, flexiondotorg can I get a new project created on https://github.com/snapcraft-docs ?
<kyrofa> sergiusens, any chance you have access to that group?
<sergiusens> kyrofa maybe, why do you ask? :-)
<kyrofa> sergiusens, every language document has its example hosted there
<sergiusens> kyrofa so, what do you want me to create?
<sergiusens> I was being tongue in cheek btw ;-)
<kyrofa> sergiusens, if you would be so kind as to create a moos-ping-example repo there to which I have access
<sergiusens> sure thing
<sergiusens> kyrofa moos-ping or moos-ping-example?
<sergiusens> moos-ping feels a bit better
<kyrofa> sergiusens, I'm good with it
<sergiusens> with which kyrofa? ;-)
<kyrofa> Ha!
<kyrofa> With moos-ping
<kyrofa> sergiusens, sadly, there are no generically useful MOOS or ROS utilities out there, so the examples we need to use are overbearingly boring
<kyrofa> Anything not boring is way too complex for this :P
<kyrofa> But it'll do the job
<sergiusens> kyrofa done, git@github.com:snapcraft-docs/-moos-ping.git
<sergiusens> kyrofa the code for moos you mean and not the snapcraft.yaml itself ;-)
<kyrofa> sergiusens, of course ;)
<kyrofa> sergiusens, hmm... the leading hyphen? A typo?
<kyrofa> sergiusens, also, can you give me commit access? Happy to do PRs if you prefer
<kyrofa> Oh, I have to accept the invite, how fancy
<kyrofa> Okay all good on the commit access. Fix the hyphen and we're good
<sergiusens> strange, not sure how that hyphen got there
<sergiusens> kyrofa you cannot commit?
<kyrofa> sergiusens, all good now, thank you!
<sergiusens> kyrofa btw, snapcraft#1578 could use your attention
<mup> PR snapcraft#1578: project_loader: quote more environment variable values <Created by malept> <https://github.com/snapcore/snapcraft/pull/1578>
<kyrofa> Ah yes, okay
<mup> PR snapcraft#1586 closed: repo: friendly, helpful error for unsupported distros <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1586>
<sergiusens> kyrofa and snapcraft#1591 is failing
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<kyrofa> Nooooooo
<mup> Issue snapcraft#1556 closed: build-snaps recording <design-required> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1556>
<mup> PR snapcraft#1567 closed: recording: record the snaps installed on the machine <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1567>
<sergiusens> elopio mind resolving the conflicts on snapcraft#1584 ?
<mup> PR snapcraft#1584: style: use dedent for multiline strings <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1584>
<kyrofa> sergiusens, if you by chance have some downtime to proofread: https://github.com/CanonicalLtd/snappy-docs/pull/131
<mup> PR CanonicalLtd/snappy-docs#131: languages: add MOOS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/131>
<sergiusens> kyrofa downtime is a rare commodity now that I am alone with my son this week ;-)
<kyrofa> sergiusens, haha, hence the phrasing
<kyrofa> ROS one should be up by tomorrow at the latest
<sergiusens> but I will indeed review later tonight, after bed the bed time shift; we have a tent in his room where we do the first try to get sleeping
<kyrofa> Going back to PRs and reviews for now
 * sergiusens mini EODs until later in the evening/night
<kyrofa> sergiusens, snapcraft#1591 should be fixed
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<elopio> sergiusens: I see no conflicts there. I updated the quotes in the docs
<elopio> oh damn, there are many in the fake refactor. That might be hard.
<mup> PR snapcraft#1565 closed: cli: add the pack command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
<kyrofa> sergiusens, when you're able, can you fork https://github.com/ros/ros_tutorials into snapcraft-docs, please?
<kyrofa> sergiusens, wait... no. Don't do that
<kyrofa> sergiusens, just create a ros-talker-listener repo, or something similar
<kyrofa> sergiusens, https://github.com/CanonicalLtd/snappy-docs/pull/132 for the ROS one
<mup> PR CanonicalLtd/snappy-docs#132: languages: add ROS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/132>
#snappy 2017-10-05
<mup> PR # closed: snapd#3734, snapd#3852, snapd#3872, snapd#3916, snapd#3945, snapd#3951, snapd#3954, snapd#3958, snapd#3960, snapd#3963, snapd#3964, snapd#3965, snapd#3970, snapd#3971, snapd#3972, snapd#3976, snapd#3978, snapd#3989, snapd#3990, snapd#3992, snapd#3993, snapd#3994, snapd#3995,
<mup> snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005
<mup> PR # opened: snapd#3734, snapd#3852, snapd#3872, snapd#3916, snapd#3945, snapd#3951, snapd#3954, snapd#3958, snapd#3960, snapd#3963, snapd#3964, snapd#3965, snapd#3970, snapd#3971, snapd#3972, snapd#3976, snapd#3978, snapd#3989, snapd#3990, snapd#3992, snapd#3993, snapd#3994, snapd#3995,
<mup> snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005
<mup> PR snapcraft#1584 closed: style: use dedent for multiline strings <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1584>
<sergiusens> kyrofa there you go
<mup> PR snapcraft#1553 closed: lxd: instructions for /etc/sub{u,g}id after failed start <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1553>
<mup> PR snapd#4004 closed: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
<mup> PR snapd#4001 closed: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4001>
<kalikiana> snappy good morning
<mup> PR snapd#4003 closed: interfaces: deny lttng by default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4003>
<mup> PR snapd#4002 closed: interfaces: misc updates for default, browser-support, home and system-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4002>
<zyga-fedora> o/
 * zyga-fedora feels bad but will try to work today
<mvo> hey zyga-fedora! good morning
<zyga-fedora> hey
<zyga-fedora> how are you doing
<mvo> zyga-fedora: I'm doing well, thank you
<mvo> zyga-fedora: how do you do?
<kalikiana> zyga-fedora: Still affected by the Ubuflu?
<mwhudson> mvo: https://github.com/snapcore/snapd/pull/3872 <- ready for merge finally???
<mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
<mwhudson> :)
<zyga-fedora> kalikiana: no, I have my own polflu here :)
<mvo> mwhudson: looking, but yeah, hopefully finally :)
<mvo> mwhudson: it needs a second +1 afaics - maybe zyga-fedora can look at 1682308? ideally jdstrand as well
<mwhudson> mvo: ah ok
<mup> PR snapd#4006 opened:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4006>
<mup> PR snapd#4007 opened: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4007>
<zyga-fedora> mwhudson: looking
<zyga-fedora> mwhudson: reviewed
<mwhudson> zyga-fedora: well um your points seem valid but after four weeks of this i am tired :)
<mwhudson> i guess they are simple enough
<zyga-fedora> mwhudson: mind if I rename that constant?
<mwhudson> zyga-fedora: i am totally happy for you to do it, sure :)
<zyga-fedora> I can do that, i feel s***y today and this is the complexity I can handle
 * mvo hugs zyga-fedora
<mvo> mwhudson: sorry for the long wait
<mwhudson> mvo: it's ok, but it has been a long time
<mwhudson> i guess the rally didn't help
<mvo> mwhudson: indeed not
<zyga-fedora> mwhudson: done
<zyga-fedora> sorry, it I spent some time to iterate on the flag names
<mwhudson> zyga-fedora: btw the glibc header that contains these variable names is not installed afaict
<mwhudson> so to go generate it you need a glibc source tree lying around
<zyga-fedora> mwhudson: aww, that sucks
<mwhudson> which of course you and i probably have but :-)
<zyga-fedora> mwhudson: or very creative strings | awk statement
<mwhudson> zyga-fedora: i'm going to pretend you didn't say that, i think
<zyga-fedora> right, I meant perl
<zyga-fedora> ;-)
 * zyga-fedora gets back to reviews
<mwhudson> ha
<zyga-fedora> mvo: 4006 has really borken test
<mvo> zyga-fedora: uh, let me check
<zyga-fedora> rm without -f failing
 * kalikiana doing some snapcraft reviews
<mup> PR snapd#3993 closed: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3993>
<ackk> when absolute paths are used in snap[craft].yaml, are they required to be prefixed with $SNAP* variables?
<mup> PR snapd#4005 closed: Add an exception for Firefox's access to /dev/shm, <Created by oSoMoN> <Closed by oSoMoN> <https://github.com/snapcore/snapd/pull/4005>
<jamespage> q - does the snapstore support the branches concept yet?  I have fixes I want to validate without having to use the edge channel
<mwhudson> jamespage: pretty sure it does
<mwhudson> jamespage: easy to try? :)
<jamespage> mwhudson:  maybe - snapcraft push --help was not helpful
<mwhudson> jamespage: it's on release shurely
<mwhudson> examples:\n...snapcraft release my-snap 9 lts-channel/stable/my-branch
<jamespage> mwhudson: indeed it is - thanks!
<jamespage> just the ticket
<mup> PR snapd#3970 closed: interfaces/mount,cmd/snap-update-ns: move change code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3970>
<ackk> I'm hitting this failure when trying to build snapd master: http://paste.ubuntu.com/25678585/, anyone knows what could be causing it?
<pstolowski> niemeyer, hey, 3852 has all your review feedback addressed, can you have another look?
<zyga-fedora> pstolowski: can you look at https://github.com/snapcore/snapd/pull/3965 again please
<mup> PR #3965: interfaces/mount: add support for parsing x-snapd-mkdir-{mode,uid,gid}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
<pstolowski> zyga-fedora, sure, I meant to
<zyga-fedora> thanks
<ogra_> ppisati_, FYI, todays daily dragoonboard image works fine again
 * __chip__ ~> physio
<ppisati_> ogra_: ok, but i'm off today
<ogra_> heh
<ogra_> ppisati_, enjoy
<ogra_> zyga-fedora, have you seen that ? https://forum.snapcraft.io/t/snapped-lxd-has-stopped-working-aa-exec-doesnt-exist-in-the-snap/2356/7
<ogra_> (core noot providing any interfaces anymore)
<zyga-fedora> huh
<ogra_> yeah
<ogra_> pretty huh
<zyga-fedora> pstolowski: is that one of the things we got from a report from sergiusens before the rally?
<zyga-fedora> ogra_: thanks
<pstolowski> zyga-fedora, sergiusens' problem was about vanishing plugs https://forum.snapcraft.io/t/vanishing-plugs/1823
<zyga-fedora> pstolowski: looks like the same problem to me
 * zyga-fedora thinks
 * kalikiana going for a lunch break in a few minutes
<pstolowski> zyga-fedora, I couldn't reproduce the problem as documented in the vanishing-plugs thread. not sure how to get insight into that problem without finding a pattern to reproduce :(
<zyga-fedora> pstolowski: thinking about how the code can ever allow that to happen
<zyga-fedora> pstolowski: I agree it's not easy
<ogra_> mvo, hmm ... do you see any reason why we shouldnt enable ntp out of the box on the core images ? (i just noticed it is only half configured (ntp.ubuntu.com is in the config) but turned off by default)
<ogra_> we only do the time sync on connect but if you never reboot or reconnect the device it migth start to drift
<stub> Is the stable channel completely unrelated to all the other stable channels? 'snap info go' shows me Go 1.9 in stable, but Go 1.9.1 in 1.9/stable
<ogra_> stub, one is a channel the other is a track ... while i would expect both to be in sync in this case, probably someone forgot to sync over the package fom the track
<ogra_> stub, you should talk to the publisher ;)
<stub> mwhudson: oi!
<zyga-fedora> mvo: what happens when I change one of the snaps in tests/lib/snaps
<zyga-fedora> mvo: how do I upload it to the store/
<stub> ogra_: The cli makes no distinction between channels and tracks that I can see. eg. 'sudo snap refresh --channel 1.9/stable go'
<zyga-fedora> mvo: another piece of the mount machinery puzzle https://github.com/snapcore/snapd/pull/4008 - stacked on top of https://github.com/snapcore/snapd/pull/3971
<mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
<mup> PR #3971: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
<mup> PR snapd#4008 opened: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
<zyga-fedora> hmm, some network failures
<zyga-fedora> # cd .; git clone https://go.googlesource.com/sys /tmp/go/src/golang.org/x/sys
<zyga-fedora> Cloning into '/tmp/go/src/golang.org/x/sys'...
<zyga-fedora> fatal: unable to access 'https://go.googlesource.com/sys/': The requested URL returned error: 502
<zyga-fedora> ok, I need a break, `for { back.hurt() }`
<zyga-fedora> I need to pick up my son from school soon so I'll just go there anyway
 * sergiusens waves
<mvo> ogra_: +1 for ntp
<mvo> zyga-fedora: I can upload it to the store, which snap is it? for some we have snapcraft auto-build branches
<zyga-fedora> aha
<zyga-fedora> I haven't finished the test yet but I'm working on richer tests for the content interface
<zyga-fedora> I think I may end up creating a new snap due to the auto-connect logic
<mvo> ok
<zyga-fedora> and the lesser impact on other tests
<sergiusens> pstolowski zyga-fedora my problem was differen, things connected but actually didn't
<zyga-fedora> aha
<zyga-fedora> wow
<zyga-fedora> opensuse changed policy for golang package
<zyga-fedora> there will be no more golang- packages
<zyga-fedora> go get is the recommended way to do stuff
<zyga-fedora> that's going to be annoying for packaging as we'll need two packages for opensuse now,  a trivial one and the legacy one for before the decision was made
<zyga-fedora> in any case, I need to go to school now
<zyga-fedora> bbl
<ogra_> happy learning then ...
<pstolowski> :)
<mup> PR snapcraft#1572 closed: catkin plugin: allow ROS_MASTER_URI change <enhancement> <Created by cratliff> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1572>
<kalikiana> Love seeing more code getting merged!
<zyga-fedora> re
<kalikiana> @elopio q for when you get in, how long does ./runtests static usually take on your system? It's extremely slow for me, I can prepare and drink a coffee whilst it's running...
<nothal> kalikiana: No such command!
<kalikiana> elopio: q for when you get in, how long does ./runtests static usually take on your system? It's extremely slow for me, I can prepare and drink a coffee whilst it's running...
<zyga-fedora> hmm, tests are not happy
<kalikiana> It seems like it wasn't so slow before... unless something on my system affects it
<Chipaca> ikey: what's your guys' software centre jobbie called?
<zyga-fedora> ohhh
<zyga-fedora> since when do we have snapcraft.io/$SNAP_NAME
<ikey> Chipaca, Software Center
<ikey> Yep...
<ikey> FWIW I put out a feeble request @ NYC for people to come up with a better name
<zyga-fedora> that's so nice
<ikey> Store McStoreFace was the best.
<ogra_> zyga-fedora, since last week or so
<zyga-fedora> nice
<ogra_> zyga-fedora, not officially announced yet though
<ikey> In terms of project name its just known as "solus-sc" on github
<zyga-fedora> aha
<ogra_> (i guess there is more to come first)
<Chipaca> ikey: but the pattern is <diminutive noun> Mc<noun>face
<zyga-fedora> ogra_: snapcraft G+ account mentioned it
<ikey> Yeah they can't even get that right :P
<ogra_> ah
<ogra_> then it is now announced :)
<ogra_> i thought there was a search to come first
<Chipaca> ikey: I was trying to work your thing into a list of more well-known ones, but don't feel i can do it without it being a little in the eye :(
<ikey> so lemme read between the lines here and translate into ikeynese
<ikey> the name is an embarrassment and the other bullet points would complain
<ikey> ?
<Chipaca> ikey: currently it read "GUI software center applications like gnome software or the kde software storeâ
<ogra_> just drop the "like ..."
<ikey> yea i mean in theory its just "the Solus Software Center" with or without capitals
<ikey> Most people (sadly) confuse it for gnome-software anyway
<zyga-fedora> S^2C
<Chipaca> I should change it to "the gnome software centre store"
<ikey> oh "Discombobulation Station" was another suggestion
<ogra_> zyga-fedora, now thats intuitive !
<zyga-fedora> right
<zyga-fedora> at least it's catchy
<Chipaca> zyga-fedora: SÂ²C FTW
<zyga-fedora> now is that at a valid chemical?
<Chipaca> zyga-fedora: or is that 2â¿ edgy 2Â²â¿ u?
<ogra_> squaresulfurcarbon !
<zyga-fedora> brilliant
<zyga-fedora> is it toxic?
<Chipaca> according to my googles SÂ²C is "Smart Sollution Computer's" (2Ãsic)
<Chipaca> ikey: "system destroyer"
<ikey> oo
<ikey> wait wait i got a real friendly cross-distro collab sounding one
<ikey> "All Your SuSE Are Belong To Us"
<Chipaca> ikey: I don't know if that's a breathless "ooh", or a noseless "oâ¸o"
<ikey> nah was an ooh
<Chipaca> ikey: "rootkit installer v7.337"
<ikey> XD
<zyga-fedora> my tests are timing out
<Chipaca> niemeyer: good morning sah! does our discourse have checklists?
<sergiusens> Chipaca as fancy as github's?
 * ogra_ wonders if the core team started giving out bonuses for most new topics/day 
<Chipaca> ogra_: cake
<ogra_> does gustavo bake it himself ?
<niemeyer> Chipaca: Sort of.. it has icons, and we can abuse them
<niemeyer> Chipaca: Per roadmap and our review sprint boards
<zyga-fedora> mvo: can you please land 3971, I think it's ready now
<Chipaca> zyga-fedora: wrt night-rider, don't give me ideas
<Chipaca> (or rather, don't reinforce ideas i'm struggling to ignore)
<zyga-fedora> Chipaca: just think about what you could make if there were ansi escape codes for sound effects
<Chipaca> zyga-fedora: there are!
<Chipaca> zyga-fedora: beep + strings-of-nulls-as-delays
<zyga-fedora> Chipaca: I know but those are limited and often disabled; think 8 bit sound :)
<mup> PR snapd#3971 closed: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3971>
<zyga-fedora> \o/
<zyga-fedora> thanks
<zyga-fedora> and 4008 now looks easy to review
<zyga-fedora> (and I'll add some spread tests for it)
 * kalikiana time for a break, back in a bit
<niemeyer> mvo: Release notes LGTM
<mvo> ta
<jdstrand> mvo, mwhudson: I took a look at https://github.com/snapcore/snapd/pull/3872. I think someone should consider my question on preserving LD_*
<mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
<zyga-fedora> jdstrand: hello, thank you for the reviews!
<jdstrand> mvo, mwhudson: beyond that it is renaming two tests (or tell me I'm wrong! :) and adding one more and I'll +1
<jdstrand> zyga-fedora: hey-- feeling better?
<zyga-fedora> jdstrand: meds make me feel better
<jdstrand> well, that's astart
<zyga-fedora> jdstrand: I think my rain-and-cold-o-meter is full for the year already
<jdstrand> oh no!
<jdstrand> you have at least a couple more days of that this year I'm sure
<zyga-fedora> not unless I buy a one-way-ticket somewhere :-)
<apol_> does anyone know what this snapd error means exactly? https://paste.kde.org/pdbxoeiqc
<zyga-fedora> apol_: is squashfs loaded into the kernel? or maybe the .snap files got corrupted?
<apol_> ah, wrong squashfs... SQUASHFS error: Filesystem uses "xz" compression. This is not supported
 * apol_ looks into it further
<zyga-fedora> looks like you need one kernel config option flipped
<zyga-fedora> XZ support for squashfs is a separate knob
<niemeyer> apol_: What distro is that?
<niemeyer> mvo: Just added a topic link to the last entry in the notes
<apol_> plasma mobile
<niemeyer> mvo: Also fixed roadmap to reflect notes, and to push dates forward
<mvo> niemeyer: thanks alot!
<niemeyer> apol_: Who maintains its kernel?  We should get in touch to suggest enabling that upstream
<apol_> yes yes, it's what we are doing
<apol_> 5' it didn't have squashfs at all
<apol_> 5' ago*
<__chip__> niemeyer: didn't we have a list of all the things that needed to be enabled?
<mvo> stgraber: I was just looking at 16325008 again (i.e. that you need a way to differentiate uninstall/shutdown from stop script. we now have a bunch of hooks (post-refresh, install, uninstall). will these hooks help you with the bug? i.e. setting the right states based on the hooks that stop-commnad-daemon.wrapper could pick up?
<__chip__> maybe that's closer to ogra_'s purview
<niemeyer> apol_: Oh, yay!
<niemeyer> __chip__: I haven't seen one, but it's a great idea
<__chip__> niemeyer: I suspect ondra knows this
<__chip__> ondra: OHAI
<__chip__> ondra: is there a list of kernel options needed for snappy?
<zyga-fedora> pstolowski: can you please re-look at 3965
<pstolowski> zyga-fedora, yes, sorry, i was looking at it and got distracted. on it
<zyga-fedora> no worries, thank you
<zyga-fedora> now for that NFS + udp test
<zyga-fedora> niemeyer: oh I know what that thing was
<zyga-fedora> niemeyer: opensuse changed packaging rules for golang
<zyga-fedora> niemeyer: (again)
<zyga-fedora> niemeyer: and the new rules are ... go get :)
<pstolowski> zyga-fedora, approved, but please add two extra checks to the test (see comment)
<zyga-fedora> niemeyer: so I'm happy to not have to maintain any golang package in suse anymore
<niemeyer> zyga-fedora: Nice!
<zyga-fedora> niemeyer: we'll have to to some work to update our package
 * kalikiana doing some pulling/ checking for red PRs
<zyga-fedora> pstolowski: ack, will do
<ondra> __chip__ hey
<ondra> __chip__ if you build using snapcraft, it will already warn you about missing options
<__chip__> apol_: ^ !
<ondra> __chip__ also have look here https://github.com/snapcore/sample-kernels
<__chip__> apol_: ^^
<__chip__> ondra: awesome stuff
<mup> PR snapd#3945 closed: snap: refactor cmdGet.Execute() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3945>
<ondra> that's usually good place to start
<__chip__> apol_: you got that?
<kalikiana> elopio: could you maybe give me a hand with https://github.com/snapcore/snapcraft/pull/1536 I can't get it to pass on Travis
<mup> PR snapcraft#1536: repo: implement :target suffix for package names <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536>
<kyrofa> Haha, kalikiana elopio is in high demand today, I'm having problems as well
<kyrofa> He probably hasn't woken up yet
<kalikiana> :-D
 * kyrofa dives into our testing infrastructure because it's all black magic
<kalikiana> kyrofa: btw I saw your PR for the stderr output. By the looks of it we have a common enemy in those false negatives
<ondra> __chip__ out of curiosity which hw are you trying to enable?
<kyrofa> kalikiana, actually no, my problem is that I have a test that runs for longer than ten minutes. Since we show nothing, Travis thinks it stalled and kills it :P
<kyrofa> kalikiana, but yeah, this can also make failures easier to trace
<kalikiana> kyrofa: Ah, maybe... I just checked some branches that failed in the middle of downloading or even invalid syntax because something gets stopped in between. So not sure they're timeouts or rather network breaking down
<kalikiana> Although it would seem odd for Travis' network to die during a test run?
<elopio> It's raining sooo much. I'm trying to wake up now, but outside of the bed it's scary.
<elopio> I'll check soon
<ogra_> __chip__, apol_ , if it is arm, i'd actually suggest to check our existing geneic kernel if the device is already supported ... by default oour arm kernel works on 430 devices OOTB (and with my allwinner changes even on 550), you just need to pick the rigth dtb from the gadget
<kalikiana> elopio: good morning ^_^ didn't mean to rush, mainly so I wouldn't forget to ping you later
<kalikiana> kyrofa: would you feel like being the second reviewer here? https://github.com/snapcore/snapcraft/pull/1546
<mup> PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
<ogra_> __chip__, apol_ also, you probably want to use this starting doc instead of just the snapcore/sample-kernels (which just has the linux boilerplate as README ) https://github.com/piso77/sample-kernels
<mvo> cachio: could you please look at 1703798 and do the sru verification for 2.27.6 once that is done I will upload 2.28.1 to -proposed
<cachio> mvo, sure+
<ogra_> though i'd always check generic first ... thats a great timesaver
<mup> PR snapcraft#1592 opened: travis: run snapd tests only if not cron <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1592>
<ackk> mvo, wrt socket activation, I'm wondering if using $SNAP_DATA/$SNAP_COMMON should be supported, or those should be rendered by snapcraft and snapd only accept a "rendered" path
<mvo> ackk: I think its fine to support $SNAP_{DATA,COMMON}
<kalikiana> Oh, missed a q in there... I really wish sometimes top-level comments didn't exist separate from actual review comments...
<zyga-fedora> jdstrand: will you have some time to look at 4008 today?
<zyga-fedora> jdstrand: it's tiny (the actual new code) apart from tests
<zyga-fedora> jdstrand: again I'm just interested in the approach taken, you can do the full review later
<jdstrand> zyga-fedora: I think so. looking at https://github.com/snapcore/snapd/pull/3958 now
<mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
<zyga-fedora> jdstrand: excellent, thank you
<zyga-fedora> jdstrand: I've added a test for UDP, will push after it runs locally
<mvo> tyhicks: I pushed some test fixes to 3998, I hope you don't mind, if you prefer I can also do them as separate PRs
<tyhicks> mvo: any help pushing this along is much appreciated - thanks! :)
<tyhicks> mvo: I'm currently working on the libseccomp and kernel SRUs to zesty and xenial
<mvo> tyhicks: great, thanks for this!
<tyhicks> no problem!
<tyhicks> mvo: did you have an opinion on preprocessing? https://github.com/snapcore/snapd/pull/3998#discussion_r142661507
<mup> PR #3998: snap-confine, snap-seccomp: Utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<elopio> kalikiana: your errors are connection problems on travis or the archive. I see no other solution than retrying.
<elopio> kyrofa: which one is failing for you?
<kyrofa> elopio, I re-ran it, I think it was network issues after comparing to other tests
<kyrofa> elopio, the plugin integration tests, though. They take forever
<kalikiana> elopio: Hrm, I guess that's what I'll keep doing. The fact that I see this more frequently worries me, though... and it gets very difficult to get reviews...
<elopio> kyrofa: yes, things like python are very very slow.
<stgraber> mvo: I haven't tried that yet since we've got a workaround in place already, I'll have to figure out if those run at the right time for us and then switch away from our hack.
<elopio> I want to time the tests, and see if we can improve a little. But I will start with unittests, and not this week.
<kyrofa> elopio, I think I found a workaround (hack) for the long-running tests with no output: travis_wait
<elopio> oh, nice. I didn't know about it.
<elopio> kalikiana: well, it happens some times. If it persists, you can open a ticket in travis.
<zyga-fedora> jdstrand: thank you!
<nacc> would it be possible for snapcraft/snapd to do some magic so that if i say my applications manpages live at a given path in the snap, that /etc/manpath.config could be adjusted to make those manpages available to all users (not sure if MANDATORY_MANPATH or MANPATH_MAP is better), without having to do an install hook? THen when the snap is removed, that line that was specifically added can be removed?
<nacc> it feels like bash completions and manpages are going to be quite common for classic snaps, as general things to expose to all users
<nacc> sergiusens: --^
<zyga-fedora> nacc: snapd will eventually support man pages, for now it's not something we have on the roadmap
<sergiusens> nacc if we do anything in a way of "placing a file somewhere" style of thing I think we should go down the same path we do for hooks
<sergiusens> I'd propose a forum topic though
<nacc> well the file already exists :)
<nacc> (/etc/manpath.config)
<nacc> sergiusens: yeah yeah :)
<sergiusens> nacc we can discuss all you want here, but as soon as the conversation is over it will be forgotten :-)
<nacc> zyga-fedora: even for classic snaps?
<sergiusens> nacc that should not make a difference
<nacc> sergiusens: well, I would agree in principle
<nacc> sergiusens: but I want to be sure
<nacc> because my experience with classic so far has been painful :)
<nacc> alternatively, would it make sense to add an interface for confined snaps that says "let me read/write anywhere the calling user can read/write to"
<nacc> if that was the case, i thinkn our snap could be confined
<zyga-fedora> nacc: in general
<nacc> zyga-fedora: ok, thanks
<mvo> tyhicks: I have a look at the pre-processing now, I had not really thought about it yet
<nacc> I guess my interface idea doesn't actually make sense in confined, since you can't see the host FS. But it's like the home interface, but broader
<nacc> I want something squarely between classic and confined, which I think basically every CLI wants
<mvo> tyhicks: sounds sensible, I will do it
<kyrofa> jdstrand, the password-manager-service interface doesn't seem to work for qtkeychain
<tyhicks> mvo: thanks!
<ppisati_> ogra_: yep, daily works fine
<ppisati_> ogra_: thought i'm slightly confused
<ogra_> ppisati_, thanks fo confirming
<ppisati_> ogra_: http://pastebin.ubuntu.com/25680457/
<ogra_> waiting for a proper fix from ondra though he first needs to get his dragonboard back to life
<ppisati_> it says 'core' is @ 2973
<ppisati_> and it's tracking edge, but edge is @ 3074
<ogra_> freshed:   2017-09-20 04:30:03 +0000 UTC
<ppisati_> ogra_: but you built it today
<ppisati_> i mean,. it's a daily
<ppisati_> uhm
<ogra_> yeah, thats a bit strange ... admittedly
<ppisati_> so it's a daily with a 2 weeks old core :D
<ppisati_> it's a daylish :D
<ogra_> ogra@dragonboard:~$ snap list core
<ogra_> Name  Version                   Rev   Developer  Notes
<ogra_> core  16-2.28.1+git405.377ffd6  3074  canonical  core
<ogra_> my image got 3074
<ppisati_> uhm
<ppisati_> let me check if i flashed the correct img
<ogra_> very strange
<ogra_> note that my images get built in-house here ... i rarely downlooad them from people.c.c ... let me check, perhapsd the upload failed
<ppisati_> ogra_: i downloaded the one from
<ppisati_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ is mine
<ondra> ogra_ I will do fix and if somebody can test it
<ppisati_> let me check the img i flashed
<ppisati_> ogra_: indeed, i had an old .img laying around
<ppisati_> never mind
<ogra_> phew ... i was just comparing md5's :)
<apol_> now I'm getting "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
<apol_> is there a way to workaround this to test it runs to some extent?
<jdstrand> kyrofa: do you have a snap that demonstrates the issue?
<kyrofa> jdstrand, I do, although it's not in the store (it's someone else's) would a github link do?
<kyrofa> Ah, I can wormhole it to you if you like
<jdstrand> kyrofa: if it is easy enough to build, sure
<jdstrand> either way
<kyrofa> jdstrand, it's easy to build, but requires qt and whatnot so you'll probably want to do it in a container
 * sergiusens takes a lunch break
<sergiusens> nacc the problem with your interface idea is the underlying filesystem
<jdstrand> kyrofa: if it can snapcraft cleanbuild, that's fine
<sergiusens> but the 17.10 classic snap thread fixes should get you on track again
<kyrofa> jdstrand, here you go: https://github.com/kyrofa/client_theming , the update_snapcraft branch
<kyrofa> jdstrand, you need to cd into the linux/snap/ dir
<kyrofa> But then yeah, should build fine
<nacc> sergiusens: not sure I follow? I believe you, but I don't understand why the underlying filesystem type should matter?
<jdstrand> kyrofa: it's dying: Issues while validating snapcraft.yaml: Specified icon '../../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
<kyrofa> jdstrand, ah, sorry, run from just the linux dir
<elopio> sergiusens, kyrofa, kalikiana: so, let's hacktober https://community.ubuntu.com/t/hacktoberfest/278
<jdstrand> kyrofa: $ snapcraft cleanbuild
<jdstrand> Issues while validating snapcraft.yaml: Specified icon '../../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
<kyrofa> jdstrand, ah, fetch again and reset that branch
<kyrofa> jdstrand, or cd into snap and build from there. There were some misunderstandings
<kyrofa> elopio, excellent
<jdstrand> kyrofa: it seems to be getting farther now
<jdstrand> kyrofa: spoke too soon. trying in ./snap now
<jdstrand> $ snapcraft cleanbuild
<jdstrand> Issues while validating snapcraft.yaml: Specified icon '../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
<jdstrand> kyrofa: perhaps give me a working snap? :)
<kalikiana> elopio: Sweet!
<kyrofa> jdstrand, hahaha
<kyrofa> jdstrand, stupid nested directories...
<jdstrand> kyrofa: so, the previous failure was: subprocess.CalledProcessError: Command '['lxc', 'exec', 'local:snapcraft-slowly-first-gull', '--', 'sh', '-c', 'cd /root/build_nextcloud-client; snapcraft snap --output nextcloud-client_2.2.4+git_amd64.snap']' returned non-zero exit status 2.
<kyrofa> jdstrand, here you go: http://people.canonical.com/~kyrofa/nextcloud-client_2.2.4+git_amd64.snap
<jdstrand> kyrofa: thanks
<zyga-fedora> apol_: snap-confine does not have an apparmor profile loaded
<zyga-fedora> apol_: not sure which distribution yours is based upon
<sergiusens> nacc in non classic, core is your underlying filesystem
<kyrofa> What is stealing all my travis...
<nacc> sergiusens: right, i can see why confined is not feasible
<nacc> sergiusens: but for classic?
<zyga-fedora> jdstrand: replied/updated the NFS PR
<zyga-fedora> jdstrand: the only unanswered problem is the .real file, I wonder how to approach that one
 * kyrofa wants to go cancel all of kalikiana's hogging PRs
<sergiusens> nacc yeah, classic is just that, with enforcing libc and library loading from specific locations
<zyga-fedora> jdstrand: it feels like a rat's nest of problems
<sergiusens> kyrofa is there a way to cancel? if he is EOD, cancel and restart them before you EOD yourself
<kalikiana> kyrofa: Noooooo. This is all because of New York. We were incontinently productive
<kyrofa> sergiusens, well sure. I was kidding though, the tests are killing him :P
<kyrofa> Hahaha
<ogra_> incontinently ...
 * ogra_ hands out dispes to the snapcaft team
<ogra_> *diapers
<ogra_> *sigh*
 * ikey no longer wants nutella
<kyrofa> ogra_, it's not as funny when you can't type
<zyga-fedora> ikey: nutella is bad for you
<ogra_> kyrofa, yeah, i trash alll my jokes with my typing :/
 * sergiusens wonders where his suspend button went to in the latest ubuntu 17.10
<kyrofa> sergiusens, it's called the lid
<zyga-fedora> sergiusens: hold alt
<sergiusens> kyrofa it is not suspending :-/
<zyga-fedora> sergiusens: power turns to suspend
<sergiusens> latest update did something weird
<ikey> because discoverability. :P
<zyga-fedora> sergiusens: at least for gnome vanilla
<kyrofa> Maybe that's why. Ubuntu knows it's not possible :P
<sergiusens> lol, it's an x1 carbon, working just 2 days ago
<zyga-fedora> sergiusens: does it work if you do what I said?
<kyrofa> zyga-fedora, you know if you used e.g. lounge you wouldn't need a million different nicks, right?
<kalikiana> sergiusens: FYI still working a little bit, trying to get my PRs green, tho probably half an hour max
<sergiusens> zyga-fedora I don't know how to convert the power, I don't have the power, "you've got the power"
<ogra_> sergiusens, add water ...
<zyga-fedora> kyrofa: longue?
<kalikiana> Agathe Bauer?
<kyrofa> ogra_, yeah, it would probably sleep then
<ogra_> for a longish time
<zyga-fedora> sergiusens: ah, sorry, click on the power icon in top-right, the menu will show up
<sergiusens> zyga-fedora snap install thelounge --edge
<zyga-fedora> sergiusens: then you have a trio of icons in the popup
<sergiusens> will be in stable as soon as I have time to make setting up ssl easier
<zyga-fedora> sergiusens: settings, lock and power off
<zyga-fedora> sergiusens: if you hold alt the poweroff icon turns into suspend
<sergiusens> zyga-fedora wow, why, why, why?
<ogra_> so use friendly !
<ogra_> *user
<zyga-fedora> sergiusens: it's been like that for years in gnome 3
<zyga-fedora> sergiusens: I read about this being done maybe over 2 years ago in a blog
<zyga-fedora> sergiusens: I think the argument at the time was that mostly people just close the lid and this optimizes the UI but keeps the ability
<zyga-fedora> sergiusens: you are welcome ;)
<ogra_> it is like needing 10 clicks to switch to  a different wlan ... i'm sue they did a lot usability tests for that
<sergiusens> in any case, I would remov shutdown and tell people to use the power button as there is an actual physical button for it on any device :-/
<zyga-fedora> sergiusens: well
<zyga-fedora> sergiusens: it usually suspends
<zyga-fedora> (in windows)
<zyga-fedora> sergiusens: so ironically.... it makes sense
<sergiusens> the optimization should be the other way around...
<zyga-fedora> sergiusens: power doesn't poweroff since windows 10
<zyga-fedora> sergiusens: laptops suspend when you hit it
<sergiusens> yeah, my TV suspends on power pressing too, as does my phone ;-)
<sergiusens> the power button these days is relegated to turning the screen on and off (and some other innards) but not a cold power down :-)
<sergiusens> zyga-fedora I still appreciate the tip, given that for some strange reason the lid event may not be coming through or doing the right thing
<ppisati_> ogra_: FWIW, i can reconfirm the image is fine now
<ppisati_> though i still can't get the bluetooth ctrl to show up with a custom kernel snap
<ppisati_> :(
<zyga-fedora> I'll get a coffee
<zyga-fedora> sergiusens: so what happened to your surface?
<zyga-fedora> sergiusens: try running opensuse or fedora on your device for a few weeks
<zyga-fedora> sergiusens: I'd love to see broader support for snapcraft
<kyrofa> sergiusens, I can't add any lounge users
<kyrofa> Oh, sudo, duh
<sergiusens> zyga-fedora I started to get a feeling of disgust of running desktop linux
<sergiusens> zyga-fedora in the end, it seems good hardware support is all you need to like desktop linux ;-)
<sergiusens> also, touch is a waste, nothing really works and I took the change that my wife needs to run some windows specific apps that crossover doesn't really support well so I did a swap
<kyrofa> sergiusens, could you compare RAM usage to something like slack?
<jdstrand> kyrofa: are there any special instructions for triggering the denial with this snap?
 * zyga-fedora has a simple solution for the .real problem
<kyrofa> jdstrand, right, so: it needs to be configured to point at Nextcloud (e.g. you can install the nextcloud snap for a quick test, then use http://localhost in the initial wizard)
<jdstrand> kyrofa: this can all work in a vm?
<kyrofa> jdstrand, after you give it auth info, quit it. Then run it again, and it'll complain about not being able to access the keyring
<kyrofa> Yep
<sergiusens> kyrofa oh, adding users requires a configuration change, `thelounge.lounge config` should open it in an editor, but currently I don't add one into the snap
<sergiusens> kyrofa /var/snap/thelounge/current/home/config.js
<kyrofa> sergiusens, actually it didn't, it seems you default to private
<kyrofa> sergiusens, then `sudo thelounge.lounge add foo` worked
<sergiusens> oh great, and you added users from the cli?
<kyrofa> Yep
<kyrofa> Works wonderfully
<sergiusens> ah, great; yeah, cannot add users from the webui
<kyrofa> Just needs a little spit and polish and SSL
<kyrofa> sergiusens, that doesn't bother me. This is already a level beyond bouncers
<kyrofa> sergiusens, go configure ZNC, THEN complain :P
<sergiusens> I have, once and never again
<kyrofa> Yep, me too. If the one I have in canonistack dies, I'm done with them :P
<kyrofa> Hopefully it lasts long enough for me to switch over
<kyrofa> sergiusens, but yeah, have you noticed any resource usage issues with it? Slack kills me
<jdstrand> kyrofa: does the nextcloud snap need a lot of ram?
<kyrofa> jdstrand, I've not tried constraining it dramatically. It runs on the rpi3
<kyrofa> jdstrand, give it a gig or so, maybe?
<kyrofa> jdstrand, note that it'll claim port 80, so make sure that doesn't clash
<sergiusens> kyrofa totally unnoticeable
<kyrofa> sergiusens, excellent
<kyrofa> sergiusens, is there a reason you haven't moved it upstream?
<kyrofa> sergiusens, also, talk to me about SSL. What is your vision? Do you want it on ports 80/443 by default?
<kyrofa> Do you want a webserver in front?
 * kalikiana wrapping up for today - kyrofa, sergiusens  enjoy your day off, see you on Tuesday!
<kyrofa> kalikiana, alright man, have a good one
<jdstrand> kyrofa: I don't see any security denials. I do see that it isn't able to find a keychain. do you see denials?
<jdstrand> kyrofa: I did like you said: installed nexcloud, used firefox to set up the admin user. closed it. started the nextcloud client, logged in for first time (no denials), shut it down, started it again, no keychain. connected the interface, logged in, logged out, stopped/started, no keychain. no denials anywhere
<kyrofa> jdstrand, huh... no. But when it's not snapped, it uses it just fine
<kyrofa> jdstrand, I just tried in devmode and it doesn't work either. I don't know anything about the keyring stuff... is there something environmental about it?
<kyrofa> jdstrand, by the way, I didn't thank you for this: I tested it this morning on another app and it works great
<kyrofa> jdstrand, so thank you for that
<jdstrand> yw
<jdstrand> as for using it-- I don't know the qtstore bits. if I were to hazard a guess since it isn't working in devmode, I would guess a missing library or stage package. secret-service and kwallet are all dbus, so shouldn't have to do anything weird with paths
<kyrofa> Maybe something with the XDG spec done by the desktop helpers...
<kyrofa> jdstrand, from qtkeychain, this sounds fishy: "Linux/Unix: If running, GNOME Keyring is used, otherwise qtkeychain tries to use KWallet (via D-Bus), if available."
<kyrofa> jdstrand, that sounds like it only uses dbus for kwallet, and uses gnome-keyring somehow differently
<kyrofa> I'm taking a look at the code now
<jdstrand> qtkeychain* - I've not specifically used this. I wrote the interface for libsecret, gnome-keyring consumers and kwallet. looking at https://github.com/frankosterfeld/qtkeychain I see files for libsecret and gnome-keyring
<jdstrand> it would be weird for it to access the keyring files directly. I suspect that is just written weird
<zyga-fedora> jdstrand: I updated the NFS branch, not sure if you have time for a 2nd look today
<kyrofa> jdstrand, it seems that it's looking for a gnome-keyring.so
<zyga-fedora> jdstrand: I'll work on testing the mkdir-before-mount branch tomorrow, after that we may look at fixing the content interface as niemeyer has discussed at the rally
<kyrofa> jdstrand, which is not in the snap. Let me stage libgnome-keyring0 and see what happens
<zyga-fedora> jdstrand: I'll probably spend some time on a overlayfs experiment I was discussing
<zyga-fedora> jdstrand: I'll try to write my thoughts on the forum as well
<kyrofa> jdstrand, if I used libsecret though, does that support both gnome-keyring as well as kwallet?
<jdstrand> kyrofa: ah
<kyrofa> jdstrand, it's loading everything at runtime, which explains why nothing is supported: nothing is staged, and it doesn't make it into the ELF so snapcraft doesn't grab it either
<jdstrand> kyrofa: libsecret is a different dbus api. it is the modern one that freedesktop.org defined. gnome adopted it, some things in kde did
<jdstrand> kyrofa: I think your question is about what to stage. you should stage all of them
<zyga-fedora> for now I'll EOD - I need to put my laptop together
<jdstrand> zyga-fedora: I've not gotten to your other request yet, so will do that first and then see what happens
<kyrofa> jdstrand, indeed, this makes more sense now. If gnome-keyring.so is available, it supports gnome-keyring. If libsecret, it uses that. There is no .so for kwallet, so it uses dbus directly
<zyga-fedora> jdstrand: thank you for your time :) no need to rush anything tonight
<kyrofa> jdstrand, so sorry, this was not your problem to solve, but I appreciate the sanity checks :)
<zyga-fedora> https://twitter.com/zygoon/status/916000719949455363
<zyga-fedora> (I was working like that today)
<jdstrand> kyrofa: sounds fine. I've not used qtkeychain before, so I thought it was yak (yet another keyring :)
<kyrofa> jdstrand, success \o/
<zyga-fedora> ooooh
<zyga-fedora> darn
<zyga-fedora> http://www.omgubuntu.co.uk/2017/10/lenovo-unwraps-25th-anniversary-thinkpad
<zyga-fedora> distraction of the evening
<jdstrand> kyrofa: ok, cool
<sergiusens> kyrofa keep it simple, 443
<sergiusens> kyrofa one of the reasons I use 443 and a webclient for that matter is easy access when at coffee shops
<kyrofa> sergiusens, well, upon initial install there will be no cert
<sergiusens> kyrofa right, no cert -> 80, setup cert -> 443
<kyrofa> sergiusens, perfect
<sergiusens> options to config to a different port should be fine, bt that is all doable from config.js
<sergiusens> so I would keep it as human as possible
<kyrofa> sergiusens, yeah I like it. Should be easy
<sergiusens> kyrofa elopio so what is the deal with travis today?
<kyrofa> sergiusens, we're hammering it
<kyrofa> sergiusens, its network seems odd
<sergiusens> why? I don't see anything green :-)
<elopio> we can always run locally, if it's too much wait. The lxd setup makes sure that the results will be identical.
<kyrofa> Lies! https://github.com/snapcore/snapcraft/pull/1591
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<kyrofa> But yeah, everything is taking longer than it should
<kyrofa> nessita, is there a way to add someone as a collaborator to a snap that is registered but does not yet have any revisions?
<kyrofa> sergiusens, also, thelounge: are you intending on moving it upstream or to snapcrafters, or maintain it yourself?
<sergiusens> kyrofa upstream, as soon as all the niceties are in
<kyrofa> sergiusens, slight complication: Let's Encrypt can work in essentially one of two ways for us: webroot mode, where it just assumes its acme challenges are available, or standalone mode, where it runs its own server on port 80
<kyrofa> sergiusens, actually, nevermind. I think I worked out how to use standalone without needing to stop thelounge
<kyrofa> sergiusens, given that they ship the example.css by default, you might want to consider leaving it alone when moving upstream. Or was there something broken with it?
<sergiusens> kyrofa the other one is what is used in the demo server
<kyrofa> Huh. Wonder why THAT one isn't the default, then
<kyrofa> sergiusens, when you're able, can you take one last pass through https://github.com/CanonicalLtd/snappy-docs/pull/132 ? Should be good now
<mup> PR CanonicalLtd/snappy-docs#132: languages: add ROS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/132>
<mup> PR snapcraft#1592 closed: travis: run snapd tests only if not cron <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1592>
<sergiusens> elopio mind taking a final look at snapcraft#1554 ?
<mup> PR snapcraft#1554: store: handle revoked developers <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554>
<kyrofa> jdstrand, nowadays, if I chown root to root, will I get killed?
<mup> PR snapcraft#1569 closed: tests: refactor the fake snapd to not hardcode values <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1569>
<elopio> \o/
<elopio> thanks for the merge
<sergiusens> elopio hah, you are alive, do your reviews ;-)
<elopio> sergiusens: you have a +1 already
<sergiusens> ah, great!
<sergiusens> elopio mind checking kyrofa's stderr/stdout PR?
<elopio> the extra execution time is a disappointment there :( It kind of breaks my idea for the container tests.
<elopio> Hello cratliff ! How was the trip back home?
<kyrofa> elopio, I'm not convinced it's due to the test changes... everything seems to be slow today
<kyrofa> I had to re-run the plugin tests and they took half as much time
<elopio> kyrofa: can you give it a try locally with/without print?
<kyrofa> elopio, I can re-run the snapd tests on that PR and see if the tighten back up if you like
<cratliff> elopio, it was good.  I was pretty tired afterwards, but got some sleep later.  How was yours?
<kyrofa> cratliff, haha, join the club
<elopio> it was ok. It's good to be back home. There's a big storm and everything is terrible on the streets, but still it feels better than NY ð
<sergiusens> kyrofa about your scriptlet thing, it only adds a rule to copy over the launch file, is it assumed that the catkin_packages make their way to the snap with proper install rules already? If so, mind clarifying that?
<kyrofa> sergiusens, yeah in the case of our example, all the install rules are correct. There are no pre-baked examples that are broken
<kyrofa> sergiusens, so the addition of the install rule just copies over the top
<kyrofa> sergiusens, can you clarify what needs clarification? :P
<sergiusens> kyrofa the text text right before the example doesn't match the expectations of what I saw, mind amending the text to clarify that?
<kyrofa> Ah, okay
<sergiusens> kyrofa "the upstream ros application does not provide proper install rules" part of it
 * sergiusens begins the trek to aikido
<kyrofa> sergiusens, done. I made the example a bit more theoretical to avoid confusion
<kyrofa> lewciie, what are you doing here?
<lewciie> @kyrofa I'm always here! :)
<nothal> lewciie: No such command!
<kyrofa> Haha, I didn't know you guys actually used IRC
<lewciie> we do, we're everywhere!
<cratliff> elopia, is everything good at your house?  Not much damage or anything I hope.  Seeing some sun when getting home was nice.
<jdstrand> kyrofa: that is allowed if you don't specify '-1' as an argument
<jdstrand> kyrofa: -1 is something I'm working on
<kyrofa> jdstrand, alright, thanks!
<kyrofa> sergiusens, I'm a little nervous altering thelounge config when it's in a writable area. Do you intend for users to modify it (I assume so)? How should we deal with conflicts?
<kyrofa> I'm starting to think maybe we do want a webserver in front to handle the HTTPS stuff
<kyrofa> Then thelounge can just use a unix socket by default
<cholcombe> sergiusens: i love the new github integration!
<mup> PR snapd#3852 closed: hooks: commands for controlling own services from snapctl <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3852>
<cholcombe> looks like the rust plugin doesn't know how to use workspaces in cargo
<kyrofa> elopio, after all that work, the ros2 test that takes 15 minutes on my machine causes travis to run too long
<kyrofa> elopio, so we need another solution
<kyrofa> elopio, ideally I could say on the PR "this requires such and such long test to run" and CI would run it
<kyrofa> elopio, also, travis_wait sucks. It masks ALL output
<kyrofa> Runs everything in a subshell
#snappy 2017-10-06
<mup> Bug #1721676 opened: implement errno action logging in seccomp for strict mode with snaps  <Snappy:In Progress by tyhicks> <linux (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu
<mup> Xenial):In Progress by tyhicks> <linux (Ubuntu Zesty):In Progress by tyhicks> <linux (Ubuntu Artful):Fix Released by tyhicks> <https://launchpad.net/bugs/1721676>
<mup> PR snapcraft#1585 closed: lxd: pass SNAPCRAFT_PARTS_URI through into container <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1585>
<mup> PR snapd#4009 opened: tests: adding test for network-manager interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4009>
<mup> PR snapcraft#1593 opened: catkin tools plugin: add catkin tools support <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1593>
<zyga-fedora> o/
<zyga-fedora> tests are sad today
<zyga-fedora> travis has some issues
<kalikiana> o/
<zyga-fedora> hey kalikiana
<mup> PR snapcraft#1484 closed: lxd: configure user in container <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1484>
<mup> PR snapd#4010 opened: tests: do not use http://canihazip.com/ which appears to be down <Created by mvo5> <https://github.com/snapcore/snapd/pull/4010>
<ackk> hi, I'm getting these errors when running snapd tests in master: http://paste.ubuntu.com/25684549/
<ackk> they take a long time to run and eventually hang
<__chip__> ackk: you're needing some dependencies
<__chip__> ackk: what system are you running the tests on?
<__chip__> what distro i mean
<ackk> __chip__, yakkety
<__chip__> ackk: sudo apt build-dep ./
<ackk> __chip__, thanks
<__chip__> ackk: and ./run-checks might be more helpful than running go test by hand
<__chip__> ackk: OTOH running go test by hand you can add a "-timeout 15s" :-)
<__chip__> (go test's default timeout is 10 minutes i think?)
<__chip__> ackk: that unit test is failing because KB vs KiB -- means you're using a different version of chegggaa's progress bar lib, there (but run-checks should sort that out for you
<mup> PR snapd#4010 closed: tests: do not use http://canihazip.com/ which appears to be down <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4010>
<ackk> __chip__, thanks, running now
<__chip__> ackk: run-checks will set the right gopath, then use govendor to get the right libs in place, etc
<__chip__> via get-deps
<__chip__> ackk: also it'll run some static checks
<ackk> yeah, some shellcheck is failing here
<ackk> might be the different shellcheck version
<ackk> __chip__, do you guys run it on xenial usually?
<__chip__> ackk: your shellcheck is probably too old
<__chip__> ackk: yes, xenial, but with shellcheck from zesty at least
<__chip__> ackk: you can't just install the one from zesty, but you can rebuild the zesty one for yakkety)
<__chip__> ackk: or, you can remove it and it won't complain -- it'll only run shellcheck if available
<ackk> yeah I disabled the check
<ackk> tests are running now
<ackk> __chip__, passed! thanks
<__chip__> ackk: does the older shellcheck have a -V option?
<ackk> yes
<ackk> 0.4.4 fwiw
<__chip__> ackk: the deeper tests are run via spread, for which you'll need that and kvm
<__chip__> ackk: hey, i've got 0.4.4 and last i checked they passed
<__chip__> so maybe something snuck in
<__chip__> i'll take a look
<__chip__> ackk: 0.4.4 _should_ work (so i was wrong and it's the one from Y not Z that we use)
<__chip__> ackk: WRT the spread tests, https://github.com/snapcore/snapd/blob/master/HACKING.md#running-the-spread-tests
<__chip__> one thing it doesn't say is that that .spread directory is in from ~
<ackk> __chip__, http://paste.ubuntu.com/25684673/
<__chip__> gah
<__chip__> ok, i'll fix
<ackk> cheers
<ackk> cool, tests pass in my branch too now :)
<zyga-fedora> mvo: quiet day, how are you
<mvo> hey zyga-fedora
<mvo> zyga-fedora: I'm feeling a bit so-so, maybe getting a cold or something. looks quiet indeed
<ogra_> mvo, i saw you answered on the DHCP thread, did you get any info out of your tests ?
<mvo> ogra_: I can reproduce it reliable using a similar setup as the report but thats all I did so far. I
<mvo> ogra_: I bet its possible to reproduce with classic as well but I have not spend time on that
<mvo> ogra_: did you find anything out? it bothers me a great deal
<ogra_> yeah, i bet it is systemd-networkd and it simply isnt seen elsewhere because we only use it in core in xenial
<ogra_> mvo, not really, which is why i was hoping xnox could give some hints what to look for ...
<ogra_> (but he didnt like to :P )
<mvo> ogra_: right, it seems like hte issue is in a bit of a limbo
<xnox> ogra_, i've requested steps to reproduce, logs, and /run state - i got nothing back in return. Also my work pipeline is full of customer work, and if you have things to escalate to foundations, it should be done via salesforce as it is done for all the other customer work.
<xnox> ogra_, networkd is used on xenial on some cloud images in production
<xnox> but cloud images typically have stable/non-changing dhcp
<ogra_> xnox, well, customer or not ... it is an issue for eveyone (just that others dont use core in a way that triggers this bug)
<ogra_> i dont see why a serious bug is any different if a customer reports it, a bug is a bug is a bug ;)
<jamespage> o/
<jamespage> any chance on the track setup detailed under https://forum.snapcraft.io/t/track-request-for-openstack-projects/2377 for the gnocchi snap - I'm working on testing that atm and installing from the default track is awkward for my charm
<ogra_> 100% sure, but i think it needs three)
<ogra_> argh
<ogra_> jamespage, i think that needs a third +1 first (not 100% sure, but i think it needs three)
<jamespage> ogra_: ack - anyone around who can do a third +1 ?
<xnox> ogra_, sure a bug is a bug.... but i have 4 srus of systemd in progress, all of which fix critical bugs for $cloud $another_cloud $this_person $that_person =)
<xnox> ogra_, and this dhcp issue is incomplete, as i'm yet to receive "steps to reproduce, logs, /run state" as requested a few days back. Do you have that for me?
<ogra_> did you ask for that in the bug ?
<xnox> without that, there is nothing i, or anybody on my team, can do, to start picking that bug up
 * ogra_ checks 
<xnox> ogra_, i've asked that _from you_ when you first pinged me about it
<xnox> ogra_, and again mvo
<xnox> ogra_, harrasing customer around is not a good idea.
<ogra_> no, you asked me to please turn the forum thread into a bug report
<ogra_> which i asked the OP to do (and he did)
<xnox> ogra_, but then it somehow escalated with multiple people pinging me and my manager.
<xnox> ogra_, are you aware of the process for UA customers? and the use of salesforce?
<ogra_> xnox, well, NCuralli pinged here first but got no reaction
<ogra_> xnox, i dont care about customers if such a bug shows up, it is a serious issue no matter who was the original reporter
<ogra_> xnox, if it is a customer request i would expect it to go through the dedicated business coontacts ... but this is a generic bug in one of your products and was generically reported
<xnox> ogra_, i understand that. but my time is limited and it is prioritised within the work my team commits to fix.
<xnox> ogra_, we do not drop everything on the floor and fix your issue.
<ogra_> i dont expect that ...
<ogra_> but after being asked to turn it into a proper bug report a one line comment on the bug that it was recognized would have been nice ... completely independent from any processes just by common sense
<xnox> ogra_, for whatever reasons there were multiple people, managers and tams pressuring and pinging my manager to somehow escalate this particular issue
<xnox> ogra_, i'm concerned why that has happened. have you been talking to anybody about this particular issue? somehow it was artficially inflated.
<NCuralli> @ogra @xnox what could I make for you?
<nothal> NCuralli: No such command!
<NCuralli> ogra_  xnox what could I make for yours?
<ogra_> NCuralli, xnox wants "steps to reproduce, logs, and /run state" (quoting from above) ... but prhaps mvo can give that tooo since he can reproduce
<xnox> NCuralli, i am interested to see the journal and copies of /run/systemd/netif/ directory between all the leases are obtained/changed. as that directory has serialised state of lease files.
<xnox> NCuralli, comparing that, with logs, and server side leases logs - we can establish where things go wrong in terms of lease renewals and changes.
<mup> PR snapcraft#1554 closed: store: handle revoked developers <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554>
<NCuralli> ogra can mvo take care of xnox requests?
<NCuralli> ogra_ can mvo take care of xnox requests?
<NCuralli> ogra_ if mvo can not. I can take of xnox requests
<mvo> NCuralli, xnox let me check, I can provide most, I'm not sure about /run/systemd/netif iirc that was not showing up on my pi2 but let me double check (it did show up in my x86 vm)
<NCuralli> mvo if you need something ping me
<xnox> mvo, it should if you are using networkd, if the device is using networkmanager it would not.
<xnox> mvo, i don't know which devices are affected.
<ogra_> xnox, all
<ogra_> xnox, and by default core uses netplan with networkd only ... no other method preinstalled
<xnox> mvo, and for networkmanager case it matters if isc-dhcp is installed or not; as networkmanager can either use isc-dhclient or use networkd's dhcp lease.
<xnox> ogra_, that is not true =)))))) as i am aware of several core devices shipping with netowkrmanager backend
<xnox> of netplan
<ogra_> xnox, well, i'm tallking about all our referenced images
<ogra_> there are some customer setups using NM alongside, yes
<xnox> ogra_, i am talking about the particular bug in question, have you reproduced it on the reference images yet and can provide logs?
<ogra_> but they are custiom things ...
<ogra_> xnox, not me, but michael
<ogra_> xnox, and NCuralli too
<ogra_> (also the bug description is pretty clear "we use the default network stack based on networkd + netplan." )
<zyga-fedora> wooooooooooot
<zyga-fedora> man
<zyga-fedora> I'm  terrible
<zyga-fedora> :)
<zyga-fedora> but I fixed it
<__chip__> zyga-fedora: what did you woot fix?
<zyga-fedora> just small part of code I was working on
<zyga-fedora> it's working now
 * zyga-fedora -> lunch
<wdouglass> i'm trying to build a snap package using the snapcraft docker image under debian. When i run 'snapcraft', i get 404 not found for linux-libc-dev libdns-export, and libins-export. i've  tried doing 'apt-get update' in my docker container, what else should i try?
<ogra_> where do these requirements come from ? your snapcraft.yaml ?
<wdouglass> i guess python may need them? the package i'm building is a python program that uses the 'python2' build plugin
<ogra_> (the latter lib doesnt exist at all in ubuntu, libdns-export has a versioned package name ... )
<wdouglass> sorry, it's libdns-export162
<ogra_> linux-libc-dev should simply be there
<ogra_> and your docker container runs xenial ?
<ogra_> (16.04)
<wdouglass> yeah, snapcore/snapcraft, distributed by the snapcraft.io tutorial
 * ogra_ always only uses lxd ... so hard to tell whats wrong there ... theoretically it should work i guess 
<ogra_> kalikiana, ^^^ any idea ?
<wdouglass> hmmm. i guess i could try lxd, i'll bang my head against docker a bit more first
<kalikiana> wdouglass: does your container have ip4 networking? Somewhat random guess perhaps, but last week I was looking at an aws container that only had ip6 configured and some package downloads failed because of it
<wdouglass> oh that's interesting, i'll look into that
<__chip__> kyrofa: ping
<ppisati_> ogra_: i guess you don't rebuild the LK bootloader in the dragonboard gadget, i mean, you reuse the binaries shipped by linaro
<__chip__> kyrofa: I read something about you being saddened by having to use --prefix=/snap/yadda/current because it limited cross-distro portability -- but the snap you were talking about is strict, meaning that it doesn't
<__chip__> kyrofa: because a strict snap always sees itself installed under /snap/
<wdouglass> kalikiana: i needed to run apt update in my container, that was the problem. thanks to you and ogra_ for your help!
<ogra_> ppisati_, i think one of ondra's recent changes actually started building two lk's  (one for mmc and one for sd) from source
<ondra> ogra_ ppisati_ no lk is taken from code there, as we do not need to rebuild or modify
<ondra> ogra_ ppisati_ though I have somewhere code to build it from code as well if needed
<ondra> so if there is interest I can test it and push it as well
<ondra> ogra_ I did pull request with fix, since I got one extra dragoboard I could test on
<ogra_> ondra, cool, i'll try to get to it before EOD
<ppisati_> the patches to modify the bt address require a new property in the dtb, if that property is not present, the driver fails to initialize
<ondra> ppisati_ dtb is fine, that lives in kernel snap
<ppisati_> so, before i commit this stuff, i need a new LK bootloader, else i break the bt on the dragonboard
<ondra> ppisati_ there shouldn't be need to rebuild lk for that
<ondra> ppisati_ new lk for changed dtb?
<ppisati_> https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?h=release/LA.BR.1.2.7-03810-8x16.0&id=372982a4d4c4922e9214ff7d6aa5348aaba602a7
<ppisati_> yes, it requires this patch
<ppisati_> and they havent' built a release since this stuff was committed
<ondra> ppisati_ right
<ondra> ppisati_ so if needed we can update gadget and start building it
<ondra> ppisati_ shall I spin for you gadget with patch in the mean time?
<ogra_> ppisati_, just compile it yourself and dd the resulting binary to  part 7
<ogra_> (for testing at least)
<ogra_> lk lives in the "aboot" partition usually
<ppisati_> ogra_: testing is already done, what i'm saying is "do you want to rebuild the gadget snap with that patch, or shall we wait for linaro to do another release, you pick the binaries and then i commit my stuff?"
<ppisati_> ondra: ^
<kyrofa> __chip__, interesting, even on fedora?
<__chip__> kyrofa: _inside_ the snap, yes, everywhere
<__chip__> kyrofa: of course it's still not ideal because it would break on rename
<kyrofa> Indeed, but that's an improvement, certainly
<__chip__> kyrofa: (you can test this with 'snap run --shell snap.app' on a fedora vm
<__chip__> )
<__chip__> kyrofa: devmode snaps also
<__chip__> kyrofa: just classic is weird and different and terrible and sad
<kyrofa> __chip__, amen
<ondra> ppisati_ we can then just update with new version
<ondra> ppisati_ if you are inpatient, we can start building it from source
<ondra> ppisati_ up to you, I can prepare the change
<ogra_> ondra, well, there are customers that want to use BT with a proper MAC ... sho we should probably add the lk build to the gadget
<ogra_> but thats something for next week IMHO
<ogra_> ondra, thanks btw ... it didnt strike me that the magic number error was about the FIT format ...
<ppisati_> ogra_: k, no rush
<ppisati_> ondra: ^
<ondra> ogra_ yeah I missed that communication and when I was reading it today, I realised I only shared gadget snapd, but not kernel snap. So my bad
<ondra> ppisati_ ogra_ I'm sprinting next week, but if jet lag hits me I might as well prepare it :)
<ppisati_> ondra: np
<__chip__> mvo: dunno if you noticed but i pushed tests to the ansimeter pr
<__chip__> mvo: an' they're all green and lovely-like
<elopio> stgraber: is it possible now to use the lxd snap without sudo? Just the lxd group?
<stgraber> elopio: it is
 * elopio tries in a clean machine. It doesn't work on mine, but mine is always crazy.
<elopio> nessita or cprov or somebody: can you please remind me the URL with the docs for store api errors?
<kyrofa> zyga-fedora, snapd is out of date on arch. Any idea who I poke about that?
<kyrofa> Looks like it's been flagged, but it's considered an orphan package
<kyrofa> elopio, curious what you think about https://github.com/snapcore/snapcraft/pull/1583#issuecomment-334620307
<mup> PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583>
<zyga-fedora> kyrofa: hey
<zyga-fedora> kyrofa: we know, we are working on resolving this
<zyga-fedora> kyrofa: for now we are trying to get a person with commit access
<kyrofa> zyga-fedora, very good, thank you :)
 * __chip__ ~> EOW
<kalikiana> elopio: leaving now, will be idling later, feel free to ping  in case I'm needed
<mvo> Chipaca: I have not noticed, I was digging into this ipv4 problem
<cprov> elopio: https://dashboard.snapcraft.io/docs/
<elopio> thanks cprov
<wdouglass> hey, i'm trying to package a python program, which works fine on my machine. For some reason in my snap, it can't import numpy.core.multiarray
<wdouglass> i've got 'python-numpy' in my stage-packages list
<wdouglass> what else should I be looking at?
<nacc> wdouglass: is your app python2 or python3?
<wdouglass> python2
<nacc> wdouglass: snapcraft.yaml link?
<wdouglass> hold on...i'll paste it up
<wdouglass> https://pastebin.com/xuc9fZfb
<nacc> wdouglass: i would suggest dropping into your snap's shell (snap run --shell <app>) and then taking a look around
<nacc> wdouglass: specifically, at that point, run the interpreter and see what sys.path is pointing at
<nacc> wdouglass: and perhaps see if the numpy modules showed up
<wdouglass> sounds like a good idea! this is my first day using snappy... thanks for the direction!
<nacc> wdouglass: np, gl
<wdouglass> hmmm...python2 isn't installed. I thought it would be an automatic dependancy becuase 'python-version: python2', but apparrently not. there's the problem. thanks again nacc
<nacc> wdouglass: hrm, it's not in your snap at all? it might be in the core snap
<wdouglass> can't get to it from the shell....just python2
<wdouglass> i mean just python3
<nacc> wdouglass: that's odd (to me)
<wdouglass> yerp, adding python2.7 as a stage-package fixed it. thanks again
<nacc> wdouglass: interesting, that feels sort of like a bug
<wdouglass> yeah, seems like that should be in core
<nacc> wdouglass: or definitely already there if you installed with the python2 plugin
<nacc> wdouglass: is 'python' available?
<wdouglass> now that i added 'python2.7' as a stage-package it is, but not by default with the python2 plugin
<nacc> wdouglass: hrm ok
<zyga-fedora> jdstrand: hey
<zyga-fedora> jdstrand: I saw your feedback on 4008
<zyga-fedora> jdstrand: do you want me to freeze them for the update process then?
<zyga-fedora> jdstrand: or what else should we do?
<zyga-fedora> jdstrand: I'm trying to make a roadmap in landable chunks
<wdouglass> does stage-packages include dependancies?
<wdouglass> or do i have to list them all manually?
<kyrofa> wdouglass, dependencies of the stage-packages are included
<wdouglass> thanks kyrofa
<jdstrand> zyga-fedora: not in 4008. yes in the PR when you perform the mount
<mup> PR core#60 opened: Fix handling of secondary addresses <Created by mvo5> <https://github.com/snapcore/core/pull/60>
<mvo> ogra_, zyga-fedora (or anyone interessted). if you are still around I would appreciate a review for the above -^
<kyleN> I'm trying a build a pi3 image -  it fails with "error: cannot find snap "pi2-kernel": snap not found". This used to work on amd64 laptop and on pi3 itself. Now, neither. Is this a known issue, or has someting changed?
<kyleN> on pi3, "snap find pi2-kernel" does find it, but still image build fails with that message
<nacc> sergiusens: classic snap, that is calling gpg. gpg on Artful fails (possibly elsewhere) because it is linked against libreadline6, which may or may not exist on the host
<nacc> sergiusens: http://paste.ubuntu.com/25688146/
<nacc> sergiusens: i'm not sure if i need to somehow exec into the core snap so taht works, but someone is reporting affecting them from running within the classic snap
<nacc> kyrofa: --^ or is that nother case of, if on classic, i really need to build gpg as well?
<nacc> seems like a real pain that a classic snap can't rely on using anything from the core snap, if so
#snappy 2017-10-07
<mup> PR snapcraft#1594 opened: code style: remove the extra quotes in the dedent example <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1594>
<mup> PR snapcraft#1595 opened: tests: fix the skip of snapd integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1595>
<mup> PR core#60 closed: Fix handling of secondary addresses <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/60>
<mup> PR snapcraft#1596 opened: tests: move ruby demo test to snapd integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1596>
<mup> PR snapcraft#1594 closed: code style: remove the extra quotes in the dedent example <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1594>
<ekkis> I'm setting up to publish a snap but need to select a "developer namespace".  can anyone explain to me what this is?
<ekkis> I can, apparently, only set it once and I don't want to get it wrong
<ekkis> the docs state: "This namespace will represent you as a publisher in the Snap Store and you wonât be able to change it afterwards"
<ekkis> represent me? how?
<ekkis> I have an account name.  so can I have my account name the same as the namespace?
<kyrofa> ekkis, yes
<kyrofa> ekkis, your namespace will show up in `snap list` as the publisher of the snap
<zyga-solus> ekkis: right
<zyga-solus> ekkis: so essentially this is your publisher nickname
<zyga-solus> ekkis: if you say "my namespace is ekkis"
<ekkis> oh... I see.  it's because my "account" doesn't have an account name, like in most other systems
<zyga-solus> ekkis: then if someone "snap install thatfancyapp"
<zyga-solus> ekkis: then they will get it from "ekkis"
<zyga-solus> ekkis: I agree the word namespace is not clear here
<ekkis> so they don't have to run `snap install ekkis/thatfancyapp`?
<zyga-solus> ekkis: that's right
<zyga-solus> ekkis: users install snaps
<zyga-solus> ekkis: snaps have names
<zyga-solus> ekkis: and users search by name, not by developer IDs or similar things
<ekkis> thanks mate
<zyga-solus> my pleasure :)
<sergiusens> kyrofa is the time off getting too boring? :-P
<ekkis> I'm building my first
<kyrofa> sergiusens, haha, no, I just tend to idle here even when I'm not working and noticed a question :)
<zyga-solus> nothing like the feeling of building one's first snap :)
<ekkis> I can specify the `source` field as a url to a tarball.  can I also point it to a github repo?
<zyga-solus> ekkis: snaps give developers the power to publish to users
<zyga-solus> ekkis: yes
<ekkis> do I use the .git url?
<zyga-solus> ekkis: there are lots of possible schemes, sergiusens and kyrofa can tell you all about that
<ekkis> for example, for Einsteinium (which I'm trying to package), the Clone or Download button indicates: https://github.com/emc2foundation/einsteinium.git
<ekkis> can I use this url?
<kyrofa> ekkis, indeed you can
<sergiusens> zyga-solus does content interface work with classic snaps?
<ekkis> kyrofa++
<ekkis> suppose that my project has a bunch of dependencies.  the build doc indicates I should install them using apt-get.  how do I express these in the `parts:` section?
<ekkis> I presume these parts are snaps?
<ekkis> so I have to find the equivalent snaps? or?
<ekkis> which also begs the question, do I have to declare all the building tools?
<ekkis> most of the dependencies are developer-level
<ekkis> in other words there are dependence packages that don't need to be included in the snap
<kyrofa> ekkis, there are three keywords that will be of interest: build-packages, stage-packages, and build-snaps
<ekkis> oh... let me read up on those then
<kyrofa> build-packages are debs that are installed on the host (builder). Build tools might fit into this section
<kyrofa> stage-packages are debs that are fetched from the archive and unpacked into the snap
<kyrofa> build-snaps are snaps that are installed on the host (e.g. perhaps your build tools are snapped)
<ekkis> it's not part of the `parts` section I see
<kyrofa> ekkis, I'm not sure which docs you're reading
<kyrofa> Link?
<ekkis> I see in the different part of the docs it talks about these 3 keywords
<ekkis> so for example, the command `sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils` in the instructions requires I have all those tools for building
<ekkis> that means I have to find snaps of them correct?
<kyrofa> ekkis, no, those would be build-packages
<ekkis> so do I just declare `build-packages: build-essential libtool autotools-dev automake pkg-config libssl-dev libevent-dev bsdmainutils` ?
<kyrofa> Something like that. It needs to be a YAML list, but you have the right idea
<ekkis> ah.  ok
<ekkis> and Snapcraft knows to do an apt-get for each
<ekkis> and if snap is running on Fedora it will do a `yum install`? (or whatever it is now)
<kyrofa> ekkis, not yet, support for other distros in snapcraft is coming
<ekkis> ah, but at least theoreticallly
<ekkis> at present I'm only concerned with Ubuntu
<ekkis> I used to package stuff in RPM form for Redhat and later Fedora
<ekkis> so having a cross-distro packager is great!
<kyrofa> ekkis, note that, while Snapcraft currently only runs on Ubuntu, the snaps it produces should run everywhere
<ekkis> oh.  anywhere so long as `snap` is available on the platform
<kyrofa> ekkis, you got it
<kyrofa> ekkis, fedora has snapd, for example
<sergiusens> ekkis support for rpm distros is coming through dnf support, you can probably get more detailed information from Son_Goku on that aspect
 * Son_Goku waves
<sergiusens> kyrofa since you are here, mind quickly glancing at snapcraft#1597 ?
<mup> PR snapcraft#1597: pluginhandler: warn about migrated system libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1597>
<Son_Goku> ekkis: if you want to build RPM-based snaps, you can do it by hand right now
<Son_Goku> though it's a pain to do
<Son_Goku> kyrofa and kalikiana have been helping me with getting different aspects of Snapcraft running on Fedora
<mup> PR snapcraft#1597 opened: pluginhandler: warn about migrated system libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1597>
<ekkis> Son_Goku: I may want to.  I'm building my first snap so I'll stick to the Ubuntu variant but I may come back to you
<ekkis> Son_Goku: I was a redhat/fedora guy for a decade years ago
<Son_Goku> the main problem is describing the security stuff
<Son_Goku> otherwise, it's really easy
 * Son_Goku grumbles
<Son_Goku> crap Wi-Fi sucks
<ekkis> does it matter what I call parts? I think I only have one part so I could just call it `main`?
<ekkis> kyrofa: "A set of Ubuntu packages to be downloaded and unpacked to join the part before itâs built" -- what does "join" mean?
<ekkis> guys, I've looked through the docs but it's not at all clear to me where I actually run the commands to build my app
<ekkis> I need to run autogen, configure, make and make install
<ekkis> oh.... I can use `plugin: autotools`
<mup> PR snapcraft#1574 closed: Add Dotnet plugin and a sample snap for integration test <enhancement> <Created by rakeshsinghranchi> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1574>
<ekkis> so I just need to figure out how to configure the plugin
<zyga-solus> ekkis: part names don't matter
<ekkis> ok, cool
<zyga-solus> ekkis: snapcraft has nice built in help I think
<zyga-solus> including help for particular plugins
<ekkis> # snapcraft --help autotools?
<sergiusens> snapcraft help autotools
<zyga-solus> not quite I think, try snapcraft help and look from there
<zyga-solus> I think snapcraft help plugins or something like that talks about it but I don't remember
<zyga-solus> thank you sergiusens
<ekkis> the help is for commands to snapcraft
<ekkis> but I'm looking at the web for help.  the docs are not very clear
<sergiusens> ekkis https://docs.snapcraft.io/build-snaps/your-first-snap
<ekkis> yes, I'm reading through that doc
<sergiusens> my network is wonky, so I cannot verify what I am sending over your way ekkis but this might be useful https://tutorials.ubuntu.com/tutorial/create-your-first-snap
<buzz_> Hello
<Guest93864> Hello
<Guest93864> Anyone hoe
<Guest93864> Anyone home
#snappy 2017-10-08
<ekkis> I'm hoping for guidance on how to use the autotools plugin so I'm reading: https://docs.snapcraft.io/reference/plugins/autotools
<ekkis> but the page isn't clear at all and if I try to look at the examples the link is broken.  help?
<ekkis> ekkis@ubuntu:~/dev/einsteinium$ sudo snap install einsteinium_0.13_amd64.snap --dangerous
<ekkis> [sudo] password for ekkis:
<ekkis> error: cannot perform the following tasks:
<ekkis> - Mount snap "einsteinium" (unset) (snap "einsteinium" requires devmode or confinement override)
<ekkis> any thoughts? it's my first snap
<ekkis> it seemed to build ok but I can't install it
<ekkis> also, the guide I'm following specifies I should use --dangerous when installing because I haven't signed the snap.  but it doesn't say how to sign it
<nsg> It will be signed by the store then you upload it, I do not think self sign is possible yet because the store keys are embedded in the snapd binary.
<nsg> I guess it's built with devmode in snapcraft.yaml, try --devmode
<apol> anybody knows of a snap that is available for armhf that shows anything graphically? or how to find the supported snaps
<apol> any idea why could be this error message? "cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_zfI2PJ//lib/modules: No such file or directory"
<zyga-solus> apol: hey
<zyga-solus> apol: I know about the second problem
<zyga-solus> apol: does your distribution have /lib/modules?
<zyga-solus> apol: that error basically says that the mount failed because one of the two directories could not be found
<zyga-solus> apol: and the second one is created automatically so it must be the first one
<bshah> zyga-solus: is it "enough" to mkdir just that dir?
<zyga-solus> bshah: yes
<zyga-solus> bshah: but that is something snapd expects the distribution to provide
<bshah> zyga-solus: well, basically we (me and apol) are trying installation on plasma mobile and we have a ubuntu/neon based rootfs without any firmware and module or kernel package
<bshah> so it's kinda "expected" but unexpected
<zyga-solus> bshah: unexpected?
<bshah> I mean unexpected for snapd to not have /lib/modules
<zyga-solus> bshah: snapd needs a few things to exist, you can patch those out or make them optional, it's just been assumed, successfully, so far that those exit
<bshah> yeah... I understand :)
<zyga-solus> bshah: snapd doesn't ship /lib/modules, does your distro provide something like that?
<zyga-solus> I'm a bit busy trying to restore network to the rest of my family, feel free to ask me questions, I'll answer when I can see (~30 min)
<hombremaledicto> hi, i hope this is the right channel
<hombremaledicto> got a question: i've installed today the filebot snap
<hombremaledicto> i need to call a script with its cli tool
<hombremaledicto> but i've noticed the shebang thingy: #!/usr/bin/env filebot -script
<hombremaledicto> would this even work, then?
<apol> zyga-solus: no, it doesn't have /lib/modules
<zyga-solus> apol: then either patch cmd/snap-confine/mount-support.c
<zyga-solus> apol: or make that an optional thing and allow it to fail
<zyga-solus> (I mean patch it in both cases)
<zyga-solus> (just differently)
 * zyga-solus -> still afk
<apol> right
 * apol looks
<apol> mkdir /lib/modules works 8-)
<bshah> did it start? o_O
<apol> bshah: libreoffice did, kanagame crashed
<bshah> weeeh
<apol> tweeting...
<hombremaledicto> solved myself once able to connect to the server: it works, sorry for the dumb question :P
<apol> https://twitter.com/AleixPol/status/917070335366791169 :P
 * zyga-solus kind of solved stuff 
<zyga-solus> for now
<zyga-solus> oh, battery running low
<alex___> Hey, just a quick question. I just tried snapd and wanted to install PyCharm (as advertised on the main webpage). However when using "find" there was no pycharm. Is there another store I have to add?
<gsilvapt> alex___, I think this is what you're looking for: https://github.com/snapcrafters/pycharm-community
<alex___> gsilvapt, thanks, but this leads to error: cannot install "pycharm-community": snap not found
<gsilvapt> Hum, weird. Perhaps you need the upstream source because this may not be maintained anymore
<gsilvapt> Ah, got it. Use --edge, alex___
<alex___> gsilvapt, still no luck, snap info pycharm-professional tells me error: no valid snaps given
<gsilvapt> Hum, weird. Then the only option is to download upstream, build and install from local
<alex___> I see, just wanted to make sure I didn't do anything wrong, before uninstalling snap. Tank you
<gsilvapt> There must be something wrong. This repository has not suffered any changes since September so the guys should be active. In fact, there's a forum post with lots of love so there must be a reason for it not being found
<gsilvapt> anyway, I opened an issue page in their repo, alex___: https://github.com/snapcrafters/pycharm-community/issues/8
<gsilvapt> In case you want to keep track of this
<alex___> Wow, thanks! I will subscribe to the issue. Maybe they need more information
<gsilvapt> Maybe, not sure. Lets see what they reply ;)
#snappy 2018-10-01
<erio> hello
<sergiusens> erio: `source-branch` should do the trick
<sergiusens> joc: mind looking into https://travis-ci.org/snapcore/snapcraft/jobs/435246430#L1574 during your morning?
<erio> whoa
<erio> hey sergiusens
<erio> thanks
<erio> if you ever find time, I really really need help doing this snap https://github.com/ericoporto/ags-snap
<erio> I can't find a way to consistently build it on my computer vs on build.snapcraft.io
<erio> a ton of my adventure is reported here: https://forum.snapcraft.io/t/need-help-to-snapcraft-alsa/7647
<erio> and here: https://github.com/ericoporto/ags-snap/issues/4
<erio> the whole source of bugs is alsa
<erio> I couldn't figure out how to make parts being built to link and include each other in a way it works
<erio> I've been online trying to make this for 40h already, gotta sleep.
<cwayne> sergiusens: joc is off next week FYI
<mborzecki> morning
 * Son_Goku waves
<Son_Goku> I'm finally heading to sleep
<Son_Goku> mborzecki, I'm working on a rollback patch for snapd packaging in Fedora so that the SELinux policy compiles again on EL7
<mborzecki> Son_Goku: yay, thank you!
<mborzecki> Son_Goku: need any help?
<Son_Goku> at the moment I'm fine
<Son_Goku> just tired and sick
<Son_Goku> the confirmation that I can't get around the dumb issue with glibc-static is what made me give up on trying to workaround it while preserving hardening flags
<Son_Goku> mborzecki, could you also file a bug report about that against RHEL 7?
<mborzecki> Son_Goku: ok
<Son_Goku> mborzecki: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=glibc&version=7.5
<Son_Goku> feel free to CC me on the bug after you file it
<Son_Goku> that works by email address, so use my regular gmail address (it's the one I commit in snapd as)
<mborzecki> Son_Goku: on friday i ran into more issues, though with mounts this time, spent some time debugging it with zyga, 3.10x seems particularly picky about unmounting stuff
<Son_Goku> yeah, there's a lot of weird things going on there
<mborzecki> Son_Goku: sure, will do
<Son_Goku> it'd be ironic if things worked better on the kernel-alt variant for ppc64le and s390x simply because that's kernel 4.14
<mborzecki> oh
<Son_Goku> the two arches I can't test at all :P
<Son_Goku> RHEL 7 uses 3.10 kernel for the arches it launched with
<Son_Goku> but all the newer arches use a 4.14 kernel
<mborzecki> that'd be fun
<Son_Goku> yep
<Son_Goku> aarch64, s390x, ppc64le use 4.14 kernel now
<Son_Goku> x86_64 uses 3.10 kernel
<Son_Goku> s390x and ppc64le give you the choice of kernels
<mborzecki> Son_Goku: maybe i'll just open a PR with centos today to keep track of what's happening there
<Son_Goku> PR with centos?
<Son_Goku> how are you going to do that?
<Son_Goku> centos doesn't patch or change the sources from RHEL
<Son_Goku> if you have a patch to fix the issue, propose it and attach to the RHEL bug
<mborzecki> Son_Goku: i mean i'd open a PR to snapd with centos added to spread suite
<Son_Goku> ah
<Son_Goku> that's probably not a good idea right now, given how broken it is
<Son_Goku> but we do need spread images with centos+epel enabled
<Son_Goku> afaik, those don't currently exist
<mborzecki> Son_Goku: whcih packages from epel you're insterested in?
<Son_Goku> squashfuse
<Son_Goku> kyrofa maintains it in Fedora and EPEL
<mborzecki> mhm
<Son_Goku> also, golang is probably going to move to epel once it is dropped from RHEL
<mborzecki> Son_Goku: they're dropping golang?
<Son_Goku> RHEL is planning to replace the golang package with the go-toolset SCL, which provides golang SCLized
<Son_Goku> https://developers.redhat.com/blog/2017/10/31/getting-started-go-toolset/
<mborzecki> ah, so software collections basically?
<Son_Goku> yep
<Son_Goku> scls will be updated each year with the latest version of those stacks from stable Fedora
<Son_Goku> so that means golang 1.10 or 1.11 will show up
<Son_Goku> and once golang is out of RHEL, it can be reintroduced in EPEL
<Son_Goku> and kept up to date with Fedora, just as rust is
<mborzecki> mhm, makes sense
<mborzecki> amzn will then be affected too, unless they keep their go packages
<Son_Goku> Amazon is likely basing their go stack on Fedora
<mborzecki> (and update)
<Son_Goku> I believe their Rust packages are also derived from ours
<mborzecki> heh, mix & mash all the bits
<mborzecki> i guess whatever works for them and their customers :)
<Son_Goku> sure
<Son_Goku> most large EL users wind up using large portions of Fedora for their purposes anyway
<Son_Goku> EPEL is ridiculously popular :)
<mborzecki> Son_Goku: zyga mentioned some stats that were shown during flock
<Son_Goku> yeah
<mborzecki> Son_Goku: did you get an email from rhbz?
<mborzecki> Son_Goku: bug report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1634486
<Son_Goku> yep
<Son_Goku> yep, got it
<zyga> good morning
 * zyga is grumpy but happy 
<zyga> well
<zyga> happy because the day is nice, it's very cold but sunny
<zyga> grumpy because apple resellers suck
<zyga> hey mborzecki
<mborzecki> zyga: they didn't replace the mbp?
<zyga> well, it's more than that
<zyga> first of all, I don't have it yet
<zyga> they don't respond to email
<zyga> I guy in another ispot said that apple NACKed the DOA claim because it was more than 5 days after purchase
<mborzecki> but the laptop was paid for already?
<zyga> and the service NACK the nack and ... nothing
<zyga> yes
<zyga> so nobody wants to fix it
<zyga> and nobody bothered to tell me
<zyga> I'll go there today for a refund or a new unit
<zyga> it's just %@!#!@ that I have to bother
<mborzecki> and you didn't get it back?
<zyga> no, it's still "in service"
<zyga> because they don't know what to do with it
<mborzecki> daamn
<zyga> yeah
<mborzecki> customer service
<zyga> anyway, I'll know more later
<zyga> real apple service is better
<zyga> it's just reseller adding the complexity that suck
<zyga> and real apple service told me to contact them if this fails
<zyga> really, the only thing missing is proper apple store somewhere in .pl
<zyga> because reseller quality varies
<zyga> and is not that controlled
<zyga> oh
<zyga> and the "service" broke the LCD
<zyga> so...
<zyga> I'm very very grumpy
<zyga> do they even train their staff?
<zyga> (where service is reseller-service)
<zyga> not apple
<zyga> hmm
<zyga> odd
<zyga> I have a shellcheck failure
<zyga> on _one_ system only (18.04)
<zyga> as if shellcheck was updated there now
<zyga> ah wait, that's not the case
<zyga> it's just confusing output of shellcheker
<zyga> mborzecki: the spellchecking script for yaml should really not spam about 1000s of things it doesn't consider as fatal errors
<zyga> how am I supposed to find the one it complained about?
<mborzecki> spread-shellcheck <file>
<zyga> no, from the log
<mborzecki> ther's a summary at the end
<zyga> I know I can re-run the experiment and see
<zyga> ERROR:root:validation failed for the following non-whitelisted files:
<zyga>  - tests/main/layout-symlink-bind-revert/task.yaml
<mborzecki> yup, there you go
<zyga> but the actual error is buried in that full log
<zyga> well, I know that's the only file I added
<mborzecki> well, that's because we have'nt landed everything yet
<zyga> I'm arguing that it should not show the other output at all in this mode
<zyga> it's just noise
<mborzecki> what reminds me i should probably revisit that branch again now
<zyga> yeah, perhaps we can just land it all quickly
<pstolowski> mornings
<zyga> hey pawel
<zyga> hmmm
<zyga> syscall.Unlinkat has different signature than what the kernel claims
<zyga> there's no flags :/
<mup> PR snapd#5884 closed: overlord/snapshotstate: store the SnapID in snapshot, block restore if changed <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5884>
<zyga> I sent a PR with a test in it, I'm working on fixing the issues but if anyone wants to read it and merge it please be my guest https://github.com/snapcore/snapd/pull/5883
<mup> PR #5883: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5883>
<mvo> pedronis: good morning! it looks like 5878 is good to go except for the one "NoStore" test that jamie asked for(?)
<mvo> pedronis: we can do that test in a followup if you prefer it this way btw (to avoid another spread-wait-for-green cycle)
<zyga> I'd say I'm freezing but it's not quite sub-zero yet
<zyga> but it's not warm anymore either
<pedronis> mvo: he asked some other things if possible, I'll look a bit and decide whether to them there or follow up
<mvo> pedronis: thanks
<Chipaca> mo'in
<pedronis> mvo: seems he was explicit about wanting the test before merging, otoh the other stuff is problaby later follow up material, it will touch preexisting tests
<mvo> pedronis: ok
<pedronis> (more comments, remove vestigial code, maybe rename CheckInterfaces)
<pedronis> mvo: pushed, thanks for the review btw
<mup> PR snapd#5892 opened: tests: shellchecks part 9 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5892>
<mvo> mborzecki: nice, thanks for more shellcheck fixes
<niemeyer> Morning all
 * zyga fires spread and goes to warm up with tea
<zyga> hey everyone new :)
<mvo> hey niemeyer , good morning
<mup> PR snapd#5878 closed: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5878>
<mborzecki> how do you remove apparmor profile withouth a file?
<zyga> ?
<zyga> ah
<zyga> heh
<zyga> I understand your question
<zyga> you cannot
<pedronis> niemeyer: hi
<zyga> because a profile "file" is just a definition of arbitrarily named actual profiles
<zyga> you can remove those if you know their name
<zyga> but the "customary" way of doing that is to parse the profile again and remove the actual profiles from the kernel based on the parsed data
<pedronis> mborzecki: I went grepping around, it seems indeed we have cover the SnapID usages that were problematic already,  and aliases code seems to use local snap names already, so it looks like it should work but test would be useful
<zyga> to remove an actual profile you just write its name to a special file in sysfs
<mborzecki> pedronis: thanks, i'll write a test for aliases nontheless
<pedronis> mborzecki: yea, we need a test about installing a 2nd version of a snap with auto-aliases and what happens with install, install --unaliases, and then prefer
<mborzecki> pedronis: agreed
<zyga> mborzecki: what prompted this?
<mborzecki> zyga: apparmor package landed in community, so i rebooted with appamor enabled and some profiles were loaded, but aa-status output could not account for all of them, so i went fishing, and for instane when i removed a snap i saw a profile getting loaded, but once remove was done the profile was still there (?)
<zyga> oh?
<zyga> maybe we have a bug
<mborzecki> zyga: idk, still looking, that's why i wanted to remove all the snap.* profiles that are there but should not be :)
<zyga> mborzecki: go to sysfs
<zyga> then to apparmor part of that
<zyga> there's a bunch of dot files there
<zyga> you can enumerate profiles
<zyga> and remove them as I explained
<mborzecki> mhm, trying
<zyga> mborzecki: perhaps we remove the file before removing the profiles from the kernel?
<zyga> mborzecki: on top of that we must see the old text in them
<zyga> mborzecki: before they are changed
<zyga> mborzecki: youck
<zyga> mborzecki: if this is the case we need to change some things to make that possible
<zyga> mborzecki: I'll wrap this up and we can talk
<mvo> niemeyer: when you have a moment (not urgent) could you please add "github.com/snapcore/pi-gadget" to the things that mup watches?
<niemeyer> mvo: Of course, will do
<mvo> ta
<pedronis> niemeyer: it would be good if could review #5882 (it has a +1 from jamie already)
<mup> PR #5882: many:  support and consider store friendly-stores when checking device scope constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5882>
<niemeyer> pedronis: Sweet, thank you
<pstolowski> if anyone has external usb camera - https://forum.snapcraft.io/t/have-a-pluggable-usb-camera-help-me-collect-some-data/7654
<zyga> yay, the leftover placeholders are gone now
<zyga> now just to patch the affected unit tests
<zyga> pstolowski: actually, any internal camera should be fine
<zyga> they are usually attached via usb, no?
<zyga> pstolowski: as such they go though the entire hot plug event system
<pstolowski> zyga: how can i see remove event for it? in any case, i'd like samples anyway, i'd like to see vendor/products/serials and other attrs
<zyga> pstolowski: unplug it
<pstolowski> zyga: ah, indeed, udevadm trigger -c remove /dev/video0, nice, thank you
<pstolowski> zyga: anyway... i'm interested in more smaples.. i see an anomaly with lime sdr, wonder if it happens to other devices
 * zyga nods
<pstolowski> devices i tried so far report a wealth of attributes when removed - including serial numbers - basically mirroring what i get when i plug them. but lime sdr for some reason only reports a subset when removed, in particular serial number is not reported even though it is present on 'add'
<zyga> pstolowski: interesting
<zyga> perhaps proprietary udev thing like Nvidia?
<pstolowski> yep..
<pstolowski> zyga: don't know about nvidia, can you tell me more?
<zyga> pstolowski: yeah, it's not registered in udev
<zyga> pstolowski: because GPL symbols and what not, I don't recall the details
<zyga> pstolowski: but presumably because it doesn't register in sysfs
<pstolowski> zyga: ack. it's weird, on remove i'm getting vendor and product names from udev db, just not serial... as long as device is plugged udevadm info reports all the nice data, i really don't get the logic behind this
<zyga> pstolowski:  look at /run
<zyga> see if the serial is written there
<zyga> remove can only report what is there
<zyga> and what the kernel says
<pstolowski> https://www.irccloud.com/pastebin/WeQxnDRO/
<pstolowski> appears to be there
<pstolowski> zyga: ^
<zyga> hmmm :D
<zyga> then yeah, now I'd jump at udev
<zyga> as in, read the source
<pstolowski> :)
<mup> PR snapd#5893 opened: interfaces/apparmor: report apparmor support level and policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5893>
<mborzecki> zyga: ^^
<zyga> reading
<niemeyer> pstolowski: Reviewed #5759.. the key is a bit too simplistic atm.. we'll need to get something slightly better there
<mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<zyga> brb
<pstolowski> niemeyer: thanks. yes, the second part of your comment (versioning) crossed my mind at some point
<niemeyer> pstolowski: Yeah, this is a real issue.. without something along those lines we cannot ever improve on the keying logic
<pstolowski> niemeyer: yep, that's valid concern indeed.
<niemeyer> pstolowski: #5782 reviewed too, with two suggestions
<mup> PR #5782: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5782>
<zyga> re
<mborzecki> zyga: https://paste.ubuntu.com/p/D6Fz5Fw3pb/ yeah, so the files are removed early, then apparmor_parser --remove has nothing to remove, but does not error out (?)
<zyga> uh
<zyga> I think it'd be nice if we remembered (in the state perhaps?) what was set up
<zyga> the name of the actual profiles
<pstolowski> niemeyer: by the way, a (random) remark about these keys: they are not "global" across interfaces, they are grouped by interface type at higher level of hotplug logic, so they need to be unique only within given interface; so, say key "1234" of "serial-port" interface might be different than "1234" of "camera" interface. this doesn't change any aspect of what you commented on, just mentioning becuase it's not apparent from
<pstolowski> that PR
<zyga> in either case we must have visibility into profile names
<niemeyer> pstolowski: That's awkward
<pstolowski> niemeyer: i can explain
<niemeyer> pstolowski: At least it's the initial gut feeling
<pstolowski> niemeyer: that goes back to what we discussed about the ability for any interface to provide own HotplugDeviceKey method
<zyga> mborzecki: we can ask apparmor_parser for the names stored in a file
<niemeyer> pstolowski: I can understand the key generation being unique, but seems suspect to have the storage of those keys being done at the interface level
<zyga> mborzecki: apparmor_parser --names <fname>
<zyga> mborzecki: the question is how to sequence that into the current framework
<niemeyer> pstolowski: Or do you mean the keys are still centrally managed, but that the central map includes the type as part of the key?
<niemeyer> pstolowski: That would be nice
<mborzecki> zyga: heh, i'm looking what we have avaialbe in the handlers, and it's only snapsup :/
<zyga> mborzecki: can you expand on that idea, what were you hoping to find?
<mborzecki> zyga: checking if there's snap.Info avaialble anywhere near there
<zyga> mborzecki: and then?
<pstolowski> niemeyer: no, storage is not done at interface level. hotplug machinery uses either the device key computed by the method from my PR, or - if interface has own method - it takes interface-calculated key string instead. and yes, that's centrally managed, basically interface type name becomes part of the internal map as well.
<niemeyer> pstolowski: I still don't quite understand the picture.. it says storage is done at interface level, but then it says that it's centrally managed
<niemeyer> pstolowski: What is done at the interface level, and how is it centrally managed then?
<mborzecki> zyga: then you have apps, so you know the file names, security tags etc. but that's not really helping this particular case
<mborzecki> zyga: how does it work on ubuntu when profile files are removed?
<zyga> one sec
<niemeyer> pstolowski: I do understand that the key is created by the interface, per our agreements.. that's sensible
<zyga> mborzecki: you mean as in regular packages?
<pstolowski> niemeyer: interface can implement HotplugDeviceKey method which returns a string representing a key, made of attributes od the device event, that's all. the returned key string is then used by hotplug machinery in internal maps, but interface type name is used together with the key
<zyga> mborzecki: that's a good question, I _think_ it's handled by apparmor debhelper things
<zyga> mborzecki: and because those files are shipped in /etc they are confffiles
<zyga> mborzecki: so probably not removed until you purge
<zyga> mborzecki: so perhaps that's how it works
<zyga> or just nobody noticed if the profiles stay in the kernel after removal
<niemeyer> pstolowski: Aha, okay.. sorry for not getting it. That's great.
<mborzecki> zyga: and how about snaps? the code clearlyl removes profile files before attemptint to call apparmor_parser --remove
<zyga> mborzecki: well, it clearly does not work
<mborzecki> :P
<zyga> it's just that the fact that the profile are in the kernel is not immediately obvious or problematic
<zyga> so nothing was reporting any issues
<pstolowski> niemeyer: thinking about your comment re devicekey, i wonder if it shouldn't become a proper object, rather than a loose string
<niemeyer> pstolowski: If we use a digest, we might just prepend a "0" to the output so we know that's version zero.. this allows us to evolve the logic of keying later so we take into account current keys
<mborzecki> ll
<niemeyer> pstolowski: I'd try to keep it simple while we can
<pstolowski> niemeyer: okay
<pstolowski> niemeyer: btw, lime sdr has an annoying quirk that i discussed earlier this morning ^
<pstolowski> niemeyer: well, it can be udev quirk
<mup> PR snapd#5877 closed: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5877>
<mvo> reviews for https://github.com/snapcore/pi-gadget/pulls would be great, should be pretty trivial
<zyga> mvo: done
<mvo> zyga: \o/
 * zyga runs some more spread tests before proposing another fix
<diddledan> netplan is passÃ©? https://www.phoronix.com/scan.php?page=news_item&px=nettools-new-linux-network
<zyga> diddledan: https://github.com/c-util/c-list/blob/dda36d30c7d655b4d61358519168fa7ce0e9dae9/src/c-list.h
<zyga> I feel happy now
<zyga> it's not just me ;-)
<zyga> (it's referenced from n-dhcp-...)
 * zyga returns to spread
<mup> PR snapd#5889 closed: make run-checks --static pass again w/shellcheck installed <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5889>
<Chipaca> mvo: if you want to see the stages in operation, https://travis-ci.org/snapcore/snapd/builds/435555961 is on
<mborzecki> Chipaca: nice
<sergiusens> cwayne: anyone who can cover for that thing that broke on plainbox?
<Chipaca> mborzecki: my comment to mvo, or my comment to you about journalctl -o json?
<Chipaca> mborzecki: either way, thanks :-)
<mborzecki> Chipaca: hah, the stages
<Chipaca> mborzecki: stealing ideas (and tests!) from snapcraft
<mborzecki> mhm
<Chipaca> mborzecki: just don't tell sergiusens or his head'll grow
<Chipaca> (let's call it "cross-pollination", as snapcraft is also picking up some ideas from our test suite)
<sergiusens> Chipaca: hah.
<diddledan> Sergio, Sergio, he's our man, if he can't be bothered, Kyle can :-p
<diddledan> msdos 2.0 is on github: https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-MS-DOS-GitHub
<diddledan> PRs welcome?
<Chipaca> diddledan: licensing is unclear tho
<diddledan> yeah
<Chipaca> also we already have a dosbox part, right?
<Chipaca> right?
<diddledan> according to the repo LICENSE.md file it's MIT now...
<diddledan> ref: https://github.com/Microsoft/MS-DOS/blob/master/LICENSE.md
<Chipaca> diddledan: https://github.com/Microsoft/MS-DOS/issues/2
<mborzecki> pedronis: quick question, i've installed test-snapd-auto-aliases_foo, now when doing snap install --unaliased test-snapd-auto-aliases_1.snap it fails complaining it cannot enable automatic aliases for test-snapd-auto-aliases because those are already enabled for _foo, but i passed --unaliased, so i'd expect it to install the snap nonetheless
<diddledan> oic
<pedronis> mborzecki: ok, sounds like there is something to fix then
<mborzecki> pedronis: after a quick look, checking for conflicts with enabled aliases does not look at the --unaliased of the snap being installed, but checks AutoAliasDisabled of snaps that are already present
<pedronis> mborzecki: that sounds strange
<pedronis> can't be the full picture
<mborzecki> pedronis: yeah, i'm more than likely to miss something, anyways, need to dig into the code
<Nafallo> hiya! :-)
<mup> PR snapd#5782 closed: ifacestate: helpers for generating slot names for hotplug <Hotplug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5782>
<Nafallo> I noticed a bunch of three loop mounts in nautilus this morning, which turned out to be lxd snaps. a bit more investigation and it turned out to be loop mounts where the backend file had been removed. looks like the loops didn't get teared down during the refresh or something?
<Nafallo> I had to reboot just now, which obviously removed the issue :-/
<Nafallo> there might be something in logs though, if anyone feel up for a debugging session...
<pedronis> mborzecki: afaict   unaliased set snapst.AutoAliasDisabled of the being installed snap to false and then checks the conflicts
<pedronis> considering that value
<popey> pstolowski|lunch: how many reports about webcams are you after? We can post on the snapcraft socials, drawing people into that post
<popey> pstolowski|lunch: given it's a really easy way for people to contribute, might be nice to promote?
<pstolowski|lunch> popey: just a few is really all i need for now, but thanks for asking!
<popey> no worries
<ogra> Nafallo, they go away after a reboot, i told stgraber about it a while ago
<ogra> (i think i had three lxd updates since my last reboot ... they pile up in the launcher :) )
<mborzecki> off to pick up the kids
<Nafallo> ogra: so a known one. excellent :-)
<ogra> well, i didnt file a bug iirc
<Nafallo> ogra: gogogog ;-)
<diddledan> audacity 2.3.0 just went to the stable channel
<popey> woooo
<popey> diddledan: shame the version string is a bit verbose
<diddledan> yeah, that's because I didn't trim the git tag - I wanted to use a portable script that any repo can use
<diddledan> note the `$SNAPCRAFT_PROJECT_NAME` to allow it to work on any project https://www.irccloud.com/pastebin/nvi3aI7B/
<diddledan> I don't like the comment wording though. it confuses me. I stole the script from wormhole
<popey> hm, just looks a bit nasty having the version number in the snap info
<popey> (the name in the version number obv)
<diddledan> surely we want the version number :-p it's the name we don't want :-p
<diddledan> yeah that â
<ogra> hmm, i have some very weird behavious of a configure hook
<ogra> #! /bin/sh
<ogra> set -e
<ogra> IP="$(snapctl get serverip)"
<ogra> [ -n "$IP" ] && echo "setting Server IP to $IP"
<ogra> thats all thats in there ...
<ogra> it automatically rolls back my snap when i try to install it
<ogra> is snapctl automatically exiting 1 when there is no value set ?
<ogra> (so that the set -e kills the hook )
<diddledan> ogra: does snapctl require the snap name?
<ogra> shouoldnt when used inside a hook
<diddledan> ok
<ogra> fun fact .... it uploads an oops to errors.ubuntu.com with completely useless content
<ijohnson> ogra: I've had it where the snapctl symlink isn't set up and so my configure script killed the install because it couldn't find snapctl
<diddledan> that'll annoy someone trying to triage :-D
<Chipaca> ogra: I love that you're using these things in ways we haven't tested
<ijohnson> ogra: Did you by chance disable re-exec?
<Chipaca> ogra: I hate that your testing is not producing bugs we can action
<ogra> ijohnson, i'm running in a core vm
<ijohnson> ogra: okay nvm not the same issue I ran into then
<ogra> Chipaca, https://errors.ubuntu.com/oops/b35c50a6-c576-11e8-92cf-fa163ee63de6
<ogra> run-hook: Error
<ogra> ERROR run hook "configure": exit status 1
<ogra> not sure what i should report as bug here ...
<mvo> ogra: did you had a reply? I did not read all backlog but for me:[ -n "$IP" ] && echo "setting Server IP to $IP" ; echo $?
<mvo> 1
<mvo>  
 * ogra removes set -e from the script 
<mvo> ogra: i.e. if $IP is empty the script will fail
<mvo> ogra: instead of removing set -e just put it inside an if condition
<ogra> oh
<mvo> ogra: if [ -n "$IP]; then echo...
<ogra> well
<ogra> or changing && to ||
<diddledan> good catch mvo
<ogra> yeah, thanks !
<diddledan> if the test fails then the return code will be 1 so the whole script will die
<mvo> ogra: your choice, I personally find the "if .." easier to read but then I don't do much shell (if I can help it ;)
<ogra> sad is that the oops is really useless in this case
<mvo> diddledan: thank you
<mvo> ogra: yeah
<diddledan> you can either replace with an `if [ -n` or do `[ -n .. ] && foo || bar`
<ogra> right
<diddledan> oh, or `[ -z .. ] || foo`
<ogra> actually i dont even need that line at all
<ogra> was just for debugging
<diddledan> haha
<diddledan> debugging breaks the script
<ogra> (in fact i wouldnt even need a hook if i could just call snap set without one ... )
<diddledan> I like those
<ogra> but snap set checks first if a configure hook exist
<diddledan> it does?
<ogra> i dont realyl use the hook but use the value in a startup script ...
<ogra> so the hook in itself is totally pointless cruft here
<diddledan> I thought it would just add the config and then exit if there's no configure hook
<ogra> (startup wrappers can directly call snapctl get ... so if you dont write a config file but read it directly a hook is moot)
<diddledan> that was my theory, too
<ogra> ogra@localhost:~$ snap set dashkiosk-browser serverip=192.168.2.70
<ogra> error: cannot perform the following tasks:
<ogra> - Run configure hook of "dashkiosk-browser" snap (snap "dashkiosk-browser" has no "configure" hook)
<ogra> so you need an empty hook script and it works
<diddledan> well fooey
<diddledan> I call shenanigans!
<Chipaca> diddledan: touch configure; chmod +x configure
<ogra> ogra@localhost:~$ cat chromium.launcher
<ogra> #! /bin/sh
<ogra> # get the IP from setting
<ogra> IP="$(snapctl get serverip)"
<ogra> ...
<Chipaca> literally an empty configure script
<Chipaca> (I don't think we support that inside a strictly confined snap, sadly -- the empty executable being true is cool)
<mup> PR snapd#5892 closed: tests: shellchecks part 9 <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5892>
<mup> PR snapd#5894 opened: many: enable AppArmor on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5894>
<mborzecki> pedronis: fun fact, we're not even sending --unaliased when installing from file
<Chipaca> mvo: a silly question for you sir
<pedronis> mborzecki: I'm not surprised, is a bit of a corner case, and we didn't think about it
<Chipaca> mvo: in https://travis-ci.org/snapcore/snapd/jobs/435622042 if you expand the "build-dep" install step, there's a lot of progress noise despite me saying --quiet
<pedronis> mborzecki: I would be more suprised if it was done half-way
<mborzecki> pedronis: i'll at it along with some tests, need this workaround for spread tests
<Chipaca> mvo: how do I tell it --no-really-i-dont-want-progress-bars?
<mvo> Chipaca: I believe so but let me look, its been a while since I did that feature
<Chipaca> mvo: :-D
<mvo> Chipaca: try "apt install -o Dpkg::Progress-Fancy=false  ...." (or apt-get will also turn this off)
<Chipaca> mvo: ta
<cachio> zyga, hey, https://forum.snapcraft.io/t/error-removing-snaps-after-refresh-core-snap/7632
<cachio> zyga, could be related to namespaces?
<zyga> on the phone
<Chipaca> cachio: that test that's failing on core, how do you know the thing has rebooted?
<cachio> we call revert
<cachio> then it waits until ssh is not available
<cachio> and then tries to connect
<cachio> Chipaca, the core is reverted
<cachio> Chipaca, but I am not explicity chacking the reboot was done
<cachio> I could add an extra ckeck
<Chipaca> cachio: maybe I'm misunderstanding something, let me dig a bit more first
<zyga> cachio: what were you expecting to see?
<zyga> (still on the phone)
<Chipaca> hmm
<Chipaca> The contributor stolowski@gmail.com has not signed the CLA.
<Chipaca> hmm
<zyga> blasphemy ;-)
<Chipaca> I'll change the checker to also check the canonical group
<Chipaca> right now it just checks for canonical email
<cachio> zyga, well, it should not fail to remove the snap
<pedronis> mvo: sorry for the slight FUD in the standup, I'm also worried that of the current processes (that we want to replace) assume that seed is writable
<mvo> pedronis: no worries, it was good feedback. I will write down what we would have to do but I think gustavo is right, we can always add it later
<zyga> - Stop snap âlxdâ services ([start snap.lxd.daemon.service] failed with exit status 5: Failed to start snap.lxd.daemon.service: Unit snap.lxd.daemon.service not found.
<zyga> cachio: ^ this is unexpected, is it stopping or starting, the error message is inconclusive
<cachio> zyga, well, it should be stopping because it fails when we do "snap remove lxd"
<cachio> zyga, but in the errror tries to start it
<cachio> zyga, it is also happening with other snaps, not just lxd
<mup> PR snapd#5895 opened: client, daemon: support passing of 'unaliased' option when installing from local files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5895>
<mborzecki> pedronis: the client/daemon part ^^
<niemeyer> mvo: Had a conversation with Bret
<mvo> niemeyer: nice, what is the outcome?
<niemeyer> mvo: We may end up going with something in between.. splitting up the kernels based on visibility and using tracks within those
<niemeyer> mvo: It's a reasonable compromise.. it doesn't offer full reusability, but means no further implementation time either
<mvo> niemeyer: ok - so what does it mean for the kernels I care about right now? pi-kernel, pc-kernel and dragonboard-kernel? how will those be handled?
<niemeyer> mvo: It'll be unfortunately only in those cases where we might actually reuse a kernel for a different customer
<niemeyer> mvo: Think core18 kernel on Brand X devices
<mvo> ok
<niemeyer> mvo: We may end up with a "pi-kernel", with tracks named as before inside it
<mvo> niemeyer: that works for me, thanks for the followup on this one
<mup> PR snapd#5893 closed: interfaces/apparmor: report apparmor support level and policy <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5893>
<pedronis> mborzecki: ack
<mvo> niemeyer: is there further discussion needed or can I go ahead with asking for tracks for the "pi-kernel" ?
<niemeyer> mvo: Same for the others
<niemeyer> mvo: noise][1 was going to give some further thought and post comments in the thread, so perhaps best to wait a bit to see whether others will comment furthr
<niemeyer> further
<mvo> niemeyer: ok, so pc-kernel with 18-{i386,amd64} and dragonboard-kernel with just 18 (there are no variants for this one (yet))?
<mvo> niemeyer: ok, I will wait then :) thanks again for chasing this!
<niemeyer> mvo: There's an interesting question on that one
<niemeyer> mvo: Do we need the i386/amd64?
<niemeyer> mvo: Note that we already split up arch internally
<mvo> niemeyer: indeed
<mvo> niemeyer: yeah, for those we don't actually need it
<niemeyer> mvo: It's curious that we cannot do the same on the pi
<mvo> niemeyer: I guess its all the same arch for the pi so that (neat) trick does not work. or am I misunderstanding what you have in mind?
<mvo> zyga: one more trivial review for snapcore/pi-gadget if you want
<zyga> mvo: sure
 * zyga just returned with fresh coffee
<roadmr> ogra: tools r1129 are now in the store
 * ogra hugs roadmr 
<mup> PR snapcraft#2306 opened: setup: remove broken setup dirs done on import <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2306>
<niemeyer> mvo: No, that's it indeed
<niemeyer> mvo: It's just curious because i386 and amd64 have a similar relationship
<mvo> niemeyer: indeed
<mup> PR snapcraft#2306 closed: setup: remove broken setup dirs done on import <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2306>
<mup> PR snapcraft#2307 opened: setup: improve dir setup for when running in legacy mode <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2307>
<mup> PR snapd#5876 closed: selftest: rename selftest.Run() to sanity.Check() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5876>
<pstolowski> niemeyer, zyga got hotplug removal sorted out per you suggestion regarding sysfs paths, work great \o/. and startup enumeration and its delta is based around device keys, no challenge there. my mistake for trying to implement 'remove' in a way that required computation of device key.
<ogra> jdstrand, hmm, so browser-support disallows daemon ? ... how do i get around that for a browser based kiosk client app ?
<zyga> pstolowski: glad to hear that :)
<diddledan> ogra: jdstrand: if browser-support kills daemon then these instructions need to be revised: https://tutorials.ubuntu.com/tutorial/electron-kiosk#2
<ogra> diddledan, well, prehaps i'm missing something ... thats what build.s.io gave me in return after building my dashkiosk-client-browser snap
<jdstrand> diddledan: I don't see 'daemon: ???' in there
<ogra> yeahm there is no daemon
<jdstrand> ogra: there is a way to override that in the store
<diddledan> jdstrand: next page has it
<niemeyer> pstolowski: No worries, and thanks zyga for the progress
<niemeyer> pstolowski: What was the trick?
<diddledan> I lunked (past tense of linked) the wrong page
<ogra> jdstrand, would be lovely, what do i need to do ? send boxes of beer your way ?
<diddledan> https://tutorials.ubuntu.com/tutorial/electron-kiosk#3
<jdstrand> ogra, diddledan: we should continue to override until we have privilege dropping. browser-support as root allows a few scary things
<ogra> yeah
<jdstrand> ogra: what snap?
<ogra> jdstrand, dashkisk-client-browser
<ogra> *dashkiosk
<ogra> it is essentially chromium with a wrapper and doesnt have any desktop'y plugs in use ... (though it uses wayland for mir-kiosk)
<pstolowski> niemeyer: well, just maintain an in-memory lookup based on sysfs paths, for the purpose of handling hotplug removal - rather than trying to compute device key from attributes of 'remove' udev event (which turned out to be incomplete sometimes, for lime sdr at least)
<niemeyer> pstolowski: So a sys path => device key?
<diddledan> in fact that electron-kiosk tutorial is confusing - it has a comment in the yaml that you can't have "identical plug/slot name in same yaml" so the author created a plug called `x11-plug` with interface `x11`, but I don't see any other usage of `x11` in that yaml at all
<ogra> diddledan, it uses a loopback to itself
<Chipaca> niemeyer: mvo: https://travis-ci.org/snapcore/snapd/builds/435647396 <- finishing spread after 30 minutes of previous tests, no timeouts
<diddledan> if all the plug definition is doing is stating that it is interface `x11` with no further config (which is what the yaml says) then surely just `plugs: [x11]` will do the same thing
<pstolowski> niemeyer: more-less yes, it's sysfs path => interface name => device key(s)
<diddledan> ogra: there's no definition of any slots anywhere in that yaml
<niemeyer> pstolowski: Hmmm.. that doesn't make much sense I guess
<diddledan> oh wait
<ogra> diddledan, the thing is that XWayland is shipped and run by the same snap ...
<diddledan> now I see it
<diddledan> hidden in the apps: stanza
<ogra> to connect to XWayland you need the x11 interface
<niemeyer> pstolowski: The sysfs path can't map to the interface name alone as we wouldn't know which device it is still
<ogra> so the snap provides the plug to itself in a loopback
<pstolowski> niemeyer: sorry, i mistyped, i mean sysfs path maps to (interface name, device key) - possibly more than one if multiple interfaces created slots for a single device
<niemeyer> pstolowski: Aha, gotcha, that makes sense
<vidal72[m]> how core18 is going? :)
<zyga>  vidal72[m] I think it's going good
<vidal72[m]> :))
<mvo> Chipaca: nice!
<niemeyer> Chipaca: Nice indeed, what's the full time now?
<Chipaca> niemeyer: without the extra "wait 30 minutes just to see if the whole thing times out"?
<Chipaca> niemeyer: about 11 minutes from unit tests & etc, and 34 minutes from spread
<niemeyer> Cool
<niemeyer> I guess it's a good deal still
<Chipaca> we gained about 1 minute by moving static into unit
<Chipaca> we can probably shave 5 minutes off the unit test by skipping (or fixing! ha ha crazy talk) the slow ones
<niemeyer> :)
<Chipaca> ok, time for a break, bbl
 * zyga break while my daughter needs my desk to build something
<mup> PR snapcraft#2307 closed: setup: improve dir setup for when running in legacy mode <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2307>
<mup> PR snapcraft#2308 opened: plugins: remove the copy plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2308>
<mup> PR snapcraft#2309 opened: snap: improve early base detection logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2309>
#snappy 2018-10-02
<mup> PR snapcraft#2310 opened: nodejs plugin: add support for ppc64el and s390x <Created by anthonyfok> <https://github.com/snapcore/snapcraft/pull/2310>
<luk3yx> When will build.snapcraft.io use 18.04 to build snaps?
<ilias_gr> hi all. does anyone maybe know why using skype for ubuntu the systray icon doesn't change when user switch between different system's icon packs?
<mborzecki> morning
<zyga> good morning
 * zyga spent way too many hours debugging a simple type error : /
<mup> PR snapd#5895 closed: client, daemon: support passing of 'unaliased' option when installing from local files <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5895>
<zyga> error: received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/pYVQrBcKmBa0mZ4CCN7ExT6jH8rY1hza_158.snap?token=1538474400_751f689ba95d256c948c3192959fb3e166ab9c82
<zyga> + find '/home/gopath/src/github.com/snapcore/snapd/tests/snapd-state/snapd-lib/*' -maxdepth 0 '!' '(' -name snaps -o -name seed ')' -exec cp -rf '{}' /var/lib/snapd ';'
<zyga> find: â/home/gopath/src/github.com/snapcore/snapd/tests/snapd-state/snapd-lib/*â: No such file or directory
<mborzecki> well, at least the tests failed right?
<zyga> integration tests failed, I incorrectly handled one unit test that would work ok because it was mocked
<zyga> error types
<zyga> anyway, sorted out now
<zyga> just realised it way too late last nighrt
<zyga> *night
<mup> PR snapd#5875 closed: interfaces/builtin: avahi interface update <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5875>
<pstolowski> morning
<zyga> hmm hmm
 * zyga digs deeper into issues 
<zyga> there's something wrong with layouts on core18
<mup> PR snapd#5874 closed: interfaces/builtin: adding missing permission to create /run/wpa_supplicant directory <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5874>
<zyga> I have a hunch I know what is going on but I wasn't expecting this problem yet
<mvo> zyga: tell me more please
<zyga> well, it's related to trespassing and when we consider it is safe to write to a directory
<zyga> I started with a conservative decision to only allow writes to a directory when said directory is the mount point of a tmpfs we can trace to snapd
<zyga> one of the tests exercises a sub-sub directory
<zyga> and snap-update-ns doesn't consider that a guaranteed tmpfs
<zyga> this happened because the apparmor generalisation landed
<zyga> and a test switched from /bin/some-very-weird-place to /bin/some/very/weird/place to show that the apparmor part of it works
<zyga> I knew about it but didn't realise it would come into reality as a test problem this way (via merging of the other branch)
<zyga> the question is how to safely extend the logic to allow sub-directories of a tmpfs that is still a tmpfs and not hidden by some other mount operation
<Chipaca> moin
<Chipaca> mvo: mborzecki: Asplode() -> AsMaps()?
<zyga> so if /bin is a tmpfs then /bin/very is also a tmpfs unless it's explicitly mounted as something else
<zyga> it's just tricky code because we cannot identify a filesystem instance easily AFAIK
 * zyga checks
<zyga> maybe I'm wrong actually
<mborzecki> Chipaca: sounds good
<mborzecki> Chipaca: your #5879 made me dig into go-flags and read what the flag does :)
<mup> PR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
<Chipaca> mborzecki: I'm so sorry
<Chipaca> :)
<Chipaca> mborzecki: --posixly-correct
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> Chipaca: don't be, it was nice
<Chipaca> heh, that looks like I'm holding mborzecki up on a platter
<Chipaca> maybe I'm about to throw it into a pool or sth
<Chipaca> zyga: is your pi3 connected and on in The Lab?
<zyga> nope, it's a bit offline actually
<zyga> I need to reformat all of the things and put them in proper network
<zyga> if urgent I can bring one online
<Chipaca> not urgent
<zyga> I have pi2-2 in my hands
<zyga> I think it's still running core
<Chipaca> I was just wondering how long 'snap' took to run on a pi these days
<zyga> hold on
<Chipaca> (that is: 'time snap > /dev/null'
<Chipaca> )
<Chipaca> things that are fun: find -type f -name \*.go \! -name \*_test.go -print0 | xargs -0 perl -pi -we 's/(^func init\(.*)/$1\nprintln("$ARGV")/'
<Chipaca> yaml wins
<zyga> no pikcza
<zyga> (no picture)
<zyga> it doesn't boot
<zyga> I think the SD cards degrade pretty rapidly :/
<zyga> I'll re-flash it
 * zyga tries to recall where to get pi2 images
<zyga> or the magic incantation to make one...
<mvo> zyga: no worries I should have a working pi3
<zyga> I may as well flash it
<mvo> Chipaca: https://paste.ubuntu.com/p/JfZ5NtpJJX/
<mvo> zyga: try http://cdimage.ubuntu.com/ubuntu-core/16/stable/
<Chipaca> mvo: and redirecting to /dev/null?
<mvo> zyga: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<Chipaca> mvo: (thanks!)
<mvo> Chipaca: pretty much the same
<mvo> Chipaca: https://paste.ubuntu.com/p/HTwkZzTGGf/
<Chipaca> mvo: lovely
<Chipaca> I can stop worrying about this for another year \o/
<zyga> thanks moo!
<zyga> mvo:
<zyga> (silly tab completion)
<zyga> but somehow aptpropritate
<mvo> haha
<mup> PR snapd#5890 closed: overlord/snapshotstate: small refactor of internal helpers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5890>
<Chipaca> BRB, new kernel
 * zyga tests a tweak that should get out out of the problem 
 * zyga forgot to flash pi2, flashing now
<mup> PR snapd#5896 opened: snapcraft.yaml: set grade to stable and add type: snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/5896>
<zyga> sigh :/
<zyga> woah
<zyga> actually!
<mup> PR snapd#5897 opened: interfaces/builtin: add gpio-keys interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
 * pstolowski after typing 'go push' for nth time, wishes computers were smart enough to know what i mean wrt to git and go, and simply do the right thing
<mup> PR snapd#5898 opened: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898>
<zyga> flashed pi2, no picture :/
<zyga> back to debugging
<mborzecki> zyga: you got to make an offering to the pi
<zyga> I have to plug the serial adapter but sigh, not now
<zyga> 2018-10-02 11:39:38 Cannot allocate google:ubuntu-core-18-64: cannot allocate new Google server for ubuntu-core-18-64: quota 'IN_USE_ADDRESSES' exceeded. Limit: 575.0 in region us-east1.
<zyga> we may have stale machines somewhere?
<zyga> woot, some improvement
<mup> PR snapd#5883 closed: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5883>
<mup> PR snapd#5899 opened: tests: shellchecks, final round <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5899>
<mvo> mborzecki: yay for shellcheck
<mborzecki> mvo: slightly longer than usual, but i figured we should just be done with it
<mvo> mborzecki: +1
<rogpeppe> if i have i've registered a snap, but i want to make it possible for other people (ideally a team) to manage that snap (push updates, etc), how would I do that?
<zyga> rogpeppe: add them as collaborators in the snap dashboard
<rogpeppe> zyga: where do i find the snap dashboard?
<zyga> rogpeppe: login to https://snapcraft.io/ and go to https://snapcraft.io/snaps
<rogpeppe> zyga: i'm currently looking at https://snapcraft.io/mysnapname/listing
<zyga> then pick the snap name you want to share
<rogpeppe> zyga: click on it?
<zyga> hmm, hold on
<zyga> https://dashboard.snapcraft.io/snaps/
<rogpeppe> zyga: ah yes! just found that
<zyga> that functionality is available in the old dashboard
<rogpeppe> zyga: very confusing
<zyga> then you can go to collaboration page
<zyga> yeah, I agree
<zyga> I thought this was one page now
<rogpeppe> zyga: can i add groups?
<zyga> no, only users AFAIK
<rogpeppe> zyga: ok, thanks.
<zyga> mborzecki: I took the logic for updating a namespace into a new package and wrote a mini tool that just displays what would happen given two fstab files
<zyga> I ran it on the problematic namespace
<zyga> https://paste.ubuntu.com/p/QYCsJMkPJg/
<zyga> the results are sane
<rogpeppe> zyga: thank you
<zyga> so far so good then
<zyga> I'll break for coffee and do more digging
<ogra> mvo, sil2100 what happened to the pi3 gadget, there are a bunch of fixes that do not show up in edge (16)
<ogra> all of a sudden the auto-builds seem to build 18.X only
<ogra> we (ondra mainly) are trying to test the pi3 b+ and the last pi3 gadget build for core16 is from august ... yet the last commits on GH are newer (to pick up the new boot firmware)
<ogra> i see it being built at https://code.launchpad.net/%7Ecanonical-foundations/+snap/pi3
<ogra> oh
<ogra> "Store upload failed: Cannot upload new revisions for name=pi3 series=16 "
<ogra> https://code.launchpad.net/~canonical-foundations/+snap/pi3/+build/343957
<ogra> ondra_, so seems the builds havent been uploaded since august 2017 :/
<ogra> cjwatson, any idea whats going on there with that "Store upload failed: Cannot upload new revisions for name=pi3 series=16" ? (there is no other error msg anywhere)
<ogra> hrm ... and hitting the retry button gets me "you are not allowed here" ... thats new
<ogra> this is pretty serious, the boot firmware had plenty of imprtat fixes since aug. 2017 that should go in asap
<ogra> (power and thermal mgmt ... support for cm3 and pi3b+)
<zyga> back to digging
<Chipaca> oh dang
<Chipaca> mborzecki: mvo: do we have a 'stop the line' button?
<Chipaca> mborzecki: mvo: the xdelta tests are failing -- at first I thought it was a transient and was checking with wgrant, but the logs show we aren't enabling deltas, and mborzecki's pr just failed with them as well
<Chipaca> mborzecki: mvo: what have we broken?
<mborzecki> Chipaca: wasn't there a switch to enable deltas?
<mborzecki> i vaguely recall a pr (from mvo?)
<ondra_> ogra ping
<pedronis> it's generally on now (lat time I checked)
<Chipaca> mborzecki: as long as we have an xdelta3 executable it should be on -- and we nearly always have an xdelta3 executable as it's in core :-)
<ogra> ondra_, yo
<mborzecki> Chipaca: what if the executable is named xdelta?
<Chipaca> mborzecki: the one in core isn't
<ogra> ondra_, i can see you now
<pedronis> Chipaca: are they failing everywhere or only some distros?
<wgrant> mborzecki, Chipaca: Also xdelta is xdelta 1, not xdelta3
<Chipaca> pedronis: everywhere
<Chipaca> bah
<pedronis> did master became red and we didn't notice?
<pedronis> or is it on PRs?
<Chipaca> amazon-linux-2-64,arch-linux-64,debian-9-64,fedora-28-64,opensuse-42.3-64,ubuntu-14.04-64,ubuntu-16.04-64,ubuntu-18.04-64,
<mborzecki> w8, but the PRs id opened today were green
<Chipaca> everywhere that isn't actually core
<Chipaca> pedronis: on two unrelated PRs that are unrelated to this bit of code
<pedronis> master is green fwiw
<pedronis> atm
<Chipaca> my epoch.CanRead, which isn't even used anywhere, and mborzecki's shellchecks
<mborzecki> yup, but #5898 which was opened 2h ago is green
<mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898>
<Chipaca> mborzecki: and the same epochs PR that ran spread just before this last run failed with a silly transient error unrelated to this
<Chipaca> so whatever it was, it was in the last half hour
<Chipaca> which is why the first thing I assumed was store shenanigans
<Chipaca> (sorry wgrant)
<wgrant> :)
<wgrant> New core snap maybe?
<wgrant> Yeah
<wgrant> It had core 5618
<wgrant> Which is 16-2.36~pre1, and it's 53 minutes old
<wgrant> mvo: ^^
<wgrant> Must be that, surely
<Chipaca>     334             "created-at": "2018-10-02T10:30:33.953597+00:00",
<Chipaca> heh, yep
<pedronis> likely, wonder why we decided to drop one package there (or whether we dropped more,  that would be bad)
<wgrant> xdelta3 is in the build log, though
<wgrant> But not the manifest
<pedronis> it's supposed to have a fixed list of packages
<Chipaca> wgrant: in which build log?
<wgrant> https://launchpad.net/~snappy-dev/+snap/core/+build/344744
<Chipaca> ah
<pedronis> at this point
<wgrant> The build log for that core snap
<Chipaca> $ /snap/core/current/usr/bin/xdelta3 -h
<Chipaca> bash: /snap/core/current/usr/bin/xdelta3: No such file or directory
<Chipaca> ^ that's core from beta
<Chipaca> fuuuuu
<Chipaca> mvo: OHAI
<Chipaca> or maybe cachio
<pedronis> fun (not)
<Chipaca> also, also, of course cachio today had is laptop go all MCE on him so he's unavailable for a bit
<pedronis> Chipaca: either losing packages out of core is bad (tm) :/
<mborzecki> good thing it was caught by the tests after all
<pedronis> I think core18 has more checks in that area
<sil2100> ogra: yeah, I'll be looking at that
<ogra> sil2100, thanks ...
<wgrant> Oh
<wgrant> The xdelta3 in the log is LP installing it for the snapd in the container to use
<wgrant> Not the build itself, heh.
<Chipaca> another thing, we need to update the tests because we've got refresh-delta and refresh-delta-from-core with the assumption that the former has xdelta3 from the distro and the latter doesn't, but the former doesn't check
<ogra> wgrant, Chipaca that build log shows that the completely wrong livecd-rootfs is used
<ogra> it needs to come from the PPA unless *all* PPA changes have been merged into xenial-updates yet
<wgrant> Hah, indeed,
<ogra> (probably that was a manual build and whoever did it missed to pick the PPA as archive ?)
<wgrant> RUN: /usr/share/launchpad-buildd/slavebin/in-target override-sources-list --backend=lxd --series=xenial --arch=amd64 SNAPBUILD-344744 'deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial main' 'deb http://ftpmaster.internal/ubuntu xenial main restricted universe multiverse' 'deb http://ftpmaster.internal/ubuntu xenial-security main restricted universe multiverse' 'deb http://ftpmaster.internal/ubuntu
<wgrant> xenial-updates main restricted universe multiverse'
<wgrant> yeah, no, image in there, just tools
<wgrant> https://launchpad.net/~snappy-dev/+snap/core/+build/344744 <- indeed, primary archive build
<wgrant> Worth quickly reverting that at least in beta to avoid bricking everybody?
<Chipaca> no brick, just no deltas
<pedronis> Chipaca: that's a theory, it was built all wrong, so something else might be amiss
<ogra> Chipaca, definitely brick ...
<ogra> Chipaca, if the build scripts are wrong you get more broken content than xdelta3 missing :)
<Chipaca> ogra: if so then we should definitely revert
<Chipaca> i can do it, but i'd rather a nod from mvo before just doing it :)
 * Chipaca telegrams
 * Chipaca succeeds
<mvo> Chipaca: here
<mvo> Chipaca: thanks for altering me, I removed ~pre1 from edge
<Chipaca> mvo: nice
<Chipaca> mvo: thanks
<mvo> Chipaca: reading backlog now
<Chipaca> mvo: look for 'stop the line' and down from there
<mvo> Chipaca: hrm, the annoying part is there is a script that checks if the ppa is missing and it should error in this case
 * mvo looks why this was not working
<Chipaca> mvo: maybe ogra removed the 'set -e'
 * Chipaca hides
<mvo> haha
<ogra> mvo, whoever buuilt it missed to pick the PPA as archive in the build form ... so the archive livecd-rootfs was used
<mvo> ogra: yes, my fault
<mvo> ogra: I'm looking why it did not error, there is code in there that should make it error :(
<ogra> Chipaca, well, for my british friends i nowadays do not remove "set -e" but add "set -eu" :P
<ogra> mvo, thats the outer lxd container ... during build it then pulls the right livecd-rootfs (but then it is already too late)
<ogra> not sure you can actually have code inside the container that checks the livecd-rootfs version outside
<zyga> ogra: lol
<Chipaca> ogra: +1.33
<cjwatson> ogra: That means that the user who authorised the upload of that snap is no longer a publisher or a collaborator of the snap.  Get somebody appropriate to go to https://code.launchpad.net/~canonical-foundations/+snap/pi3/+authorize and reauth it
<ogra> cjwatson, ah, seems i lost my credentials when i moved teams or some such ... but sil2100 already said he'd take care
<ogra> (or the build moved ownership ...)
<mup> PR core#97 opened: snapcraft.yaml: add check for ppa:snappy-dev/image <Created by mvo5> <https://github.com/snapcore/core/pull/97>
<zyga> HA
<zyga> that was super fun to find
<axino> hi popey, could you please release edge into stable for the sentry snap ?
<popey> axino: done
<axino> popey: thanks !
<dot-tobias> What's the best way to implement an on-demand-service in my snap? Use case: My snapped app needs a DNS server (dnsmasq) if it is in setup mode, so I need to start/stop the server from within my application code. However, it should *not* (re-)start automatically (i.e. like snap daemons) Q1: How would I start the service from within the snap? Q2: And how to stop the service if I don't have access to systemctl?
<zyga> you can do both by invoking "snapctl"
<zyga> or by talking to snapd over a socket directly
<zyga> (but snapctl makes that much easier)
<mup> PR snapcraft#2309 closed: snap: improve early base detection logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2309>
<zyga> as for the part where you want the service not to restart automatically
<zyga> there's a word that you can use in the snapcraft.yaml (or snap.yaml) to convey that
<zyga> I recall that at the level of an application definition you say "refresh: endure" or something like that
<zyga> it will then not be restarted when a snap is refreshed
<zyga> and it is up to you to manage that
<dot-tobias> zyga Ok, thanks. But the service would be started on snap installation?
<zyga> currently yes but there's a PR that fixes a bug in this area, which once merged would allow you to disable the service from a configure (or install) hook
<zyga> so your hook disables the service using snapctl
<zyga> your snap or configure hook can enable or start it on demand
<zyga> or actually, as the need arises
<zyga> such as when the application logic determines it is now needed
<zyga> not in the socket-activation meaning of the word
<zyga> but note that the bug is still in place and snapd will still try to start disabled services
 * zyga looks at the PR
<zyga> https://github.com/snapcore/snapd/pull/5777
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<zyga> it seems that someone needs to pick that up and finish it
<zyga> dot-tobias: does that answer your question?
<dot-tobias> zyga (skimming through the PR) yes, that should solve my problem. Any internal ETA on when this will be merged? Need to release an initial beta soon, and depending on that I'd need to find a workaround until then.
<dot-tobias> And thank you again, of course ð
<zyga> no ETA, someone just needs to pick it up
<mup> PR core#97 closed: snapcraft.yaml: add check for ppa:snappy-dev/image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/97>
<dot-tobias> zyga Would love to help if I had any proficiency in Go, but I guess I would need to take a weeklong deep dive into Go & snapd to even have a faint idea of what I'd be doing there â¦ While the daemon route seems the way to go when the PR is merged, is it possible to stop a process (dnsmasq in background mode) that's been triggered by my app? The interfaces docs mention that core-support provides access to systemctl, but is reserved for core snaps.
<ogra> mvo, oh, wow ... seems you trashed three of my test Pi's over here ... all of them run 16-2.36~pre1 and there are no network tools in the rootfs (so only serial login)
<zyga> dot-tobias: I think we will handle that , no worries, just cannot give you a timeline
<ogra> interestingly enough it boots fine to console login
<Chipaca> waiting for tests is dangerous
<Chipaca> https://pastebin.ubuntu.com/p/jR2vnGjZvP/
<zyga> dot-tobias: would dnsmasq be a part of your snap or just any random service in the system?
<dot-tobias> zyga dnsmasq is part of my snap.
<dot-tobias> organized to $SNAP/bin/dnsmasq
<zyga> dot-tobias: for that you *can* use snapctl to stop the service from your snap, you don't need any interface for this
<zyga> I don't recall if this is documented, let me look
<zyga> dot-tobias: have a look at https://forum.snapcraft.io/t/service-management/3965
<mvo> ogra: yeah, snap revert
<mvo> ogra: but no network, I reproduced it and the no-network is the killer
<mvo> ogra: sorry for that
<dot-tobias> zyga: Thanks, will try it out!
<ogra> mvo, no worries ... i asked for it by choosing edge after all ;)
<Chipaca> oh dang, lunch
<mvo> ogra: I'm looking into a check for this as we speak to ensure this can't happen again
<ogra> mvo, yeah, i saw your clever PR above already
<ogra> that looks actually good ...
<zyga> dot-tobias: good luck!
<zyga> dot-tobias: hint: try "snap run --shell your-snap"
<zyga> and then run snapctl
<zyga> you should be able to get access to your services
<mvo> ogra: yay, check worked, so this won't ever happen again:https://code.launchpad.net/~snappy-dev/+snap/core/+build/344819  - bad enough that it happend once :(
<ogra> jdstrand, any news for me about dashkiosk-client-browser ?
<ogra> mvo, once ? it happened quite often to me back when i was still in charge ... :) (but i usually noticed before it went to the store)
<ogra> its a bit sad that LP doesnt simply keep the choices you did for the last build as default
<mvo> ogra: heh - indeed
<ogra> perhaps one day someone invents an internet technology that makes it possible to store such data in your local browser ... and callsss them crisps ... or cakes ... or cookies :P
<jdstrand> ogra: oh sorry. I had it on my desk then got distracted
<ogra> no worries ... i thought so :)
<mup> PR snapd#5900 opened: release: 2.36~pre1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5900>
<ijohnson> Hey folks, I'm almost done with handling sockets/timers in #5777, but currently snapctl and snap commands both don't handle stopping services with timers/sockets so that can't be tested in my PR. I'm wondering if I should add support for stopping sockets/timers in this PR or a different one?
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<emilengler> Why snap remove does not remove the cahced snap ?
<ogra> can you elaborate ?
<zyga> emilengler: I think we cache the snap on disk for some time
<zyga> I don't recall the exact condition
<zyga> but it's deliberate
<ogra> but only the first installed one, no ?
<mborzecki> pedronis: can you take a look at https://github.com/snapcore/snapd/pull/5898 later today/tomorrow?
<mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898>
<pedronis> mborzecki: tomorrow, I have some errands today and will finish a bit early
<mborzecki> pedronis: sure, thank you!
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/5791
<mup> PR #5791: overlord/snapstate: improve consistency, use validateInfoAndFlags also in InstallPath <Created by pedronis> <https://github.com/snapcore/snapd/pull/5791>
<Chipaca> mvo: with you now having written a juju charm, do we need to add Charming to your honorifics?
<Chipaca> pedronis: looking
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/5891 one to help you with your aim of review more :-D
<mup> PR #5891: snap: give Epoch a CanRead helper <Created by chipaca> <https://github.com/snapcore/snapd/pull/5891>
<zyga> Chipaca: ack :) looking now
 * zyga fired spread with the tmpfs subdirectory fix
<zyga> the actual fix is tiny, it just took a while to get to
<Chipaca> pedronis: I'm sure I'd seen this one before; +1
<zyga> Chipaca: oooh
<pedronis> Chipaca: yes, but just today I went to it to make the spread tests pass, again don't make it too backward incompatible
<zyga> Chipaca: you know I will bike shed around intersect, right?
<Chipaca> zyga: I can show you alternative, worse implementations
<Chipaca> zyga: https://pastebin.ubuntu.com/p/2WwjkPNStG/
<Chipaca> zyga: the only one that is arguably better is F1b
<Chipaca> zyga: F1c,  not shown there, which has two more ifs in it is slower again
<mvo> Chipaca: hahaha
<Chipaca> bah, I might as well add them all
<zyga> Chipaca: did you try sorting the shorter list, then iterating over the longer list while binary-searching in the short list?
<Chipaca> zyga: they're both sorter
<Chipaca> sorted*
<zyga> oh
<zyga> nice
<Chipaca> zyga: and both non-empty
<Chipaca> zyga: F3 does binary search
<zyga> anyway, I'll get something to bite on and read this
<Chipaca> zyga: I'll restore the full one so you see all the variations
<zyga> k, brb
<mborzecki> funny, cause iirc the list of 10 elements max :)
<cachio> mvo, 2.35.2 is stable now
<mvo> cachio: thank you
<mvo> cachio: now I just need to nudge the sru guys again about it :/
<mborzecki> off to pick up the kids
<cachio> mvo, good
<cachio> mvo, I'll start with beta now
<kenvandine> zyga: any theories on bug 1794953 ?
<mup> Bug #1794953: GNOME Calculator snap has wrong theme in live session <rls-cc-tracking> <snapd:New for zyga> <gnome-calculator (Ubuntu):Invalid by ken-vandine> <snapd (Ubuntu):Confirmed
<mup> for zyga> <gnome-calculator (Ubuntu Cosmic):Invalid by ken-vandine> <snapd (Ubuntu Cosmic):Confirmed for zyga> <https://launchpad.net/bugs/1794953>
<Chipaca> zyga: qqq in my home on office.zygoon.pl, fwiw
<zyga> re
<zyga> Chipaca: qqq?
<zyga> (sorry, I was stolen to participate in family lunch_)
<zyga> ah
 * zyga looks
<Chipaca> zyga: I have a random package name generator
<Chipaca> zyga: (it's not very random)
<Chipaca> for example I also have some other unrelated tests in /tmp/jjj
<zyga> I need to spend this evening on bringing machines back online
<Chipaca> (about json)
 * zyga sees that now
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> oh, BenchmarkF
<Chipaca> it starts with /tmp/q.go being my default scratch file for go stuff
<zyga> I never tried that
<Chipaca> and, well, not being good with names means i don't even try unless it's important :-)
<zyga> kenvandine: as for your question, no theory yet, I need to see what's going on in live sessions to begin with
<zyga> kenvandine: is it perhaps related to the fact that theming was broken in those snaps we looked at the last time?
<rbasak> Is there any known regression in the core beta snap atm? I have one
<rbasak> Affects beta and edge AFAICT
<rbasak> https://paste.ubuntu.com/p/zqWhpGF8nC/
<rbasak> mvo: ^
<Chipaca> rbasak: re-refresh
<Chipaca> rbasak: we broke it, and then fixed it
<rbasak> Ah
<Chipaca> rbasak: 1 sec, let me get you a timestamp
<Chipaca> rbasak: 2018-10-02T10:30:33.953597+00:00
<Chipaca> rbasak: that core ^ is buggy
<rbasak> ahasenack: ^
<Chipaca> er, i should have a revno
<mvo> rbasak: we had a bad core for about 30min
<Chipaca> rbasak: we caught the issue and reverted to a known-good one already, fwiw
<Chipaca> as mvo says
<kenvandine> zyga: the theme is fine for those same snaps on a clean 18.10 install
<zyga> I see
<ahasenack> refresh-date: 11 days ago, at 08:50 -03
<rbasak> beta (5624) is still broken I think?
<ahasenack> weird why mine didn't refresh in such a long time
<zyga> it could be a new interaction with how overlayfs is used on 18.10, I need to debug that
<mvo> rbasak: sorry for that, just revert or refresh and it should be fine again. sorry for the trouble. we identified the source and added an extra check during the build to ensure this won't happen again
<zyga> I didn't have the time to do that yet
<ahasenack> installed:   16-2.35.2                (5548) 92MB core is what I have
<Chipaca> 5618 is the broken one for amd64
<ahasenack> what about 5548?
 * Chipaca checks revnos
<mvo> rbasak: what kind of breakage do you see with 5624?
<mvo> ahasenack: 5548 should be good
<rbasak> I don't have a reproducer with core only. Is there any way of getting a shell on core?
<ahasenack> I'm tracking beta, I wonder why I didn't get   beta:      16-2.36~pre1             (5624) 92MB -
<rbasak> My reproducer is as my pastebin above
<mvo> rbasak: if you have grub you can add "systemd.debug-shell=1" to the cmdline
<Chipaca> 5548 is stable, even
<mvo> rbasak: missed that pastebin let me look
<rbasak> It could be git-ubuntu, I don't know.
<mvo> rbasak: let me try this
<Chipaca> rbasak: ahasenack: ah, was about to say, 5624 is what you're on it seems
<rbasak> But it seems to be triggered by a core snap update - stable was OK this morning.
<mvo> rbasak: could be us let me look at it
<rbasak> Thanks
<mvo> rbasak: I mean, we had a bad beta today so I'm inclined to first look at our stuff.
<zyga> kenvandine: I can promise you to look at and attempt to debug the issue first thing tomorrow
<ahasenack> Chipaca: https://pastebin.ubuntu.com/p/mw8g8x3qm3/ am I not on 5548?
<zyga> kenvandine: today I plan to finish producing mergeable fixes for other mount related bugs
<Chipaca> ahasenack: ah,  you are, rbasak is not
<kenvandine> zyga: thanks
<ahasenack> ok, I get the same problem as him
<rbasak> I've jumped about all over the place today
<Chipaca> ahasenack: so that's confusing, are you talking about the same issue?
<Chipaca> mvo: ahasenack has it and he's on stable
<ahasenack> yes, I'm getting this:
<rbasak> I can confirm a specific one for you if you want to focus on a particular version
<Chipaca> we haven't touched stale in a while, let me get a timestamp
<ahasenack> 10/02/2018 11:50:51 - ERROR:stderr: awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
<ahasenack>   awk: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
<ahasenack> which rbasak streamlined into his pastebin
<Chipaca> stable is from 2018-09-21
<Chipaca> ahasenack: rbasak: 5548 is from 2018-09-21T09:37:27.063407+00:00
<mvo> ahasenack: we had a stable update today
<ahasenack> the word "stable" does not appear for core in my snap list --all output
<ahasenack> and "snap info core" says I'm tracking beta
<ahasenack> is stable ahead of beta?
<rbasak> stable is now broken :-/
<rbasak> 5548
<Chipaca> sigh
<rbasak> it was working for me this morning, but I didn't record the version
<Chipaca> ahasenack: you said you were on 5548
<Chipaca> ahasenack: or am I losing it
<ahasenack> Chipaca: look at https://pastebin.ubuntu.com/p/mw8g8x3qm3/
<mvo> rbasak: this morning it was 2.35 - now its 2.35.2
<ahasenack> 5548 has "beta" next to it
<rbasak> I did some testing this morning, then was called away, so there was a gap before I reported it here, sorry.
<ahasenack> so looks like beta was promoted to stable, and now both have 5548, is that it?
<mvo> rbasak: what environment did you run this on? bionic? cosmic?
<rbasak> mvo: bionic
<mvo> ahasenack: candidate was promoted to stable today, beta should be a different revision (r5624 currently)
 * Chipaca was getting confused and only adding confusion so will now keep quiet for a bit
<rbasak> mvo: I reproduced on a Bionic VM with the edge git-ubuntu snap
<mvo> rbasak: thanks, let me try with git-ubuntu edge
<ahasenack> refreshing core
<ahasenack> I'm getting 5624 now
<rbasak> I can give you exact steps that work I believe, so let me know if you have any difficulty
<mvo> rbasak: I poke at it now (both on my bionic box and in a VM)
<ahasenack> still happens to me with 16-2.36~pre1          5624
<ahasenack> fwiw
<mvo> rbasak: slightly strange is that you and ahasenack  were running beta for a while so nothing should have changed for you
<Chipaca> ahasenack: rbasak: which was the last core that worked ok for you?
<mvo> rbasak: this revision of core that is now in stable was in beta/candidate for a while
<ahasenack> mvo: I didn't get this just today, it's from last week I think
<ahasenack> I was on pto
<mvo> ahasenack: oh, ok
<mvo> ahasenack: thanks, that explains this part then
<ahasenack> I can try reverting core
<rbasak> mvo: I haven't been using this particular subcommand of git-ubuntu that triggers it, so it's only ahasenack who had noticed it until I tried to reproduce
<ahasenack> I still have 5486 available
<rbasak> Chipaca: I believe stable from this morning worked, though I don't see exactly how to revert to that right now.
<mvo> rbasak: snap revert core is not working ?
<Chipaca> rbasak: snap list --all core, if you still have the revno you can revert core --revision=...
<Chipaca> which is the git-ubuntu subcommand that fails?
<ahasenack> mvo: Chipaca rbasak with core r5486, it works
<Chipaca> nice
<ahasenack> Chipaca: build-source, when inside an ipsec-tools package, but rbasak's test case is shorter/simpler
<rbasak> Chipaca: thanks. "snap help refresh" said "snap refresh --list" but that didn't work (just said "All snaps up to date."
<rbasak> )
<Chipaca> rbasak: refresh != revert :)
<mvo> so far on my bionic main box I can not reproduce it but I am trying in a vm now, my regular machine is heavily customized
<rbasak> Chipaca: nevertheless, that's what "snap help refresh" says!
<mvo> rbasak: I see it in a fresh vm
<rbasak> Unfortunately I think I've tested too many revisions since, and it has scrolled out of my (three?) history revisions
<rbasak> (the stable one that worked)
<Chipaca> rbasak: I'm not following, but let's get back to that afterwards (better docs is good, but)
<rbasak> OK
<Chipaca> rbasak: which was your smaller reproducer?
<mup> PR snapcraft#2311 opened: snap: legacy needs to now it is legacy for re-exec <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2311>
<Chipaca> rbasak: got it
<rbasak> FTR, https://paste.ubuntu.com/p/zqWhpGF8nC/
<rbasak> On the git-ubuntu edge snap, is the smallest I have
<Chipaca> rbasak: can you install test-snapd-tools, and snap run --shell test-snapd-tools.sh and see awk there?
<mvo> rbasak: it looks like something is not setting the right LD_LIBRARY_PATH, with LD_LIBRARY_PATH=/snap/core/current/lib/x86_64-linux-gnu/ inside the shell things should be ok
<mvo> Chipaca: -^
<mvo> rbasak: the issue is that bionic ships with libreadline.so.7
<rbasak> Chipaca: done, and awk works there, contrary to the git-ubuntu snap for the same core snap revision.
<mvo> rbasak: but the awk on core is from xenial which has libreadline.so.6 and the core awk wants this lib.
<greyback> sergiusens: hey, any ideas why this is failing? https://pastebin.ubuntu.com/p/hxMjKT6VMM/
<mvo> rbasak, Chipaca I think it is related to --classic so test-snapd-tools is fine
<Chipaca> my next check was the same but with 'go'
<mvo> Chipaca: \o/
<Chipaca> rbasak: if you could do the same (snap install --classic go && snap run --shell go, and see awk)
<mvo> Chipaca: I'm still struggling to understand why that worked before - actually I thnk I know. before it was a symlink in /etc/alternatives that pointed inside the host fs. now its a relative symlink that points into core
<sergiusens> greyback: you are on stable?
<rbasak> Chipaca: also works
<greyback> sergiusens: yes
<mvo> Chipaca: can of worms
<greyback> sergiusens: but same on edge and beta
<rbasak> I'm happy to land any change you recommend into git-ubuntu of course
<sergiusens> greyback: we haven't changed stable in weeks
<sergiusens> greyback: lxd 3.0?
<mvo> rbasak: thanks and again sorry for the trouble, looking at git-ubuntu now to see what its actually doing
<sergiusens> greyback: if you run again, does it work?
<greyback> sergiusens: 3.5 from the stable snap
<greyback> sergiusens: no, fails same way. Just tried cleanbuild, also errored out with "snapcraft: not found"
<sergiusens> greyback: what happens if you wipe "~/.local/share/snapcraft/projects/lxd/"?
<sergiusens> I mean, can you wipe that and try again
<mvo> sergiusens: I'm just looking at an issue with a classic snap. the issue is that it uses gawk from xenial which uses libreadline.so.6 but runs (in classic mode) on a bionic with just libreadline.so.7. it looks like snapcraft sets the PATH to the /snap/core/current. should we also set the LD_LIBRARY_PATH to the matching pathes?
<zyga> mvo: I don't think that's safe
<zyga> in general
<zyga> that impacts more than it should
<zyga> if you set it other things may break
<sergiusens> mvo: we never set PATH, I we do not set LD_LIBRARY_PATH
<sergiusens> because of what zyga mentions
<sergiusens> we leave it up to the dev
<mvo> sergiusens: aha, so thats a snap specific thing? ok
<greyback> sergiusens: that seemed to have helped (core and snapcraft snaps installed ok), now fails a bit later https://pastebin.ubuntu.com/p/CR26TgZjgg/ - something not done apt update?
<sergiusens> if they do not intend to ever shell out or dlopen anything random, it can work
<mvo> rbasak: where is the source of git-ubuntu? I will poke a bit
<greyback> sergiusens: but I can work with that at least
<sergiusens> greyback: you are using tech we really haven't supported at all, but try "snapcraft refresh" then go and build away
<greyback> sergiusens: ok, what should I use? cleanbuild?
<mvo> zyga: yeah, but right now setting path but not the library path seems inconsistent. i will poke at the snap some more
<zyga> mvo: we don't set the PATH
<sergiusens> mvo rbasak git-ubuntu shells out a lot, if you add library paths you risk it breaking when calling binaries from the host
<zyga> mvo: not for classic snaps
<mvo> sergiusens: well, its broken right now and I'm looking for a way to unbreak it :)
<sergiusens> mvo: I cannot say in words on how classic has been my biggest pain for the past two years ð
<mvo> sergiusens: amen brother
<ogra> +1
<sergiusens> I still blame zyga for saying "it's easy" ð
<ogra> (or rather +10000)
 * greyback holds up his ligher
<zyga> it's all about the context
<mvo> zyga: I was under the misconception that this would be something that snapcraft would do automatically
<zyga> making a correct snap is hard
<sergiusens> yeah, a "Hello world" works fine :-P
 * ogra hands out hinges to everyone ... so we can actually do something useful with this can of worms
<sergiusens> mvo: that's the thing, we crawl all the elf files in the snap and set relative RPATHS all over the place
<sergiusens> mvo: but not PATH or ld_library_path's
<mvo> sergiusens: makes me wonder if I should do the same for core
<rbasak> mvo: https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master
<rbasak> otp
<sergiusens> mvo: but then dlopen and python ctypes and maybe other things need manual patching still as they all have their own implementation on how to find libraries to load
<sergiusens> mvo: that would solve problems if it is what is causing a segfault
<sergiusens> mvo: if I can parse the problem, is rbasak calling a binary in core and it is loading the wrong libraries?
<mvo> sergiusens: correct
<sergiusens> if that is the case, then elf patching is what you need to do, as a classic snap accessing things from core, makes core essentially classic
<mvo> sergiusens: git-ubuntu is running gawk and because PATH is set its the version from core
<mvo> sergiusens: but gawk does not find its library (libreadline.so.6)
<sergiusens> mvo: the alternative is, disallow calling binaries from core; and only allow libraries; but then, you run into problems of libraries calling binaries (like you know in apt)
<sergiusens> and also library behavior when it dlopens
<mvo> sergiusens: hrm, hrm, can of worms
<sergiusens> we can also discuss and transform what classic means and require you to bundle all your deps except maybe libc6 or maybe even so, and they become baseless snaps
<ogra> just fix PATH that $SNAP/bin:$SNAP/usr/bin comes first and ship gawk in the snap
<sergiusens> ogra: what if you call a shell out to an app on the host and the host sees that path and makes you call a binary in the snap instead of the host
<sergiusens> everything is solvable, but it is really project specific
<ogra> indeed
<mvo> yeah, the readline problem is really only {g,n}awk and gpg
<sergiusens> we cannot throw out ideas without looking at the actual problem
<Chipaca> mvo: and vi?
<sergiusens> mvo: if core/bases are to support classic, they probably need to do the right thing when it is not the root
<mvo> Chipaca: unless my script is silly vi on core does not use libreadline
<mvo> Chipaca: but yeah, its all the same issue it just happens to work because most  libs have not changed much
<mvo> sergiusens, Chipaca it sounds like for this particular problem we would need something like LD_LIBRARY_PATH_AFTER_LD_SO_CONF=...
<Chipaca> mvo: ah, i was thinking the other way round, but yeah
<sergiusens> mvo: but the library path will live on the host or how will you set this up?
<mvo> sergiusens: yeah, there is no such a think right now
<mvo> sergiusens: I mean the problem would be solved with LD_LIBRARY_PATH=$HOST_LIBRARY_PATH_FROM_LD_SO_CONF:/snap/core/current/lib...
 * mvo scratches head a bit
<sergiusens> mvo: but the libreadline from the host will be found first
<sergiusens> mvo: that works if the host does not have the library
<mvo> sergiusens: thats ok in this particular case
<mvo> sergiusens: yeah this would solve this particular problem
 * rbasak is back
<sergiusens> mvo: heh, that last sentence kind of proves it is not a generic solution
<mvo> sergiusens: heh, no
<mvo> sergiusens: I think there is no general solution there is just too much messiness (as you said, ctypes and friends)
<sergiusens> mvo: this is what we do for snapcraft as a snap to support ctypes https://github.com/snapcore/snapcraft/blob/master/patches/ctypes_init.diff#L1
<mvo> sergiusens: woah, you patch it inside the snap?
<sergiusens> mvo: yes; ctypes works in a way that it finds libraries by doing an ldconfig -p
<sergiusens> which means it will never pick libs in the snap
<sergiusens> I need to upstream this in a sort of generic way into cpython
<mvo> rbasak: I have not forgotten you, still poking at this
<rbasak> No problem, thanks
<mvo> rbasak: could you please try this low-tech "fix": http://paste.ubuntu.com/p/CZkGWz7dzm/   - snapcraft should patchelf gawk to look into core for its libs (cc sergiusens)
 * mvo is off for a bit but will read backlog
<sergiusens> yeah, bundling gawk in the snap will fix it, certainly will be patched correctly too
<sergiusens> this is however, a workaround to the core issue (oh a pun)
 * zyga runs one more round of spread and goes to make something warm to drink
<zyga> Chipaca: I did not forget
<zyga> I think I should just approve it and bikes head separately
<roadmr> yum spread
<zyga> yeah, we should add an RPM package
<zyga> oh
<zyga> drat, I forgot opensuse, I got my package in
<zyga> I need to do some paperwork on ti
<zyga> on *it
<mup> PR snapcraft#2312 opened: meta: support relocatable prime for path verification (#2287) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2312>
<rbasak> mvo: thanks! I created https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/355995 so I can get a CI run that will produce a test snap for me. Then I can test the generated snap manually for now. Is my commit message accurate? Separately I'll see about adding a test to ensure gawk works for CI in the future before landing it, but I thought I'd throw your patch at CI now to see if it works.
<mvo> rbasak: I will write a followup on this, the commit message is mostly fine - I will suggest some tweaks (after dinner :)
<Chipaca> zyga: *doubt*
<zyga> ;-)
<morphis> mvo: just found an issue where the systemd units generated by snapd for socket activation causes my system to not start NetworkManager on startup: https://forum.snapcraft.io/t/networkmanager-doesnt-start-anymore-on-a-fresh-ubuntu-system-after-installing-the-lxd-snap/7666
<zyga> Chipaca: review sent
<Chipaca> wee
<zyga> morphis: I think we dropped the online target
<zyga> but we don't update existing units
<zyga> we don't have code for that yet
<morphis> zyga: I've installed the system a few hours ago so not sure if these are left over units
<zyga> Chipaca: I revised the second comment
<zyga> morphis: maybe that's 2.36 material
<zyga> I recall seeing this land
<zyga> I think we ought to think about doing that
<zyga> but not sure how TBH
<zyga> snapd starts up and decides to rewrite all the systemd units?
<morphis> zyga: only bad thing about this is that it leaves my system starting up with no network, sounds pretty bad for unattended systems
<zyga> no disagreement
<Chipaca> zyga: what's your nitpick?
<mup> PR snapd#5901 opened: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901>
<Chipaca> zyga: I'm merging, but I can amend the comment in a followup :)
<zyga> Chipaca: it's a placeholder for the eventual nitpick about avoiding O(N^2)
<Chipaca> ah
<zyga> but please merge
<zyga> it's not a problem now
<Chipaca> zyga: nor ever, because N<=10
<zyga> Chipaca: can I ask you to look at the principal idea behind https://github.com/snapcore/snapd/pull/5901
<Chipaca> :)
<mup> PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901>
<Chipaca> muuurged!
<mup> PR snapd#5891 closed: snap: give Epoch a CanRead helper <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5891>
<zyga> that is use of major:minor numbers
<zyga> feel free to postpone till tomorrow
<zyga> Chipaca: the primary part of the change is https://github.com/snapcore/snapd/pull/5901/files#diff-4096bdaf9890161ea9c6e277d6ec7291R100
<zyga> + the commit message
<zyga> and what is in the next hunk
<zyga> rest is just tests and furnishing
<Chipaca> zyga: allowed allowed
<Chipaca> https://github.com/snapcore/snapd/pull/5901/files#diff-72963e5a6ac9e80f645d1c39c1a670d1R186
<mup> PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901>
<zyga> I shall fix fix
<zyga> thanks!
<Chipaca> wow, there's a lot of allowed allowed
<Chipaca> a lot == at least 2
 * Chipaca skips ahead to the meat of the pr
<zyga> corrected locally
<zyga> I'll push with any updates
<zyga> mborzecki: I understand why the propagation failed
<zyga> it didn't
<zyga> it was a tricky test
<zyga> I will explain tomorrow
<zyga> but the good thing is, there are no bugs :)
<zyga> well
<zyga> it's still not what people may expect
<zyga> and we can fix the sorting to perhaps handle that (I alluded to a better sort algorithm)
<zyga> but it's not propagation
<Chipaca> zyga: which was the syscall that qt started using that they didn't take the patch?
<zyga> statx
<Chipaca> zyga: ta
<Chipaca> aw, no manpage on xenial
<zyga> I'll make tea and see if my wife has any plum cake left
<zyga> Chipaca: http://man7.org/linux/man-pages/man2/statx.2.html
<Chipaca> teo
<Chipaca> ta*
<Chipaca> not sure what i tried to write there
<Chipaca> zyga: when is .dev 0?
 * ogra hugs jdstrand 
<ogra> jdstrand, is it whitelisted too ? (i might need a few subsequent changes)
<zyga> re
<zyga> Chipaca: ha, in tests
<zyga> that warrants a comment :)
<zyga> I only added it so that we don't mistakenly use zero-valued struct data
<Chipaca> zyga: yeh
<Chipaca> zyga: otherwise, looks very sane
<zyga> adding now
<zyga> Chipaca: pushed
<rbasak> mvo: the fix only half works. "gawk" now succeeds, but "awk" does not - since usr/bin/awk isn't provided in the snap (I wonder why)
<rbasak> mvo: snap binary here: https://jenkins.ubuntu.com/server/view/git-ubuntu/job/git-ubuntu-ci/40/
<mup> Bug #1783772 changed: syslog error msgs when running 'snap list' on disabled daemon snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1783772>
<rbasak> Chipaca: here's the snap refresh doc thing: https://paste.ubuntu.com/p/3pbYj7F9dQ/
<rbasak> Chipaca: from line 40 I expected refresh --list would work
<Chipaca> rbasak: in what sense does it not work?
<rbasak> "All snaps up to date." is not a list of available snaps for refresh
<Chipaca> rbasak: or rather: what did you expect it would do?
<rbasak> I expected it to do what "snap list --all git-ubuntu" does
<rbasak> Show me the snaps I can refresh to
<rbasak> (versions)
<Chipaca> rbasak: how does --all show you what you can refresh to?
<Chipaca> i mean, list --all
<Chipaca> "snap list --all" shows you what you can revert to, if you want
<rbasak> sudo snap refresh --revision=x1 git-ubuntu
<rbasak> That works
<Chipaca> sigh
<rbasak> How is "All snaps to date." a list of snaps avialable for refresh?
<Chipaca> rbasak: ok, try this
<Chipaca> rbasak: snap switch core --edge
<Chipaca> rbasak: snap refresh --list
<rbasak> Oh, I see
<rbasak> Snaps that would refresh if I ask for a refresh with no parameters?
<Chipaca> or even by name
<rbasak> I suppose the difference is that I can use refresh to switch channels and suchlike
<Chipaca> so, clearly the doc needs work
<rbasak> I probably conflate refresh, revert and switch
<rbasak> And the CLI is happy to do what I mean
<Chipaca> "List snaps that would be updated on the next refresh"?
<rbasak> But that leads to confusion in understanding the docs
<Chipaca> rbasak: conflating revert and refresh will lose you data :-/
<Chipaca> (per-revision data is assumed bad on revert, and left alone, whereas on refresh it's copied along)
<Chipaca> revert is "omg these idiots broke it"
<rbasak> The problem with revert is that it's a one time thing
<rbasak> It's not necessarily obvious when it broke
<rbasak> It might have been multiple refreshes ago
<rbasak> Or at least it _seems_ like a one time thing to me
<Chipaca> yes, the revert story isn't complete without health checks
<Chipaca> (those are coming!)
<rbasak> Whereas normally I end up having to "hunt" to get back to something working, as I don't necessarily know when it broke; rather all I have is a reproducer
 * Chipaca nods
<Chipaca> which ties in with xnox's argument about foundations having to keep a copy of every revision of every snap ever
<zyga> Chipaca: just share it on facebook
<rbasak> Anyway, thank you for helping me understand better what I'm doing
<Chipaca> I mean, I'm still not sure I agree, but I can see where he's coming from
<Chipaca> rbasak: no problem! thank you for pointing out where things are unclear / surprising
<rbasak> We keep a copy of every deb we published ever. It's particular useful when debugging broken upgrade paths, etc.
<rbasak> snap refresh --list git-ubuntu
<rbasak> All snaps up to date.
<zyga> hmm?
<zyga> rbasak: what were you hoping to see?
<zyga> rbasak: note that the store keeps a copy of every revision
<rbasak> Perhaps this is the particular case that's confusing? "All" doesn't make sense here. "This snap is up to date." would perhaps be clearer in hinting to me what the command actually does.
<Chipaca> mmmm
<Chipaca> this one might be even more interesting
<rbasak> Hard to translate possibly though
<rbasak> (for i8n etc)
<Chipaca> rbasak: if --list is given, the argument is ignored completely
<Chipaca> I'd posit that that's a bug :-)
<rbasak> Ah. Yes :)
<Chipaca> either error, or filter
<Chipaca> hmmm hmmm
<Chipaca> i'll error for now (making it filter would be either client-side (ew), or a lot of work on the daemon (ugh))
<Chipaca> TBF --list is one of the weird ones that we're pretty sure doesn't "go" there (like --times), but we haven't found the right place yet
<Chipaca> rbasak: are you rbasak on github as well?
<rbasak> Chipaca: no, "basak"
<Chipaca> k
<rbasak> Chipaca: how about --dry-run or similar, instead of --list?
<rbasak> The same information, but from a "what I would do" perspective which is easier semantically I think since that concept is pretty common rather than being snap-specific.
<Chipaca> rbasak: I'm used to --dry-run and it feels more natural to me, but the output would be wrong (unless refresh did the same)
<Chipaca> â¦ or does it
 * Chipaca hasn't looked at 'refresh' in a while :)
<rbasak> I don't expect --dry-run to produce exactly the same output
<rbasak> But I understand why others might
<Chipaca> I like rename's behaviour of --dry-run being --verbose
<Chipaca> OTOH, we _could_ write a --dry-run that just printed nearly the same as a plain refresh, but with "would be updated" instead of "updated"
<Chipaca> er, refreshed
<Chipaca> core (edge) 16-2.35.2+git954.b1b6b89 from Canonicalâ available for refresh
<Chipaca> that sort of thing
<Chipaca> all the info you want is there
<Chipaca> hmm
<Chipaca> niemeyer: you around?
<mup> PR snapd#5902 opened: cmd/snap: tweak UX of snap refresh --list <Created by chipaca> <https://github.com/snapcore/snapd/pull/5902>
<Chipaca> rbasak: ^
<rbasak> Thanks!
<Chipaca> niemeyer: what do you think of moving from 'snap refresh --list' with its 'snap list'-like output (that's slightly alien-feeling),  to a 'snap refresh --download' that would print summaries very similar to what 'snap refresh' actually does?
<Chipaca> er
<Chipaca> er
<Chipaca> niemeyer: snap refresh --dry-run
<Chipaca> brain fart there
<Chipaca> clearly i should eod
<mvo> rbasak: does https://forum.snapcraft.io/t/git-ubuntu-issue-with-core-2-35-2/7668 clarify things? I tried to summarize the issue we hit, I hope this also answers your question in the commit messages
<niemeyer> Chipaca: No problem, happy to help-by-listening :)
<Chipaca> niemeyer: question stands though :-)
<Chipaca> niemeyer: 'snap refresh --list' is a bit weird, why isn't it 'snap refresh --dry-run'?
<mvo> rbasak: re gawk> awk is "special" in that it does not ship a awk binary but only a postrm script that uses update-alternatives. let me look into this again
<mvo> rbasak: I pushed an alternative PR
<rbasak> mvo: thanks! Will read.
<mvo> rbasak: let me know if anything is unclear, its an unfortunate combination of classic, update-alternatives etc
<rbasak> mvo: that's clear, thanks. I need to EOD now. I'll resume tomorrow. Meanwhile your branch/MP is building a test snap  in CI.
<jdstrand> ogra: part of it has a snap decl. the other part is committed in the review-tools but is not in prod yet
<jdstrand> roadmr: hi! at whatever time is convenient, can you pull r1131?
<mvo> rbasak: ta
<mvo> rbasak: enjoy your eod
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<mup> PR snapcraft#2311 closed: snap: legacy needs to now it is legacy for re-exec <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2311>
<zyga> re
<roadmr> jdstrand: sure thing
<zyga> jdstrand: hey
<zyga> jdstrand: I have two pings for you: one is a quick look on a "input" trigger on udev on an upcoming interface: https://github.com/snapcore/snapd/pull/5897
<mup> PR #5897: interfaces/builtin: add gpio-keys interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
<zyga> jdstrand: and another is extension of the tmpfs detector for sub-directory support https://github.com/snapcore/snapd/pull/5901
<mup> PR #5901: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <https://github.com/snapcore/snapd/pull/5901>
<zyga> nothing urgent
<zyga> jdstrand: the detector is mostly test changes, look at the non-test part of the patch to see what the interesting thing is, I also tried to make the commit message as useful as I could
<zyga> that's all, enjoy your work on the road
<zyga> Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})'
<zyga> another case of that
<zyga> well, for tomorrow
 * zyga EODs
<mup> PR snapcraft#2312 closed: meta: support relocatable prime for path verification (#2287) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2312>
<mup> PR snapcraft#2305 closed: [legacy] pluginhandler: update build should overwrite organize <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2305>
<mup> PR snapcraft#2313 opened: meta: link the icon correctly across filesystems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2313>
<sergiusens> Saviq: want to give that a review? ^
<koala_man> what are my options if I'm unable to reproduce a build failure locally?
<ogra> koala_man, how do you not reproduce it locally ? ... did you use snapcraft cleanbuild to do so ?
<koala_man> Yes. Is the intention that this type of build uses the same kinds of http proxies?
<ogra> no, the intention is that you use the same container setup the builders use
<ogra> not necessarily the proxies
<ogra> does your build fail with a proxy error ?
<koala_man> it fails on 'cabal update' which is supposed to download an index of haskell packages
<koala_man> I'm not sure how to debug it since it works locally, or how to try any random suggestions without pushing junk commits
<ogra> open a forum thread and attach a build log (or a link to a pastebin with a build log)
<ogra> (see the topic for the forum link)
<ogra> if it locally also works when using snapcraft cleanbuild, there is surely somthign wrong
<ogra> typically cleanbuild shows the same errors as the builders and most of the time this points to some missing build-packages entry ... i.e. if you would download something using wget during your build but did not define wget in your build-packages it will fail in cleanbuild
<ogra> or on the build host
<ogra> but it wouldnt fail on your desktop because you have wget already installed
<ogra> this is why i initially asked if you tried cleanbuild
<cjwatson> maybe cabal doesn't honour the usual proxy environment variables
<koala_man> It does. I googled it for a while and found some misc older bugs, but nothing concrete and it's hard to test anything
<cjwatson> do you have a link to a failing build?
<koala_man> here's one with cabal update -v3: https://build.snapcraft.io/user/koalaman/shellcheck/345086
<koala_man> at least I think that's the failing command.
<cjwatson> https://launchpadlibrarian.net/391408584/buildlog_snap_ubuntu_xenial_amd64_0dfd7b5345eb70630bdf6240b06280c5-xenial_BUILDING.txt.gz <- direct link
<cjwatson> koala_man: Could you please file a bug on https://bugs.launchpad.net/launchpad-buildd about that?  Not something I've seen before.
<koala_man> sure
<cjwatson> Certainly something odd there, as it claims to be sending GET http://hackage.haskell.org/packages/index.tar.gz but there's no corresponding log message from the internal proxy.
<cjwatson> Nor from the backend proxy (in our private logs).
<cjwatson> Chances are it's a bug in the internal proxy in launchpad-buildd, since that's the least well-tested code involved, but it's a surprise that this is the first place I've seen it.
<cjwatson> Looks very reproducible given the appropriate setup though, so that'll help.
<mup> PR snapd#5903 opened: overlord/snapshotstate: store epoch in snapshot, check on restore <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903>
#snappy 2018-10-03
<jdstrand> zyga: I commented on 5897 (extensively) earlier today (including the trigger)
<jdstrand> zyga: ack on 5901
<mup> PR snapcraft#2313 closed: meta: link the icon correctly across filesystems <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2313>
<mup> PR snapcraft#2310 closed: nodejs plugin: add support for ppc64el and s390x <Created by anthonyfok> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2310>
<mup> PR snapcraft#2314 opened: nodejs plugin: add support for ppc64el and s390x (#2310) (#2310) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2314>
<mup> PR snapcraft#2304 closed: project loader: remove remote parts support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2304>
<mborzecki> morning
<zyga> good morning
<zyga> jdstrand: thank you on both, looking at feedback
<zyga> hey mborzecki
<zyga> tests look reddish today
<mborzecki> zyga: hey
<zyga> + quiet zypper --gpg-auto-import-keys refresh
<zyga> <kill-timeout reached>
<zyga> hmmm :/
<zyga> and then
<zyga> more openSUSE repo woes https://www.irccloud.com/pastebin/1Xu1svZW/
<mborzecki> hmm --non-interactive
<mborzecki> we don't pass it do we?
<zyga> Download (curl) error for 'http://download.opensuse.org/update/leap/42.3/non-oss/repodata/b95bdb6d60aafb004e5486f977be7f0271423a08250b846de8fbd842d2c0a87a-primary.xml.gz':
<zyga> Error code: HTTP response: 500
<zyga> Error message: The requested URL returned error: 500 Internal Server Error
<zyga> it's the server side
<zyga> well
<mborzecki> fwiw that url is timing out locally too
<zyga> ok, if this persists during the day we need to disable opens use
<zyga> oh, we disabled 18.04 AFAIR
<zyga> we should keep track of those
<zyga> ok, time to look at 18.10 live issues
<Chipaca> good morning peeps
<zyga> good morning Chipaca
<zyga> IRC is splitty this morning
<zyga> and openSUSE archive is not responding
<zyga> but otherwise things are fine
<zyga> my cosmic download will finish tomorrow at this rate :/
<zyga> (it's raining, LTE speed is very low now)
<Chipaca> boo to opensuse
<Chipaca> makes me feel we should have a control panel thing for skipping tests
<Chipaca> also a cache for spread
<Chipaca> boo
<zyga> that would be great
<Chipaca> a cache for spread where things expire after ~5 days, where you look up with a git hash and get back a list of everything that passed
<Chipaca> and then spread just skips those
<Chipaca> what could go wrongâ¢
<zyga> schedule ;)
<mborzecki> https://github.com/snapcore/snapd/pull/5904 could we land this?
<mup> PR #5904: spread: put openSUSE to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5904>
<zyga> yes
<zyga> Chipaca: ^
<mborzecki> yay
<mborzecki> Chipaca: thanks!
<mborzecki> hm mup is somewhat quiet today
<zyga> split
<mup> PR snapd#5904 closed: spread: put openSUSE to manual <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5904>
<mborzecki> maybe
<degville> Chipaca: yep, that makes sense.
<Chipaca> degville: (the biggest tell used to be that I called the big white thing in the kitchen the ice chest, but I taught myself out of that one)
<degville> ahahaha!
<mborzecki> zyga: hm so requiring network-online.target comes back to haunt us
<zyga> but didn't we drop that
<zyga> or is my memory backwards/
<mborzecki> wasn't there a PR to dro that?
<mborzecki> iirc someone from ce team opened it
<zyga> right, I think there was one
<zyga> but we don't change existing unit
<zyga> so :/
<mborzecki> https://github.com/snapcore/snapd/pull/5746 ?
<mup> PR #5746: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746>
<zyga> so either not released yet
<zyga> or released but people did not update
<Chipaca> this is more a "make all service files generated" coming back to haunt us, fwiw
<Chipaca> or rather, the lack of doing that :)
<zyga> yeys
<zyga> or at least managed with Ensure-like manner like security code is
<zyga> (imagine how terrible it would be if we had not done it that way)
<mborzecki> so even if people refresh the core they won't see it fixed
<zyga> correct
<mborzecki> they'd have to do eg. snap disable/enable as a workaround
<Chipaca> mborzecki: hope they're not ssh'ing in to do that
<mborzecki> hahaha
<mborzecki> something fishy, NetworkManager is not a snap in a desktop installation, is it?
<zyga> https://status.opensuse.org/
<zyga> mborzecki: no, no it should not be a snap (yet)
<pedronis> no, I expected  lxd + network manager both as snaps, not to be super common, unless there is some device setup like that for reasons
<mborzecki> pedronis: why would the store send an error for a snap what was send in current snaps but not asked for in a refresh/install action?
<pedronis> mborzecki: it shouldn't afaik, I would hope the issue is something else
<pedronis> mborzecki: we should be doing that all the time
<pedronis> any snap refresh foo
<pedronis> would do that
<pedronis> or I'm not understanding what you wrote
<mborzecki> pedronis: i get a segfault right here https://github.com/snapcore/snapd/blob/master/store/store.go#L2296 which is missing a check (alredy got a fix for it), but added some debugging around that
<mborzecki> pedronis: and i'm getting store.go:2302: refresh error of snap "test-snapd-auto-aliases_foo", instance key 7Q1OfI5JLwQMvR4LXoToCw1srmPjnu7z:d3ZayHx_juNBYOCHyKqGCggvrQN-rSGgFeOYyIJOScw, but not asked for? error: duplicated-snap The Snap is present more than once in the request.
<mborzecki> pedronis: that's when i tried to install some other snap
<pedronis> mborzecki: well, as I said parallel installs are not supported
<pedronis> by the store
<pedronis> anyway that place is more like the store returned a result for a snap that was only in current
<pedronis> and not in any action
<mborzecki> pedronis: yes
<mborzecki> pedronis: though i don't recall it doing that, otherwise i'd notice i can't install any snaps
<mborzecki> (from the store obviously)
<pedronis> it shouldn't in the normal case
<pedronis> but in your situation it does
<pedronis> I would need to see the json to say exactly if it store is being unreasonable
<Chipaca> gasp
<pedronis> yea, the store is a bit wrong here
<Chipaca> bits of our tests still have snapname.developer in them
<wgrant> pedronis: Howso?
<pedronis> it's returning an action-like error for something that is only in context
<wgrant> pedronis: Oh, is it in results rather than error-list?
<pedronis> yes
<wgrant> Right, can someone file a bug?
<pedronis> will do
<wgrant> Thanks
<mborzecki> pedronis: https://paste.ubuntu.com/p/QGXfB9FPBt/ there you go
<pedronis> mborzecki: yea, what I expected, thanks
<mup> PR snapd#5905 opened: store: gracefully handle unexpected errors in 'action' response <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5905>
<mborzecki> pedronis: Chipaca: ^^
<mup> PR snapd#5906 opened: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
<mup> PR snapcraft#2315 opened: tests: use mocked plugins for list-plugins <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2315>
<Chipaca> hoping for a second review on #5903
<mup> PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903>
<Chipaca> (I've got a followup already ready to go)
<mup> PR snapcraft#2316 opened: storeapi: Use structured data for the conflicted current value <Created by sparkiegeek> <https://github.com/snapcore/snapcraft/pull/2316>
<mup> PR snapd#5902 closed: cmd/snap: tweak UX of snap refresh --list <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5902>
<mborzecki> Chipaca: can you take a look at https://github.com/snapcore/snapd/pull/5898 ?
<sparkiegeek> sergiusens: o/
<mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5898>
<Chipaca> mborzecki: probably yes
<mborzecki> Chipaca: it's aliases :)
<Chipaca> give me a sec to save state
<mborzecki> Chipaca: sure, thank you!
<pstolowski> niemeyer: pushed new changes to https://github.com/snapcore/snapd/pull/5759 and commented, let me know what you think
<mup> PR #5759: ifacestate: implementation of defaultDeviceKey function for hotplug <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5759>
<pstolowski|lunch> niemeyer: ah, and i think i missed part of your suggestion regarding including attribute names in the key to avoid collision; will address this
<zyga> is cdimage.ubuntu.com slow for everyone or just me?
<zyga> I'm getting 50KB/s roughly
<Chipaca> I have no idea what veeam is, but I already don't like it
<popey> zyga: getting 7MB/s here
<zyga> sigh , thanks
<zyga> I rebooted my router
<Chipaca> zyga: you don't have an implementation of tempdir from snap-update-ns etc, right?
<zyga> tempdir?
<zyga> I don't think we use any apart from stdlbi
<zyga> *stdlib
<Chipaca> zyga: yeah me neither
<zyga> what do you need?
<Chipaca> zyga: vvv
 * Chipaca prods mup
<mup> PR snapd#5907 opened: overlord/snapshotstate: chown the tempdir <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5907>
<Chipaca> zyga: ^^^
<Chipaca> zyga: I'd love to have a mktempdir that uses O_TEMPDIR :)
<zyga> Chipaca: note that the O_TMPFILE thing is only suitable for files, not for directories AFAIK
<Chipaca> yeah that
<Chipaca> oohhhhhh awwww
<Chipaca> boo
<zyga> right?
 * Chipaca manpages
<zyga> software sucks
<Chipaca> nah, 's ok
<Chipaca> software i can fix
<zyga> fg
<zyga> heh
<zyga> I _just_ got this message from you: zyga: I'd love to have a mktempdir that uses O_TEMPDIR :)
<zyga> ordering FTW
<Chipaca> wut
<Chipaca> your network is in distress
<Chipaca> irc can't do out-of-order, so your client is loopy
<zyga> are you sure?
<zyga> I just noticed it appearing mid log
<Chipaca> zyga: it's a tcp connection
<Chipaca> a single one
<zyga> hohoh
<zyga> Chipaca: something cool to show you
<Chipaca> oh dear
<zyga> http://paste.ubuntu.com/p/Y2zpfGNkQg/
<zyga> while my network sucks at pulling ISOs
<zyga> I'm going back to past PRs
<zyga> remember this one?
<zyga> evil genius or evil madman?
<mborzecki> anyone know of a simple snap that has services, is in the store and is not lxd?
<zyga> xkcd-webserver?
<mborzecki> oh, let me try that
<mborzecki> edge is really broken now without https://github.com/snapcore/snapd/pull/5905 if there's more than instance of a given snap in the system
<mup> PR #5905: store: gracefully handle unexpected errors in 'action' response <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5905>
<Chipaca> mborzecki: what will happen if you run 'snap alias foo_bar.baz baz' with a core that doesn't understand instances?
<mborzecki> Chipaca: you won't have foo_bar installed
<Chipaca> s/core/snapd/ i meant
<Chipaca> right, so there's no way to get a SnapSetup that uses a snap name instead of the instance name
<Chipaca> that wasn't created when they were equivalent
<Chipaca> bah
<mborzecki> yes, _ was also invalid for snap names
<Chipaca> mborzecki: what happens today, without this pr, if you have instances enabled and install foo and foo_bar and try that alias command?
<noise][> mborzecki: bear in mind there is store work still being done to support parallel
<Chipaca> mborzecki: and, what happens if you have a snapd running with this pr, run 'snap alias', but before it can run you restart snapd into one that knows about instances but not instances for aliases?
<Chipaca> s/run 'snap alias'/run 'snap alias foo_bar.baz baz'/
<zyga> Chipaca: I pushed the changes to https://github.com/snapcore/snapd/pull/5869 - please have a look
<Chipaca> no
<mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
<mborzecki> Chipaca: you mean the aliases PR?
<Chipaca> mborzecki: y
<zyga> it's generic and gives pretty useful error messages
<mborzecki> Chipaca: so the missing instancekey in snapsetup in aliases was benign, the code operated on snapsup.InstanceName() which gave the same results if you had RealName: "foo_bar" and {RealName: "foo", InstanceKey: "bar"}
<mborzecki> i had a change somewhere which triggered panics if snapstate or snapup had name with _ but instancekey was unset
<mborzecki> but this is probably only appropriate for tests, not the end users
<Chipaca> agreed
<Chipaca> mborzecki: ok. I couldn't spot a way for it to break beyond erroring, that is, I couldn't find a way to make it get you an alias on foo.baz when you asked for foo_bar.baz or viceversa
<Chipaca> which is why I +1'ed
<mborzecki> yup
<Chipaca> but, thought I'd ask
<Chipaca> as these things make my hair wobble
<mborzecki> fwiw, the spread tests were written (somewhat deliberate) before the code change
<mborzecki> and were passing :)
<Chipaca> mborzecki: right, but you don't have a spread test for "stop snapd just before this change gets run, and switch it to this other one because life is pain"
<zyga> FYI: I re-opened the PR that adds a spread test showing how layout migration may fail due to leftovers
<zyga> https://github.com/snapcore/snapd/pull/5908
<mup> PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
<zyga> to make it easier to see what happens with the bug fix
<mup> PR snapd#5908 opened: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
<Chipaca> mostly a note to self: we should try to make commands in a family point to the other ones
<Chipaca> e.g. have 'snap aliases' mention alias, unalias, prefer
<Chipaca> etc
<zyga> note to chipaca, you should make notes to self mention other people so that they remind you of your notes to self ;-)
<Chipaca> not necessarily all in all of them, but try to make it non-disconnected
<zyga> but yeah
<Chipaca> zyga: when they're serious, I make notes to niemeyer and then EOD
<Chipaca> like 'snap refresh --dry-run' yesterday
<zyga> LOL
<zyga> it would be nice to have a common theme (e.g. how they are worded or introduced) for such hints
<Chipaca> speaking of hints, I created a label for snapshot prs, because that's how i roll now
<zyga> Chipaca: review on https://github.com/snapcore/snapd/pull/5906
<mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
<Chipaca> zyga: I have a review in my review!
<zyga> refresh
<Chipaca> oh noes
 * Chipaca refreshes again
 * zyga stops now ;)
<zyga> sorry, your icon triggered me ;)
<Chipaca> it's not even on that PR, but ok :)
<mup> PR snapd#5909 opened: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/5903#pullrequestreview-161136203
<mup> PR #5903: overlord/snapshotstate: store epoch in snapshot, check on restore <ð¸ó Ì»> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5903>
<mup> PR snapd#5903 closed: overlord/snapshotstate: store epoch in snapshot, check on restore <ð¸ó Ì»> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5903>
<mup> PR snapd#5910 opened: snapshotstate: restore to current revision <ð¸ó Ì»> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5910>
<Chipaca> laptop just powered off
 * Chipaca worries
<zyga> Uh
<Chipaca> nothing in the logs that i can see
 * zyga -> walk
<Chipaca> anyway, one snapshots PR in, so pushed another
<Chipaca> :-)
<Chipaca> zyga: once snapshots is landed, I'll see what happens if you try to snapshot a broken snap
<Chipaca> zyga: or restore into it
<Chipaca> zyga: and then decide what we want to happen, and write a test for it, and implement it :)
<Chipaca> but, not before it works for the non-broken case
<Chipaca> (we're co slose)
<zyga> My point is that you donât get error
<zyga> You get a snap info
<zyga> And the error is inside the Broken field
<frodus> Hi. I try to make a snap of "Teamviewer version10" by useing Ubuntu 16.04 i386. I have tested that the app it self works before package it. I have made a snap without errors, but when running the snap teamviewer tires to write logfiles to the "non writeable" /snap/teamviewer10/x1/.....   I have heard about $SNAP_USER_DATA but does not know how to use it in my snap to get teamviewer to write in a writeable area. Could anyony point me in the right direction?
<popey> hi frodus. does teamviewer have any environment variables or command line options you can pass it?
<popey> you could set environment variables in the apps section of the yaml, or pass parameters in the command: line.
<frodus> Hi popey. I'll see whay I can find. Is there any other way to acheive this?
<popey> Those are the first ways I'd try
<popey> Maybe it writes logs to the current directory. Perhaps you can make a launcher script which does a "cd $SNAP_USER_DATA" before launching it
<frodus> thanks popey.
<Chipaca> zyga: but do you get a Current
<Chipaca> zyga: and do we want snapshots failing when the snap is broken
<Chipaca> zyga: 'ooh snap broke, better take a snapshot and reinstall it'
<Chipaca> zyga: (and note we'll be taking snapshots automatically -- so now you can't remove broken snaps)
<Chipaca> bah, it's unclear whether the auto-snapshot failing should error the change, or just leave the data
<Chipaca> the latter sounds better; that plus a warning
<zyga> Chipaca: that's a great point actually
<zyga> worth a comment
<mup> PR snapd#5869 closed: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5869>
<mup> PR snapd#5911 opened: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <https://github.com/snapcore/snapd/pull/5911>
<mup> PR snapd#5900 closed: release: 2.36~pre1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5900>
<zyga> jdstrand: a trivial one liner that could use your ack https://github.com/snapcore/snapd/pull/5909
<mup> PR #5909: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
<zyga> Chipaca, mborzecki: a quick review for https://github.com/snapcore/snapd/pull/5908 would be appreciated, for the follow-up fix
<mup> PR #5908: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5908>
<cachio> sergiusens, https://paste.ubuntu.com/p/WTTFZCBHg6/
<cachio> sergiusens, hey,
<cachio> any idea what could be causing this error?
<sergiusens> cachio: build on 16.04 and it will work
<cachio> sergiusens, ok
<cachio> is it any workaound to make it work on bionic?
<zyga> cachio: build it in a container
<zyga> cachio: or use a base: core18 definition
<cachio> zyga, ah, ok
<zyga>  kenvandine: reproduced, investigating
<zyga>  kenvandine debugged
<kenvandine> :)
<mup> PR snapcraft#2317 opened: tests: add spread suite for plainbox plugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2317>
<zyga> kenvandine: fixed
<kenvandine> zyga: awesome, now to get that fix into cosmic :)
<zyga> kenvandine: we could do a distro patch but perhaps not very useful
<zyga> kenvandine: the fix is tiny
<zyga> mvo is not around today but I would love to see this in the next release candidate of 2.36
<kenvandine> zyga: mvo had said he would do a point release with just the fix
<zyga> ah, that's ok
<zyga> so perhaps tomorrow
<zyga> I don't know why he is off today
<kenvandine> yeah, please point him to the fix
<kenvandine> we talked about it yesterday, so it's on his radar
<kenvandine> it's a cosmic release blocker, so it needs to go in
<kenvandine> hopefully he's back tomorrow :)
<zyga> that's great, I'll just focus on landing it
<pedronis> it's a national holiday he said
<zyga> ah great
<zyga> I was worried he's ill
<mup> PR snapd#5912 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5912>
<zyga> kenvandine: ^
<zyga> mborzecki: ^
<zyga> jdstrand: ^
<sergiusens> zyga: he as in Michael? German holiday he mentioned
<zyga> yeah, that's good to know :)
<kenvandine> zyga: awesome
<mborzecki> degville: i've dropped some documentation for parallel installs right here https://forum.snapcraft.io/t/parallel-installs/7679 can you take a look?
<degville> thanks mborzecki! Just seen it - I'll take a look.
<mborzecki> degville: thanks! ping me if you have any questions
<degville> mborzecki: will do, thanks.
<mborzecki> degville: and sorry for the poor man's tables :)
<degville> mborzecki: ahaha! I'll fix them :)
 * zyga -> dinner
<niemeyer> I need to run an errand as well.. back later
<mup> PR snapcraft#2315 closed: tests: use mocked plugins for list-plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2315>
<mup> PR snapd#5913 opened:  daemon: expose snapshots to the API <Created by chipaca> <https://github.com/snapcore/snapd/pull/5913>
<Chipaca> ^^ 1 more R for snapshots (1 more to go!)
<Chipaca> 1 more PR*
<Chipaca> taking a break, now
<zyga> My daughter is 10 years old now.
<pstolowski> i really love snap run --strace
<zyga> Chipaca: still here?
<mup> Bug #1795947 opened: `snap services` should indicate when services are a oneshot <Snappy:New> <https://launchpad.net/bugs/1795947>
 * zyga EODs 
<Chipaca> zyga: yes
<zyga> Chipaca: can you please look at the PR marked as critical
<Chipaca> zyga: will do
<Chipaca> zyga: when i get back from the supermarket
<mup> PR snapcraft#2314 closed: nodejs plugin: add support for ppc64el and s390x (#2310) (#2310) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2314>
<zyga> Thank you
<zyga> I want to backport it for 2.36
<mup> PR snapd#5912 closed: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Critical> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5912>
<zyga> Wooot
<zyga> Thank you
<joelkraehemann> hi all
<joelkraehemann> https://forum.snapcraft.io/t/alsa-cannot-access-devices/7025
<joelkraehemann> ^^ I have the very same problem
<joelkraehemann> Here is my snapcraft.yaml:
<joelkraehemann> https://bazaar.launchpad.net/~jkraehemann/+junk/gsequencer/view/head:/snap/snapcraft.yaml
<joelkraehemann> I have tried all sorts of combination trying to get it up running
<joelkraehemann> but without any success
<ogra> joelkraehemann, https://forum.snapcraft.io/t/reusable-alsa-lib-part/3556/10
<joelkraehemann> I don't want to use pulseaudio at all
<joelkraehemann> ogra: just because you share me the link showing this ^^
<ogra> joelkraehemann, i dont see any reference to pulse in the remote part that post points to https://github.com/diddledan/snapcraft-alsa
<joelkraehemann> pulsify-alsa
<joelkraehemann> Yeah, I was trying this ...
<ogra> not sure what you are talking about ... that remote part definitely doesnt use pulse and just makes sure to build alsa in a snap consumable way
<joelkraehemann> could it be that I have to stage: [- - usr/lib/libasound.so]
<ogra> and there are many snaps in the store using it so i'd expect it to work
<ogra> if you have probs you probably want to talk to diddledan
<ogra> (the author and maintainer of that remote part)
<joelkraehemann> thank you
<ogra> jdstrand, there is a new dashkiosk-client-browser in the store that would appreciate a helping hand to become a release :)
<ogra> (only interested in armhf, you dont need to bother about the other arches if it take extra time)
<ogra> *takes
<joelkraehemann>     stage:
<joelkraehemann>         - -usr/share/alsa
<joelkraehemann>         - -usr/lib/x86_64-linux-gnu/libasound.so
<joelkraehemann> ^^ is there a way to have an environment variable of x86_64-linux-gnu?
<joelkraehemann> I just try to list both x86_64 and i386
<joelkraehemann> I think prior the libs in usr/lib/x86_64-linux-gnu/ caused problems
<joelkraehemann> ogra: Well it does say anymore about pulseaudio but is what it actually does ;)
<joelkraehemann> First my application supports output to pulseaudio
<joelkraehemann> What I want is alsa access and not a wrapper
<joelkraehemann> ALSA provides just some fancy features like low-latency and MIDI device access
<joelkraehemann> So my advice what ever stops you to disable ALSA access, fix it :)
<mup> PR snapcraft#2318 opened: meta: add support for the license field <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2318>
<jdstrand> ogra: done
<jdstrand> and thanks to roadmr for getting r1131 up so fast (it approved r10-r12)
<ogra> jdstrand, awesome, thanks (and roadmr too (in absence))
#snappy 2018-10-04
<zyga> good morning
<Faults> Goooood morning!
<zyga> I need to run an errand
<zyga> Daughter forgot homework
<zyga> Going to school
<pstolowski> mornings
<mvo> hey pstolowski
<abeato> mvo, hey, is the 'connections' stance (gadget.yaml) supported in the current stable core? I'm trying https://paste.ubuntu.com/p/t5dsmHC8Yk/ but does not seem to do anything
<mvo> abeato: let me look, I think it should be supported but let me double check
<mup> PR snapd#5899 closed: tests: shellchecks, final round <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5899>
<mvo> abeato: we added connections in 2.34 so this should work
<abeato> mvo, ok, do you think there is something wrong in my yaml?
<mvo> abeato: hm, this looks correct. what do you see? just nothing?
<abeato> mvo, nothing
<mvo> abeato: and the snapids are part of the seeding and all that?
<zyga> abeato: show me log for snapd please
<abeato> yes, all are in the seed
<zyga> Typically this happens because the plug is removed by snapd
<abeato> zyga, https://paste.ubuntu.com/p/JtmwzBpHy8/
<zyga> Hey everyone
<mvo> hey zyga
<zyga> Is that the complete log?
<abeato> zyga, what I get when I do "snap install my-gadget"
<zyga> Mmm
<zyga> What is the interface that misbehaves?
<mup> PR snapd#5896 closed: snapcraft.yaml: set grade to stable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5896>
<abeato> zyga, serial port
<zyga> Hmmm
<zyga> So you see it in âsnap interfacesâ
<mvo> zyga: do you think #5909 needs a review from jamie? it looks so trivial
<mup> PR #5909: allow network_control to also use /sbin/iw <Created by ogra1> <https://github.com/snapcore/snapd/pull/5909>
<zyga> Probably not
<zyga>  
<abeato> zyga, https://paste.ubuntu.com/p/HVWxNTPYJh/
<mup> PR snapd#5909 closed: allow network_control to also use /sbin/iw <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5909>
<zyga> mvo: I fixed the release blocker for cosmic
<mvo> abeato: are the snaps part of the seeding? do you have a "journalctl -u snapd" after the seeding and snap changes, snap change 2
<mvo> zyga: \o/
<zyga> mvo: we need a back port for the release branch
<zyga> I will prepare one
<mvo> zyga: amazing, is it in master already?
<zyga> yes
<abeato> mvo, zyga hm, found this: https://paste.ubuntu.com/p/TNdQSpZ8jp/
<zyga> 2018-10-03T16:38:36Z INFO gadget connect: ignoring missing slot THBWLoSEcoDOBe1W15W9uHxF8nadSiWn:ttymxc-0
<zyga> gadget ID vs gadget name?
<zyga> feels like either:
<zyga> the slot being removed by sanitize
<zyga> or bug in id / name mapping
<zyga> mvo: https://github.com/snapcore/snapd/pull/5914
<mup> PR #5914: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5914>
<zyga> mvo: I started working on a spread test for this last night
<zyga> but it's a bit complex so I'm not done yet
<abeato> zyga, now that I think about it, there is no actual assertion for the gadget, as when I built the image I used a local gadget snap, while the other are downloaded with the other corresponding assertions
<zyga> abeato: aha
<mup> PR snapd#5914 opened: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/5914>
<abeato> zyga, so I think I need to manually add an assertion for that to be able to test
<zyga> I don't know if this applies but auto-connections are only done when installing with assertions
<abeato> zyga, yeah, makes sense
<abeato> zyga, mvo, thanks now I have enough directions on how to fix this
<zyga> mvo: I tried to review and land things yesterday
<abeato> zyga, can I use a gadget name instead of the ID? would that need an assertion?
<zyga> abeato: I honestly don't know
<zyga> I didn't write the auto-connection for gadget code
<zyga> let me look
<abeato> ok
<zyga> abeato: we resolve snapd ID to snap name
<zyga> abeato: I just realised that unless you have an assertion your snap will not have an ID
<dot-tobias> Can someone help me out with figuring otu why mir-kiosk + chromium-mir-kiosk won't work as described in https://tutorials.ubuntu.com/tutorial/ubuntu-web-kiosk#0 ? Running latest core stable on a pi3, mir-kiosk stable and chromium-mir-kiosk --beta. I also tried various candidate/edge combinations from earlier posts in https://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424/82
<zyga> dot-tobias: sorry, cannot spare the time for that now, perhaps ogra can help?
<abeato> yeah, you need a snap-delcaration for that
<zyga> abeato: one more possibility
<zyga> abeato: look at your state.json
<ogra> dot-tobias, whats exactly your problem ?
<zyga> if there is an existing connection data with the undesired flag set
<zyga> we won't auto-connect
<abeato> alright, will check that
<zyga> abeato: actually, scratch that
<zyga> the error messages you pasted
<zyga> they clearly indicate that the gadget doesn't have the given slot
<zyga> can you paste the gadget's snap.yaml please?
<dot-tobias> ogra: The tutorial states that after installing the two snaps, I should see a fullscreen webpage. Which is not the case. Mir-kiosk's VT is set to 4 (default), but my tty4 just shows a black screen with a tiny rainbow box in the upper right corner.
<ogra> dot-tobias, oh, wait, you said stable ... try with the edge image i think stable does not have all the bells and whistles for graphics support
<zyga> abeato: but I think I also see a bug
<zyga> mvo: when resolveSnapIDToName cannot find a snap declaration it returns ... "", nil
<zyga> no error
<ogra> dot-tobias, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
<dot-tobias> ogra: Ok, you mean edge image for core or just mir-kiosk?
<zyga> empty snap name
<dot-tobias> ogra: Gotcha ð
<zyga> that feels buggy
<ogra> o mean that image :)
<abeato> zyga, https://paste.ubuntu.com/p/B43RYC3Y5w/
<ogra> s/o/i
<zyga> pedronis: ^ AFAIK you wrote that, do you think this is desired?
<mvo> zyga: not even a log message, that looks like we need to fix it
<dot-tobias> ogra: Does that image also support the Pi3B+ already, or do I need to fumble with the firmware files like with the stable Core image? (Just out of curiosity)
<zyga> I'm 99% sure it's sanitisation discarding those slots
<ogra> dot-tobias, ah, it might not, i'm working with sil2100 and ondra_ on getting the B+ to work this week
<ogra> dot-tobias, we bumped the firmware on edge yesterday, but i'm not sure about the kernel yet
<ogra> dot-tobias, though if stable worked for you with just updating the firmware, edge should be similar to what you did manually over there :)
<zyga> abeato: can you show me all the changes again please
<zyga> abeato: unfortunately both serial ports and leds would be allowed by the code in master so it's probably something else
<abeato> zyga, https://paste.ubuntu.com/p/RwYtYnv6nc/
<dot-tobias> ogra: Ok, thanks for the info. Maybe it'll still work ð B+ support for my project can wait a few weeks. Will test the kiosk stuff with a Pi3B in the meantime. Is there a forum topic / sth else to follow along with the B+ progress?
<zyga> abeato: can you find THBWLoSEcoDOBe1W15W9uHxF8nadSiWn in snap declarations known to snapd on that device?
<abeato> zyga, no, it is what I tould you above, this is happening because I built the image wiht a local gadget snap, no assertion
<pedronis> zyga: that's the it in that sentence?
<zyga> pedronis: gadget auto-connect code, specifically the resolveSnapIDToName function
<zyga> it doesn't return an error with the ID cannot be found
<zyga> returns an empty string
<zyga> caller doesn't check for that
<pedronis> I think it was designed like that
<pedronis> we just log don't error
<pedronis> saying the plug or slot doesn't exist
<ogra> dot-tobias, https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509 i'll update that thread once we know it works (my b+ only arrives on the weekend so the turnaround time in testing is a bit slow)
<zyga> but what's the point of attempting to connect ":foo" ?
<zyga> it's equivalent to "system:foo"
<zyga> that's incorrect
<pedronis> zyga: ?
<pedronis> that is handled at a different level
<zyga> I'm saying that it is more than logging, when resolve ... returns an empty string we carry on and attempt to find the slot
<zyga> the slot _will_ resolve empty snap name to the system/core/snapd snap
<dot-tobias> ogra: Great, thank you very much!
<zyga> so if you say "connect $gadget_id:foo" it effectively means, when the gadget assertion is missing, connect system:foo
<zyga> I think that's unexpected
<pedronis> did we change some other code
<pedronis> and miss a test
<zyga> specifically?
<pedronis> in repo
<ogra> pedronis, when using a system user asertion from USB with the USB stick plugged in before first boot, it never creates a password, i have to re-plug the stick to make that happen (works fine if i dont forget to unplug the USB key and only plug it in later)
<zyga> look at ifacestate's handlers.go:1118
<zyga> that just calls repo.Slot, that does auto-detection when slot snap name is empty
<pedronis> zyga: let me look at code
<zyga> in this case it failed because the particular slot name was not something the core provides
<zyga> but I think the semantics is undesired
<zyga> we should treat err != nil and slotSnapName == "" equally
<pedronis> zyga: you are reapeting yourself
<zyga> (same for the plug side)
 * zyga stops
<mvo> ogra: hm, we do have cold-plug code, hrm, hrm
<pedronis> let  me look at ode
<pedronis> code
<ogra> mvo, well, i pre-seed 5 snaps ... that puts the system under heavy load (takes about 20min for first boot (subsequent ones take 30sec)) ... might be related
<ogra> though probably not ... given that it just works immediately when i re-plug ... even if the system is still seeding
 * mvo nods
<mvo> ogra: can you please check "journalctl -u snapd.autoimport.service"
<pedronis> zyga: repo.Slot/repo.Plug don't do that? unless we store core using "" as name there?
<zyga> ah, you are correct, sorry about that
<zyga> ResolveConnect does that
<zyga> but plain Plug/Slot does not
<pedronis> I agree is a bit fragile, but Plug/Slot have been naive like that since forever
<ogra> mvo, there we go ... i guess it iss the order of processing on first boot https://paste.ubuntu.com/p/DzZHMWq9pv/
<pedronis> tbh I don't remember why I didn't write more explicit code
<zyga> pedronis: I think in light of what you said this is correct
<zyga> we should probably error explicitly earlier though, with a clearer error message
<zyga> that is, when either of the resolve things fail
<mvo> ogra: yeah, thats it
<zyga> it's a different thing to say "snap foo has no slot bar"
<pedronis> zyga: that no, we decided not to fail
<zyga> than "cannot find snap with ID ...."
<ogra> mvo, here iss the manual re-plug https://paste.ubuntu.com/p/XvjzMNGYdz/ jut for refrernce
<pedronis> but only log
<zyga> not fail as in abort
<zyga> I'm just saying that the error message is confusing
<pedronis> that was an explicit discussion with gustavo
<zyga> continue there is fine
<pedronis> you mean, make the snapid is wrong error explict
<mvo> ogra: the manual replug worked? I ask because: "Oct 04 07:53:35 dashkiosk systemd-udevd[6850]: Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 1."
<ogra> mvo, well, i'm logged in enough to give you these logss ;)
<mvo> ogra: heh
<zyga> yep, something like this:
<ogra> (timestamps are UTC btw)
<zyga> https://www.irccloud.com/pastebin/giitgNDO/
<mvo> ogra: aha, I get it - this replug you did when you already had the system-usern, right?
<zyga> pedronis: I agree that log + continue is better than error
<mvo> ogra: I think I have an idea what to do about the coldplug case, I need to think a little bit more but I should have something actionable soon
<ogra> mvo, well, it is a virgin boot ... but the key was plugged in during that
<ogra> so yeah, parts might exist already
<zyga> pedronis: perhaps the log could even become a warning to make device makers aware of possibly overlooked log message
<ogra> oh geez !
 * ogra stomps foot
<ogra> Oct 04 07:42:50 dashkiosk dashkiosk-client-browser.dashkiosk-browser[6400]: /snap/dashkiosk-client-browser/9/bin/desktop-launch: line 511: exec: /snap/dashkiosk-client-browser/9/bin/xwayland-dashkiosk-launch: cannot execute: Permission denied
<ogra> how iu hate it when i forget to sset the exec bit for complex to build snaps
<ogra> ARGHGH!!!
<Chipaca> ogra: is that thing referenced by the yaml?
<ogra> Chipaca, "thing" ?
<Chipaca> ah
<Chipaca> desktop-launch
<Chipaca> drat
<ogra> it is, yeah
<Chipaca> ogra: if the yaml said 'run this thinig' directly, you'd get an error earlier
<Chipaca> ideally at build, but we're not there yet
<pedronis> zyga: anyway I don't there is bug, we could improve the logged error (and maybe make the code less fragile if repo changes)
<ogra> i re-wrote it from scratch and forgot to set the exec bit
<zyga> pedronis: agreed
<ogra> Chipaca, ogra@anubis:~/datengrab/appliances/dashkiosk-client-browser:master$ grep command snap/snapcraft.yaml
<ogra>     command: desktop-launch xwayland-dashkiosk-launch chromium.launcher
<ogra> sadly it is only a wrapper in a wrapper
<ogra> thats not anything snapcraft can catch
<ogra> i could add a check to the build ... but if i had thought of that i would also have thought of setting +x ;)
<Chipaca> mvo: mo'in
<Chipaca> mvo: I was having trouble sleeping last night again, so I tried to bring your --format branch up to date
<Chipaca> mvo: remember how I suggested to use the json names for things?
<Chipaca> mvo: I was wrong, I think, unless we want to rewrite the template engine :-/
<zyga> hey Chipaca, thank you for the review last night :)
<Chipaca> mvo: because now instead of {{.Name}} you can do {{.name}}, but instead of {{.InstallDate}} you need  to do â¦ {{ index . "install-date" }}
<Chipaca> mvo: so, I was wrong, let's not do that
<pedronis> Chipaca: then it's a bit annoying though, we would need to document all the names again
<Chipaca> mvo: also: the help needs i18n'ing, and putting it in the struct means we can't, so I was wrong about that as well
<Chipaca> pedronis: this is user-facing documentation though
<pedronis> Chipaca: ?
<Chipaca> pedronis: as opposed to developer-facing
<Chipaca> pedronis: i mean, the only place we've documented (some of!) these names is in the API docs, which aren't user-facing
<pedronis> Chipaca: ah
<dot-tobias> ogra: re mir-kiosk & chromium: Works perfectly on edge image, thank you very much!
<pedronis> Chipaca: btw was this requested by somebody? (me doesnt remember)
<Chipaca> pedronis: yep
<Chipaca> low priority though
<Chipaca> still fun
<pedronis> Chipaca: what do we do with Publisher?
<Chipaca> pedronis: I was going to make the publisher you get in the template have two additional attributes (or methods), for long and short
<Chipaca> right now, if you do {{.publisher}} you get e.g. "{canonical canonical Canonical verified}" or "{H5KLLP4UAnXs3naD386UN9B1IAW3aBZv chipaca John Lenton unproven}"
<pedronis> or ?
<pedronis> ah, sorry
<Chipaca> two examples :)
 * Chipaca pours pedronis another coffee
<pedronis> it's been a rough morning
<pedronis> Chipaca: but it would be Publisher now again?
<Chipaca> yeah, probably
<Chipaca> OTOH
<pedronis> Chipaca: mmh
<Chipaca> another approach would be to have publisher being the above object, and separate ShortPublisher and LongPublisher for the pretty ones
<Chipaca> or, just make publisher be short publisher
<Chipaca> as long is only really for info
<pedronis> bur somebody might want to print the account id
<Chipaca> yes
<pedronis> .publisher.AccountID ?
<mvo> Chipaca: oh, nice, thanks for looking into all of this
<pedronis> .Publisher.AccountID
<Chipaca> I could give publisher a String but still leave its things accessible
<Chipaca> that should work
<pedronis> anyway lots of stuff to document
<Chipaca> whoo yes
<Chipaca> still, we're in no rush for it :)
<pedronis> still wonder the win vs --json or something
<mvo> yeah, maybe the complications are not worth it, even though I really like it
<Chipaca> I agree the biggest burden for us is in documenting everything
<Chipaca> especially because it'll be ongoing
<pedronis> yes
<Chipaca> giving it --json that printed either one object per line, or pretty-printed json-seq, would let people do this using jq
<Chipaca> we could document that instead
<Chipaca> simulate it with: http snapd:///v2/snaps | jq -c '.result | .[] '
<Chipaca> using it would look like: snap list --json | jq -r '.name + "\t" + .version'
<pedronis> which looks painful
<Chipaca> or, | jq -r '"\(.name)\t\(.version)"'  if you'd rather interpolate than build
<Chipaca> a little
<Chipaca> OTOH, it's json, go nuts :)
<Chipaca> OTOÂ²H, I fear all this might be a lot of work when introducing fields
<Chipaca> that is, when introducing the fields argument to list et al, ie having the client choose fields
<Chipaca> we'd either neet to understand the template well enough to know which fields to ask for, or ask for all
<Chipaca> maybe the answer should be 'snap install http, and skip the middleman'?
<pedronis> Chipaca: we would need some support in client for a api passthrough
<pedronis> Chipaca: actually, I don't think I understood your last comment
<Chipaca> pedronis: the one about 'snap install http'?
<pedronis> the one before
<pedronis> about the work to add a field
<ogra> dot-tobias, good to hear, we'll make sure to have the dge stuff tested and released for early next week so you can switch to stable again
<ogra> s/dge/edge/
<mup> PR snapd#5914 closed: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5914>
<Chipaca> pedronis: say 'snap list' only asks for the fields it is going to show
<Chipaca> pedronis: but then we have 'snap list --format'
<Chipaca> pedronis: so either we inspect the format and ask for those fields, or we ask for all the fields, or not all fields will show up
<Chipaca> I like none of these options
<pedronis> Chipaca: ah
<pedronis> with --json we are forced to ask all fields
<Chipaca> TBH for list it's not bad, but you know we'll be asked for 'snap find --format' next :)
<pedronis> yes
<pedronis> that's also why I'm not 100% sure we want to go down this path
<Chipaca> the fourth alternative would be to have --fields
<Chipaca> (which is slightly ew)
<Chipaca> pedronis: yes, about --json. Which makes the "talk to the api" more attractive
<Chipaca> there, of course you need to say fields :)
<Chipaca> or you get the default set, for now
<dot-tobias> ogra: Great, looking forward to it! And thank you for the amazing work you're (all) doing.
<pedronis> Chipaca: anyway I'm sure we could argue that --format is only for list
<pedronis> if you want to play with find talk to the api
<ogra> dot-tobias, well, thanks for using it ... the work wouldnt make  sense without people like you ;) its a win-win ...
<Chipaca> wgrant: the thing that maciej found yesterday about the store returning an error for a snap in context and not action, is there a store-side bug for it?
<pedronis> (I also don't want to help much more bash code come into the world :) )
<Chipaca> pedronis: to the store api, even :-D
<wgrant> Chipaca: https://bugs.launchpad.net/snapstore/+bug/1795841
<Chipaca> wgrant: cheers
<pedronis> Chipaca: there is, I created it
<Chipaca> pedronis: what about zsh code
<Chipaca> :-D
 * Chipaca doesn't use zsh, but a lot of people are happy with it
<pedronis> fish code
<pedronis> anyway snap find --format is a slippery slope (so is snap info --format maybe)
<Chipaca> in uni we wrote a shell we called dijsh, the dijkstra shell, which was different because it had 'goto'
<Chipaca> pedronis: agreed
<Saviq> niemeyer: hey, what was your data processing tool again? the jq-inspired one?
<Chipaca> Saviq: ymes
<Chipaca> Saviq: snap instlal ymes
<Chipaca> no
<Chipaca> jmes
<Chipaca> Saviq: ^
 * zyga breaks for errand
<niemeyer> Saviq: bend
<niemeyer> Saviq, Chipaca: jmes has a number of issues
<niemeyer> Suggest not using it
<Chipaca> ah
<ogra> ppisati, shouldnt this be fix released ? https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1784025 (the toplevel status tricked me to belive it is still not in)
<mup> Bug #1784025: Support for the RaspberryPi 3 B Plus board <linux-raspi2 (Ubuntu):Confirmed> <linux-raspi2 (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1784025>
<ogra> (asuming 4.15 will "just work" anyway)
<ogra> +s
<Chipaca> sorry if you missed me: middle clicked with my palm (grr annoying)
<Saviq> bend!
<Saviq> thanks :)
<mup> PR snapd#5915 opened: allow calling netplan generate/apply after changing its config <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915>
<Saviq> niemeyer: is there a snap?
<niemeyer> Saviq: No, not yet
<ppisati> ogra: yeah, it was fixed in xenial end of July / beginning of August
<ppisati> ogra: bionic had support for the rpi3b+ since its inception
<ogra> ppisati, right, thats what i thought so it should be good to be fix-released
<ppisati> ogra: uhm, there's a script that does that, let me ask
<ppisati> ogra: the xenial side is marked as fix released
<ppisati> ogra: bot sure why the 'main' part is still confirmed
<ogra> yeah, just not the toplevel one
<ogra> prob is that in a bug search only the toplevel shows up
<mvo> zyga: thanks for your layouts typo detection backoprt pr. one comment https://github.com/snapcore/snapd/pull/5911#discussion_r222581386 - I merge it now (writing here so that the comment won't get lost in the merge)
<mup> PR #5911: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <https://github.com/snapcore/snapd/pull/5911>
<mup> PR snapd#5911 closed: snap: detect layouts vs layout in snap.yaml (#5869) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5911>
<abeato> zyga, mvo fyi connections worked after providing assertions for the snap :)
<zyga> That is great to know abeato
<zyga> mvo: checking
<zyga> mvo: we looked at that
<zyga> It would require changing yaml package
<zyga> We = Chipaca and me
<mvo> zyga: aha, ok. thanks for this
<mvo> abeato: yay
<zyga> I think it is a good idea
<zyga> Just needs more wor
<mup> PR snapd#5916 opened: data: run snapd.autoimport.service only after seeding <Created by mvo5> <https://github.com/snapcore/snapd/pull/5916>
<mvo> ogra: the auto-import issue you reported earlier should be fixed with this: -^
<ogra> yeah, just saw the mnail pop in here
<zyga> re
<Chipaca> mvo: zyga: it would actually require work in the unyamler of the containing struct
<Chipaca> which is doable, but â¦ this way is not super clean, but is ingenious in its simplicity
<Chipaca> the other would feel a lot like spooky action at a distance
<zyga> Chipaca: yeah
<zyga> I'm happy I got away with one type :)
<zyga> so overall, with the patch size, it's great value for diff :)
<zyga> ok
<zyga> back to overlayfs
<jamesh> is there anything more that needs to be done to get https://github.com/snapcore/snapd/pull/5271 merged?
<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>
<thresh> good morning
<thresh> should I file a bug so https://forum.snapcraft.io/t/unknown-syscall-when-running-an-18-04-built-snap/7094/9 would get fixed?  (re: statx whitelisting in core18)
<thresh> or is it already filled out?
<jamesh> I think it all the pending review comments have been addressed, and spread tests are passing
<Chipaca> thresh: was that one about statx?
<Chipaca> zyga looked at that
<zyga> jamesh: hey
<zyga> jamesh: looking
<zyga> no, I think it is all good
<jamesh> zyga: thanks
<zyga> 2.36 material?
<thresh> Chipaca, yeah
<zyga> jamesh: is it ready to be in the release today?
<jamesh> zyga: I think so.  I think all the perf issues are addressed
<zyga> mind if I squash-merge it?
<jamesh> whatever is easiest for you
<zyga> cool, let me do that and prepare a back port then
<Chipaca> zyga: do we want such a big thing in so close to release?
<zyga> this is a question for mvo in the release branch
<Chipaca> ah, true
<Chipaca> ok
<zyga> jamesh: btw, Gustavo asked about "portals-missing"
<Chipaca> zyga: after that, could you update thresh on the statx thing?
<zyga> ah, sorry
<zyga> I misread the statement in the PR
<zyga> LGTM
<zyga> Chipaca: yes
<jamesh> niemeyer added the 2.36 milestone to the PR, so presumably he's okay with it
<Chipaca> AFAIR it was something like: qt said no to a patch, seccomp said the same, so we're SOL?
<Chipaca> i might've misunderstood though
<mup> PR snapd#5271 closed: cmd/snap: attempt to start the document portal if running with a session bus <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5271>
<zyga> thresh: no update on our side but Qt has agreed to remove statx from qt itself until glibc supports it explicitly, then it should be only used when more recent seccomp is used
<thresh> oh that's nice
<zyga> thresh: there are plans to improve the situation for older systems but it's not really ready yet
<zyga> thresh: in the meantime we will add statx to our profiles and, if you have recent seccomp, it will be allowed
<zyga> the plan is to use snap-seccomp from core as a low-tech solution
<zyga> and eventually transition, perhaps, to in-house profiles
<zyga> but that's not the immediate future
<thresh> zyga, and by "qt agreed" you mean ubuntu packaging or upstream qt?
<zyga> upstream qt
<thresh> thakns!
<thresh> err thanks!
<Chipaca> zyga: they said no to a patch, but agreed to fix it?
<Chipaca> or did i get that bass-ackwards?
<zyga> Chipaca: they said no to a small patch but agreed to postpone using the feature until glibc ships it
<zyga> then presumably seccomp is fixee
<Chipaca> ah
<Chipaca> so what does thresh do?
<zyga> not sure
<mup> PR snapd#5917 opened: cmd/snap: attempt to start the document portal if running with a sessâ¦ <Created by zyga> <https://github.com/snapcore/snapd/pull/5917>
<zyga> jamesh: backport pushed
<zyga> mvo: when do you plan to make the next point release? today?
<thresh> I think glibc 2.28 added statx
<thresh> I'm going to poke KDE Neon folks to remove statx support from their Qt build meanwhile since that's the one I'm using
<zyga> and, perhaps by coincidence, we can support statx there
<thresh> thank you for the update, much appreciated!
<zyga> thresh: sorry it's not perfect, I'll propose the change to enable statx in cosmic
<thresh> np no software is perfect zyga
<Chipaca> except ed
<thresh> no grave bugs with 16.04-based snap yet, too, so it's R&D more or less
<zyga> thresh: https://github.com/snapcore/snapd/pull/5918
<mup> PR #5918: many: allow using statx by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5918>
<mup> PR snapd#5918 opened: many: allow using statx by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5918>
<zyga> mvo: ^ I marked this as 2.36 candidate
<zyga> mvo: we don't have google support for cosmic yet, right?
<zyga> mvo: only qemu/autopkgtest?
<Chipaca> zyga: looks like it
<Chipaca> zyga: but I think we use the standard images? maybe just adding the stanza works :-)
<Chipaca> cachio would know better though
<zyga> mmm, perhaps
<zyga> I'll double check with qemu image and chat with cachio about adding one
<zyga> cachio: can we get a 18.10 image in google? it would help with testing
<cachio> zyga, yes
<cachio> zyga, I'll create it today
<zyga> splendid, thank you!
<cachio> zyga, np
<Chipaca> mvo: was your "this looks fine" on #5907 a +1?
<mup> PR #5907: overlord/snapshotstate: chown the tempdir <Simple> <ð¸ó Ì»> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5907>
<mup> PR snapd#5919 opened: overlord: don't make become-operational interfere with user requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5919>
<Chipaca> pedronis: why does become-operation being retried imply other things don't need to conflict with it?
<pedronis> Chipaca: because it actually doesn't change any snap, the retry means that if it's relevant snap goes way too bad
<pedronis> we will retry
<pedronis> that logic doesn't apply to anything else
<zyga> can someone with forum edit powers go and fix formatting on this post please: https://forum.snapcraft.io/t/snap-from-jar/5529/43
<mup> PR snapd#5907 closed: overlord/snapshotstate: chown the tempdir <Simple> <ð¸ó Ì»> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5907>
<mvo> Chipaca: it was a +1, just watned to wait for the answer about my tests question
<Chipaca> mvo: thanks :)
<Chipaca> pedronis: ok
<pedronis> Chipaca: master is broken with a shellcheck error
<pedronis> I suppose something that landed recently has a shellcheck error that wasn't spotted
<pedronis> when it landed
<Chipaca> pedronis: fixing
<pedronis> Chipaca: to be clear, not your fault, but I know you are into shellcheck
<pedronis> or so I vaguely remember
<Chipaca> :)
<Chipaca> pedronis: the shellcheck spread test, or the shellcheck static check?
<pedronis> Chipaca: https://travis-ci.org/snapcore/snapd/jobs/437115506
<Chipaca> the spread shellcehck
<Chipaca> looking
<pedronis> thx
<pedronis> mvo: my small fix is red because of that ^
<mvo> pedronis: looking
<pedronis> mvo: Chipaca is fixing I think, but means master is red atm
<mvo> ta
<Chipaca> yes
<Chipaca> mvo: the problematic pr is the portal activation one :)
<Chipaca> which should've been merged with master before doing that last merge
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> an easy fix
<mvo> Chipaca: we can enforce in GH that things must be up-to-date before merging but that will be a burden of its own
<Chipaca> not worth it imo
<Chipaca> how often do we break master because of this?
<Chipaca> mvo: niemeyer: should I merge #5888, or should I close it?
<mup> PR #5888: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>
<mup> PR snapd#5920 opened: tests/main/document-portal-activation/task.yaml shellcheck fix <Created by chipaca> <https://github.com/snapcore/snapd/pull/5920>
<Chipaca> pedronis: mvo: ^ fix
<mvo> Chipaca: thank you
<pedronis> mvo: I'll need to backport my fix to both 2.35 and 2.36 (once we can land it)
<popey> zyga: should opensuse 15.0 work? (it doesn't for me). https://docs.snapcraft.io/core/install-opensuse
<popey> it says "Repository 'snappy' is invalid" when I add it on OpenSUSE 15
<popey> (modified the line to use the 15.0 directory from http://download.opensuse.org/repositories/system:/snappy/ )
<mvo> pedronis: its probably just a cherry pick, no?
<mvo> pedronis: if it applies cleanly no need to backport I can just to the cherry picking
<mup> PR snapcraft#2317 closed: tests: add spread suite for plainbox plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2317>
<mup> PR snapcraft#2319 opened: plugins: remove the tar-content plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2319>
<mup> PR snapcraft#2316 closed: storeapi: Use structured data for the conflicted current value <Created by sparkiegeek> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2316>
<pedronis> mvo: hopefully, new tests sometimes give problems
<ackk> hi, I'm trying to use build-snaps to get go 1.11 to build a part, but it seems that the build phase prefers the distro go over the snap one. is there way to change that?
<sergiusens> ackk: what version of snapcraft? AFAIK we had contributions from mvo   to have this fixed
<sergiusens> and that lives on 2.43.1 at least
<ackk> sergiusens, well I'm running cleanbuild so it's using stable I think
<ackk> sparkiegeek, I am using edge here, but not specifying to use edge to cleanbuild
<zyga> popey: not sure, the infra was down lately and the package needs an update that we cannot ship because $reasons (packaging woes)
<ackk> err sergiusens ^
<zyga> popey: I am working on fixing that but with low priority lately
<mup> PR snapcraft#2321 opened: tests: add spread suite for plainbox plugin (#2317) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2321>
<zyga> popey: though with some progress
<popey> ok
<zyga> popey: I see that the download servers are responding as my suse box has successfully updated now
<zyga> but the version of snapd in the repo is old and out of date
<zyga> i have an updated version but it was impossible to build for a while
<niemeyer> cachio: Works?
<zyga> so that's the state
<cachio> niemeyer, yes
<niemeyer> cachio: Sweet
<cachio> niemeyer, tx
<ackk> sergiusens, so I am using 2.43.1
<mup> PR snapd#5921 opened: spread-shellcheck: use threads to parallelise <Simple :smiley:> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5921>
<Chipaca> aw that sucks
 * Chipaca fixes
<Chipaca> #5921
<mup> PR #5921: spread-shellcheck: use threads to parallelise <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5921>
<Chipaca> mucho bettero
<mup> PR snapd#5920 closed: tests/main/document-portal-activation/task.yaml shellcheck fix <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5920>
<Chipaca> pedronis: master fixed ^
<sergiusens> ackk: go plugin or a different one?
<ackk> sergiusens, godeps one
<sergiusens> ackk: support not there yet, mind creating a bug for that?
<ackk> sergiusens, sure. fwiw I tried overriding the PATH before calling snapcraftctl build but it doesn't work
<ackk> sergiusens, https://bugs.launchpad.net/snapcraft/+bug/1796109
<mup> Bug #1796109: godeps plugin doesn't use go from build-snaps <Snapcraft:New> <https://launchpad.net/bugs/1796109>
<sergiusens> ackk: snapcraftctl runs inside snapcraft, so environment is not going to stick
<ackk> I see
<ackk> sergiusens, maybe related, the snap has version: git  and the actual version of the snap comes out as "git"
<sergiusens> ackk: file name or actual version set in the snap? Can I see logs?
<ackk> sergiusens, filename for sure, I'm rebuilding now
<sergiusens> ackk: check prime/meta/snap.yaml, that's what matters
<ackk> $ snap install --dangerous ./candid_git_amd64.snap
<ackk> error: cannot read snap file: invalid snap version "v1.0.0-alpha4+git17.1d2e580-dirty": cannot be
<ackk>        longer than 32 characters (got: 33)
<ackk> sergiusens, oops :) ^
<ackk> but it shows the version is actually ok
<popey> that is quite a version string!
<ackk> popey, well TBF the tag is only v1.0.0.0-alpha4, the rest is from snapcraft
<mup> PR snapd#5922 opened: Revert "spread: put openSUSE to manual" <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/5922>
<sergiusens> ackk: do something like this instead https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml#L68
<ackk> sergiusens, for the internal version?
<sergiusens> ackk: https://discourse-docs.staging.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
<sergiusens> ackk: there are no anchors on there yet, so you will need to hit page down
<sergiusens> or end, to get, to the last section
<ackk> sergiusens, fwiw if I build with snapcraft edge the version is correct
<sergiusens> ackk: using `version: git`? That code has not changed across stable and edge...
<mvo> zyga: hey, I was thinking about the systemd protocol mount error again - you suspected mount itself iirc, I did a small script (http://paste.ubuntu.com/p/Dy95dMFgDq/) that does a load of mounts in parallel but I can't reproduce the failure with this - am I missing something ?
<ackk> sergiusens, could it be because of cleanbuild vs build?
<zyga> mvo: perhaps
<zyga> mvo: I found the bug in C
<zyga> mvo: just didn't have time to wrap that up and propose a fix upstream
<ackk> sergiusens, or because I now committed so now there's no -dirty suffix anymore
<zyga> mvo: I can share the details but perhaps in private
<sergiusens> ackk: which one is which? -dirty shows up when non commited code exists
<sergiusens> ackk: yeah, that would do it
<mvo> zyga: it was about loopctx_find_unused?
<mvo> zyga: sure
<ackk> sergiusens, I mean I made 2 changes from when I only had "git" in the filename, 1) committed changes 2) ran "snapcraft" instead of "snapcraft cleanbuild"
<sergiusens> ackk: the docs I pointed you to allow you to control better what to show and takes (so we do not need to be guessing if folks are using signed tags or not)
<ackk> sergiusens, thanks
<ackk> sergiusens, do you know if the change to support go build-snaps in godeps is only a matter of PATH?
<sergiusens> ackk: yes, the `-` represent how it is solved today in the go plugin and the `+` on how it will work for when using bases https://pastebin.com/zzgDzdxf
<sergiusens> ackk: I would need to sort of just cherry-pick on the original implementation into the godeps plugin for our legacy branch for you to see results today
<sergiusens> ackk: but yes, it is somewhat PATH related.
<ackk> sergiusens, I see
<kyrofa> zyga, do you have any docs on layouts? Gonna work on adding support
<zyga> kyrofa: indeed we have
<zyga> https://forum.snapcraft.io/t/snap-layouts/7207
<niemeyer> zyga: What's the plan for making sure the test mentioned in https://github.com/snapcore/snapd/pull/5912 doesn't get lost?
<mup> PR #5912: interfaces/apparmor: handle overlayfs snippet for snap-update-ns <â  Critical> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5912>
<zyga> niemeyer: I'm working on it since yesterday
<zyga> moving onto spread now
<zyga> (from hacking around on my local system)
<niemeyer> zyga: Cool, thanks
<Chipaca> mvo: should I squash #5096?
<mup> PR #5096: snap: improve error for snaps not available in the given context <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5096>
<Chipaca> wait no
<Chipaca> #5906
<mup> PR #5906: snap, client, daemon, store: use and expose "media" more <Created by chipaca> <https://github.com/snapcore/snapd/pull/5906>
<pedronis> Chipaca: think so
<Chipaca> me too (but i don't like squashes) :)
<Chipaca> ah well
<Chipaca> oh, bah, spread isn't even started yet
<Chipaca> zyga: https://lwn.net/Articles/767547/
<zyga> oooooh
<zyga> ooh
<zyga> I think I need a moment here
<zyga> with those we could throw away 80% of the C / go magic
<zyga> thank you
<Chipaca> zyga: any year now
<zyga> Chipaca: "In this particular case, it turns out that part of the problem is the result of the fact that the container runtime in question is written in Go:"
<zyga> that's true in our case as well
<zyga> anyway, definitely something to read in detail later
<Chipaca> zyga: this being lwn you have links to the lkml threads and all
<Chipaca> zyga: happy reading :)
<mvo> Chipaca: please squash it
<Chipaca> mvo: ack
 * zyga breaks for family time
<cachio> zyga, cosmic image in progress
 * cachio afk
<Chipaca> zyga: what man section should snap-confine be in? and snap-discard-ns? (the latter is in section 5 right now which is Very Wrong)
<Chipaca> this is on Ubuntu,  dunno elsewhere
<Chipaca> also snapd-env-generator in the wrong section
<Chipaca> augh
<pedronis> Chipaca: is that even well defined? they are not path
<pedronis> *on path
<pedronis> Chipaca: anyway it's either 1 or 8
<pedronis> Chipaca: I suppose snap-discard-ns could go in 8
<zyga> Chipaca: 1 perhaps
<zyga> but it's not on PATH so I put it in 5
<mup> PR snapcraft#2321 closed: tests: add spread suite for plainbox plugin (#2317) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2321>
<pedronis> Chipaca: postgres seems to have a bunch of binaries only in /usr/lib but they are under 1
<pedronis> fwiw
<mup> PR snapd#5919 closed: overlord: don't make become-operational interfere with user requests <â  Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5919>
<vidal72[m]> what's ETA for stable core18? roughly
<mup> PR snapd#5923 opened: overlord: don't make become-operational interfere with user requests (2.35) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5923>
<mup> PR snapd#5924 opened: overlord: don't make become-operational interfere with user requests (2.36) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5924>
<pedronis> ok, created the cherry-picks for 2.35/36
<mup> Bug #1796165 opened: seeded snaps never cleaned up. <Snappy:New> <https://launchpad.net/bugs/1796165>
<Chipaca> pedronis: yep. But it's not about /usr/lib or not, it's about 'is this for a user, or for an admin'
<Chipaca> pedronis: (snap is for an admin, in general)
<Chipaca> zyga: 5 is for files, like /etc/passwd, not for tools
<mup> PR snapd#5925 opened: interfaces/docker-support: add rules to read apparmor macros for 2.35 release <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/5925>
<mup> PR snapd#5922 closed: Revert "spread: put openSUSE to manual" <Simple ð> <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5922>
<mup> PR snapd#5905 closed: store: gracefully handle unexpected errors in 'action' response <Simple ð> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5905>
<mup> PR snapd#5918 closed: interfaces/seccomp: allow using statx by default <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5918>
<mup> PR snapd#5898 closed: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5898>
<Chipaca> pedronis: what's up with #5712? seems GTG?
<mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
<pedronis> Chipaca: needs more tests
<pedronis> Chipaca: notice that both branches you just merged had +1 with requests of tweaks from me
<mup> PR snapd#5901 closed: cmd/snap-update-ns: better detection of snapd-made tmpfs <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5901>
<Chipaca> er
<Chipaca> pedronis: one was about findSnapOfManualAlias but and other renames which sounds like a separate concern
<Chipaca> pedronis: in any case sorry :-/
<pedronis> Chipaca: yes
<pedronis> Chipaca: the other one was a fix for the log
<Chipaca> ah drat
<Chipaca> i'd _seen_ that
<Chipaca> :-(
<Chipaca> sorry again
<Chipaca> i should go have dinner and stop breaking stuff
<pedronis> Chipaca: is not breaking stuff, but I also don't want to start voting changes request for small things
<pedronis> to avoid this
<Chipaca> right
<Chipaca> I'm usually more careful
 * Chipaca ~> something to eat
<pedronis> Chipaca: anyway the log fix is throwing a couple of [] in the mix
<mup> PR snapd#5925 closed: interfaces/docker-support: add rules to read apparmor macros for 2.35 release <Created by anonymouse64> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5925>
<mup> PR snapcraft#2319 closed: plugins: remove the tar-content plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2319>
<ijohnson> jdstrand: thanks for merging that docker PR, any idea when the next 2.35 release will have that?
<zyga> Chipaca: can I land 5908?
<mup> PR snapcraft#2308 closed: plugins: remove the copy plugin when using a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2308>
<Chipaca> zyga: what's the .keep file?
<zyga> a placeholder so that we have a directory entry
<mup> PR snapd#5926 opened: store: tweak unmatched refresh result error log <Created by pedronis> <https://github.com/snapcore/snapd/pull/5926>
<Chipaca> ah
<mup> PR snapd#5908 closed: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5908>
<zyga> thanks!
<zyga> I have a follow up now
<Chipaca> zyga: could you review #5926?
<mup> PR #5926: store: tweak unmatched refresh result error log <Created by pedronis> <https://github.com/snapcore/snapd/pull/5926>
<zyga> sure
<Chipaca> zyga: it's  my fault that even exists :)
<pedronis> Chipaca: btw did you squash those PR you merged? they were meant for 2.36 as well
<Chipaca> pedronis: the ones that were tagged, yes
<Chipaca> pedronis: targeted i mean
<zyga> is it just wording change?
<Chipaca> zyga: yes
<zyga> pedronis: I have a way to get non-squashed PRs easily into the release branch
<zyga> a git feature
<zyga> I showed it to mvo a while ago
<zyga> (offtopic: mac spellchecker consistently renames mvo to moo, I think it knows mvo's background ;-)
<pedronis> Chipaca: we need to remember to create the cherrypicks then
 * pedronis -> rest
<Chipaca> pedronis: I'm hoping mvo keeps track of things with the milestone :)
<Chipaca> otherwise, uff
<zyga> Chipaca: I pushed one more fix but I'm not expecting anyone to review it today
<Chipaca> s/hoping/expecting/
<Chipaca> zyga: to who?
 * Chipaca is owl
 * zyga scratches head
<zyga> Chipaca: yes :)
<pedronis> Chipaca: we do have a list of closed stuff
<zyga> Chipaca: we need to review 2.36 milestone closed branches with him
<mup> PR snapd#5927 opened: cmd/snap-update-ns: remove empty placeholders used for mounting <Created by zyga> <https://github.com/snapcore/snapd/pull/5927>
<pedronis> but not sure
<Chipaca> if I were in mvo's position, i'd have gotten through seven cans of kick-butt today, with all these sudden targeted PRs
<Chipaca> just sayin'
<zyga> Chipaca: we need anonymous branch authors ;)
 * zyga needs to go to bed 
<zyga> ttyl guys
<mup> PR snapd#5906 closed: snap, client, daemon, store: use and expose "media" more <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5906>
<Chipaca> cachio: you around?
<mup> PR snapcraft#2322 opened: project_loader: add build-environment part property <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2322>
<mup> PR snapd#5928 opened: cmd: put our manpages in section 8 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5928>
#snappy 2018-10-05
<mup> PR snapd#5926 closed: store: tweak unmatched refresh result error log <Simple ð> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5926>
<mup> PR snapcraft#2318 closed: meta: add support for the license field <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2318>
<mborzecki> morning
<zyga> Hey hey
<zyga> Time to get to work
<mborzecki> zyga: anything interesting happened yday?
<zyga> Hmmm
<zyga> Some things yeah
<zyga> Currently taking the dog out so harder to type
<mup> PR snapd#5923 closed: overlord: don't make become-operational interfere with user requests (2.35) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5923>
<mup> PR snapd#5924 closed: overlord: don't make become-operational interfere with user requests (2.36) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5924>
<mup> PR snapd#5928 closed: cmd: put our manpages in section 8 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5928>
<mborzecki> hm our socket unit files should probably just have `Wants=<mount unit> sockets.target` and we should not use network.target in there
<mvo> mborzecki: indeed
<mborzecki> i'll open a PR
<mvo> ta
<mborzecki> i'll be good to have it cherry picked to 2.36 too
<mborzecki> from what i found in systemd source code, when there's a cycle it'll drop/delete the job(s) that is/are not directly required by the anchor job (the main job that's at the top of transaction chain?)
<mborzecki> i guess if stars align and you're unlucky enough some target may be dropped (network.target maybe?) or nm service/start job, then you'd end up without wifi/eth whatever
<zyga> mvo: are you tracking all the 2.36 PRs for backports?
<mborzecki> good question, mvo should i open backport PRs to 2.36 of #5898 and #5905?
<mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5898>
<mup> PR #5905: store: gracefully handle unexpected errors in 'action' response <Simple ð> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5905>
<pstolowski> mornings
<mvo> mborzecki: I think we can ignore the test one but the other one yes please
<mvo> mborzecki: if its a single commit I can cherry pick
<mborzecki> mvo: please cherry-pick the simple one
<mborzecki> mvo: as for the test one, it has some tweaks/cleanups in the code, so it'd still be useful, i"ll open a PR for that
<mvo> mborzecki: ok
<mvo> mborzecki: cherry-picked
<mborzecki> mvo: ta
<zyga> mvo: should I prepare a chain of backports?
<mup> PR snapd#5234 closed: snap: add `snap list --format=...` option <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5234>
<mvo> zyga: for what exactly?
<zyga> For things I tagged 2.36 and landed in master
<mup> PR snapd#5929 opened: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5929>
<mvo> zyga: let me have a look
<zyga> Ok, please let me know
<mvo> zyga: given a) we need to do a 2.35.3 and b) how much 2.36 prs are tagged I wonder if we should simply take master for ~pre2, we didn't merge anything scary iirc
<zyga> Mmmm, interesting
<zyga> What is the motivation for 2.35.3?
<mvo> zyga: we need a fix for the unionfs issue on the livecd
<zyga> Ah
<mvo> zyga: without that the snaps on the live media do not start
<zyga> Overlayfs
<mvo> zyga: which is release criticial for cosmic
<zyga> But sure
<mborzecki> +1 for ~pre2 from master
<mvo> ok, let me prepare 2.35.3 and then I look at this, until then, no more backport PRs please :)
<zyga> Ok
<ackk> hi, I'm getting the following error when trying to run a command from a snap: cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_zr48qw//lib/modules: No such file or directory
<ackk>  
<ackk> (the same happens to a service in the snap)
<zyga> ackk: this is fixed in master
<zyga> Try beta/edge perhaps
<ackk> zyga, of what?
<ackk> snapd?
<zyga> Yes
<zyga> Well, core snap
<ackk> yeah that worked.
<pedronis> mvo: hi, seems we don't have a 2_35 tag in the forum?
<mvo> pedronis: looking
<mvo> pedronis: I added one now
<pedronis> thanks
<mvo> pedronis: and added it to "clarification on seed.loaded"
<pedronis> mvo: yes, did the same, added 2.36 as well
<pedronis> thank you
<pedronis> :)
<mvo> :)
<Chipaca> morning peeps! welcome to Friday :) how do we close PRs today?
<zyga> Wholesale
<Chipaca> looking at my own PRs: #5879 can use another review
<mup> PR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
<Chipaca> and #5888 also
<mup> PR #5888: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>
<zyga> Iâll help
<Chipaca> wheee :)
<zyga> Just back hurts somewhat today
<Chipaca> zyga: you were fine yesterday before you decided to do this dodge "sleep" thing
<Chipaca> dodgy*
<Chipaca> also, review stuff or I'll make your browsers crash with emoji overload from looking at the pr page
<zyga> Yeah, yesterday was too long
<zyga> Not enough walking
<Chipaca> ah, yeah, that'd suck
<Chipaca> yesterday I went to the gym and thought I'd had a bad day, turns out i was just pushing myself too hard (still got through 600kcal in an hour)
<Chipaca> niemeyer: I got an email telling me you changed the standup meeting, but it looks the same to me. What's different?
<Chipaca> niemeyer: (morning!)
<niemeyer> Chipaca: moin! If I didn't do anything wrong, I just declined today's event
<mvo> niemeyer: he is off today, no?
<niemeyer> Yes, in theroy at least :)
<mvo> heh
 * Chipaca reaches for his get-off-irc-then stick
<Chipaca> niemeyer: :) enjoy
<Chipaca> google calendar is wacko, but holidays are good
<mup> PR snapd#5930 opened: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5930>
<mborzecki> mvo: ^^
<mvo> mborzecki: cool! looking
<Chipaca> zyga: is #5170 ready for re-review?
<mup> PR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<mvo> mborzecki: uh, do we need this for 2.35 as well?
<mvo> mborzecki: thats not a regression, is it?
<mborzecki> hm, i'd say yes
<zyga> Chipaca: I think so but let me double check
<mborzecki> mvo: let me open a PR for 2.35 so that it gets a full spread run
<mvo> mborzecki: uh, ok. that means 2.35.4
<Chipaca> zyga: if so, I'd say @-mention the j of the d strand
<zyga> yes John, it is ready
<zyga> I wanted to get an ack from Gustavo first as s-j is busy lately
<zyga> to avoid re-review if we change direction
<mborzecki> mvo: while at it, i'd like to get the feedback if the change, once in edge, fixes problems people have observed
<mvo> mborzecki: silly question but we remove network-online.target so what did we do that triggered a regression
<mvo> mborzecki: hm, I see we just changed it to network.target
<mvo> mborzecki: ok, but that is no regression, is it? I mean this was broken before
<mvo> mborzecki: (may still be a good idea to do a .4 for this but I want to figure out if we have to because of regression or if its "optional")
<zyga> IMO serious bugs are serious bugs, regression or not
<mvo> zyga: we had this serious bug from day one
<mvo> zyga: well, since we added socket activation
<zyga> let's fix it and move on :)
<mvo> zyga: there is a cost, I'm not saying we shouldn't do it just want to understand the details
<mvo> mborzecki: you have a review, looks great, just one comment
<Chipaca> zyga: #5469 is also blocked on gustavo
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<Chipaca> zyga: and that one's blocking a customer
<mvo> Chipaca: my dotfiles as well
 * Chipaca wants mvo's dotfiles
<Chipaca> I'll auction them at sotheby's or something
<mvo> Chipaca: haha
<mvo> mborzecki: I pushed a tiny addition to your PR
<mvo> mborzecki: (i.e. resolving my comment)
<mvo> mborzecki: after thinking about this I think you (and zyga) are right, this is worth a 2.35.4
<niemeyer> zyga: BTW, to unblock the snap-update-ns work, I suggest simply looking for the presence of a flag file on a good location that only root can write
<niemeyer> zyga: Flag file could be .experimental-snap-update-ns for example
<zyga> niemeyer: yeah, I can just assume it's set for now. It's good enough to move the rest forward. We can discuss the details next week
<niemeyer> zyga: This file is a trivial one-liner anywhere you want to test for it
<zyga> niemeyer: perhaps this can even do away without an experimental flag it if lands after this release
<niemeyer> zyga: as long as we're sure it works
<zyga> yep
<zyga> something like facts could be useful later on though for things we kind of abuse facts for today (like telling snap-confine that a given snap is in classic mode without any way to abuse it)
<zyga> or telling snap-confine what snapd thinks about the distribution directory layout
<zyga> but regardless, for user mounts we can unblock
<mvo> mborzecki: happy to help with the backport of 5930 to 2.35
<Chipaca> niemeyer: if you're not not here, #5469 is the 4th-oldest PR, waiting for your re-review, blocking a customer. Not flagged as urgent though so if you _are_ not here, go away already
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<mvo> mborzecki: aha, its there, nice!
<mborzecki> mvo: from what i understand, adding network.target and being wanted by sockets.target made us move the network target to be reached before 'basic', with defautl dependencies being basic and sysinit, NM which ash Before=network.target + defaults made a cycle
<mvo> mborzecki: aha, that makes sense
<mup> PR snapd#5931 opened: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5931>
<niemeyer> Chipaca: There's no relevant internal or external design changes in there which would greatly benefit from my input (I think?).. if you and the team are comfortable that the change in behavior is correct, I suggest just going ahead
<mborzecki> mvo: full PR to 2.35  ^^
<mvo> ta
<Chipaca> niemeyer: neat. I'll document this by retracting your PR.
<Chipaca> dismissing it even
<mvo> Chipaca: is it land-it-friday today :) ?
<Chipaca> oh yes
<Chipaca> mvo: we hit 50 PRs yesterday
<mborzecki> mvo: 5930 needs your +1 too :)
<Chipaca> mvo: you know how that affects me :)
<mvo> mborzecki: indeed and a second review
<mvo> Chipaca: haha, sounds like a good plan
<Chipaca> niemeyer: now go away and enjoy yourself doing â¦ whatever it is people do out there
<Chipaca> :)
<zyga> mvo: merge everything ;)
<Chipaca> mvo: I'm even using my gh.go thing (which made me merge a bit too overeagerly yesterday, to pedronis's chagrin)
<zyga> Chipaca: wow, the icons on hot plug are ... really nice!
<Chipaca> hehe
<niemeyer> Yes, I'm doing something very important right now by constructing a Minecraft head out of a cardboard box.. lots of focus required :P
<Chipaca> niemeyer: ah. Make sure you get the derp eyes just right.
<Chipaca> niemeyer: otherwise you might accidentally herobrine
<zyga> and we will have to remove him in a point release!
 * zyga wonders who gets Minecraft lore references...
<ogra> did you guys break core ? my edge images just exploded in my face
<zyga> ogra: break core on Friday? what are we, workaholics?
<niemeyer> Yeah, we were trying to break it for a while..
 * niemeyer steps out quietly..
<ogra> avahi cant start anymore https://paste.ubuntu.com/p/RzH4y8TZDm/ and the only snap that got updated on this image was core
<ogra> (the image was feshly built from edge yesterday evening)
<zyga> ogra: and seriously, no idea, does it work if you switch core to stable?
<ogra> on it, waiting for the reboot
<zyga> thank you
<Chipaca> zyga: #5469 GTG at your discretion
<ogra> yes, works fine i can ping the mdns addres again
<mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
<ogra> *address
<ogra> seems whatever landed in edge does not create XDG_RUNTIME_DIR for the app snaps
<zyga> Chipaca: thanks, I think it is file to land
<Chipaca> cool cool
<mvo> ogra: core traveled back in time from edge to 2.35.3
<mvo> ogra: now it has traveld back
<mvo> ogra: but will soon travel again for 2.35.4
<ogra> mvo, well, something broke
<mup> PR snapd#5469 closed: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5469>
<mvo> ogra: yeah
<ogra> btw, is it normal that gadgets never survive delta generation ? all other snaps i push do it fine
<zyga> hmm?
<ogra> Error generating delta: There has been a problem while processing a snap delta.
<ogra>   - Delta service failed to apply delta successfully
<ogra> Falling back to pushing full snap...
<ogra> with snapcrft push
<ogra> *snapcraft
<zyga> no idea but I doubt it's desired
<ogra> k, because i have only seen it with gadgets
<zyga> ogra: look if snap craft leaves a log with the reason for the failure
<ogra> nope, doesnt ... (and i would be surprised, i think thats all happening server side after the upload)
<zyga> no, the delta is local
<zyga> it is a local delta for speeding up the upload
<ogra> ah
<ogra> indeed
<ogra> my brain is kind of friday today :P
<axino> hi
<zyga> hello axino
<axino> o/ zyga
<axino> is this the proper place to ask how to get a snap owned by ~snapcrafters ?
<zyga> axino: I think the forum is the better place
<zyga> perhaps popey can help though
<popey> hello
<popey> axino: which snap?
<axino> popey: a "redis" snap I'm currently building
<popey> axino: have you spoken to the upstream redis people? :)
<axino> popey: heh, I have not :)
<popey> (We'd rather snaps went upstream first, rather than direct to snapcrafters)
<axino> indeed, indeed
<axino> I'll see what I can do
<axino> zyga popey : thanks !
<zyga> Chipaca: do you have a second
<zyga> i see a failure in something that looks like travis job stages
<zyga> would you mind having a look?
<zyga> I know nothing about that
<zyga> https://travis-ci.org/snapcore/snapd/jobs/437096029
<Chipaca> zyga: where?
 * Chipaca clicks
<Chipaca> zyga: is that the right link?
<zyga> twa
<zyga> yes
<zyga> : /home/travis/.travis/job_stages: eval: line 98: syntax error near unexpected token `newline'
<zyga> line 450
<Chipaca> huh
<mvo> I suspect thats from travis itself, no?
<zyga> not sure
<zyga> but looks like it's not a fatal but real proble
<Chipaca> zyga: whatever it is, it seems to be innocuous
<Chipaca> zyga: i see the same error in successful runs
<Chipaca> e.g. https://travis-ci.org/snapcore/snapd/jobs/434561439
<Chipaca> zyga: with any luck the things it's spewing there aren't parts of any key :-)
<Chipaca> i'll dig a little anyway
<zyga> yeah, we just name variables with long hexadecimal names ;)
<zyga> thanks! just something that caught my eye
<Chipaca> zyga: https://github.com/travis-ci/travis-ci/issues/6174
<zyga> wow
<zyga> we must up our use of bug report images
<mup> PR snapd#5929 closed: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5929>
<Chipaca> hmmmmmmmmmmmââââââââââ
<mborzecki> little â ?
<Chipaca> ð¡ð¼
<Chipaca> I wonder if the secure: encoding is brittle in that it needs to be in the exact same place in the yaml for it to work
<Chipaca> OTOH the tests pass, so _something_ is working :)
<Chipaca> I'll try moving them up to the top level later
<mvo> hrm, hrm, it looks like opensuse tests are failing again
<mvo> didn't we put those on manual? curl error 52 when talking to their repo
<mup> PR snapd#5932 opened: spread: put openSUSE to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/5932>
<mborzecki> mvo: yes, in master at least
<mvo> it looks like it got reverted, I think we need it again, right now things are failing and I want to release 2.35.4 :/
<mborzecki> mvo: uh, ok, they were manual in master on wednesday :)
<mborzecki> https://status.opensuse.org/ still partial outage of mirroring infra
<mborzecki> wonder if the page is actually updated
<zyga> mvo: yes but we reverted that
<zyga> mborzecki: yeah, I saw changes yesterday
<zyga> mvo: sorry about that, I flipped it back after seeing good results on my local machine
<zyga> mmm
<zyga> pstolowski: about getHotplugSlots
<pstolowski> zyga: yes?
<zyga> they override any implicit slots
<zyga> as in
<zyga> actually, any slots
<zyga> should we not check that there are no clashes?
<mvo> hrm, also travis is handing out slots really slowly
<pstolowski> zyga: they won't, it's not visible in this PR, but when they are generated i ensure they have unique name (by appending a number if neccessary etc)
<zyga> unique name among what set?
<pstolowski> zyga: but perhaps an extra check + internal error here is a good idea?
<mborzecki> hmm Chipaca degville you install snaps 'on' the system or 'in' the system? because the long and short help message disagree on this
<Chipaca> on, in, to
<mborzecki> pick one basically?
<Chipaca> i don't have a strong reason to pick one over another
<pstolowski> zyga: unique among all existing slots in the repo and all remembered slots for currently missing devices
<Chipaca> maybe degville does :)
<zyga> pstolowski: mm, but here we are presented with _a_ snap
<zyga> we don't know what that snap has beforehand
<zyga> I'd add a check, similar to implicit slots, that ensure we don't overwrite
<pstolowski> zyga: i see what you mean, but this is a system snap, so only implicit + hotplug slots, no?
<zyga> + whatever is defined in snap.yaml :)
<pstolowski> hmmm do we actually do/support that?
<pstolowski> zyga: ok, i'll check that, thanks for the remark!
<zyga> thanks, I'm reading the rest
<ogra> sil2100, your latest edge image seem to not have the latest pi3 gadget (i can sadly currently not check the gadget in the sstore atm, there was an issue when mvo tried to switch me over from @ubuntu.com to @canonical.com) can you re-build the edge image and make sure at least rev 27 of the gadget is in ?
<ogra> sil2100, ondra tested on the b+ and a locally built image works fine, but the one on cdimage seems to still have rev 22
<sil2100> ogra: wait, how is that possible? I checked the manifest and it said 27, as per my e-mail
<sil2100> Is the manifest wrong?
<sil2100> We build edge images daily btw.
<ogra> dunno ... one sec
<ogra> http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz
<sil2100> http://cdimage.ubuntu.com/ubuntu-core/16/20181005/ubuntu-core-16-armhf+raspi3.manifest
<sil2100> ogra: the images in the 'edge' directory haven't been updated since beginning of the year
<sil2100> http://cdimage.ubuntu.com/ubuntu-core/16/current/
<sil2100> This is what should be used
<ogra> ouch
<ogra> we should clean that up then ;)
<sil2100> Yeah, not sure why it's so confusing!
<sil2100> Need to poke Steve next week why it's like that ;p
<sil2100> (maybe there's some purpose for that, or maybe something broke that was supposed to use the edge/ directory)
<ogra> sil2100, there was initially ... websites had hardcoded links that needed to persist but i think thats bogus now
<ogra> o we hould clean up or at least set proper channel links there
<ogra> *so
<degville> mborzecki, Chipaca: sorry, only just seen this. I think I have a slight preference for *on* - but no strong feelings. You usually say 'I put Firefox on the computer' so it kind of makes sense that we keep to that casual usage.
<zyga> it depends if the Firefox is quiet and doesn't move much, in that case you really have to put it in the computer and screw the side door tightly
<Chipaca> see, this is why i don't have a preference, i'm still using chrome
<cachio> Chipaca, hey
<zyga> if you put chrome on your Firefox you may lose warranty
<zyga> it makes the fur sticky
<cachio> did you ping me yesterday?
<degville> The teenage years were tought, but my Firefox seems to be finally past that stage.
<degville> s/tought/tough
<Chipaca> cachio: I did, but it's no longer relevant
<Chipaca> now I'm worried for zyga's kids when they teen
<cachio> Chipaca, hehee
<cachio> ko
<zyga> Chipaca: technically they now are
<zyga> Chipaca: wanna be afraid more?
<zyga> I may become a grandpa in the next 15 years
<Chipaca> zyga: I don't need flags to Unlinkat, fwiw
<zyga> no?
<Chipaca> nope
<zyga> I'm looking forward to one to simplify some code
<Chipaca> only flag Unlinkat knows today is AT_REMOVEDIR, which I don't want
<zyga> right, that's the one I want
<Chipaca> hehe
<Chipaca> sys/unix's Unlinkat does have that
<Chipaca> fwiw
<zyga> go itself has it
<zyga> just doesn't expose it
<zyga> I really don't like that logic
<zyga> it's either sys call or stdlib
<zyga> but in golang,it's a bit of both
<Chipaca> zyga: #5933
<zyga> mmm
<mup> PR #5933: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>
<cachio> mborzecki, hey
<ogra> zyga, (and probably kenvandine ) https://lists.ubuntu.com/archives/ubuntu-users/2018-October/295405.html
<mup> PR snapd#5933 opened: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>
<cachio> I created the arch image with apparmor enabled but ...
<mborzecki> cachio: hey
<zyga> ogra: feels like interface(s) that fuel the gnome system monitor need improvements
<cachio> mborzecki, I am having a problem wiht this machine
<zyga>  pstolowski some reviews on hot plug PRs
<Chipaca> ogra: is having the journal on disk the default?
<cachio> mborzecki, it is not starting the google services
<ogra> zyga, yeah ... note that we a) ship it by default and b) default to journald-to-disk logging now
<cachio> mborzecki, so it can't be used by spread
<ogra> Chipaca, i think so
<zyga> meta comment I would prefer a pub-sub model over blind logging
<zyga> but that's what we have
<ogra> at least with 18.10
<mborzecki> cachio: is it possible to access it via ssh?
<cachio> mborzecki, it happens when we update the packages on that machine
<cachio> mborzecki, no, via seria console
<mborzecki> cachio: can i access that?
<cachio> mborzecki, let me start one for you
<Chipaca> ogra: why isn't it being rotated?
<ogra> Chipaca, works differently ... its a ringbuffer and is by default limited to a certain percentage of the rootfs disk
<ogra> on a multi terabyte disk 4GB is nothing ;)
<mvo> 5930 needs a second review
 * Chipaca looks
<Chipaca> huh, i thought i'd done this one already
<Chipaca> grrr opensuse
 * Chipaca ~> lunch-making
<zyga> Chipaca: commented
<mborzecki> off to pick up the kids
 * cachio afk
<cachio> ~ 10 mins
<Chipaca> zyga: d'oh, fixed
<zyga> :D
<pstolowski> zyga: thank you!
<diddledan> popeycore sounds like an awesome music genre
<mup> PR snapd#5931 closed: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5931>
<zyga> I'll stop reviewing now
<zyga> my back is not great today and it's hard to focus
<mup> PR snapd#5932 closed: spread: put openSUSE to manual <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5932>
<zyga> Chipaca: hey
<zyga> Chipaca: I realized the touch bar is good for one thing for sure :)
<zyga> ð¶ð¼ð°ð½
<zyga> irc was never this ð·
 * diddledan needs to google to find out how well it's supported in Linux
<pstolowski> zyga: :D
<Chipaca> diddledan: zyga: all you need to do is remember all the unicode code points, and then <ctrl>+<shift>+u1f577 <whitespace> gives you ð· tadaa
<diddledan> hah
<zyga> ð­
<zyga> touchbar is useless then
<Chipaca> zyga: U+1F631 FACE SCREAMING IN FEAR
<Chipaca> brb renaming Hotplug to ð¶ð
<mup> PR snapd#5930 closed: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5930>
<mup> PR snapd#5888 closed: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5888>
<axino> popey: do you know a good example of a charm hosted upstream and building automatically ? I'm mostly wondering how to dynamically handle snap versions
<mup> PR snapd#5934 opened: release: 2.35.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5934>
<Chipaca> hmm, I know how i can speed up this :-D
 * Chipaca will do it on Monday
<mup> PR snapcraft#2293 closed: build providers: use the new snapcraft: remote for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2293>
<zyga> sigh
<zyga> mvo: yeah, I will just rebuild :/
<mvo> zyga: rebuild the kernel?
<zyga> yep
<mvo> cachio: 2.35.4 is in the beta channel now
<cachio> mvo, nice
<cachio> I'll start
<cachio> thanks
<mvo> cachio: thank you!
<mup> PR snapd#5935 opened: po: sync translations from launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/5935>
 * zyga uses this moment to build the kernel a few times 
<zyga> mvo: you win the PR of the year award
<zyga> +42,937, -2,729
<zyga> wow
<stgraber> mvo: hey there, so for those unix socket problems, (first network-online, then network.target), do we have an ETA for that landing in 18.10?
<stgraber> mvo: we've seen a few reports of startup regression in cloud instances and the like ever since we started seeding LXD as a snap and enabled socket activation
<mborzecki> stgraber: the 'fix' thing has landed in master, 2.36 and 2.35
<mborzecki> would appreciate if you can check it on your end with core from edge (provided it's alreay been published)
<mup> PR snapd#5934 closed: release: 2.35.4 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5934>
<mvo> stgraber: I uploaded the fix some hours ago into cosmic
<mvo> stgraber: let me see
<mvo> zyga: haha - this PR is great, isn't it?
<stgraber> mvo: ah, is it in the queue?
<mvo> stgraber: yes
<zyga> mvo: yes but also somewhat worrying, bad i18n can cause issues
<mvo> stgraber: waiting for approval
<stgraber> mvo: ok, let me review it quickly then
<zyga> though go is much safer than C ever was so .. not terrible :)
<mvo> zyga: indeed
<mvo> stgraber: \o/
<stgraber> mvo: accepted
<mvo> stgraber: cool, thanks
<pstolowski> to whom should i bow for the nice beautification of the hotplug label in github? ;)
<mvo> pstolowski: probably Chipaca
<Chipaca> lies
 * Chipaca reads what he's been accused of
<mvo> pstolowski: thats my guess at least
<Chipaca> <Chipaca> brb renaming Hotplug to ð¶ð
<Chipaca> :-)
<pstolowski> because he loves unicode?
<zyga> ð
<pstolowski> Chipaca: looking forward to parallel installs label ;)
<Chipaca> pstolowski: Probably a bit much :) I'll revert it to the older one
<mvo> pstolowski: unicode + beautiful sounds very much like Chipaca :)
<Chipaca> there
<zyga> â
<mvo> zyga: haha
<Chipaca> #5880
<mvo> Chipaca: I think its fine
<mup> PR #5880: interfaces/repo: two helper methods for hotplug <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5880>
<Chipaca> #5596
<mup> PR #5596: [WIP] Parallel installs integration <Parallel installs â> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
<Chipaca> zyga: ^ at your command
<pstolowski> :)
<zyga> Chipaca: please add one for user mounts ð
<zyga> just because Friday is fun
<pstolowski> heh
<Chipaca> zyga: that chains thing doesn't work on github though
<Chipaca> zyga: no contrast
<zyga> btw, I think we could use projects rather than labels (for this)
<zyga> mmm
 * zyga looks
<mborzecki> zyga: Chipaca: you can close it
<mborzecki> that parallel installs WIP
<Chipaca> zyga: you can create and edit labels too, you know? :)
<Chipaca> whoa that was quick
<mup> PR snapd#5596 closed: [WIP] Parallel installs integration <Parallel installs â> <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
<Chipaca> mborzecki: no more parallel installs label then?
<mborzecki> Chipaca: there will be one or two PRs more
<Chipaca> ah ok
<Chipaca> zyga: projects sounds nice, but I don't think they'll fit without quite a bit of admin on our end
<zyga> admin? they are just like labels, just pick and go
<mborzecki> heh we have this silly thing in arch in gce: https://paste.ubuntu.com/p/BJKrJ3yp7y/ so ssh starts, and then 10 minutes later actually starts listening on ports, wtf??
<mborzecki> network is up way before that
<Chipaca> zyga: "automated kanban with pull requests" using issues and stuff to trigger it
<mborzecki> sshd is actually After=network.target
<zyga> Chipaca: I don't know what you just said but that's fine, it's Friday and I'm booting my kernels
<Chipaca> zyga: I think I'm going to go for a friday run, and then i'm going to have friday pizza and friday beer and maybe some friday guitar
<zyga> I have a bottle of cider upstairs
<zyga> but maybe I will take a ride on a bike before winter strikes
<ogra> winter ?
<ogra> do you also belive in santa ?
<ogra> winter are over ... :P
<ogra> *winters
<mborzecki> w8, aren't they coming?
<ogra> nah, we're letft with endless autumn now until jumping directly into summer in march
<zyga> winter is coming, something something
<zyga> my office is going to be feezing
<zyga> it's not well insulated
<mvo> Chipaca: if you do this you miss my review for 5913 ;)
<mvo> Chipaca: but +100, run+pizza sounds way more fun
<Chipaca> nooooo
 * ogra pokes the armhf builders on build.s.io with a pointy stick ... come on your x86 firends have finished the 2min build 30 min ago ... there is no reason to say "Building soon" !
<Chipaca> mvo: I've been told I said the run was at 5, so if it's not 5 they're not going yet
<zyga> mvo: it's actually slower than the desktop :/
<zyga> but well, it's a laptop :)
<Chipaca> mvo: _now_ i'm off. But I'll give the review a look before the beer.
<mvo> zyga: what is slower than the desktop?
<zyga> the laptop
<mvo> Chipaca: heh, no need, enjoy your WE
<mvo> zyga: aha, ok
<pstolowski> Chipaca: any chance for +1 on https://github.com/snapcore/snapd/pull/5497 (i did the rename)?
<mup> PR #5497: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>
<pstolowski> (nad now as i fixed the trivials in my PRs, travis hates everything again)
<pstolowski> Chipaca: ah, you're off. have a good weekend!
<pstolowski> good idea, actually
<ogra> cjwatson, put away the mop ! (... watching armhf on https://launchpad.net/builders)
<cjwatson> ogra: see #launchpad-ops
<ogra> (well, in fact watching arm64 but waiting for armhf capacity)
<cjwatson> ogra: IS is working on it
<ogra> ah, good
<ogra> thanks (i just wanted to make a bad friday joke anyway :P )
<mvo> Chipaca: added some comments, hope I'm not too annoying, I guess I shouldn't review when hungry
<mup> Bug #1796362 opened: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:New> <https://launchpad.net/bugs/1796362>
<mup> PR snapd#5933 closed: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5933>
<zyga> it's still building...
<zyga> I tweaked a few things and restarted the process twice
<zyga> mainly to add space to the VM :)
<zyga> and to up the thread count
<mup> PR snapcraft#2323 opened: go plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323>
<sergiusens> mvo: that is probably close to your heart in case you want to check ^
<Chipaca> EOW
<Chipaca> o/
<zyga> linux-image-4.18-unsigned from cosmic, dpkg-build in a VM + music + some casual browsing took  76 minutes and wrote over 40GB of data!
<Pharaoh_Atem> zyga, mvo: this should be fixed now: https://github.com/snapcore/snapd/commit/79b85c4009032cf61864ced46b97abe3793efbee
<mup> PR snapcraft#2324 opened: plugins: remove the ament plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2324>
<mup> PR snapd#5936 opened: Revert "spread: put openSUSE to manual" <Created by zyga> <https://github.com/snapcore/snapd/pull/5936>
<zyga> thanks Pharaoh_Atem
<mup> PR snapcraft#2325 opened: plugins: remove the python2 and python3 plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2325>
<pedronis> zyga: do you remember why we validate plug/slot name only when they are added to the repo and not when parsing snap.yaml ?
<zyga> mmmmm
<zyga> I was hoping we would validate the yams and then each added one
<zyga> but I don't remember at this time more
<zyga> I mean, we should definitely validate in the yaml
<zyga> AFAIK we moved validation there even (the patterns)
<pedronis> actually we don't validate them even when adding
<pedronis> is done in AddSlot/AddPlug
<pedronis> but that is not really used
<zyga> mmm
 * zyga looks
<pedronis> you can have a 22.33 slot afaict
<pedronis> (unless I'm missing something)
<zyga> correct
<zyga> wow, that's bad :/
<zyga> AddSnap calls Validate
<zyga> but Validate doesn't
<zyga> I guess we call sanitise
<zyga> in the end
<zyga> perhaps that's why?
<zyga> but the name validation should be done earlier
<pedronis> does sanitize check the name?
<zyga> no, it's an optional helper, it used to be different before but not anymore
<zyga> looking at this briefly nothing does now
<pedronis> yea
<pedronis> seems you can have fairly random plug/slot names atm
<zyga> I'll fix that
<zyga> correct
<pedronis> we do have ValidateSlot/PlugName in snap but is not used in validate code
<jdstrand> zyga: does opensuse-42.3-64 correspond to tumbleweed?
<zyga> pedronis: yep, branch coming up soon
<zyga> jdstrand: no, that is LEAP 42.3 (older LEAP, current one is .. 15)
<zyga> tumblweed is just that
<pedronis> zyga: same for ValidateInterfaceName btw
<pedronis> not called
<zyga> pedronis: yeah, they are called from interfaces/
<zyga> I moved them to snap to de-duplicate the code
<zyga> but something got lost along the way
<pedronis> but not in all relefvant cases
<pedronis> anyway we want to use them in validate code itself
<pedronis> wonders if there are weird plug/slot out there
<pedronis> given the missing validation
 * jdstrand wonders why spread -list doesn't list anything with opensuse any more
<pedronis> jdstrand: it might have been set ot manual
<pedronis> not sure if that influences -list or not
<zyga> jdstrand: opensuse was disabled
<zyga> https://travis-ci.org/snapcore/snapd/builds/437765662
<jdstrand> I'm looking at an old travis failure
<jdstrand> oh, heh, ok
<jdstrand> zyga: otoh, if I'm in the code that it setting up a snippet in one interface, can I query if another interface is specified/connected?
<zyga> I don't believe so
<jdstrand> that's sucky
<zyga> what would you like to do?
<jdstrand> me fears about 'ix' in the home interface have thus come true
<jdstrand> my*
<zyga> I see
<zyga> well, we _could_ fix that
<zyga> the specification could gain a query API
<zyga> like spec.IsTypeConnected("home")
<zyga> it's not hard to add in our model now
<jdstrand> docker-support will need a change-profile unsafe... rule, but docker snaps have home connected. the combination causes a parser error
<jdstrand> so I need to strip out the 'ix' there
<pedronis> mmh
<pedronis> that is not a simple problem
<pedronis> we don't connect interfaces as groups
<pedronis> they come one by one
<pedronis> so we would need to deal with both directions
<jdstrand> for this, I really only need to know if docker-support is plugged at all
<pedronis> it can get connected later
<jdstrand> because in practice, anything using that will have it connected (it is a super privileged interface)
<pedronis> jdstrand: you don't know if they will be connected in a given order
<pedronis> or the other
<jdstrand> so in practice it will always be connected. and I only need this for the docker-support interface
<jdstrand> pedronis: that's is what I'm saying. for this very specific case, I don't actually care about connection order because in practice, in the real world, if docker-support is in plugs, it will be connected, because of the nature of how we grant snap declarations for it
<pedronis> jdstrand: I'm not understanding, it sounds fragile or I'm missing something
<jdstrand> pedronis: so, to unblock the k8s work, I only really need in the home interface to know if docker-support is plugged, not connected. if it is, we just assume it is connected and drop the ix
<jdstrand> pedronis: it isn't fragile, it makes a simple assumption
<zyga> pedronis: that's fine, I think, because if it is connected later the same method will be called (to compute the policy) and we can just do the right thing
<zyga> pedronis: it doesn't have to check both ways, it can just check the current state
<jdstrand> in the home interface, behave like normal in all cases unless docker-support happens to be plugged. then drop some ix rules
<pedronis> what does plugged mean?
<jdstrand> and by plugged, I do *not* mean connected
<pedronis> that the snap has a plug?
<jdstrand> whether it is connected or not, you don't get ix if your snap plugs docker-support with home
<jdstrand> plugs:
<jdstrand>   home: null
<jdstrand>   docker-support: null
<jdstrand> in this case *only*, home drops some ix rules
<pedronis> I seee
<pedronis> it's kind of a hack and a layering violation tough
<jdstrand> yes
<jdstrand> but when we added the ix rule to the home interface, we added a potential apparmor conflict
<jdstrand> that conflict is here now, because docker-support must have a special rule to fix k8s. it didn't exist before
<jdstrand> I warned about this btw
<zyga> pedronis: 5937
<zyga> jdstrand: another idea
<mup> PR snapd#5937 opened: snap: validate plug and slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/5937>
<zyga> jdstrand: you can fix this in compose
<jdstrand> but I couldn't forsee the use case that would cause the problem
<zyga> jdstrand: AddConditinalSnippet("...", func() { ... })
<zyga> then at compose level we can decide
<zyga> something along those lines
<jdstrand> zyga: oh, where is that?
<zyga> we don't have that
<zyga> but it is another thing we could add
<zyga> then interfaces are still "easy"
<zyga> and operate at their own layer
<zyga> but the backend can do smarter things when combining snippets
<zyga> right?
<zyga> it's a bit late so I won't jump at implementing that now but I think it is doable
<zyga> (both this and exposing connections to the specification, technically, probably one is cleaner than the other)
<jdstrand> zyga: well, I could probably do something right before the snippets are written out and do the equivalent of a sed. that would be pretty terrible though
<zyga> that's deriveContent
<zyga> in apparmor/backend.go
<jdstrand> yeah
<pedronis> jdstrand: anyway ConnectedPlug has Snap so you should be able to get to the info
<jdstrand> I think I will propose something with ConnectedPlug cause the logic would be simple, if a bit of a hack, and easier to remove once there was a proper solution
<zyga> hmmm
<zyga> jdstrand: can you tell me what you would do?
<jdstrand> in the home interface:
<zyga> I'm not sure connected plug and the info are enough tell you something is or is not connected
<zyga> I hope I'm wrong though :)
<jdstrand> use_ix = true
<zyga> mmm
<jdstrand> if docker-support in plugs:
<jdstrand>    use_ix = false
<jdstrand> ...
<zyga> ah, regardless of connection status?
<jdstrand> yes
<zyga> ah, that's doable easily
<zyga> go for it :)
<jdstrand> right
<zyga> but my suggestion is
<zyga> look at interface type rather than the name
<zyga> I'm sure you meant that
<zyga> but just wanted to say that just in case :)
<zyga> Friday evening and all that
 * jdstrand nods
<zyga> pedronis: I'll add a spread test for the validation later on, today I just want to see if this passes as-is
<zyga> if any tests we have now have invalid plug and slot names by accident
<jdstrand> the above is 'wrong' cause technically use_ix is only false if docker-support is connected. but in practice you need an installation constraint for docker-support and so if we grant that you get auto-connect too
<jdstrand> and, the type of snap that has docker-support is, well, docker, and it will fall over without it, so disconnecting is infeasible for a working snap
<jdstrand> really, we shouldn't have interface combinations that conflict with each other, but alas, we do
<pedronis> zyga: wonder if we should validate the interface name in the slots and plugs
<pedronis> as well
<zyga> perhaps but that one is more or less harmless
<pedronis> it it's invalid it will also be a non-existing interface so we will ignore it
<pedronis> atm
<zyga> and we do validate that at some stage against known interfaces
<zyga> we said we would not reject unknown interfaces
<zyga> just ignore them
<pedronis> yes
<zyga> so I think that's the best we can do
<zyga> we _could_ validate the actual name but that's a small extra
<pedronis> but this is about malformed names, no unknown
<pedronis> not unknown
<zyga> I mean, I don't oppose it, I think we already do at another level
<zyga> but perhaps I'm wrong as with the initial validation
<zyga> but all known names are not malformed :)
<zyga> so if not known then we don't care
<zyga> still, I see your point
<zyga> we could just be more aggressive about invalid names in general
<pedronis> zyga: I just think it would be more consistent, and given we are adding it for slots and plugs
<pedronis> it would be a good idea
<pedronis> instead of adding it later
<pedronis> again
<zyga> yes
<zyga> +1
<zyga> pedronis: pushed
<zyga> pedronis, jdstrand ^ review on that appreciated
<zyga> would love to see it in 2.36 for mvo
<pedronis> zyga: +1 with a comment
<Pharaoh_Atem> zyga: are we looking to have 2.36 soon?
<zyga> I hope so
<zyga> pedronis: I saw, good point,
<Pharaoh_Atem> also...
 * Pharaoh_Atem pokes kyrofa
<jdstrand> zyga: what pr?
<zyga> jdstrand: 5937
<zyga> `plug "plug" has invalid interface name "i--face"`
<zyga> anyone wants to suggest better wording?
<pedronis> invalid inteface name "i--face" for plug "plug"
<pedronis> ?
<zyga> nicer, thanks
<zyga> pushed
<zyga> thanks pedronis, that's a very good find for Friday evening
<pedronis> zyga: it's actually jdstrand that made me go dig into this, because he noticed that one could happily use numbers
<pedronis> in those places (because of our type-directed YAML parsing of some things)
<pedronis> 1234 plug anyone
<zyga> 1337 plugs FTW
 * zyga clones ubuntu kernel and sees that only 12% managed to flow so far :/
<zyga> I guess I'll be patching tomorrow
<zyga> have a great night everyone!
<jdstrand> bye zyga :)
<kyrofa> Hey there Pharaoh_Atem
<Pharaoh_Atem> kyrofa: how are things coming along with snapcraft?
<kyrofa> Pharaoh_Atem, pretty good from my perspective, but it depends on what exactly you're looking for!
<Pharaoh_Atem> well, principally being able to reasonably use it to produce Fedora based snaps ;)
<kyrofa> Pharaoh_Atem, there are two things I can think of that will be needed. First of all, the way snapcraft will be supporting other bases is by way of VM images for the base, so a fedora one will be required. Second, snapcraft is still missing any sort of dnf backend
<kyrofa> Either one of those could be tackled independently from the other
<Pharaoh_Atem> kyrofa: the VM images thing is going to be a problem for running snapcraft in a koji build or something
<Pharaoh_Atem> since they'll be running in restricted nspawn containers
<kyrofa> Pharaoh_Atem, there is a "destructive" mode as well that will run on the host, but that will still require the dnf backend
<kyrofa> It also isn't quite as clean
<Pharaoh_Atem> that's fine
<Pharaoh_Atem> Koji purges the container environments after use4
<Pharaoh_Atem> *use
<Pharaoh_Atem> it's not stupid enough to reuse them
<kyrofa> Yeah similar to what we do
<Pharaoh_Atem> there are a few build systems that do reuse chroots, but they're irrelevant since no large distro uses them
<Pharaoh_Atem> kyrofa: I tried to write a DNF backend a long time ago, but it was too hard :(
<kyrofa> Pharaoh_Atem, the only thing you might consider is, let's say we have a fedora VM image: how different will it be from koji?
<Pharaoh_Atem> kyrofa: koji does a mock container setup
<Pharaoh_Atem> the main things are: no real devfs, no kernel access, etc.
<Pharaoh_Atem> and in the case of Fedora's Koji instance, no internet access
<cjwatson> Sounds familiar, though we use throwaway VMs rather than containers.  Sounds like koji might in fact be an even more restrictive environment than Launchpad in some ways from the POV of snapcraft
<kyrofa> Indeed
<kyrofa> Pharaoh_Atem, sounds like this is all moot without dnf support though, which isn't really on our immediate roadmap
<Pharaoh_Atem> cjwatson: SUSE's OBS is equally restrictive, though they default to VMs
<cjwatson> Yeah, I'm surprised Fedora doesn't in fact
<Pharaoh_Atem> (they support LXC containers as a fallback)
<cjwatson> Maybe they have fewer untrusted builds
<Pharaoh_Atem> cjwatson: Fedora COPR (where our PPA-like infra is) uses VMs
<cjwatson> Right, makes sense
<Pharaoh_Atem> since Koji is used _exclusively_ for distro packages, containers work fine
<cjwatson> We deliberately share infra between the two uses because it gives us better density
<Pharaoh_Atem> if the two systems were to merge (as I hope they will eventually), it'll probably be build VMs
<Pharaoh_Atem> kyrofa: if I could get some help from you, I'd like to look at getting snapcraft a DNF backend soon
<Pharaoh_Atem> today, every major RPM based distro (and some minor ones) have DNF in a functional state so that their distro repos can be managed with it
<Pharaoh_Atem> even Yocto derivatives that use RPM (like Wind River Linux) use DNF now
<kyrofa> Pharaoh_Atem, sure thing. Not sure what your schedule is like, but mine will be a little more open after 18.10 ships
<Pharaoh_Atem> that's probably a reasonable window for me too
<kyrofa> Good deal
<Pharaoh_Atem> I did this a while ago, but obviously didnt' get far: https://github.com/Conan-Kudo/snapcraft/blob/repo_rpm/snapcraft/internal/repo/_rpm.py
<mup> PR snapd#5937 closed: snap: validate plug and slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5937>
<mup> PR snapd#5921 closed: spread-shellcheck: use threads to parallelise <Simple ð> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5921>
<mup> PR snapd#5936 closed: Revert "spread: put openSUSE to manual" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5936>
<mup> PR snapd#5938 opened: [test] Tweak cla checker <Created by chipaca> <https://github.com/snapcore/snapd/pull/5938>
#snappy 2018-10-06
<mup> PR snapd#5939 opened: testing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5939>
<mup> PR snapd#5940 opened: store: speedup unit tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/5940>
<mup> PR snapd#5941 opened: systemd, wrappers: speed up wrappers unit tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/5941>
<mup> PR snapd#5942 opened: client: speedup unit tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/5942>
<mup> PR snapd#5943 opened: osutils: unit tests speedup; introduce Â«run-checks --short-unitÂ» <Created by chipaca> <https://github.com/snapcore/snapd/pull/5943>
<mup> PR snapd#5944 opened: cmd/snap: speed up unit tests <Created by chipaca> <https://github.com/snapcore/snapd/pull/5944>
#snappy 2018-10-07
<filib> Hi guys I would like to contribute to the Ubuntu community testing some code, how can I do??
<mup> PR core-build#33 opened: fix typo for handle_writable_paths() <Created by madper> <https://github.com/snapcore/core-build/pull/33>
<AuroraAvenue> How Do I check whether my installed AbiWord is a snap or not ?
<ogra> snap list
<ogra> (shows all installed naps on your system)
<AuroraAvenue> okay, its not thanks.
<AuroraAvenue> ogra, its not even snapped is it ?
<ogra> "snap find abiword" should tell you
<ogra> but i think it isnt ... there are libreoffice and wps-office though
<AuroraAvenue> ogra, What version of ubuntu are you using ?
<AuroraAvenue> forget that.
<AuroraAvenue> Could someone put it on the Wishlist on snapcraft (I cant as I only have one eMail) - as I think this could be a Lubuntu issue in future.
<AuroraAvenue> ogra, hello there, you about still?
<AuroraAvenue> ogra, Can you see the issue ?
<ogra> AuroraAvenue, you want to put it here https://forum.snapcraft.io/t/snap-wishlist-suggestions-wanted/567
<AuroraAvenue> ogra, I cannot - its the one program I said I would never talk of on wishList - too many connections.
<AuroraAvenue> hopefully someone shall see these logs and do it themselves.
<AuroraAvenue> I thnk AbiWord on lubuntu is a priority snap though.
#snappy 2019-09-30
<mborzecki> morning
<mup> PR snapd#7530 opened: tests: move "centos-7" to unstable systems (2.42) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7530>
<mborzecki> mvo: morning
<mvo> hey mborzecki
<mup> PR snapd#7530 closed: tests: move "centos-7" to unstable systems (2.42) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7530>
<mup> PR snapd#7525 closed: tests: disable {contacts,calendar}-service tests on Arch Linux (2.42) <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7525>
<mup> PR snapd#7524 closed: tests: add unit test for gadget defaults with a multiline string <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7524>
<mup> PR snapd#7523 closed: sandbox/selinux: move SELinux related bits from 'release' to 'sandbox/selinux' <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7523>
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/7507 ?
<mup> PR #7507: gadget: do not fail the update when old gadget snap is missing bare content <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7507>
<mvo> mborzecki: sure
<zyga> good morning everyone
<zyga> some weather ...
<mborzecki> mvo: thanks
<mborzecki> zyga: hey
<mborzecki> hm can't launch anything under mulitpass
<mborzecki> launch failed: Failed to set iptables rule for table filter: iptables v1.6.1: unknown option "--dport"
<mborzecki> --beta works though
<pstolowski> morning
<dot-tobias> good morning
<mborzecki> Saviq: filed https://github.com/CanonicalLtd/multipass/issues/1100 let me know if you need more info
<mborzecki> pstolowski:  hey
<mvo> hey pstolowski
<mup> PR snapd#7507 closed: gadget: do not fail the update when old gadget snap is missing bare content <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7507>
<mborzecki> yay :)
<mborzecki> mvo:  can you cherry-pick that to 2.42? the commit hash is 31d33fa4e
<mvo> mborzecki: thanks, done
<mup> PR snapd#7531 opened: cmd/system-shutdown: include correct prototype for die <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7531>
<zyga> mvo: there's one more thing to cherry pick
<zyga> it landed when you were away, one sec
<zyga> mvo: https://github.com/snapcore/snapd/pull/7526
<mup> PR #7526: cmd/snap-confine: allow digits in hook names <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7526>
<zyga> mvo: and perhaps https://github.com/snapcore/snapd/pull/7531 as well
<mup> PR #7531: cmd/system-shutdown: include correct prototype for die <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7531>
<zyga> mvo: so that I can drop all patches from 2.42 in suse
<mvo> zyga: thanks, looking
<zyga> I'll check why our builds don't catch that though, must be -Wsomething we're missing
<mvo> zyga: 7526 is in
<zyga> Thank you, ondra will be very happy this made it in
<zyga> mborzecki: ping about https://github.com/snapcore/snapd/pull/7484
<mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<zyga> mvo: not sure if you want to pull that into 2.42
<zyga> it's the memory optimization for icons
<pedronis> it needs reviews
<mvo> zyga: no
<mvo> zyga: or *maybe* but it needs to be reviewed and obviously fixing something :)
<zyga> yeah, just asking because you indicated you might be interested in that at the sprint when it came up
<zyga> but I think it's okay to get this in 2.43
<zyga> we can use store to prevent people from sending huge icons
<pedronis> #7277 needs 2nd review
<mup> PR #7277: overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/7277>
 * Chipaca has successfully bred some kind of a throat bug over the weekend and feels this was a poor idea and would like to cancel his subscription to it
<zyga> re
<zyga> Chipaca: so you have my copy? :D
<zyga> get well man
<Chipaca> zyga: eh, just my throat catching a lot and the general sense of fighting something bringing me down a bit, nothing that should stop me (might slow me down some)
<pedronis> Chipaca: hi, sorry about that
<pedronis> Chipaca: #7402 can be merged ?
<mup> PR #7402: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>
<Chipaca> pedronis: heading into a meeting, but â¦ probably?
<mup> PR snapd#7516 closed: daemon: allow /v2/assertions/{assertType} to query store <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7516>
<mup> PR snapd#7402 closed: daemon, client, cmd/snap: include architecture in 'snap version' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7402>
<mup> PR snapd#7531 closed: cmd/system-shutdown: include correct prototype for die <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7531>
<zyga> heavy rain here, hope no funny stuff with power lines toda
<Chipaca> "hope no funny stuff with power lines toda--" KOOOOMzapWHUMP
 * zyga -> quick tea
<mvo> zyga: re 7484 - I wonder if it would make sense to push a PR that just adds the osutil.FileState interface and does all the mechanical stuff (no real code changes)
<zyga> mvo: I can do that
<zyga> note that FileState became an interface from a struct
<zyga> so it would involve a lot of changes already
<zyga> not sure if that's what you had on your mind
<mvo> zyga: yeah, thats what I mean
<zyga> let me try
<mvo> zyga: it might be simpler to review one PR with just this mechanical change FileState->interface previous FileState->MemoryThing no other changes
<mvo> zyga: i.e. no adding of FileReference or anything
<mvo> zyga: then it becomes a mechanical review and the actual implementation change is smaller and more obvious
<zyga> mhm
<zyga> man, what a downpour!
<mvo> (but of course if e.g. pedronis thinks 7418 is fine as is and should not be split that is fine for me too)
<pedronis> mvo: no strong opinion, is not very big either way
 * mvo nods
<mborzecki> duh, dates suuuck
<Chipaca> mborzecki: you're reminding me of this book that looked into systems that needed something like three different times referring to everything so as to answer questions such as "what price would the sales person have had on their laptop in the field at the time they gave the presentation?"
<mup> Bug #1628289 changed: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <squashfuse (Ubuntu):Fix Released> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<mborzecki> ok, pushed a fix to https://github.com/snapcore/snapd/pull/7443 think i got all the edge cases right
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<mup> Bug #1548225 changed: Snapcraft/snappy should detect incompatible version mismatches <Snapcraft:Won't Fix> <Snappy:Won't Fix> <https://launchpad.net/bugs/1548225>
<mup> Bug #1636891 changed: Unable to log in using email with + character <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1636891>
<mup> Bug #1636242 changed: snap fails to install a package if it doesn't start a daemon successfully <Snappy:Won't Fix> <https://launchpad.net/bugs/1636242>
<pedronis> Chipaca: do the current retries handle this better:  https://bugs.launchpad.net/snappy/+bug/1643893 ?
<mup> Bug #1637153 changed: plugging in a network cable when wifi config failed causes a traceback when restarting console-conf <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1637153>
<mup> Bug #1644546 changed: [console-conf] Network screen continues to account setup with failing configuration <Snappy:Fix Released> <subiquity:Fix Released> <https://launchpad.net/bugs/1644546>
<zyga> back from call, returning to branches
<Chipaca> pedronis: dunno
<pedronis> mborzecki: could you update/answer here: https://bugs.launchpad.net/snappy/+bug/1839709
<mup> Bug #1839709: does not work under cgroup v2 <Snappy:New> <snapd (Debian):Confirmed> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1839709>
<mborzecki> pedronis: sure
<pedronis> thx
<mborzecki> btw. on this note, people are starting to notice cgroups v2 in fedora since docker broke :P
<zyga> mborzecki: I saw that
<zyga> mborzecki: note there's a fallback plan still, to push it for another release
<zyga> but I'm curious
<zyga> since it seems like fedora might want to push to the docker replacement stack (podman and friends) instead
<zyga> which would be perfectly in line with what they are trying to achieve (ship brand new software early)
<mborzecki> yeah, still it kind of assumes that you have the time to play with it and 1st, debug why docker doesn't work anymore, 2nd actually switch to podman
<zyga> mborzecki: I'm suprised docker is not a transitional package with a loads of wrapper scripts
<mborzecki> zyga: well podman should be able to consume the same arguments as you normally pass to docker
<mborzecki> and it does not require a daemon
<zyga> mborzecki: right my point is that it feels like user-machine friction
<zyga> "podman" != "docker"
<zyga> so people get docker and bam
<mborzecki> zyga: right, and docker inc. adds to that by having docker and moby :P
<mborzecki> zyga: where moby may as well come from distro repos and behave a bit differently than docker from docker repos
<zyga> part of FOSS complexity I guess
<diddledan> we should get podman into a snap
<pedronis> mvo: we got an answer to your request here: https://bugs.launchpad.net/snapd/+bug/1843077
<mup> Bug #1843077: Data corruption when UC18 is not powered down cleanly <snapd:Confirmed> <https://launchpad.net/bugs/1843077>
<pedronis> zyga: you got one +1 to 7484, splitting it now seems a bit a waste of time
<zyga> pedronis: I'm happy NOT to if mvo agrees :)
<zyga> I can do more useful stuff then
<pedronis> zyga: I don't think mvo had a strong opinion on this :) if you add the tests and get a +1 from mborzecki it can land I think
<zyga> cool, I'll do that then
<mborzecki> pedronis: zyga: not splitting is ok for me
<zyga> mborzecki: +1
<cachio> mborzecki, hey, here there is a log when centos cannot start activate a service
<cachio> and gives a timeout
<cachio> https://paste.ubuntu.com/p/pNYYqPKJM7/
<cachio> mborzecki, then you see
<cachio> + systemctl daemon-reload
<cachio> Failed to execute operation: Connection timed out
<cachio> in the log
<mborzecki> cachio: yup, i filed a bug in centos with this last week, there's a fixed systemd build in the fasttrack repo, but we have to wait for it to end up in updates
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7484/commits/9481c3cba1a8a4a62c76df78fb7cb7bece6ee89d
<mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<cachio> mborzecki, nice
<cachio> thanks for the update
<mborzecki> cachio: https://bugs.centos.org/view.php?id=16441 if you want the details
<mvo> zyga: yeah, thats fine. was mostly wondering, especially since you suggested it for 2.42
<mvo> zyga: so not splitting is fine
<zyga> break for more tea
<zyga> brb
<mup> PR snapd#7532 opened: Allow ovs interface access to bridge sockets <Created by dosaboy> <https://github.com/snapcore/snapd/pull/7532>
 * Chipaca stops editing mborzecki's standup thing and goes to get something to nom
<mup> PR snapd#7533 opened: client: add support to use the new "download" API <Created by mvo5> <https://github.com/snapcore/snapd/pull/7533>
<mup> PR snapd#7534 opened: sandbox/seccomp: move the remaining sandbox bits to a corresponding sandbox package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7534>
<mborzecki> zyga: ^^
<zyga> sure
<zyga> mborzecki: done
<zyga> mborzecki: can you review /writable PR please :)
<mborzecki> zyga: hmm quite sure i posted a review
<zyga> oh
<zyga> silly github stale stuff
<zyga> thanks!
<zyga> mborzecki: replied
<zyga> thanks
<zyga> jdstrand: hey
<zyga> jdstrand: are you back this week?
<jdstrand> zyga: today and tomorrow, yes
<jdstrand> (hey)
<zyga> hey :)
<zyga> I did an update over one branch and I'd like your re-review, just one today
<zyga> https://github.com/snapcore/snapd/pull/7421
<zyga> it's also shorter and easier
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> jdstrand: the whole complexity got reduced to one function with two if statements
<zyga> https://github.com/snapcore/snapd/pull/7421/files#diff-af477950316a096b57d91c74478bc4d2R521
<jdstrand> zyga: ok
<zyga> thanks, I'm working on more :)
 * zyga -> walking the dog in the rain
<mborzecki> Chipaca: so this one https://github.com/snapcore/snapd/pull/7166#discussion_r329554850 is actually quite interesting, bc the way i read it, timeout.C serves as the upper timit (time based though) for the retry mechanism (and that one is a workaround for snapd daemon restarts)
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mborzecki> Chipaca: but since it doesn't affec the actual client.raw() call, it will have no effect when client.raw() gets stuck
<ijohnson> hey folks, could I get reviews for #7437? ping mborzecki :-)
<mup> PR #7437:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7437>
<mup> PR snapd#7484 closed: osutil: generalize SyncDir with FileState interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7484>
<Chipaca> mborzecki: fair enough; that one wasn't the blocker :-)
 * zyga EODs for now, will return to garden one branch later tonight after homework and rest
<zyga> o/
<Chipaca> I'm going to slither off early as well, got my monthly physio check-up thing and then maybe a run if I'm up to it (doubt it because bleh)
<mup> PR snapd#7534 closed: sandbox/seccomp: move the remaining sandbox bits to a corresponding sandbox package <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7534>
 * cachio lunch
<cmatsuoka> mvo: pushed commits, still to check the test errors
<cmatsuoka> mvo: i'll be back after lunch
<mvo> cmatsuoka: thank you
<kyrofa> Using xdg-open within a snap: should I be using snap-xdg-open, or just xdg-open?
<abeato> sil2100, fyi: https://github.com/CanonicalLtd/ubuntu-image/pull/175
<mup> PR CanonicalLtd/ubuntu-image#175: Little kernel bootloader support <Created by alfonsosanchezbeato> <https://github.com/CanonicalLtd/ubuntu-image/pull/175>
<ijohnson> mvo got a minute to talk about uc18 spread test setup? I'm still having difficulties building an image with hacks in it by following parts of the spread prepare suite, and I'm not sure how much of the spread stuff I should be copying...
<ijohnson> we could also talk tomorrow if you're EOD or about to EOD
<sil2100> abeato: see it, thanks! Will review, but it looks solid from a first look
<mvo> ijohnson: pretty much eod, so unless its something specfic tomorrow is better. any particular thing that you are looking for?
<ijohnson> well how to make it work haha
<ijohnson> let's just talk tomorrow then
<sil2100> abeato: could we get the gadget.yaml spec updated to include the new bootloader? https://forum.snapcraft.io/t/the-gadget-snap/696
<abeato> sil2100, good point, will give that a go. or maybe ondra prefers to do that himself ^^
<sil2100> abeato: anyway, thanks for the PR! I'll make sure it's reviewed and (hopefully) merged tomorrow
<abeato> sil2100, awesome, thanks!
<sil2100> o/
<ijohnson> cachio: is there an easy way to increase the size of the disk space provided to a qemu machine when setup with spread?
<ijohnson> I'm trying to run the ubuntu-core-18-64 tests (well a modified one) and it runs out of space before finishing preparing
<ijohnson> hmm actually I think if I just increase the empty space in the image that spread uses it should automatically expand to use that I think
<cachio> ijohnson, which image are you using?
<ijohnson> I am trying to use the qemu backend
<ijohnson> cachio: ^
<cachio> ijohnson, it is weird
<cachio> ijohnson, did you change the prapare phose of the test suite?
<ijohnson> no, not yet, just trying to see how uc18 in the tests is "bootstrapped" from classic 16.04
<cachio> ijohnson, so, you want to run uc18 on qemu right?
<ijohnson> yes, but I want to eventually modify the image that boots in order to add stuff to the root filesystem
<ijohnson> but for now, just getting one that boots with spread is sufficient for me
<cachio> and how did you create that image?
<cachio> ijohnson, the uc18 one
<ijohnson> I followed HACKING.md :-)
<ijohnson> https://github.com/snapcore/snapd/blob/master/HACKING.md#building-spread-vm-images
<ijohnson> I created the ubuntu-16.04-64.img with `adt-buildvm-ubuntu-cloud`
<cachio> ijohnson, ah, and then you want to transform it to core18, right?
<ijohnson> yes
<cachio> ijohnson,  did you try to generate the image directly by using ubuntu-image?
<ijohnson> I tried just modifying the official amd64 image by adding stuff to the rootfs but it didn't take, it seems to be ignored
<cachio> and the using external system?
<ijohnson> I have not tried that yet
<ijohnson> s/official amd64 image/official amd64 UC18 image/
<cachio> so, you can generate the image by running
<cachio> sudo ubuntu-image "$image_option" "$snaps" \
<cachio>          -c "$CHANNEL" \
<cachio>          -O "$output" \
<cachio>          "./models/${platform}-${VERSION}.model"
<cachio> with
<cachio> image_option="--image-size 3G"
<cachio> snaps= --snap <path to local snap>
<cachio> if you need to add any new snap
<ijohnson> how would I do that for the qemu image?
<cachio> then you run
<cachio> sudo kvm -snapshot -smp 2 -m 2000 -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -nographic -serial mon:stdio <PATH_TO_VM_IMAGE>
<cachio> and you can connect to it
<cachio> setting the
<cachio> SPREAD_EXTERNAL_ADDRESS=localhost:8022
<cachio> and using the external backend4
<cachio> backend
<cachio> the qemu backend in fact is doing something similar to that
<cachio> the qemu backend is doing  this: https://github.com/snapcore/spread/blob/master/spread/qemu.go#L117
<cachio> ijohnson, I didnt try it, beu you could save the image generated with ubuntu-image into "$HOME/.spread/qemu/"
<cachio> and then try to use the qemu backend
<ijohnson> yes I've been able to boot the image with qemu, I guess the problem I have is 2 problems
<ijohnson> , first is that if I modify my UC18 image directly, the changes don't seem to work properly (I think this is because of the special UC18 boot process which is different from UC16 where my modifications do work)
<cachio> ijohnson, but it is not gonna work because ubuntu core needs to run console-conf
<ijohnson> and the second problem is that if I try to use spread to boot the default classic xenial image and let spread "prepare" the xenial image into a UC18, then preparing fails because the default image doesn't have enough space
<ijohnson> cachio: I successfully disabled console-conf in the image, that much still works from my days hacking on UC16 images :-)
<ijohnson> I need to break for lunch but will look at this again in a little bit, cachio do you know if the adt-build-vm-ubuntu-cloud created images are in raw format or a different format?
<cachio> ijohnson, no idea
<ijohnson> ok, np
<cachio> ijohnson, but you should be able to resize the image
<ijohnson> hmm actually there is a qemu resize image command isn't there
<cachio> ijohnson,  for google images we run resize2fs
<cachio> to resize them when it is needed
<ijohnson> ack, thanks I'll look into that after lunch
<ijohnson> thanks cachio!
 * ijohnson lunches
<cachio> ijohnson, sure
<mup> PR snapd#7535 opened: tests: disable {contacts,calendar}-service tests on debian-sid <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7535>
<mvo> review for -^ would be great
<mvo> simple and will unbreak master
<mup> PR snapcraft#2734 opened: SnapcraftError refactoring <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2734>
<cachio> mvo, do you know why it is failing in debian
<cachio> same reason than arch?
<mvo> cachio: looks like it
<mvo> cachio: https://metadata.ftp-master.debian.org/changelogs//main/e/evolution-data-server/evolution-data-server_3.34.0-3_changelog
<mvo> cachio: looks like the updated version hit unstable today
<cachio> mvo, today we updated debian sid
<ijohnson> mvo: reviewed
<mvo> ta!
<mup> PR snapd#7536 opened: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>
<mup> PR snapd#7535 closed: tests: disable {contacts,calendar}-service tests on debian-sid <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7535>
<jdstrand> roadmr: hey, not urgent at all, can you pull 20190930-2141UTC. it is the override for spread for Chipaca
<roadmr> jdstrand: sure, anything for Chipaca ð
<jdstrand> :)
<roadmr> I'll aim to deploy that tomorrow but no promises - it'll be in the queue anyway, worst case a couple of days
<mup> PR snapcraft#2735 opened: extensions: add gsettings plug to gnome-3-28 extension <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2735>
<mup> PR snapd#7537 opened: tests: fix ubuntu-core-device-reg test for arm devices on core18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7537>
#snappy 2019-10-01
<mup> PR snapcraft#2736 opened: cli: prompt for login if required <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2736>
<mup> PR snapcraft#2737 opened: cli: add -s back to clean for legacy <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2737>
<mborzecki> morning
<zyga> Good morning
<zyga> Iâll start late, looking after Lucy while wife is away
<zyga> Should be back full time by 10
<mborzecki> zyga:  hey
<zyga> Hey :-)
<zyga> Bug triage day for me :-)
<jamesh> hi zyga
<mup> PR snapd#7537 closed: tests: fix ubuntu-core-device-reg test for arm devices on core18 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7537>
<mborzecki> mvo: morning
<mvo> mborzecki: good morning
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: since you're already reviewed it, can you take another look at https://github.com/snapcore/snapd/pull/7443 ?
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pstolowski> mborzecki: will do today
<mborzecki> pstolowski: thanks!
<mup> PR snapd#7538 opened: tests: use `snap model` instead of `snap known model` in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7538>
<zyga> re
<zyga> jamesh: hello :)
<zyga> sorry for starting late, Lucy was sleeping while hugging me on the floor and I was pinned down until the wife returned :)
<jamesh> zyga: I'm just back from holiday.  I wasn't just ignoring your review comments
<zyga> jamesh: no worries, I wasn't thinking that at all
<jamesh> zyga: I think https://github.com/snapcore/snapd/pull/7197 has all the review ticks it needs.  Would you mind landing it for me when you have time?
<mup> PR #7197: usersession: track connections to session agent for exit on idle and peer credential checks <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7197>
<zyga> looking now
<zyga> done :)
<zyga> I'm very happy about what's coming to snapd recently
<zyga> exciting new features are brewing
<mup> PR snapd#7197 closed: usersession: track connections to session agent for exit on idle and peer credential checks <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7197>
<zyga> mvo: could you please double check https://github.com/snapcore/snapd/pull/7533 is safe for landing
<mup> PR #7533: client: add support to use the new "download" API <Created by mvo5> <https://github.com/snapcore/snapd/pull/7533>
<zyga> it's got +2 and green but there's a comment there that may need attention
<zyga> just got an app failure from travis ...
<zyga> and it turns out they run on heroku! who knew?
<mvo> pedronis: hey, I need a quick advice - in "snap debug boot-vars" - if a boot vars is not set, should we print "snap_bootvar=" or simply omit printing anything?
<pedronis> mvo: is it related to 7519 ?
<mvo> pedronis: yeah
<pedronis> mvo: I'm not quite sure 7519 makes completely sense
<mvo> pedronis: fair enough, I can kill it
<pedronis> mvo: I think snap debug boot-vars though should probably return something specific on classic
<pedronis> not print the env var as empty
<pedronis> boot-vars atm don't make sense on classic
<pedronis> mvo: to be clear my comment about 7519 it's that it moves from code not trusting snapd to code that does
<pedronis> not sure it's a good idea for tests in general
<pedronis> or maybe it needs to be changed test by test
<pedronis> mvo: but the reason was to fix some core18 tests, right?
<pedronis> we'll need to do something about those
<mup> PR snapd#7519 closed: tests: use `snap debug boot-vars` in "ubuntu-core-upgrade" test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7519>
<mup> PR snapd#7277 closed: overlord/snapstate: fix undo on firstboot seeding <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7277>
<Chipaca> pedronis: mvo: imo 'snap debug boot-vars' could error with 'wtf, u classic'
<Chipaca> on classic i mean
<Chipaca> no need to print anything there
<zyga> hmmm
<mborzecki> pedronis: #7468 is ready to land, there's a typo in the comments, but i'm not sure it's worth another spread run
<mup> PR #7468: seed/seedwriter,snap: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<mup> PR snapd#7539 opened: sandbox/cgroup: avoid dependency on dirs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7539>
<mborzecki> zyga: super simple fix for dependency cycle when importing sandbox/cgroup in release ^^
<zyga> +1
<mborzecki> thx
<pedronis> mborzecki: is there no other place using this that will need to mock root?
<pedronis> for it
<mborzecki> pedronis: there's a higher level mocking helper for this already
<pedronis> ah ok
<Chipaca> it's impressive how badly gocheck fails when you try to DeepEquals some nil things
<mup> PR snapd#7468 closed: seed/seedwriter,snap: support local snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<mup> PR snapd#7540 opened: interfaces/seccomp: query apparmor sandbox helper rather than aggregate info <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7540>
<mup> PR snapd#7541 opened: seed/seedwriter: support for extra snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7541>
<mborzecki> zyga: ^^ probably needs a blessing from jdstrand too
<pedronis> mborzecki: yes
<zyga> mborzecki: done
<pedronis> mborzecki: I applied that typo fix in the follow up, also applied some of pstolowski comments in it and previous
<pedronis> mvo: pstolowski: I pushed one more seedwriter PR  (the one after that is the actual switch in image)
<pstolowski> pedronis: thanks, will try to look at one of your remaining PRs today
<mvo> pedronis: thanks!
<mvo> pedronis: will look once 2.42 is out
<Chipaca> mborzecki: how would you say "update daily from 10pm to 6am, or any time on the weekends"?
<mup> Bug #1635258 changed: ubuntu-image should reserve 1-5% for root  when creating filesystems <snapd:Triaged> <Ubuntu Image:New> <https://launchpad.net/bugs/1635258>
 * Chipaca is bad at writing these things because coming up with it from examples is hard
<mborzecki> Chipaca: in the refresh schedule?
<Chipaca> mborzecki: yeh
<mborzecki> Chipaca: something like: mon-fri,22:00-6:00,,sat-sun
<Chipaca> mborzecki: thanks
<mup> Bug #1634803 changed: snapcraft register-key doesn't use U1 SSO login credentials <Snapcraft:New> <snapd:Invalid> <https://launchpad.net/bugs/1634803>
<mup> Bug #1637324 changed: snapd does not provide a REST API to log out <snapd:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1637324>
<mup> Bug #1637046 changed: requesting "quiet" mode <canonical-is> <papercut> <snapd:Confirmed> <https://launchpad.net/bugs/1637046>
<mup> Bug #1642669 changed: PolicyKit doesn't work inside snaps, preventing snap installation in unity8 <personal> <Canonical System Image:Confirmed for thomas-voss> <snapd-glib:Confirmed> <Snappy:Won't Fix> <Unity8 Session Snap:Confirmed> <https://launchpad.net/bugs/1642669>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Bug #1642090 changed: crontab like snaps or interfaces <snapd:New> <https://launchpad.net/bugs/1642090>
<mup> Bug #1642183 changed: GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <snapd:Triaged> <https://launchpad.net/bugs/1642183>
<mup> Bug #1637328 changed: Ubuntu Core 16 includes libnss-resolve from universe <Snappy:Fix Released by mvo> <https://launchpad.net/bugs/1637328>
<zyga> hmmm
<zyga> I think launchpad ate my bug
<zyga> mvo: can you see bug https://bugs.launchpad.net/snapd/+bug/1643893 ?
<mvo> zyga: in a meeting, but no
<zyga> thanks
<zyga> I'll ask in lp channels
<zyga> ijohnson: please look at this bug for your work concerning services https://bugs.launchpad.net/snappy/+bug/1645271
<mup> Bug #1645271: User unable to disable service <snapd:Confirmed> <https://launchpad.net/bugs/1645271>
<mup> Bug #1644074 changed: auto connect none auto-connect interfaces of snaps in gadget snap <snapd:Fix Released> <https://launchpad.net/bugs/1644074>
<mup> Bug #1645271 changed: User unable to disable service <snapd:Confirmed> <https://launchpad.net/bugs/1645271>
<mup> Bug #1646968 changed: There's something weird about /tmp <snapd:Won't Fix> <Ubuntu Image:Fix Released by barry> <https://launchpad.net/bugs/1646968>
<mup> Bug #1646881 changed: Enable pre-caching of snaps in a classic chroot <cpc> <snapd:Triaged> <https://launchpad.net/bugs/1646881>
<mborzecki> mvo: i've moved the f31 cgroupv2 minimal work to done, we don't seem to have a an umbrella card for cgroupv2 work
<mvo> mborzecki: feel free to create one
<mborzecki> mvo: added one for hierarchy support and one for device filtering (cc zyga)
<mvo> mborzecki: and *thank you*
<mup> PR snapd#7542 opened: release: 2.42 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7542>
<zyga> ack
<ogra> zyga, while going over all these 3 year old bugs you should probably first ask if it can still be repoduced at all :P
<zyga> yeah, I'm doing that :)
<mup> PR snapd#7539 closed: sandbox/cgroup: avoid dependency on dirs <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7539>
 * Chipaca lunches
<mborzecki> somebody just added a comment in the AUR page of snapd that fonts are rendered as boxes
<mborzecki> well, they are https://i.imgur.com/5sLAJTs.png
<zyga> ohhh
<mborzecki> added a note under: https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484 still, no clue how to debug fontconfig rendering little boxes :/
<zyga> did something new land there?
<mborzecki> it's touching a number of paths: https://paste.ubuntu.com/p/C39dpbfyHC/
<zyga> perhaps we can get our desktop teams to help us understand the stack more?
<mborzecki> [2019-09-24 07:09] [ALPM] upgraded fontconfig (2:2.13.1+12+g5f5ec56-1 -> 2:2.13.91+23+g65087ac-1)
<mborzecki> so the package got updated just recently
<mborzecki> hm maybe i can downgrade on my laptop
<mup> PR snapd#7543 opened: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
<mborzecki> zyga: ^^
<mvo> mborzecki: do you get anything useful with FC_DEBUG=5 gnome-logs
<mvo> mborzecki: or 1
<mborzecki> mvo:  https://paste.ubuntu.com/p/83CNv4NncM/
<mvo> mborzecki: https://www.freedesktop.org/wiki/Software/fontconfig/Devel/ fwiw has the high level changes
<mborzecki> hmm Rework Flatpak support interesting, flatpak has extra sugar in there? something we could use too?
<mvo> mborzecki: a good question
<zyga> mborzecki: yes, they create fontconfig config
<zyga> AFAIK
<mborzecki> hm pango got updated more-less at the same time
<pedronis> mvo: I commented in #7536
<mup> PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>
<mvo> pedronis: thank you!
<mvo> pedronis: sounds perfect
<pedronis> mvo: probably best first to introduce ModelConstraints with just Classic
<pedronis> and then do the UC20 change on top
<mvo> pedronis: makes sense (cc cmatsuoka )
<pedronis> mborzecki: ^ that probaby is interesting for #7509
<mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
<zyga> joining
<mup> Bug #1645606 changed: Default ubuntu core Pi2 configuration doesn't allow to use fullscreen browser <snapd:New> <https://launchpad.net/bugs/1645606>
<zyga> sorry
<mborzecki> zyga: do the fonts render correctly on TW?
<zyga> mborzecki: yes
<zyga> I checked yesterday
<zyga> odd?
<zyga> mborzecki: I can recheck today
<mborzecki> zyga: zypper dup? :)
<zyga> yeah, daily
<mborzecki> hmmm
<mup> Bug #1648712 changed: Complete /etc content from host accessible to the snap <snapd:New> <https://launchpad.net/bugs/1648712>
<mup> Bug #1663103 changed: No snapd API to determine which plugs/slots an app uses <snapd:Confirmed> <https://launchpad.net/bugs/1663103>
<cachio> mvo, #7537 for 2.42 please
<mup> PR #7537: tests: fix ubuntu-core-device-reg test for arm devices on core18 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7537>
<mvo> cachio: thanks, will cherry-pick it
<mvo> cachio: this is already in :)
<mup> Bug #1663787 changed: Libreoffice 5.3 instalado via snapd. NO accede a root ni a la particiÃ³n con ntfs <Snappy:Invalid> <https://launchpad.net/bugs/1663787>
<doko> mvo, whoever: https://bugs.launchpad.net/ubuntu/+source/abootimg/+bug/1846208
<mup> Bug #1846208: [MIR] abootimg (dependency of initramfs-tools-ubuntu-core) <eoan> <rls-ee-incoming> <abootimg (Ubuntu):Incomplete by snappy-dev> <https://launchpad.net/bugs/1846208>
<mvo> doko: in a meeting right now but let me see what this is about
<mvo> doko: I get to it
<mup> Bug #1669000 changed: classic snap can't use confinement override <amd64> <apport-bug> <xenial> <snapd:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1669000>
<mup> Bug #1669151 changed: No way to discover one's own appID <personal> <Canonical System Image:New> <snapd:Incomplete> <https://launchpad.net/bugs/1669151>
<zyga> camera angle on the thinpad is really poor
<roadmr> zyga: hopefully better than the XPS 13 nostril-cam though :)
<zyga> hahaha
<zyga> yeah, that's true
<zyga> it showed my forehead and ceiling
<roadmr> I prefer foreheads over knuckles blocking the person's face haha
<roadmr> I mean, it was so bad that Dell actually had to move it to the top bezel at the expense of Windows Hello support
<roadmr> because knuckle fingerprints or nose hair scans are not yet a thing
<mup> PR snapcraft#2735 closed: extensions: add gsettings plug to gnome-3-28 extension <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2735>
<mborzecki> mvo: sooo, krita works fine, no font issues
<mborzecki> mvo: actually looking at gnone-logs snap, it pulls in fonts.conf from the gnome-3-28-1804 connected via content interface
<mborzecki> anyone know of gtk3 snap that does not use gnome-3-28-1804?
<ijohnson> zyga: thanks for the ping, I use irccloud now so I don't need to be logged in to get pings :-)
<zyga> :)
<zyga> cool
<ijohnson> and I closed that bug as FixReleased, the command exists, it's just called `snap stop --disable`
<ijohnson> unclear if that command existed when the bug was filed but it exists now
<mup> PR snapcraft#2737 closed: cli: add -s back to clean for legacy <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2737>
<zyga> thank you
<ijohnson> mvo: you were right it was a bunch of binaries I had in my git tree which made it run out of space, should we perhaps include `git clean -xfd` in the prepare section for spread?
<mvo> ijohnson: sounds sensible!
<mborzecki> mvo: poedit is gtk3, uses gnome-3-26-1604 and works fine, fonts are rendered correctly
<mup> PR snapd#7544 opened: tests: fix snapd-failover test for core18 tests on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7544>
 * zyga -> food
<ijohnson> pstolowski: mind giving a review to #7437 when you get a chance?
<mup> PR #7437:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7437>
 * cachio lunch
<pstolowski> ijohnson: sure, will do, but most likely tomorrow
<ijohnson> that's fine, thanks!
<pedronis> Chipaca: I did a pass on #7445, looking good but tests need some addition/tweaks
<mup> PR #7445: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
<Chipaca> pedronis: thanks
<Chipaca> âThanks all, love the work you guys are doing. Itâs helped us reach users and saves us a lot of time and energyâ
<Chipaca> https://forum.snapcraft.io/t/autoconnection-of-camera-for-wickrpro/13413/7?u=chipaca
<Chipaca> <3
<zyga> nice :)
<roadmr> â¤
<Chipaca> I'm going to soft-eod and try to sneak in a run before the sky falls
<mup> PR snapd#7542 closed: release: 2.42 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7542>
<mvo> xnox: adding abootimg to initramfs-tools-ubuntu-core in eoan has triggered lp 1846208
<ijohnson> pedronis: looking at mvo's usage of `snap model` in #7538 shows me that there are a number of cases where we can't use `--verbose` and have to use `--assertion` even in the scripted case like we have in the tests, is it okay if I ping you to look at that PR (can be tomorrow) just to think about the current design for `snap model` ?
<mup> PR #7538: tests: use `snap model` instead of `snap known model` in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7538>
<xnox> mvo:  yes. it's naughty to use things in the image-build PPA that are from universe, as there is no security support for them.
 * ogra is surprised abootimg isnt in main yet given it was the most essential bit to actually boot our phones
<ogra> we have used and supported it for at least 5 years before
<ogra> seems it simply never moved to the right archive component
<enkayz> hey ladies
<cachio> mvo, hey, I see this error when I reboot core 18 https://paste.ubuntu.com/p/WpNftfG5G2/
<cachio> on my pi3
<cachio> fail unmounting writable
<pedronis> ijohnson: mmh
<pedronis> ijohnson: I'm probably missing something
<ijohnson> let me submit my PR review if you want to look at it right now
<ijohnson> pedronis: look at https://github.com/snapcore/snapd/pull/7538#pullrequestreview-295727879
<mup> PR #7538: tests: use `snap model` instead of `snap known model` in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/7538>
<pedronis> yes?
<ijohnson> so there are instances where we can't use `snap model --verbose` to look at authority-id for example
<ijohnson> so firstly I was wondering if we should include `authority-id` in `--verbose`
<ijohnson> secondly, we can't use `snap model --verbose` to easily look at the `model`, since we have the display-name before the actualy model value
<pedronis> ijohnson: mmh, I probably misunderstood something
<pedronis> when we finalized the other PR
<ijohnson> so since this is the first time I've seen someone other than myself try to use snap model in a programmatic way, I'm wondering if we should revisit the discussion around the display-name for the model and whether we should use `authority-id` because here's a use case where we couldn't do that
<ijohnson> s/should use/should show/
<pedronis> ijohnson: I don't think display-name work as intented
<pedronis> for --verbose
<ijohnson> oh that's fair I seem to recall you wanted `model : display-name (value)` for --verbose just like without --verbose
<ijohnson> but I could have gotten that wrong
<ijohnson> pedronis: I need to break for lunch right now, but if you want to just comment on the PR what you think in your morning we can discuss tomorrow if needed
<pedronis> ijohnson: the minsunderstanding was here: https://github.com/snapcore/snapd/pull/7411#discussion_r323704447
<mup> PR #7411: cmd/model: output tweaks, add'l tests <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7411>
<pedronis> ijohnson: because of generic-classic doesn't have a display-model
<pedronis> ijohnson: in --verobse is strange to have the display-name in model and in display-name
<ijohnson> ok so it does sound like a bug with `snap model --verbose`, I should have done the similar thing with model/display-name that we did with brand/brand-id
<ijohnson> so then, `snap model` -> shows `display-name (value)`
<ijohnson> `snap model --verbose` -> show `model: value` and also `display-name: display-name-thing`
<ijohnson> is that correct?
<pedronis> yes
<pedronis> I thought it was already implemented like that
<pedronis> because of my comment
<ijohnson> no I don't think it is implemented like that I just tried in a UC vm with snapd edge and it looks like this:
<pedronis> but the discussion uses an example without a display-name
<pedronis> it's not
<pedronis> I looked at the code
<pedronis> the x.Serial case was split intoo
<ijohnson> https://pastebin.ubuntu.com/p/6cwvVwf28k/
<pedronis> in two
<ijohnson> alright I will submit a fix to snap model for that then
<ijohnson> also quick, while you're here, do you need to review #7437 or can I merge when I get a 2nd review?
<ijohnson> pedronis: ^
<mup> PR #7437:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7437>
<pedronis> ijohnson|lunch: you can merge with a 2nd review
<pedronis> ijohnson|lunch: I will look at the final one once the prereqs are in
<pedronis> ijohnson|lunch: what's the use case for authority-id in --verbose apart tests, at least for model is always the same as brand-id
<pedronis> ?
<xnox> ogra:  phone was built out of universe
<mvo> cachio: is this new?
<cachio> mvo, don't know
<cachio> because I saw this on my device
<cachio> and bata and edge validation are done on the lab devices
<mvo> ijohnson|lunch: is snap model in 2.42?
<mvo> cachio: ok, would be great to check if its a regression compared to 2.31
<mvo> cachio: eh 2.41
<mvo> cachio: and if so I think we need to see if its reproducible and if so we probably need a 2.42.1 :/
<cachio> mvo, I'll check now against stable
<cachio> it is 2.41
<mvo> cachio: oh? so this happend on 2.41?
<cachio> no
<cachio> sorry
<cachio> is it 2.42
<cachio> my fault ;)
<mvo> cachio: ok, thanks. let double check if it happens all the time and also if it happen with 2.41
<cachio> mvo, sure, thanks
<mvo> cachio: thanks, I will soon eod, but if you could mail me a brief summary of your findings that would be great
<cachio> mvo, sure, so far we are ok but I had to re-execute some tests because of the issue that we saw running 2.42~pre
<cachio> mvo, the issue related to the memory
<mvo> cachio: right
<mvo> cachio: yeah, that is a also a bit worrying
<mvo> cachio: the umount issue is also something we need to double check
<mvo> cachio: but not rush, I won't get a chance to look at any of this today anyway :)
<mvo> (my today)
<cachio> mvo, sure, I'll continue reviewing the results and I'll send you a briefa report
<mup> Bug #1672740 changed: Netplan replug function is incompatible with ath9k_htc module <verification-done-xenial> <verification-done-yakkety> <verification-done-zesty> <netplan:Fix Released by cyphermox> <Snappy:Fix Released> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Released> <nplan
<mup> (Ubuntu Yakkety):Fix Released> <nplan (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1672740>
<mup> Bug #1672803 changed: Console-conf restarts on db when applying wrong wlan SSID or password <Snappy:Fix Released> <subiquity (Ubuntu):Fix Released> <https://launchpad.net/bugs/1672803>
<jdstrand> zyga: hi! fyi, I reviewed 7421 with conditional approval
<zyga> jdstrand: oooh, thank you!
<zyga> jdstrand: I got the note that you are off for the week
<zyga> have a fantastic anniversary :)
<Greyer> 2mVhw5w841008
<jdstrand> zyga: thanks! :)
<mup> Bug #1669476 changed: content: piece of content interfaces now mandatory in trunk <snapd:Fix Released> <https://launchpad.net/bugs/1669476>
<mup> Bug #1674468 changed: More than 36% overhead running tests for dbus interface in snap with devmode confinement <snapd:Triaged> <https://launchpad.net/bugs/1674468>
<mup> Bug #1674634 changed: After initial 'refresh', snapd doesn't work <snapd:Incomplete> <https://launchpad.net/bugs/1674634>
<mup> Bug #1749276 changed: Interface request: dvb <snapd-interface> <snapd:Fix Released> <https://launchpad.net/bugs/1749276>
<mup> Bug #1676614 changed: snap install canonical-livepatch fails on system with nvidia driver <snapd:Fix Released> <https://launchpad.net/bugs/1676614>
<mup> Bug #1749028 changed: snapd and disks <snapd:Fix Released> <https://launchpad.net/bugs/1749028>
<mup> Bug #1680011 changed: snapd support for xdg-desktop-portal <cross-distro> <snapd:Fix Released> <https://launchpad.net/bugs/1680011>
<mup> Bug #1683061 changed: Support wayland <Snappy:Won't Fix> <https://launchpad.net/bugs/1683061>
<mup> Bug #1651090 changed: snap names starting with capital letters aren't supported <capitalized-app-name> <Snapcraft:Opinion> <Snappy:Won't Fix> <https://launchpad.net/bugs/1651090>
<mup> Bug #1648478 changed: 'snap run --shell snap.hello-world.env' tries to read /snap/snap/current <snapd:Confirmed> <https://launchpad.net/bugs/1648478>
<mup> Bug #1651936 changed: autopkgtests fail on ppc64el <snapd:Confirmed> <https://launchpad.net/bugs/1651936>
<mup> Bug #1655594 changed:  expect based tests fails on ppc64el <snapd:Confirmed> <https://launchpad.net/bugs/1655594>
<mup> Bug #1749374 changed: The /bin/sync command is not allowed by default <snapd:New> <https://launchpad.net/bugs/1749374>
<mup> Bug #1756285 changed: Gamepads only working in devmode <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1756285>
<mup> Bug #1761363 changed: Add interface to access to Zeitgeist <snapd-interface> <snapd:New> <https://launchpad.net/bugs/1761363>
<mup> Bug #1833004 changed: Application SNAP is slower than DEB at first launch <snapd:Confirmed> <https://launchpad.net/bugs/1833004>
<zyga> kenvandine: can you please enqueue a sanity check of https://bugs.launchpad.net/snappy/+bug/1834061
<mup> Bug #1834061: qt apps in hidpi looks tiny <Snappy:Triaged> <https://launchpad.net/bugs/1834061>
<mup> Bug #1804281 changed: Cannot refresh snaps if home is in NFS with root_squash <snapd:Incomplete> <https://launchpad.net/bugs/1804281>
<mup> Bug #1839709 changed: does not work under cgroup v2 <snapd:New> <snapd (Debian):Confirmed> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1839709>
<mup> Bug #1828175 changed: Lack of proxy support for snap prepare-image <snapd:Triaged> <https://launchpad.net/bugs/1828175>
<mup> Bug #1834723 changed: snap auto-import causes part-probe to hang while running in a VMware VM <snapd:Triaged> <https://launchpad.net/bugs/1834723>
<mup> Bug #1841327 changed: Install snaps in Dockerfile <wishlist> <Snappy:Won't Fix> <https://launchpad.net/bugs/1841327>
<zyga> ijohnson: can you please enqueue a quick pass over https://bugs.launchpad.net/snapd/+bug/1795947
<mup> Bug #1795947: `snap services` should indicate when services are a oneshot <snapd:Triaged> <https://launchpad.net/bugs/1795947>
<ijohnson> zyga: sure as long as you can enqueue some sleep :-)
<zyga> ijohnson: yeah, I should
<zyga> one last and I'm off
<ijohnson> famous last words!
<mup> Bug #1795947 changed: `snap services` should indicate when services are a oneshot <snapd:Triaged by anonymouse67> <https://launchpad.net/bugs/1795947>
<zyga> ok, I'm off :)
<zyga> night night :)
<zyga> down to 66 new bugs on snappy
<mup> Bug #1801567 changed: /home/* access not available <snapd:Triaged> <https://launchpad.net/bugs/1801567>
<ijohnson> good work! and good night zyga :-)
#snappy 2019-10-02
<mup> PR snapd#7545 opened: cmd/model: don't show model with display-name inline w/ opts <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7545>
<mborzecki> morning
<mborzecki> mvo: morning
<mup> PR snapd#7540 closed: interfaces/seccomp: query apparmor sandbox helper rather than aggregate info <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7540>
<mvo> hey mborzecki !
<mvo> mborzecki: how are tests looking today?
<mborzecki> mvo: not worse than usual
<mvo> ok, just wondering as I see a few reds from the night
<mvo> mborzecki: the timeout test failure is peculiar - do you have any idea why it happens? do we have more than 52s wait under certain conditions with our retry stratgy?
<mborzecki> mvo: no clue yet, i can reproduce it with spread, but it doesn't make sense, there's snap find executed couple lines earlier and that works fine
<mvo> mborzecki: confusing!
<mvo> mborzecki: can you reproduce it by e.g. blocking the store with iptables and then running snap find locally?
<mvo> mborzecki: I wonder if we use a different retry strategy for some command or something crazy like this
<mborzecki> mvo: but then, across all the restarts, it happened only on opensuse
<mborzecki> mvo: hmm daemon.go:316: DEBUG: pid=9079;uid=0;socket=/run/snapd.socket; GET /v2/find?scope=wide&section=featured 1m0.45857103s 200
<mvo> mborzecki: oh, interessting!
<mborzecki> Oct 02 06:36:47 oct020627-523151 snapd[8948]: retry.go:61: DEBUG: The retry loop for
<mborzecki> https://api.snapcraft.io/api/v1/snaps/search?confinement=strict%2Cclassic&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cbinary_filesize%2Cdownload_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Csnap_id%2Clicense%2Cbase%2Cmedia%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cdevelop
<mborzecki> er_name%2Cdeveloper_validation%2Cprivate%2Cconfinement%2Ccommon_ids&scope=wide&section=featured finished after 1 retries, elapsed time=1m0.45638716s, status: 200
<mborzecki> mvo: hm so we don't really set a timeout for the store request context
<mborzecki> tbh beats me why this consistently fails on opensuse
<zyga> Gooooood morning
<mborzecki> zyga:  hey
<zyga> This feels like a good day
<zyga> Iâm taking Bit for a walk but I will be back shortly
<zyga> Today is a cgroup day
<mborzecki> mvo: i'll see if i can improve the error message maybe, 'context deadline exceeded' isn't really nice ux
<mborzecki> mvo: and perhaps find should not use a timeout then
<mvo> mborzecki: yeah, the ux improvements would be more than welcome
<mvo> mborzecki: do we use no deadline when we do the store find api call in the daemon? or just a diffrent one?
<mborzecki> mvo: hmmm, so we use httputil and set a http.Client.Timeout which is set in store.New() to 10s, yet the request somehow takes 1m
<mvo> mborzecki: thats confusing
<pstolowski> morning
<mvo> mborzecki: also there was no retry, right?
<mborzecki> mvo: no retry, it finished after the first attempt which was successful
<mborzecki> pstolowski: hey
<mvo> mborzecki: confusing++
<mvo> mborzecki: makes me wonder if our timeout is actually working
<pstolowski> mborzecki: reviewing your schedule fix pr
<mborzecki> pstolowski: thanks! better grab a coffe :P
<pstolowski> mborzecki: yes, i'm on a 2nd coffee already ;)
<mborzecki> mvo: trying with this snippet using httputil.Client https://paste.ubuntu.com/p/Xcc7bfxtKf/ timeout seems to work
<mvo> mborzecki: even more puzzling
<mvo> mborzecki: we use bundled deps on opensuse, right? it can't be some strange bug in some external go package packaged in opensuse?
<mborzecki> mvo: so crazy thought, the search results are super long, and we run with SNAPD_HTTP_DEBUG=7, what if journald/systemd blocks reading from stderr?
<mvo> mborzecki: could be! an interessting idea. it would be quite a bug though
<pedronis> mvo: hi, I made some high-level comments again in #7536, I didn't look at detail of the gadget code
<mup> PR #7536: gadget: accept system-seed role and ubuntu-data label <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7536>
<mvo> pedronis: thank you! yeah, it matches my understanding.
<mborzecki> google:opensuse-15.1-64 .../tests/main/searching# snap find --section=featured
<mborzecki> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/find?scope=wide&section=featured: context deadline exceeded
<mborzecki> mvo:  ^^ heh
<mborzecki> mvo: so, was able to trigger this by executing snap find a number of times in succession
<mvo> mborzecki: but *just* on opensuse?
<mborzecki> mvo: well, i have debug shell on opensuse open now :P
<pstolowski> mborzecki: some comments/questions
<mup> Bug #1647256 changed: snap create-user cannot add a new user to an existing ubuntu core device <Snappy:Won't Fix> <https://launchpad.net/bugs/1647256>
<zyga> mvo, pedronis, mborzecki: https://forum.snapcraft.io/t/enabling-new-snapd-features-on-next-boot/13493
<zyga> this is a required intermediate step for refresh app awareness _and_ for parallel instances and perhaps also for parallel installs for classic
<zyga> I'd like to start implementing this as I really need it to have the ability to do some of the cgroup operations reliably
<pedronis> zyga: so are you saiyng that some featue even after set will be on only after a reboot?
<Chipaca> yes, yes he is
<pedronis> zyga: also it is really reboot or restart of snapd?
<Chipaca> pedronis: AIUI it's a reboot because things need to be set up before apps / services are started
<mborzecki> ehh, go errors are so bad
<Chipaca> mborzecki: -1
<mborzecki> also our client error handling is kind of bad too, especially the retry thing, but if we start looking at the errors, trying to find out which one is temporary or not, we're again into go-errors-are-bad territory
<Chipaca> mborzecki: client as in snapd/client/ ? or as in snapd/store/ http client usage?
<mborzecki> Chipaca: snapd/client
<Chipaca> mborzecki: ah. I'll be looking at the temporary vs not thing as part of download at some point
<Chipaca> well, that was the plan, but if you're there already
<zyga> pedronis: it is about really reboot
<Chipaca> mborzecki: basically the retry thing should look at externalities (bah, the existence of the socket :) ) to know whether to actually retry or not
<mup> PR snapd#7546 opened: daemon: add a 'prune' debug action <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7546>
<pedronis> zyga: you need to explain why because I don't know it, that topic says a lot of things except why exactly
<pedronis> it's very hard to judge if it's a good solution or not given the problem isn't clear
<pedronis> it sounds very complicated for sure, that I can say
<zyga> pedronis: as I said on the post "The feature only really works reliably if enabled before anything using said feature is used". We need this to reliably track cgroups for all processes using the feature. We also need it to establish a tracking cgroup so that we can get release notification handlers set up.
<pedronis> zyga: please write down the details of the things we need to have, anyway is it related to version of snap-confine? or only install time stuff? or only boot time stuff?
<zyga> pedronis: for parallel instances I think we need a new mount unit for /snap or we will have transition issues as well.
<pedronis> zyga: parallel instances for classic? in general?
<pedronis> zyga: as a principle it's better to check for precise things, that for something correlated to those things
<zyga> pedronis: it is really about system-level machinations we perform, either we do or we don't at all - then the model is simple. If we sometimes do and sometimes don't because snapd was updated and apps are already running then there's all kinds of messy complexity that this solution avoids
<pedronis> zyga: this is not useful, your are talking about general principles
<zyga> pedronis: it involves systemd units, snap-confine behavior (applied consistently) and snapd behavior which relies on it
<pedronis> I need the details of the single problems
<pedronis> in the forum topic
<pedronis> otherwise we are not going anywhere here
<zyga> pedronis: there are multiple distinct ones, an existing one is where refresh app awareness misbehaves if enabled without rebooting because it doesn't known about processes that were started before the tracking was established
<pedronis> zyga: but tracking involves snap-confine code, no?
<zyga> pedronis: the /snap mount propagation changes must happen before any systemd mount unit is started so it cannot be really enabled mid-way once the system is up and running
<zyga> pedronis: yes, it involves snap-confine code
<pedronis> zyga: so don't think the solution is appropriate
<zyga> pedronis: why?
<pedronis> zyga: because I can switch around snap-confine version without reboots
<zyga> pedronis: note, it involves many other components as well, not just snap-confine
<zyga> pedronis: so?
<pedronis> so the tracking gets broken
<zyga> pedronis: how?
<zyga> pedronis: I think you are trying to find a bug in the system
<zyga> pedronis: the bug is already there
<zyga> pedronis: this allows us to fix the bug once we want to _enable_ experimental features that are currently disabled when unset
<zyga> pedronis: this allows us to _reliably_ make _that_ specific change
<pedronis> zyga: I disagree on the reliable part
<zyga> pedronis: can you explain please?
<pedronis> zyga: please write in the forum info of the form. Feature x is reliable if :  mount unit z looks like this,  all currently running apps for snas where started by a snap-confine with tracking code etc
<pedronis> then we can disuss details
<Chipaca> pedronis: context switch! we currently sub core for core16, do we have plans of doing the converse someday?
<pedronis> Chipaca: I was asking myself the same question looking at your code yesterday
<Chipaca> :-)
<pedronis> Chipaca: in principle maybe, but I would write code for that now, you can put a TODO somewhere though
<Chipaca> pedronis: the first generalization of baseUsedBy took a otherBases ...string, but I deemed it over-engineered for what we used it for
<pedronis> *I wouldn't write
<pedronis> sorry
<Chipaca> yeah i gotcha
<zyga> pedronis, Chipaca: note that if we want to substitute core16 for core we need new logic
<zyga> in snap-confine at least
<Chipaca> zyga: in snapstate as well
<pedronis> zyga: yes, I imagine we need various code everywhere
<zyga> this also amplifies the effect of a bug that needs design resolution on the forum
<zyga> (about snap tools)
<pedronis> that's why I said it doesn't make soon to add support for it just in Chipaca's new code
<pedronis> s/soon/sense/
<zyga> yeah, I think that should be done only after core18 tooling situation is stable
<zyga> pedronis: as to your question, I'm responding to the forum thread but I will create a separate thread for the tracking features that in my eyes justify the need for such a system
<zyga> pedronis: I'll give you a link when I have that in written form
<zyga> pedronis: thank you for looking :)
<zyga> mvo: I just noticed your status update in yellow
<zyga> mvo: do you know if that was core18?
<mvo> zyga: that is a very good question - cachio will know, all I have is https://paste.ubuntu.com/p/WpNftfG5G2/ and that its not a regression
 * zyga looks
<Chipaca> hmmmmm
<zyga> heh
<Chipaca> pedronis: zyga: core installed in a core18 system, and install a snap with base:core16, and then install core16, and then go to remove core, how far do you need to run?
<zyga> the bug is: we never ran system-shutdown
<zyga> mvo: ^
<zyga> mvo: please report that for tracking
<zyga> or it will be lost in the rain
<zyga> mvo: probably the glue logic for shutdown is missing
<zyga> mvo: I forgot how we inject system-shutdown into initramfs
<zyga> anyway, something for later
<zyga> not for today
<zyga> today I really want to start this new feature work
<pedronis> mvo: I updated #7462 to Paris decisions
<Chipaca> mvo: what's that bastebin from?
<mup> PR #7462: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7462>
<Chipaca> mvo: that's missing things :-(
 * mvo is in a meeting
 * Chipaca hugs mvo for protecting us all from meetings
<mvo> Chipaca: pastebin is from cachio
<mvo> zyga, Chipaca: do you already know whats missing ?
<Chipaca> mvo: I know what didn't happen, but I don't know what's missing without more context
<mvo> Chipaca: ok
<Chipaca> mvo: there's an involved little dance that needs to happen for the system shutdown helper to be called
<Chipaca> it hasn't been called
<Chipaca> so the dance didn't happen, or didn't work
<Chipaca> or _something_ :)
<mvo> Chipaca: ok
<mvo> Chipaca: still in a meeting so can't poke at this right :/
<Chipaca> mvo: time is immaterial, or of the essence
<mborzecki> Chipaca:  pushed a small refactor to #7166 to actually make sense of the errors returned in the client. can you take another look?
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<zyga> mvo: a hunch, I can confirm in 10 minutes
<Chipaca> mborzecki: lgtm
<mborzecki> jamesh: thanks for the hint about cache, i've tweaked the mount namespace of the snap and mounted a clean tmpfs over /var/cache/fontconfig, the fonts appear correctly now (although at the cost of longer start time)
<Chipaca> mvo: zyga: core18 seems to not have /lib/systemd/system/snapd.system-shutdown.service
<Chipaca> that's the service that does the dance
<Chipaca> why is it not there?
<Chipaca> it was there before, I remember checking for this in core18
<mborzecki> Chipaca: thanks!
<jamesh> mborzecki: interestingly the snaps using gnome-3-26-1604 are running with newer fontconfig than those using gnome-3-28-1804
<jamesh> It is a bit annoying to see that 2.14 is going to be different yet again though
<mborzecki> jamesh: hm, perhaps updating gnome-3-28-1804 would be enough?
<jamesh> mborzecki: the 3-26 platform snap was built with a backport of new desktop libraries to 16.04, while 3-28 is just packaging what was in vanilla 18.04
<jamesh> it's a bit harder to replace random libraries there
<Chipaca> mvo: zyga: oh, it's at /etc/systemd/system/snapd.system-shutdown.service in core18
<Chipaca> mvo: zyga: straange, but ok
<Chipaca> mvo: zyga: and if the pastebin is indeed from core18, I've just confirmed that core18 on amd64 does do the shutdown dance
<Chipaca> mvo: zyga: http://r.chipaca.com/core18-shutdown.png
<pedronis> Chipaca: sorry, https://github.com/snapcore/snapd/pull/7445/files#r330474755
<mup> PR #7445: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
<mvo> Chipaca: nice, thank you! so we need cachio to help with details, I think this was a on a pi
<mvo> Chipaca: but that should not make a difference :/
<Chipaca> mvo: maybe it's a fake core image, and whatever does the dance to set up the snapd.system-shutdown.service unit is missing?
<Chipaca> because that unit is in /lib in core that setting up for a core system wouldn't be necessary
<zyga> Chipaca: that's interesting
<zyga> Chipaca: it would be fun if the following were true
<Chipaca> the fact that it's in /etc in core18 means something is adding it
<zyga> Chipaca: system-shutdown is broken by our extra mount points set up to execute tests on core systems
<Chipaca> seems like a strange decision
<zyga> Chipaca: but I think we need to get sergio to just tell us what was executed
<zyga> until then we know too little
<Chipaca> speak of the devil
<Chipaca> cachio: buen dÃ­a!
<Chipaca> pedronis: which "other request"?
<pedronis> Chipaca: to enumerate the keys being set
<Chipaca> ah
<Chipaca> pedronis: yeah, it's weird that you don't get to see that
<cachio> Chipaca, buen dia!
<Chipaca> cachio: we've been puzzling over https://paste.ubuntu.com/p/WpNftfG5G2/
<Chipaca> cachio: what is the system running there? because it's missing something :) maybe
<cachio> Chipaca, here you have more details https://paste.ubuntu.com/p/WmVCD8SvTz/
<cachio> it is pi3 running core 18
<cachio> that one is more interesting
<cachio> Failed unmounting /var/lib/snapd.
<Chipaca> cachio: that is expected
<Chipaca> cachio: i think
<Chipaca> cachio: but that pastebin is different from the other in a crucial way
<Chipaca> snapd system-shutdown helper: started.
<Chipaca> ^ those lines
<Chipaca> cachio: that is: systemd _can't_ unmount everything cleanly because it's all very circular; only something completely static and mounted outside of /writable can do that. So the system-shutdown helper does that.
<cachio> Chipaca, the short pastebin is what I got from the screen doing copy&paste
<Chipaca> cachio: and the long one?
<cachio> the long one I used screen tool to log it
<cachio> with -L
<Chipaca> cachio: but it's not the same run, is it?
<Chipaca> i mean, the output is different
<cachio> Chipaca, no
<Chipaca> ok
<cachio> different runs
<Chipaca> cachio: so, the long one is fine AFAIK
<Chipaca> cachio: the short one is not
<Chipaca> cachio: what is the difference?
<cachio> Chipaca, the short one is after running the tests
<cachio> Chipaca, the long one is with a fresh image
<Chipaca> zyga: is that what you meant about the test bind mounts breaking things?
<cachio> Chipaca, is this expected? [FAILED] Failed unmounting /writable.
<Chipaca> cachio: yes, that is expected
<Chipaca> cachio: note further down: snapd system-shutdown helper: - was able to unmount writable cleanly
<zyga> Chipaca: yes, I suspect our test preparation breaks this mechanism
<ogra> Chipaca, it would be cool if we could teach systemd to omit that /writable message ... users notice the red more than the later message of the shutdown helper
<ogra> (orthogonal to your discussion indeed)
<Chipaca> ogra: I looked into that in the core timeline and didn't find a way
<Chipaca> ogra: there might be a way now but i haven't re-checked
<ogra> ah, k
<ogra> (perhaps we could omit the writable mount unit from the start ... ? after all we dont really need it, it is just the silly systemd policy of creating usints for everyhing in fstab that creates it)
<Chipaca> do we need it in fstab even
<ogra> good question
<ogra> (the initrd scripts generate fstab and add writable there ... someone would have to test if we could omit it)
<zyga> ogra, Chipaca: systemd doesn't need fstab, it understands mount table directly
<zyga> fstab is a way to convey extra options
<zyga> ideally we would change things a little so that we can boot with just systemd created mount table
<zyga> but that ship has sailed AFAIK
<zyga> until perhaps core20
<zyga> mvo, xnox: is the experiment to boot with systemd in initrd still ongoing?
<xnox> zyga:  yes
<zyga> xnox: is it promising?
<xnox> zyga:  however, systemd does require either -.mount or like / declared in fstab.
<xnox> zyga:  hence e.g. our lxd containers declare that in fstab
<zyga> xnox: _or_ specific declaration in GPT
<zyga> xnox: then you can boot without /etc
<xnox> zyga:  -.mount unit needs to exist, whether gpt-generator or fstab-generator created it, doesn't matter, that is true. or if -.mount is written in /usr/lib
<ogra> xnox, the prob we have is a loopback mounted / ... where on shutdown systemd tries to pull out the carpet underneath the rootfs by trying to unmount /writable
<zyga> xnox: yeah, agreed
<xnox> ogra:  well, use finalrd to pivot into shutdown initrd which then has everything in ram to kill all the things, and unmount all the things, cleanly. despite layering.
<xnox> ogra:  or declare LazyUnmount=yes on /writable
<zyga> mm
<ogra> xnox, on shutdown you go back into intird nowadays?
<zyga> initrd is removed on boot (as in removed from memory) but I may be mistaken
<ogra> how would you declare LazyUnmount=yes  ? the mount unit is created by a generator ...
<ogra> so that generator would have to know that /writable is a special thing while creating the unit
<zyga> ogra: I think we don't need lazy, we need to describe how we actually booted in the first place -- I think then systemd should be able to undo that
<ogra> (but that sounds like a possible solution actually)
<zyga> but anyway, I have things to do, this is in good hands
<ogra> zyga, not sure because what we do is actually very hackish
<zyga> ogra: let's just make ubunt-core cloud native: let's boot core in a small container created by a regular system ;)
<ogra> s/regular system/initrd/ ...
<ogra> :)
<xnox> zyga:  ogra: not back into initrd, but pivot_root to /run/initramfs/ something that looks like initrd, is in ram, but has /shutdown instead of /init
<xnox> $ apt install finalrd
<zyga> yeah
<xnox> $ sudo finalrd
<zyga> xnox: this matches my memory
<xnox> and checkout what's in /run/initramfs/
<Chipaca> xnox: zyga: ogra: snapd.system-shutdown.service does the run/initramfs thing
<Chipaca> not initramfs but whatever
<zyga> yep
<Chipaca> it sets up things to be pivoted into
<Chipaca> that bit is fine
<ogra> xnox, oooh, thats sexy ... ! whose baby is that, yours ?
<xnox> Chipaca:  yeah, but as discussed with mvo need to check if that does everything / enought / right
<xnox> (yesterday on a different call with shutdown issues)
<Chipaca> xnox: i hadn't heard that, but ok
<Chipaca> maybe LazyUnmount is all that's needed for the angry red to go away
 * Chipaca tries
<ogra> yeah, but how to get it into the unit ?
<ogra> you'd have to hack the generator and special-case /writable
<xnox> Chipaca can create /run/systemd/system/writable.mount.d/lazy.conf with [Mount] LazyUnmount=yes
<xnox> ogra:  it's a unit.... and supports drop-ins..... like everything
<ogra> oh, indeed !
<Chipaca> yep am already trying that
<Chipaca> in /etc not /run but w/e
<Chipaca> xnox: also also why is bash-completion not in core18 :-(
<ogra> the question is ... does that at least call sync to make sure ram is flushed to disk ? so we dont end up with fs corruption
<Chipaca> ogra: system-shutdown helper does the actual unmounting
<ogra> Chipaca, i know but in case of Lazy... would we still need the shutdown helper if systemd calls sync ?
<Chipaca> ogra: systemd can't unmount /writable
<Chipaca> it _can't_
<Chipaca> systemd is _running_ from /writable
<Chipaca> from a loopback filesystem mounted from /writable to /
<ogra> well, i know :)
<ogra> but its fine to not unmount if you are able to flush everything to disk
<Chipaca> adding LazyUnmount=yes to /writable leads to system-shutdown helper not being able to find it
<Chipaca> so that one is a no
<Chipaca> ehhh
<Chipaca> maybe i should let other people worry about this
 * Chipaca has other stuff to worry about
<xnox> Chipaca:  what is your original issue? maybe i can take over it?
<Chipaca> xnox: nothing serious: core18 (as core) prints a nasty WARNING about not being able to unmount /writable
<xnox> Chipaca:  on shutdown, right?
<Chipaca> xnox: that is worrisome for users
<xnox> Chipaca:  i think that is fixable.
<Chipaca> shutdown/halt/reboot/etc
<xnox> gotcha
<Chipaca> xnox: the system-shutdown helper then kicks in and makes sure everything is alright
<Chipaca> OTOH, and the point where I would have to sink time into this, is whether this LazyUnmount thing actually does the right thing somehow?
<Chipaca> dunno
<xnox> Chipaca:  which is same as on live media today, when booted with casper. There are similar warnings about not being able to unmount /cdrom which is like the same thing.
<Chipaca> if the shutdown helper is no longer needed, huzzzah :)
<Chipaca> xnox: yeah
<xnox> Chipaca:  the other alternatives i was looking at, is to declare [Unit] DefaultDependencies=no => such that initial run of unmounts, doesn't try to unmount writable at all.
<xnox> but the later helper undoes it all
<Chipaca> xnox: that does seem to work
<Chipaca> at least wrt not printing the warning
<Chipaca> the system-shutdown helper logging sometime doesn't make it to the terminal, for some reason, which is weird
<Chipaca> cachio: ^^^ that's relevant to your pastebin
<Chipaca> sometimes things don't appear where i expect them to be :-|
<cachio> Chipaca, i'll try to run tests 1 by 1 and reboot to see if at some point we see that
<pedronis> pstolowski: I reviewed #7518 , couple things look a bit off
<mup> PR #7518: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <https://github.com/snapcore/snapd/pull/7518>
<pstolowski> pedronis: ty
<Chipaca> lunch, you say?
 * Chipaca bows to the inevitable
<mup> PR snapd#7166 closed: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7166>
<mup> PR snapd#7527 closed: interfaces/input: support confined snaps accessing keyboard and mouse directly <Created by AlanGriffiths> <Closed by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7527>
<Chipaca> "take up running", they said. "it's healthy", they said.
<cwayne> Chipaca: who said that theyre dumb
<Chipaca> that was my knee talking, you may disregard
<mup> PR snapd#7546 closed: daemon: add a 'prune' debug action <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7546>
<Chipaca> cachio: about the 'snap logs' issue, i think the test is buggy
<Chipaca> cachio: it assumes the only lines in the log come from the unit, but they can also be from systemd
<Chipaca> cachio: and the systemd ones happen 'at random' (not really random, but from the PoV of the test they are unpredictable)
 * Chipaca adds support for refresh.metered=hodl
<ogra> hodl !
<cwayne> hodor
<blake_r> i submitted a form to register the "maas-cli" snap in snapcraft.io (being that its reserved), but I have not received a response and its been a few days
<blake_r> did I go about that the correct way?
<Chipaca> roadmr: is that a you? ^
 * roadmr ducks behind the nearest shrub
<roadmr> Chipaca, blake_r : let me check the queue
<ogra> just use Chipaca's hodl to hide behind
<roadmr> blake_r: I see blake-maas-cli which is approved
<blake_r> roadmr: yeah the form required me to use that name
<blake_r> roadmr: but I really wanted maas-cli
<blake_r> roadmr: if you could have it owned by Canonical, that would be good as well ;-)
<blake_r> roadmr: as the "maas" snap is going to use a content interface to the maas-cli snap
<roadmr> blake_r: I can't rename a snap; can you please request maas-cli again? if it asks you to file a dispute, please do so, then I can approve it and give you the name
<blake_r> i tried that, but the form hit a validation error
<blake_r> let me try again
<roadmr> blake_r: try this form: https://dashboard.snapcraft.io/register-snap/
<blake_r> roadmr: hmm worked that time
<blake_r> roadmr: should be there
<roadmr> ðª
<blake_r> roadmr: can the blake-maas-cli be removed?
<roadmr> blake_r: I can revoke it
<blake_r> roadmr: can you also do "meta-maas-blake"?
<roadmr> revoke that one? sure
<blake_r> roadmr: sure just to make my snapcraft account clean!
<blake_r> roadmr: thank you
<blake_r> roadmr: now how do I go about getting the maas-cli to be owned by Canonical
<blake_r> roadmr: do I need to push a snap first?
<roadmr> blake_r: we transfer it to the canonical account; we typically only do that once there's a snap there, preferrably on stable. Fine to keep under your account while the snap is still developer-grade
<roadmr> blake_r: (to be clear, you ask us to transfer it, preferrably via snap-store-admins@lists.canonical.com)
<roadmr> please :)
<blake_r> roadmr: will do
<roadmr> thanks :)
<blake_r> roadmr: thank you!
<zyga> pedronis_: running test with the new cgroup idea
<roadmr> blake_r:  meta-maas-blake is in some weird state, it'll take me a bit to fix it.
<cachio> Chipaca, ok, so I'll update the test
<cachio> Chipaca, thanks for the info
<roadmr> blake_r: I think I fixed meta-maas-blake
<blake_r> roadmr: yeah I see its gone, thank!
<mup> PR snapd#7547 opened: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<Chipaca> who knows about the snap store proxy these days?
<mvo> zyga: nice, surprisingly small
<zyga> it has some clenaups that I can fork off and do separately
<zyga> still working on it though :)
<mup> PR snapd#7548 opened: tests: update snap logs to match for "test-snapd-service" instead of "running" <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7548>
<zyga> but that's bulk of the idea
<joeubuntu> I have an update to my snap, I incremented the version in the yaml, built a new snap and pushed it. But the version on the listing page did not increment. What is the correct way to do this ?
<zyga> oh, github has added multi-line comments!
<zyga> joeubuntu: what is the listing page?
<joeubuntu> hey zyga https://snapcraft.io/teamtime
<Chipaca> joeubuntu: did you release the pushed revision?
<ogra> snap info temtime shows a revision from today in stable
<ogra> *teamtime
<joeubuntu> Chipaca maybe :)
<Chipaca> ogra: yes but it's revision 1
 * zyga is hungry for real lunch
<joeubuntu> ogra, but if I install it , it pushes the old version .
<zyga> that breakfast-for-lunch was not a good idea
<Chipaca> joeubuntu: the revision in stable is revision 1
<Chipaca> joeubuntu: that's not an update of anything :)
<zyga> :-)
<joeubuntu> Chipaca , how would I increment that? I pushed a 2.0 up
<zyga> joeubuntu: release
<ogra> zyga, try brunch-for-dinner instead ... way better ...
<Chipaca> joeubuntu: snapcraft list-revisions teamtime
<Chipaca> joeubuntu: identify the revision you want to be in stable
<Chipaca> joeubuntu: then, snapcraft release teamtime <that revision> stable
<Chipaca> joeubuntu: there are flags on push to do this in a single step
<Chipaca> ie snapcraft push --release=<channel> the.snap
<joeubuntu> cool. it worked thanks Chipaca !
<Chipaca> shocking :)
<joeubuntu> great, thanks for the help.
<Chipaca> joeubuntu: this was all a marketing ploy wasn't it
<joeubuntu> I think looking at my revision history you'd see it took me at least 4 tries :)
<cachio> Chipaca, after running the snapd-failover test the reboot is not triggering the snapd system-shutdown helper anymore
<cachio> Chipaca, do you know if is it any way to restore it
<cachio> so I don't need to reflash the sd card
<Chipaca> cachio: zyga was the one with insight into it not working i think
<Chipaca> wrt mounts?
 * zyga runs
<zyga> I didn't look at specific
<zyga> just said it felt like something we would break
<zyga> ;-)
<zyga> it may also
<zyga> indicate
<zyga> that there's a real bug
<zyga> unrelated to the test itself
<zyga> fixed a bunch of silly stuff, trying again
<zyga> I think refresh-app-awareness test will now pass
<zyga> the management scripts may need tweaking to unmount that though
 * zyga adds a todo
<ijohnson> Chipaca or mvo am I good to merge #7545 now? I fixed the issue with the spread test and it's green with 3 approvals
<mup> PR #7545: cmd/model: don't show model with display-name inline w/ opts <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7545>
<cachio> zyga, after run any test the is not triggering the snapd system-shutdown helper anymore
<mup> PR snapd#7545 closed: cmd/model: don't show model with display-name inline w/ opts <Simple ð> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7545>
<cachio> but if I restart the board again
<mvo> ijohnson: I have not looked and I'm in a meeting but if it has 3 +1 - sounds like it
<ijohnson> ah well pedronis merged it, thanks!
<cachio> the is not triggering the snapd system-shutdown helper is triggered
<zyga> cachio: probably something nukes the shutdown state
<cachio> zyga, yes
<cachio> I'll continue with this after lunch
 * cachio lunch
<zyga> and now it passes, cool
<zyga> ok, wrapping up soon
<zyga> need to adjust mount-ns test to reflect this
<zyga> but I'm super positive this is the way forward
<zyga> mvo: https://github.com/snapcore/snapd/pull/7547 pushed
<mup> PR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>
<zyga> it should pass all tests (we'll see what happens)
<zyga> I'll work with maciek on it tomorrow
<zyga> probably chop it into a smaller part to focus on the essential
<zyga> and add some more tests
<zyga> next up: the release agent :)
<zyga> this is so cool
<zyga> pedronis: ^ if you want to take a peek
<zyga> pedronis: I added a TODO to the pull request
 * zyga EODs
<zyga> enjoy your evenings :)
<blake_r> i got a content interface question
<blake_r> so i created a content interface where i want to expose the maas-cli executable to the maas snap
<blake_r> the interface works correctly
<blake_r> but when the maas snap calls the maas-cli binary none of the SNAP_ are set for the maas-cli they are from the maas snap instead
<blake_r> any ideas on how I can get the environment to be the maas-cli SNAP when calling the binary from the maas snap
<Chipaca> blake_r: sounds like a question for the forum
<Chipaca> blake_r: also note _most_ (but not all!) of the snapd core team is in eu timezone
<Chipaca> blake_r: but that question in particular is best answered by our tame polish horde
<Chipaca> probably
<Chipaca> anyway, i'm not here, i'm having dinner
<blake_r> yeah your messages are invisible ;-)
<blake_r> enjoy dinner
<zyga> blake_r: hey
<zyga> blake_r: can you take a step back
<zyga> blake_r: and tell me what you want to achieve
<blake_r> goal is to keep the "maas-cli" in its own snap
<blake_r> when installing "maas" snap it will also install "maas-cli" using content interface
<zyga> blake_r: while you can change or just ignore SNAP_ environment variables it won't change what happens at runtime, the program will run with the permission of the snap it is used from, not the snap it is coming from
<blake_r> zyga: is it possible to allow a strict snap to call another strict snaps executable? from the system root per say
<blake_r> so like /snap/bin/maas to call /snap/bin/maas-cli ?
<ogra> yes, there are snaps doing that (the wine content snap comes to mind)
<blake_r> okay I will give it a try
<blake_r> that might be all that is needed, if that is possible
<blake_r> https://paste.ubuntu.com/p/qCFGsVPtxb/
<blake_r> ogra: doesn't seem possible
<mvo> rbasak: I guess I'm way too late but I was wondering if you might have a look at the snapd sru in the unapproved queue?
<zyga> re
<zyga> blake_r: no, not today
<zyga> blake_r: you cannot do that with the usual semantics of "that other snap is running"
<zyga> blake_r: you can at most share the bits and run them as yourself
<blake_r> zyga: okay, will try to get it to work by just importing the python library
<zyga> blake_r: if you need to share things more you need an API and you need to make requests to a service
<blake_r> zyga: i think that will work, as that is all that is really needed
<ogra> perhaps try talking to @mmtrt on the forum ... https://forum.snapcraft.io/t/auto-connections-of-wine-base-stable-wine-base-devel-and-wine-base-staging/11229
<ogra> he provides snaps that layer one on top of each other to make wine applications work via content sharing
<ogra> like an onion :)
<ogra> (might also make you cry ... not sure :) )
<mup> PR core18#140 opened: run-snapd-from-snap: check for snapd.service existing too <Created by anonymouse64> <https://github.com/snapcore/core18/pull/140>
 * cachio eOD
#snappy 2019-10-03
<mup> PR snapcraft#2738 opened: mypy: add coverage to tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2738>
<zyga> Good morning
<pstolowski> mornings
<zyga> re
<zyga> sorry, baby watch duty
<zyga> back now
<zyga> hey pawel, good morning :)
<mup> PR snapd#7532 closed: interfaces/openvswitch: allow access to other openvswitch sockets <Created by dosaboy> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7532>
<mup> PR snapd#7549 opened: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549>
<zyga> settle not converging https://www.irccloud.com/pastebin/qfxvW2Qh/
<zyga> pedronis: can we change settle for tests so that it has no timeout
<zyga> and instead it just does more as long as a handler ran
<zyga> I think it's incredibly fragile that our *unit* test suite is riddled with millisecond quantities
<zyga> this is now blocking 2.42 release to opensuse
<pedronis> zyga: it's not that simple because we do have retries
<zyga> it's fine if a test fails forever
<Chipaca> zyga: how are you running the unit tests on opensuse?
<zyga> as in, code us buggy
<zyga> and loops forever
<zyga> go's test stack catches that
<zyga> I think the only problem would be tests that want to see failure
<pedronis> zyga: you say that because you haven't had to debug that
<zyga> pedronis: I have to debug this :)
<zyga> pedronis: I think it is not a unit tests if it has timing-sensitive concurrent operation
<zyga> Chipaca: go test
<pedronis> anyway, as I said is not that simple
<zyga> Chipaca: same as anywhere
<zyga> pedronis: nothing is simple, what we have is just broken randomly
<Chipaca> zyga: try 'go test -short'
<zyga> pedronis: I want to get to deterministic
<Chipaca> zyga: those are more likely to be unit tests
<zyga> Chipaca: I don't see how this is a solution, should we switch to "go test -short" for all unit tests across distributions?
<pedronis> zyga: there is nothing that prevent us to use long settle on traviss
<Chipaca> zyga: do you want solutions, or do you want to vent?
<zyga> Chipaca: I want solutions, this is not one IMO
<zyga> pedronis: is there a place where we cannot?
<pedronis> it's a timeout is set low just to fail fast locally
<Chipaca> AIUI it's not about travis, is it?
<zyga> it is not about travis
<zyga> it's actually failing on my workstation right now
<pedronis> really ?
<pedronis> which one
<zyga> yes
 * Chipaca hands zyga a nickel
<zyga> ?
<zyga> which test?
<pedronis> yes, which test
<zyga> mgrsSuite.TestRemodelSwitchToDifferentKernel
<pedronis> that is recent and might have a real bug
<pedronis> don't know
<pedronis> or be too slow
<pedronis> to start with
<zyga> it has some comments that expand settle time 4 times
<zyga> "because buildds are slow"
<pedronis> well, the test is problematic
<zyga> anyway, since it affects me, I'll look
<pedronis> but I haven't looked at details
<zyga> pedronis: problematic in which sense?
<pedronis> that it might be buggy for real
<pedronis> not just slow
<zyga> aha
<zyga> I'll look
<pedronis> anyway consider that Ian made this: https://trello.com/c/foU3iOrs/321-investigate-testremodelswitchtodifferentkernel-failure
<zyga> thanks, this is useful!
<Chipaca> what is this sorcery
<Chipaca> a trello card created before work is done?!?
 * Chipaca is so bad at trello
<pedronis> it might never get done
<pedronis> though
<pedronis> upcoming is like that
<pedronis> to be fair
<mup> PR snapd#7550 opened: spread.yaml: exclude automake cache <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7550>
<zyga> https://github.com/snapcore/snapd/pull/7550 <- trivial cleanup for build issues
<mup> PR #7550: spread.yaml: exclude automake cache <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7550>
<zyga> tests failed with "unable to contact the snap store"
<zyga> https://status.snapcraft.io/ says all good
 * Chipaca breaks all the policy tests and weeps
<Chipaca> pedronis: I'm starting to suspect this last change doesn't make sense, but i need to take a break
<Chipaca> pedronis: but checking for model before checking rev.Unset means you can't ever remove even a single revision of the model kernel
<pedronis> Chipaca: you need to invert the condition
<pedronis> of course
<pedronis> if not model kernel: can remove     if in use: cannot remove
<pedronis> Chipaca: am I making sense, the flow is more complicated with the change (but more consistent)
<pedronis> ?
<Chipaca> pedronis: currently it's: if !unset { if in_use { bzzzt } else { ok } } else if is_model { bzzt } else { ... }
<pedronis> Chipaca: that's not the question, is it?
<pedronis> I can try to write it down, but does that make sense
<Chipaca> i'm trying to understand what exactly you're proposing
<pedronis> Chipaca: I'm not proposing "exactly" anything
<pedronis> I don't want to be proposing extact things
<pedronis> I can if it helps
<pedronis> Chipaca: the essence of the change is:  don't care about revision if the kernel is not the model kernel
<pedronis> that's my understanding
<Chipaca> do we care about the error, about it being a model kernel?
<pedronis> Chipaca: this:  https://pastebin.ubuntu.com/p/bJ6trqPcn3/
<pedronis> (not promising it makes sense, it does still pass the tests though)
<zyga> can I get a review for https://github.com/snapcore/snapd/pull/7550
<mup> PR #7550: spread.yaml: exclude automake cache <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7550>
<zyga> it's a one liner
<zyga> and it's green :)
<Chipaca> pedronis: I do think that makes sense, although it wasn't obvious to me. But I could blame the painkillers for that, today.
<zyga> pstolowski: perhaps you can look
<zyga> it's just a cache exclusion from spread.yaml
<pedronis> Chipaca: and we want something like this for bases/core too I suspect (if we do the change), well for the other thing using boot.InUse
<pedronis> *things
<Chipaca> pedronis: yes i'm changing all three
<pedronis> Chipaca: thx
<pstolowski> zyga: sure
<zyga> thanks!
<mup> PR snapd#7550 closed: spread.yaml: exclude automake cache <Simple ð> <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7550>
<zyga> pedronis: thanks!
 * zyga goes for lunch
<zyga> pedronis: quick question: release app awareness was so far only implemented for strict snaps
<zyga> pedronis: but there's nothing that holds us to this design, should we expand it to cover classic confinement?
<pedronis> zyga: I don't even remember why?
<zyga> why yes or why not?
<pedronis> why we didn't cover classic?
<pedronis> I'm just not sure it was a design
<zyga> because the code adding tracking was in close proximity to other "strict" setup logic
<zyga> but I think it's not meant to be this way
<zyga> it feels like we didn't notice
<pedronis> yea, that's not a design
<pedronis> it's a bug
<zyga> I added a todo for it
<zyga> yeah, thanks for confirming that
<zyga> I'll untangle that
<cmatsuoka> cachio: seen this in tests? dial tcp 91.189.92.41:443: connect: connection refused
<cachio> cmatsuoka, hi let me check
<cachio> cmatsuoka, I can't see that, do yoiu have a log?
<cmatsuoka> cachio: yes, https://api.travis-ci.org/v3/job/592790683/log.txt
<cmatsuoka> cachio: look for connection refused
<cachio> cmatsuoka, seems to be related to the store, let me talk to them
<zyga> one sec
<pedronis> cachio: zyga: standup?
<sergiusens> blake_r (in case it was not answered, seems not) if maas-cli plugs into a slot in maas, then installing maas-cli would pull in the default provider but installing maas alone would not pull in every snap declaring a plug for it (I suspect that is how this is how these two snaps interact)
<Mirv> oSoMoN: is the chromium vaapi work mentioned in https://discourse.ubuntu.com/t/monday-21st-january-2019/9434/8 now merged in normal chromium snaps?
<blake_r> sergiusens: its the other way
<blake_r> sergiusens: "maas" plugs into "maas-cli", so installing "maas" will install "maas-cli", correct?
<Mirv> oSoMoN: at least I'm getting somewhat lower CPU use with snap versus native package of my distro (same video, full screen, drop from 30-40% to 20-30%). hmm, if only there was a way to query directly whether VAAPI is currently being used by software.
<sergiusens> blake_r if you declare a default provider, yes
<roadmr> ohhh so snapd can now resolve dependencies? snapian.io here we gooooo ðª
<sergiusens> /snap/gnome-calculator/current/meta/snap.yaml can be used for insipiration
<sergiusens> it can try and satisfy interfaces
<zyga> oh, I forgot to mention one thing
<zyga> over weekend (I realize that's a late recollection) I played with a static analyzer
<oSoMoN> Mirv, no it's not, but thanks for asking, it had slipped off my radar, I will test again and if everything still works I'll merge it
<zyga> while somewhat fiddly to setup I found the results useful
<zyga> it's not coverity
<Mirv> ok, thanks oSoMoN! and it seems intel_gpu_top is a good tool to check whether video hardware is being used - I can see a clear distinction between eg a browser and mpv
<Chipaca> "Kindly correct this anomaly."
 * Chipaca hmms
<roadmr> Chipaca: well at least they asked nicely, right? ð¤·
<Chipaca> true, true
 * diddledan blows up the anomoly with a photon torpedo and some inversed polarities
<diddledan> a tachyon beam is probably worth while, too
<Chipaca> diddledan: just don't cross the tachyon beams, or sth
<diddledan> and make sure you're travelling faster than 88 jiggerwatts
 * zyga is tired, needs a break/nap
<zyga> also, my daughter is 11 today
<zyga> so perhaps time to EOD
<roadmr> zyga: congrats to her! ð
<zyga> roadmr: thank you :)
<zyga> I'll let her know
<zyga> store still wonky
<zyga> yeah, I'll take a nap now
<zyga> ttyl
 * Chipaca sharpens his hunting knife an goes for a cuppa
<mup> PR snapd#7551 opened: tests: fix the how the systemd-journald.service is restarted during the prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7551>
 * cachio lunch
<ackk> sergiusens, hi, any chance https://github.com/sergiusens/snapcraft-preload/pull/37 could be merged?
<mup> PR sergiusens/snapcraft-preload#37: add option to only redirect paths for /dev/shm/* <Created by albertodonato> <https://github.com/sergiusens/snapcraft-preload/pull/37>
<mup> PR snapcraft#2736 closed: cli: prompt for login if required <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2736>
<ondra> sergiusens how do I create app in snap calling "pkill" which I have access to from 'process-control' without actually shipping pkill in my snap?
<ondra> sergiusens I know I can do wrapper script, but I wonder is there is way to do it without wrapper script
<ondra> sergiusens I guess even is snapcraft allows it. snapd will probably refuse it?
<sergiusens> ondra snapd for some reason does not allow command entries that start with / even though it allows it in shebangs (or wrappers), so all your enquiries are for the snapd team
<ondra> sergiusens yep I realised so
<mup> PR snapd#7552 opened: tests: add new option "invert" to retry-tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7552>
<zyga> zxre
<zyga> re
<zyga> hey ondra
<zyga> how are you doing
<zyga> the nap worked, I feel so much better now
<Chipaca> zyga: go sing happy birthday
<zyga> Chipaca: we did that already
<zyga> I prefer to avoid granpas and grammas that had some event-booze
<zyga> kids are off upstairs already
<zyga> I'm here to ...
<zyga> merge this https://github.com/snapcore/snapd/pull/7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> whee :)
<zyga> now what's the state of https://github.com/snapcore/snapd/pulls/zyga
<mup> PR snapd#7421 closed: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> dire :)
<zyga> maybe I should go and have cake instead
<zyga> ;-)
<zyga> Chipaca: are you still working?
<Chipaca> no
<Chipaca> i retired
<mup> PR snapcraft#2738 closed: mypy: add coverage to tests <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2738>
<pokk> When trying to rsync to a newly created ubuntu core instance I get a "Permission denied" from mkdir. I'm guessing it's an apparmor thing. Is there any good reading on this?
<joedborg> hi all, i'm seeing an issue where my snap isn't building on the snapcraft.io servers, but builds fine locally (with the command given from the site)
<joedborg> HEAD is now at 2bd9643cee Add/Update CHANGELOG-1.16.md for v1.16.0-rc.2.
<joedborg> +++ [1003 19:50:48] Building go targets for linux/amd64:
<joedborg>     ./vendor/k8s.io/code-generator/cmd/deepcopy-gen
<joedborg> find: ârsyncâ: No such file or directory
<joedborg> find: ârsyncâ: No such file or directory
<joedborg> ./hack/run-in-gopath.sh: line 33: _output/bin/deepcopy-gen: Permission denied
<joedborg> make[1]: *** [gen_deepcopy] Error 1
<joedborg> Makefile.generated_files:152: recipe for target 'gen_deepcopy' failed
<joedborg> Makefile:559: recipe for target 'generated_files' failed
<joedborg> make: *** [generated_files] Error 2
<joedborg> Failed to run 'override-build': Exit code was 2.
<joedborg> ^ sorry, I meant to send that as a snippet
<sergiusens> ijohnson are you around? Maybe you can answer https://forum.snapcraft.io/t/permissions-problem-using-snapcraft-in-azure-pipelines/13258/5
<sergiusens> joedborg add rsync to build-packages
<sergiusens> if using multipass, this should be addressed soon.
<sergiusens> if using --use-lxd, it will take a bit longer
<joedborg> sergiusens: locally, it works fine with both multipass and lxd
<joedborg> it's only on the snapcraft io servers that it fails
<sergiusens> we are moving to the common denominator for building, and that is the same env used by the builders
<sergiusens> joedborg yeah, build servers are more minimal than minimal and we are going to be aligning with that
<joedborg> sergiusens: okay thanks, I'll try now with adding rsync to build-packages
<Chipaca> pokk: what are you rsync'ing?
<Chipaca> pokk: joedborg: are you looking at the same issue, or is it a coincidence?
<joedborg> Chipaca: mines to do with buildign only
<Chipaca> joedborg: ok :)
<Chipaca> strange coincidence then
<joedborg> looks like it :)
<Chipaca> pokk: 'trying to rsync a newly created ubuntu core instance' sounds like a fascinating exploration of a terribly bad idea, but do tell me more
<roadmr> Chipaca: he did say "trying to rsync *to* a newly created" :P
<Chipaca> roadmr: s/he/they/
<Chipaca> roadmr: and, curiouser and curiouser
<joedborg> working now thanks sergiusens !
<mup> PR snapd#7553 opened: cmd/snap: update 'snap find' help because it's no longer narrow <Created by chipaca> <https://github.com/snapcore/snapd/pull/7553>
<mup> PR snapd#7554 opened: recovery: update fde-utils calls <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7554>
<mup> PR core-build#54 opened: initramfs: update unlock keyfile parameter <Created by cmatsuoka> <https://github.com/snapcore/core-build/pull/54>
<mup> PR snapcraft#2734 closed: SnapcraftError refactoring <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2734>
#snappy 2019-10-04
<sarnold> is discord supposed to be doing this? https://pastebin.com/fcxZ3aQc
<mup> PR snapcraft#2739 opened: tests: fix mypy error with test_errors.py <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2739>
<mup> PR snapd#7555 opened: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<mborzecki> morning
<pstolowski> mornings
<marcustomlinson> pstolowski: hi :)
<mborzecki> pstolowski: marcustomlinson: hey guys
<marcustomlinson> mborzecki: hey
<mborzecki> we don't have any code that uses the new seedwriter pedronis is working on, or do we?
<pokk> Chipaca: sorry for afk:ing last night. No my problem have no relation with joedborg. I'm just trying to get a rsync backup from A to B where B is a ubuntu core raspberry pi
<pokk> Chipaca: is there a specific reason why you say it's a terribly bad idea?
<Chipaca> pokk: I thought you were trying to make an rsync copy of a core device
<pokk> oh no :)
<Chipaca> pokk: phew
<Chipaca> pokk: as long as the place you're rsync'ing *to* isn't readonly, that should work fine
<pokk> no, I'd agree that would be a rather bad idea.
<Chipaca> pokk: so, i guess, where are you rsync'ing to?
<pokk> I've not played around with Core befor but it seemed like a good fit. A low maintanance secure dist. Very little that would need to be tweaked
<pokk>  /media/data, a mounted usb disk
<Chipaca> pokk: ohhh, and you installed rsync from a snap?
<Chipaca> of coruse :)
<pokk> yes
<Chipaca> pokk: there's an extra manual step, indeed because of confinement
<pokk> there's a provided apparmor profile, /var/lib/snapd/apparmor/profiles/snap.rsync.rsync
<pokk> but I've not been able to figure out what it should look like. I'm new to apparmor
<Chipaca> actually, we might need to ask the rsync snap's author to tweak the snap
<Chipaca> pokk: nah, the snappy way would be to do 'snap connect rsync:removable-media'
<Chipaca> but
<Chipaca> that snap is missing the interface
<pokk> oh, I figured I should just have to add something like /media/data/* rw, to the profile. But no game
<Chipaca> well, that's what the connect boils down to (and a bit more but essentially that)
<Chipaca> but the snap needs to declare it as something ok to do
<pokk> oh, so it's not enought to add it to apparmor?
<Chipaca> pokk: if it can wait a bit, we'll get the snap author to tweak it
<pokk> I'm not really in any hurry
<Chipaca> pokk: easiest then to wait until cachio wakes up, he'll be here in ~3 hours, maybe 4
<pokk> I was thinking of having it run as a remote backup solution. But atm I'm just playing around with it
<Chipaca> ð
<pokk> lol, yeah if the waiting time for more discussions is 3 hours I'd barely call that waiting :D
<pokk> I'm used to days between messages at times. So far I'm really loving this distro tho
<pokk> it's like the perfect mix between coreos and ubuntu
<Chipaca> do let us know of any bumps
<Chipaca> wait, is cachio actually away today
<Chipaca> ah no, just mvo and ijohnson
<pokk> The setup process was definitly interesting. I'd have prefered a more cloud-config centered way of setting things up, but that's really just personal oppionons
<Chipaca> mwhudson: ^
<pokk> I've also found it some what hard to google thing, not sure of what to prefix the searches with. When searching "Ubuntu core" 90% of the hits are just ubuntu
<pokk> I've really not had time to read all the docs either so some googles could have probably been avoided
<Chipaca> pokk: yeah, we've not made that bit easy. Adding 'snappy' in there sometimes helps. Otherwise, forum.snapcraft.io can be easier to find stuff in than google, strangely
<Chipaca> pedronis: ð
<pedronis> mborzecki: hi, tried to answer some questions in your reviews. Seedwriter is a reorg of image.go, is not trying to add much new functionality.
<Chipaca> pedronis: https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/49?u=chipaca
<pokk> Chipaca: I take it you're a contributor in some way?
<Chipaca> pokk: yeah
<pedronis> Chipaca: sometimes? yes, now? unlikely
<Chipaca> pedronis: k
<pokk> cool :) it's always nice with friendly developers on irc
<Chipaca> pedronis: i'll try to remember to badger about this periodically then
<Chipaca> pokk: why thank you
<Chipaca> we can also get ornery sometimes
<pedronis> Chipaca: if I remember the issue was that we cannot trust NM
<zyga> Hey
<pedronis> anyway I have no bandwidth to think about this right now
<zyga> I have a complicated morning. I will make up for it in the evening but I cannot work yet
<Chipaca> pedronis: understandable
<Chipaca> zyga: how much birthday cake did you eat
 * Chipaca imagines zyga in a coma
<pokk> zyga: coffee always helps :)
<Chipaca> *food* coma
<Chipaca> zyga: take care, thank you for letting us know
<pokk> Chipaca:oh, one more thing. It's reallly minor but you didn't get to pick a timezone when installing. I'm sure it's been discussed and decided on not being included. But it's a think I tend to forget
<pokk> resulting in having the wrong time on the system for days/weeks/months...
<zyga> Chipaca: Lucy has a small bite :-)
<Chipaca> pokk: ah the fight between minimalist and quick setup, and all the options
<pokk> yepp
<Chipaca> mwhudson: do you know if there are plans for prompting for the timezone (or any other extra stuff) ?
<pokk> Why I sort of like a cloud-config file. I can decide on how minimalist I want it on my own
<pokk> as for most other things I tend to remember doing them once installed. But for some reason I forget about timezones
<mborzecki> pedronis:  https://github.com/snapcore/snapd/pull/7529 is the next one?
<mup> PR #7529: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/7529>
<pedronis> mborzecki: yes
<mborzecki> pedronis: i'll land #7469 or do you want to push anything more there?
<mup> PR #7469: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>
<pedronis> mborzecki: I'll land it
<mborzecki> pedronis: ok
<mup> PR snapd#7469 closed: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7469>
<pedronis> mborzecki: do you want me to rebase 7529 before looking at it?
<mborzecki> pedronis: yeah, can you merge master there?
<mborzecki> gh should really be smart enough do to it when generating diffs and there's no conflicts
<pedronis> mborzecki: done, it's smallish in itself
<mborzecki> pedronis: thanks
<pedronis> a bit of kitchen sink of various things though
<pedronis> Chipaca: +1 for #7445
<mup> PR #7445: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <https://github.com/snapcore/snapd/pull/7445>
<Chipaca> woop
<Chipaca> pstolowski: when you find a moment, could you take a look at ^ 7445? it's a bit big but not complicated
<pstolowski> Chipaca: yes
<mup> PR snapd#7553 closed: cmd/snap: update 'snap find' help because it's no longer narrow <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7553>
 * Chipaca is helping
<mborzecki> pstolowski: regarding https://github.com/snapcore/snapd/pull/7443#discussion_r330408988 how about `weekdayInMonth()`?
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pstolowski> mborzecki: perhaps weekday*s*InMonth() - it gives number of days right?
<mborzecki> pstolowski: yeah, sgtm
<pstolowski> weekdayInMoth sounds like it would return time.Time
<mborzecki> pstolowski: hehe, adding tests with time.Time{}
<mborzecki> actually according to go 0001-01-01 is monday :P
<pstolowski> mborzecki: is it a problem actually?
<mborzecki> pstolowski: no, but i'm adding the test to make sure that future changes don't break it
<pstolowski> mborzecki: sounds great
<mborzecki> pstolowski: equalWeekdaysInMonth or matchingWeekdaysInMonth
<mborzecki> how about this?
<pstolowski> mborzecki: is this wrt weekday*s*InMonth still?
<mborzecki> pstolowski: yeah, still on my mind
<pstolowski> mborzecki: I like matchingWeekdaysInMonth
<Chipaca> yeesh, family drama brewing
 * Chipaca goes for a coffee
<pokk> My blood is probably more coffee than anything atm :|
<mup> PR snapd#7529 closed: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7529>
<pedronis> pstolowski: mborzecki: in case #7451 is ready for review now
<mup> PR #7451: sandbox/cgroup: introduce cgroup wrappers package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7451>
<pstolowski> pedronis: ack
<mborzecki> pstolowski: i've updated #7443
<mborzecki> also it needs a 2nd review
<mup> PR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>
<pstolowski> mborzecki: thanks
<mup> PR snapcraft#2739 closed: tests: fix mypy error with test_errors.py <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2739>
<mborzecki> school run, back in a bit
<abeato> hm, it looks like we cannot have base core18 in classic?
<abeato> error: cannot assemble assertion model: cannot specify a base with a classic model
<abeato> pedronis, do you know that? ^^
<abeato> I get on snapd initialization:
<abeato> Oct 04 10:45:01 numancia snapd[1047]: stateengine.go:108: state ensure error: devicemgr: cannot use gadget snap because its base "core18" is different from model base ""
<pokk> Chipaca: so would one dare pinging cachio now?
<Chipaca> cachio: ð
<Chipaca> cachio: could you add home and removable-media to the rsync snap?
<cachio> Chipaca, sure
<pokk> I'd offer you a strawberry and banana small pancake as a thank you, but I'm guessing they'd not be so nice after an airplane trip
<cachio> Chipaca, you mean to the save/restore snapd state ritght?
<Chipaca> cachio: no, it's because pokk is wanting to rsync some things to /media/<something>/
<Chipaca> cachio: and the rsync snap doesn't have the right interfaces
<Chipaca> cachio: and you're the rsync snap publisher :)
<cachio> Chipaca, ah
<cachio> sure
<mborzecki> re
<cachio> pokk the snap is being built, I'll ping you in few minutes when it is published
<pokk> out of curiousity. Where's the code for something like rsync? Is it all on github? If so my foo seems to be missing it
<pokk> cachio: wow, that's some quick working!
<cachio> pokk, it was a small change
<mborzecki> cachio: Refreshing store authorization failed for test-snapd-rsync hmm
<cachio> mborzecki, didn't update the test-snapd-rsync :)
<cachio> it is the same
<mborzecki> cachio: ah, i read some of the backlog, but not all :P
<cachio> just updates the rsync
<cachio> and it is not published yet
<cachio> mborzecki, but if you have a log please share it so I can take a look
<mborzecki> cachio: got this by email just few minutes ago
<mborzecki> cachio: https://launchpad.net/~snappy-dev/+snap/test-snapd-rsync/+build/693784 store upload failed
<mborzecki> btw. does anyone click the retry button when it happens?
<cachio> mborzecki, you are right
<cachio> rsync project created the test-snapd-rsync snap
<Chipaca> cachio: mborzecki: I too am being spammed with these test-snapd-rsync emails
<Chipaca> no idea what they're about :-)
<cachio> but is was correctly built
<Chipaca> cachio: the email says: Depending on the error message above, this may indicate a bug.  If so, you
<Chipaca> may be able to work around it by reauthorizing Launchpad to upload the
<Chipaca> package in question:
<Chipaca> cachio:
<Chipaca>   https://launchpad.net/~snappy-dev/+snap/test-snapd-rsync/+authorize
<Chipaca> Â¯\_(ã)_/Â¯
<Chipaca> cachio: but I don't know how this is connected to the 'rsync' snap :)
<mborzecki> Chipaca: test-snapd->>>>>rsync<<<<< xD
<mborzecki> only connection i see tbh
<Chipaca> cachio: ACKshully, it might be that you created both (they're both in your name), and it looks like the only difference is the snap name itself :-)
<Chipaca> cachio: so maybe you just changed the name: entry in the yaml :)
<cachio> mborzecki, Chipaca I think the problem is that the owner for the snap package in launchpad is dnappy-developers and in the stop I am
<mborzecki> pedronis: can you take a look https://github.com/snapcore/snapd/pull/7543 later on?
<mup> PR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>
<Chipaca> cachio: wo'a mess
<cachio> Chipaca, moving all the test snaps to snappy-dev
<Chipaca> cachio: and the plain 'rsync' snap?
<cachio> Chipaca, too
<cachio> Chipaca, does it make sense for you?
<Chipaca> cachio: yeah, probably (either that or straight up Canonical for the rsync one)
<pokk> seems like I caused some added trouble here :| sorry about that
<Chipaca> pokk: it obviously needed sorting
<Chipaca> that snap hadn't been rebuilt in over a year â it almost certainly needed rebuilding at least to pick up new libs
<pokk> sure, but also unplaned workd
<cachio> pokk, hey, could you try the test-snapd-rsync snap
<cachio> pokk, this is the same than the rsync once
<cachio> pokk, if it works well then I'll see how to release the rsync once
<cachio> one
<pokk> just `snap install test-snapd-rsync` then?
<cachio> then you need to connect the interface
<cachio> pokk, you also can do snap alias test-snapd-rsync.rsync rsync
<pokk> right
<cachio> so then you will be able to do rsync and it will call the test-snapd-rsync snap
<cachio> pokk, did it connect=
<cachio> ?
<cachio> pokk, sudo snap connect test-snapd-rsync:removable-media
<cachio> this should be enough
<cachio> then you should be able to use it
<pokk> it seeems to work
<pokk> I'm running it on an raspberry pie 3 so it's sloooow
<cachio> pokk, is it ok for you to use it until we decide what to do with the rsync one?
<cachio> today/monday
<pokk> cachio: oh for sure. Atm I'm really just trying core out. Trying to get a feel for it. I'd probably reinstall next week anyway and restart from scratch
<cachio> pokk, nice, I'll discuss about this today
<cachio> thanks
<pokk> it's not like I'm paying you for the development atm :) So I can't demand things to be solved in hours. Monday would be weeks/months faster than some problems one encounters at times
<pokk> aaaaand, sometimes you'll not get things fixed even when paying looots of money :|
<Chipaca> ooh, I could go with that plan
<Chipaca> (a) get paid looots of money, (b) do nothing
<Chipaca> (c) and (d) are not needed because see (a)
<pokk> well I mean, we're getting the service. But not getting things outside of the very small box
 * pokk isn't at all grumpy
<pokk> oh, and just to be clear. I'm not talking about Ubuntu at all here
<pokk> and now my rsync backup works :) Thanks a lot!
<Chipaca> pokk: with my canonical-employee hat on, if you ever find yourself in that kind of place with canonical, please do reach out
<Chipaca> everybody can mess up and get stuck in that kind of place with a contract, but all it should take is a conversation to dislodge things
<pokk> Chipaca: I'm talking about some of the bigger cloud providers :) At times they can be super helpful, at times they'll just refuse to help at all. No matter how many zeroes there's in the bill you're paying each month
<mup> PR snapd#7556 opened: image,seed/seedwriter: switch image to use seedwriter.Writer <Created by pedronis> <https://github.com/snapcore/snapd/pull/7556>
<Chipaca> pedronis: stdup?
<zyga> I cannot join
<zyga> Still looking after Lucy
<zyga> No work done today
 * Chipaca hugs zyga 
<Chipaca> zyga: that's ok
<Chipaca> zyga: you know what happens when you don't come to the standup
 * Chipaca assigns everything to zyga
<cachio> mborzecki, https://travis-ci.org/snapcore/snapd/jobs/593470475#L9354
<cachio> now happening in i386
<mborzecki> cachio: looks like the job took too long, nothing seems to have explicitly failed
<cachio> mborzecki, I thing it got stuck as it used to happend in arch
<cachio> mborzecki, then the build fails because of this test
<mborzecki> cachio: hmm that's possible, we know there's a race, but unless someone picks up the work on the kernel or strace side it's not going to get fixed :(
<cachio> mborzecki, makes sense, if I see this again in i386 I'll apply the same solution than arch
<Chipaca> popey: are you a round?
<roadmr> round like ðµ  ?
<mup> PR snapcraft#2740 opened: crystal plugin: add flags to use during shards build <Created by mamantoha> <https://github.com/snapcore/snapcraft/pull/2740>
<cachio> zyga, there?
<joeubuntu> Snappers (is that a thing? it should be...) I have a snap that uses python's plotly module to create an html page which it opens using the default browser. In my snap when that is called it just hangs. What do I need to do in my yaml to make it work? Thanks for the help!
<Chipaca> joeubuntu: https://www.urbandictionary.com/define.php?term=snapper er.
 * cachio lunch
<Chipaca> joeubuntu: add the 'desktop' interface, so you can run xdg-open
<joeubuntu> thanks Chipaca , let me try that!
<joeubuntu> Woot! It worked if I installed the package snapd-xdg-open on the host, is there a way to make the snap require that somehow on install or in the yaml ?
<Chipaca> joeubuntu: what is the description of snapd-xdg-open?
<joeubuntu> Chipaca  This is a transitional dummy package. It can safely be removed.
<Chipaca> joeubuntu: thank you.
<Chipaca> joeubuntu: you can remove that package, it has nothing in it.
<joeubuntu> The browser will not launch without it though.
<Chipaca> joeubuntu: try a second time
<Chipaca> there's a bug with the auto-launching of the service
<Chipaca> where the first time it auto-laucnhes but doesn't open the thing
<Chipaca> it's fixed in â¦ master at least
<Chipaca> dunno where it is in the release queue
<joeubuntu> That is incredibly confusing. It throws the error:" user-open error: Object does not implement the interface ." Which googling leads to snapcraft forum posts about the snapd-xdg-open package needing  to be installed
<joeubuntu> But you are right, running it a second time fixes that.
<Chipaca> joeubuntu: yeah! it's a stupid bug
<Chipaca> joeubuntu: we put the service on the bus before attaching the interfaces to it
<Chipaca> joeubuntu: because we are super smart (tm)
<Chipaca> anyway it's fixed, but annoying until that's sorted
<Chipaca> joeubuntu: the fascinating thing is how long it took for that one to be noticed
<Chipaca> people just double-clicked, i guess?
<joeubuntu> Chipaca I just click harder if it doesn't work ... that helps, right?
<joeubuntu> Thanks for the help!
<Chipaca> joeubuntu: totally. That error message _means_ "click harder next time!"
<joeubuntu> ð
 * diddledan clicks. quite hard.
 * Chipaca buys shares in sellers of replacement clicky things
<diddledan> I got a new clicky today!
<diddledan> it's not got a wire!
<diddledan> this is voodoo...
<Chipaca> diddledan: who do?
<diddledan> you do!
<Chipaca> https://www.youtube.com/watch?v=UunvsU66B4Y
 * cwayne is disappointed that YouTube links not for labyrinth
<Chipaca> it'd have to be a qr code
<mup> PR snapcraft#2697 closed: Neon extension <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2697>
<pokk> so far it seems like a raspberry pi 3b+ with ubuntu core on it is a really great setup. The poor thing have been on heavy load for a few hours but it seems to work great
<ackk> hi, is there a way to autoconnect interfaces for a snap with "snap try" or when installing with --dangerous?
<mup> PR snapd#7445 closed: overlord/snapstate/policy, etc: introduce policy, move canRemove to it <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7445>
 * cachio afk
<mup> PR snapcraft#2741 opened: extensions: support using gjs from gnome runtime <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2741>
<mup> PR snapcraft#2742 opened: cli: use click utilities for login prompts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2742>
#snappy 2019-10-05
<mup> Bug #1846894 opened: Cannot use PulseAudio in classic confinement <Snappy:New> <https://launchpad.net/bugs/1846894>
