=== 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 [04:34] 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:36] 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 [05:21] morning [05:22] hey mborzecki ! good morning [05:24] 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:26] PR snapd#5166 opened: tests: go must be installed as a classic snap [05:26] mborzecki: *cough* yeah, but hopefully we do better over the coming days [05:55] mvo: #5156 can be merged now? [05:55] PR #5156: core-fixup: address review feedback from #5147 [05:57] mborzecki: yes, done. thank you! [05:58] PR snapd#5156 closed: core-fixup: address review feedback from #5147 [05:59] PR snapd#5167 opened: tests: cherry-pick more GCE commits [06:00] PR snapd#5166 closed: tests: go must be installed as a classic snap [06:01] PR snapd#5160 closed: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle [06:04] good morning [06:16] PR snapd#5061 closed: tests: ensure interfaces-network-bind daemon is stopped early [06:17] mvo: I will be off for 5 work days, starting tomorrow [06:18] PR snapd#4562 closed: debian: add a zenity|kdialog suggests [06:19] zyga: nice! will you go on vac? [06:20] mvo: ish, yes, we need to go and wrap up some stuff in Catalonia [06:20] mvo: but also some vac hopefully, a surprise birthday party for our close friend there [06:20] (she doesn't know we're coming yet :) [06:21] zyga: ha! nice [06:21] I will take my laptop (obviously) so I can still help land stuff while nothing better to do around [06:21] this reminds me, I need to find my Vodafone SIM and install it [06:23] * zyga installed an air filter yesterday [06:23] and ... shockingly, it worsk [06:23] air filter where? [06:23] my desk was covered in dust every morning, driving me insane [06:23] it's a pretty big box standing right next to me [06:24] I moved my hand across the desk and keyboard this morning and it was clean as if wiped a moment ago [06:24] ah, that dust, isn't that some pollen or the mythical sands from sahara dragged over europe? [06:24] before it was always full of fine powdery dust [06:24] well, whatever it is, the machine works :) [06:27] make sure to clean the filter regularly, otherwise you may have a close encounter with fungi spores dispersed in the air [06:28] mborzecki: yeah, I need to learn proper maintenance [06:28] it has a nice phone app to measure stuff though, it will surely remind me of everything :) [06:28] zyga: xiaomi? [06:28] yes [06:28] model 2 [06:29] it was 200zł off the normal price to celebrate a new store that opened in warsaw [06:30] PR snapd#5167 closed: tests: cherry-pick more GCE commits [06:30] aah yes, 'big event' :), well whatever people say, they have a better track updating their firmware than most vendors [06:30] hehe, yes, it had a firmware update out of the box [06:31] so far I'm happy, it is quiet on auto and seems to solve my biggest annoyance with home office, [06:31] so morphis found some issues with egl support, i'm looking into that [06:31] I saw [06:31] it's interesting [06:32] maybe run a strace -e open [06:32] and see what else is opened by sample app [06:32] then sort -u the paths [06:32] there should be a handful of things really [06:32] it should be easy to fix [06:32] at least it's saner than what vulkan setup did [06:32] (though the mechanism is similar) [06:35] mvo: shall we do `xmessage -buttons Yes:0,No:1 -default Yes -nearmouse "shall we do xmessage?" -timeout 10` ? [06:36] mborzecki: as a fallback if zenity or kdialog are not around? probably a good idea but its pretty hardcore [06:37] mborzecki: I mean, Xaw [06:37] haha yes [06:47] * zyga requests a review for https://github.com/snapcore/snapd/pull/5159 [06:47] PR #5159: testutil: record system call errors / return values [06:47] it went through an iteration with chipaca already [07:00] morning [07:00] we seem to be globbing the right egl libraries already, so what's missing is the vedor files only [07:00] i've built https://github.com/dv1/eglinfo and running some tests with it now [07:00] mvo: do you plan any more 2.32.x? [07:00] mborzecki: if so that would feel like an update to backport [07:01] or .33 material [07:02] 2.33 is not branched yet so it's full master [07:03] zyga: have you made any attempts at building nvidia snap? [07:03] mborzecki: no but after doing some research I would say we should split the responsibility of the snap [07:03] mborzecki: it should be a snap that only handles non-kmod aspect [07:03] so just userspace [07:03] zyga: yes, that's what i understand as nvidia snap [07:04] one for each driver version [07:05] actually that might be a track [07:14] mborzecki: yes, it should be a track [07:14] well [07:14] actually [07:14] no [07:15] what if you have >1 card? [07:15] old and a new one [07:15] is that even supported by the driver today/ [07:16] PR snapd#5115 closed: interfaces: add xdg-document-portal support to desktop interface [07:18] mvo: #5032 looks like a low hanging fruit [07:18] PR #5032: repo: pass and return ConnRef via pointers

