| ahoneybun | mm if if get the tar.bz2 file what plugin do i need to use? | 01:18 |
|---|---|---|
| ahoneybun | audacious 3.8 | 01:18 |
| mup | Bug #1628357 opened: A deamon fails with: No home directory found <Snappy:New> <https://launchpad.net/bugs/1628357> | 02:42 |
| === JanC is now known as Guest85708 | ||
| === JanC_ is now known as JanC | ||
| === jibel_ is now known as jibel | ||
| 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:26 |
| dholbach | good morning | 06:33 |
| dholbach | mhall119, nice work on the content snap blog! | 06:38 |
| 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:04 |
| didrocks | ok, found a cryptic explanation on some design doc | 07:07 |
| dholbach | didrocks, no, I don't | 07:10 |
| 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:13 |
| === cpaelzer_ is now known as cpaelzer | ||
| dholbach | didrocks, to the codelabs or where? | 07:28 |
| didrocks | dholbach: codelabs | 07:33 |
| didrocks | (done) | 07:33 |
| dholbach | didrocks, awesome - thanks | 07:34 |
| didrocks | yw! | 07:35 |
| 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:36 |
| 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:49 |
| 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 | 07:59 |
| 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:02 |
| 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:18 |
| 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:19 |
| didrocks | dholbach: oh, that, maintaining together | 08:21 |
| didrocks | yeah | 08:21 |
| didrocks | let me see if I have a link for this | 08:21 |
| didrocks | dholbach: sent | 08:22 |
| dholbach | hah, fun - the message was in French | 08:23 |
| dholbach | great, that was painless | 08:23 |
| === tasdomas` is now known as tasdomas | ||
| didrocks | ;) | 08:28 |
| popey | haha, got that too | 08:31 |
| popey | thought it was spam, being french ;) | 08:32 |
| popey | "You have successfully been granted administrative access to snap-codelabs.didrocks." - MUhahahahah | 08:33 |
| mup | PR snapd#2018 opened: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2018> | 08:39 |
| 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> | 08:51 |
| 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:00 |
| ogra_ | (at least a blog post is ... ) | 09:01 |
| popey | ok | 09:02 |
| 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:07 |
| 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:14 |
| 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:16 |
| 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:17 |
| ogra_ | (havent seen that one before ... and i guesss it might just succeed if i re-try) | 09:18 |
| ogra_ | (since all others have succeeded) | 09:19 |
| mup | PR snapd#2019 opened: store: retry download on 500 <Created by chipaca> <https://github.com/snapcore/snapd/pull/2019> | 09:34 |
| 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:46 |
| 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 | 09:48 |
| mup | PR snapd#2021 opened: releasing package snapd version 2.16 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2021> | 10:14 |
| ogra_ | well, let me just try a re-build ... i dont really see any obvious other errors and yesterdays build has worked ... | 10:23 |
| 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:25 |
| * ogra_ files bug 1628457 | 10:41 | |
| mup | Bug #1628457: snapcraft fails on s390x with utf8 error <Snapcraft:New> <https://launchpad.net/bugs/1628457> | 10:41 |
| 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> | 11:05 |
| === jkridner|pd is now known as jkridner | ||
| 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:31 |
| 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:33 |
| zyga_ | didrocks: I don't know about grade, sorry | 12:35 |
| === zyga_ is now known as zyga | ||
| 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:36 |
| zyga | my current quest is to figure out where pivot_root is giving up with EINVAL, I'm just patching the kernel | 12:37 |
| 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:38 |
| jdstrand | zyga: you're kernel isn't oopsing or anything? | 12:39 |
| zyga | jdstrand: ah, no, nothing like that happens | 12:39 |
| 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:40 |
| zyga | jdstrand: oh, interesting | 12:41 |
| zyga | jdstrand: I bet there is some new ground we are breaking here | 12:41 |
| jdstrand | oh totally | 12:42 |
| jdstrand | all kinds of new ground :) | 12:42 |
| zyga | moving to a VM is actually better as native is slow/costly to recover | 12:43 |
| jdstrand | indeed :) | 12:43 |
| 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:44 |
| 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:46 |
| 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:47 |
| 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:48 |
| ogra_ | you just attach them to the eyelet on your computer :P | 12:51 |
| 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:57 |
| 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:58 |
| ogra_ | but yeah, as a quick hack, tell me what changes you need and i'll push a debug snapcraft to the PPA temporary | 12:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:07 |
| 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:08 |
| 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:09 | |
| oparoz | The discussion about /media earlier was to allow snaps access to /media? That would be great :) | 13:10 |
| ogra_ | sergiusens, well, it is funny that it only affects s390x ... | 13:11 |
| sergiusens | ogra_ well, funny as it may be, I bet that is the issue and your ppa run will luckily prove it | 13:15 |
| 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:17 |
| zyga | joc: hey, do you have a second? | 13:19 |
| joc | zyga: sure | 13:20 |
| zyga | joc: I need to verify something for GPIO interface | 13:20 |
| 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:21 |
| joc | zyga: yep i have hardware can try it on | 13:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:37 |
| * 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:38 |
| kyrofa | jdstrand, but yeah, that doc should be updated as hooks are added | 13:39 |
| 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:40 |
| 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:41 |
| jdstrand | I see, nm then | 13:42 |
| 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:43 |
| joc | zyga: yes three chips | 13:44 |
| Elleo | kgunn: ah, seems to actually be /run/snapd.socket it gets the error on: http://pastebin.ubuntu.com/23246852/ | 13:45 |
| kgunn | otp but will read up in a bit | 13:46 |
| kyrofa | Hey ogra_, got a sec? | 13:47 |
| ogra_ | kyrofa, i guess i do | 13:49 |
| kyrofa | ogra_, saw a question on askubuntu that made me think of you: https://askubuntu.com/questions/829118/ubuntu-core-power-failure-resistance | 13:50 |
| kyrofa | ogra_, I suspect the overall answer to the question is no, is that correct? | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 :) | 13:58 |
| 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:08 |
| 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:09 |
| 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:10 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | sergiusens, snap build started ... | 14:22 |
| sergiusens | ogra_ \o/ | 14:26 |
| kyrofa | ogra_, does http://askubuntu.com/a/830774/261753 look reasonable? | 14:31 |
| ogra_ | kyrofa, looks fine to me | 14:33 |
| 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:34 |
| zyga | joc: can you tell me what you see in /sys/class/gpio please | 14:36 |
| 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:37 |
| mvo | dbarth: does #65 for snapweb the "WI" mean "work-in-progress" ? or work-item? or something else :) ? | 14:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| dbarth | ogra_: :) | 14:44 |
| zyga | joc: if you 'echo 123 > /sys/class/gpio/export' does it just do what is expected? | 14:45 |
| zyga | joc: where 123 is any number in the expected range | 14:46 |
| joc | zyga: yep | 14:46 |
| zyga | joc: thanks | 14:47 |
| * zyga wonders what the udev rule trigger should be | 14:47 | |
| mup | PR snapd#2024 opened: docs: add `configure` hook to hooks list <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2024> | 15:17 |
| shuduo | ogra_: hi in recent pi3 beta image, there is no camera slot in "snap interfaces" output. is it expected? | 15:18 |
| ogra_ | shuduo, hmm, i wouldnt know who is supposed to actually provide it | 15:20 |
| zyga | stgraber: hey, do you have a moment | 15:20 |
| ogra_ | shuduo, ounds liek you sshoudl file a bug as a starting point | 15:21 |
| shuduo | ogra_: sure if it's a tracked issue i would file a bug | 15:22 |
| ogra_ | sergiusens, have you seen the log above ? | 15:27 |
| 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:28 |
| ogra_ | iirc we are using C.UTF-8 ... i wonder if thats any different on s390x than on the other arches | 15:29 |
| sergiusens | ogra_ all the same | 15:30 |
| sergiusens | ogra_ can I give you a quick other patch? | 15:30 |
| ogra_ | sure | 15:30 |
| 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:32 |
| 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:33 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | ogra_ http://paste.ubuntu.com/23247199/ | 15:42 |
| 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:49 |
| zyga | hmm | 15:56 |
| ogra_ | shuduo, no, thats not expected, if th device is properly set up via console-conf it should boot (and does here) | 15:57 |
| shuduo | ogra_: sadly it is almost 100% reproducable at my side | 15:58 |
| ogra_ | weird | 15:58 |
| 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:07 |
| ogra_ | heh, yeah, arm devices demand some level of patience ;) | 16:08 |
| ogra_ | sergiusens, so the package has just finished building ... lets see if the publisher manages to publish in under 60min :P | 16:09 |
| 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:13 |
| oparoz | Are there plans to let Snaps mount external storage (NFS, CIFS)? | 16:15 |
| 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:16 |
| 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:17 |
| 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:20 |
| ogra_ | because your desktop/laptop has a camera ? | 16:21 |
| shuduo | ogra_: actually no. my camera can't be detected by 1604 desktop. :D | 16:22 |
| stgraber | zyga: what's up? | 16:23 |
| shuduo | niemeyer: i want to show webcam demo or face-detection demo to customer on core. may i know ETA of camera interface? | 16:24 |
| niemeyer | shuduo: Don't we already have one? | 16:25 |
| niemeyer | Checking | 16:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| mup | PR snapcraft#834 opened: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/834> | 16:54 |
| davmor2 | how do you go about reading the description of a snap from the commandline to know if you want to install it? | 16:57 |
| kyrofa | niemeyer, is what davmor2 is asking possible? | 17:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| ogra_ | zyga, first you would need curl though | 17:12 |
| ogra_ | ogra@pi3:~$ snap find curl | 17:13 |
| ogra_ | error: no snaps found for "curl" | 17:13 |
| ogra_ | ogra@pi3:~$ | 17:13 |
| zyga | ogra_: there's a nice http snap AFAIK | 17:17 |
| ogra_ | true | 17:18 |
| ogra_ | from the almighty Chipaca | 17:18 |
| 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:21 |
| 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:25 |
| sergiusens | ogra_ the NEW wait begins :-) | 17:31 |
| ogra_ | heh | 17:31 |
| 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:34 |
| zyga | fg | 17:35 |
| zyga | jdstrand: some progress, not much success | 17:35 |
| 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:36 |
| 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:41 |
| 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:42 |
| * 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| zyga | jdstrand: it works :) | 17:48 |
| jdstrand | \o/ | 17:48 |
| zyga | http://paste.ubuntu.com/23247685/ | 17:48 |
| zyga | have a look, please | 17:48 |
| zyga | I'll comment it now to explain why, IMHO, things are as they are | 17:49 |
| ogra_ | sergiusens, looks like it finished | 17:53 |
| jdstrand | zyga: man | 17:58 |
| 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 | 17:59 |
| 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 |
| === dpm is now known as dpm-afk | ||
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| jdstrand | yeah, will have to test with content interface, lxd, docker, shared mounts, etc | 18:06 |
| * jdstrand hugs the testsuite | 18:06 | |
| tyhicks | zyga: that's pretty close to what I expected it to look like | 18:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| tyhicks | zyga: wow, you really have been reading it closely in order to take the quiz :) | 18:14 |
| 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:18 |
| 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:23 |
| 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:24 |
| 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:27 |
| 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:28 |
| * ogra_ grins about jdstrand ending up on the quotes page ... | 18:30 | |
| 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:31 |
| 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:32 |
| 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:33 |
| ogra_ | anyway ... | 18:34 |
| * ogra_ & | 18:34 | |
| mup | Bug #1628640 opened: Add 'snap info' command showing publisher, channel map <Snappy:New> <https://launchpad.net/bugs/1628640> | 18:41 |
| 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:46 |
| 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:47 |
| 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:50 |
| 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:54 |
| mhall119 | hi all, is there an electron desktop snap that I can use as an example? | 18:57 |
| 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:58 |
| mhall119 | no, it's your fault for not doing this one first, thus leaving it to me :-P | 18:59 |
| 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:00 |
| davmor2 | mhall119: wait you were the one trialling it I'd never heard of it till you G+'d it :P | 19:01 |
| sergiusens | mhall119 there's google play music from RAOF and atom | 19:14 |
| sergiusens | mhall119 but saying 'electron' based is really vague, the world electron lives in has no convention | 19:15 |
| 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:33 |
| cwayne | I'll take a look sergiusens thanks for the heads up | 19:34 |
| 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:35 |
| mhall119 | can I get somebody to look into a snap that fails to install? | 19:45 |
| 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:46 |
| mhall119 | if I make it just a standard app, not a daemon, I can launch it manually and it works | 19:47 |
| 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:49 |
| paul_r0b0t | it complains about some of the folders missing | 19:50 |
| 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:51 |
| 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 | 19:52 |
| sergiusens | cprov where does this error come from? "Your account lacks information to sign build assertions for this snap." | 20:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| cprov | sergiusens: staging is enabled and I will enable production when we are happy. | 20:15 |
| 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:16 |
| kyrofa | paul_r0b0t, then you can't be surprised when things break down :) | 20:17 |
| 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:18 |
| paul_r0b0t | i guess i can keep a backup of local parts source code | 20:19 |
| paul_r0b0t | then remove everything in parts except 'plugins' | 20:20 |
| paul_r0b0t | and run snapcraft clean | 20:20 |
| kyrofa | paul_r0b0t, or do what sergiusens recommended, but yeah, that works too | 20:21 |
| 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:23 |
| 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:30 |
| 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:31 |
| sergiusens | cprov also, do we have a bug for this; sorry I am super slow today | 20:32 |
| cprov | sergiusens: no, we do not since it's a new UX feature, I will create one. | 20:33 |
| cprov | sergiusens: new commit for you appreciation ;-) | 20:45 |
| sergiusens | cprov that looks much nicer :-) | 20:50 |
| cprov | sergiusens: np, sorry for letting it slip. | 20:51 |
| cprov | it was equivalent to display "You suck!" on the terminal ;-) | 20:51 |
| 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> | 20:59 |
| 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:15 |
| josepht | cwayne: roughly an hour | 21:20 |
| josepht | sergiusens: ^ | 21:21 |
| cwayne | josepht: thanks | 21:21 |
| josepht | cwayne: np | 21:21 |
| 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:36 |
| lool | ogra_: around still? | 21:38 |
| lool | or anyone: where's the source for the gadget snaps for rpi*? | 21:38 |
| mup | PR snapd#2015 closed: asserts: introduce AttributeConstraints <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2015> | 21:53 |
| mup | PR snapcraft#831 closed: 'sign-build' implementation <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/831> | 22:30 |
| cwayne | sergiusens: so i was able to build checkbox with that branch, so lgtm on that front at least :) | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!