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