| === wgrant__ is now known as wgrant | ||
| zyga-solus | good morning | 05:31 |
|---|---|---|
| zyga-solus | mwhudson: I'll look into packaging this week | 05:35 |
| zyga-solus | mwhudson: sorry for not having any time for that lately | 05:35 |
| zyga-solus | good morning mvo :) | 05:37 |
| zyga-solus | mvo: I got a +1 from jdstrand on 4008, could you please do 2nd review? | 05:38 |
| zyga-solus | mvo: that branch is on the critical path towards layouts | 05:39 |
| zyga-solus | mvo: and I'd love it if we could pull it into 2.29.2 | 05:39 |
| mvo | hey zyga-solus - good morning | 05:40 |
| === JanC_ is now known as JanC | ||
| mvo | zyga-solus: pr looks very good, I added some cosmetic suggestions and I'm fine pulling this in for 2.29 | 06:06 |
| zyga-solus | thank you | 06:12 |
| === chihchun_afk is now known as chihchun | ||
| kalikiana | good morning, snappy | 06:46 |
| zyga-solus | good morning kalikiana | 06:53 |
| mwhudson | zyga-solus: me neither | 07:31 |
| mwhudson | zyga-solus: i refreshed the patches, so i think it's build-dep updates and try to build | 07:31 |
| zyga-solus | thank you, that sounds good | 07:32 |
| mwhudson | let me check i pushed that much to alioth :) | 07:32 |
| zyga-solus | thank you :) | 07:34 |
| mwhudson | seems i did! | 07:35 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| Tribaal | hi folks! I just got an extra rasperri pi 3 and would love to use it for Ubuntu core. What would you all use it for? Nextcloud? | 08:02 |
| Tribaal | what's the new snapped hotness? :p | 08:02 |
| zyga-solus | mvo: hey | 08:07 |
| zyga-solus | mvo: I updated 4008 | 08:07 |
| zyga-solus | mvo: could you please look at secureMkdirAll again? I'm not using defer but if you feel strongly about it I can reiterate | 08:08 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| mvo | zyga-solus: thanks, I check it out. out of curiosity, whats wrong with defer there? | 08:14 |
| zyga-solus | mvo: nothing technically, there are two reasons (perhaps three) that I didn't use defer for | 08:14 |
| zyga-solus | mvo: it was a rewrite from C and I kept the style | 08:15 |
| zyga-solus | mvo: I check for all possible errors, including from close (unless already handling an error) | 08:15 |
| zyga-solus | mvo: and defer would keep more FDs open then we need (one for each path segment) | 08:15 |
| zyga-solus | mvo: if you prefer defer I can re-work the code to use defer and adjust tests to match | 08:15 |
| mvo | zyga-solus: ok, that makes sense. I was thinking the fd usage would be it | 08:16 |
| zyga-solus | mvo: it's not a very strong argument arguably as in typical cases it would keep a handful of FDs open at most | 08:17 |
| zyga-solus | mvo: I'll try defer quickly, if it's not too ugly we can merge that ;) | 08:17 |
| zyga-solus | mvo: pushed with defer | 08:23 |
| zyga-solus | mvo: have a look at patch here please: https://github.com/snapcore/snapd/pull/4008/commits/1a4d21279aedfbad71357ee031cca068af8e4850 | 08:24 |
| mup | PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008> | 08:24 |
| * zyga-solus -> ENOTEA brb | 08:24 | |
| mvo | zyga-solus: it says "done" to the rename of EnsureMountPointImpl but the name is still EnsureMountPointImpl not EnsureMountPoint ? | 08:25 |
| mvo | zyga-solus: I like it but no super strong opinion either, just feel more "natural" | 08:27 |
| zyga-solus | mvo: oh, I must have missed it, I renamed the other Impl, correcting now | 08:50 |
| skjensen | Morning guys, I have got past the error I had yesterday building the image for the jetson tk1. I'm now at step 8: populate_filesystems. But I'm missing the MLO. | 08:51 |
| zyga-solus | no, wait, I dropped that patch entirely :/ | 08:51 |
| skjensen | I have tried to go through the uboot build steps in a terminal and it isn't building the MLO, anyone who can point me in the right direction of figuring out how to build a MLO or why ubuntu-image build expects to find one? | 08:52 |
| zyga-solus | skjensen: sorry, I don't know much about uboot :/ | 08:53 |
| zyga-solus | mvo: ok, all done now | 08:53 |
| * zyga-solus didn't make tea but instead walked his daughter to school to help | 08:54 | |
| Chipaca | zyga-solus: to help what? | 08:55 |
| zyga-solus | Chipaca: to help her, it's raining all the time and her backpack was very heavy today | 08:55 |
| Chipaca | zyga-solus: you're supposed to let the rain water get out of the backpack | 08:56 |
| zyga-solus | :D | 08:58 |
| zyga-solus | Chipaca: how would they have their swimming classes if I did? | 08:58 |
| Chipaca | zyga-solus: fair point | 08:59 |
| pedronis | mvo: hi, did you see my comment from last evening? | 08:59 |
| zyga-solus | Chipaca: can I frame you into a review of one function? | 09:00 |
| Chipaca | zyga-solus: you can try | 09:00 |
| zyga-solus | Chipaca: can you please have a look at secureMkdirAll in 4008 please | 09:00 |
| zyga-solus | Chipaca: it's very sensitive to get right and mvo found a bug already today | 09:00 |
| mvo | pedronis: yeah, I think it makes sense. I have no managed to start with it though but I think I'm done with the xdg-settings for now until I get a review from jamie again so I will look at it next | 09:02 |
| pedronis | mvo: thx | 09:05 |
| Chipaca | zyga-solus: I don't understand your answer wrt path vs path/filepath | 09:05 |
| pstolowski | mvo, hey, the autokpgtest failure on 4072 look unrelated to the change (spread passed), i think it's safe to merge isn't it? | 09:06 |
| Chipaca | zyga-solus: filepath is path for filesystem stuff, path is a more generic thing (for, say, the web) | 09:06 |
| pedronis | Chipaca: snapd#4075 needs a review, it's mostly undoing a previouw checking and starting going in a different direction (in store/ ) | 09:06 |
| mup | PR #4075: many: reorg things in preparation to make handling of the base url in store dynamic <Created by pedronis> <https://github.com/snapcore/snapd/pull/4075> | 09:06 |
| zyga-solus | Chipaca: aha | 09:06 |
| Chipaca | pedronis: a'ight, i'll get to it after looking at zyga's | 09:07 |
| zyga-solus | Chipaca: I didn't get that, I'll switch to filepath | 09:07 |
| zyga-solus | Chipaca: done | 09:08 |
| mvo | pstolowski: indeed, thank you | 09:08 |
| mup | PR snapd#4072 closed: daemon: use newChange() in changeAliases for consistency <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4072> | 09:08 |
| Chipaca | zyga-solus: path.go still uses path though | 09:10 |
| zyga-solus | Chipaca: path.go? | 09:11 |
| zyga-solus | ah I see | 09:12 |
| Chipaca | OTOH grepping shows a few places | 09:12 |
| Chipaca | maybe i should fix in a separate pr | 09:12 |
| zyga-solus | done | 09:12 |
| zyga-solus | pushed | 09:13 |
| Chipaca | zyga-solus: jamie asked that you add a comment about why secureMkdirAll doesn't take relative paths, and you said 'done', but i don't see the comment; is it somewhere else? | 09:15 |
| zyga-solus | Chipaca: man, I added that comment, did I break my rebase? | 09:15 |
| * zyga-solus looks | 09:15 | |
| zyga-solus | yep | 09:16 |
| zyga-solus | it's not there :/ | 09:16 |
| * zyga-solus looks at reflog | 09:16 | |
| zyga-solus | pushed | 09:17 |
| * Chipaca worries | 09:18 | |
| zyga-solus | I just checked, nothing else is lost | 09:20 |
| mvo | mwhudson: could you please check https://bugs.launchpad.net/ubuntu/+source/golang-1.7/+bug/1726706 and comment if that is safe? there is concern from the sru team that this changes existing behavior on unrelated architectures | 09:22 |
| mup | Bug #1726706: Fails to build snapd on ppc64el <golang-1.7 (Ubuntu):Fix Released> <golang-1.7 (Ubuntu Zesty):New> <https://launchpad.net/bugs/1726706> | 09:22 |
| Chipaca | zyga-solus: how much bikeshedding is acceptable on this? | 09:24 |
| Chipaca | zyga-solus: 3? :-) | 09:24 |
| zyga-solus | Chipaca: any amount, what else did you find? | 09:24 |
| mwhudson | mvo: sure | 09:25 |
| pstolowski | mvo, looks like Sergio has been waiting for your feedback on 3994 (and it's a very small change) | 09:25 |
| Chipaca | zyga-solus: i'll comment on the pr | 09:25 |
| mvo | pstolowski: thanks, I just checked and have the same question as you :) | 09:27 |
| pstolowski | good :) | 09:27 |
| mwhudson | mvo: where did the sru team express their concerns? | 09:30 |
| mvo | mwhudson: on irc via /query *cough* | 09:30 |
| mwhudson | mvo: hooray | 09:30 |
| seb128 | mvo, hey, do you know what's the status of making classic snaps to work on 17.10? | 09:31 |
| mvo | mwhudson: I will ask apw to voice his concern about https://launchpad.net/bugs/1726706 in the bug :) but if you can just confirm its an ok change (with your golang maintainer/upstream head on, that would be great) | 09:32 |
| mup | Bug #1726706: Fails to build snapd on ppc64el <golang-1.7 (Ubuntu):Fix Released> <golang-1.7 (Ubuntu Zesty):New> <https://launchpad.net/bugs/1726706> | 09:32 |
| mwhudson | mvo: done | 09:32 |
| mvo | seb128: I'm not sure we are tracking this right now, aiui snapcraft is working on a fix, maybe kalikiana knows more? | 09:32 |
| mvo | mwhudson: thank you! | 09:32 |
| seb128 | mvo, seems like an important issue? we have projects that were trying to go the snap way and are considering not doing that after all and going back to some other format since snaps don't work for them on current Ubuntu :-/ | 09:34 |
| mvo | seb128: yes, it sucks. I will raise it during the standup to make sure it gets attention and a proper analysis. is there a forum topic already? | 09:35 |
| ogra_ | seb128, i think snapcraft works on droopping all LD_LIBARY_PATH stuff for that and to make all classic snaps use rpath ... | 09:37 |
| * ogra_ looks fo the PR ... | 09:37 | |
| Chipaca | zyga-solus: i was wrong :-) | 09:38 |
| zyga-solus | Chipaca: about what? | 09:39 |
| ogra_ | seb128, https://github.com/snapcore/snapcraft/pull/1632 and https://github.com/snapcore/snapcraft/pull/1635 (seems both are merged in master already... though i guess all existing classic snaps need to be re-built) | 09:42 |
| mup | PR snapcraft#1632: libraries: exclude the full set of libc6 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1632> | 09:42 |
| mup | PR snapcraft#1635: snap: remove leaking LD_LIBRARY_PATH <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1635> | 09:42 |
| seb128 | mvo, ogra_, thanks | 09:43 |
| kalikiana | mvo: Fix for...? | 09:44 |
| seb128 | mvo, https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/ is the forum post ... from what ogra_ replied it seems to be worked, would still be good to make sure it's properly tracked and know when it might land | 09:44 |
| * kalikiana reading the backlog | 09:44 | |
| seb128 | kalikiana, ^ | 09:44 |
| seb128 | ogra_, kalikiana, mvo , could somebody post an update on that forum topic? it has several users asking for a status update in the course of the recent weeks and they just got silence in return so far | 09:45 |
| kalikiana | seb128: Good call. We've got some fixes for library exclusion and LD_LIBRARY_PATH handling in the pipeline. Will have to check exactly which bits apply to this topic | 09:46 |
| ogra_ | seb128, well, kyrofa and sergiusens have been working on it ... either of them should be able to give updates (i dont know more than whats in the discussion and the PRs) | 09:46 |
| seb128 | kyrofa, sergiusens, ^ could you update that forum post before we get people who consider stopping their snap actually doing that because they feel like the system is buggy and nobody cares to update them on the issues? | 09:52 |
| Chipaca | zyga-solus: curse you! why am i reading open_by_handle_at(2) at this time of the morning | 09:55 |
| ogra_ | Chipaca, dude! now you made us all read it ! | 09:56 |
| Chipaca | ogra_: it's all dem bionic badgers | 09:57 |
| ogra_ | heh | 09:57 |
| zyga-solus | Chipaca: haha | 10:02 |
| zyga-solus | Chipaca: I read it too, did you find anything interesting? | 10:03 |
| Chipaca | zyga-solus: no, it nerdsniped me, is all | 10:06 |
| Chipaca | zyga-solus: commented on the pr | 10:06 |
| zyga-solus | Chipaca: thank you | 10:09 |
| zyga-solus | Chipaca: I can add O_PATH easily | 10:10 |
| zyga-solus | Chipaca: please look at the defer vs hand-made cleanup response | 10:10 |
| mup | PR snapd#4052 closed: tests: check for invalid udev files during all tests <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4052> | 10:10 |
| Chipaca | zyga-solus: yes i know you added the defers | 10:10 |
| Chipaca | zyga-solus: i thought the better solution would be to move the body of the loop to a helper, but it doesn't help | 10:10 |
| pstolowski | Chipaca, hey, 4050 has a conflict | 10:11 |
| Chipaca | (that's why it took me some time to review: i wrote what i thought would help, and it didn't) | 10:11 |
| Chipaca | pstolowski: lies! | 10:11 |
| * Chipaca looks | 10:11 | |
| pstolowski | :) | 10:11 |
| Chipaca | a PR that's been open for over a week, having a conflict? i'm shocked | 10:11 |
| Chipaca | fixing... | 10:12 |
| zyga-solus | Chipaca: yes, I was thinking about that but there's no nicer way with defer | 10:12 |
| zyga-solus | Chipaca: python refcount would be better | 10:12 |
| mup | PR snapd#4007 closed: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4007> | 10:13 |
| Chipaca | zyga-solus: not really, as the refcount cleanup is not deterministic | 10:13 |
| Chipaca | zyga-solus: at least with defers when you're done you're done | 10:13 |
| zyga-solus | Chipaca: in CPython it is deterministic | 10:14 |
| Chipaca | true | 10:15 |
| Chipaca | but who still uses cpython :-p | 10:15 |
| * Chipaca knows the answer is 'everybody' | 10:15 | |
| Chipaca | mvo: remember `tidyNoticef`? did you have a better name in mind? | 10:17 |
| Chipaca | i'm touching that pr anyway to resolve a conflict so i might as well address this | 10:17 |
| seb128 | kalikiana, thanks for posting on that forum discussion | 10:20 |
| kalikiana | Sure. Thanks for bring it up. I try to follow what's going on but sometimes it's just a lot to read. | 10:20 |
| Chipaca | i hadn't noticed github's favicon now shows the state of the tests | 10:30 |
| Chipaca | nice | 10:30 |
| skjensen | Is it possible to unpack a gadget snap? | 10:32 |
| mvo | Chipaca: hm, I need to think about a better name but names are hard | 10:33 |
| Chipaca | skjensen: you can unpack it with unsquashfs, or you can mount it by hand | 10:33 |
| zyga-solus | Chipaca: updated again | 10:34 |
| Chipaca | skjensen: snaps are just squashfs | 10:34 |
| skjensen | Excellent.. Thanks I will try that and try understand what I have packed down into the gadget.. :) | 10:34 |
| Chipaca | :-) | 10:34 |
| Chipaca | zyga-solus: ack. On samuele's pr now, i'll check back later (unless i forget :-) | 10:35 |
| zyga-solus | thank you! | 10:35 |
| zyga-solus | I'll look at my other PRs that are close to landing | 10:35 |
| Chipaca | mvo: I'll just call it noticef, and add a comment | 10:36 |
| mvo | Chipaca: ok | 10:41 |
| pstolowski | Chipaca, got travis failure on completion test https://travis-ci.org/snapcore/snapd/builds/292510395?utm_source=github_status&utm_medium=notification , thought you might want to know | 10:53 |
| Chipaca | pstolowski: in prepare | 10:54 |
| Chipaca | nice one | 10:55 |
| Chipaca | 'tar: /var/lib/snapd: file changed as we read it' | 10:55 |
| niemeyer | pedronis: About your comment yesterday, perhaps the right place is indeed the handler of the "configure" task handler | 11:07 |
| niemeyer | pedronis: Oh, wait.. the task is actually a hook task | 11:08 |
| niemeyer | Hmm | 11:08 |
| pedronis | niemeyer: yea, so a level up | 11:08 |
| pedronis | configstate.Configure | 11:08 |
| pedronis | which needs to create the hook task or a different one | 11:08 |
| pedronis | unless we had overriding pluggability into hooks themselves | 11:08 |
| pedronis | which seems a bit overkill unless we have another use case | 11:09 |
| niemeyer | pedronis: The cheapest seems to be intercepting it within the hook handler itself | 11:09 |
| niemeyer | pedronis: Well.. or we just have a new handler inside configstate | 11:10 |
| pedronis | the 2nd one was my idea | 11:10 |
| pedronis | I mean hacking in doRunHook is probably cheap but is strange unless we do it as a general mechanism, but then is not that cheap anymore | 11:11 |
| niemeyer | pedronis: Sounds good.. these other options in HookSetup probably don't make much sense either way | 11:12 |
| niemeyer | pedronis: "configure-snapd"? | 11:12 |
| pedronis | sounds reasonable | 11:13 |
| pedronis | mvo: ^ | 11:13 |
| Facu | elopio, sergiusens, hello! do you know how could I get reviews here? https://github.com/snapcore/snapcraft/pull/1634 thanks! | 11:14 |
| mup | PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 11:14 |
| kalikiana | Facu: For some reason there was no GitHub notifications of your replies... let me have another look now. | 11:24 |
| kalikiana | So thanks for pinging on that! | 11:25 |
| Facu | kalikiana, :) | 11:25 |
| kalikiana | The other guys will be around later. I can check also who would help review | 11:25 |
| niemeyer | pedronis, mvo: https://forum.snapcraft.io/t/special-casing-the-core-configuration/2594 | 11:29 |
| kalikiana | Facu: I added some comments - I'm still slightly confused, though, regarding the arch in update_metadata... what relevance does it have there, if it's unused in the failing code path? | 11:35 |
| kalikiana | Maybe the error should be changed? | 11:36 |
| niemeyer | pedronis: When you have a moment, would you mind to pass your eyes over #4070.. I think it's good to go, but it wouldn't heart to have another pair of eyes there to check we didn't miss something | 11:36 |
| mup | PR #4070: hooks/configure: queue service restarts <Created by stolowski> <https://github.com/snapcore/snapd/pull/4070> | 11:36 |
| pstolowski | thanks niemeyer | 11:37 |
| niemeyer | pstolowski: np | 11:37 |
| Facu | kalikiana, mmm... I see that SnapNotFoundError supports *not* receiving the arch | 11:38 |
| pstolowski | niemeyer, btw, any chance to have your eyes on #4013 before your holidays? | 11:38 |
| mup | PR #4013: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4013> | 11:38 |
| mvo | niemeyer, pedronis thanks for this, I'm working on this now | 11:39 |
| Facu | kalikiana, OTOH, see for example the function get_snap_status in that file; it builds the error with the arch even if the situation that led to the error has nothing to do with the arch (it happened to have the arch because it's just used later) | 11:40 |
| pedronis | niemeyer: I'll look at 4070 in a bit | 11:42 |
| niemeyer | pedronis: Thanks! | 11:42 |
| niemeyer | mvo: np | 11:42 |
| niemeyer | ackk: PR reviewed, and LGTM | 11:42 |
| niemeyer | ackk: We need a second review on it | 11:43 |
| niemeyer | I don't recall who was involved in the socket activation conversations.. | 11:43 |
| kalikiana | Facu: I'd say rather not use it if nothing in the method does. It makes a lot more sense to me anyway | 11:44 |
| niemeyer | Ah, Chipaca would be a great reviewer here I think | 11:45 |
| niemeyer | Chipaca: #3916! | 11:45 |
| mup | PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916> | 11:45 |
| Facu | kalikiana, let's do that | 11:45 |
| niemeyer | pstolowski: Yeah, I'm hoping so.. it's looking like a long day :) | 11:46 |
| Facu | kalikiana, do you have any idea about that ACL failure in Travis? | 11:47 |
| ackk | thanks niemeyer | 11:48 |
| kalikiana | Facu: You mean CLI? Try merging master. The check can get confused when there's new commits. | 11:48 |
| kalikiana | CLA, even | 11:49 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | skjensen, MLO is only expected if you defined it ... if your board doesnt use one you indeed dont need to add it to the gadget.yaml (sorry, only saw you now in the backlog) | 11:54 |
| ogra_ | skjensen, here is an example gadget without MLO https://github.com/ogra1/nanopi-neo-gadget ... note that you need to find the right size and offset values for your board indeed ... | 11:55 |
| pedronis | niemeyer: pstolowski: about #4070, +1 with some comments | 11:55 |
| mup | PR #4070: hooks/configure: queue service restarts <Created by stolowski> <https://github.com/snapcore/snapd/pull/4070> | 11:55 |
| pedronis | and questions | 11:56 |
| pedronis | pstolowski: it seems some of your "upcoming" were in 2.28, time to remove the tags ? | 11:57 |
| niemeyer | pedronis: Good points | 11:57 |
| niemeyer | Definitely worth testing, and documenting in the snapctl description | 11:58 |
| niemeyer | pedronis, pstolowski: The flag also seems useful for the near future.. I'd wait until we have some experience, though, even to make sure we won't have to revert this decision based on user feedback | 11:58 |
| niemeyer | I'd name it as --now if it comes | 11:59 |
| pedronis | yea | 11:59 |
| pedronis | updated my comment | 12:00 |
| niemeyer | Thanks! | 12:01 |
| Facu | kalikiana, ack, will merge master, thanks | 12:01 |
| skjensen | ogra_ thanks I will try to build the snap without.. :) | 12:02 |
| skjensen | ogra_ how do you find the correct size and offset values? | 12:03 |
| ogra_ | skjensen, i think i wrote about thet in my blog ... | 12:03 |
| ogra_ | *that | 12:03 |
| skjensen | okay, I will have another read through the blog.. :) | 12:03 |
| ogra_ | https://ograblog.wordpress.com/2017/05/30/building-u-boot-gadget-snap-packages-from-source/ | 12:04 |
| ogra_ | under "creating the gadget.yaml " | 12:04 |
| ogra_ | you need to know the values typically used for your board ... then you can convert them to byte offsets and size | 12:05 |
| skjensen | yes.. | 12:06 |
| skjensen | ogra_ any chance you know the difference between u-boot.img u-boot-tegra.bin u-boot-dtb-tegra.bin u-boot-nodtb-tegra.bin I see you used the u-boot.img in your example for the bbb but the nanopo is using u-boot-sunxi-with-spl.bin so a bin file.. I got both from building u-boot so which to choose? | 12:20 |
| ogra_ | skjensen, oh, no idea, i'd start with u-boot-tegra.bin | 12:23 |
| ogra_ | try to find some docs about that from someone wh has done this before | 12:24 |
| skjensen | Okay.. | 12:24 |
| jdstrand | willcooke: hey, I had an idea about speeding up gnome snaps on first launch | 12:44 |
| jdstrand | willcooke: it isn't fully formed or anything, but snappy has this thing 'userd' that runs as the user in the user's session. it seems plausible that it could be the thing that compiles the gschemas | 12:45 |
| willcooke | jdstrand, we're planning on layouts allowing us to use the compiled schemas which should shave a couple of seconds at least of start-up | 12:49 |
| willcooke | jdstrand, I'll ask jamesh to sync with you on that topic | 12:49 |
| jdstrand | willcooke: I'm actually involved in the layouts work, so if he can solve it there, even better | 12:49 |
| willcooke | jdstrand, nice one. I'll drop James an email now anyway | 12:50 |
| pstolowski | pedronis, thanks for the review, good points. i'll check my 'upcoming' tags, thanks | 12:52 |
| Chipaca | anybody know a snap that has a service and a command? | 12:55 |
| pedronis | Chipaca: network-manager | 13:00 |
| pedronis | Chipaca: it's an interesting example though, because we don't want (for now) people installing it on classic | 13:02 |
| zyga-ubuntu | Chipaca: fun fact: no fchown with O_PATH | 13:02 |
| zyga-ubuntu | Chipaca: also, standup | 13:03 |
| noise][ | Chipaca: postgresql? | 13:05 |
| arubislander | Hi, I have a question. Say I have a snap that needs access to /tmp what interface(s) should it connect to? | 13:26 |
| zyga-ubuntu | arubislander: hey | 13:30 |
| zyga-ubuntu | arubislander: /tmp is always available but it is private to the snap | 13:31 |
| zyga-ubuntu | arubislander: no snap can use the real host-side /tmp directory | 13:31 |
| zyga-ubuntu | arubislander: there is no interface that controls this currently | 13:31 |
| zyga-ubuntu | arubislander: why do you need access to the host-side /tmp? | 13:31 |
| arubislander | Well, it was more that I am using the libreoffice snap, and every time I want to directly open a file downloaded in firefox I get a permissions error thrown. I need to save the file first to a location in my home folder. | 13:34 |
| arubislander | So I was thinking that maybe there should be an interface for /tmp access just like there is for removable media access. | 13:35 |
| arubislander | zyga-ubuntu: O, I see the convention here is to make it explicit who you are talking too. Apologies for the previous omissions. | 13:36 |
| Chipaca | noise][: the postgres snaps have no daemons | 13:38 |
| Chipaca | noise][: i suspect this is a bug | 13:38 |
| noise][ | odd. | 13:39 |
| noise][ | Chipaca: etcd has both | 13:40 |
| Chipaca | yes yes it does | 13:41 |
| jdstrand | zyga-ubuntu: 'daemon is not so portable actually'. what failed with daemon? | 13:47 |
| jdstrand | it is defined by the LSB as required | 13:47 |
| jdstrand | I'm curious because of something I am working on | 13:48 |
| zyga-ubuntu | jdstrand: solus | 13:48 |
| zyga-ubuntu | jdstrand: I switched to nobody nogroup | 13:48 |
| zyga-ubuntu | arubislander: no worries :) | 13:49 |
| zyga-ubuntu | arubislander: real /tmp is in /var/lib/snapd/hostfs/tmp but it's not accessible | 13:49 |
| zyga-ubuntu | jdstrand: I think ikey would know why daemon group is not available there :) | 13:49 |
| zyga-ubuntu | jdstrand: thank you for the reviews, I think the two branches are much better now | 13:51 |
| zyga-ubuntu | jdstrand: I'm curious to know what you are working on now | 13:51 |
| jdstrand | well, the uid/gid priv dropping work | 13:51 |
| jdstrand | but it isn't something I have much time to focus on unfortunately | 13:51 |
| zyga-ubuntu | jdstrand: uid/gid priv dropping where? I'm not familiar with this topic | 13:53 |
| zyga-ubuntu | ah | 13:53 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| zyga-ubuntu | you mean in-snap users? | 13:53 |
| zyga-ubuntu | (users and grops) | 13:53 |
| zyga-ubuntu | *groups) | 13:53 |
| jdstrand | zyga-ubuntu: that is one of 4 use cases, yes | 13:53 |
| jdstrand | https://forum.snapcraft.io/t/snappy-users-and-groups-take-2/1461 | 13:54 |
| jdstrand | the topic was renamed to focus on only one use case though... | 13:54 |
| jdstrand | ikey: fyi> http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/usernames.html | 13:55 |
| jdstrand | ikey: 'daemon' is listed under 'Required User & Group Names' | 13:55 |
| jdstrand | zyga-ubuntu: you might consider the fact that 'nobody' is optional under LSB and 'nogroup' is not lised as anything (I think 'nogroup' is a Debian-ism iirc) | 13:56 |
| jdstrand | zyga-ubuntu: perhaps your PR should use 'bin/bin' or continue to use 'daemon/daemon' and pick something else on solus? | 13:57 |
| jdstrand | anyway, I'm not blocking on that. it is just the test code | 13:57 |
| pedronis | niemeyer: would be good to have your input here https://forum.snapcraft.io/t/new-install-refresh-api-with-the-store/2269/6 if you have any immediate feedback | 13:58 |
| zyga-ubuntu | jdstrand: eh, good point | 14:02 |
| zyga-ubuntu | jdstrand: maybe I cna put a list of things and if any of those work, pass the tset | 14:02 |
| zyga-ubuntu | *test | 14:02 |
| mup | PR snapcraft#1639 opened: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639> | 14:04 |
| zyga-ubuntu | mvo: FYI, I just want to get this under someone's radar: https://bugs.launchpad.net/snappy/+bug/1723881 | 14:13 |
| mup | Bug #1723881: [Feature Request] Support pre-invoke and post-invoke commands as DPkg::Pre-Invoke and DPkg::Post-Invoke in APT <Snappy:New> <https://launchpad.net/bugs/1723881> | 14:13 |
| * zyga-ubuntu breaks for lunch | 14:16 | |
| arubislander | zyga-ubuntu: thanks for the info. /tmp not being accessible, is that a confinement security based decision? | 14:29 |
| * jdstrand -> errands and lunch | 14:34 | |
| Chipaca | mvo: can i nominate #4050 for 2.19rcN? | 14:41 |
| mup | PR #4050: cmd/snap: tell translators about arg names and descs req's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4050> | 14:41 |
| Chipaca | mvo: also can i have a review of it :-) | 14:42 |
| om26er | hey popey, can you share the snapcraft.yaml of yakyak, probably a comment here: https://github.com/yakyak/yakyak/issues/741 would be nice. | 14:43 |
| zyga-ubuntu | arubislander: yes | 14:44 |
| zyga-ubuntu | arubislander: for isolation each snap sees a private /tmp | 14:44 |
| om26er | popey: someone actually proposed snap packaging a few months ago for yakyak: https://github.com/yakyak/yakyak/pull/752 but that didn't go much far. (and the diff looks weird) | 14:45 |
| mup | PR yakyak/yakyak#752: Added Snap Support <Created by OctoPenguin> <https://github.com/yakyak/yakyak/pull/752> | 14:45 |
| cachio | mvo, is this the error that you mentioned in trusty https://paste.ubuntu.com/25817308/ | 14:45 |
| cachio | ? | 14:45 |
| zyga-ubuntu | darn, I didn't plug my laptop and it suspended | 14:46 |
| kyrofa | ogra_, kalikiana seb128 mvo not completely fixed yet, but definitely a high priority | 14:48 |
| kyrofa | ogra_, kalikiana seb128 mvo we've landed a few PRs that make progress, but we're still missing patchelf changes | 14:49 |
| kyrofa | Which is in progress | 14:49 |
| kyrofa | I'll update the forum thread | 14:49 |
| kalikiana | +1 | 14:49 |
| kyrofa | seb128, thank you for the ping, we should have been updating it as we made progress | 14:49 |
| mvo | cachio: I have not seen this one yet :/ | 14:50 |
| cachio | mvo, ok | 14:51 |
| seb128 | kyrofa, thanks | 14:52 |
| mup | PR snapd#3989 closed: client, daemon: rest api to configure store api <Blocked> <Created by atomatt> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3989> | 15:05 |
| elopio | snappy-m-o 1630 xenial:amd64:integrationtests | 15:05 |
| mup | PR snapd#3990 closed: cmd/snap,client,daemon: support set/unset of store front <Blocked> <Created by atomatt> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/3990> | 15:06 |
| elopio | snappy-m-o autopkgtest 1630 xenial:amd64:integrationtests | 15:08 |
| snappy-m-o | elopio: I've just triggered your test. | 15:09 |
| zyga-ubuntu | hrm | 15:11 |
| pedronis | Chipaca: any reason not to merge #4062, you addressed the objection afaict. | 15:11 |
| mup | PR #4062: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <https://github.com/snapcore/snapd/pull/4062> | 15:11 |
| Chipaca | pedronis: I did, but I don't like to merge while it's still 'changes requested' | 15:13 |
| Chipaca | although I now see a "dismiss review" button | 15:13 |
| * Chipaca grins evily | 15:13 | |
| === cachio_ is now known as cachio_lunch | ||
| kyrofa | snappy-m-o, autopkgtest 1636 xenial:amd64 | 15:14 |
| snappy-m-o | kyrofa: I've just triggered your test. | 15:14 |
| mup | PR snapd#3965 closed: interfaces/mount: add support for parsing x-snapd.{mode,uid,gid}= <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3965> | 15:15 |
| mup | PR snapd#3999 closed: cmd/snap-confine: add detection of stale mount namespace <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3999> | 15:15 |
| mup | PR snapd#4062 closed: cmd/snap: warn when a snap is not from the tracking channel <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4062> | 15:16 |
| Chipaca | snappy-m-o: dance for us | 15:16 |
| snappy-m-o | Command ":" / ": dance" not found. | 15:16 |
| arubislander | zyga-ubuntu: check | 15:20 |
| pedronis | mvo: what's the status of #4060, I see it has two +1 but some open nitpicks ? | 15:20 |
| mup | PR #4060: interfaces: clean system apparmor cache on core device <Created by mvo5> <https://github.com/snapcore/snapd/pull/4060> | 15:20 |
| kyrofa | seb128, update given | 15:22 |
| mvo | pedronis: indeed, I will get to it later, forgot about those | 15:23 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| seb128 | kyrofa, thanks | 15:26 |
| popey | om26er: kk | 15:28 |
| * Chipaca hugs pedronis | 15:36 | |
| Chipaca | thank you for doing this | 15:36 |
| kyrofa | Hey jdstrand, review-wise, can I claim the same dbus common name in two snaps? | 15:41 |
| mvo | zyga-ubuntu: do you have any idea about https://bugs.launchpad.net/snapd/+bug/1721518 ? the most interessting part if #3 actually, on trusty apprently sometimes interface connections get lost | 15:42 |
| mup | Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518> | 15:42 |
| zyga-ubuntu | mvo: looking | 15:44 |
| zyga-ubuntu | mvo: that's very interesting | 15:45 |
| zyga-ubuntu | mvo: no idaa, come to think of it, maybe something we are doing is wiping our state | 15:45 |
| zyga-ubuntu | mvo: maybe some 1st boot logic? | 15:45 |
| mvo | zyga-ubuntu: interessting idea | 15:45 |
| zyga-ubuntu | mvo: nothing that I can think of would remove connections | 15:45 |
| zyga-ubuntu | mvo: especially if the snap is present | 15:46 |
| zyga-ubuntu | mvo: and it seems it is as there are slots there from core | 15:46 |
| mvo | zyga-ubuntu: the annoying part is that its on trusty and we have lost the knowledge about the details there | 15:46 |
| zyga-ubuntu | mvo: yes but I think we are not in a terrible situation, the set of units is closed, it's just deputy-systemd and snapd systemd units | 15:46 |
| zyga-ubuntu | mvo: we can see what starts when and what happens | 15:47 |
| zyga-ubuntu | mvo: the downside is that last time I looked there was no logging on 14.04 | 15:47 |
| zyga-ubuntu | mvo: I can look but I'm in a car now | 15:47 |
| zyga-ubuntu | mvo: tell me what you know | 15:48 |
| mvo | zyga-ubuntu: heh, no worries | 15:48 |
| zyga-ubuntu | mvo: did you manage to reproduce it? | 15:48 |
| mvo | zyga-ubuntu: I don't know anything at this point :( I have not yet found time to reproduce/debug. was mostly wondering if you saw any of this before, if not, thats fine. I can look tomorrow morning if I can reproduce (some people from landscape wait for this) | 15:49 |
| zyga-ubuntu | mvo: I saw one instance | 15:50 |
| zyga-ubuntu | mvo: but it was _not_ on 14.04 | 15:50 |
| mvo | zyga-ubuntu: oh?!? | 15:50 |
| zyga-ubuntu | mvo: sergio reported it on his surface | 15:50 |
| zyga-ubuntu | mvo: not sure what the conditions were but it wasn't 14.04 for sure | 15:50 |
| kalikiana | kyrofa: Perhaps you'd like to have a look at snapcraft#1639 - as written in the description that's not implementing the "on..to.." yet. I'm still working on that (and still pondering how to not make it too ugly, haha). Was wondering if it should be done in one bigger PR or rather two separate ones... | 15:50 |
| mup | PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639> | 15:50 |
| zyga-ubuntu | mvo: I can setup a test loop | 15:50 |
| zyga-ubuntu | mvo: just not sure what the steps are, boot trusty, <snapshot> install snapd, reboot, test hello world, <rollback> | 15:51 |
| zyga-ubuntu | mvo: at each time hello-world should have iface connections | 15:51 |
| mvo | cachio_lunch: hey, if you have a free slot in between the other work, would you mind to try to reproduce https://bugs.launchpad.net/snapd/+bug/1721518 ? | 15:51 |
| mup | Bug #1721518: Latest snapd in Trusty is broken after reboot because of systemd units start ordering <snapd:In Progress by inaddy> <https://launchpad.net/bugs/1721518> | 15:51 |
| zyga-ubuntu | mvo: I can also install other snaps (maybe the one used in the report matters) | 15:51 |
| === cachio_lunch is now known as cachio | ||
| zyga-ubuntu | mvo: I can tweak my python script for snapshots to test this very quckly (many loops) | 15:51 |
| cachio | mvo, sure | 15:51 |
| zyga-ubuntu | mvo: but that looks like a half day effort tomorrow morning | 15:52 |
| * kalikiana will be leaving in a few minutes, but feel free to respond here anyway | 15:52 | |
| mvo | zyga-ubuntu: canonical-livepatch is the important one. if you or cachio (timezone wise it might be better for him as its earlier there) could check that would be great | 15:52 |
| mvo | zyga-ubuntu: yeah, lets see if cachio can easily reproduce and then we decide what to do | 15:52 |
| mup | PR snapd#4076 opened: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076> | 15:52 |
| zyga-ubuntu | mvo: ok, Ill let cachio work on this today and I'll attack it first thing tomorrow | 15:52 |
| mvo | zyga-ubuntu: \o/ lets sync on it in the morning | 15:52 |
| zyga-ubuntu | I'm working on the overlayfs PR now but I have some tests to adjusts after rebasing | 15:52 |
| zyga-ubuntu | mvo: sounds good, | 15:52 |
| kyrofa | kalikiana, will do | 15:53 |
| mvo | zyga-ubuntu: ta | 15:53 |
| kalikiana | Thanks! | 15:57 |
| kalikiana | sergiusens: Maybe you wanna check this one? It's store-related and needs another reviewer snapcraft#1634 | 16:01 |
| mup | PR snapcraft#1634: Push metadata to the Store <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1634> | 16:01 |
| pedronis | mvo: I left some initial comments in #4076, but looking code afaict | 16:13 |
| mup | PR #4076: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <https://github.com/snapcore/snapd/pull/4076> | 16:13 |
| niemeyer | pedronis: Thanks, will definitely look today | 16:18 |
| mup | PR snapd#4077 opened: spdx: fix for WITH syntax, require a license name before the operator <Created by matiasb> <https://github.com/snapcore/snapd/pull/4077> | 16:25 |
| pedronis | mvo, I meant "looking good" | 16:31 |
| niemeyer | pedronis: I'm slightly confused about the question about epoch | 16:40 |
| niemeyer | pedronis: How can the server possibly respect the epoch if it doesn't know it? | 16:40 |
| cachio | mvo, I could reproduce the error | 16:54 |
| kyrofa | snappy-m-o, autopkgtest 1583 xenial:amd64 | 16:57 |
| snappy-m-o | kyrofa: I've just triggered your test. | 16:57 |
| cachio | mvo, http://paste.ubuntu.com/25818102/ | 17:02 |
| cachio | mvo, I don't see anything weird apart of that | 17:10 |
| * zyga-ubuntu is stuck in a traffic jam | 17:23 | |
| zyga-ubuntu | running spread tests | 17:23 |
| zyga-ubuntu | watching the rain | 17:23 |
| zyga-ubuntu | ... | 17:23 |
| cachio | zyga-ubuntu, I could reproduce the error in trusty | 17:26 |
| cachio | raining here too :) | 17:26 |
| cachio | falling hail now | 17:28 |
| cachio | kenvandine, hey | 17:39 |
| pedronis | niemeyer: I think, they are thinking of going from revision to the epoch info looking at the info in the store | 17:39 |
| niemeyer | pedronis: I see.. but that wouldn't work for the local case | 17:40 |
| cachio | kenvandine, trying to access to gsettings schemas from a test snap | 17:40 |
| kenvandine | hey cachio | 17:40 |
| cachio | kenvandine, I am using the desktop interface but I can just access by using devmode | 17:41 |
| pedronis | niemeyer: yes, but the local case doesn't quite fit into things, it's really special, we don't have a snap-id either for that case, it's really a cross of an install and refresh | 17:41 |
| kenvandine | cachio, you need the gsettings interface too | 17:41 |
| cachio | kenvandine, yes | 17:41 |
| cachio | kenvandine, I can access to if I manually set the schemas dir to /var/lib/snapd/hostfs/usr/share/glib-2.0/schemas | 17:42 |
| cachio | kenvandine, and I am in devmode | 17:42 |
| cachio | kenvandine, is there any other way to access the user schemas? | 17:42 |
| mvo | pedronis: yay, thanks a lot for your review! | 17:42 |
| mvo | cachio: thanks, thats great. well, not great but at least easy to reproduce | 17:43 |
| cachio | mvo, yes, first attempt | 17:43 |
| mvo | cachio: what comments did you run? exactly the same as in the bugreport? I wonder why none of our existing tests caught this :( | 17:44 |
| * mvo gets the feeling that however many tests you have, its never enough | 17:44 | |
| kenvandine | cachio, i haven't needed to change any schemas dir | 17:45 |
| kenvandine | all my gnome snaps work just fine | 17:45 |
| kenvandine | cachio, which snap are you working on? | 17:45 |
| cachio | kenvandine, do you have an example? | 17:45 |
| cachio | kenvandine, I would like to see how you are building the snaps, tx | 17:46 |
| kenvandine | http://bazaar.launchpad.net/~ubuntu-desktop/gnome-calculator/snap/view/head:/snapcraft.yaml | 17:46 |
| cachio | mvo, I have the same question | 17:46 |
| kenvandine | cachio, is an example | 17:46 |
| cachio | kenvandine, tx | 17:46 |
| kenvandine | cachio, and it has to be built with the ubuntu-desktop/gnome-3-26 PPA enabled | 17:46 |
| cachio | mvo, I'll gonna make a review of the tests to see if we need a new tests or what happened | 17:47 |
| zyga-ubuntu | cachio: can you tell me what you did to reproduce? I will do the same | 17:47 |
| cachio | zyga-ubuntu, just updated with apt | 17:48 |
| zyga-ubuntu | caa | 17:48 |
| mvo | cachio: thanks for chasing this, much appreciated | 17:48 |
| zyga-ubuntu | cachio: aha, just that? did you have any set of snaps installed? | 17:48 |
| cachio | and then followed the steps in the bug | 17:48 |
| zyga-ubuntu | ah, ok, so the canonical-livepatch is relevant to the bug? | 17:48 |
| mvo | cachio: I will look into it in my morning (in ~11h) to see if I can find the root cause | 17:48 |
| cachio | I removed snapd, and then installed 2.27.5 from the archive | 17:48 |
| zyga-ubuntu | cachio: so the steps are: | 17:49 |
| zyga-ubuntu | cachio: boot 14.04 | 17:49 |
| zyga-ubuntu | cachio: install/update snapd | 17:49 |
| zyga-ubuntu | cachio: install canonical-livepatch | 17:49 |
| cachio | 2.27.5 | 17:49 |
| zyga-ubuntu | cachio: ... ? | 17:49 |
| zyga-ubuntu | cachio: can you tell me which kernel you had around when the bug happened | 17:49 |
| zyga-ubuntu | cachio: (running) | 17:49 |
| cachio | zyga-ubuntu, 4.4.0-89-generic | 17:50 |
| zyga-ubuntu | cachio: ok | 17:50 |
| cachio | then you rebboot | 17:50 |
| cachio | then install hello-world and see that everything goes ok | 17:50 |
| cachio | then you reboot again | 17:50 |
| zyga-ubuntu | cachio: so after reboot is's okay | 17:50 |
| zyga-ubuntu | cachio: aha, go on | 17:50 |
| cachio | and when you do snap intergaces, you see there are not interfaces listed | 17:51 |
| zyga-ubuntu | cachio: when you started and before the 1st reboot, were you on 4.x already? | 17:51 |
| cachio | zyga-ubuntu, yes | 17:51 |
| mvo | the instructions sound like a spread test is not too hard to write for this (which is nice) | 17:51 |
| cachio | mvo, should be easy | 17:51 |
| cachio | I'll try to do it | 17:51 |
| mvo | \o/ | 17:54 |
| pedronis | mvo: seems the change about configure made it so that we run it also on classic but now it fails seeing it cannot be, but we want some bits run also on classic, we need to reorg that somehow | 17:57 |
| pedronis | or we ignore errors differently | 18:00 |
| niemeyer | pedronis: Indeed, but ideally we'd still try to handle it correctly | 18:02 |
| jdstrand | kyrofa: review-wise, yes, so long as it makes sense for both | 18:02 |
| niemeyer | pedronis: Based on the name | 18:02 |
| niemeyer | pedronis: and we might prevent obvious breakage by not allowing the epoch to go through | 18:02 |
| pedronis | niemeyer: yes, but unclear we would put epoch in the context (the context doesn't have names, just snap-id), as I see it it woulb be a special case of "install" or its own "refresh-local" or something | 18:03 |
| niemeyer | pedronis: Hmm | 18:04 |
| pedronis | we could support both snap-ids and names in context | 18:04 |
| pedronis | but not a fan of that | 18:04 |
| niemeyer | pedronis: Yeah, I guess it'd be special indeed, and we probably don't want to send names at all cases | 18:04 |
| niemeyer | pedronis: So sounds worth not bothering for now | 18:04 |
| pedronis | yes, I think it's special enough, we can fit it in later but with some special casing | 18:05 |
| pedronis | but not worth making general changes based on it | 18:05 |
| pedronis | niemeyer: I think the conclusion is tha we don't strictly need epoch in context, I don't know if we still want to be explict though, or better leave the server to do revision->epoch lookup | 18:06 |
| niemeyer | pedronis: I think it wouldn't hurt to have it either way | 18:08 |
| niemeyer | pedronis: But I also can't argue for it with a good argument | 18:08 |
| pedronis | I think it's best to leave it out, at least there's no situation in which the client can send somebody that is "wrong" | 18:11 |
| pedronis | s/somebody/something/ | 18:12 |
| === JanC_ is now known as JanC | ||
| mcphail | ogra_: is porting ubuntu core to a new ARM device something a semi-technical semi-literate numpty like me would be capable of doing? I'd love to run core on my sheevaplug device, instead of debian | 19:10 |
| kyrofa | You're still using a sheevaplug? Nice, I've got my old one sitting here | 19:13 |
| kyrofa | However, I seem to remember that being arm6 | 19:13 |
| kyrofa | Which Ubuntu doesn't support | 19:13 |
| mcphail | kyrofa: I have yet to find anything more reliable, to be honest. It just keeps working. | 19:13 |
| kyrofa | mcphail, yeah I was on that train for a while as well. Used a few different plug computers. They kept eating my SD cards, though | 19:14 |
| kyrofa | mcphail, the Mirabox was the best | 19:15 |
| kyrofa | Dual USB 3, dual gigabit ethernet | 19:15 |
| mcphail | I use the SD card for as little as possible. Most of my stuff is on the internal flash with an external usb drive bind-mounted over it | 19:15 |
| kyrofa | Ah, good idea | 19:15 |
| mcphail | It is a PITA to update when a new debian version comes out, though. Messing about with uboot is never fun. That's why the snappy model is attractive | 19:17 |
| kyrofa | mcphail, just to double-check, can I see a `cat /proc/cpuinfo` ? | 19:17 |
| mcphail | http://termbin.com/1tev | 19:19 |
| mcphail | Does core require a certain feature set? | 19:21 |
| kyrofa | mcphail, armv5 | 19:24 |
| kyrofa | mcphail, Ubuntu hasn't supported that since... what... 9.10? | 19:24 |
| kyrofa | mcphail, and by extension, Ubuntu Core | 19:24 |
| mup | PR snapd#4070 closed: hooks/configure: queue service restarts <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4070> | 19:24 |
| mcphail | kyrofa: aah. But I can build my own kernel snap, can't I? | 19:25 |
| kyrofa | mcphail, ogra_ is the expert here of course, but I don't think your quest will end in happiness | 19:25 |
| mcphail | shame | 19:25 |
| kyrofa | mcphail, oh sure. But consider the core snap, and the support archs in the store | 19:25 |
| kyrofa | s/support/supported/ | 19:26 |
| mcphail | Hmm. Isn't armhf backwards compatiblke? | 19:26 |
| kyrofa | Backwards compatible to... what? | 19:27 |
| zyga-ubuntu | a armv5 binary to run on arvm7 | 19:27 |
| zyga-ubuntu | an* | 19:28 |
| mcphail | armel | 19:28 |
| mcphail | debian moved from armel to armhf with ARMv7 CPUs. That's when Ubuntu dropped sheevaplug support, but debian continued its armel port as well. I _think_ I've run armhf packages on the asheevaplug in the past (certainly, I run syncthing which is just packaged in a generic "arm" repo). I don't really understand this stuff ;) | 19:31 |
| youngc | Can anyone here help with a snapcraft make error? | 19:38 |
| kyrofa | mcphail, I don't think it works that direction-- I suspect hard-float instructions aren't supported on soft-float hardware, but the other way around might be possible | 19:39 |
| kyrofa | mcphail, but yeah, I don't pretend to be an expert either | 19:39 |
| kyrofa | I also think it's beyond just the floating point hardware | 19:40 |
| kyrofa | youngc, hit me :) | 19:40 |
| mcphail | kyrofa: thanks. You're probably right. I've just run "readelf -h syncthing | grep Flags" and it looks like it is ARM EABI v5. I suspect they release it that way and it will probably be forward compatible | 19:43 |
| youngc | here we go... As far as using make goes it works, but... when I use the following command "make -f ./Makefile-Linux.x86_64 all" the make fails. Mind you I can manually go to the folder and type make and it works. | 19:44 |
| youngc | more info just a sec | 19:44 |
| youngc | it seems to be failing due to the actual folder is trying to run from | 19:45 |
| youngc | but not sure | 19:47 |
| youngc | the code is here: https://github.com/chadyoungdell/benchmark.io.iometer.snap | 19:48 |
| kyrofa | youngc, when you "manually go to the folder and type make", it uses a different Makefile | 19:49 |
| kyrofa | youngc, unless you're missing a step? | 19:49 |
| kyrofa | Let me pull this thing real quick | 19:49 |
| kyrofa | elopio, loving all the bitesize bugs | 19:51 |
| kyrofa | youngc, try `makefile: src/Makefile-Linux.x86_64` | 19:53 |
| kyrofa | youngc, it's relative to the root of the source | 19:53 |
| kyrofa | youngc, which in the tarball, has that makefile in the `src/` dir | 19:54 |
| youngc | I did that before this and had the same failure - let me try again real quick | 19:54 |
| kyrofa | youngc, it still doesn't build, looks like the makefile is missing some things, but that'll get you unblocked anyway | 19:55 |
| kyrofa | youngc, I get "make: *** No rule to make target 'IOGlobals.o', needed by 'dynamo'. Stop." | 19:55 |
| youngc | thats what I get to | 19:55 |
| kyrofa | youngc, definitely not the same error | 19:56 |
| youngc | if you open the file Makefile-Linux.x86_64 and modifiy IOGlobals.o to src/IOGlobals.o that file actually compiles | 19:56 |
| youngc | sorry, I meant after I chaned the file to what you asked | 19:57 |
| kyrofa | youngc, you might find this works better: https://pastebin.ubuntu.com/25818987/ | 19:57 |
| kyrofa | youngc, sounds like the cwd needs to be in src/ basically | 19:58 |
| kyrofa | youngc, so that will help | 19:58 |
| kyrofa | youngc, note the `source-subdir` | 19:58 |
| youngc | ok, let me try that | 19:58 |
| kyrofa | youngc, also note the removal of `src` from `makefile` | 19:58 |
| kyrofa | basically that will run `cd src && make -f Makefileblahblah` instead | 19:59 |
| youngc | cool!! that works | 19:59 |
| kyrofa | Good deal | 20:00 |
| youngc | I did not know that you could add the source-subdir to something other than git | 20:00 |
| youngc | thanks for the help | 20:00 |
| kyrofa | youngc, any time :) | 20:00 |
| Odd_Bloke | sergiusens: o/ Am I doing something wrong, or are dots not allowed in app names? | 20:01 |
| kyrofa | Odd_Bloke, app names consist of upper- and lower-case alphanumeric characters and hyphens. They cannot start or end with a hyphen | 20:02 |
| kyrofa | No periods | 20:02 |
| Odd_Bloke | Hmph. | 20:03 |
| Odd_Bloke | Fair enough. | 20:03 |
| popey | sergiusens: https://forum.snapcraft.io/t/snapcraft-unable-to-install-core-snap/2599 - what am I doing wrong? | 20:20 |
| elopio | kyrofa these two PRs have been very challenging for my English. They will need many of your reviews. | 20:41 |
| kyrofa | elopio, my pleasure, of course | 20:43 |
| kyrofa | elopio, oh! Your regular nick again, eh? | 20:43 |
| elopio | I had to change my password... | 20:44 |
| elopio | Matrix is fun. | 20:44 |
| kyrofa | Yeah, top-of-the-line user experience, I've noticed | 20:52 |
| jdstrand | roadmr: fyi, https://dashboard.snapcraft.io/dev/snaps/7385/rev/995/ got stuck too. I requested to re-review | 20:58 |
| roadmr | jdstrand: let's have a look | 20:59 |
| jdstrand | roadmr: that didn't seem to help | 20:59 |
| jdstrand | (the re-review) | 20:59 |
| jdstrand | roadmr: https://dashboard.snapcraft.io/dev/snaps/8324/rev/51/ too. 19 hours ago, review tools passed | 21:00 |
| jdstrand | roadmr: could this have something to do with the pacemaker bug? | 21:00 |
| roadmr | pacemaker bug?? | 21:00 |
| mup | PR snapd#4078 opened: tests: new test to check interfaces after reboot the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4078> | 21:01 |
| roadmr | so - 8324 does seem stuck but 7385 doesn't | 21:01 |
| roadmr | give me a sec to check the admin | 21:01 |
| roadmr | oh, 7385 too, I was looking at wrong rev | 21:01 |
| jdstrand | roadmr: https://launchpadlibrarian.net/342811432/pacemaker_1.1.14-2ubuntu1.2_1.1.14-2ubuntu1.3.diff.gz | 21:01 |
| jdstrand | roadmr: I'm just curious-- cj watson mentioned something dying before that fix | 21:02 |
| roadmr | jdstrand: probably not, this seems related to celery processes in the store's application units grabbing tasks which they then don't process | 21:03 |
| jdstrand | roadmr: ok, 7385-- it just took longer than I expected. looks like my re-review request got it unstuck | 21:03 |
| roadmr | jdstrand: ok - I do see 8324 in the "stuck" queue | 21:03 |
| roadmr | jdstrand: do you have the "run the automated review again" button in https://dashboard.snapcraft.io/dev/snaps/8324/rev/51/ ? | 21:04 |
| jdstrand | roadmr: ok, I won't touch 8324 and let you do whatever you need | 21:04 |
| jdstrand | roadmr: I do | 21:04 |
| jdstrand | I can do that. I didn't know if you wanted to look at 8324 more closely | 21:04 |
| roadmr | jdstrand: give me a sec to just check if it correlates with a rollout (which is when we see celery weirdness happening) | 21:05 |
| roadmr | jdstrand: ok, I kicked 8324 so we don't block it. We did match it with a rollout yesterday, so we'll figure out a way to keep this from happening | 21:09 |
| roadmr | but it might, while we do figure out a way :) so let me know of any weirdness | 21:09 |
| kyrofa | jdstrand, I just got a bug report from a user trying to install my snap on digitalocean, but getting "cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied" | 21:18 |
| jdstrand | roadmr: ackc | 21:18 |
| kyrofa | jdstrand, any clues regarding what might be the issue there? | 21:18 |
| jdstrand | kyrofa: sounds like the kernel blocked snap-confine. are there any security denials? | 21:21 |
| jdstrand | kyrofa: fyi, this is line 132 in cmd/snap-confine/ns-support.c | 21:22 |
| kyrofa | jdstrand, I'll check | 21:23 |
| jdstrand | kyrofa: if there is no denial, this is code zyga wrote so he may be more familiar with it. but would likely need a forum post with kernel version, etc | 21:24 |
| kyrofa | jdstrand, does this look odd? Oct 25 17:40:26 portfolio kernel: [ 223.174251] type=1400 audit(1508967626.765:94): apparmor="DENIED" operation="ptrace" profile="/snap/core/3247/usr/lib/snapd/snap-confine" pid=2427 comm="snap-confine" requested_mask="read" denied_mask="read" peer="unconfined" | 21:48 |
| jdstrand | kyrofa: it does | 21:49 |
| jdstrand | kyrofa: I'm curious if this rule would fix it: ptrace (read) peer=unconfined, | 21:50 |
| jdstrand | kyrofa: we already have this rule which is meant to cover this: ptrace trace peer=unconfined, | 21:51 |
| jdstrand | kyrofa: so it is possible that the Digital Ocean kernel is behaving differently | 21:51 |
| jdstrand | kyrofa: (in snap-confine's profile) | 21:52 |
| kyrofa | jdstrand, it's not re-execing using the profile in the core snap? | 21:52 |
| jdstrand | kyrofa: hmm? I don't know anything about the vm that this would be running in | 21:53 |
| kyrofa | jdstrand, sorry, rephrasing: where is snap-confine's profile? | 21:53 |
| jdstrand | kyrofa: yes, that is the question. and the answer depends on if it is re-execing :) | 21:54 |
| kyrofa | Oh! So I DID ask the right question, haha | 21:54 |
| kyrofa | jdstrand, I believe it's good old Ubuntu 16.04 | 21:54 |
| jdstrand | kyrofa: well, if that was your question, I didn't understand it :P | 21:54 |
| jdstrand | anyhoo | 21:54 |
| kyrofa | jdstrand, boo :( | 21:55 |
| jdstrand | so, if Ubuntu 16.04, then it should be reexecing | 21:55 |
| kyrofa | But I can still copy the profile off, edit it, and load it | 21:55 |
| jdstrand | you'll want to obtain the version of core. look at /snap/core/current and see what it is pointing to | 21:55 |
| kyrofa | jdstrand, 3247 given the denial above, no? | 21:56 |
| jdstrand | then it will be /etc/apparmor.d/snap.core.3247.usr.lib.snapd.snap-confine | 21:56 |
| jdstrand | kyrofa: I suggest copying that file to ~ | 21:56 |
| jdstrand | then modify it, then do: sudo apparmor_parser -r ~/snap.core.3247.usr.lib.snapd.snap-confine | 21:56 |
| kyrofa | jdstrand, excellent, thank you | 21:57 |
| kyrofa | I'll get back to you | 21:57 |
| jdstrand | that was harsh. I had a terminal open with an ssh session to a vm. I start to type in it and I didn't notice that typing into showed the connection was broken. then I sudo shutdown the 'vm' and tore down my session | 22:00 |
| jdstrand | fun! | 22:00 |
| kyrofa | Oouuch | 22:00 |
| kyrofa | jdstrand, teach YOU to type looking at your fingers | 22:01 |
| jdstrand | kyrofa: so, what I was going to say was make sure you add the rule to the main profile, not the mount-helper child profile | 22:01 |
| jdstrand | well, the vm is stopped now | 22:01 |
| jdstrand | so I achieved at least that much :) | 22:02 |
| jdstrand | kyrofa: if that works, let me know and give the output of cat /proc/version_signature | 22:03 |
| kyrofa | jdstrand, I only see one `ptrace trace peer=unconfined` in there | 22:03 |
| kyrofa | jdstrand, I'm just replacing it... no? | 22:03 |
| jdstrand | kyrofa: don't replace. add | 22:04 |
| kyrofa | Just right below? | 22:04 |
| jdstrand | yeah | 22:04 |
| kyrofa | jdstrand, double-checking: the filename that I hand to apparmor_parser doesn't matter, right? | 22:05 |
| jdstrand | kyrofa: correct | 22:06 |
| kyrofa | jdstrand, one more double-check: https://pastebin.ubuntu.com/25819686/ | 22:06 |
| kyrofa | Haha, dangit, flip the args | 22:07 |
| jdstrand | kyrofa: the diff is backwards, but yes | 22:07 |
| * jdstrand nods | 22:07 | |
| kyrofa | Okay good | 22:07 |
| jdstrand | kyrofa: wait whoops | 22:07 |
| jdstrand | kyrofa: you forgot the trailing comma | 22:07 |
| kyrofa | Ah, good catch | 22:07 |
| jdstrand | kyrofa: this is also a safe action. if you jack it up, a reboot gives you the profile on the system since you didn't modify it | 22:08 |
| kyrofa | jdstrand, indeed, thank you! | 22:12 |
| jdstrand | kyrofa: did it work? | 22:13 |
| kyrofa | jdstrand, working on it, this is async I'm afraid | 22:17 |
| jdstrand | gotcha | 22:17 |
| kyrofa | jdstrand, side note, I was trying to tweak the profile myself and send it to him, only to learn that I seemingly can't access anything in my home directory with "snap-confine" in the name from a confined snap | 22:17 |
| kyrofa | jdstrand, is that true? | 22:17 |
| kyrofa | jdstrand, https://pastebin.ubuntu.com/25819750/ | 22:18 |
| jdstrand | kyrofa: you are within a confined snap? | 22:18 |
| kyrofa | jdstrand, indeed | 22:18 |
| jdstrand | kyrofa: and the home interface is connected? | 22:19 |
| jdstrand | kyrofa: it seems it would be since foo-bar-baz is there | 22:19 |
| kyrofa | jdstrand, yep. Note the pastebin. It works as long as "snap-confine" isn't part of the file name :P | 22:19 |
| kyrofa | jdstrand, wait, no sorry, only if snap-confine is starting the file name | 22:22 |
| jdstrand | ok | 22:22 |
| jdstrand | I was going to say, I couldn't see how foo-bar-snap-confine wouldn't work | 22:22 |
| jdstrand | kyrofa: it is this gem: http://paste.ubuntu.com/25819780/ | 22:23 |
| kyrofa | jdstrand, haha, ouch | 22:23 |
| jdstrand | kyrofa: it's incomplete | 22:24 |
| jdstrand | I'll add a todo for that | 22:24 |
| kyrofa | jdstrand, thank you! | 22:24 |
| kyrofa | jdstrand, that profile tweak did the trick | 22:26 |
| kyrofa | jdstrand, another interesting tidbit: this box was upgraded from trusty | 22:26 |
| jdstrand | kyrofa: ok, what is the kernel? cat /proc/version_signature | 22:27 |
| kyrofa | jdstrand, Ubuntu 3.13.0-71.114-generic 3.13.11-ckt29 | 22:28 |
| jdstrand | kyrofa: alright, so that there is your problem. you need the xenial kernel | 22:28 |
| jdstrand | I'm surprised things are working as well as it is | 22:29 |
| kyrofa | So do-release-upgrade doesn't upgrade the kernel? | 22:29 |
| jdstrand | kyrofa: it absolutely should have | 22:29 |
| jdstrand | kyrofa: perhaps the kernel was pinned? something went awry in the upgrade? grub didn't get updated? | 22:30 |
| jdstrand | there are a lot of things that could've gone wrong | 22:30 |
| jdstrand | kyrofa: sudo apt-get install linux-generic | 22:30 |
| jdstrand | that may provide a clue if it is pinned. beyond that, they need to upgrade their kernel | 22:31 |
| kyrofa | Thanks jdstrand there are actually two people saying this happened on digitalocean | 22:32 |
| kyrofa | Something weird is happening over there | 22:32 |
| jdstrand | yeah. huh | 22:33 |
| jdstrand | kyrofa: is this a xen environment? | 22:33 |
| kyrofa | jdstrand, great question, I have no idea how they do it | 22:33 |
| jdstrand | cause maybe it is Digital Ocean's kernel (that happens to be an Ubuntu kernel) | 22:33 |
| jdstrand | some hosting environments do things like that | 22:34 |
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 22:50 |
| mup | PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58> | 22:50 |
| mup | PR core#62 closed: create xdg-settings inside the core snap <Created by mvo5> <https://github.com/snapcore/core/pull/62> | 22:50 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 22:51 |
| mup | PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58> | 22:51 |
| mup | PR core#62 opened: create xdg-settings inside the core snap <Created by mvo5> <https://github.com/snapcore/core/pull/62> | 22:51 |
| kyrofa | jdstrand, finally, all resolved now | 23:09 |
| kyrofa | jdstrand, https://www.digitalocean.com/community/tutorials/how-to-update-a-digitalocean-server-s-kernel | 23:09 |
| kyrofa | jdstrand, tl;dr older droplets manage their kernel differently, outside the machine in the dashboard | 23:10 |
| kyrofa | jdstrand, so even after updating, while the new kernel was installed, it wasn't booting into it | 23:10 |
| nacc | kyrofa: yeah, it's a pretty regular FAQ in #ubuntu sadly | 23:10 |
| kyrofa | jdstrand, once we got that sorted, snaps work fine | 23:10 |
| kyrofa | nacc, brutal man | 23:10 |
| kyrofa | Weird way to structure a system | 23:11 |
| nacc | kyrofa: we'll be debugging some weird issue and it'll turn out they are runnig some random kernel :) | 23:11 |
| kyrofa | But it sounds like they know that, and don't do it anymore | 23:11 |
| nacc | kyrofa: VPS are a pain in that regard | 23:11 |
| kyrofa | nacc, oh yeah, that happens all the time, definitely | 23:11 |
| kyrofa | nacc, but trying to figure out why a kernel isn't being booted, despite grub looking perfect... ? | 23:11 |
| kyrofa | nacc, do you see that often? | 23:11 |
| nacc | kyrofa: not off the top of my head -- but i often default to blaminng the VPS provider if they are on any kind of VPS | 23:12 |
| nacc | :) | 23:12 |
| kyrofa | nacc, heh | 23:12 |
| jdstrand | kyrofa: interesting, thanks! | 23:35 |
| kyrofa | jdstrand, thank YOU | 23:36 |
| kyrofa | Didn't even consider asking about the kernel | 23:36 |
| kyrofa | Sorry for the wild goose chase | 23:36 |
| kyrofa | Now I know | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!