[07:19] zyga: each with different driver? [07:20] 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] mborzecki: well, it depends on the actual support with the existing drivers [07:20] if it's not supported at all then yeah, tracks are natural [07:20] but gt730 and gt1030 is probably ok [07:20] snapd could have a hardware manager that looks at your cards and refreshes the right snap/track [07:20] yup [07:21] we could pull in those snaps as dependencies (like with do with content now) [07:21] yes [07:21] the OpenGL interface could be extended to do that [07:21] it would behave as a content interface to the special-cased nvidia snap [07:21] all without any app changes that is :) [07:25] mvo: hi, this was the original comment that prompted the expansion, no: https://github.com/snapcore/snapd/pull/5124#discussion_r187167856 [07:25] PR #5124: many: add wait command and seeded target [07:25] coffee and rhubarb pie :) [07:29] pstolowski: some feedback on 4510 [07:30] In snapcraft how we clear the ppa:repository cache? [07:37] zyga: thanks [07:38] * zyga -> breakfast [07:39] zyga: pstolowski: I counter feedbacked [07:39] yep, reading, thanks [07:40] pstolowski: I really don't see a reason to bring in the Mock* functions here [07:43] pedronis: yeah, thats correct [07:44] 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:45] 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:46] 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:47] pedronis, zyga fair point about Mocks and just using Attrer interface, I'll change it, thanks! [07:48] mvo: btw client uses jsonutil.DecodeWithNumber [07:48] pstolowski: is 5032 good to go? [07:49] 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] mvo: so really only Number can appear and it's not documented in client which probably should [07:49] pedronis: what cases are missed for option(3) ? I know "nil" is missing right now, what else? [07:49] pedronis: yes [07:50] pedronis: yeah, I noticed we use json.Number, so I can remove "int" support too, right? [07:50] mvo: yes, but you should go over client and see where it's relevant, it's likely only conf and debug stuff ? [07:50] and put in the docs [07:51] pedronis: yeah, only conf even at this point (not even debug) [07:51] I actually expect that to bite us at some point, I think the change was done indeed for conf stuff [07:51] hi [07:51] pedronis: what in particular will bite us? [07:51] that we write some code that forgets about it [07:52] it's the only place we do that [07:52] afair [07:53] pedronis: sorry, I'm a bit slow this morning: "forgets about it" - whats the "it" here? [07:53] hi [07:53] mvo: that decoding in client is using Number [07:53] pedronis: aha, right. let me check the client, I know we do it in the daemon everywhere(ish?) [07:54] mvo: ? [07:54] I see only one call in non-test code to UseNumber [07:54] sorry [07:54] pedronis: oh, let me check, sorry, then I must mis-remember [07:55] it's only all config code [07:55] that uses it [07:55] but in client is everything [07:56] pedronis: do you think it would be a good time to change this in the client? [07:56] in which sense? [07:56] pedronis: change the client code to not use numbers so that it won't bite us in the future [07:57] well, we do it for good reasons for config [07:57] stuff [07:57] pedronis: its for the float vs int which we normally won't have, right? [07:57] yes [08:00] 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] mvo: the only problematic place for Number is Attrs in interfaces.go [08:00] atm [08:01] having float64 for everything there is not good either though [08:01] pedronis: indeed [08:01] but I think at least doSync document should mention the fact that it uses Number [08:02] pedronis: I can add this [08:04] and the same in the documentation for Conf [08:06] mvo: ^ [08:07] pedronis: ta, I will push something new shortly [08:07] mvo: also I agree > 0 vs != 0 is a bit strange [08:07] that was zyga comment [08:08] PR snapd#5032 closed: repo: pass and return ConnRef via pointers

