| === cmars_ is now known as cmars | ||
| === Guest94286 is now known as katnip- | ||
| === katnip- is now known as katnip | ||
| === chihchun_afk is now known as chihchun | ||
| eraserpencil | I'm reading some articles on snappy, and read that it's not possible to update snaps that are not hosting on the snap store.. | 04:34 |
|---|---|---|
| eraserpencil | Is it a functionality I might be able to replicate if I hosted my own distribution network? currently, I'm manually copying snaps onto different machines and installing them but just thinking of how I might be able to update them | 04:36 |
| mborzecki | morning | 05:21 |
| mvo | hey mborzecki ! good morning | 05:22 |
| mborzecki | hm 15 reviews/week, i have a feeling we'll not bring bring down the PR count to say 20 in a reasonable time :) | 05:24 |
| mup | PR snapd#5166 opened: tests: go must be installed as a classic snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5166> | 05:26 |
| mvo | mborzecki: *cough* yeah, but hopefully we do better over the coming days | 05:26 |
| mborzecki | mvo: #5156 can be merged now? | 05:55 |
| mup | PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156> | 05:55 |
| mvo | mborzecki: yes, done. thank you! | 05:57 |
| mup | PR snapd#5156 closed: core-fixup: address review feedback from #5147 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5156> | 05:58 |
| mup | PR snapd#5167 opened: tests: cherry-pick more GCE commits <Created by mvo5> <https://github.com/snapcore/snapd/pull/5167> | 05:59 |
| mup | PR snapd#5166 closed: tests: go must be installed as a classic snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5166> | 06:00 |
| mup | PR snapd#5160 closed: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5160> | 06:01 |
| zyga | good morning | 06:04 |
| mup | PR snapd#5061 closed: tests: ensure interfaces-network-bind daemon is stopped early <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5061> | 06:16 |
| zyga | mvo: I will be off for 5 work days, starting tomorrow | 06:17 |
| mup | PR snapd#4562 closed: debian: add a zenity|kdialog suggests <Reviewed> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4562> | 06:18 |
| mvo | zyga: nice! will you go on vac? | 06:19 |
| zyga | mvo: ish, yes, we need to go and wrap up some stuff in Catalonia | 06:20 |
| zyga | mvo: but also some vac hopefully, a surprise birthday party for our close friend there | 06:20 |
| zyga | (she doesn't know we're coming yet :) | 06:20 |
| mvo | zyga: ha! nice | 06:21 |
| zyga | I will take my laptop (obviously) so I can still help land stuff while nothing better to do around | 06:21 |
| zyga | this reminds me, I need to find my Vodafone SIM and install it | 06:21 |
| * zyga installed an air filter yesterday | 06:23 | |
| zyga | and ... shockingly, it worsk | 06:23 |
| mborzecki | air filter where? | 06:23 |
| zyga | my desk was covered in dust every morning, driving me insane | 06:23 |
| zyga | it's a pretty big box standing right next to me | 06:23 |
| zyga | I moved my hand across the desk and keyboard this morning and it was clean as if wiped a moment ago | 06:24 |
| mborzecki | ah, that dust, isn't that some pollen or the mythical sands from sahara dragged over europe? | 06:24 |
| zyga | before it was always full of fine powdery dust | 06:24 |
| zyga | well, whatever it is, the machine works :) | 06:24 |
| mborzecki | make sure to clean the filter regularly, otherwise you may have a close encounter with fungi spores dispersed in the air | 06:27 |
| zyga | mborzecki: yeah, I need to learn proper maintenance | 06:28 |
| zyga | it has a nice phone app to measure stuff though, it will surely remind me of everything :) | 06:28 |
| mborzecki | zyga: xiaomi? | 06:28 |
| zyga | yes | 06:28 |
| zyga | model 2 | 06:28 |
| zyga | it was 200zł off the normal price to celebrate a new store that opened in warsaw | 06:29 |
| mup | PR snapd#5167 closed: tests: cherry-pick more GCE commits <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5167> | 06:30 |
| mborzecki | aah yes, 'big event' :), well whatever people say, they have a better track updating their firmware than most vendors | 06:30 |
| zyga | hehe, yes, it had a firmware update out of the box | 06:30 |
| zyga | so far I'm happy, it is quiet on auto and seems to solve my biggest annoyance with home office, | 06:31 |
| mborzecki | so morphis found some issues with egl support, i'm looking into that | 06:31 |
| zyga | I saw | 06:31 |
| zyga | it's interesting | 06:31 |
| zyga | maybe run a strace -e open | 06:32 |
| zyga | and see what else is opened by sample app | 06:32 |
| zyga | then sort -u the paths | 06:32 |
| zyga | there should be a handful of things really | 06:32 |
| mborzecki | it should be easy to fix | 06:32 |
| mborzecki | at least it's saner than what vulkan setup did | 06:32 |
| mborzecki | (though the mechanism is similar) | 06:32 |
| mborzecki | mvo: shall we do `xmessage -buttons Yes:0,No:1 -default Yes -nearmouse "shall we do xmessage?" -timeout 10` ? | 06:35 |
| mvo | mborzecki: as a fallback if zenity or kdialog are not around? probably a good idea but its pretty hardcore | 06:36 |
| mvo | mborzecki: I mean, Xaw | 06:37 |
| mborzecki | haha yes | 06:37 |
| * zyga requests a review for https://github.com/snapcore/snapd/pull/5159 | 06:47 | |
| mup | PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159> | 06:47 |
| zyga | it went through an iteration with chipaca already | 06:47 |
| pstolowski | morning | 07:00 |
| mborzecki | we seem to be globbing the right egl libraries already, so what's missing is the vedor files only | 07:00 |
| mborzecki | i've built https://github.com/dv1/eglinfo and running some tests with it now | 07:00 |
| zyga | mvo: do you plan any more 2.32.x? | 07:00 |
| zyga | mborzecki: if so that would feel like an update to backport | 07:00 |
| mborzecki | or .33 material | 07:01 |
| zyga | 2.33 is not branched yet so it's full master | 07:02 |
| mborzecki | zyga: have you made any attempts at building nvidia snap? | 07:03 |
| zyga | mborzecki: no but after doing some research I would say we should split the responsibility of the snap | 07:03 |
| zyga | mborzecki: it should be a snap that only handles non-kmod aspect | 07:03 |
| zyga | so just userspace | 07:03 |
| mborzecki | zyga: yes, that's what i understand as nvidia snap | 07:03 |
| mborzecki | one for each driver version | 07:04 |
| mborzecki | actually that might be a track | 07:05 |
| zyga | mborzecki: yes, it should be a track | 07:14 |
| zyga | well | 07:14 |
| zyga | actually | 07:14 |
| zyga | no | 07:14 |
| zyga | what if you have >1 card? | 07:15 |
| zyga | old and a new one | 07:15 |
| zyga | is that even supported by the driver today/ | 07:15 |
| mup | PR snapd#5115 closed: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5115> | 07:16 |
| zyga | mvo: #5032 looks like a low hanging fruit | 07:18 |
| mup | PR #5032: repo: pass and return ConnRef via pointers <Simple> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5032> | 07:18 |
| mborzecki | zyga: each with different driver? | 07:19 |
| mborzecki | zyga: i think both cards have to be supported by the same driver, i.e. 9600gt and gt1030 setup is a no go | 07:20 |
| zyga | mborzecki: well, it depends on the actual support with the existing drivers | 07:20 |
| zyga | if it's not supported at all then yeah, tracks are natural | 07:20 |
| mborzecki | but gt730 and gt1030 is probably ok | 07:20 |
| zyga | snapd could have a hardware manager that looks at your cards and refreshes the right snap/track | 07:20 |
| mborzecki | yup | 07:20 |
| mborzecki | we could pull in those snaps as dependencies (like with do with content now) | 07:21 |
| zyga | yes | 07:21 |
| zyga | the OpenGL interface could be extended to do that | 07:21 |
| zyga | it would behave as a content interface to the special-cased nvidia snap | 07:21 |
| zyga | all without any app changes that is :) | 07:21 |
| pedronis | mvo: hi, this was the original comment that prompted the expansion, no: https://github.com/snapcore/snapd/pull/5124#discussion_r187167856 | 07:25 |
| mup | PR #5124: many: add wait command and seeded target <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5124> | 07:25 |
| mborzecki | coffee and rhubarb pie :) | 07:25 |
| zyga | pstolowski: some feedback on 4510 | 07:29 |
| newbee | In snapcraft how we clear the ppa:repository cache? | 07:30 |
| pstolowski | zyga: thanks | 07:37 |
| * zyga -> breakfast | 07:38 | |
| pedronis | zyga: pstolowski: I counter feedbacked | 07:39 |
| pstolowski | yep, reading, thanks | 07:39 |
| pedronis | pstolowski: I really don't see a reason to bring in the Mock* functions here | 07:40 |
| mvo | pedronis: yeah, thats correct | 07:43 |
| mvo | pedronis: sorry for the delay - I looked at the json package, the amount of types is pretty small we need to support if we limit to it | 07:44 |
| mvo | just FYI - I will do a 2.23.9 which *just* contains the spread fixes so that we get working autopkgtests agian on 16.04 | 07:45 |
| pedronis | mvo: I think we have 3 options: the json types, the yaml types (to be a bit more future proof and consistent with other similar code), everything but then it belong to some util package as mborzecki said and we need to consider some other cases | 07:46 |
| pstolowski | pedronis, zyga fair point about Mocks and just using Attrer interface, I'll change it, thanks! | 07:47 |
| pedronis | mvo: btw client uses jsonutil.DecodeWithNumber | 07:48 |
| mvo | pstolowski: is 5032 good to go? | 07:48 |
| mvo | pedronis: yeah, I agree. I have not looked at the types that yaml uses yet, if we go with the option (2) I need to do that | 07:49 |
| pedronis | mvo: so really only Number can appear and it's not documented in client which probably should | 07:49 |
| mvo | pedronis: what cases are missed for option(3) ? I know "nil" is missing right now, what else? | 07:49 |
| pstolowski | pedronis: yes | 07:49 |
| mvo | pedronis: yeah, I noticed we use json.Number, so I can remove "int" support too, right? | 07:50 |
| pedronis | mvo: yes, but you should go over client and see where it's relevant, it's likely only conf and debug stuff ? | 07:50 |
| pedronis | and put in the docs | 07:50 |
| mvo | pedronis: yeah, only conf even at this point (not even debug) | 07:51 |
| pedronis | I actually expect that to bite us at some point, I think the change was done indeed for conf stuff | 07:51 |
| eraserpencil | hi | 07:51 |
| mvo | pedronis: what in particular will bite us? | 07:51 |
| pedronis | that we write some code that forgets about it | 07:51 |
| pedronis | it's the only place we do that | 07:52 |
| pedronis | afair | 07:52 |
| mvo | pedronis: sorry, I'm a bit slow this morning: "forgets about it" - whats the "it" here? | 07:53 |
| eraserpencil | hi | 07:53 |
| pedronis | mvo: that decoding in client is using Number | 07:53 |
| mvo | pedronis: aha, right. let me check the client, I know we do it in the daemon everywhere(ish?) | 07:53 |
| pedronis | mvo: ? | 07:54 |
| pedronis | I see only one call in non-test code to UseNumber | 07:54 |
| pedronis | sorry | 07:54 |
| mvo | pedronis: oh, let me check, sorry, then I must mis-remember | 07:54 |
| pedronis | it's only all config code | 07:55 |
| pedronis | that uses it | 07:55 |
| pedronis | but in client is everything | 07:55 |
| mvo | pedronis: do you think it would be a good time to change this in the client? | 07:56 |
| pedronis | in which sense? | 07:56 |
| mvo | pedronis: change the client code to not use numbers so that it won't bite us in the future | 07:56 |
| pedronis | well, we do it for good reasons for config | 07:57 |
| pedronis | stuff | 07:57 |
| mvo | pedronis: its for the float vs int which we normally won't have, right? | 07:57 |
| pedronis | yes | 07:57 |
| mvo | pedronis: ok, I'm inclined to go with removing the extra code and just deal with the types that json produces (in the spirit of YAGNI) | 08:00 |
| pedronis | mvo: the only problematic place for Number is Attrs in interfaces.go | 08:00 |
| pedronis | atm | 08:00 |
| pedronis | having float64 for everything there is not good either though | 08:01 |
| mvo | pedronis: indeed | 08:01 |
| pedronis | but I think at least doSync document should mention the fact that it uses Number | 08:01 |
| mvo | pedronis: I can add this | 08:02 |
| pedronis | and the same in the documentation for Conf | 08:04 |
| pedronis | mvo: ^ | 08:06 |
| mvo | pedronis: ta, I will push something new shortly | 08:07 |
| pedronis | mvo: also I agree > 0 vs != 0 is a bit strange | 08:07 |
| pedronis | that was zyga comment | 08:07 |
| mup | PR snapd#5032 closed: repo: pass and return ConnRef via pointers <Simple> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5032> | 08:08 |
| mvo | pedronis: PR updated | 08:12 |
| mvo | yay, less than 40 PRs | 08:14 |
| Chipaca | yay | 08:14 |
| Chipaca | mvo: good morning | 08:14 |
| mvo | Chipaca: good morning | 08:14 |
| mup | PR snapd#5164 closed: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5164> | 08:15 |
| mvo | pedronis: pr is updated (and addressed zyga comments as well, sorry for the confusing behavior there) | 08:15 |
| zyga | thanks | 08:15 |
| mvo | zyga: thank you, that was a nice catch | 08:16 |
| zyga | mvo: one more nitpick | 08:18 |
| mvo | zyga: sure, keep them coming | 08:18 |
| pedronis | mvo: given the complexity you probably want a couple of end to end tests about 1.1 0.0 0 and 1 | 08:20 |
| mvo | pedronis: yeah, that makes sense | 08:21 |
| mborzecki | well egl is a bag of snakes apparently, i'm reading some presentation on egl external platform, afaict in the context of nvidia drivers it's only relevant for wayland now | 08:22 |
| pedronis | I mean RedirectClientToTestServer tests | 08:22 |
| mvo | pedronis: thanks, yes, that is what I understood :) | 08:23 |
| mvo | pedronis: +1 for this, will do that in a wee bit (doing the 2.32.9 SRU to unblock autopkgtests again) | 08:23 |
| mvo | pedronis: but once that is done I will add the tests and zyga nitpicks | 08:23 |
| pedronis | mvo: indeed snap interface --attrs (which I didn't know about) is probably broken because of Number | 08:34 |
| zyga | oh? | 08:35 |
| zyga | Number? | 08:35 |
| zyga | there are tests for --attr so whatever it is, should be easy to check | 08:35 |
| pedronis | they don't test the number case | 08:35 |
| pedronis | just strings | 08:35 |
| pedronis | anyway the impl is a bit naive anyway | 08:35 |
| pedronis | but Number isn't helping it | 08:36 |
| mup | PR snapd#5168 opened: release: 2.32.9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5168> | 08:36 |
| zyga | woah | 08:36 |
| zyga | woah | 08:36 |
| zyga | 9? | 08:36 |
| pedronis | because of autopkgtests | 08:36 |
| pedronis | mvo mentioned before here | 08:37 |
| zyga | ah, a test-only release | 08:37 |
| zyga | uff :) | 08:37 |
| mvo | zyga: yeah, just tests, no further change | 08:37 |
| pedronis | so the kind of bug I expected in future, is already in the present/past | 08:38 |
| mvo | xnox: I get errors on s390x in cosmic in the snapd autopkgtests when trying to read /dev/kmsg - is that something new? afaict this test used to work. should we just blacklist it on s390x ? | 08:39 |
| mvo | pedronis: I can have a look in a wee bit | 08:39 |
| pedronis | not super important I suspect | 08:39 |
| pedronis | less important than progressing with the review sprint | 08:39 |
| pedronis | atm | 08:39 |
| pedronis | the bug has been there since a long while | 08:40 |
| mborzecki | zyga: it feels like we should have the opengl interface produce mount entries for vulkan and egl | 08:40 |
| zyga | mborzecki, yes, can you expand on that idea, I'd like to do that and ditch the nvidia code in snap-confine | 08:40 |
| zyga | we're now very much equipped to do that | 08:40 |
| mborzecki | zyga: why exactly the nvidia setup is done in snap-confine now? or is it just historical? | 08:45 |
| zyga | just historical | 08:45 |
| zyga | snap-confine is far older than snap-update-ns and mount profiles | 08:45 |
| zyga | it dates back to 15.04 and before | 08:46 |
| mvo | the dawn of time! | 08:46 |
| mborzecki | i was afraid of some pivot_root play or whatever but if it's historical then maybe we could dump/trim it now | 08:46 |
| zyga | mborzecki: now that we have full access to hostfs all nvidia setup can easily be done after pivot_root in a mount profile | 08:47 |
| mborzecki | yes, that's what i'm looking into now | 08:47 |
| zyga | mborzecki: my suggestion: how to update existing namespaces (we cannot easily) | 08:47 |
| mborzecki | we could pick out the libraries from the host, glob it nicely in go code | 08:47 |
| zyga | mborzecki: write a function for what you just said above, that computes the mount profile for various use-cases of nvidia | 08:48 |
| zyga | mborzecki: and add a mode in snap-confine where nvidia is managed by snapd | 08:48 |
| zyga | mborzecki: (maybe via --managed-nvidia or something) | 08:48 |
| mborzecki | if system-key changes, the mount profile will be regenerated too? | 08:48 |
| zyga | mborzecki: so that we can opt in/out | 08:48 |
| zyga | mborzecki: yes but existing mount namespaces cannot be updated | 08:49 |
| zyga | mborzecki: on a system that does snapd update with running apps it would pose a problem | 08:49 |
| mborzecki | ok, so PRIME (maybe) or old optimus then | 08:49 |
| zyga | mborzecki: so what I'm saying, keep the old code for now for transition purpose | 08:49 |
| zyga | mborzecki: but also keep in mind that we don't want to break apps on snapd update and that updating pre-pivot-root mount namespace is tricky | 08:49 |
| zyga | mborzecki: so maybe don't try that, just wait for reboot or namespace invalidation | 08:50 |
| zyga | mborzecki: it's an edge case that is better left as-is | 08:50 |
| mborzecki | zyga: the upside is that if you install/enable the driver, you have to reboot/stop all apps anyway | 08:51 |
| xnox | mvo, it should work.... the kernel between bionic & cosmic should be the same, and i better hope that /dev/kmsg works.... | 08:57 |
| xnox | mvo, if you don't have it blacklisted on other releases, there is nothign special about cosmic... | 08:58 |
| * zyga asks for a review of #5159 | 08:58 | |
| mup | PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159> | 08:58 |
| mvo | xnox: ok, I will dig into it then | 09:02 |
| mvo | xnox: thank you! | 09:02 |
| sparkiegeek | hmm, after pulling in 2.32.8+18.04 on my bionic machine I'm left without a running snapd service | 09:03 |
| sparkiegeek | https://paste.ubuntu.com/p/Vx8SK2xmDW/ <- socket was stopped and not restarted? | 09:03 |
| sparkiegeek | dpkg.log https://paste.ubuntu.com/p/ZcwcH2pbtb/ | 09:05 |
| mvo | sparkiegeek: weeeh, but no install error or anything? | 09:05 |
| sparkiegeek | mvo: nope | 09:05 |
| mvo | sparkiegeek: from what version did you upgrade? /var/log/apt/history.log should tell you | 09:05 |
| sparkiegeek | mvo: snapd:amd64 (2.32.5+18.04, 2.32.8+18.04) | 09:06 |
| sparkiegeek | ahh Error: Sub-process /usr/bin/dpkg returned an error code (2) | 09:06 |
| mvo | sparkiegeek: I just tested this on a spare bionic box and went from 2.32.6->.8 without this but that is quite scary | 09:06 |
| mvo | sparkiegeek: puhh, at least an error - well, an error still sucks but the alternative would be worse | 09:06 |
| sparkiegeek | mvo: so, I just `dpkg --configure -a` | 09:06 |
| sparkiegeek | that seems to have unblocked it | 09:06 |
| mvo | sparkiegeek: can you paste me the details of the error please? either from /var/log/apt/term.log or history.log (former probably has more info) | 09:07 |
| mvo | sparkiegeek: was the dpkg error related to snapd? or an unrelated package? | 09:07 |
| sparkiegeek | mvo: looks like dpkg lock issues, pasting | 09:07 |
| mvo | sparkiegeek: if unrelated package thats "expected" (and one reason we like snaps), apt will just stop dpkg in this case and the daemons are usually stopped early | 09:08 |
| mvo | sparkiegeek: thank you | 09:08 |
| sparkiegeek | mvo: https://paste.ubuntu.com/p/GMshWgdrSh/ | 09:08 |
| sparkiegeek | note that this wasn't interactive | 09:08 |
| mvo | sparkiegeek: this was unattended-upgrades? | 09:08 |
| mvo | sparkiegeek: was there anything else running at the same time? packagekit or gnome-software or anything like this? or was this on a server | 09:08 |
| mvo | sparkiegeek: its not (strictly speaking) my turf but I don't like this :/ | 09:09 |
| sparkiegeek | mvo: yeah, I think it might have been landscape... | 09:09 |
| mvo | sparkiegeek: so any extra info about the system is appreciated | 09:09 |
| mvo | sparkiegeek: aha, interessting | 09:09 |
| sparkiegeek | (now snapd is running, using my browser becomes easier!) | 09:10 |
| pstolowski | zyga: pedronis addressed your feedback re 4510 | 09:14 |
| zyga | ack | 09:16 |
| mvo | pedronis: I added the integration test you asked about in 5157 | 09:18 |
| eraserpencil | is making a gadget snap the only way to apply udev rules to a device? | 09:22 |
| Lin-Buo-Ren | https://github.com/ubuntu/snapcraft-desktop-helpers/issues/117 | 09:23 |
| zyga | Lin-Buo-Ren: what changed in the before/after? | 09:26 |
| zyga | eraserpencil: one more way is to add an interface | 09:26 |
| eraserpencil | zyga: like exposing a serial port or usb port | 09:27 |
| zyga | eraserpencil: usb port? | 09:28 |
| zyga | those don't need to be exposed, what is the rule you are after? | 09:28 |
| mup | PR snapd#5169 opened: snap: fix `snap interface --attrs` output when numbers are used <Created by mvo5> <https://github.com/snapcore/snapd/pull/5169> | 09:29 |
| eraserpencil | assigning usb ports to usb devices if/when plugged in | 09:31 |
| mup | PR snapd#5168 closed: release: 2.32.9 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5168> | 09:33 |
| eraserpencil | zyga: actually, I'm more interested in exposing the serial port, which i read needs a gadget port | 09:38 |
| zyga | eraserpencil: yes, that's correct | 09:38 |
| zyga | you need a gadget for that | 09:38 |
| Chipaca | mvo: want to link the "boot modes" doc from https://forum.snapcraft.io/t/documentation-outline/3781 ? | 09:39 |
| Chipaca | mvo: building the case for a 'devices' heading in there soon :-) | 09:39 |
| pedronis | that was what was about to say, there is no core specific content there yet | 09:39 |
| Chipaca | pedronis: “Enabling swap on core devices” is on there | 09:40 |
| pedronis | in the wrong section | 09:40 |
| Chipaca | pedronis: how do you figure | 09:41 |
| Chipaca | pedronis: it's not "developing", and it's not "publishing" | 09:41 |
| zyga | I think device makers need a dedicated section | 09:41 |
| Chipaca | pedronis: of the sections there are, it's under the right one | 09:41 |
| zyga | that's neither developing nor publishing | 09:41 |
| pedronis | Chipaca: I don't know | 09:42 |
| Chipaca | I agree, but it's not going to happen unless we write things for devices | 09:42 |
| Chipaca | thus, my prompting mvo to link to the thing he wrote | 09:42 |
| Chipaca | with two device-specific entries, we could think of a section for them | 09:42 |
| Chipaca | although "Devicing" is not a word | 09:43 |
| Chipaca | :-) | 09:43 |
| mvo | Chipaca: hm, yes. linking makes sense | 09:44 |
| mvo | Chipaca: I added it under "Using" for now but I think we need niemeyer to discuss where to put ubuntu core specific bits, the current naming makes it a bit hard and I don't want to add somehting that is totally out of line | 09:46 |
| pstolowski | there was a failure in master on snap-confine-from-core test: https://api.travis-ci.org/v3/job/379596518/log.txt ; it seems we didn't match on "restarting into" in the journal | 09:55 |
| zyga | -- Logs begin at Wed 2018-05-16 08:21:06 UTC, end at Wed 2018-05-16 08:29:15 UTC. -- | 09:57 |
| zyga | May 16 08:29:04 may160809-192333 kernel: audit: type=1400 audit(1526459344.395:475): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.test-snapd-tools.head" pid=21848 comm="apparmor_parser" | 09:57 |
| zyga | this is the head of the log | 09:57 |
| zyga | it feels to me like it is too late | 09:57 |
| zyga | the cursor logic may be inaccurate? | 09:58 |
| pstolowski | I think the cursor changes landed quite some time ago? or is it a recent change? | 09:59 |
| zyga | recent | 09:59 |
| pstolowski | ok | 10:00 |
| newbee | please guide us how to add external jar in snapcraft.ymal file. for example to access postgres database i need postgres.jar in my project lib path, i want to add like that in my snap | 10:01 |
| pstolowski | newbee: you need to add it as a part in your parts: section to have it bundled somewhere in the snap; then you will most likely want a wrapper shell script for your app that sets CLASSPATH properly | 10:04 |
| newbee | @pstolowski, ok, and just clarify us, in which part have to that, any example for this plese | 10:21 |
| sparkiegeek | mvo: just for completeness, my issue seems to have been a bad interaction between unattended upgrades and landscape, which I'm pursuing with the Landscape team | 10:25 |
| mvo | sparkiegeek: I suspect the underlying issue is that apt needs a more global lock. right now it is using the dpkg lock but there is a race because apt needs to release that in order to let dpkg do the work. so a higher level /var/lib/apt/lock would be in order that everything libapt respects. this can then be kept being locked even when the lower-level dpkg lock is released | 10:31 |
| zyga | mvo: thank you for the review on #5159, replied | 10:32 |
| mvo | zyga: ta | 10:32 |
| mup | PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159> | 10:32 |
| zyga | mvo: as for Call and RCall, maybe we should call the function RECall | 10:33 |
| zyga | as or just Recall | 10:33 |
| zyga | it would play nice on the Result, Error and Call | 10:33 |
| zyga | and it is also a word | 10:33 |
| zyga | recall what happened | 10:33 |
| zyga | hmm? | 10:33 |
| mvo | zyga: no strong opinion about this | 10:35 |
| mvo | zyga: I was mostly curious if its something I should know | 10:35 |
| sparkiegeek | mvo: ack, waveform has found some /interesting/ lock behaviour in unattended-upgrades too | 10:38 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | newbee: see the advanced examples here https://docs.snapcraft.io/build-snaps/parts | 10:39 |
| waveform | mvo, I'm probably making a mistake but looking through unattended-upgrades, the Unlocked context manager looks ... unusual | 10:39 |
| mvo | sparkiegeek: it will unlock the dpkg lock quite often as it runs many dpkg operations (it defaults to minimal upgrade mode nowdays) | 10:39 |
| waveform | it's called apt_pkg.pkgsystem_unlock on both __enter__ *and* __exit__ | 10:39 |
| mvo | waveform: oh? let me see | 10:39 |
| waveform | (and it wraps both calls in bare try..except so a double-unlock will go unnoticed) | 10:39 |
| pstolowski | newbee: one of your parts will be the jar file, and you will probably want to use dump plugin to have it copied into a specific place in the resulting snap; see https://docs.snapcraft.io/reference/plugins/dump | 10:39 |
| mup | PR snapd#5170 opened: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170> | 10:40 |
| mvo | waveform: yeah, that looks very broken | 10:41 |
| waveform | as far as I can tell Unlocked is only used by cache_commit, which is only used by do_install and do_auto_remove | 10:41 |
| waveform | so I don't *think* this would get called by a default config (which might explain why it's not been seen yet?) | 10:41 |
| waveform | still, it looked rather weird to me! | 10:42 |
| mvo | waveform: very sure this is a bug | 10:42 |
| waveform | ok, thanks - glad I'm not missing something! | 10:42 |
| mvo | waveform: I will propose a fix and followup with foundations about it | 10:43 |
| waveform | ta | 10:43 |
| mvo | waveform: thank *you* | 10:43 |
| waveform | mvo, incidentally ... I couldn't figure out where the pkgsystem lock gets removed; main sets it (with pkgsystem_lock) but the only place pkgsystem_unlock is called (I think?) is in Unlocked which isn't *necessarily* called by main ... | 10:46 |
| waveform | ... so I'm not sure if something higher level is dealing with that lock later, or if there's some logic for breaking stale locks somewhere ... either way, that was another bit that felt rather odd to me | 10:47 |
| mvo | waveform: when u-u exists the lock is automatically freeed but it holds it for its entire lifetime | 10:47 |
| waveform | ah, that explains it | 10:48 |
| pstolowski | zyga: replied to your comments on 4510 | 10:48 |
| mborzecki | zyga: land #5159 ? | 10:48 |
| mup | PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159> | 10:48 |
| zyga | pstolowski: +1 | 10:49 |
| zyga | mborzecki: yes please | 10:49 |
| zyga | mborzecki: I will do follow ups that adjust things to move to RCall | 10:49 |
| pstolowski | zyga: ty! | 10:50 |
| mup | PR snapd#4510 closed: asserts: use Attrer in policy checks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4510> | 10:50 |
| mup | PR snapd#5159 closed: testutil: record system call errors / return values <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5159> | 10:50 |
| pstolowski | yay, more PRs landing today | 10:51 |
| mvo | waveform, sparkiegeek thanks again for the report! | 10:51 |
| waveform | np | 10:51 |
| zyga | mborzecki: about our earlier discussion | 10:56 |
| zyga | https://github.com/snapcore/snapd/pull/4889#discussion_r188582792 | 10:56 |
| mup | PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889> | 10:56 |
| zyga | this made my day :-( | 10:56 |
| zyga | :-) | 10:56 |
| mborzecki | hm you mean x-snapd.role? is it always stored? | 11:00 |
| zyga | mborzecki: we can tag our mounts | 11:00 |
| zyga | read the man page | 11:00 |
| zyga | look for X. and x. | 11:00 |
| mborzecki | yeah, it's hairy, libmount tools etc | 11:00 |
| zyga | libmount is not the key, the key is that the kernel stores this | 11:01 |
| mborzecki | zyga: are you sure? just tried something, mount shows the options, /proc/$$/mount{s,info} does not | 11:03 |
| pedronis | the man page lists places is not stored, not where it is | 11:03 |
| pedronis | a bit unclear | 11:04 |
| pedronis | is says it doesn't go to mount(2) though | 11:04 |
| mborzecki | wonder where it keeps it though | 11:04 |
| zyga | hmmm | 11:04 |
| zyga | yes, I agree | 11:04 |
| mborzecki | wouldn't be surprised if there's some shm just to store this | 11:05 |
| zyga | it is /run/mount/utab | 11:06 |
| pedronis | searching for that gives references to this: https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.23/libmount-docs/libmount-Tables-update.html | 11:14 |
| zyga | this is certainly something to consider | 11:16 |
| pedronis | we can always list the mimic paths in some /run file of our own? | 11:18 |
| zyga | yes, that's another option | 11:18 |
| zyga | though I think using the same file would have some advantages, e.g. mount would print that | 11:19 |
| * zyga dog walk & lunch | 11:22 | |
| pedronis | zyga: does it? I don't see it listing in xenial | 11:23 |
| zyga | I checked artful | 11:25 |
| pedronis | in xenial that command line (in the PR) doesn't file but mount doesn't list anything | 11:25 |
| pedronis | and utab is there but empty | 11:25 |
| pedronis | s/file/fail/ | 11:25 |
| pedronis | unless I'm missing something | 11:25 |
| mborzecki | too old util-linux? | 11:35 |
| Lin-Buo-Ren | zyga: The default font used to render the characters | 11:36 |
| zyga | So the snap has changed? | 11:36 |
| zyga | Was the application snap the same or was it rebuilt? | 11:36 |
| pedronis | mvo: what is stopping #5095 from being merged? | 11:39 |
| mup | PR #5095: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/5095> | 11:39 |
| ads20000 | https://forum.snapcraft.io/t/support-for-appstream-id/2327/19 there's been nothing posted in here since February and is apparently a blocker for deduplicating Software listings, I don't normally like asking for progress but it's unclear to a non-technical user how finished this is? :) | 11:44 |
| * cachio_ afk | 11:48 | |
| pedronis | mborzecki: don't know, but we need something that works also in xenial and trusty(?) | 11:52 |
| * zyga waits for police to get a drunken guy off school yard | 11:52 | |
| zyga | Also, it started raining now | 11:54 |
| pstolowski | zyga: land #4968? | 12:01 |
| mup | PR #4968: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968> | 12:01 |
| zyga | In the rain, returning home | 12:02 |
| zyga | But yes | 12:02 |
| zyga | Please | 12:02 |
| pstolowski | thx | 12:07 |
| mup | PR snapd#4968 closed: ifacemgr: remove stale connections on startup <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4968> | 12:07 |
| zyga | re, food and back to PRs | 12:15 |
| mup | PR snapd#5095 closed: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5095> | 12:19 |
| Lin-Buo-Ren | zyga: The snap is rebuilt with snapcraft.yaml constantly changing, so I can't tell | 12:34 |
| Lin-Buo-Ren | I'm trying to rebuild the snap with old revision of desktop-helpers to see the issue can still be reproduced | 12:34 |
| zyga | can you install the old revision? are you the developer of that snap? | 12:34 |
| Lin-Buo-Ren | @zyga I don't keep the old builds but can rebuild them if needed; I'm working with upstream with the snap packaging | 12:46 |
| zyga | Lin-Buo-Ren: if you are the developer of that snap (you can publish releases) then you can also install any old revision | 12:46 |
| zyga | just snap install -r | 12:46 |
| zyga | see if current snapd makes old revisions work correctly | 12:47 |
| zyga | if this is an issue with snapd or with the desktop helpers | 12:47 |
| niemeyer | ads20000: There's just one piece missing which is the integration on snapd proper.. that's scheduled for this cycle | 12:48 |
| Lin-Buo-Ren | zyga: I just successfully pushed a few releases on the store, I'll check it out | 12:48 |
| niemeyer | ads20000: Updated the topic | 12:49 |
| ads20000 | thank you niemeyer for the update! <3 | 12:49 |
| niemeyer | ads20000: np | 12:50 |
| mborzecki | hmm gnome session got killed again | 12:57 |
| zyga | mborzecki: what happens? | 12:57 |
| mborzecki | again when snaps were being installed | 12:57 |
| popey | mborzecki: is that when installing a snap? I find it happens when the opengl interface is connecting | 12:57 |
| popey | you on nvidia? | 12:57 |
| thresh | meh, fonts are invisible again | 12:58 |
| mborzecki | zyga: http://paste.ubuntu.com/p/w42w3SW4RG/ | 12:58 |
| pstolowski | snapc-confine-core failed again in master; there is also test-snapd-python-webserver.test-snapd-python-webserver[21122]: ImportError: No module named 'contextlib' there | 12:58 |
| thresh | snap-ns-disccard thingie worked though, but I didnt use nvidia bumblebee/prime or whatever that is | 12:58 |
| mborzecki | it's like Xorg was gone | 12:58 |
| mborzecki | popey: yes, on nvidia | 12:58 |
| popey | same as me, xorg goes bang | 12:58 |
| niemeyer | That sounds pretty bad.. :/ | 12:59 |
| niemeyer | mborzecki: Please let us know what you find there | 12:59 |
| niemeyer | I won't be in the standup today as we have a conflicting meeting, and also have one right after it so we can't even reschedule | 12:59 |
| mvo | zyga, pstolowski I have a conflicting | 13:00 |
| mvo | meeting | 13:00 |
| zyga | ack | 13:00 |
| popey | niemeyer: mborzecki https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104 | 13:00 |
| pstolowski | k | 13:00 |
| niemeyer | popey: Can't see it | 13:01 |
| mborzecki | popey: me neither | 13:01 |
| mvo | and niemeyer also has the same conflicting meeting now | 13:01 |
| popey | made it public | 13:01 |
| popey | I have had this about 4 or 5 times now | 13:01 |
| popey | kinda annoying to have your entire session blown away when doing "snap install" | 13:01 |
| zyga | popey: we are discussing this in the standup now | 13:14 |
| popey | thanks | 13:14 |
| Son_Goku | popey, with nvidia and ogl, snaps cause the system to flicker every minute :/ | 13:15 |
| Son_Goku | that happens on Fedora | 13:15 |
| popey | ooer, not seen that | 13:15 |
| Son_Goku | it doesn't cause gnome session to crash, but I almost would have preferred that | 13:15 |
| popey | hah! | 13:15 |
| Son_Goku | though I suspect it _would_ crash if I was using xorg | 13:15 |
| mborzecki | Son_Goku: system to flicker, can you elaborate? | 13:16 |
| popey | maybe get a video with a cell phone? | 13:17 |
| Son_Goku | mborzecki, display session looks like it's constantly refreshing slowly | 13:17 |
| Son_Goku | this is with free drivers, since my card is old enough | 13:17 |
| Son_Goku | I suspect it'd crash on f28 + nvidia + proprietary | 13:17 |
| Son_Goku | snapd 2.32.4 | 13:18 |
| zyga | .4 oh gosh | 13:28 |
| zyga | we are at .8 | 13:28 |
| zyga | ;-) | 13:28 |
| Son_Goku | dude, I haven't had any time | 13:29 |
| mvo | we are at .9 ;) | 13:29 |
| Son_Goku | oh god | 13:29 |
| Son_Goku | zyga, mvo: the next time I update snapd will be the last one for Fedora 26 | 13:31 |
| mborzecki | zyga: yeah, it seems that udev rules are reloaded | 13:36 |
| mborzecki | udevadm monitor is showing a change for each device | 13:36 |
| zyga | Son_Goku: that's fine | 13:37 |
| zyga | we are looking at F29 :) | 13:37 |
| Son_Goku | zyga, you got the list from me on the stuff we need to touch, right? | 13:38 |
| zyga | yes | 13:38 |
| zyga | I was wondering how to start | 13:38 |
| zyga | shall we merge your code somewhere? | 13:38 |
| mborzecki | hahaha now my sound is gone | 13:38 |
| mborzecki | pcspkr works though | 13:38 |
| Son_Goku | zyga, well, my code is pretty much PoC | 13:39 |
| Son_Goku | to integrate into oz, koji, and pungi will require different code | 13:39 |
| zyga | Son_Goku: which tool shall we start with? koji? | 13:40 |
| Son_Goku | oz | 13:40 |
| Son_Goku | it's the thing that actually makes the stuff | 13:40 |
| zyga | ah | 13:40 |
| zyga | ok | 13:40 |
| zyga | is it easy to run? | 13:40 |
| * Son_Goku shrugs | 13:40 | |
| Son_Goku | looks like it | 13:41 |
| Son_Goku | https://github.com/redhat-imaging/imagefactory | 13:41 |
| === pstolowski is now known as pstolowski|lunch | ||
| b_b | hi | 14:15 |
| b_b | can anyone point me on a basic snap question ? | 14:15 |
| b_b | i'm trying to snap a python app | 14:15 |
| b_b | http://thetimelineproj.sourceforge.net/about.html this one | 14:15 |
| b_b | for now i've got this yaml file | 14:16 |
| b_b | http://pastebin.fr/53663 | 14:16 |
| b_b | and the app need python-wxgtk2.8 ubuntu package | 14:16 |
| b_b | i'm not sure how to write this dependencie | 14:17 |
| b_b | with a stage-packages ? | 14:17 |
| popey | yes | 14:18 |
| popey | stage-packages: | 14:18 |
| popey | - python-wxgtk2.8 | 14:18 |
| b_b | http://pastebin.fr/53664 like this ? | 14:19 |
| b_b | thx popey :) | 14:19 |
| b_b | so, i can try to prime it now | 14:20 |
| popey | yeah, like that | 14:21 |
| b_b | i was missing a space | 14:21 |
| b_b | hmm prime wants to install libpython3-dev libpython3.5-dev python3-dev etc. | 14:23 |
| b_b | ever if i add python-version: python2 | 14:23 |
| popey | did you add that to both parts? | 14:24 |
| b_b | 'k, got to add it to the two parts ^^ | 14:24 |
| b_b | nice | 14:24 |
| b_b | Failed to stage: Parts 'timeline' and 'humblewx' have the following files, but with different contents: | 14:34 |
| b_b | usr/lib/python2.7/UserString.py | 14:34 |
| b_b | etc. | 14:34 |
| === pstolowski|lunch is now known as pstolowski | ||
| b_b | http://pastebin.fr/53665 | 14:35 |
| b_b | for info, the provided zip for timeline doesn't need a build | 14:36 |
| b_b | cf http://thetimelineproj.sourceforge.net/installing.html#installing-from-source | 14:36 |
| b_b | 'k, it seems i have to stage all thath files | 14:56 |
| b_b | hmmm timeline seems to be a "prebuilt app", so dump plugin will do the trick | 15:08 |
| b_b | same error with this yaml http://pastebin.fr/53666 | 15:13 |
| b_b | anyone know a working snap of this type of app that can provide me an exemple ? | 15:18 |
| popey | might have more success on the forum | 15:21 |
| b_b | 'k | 15:22 |
| mup | PR snapd#5171 opened: ifacestate: unify reconnect and autoconnect methods <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5171> | 15:33 |
| b_b | got it with http://pastebin.fr/53667 | 15:44 |
| pstolowski | cachio_: you asked about faillog for journalctl issue? https://api.travis-ci.org/v3/job/379684074/log.txt | 15:48 |
| mup | PR snapcraft#2139 closed: ci: remove unused cron tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2139> | 15:51 |
| mup | PR snapd#5090 closed: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5090> | 15:55 |
| === pstolowski is now known as pstolowski|afk | ||
| cachio_ | pstolowski|afk, tx | 16:16 |
| chzbacon | hey guys, i'm having a time trying to get logged into a fresh install of core on a raspberry pi 3. might anyone be able to lend a hand? | 16:30 |
| chzbacon | can i not connect locally? ie chzbacon@192.168.1.xx ? | 16:31 |
| popey | once it's setup, you can. | 16:31 |
| popey | to do the setup you need to either connect a serial cable or keyboard/display | 16:31 |
| chzbacon | i'm trying to login from another local machine on the network (which i've uploaded the public key for). I still get prompted for a password though. | 16:31 |
| popey | have you been through the first run setup? | 16:32 |
| chzbacon | yeah i set it up last night using a kb and monitor | 16:32 |
| chzbacon | yup | 16:32 |
| popey | are you specifying the right username as well as the ip? | 16:32 |
| chzbacon | i didn't see any prompt for a password though. i think so. chzbacon@gmail.com | 16:33 |
| popey | no, it uses ssh key not password | 16:34 |
| chzbacon | that's what i thought. i've tried both a key with a passphrase and without. | 16:35 |
| chzbacon | i'll just go back through the steps once i get home. maybe i messed something up. | 16:52 |
| b_b | so my latester attempt works fine with prime | 17:43 |
| b_b | http://pastebin.fr/53667 | 17:43 |
| b_b | now i need to copye the content of the zip somewhere in order to get this working | 17:44 |
| b_b | since there is no setup.py in the zip | 17:44 |
| b_b | anyone have a clue to do that ? | 17:44 |
| b_b | https://docs.snapcraft.io/build-snaps/syntax#stage is maybe what i'm searching for ? | 17:46 |
| b_b | or maybe https://docs.snapcraft.io/build-snaps/syntax#prime | 17:47 |
| jdstrand | niemeyer: fyi, I didn't mention you in the response so you may not have seen it, but I responded in https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/8 | 17:51 |
| niemeyer | jdstrand: Thanks, replied there | 18:48 |
| * cachio_ afk | 18:56 | |
| b_b | my last attempt work fine until i try to lauch timeline command | 19:39 |
| b_b | http://pastebin.fr/53670 | 19:39 |
| skomorokh | Is a "classic" confinement snap just classic in the sense that it runs unconfined as the user when they load the app or does it also let the package maintainer run scripts as root like a .deb or similar? | 19:39 |
| b_b | enough for this day :p | 19:39 |
| b_b | ++ | 19:39 |
| cachio_ | e | 20:03 |
| jdstrand | kjackal: hey, fyi, https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/9 | 20:45 |
| jdstrand | kjackal: it doesn't completely solve the microk8s problem, but does mean that the docker snap could be modified to have a 'signal (receive) peer=snap.*,' rule in its default container policy. with that, microk8s could 'plugs: [ process-control ]' and send signals to the docker snap's containers | 20:48 |
| jdstrand | kjackal: there are other options once you've decided what docker to use | 20:49 |
| jdstrand | kjackal: honestly, I still think that shipping your own docker is going to be the most robust snap implementation (since you don't have to worry about docker changing incompatibly from under you, and you can adjust its policies, etc) | 20:50 |
| jdstrand | kjackal: we can chat later at your convenience | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!