[00:21] PR snapd#2234 opened: static tests: add spell check === deadk is now known as e [01:39] elopio, ping === chihchun is now known as chihchun_afk [02:02] PR snapcraft#879 opened: The latest icon definition is deprecated === chihchun_afk is now known as chihchun [05:00] I have a .gz file, what should be the source-type to use when I download it in the snapcraft.yaml. I have tried to use zip, bit it does not succeed. thanks [05:03] PR snapd#2233 closed: docs: update the name of the command for the cross-build [05:20] ogra_: no holiday, but being stuck in cloud roadmap review sessions all day, laptop-less :) (yesterday) [05:23] elopio: I didn't see this before, no; did you try this locally? sounds like your way of checking out a github (?) PR doesn't work [07:04] PR snapd#2235 opened: debian: wrap-and-sort === mup_ is now known as mup [09:02] PR snapd#2228 closed: interfaces/bulitin: allow fwupdmgr refresh on fwupd plug [09:29] PR snapd#2236 opened: interfaces: add realsense interface [10:02] PR snapcraft#877 closed: Add new "source-commit" field for VCS sources [10:07] for the life of me, I can't figure out where the man page is generated from when running snap help --man [10:07] niemeyer: ^ [10:08] Son_Goku: It's generated from the flag metadata in the code itself [10:09] niemeyer, it says the man page is snap(1) rather than snap(8) [10:09] I just want to fix that [10:09] or have it fixed [10:09] either way works [10:09] Ah, let me see where the code lives [10:09] I tried diving into it yesterday and got lost in the wave of golang things ;) [10:12] niemeyer, it's been a section 8 manpage for a while, but apparently the man page generation code still writes snap(1) [10:14] Son_Goku: Will be slightly trickier than it sounds: https://github.com/jessevdk/go-flags/blob/master/man.go#L179 [10:14] eek [10:15] Son_Goku: Might be easier to patch it locally, if you want a quick fix [10:15] hi everyone. I was having a look at snapcraft.io homepage, I saw this line "A snap can declare daemons to be started as well, this one just describes some apps. [10:16] yeah, I think I'm just going to patch the man page itself until that's figured out [10:16] but I'm not sure what that means. "This one?" [10:16] does it refer to the example above? [10:16] but since Debian, Ubuntu, and Fedora install it per the reference debian packaging data (as section 8), the man page is obviously wrong here [10:16] Son_Goku: Both snap and dpkg are (1) in Ubuntu/Debian [10:16] (maybe it needs some rephrasing?) [10:16] (FWIW) [10:17] snap is in section 8 [10:18] niemeyer: https://github.com/snapcore/snapd/blob/master/debian/rules#L157 [10:18] someone changed it a while back [10:18] Son_Goku: $ dpkg -L snapd | grep 'man[0-9]/snap' [10:18] /usr/share/man/man1/snap.1.gz [10:18] wtf? [10:18] but... https://github.com/snapcore/snapd/commit/d1bd21632f3bca781bb64cb6a62e099f7978658d [10:19] I'm completely confused now [10:19] Son_Goku: We need to kill the debian/ directory really [10:19] alright, I'll fix it in the spec for now [10:19] I think does belong in 8, though [10:19] It's super confusing indeed.. basically it can be out of date with the actual packaging rules in use in Debian and/or Ubuntu [10:19] Son_Goku: Not any more than dpkg itself [10:20] rpm and yum/dnf are in section 8 [10:20] I'm not sure why dpkg isn't [10:20] Son_Goku: I think it's reasonable [10:20] Son_Goku: Users care about what is installed too [10:20] apt is in section 8 as well [10:21] as is aptitude and... synaptic?! [10:21] synaptic has a man page...? [10:21] Son_Goku: But I won't bikeshed much on this one.. it's just a number really [10:21] yeah, meh [10:21] I'll just fix it to point to 1 for now [10:21] and a pretty irrelevant one at that [10:21] I don't actually care, but the inconsistency annoyed me [10:21] Yeah [10:22] Having it in one is the easiest, given it's hardcoded in go-flags [10:22] that's a weird and terrible thing to be hardcoded [10:22] but whatever [10:23] PR snapd#2235 closed: debian: wrap-and-sort [10:25] zyga: ping [10:26] zyga: https://github.com/zyga/snapcore-fedora/pull/11 [10:26] PR zyga/snapcore-fedora#11: Update SELinux subpackage commit and move snap.8 to snap.1 [10:26] I'm at the point where I don't want to keep hitting it with a hammer anymore [10:26] the policy *should work* once niemeyer lands the change to stop downloading things into /tmp and download them in /var/lib/snapd/ [10:27] for the curious, here's what the policy looks like now: https://gitlab.com/Conan_Kudo/snapcore-selinux/blob/master/snappy.te [10:28] it could stand to have some cleanup, but I don't want to do that now [10:28] zyga, please merge the pull request and then update the snapd review with it [10:28] I want to approve it already... :/ [10:29] that way the preset rules can make it into Fedora asap [10:37] niemeyer, has the code landed for making it download in /var/lib/snapd/ yet? [10:37] Son_Goku: Not yet.. hopefully today [10:37] cool === dholbach_ is now known as dholbach [10:56] hi all, I tried to install http://cdimage.ubuntu.com/ubuntu-snappy/16.04/20160919/ubuntu-core-16-amd64.img.xz on an Intel compute stick (STK1A32SC). It gets stuck when booting, saying 'grep: /proc/device-tree/model: No such file or directory' and later "findfs: unable to resolve 'LABEL=writeable'" [10:56] booting ubuntu-15.04-snappy-amd64-generic.img.xz goes fine on the same hardware. [10:58] I am wondering if it is known prob or should I report somewhere? [11:00] tptr, that is from a USB key ? [11:00] (or how do you boot ?) [11:01] well, I boot a normal 16.04 on the stick from a USB key. then download this image, unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz | sudo dd of=/dev/mmcwhatever bs=32M [11:02] Bug #1638248 opened: No 'current' symlink for $SNAP_USER_DATA [11:02] then it starts booting OK but then gets stuck at the above mentioned point. Unfortnately keyboard does not work either so cannot interact with it... [11:02] ( tre instructions from https://developer.ubuntu.com/en/snappy/start/#try-x86 ) [11:10] tptr, if you dd directly to the USB key and boot from there, does it work ? [11:10] oh, wait [11:10] you downloaded 15.04 ... [11:10] this is what I do [11:10] with 15.04 it works fine [11:11] with 16.04/20160919/ubuntu-core-16-amd64.img.xz it gets stuk [11:11] well, 15.04 is pretty much EOL (within the next 4 weeks or so) ... [11:12] and completely different too (regarding the overall image design) [11:12] yes... [11:12] this is why I would love to switch to 16.04 as soon as I can [11:13] but I cannot boot it on this device. due to this problem. [11:14] well, try booting from the USB key [11:15] oh, wait ... you also downloaded the wrong image [11:15] http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ is waht you want [11:17] aaah ok. I will give this a try. thanks a bunch. === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko [12:38] slangasek: can we release snap-confine 1.0.44 into ubuntu? [12:39] slangasek: there's some SRU work that needs to happen for that [12:39] slangasek: https://bugs.launchpad.net/snap-confine/+milestone/1.0.44 [12:41] zyga, can you please update the snapd review with the latest SRPM and spec [12:41] hai [12:41] i want to know about ubuntu mobile os [12:42] can you help me [12:42] sree, you should probably ask in #ubuntu [12:42] okay [12:43] zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825 [12:44] zbyszek is waiting on my to approve the package so he can merge the presets in [12:44] s/my/me/ [12:46] zyga, technically, the selinux policy as-is isn't going to completely work with snapd 2.16 [12:46] because of it downloading to /tmp instead of /var/lib/snapd [12:47] but niemeyer says that change will land today, so you can backport it before making a build in koji and submitting it as an update [12:53] snapd is vulnerable to all of these currently, in some form: https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html [12:55] erm [12:55] femme: No, none of them, actually [12:55] it shouldn't be [12:55] the connection is secured between snapd and the Canonical store [12:56] and the data is document signed and checksummed [12:57] femme, the major Linux distributions today provide mechanisms to defeat those particular attacks [12:57] the 'parts' are not signed or checked for integrity any way - it's just a wiki page and it will download and execute whatever is on that page [12:59] femme: snapcraft is not snapd [13:00] ok, my mistake then, snapcraft [13:00] snapcraft has its own issues, sure [13:00] femme: This page is about apt and yum, not their build infrastructure [13:00] it's also horribly out of date for apt and yum too [13:00] niemeyer: doesn't matter [13:00] both package managers have solved these issues a long time ago [13:01] it's a research paper and they only solved the issues because of it... [13:01] femme: Of course it matters. [13:01] niemeyer: how? [13:02] I humored this channel enough with the pedantic questions yesterday, I hope today won't be a repeat because I won't be coming back [13:02] femme: This page is entirely about APT and YUM, and discuss issues related to package management and not how these packages are build [13:02] built [13:02] the way packages are built has a different set of issues [13:02] femme: If you want to raise issues with snapcraft, that's fine.. but that's completely unrelated to snapd and do the page you pointed out [13:02] femme: So, sort of fundamental to the point [13:03] niemeyer: it's about dependency management [13:03] snap build infrastructure is quite weak, sure, but that's not necessarily the same as the snap runtime/install infrastructure [13:03] So you're missing a fundamental point [13:03] femme: Exactly, and snapcraft is not about package management dependency [13:03] niemeyer: then why does it include that functionality? [13:03] femme: This is the *build* system [13:03] femme, snaps cannot do direct dependencies [13:03] femme: The tone of the conversation is also very unfriendly.. unnecessarily unfriendly [13:04] they can indirect, capability oriented dependencies [13:04] much coarser than package deps [13:04] femme: I appreciate the point you are trying to make, though.. it's just a bit misguided [13:04] No, I think you either don't understand or you don't care if snapcraft users are targeted. [13:05] femme: You are very strongly making the wrong point, instead of kindly making the right one. [13:05] femme, I agree that what you're saying is a problem [13:05] but the issue is, the person you should be talking to isn't even here right now [13:05] Son_Goku: I'll probably never talk to them thanks to people like niemeyer [13:06] * Son_Goku sighs [13:06] PR snapd#2237 opened: bugfix: use a .partial file in download to unbreak `snap download` as user [13:06] Just keep up with the pedantics, it's a build system as if it doesn't do dependency resolution in a vulnerable way [13:08] that went well [13:09] is there a way to prompt the user for input during the installation of a snap? couchdb needs to setup an admin username and password when you install it [13:10] can somebody reply to http://askubuntu.com/questions/842792/unable-to-install-ubuntu-snap-in-16-04-lts? [13:10] Yes, security is pedantic femme. [13:11] kalikiana_: re lxd clients-- it is is limitation of lxd. if you can connect to the lxd socket, you can trivially escape confinement. this is not unlike docker or libvirt (not quite as trivial, but scriptable) [13:11] I've followed up up privately. [13:11] Son_Goku: yes, I'll do it shortly [13:11] kalikiana_: aiui, they have todos to improve that, I think using acls [13:11] Son_Goku: understood [13:11] hey niemeyer and zyga :) [13:12] kalikiana_: ah, I see stgraber already anwswered you [13:13] zyga: niemeyer: do we have documentation somewhere about the configuration hook and how to use it? [13:14] mhall119: I'm working on that.. will finish as soon as the holy image is out. [13:14] jdstrand: hey [13:14] thanks niemeyer, I think that will solve couchdb's needs [13:15] < niemeyer> | We know about the *actual* underlying issue, and the fix is planned. < niemeyer> | I was merely pointing out that this is unrelated to snapd, and to the page you linked saying "snapd is vulnerable to all of those" < niemeyer> | Your attitude makes it very hard to even start a conversation, though < niemeyer> | Yes, I am pedantic. Security is pedantic, very. [13:15] Yeah, *my attitude* is the problem. It's not like I immediately said I was mistaken and in fact meant snapcraft, right? [13:16] niemeyer: are there any security restrictions on who can call "snap set"? [13:16] But I'm the one that made it hard to start a conversation, sure. [13:16] mhall119: Yeah, root only for now. [13:16] cool [13:16] mhall119: Sorry, more clearly: auth-only for now [13:16] mhall119: As in, works through the API [13:17] so, same auth requirement as was needed to install it in the first place? [13:17] jdstrand: is everything okay? [13:17] femme: the issue of it being a wiki page is being sorted out as we speak.. it was obviously a cheap way to start, and a visible one, which was handy for a while [13:17] femme: There will be an actual server handling those things, with proper auth, etc [13:18] niemeyer: you could have just said that instead of repeating over and over that they weren't talking about build systems but you instead chose to ignore everything I was saying and when I left to tell me that I was the problem. [13:19] zyga: yes, I got back and just wanted to say 'hi' :) [13:19] jdstrand: ah, great to have you back :) [13:19] thanks! :) [13:19] the 'fundamental point' you were talking about, was one you were and still are missing [13:19] femme: That's what I've been trying to do. Sorry if I failed at that. [13:20] femme: niemeyer: we're all just trying to get stuff done, there's nothing personal about it, it's just code. [13:21] zyga, I think mvo's PR here is the one that fixes this: https://github.com/snapcore/snapd/pull/2237 [13:21] PR snapd#2237: bugfix: use a .partial file in download to unbreak `snap download` as user [13:21] I don't like being talked over by people that think they know more than you. [13:21] give each other the benefit of the doubt, text doesn't lend itself to expression very well, and sometimes we don't come across the way we meant to [13:22] femme: niemeyer just wants to help people use snaps, he wants to help you too. I'm positive he wasn't trying to talk over you [13:22] Son_Goku: he's sitting right besides me, I'll update the SRPM when the branch lands [13:22] zyga, did you go ahead and make the SRPM and spec update to the bugzilla ticket, though? [13:22] I'd like to go ahead and give it my stamp of approval [13:23] Great, I came here because at the tor project we were considering snaps but this has only left a bad taste in my mouth. [13:23] Son_Goku: ah, ok, I'll do that now [13:23] Son_Goku: thank you for all the contributions, this is fantastic milestone! [13:23] zyga: Son_Goku: is this the contribution I think it is? [13:23] femme: tor can use snaps, you don't have to use the parts wiki [13:23] mhall119: yes [13:23] \o/ [13:23] mhall119, yes, it is :D [13:23] Son_Goku: you're going to blog about it somewhere, right? right? [13:24] mhall119, yes, yes [13:24] mhall119: I think many people will :) [13:24] as soon as I have a working version of snapd in the repos, yes [13:24] * mhall119 prepares the share/like/+1 button [13:24] femme: you don't even have to use snapcraft, strictly speaking [13:24] femme: you can very precisely build a snap manually, controlling all the bits [13:25] femme: and publish gpg signatures and anything else you want for cross-checks [13:25] femme: Again, I'm sorry if it sounded like I was trying to "talk over you" or offend in any other way. The point above is exactly what I was trying to convey, and failed apparently. [13:25] We need reproducible builds so I think that's the only way we can go about it. [13:25] femme: and you can [13:25] femme: snap is a fancy zip file [13:25] femme: just build the content [13:25] ehhh [13:25] it's not *quite* that [13:25] a fancy squashfs file [13:25] :) === chihchun is now known as chihchun_afk [13:26] PR snapd#2238 opened: many: fix download as user with nice partial filename [13:26] femme: This should give you ideas: https://github.com/snapcore/snapd/tree/master/tests/lib/snapbuild [13:27] Incidentally, I have a branch of snapcraft that (almost) takes a source-signed-by: [ 0xGPG, 0xGPG ] argument in snapcraft yaml parts. [13:27] femme: It takes the final content of a snap and simply bundleds it into the .snap file [13:27] bundles [13:27] I haven't published because GPG is kind of dumb, take ALL instead of ANY OF in its verification step. [13:28] and I've written an independent snap build implementation for core snaps [13:28] https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap [13:28] it wouldn't take much for me to be able to do snapcraft-like things [13:29] femme: These are all snaps we use on the test suite, that we "build" with it: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps [13:29] femme: It doesn't actually build anything, though.. it merely packs it up [13:30] niemeyer: are there any plans for an install-time hook? [13:30] femme: As an interesting property of the system in this context, the snap is never modified.. the digest of whatever is built on your machine is the digest that lands on the users machine [13:30] it would be useful to bootstrap stuff in $SNAP_DATA or $SNAP_COMMON [13:30] femme: And there are two signatures on it, one by the store, one by the snap publisher [13:31] mhall119: configure! [13:31] niemeyer: does that get called at install time? Or only when a user calls snap set? [13:31] mhall119: It's called at install time [13:31] mhall119: and on every refresh [13:31] zyga, my VM is a complete mess now :) [13:31] oh, perfect! Are docs coming for that soon too? [13:32] mhall119: Wait, I need to confirm the second part of it [13:32] mhall119: Definitely at install time [13:32] that's the main one for me [13:32] mhall119: Yeah, it's part of that doc wiki [13:33] Son_Goku: build in progress [13:36] Son_Goku: /var/tmp/rpm-tmp.XLkaC3: line 62: /home/zyga/rpmbuild/BUILDROOT/snapd-2.16-1.fc24.x86_64/usr/share/man/man1/snap.1: No such file or directory [13:36] uhh [13:36] niemeyer: enabling HPKP on wiki.ubuntu.com and snapcraft would go a long way [13:36] you messed up [13:36] femme: We'll drop that entirely, and have a proper database for that content, with proper authentication, etc [13:37] or rather I did [13:38] zyga: https://github.com/zyga/snapcore-fedora/blob/master/snapd.spec#L172 [13:38] that needs to be man1 [13:38] Son_Goku: right [13:38] Son_Goku: fixing, thanks [13:38] np [13:38] femme: But if you'd like to start sooner, I'd suggest going the snapbuild route.. it's really not that big of a jump. Once we've nailed down these snapcraft edges, should be trivial to move back [13:39] femme: We should also have a --no-remote sort of flag [13:39] femme: Which forces snapcraft to operate only on local parts [13:39] I'll talk to Sergio about this [13:39] serguisens is our snapcraft master [13:40] niemeyer, that would be handy for integration of snapcraft into something like Koji [13:40] or OBS [13:41] Son_Goku: uploaded [13:42] you've uploaded a new SRPM and spec to your fedorapeople space and linked it in the bug? [13:42] * Son_Goku doesn't see it... [13:43] Son_Goku: bug updated [13:43] Son_Goku: really? [13:43] Son_Goku: yes, both [13:43] https://fedorapeople.org/~zyga/snapd.spec [13:43] shows me snapd 2.12 [13:43] PR snapd#2238 closed: many: fix download as user with nice partial filename [13:43] and nothing here https://bugzilla.redhat.com/show_bug.cgi?id=1367825 [13:43] oh, sorry wrong directory [13:44] and bug was updated separately now [13:44] Son_Goku: check now please [13:44] there we go [13:44] * zyga hugs Son_Goku :) [13:47] @orga I have just tried with http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ but I got the same. dd image to intel stick. it starts booting then gets stuck at Running /scripts/local-premount ... grep: /proc/device-tree/model: No such file or directory [13:47] tptr: No such command! [13:47] @ogra_ :-) [13:47] tptr: No such command! [13:47] Son_Goku: ok, we just need that patch and we're good [13:48] tptr, thats a red herring (i just rolled a new kernel snap that suppresses that warning) [13:48] zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c23 [13:48] tptr, it shouldnt influence your boot process though ... [13:49] Son_Goku: going to create the package now [13:49] :D [13:49] tptr, did you try booting directky from usb stick ? [13:49] next line: findfs: unable to resolve 'LABEL=writable' [13:49] right, thats the issue ... but also not the cause [13:49] you said something about mmc [13:49] i assume the missing mmc/SD card driver in the initrd is your issue [13:50] zyga, so far, this was the worst part: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/6331fd4a058271b0246714bc6746ab1e7ce2aa09 :( [13:50] try booting off USB, if that actually worksd we know for sure [13:50] Son_Goku: should I ask for epel as well? [13:51] Son_Goku: nice, I need to learn this better [13:51] PR snapd#2239 opened: snap, image: fix `snap download` and `snap prepare-image` running as user [13:51] zyga, let's not bother with EPEL for now [13:52] Son_Goku: ok [13:52] but I think it'd be a good idea to start testing epel builds with COPR [13:52] I think that EL7 may not require the SELinux policy module right now [13:52] Son_Goku: package requested [13:52] Son_Goku: good idea [13:52] yes, so my steps are: 1) I boot a normal ubuntu desktop 16.04 on the stick 2) download and then unxz -c ubuntu-core-16-amd64-rc2.img.xz | sudo dd of=/dev/mmcblk0 3) sync 4) reboot. -> boot starts OK then gets stuck at this point. [13:54] tptr, right, dd to the USB key instead and boot off the os thats on theer, see if that works, then we have proof that it is the missing mmc driver [13:54] mvo on hols? [13:54] Son_Goku: after this lands we can finish snapd-glib [13:54] ok I do that now. thx [13:54] Son_Goku: should be a low hanging fruit by now [13:54] zyga, you can start it now, technically [13:54] snapd-glib has no direct dep on snapd [13:54] Son_Goku: ok, I'll start that then [13:54] at build time [13:55] snapd and snapd-glib can be submitted to bodhi in the same update along with updated snap-confine (if a new one arrives) [13:55] Son_Goku: .44 is good for now I think [13:55] Son_Goku: I'll do .45 without patches and then we fuse them into snapd [13:55] Son_Goku: (probably) [14:03] blech [14:03] Son_Goku: some updates for snapd-glib, I'll finish this in the evening as I'd like to test it from python [14:04] okay, cool [14:04] Son_Goku: what's about blech? [14:04] merging snap-confine into snapd [14:05] Son_Goku: you'll thank me after 3 releases where it's just painless :) [14:06] mixing golang and other things, by definition, is not painless [14:08] Son_Goku: we'll make the packaging work, then updates are painless, and so is development [14:08] Son_Goku: especailly for things like selinux integration, one branch, one CI, one result [14:09] travis sucks, though :/ [14:09] Son_Goku: spread! [14:09] :-) [14:09] mugh [14:09] ugh [14:09] that means figuring out lxd [14:09] Son_Goku: don't worry about it, I'll make it work brilliantly [14:10] Son_Goku: not really, you can use qemu or linode and linode will run fedora CI [14:10] unfortunately, no one has packaged lxd in Fedora :/ [14:10] so local spread things with containers don't work [14:11] Son_Goku: I think initilly kvm will be much much better [14:12] we have libvirt/KVM and systemd-nspawn [14:12] and of course, lxc 2.0 itself [14:12] and rkt too [14:12] and of course docker [14:13] but, bleh on docker [14:13] was store updated already to accept content interface users with the content property defined? [14:15] ogra_: bingo, intel compute stick is booting ubuntu-core-16-amd64-rc2.img.xz fine from the USB stick. [14:16] Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1390616 [14:17] ogra_: ping. Have you measured the boot time with cloud-init lately? [14:18] tptr, ok, i'm spinning new daily images, i'll ping you once they are ready (30min or so) they should have the fix [14:18] elopio, i didnt really care for cloud-init since we disabled it by default [14:18] ah, great, thx [14:21] ogra_: can you help me to make a gadget snap that enables cloudinit for rpi2? I [14:21] I'm going to look for the sources. It might be obvious. [14:21] elopio, i have not the slightest clue how the cloud.cfg needs to look like [14:22] the gadget side is easy though, iirc you just need to include it in the toplevel dir of the gadget [14:22] but i dont know anything about the format [14:23] (with the requirement for a special gadget, i actually doubt that people will use cloud-init on realy hardware ... i.e. non-cloud images) [14:23] *real [14:24] thanks ogra_. I'll look for somebody who knows about it. I think this is for cloud people. [14:24] I mean, it's coming from the people attending the cloud sprint. [14:24] ah [14:24] well, mvo might know something about the cloud.cfg file [14:24]