[08:12] pedronis: PR updated [08:14] yay, less than 40 PRs [08:14] yay [08:14] mvo: good morning [08:14] Chipaca: good morning [08:15] PR snapd#5164 closed: tests: increase timeouts to make tests reliable on slow boards [08:15] pedronis: pr is updated (and addressed zyga comments as well, sorry for the confusing behavior there) [08:15] thanks [08:16] zyga: thank you, that was a nice catch [08:18] mvo: one more nitpick [08:18] zyga: sure, keep them coming [08:20] mvo: given the complexity you probably want a couple of end to end tests about 1.1 0.0 0 and 1 [08:21] pedronis: yeah, that makes sense [08:22] 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] I mean RedirectClientToTestServer tests [08:23] pedronis: thanks, yes, that is what I understood :) [08:23] pedronis: +1 for this, will do that in a wee bit (doing the 2.32.9 SRU to unblock autopkgtests again) [08:23] pedronis: but once that is done I will add the tests and zyga nitpicks [08:34] mvo: indeed snap interface --attrs (which I didn't know about) is probably broken because of Number [08:35] oh? [08:35] Number? [08:35] there are tests for --attr so whatever it is, should be easy to check [08:35] they don't test the number case [08:35] just strings [08:35] anyway the impl is a bit naive anyway [08:36] but Number isn't helping it [08:36] PR snapd#5168 opened: release: 2.32.9 [08:36] woah [08:36] woah [08:36] 9? [08:36] because of autopkgtests [08:37] mvo mentioned before here [08:37] ah, a test-only release [08:37] uff :) [08:37] zyga: yeah, just tests, no further change [08:38] so the kind of bug I expected in future, is already in the present/past [08:39] 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] pedronis: I can have a look in a wee bit [08:39] not super important I suspect [08:39] less important than progressing with the review sprint [08:39] atm [08:40] the bug has been there since a long while [08:40] zyga: it feels like we should have the opengl interface produce mount entries for vulkan and egl [08:40] mborzecki, yes, can you expand on that idea, I'd like to do that and ditch the nvidia code in snap-confine [08:40] we're now very much equipped to do that [08:45] zyga: why exactly the nvidia setup is done in snap-confine now? or is it just historical? [08:45] just historical [08:45] snap-confine is far older than snap-update-ns and mount profiles [08:46] it dates back to 15.04 and before [08:46] the dawn of time! [08:46] i was afraid of some pivot_root play or whatever but if it's historical then maybe we could dump/trim it now [08:47] 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] yes, that's what i'm looking into now [08:47] mborzecki: my suggestion: how to update existing namespaces (we cannot easily) [08:47] we could pick out the libraries from the host, glob it nicely in go code [08:48] mborzecki: write a function for what you just said above, that computes the mount profile for various use-cases of nvidia [08:48] mborzecki: and add a mode in snap-confine where nvidia is managed by snapd [08:48] mborzecki: (maybe via --managed-nvidia or something) [08:48] if system-key changes, the mount profile will be regenerated too? [08:48] mborzecki: so that we can opt in/out [08:49] mborzecki: yes but existing mount namespaces cannot be updated [08:49] mborzecki: on a system that does snapd update with running apps it would pose a problem [08:49] ok, so PRIME (maybe) or old optimus then [08:49] mborzecki: so what I'm saying, keep the old code for now for transition purpose [08:49] 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:50] mborzecki: so maybe don't try that, just wait for reboot or namespace invalidation [08:50] mborzecki: it's an edge case that is better left as-is [08:51] zyga: the upside is that if you install/enable the driver, you have to reboot/stop all apps anyway [08:57] mvo, it should work.... the kernel between bionic & cosmic should be the same, and i better hope that /dev/kmsg works.... [08:58] 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] PR #5159: testutil: record system call errors / return values [09:02] xnox: ok, I will dig into it then [09:02] xnox: thank you! [09:03] hmm, after pulling in 2.32.8+18.04 on my bionic machine I'm left without a running snapd service [09:03] https://paste.ubuntu.com/p/Vx8SK2xmDW/ <- socket was stopped and not restarted? [09:05] dpkg.log https://paste.ubuntu.com/p/ZcwcH2pbtb/ [09:05] sparkiegeek: weeeh, but no install error or anything? [09:05] mvo: nope [09:05] sparkiegeek: from what version did you upgrade? /var/log/apt/history.log should tell you [09:06] mvo: snapd:amd64 (2.32.5+18.04, 2.32.8+18.04) [09:06] ahh Error: Sub-process /usr/bin/dpkg returned an error code (2) [09:06] 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] sparkiegeek: puhh, at least an error - well, an error still sucks but the alternative would be worse [09:06] mvo: so, I just `dpkg --configure -a` [09:06] that seems to have unblocked it [09:07] 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] sparkiegeek: was the dpkg error related to snapd? or an unrelated package? [09:07] mvo: looks like dpkg lock issues, pasting [09:08] 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] sparkiegeek: thank you [09:08] mvo: https://paste.ubuntu.com/p/GMshWgdrSh/ [09:08] note that this wasn't interactive [09:08] sparkiegeek: this was unattended-upgrades? [09:08] 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:09] sparkiegeek: its not (strictly speaking) my turf but I don't like this :/ [09:09] mvo: yeah, I think it might have been landscape... [09:09] sparkiegeek: so any extra info about the system is appreciated [09:09] sparkiegeek: aha, interessting [09:10] (now snapd is running, using my browser becomes easier!) [09:14] zyga: pedronis addressed your feedback re 4510 [09:16] ack [09:18] pedronis: I added the integration test you asked about in 5157 [09:22] is making a gadget snap the only way to apply udev rules to a device? [09:23] https://github.com/ubuntu/snapcraft-desktop-helpers/issues/117 [09:26] Lin-Buo-Ren: what changed in the before/after? [09:26] eraserpencil: one more way is to add an interface [09:27] zyga: like exposing a serial port or usb port [09:28] eraserpencil: usb port? [09:28] those don't need to be exposed, what is the rule you are after? [09:29] PR snapd#5169 opened: snap: fix `snap interface --attrs` output when numbers are used [09:31] assigning usb ports to usb devices if/when plugged in [09:33] PR snapd#5168 closed: release: 2.32.9 [09:38] zyga: actually, I'm more interested in exposing the serial port, which i read needs a gadget port [09:38] eraserpencil: yes, that's correct [09:38] you need a gadget for that [09:39] mvo: want to link the "boot modes" doc from https://forum.snapcraft.io/t/documentation-outline/3781 ? [09:39] mvo: building the case for a 'devices' heading in there soon :-) [09:39] that was what was about to say, there is no core specific content there yet [09:40] pedronis: “Enabling swap on core devices” is on there [09:40] in the wrong section [09:41] pedronis: how do you figure [09:41] pedronis: it's not "developing", and it's not "publishing" [09:41] I think device makers need a dedicated section [09:41] pedronis: of the sections there are, it's under the right one [09:41] that's neither developing nor publishing [09:42] Chipaca: I don't know [09:42] I agree, but it's not going to happen unless we write things for devices [09:42] thus, my prompting mvo to link to the thing he wrote [09:42] with two device-specific entries, we could think of a section for them [09:43] although "Devicing" is not a word [09:43] :-) [09:44] Chipaca: hm, yes. linking makes sense [09:46] 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:55] 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:57] -- Logs begin at Wed 2018-05-16 08:21:06 UTC, end at Wed 2018-05-16 08:29:15 UTC. -- [09:57] 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] this is the head of the log [09:57] it feels to me like it is too late [09:58] the cursor logic may be inaccurate? [09:59] I think the cursor changes landed quite some time ago? or is it a recent change? [09:59] recent [10:00] ok [10:01] 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:04] 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:21] @pstolowski, ok, and just clarify us, in which part have to that, any example for this plese [10:25] 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:31] 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:32] mvo: thank you for the review on #5159, replied [10:32] zyga: ta [10:32] PR #5159: testutil: record system call errors / return values [10:33] mvo: as for Call and RCall, maybe we should call the function RECall [10:33] as or just Recall [10:33] it would play nice on the Result, Error and Call [10:33] and it is also a word [10:33] recall what happened [10:33] hmm? [10:35] zyga: no strong opinion about this [10:35] zyga: I was mostly curious if its something I should know [10:38] mvo: ack, waveform has found some /interesting/ lock behaviour in unattended-upgrades too === chihchun is now known as chihchun_afk [10:39] newbee: see the advanced examples here https://docs.snapcraft.io/build-snaps/parts [10:39] mvo, I'm probably making a mistake but looking through unattended-upgrades, the Unlocked context manager looks ... unusual [10:39] sparkiegeek: it will unlock the dpkg lock quite often as it runs many dpkg operations (it defaults to minimal upgrade mode nowdays) [10:39] it's called apt_pkg.pkgsystem_unlock on both __enter__ *and* __exit__ [10:39] waveform: oh? let me see [10:39] (and it wraps both calls in bare try..except so a double-unlock will go unnoticed) [10:39] 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:40] PR snapd#5170 opened: interfaces/builtin: add adb-support interface [10:41] waveform: yeah, that looks very broken [10:41] 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] so I don't *think* this would get called by a default config (which might explain why it's not been seen yet?) [10:42] still, it looked rather weird to me! [10:42] waveform: very sure this is a bug [10:42] ok, thanks - glad I'm not missing something! [10:43] waveform: I will propose a fix and followup with foundations about it [10:43] ta [10:43] waveform: thank *you* [10:46] 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:47] ... 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] waveform: when u-u exists the lock is automatically freeed but it holds it for its entire lifetime [10:48] ah, that explains it [10:48] zyga: replied to your comments on 4510 [10:48] zyga: land #5159 ? [10:48] PR #5159: testutil: record system call errors / return values