| === ikey is now known as ikey|zzz | ||
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| zyga-ubuntu | o/ | 05:21 |
|---|---|---|
| zyga-ubuntu | mvo: hey, how is 2.28 looking | 06:13 |
| mup | Bug #1718026 opened: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026> | 06:14 |
| mvo | zyga-ubuntu: looking good overall looks like some things need to go into it (3937) | 06:14 |
| mvo | zyga-ubuntu: did you figure out if it is this rule that triggered the issue? | 06:14 |
| zyga-ubuntu | mvo: no, I had to leave last night | 06:14 |
| zyga-ubuntu | mvo: jamie prepared a PR and some rationale | 06:14 |
| zyga-ubuntu | mvo: it looks good but fails testing | 06:14 |
| zyga-ubuntu | mvo: I will investigate that soon | 06:14 |
| mvo | zyga-ubuntu: testing is currently failing left and right but I have not looked into the why yet too | 06:15 |
| zyga-ubuntu | mvo: I wanted to highligh one bug https://bugs.launchpad.net/snappy/+bug/1718026 - this is fixed in master, I haven't checked if it is in 2.28 reease branch | 06:15 |
| mup | Bug #1718026: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026> | 06:15 |
| zyga-ubuntu | mvo: if we do another respin it would be worth to pick it up | 06:15 |
| zyga-ubuntu | mvo: specifically this patch should be in 2f55619677810a4872145b8ccbbe2bdc1ba364fa | 06:16 |
| mvo | zyga-ubuntu: aha, build fails in udev-support.c in a bunch of places - setup_dvices_cgroup | 06:16 |
| zyga-ubuntu | mvo: build fails? that's odd - in jamie's branch tests failed but the build was (supposedly) ok | 06:17 |
| * zyga-ubuntu looks again | 06:17 | |
| mvo | zyga-ubuntu: this is the opengl change | 06:18 |
| * mvo goes top-to-bottom | 06:18 | |
| zyga-ubuntu | aha, I was looking another pr | 06:19 |
| mvo | zyga-ubuntu: no worries, I fixed the issue in jamies | 06:19 |
| zyga-ubuntu | thank you | 06:20 |
| * zyga-ubuntu walks kids to school | 06:22 | |
| niemeyer | Early hellos | 06:23 |
| mvo | niemeyer: good morning, early is an understatement here :) | 06:24 |
| niemeyer | mvo: :P | 06:24 |
| mvo | zyga-ubuntu: btw what happend to the debian man-page bug, did it fix itself magically? | 06:24 |
| niemeyer | mvo: Just felt like one of those days.. | 06:24 |
| mvo | niemeyer: heh :) take it easy | 06:25 |
| zyga-ubuntu | mvo: probably | 06:26 |
| zyga-ubuntu | mvo: it broke a lot of sid :) | 06:26 |
| niemeyer | mvo: We had some issues with Debian preparing yesterday.. have you seen that? Just wondering if it went away already.. | 06:28 |
| niemeyer | mvo: Felt like an unrelated packaging bug | 06:29 |
| mvo | niemeyer: yeah, we ran into it yesterday, I'm just looking, its debian bug #876128, zyga-ubuntu has a workaround PR, I check the bugstatus and then we can apply the workaround if needed | 06:34 |
| mup | Bug #876128: Window too tall <amd64> <apport-bug> <oneiric> <running-unity> <thunderbird (Ubuntu):New> <https://launchpad.net/bugs/876128> | 06:34 |
| * mvo wonders if we should test against testing instead of unstable - this would prevent issues like this one | 06:36 | |
| niemeyer | mvo: Yeah, that might be a good idea | 06:39 |
| niemeyer | mvo: We'd still pick issues earlier but not be so close to the edge to face those unrelated bugs that will likely be fixed there | 06:40 |
| mvo | indeed | 06:40 |
| niemeyer | mvo: What are most devs using? | 06:40 |
| mvo | niemeyer: unstable I would say | 06:40 |
| niemeyer | mvo: Well.. then there's not much of a choice | 06:40 |
| mvo | niemeyer: we can pick 3932 with the workaround | 06:40 |
| niemeyer | mvo: We do want to know if people have a broken setup | 06:41 |
| mvo | niemeyer: right | 06:41 |
| niemeyer | mvo: 20h ago.. was it broken for other reasons? | 06:42 |
| ackk | niemeyer, thanks for the review | 06:44 |
| niemeyer | ackk: Heya | 06:45 |
| mvo | niemeyer: tsee the comment in the PR, the PR itself is fine, I think it should include a link to the debian bug so that we know when we can remove this again. I added that now | 06:45 |
| niemeyer | ackk: No problem, thanks for the PR.. hopefully the notes make sense? | 06:45 |
| niemeyer | mvo: Good idea | 06:46 |
| ackk | niemeyer, sure. fwiw the main reason I went for a string for the socket-mode is that using an int makes snacfraft write it out in decimal notation in the snap.yaml. I guess that can be somehow overridden (although even leaving as decimal works of course) | 06:46 |
| niemeyer | ackk: Yeah, and I think it's easy to fix that as well | 06:51 |
| niemeyer | ackk: I mean, forcing the notation on ints | 06:51 |
| niemeyer | ackk: Look at the second answer here: | 06:53 |
| niemeyer | ackk: https://stackoverflow.com/questions/18666816/using-python-to-dump-hexidecimals-into-yaml | 06:53 |
| niemeyer | Hey.. I know this guy... :P | 06:53 |
| ackk | heh | 06:57 |
| ackk | niemeyer, thanks for the pointers | 06:57 |
| mvo | zyga-ubuntu: do you know more about this udev regression that jamie talks about in the forum? I just tried to reproduce but no luck | 06:57 |
| niemeyer | ackk: The question about the actual structure of the syntax and its equivalence in the systems is more of an issue though, but we should discuss this in the forum | 07:00 |
| zyga-ubuntu | re | 07:07 |
| zyga-ubuntu | mvo: the udev issue can be reproduced on a artful (probably zesty as well) machine runnin wayland | 07:07 |
| zyga-ubuntu | mvo: for me it was sufficient to install gimp and then hit alt-f4 (note, just alt-f4, nothing more) | 07:07 |
| zyga-ubuntu | mvo: if you switch to VT4 you are affected | 07:08 |
| zyga-ubuntu | mvo: and subsequent ctrl-c will kill gnome-shell | 07:08 |
| mvo | zyga-ubuntu: sorry, I mean the other issue that jamie reported, https://forum.snapcraft.io/t/2-28-release-cycle-started/2026/13 | 07:08 |
| zyga-ubuntu | mvo: I wasn't aware of this, lookng | 07:08 |
| zyga-ubuntu | mvo: it looks like a busy day ahead, sorry for starting late btw, I wanted to have a walk as I'm mostly indoors lately | 07:10 |
| mvo | zyga-ubuntu: no worries | 07:10 |
| mvo | zyga-ubuntu: and +1 for walking, its good for productivity :) | 07:10 |
| mvo | (seriously!) | 07:10 |
| zyga-ubuntu | mvo: so first thing I checked if jamie's test snap has any apps in it | 07:11 |
| zyga-ubuntu | but it does... | 07:11 |
| zyga-ubuntu | (pretty fancy snap actually) | 07:11 |
| zyga-ubuntu | mvo: let me try to reproduce on master | 07:12 |
| zyga-ubuntu | mvo: so far I cannot think of anything | 07:12 |
| zyga-ubuntu | mvo: well, :) | 07:13 |
| zyga-ubuntu | mvo: maybe one (silly) explanation would be that jamie tried to disable the udev backend while exploring the wayland issue | 07:13 |
| zyga-ubuntu | mvo: and then didn't notice this when testing the other issue | 07:14 |
| zyga-ubuntu | mvo: also the udev code has not changed lately | 07:16 |
| zyga-ubuntu | mvo: last change is in March 2017 | 07:16 |
| zyga-ubuntu | mvo: so +1 on doubt it's real | 07:16 |
| mup | PR snapd#3777 closed: snap-repair: implement basic `snap-repair {list,show}` <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3777> | 07:32 |
| mvo | niemeyer: I was just looking over the spread PRs (got a ping about #30) and it seems like e.g. #33 is uncontroversial (maybe tweaking the error a bit) | 07:37 |
| mup | PR #33: small daemon tests cleanup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/33> | 07:37 |
| mup | PR snapd#3932 closed: spread: work around temporary packaging issue in debian sid <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3932> | 07:38 |
| niemeyer | mvo: Yeah, the queue needs some love.. let me check that one | 07:39 |
| zyga-ubuntu | mvo: btw, I found the debian bug tracker entry for manpages: 876128 | 07:40 |
| zyga-ubuntu | mvo: shall I add it? | 07:40 |
| niemeyer | zyga-ubuntu: mvo already did it | 07:41 |
| zyga-ubuntu | ah, thank you mvo :) | 07:41 |
| mvo | zyga-ubuntu: I added it already and merge the PR, sorry that I wasn't more explicit about it | 07:41 |
| zyga-ubuntu | I didn't notice | 07:41 |
| niemeyer | And merged it | 07:41 |
| niemeyer | zyga-ubuntu: He also fixed the apparmor summary/level PR | 07:42 |
| zyga-ubuntu | niemeyer: yes, we discussed that earlier so I knew about it | 07:42 |
| niemeyer | zyga-ubuntu: You'll need to get layouts working to compensate him ;) | 07:43 |
| zyga-ubuntu | working on that :) | 07:44 |
| pedronis | mvo: hi, where should we create the lock file for snap-repair run ? | 07:45 |
| niemeyer | zyga-ubuntu: That last comment from jdstrand is a bit eye opening.. we need to address review items made, or respond to the points when that's the case | 07:45 |
| niemeyer | zyga-ubuntu: But definitely not ignore.. as a rule of thumb, always respond to all review points in a review, even if it's a thumbs up | 07:46 |
| zyga-ubuntu | niemeyer: I discussed each point jamie made | 07:47 |
| niemeyer | zyga-ubuntu: So why is his review reading like that? | 07:47 |
| zyga-ubuntu | niemeyer: I didn't understand that he essentially said that is all mandatory | 07:48 |
| zyga-ubuntu | niemeyer: when you are subtle on the internet... | 07:48 |
| niemeyer | zyga-ubuntu: "You did not address the off-by-one in read_cmdline() yet" | 07:48 |
| zyga-ubuntu | niemeyer: read the full discussion, I disagree about that item (it's not a bug, it's an optimization) | 07:49 |
| zyga-ubuntu | niemeyer: I'll address each element jamie made, it's just not easy to keep track of everything in that PR and, as I said, I was confused by his earlier statements about what is needed and what is optional and nice | 07:49 |
| mvo | pedronis: I have not looked at your latest branch yet but maybe in main.go when you start the runner. I will soon look at your latest PRs maybe I have a better idea then | 07:50 |
| zyga-ubuntu | (some of the things I pushed into the PR were in the "nice" category according to my earlier understanding) | 07:50 |
| oSoMoN | zyga-ubuntu, hey, out of curiosity, could you please point me to the commit in master that fixes bug #1718026 ? | 07:50 |
| mup | Bug #1718026: Applications from installed snaps don't appear in activities overview <Snappy:Fix Committed> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1718026> | 07:50 |
| pedronis | mvo: no, I mean on disk? | 07:50 |
| zyga-ubuntu | oSoMoN: yes, one sec | 07:50 |
| zyga-ubuntu | oSoMoN: 2f55619677810a4872145b8ccbbe2bdc1ba364fa | 07:50 |
| pedronis | mvo: sorry, I wasn't clear, I mean where on disk | 07:50 |
| zyga-ubuntu | oSoMoN: I verified this by installing the updated file on 17.10 running wayladn | 07:51 |
| oSoMoN | zyga-ubuntu, thanks | 07:51 |
| mvo | pedronis: oh, sorry :) /var/lib/snapd/repair/lock maybe? | 07:51 |
| pedronis | ok | 07:51 |
| pedronis | that seems reasonable | 07:51 |
| pedronis | and what I was thinking as well | 07:51 |
| pedronis | ah | 07:52 |
| pedronis | mmh | 07:52 |
| pedronis | mvo: no reason to creat it in /run/snapd/repair/lock ? (I see we create some other locks under /run) | 07:52 |
| niemeyer | zyga-ubuntu: His comment seems spot on regarding off by one.. | 07:52 |
| niemeyer | zyga-ubuntu: and he's asking you to take it into account | 07:52 |
| mvo | pedronis: oh, that is a good one too, the advantage is of course that its slightly cleaner) | 07:52 |
| mvo | pedronis: less clutter on the real disk, so that works for me | 07:53 |
| niemeyer | zyga-ubuntu: His code is both safer and more technically correct as it handles the length of the string properly for the exact fitting case | 07:53 |
| zyga-ubuntu | niemeyer: yes, I don't disagree about it but it's not a blocker in any sense of the word | 07:54 |
| niemeyer | zyga-ubuntu: just n > m on itself would already be worth fixing | 07:54 |
| pedronis | mvo: thanks | 07:54 |
| niemeyer | zyga-ubuntu: Instead of an exact == match | 07:54 |
| niemeyer | zyga-ubuntu: Please take Jamie's review more carefully.. | 07:54 |
| pedronis | mvo: I'm reviewing your PRs btw | 07:55 |
| mvo | pedronis: thanks for that! | 07:58 |
| mvo | pedronis: I will address and look at your PRs too. fwiw, if you merge master into your PRs tests should be happy again (kudos to zyga-ubuntu for the workaround) | 08:01 |
| pedronis | ah, good | 08:02 |
| mwhudson | what does "Ubuntu Artful, for Ubuntu Core 16" mean in a snap build on launchpad? | 08:32 |
| mvo | mwhudson: my guess is that the snap was build with an artful chroot but is targeted towards ubuntu core 16 (which AFAIK is the only target we have currently :) | 08:36 |
| mwhudson | ah so build-packages etc will come from artful | 08:36 |
| mwhudson | that might actually be useful for me | 08:36 |
| mwhudson | can i get cleanbuild to use an artful lxd? | 08:36 |
| pedronis | mvo: I added the flock code to the loop PR | 08:37 |
| mvo | mwhudson: I think you can but I'm not familiar with the syntax unfortunately | 08:38 |
| mvo | pedronis: thank you | 08:38 |
| mwhudson | mvo: " self._image = 'ubuntu:xenial/{}'.format(deb_arch)" :( | 08:40 |
| mvo | mwhudson: *cough* | 08:40 |
| ogra_ | urgh ... i hope we dont allow that | 08:40 |
| mvo | mwhudson: sounds like a PR waiting to happen then | 08:40 |
| ogra_ | nne of the deps will be coorrrect | 08:40 |
| ogra_ | *none | 08:40 |
| ogra_ | afaik launchpad always calls cleanbuild regardless ... so the host might be artful but the build container will still be xenial | 08:42 |
| pedronis | that message seems mostly confusing then (the host shouldnd't play a big role) | 08:43 |
| mvo | indeed, if thats the case its pretty useless to even offer builds on anything but xenial | 08:44 |
| ogra_ | well, and we shuldnt | 08:45 |
| pedronis | yes, until we have base-18 (or however we will call it) | 08:46 |
| ogra_ | buillding on anythhing but xenial for core 16 willl only result in dependency mess for stage-packages, you really dont want that | 08:46 |
| ogra_ | ight | 08:46 |
| ogra_ | once we have another base/core we should have choices, but not atm | 08:46 |
| mwhudson | ogra_: no, that's definitely not what is happening | 08:47 |
| ogra_ | got a link to the log ? | 08:47 |
| mwhudson | ogra_: https://launchpadlibrarian.net/337523100/buildlog_snap_ubuntu_artful_amd64_subiquity-artful_BUILDING.txt.gz | 08:47 |
| mvo | pedronis: should we restrict summary further or is checking for \n enough in your estimate? | 08:48 |
| ogra_ | yeah, that uses atful all the way through, thats definitely wrong and dangerous | 08:48 |
| mwhudson | i assume lp didn't just add this by accident... | 08:49 |
| ogra_ | mwhudson, talk to wgrant or cjwatson | 08:49 |
| ogra_ | such builds shouldnt be provided | 08:49 |
| cjwatson | wat | 08:50 |
| ogra_ | (imagine yoou wouldnt use the python plugin (which pulls in the interpreter) but just dump to copy sme py modules in place ... how woould you knw they are even remotely compatible with the intepreter shhipped in core (which we'd fall back to in this case) | 08:50 |
| mvo | how would people get e.g. stage-package for artful then? | 08:50 |
| cjwatson | sorry, how is this our problem? | 08:50 |
| ogra_ | cjwatson, why doesnt it call cleanbuild ? | 08:51 |
| cjwatson | LP has never used cleanbuild | 08:51 |
| cjwatson | it uses containers based on its own chroots | 08:51 |
| ogra_ | still | 08:51 |
| pedronis | mvo: ScanLine uses the equivalent of `\r?\n` | 08:51 |
| cjwatson | if it's using artful it's because the person who set it up explicitly asked for it to use artful | 08:51 |
| pedronis | *ScanLines | 08:51 |
| cjwatson | cleanbuild is beside the point | 08:52 |
| ogra_ | another example ... pulse has 100% incompatible API changes in libpulse between xenial and all the following releases ... as soon as your app uses sound you are screwed ... | 08:52 |
| mvo | pedronis: aha, nice. I will use a similar pattern than, but essentially a blacklist \n\r? is ok, we don't want a fancy whitelist "[a-zA-Z,.-?...] (?) | 08:52 |
| cjwatson | right, so don't do that, but it still needs to be possible to run test builds where appropriate | 08:52 |
| ogra_ | builds should only target xenial | 08:52 |
| cjwatson | so we won't withdraw the facility | 08:52 |
| pedronis | mvo: don't think we need a fancy whitelist, no | 08:52 |
| mvo | pedronis: thank you | 08:53 |
| pedronis | it's mostly us for now that will make them | 08:53 |
| mvo | +1 | 08:53 |
| pedronis | mostly keeping us honest, not confuse that code | 08:53 |
| ogra_ | cjwatson, well, as long as you cant release the result to the store i guess it is fine for test building ... to me it looked like mwhudson was hitting a default though | 08:53 |
| cjwatson | you can, but it's up to the builder to ensure that the result works, like anything | 08:54 |
| cjwatson | I mean the person operating the recipe | 08:54 |
| cjwatson | artful is not the default | 08:54 |
| mwhudson | i selected this option because i _want_ all my stage-packages etc to come from artful | 08:54 |
| mwhudson | at least for a trial | 08:55 |
| ogra_ | mwhudson, right, just dont release it ... (and i think there shoudl be at least a warning when you select that option) | 08:55 |
| cjwatson | the default is xenial | 08:55 |
| mwhudson | ogra_: this is subiquity, it is a normal snap in no ways at all | 08:55 |
| mwhudson | for another questoin | 08:56 |
| ogra_ | mwhudson, well, what goes to the store should always target xenial ... if you do test builds it doesnt matter indeed (not sure about the benefit of it ... but well) | 08:56 |
| wgrant | Someone can produce something that doesn't work by asking snapcraft to download a tarball with the wrong ABI. | 08:56 |
| ogra_ | sure | 08:56 |
| wgrant | I don't see why we should prevent them from shooting themselves in the foot if they don't know what they're doing by selecting a series that won't work for them. | 08:57 |
| mwhudson | for another question | 08:57 |
| mwhudson | hm no | 08:57 |
| ogra_ | but thats a pretty explicit action ... i'd expect you to knwo what yuo do any why in that case | 08:57 |
| ogra_ | wgrant, the point is that it wont work for the ednuser ... it might just build fine for the developer | 08:57 |
| mwhudson | oh heh pushing my change to github and then immediatly building from the import branch on lp, not so useful | 08:57 |
| ogra_ | mwhudson, fsvo "immediately" :) | 08:58 |
| mwhudson | ogra_: i generally don't wait for 3 or so hours by mistake | 08:59 |
| ogra_ | (i have never the luck to hit the import schedule with my commits ... it usually just ran or says "will run in 20min" or soo) | 08:59 |
| ogra_ | you can just click the import button | 08:59 |
| mwhudson | yes i know | 09:00 |
| mwhudson | i implemented the import button :) | 09:00 |
| ogra_ | heh | 09:00 |
| mwhudson | a very very long time ago now | 09:01 |
| pstolowski | zyga-ubuntu, is the bug re manpages (that you mentioned above) concerning snapctl (discussed yesterday)? | 09:07 |
| zyga-ubuntu | pstolowski: there are two bus, one affecting all of debian sid (packaging bug where file clashes) and one affecting snapd (snactl does not have a man page but is in path) | 09:08 |
| mup | PR snapd#3939 opened: core/repo: Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939> | 09:11 |
| pstolowski | niemeyer, pedronis, zyga-ubuntu : quick first feedback appreciated before I dive in with more significant changes: https://github.com/snapcore/snapd/pull/3939 | 09:11 |
| mup | PR #3939: core/repo: Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939> | 09:11 |
| pstolowski | zyga-ubuntu, i see, ack. ok, I'm going to work on snapctl man page now | 09:12 |
| zyga-ubuntu | pstolowski: thanks, it's not a high priority but I think one will be useful for developers and users alike | 09:17 |
| niemeyer | Is it time for another review sprint yet, or too soon? | 09:35 |
| niemeyer | mvo: How do you feel about our queue atm? | 09:35 |
| mvo | niemeyer: its too big, but I hope before EOD we can close a good bunch, some are very close but tests issues have slowed progress a bit | 09:35 |
| ackk | niemeyer, wrt the SocketInfo struct, you're suggesting to add Name as an attribute and have App.Sockets as a []SocketInfo rather than a map, right? | 09:36 |
| ackk | niemeyer, that would also allow having socket.File() as you suggested | 09:36 |
| niemeyer | ackk: Let's please discuss this in that topic in the forum | 09:36 |
| niemeyer | Oh, wait | 09:36 |
| niemeyer | ackk: Sorry, separeate issue | 09:36 |
| niemeyer | ackk: No | 09:36 |
| ackk | yeah, that's about implementation details | 09:36 |
| ackk | :) | 09:36 |
| niemeyer | ackk: The idea was still having it as a map | 09:37 |
| niemeyer | ackk: Having a Name attribute isn't something I thought of, but sounds like a good idea | 09:37 |
| niemeyer | ackk: Even if redundant with the map key | 09:37 |
| ackk | niemeyer, yeah I was trying to avoid duplication | 09:37 |
| niemeyer | ackk: It's good duplication in this case.. | 09:38 |
| ackk | niemeyer, FWIW I'm not sure we even a map at that point | 09:38 |
| niemeyer | ackk: Means we can use the SocketInfo by itself | 09:38 |
| ackk | right, I do like the idea of socket.Name | 09:38 |
| niemeyer | ackk: What's the issue iwth the map? | 09:38 |
| ackk | niemeyer, I don't think there's really one, but if we don't need to look up by name (which we probably don't), we could just keep a list | 09:39 |
| ackk | I'm talking just about App.Sockets, not about the Yaml format, to be clear | 09:39 |
| ackk | anyway, duplication is not a big deal in this case, agreed | 09:40 |
| ackk | if you prefer to keep the map, LGTM | 09:40 |
| niemeyer | ackk: Yeah, let's keep it at least for now, as it reflects the structure in the yaml.. but there's still that more fundamental underlying question about whether the whole thing is workable or not | 09:40 |
| ackk | niemeyer, what's the issue? | 09:41 |
| niemeyer | mvo: Ack.. let's wait til the EOD and reevaluate tomorrow | 09:41 |
| niemeyer | ackk: It's in the review | 09:41 |
| ackk | niemeyer, ah yeah, I did answer that in the review | 09:42 |
| mvo | niemeyer: +1 | 09:44 |
| ackk | xnox, hi, can you define more than one Listen* in a .socket file? | 09:46 |
| pstolowski | zyga-ubuntu, do we still want bugs concerning snap-confine to be reported against https://bugs.launchpad.net/snap-confine/+filebug ? or is it the main snapd bug tracker now? | 09:53 |
| zyga-ubuntu | pstolowski: I don't have a strong opinion on that | 09:54 |
| zyga-ubuntu | pstolowski: it can be moved to snapd | 09:54 |
| pstolowski | zyga-ubuntu, i see, just asking, wasn't sure if snap-confine bugtracker isn't dead or something | 09:55 |
| zyga-ubuntu | pstolowski: I'm not sure either, we have snapd, snappy, snap-confine + distro versions of those | 09:56 |
| zyga-ubuntu | so it's all a bit all over the place | 09:56 |
| pstolowski | zyga-ubuntu, ok, I was wondering about updating snap-confine manpage while on it, but it seems there is no obvious answer, that's fine | 09:58 |
| xnox | ackk, hi, you can use $ systemd-analyze verify FILE for systemd to check syntax of a unit file. | 10:03 |
| zyga-ubuntu | pstolowski: go ahead and do it if you want to | 10:05 |
| zyga-ubuntu | pstolowski: one less bug tracker to worry about (eventually) | 10:05 |
| pstolowski | ok | 10:05 |
| pedronis | mvo: niemeyer: I have an errand this afternoon, if there are no delays I should be back for the standup, but I might not | 10:06 |
| mvo | ta | 10:07 |
| niemeyer | pedronis: Thanks for the note | 10:08 |
| niemeyer | mvo: #3934 is reviewed | 10:09 |
| mup | PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934> | 10:09 |
| niemeyer | mvo: Have you seen the description on #3929? | 10:09 |
| mup | PR #3929: Correct typo in test <Created by gliptak> <https://github.com/snapcore/snapd/pull/3929> | 10:09 |
| niemeyer | mvo: I'm assuming the answer is "no" :D | 10:10 |
| niemeyer | mvo: I mean, to the questions in the description | 10:10 |
| mvo | niemeyer: thanks for the review, i have a look | 10:11 |
| mup | PR snapd#3940 opened: dirs: fix classic support detection <Created by chipaca> <https://github.com/snapcore/snapd/pull/3940> | 10:11 |
| mvo | niemeyer: I had hoped we get an answer for the question. | 10:12 |
| mup | PR snapd#3929 closed: snap: correct typo in test name <Created by gliptak> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3929> | 10:12 |
| niemeyer | mvo: Well, getting "No" as a description wouldn't be much better I'm afraid.. LOL | 10:12 |
| mvo | niemeyer: heh :) | 10:13 |
| * zyga-ubuntu runs tests on updated update-ns PR and takes a break | 10:17 | |
| mup | PR snapd#3941 opened: overlord/snapstate: prefer a smaller corner case for doing the wrong thing <Created by chipaca> <https://github.com/snapcore/snapd/pull/3941> | 10:21 |
| * zyga-ubuntu hugs chipaca | 10:22 | |
| * Chipaca hugs back | 10:23 | |
| mwhudson | snapping snapcraft is quite a slow process, probably not the right way to go for testing local hacks :) | 10:26 |
| * Chipaca hugs the snaps he's written before snapcraft was a thing | 10:28 | |
| zyga-ubuntu | mwhudson: does snap try on snapcraft works? | 10:28 |
| niemeyer | I still sort of want "snap pack" or something similar.. | 10:29 |
| mwhudson | zyga-ubuntu: huh i didn't know about snap try | 10:29 |
| Chipaca | mwhudson: dude :-) | 10:30 |
| Chipaca | mwhudson: as long as you're not modifying the snap metadata, with snap try you can edit stuff and test them without touching anything else | 10:30 |
| mwhudson | sounds exciting :) | 10:32 |
| mvo | niemeyer: "snap pack" would be like "snapcraft snap" ? | 10:33 |
| niemeyer | mvo: I'm not sure, which is perhaps another reason why I'd like to have it :) | 10:35 |
| niemeyer | mvo: snapcraft snap used to mean something else | 10:35 |
| niemeyer | mvo: Its help text says: | 10:36 |
| niemeyer | If you want to snap a directory, you should use the snap-dir command | 10:36 |
| niemeyer | instead. | 10:36 |
| niemeyer | Except, snap-dir doesn't exist? | 10:36 |
| niemeyer | sergiusens: ^ | 10:36 |
| niemeyer | mvo: I think "snapcraft" and "snapcraft snap" are the same thing | 10:37 |
| niemeyer | mvo: Anyway, yeah.. something dumb that just packs a snap dir.. | 10:37 |
| niemeyer | pstolowski: #3939 LGTM | 10:38 |
| mup | PR #3939: interfaces: add Connection type <Created by stolowski> <https://github.com/snapcore/snapd/pull/3939> | 10:38 |
| Chipaca | niemeyer: snapcraft snap <directory> just mksquashfs's | 10:39 |
| * Chipaca hasn't read all the context | 10:39 | |
| niemeyer | Chipaca: I don't think so.. | 10:39 |
| Chipaca | niemeyer: you think wrong | 10:40 |
| Chipaca | :-) | 10:40 |
| pstolowski | niemeyer, great, thank you. i'll shortly outline what's next on the standup (or after it) | 10:40 |
| Chipaca | niemeyer: but yes the docs for snap are wrong and/or misleading | 10:42 |
| mwhudson | did i imagine something about using a persistent container for building snaps? | 10:44 |
| niemeyer | Chipaca: Well, if it is a dumb pack, then it's broken in terms of UX too | 10:44 |
| Chipaca | niemeyer: no no no | 10:44 |
| niemeyer | Chipaca: As "snapcraft snap" and "snapcraft snap foo/" would be completely different | 10:44 |
| Chipaca | niemeyer: no adding ux requirements mid-rant | 10:44 |
| Chipaca | :-) | 10:45 |
| niemeyer | LOL :) | 10:45 |
| niemeyer | Chipaca: The former reads snapcraft.yaml and builds the whole snap | 10:45 |
| Chipaca | niemeyer: yes they are completely different, and surprising, and being in the current directory and doing one instead of the other is a pain | 10:45 |
| Chipaca | which suggests that the idea is to move it to snap-dir? dunno | 10:46 |
| Chipaca | but today, it is like it is | 10:46 |
| Chipaca | (i'm just telling you how it is) | 10:46 |
| Chipaca | (in particular, i'm not saying it's the way it should be) | 10:46 |
| pedronis | mvo: btw, should we build snap-repair for 14.04 at all? we don't have 14.04 core systems | 10:47 |
| niemeyer | Chipaca: I honestly don't know either.. but "snap pack" will solve it all.. :) | 10:48 |
| Chipaca | niemeyer: we used to have that | 10:48 |
| pedronis | we still do internally (for tests) | 10:49 |
| Chipaca | niemeyer: we got rid of it to only have the mksquashfs call in one place (lots of little flags that need to be in sync) | 10:49 |
| pedronis | I mean, we didn't quite manage to get rid of the code | 10:49 |
| pedronis | anyway | 10:49 |
| Chipaca | i know i know | 10:49 |
| Chipaca | also, more and more snapcraft calls snap for things, so maybe we made the wrong call | 10:49 |
| Chipaca | and moving to snap pack is the right thing | 10:49 |
| Chipaca | but, there is that DRY thing i wanted to point out | 10:50 |
| niemeyer | Chipaca: Yeah.. we should probably seed the idea with a hidden command and see what happens next | 10:50 |
| sergiusens | ogra_ mwhudson wrt launchpad, it creates its own container and runs plain old snapcraft (without cleanbuild | 10:50 |
| niemeyer | sergiusens: What's the deal with snap vs. snap-dir | 10:50 |
| niemeyer | ? | 10:50 |
| niemeyer | sergiusens: The snapcraft commands, I mean | 10:50 |
| sergiusens | wrt "mvo: " self._image = 'ubuntu:xenial/{}'.format(deb_arch)" :(" as soon as base support comes in, we will map this to proper bases | 10:51 |
| sergiusens | build.snapcraft.io does not allow you to pick artful, if using launchpad directly you have a bit more "advanced" flexibility | 10:51 |
| Chipaca | how is there a travis build running for 3h+ | 10:52 |
| niemeyer | Chipaca: If seen a bug in travis happening recently where they concatenate two independent runs and sum up the logs and the times | 10:54 |
| niemeyer | Chipaca: Have a look in the middle of the logs.. look for a big jump in the timestamp | 10:54 |
| niemeyer | sergiusens: Parlez-vous anglais? | 10:56 |
| * zyga-ubuntu pushes lots of changes to https://github.com/snapcore/snapd/pull/3621 and crosses his fingers | 10:59 | |
| mup | PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621> | 10:59 |
| sergiusens | niemeyer we have a bug for that, should be fixed soon (wrt snap-dir) | 11:09 |
| niemeyer | sergiusens: Ack, thanks | 11:09 |
| niemeyer | sergiusens: Which direction will the fix go? | 11:09 |
| sergiusens | and the issue was oversight | 11:09 |
| sergiusens | niemeyer we need to implement snap-dir and deprecate using `snap <directory>` | 11:10 |
| niemeyer | sergiusens: Nice, sounds like the best option | 11:10 |
| niemeyer | sergiusens: Might be worth renaming snap-dir, though, to make the delta more clear | 11:10 |
| sergiusens | niemeyer suggestions? | 11:11 |
| niemeyer | sergiusens: snapcraft pack | 11:11 |
| * sergiusens is open for them early in the morning after staying up too late working on integration tests | 11:11 | |
| niemeyer | sergiusens: Hopefully one day this will simply call "snap pack" | 11:11 |
| * zyga-ubuntu does school run | 11:11 | |
| sergiusens | niemeyer rings nice as I say it out loud | 11:12 |
| niemeyer | sergiusens: Yeah, it's dumb-sounding | 11:12 |
| pedronis | Chipaca: what's the status of #3835 ? | 11:12 |
| mup | PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835> | 11:12 |
| niemeyer | "Just pack it up..." | 11:12 |
| Chipaca | pedronis: needing a second review | 11:12 |
| zyga-ubuntu | Chipaca: it's also red | 11:13 |
| ogra_ | sergiusens, yeah, i learned that above, i always though it uses cleanbuild :) | 11:13 |
| mvo | pedronis: good point, we don't need snap-reparir for 14.04 at all | 11:14 |
| Chipaca | pedronis: "red"? | 11:14 |
| zyga-ubuntu | Chipaca: tests are failing | 11:15 |
| Chipaca | the last spread test was green | 11:15 |
| pedronis | they are being re-run | 11:15 |
| Chipaca | which tests were failing? | 11:15 |
| zyga-ubuntu | autopackage | 11:16 |
| pedronis | Chipaca: afaict spread tests are running atm because mvo just pushed master into it | 11:16 |
| zyga-ubuntu | maybe harmless, just observing | 11:16 |
| Chipaca | yes | 11:16 |
| Chipaca | but if you click the previous commit's red X, you'll see the green spread tests | 11:16 |
| mvo | niemeyer: I would love to bring "snap pack <dir>" back, this would allow us to stop building the snapbuild helper for our tests. if there is a +1 from you I make this happen, should be reasonable quick | 11:16 |
| mvo | Chipaca: there wre conflicts | 11:16 |
| niemeyer | mvo: +1! | 11:16 |
| pedronis | mvo: let's close a bit more PRs first though :) | 11:17 |
| mvo | Chipaca: this is why I merged master/pushed (in debian/snapd.dirs) | 11:17 |
| mvo | pedronis: *pfff* | 11:17 |
| Chipaca | mvo: thank you | 11:17 |
| mvo | pedronis: ;) | 11:17 |
| Chipaca | to be expected when it's just sat there for nearly three weeks | 11:17 |
| mvo | Chipaca: yeah, it has my +1 | 11:17 |
| Chipaca | mvo: yes | 11:17 |
| niemeyer | pedronis: Man, we're in a roll today! ;) | 11:18 |
| niemeyer | I should not sleep more often.. feels so much more productive | 11:18 |
| niemeyer | LOL | 11:18 |
| Chipaca | niemeyer: _on_ a roll, hopefully | 11:18 |
| niemeyer | Chipaca: Both! | 11:18 |
| Chipaca | heh | 11:19 |
| pedronis | mvo: what's the status of #3901 ? issues with 14.04 ? | 11:20 |
| mup | PR #3901: snap-seccomp: run secondary-arch tests via gcc-multilib <Created by mvo5> <https://github.com/snapcore/snapd/pull/3901> | 11:20 |
| pedronis | can't we skip it there for now? and see about that in a follow up? | 11:20 |
| mvo | pedronis: the last run died because of the debian issue, I haven't yet the status since (I merged master this morning) | 11:22 |
| niemeyer | pstolowski: #3918 reviewed too | 11:23 |
| mup | PR #3918: hooks: substitute env vars when executing hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3918> | 11:23 |
| niemeyer | pstolowski: LGTM, but let's just move the test logic into the existing test that is already supposed to check basics of snap run for hooks | 11:23 |
| sergiusens | ogra_ they should produce similar environments in the end | 11:25 |
| ogra_ | sergiusens, sure ... unless the wrong release is used | 11:25 |
| pstolowski | niemeyer, i can, np.. it is sometimes nice though to have even basic tests separated, as a failure gives a very quick hint about what went wrong | 11:25 |
| ogra_ | (which was my point) | 11:25 |
| sergiusens | ogra_ oh, not sure we plan to support anything outside of bases for that | 11:26 |
| ogra_ | sergiusens, well, we do support building a snap completely on artful atm ... that was what made me curious | 11:26 |
| ogra_ | sergiusens, but it is an explicit action you have to select (despite likely producing something useless) | 11:26 |
| sergiusens | ogra_ well, yes, given we release snapcraft to artful means we have to make sure it passes tests | 11:27 |
| ogra_ | sergiusens, this is about the option to pick artful as a target for your snap ... i know snapcraft runs its autopkgtests | 11:27 |
| * Chipaca ~> lunch | 11:31 | |
| niemeyer | pstolowski: We don't really want to split out functional tests every few lines because they are testing a slightly different aspect of the same logic | 11:35 |
| pstolowski | niemeyer, fair enough | 11:35 |
| niemeyer | pstolowski: The test is literally called "snap-run-hook" already.. | 11:35 |
| niemeyer | pstolowski: I'd even more the env into the snap used in that test | 11:36 |
| * Chipaca ~> really lunch | 11:47 | |
| ogra_ | mvo, uhmmmm ... your change to xdg-open cant really work ... we have no dbus-send inside core ... | 11:47 |
| ogra_ | hmm, ignore that, the old code also used dbus-send ... how the heck did that work without a dbus-send binary | 11:49 |
| ackk | xnox thanks | 11:55 |
| mup | PR snapd#3887 closed: snapstate: auto-install missing base snaps <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3887> | 11:58 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| niemeyer | pstolowski: #3852 just has the rename mentioned in the first comment pending | 12:04 |
| mup | PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852> | 12:04 |
| niemeyer | pstolowski: Should be something like servicestate.Change, similar to configstate.Configure, cmdstate.Exec, snapstate.Install, etc. | 12:05 |
| pstolowski | niemeyer, indeed, but I thought it was ok to postpone this, per your second comment? | 12:06 |
| niemeyer | pstolowski: The second comment is talking about the return value | 12:07 |
| niemeyer | pstolowski: Unrelated to the rename | 12:07 |
| pstolowski | niemeyer, I see. ok. misunderstood | 12:07 |
| niemeyer | np | 12:07 |
| ackk | niemeyer, posted the question related to the yaml format on https://forum.snapcraft.io/t/socket-activation-support/2050/12 | 12:08 |
| mup | PR snapd#3942 opened: doc: snapctl man page <Created by stolowski> <https://github.com/snapcore/snapd/pull/3942> | 12:10 |
| pstolowski | zyga-ubuntu, ^ | 12:10 |
| niemeyer | ackk: Thanks | 12:13 |
| niemeyer | ackk: Also reading your feedback on the PR | 12:13 |
| ackk | niemeyer, I just pushed the other changes you requested | 12:13 |
| === chihchun is now known as chihchun_afk | ||
| zyga-ubuntu | re | 12:21 |
| zyga-ubuntu | pstolowski: thank you | 12:21 |
| zyga-ubuntu | pstolowski: reviewed | 12:25 |
| zyga-ubuntu | jdstrand: hey, around? | 12:28 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| pedronis | mvo: there's a error difference in artful that makes some unit tests fail here on artful: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170919_102916_63405@/log.gz | 12:46 |
| mvo | pedronis: yeah, I saw that too, I will update my tests | 12:49 |
| jdstrand | mvo: hey, regarding cgroups-- I was doing this on xenial classic distro, using a dpkg-buildpackage built deb from master. what were you doing? (I'm going to try again) | 12:52 |
| mup | PR snapcraft#1554 opened: store: handle revoked developers <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554> | 12:52 |
| mvo | jdstrand: I was doing it on zesty running snapd from git | 12:53 |
| mvo | jdstrand: I can try your setup next | 12:53 |
| jdstrand | mvo: 'snapd from git' means dpkg-buildpackage? | 12:53 |
| mvo | jdstrand: it means "go build && sudo ./snapd" from cmd/snapd in the source tree | 12:55 |
| jdstrand | mvo: so, I was using dpkg-buildpackcage because of all the different binaries involved | 12:56 |
| jdstrand | snapd, snap, snap-confine, snap-seccomp, snap-update-ns, snap-discard-ns, snap-exec, etc | 12:56 |
| jdstrand | I have a script to go build everything, copy over, etc | 12:57 |
| jdstrand | but I was trying to do what you typically do :P | 12:57 |
| jdstrand | (we talked about this I think last week) | 12:57 |
| jdstrand | mvo: I'm going to retest on classic xenial, zesty and artful. maybe I messed something up in the vm | 12:58 |
| jdstrand | mvo: does core in edge have master code? I'd like to retry there too | 12:58 |
| mvo | jdstrand: yeah, core should be up-to-date | 13:00 |
| mvo | jdstrand: I can check after the standup | 13:00 |
| niemeyer | Just grabbing a cup'a and will be in the standup | 13:01 |
| roadmr | mvo hi | 13:08 |
| roadmr | mvo: question about base snaps: is it possible for a snap to have more than one base snap? (i.e. can it have "no" base snap or "one" base snap but not more?) | 13:09 |
| roadmr | mvo: and I guess follow-up: is it planned for multi-base snaps to be a possibility in the future? or not at all? | 13:09 |
| roadmr | (I guess not because that'd reintroduce dependency hell, right?) | 13:09 |
| ogra_ | yeah, very unlikely | 13:09 |
| ackk | niemeyer, I'm not sure I follow the point about systemd generating the .socket files. where do you put the [Socket] definition itself? | 13:21 |
| niemeyer | ackk: In a configuration file for systemd? :) | 13:22 |
| niemeyer | ackk: Ah, no.. not those socket files | 13:22 |
| niemeyer | ackk: The *real* socket files | 13:22 |
| ackk | niemeyer, for unix sockets? | 13:23 |
| zyga-ubuntu | roadmr: not right now because a base snap is the rootfs | 13:23 |
| * ackk is a bit lost :) | 13:23 | |
| zyga-ubuntu | roadmr: so we'd have to understand what you mean by having more than one first | 13:23 |
| roadmr | zyga-ubuntu: I mean exactly that :P | 13:23 |
| zyga-ubuntu | roadmr: and what would that do? there can be only one rootfs in the traditional meaning of the word | 13:24 |
| roadmr | zyga-ubuntu: I don't know, that's why I'm asking :) | 13:24 |
| zyga-ubuntu | roadmr: why are you asking? do you have a workflow on your mind? | 13:25 |
| roadmr | zyga-ubuntu: it's in connection with https://bugs.launchpad.net/snapstore/+bug/1715824. We'll work on implementing that but we'd like to know if we need to design for 0-N bases or only for 0,1 bases | 13:25 |
| mup | Bug #1715824: Please provide "base" snap data from snaps <Snap Store:Confirmed> <https://launchpad.net/bugs/1715824> | 13:25 |
| zyga-ubuntu | roadmr: for that you can safely assume each snap has exactly one base snap (with a default, so it's never empty) | 13:26 |
| zyga-ubuntu | roadmr: technically it's a unset -> default or explicitly set but I don't know if you need to have that detail at the API level | 13:26 |
| roadmr | zyga-ubuntu: nice, thanks! | 13:27 |
| niemeyer | ackk: Yeah, the unix socket files.. sorry, in the standup so a bit slow | 13:27 |
| ogra_ | zyga-ubuntu, base-busybox + base-rootfs-core + base-fobbar-service | 13:27 |
| zyga-ubuntu | ogra_: what is the composition operator for a filesystem? union? | 13:28 |
| * ogra_ hopes thats a nono | 13:28 | |
| ogra_ | zyga-ubuntu, well, it is all squashfses .... i think you can merge them on mount ... | 13:28 |
| ogra_ | (would still be awful though) | 13:28 |
| zyga-ubuntu | ogra_: we cannot currently merge them on mount | 13:29 |
| ackk | niemeyer, but that's what is defined by ListenStream, no? | 13:29 |
| ogra_ | (i just meant to outline the possibility of multiple base snaps) | 13:29 |
| niemeyer | ackk: Yes, exactly | 13:29 |
| ackk | niemeyer, so I don't get the comment about FileDescriptorName (which TIL) | 13:29 |
| zyga-ubuntu | ogra_: since we never discussed merging multiple base snaps I'll skip that for now, once overlayfs becomes LSM-aware and apparmor is overlayfs aware we can explore this with layouts | 13:29 |
| ogra_ | zyga-ubuntu, uh, i hope we never have to ... :) | 13:30 |
| zyga-ubuntu | ogra_: as a layout element it would be powerful capability, it's just we cannot do it yet | 13:30 |
| ogra_ | one bae snap is enough for everyone !!! | 13:30 |
| niemeyer | ackk: Those two things are unrelated.. do you get the first one, before we move to something else? | 13:31 |
| ackk | niemeyer, about sanitizing the keys for the sockets: entries? yes | 13:31 |
| niemeyer | ackk: That's a third thing.. | 13:31 |
| * ogra_ wonders if ackk's choice of nick is because you always have the feeling of agreement if people talk to you | 13:32 | |
| ackk | niemeyer, sorry, not sanitizing, ensuring the generated names are safe | 13:32 |
| ackk | ogra_, lol, I had this since since forever (actually just "ack" but that's taken here) | 13:32 |
| ogra_ | :) | 13:33 |
| ogra_ | it surely gives a positive feeling :) | 13:33 |
| niemeyer | ackk: Ok, cool.. yeah, not quite clear how we'll do that | 13:33 |
| ackk | niemeyer, isn't validating the key like for snap names not enough? | 13:34 |
| ackk | (as you mentioned) | 13:34 |
| niemeyer | ackk: No.. as I said, that's a separate problem and a separate solution | 13:34 |
| niemeyer | ackk: The file location safety is about confinement | 13:35 |
| ackk | niemeyer, right. for that I guess we could change it so that listen-stream in the case of an actual socket file would be prefixed with the snap dir ($SNAP_DATA IIRC?) | 13:36 |
| === chihchun_afk is now known as chihchun | ||
| mvo | roadmr: no plans to have multiple bases currently. you can have "no" base by using the "bare" bases which is literally an empty base snap, nothing inside it (not even libc) | 14:02 |
| roadmr | mvo: nice. Hey, we put that (and a few other) question(s) in the bug, would you mind answering there? it helps with keeping things documented :) | 14:03 |
| roadmr | mvo: (thanks in advance !) | 14:03 |
| === ikey|zzz is now known as ikey | ||
| mvo | roadmr: sounds good, what was the bugnumber again ? | 14:13 |
| roadmr | https://bugs.launchpad.net/snapstore/+bug/1715824 | 14:14 |
| mup | Bug #1715824: Please provide "base" snap data from snaps <Snap Store:Incomplete> <https://launchpad.net/bugs/1715824> | 14:14 |
| roadmr | mvo: ^^ | 14:14 |
| mvo | ta | 14:14 |
| zyga-ubuntu | mvo: question about bases that's probably related: can we agree that base snaps cannot have any apps | 14:16 |
| zyga-ubuntu | actually, no because core config | 14:16 |
| zyga-ubuntu | sorry | 14:16 |
| zyga-ubuntu | roadmr: I think mvo is right that base snaps don't have a base | 14:16 |
| zyga-ubuntu | roadmr: because they are their own base | 14:17 |
| ogra_ | zyga-ubuntu, i was about to ask you to explain how we boot core then ;) | 14:17 |
| ogra_ | (if a base cant have any apps) | 14:17 |
| mvo | zyga-ubuntu: we could, but I think morphis has some interessting ideas for base snaps with apps | 14:17 |
| zyga-ubuntu | ogra_: apps != programs | 14:17 |
| ogra_ | ? | 14:18 |
| ogra_ | what are they then ? | 14:18 |
| zyga-ubuntu | mvo: I think I wanted to say that base is its own base snap | 14:18 |
| zyga-ubuntu | mvo: then the propery I cared about holds regardless of apps/hooks | 14:18 |
| mvo | zyga-ubuntu: yes | 14:18 |
| mvo | zyga-ubuntu: I mean, yes, base is its own base snap | 14:18 |
| zyga-ubuntu | mvo: or that the "base" property applies to app snaps and gadget snaps but not to base snaps :) | 14:18 |
| zyga-ubuntu | yep | 14:18 |
| ogra_ | why would it apply to gadget snaps ? | 14:19 |
| ogra_ | (a gadget should pretty much operate standalone without any dependency on a base ... the model assertion should then define the base) | 14:20 |
| zyga-ubuntu | ogra_: because those will have hooks as far as I konw | 14:20 |
| zyga-ubuntu | *know | 14:20 |
| zyga-ubuntu | and any executable process needs a well-defined base | 14:21 |
| ogra_ | they *can* have hooks (note we dont have a single one that does atm) | 14:21 |
| ogra_ | currently our gadgets only have bootloader binaries and a snap.yaml with interface definitions | 14:22 |
| zyga-ubuntu | ogra_: s/will have/may have/ and I agree | 14:22 |
| niemeyer | pedronis, zyga-ubuntu: Any objections to LivePlug instead of ConnectedPlug? | 14:22 |
| pedronis | not from me | 14:22 |
| Pharaoh_Atem | oh god, I'm so confused now | 14:23 |
| niemeyer | Just want to avoid typing 24 characters every single time on every single interface | 14:23 |
| Pharaoh_Atem | niemeyer: tab completion ;) | 14:23 |
| ogra_ | zyga-ubuntu, we should make that optional so you can use gadgets without hooks still with multiple bases via models ... (so that a fedora image could be built using the existing bootloader for a board) | 14:23 |
| ogra_ | (snapcraft should handle that imho ... if there is a hook, fail the build if there isnt a base defined ... without hooks ... dont care) | 14:24 |
| niemeyer | pedronis, zyga-ubuntu: We can even dial them back to interfaces.Plug/Slot again after it's all clean and we're used to the new world | 14:26 |
| ogra_ | Pharaoh_Atem, +1000 | 14:27 |
| zyga-ubuntu | niemeyer: hmmm | 14:27 |
| ogra_ | (you cant even easily copy/paste them because of the colon currently) | 14:27 |
| zyga-ubuntu | niemeyer: LivePlug doesn't feel very clear, is there a DeadPlug or is it in some form "ready" (as in live explosives) | 14:27 |
| zyga-ubuntu | niemeyer: what made you change your mind about connected plug? | 14:27 |
| zyga-ubuntu | niemeyer: +1 on a temporary name though | 14:28 |
| niemeyer | zyga-ubuntu: I don't care right now.. will name them as ConnectedPlug as we agreed | 14:28 |
| zyga-ubuntu | niemeyer: I don't mind that, it also has a nice "unclashing" property of assumptions | 14:28 |
| zyga-ubuntu | (no prior semantics so nobody can get confused about what it used to do) | 14:28 |
| mvo | zyga-ubuntu: slightly bad news, bug 1667479 becomes an issue when playing with bases, i.e. when testing and installing bases then the things that consume bases hit this bug, I think morphis just got hit by this | 14:31 |
| mup | Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479> | 14:31 |
| Pharaoh_Atem | what am I supposed to do anymore? | 14:31 |
| zyga-ubuntu | mvo: let's sync on this first thing tomorrow, I think we can solve it much how like I initially attempted, | 14:33 |
| zyga-ubuntu | mvo: with a way to work around any kernel issues | 14:34 |
| mvo | zyga-ubuntu: neat | 14:34 |
| zyga-ubuntu | mvo: for today it's too much stack, I think | 14:34 |
| mvo | zyga-ubuntu: yeah, I have some more things I need to finish as well | 14:37 |
| pstolowski | back | 15:05 |
| pstolowski | niemeyer, pedronis, zyga-ubuntu can we resume the discussion (or are you still in the HO ;) ? | 15:05 |
| niemeyer | ackk: $SNAP_DATA is probably too restrictive.. software will often want its socket in a predictable place such as /run.. that's the challenge | 15:06 |
| niemeyer | pstolowski: Just sent a summary to the forum | 15:06 |
| mvo | roadmr: I replied, please let me know if there is aynthing unclear | 15:06 |
| roadmr | thanks mvo | 15:06 |
| niemeyer | Stepping out for lunch | 15:07 |
| pedronis | pstolowski: https://forum.snapcraft.io/t/preparing-the-interfaces-logic-for-connection-hooks/2184 | 15:08 |
| pstolowski | niemeyer, thanks, reading | 15:10 |
| === ikey is now known as ikey|work | ||
| === chihchun is now known as chihchun_afk | ||
| ackk | niemeyer, yeah, for instance LXD expects it as $LXD_DIR/unix.socket | 15:14 |
| pstolowski | niemeyer, great summary, looks like a sensible plan. thanks for detailing that! | 15:29 |
| mup | PR snapd#3937 closed: interfaces/udev: only 'trigger --action=change', not 'control --reload-rules' <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3937> | 15:32 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| cachio | mvo, about the service snapd.autoimport.service | 16:09 |
| cachio | it is in state Active: inactive (dead) since Thu 2017-09-14 14:33:18 UTC; 4 days ago | 16:09 |
| cachio | it is making the tests fail on db | 16:10 |
| cachio | mvo, should be enough with status=0/SUCCESS? | 16:10 |
| mzanetti | mvo, ondra: hi there. The "After=network-online.target" doesn't seem to help | 16:11 |
| ondra | mvo some other ideas what to try? | 16:18 |
| mup | Bug #1710637 changed: Input falls through to gdm3 and terminates the session on Ctrl+C after udevadm trigger is executed under wayland <amd64> <apport-bug> <artful> <gnome-17.10> <rls-aa-incoming> <wayland-session> <Snappy:Won't Fix> <console-setup (Ubuntu):Fix Released by cyphermox> <gdm3 | 16:18 |
| mup | (Ubuntu):Invalid> <gnome-shell (Ubuntu):Invalid> <mutter (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1710637> | 16:18 |
| === chihchun_afk is now known as chihchun | ||
| ppisati | ogra_: what did you have to do to get the bluetooth to work on the dragonboard? i'm using ubuntu classic ATM | 16:26 |
| mup | PR snapd#3943 opened: tests: fix ubuntu core services <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3943> | 16:27 |
| ogra_ | ppisati, https://bugs.launchpad.net/snappy/+bug/1674509 | 16:30 |
| mup | Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509> | 16:30 |
| ogra_ | has the full set of steps i used | 16:31 |
| ogra_ | ppisati, mainly the hciattach line and you need to power on the device with bluetoothctl | 16:31 |
| ppisati | ogra_: i guess you have this stuff in some systemd service on ubuntu core | 16:32 |
| ogra_ | we dont yet | 16:32 |
| ogra_ | the bug is still open ... but it describes what is needed | 16:33 |
| ppisati | ogra_: do you have this lp bug handy? | 16:34 |
| ogra_ | ppisati, you mean beyond the one i pasted 110 lines ago ? :) | 16:35 |
| ogra_ | *10 | 16:35 |
| ppisati | ogra_: but that is for the rpi3 | 16:35 |
| ogra_ | uh, oh | 16:35 |
| ogra_ | sorry, i totally mis-read | 16:35 |
| ogra_ | the dragonboard should be the same but without the hciattach call | 16:35 |
| ogra_ | if not, then we are missing something | 16:36 |
| ogra_ | bluetoothctl should just work afaik | 16:36 |
| ppisati | ogra_: it's an old ubuntu classic image, so i'm probably missing something | 16:36 |
| ppisati | ogra_: hcitool doesn't show anything, and just invoking 'bluetoothctl' hangs the tty | 16:36 |
| ogra_ | yeah ... you probably use the old bluez stack | 16:36 |
| ppisati | ogra_: i'm on xenial here | 16:37 |
| ogra_ | well, i'm not sure, does xenial have bluez5 at all ? | 16:37 |
| ppisati | me checks | 16:38 |
| ppisati | $ dpkg -l | grep -i blue | 16:38 |
| ppisati | ii bluez 5.37-0ubuntu5.1 arm64 Bluetooth tools and daemons | 16:38 |
| ogra_ | the snap is at 5.44 | 16:39 |
| ogra_ | but i guess it shoudl still just work | 16:39 |
| ppisati | i think i'm gonna try with ubuntu core, and see if i can deduct what's going on | 16:39 |
| ogra_ | ppisati, https://forum.snapcraft.io/t/wifi-and-bluetooth-on-snappy-ubuntu-on-a-dragonboard/1297/9?u=ogra | 16:40 |
| ogra_ | so it just works here ... | 16:40 |
| ogra_ | your bluetoothctl call should actually give you a shell, it definitely does here | 16:41 |
| ppisati | ogra_: ok, i'll give it a try with a more recent bluez stack, let's see | 16:43 |
| ogra_ | if that doesnt work either i'D guess there is firmware missing | 16:44 |
| ogra_ | assuming the kernels are actually identical | 16:45 |
| ppisati | ogra_: yep, same kernel, and i installed the linux-firmware-snapdragon package - so that should be fine, i don't see any 'missing fw' msg in dmesg | 16:45 |
| ogra_ | your wlan works fine ? | 16:46 |
| ppisati | ogra_: let me try ubuntu core, and see if i can grasp what's going on there | 16:46 |
| ppisati | ogra_: i can see the wlan0, but i didn't attach to my wifi network | 16:46 |
| ogra_ | (we did have to jump through some hoops to fix the MAC addresxs handling of that weirdly broken driver) | 16:46 |
| ogra_ | i wonder if that would influence BT behaviour | 16:46 |
| Chipaca | niemeyer: 0*: bad epoch, or equivalent to 0? | 16:55 |
| Chipaca | niemeyer: yes i will transcribe this to the forum | 16:55 |
| mvo | cachio: re snapd.autoimport.service> yes, the SUCCESS is enough | 17:00 |
| mvo | if we can get a second review for 3835 it can go in | 17:02 |
| mvo | also 3807 | 17:04 |
| mup | PR snapd#3814 closed: interfaces: enable partial apparmor support <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3814> | 17:05 |
| cachio | mvo, this is the log | 17:05 |
| cachio | https://paste.ubuntu.com/25573688/ | 17:05 |
| mzanetti | ondra: also, makes me think... even if the network-online.target would work for me, Simon has no ipv6 setup except the zigbee interface in our device... so in his case ipv6 only DNS resolving would never work. | 17:07 |
| mup | PR snapd#3889 closed: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3889> | 17:10 |
| mvo | cachio: oh, " Main PID: 1301 (code=exited, status=1/FAILURE)" woudl be really good to figure out why that failed, any hints in /var/log/syslog or anything? | 17:10 |
| mzanetti | altough, manually restarting snapd at a later point makes it work... so... dunno, really | 17:11 |
| cachio | mvo, no yes, checking | 17:17 |
| cachio | no yet | 17:17 |
| mup | PR snapd#3927 closed: tests: only run tests/regression/nmcli on amd64 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3927> | 17:23 |
| cachio | mvo, not able to get any other log | 17:24 |
| cachio | mvo, this error is from the nightly execution | 17:24 |
| cachio | i am gonna run in a vm here now to see the log | 17:25 |
| mvo | cachio: thank you | 17:26 |
| mvo | cachio: I call it a day, but I'm keen to hear tomorrow what you figured out | 17:26 |
| cachio | mvo, SURE | 17:26 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | niemeyer: i have some questions: https://play.golang.org/p/AA24O9k_oo | 17:56 |
| niemeyer | Chipaca: I'm almost alive again.. will just grab a mate and we can talk if you still have some minutes | 18:07 |
| Chipaca | niemeyer: heh. i didn't expect an answer until tomorrow (but i am still here for a bit) | 18:09 |
| niemeyer | Chipaca: Okay, checking it out | 18:20 |
| niemeyer | Chipaca: For 0*, I think that's an error | 18:22 |
| Chipaca | ok | 18:23 |
| Chipaca | niemeyer: the others are questions about the behaviour of go-yaml :-) | 18:23 |
| niemeyer | Chipaca: We have no -1 epoch of course, so it would be a clear exception and perhaps an indication that there's a misunderstanding about how it works | 18:23 |
| niemeyer | Chipaca: Vaguely, what should I be looking for there? | 18:25 |
| niemeyer | Chipaca: The fact strings always unmarshal? | 18:25 |
| Chipaca | niemeyer: if you run that pastebin (sadly it won't run directly), you'll notice that the custom unmarshaller isn't called in a couple of cases | 18:25 |
| Chipaca | in particular, for an empty string, the yaml.Unmarshal call returns an error, but the unmarshaller never got a say | 18:26 |
| Chipaca | also for the null value it isn't called, but at least no error is returned | 18:26 |
| Chipaca | it just assumes that null value means empty value, which isn't true for us | 18:27 |
| Chipaca | (to be clear, these won't block my work, but they were weird enough that i thought i'd check with you if it's working as expected) | 18:28 |
| niemeyer | Chipaca: Weird.. for the null case I sort of expected it to not be called | 18:28 |
| niemeyer | Chipaca: But I cannot see the behavior on the empty string | 18:28 |
| Chipaca | niemeyer: "cannot see" in the sense of "cannot understand"? | 18:29 |
| niemeyer | Chipaca: No.. I get no errors see | 18:29 |
| niemeyer | Argh | 18:29 |
| niemeyer | Chipaca: I get no errors here | 18:29 |
| Chipaca | niemeyer: running that code? | 18:29 |
| niemeyer | --- `a: ""`: | 18:29 |
| niemeyer | struct { A main.Foo }{A:main.Foo{X:"", Y:true}} | 18:29 |
| Chipaca | wat | 18:29 |
| Chipaca | --- `a: ""`: | 18:30 |
| Chipaca | yaml: unmarshal errors: | 18:30 |
| Chipaca | line 1: cannot unmarshal !!str `` into main.Foo | 18:30 |
| niemeyer | Chipaca: Let me update my package | 18:30 |
| Chipaca | niemeyer: go 1.6? | 18:30 |
| niemeyer | Chipaca: There might be changes in tip of go-yaml itself that I don't have | 18:30 |
| Chipaca | and i'm on tip? | 18:30 |
| Chipaca | (i'm on whatever get-deps got) | 18:31 |
| Chipaca | niemeyer: i thought you were the go-yaml guy? | 18:31 |
| niemeyer | Chipaca: Nope, still runs fine | 18:31 |
| niemeyer | Chipaca: Thankfully I have other people maintaining it by now | 18:31 |
| Chipaca | niemeyer: what version of go? | 18:31 |
| niemeyer | Roger Peppe specifically | 18:32 |
| niemeyer | Chipaca: tip | 18:32 |
| Chipaca | niemeyer: can you try with 1.6? | 18:32 |
| niemeyer | Chipaca: But I don't expect that to count.. yeah, sure.. let me find it :) | 18:32 |
| Chipaca | :-) | 18:32 |
| niemeyer | Chipaca: Still works | 18:34 |
| Chipaca | ok... | 18:34 |
| Chipaca | … | 18:34 |
| niemeyer | Chipaca: It's probably the proximity with me.. it knows that if it breaks in front of me I will fix it | 18:34 |
| Chipaca | niemeyer: so, i just go got it, and it works | 18:35 |
| Chipaca | so whatever go get gets, works | 18:35 |
| Chipaca | which is good | 18:35 |
| Chipaca | but whatever we have in snappy doesn't? | 18:35 |
| niemeyer | Chipaca: Ah, okay.. so probably something that was fixed back then | 18:35 |
| Chipaca | niemeyer: and whatever we have in vendor is also ok | 18:37 |
| Chipaca | because get-deps is no longer updating outside of vendor | 18:37 |
| Chipaca | so i still have leftover crud | 18:37 |
| Chipaca | :-( | 18:37 |
| Chipaca | niemeyer: thank you :-) | 18:37 |
| * Chipaca wipes it all clean | 18:38 | |
| niemeyer | Chipaca: np, and quite curious indeed | 18:38 |
| Chipaca | ok, i'm off to walk the dog and make dinner (or viceversa) | 18:40 |
| Chipaca | niemeyer: take care, and get more sleep | 18:40 |
| Chipaca | niemeyer: sleep is good for you, keeps the cray-cray away | 18:40 |
| niemeyer | Chipaca: Thanks, enjoy your evening and hope the dog tastes good | 18:41 |
| niemeyer | I should probably not make that sort of joke on such a diverse community :) | 18:42 |
| Chipaca | niemeyer: 🌭 | 18:44 |
| niemeyer | Chipaca: One of our favorite bad jokes was translating that to Spanish literally | 18:45 |
| Chipaca | niemeyer: there was a skit we'd do where we spoke in Bad Translator Accent, and talk about carros and perros calientes | 18:48 |
| Chipaca | we were all sorts of fun | 18:48 |
| * Chipaca ~> really off now | 18:48 | |
| mup | PR snapcraft#1555 opened: store: switch to new endpoints <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555> | 19:02 |
| diddledan | ogra_: I got ring working | 19:20 |
| diddledan | ogra_: this is the yaml which worked for me: https://www.irccloud.com/pastebin/JFeIwqQr/ | 19:22 |
| diddledan | I'll pop it on github in a sec | 19:23 |
| diddledan | there ya go: https://github.com/diddledan/ring-snap | 19:24 |
| mup | Issue snapcraft#1556 opened: build-snaps recording <design-required> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1556> | 19:26 |
| elopio[m] | Hello from riot.im ! | 19:56 |
| sergiusens | elopio[m] inovative ;-) | 19:56 |
| elopio[m] | I'm from the future. | 19:56 |
| === elopio[m] is now known as elopio | ||
| sergiusens | diddledan do you have an example on how to build a nice project using jhbuild and snapcraft? | 20:19 |
| diddledan | sergiusens: older builds of corebird used jhbuild: snapcraft.yaml: https://go.bwlh.at/2xkN0ga corebird.modules file in parent directory: https://go.bwlh.at/2w5UUHs full repo at latest commit which uses jhbuild: https://go.bwlh.at/2xv37bA | 20:36 |
| diddledan | I specifically used jhbuild because a lot of gnome stuff it required were newer than 16.04 provided, but I've since moved to using the gnome-3-24 platform snap and ppa | 20:38 |
| diddledan | jhbuild was the easiest way I could find to reliably build the gnome deps | 20:38 |
| sergiusens | diddledan boo, is `jhbuild` now abandonware? :-) | 20:43 |
| diddledan | I think it's still usefull, but people keep moaning at me for large download sizes :-( | 20:50 |
| diddledan | of snaps* | 20:51 |
| diddledan | I particularly like it for the ability to build on other people's work because you can import other *.modules files from gnome for example which are prepared with all the relevant dependencies and build info for stuff you might rely on | 20:54 |
| fmulti | hi, im behind a corporate proxy and cant get snap to install anything due to the x509 certificate checking | 20:55 |
| fmulti | same issue as https://forum.snapcraft.io/t/certificate-substitution-and-snaps/1077 but cant find any resolution | 20:55 |
| elopio | sergiusens: I would remove this sentence from the release notes: (for the case of today of only supporting one base) | 21:07 |
| elopio | sergiusens: the build-snaps section has a sentence that's not finished: "This release exposes the feature through" | 21:12 |
| === elopio is now known as elopio2 | ||
| === elopio2 is now known as elopio | ||
| mwhudson | i can't cleanbuild snapcraft master | 22:17 |
| mwhudson | fails with "mkdir: cannot create directory ‘build’: File exists" | 22:18 |
| mwhudson | during the build of apt it seems | 22:18 |
| mwhudson | well ok this is my hacked up version, not master but my changes really shouldn't have caused this :) | 22:18 |
| kyrofa | mwhudson, I get that if I try to build snapcraft from snapcraft src | 22:19 |
| mwhudson | yes, that's what i mean | 22:19 |
| kyrofa | mwhudson, my solution was to build it using the deb or snap instead | 22:19 |
| mwhudson | oh | 22:19 |
| kyrofa | There's _something_ weird there | 22:20 |
| mwhudson | yeah ok i have the snap i built from master earlier installed | 22:20 |
| mwhudson | so if i refresh that back to candidate it'll work? | 22:20 |
| mwhudson | bah | 22:21 |
| mwhudson | reverting from a local snap to the store should be easier than this i think | 22:21 |
| kyrofa | mwhudson, I don't think you should be able to install local over the store or vice-versa. They could be completely different snaps, but now you're sharing data | 22:24 |
| kyrofa | If it's not associated with the store, it could be named anything | 22:24 |
| mwhudson | i guess | 22:25 |
| Hilikus | hello. i'm trying to understand when do i need to create a custom gadget snap. can someone explain this to me. i see for example a pi2 and pi3 image, but there's also a i386 and amd64 image. is the gadget snap per architecture? how come the pi image is not ARMv7 image? | 22:50 |
| kyrofa | Hilikus, normally I'd refer you to ogra_, but it's pretty late for him | 22:54 |
| kyrofa | Hilikus, so I'll do my best :) | 22:54 |
| Hilikus | awesome :) | 22:54 |
| kyrofa | Gadgets have a number of responsibilities. They contain the bootloader, and they also are responsible for exposing the hardware of the board to the rest of the system | 22:55 |
| kyrofa | Hilikus, so yes, they are not only arch specific, but hardware specific | 22:55 |
| kyrofa | Reference platforms, such as the rpi2/3, amd64, etc. have a gadget already created for them | 22:56 |
| kyrofa | But if you're using other hardware, you may have to write one | 22:56 |
| kyrofa | So there's one reason to write one. Another reason is that perhaps the hardware isn't being exposed quite how you're like using the official gadget. An example of this is serial ports: gadgets are the only place you can specify udev-like rules to get serial ports consistently mounted and provided to snaps in a confined manner | 22:57 |
| kyrofa | As for the pi image arch, I'm afraid I can't field that one | 22:58 |
| Hilikus | what exactly does "other hardware" mean? where i get confused is with the i386 and amd64 images. does that mean that i can buy any embedded computer kind of machine and as long as it's an x86 32 or 64bit then i can use the i386 or amd64 images? if not, for what exact type of i386 and amd64 where those made? would they work in a desktop? server? | 22:58 |
| Hilikus | by having an i386 and amd64 i get the idea that this image will work almost anywhere as long as the arch matches, but based on what i read from the gadget snap that's not the case | 22:59 |
| kyrofa | Yeah as a general rule that's not the case, but amd64 and i386 gadgets are a little more general purpose as I don't imagine they expose any specific hardware and use grub | 22:59 |
| kyrofa | You can use them in virtualbox, for example | 23:00 |
| kyrofa | Or on a NUC | 23:00 |
| kyrofa | Kernels are often device-specific as well | 23:00 |
| Hilikus | really? i thought the kernel snap was only arch dependent | 23:02 |
| mup | PR snapcraft#1557 opened: cleanbuild: add a --image option to build in a different image <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1557> | 23:03 |
| Hilikus | ok, so if udev is really configured in the gadget snap then i think that's clear to me. i can't for example use the x64 ubuntu core image and configure my bluetooth or NFC adapter in it | 23:03 |
| Hilikus | i would have to create an image specifically for the peripheral I want to control | 23:04 |
| kyrofa | Hilikus, well, other interfaces might cover that. I know there are bluez interfaces | 23:16 |
| kyrofa | But I've not experimented with them | 23:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!