| mup | PR snapd#2234 opened: static tests: add spell check <Created by elopio> <https://github.com/snapcore/snapd/pull/2234> | 00:21 |
|---|---|---|
| === deadk is now known as e | ||
| liuxg | elopio, ping | 01:39 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#879 opened: The latest icon definition is deprecated <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/879> | 02:02 |
| === chihchun_afk is now known as chihchun | ||
| liuxg | 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:00 |
| mup | PR snapd#2233 closed: docs: update the name of the command for the cross-build <Created by elopio> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2233> | 05:03 |
| pitti | ogra_: no holiday, but being stuck in cloud roadmap review sessions all day, laptop-less :) (yesterday) | 05:20 |
| pitti | 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 | 05:23 |
| mup | PR snapd#2235 opened: debian: wrap-and-sort <Created by zyga> <https://github.com/snapcore/snapd/pull/2235> | 07:04 |
| === mup_ is now known as mup | ||
| mup | PR snapd#2228 closed: interfaces/bulitin: allow fwupdmgr refresh on fwupd plug <Critical> <Created by timchen119> <Closed by timchen119> <https://github.com/snapcore/snapd/pull/2228> | 09:02 |
| mup | PR snapd#2236 opened: interfaces: add realsense interface <Created by swem> <https://github.com/snapcore/snapd/pull/2236> | 09:29 |
| mup | PR snapcraft#877 closed: Add new "source-commit" field for VCS sources <Created by stgraber> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/877> | 10:02 |
| Son_Goku | for the life of me, I can't figure out where the man page is generated from when running snap help --man | 10:07 |
| Son_Goku | niemeyer: ^ | 10:07 |
| niemeyer | Son_Goku: It's generated from the flag metadata in the code itself | 10:08 |
| Son_Goku | niemeyer, it says the man page is snap(1) rather than snap(8) | 10:09 |
| Son_Goku | I just want to fix that | 10:09 |
| Son_Goku | or have it fixed | 10:09 |
| Son_Goku | either way works | 10:09 |
| niemeyer | Ah, let me see where the code lives | 10:09 |
| Son_Goku | I tried diving into it yesterday and got lost in the wave of golang things ;) | 10:09 |
| Son_Goku | niemeyer, it's been a section 8 manpage for a while, but apparently the man page generation code still writes snap(1) | 10:12 |
| niemeyer | Son_Goku: Will be slightly trickier than it sounds: https://github.com/jessevdk/go-flags/blob/master/man.go#L179 | 10:14 |
| Son_Goku | eek | 10:14 |
| niemeyer | Son_Goku: Might be easier to patch it locally, if you want a quick fix | 10:15 |
| faenil | 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:15 |
| Son_Goku | yeah, I think I'm just going to patch the man page itself until that's figured out | 10:16 |
| faenil | but I'm not sure what that means. "This one?" | 10:16 |
| faenil | does it refer to the example above? | 10:16 |
| Son_Goku | 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 |
| niemeyer | Son_Goku: Both snap and dpkg are (1) in Ubuntu/Debian | 10:16 |
| faenil | (maybe it needs some rephrasing?) | 10:16 |
| niemeyer | (FWIW) | 10:16 |
| Son_Goku | snap is in section 8 | 10:17 |
| Son_Goku | niemeyer: https://github.com/snapcore/snapd/blob/master/debian/rules#L157 | 10:18 |
| Son_Goku | someone changed it a while back | 10:18 |
| niemeyer | Son_Goku: $ dpkg -L snapd | grep 'man[0-9]/snap' | 10:18 |
| niemeyer | /usr/share/man/man1/snap.1.gz | 10:18 |
| Son_Goku | wtf? | 10:18 |
| Son_Goku | but... https://github.com/snapcore/snapd/commit/d1bd21632f3bca781bb64cb6a62e099f7978658d | 10:18 |
| Son_Goku | I'm completely confused now | 10:19 |
| niemeyer | Son_Goku: We need to kill the debian/ directory really | 10:19 |
| Son_Goku | alright, I'll fix it in the spec for now | 10:19 |
| Son_Goku | I think does belong in 8, though | 10:19 |
| niemeyer | 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 |
| niemeyer | Son_Goku: Not any more than dpkg itself | 10:19 |
| Son_Goku | rpm and yum/dnf are in section 8 | 10:20 |
| Son_Goku | I'm not sure why dpkg isn't | 10:20 |
| niemeyer | Son_Goku: I think it's reasonable | 10:20 |
| niemeyer | Son_Goku: Users care about what is installed too | 10:20 |
| Son_Goku | apt is in section 8 as well | 10:20 |
| Son_Goku | as is aptitude and... synaptic?! | 10:21 |
| Son_Goku | synaptic has a man page...? | 10:21 |
| niemeyer | Son_Goku: But I won't bikeshed much on this one.. it's just a number really | 10:21 |
| Son_Goku | yeah, meh | 10:21 |
| Son_Goku | I'll just fix it to point to 1 for now | 10:21 |
| niemeyer | and a pretty irrelevant one at that | 10:21 |
| Son_Goku | I don't actually care, but the inconsistency annoyed me | 10:21 |
| niemeyer | Yeah | 10:21 |
| niemeyer | Having it in one is the easiest, given it's hardcoded in go-flags | 10:22 |
| Son_Goku | that's a weird and terrible thing to be hardcoded | 10:22 |
| Son_Goku | but whatever | 10:22 |
| mup | PR snapd#2235 closed: debian: wrap-and-sort <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2235> | 10:23 |
| Son_Goku | zyga: ping | 10:25 |
| Son_Goku | zyga: https://github.com/zyga/snapcore-fedora/pull/11 | 10:26 |
| mup | PR zyga/snapcore-fedora#11: Update SELinux subpackage commit and move snap.8 to snap.1 <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/11> | 10:26 |
| Son_Goku | I'm at the point where I don't want to keep hitting it with a hammer anymore | 10:26 |
| Son_Goku | the policy *should work* once niemeyer lands the change to stop downloading things into /tmp and download them in /var/lib/snapd/<foodir> | 10:26 |
| Son_Goku | for the curious, here's what the policy looks like now: https://gitlab.com/Conan_Kudo/snapcore-selinux/blob/master/snappy.te | 10:27 |
| Son_Goku | it could stand to have some cleanup, but I don't want to do that now | 10:28 |
| Son_Goku | zyga, please merge the pull request and then update the snapd review with it | 10:28 |
| Son_Goku | I want to approve it already... :/ | 10:28 |
| Son_Goku | that way the preset rules can make it into Fedora asap | 10:29 |
| Son_Goku | niemeyer, has the code landed for making it download in /var/lib/snapd/<foodir> yet? | 10:37 |
| niemeyer | Son_Goku: Not yet.. hopefully today | 10:37 |
| Son_Goku | cool | 10:37 |
| === dholbach_ is now known as dholbach | ||
| tptr | 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 |
| tptr | booting ubuntu-15.04-snappy-amd64-generic.img.xz goes fine on the same hardware. | 10:56 |
| tptr | I am wondering if it is known prob or should I report somewhere? | 10:58 |
| ogra_ | tptr, that is from a USB key ? | 11:00 |
| ogra_ | (or how do you boot ?) | 11:00 |
| tptr | 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:01 |
| mup | Bug #1638248 opened: No 'current' symlink for $SNAP_USER_DATA <Snappy:New> <https://launchpad.net/bugs/1638248> | 11:02 |
| tptr | 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 |
| tptr | ( tre instructions from https://developer.ubuntu.com/en/snappy/start/#try-x86 ) | 11:02 |
| ogra_ | tptr, if you dd directly to the USB key and boot from there, does it work ? | 11:10 |
| ogra_ | oh, wait | 11:10 |
| ogra_ | you downloaded 15.04 ... | 11:10 |
| tptr | this is what I do | 11:10 |
| tptr | with 15.04 it works fine | 11:10 |
| tptr | with 16.04/20160919/ubuntu-core-16-amd64.img.xz it gets stuk | 11:11 |
| ogra_ | well, 15.04 is pretty much EOL (within the next 4 weeks or so) ... | 11:11 |
| ogra_ | and completely different too (regarding the overall image design) | 11:12 |
| tptr | yes... | 11:12 |
| tptr | this is why I would love to switch to 16.04 as soon as I can | 11:12 |
| tptr | but I cannot boot it on this device. due to this problem. | 11:13 |
| ogra_ | well, try booting from the USB key | 11:14 |
| ogra_ | oh, wait ... you also downloaded the wrong image | 11:15 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ is waht you want | 11:15 |
| tptr | aaah ok. I will give this a try. thanks a bunch. | 11:17 |
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| zyga | slangasek: can we release snap-confine 1.0.44 into ubuntu? | 12:38 |
| zyga | slangasek: there's some SRU work that needs to happen for that | 12:39 |
| zyga | slangasek: https://bugs.launchpad.net/snap-confine/+milestone/1.0.44 | 12:39 |
| Son_Goku | zyga, can you please update the snapd review with the latest SRPM and spec | 12:41 |
| sree | hai | 12:41 |
| sree | i want to know about ubuntu mobile os | 12:41 |
| sree | can you help me | 12:42 |
| Son_Goku | sree, you should probably ask in #ubuntu | 12:42 |
| sree | okay | 12:42 |
| Son_Goku | zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825 | 12:43 |
| Son_Goku | zbyszek is waiting on my to approve the package so he can merge the presets in | 12:44 |
| Son_Goku | s/my/me/ | 12:44 |
| Son_Goku | zyga, technically, the selinux policy as-is isn't going to completely work with snapd 2.16 | 12:46 |
| Son_Goku | because of it downloading to /tmp instead of /var/lib/snapd | 12:46 |
| Son_Goku | 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:47 |
| femme | snapd is vulnerable to all of these currently, in some form: https://www.cs.arizona.edu/stork/packagemanagersecurity/otherattacks.html | 12:53 |
| Son_Goku | erm | 12:55 |
| niemeyer | femme: No, none of them, actually | 12:55 |
| Son_Goku | it shouldn't be | 12:55 |
| Son_Goku | the connection is secured between snapd and the Canonical store | 12:55 |
| Son_Goku | and the data is document signed and checksummed | 12:56 |
| Son_Goku | femme, the major Linux distributions today provide mechanisms to defeat those particular attacks | 12:57 |
| femme | 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:57 |
| niemeyer | femme: snapcraft is not snapd | 12:59 |
| femme | ok, my mistake then, snapcraft | 13:00 |
| Son_Goku | snapcraft has its own issues, sure | 13:00 |
| niemeyer | femme: This page is about apt and yum, not their build infrastructure | 13:00 |
| Son_Goku | it's also horribly out of date for apt and yum too | 13:00 |
| femme | niemeyer: doesn't matter | 13:00 |
| Son_Goku | both package managers have solved these issues a long time ago | 13:00 |
| femme | it's a research paper and they only solved the issues because of it... | 13:01 |
| niemeyer | femme: Of course it matters. | 13:01 |
| femme | niemeyer: how? | 13:01 |
| femme | 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 |
| niemeyer | 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 |
| niemeyer | built | 13:02 |
| Son_Goku | the way packages are built has a different set of issues | 13:02 |
| niemeyer | 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 |
| niemeyer | femme: So, sort of fundamental to the point | 13:02 |
| femme | niemeyer: it's about dependency management | 13:03 |
| Son_Goku | snap build infrastructure is quite weak, sure, but that's not necessarily the same as the snap runtime/install infrastructure | 13:03 |
| femme | So you're missing a fundamental point | 13:03 |
| niemeyer | femme: Exactly, and snapcraft is not about package management dependency | 13:03 |
| femme | niemeyer: then why does it include that functionality? | 13:03 |
| niemeyer | femme: This is the *build* system | 13:03 |
| Son_Goku | femme, snaps cannot do direct dependencies | 13:03 |
| niemeyer | femme: The tone of the conversation is also very unfriendly.. unnecessarily unfriendly | 13:03 |
| Son_Goku | they can indirect, capability oriented dependencies | 13:04 |
| Son_Goku | much coarser than package deps | 13:04 |
| niemeyer | femme: I appreciate the point you are trying to make, though.. it's just a bit misguided | 13:04 |
| femme | No, I think you either don't understand or you don't care if snapcraft users are targeted. | 13:04 |
| niemeyer | femme: You are very strongly making the wrong point, instead of kindly making the right one. | 13:05 |
| Son_Goku | femme, I agree that what you're saying is a problem | 13:05 |
| Son_Goku | but the issue is, the person you should be talking to isn't even here right now | 13:05 |
| femme | Son_Goku: I'll probably never talk to them thanks to people like niemeyer | 13:05 |
| * Son_Goku sighs | 13:06 | |
| mup | PR snapd#2237 opened: bugfix: use a .partial file in download to unbreak `snap download` as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2237> | 13:06 |
| femme | Just keep up with the pedantics, it's a build system as if it doesn't do dependency resolution in a vulnerable way | 13:06 |
| Son_Goku | that went well </sarcasm> | 13:08 |
| mhall119 | 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:09 |
| dholbach | can somebody reply to http://askubuntu.com/questions/842792/unable-to-install-ubuntu-snap-in-16-04-lts? | 13:10 |
| niemeyer | Yes, security is pedantic femme. | 13:10 |
| jdstrand | 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 |
| niemeyer | I've followed up up privately. | 13:11 |
| zyga | Son_Goku: yes, I'll do it shortly | 13:11 |
| jdstrand | kalikiana_: aiui, they have todos to improve that, I think using acls | 13:11 |
| zyga | Son_Goku: understood | 13:11 |
| jdstrand | hey niemeyer and zyga :) | 13:11 |
| jdstrand | kalikiana_: ah, I see stgraber already anwswered you | 13:12 |
| mhall119 | zyga: niemeyer: do we have documentation somewhere about the configuration hook and how to use it? | 13:13 |
| niemeyer | mhall119: I'm working on that.. will finish as soon as the holy image is out. | 13:14 |
| zyga | jdstrand: hey | 13:14 |
| mhall119 | thanks niemeyer, I think that will solve couchdb's needs | 13:14 |
| femme | < 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 |
| femme | Yeah, *my attitude* is the problem. It's not like I immediately said I was mistaken and in fact meant snapcraft, right? | 13:15 |
| mhall119 | niemeyer: are there any security restrictions on who can call "snap set"? | 13:16 |
| femme | But I'm the one that made it hard to start a conversation, sure. | 13:16 |
| niemeyer | mhall119: Yeah, root only for now. | 13:16 |
| mhall119 | cool | 13:16 |
| niemeyer | mhall119: Sorry, more clearly: auth-only for now | 13:16 |
| niemeyer | mhall119: As in, works through the API | 13:16 |
| mhall119 | so, same auth requirement as was needed to install it in the first place? | 13:17 |
| zyga | jdstrand: is everything okay? | 13:17 |
| niemeyer | 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 |
| niemeyer | femme: There will be an actual server handling those things, with proper auth, etc | 13:17 |
| femme | 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:18 |
| jdstrand | zyga: yes, I got back and just wanted to say 'hi' :) | 13:19 |
| zyga | jdstrand: ah, great to have you back :) | 13:19 |
| jdstrand | thanks! :) | 13:19 |
| femme | the 'fundamental point' you were talking about, was one you were and still are missing | 13:19 |
| niemeyer | femme: That's what I've been trying to do. Sorry if I failed at that. | 13:19 |
| mhall119 | femme: niemeyer: we're all just trying to get stuff done, there's nothing personal about it, it's just code. | 13:20 |
| Son_Goku | zyga, I think mvo's PR here is the one that fixes this: https://github.com/snapcore/snapd/pull/2237 | 13:21 |
| mup | PR snapd#2237: bugfix: use a .partial file in download to unbreak `snap download` as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2237> | 13:21 |
| femme | I don't like being talked over by people that think they know more than you. | 13:21 |
| mhall119 | 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:21 |
| mhall119 | 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 |
| zyga | Son_Goku: he's sitting right besides me, I'll update the SRPM when the branch lands | 13:22 |
| Son_Goku | zyga, did you go ahead and make the SRPM and spec update to the bugzilla ticket, though? | 13:22 |
| Son_Goku | I'd like to go ahead and give it my stamp of approval | 13:22 |
| femme | 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 |
| zyga | Son_Goku: ah, ok, I'll do that now | 13:23 |
| zyga | Son_Goku: thank you for all the contributions, this is fantastic milestone! | 13:23 |
| mhall119 | zyga: Son_Goku: is this the contribution I think it is? | 13:23 |
| zyga | femme: tor can use snaps, you don't have to use the parts wiki | 13:23 |
| zyga | mhall119: yes | 13:23 |
| mhall119 | \o/ | 13:23 |
| Son_Goku | mhall119, yes, it is :D | 13:23 |
| mhall119 | Son_Goku: you're going to blog about it somewhere, right? right? | 13:23 |
| Son_Goku | mhall119, yes, yes | 13:24 |
| zyga | mhall119: I think many people will :) | 13:24 |
| Son_Goku | 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 | |
| niemeyer | femme: you don't even have to use snapcraft, strictly speaking | 13:24 |
| zyga | femme: you can very precisely build a snap manually, controlling all the bits | 13:24 |
| zyga | femme: and publish gpg signatures and anything else you want for cross-checks | 13:25 |
| niemeyer | 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 |
| femme | We need reproducible builds so I think that's the only way we can go about it. | 13:25 |
| zyga | femme: and you can | 13:25 |
| zyga | femme: snap is a fancy zip file | 13:25 |
| zyga | femme: just build the content | 13:25 |
| Son_Goku | ehhh | 13:25 |
| Son_Goku | it's not *quite* that | 13:25 |
| mhall119 | a fancy squashfs file | 13:25 |
| mhall119 | :) | 13:25 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2238 opened: many: fix download as user with nice partial filename <Created by mvo5> <https://github.com/snapcore/snapd/pull/2238> | 13:26 |
| niemeyer | femme: This should give you ideas: https://github.com/snapcore/snapd/tree/master/tests/lib/snapbuild | 13:26 |
| qengho | Incidentally, I have a branch of snapcraft that (almost) takes a source-signed-by: [ 0xGPG, 0xGPG ] argument in snapcraft yaml parts. | 13:27 |
| niemeyer | femme: It takes the final content of a snap and simply bundleds it into the .snap file | 13:27 |
| niemeyer | bundles | 13:27 |
| qengho | I haven't published because GPG is kind of dumb, take ALL instead of ANY OF in its verification step. | 13:27 |
| Son_Goku | and I've written an independent snap build implementation for core snaps | 13:28 |
| Son_Goku | https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap | 13:28 |
| Son_Goku | it wouldn't take much for me to be able to do snapcraft-like things | 13:28 |
| niemeyer | 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 |
| niemeyer | femme: It doesn't actually build anything, though.. it merely packs it up | 13:29 |
| mhall119 | niemeyer: are there any plans for an install-time hook? | 13:30 |
| niemeyer | 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 |
| mhall119 | it would be useful to bootstrap stuff in $SNAP_DATA or $SNAP_COMMON | 13:30 |
| niemeyer | femme: And there are two signatures on it, one by the store, one by the snap publisher | 13:30 |
| niemeyer | mhall119: configure! | 13:31 |
| mhall119 | niemeyer: does that get called at install time? Or only when a user calls snap set? | 13:31 |
| niemeyer | mhall119: It's called at install time | 13:31 |
| niemeyer | mhall119: and on every refresh | 13:31 |
| Son_Goku | zyga, my VM is a complete mess now :) | 13:31 |
| mhall119 | oh, perfect! Are docs coming for that soon too? | 13:31 |
| niemeyer | mhall119: Wait, I need to confirm the second part of it | 13:32 |
| niemeyer | mhall119: Definitely at install time | 13:32 |
| mhall119 | that's the main one for me | 13:32 |
| niemeyer | mhall119: Yeah, it's part of that doc wiki | 13:32 |
| zyga | Son_Goku: build in progress | 13:33 |
| zyga | 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 |
| Son_Goku | uhh | 13:36 |
| femme | niemeyer: enabling HPKP on wiki.ubuntu.com and snapcraft would go a long way | 13:36 |
| Son_Goku | you messed up | 13:36 |
| niemeyer | femme: We'll drop that entirely, and have a proper database for that content, with proper authentication, etc | 13:36 |
| Son_Goku | or rather I did | 13:37 |
| Son_Goku | zyga: https://github.com/zyga/snapcore-fedora/blob/master/snapd.spec#L172 | 13:38 |
| Son_Goku | that needs to be man1 | 13:38 |
| zyga | Son_Goku: right | 13:38 |
| zyga | Son_Goku: fixing, thanks | 13:38 |
| Son_Goku | np | 13:38 |
| niemeyer | 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:38 |
| niemeyer | femme: We should also have a --no-remote sort of flag | 13:39 |
| niemeyer | femme: Which forces snapcraft to operate only on local parts | 13:39 |
| niemeyer | I'll talk to Sergio about this | 13:39 |
| niemeyer | serguisens is our snapcraft master | 13:39 |
| Son_Goku | niemeyer, that would be handy for integration of snapcraft into something like Koji | 13:40 |
| Son_Goku | or OBS | 13:40 |
| zyga | Son_Goku: uploaded | 13:41 |
| Son_Goku | 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:42 | |
| zyga | Son_Goku: bug updated | 13:43 |
| zyga | Son_Goku: really? | 13:43 |
| zyga | Son_Goku: yes, both | 13:43 |
| Son_Goku | https://fedorapeople.org/~zyga/snapd.spec | 13:43 |
| Son_Goku | shows me snapd 2.12 | 13:43 |
| mup | PR snapd#2238 closed: many: fix download as user with nice partial filename <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2238> | 13:43 |
| Son_Goku | and nothing here https://bugzilla.redhat.com/show_bug.cgi?id=1367825 | 13:43 |
| zyga | oh, sorry wrong directory | 13:43 |
| zyga | and bug was updated separately now | 13:44 |
| zyga | Son_Goku: check now please | 13:44 |
| Son_Goku | there we go | 13:44 |
| * zyga hugs Son_Goku :) | 13:44 | |
| tptr | @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 |
| nothal | tptr: No such command! | 13:47 |
| tptr | @ogra_ :-) | 13:47 |
| nothal | tptr: No such command! | 13:47 |
| zyga | Son_Goku: ok, we just need that patch and we're good | 13:47 |
| ogra_ | tptr, thats a red herring (i just rolled a new kernel snap that suppresses that warning) | 13:48 |
| Son_Goku | zyga: https://bugzilla.redhat.com/show_bug.cgi?id=1367825#c23 | 13:48 |
| ogra_ | tptr, it shouldnt influence your boot process though ... | 13:48 |
| zyga | Son_Goku: going to create the package now | 13:49 |
| Son_Goku | :D | 13:49 |
| ogra_ | tptr, did you try booting directky from usb stick ? | 13:49 |
| tptr | next line: findfs: unable to resolve 'LABEL=writable' | 13:49 |
| ogra_ | right, thats the issue ... but also not the cause | 13:49 |
| ogra_ | you said something about mmc | 13:49 |
| ogra_ | i assume the missing mmc/SD card driver in the initrd is your issue | 13:49 |
| Son_Goku | zyga, so far, this was the worst part: https://gitlab.com/Conan_Kudo/snapcore-selinux/commit/6331fd4a058271b0246714bc6746ab1e7ce2aa09 :( | 13:50 |
| ogra_ | try booting off USB, if that actually worksd we know for sure | 13:50 |
| zyga | Son_Goku: should I ask for epel as well? | 13:50 |
| zyga | Son_Goku: nice, I need to learn this better | 13:51 |
| mup | PR snapd#2239 opened: snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <https://github.com/snapcore/snapd/pull/2239> | 13:51 |
| Son_Goku | zyga, let's not bother with EPEL for now | 13:51 |
| zyga | Son_Goku: ok | 13:52 |
| Son_Goku | but I think it'd be a good idea to start testing epel builds with COPR | 13:52 |
| Son_Goku | I think that EL7 may not require the SELinux policy module right now | 13:52 |
| zyga | Son_Goku: package requested | 13:52 |
| zyga | Son_Goku: good idea | 13:52 |
| tptr | 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:52 |
| ogra_ | 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 |
| Mirv | mvo on hols? | 13:54 |
| zyga | Son_Goku: after this lands we can finish snapd-glib | 13:54 |
| tptr | ok I do that now. thx | 13:54 |
| zyga | Son_Goku: should be a low hanging fruit by now | 13:54 |
| Son_Goku | zyga, you can start it now, technically | 13:54 |
| Son_Goku | snapd-glib has no direct dep on snapd | 13:54 |
| zyga | Son_Goku: ok, I'll start that then | 13:54 |
| Son_Goku | at build time | 13:54 |
| Son_Goku | 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 |
| zyga | Son_Goku: .44 is good for now I think | 13:55 |
| zyga | Son_Goku: I'll do .45 without patches and then we fuse them into snapd | 13:55 |
| zyga | Son_Goku: (probably) | 13:55 |
| Son_Goku | blech | 14:03 |
| zyga | Son_Goku: some updates for snapd-glib, I'll finish this in the evening as I'd like to test it from python | 14:03 |
| Son_Goku | okay, cool | 14:04 |
| zyga | Son_Goku: what's about blech? | 14:04 |
| Son_Goku | merging snap-confine into snapd | 14:04 |
| zyga | Son_Goku: you'll thank me after 3 releases where it's just painless :) | 14:05 |
| Son_Goku | mixing golang and other things, by definition, is not painless | 14:06 |
| zyga | Son_Goku: we'll make the packaging work, then updates are painless, and so is development | 14:08 |
| zyga | Son_Goku: especailly for things like selinux integration, one branch, one CI, one result | 14:08 |
| Son_Goku | travis sucks, though :/ | 14:09 |
| zyga | Son_Goku: spread! | 14:09 |
| zyga | :-) | 14:09 |
| Son_Goku | mugh | 14:09 |
| Son_Goku | ugh | 14:09 |
| Son_Goku | that means figuring out lxd | 14:09 |
| zyga | Son_Goku: don't worry about it, I'll make it work brilliantly | 14:09 |
| zyga | Son_Goku: not really, you can use qemu or linode and linode will run fedora CI | 14:10 |
| Son_Goku | unfortunately, no one has packaged lxd in Fedora :/ | 14:10 |
| Son_Goku | so local spread things with containers don't work | 14:10 |
| zyga | Son_Goku: I think initilly kvm will be much much better | 14:11 |
| Son_Goku | we have libvirt/KVM and systemd-nspawn | 14:12 |
| Son_Goku | and of course, lxc 2.0 itself | 14:12 |
| Son_Goku | and rkt too | 14:12 |
| Son_Goku | and of course docker | 14:12 |
| Son_Goku | but, bleh on docker | 14:13 |
| Mirv | was store updated already to accept content interface users with the content property defined? | 14:13 |
| tptr | ogra_: bingo, intel compute stick is booting ubuntu-core-16-amd64-rc2.img.xz fine from the USB stick. | 14:15 |
| zyga | Pharaoh_Atem: https://bugzilla.redhat.com/show_bug.cgi?id=1390616 | 14:16 |
| elopio | ogra_: ping. Have you measured the boot time with cloud-init lately? | 14:17 |
| ogra_ | 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 |
| ogra_ | elopio, i didnt really care for cloud-init since we disabled it by default | 14:18 |
| tptr | ah, great, thx | 14:18 |
| elopio | ogra_: can you help me to make a gadget snap that enables cloudinit for rpi2? I | 14:21 |
| elopio | I'm going to look for the sources. It might be obvious. | 14:21 |
| ogra_ | elopio, i have not the slightest clue how the cloud.cfg needs to look like | 14:21 |
| ogra_ | the gadget side is easy though, iirc you just need to include it in the toplevel dir of the gadget | 14:22 |
| ogra_ | but i dont know anything about the format | 14:22 |
| ogra_ | (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 |
| ogra_ | *real | 14:23 |
| elopio | thanks ogra_. I'll look for somebody who knows about it. I think this is for cloud people. | 14:24 |
| elopio | I mean, it's coming from the people attending the cloud sprint. | 14:24 |
| ogra_ | ah | 14:24 |
| ogra_ | well, mvo might know something about the cloud.cfg file | 14:24 |
| ogra_ | but he isnt on irc | 14:24 |
| ogra_ | (not sure if he took off the week, i see commits from him on github :P ) | 14:25 |
| elopio | ogra_: yes, I'm talking to him on telegram and passing the messages through to you :) | 14:25 |
| ogra_ | lol | 14:25 |
| ogra_ | is he to shy for irc ? :) | 14:25 |
| elopio | ogra_: irc doesn't have gifs, it's doomed :p | 14:27 |
| elopio | ogra_: hey you might like this one: https://github.com/matrix-org/synapse/pull/1158 | 14:29 |
| mup | PR matrix-org/synapse#1158: Add the packaging metadata to build the synapse snap <Created by elopio> <https://github.com/matrix-org/synapse/pull/1158> | 14:29 |
| elopio | peer to peer, encrypted, with a bridge to irc. | 14:29 |
| ogra_ | elopio, lol ... that name reminds me of https://en.wikipedia.org/wiki/Antitrust_(film) | 14:30 |
| ogra_ | nice one though | 14:32 |
| elopio | that sounds like a terrible film... so I'll watch it during lunch. | 14:34 |
| ogra_ | elopio, dude ! you dont know it ? it is the movie where gnome made its first appearnce ever in a movie :) | 14:35 |
| ogra_ | tptr, try the amd64 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 14:40 |
| tptr | ok | 14:40 |
| ogra_ | that should have all needed drivers included now | 14:40 |
| elopio | rharper: can you help me generating an image with cloud-init for rpi2? | 14:44 |
| Croepha | is there a standard way to include the contents of the linux-firmware debian package in your kernel snap? | 14:47 |
| mup | PR snapd#2240 opened: interfaces: network-manager: give slot full read-write access to /run… <Created by morphis> <https://github.com/snapcore/snapd/pull/2240> | 14:48 |
| Croepha | will stage-packages actually just work? | 14:48 |
| kyrofa | elopio, great film! You'll love it! | 14:48 |
| elopio | kyrofa: we'll see. | 14:53 |
| kyrofa | elopio, let us know | 14:54 |
| Croepha | the only reason I ask, is because every time i make a change to the kernel snapcraft.yaml, it takes like 30 minutes to build the snap... | 14:55 |
| Pharaoh_Atem | zyga: grabbed the review and left a comment already | 14:58 |
| Pharaoh_Atem | also requested comaintainership for snapd in pkgdb: https://admin.fedoraproject.org/pkgdb/package/rpms/snapd/ | 14:59 |
| tptr | ogra_: intel stick is booting your image ok from the internal mmc. yey. :-) | 15:06 |
| tptr | thanks a lot for the help | 15:11 |
| mup | PR snapcraft#880 opened: Remove license concepts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/880> | 15:11 |
| ogra_ | tptr, thanks for verifying the fix ;) | 15:12 |
| mup | PR snapcraft#881 opened: Catkin plugin: Python nodes require gcc/g++ too <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/881> | 15:29 |
| mup | Bug #1638320 opened: remove core snap via snapweb fails but it still removes from the web interface <Snappy:New> <https://launchpad.net/bugs/1638320> | 15:36 |
| Pharaoh_Atem | zyga: snapd-glib approved | 15:42 |
| zyga | Pharaoh_Atem: thanks, I'll do the rest :) | 15:44 |
| mup | PR snapd#2240 closed: interfaces: network-manager: give slot full read-write access to /run… <Created by morphis> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2240> | 15:44 |
| mup | PR snapcraft#788 closed: support npm install from npm-shrinkwrap.json in nodejs plugin <Created by mvayngrib> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/788> | 15:44 |
| Croepha | tptr: is your intel compute stick working with wifi/hdmi audio/ and direct rendering? | 15:45 |
| Croepha | i was using the linuxium sources to get those features, had to roll my own kernel | 15:45 |
| tptr | I am using it only for some IoT usecase. no graphics... model is STK1A32SC | 16:00 |
| tptr | just struggling to make docker available to my own snap somehow... | 16:01 |
| tptr | previously I used it with 15.04 snappy image. there wifi was working fine too. | 16:02 |
| tptr | so far all looks good with the 16.04 too... using the above image from ogra_ | 16:03 |
| === devil is now known as Guest16096 | ||
| === JanC_ is now known as JanC | ||
| thresh | hi. how do I go about the autotools-based project where I need to build something before launching actual configure/make/makeinstall? | 16:28 |
| Pharaoh_Atem | zyga: there's no point in submitted snapd-glib yet | 16:29 |
| Pharaoh_Atem | you don't have snapd with it | 16:29 |
| Pharaoh_Atem | it's completely useless without it | 16:29 |
| kyrofa | thresh, you mean you need to run a command before configure? | 16:30 |
| thresh | kyrofa, exactly, yeah. | 16:30 |
| thresh | and the command is not autoreconf :) | 16:30 |
| kyrofa | thresh, you'll need to create a plugin within your project for snapcraft to use | 16:31 |
| kyrofa | thresh, are you familiar with that at all? | 16:31 |
| zyga | Pharaoh_Atem: nobody can download and test it | 16:32 |
| zyga | Pharaoh_Atem: we'll get snapd in in a few hours | 16:32 |
| zyga | Pharaoh_Atem: did you try running any snaps? | 16:33 |
| Pharaoh_Atem | once built in koji, people can do that | 16:33 |
| zyga | Pharaoh_Atem: with some workaround for /tmp? | 16:33 |
| zyga | Pharaoh_Atem: ook | 16:33 |
| thresh | kyrofa, I'm not. I'm actually trying to make VLC (http://git.videolan.org/?p=vlc.git;a=tree;f=extras/package/snap) use the contribs (self-built deps) instead of Ubuntu ones, which are outdated (only Zesty seems to have needed ffmpeg). | 16:33 |
| Pharaoh_Atem | I can write a temporary patch to add support for read/write /tmp in the selinux policy | 16:33 |
| thresh | kyrofa, any tips on how to do that? Appreciate it. | 16:34 |
| zyga | Pharaoh_Atem: please do | 16:34 |
| zyga | Pharaoh_Atem: let's check that it works | 16:34 |
| zyga | Pharaoh_Atem: and undo it later tonight | 16:34 |
| kyrofa | thresh, of course, let me grab some docs for you | 16:34 |
| kyrofa | thresh, here's a high-level example: https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md | 16:35 |
| zyga | Pharaoh_Atem: so the package in mater is good, we'd have to rev the policy and later on rev both when it's ready | 16:35 |
| kyrofa | thresh, yours might look a little more similar to this one: https://github.com/nextcloud/nextcloud-snap/blob/master/parts/plugins/x-redis.py | 16:36 |
| kyrofa | thresh, that one needed to run `make install PREFIX=` instead of `make install DESTDIR=` (the make plugin now supports this, but it didn't at the time) | 16:37 |
| kyrofa | thresh, so you can almost copy this, inherit from the autotools plugin, and run the commands you need | 16:37 |
| thresh | kyrofa, right, seems easy! Thanks! | 16:37 |
| kyrofa | thresh, any time :) | 16:37 |
| kyrofa | Let me know if you run into problems | 16:38 |
| mup | Bug #1638334 opened: snap install not properly generating ConnectedSlot policy when auto-connecting via snap-declaration-allowed connection <Snappy:New> <https://launchpad.net/bugs/1638334> | 16:40 |
| Pharaoh_Atem | zyga: I've added a patch for it | 16:50 |
| Pharaoh_Atem | you can go ahead and build for all targets and merge it into the update that includes snap-confine and snapd-glib | 16:51 |
| zyga | Pharaoh_Atem: I don't know how to merge updates in bodhi | 16:53 |
| Pharaoh_Atem | it's super easy | 16:53 |
| zyga | Pharaoh_Atem: did you test it in any way? any hello snaps running? | 16:53 |
| Pharaoh_Atem | I have not, as I'm at work and it's tricky for me to do that | 16:53 |
| sborovkov | Hello. Anyone knows how I can trigger first boot again on classic? We are creating image from classic, need it to repartition free space when users use the resulting image | 16:53 |
| zyga | Pharaoh_Atem: ok, Ill check | 16:53 |
| Pharaoh_Atem | cool | 16:53 |
| zyga | Pharaoh_Atem: FYI: https://github.com/zyga/snapcore-fedora/issues/4 | 16:53 |
| zyga | Pharaoh_Atem: I think we need to try it on a cloud variant too | 16:54 |
| zyga | Pharaoh_Atem: but we can do that after trying workstating | 16:54 |
| zyga | workstation* | 16:54 |
| zyga | Pharaoh_Atem: thank you again :) building now | 16:55 |
| Pharaoh_Atem | I know what's wrong with the cloud thing | 16:56 |
| Pharaoh_Atem | mismatched kernel packages | 16:56 |
| zyga | Pharaoh_Atem: can we somehow fix that? | 16:57 |
| zyga | Pharaoh_Atem: something we can improve in fedora? | 16:57 |
| Pharaoh_Atem | not really, people just need to make sure they install kernel-modules matching their kernel, or get things upgraded properly | 16:57 |
| zyga | Pharaoh_Atem: or in the dependencies in snapd.spec? | 16:57 |
| * Pharaoh_Atem shrugs | 16:57 | |
| Pharaoh_Atem | the kernel package is multiversioned | 16:57 |
| zyga | Pharaoh_Atem: well, we install kernel-modules via a dependency | 16:57 |
| zyga | Pharaoh_Atem: hmm hmm hmm | 16:57 |
| Pharaoh_Atem | there has been talk of making a DNF plugin to handle this by providing additional, environment specific hints | 16:58 |
| zyga | Pharaoh_Atem: ok, at least you've identified the issue correctly, thanks | 16:58 |
| Pharaoh_Atem | see this thread (relevant in our case as well): http://lists.rpm.org/pipermail/rpm-ecosystem/2016-October/000430.html | 16:58 |
| zyga | looking | 16:59 |
| thresh | kyrofa, looks like I got it working, many thanks! | 17:00 |
| kyrofa | thresh, excellent! | 17:00 |
| zyga | Pharaoh_Atem: maybe those should be snaps? :) | 17:02 |
| Pharaoh_Atem | ugh | 17:03 |
| Pharaoh_Atem | when snapcraft and snapd are properly decoupled from Ubuntu so that a Fedora-built Snappy Core could be done, we'll talk then | 17:03 |
| zyga | Pharaoh_Atem: very soon I hope :) | 17:03 |
| zyga | Pharaoh_Atem: one more thing | 17:09 |
| zyga | Pharaoh_Atem: lis 01 19:08:45 fedora24 setroubleshoot[51485]: SELinux is preventing snapd from execute access on the file unsquashfs. For complete SELinux messages. run sealert -l 116eed8f-b15a-4a60-9532-3268ba616497 | 17:09 |
| Pharaoh_Atem | mrgh | 17:09 |
| Pharaoh_Atem | I thought I got all of those | 17:09 |
| zyga | Pharaoh_Atem: but it download now | 17:09 |
| zyga | Pharaoh_Atem: we're so so close now | 17:09 |
| Pharaoh_Atem | I'm revoking your bodhi updates | 17:09 |
| zyga | Pharaoh_Atem: OK | 17:10 |
| zyga | Pharaoh_Atem: is that something we can fix quickly today? | 17:14 |
| Pharaoh_Atem | yes, but I need to set up a fresh VM | 17:15 |
| Pharaoh_Atem | I have to add more rules... :/ | 17:15 |
| AlbertA | question: if I declare a package through stage-packages is there a way to only include a subset of files from that package? | 17:23 |
| Pharaoh_Atem | purge the files afterward? | 17:24 |
| AlbertA | for example I've tried this: http://pastebin.ubuntu.com/23412484/ | 17:24 |
| zyga | Pharaoh_Atem: purge? | 17:24 |
| zyga | Pharaoh_Atem: ah, sorry :) | 17:24 |
| AlbertA | but I get "[Errno 2] No such file or directory: '/home/alberto/source/mir-demos-snap/stage/usr/share/doc-base'" during priming | 17:24 |
| AlbertA | Pharaoh_Atem: purge? how though? | 17:28 |
| === Guest16096 is now known as devil_ | ||
| sborovkov | Hello. Anyone knows how I can trigger first boot again on classic? We are creating image from classic, need it to repartition free space when users flash the resulting image. | 18:07 |
| ogra_ | sborovkov, thats not in firstboot but inside the special core initrd (you need to resize before anything gets mounted if you dont want to risk corruption) | 18:11 |
| ogra_ | you wont get it on classic | 18:11 |
| mup | PR snapd#2241 opened: overlord/state: introduce state lanes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2241> | 18:11 |
| ogra_ | (without hacking your own resize initrd together) | 18:12 |
| mup | PR snapd#2242 opened: tests: do not use hello-world in our tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2242> | 18:17 |
| pmcgowan | ogra_, if my dragonboard is rebooting itself that means I got a new kernel? | 18:30 |
| sborovkov | ogra_: oh ok, that's unfortunate | 18:33 |
| mup | PR snapcraft#882 opened: Python plugin: remove pip packages when cleaning pull <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/882> | 18:47 |
| kyrofa | pmcgowan, either a new kernel or a new core | 18:54 |
| pmcgowan | kyrofa, ack thanks | 18:56 |
| mterry | How do I unpack a snap, so I can quick edit and repack it? | 19:08 |
| mterry | I thought it used to be a command under 'snap', but don't see it any longer | 19:08 |
| === JanC_ is now known as JanC | ||
| kyrofa | mterry, you mean snap try? | 19:56 |
| kyrofa | mterry, it doesn't quite do that, but it allows you to edit it while mounted rather than going all the way to creating the squashfs | 19:56 |
| === robert_ancell_ is now known as robert_ancell | ||
| mup | PR snapd#2227 closed: overlord/snapstate: add dynamic snapdX.Y assumes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2227> | 20:22 |
| mup | PR snapd#2232 closed: many: fix incorrect security files generation on undo <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2232> | 20:23 |
| mup | PR snapcraft#882 closed: Python plugin: remove pip packages when cleaning pull <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/882> | 20:41 |
| ogra_ | pmcgowan, snap changes (and snap change $changenumber) will tell you ;) | 20:45 |
| mup | PR snapd#2243 opened: overlord/ifacestate: add unit tests for undo of setup-snap-security <Created by zyga> <https://github.com/snapcore/snapd/pull/2243> | 20:45 |
| pmcgowan | ogra_, I see it Update kernel and core snap revisions | 20:46 |
| ogra_ | well, then it eventually reboots :) | 20:46 |
| ogra_ | the changes should have timestamps so you can see if they match the reboot | 20:46 |
| pmcgowan | yeah it says it requested it | 20:48 |
| Pharaoh_Atem | mhall119 & zyga: the presets have been merged into fedora-release for f24, f25, and rawhide/f26 | 21:05 |
| Pharaoh_Atem | Fedora 25 final will be the first release of Fedora where the installation of snapd will automatically activate the socket | 21:06 |
| Pharaoh_Atem | so that "snap install" will Just Work(TM) | 21:06 |
| zyga | Pharaoh_Atem: :-) | 21:11 |
| Pharaoh_Atem | and snap install hello threw no denials related to the policy :) | 21:12 |
| mup | PR snapd#2239 closed: snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2239> | 21:32 |
| mup | PR snapd#2229 closed: interfaces/sytemd: enable/disable generated service units <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2229> | 21:34 |
| mup | PR snapd#2244 opened: snapstae: use lanes when building a "refresh-many" change <Created by mvo5> <https://github.com/snapcore/snapd/pull/2244> | 21:38 |
| mup | PR snapd#2224 closed: overlord/snapstate: update ux around explicit refresh of reverted, an… <Critical> <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2224> | 21:46 |
| mup | PR snapcraft#883 opened: python plugin: wheel and install in the proper order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/883> | 21:56 |
| mup | PR snapd#2241 closed: overlord/state: introduce state lanes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2241> | 21:57 |
| mup | PR snapd#2245 opened: overlord/state: marshaling tests for lanes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2245> | 22:12 |
| mup | PR snapd#2244 closed: snapstate: use lanes when building a "refresh-many" change <Critical> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2244> | 22:43 |
| zyga | Pharaoh_Atem: around? | 22:49 |
| mup | Bug #1638405 opened: libunity not added to LD_LIBRARY_PATH <Snappy:New> <https://launchpad.net/bugs/1638405> | 23:00 |
| mup | PR snapd#2245 closed: overlord/state: marshaling tests for lanes <Critical> <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2245> | 23:02 |
| mup | Bug #1638405 changed: libunity not added to LD_LIBRARY_PATH <Snapcraft:New> <Snappy:Invalid> <https://launchpad.net/bugs/1638405> | 23:03 |
| mup | PR snapd#2213 closed: tests: skip tests that use expect when expect is not working (like on ppc64el) <Critical> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2213> | 23:07 |
| * mwhudson wonders if the snapd autopkgtest just needs some zesty upload to ppa:snappy-dev/image | 23:08 | |
| mup | PR snapd#2237 closed: daemon,overlord,snap,tests: download to .partial in final dir <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2237> | 23:10 |
| mup | PR snapd#2243 closed: overlord/ifacestate: add unit tests for undo of setup-snap-security <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2243> | 23:13 |
| === JanC is now known as Guest13101 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2246 opened: releasing package snapd version 2.17 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2246> | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!