[01:18] <ahoneybun> mm if if get the tar.bz2 file what plugin do i need to use?
[01:18] <ahoneybun> audacious 3.8
[02:42] <mup> Bug #1628357 opened: A deamon fails with: No home directory found <Snappy:New> <https://launchpad.net/bugs/1628357>
[06:26] <mup> PR snapd#2017 opened: Download deltas (but do nothing with them yet) when env var is set <Created by absoludity> <https://github.com/snapcore/snapd/pull/2017>
[06:33] <dholbach> good morning
[06:38] <dholbach> mhall119, nice work on the content snap blog!
[07:04] <didrocks> zyga_: hey! do you know the rationale for the "grade" keyword which is mandatory now? (There has been no announcement on it if I didn't miss anything?)
[07:04] <didrocks> dholbach: maybe you know? ^
[07:07] <didrocks> ok, found a cryptic explanation on some design doc
[07:10] <dholbach> didrocks, no, I don't
[07:13] <didrocks> dholbach: I just added some changes to take into account the grade channel, also, going to change few things for --dangerous install with latest version
[07:28] <dholbach> didrocks, to the codelabs or where?
[07:33] <didrocks> dholbach: codelabs
[07:33] <didrocks> (done)
[07:34] <dholbach> didrocks, awesome - thanks
[07:35] <didrocks> yw!
[07:36] <mup> PR snapd#2016 closed: many: rename apply-config hook to configure <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2016>
[07:49] <popey> ogra_: is the process of porting to new devices well documented? Is it as hard as porting to new phones? I have a banana pi I'd like to see ported to...
[07:59] <popey> huh, turns out they've looked at this before. http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432
[08:02] <dholbach> didrocks, can we try the collaboration feature for snap-codelabs?
[08:02] <dholbach> I haven't seen in action yet and it might make sense in this case.
[08:18] <didrocks> dholbach: hum, what do you mean by collaboration feature?
[08:18] <didrocks> dholbach: I'm trying to fix the "resume" not working FYI ;)
[08:19] <dholbach> didrocks, IIRC there's a few feature where you hit the "collaboration" link for a snap in myapps and can enter an email for somebody with whom you want to maintain the package together
[08:21] <didrocks> dholbach: oh, that, maintaining together
[08:21] <didrocks> yeah
[08:21] <didrocks> let me see if I have a link for this
[08:22] <didrocks> dholbach: sent
[08:23] <dholbach> hah, fun - the message was in French
[08:23] <dholbach> great, that was painless
[08:28] <didrocks> ;)
[08:31] <popey> haha, got that too
[08:32] <popey> thought it was spam, being french ;)
[08:33] <popey> "You have successfully been granted administrative access to snap-codelabs.didrocks." - MUhahahahah
[08:39] <mup> PR snapd#2018 opened: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2018>
[08:51] <mup> PR snapd#2012 closed: interfaces/builtin: add missing rule to allow run-parts to execute all resolvconf scripts <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2012>
[09:00] <ogra_> popey, porting is a lot easier ... but you need to build kernel, uboot and a gadget snap
[09:00] <popey> ogra_: is it documented?
[09:00] <ogra_> not really ... thats kind of on my TODO
[09:01] <ogra_> (at least a blog post is ... )
[09:02] <popey> ok
[09:07] <mup> PR snapd#2007 closed: interfaces: ppp: load needed kernel module <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2007>
[09:14] <ogra_> popey, oh, and it gets a lot eaier if your board is already supported by our linux-generic armhf kernel (there is a bunch o borads that are supported by default in that one
[09:14] <ogra_> )
[09:16] <ogra_> https://launchpadlibrarian.net/287031519/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
[09:16] <ogra_> Staging livebuild
[09:16] <ogra_> Priming livebuild
[09:16] <ogra_> 'utf-8' codec can't encode character '\udcc4' in position 93: surrogates not allowed
[09:16] <ogra_> Traceback (most recent call last):
[09:16] <ogra_>   File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 191, in main
[09:16] <ogra_>     builder.build()
[09:16] <ogra_> cjwatson, ^^^ i that buildnaps or snapcrafts fault ?
[09:16] <ogra_> *is that
[09:17] <mup> PR snapd#2008 closed: overlord/state: prune old empty changes <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2008>
[09:18] <ogra_> (havent seen that one before ... and i guesss it might just succeed if i re-try)
[09:19] <ogra_> (since all others have succeeded)
[09:34] <mup> PR snapd#2019 opened: store: retry download on 500 <Created by chipaca> <https://github.com/snapcore/snapd/pull/2019>
[09:46] <mup> PR snapd#2020 opened: prevent timeout while waiting for log on systemctl status <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2020>
[09:48] <cjwatson> ogra_: must be snapcraft, I think
[09:48] <cjwatson> ogra_: if you look closely at the buildsnap traceback it's just reporting the non-zero exit status
[10:14] <mup> PR snapd#2021 opened: releasing package snapd version 2.16 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2021>
[10:23] <ogra_> well, let me just try a re-build ... i dont really see any obvious other errors and yesterdays build has worked ...
[10:25] <mup> PR snapd#2020 closed: tests: prevent timeout while waiting for log on systemctl status <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2020>
[10:41]  * ogra_ files bug 1628457
[10:41] <mup> Bug #1628457: snapcraft fails on s390x with utf8 error <Snapcraft:New> <https://launchpad.net/bugs/1628457>
[11:05] <mup> PR snapd#2021 closed: debian: releasing package snapd version 2.16 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2021>
[12:31] <mup> PR snapd#2022 opened: Add links to IRC, mailing list and social media <Created by dholbach> <https://github.com/snapcore/snapd/pull/2022>
[12:33] <mup> PR snapcraft#833 opened: Add links to IRC, mailing list and social media <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/833>
[12:35] <zyga_> didrocks: I don't know about grade, sorry
[12:36] <zyga> jdstrand, tyhicks: mixed news about /media sharing, still no luck, I'm debugging and investigating
[12:36] <zyga> this is somewhat frustarating as it is extremely easy to break the system
[12:36] <jdstrand> :\
[12:37] <zyga> my current quest is to figure out where pivot_root is giving up with EINVAL, I'm just patching the kernel
[12:38] <jdstrand> zyga: you are on xenial?
[12:38] <zyga> but I also seem to be missing some other things that are required to make this work, most importantly, it seems that mount points happily leak outside
[12:38] <zyga> yes, I'm doing all of this on xenial
[12:38] <jdstrand> zyga: but no kernel trace?
[12:38] <zyga> jdstrand: ?
[12:39] <jdstrand> zyga: you're kernel isn't oopsing or anything?
[12:39] <zyga> jdstrand: ah, no, nothing like that happens
[12:40] <zyga> jdstrand: I think that the crashes earlier can be trivially caused by what looks like recursive mount that sees itself and just continues
[12:40] <zyga> jdstrand: but I also had less adventourous examples where after the test program has finished I had something I couldn't unmount
[12:40] <zyga> jdstrand: or unmount -l would really detach /
[12:40] <jdstrand> zyga: ok, I ask just to be sure-- in another channel there was an issue with pivot_root causing an oops if running snapd in an lxd container, and the timing of your comment was just odd. nm me
[12:41] <zyga> jdstrand: oh, interesting
[12:41] <zyga> jdstrand: I bet there is some new ground we are breaking here
[12:42] <jdstrand> oh totally
[12:42] <jdstrand> all kinds of new ground :)
[12:43] <zyga> moving to a VM is actually better as native is slow/costly to recover
[12:43] <jdstrand> indeed :)
[12:44] <zyga> jdstrand: from what I see so far I think we need MS_UNBINDABLE at a strategic spot or everything blows up
[12:44] <zyga> jdstrand: but I don't have a working demo that goes all the way to pivot_root and behaves
[12:44] <zyga> jdstrand: well, investigating :)
[12:46] <zyga> oh, curious
[12:46] <zyga> jdstrand: pivot_root documentation really sucks, kernel sources are better
[12:46] <jdstrand> kyrofa: hey, do you have an agreed to list of keys that are allowed in the hooks yaml?
[12:47] <jdstrand> kyrofa: eg:
[12:47] <jdstrand> hooks:
[12:47] <jdstrand>   <???>:
[12:47] <jdstrand>     plugs: ...
[12:47] <jdstrand> kyrofa: and aiui, 'plugs' is the only thing that can be in there, but this is valid:
[12:47] <jdstrand> hooks:
[12:47] <jdstrand>   <???>: null
[12:48] <jdstrand> kyrofa: also, if the hook key names are defined, do they map to files in meta?
[12:48] <jdstrand> kyrofa: perhaps a better question is: is there up to date documentation on how hooks are supposed to work? :)
[12:51] <ogra_> you just attach them to the eyelet on your computer :P
[12:57] <sergiusens> ogra_ I am not sure how to fix your problem or debug it and I bet adding --debug is not going to be easy
[12:57] <sergiusens> ogra_ can you use a hacked up snapcraft to run through the build?
[12:57] <ogra_> sergiusens, yeah, i was waiting for you to show up here ... i guess we might need some cjwatson help
[12:58] <sergiusens> ogra_ well, I recall you forked snapcraft once
[12:58] <ogra_> i could do that i guess, yeah
[12:58] <sergiusens> so we don't need him
[12:58] <ogra_> well, i guess a debug toggle might be helpful in general ... cant be that hard to add code for this to the lp builder
[12:59] <ogra_> but yeah, as a quick hack, tell me what changes you need and i'll push a debug snapcraft to the PPA temporary
[13:00] <cjwatson> ogra_: the problem with that is that we have nowhere to set it in LP
[13:00] <cjwatson> so it would not be a trivial stack of changes
[13:00] <ogra_> ah, because it would need UI ...
[13:00] <ogra_> yeah
[13:00] <cjwatson> and a database change, and a model change, and passing it over the channel to the buildd
[13:01] <cjwatson> so, you know, I can spend two days on all that or you can push a debug package to the PPA :)
[13:01] <sergiusens> cjwatson ogra_ in all fairness I need to finish up the rework of using project owned exceptions for everything we know about and let the built-ins fly away to stdout/stderr
[13:01] <ogra_> heh, ok, my imagination didnt go far enough here :)
[13:02] <sergiusens> ogra_ http://paste.ubuntu.com/23246720/
[13:02] <ogra_> ah, thats definitely easier than what colin described above :)
[13:02] <dz0ny> not sure what rules you have for snapcraft or snapd but this could be nice publicity https://hacktoberfest.digitalocean.com/
[13:04] <cjwatson> also perhaps a sensible alternative would be to allow a project to put debug: true in snapcraft.yaml?
[13:04] <cjwatson> of course wouldn't be active from the very start
[13:05] <sergiusens> cjwatson yeah, that is the debian/rules path; I was trying to keep those two things separate, but I guess it will be inevitable
[13:07] <kgunn> kyrofa you about ?
[13:07] <Elleo> has anyone run gdb on a snap inside unity8? I've managed it in unity7, but in unity8 I just get a permission denied error even when run as root
[13:08] <sergiusens> ogra_ this is the branch that broke you https://github.com/snapcore/snapcraft/pull/796/files
[13:08] <mup> PR snapcraft#796: Only discover dependencies once per file <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/796>
[13:08] <sergiusens> ogra_ I failed to notice this got removed `fs_encoding = sys.getfilesystemencoding()`
[13:08] <ogra_> geez, how can i make github not show me that "we've made soe changes" thing ... so annoying
[13:09] <sergiusens> ogra_ accept the changes, let them flow and they will go :-P
[13:09] <ogra_> i think i did that a few times now
[13:09]  * ogra_ tries again
[13:10] <oparoz> The discussion about /media earlier was to allow snaps access to /media? That would be great :)
[13:11] <ogra_> sergiusens, well, it is funny that it only affects s390x ...
[13:15] <sergiusens> ogra_ well, funny as it may be, I bet that is the issue and your ppa run will luckily prove it
[13:17] <mup> PR snapd#1832 closed: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 <Reviewed> <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1832>
[13:19] <zyga> joc: hey, do you have a second?
[13:20] <joc> zyga: sure
[13:20] <zyga> joc: I need to verify something for GPIO interface
[13:21] <zyga> joc: if you have hardware with GPIOs around (could be any device really, including pi) I can give you an udev rule that will export one of them to userspace
[13:22] <joc> zyga: yep i have hardware can try it on
[13:23] <zyga> joc: can you give me a pastebin of: udevadm info --export-db | grep -i gpio
[13:23] <joc> one sec, booting it
[13:23] <zyga> joc: what we want in a file, e.g. /etc/udev/rules.d/foo.rules
[13:24] <ogra_> sergiusens, grrr ... snapcraft build fails in the tests
[13:24] <zyga> joc: and then a correctly done RUN line :)
[13:24] <kgunn> Elleo: i just saw your statement, interesting...
[13:24] <zyga> joc: but I need the details from your device first
[13:24] <kgunn> tedg: ^^^
[13:24] <ogra_> is there some var i could set to disable them altogether ? (thats not the first time i have to hack them up)
[13:25] <sergiusens> ogra_ oh right, disable them as we test the error outputs and that applied diff would set it off
[13:25] <sergiusens> ogra_ tests, no, just debian/rules overrides
[13:25] <Elleo> kgunn: not currently certain if the permission denied is coming from gdb itself or snap, either way it happens very early on in loading things
[13:26] <kgunn> Elleo: is the snap --devmode?
[13:26] <Elleo> kgunn: yeah
[13:26] <kgunn> Elleo: i would suspect the general confinement of u8 itself
[13:26] <kgunn> e.g. click
[13:27] <joc> zyga: http://paste.ubuntu.com/23246802/
[13:27] <Elleo> kgunn: interestingly I can run "snap list" in gdb, but not "snap run ubuntu-keyboard"
[13:27] <kgunn> Elleo: are you on yakkety or xenial?
[13:27] <Elleo> kgunn: xenial
[13:27] <Elleo> kgunn: but with the overlay
[13:27] <kgunn> sure
[13:27] <joc> zyga: gpio 346 would be a nice one to test
[13:29] <kgunn> Elleo: wonder if you need to break confinement on snappy...this is weird, but install classic on core on classic :-P
[13:29] <kyrofa> kgunn, I am now
[13:29] <kgunn> Elleo: https://github.com/snapcore/classic-snap
[13:30] <Elleo> kgunn: I'm currently running unity8 via the unity8-desktop-session rather than the unity8 snap, wouldn't that avoid that confinement?
[13:30] <kyrofa> kgunn, sorry, standup is at 0600, I wake up at 0550, and space IRC until about 0630 or so :P
[13:30] <kgunn> kyrofa hey, so i wanna build a qt demo, and i have the git source link....but the actual qt .pro file is kinda buried
[13:30] <kgunn> kyrofa https://github.com/qt/qtdeclarative/tree/dev/examples/quick/demos/photoviewer
[13:30] <kyrofa> Hmm
[13:30] <kgunn> kyrofa so wondering is there a way to point there ?
[13:31] <tedg> kgunn: I'm confused at what you're pointing me at.
[13:31] <kgunn> tedg: <Elleo> has anyone run gdb on a snap inside unity8? I've managed it in unity7, but in unity8 I just get a permission denied error even when run as root
[13:32] <kyrofa> kgunn, did you try using the `project-files` option in the qmake plugin?
[13:32] <kyrofa> jdstrand, yes indeed
[13:32] <kgunn> kyrofa ....bah! thank you
[13:32] <kgunn> kyrofa next time just reply rtfm :)
[13:33] <kyrofa> kgunn, hahaha, not my style ;)
[13:33] <ogra_> yeah, thats so un-ubuntu
[13:33] <Elleo> kgunn: same result when running inside classic
[13:34] <kyrofa> jdstrand, you have a good grasp of this, but this might reaffirm: https://github.com/snapcore/snapd/blob/master/docs/hooks.md
[13:34] <zyga> joc: thanks, let me finish a meeting and I'll be back to this
[13:34] <cjwatson> sergiusens: could you retry tests on https://github.com/snapcore/snapcraft/pull/831 ?  they should pass now (or at least get further)
[13:34] <mup> PR snapcraft#831: 'sign-build' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/831>
[13:34] <joc> k
[13:35] <kyrofa> jdstrand, the hooks that are supported are maintained in the snapd code though, and the list will change. Are you adding them to the review tools?
[13:37] <jdstrand> kyrofa: right now I have some basic tests for hooks in the review tools that I added yesterday. I did read that file. I was wondering if there was a list-- that doc says none are currently supported
[13:37] <jdstrand> I can wait on added valid ones-- that isn't a big deal
[13:37] <Elleo> kgunn: get the same thing if I try running strace on it, happens when running the ubuntu-core-launcher: http://pastebin.ubuntu.com/23246832/
[13:37] <jdstrand> also, this output is less than helpful:
[13:37] <kyrofa> jdstrand, there's a list of one as of now, but the PR that adds it to the doc hasn't landed yet
[13:37] <jdstrand> $ snapctl
[13:37] <jdstrand> error: snapctl requires SNAP_CONTEXT environment variable
[13:37] <kyrofa> jdstrand, it's called `configure`
[13:37] <jdstrand> and snapctl -h
[13:37] <kyrofa> jdstrand, yeah, snapctl is typically used within hooks
[13:38]  * jdstrand notes that he was told to use 'snapctl -h' by the aforementioned doc :)
[13:38] <kyrofa> jdstrand, oh right-- snapctl -h will work in the next release
[13:38] <jdstrand> kyrofa: ok, thanks. this is helpful
[13:38] <kyrofa> Side effect of only maintaining docs in master, heh, sorry
[13:39] <kyrofa> jdstrand, but yeah, that doc should be updated as hooks are added
[13:40] <Elleo> kgunn: aha
[13:40]  * kgunn waits anxiously
[13:40] <Elleo> kgunn: all snaps are failing to run in unity8's terminal for me
[13:41] <Elleo> kgunn: including simple things like hello-world, strace shows it trying to do some network stuff and then getting an EACCESS error
[13:41] <jdstrand> Elleo, kgunn: curious if you are using the newest snapd in yakkety-proposed and the snap-confine in yakkety
[13:41] <Elleo> jdstrand: I'm running xenial + stable-overlay
[13:42] <jdstrand> I see, nm then
[13:43] <zyga> joc: ok, back
[13:43] <Elleo> kgunn: ah, and now after running hello-world successfully by sshing in, I get the permission denied error when attempting to start it
[13:43] <zyga> joc: so that device three distinc GPIO chips, right?
[13:43] <zyga> joc: what do you see in /sys/class/gpio?
[13:44] <joc> zyga: yes three chips
[13:45] <Elleo> kgunn: ah, seems to actually be /run/snapd.socket it gets the error on: http://pastebin.ubuntu.com/23246852/
[13:46] <kgunn> otp but will read up in a bit
[13:47] <kyrofa> Hey ogra_, got a sec?
[13:49] <ogra_> kyrofa, i guess i do
[13:50] <kyrofa> ogra_, saw a question on askubuntu that made me think of you: https://askubuntu.com/questions/829118/ubuntu-core-power-failure-resistance
[13:51] <kyrofa> ogra_, I suspect the overall answer to the question is no, is that correct?
[13:52] <ogra_> kyrofa, we redice the writes as much as we can and since we use ext4 the recovery should also work fins after a power failure
[13:52] <ogra_> *fine
[13:52] <ogra_> i often enough just unplug the power when testing
[13:52] <ogra_> with no ill effects
[13:53] <ogra_> *reduce the writes
[13:53] <kyrofa> ogra_, makes sense. But in terms of the design, things are split like that for security more for increasing the lifetime, since the writable partition is still on disk. Right?
[13:53] <kyrofa> The read-only bits are snaps which are still written to disk as well
[13:53] <ogra_> i guess wearing out the SD really depends on the snaps you use and if they do a lot of wild write operations
[13:54] <ogra_> the OS itself is very unlikely to ever wear out an SD
[13:54] <ogra_> kyrofa, yes, the RO bits are written to disk on "snap refresh" ...
[13:54] <kyrofa> ogra_, I dunno, I go through an SD card a year on my plug computer. I figured it was due to logging
[13:55] <Elleo> kgunn: not sure if it's relevant, but when I did the initial "snap login" it forced me to do it as root, I don't know if that's resulted in something having odd permissions (although snap stuff works fine under unity7 still)
[13:55] <Elleo> kgunn: well, via sudo
[13:56] <ogra_> kyrofa, yeah, that can indeed be ... but we dont have swap, /tmp is a tmpfs in ram and writes on OS level only happen for the few writable bind mounts we actually have ...
[13:56] <ogra_> kyrofa, the thing that will really wear it out is a snap that does a lot of writing
[13:57] <ogra_> but not the OS
[13:57] <ogra_> logging on its own is usually very quiet unless you start running snaps with --devmode ... then it gets super agressive
[13:57] <ogra_> (which i'd really like to get rid of)
[13:58] <kyrofa> ogra_, alright, thanks for the explanation! I think I have enough to answer that question now unless you want to tackle it
[13:58] <ogra_> all these apparmor ALLOWED lines wil eat your SD in no time if you run a devmode snap for a while
[13:58] <ogra_> no, go ahead :)
[14:08] <sergiusens> ogra_ did it finish yet?
[14:08] <ogra_> sergiusens, ages ago ... but the publisher is a bitch lately
[14:08] <ogra_> still waiting ...
[14:08] <sergiusens> ogra_ lol; ssh and grab the logs :-)
[14:09] <ogra_> (disabling the tests makes the build **really* fast :) )
[14:09] <ogra_> sergiusens, no, i'm still waiting for the snapcraft package to be published in the PPA
[14:09] <ogra_> no logs to grab yet :)
[14:10] <sergiusens> ogra_ oh, I thought you built the snap already!
[14:10] <sergiusens> darn this is slow
[14:10] <ogra_> yeah
[14:10] <ogra_> the publisher is a pain atm
[14:22] <ogra_> sergiusens, snap build started ...
[14:26] <sergiusens> ogra_ \o/
[14:31] <kyrofa> ogra_, does http://askubuntu.com/a/830774/261753 look reasonable?
[14:33] <ogra_> kyrofa, looks fine to me
[14:34] <kyrofa> ogra_, alright, thanks for the help!
[14:34] <ogra_> sergiusens, https://launchpadlibrarian.net/287088900/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
[14:36] <zyga> joc: can you tell me what you see in /sys/class/gpio please
[14:37] <joc> zyga: yes, what you said - three gpio chips as indicated by udev and export/unexport
[14:37] <joc> zyga: no gpios have been exported yet
[14:39] <mvo> dbarth: does #65 for snapweb the "WI" mean "work-in-progress" ? or work-item? or something else :) ?
[14:40] <ogra_> west india problem
[14:40] <zyga> joc: ok, great,
[14:40] <mup> PR snapd#2023 opened: cmd/snap,configstate: rename apply-config variables to configure <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2023>
[14:42] <mup> Bug #1628559 opened: Can't install more than 1 package in one command <Snappy:New> <https://launchpad.net/bugs/1628559>
[14:42] <dbarth> mvo: WIP indeed; lenses playing tricks with my eyes...
[14:43] <ogra_> use scopes then
[14:43] <ogra_> :P
[14:43] <dbarth> mvo: i'll rebase and push shortly
[14:43] <mvo> dbarth: cool, thanks
[14:44] <dbarth> ogra_: :)
[14:45] <zyga> joc: if you 'echo 123 > /sys/class/gpio/export' does it just do what is expected?
[14:46] <zyga> joc: where 123 is any number in the expected range
[14:46] <joc> zyga: yep
[14:47] <zyga> joc: thanks
[14:47]  * zyga wonders what the udev rule trigger should be
[15:17] <mup> PR snapd#2024 opened: docs: add `configure` hook to hooks list <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2024>
[15:18] <shuduo> ogra_: hi in recent pi3 beta image, there is no camera slot in "snap interfaces" output. is it expected?
[15:20] <ogra_> shuduo, hmm, i wouldnt know who is supposed to actually provide it
[15:20] <zyga> stgraber: hey, do you have a moment
[15:21] <ogra_> shuduo, ounds liek you sshoudl file a bug as a starting point
[15:22] <shuduo> ogra_: sure if it's a tracked issue i would file a bug
[15:27] <ogra_> sergiusens, have you seen the log above ?
[15:28] <ogra_> https://launchpadlibrarian.net/287088900/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz ... not really a lot more info i must say ...
[15:28] <sergiusens> ogra_ yes, I wish I printed(filename) but at least I know where to look now
[15:28] <ogra_> yeah
[15:29] <ogra_> iirc we are using C.UTF-8 ... i wonder if thats any different on s390x than on the other arches
[15:30] <sergiusens> ogra_ all the same
[15:30] <sergiusens> ogra_ can I give you a quick other patch?
[15:30] <ogra_> sure
[15:32] <ogra_> sergiusens, btw https://bugs.launchpad.net/hplip/+bug/1498366
[15:32] <ogra_> s.encode("utf-8", errors="surrogateescape")
[15:32] <ogra_> seeems to be a valid workaround
[15:33] <sergiusens> ogra_ right, we don't encode anything now from the new source of information; I want to try without surrogateescape, but I guess we can go full steam ahead
[15:42] <sergiusens> ogra_ http://paste.ubuntu.com/23247199/
[15:49] <shuduo> ogra_: if a device like pi3 neither connected to PC with USB debug cable nor connect to HDMI monitor, it will not boot up. is it expected? since i see my pi3 boot well with debug cable. but if I unplug debug cable, i can't see its ethernet get IP via nmap command.
[15:56] <zyga> hmm
[15:57] <ogra_> shuduo, no, thats not expected, if th device is properly set up via console-conf it should boot (and does here)
[15:58] <shuduo> ogra_: sadly it is almost 100% reproducable at my side
[15:58] <ogra_> weird
[16:07] <shuduo> ogra_: sorry false alert. i tried few more times, i'm sure it works well. i guess i run nmap too fast after it shows connection estiblished
[16:08] <ogra_> heh, yeah, arm devices demand some level of patience ;)
[16:09] <ogra_> sergiusens, so the package has just finished building ... lets see if the publisher manages to publish in under 60min :P
[16:13] <ogra_> zyga, niemeyer see shuduo's question above regarding the camera interface on images ... on actual images, who woud provide that slot and how would we define it ? i.e. if there is camera hardware, woud we/i have to define that interface in gadget.yaml ? would it magically show up once i plug in a USB camera etc
[16:15] <oparoz> Are there plans to let Snaps mount external storage (NFS, CIFS)?
[16:16] <mup> Bug #1628592 opened: no camera slot in pi2 or pi3 image <Snappy:New> <https://launchpad.net/bugs/1628592>
[16:16] <ogra_> i think there was some kind of interface planned for this
[16:16] <oparoz> That's missing for enterprise snaps
[16:16] <ogra_> though this would bee network storage ...
[16:16] <ogra_> not external torage (like USB sticks)
[16:17] <ogra_> +s
[16:17] <niemeyer> ogra_, shuduo: The core or the gadget snap would provide the camera slot. Not in gadget.yaml.. snap.yaml. Hot plug of USB devices is coming..
[16:20] <shuduo> niemeyer: so it is not exist in amd64 core image too, right? i can see camera interface exist from "snap interfaces" on 1604 desktop.
[16:21] <ogra_> because your desktop/laptop has a camera ?
[16:22] <shuduo> ogra_: actually no. my camera can't be detected by 1604 desktop. :D
[16:23] <stgraber> zyga: what's up?
[16:24] <shuduo> niemeyer: i want to show webcam demo or face-detection demo to customer on core. may i know ETA of camera interface?
[16:25] <niemeyer> shuduo: Don't we already have one?
[16:25] <niemeyer> Checking
[16:26] <niemeyer> We do..
[16:26] <niemeyer> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go
[16:26] <ogra_> niemeyer, we do but it does not seeem to show up on the imagees (though i wouldnt know hwo to enable it)
[16:27] <zyga> stgraber: hey
[16:27] <zyga> stgraber: I'm trying to crack a problem that you may know much more about
[16:27] <ogra_> shuduo, what kind of camera are you trying to use ?
[16:28] <shuduo> niemeyer, ogra_ so the question become when the camera interface show up in image. :)
[16:28] <zyga> stgraber: I'd like to create a separate mount namespace in which / is a slave of the real / but /media (or some other location) is not a slave but the real thing
[16:28] <ogra_> shuduo, depends on the camera ... i there is no camera on the device by default i dont think we can show the slot ...
[16:29] <zyga> shuduo: it only shows up automatically on classic AFAIR
[16:29] <ogra_> shuduo, if it is a USB camera it should be handled by the USB hotplug interface that niemeyer mentioned above
[16:29] <niemeyer> shuduo, ogra_: You don't need to do anything.. it's already supported both in the images and in 16.04:
[16:29] <niemeyer> snap interfaces | grep camera
[16:29]  * zyga looks
[16:29] <niemeyer> Just add a plug to the snap, and connect it after installing it
[16:29] <shuduo> ogra_: normal usb camera, some model from logitech.
[16:30] <ogra_> ogra@pi3:~$ snap interfaces|grep camera
[16:30] <ogra_> ogra@pi3:~$
[16:30] <zyga> niemeyer: camera is only implicitly defined on classic
[16:30] <ogra_> we do not expose it on the images
[16:30] <niemeyer> Huh
[16:30] <zyga> niemeyer: and it is also reserved for core snap
[16:30] <zyga> niemeyer: it smells wrong
[16:31] <niemeyer> zyga: The slot being reserved is correct
[16:31] <zyga> niemeyer: should be either something the gadget can add or always there
[16:31] <ogra_> reserved sounds ok
[16:31] <niemeyer> zyga: Should always be there..
[16:31] <zyga> ay, I'll make a PR quickly
[16:31] <ogra_> zyga, assuming you can aways plug a USB camera in i think it should always be there
[16:31] <zyga> yes, I agree
[16:31] <ogra_> zyga, then bug #1628592 is yours ;)
[16:31] <mup> Bug #1628592: no camera slot in pi2 or pi3 image <Snappy:New> <https://launchpad.net/bugs/1628592>
[16:32] <stgraber> zyga: so you want a given path outside the mntns to be / in the mntns but want /media to be the same and still get you any new mount under it?
[16:32] <ogra_> shuduo, thanks for pointing it out !
[16:32] <zyga> stgraber: yes, I tried a few prototypes with just command line tools (mount, unshare, pivot_root) and I didn't get anything sensible
[16:33] <zyga> stgraber: it is surprisingly easy to blow the machine up
[16:33] <shuduo> ogra_: good to know someone will take care it. go to sleep now. bye all. :)
[16:33] <ogra_> bye
[16:34] <mup> PR snapd#2025 opened: snap/implicit: don't restrict the camera iface to clasic <Created by zyga> <https://github.com/snapcore/snapd/pull/2025>
[16:34] <sborovkov> zyga: hi. Indeed after enabling xenial proposed and upgrading that armhf issue went away. My snaps run fine again.
[16:35] <zyga> done
[16:35] <zyga> sborovkov: woot, that's great
[16:35] <zyga> sborovkov: :)
[16:35] <stgraber> zyga: hmm, so I'd expect something like 1) unshare mntns 2) bind-mount new / somewhere 3) make target rprivate 4) bind-mount /media to target/media 5) make target/media rshared 6) pivot
[16:36] <zyga> stgraber: let me try that quickly
[16:36] <zyga> stgraber: my gut feeling is that without unbindable mount somewhere it blows up at 2
[16:36] <stgraber> zyga: the kernel won't let you add mounts cross mntns, so you need to have all your rshared bits setup before you pivot
[16:36] <zyga> stgraber: right, I patched my kernel to give extra diagnostic for pivot_root error cases
[16:54] <mup> PR snapcraft#834 opened: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/834>
[16:57] <davmor2> how do you go about reading the description of a snap from the commandline to know if you want to install it?
[17:08] <kyrofa> niemeyer, is what davmor2 is asking possible?
[17:09] <ogra_> xdg-open https://uappexplorer.com/apps?q=myssnapname&sort=relevance&type=snappy_application
[17:09] <ogra_> :P
[17:09] <davmor2> kyrofa, niemeyer: for example I can do apt show X and it will give me the long description as well as the short snap find only seems to show the short description
[17:09] <ogra_> just replace "mysnapname"
[17:10] <davmor2> ogra_: yeah that is fine but if you are on core you have no browser :P
[17:10] <ogra_> snap install a-browser :P
[17:10] <davmor2> ogra_: hence asking about a cli version
[17:10] <ogra_> i think there is no way ...
[17:11] <ogra_> apart from hand crafting a store query or some such
[17:11] <zyga> well, a nice CURL query probably gets you all the answers ;)
[17:11] <zyga> but I don't think you want that
[17:12] <ogra_> zyga, first you would need curl though
[17:13] <ogra_> ogra@pi3:~$ snap find curl
[17:13] <ogra_> error: no snaps found for "curl"
[17:13] <ogra_> ogra@pi3:~$
[17:17] <zyga> ogra_: there's a nice http snap AFAIK
[17:18] <ogra_> true
[17:18] <ogra_> from the almighty Chipaca
[17:21] <mup> PR snapd#2026 opened: Connect fixes <Created by stolowski> <https://github.com/snapcore/snapd/pull/2026>
[17:21] <zyga> stgraber: (sorry for the lag), that doesn't work quite well
[17:21] <zyga> stgraber: and worst of all, after pivot_root fails I see lots of extra (stale) mounts in the main namespace
[17:21] <zyga> stgraber: I'll share the script I have
[17:25] <ogra_> sergiusens, core snap building
[17:25] <mup> Bug #1628616 opened: Hello nextcloud claws-mail-moon127 all segfault on yakkety <Snappy:New> <https://launchpad.net/bugs/1628616>
[17:25] <ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ... and https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5708
[17:31] <sergiusens> ogra_ the NEW wait begins :-)
[17:31] <ogra_> heh
[17:34] <zyga> stgraber: perhaps a key qustion, when you said that step one is to unshare the mount namespace, do you consider any special sharing of / itself?
[17:35] <zyga> fg
[17:35] <zyga> jdstrand: some progress, not much success
[17:36] <zyga> stgraber, jdstrand: http://paste.ubuntu.com/23247640/
[17:36] <zyga> the good things are caused by --propagation private but this also breaks the key feature
[17:41] <jdstrand> zyga: you made that comment about keeping the namespace doc up to date. I had the same thought, but then I was like "man, once the stars align and every feature works, we should never, ever, touch this again" :P
[17:41] <sergiusens> ogra_ Snapping 'ubuntu-core' ...
[17:42] <zyga> jdstrand: yes, I had that thought too :)
[17:42] <zyga> jdstrand: I'll convert some of the docs we have into an unified format, perhaps man pages because I just love man pages and because they are installed and discoverable
[17:42] <zyga> jdstrand: hey, I think I *might* have solved the problem just now
[17:43]  * zyga typed "sync" three times just in case the world blows up
[17:43] <jdstrand> zyga: yeah, I don't care about the format. the code is well-written and well-commented, but it is hard to really see the exact steps, so I wanted that somewhere and having close to the code (ie, somewhere in snap-confine) made a lot of sense to me
[17:44] <jdstrand> s/having/have it/
[17:44] <zyga> mwahaha
[17:44]  * jdstrand crosses fingers
[17:44] <zyga> almost :)
[17:44] <zyga> I have the umount -l /old-root in the script
[17:44] <zyga> that breaks the host (understandably)
[17:44] <zyga> one fix after reboot
[17:44] <zyga> man, umount -l / just breaks the world in very very funny ways
[17:45] <zyga> rebooting
[17:45] <mup> PR snapcraft#835 opened: Add the test upstream rules <Created by elopio> <https://github.com/snapcore/snapcraft/pull/835>
[17:45] <zyga> but I think this already works
[17:45] <zyga> modulo the umount
[17:45] <zyga> I saw the event propagate
[17:46] <zyga> and I saw *correct* sharing in mountinfo
[17:46] <mup> PR snapd#2019 closed: store: retry download on 500 <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2019>
[17:46] <zyga> man, this os one abused VM
[17:46] <zyga> systemd doesn't cope that well without /
[17:47] <mup> PR snapd#2023 closed: cmd/snap,configstate: rename apply-config variables to configure <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2023>
[17:47] <zyga> there's some nice binfmt stuff that lets you run processes with an open fd to the executable, sstemd should perhps use that on all its esesential bits
[17:48] <zyga> jdstrand: it works :)
[17:48] <jdstrand> \o/
[17:48] <zyga> http://paste.ubuntu.com/23247685/
[17:48] <zyga> have a look, please
[17:49] <zyga> I'll comment it now to explain why, IMHO, things are as they are
[17:53] <ogra_> sergiusens, looks like it finished
[17:58] <jdstrand> zyga: man
[17:59] <jdstrand> so many layers of mounts...
[17:59] <jdstrand> (thinking about this added to what we already have)
[17:59] <zyga> jdstrand: more than you expected?
[17:59] <jdstrand> no
[17:59] <zyga> jdstrand: http://paste.ubuntu.com/23247723/
[17:59] <zyga> jdstrand: with extra explanations about why I think this is required
[17:59] <jdstrand> just, overall how complicated the mount namespace setup is
[18:00] <zyga> jdstrand: I left my printout of shared subtrees in the attic, I'll check some of my own questions in a moment
[18:00] <zyga> jdstrand: well, yes :)
[18:00] <jdstrand> I'm not saying it can be simplified
[18:00] <zyga> jdstrand: it's a hell of a maze
[18:00] <jdstrand> just... man
[18:00] <zyga> jdstrand: I cannot wait to see the windows kernel replicate this with their linux subsystem ;)
[18:00] <jdstrand> lol
[18:00] <zyga> tyhicks: hey, if you are around, I would love a review of the pastebin above ^^
[18:01] <zyga> stgraber: ditto, this will help us a lot
[18:01] <zyga> jdstrand: the pivot_root call can be used to set up /var/lib/snapd/hostfs
[18:01] <zyga> jdstrand: but I need to make nvidia work in a different way before that happens
[18:02] <jdstrand> hehe "infinite cycle"
[18:02] <jdstrand> I now know what prompted your tweet :)
[18:02] <zyga> jdstrand: gee, what is using that 5GBs of ram
[18:03] <jdstrand> I thought 514000+ mounts was a bit high, even for snappy :)
[18:03] <zyga> jdstrand: I killed the process, I guess that made the kernel stop in some way
[18:03] <zyga> jdstrand: but it still crashed soon after :)
[18:03] <jdstrand> I bet :)
[18:03] <jdstrand> that's funny
[18:03] <sergiusens> ogra_ I will prepare a PR
[18:04] <sergiusens> ogra_ do you have a link to the logs
[18:04] <zyga> jdstrand: and since having this I can see that none of the mount entries are share
[18:04] <zyga> jdstrand: this is a bit worring though as this is differerent from systemd defaut
[18:04] <zyga> jdstrand: so perhaps after pivot_root we should mount --make rshared / again
[18:04] <zyga> (crazy)
[18:05] <zyga> jdstrand: I bet some tools rely on this systemd default now
[18:05] <zyga> jdstrand: e.g. systemd-nspawn or similar
[18:05] <zyga> jdstrand: probably lxd as well
[18:06] <jdstrand> yeah, will have to test with content interface, lxd, docker, shared mounts, etc
[18:06]  * jdstrand hugs the testsuite
[18:08] <tyhicks> zyga: that's pretty close to what I expected it to look like
[18:09] <ogra_> sergiusens, https://launchpadlibrarian.net/287114070/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
[18:09] <tyhicks> zyga: that's crazy stuff but I don't see anything unexpected/surprising in there
[18:10] <zyga> tyhicks: thank you
[18:10] <zyga> tyhicks: the key was the unbindable part
[18:10] <zyga> tyhicks: that makes it not a new kind of fork bomb
[18:10] <tyhicks> zyga: yeah, I wouldn't have figured the unbindable part out
[18:11] <tyhicks> zyga: did shared-subtrees.txt point you towards using unbindable?
[18:11] <zyga> tyhicks: yes
[18:11] <zyga> tyhicks: I have it printed on my desk for a few days now
[18:12] <tyhicks> hehe
[18:12] <jdstrand> zyga: these days, I'm surprised you don't have it tacked up on your wall
[18:12] <tyhicks> you should laminate it
[18:12] <zyga> tyhicks: lol :)
[18:13] <zyga> tyhicks: I love that it has a quiz
[18:13] <zyga> tyhicks: that's like "you may have read it but now let's see if you pass the quiz" :-)
[18:14] <tyhicks> zyga: wow, you really have been reading it closely in order to take the quiz :)
[18:18] <zyga> thanks guys, I'll make this into a nice pull request tomorrow
[18:18] <zyga> morphis: ^^ FYI
[18:18] <zyga> morphis: call of the alarm :)
[18:23] <mup> PR snapd#2024 closed: docs: add `configure` hook to hooks list <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2024>
[18:23] <kyrofa> jdstrand, there ^^ . Now the hooks doc has information about the only existing hook
[18:24] <mup> PR snapd#2022 closed: README: add links to IRC, mailing list and social media <Created by dholbach> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2022>
[18:27] <mup> PR snapd#2018 closed: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2018>
[18:28] <ogra_> niemeyer, it is nice that you tell me the gadget isnt any different regarding slots ... my problem is that we do not have syntax for slots *anywhere* defined in the docs ... i.e. i'd expect some "slot:" keyword that i can define in the snap.yaml of  the gadget to tell the system there is such an interface
[18:30]  * ogra_ grins about jdstrand ending up on the quotes page ...
[18:31] <ogra_> jdstrand, the number of mounts will go down once we ran out of major numbers for loop devices in the kernel :P
[18:31] <niemeyer> ogra_: Yes, you are right.. we need doc champions to cover that aspect better at snapcraft.io
[18:32] <niemeyer> slots:
[18:32] <ogra_> yeah, i cant find anything aynwhere ....i looked around at the known places
[18:32] <niemeyer>     camera:
[18:32] <niemeyer> ogra_: That should be enough for this case
[18:32] <ogra_> ah, neat, k
[18:32] <niemeyer> ogra_: Plugs are also poorly documented
[18:32] <ogra_> (i would have expected it in interfaces.md ... but that actually only explains how to use the snap command)
[18:33] <niemeyer> ogra_: We really need some love in that area of snapcraft.io
[18:33] <ogra_> yeah
[18:33] <ogra_> plugs are at least mentioned in the snapcraft.yaml doc ...
[18:34] <ogra_> anyway ...
[18:34]  * ogra_ &
[18:41] <mup> Bug #1628640 opened: Add 'snap info' command showing publisher, channel map <Snappy:New> <https://launchpad.net/bugs/1628640>
[18:46] <jdstrand> ogra_: heh-- and here I was thinking the quote would be "13:03 < jdstrand> I thought 514000+ mounts was a bit high, even for snappy :)"
[18:47] <mup> PR snapd#2009 closed: tests: add firewall-control interface test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2009>
[18:50] <mup> PR snapd#1988 closed: interface/builtin: access system bus on screen-inhibit-control <Created by afrantzis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1988>
[18:54] <davmor2> ogra_: nice looks like it might be an upgrade issue rather than an install issue so I'll have a play with that tomorrow
[18:57] <mhall119> hi all, is there an electron desktop snap that I can use as an example?
[18:58] <mhall119> trying to snap up Rambox,which is electon-based
[18:58] <mhall119> davmor2: ^^ see what you did?
[18:58] <davmor2> mhall119: hey it's not my fault you are compelled to snap all the things
[18:59] <mhall119> no, it's your fault for not doing this one first, thus leaving it to me :-P
[19:00] <mup> PR snapcraft#836 opened: Deal with 404 responses from the store's snap status endpoint <Created by thomir> <https://github.com/snapcore/snapcraft/pull/836>
[19:01] <davmor2> mhall119: wait you were the one trialling it I'd never heard of it till you G+'d it :P
[19:14] <sergiusens> mhall119 there's google play music from RAOF and atom
[19:15] <sergiusens> mhall119 but saying 'electron' based is really vague, the world electron lives in has no convention
[19:33] <sergiusens> cwayne or joc a review for https://github.com/snapcore/snapcraft/pull/832 from either of you would be nice
[19:33] <mup> PR snapcraft#832: python plugin: only download in pull and build in build <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/832>
[19:34] <cwayne> I'll take a look sergiusens thanks for the heads up
[19:35] <sergiusens> cwayne this makes the plugin respect the lifecycle (to not build during the `pull` step)
[19:35] <sergiusens> and makes the hacking on the offline train story for python a reality
[19:45] <mhall119> can I get somebody to look into a snap that fails to install?
[19:46] <mhall119> http://people.ubuntu.com/~mhall119/snaps/couchdb_2.0_amd64.snap
[19:46] <mhall119> it's a daemon that systemd is failing on starting, so the install aborts
[19:47] <mhall119> if I make it just a standard app, not a daemon, I can launch it manually and it works
[19:49] <paul_r0b0t> hi
[19:49] <mhall119> hello paul_r0b0t
[19:49] <paul_r0b0t> i have deleted the stage and prime folders
[19:49] <paul_r0b0t> and when i do snapcraft clean
[19:50] <paul_r0b0t> it complains about some of the folders missing
[19:51] <paul_r0b0t> eventually i would like to crate the stage folder again
[19:51] <paul_r0b0t> with snapcraft stage
[19:51] <mhall119> you should "snapcraft clean -s stage" instead of just deleting those folders
[19:52] <mhall119> snapcraft remembers the last steps that finished successfully, so it doesn't have to repeat them
[19:52] <paul_r0b0t> right
[19:52] <mhall119> so by deleting the folders themselves, you've left it confused, it knows it finished staging and priming, but it doesn't see those folders anymore
[20:01] <sergiusens> cprov where does this error come from? "Your account lacks information to sign build assertions for this snap."
[20:02] <sergiusens> cprov I believe it comes from the store, but I thought we agreed that good error messages would tell me what to do
[20:02] <sergiusens> cprov not blaming anyone in any case, just lost
[20:03] <paul_r0b0t> ok. eventually i would to generate the stage folder again
[20:03] <paul_r0b0t> ok. eventually i would like to generate the stage folder again
[20:03] <cprov> sergiusens: snapcraft, sign-build, your account does not have upload perms on this snap. Needs a proper message, agreed
[20:04] <sergiusens> cprov oh, the error is related to me not having registered the snap?
[20:04] <sergiusens> even though the message does not mention that even :-)
[20:04] <sergiusens> I will log a bug
[20:05] <paul_r0b0t> but when i do snapcraft stage, it still "remembers" all the staged components
[20:05] <paul_r0b0t> so it doesn't attempt to stage again
[20:05] <cprov> sergiusens: yes, please, I will tackle this in a bit.
[20:06] <mhall119> paul_r0b0t: try "snapcraft clean -s stage"
[20:06] <mhall119> it might not like that though, since it's out of sync
[20:06] <mhall119> worst case, run "snapcraft clean" to reset snapcraft back to a clean slate
[20:06] <mhall119> but you'll have to do the pull and build steps again if you do
[20:06] <paul_r0b0t> yes, i tried snapcraft clean
[20:07] <paul_r0b0t> but complains b/c it cant find many of the folders
[20:07] <mhall119> then "snapcraft stage" will get you to the point where you have a ./stage/ folder agian
[20:07] <paul_r0b0t> snapcraft stage doesnt do much
[20:08] <paul_r0b0t> b/c it thinks or "remembers" all the staged components
[20:08] <sergiusens> cprov LP: #1628671
[20:08] <mup> Bug #1628671: Assertion error message with no useful end user information <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1628671>
[20:08] <mhall119> paul_r0b0t: what folders do you still have there?
[20:08] <paul_r0b0t> so it doesn't attempt to generate them again
[20:08] <paul_r0b0t> mhall119: only parts
[20:09] <sergiusens> cprov with a proper snap I get $ snap sign-build telegram-sergiusens_0.10.8_amd64.snap error: the required flags `--developer-id' and `--snap-id' were not specified
[20:09] <mhall119> ok, parts is where it stores your state info I believe, so if you remove that you should be able to start over
[20:10] <cprov> sergiusens: wow, 'snapcraft sign-build' not *snap*
[20:10] <cprov> sergiusens: snap is driven by snapcraft
[20:10] <sergiusens> cprov doh
[20:10] <sergiusens> cprov heh, autocomplete fail :-)
[20:11] <cprov> :-)
[20:11] <paul_r0b0t> yeah, only catch is that i have some local code in parts that i have changed
[20:11] <paul_r0b0t> so ideally i would just like to build
[20:11] <paul_r0b0t> and stage
[20:12] <sergiusens> cprov nice, another weird message 'Could not assert build: Snap builds are currently disabled.'
[20:12] <kyrofa> paul_r0b0t, then remove everything in parts other than the `plugins` folder
[20:12] <kyrofa> paul_r0b0t, then run snapcraft clean again
[20:12] <sergiusens> cprov so nice, I have my assertion :-) comma, look at this
[20:12] <kyrofa> paul_r0b0t, ah, you've been editing code in parts/<part>/src?
[20:13] <sergiusens> paul_r0b0t you shouldn't be adding local code in parts
[20:13] <paul_r0b0t> kyrofa: yes
[20:13] <kyrofa> paul_r0b0t, yeah, it's not really made for that
[20:13] <sergiusens> paul_r0b0t instead clone and point `source: <path-on-disk>`
[20:13] <kyrofa> paul_r0b0t, but you can get up and running if you remove all the files in parts/*/state/ EXCEPT for the one named `pull`
[20:14] <sergiusens> paul_r0b0t stuff in parts/<part-name> is there for discoverability not so much for changing; well quick experiments but not much else
[20:15] <cprov> sergiusens: staging is enabled and I will enable production when we are happy.
[20:16] <paul_r0b0t> all: yes, i understand that its not the best practice to add local code in parts
[20:16] <sergiusens> cprov got it
[20:17] <kyrofa> paul_r0b0t, then you can't be surprised when things break down :)
[20:18] <paul_r0b0t> but it has been convenient to use snapcraft in order to setup quickly my development environment
[20:18] <paul_r0b0t> not what snapcraft has beeen made for
[20:19] <paul_r0b0t> i guess i can keep a backup of local parts source code
[20:20] <paul_r0b0t> then remove everything in parts except 'plugins'
[20:20] <paul_r0b0t> and run snapcraft clean
[20:21] <kyrofa> paul_r0b0t, or do what sergiusens recommended, but yeah, that works too
[20:23] <paul_r0b0t> kyrofa, sergiusens, mhall119, : thx!
[20:23] <sergiusens> cprov darn, my search for a string failed I will kill that bug I logged as your branch isn't merged yet
[20:30] <cprov> sergiusens: Can I amend my PR with the error messages fix or to do you prefer a new one because that is already fully tested ?
[20:30] <sergiusens> cprov ammend is fine
[20:31] <cprov> sergiusens: will do, thanks.
[20:31] <sergiusens> cprov no need to ammend either, we can squash on merge (which will make it easier to review the delta actually)
[20:32] <sergiusens> cprov also, do we have a bug for this; sorry I am super slow today
[20:33] <cprov> sergiusens: no, we do not since it's a new UX feature, I will create one.
[20:45] <cprov> sergiusens: new commit for you appreciation ;-)
[20:50] <sergiusens> cprov that looks much nicer :-)
[20:51] <cprov> sergiusens: np, sorry for letting it slip.
[20:51] <cprov> it was equivalent to display "You suck!" on the terminal ;-)
[20:59] <mup> PR snapd#2027 opened: asserts: support parsing the plugs stanza i.e. plug rules in snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2027>
[21:15] <cwayne> sergiusens: if i push up a new snapcraft.yaml for a remote part, how long does it usually take before snapcraft update sees it
[21:20] <josepht> cwayne: roughly an hour
[21:21] <josepht> sergiusens: ^
[21:21] <cwayne> josepht: thanks
[21:21] <josepht> cwayne: np
[21:36] <mup> PR snapcraft#833 closed: Add links to IRC, mailing list and social media <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/833>
[21:38] <lool> ogra_: around still?
[21:38] <lool> or anyone: where's the source for the gadget snaps for rpi*?
[21:53] <mup> PR snapd#2015 closed: asserts: introduce AttributeConstraints <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2015>
[22:30] <mup> PR snapcraft#831 closed: 'sign-build' implementation <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/831>
[23:02] <cwayne> sergiusens: so i was able to build checkbox with that branch, so lgtm on that front at least :)