=== thibautr___ is now known as thibautr__ === tedg_ is now known as tedg === TinoGuest_ is now known as TinoGuest === davidcalle_ is now known as davidcalle === clemensv_ is now known as clemensv === Dmitrii-Sh_ is now known as Dmitrii-Sh === iatrou__ is now known as iatrou_ === mup_ is now known as mup === pstolowski|afk is now known as pstolowski [07:11] mornings [07:12] hey pstolowski [07:43] #5474 needs a 2nd review, would be great to land it [07:43] PR #5474: many: finish sharing a single TaskRunner with all the the managers [07:43] pstolowski: I have a look in a bit [07:43] ty [07:54] mvo can #5535 land, or is there more to it? [07:54] PR #5535: tests: fix tests expecting old email address [08:06] buenos días, gente [08:09] pstolowski: it can land, I fixed this 2h earlier but for some reason my PR was not visible, oh well [08:10] pstolowski: s/not visible/not reviewed/ [08:10] pstolowski: if merged, please squash, we need it for the sru [08:10] mvo: yep, noticed that.. [08:10] Chipaca: hey, good morning [08:10] ouch, i merged a second ago, but not squashed [08:11] sorry about that [08:11] pstolowski: no worries, its just three commits so not a big deal [08:20] hmm [08:21] I've got a question about #5535 [08:21] PR #5535: tests: fix tests expecting old email address [08:21] why the unknown|unset change? [08:21] that one's wrong [08:21] and backwards [08:22] pstolowski: thanks for the review [08:22] Chipaca: unset is the new one right? [08:23] yes [08:23] there should be nothing saying 'unknown' now, ever [08:23] if there is, it's a bug [08:24] Chipaca: did the server side sent it? [08:24] Chipaca: or is this entirely local? [08:24] mvo: server side sends "unset" [08:24] Chipaca: sounds like we need a PR then that removes the unknown [08:24] mvo: for local snaps with no set license snapd sent "unknown" until #5508 [08:25] PR #5508: cmd/snap: print unset license as "unset", instead of "unknown [08:25] mvo: so I'm asking, before just pushing the PR to do it, because it was unset and obviously something broke, I need to understand what broke :-) [08:26] i mean, i doubt cachio made the change just for fun [08:27] when was this? is this related to the reindex or was from before? [08:27] * pedronis is going to spend the morning on reviews [08:27] pedronis: same pr as the email change [08:27] ah [08:28] maybe something is broken in the store and the reindex put unknown in places again? [08:28] nope [08:29] unless this is the fake store? [08:29] the actual store is sending "Other Open Source" [08:29] which wouldn't mach either of those :-) [08:30] mmh [08:30] yes [08:30] this is test-snapd-tools ? [08:30] core, test-snapd-tools, and test-snapd-devmode [08:31] Chipaca: core says unknown here [08:31] pedronis: where and how? [08:32] snap info core [08:32] with beta [08:32] I mean 2.34.1 [08:32] pedronis: #5508 is recent, probably only edge [08:32] PR #5508: cmd/snap: print unset license as "unset", instead of "unknown [08:33] Chipaca: ah, but cachio is doing an SRU, so it needs still the unknown [08:33] merged 3 days ago [08:33] pedronis: on master? [08:33] I'm not quite sure how is running things [08:33] no clue [08:33] yeah [08:33] * Chipaca grumbles some more [08:33] anyhow [08:33] pedronis: it's have-another-coffee o'clock [08:34] me I'm fininish my first tea [08:34] after that i'll be working on snapshotstate conflicts [08:34] wish me luck :-) [08:44] Chipaca: it should be easy [08:45] Chipaca: afaiu just use AddAffectedSnapsByAttr [08:45] with snapshot-setup [08:48] when calling /v2/interfaces?select=connected&plugs=true&slots=true, is it normal that unconnected plugs and slots are returned? [08:48] it only seems to filter out interface types that have no connected plugs or slots [09:08] jamesh: I'm not sure. That code was refactored recently, so we might've fudged it [09:08] zyga: ^ jamesh's question is for you I fear [09:09] jamesh: zyga is further west than normal so I wouldn't expect a response for a few hours [09:10] Chipaca: Montreal? [09:10] yah [09:10] jamesh: OTOH the refactor is probably only on master (so on edge) [09:10] jamesh: are you talking to edge? [09:10] good point. I'm on edge at the moment. I'll check stable [09:12] jamesh: even if we didn't change the behaviour it's possible it's wrong :-) i'd be surprised to get unconnected things when i ask for connected ones [09:12] mvo: I don't understand the localSnaps change in the kernel-track branch, it seems to be done for all snaps [09:14] Chipaca: I want to find out if a particular snap has a connected plug for a particular interface, and didn't feel like sifting through the full list of connections. This interface looked like it should do what I want, but didn't seem to be doing the filtering [09:14] Chipaca: okay. Stable (2.33.1) also shows unconnected plugs [09:15] jamesh: so 'snap interfaces -i theinterface thesnap', but via the api? [09:15] pedronis: hm, let me double check, maybe there is a test missing :( [09:15] mvo: did you forget to check that the snap name is the kernel name? [09:16] pedronis: yes, silly me. plus a test is missing that should have failed, let me check why this is not failing, I thought I had checked for the channel [09:17] Chipaca: that command does client side filtering. I was thinking of doing the equivalent of "snap interface pulseaudio" and then checking checking if the snap in question was listed as a plug [09:17] pstolowski: I tried to answer your doubt [09:18] pedronis: aha, there is a test for two local snaps missing, let me fix that [09:18] that's "interface" rather than "interfaces" [09:19] jamesh: ah, right, interfaces is the old one [09:19] (what you get with select="") [09:20] jamesh: looks like a bug to me [09:21] jamesh: I have both vlc and firefox snaps, neither of which are connected to camera, yet 'snap interface camera' lists them [09:21] jamesh: whereas i'd only expect them to appear under 'snap interface --all camera' [09:21] Chipaca: I'd expect them to show with select=all and not with select=connected [09:21] yeah [09:21] exactly [09:21] so, yeah, this looks like a bug to me [09:22] also the output with --all should probably say connected/disconnected [09:23] The json doesn't currently tell you about the connection state, or what they are connected to [09:23] it'd kind of be nice if one of the output formats clearly had a superset of the data of the other [09:25] pedronis: thanks again, fix pushed, can't wait to write integration tests for this [09:30] jamesh: want to raise that last point in the forum? [09:30] Chipaca: sure. [09:30] jamesh: I know niemeyer had Opinions about this, but I'm not sure the current interface command is that, or if there was going to be a connections command [09:31] popey: is somebody working on a new minecraft snap? [09:32] popey: (because I'm going to be asked for it this weekend) [09:32] @Chipaca looked at it last night, and mentioned to @Wimpress as I am on vacation starting today. he said he'd look at it if he gets time. Looks simple enough to dump the deb into a snap [09:32] we could put it in edge on the minecraft name [09:33] popey: there's a deb now? [09:33] but need to test that it migrates from old minecraft to new properly [09:33] yes [09:33] its a chromium embedded (electron like) app [09:33] saw that in the tarball, but didn't see a deb [09:33] anyway, good to know [09:33] popey: enjoy your holidays and your vacationdays [09:34] thanks. give Wimpress a nudge later when he's online [09:34] :) [09:36] mvo: not urgent, there's a couple of mispellings of "topic" in the roadmap entry for 2.34 in the forum [09:36] pedronis: thank you, will fix in a bit [09:45] hmm, does aynone know if layouts can be used on top of dirs that are imported via a content interface ? [09:47] (i wonder if the ordering allows that) [09:50] mvo: 5533 looks good but I think it could be simplified a bit further [09:53] mvo: let me know if the comment/proposal are unclear [09:55] * Chipaca afk for a while [09:55] Chipaca: should snap pack foo/ create a valid snap? [09:56] popey: snap pack foo/ . should [09:56] it doesnt [09:56] dunno how good we are with the defaults [09:57] https://www.irccloud.com/pastebin/Q4A7E8gz/ [09:57] sigh [09:57] popey: i'll take a look when i get back [09:57] ok :) [09:57] sorry [09:57] no probs [09:57] shall i file a bug? [09:57] this is part of why we want to have a single way to do this [09:57] popey: please [09:57] on snapd? [09:58] yup [09:58] kk [09:58] on it [09:58] https://bugs.launchpad.net/snapd/+bug/1782545 [09:58] Bug #1782545: "snap pack" doesn't make a valid snap [10:01] pedronis: thanks, looking [10:07] mvo: btw I think the current code is probably even buggy (it would store the effective channel, instead of the tracking channel in some cases) [10:08] (which I don't think is what we want) [10:10] pedronis: oh, you mean the pre-existing code? I will check that too [10:11] mvo: yes, because we store info.Channel in the side, but if you ask for some channel that is closed you might get something different [10:11] is not relevant if channel is stable anyway, that's why probably nobody noticed [10:11] is not a serious bug, but it's conceptually off [10:11] pedronis: good catch [10:11] pedronis: I do a fix in a bit [10:13] mvo: basically we need to store in seed what we set in dlOpts , not what we got in the info (which then also means the code in localSnaps is not needed) [10:14] should simplify a bunch of code, some tests might need re-tweaks [10:15] pedronis: I will do a separate PR for this [10:49] Chipaca: here's the forum post: https://forum.snapcraft.io/t/should-v2-interfaces-select-connected-return-unconnected-plugs-slots/6455 [10:50] pedronis: I looked now and it seems we don't need a separate PR, the changes needed look quite small [10:58] Bug #1619258 changed: netplan should allow NICs to be disconnected and not stall the boot [11:40] mvo: +1 with some small comments [11:42] mvo: thanks for the other changes [11:49] pedronis: thank you, looking and tweaking :) [12:04] * Chipaca wanders off in search of lunch [12:08] o/ [12:13] Chipaca: I reviewed the state bits of #5514 [12:13] PR #5514: daemon, overlord/state: warnings pipeline [12:14] pedronis: saw that, thank you [12:14] pedronis: the names of those things were (iirc) taken from the whiteboard, but yeah they're probably not the best [12:14] especially because the lastSeen is from one pov and the lastShown from another [12:15] and they're practically synonymous [12:15] yes, Seen doesn't work for me there [12:16] pedronis: also was thinking we could drop the explicit delete method and just expire them on load [12:17] anyway, really must lunch [12:18] Chipaca: given that we call the method Add* maybe s/seen/added/ [12:18] seems the most explicit [12:19] comment in the PR [12:29] a 2nd review of #5474 would be great [12:29] PR #5474: many: finish sharing a single TaskRunner with all the the managers [12:41] cachio: hey, 2.34.2 is uploaded into trusty,xenial,bionic, we need to do the validation this week for it to make it to 18.04.1 [12:57] mvo, sure [13:40] mvo: +1 for beta core [13:40] cwayne: yay, thank you [13:41] cachio: -^ [13:41] mvo: once we get one of these kernel issues on a gateway figured out once and for all it'll go more quickly in the future :) [13:56] mvo, promoting [14:07] pedronis: thank you for the review, I'm addressing the comments now [14:07] mvo: do you have any news on the racy stop mode tests? is that a logging issue at this stage (after all the other fixes?) [14:14] mvo: I added some comments to #5537, it looks good overall [14:14] PR #5537: snapstate: ensure kernel-track is honored on switch/refresh [14:18] I addressed stuff on https://github.com/snapcore/snapd/pull/5527 and it just needs a 2nd review [14:18] PR #5527: overlord/ifacestate: support implicit slots on snapd [14:29] zyga, would layouts work on top of imported dirs from content interfaces (i suspect there might be ordering issues (if a layout symlink gets created before the interface connects etc)) [14:29] layouts are first [14:30] but we should reject anything that is overlapping already [14:30] if we don't that's a bug [14:30] k, note i didnt try it just asking conceptually [14:30] so overlaps arent allowed anyway ... hmm [14:31] yes [14:31] mvo: can we talk about https://github.com/snapcore/snapd/pull/5518 quickly? [14:31] PR #5518: systemd: fix snapd.apparmor.service.in dependencies [14:32] pedronis: thank you, will work on those [14:32] zyga: stop mode is logging related but its not fully conclusive yet. my file based fix works for me(tm) as does decreasing the sleep [14:32] zyga: aha, right, 5518 [14:33] zyga: yeah, lets kill the requiste= [14:33] thanks! [14:33] mvo: should we merge the general fixes I did earlier [14:33] mvo: and then pursue logging separately [14:33] mvo: or do you want to get to the bottom of the issue entirely [14:34] zyga: merging your fix is great [14:34] zyga: it fixes a lot of problems already [14:34] zyga: and then we can use that to get to the bottom of the issue itself [14:41] we need a 2nd review on https://github.com/snapcore/snapd/pull/5521 [14:41] Chipaca: ^ perhaps [14:41] PR #5521: snap-confine: mount internal tooling even for the core snap on core18 [14:43] zyga: ok [14:43] thank you! [14:53] Chipaca: please have a look at my comment here https://github.com/snapcore/snapd/pull/5531#pullrequestreview-138710326 [14:53] PR #5531: cmd/snap: support `--last=?` to mean "no error on empty" [14:53] zyga: https://forum.snapcraft.io/t/spotify-doesnt-open-everytime-i-reboot/6460 [14:54] popey, didnt you say your vacation starts today ? what are you doig here all day ? [14:54] * popey disappears [14:54] popey, here ... a poster for you ... https://www.kotzendes-einhorn.de/blog/wp-content/uploads/2014/04/smartwatch.jpg [14:55] :) [14:55] I love that image [14:55] popey: looking [14:56] ah, [14:58] hi there [14:58] but after the session [14:58] hey there odc :) [15:01] question: i have a C++ app that requires C++14 and thus, can only be compiled on ubuntu bionic (doesn't compile on xenial). I have managed to create a .snap from bionic. Will snapcraft.io accept my snap since it doesn not compile on xenial? [15:02] it may accept it but it will likely segfault on user computers [15:02] because it will pull in core (ubuntu 16) [15:02] o.O it won't include the libstdc++ from bionic? [15:02] well, depends how you build it ... you would need to override libc and stdc++ an also hack the snapcraft.yaml in a way to get a proper compiler/toolchan [15:03] zyga: responded [15:03] *and also hack [15:03] hm, i may be able to compile some libs as static [15:03] not sure the ibc/stdc++ overriding works [15:03] yeah, that might be ok [15:04] how can i view what files are in my snap? [15:04] i fthey are linked into your binary ... but even then you will execute on top of xenial [15:04] unsquashfs -ls /part/to/snap [15:04] *path [15:04] or look in prime/ [15:04] or if you're using snapcraft, look in prime/ [15:04] which will be whats in the snap [15:04] sorry [15:04] right, if you have the source tree look in prime/ [15:04] * popey shuts up and closes irc [15:04] cheerio :) [15:05] haha [15:05] cool. thx all [15:05] go watch planes :) [15:05] * Chipaca kicks popey off [15:05] some people need help vacationing [15:05] ctrl+q [15:09] apparently, all the libs but libc are included in the snap :) [15:10] gonna test on xenial [15:11] odc: libc is a problem [15:11] odc: but you can force it to be included as well [15:11] (i don't remember how though) [15:12] odc: it's a problem because you'll be getting xenial's libc everywhere, and you built against bionic's, and they have different ABIs [15:12] unless what you managed to do was build on xenial + backported libs, in which case i should shut up [15:13] nope, i build my snap in a docker container [15:13] (with bionic) [15:14] odc: OTOH, you could use base: core18 [15:15] odc: in which case you might find bugs in core18 as it's not yet 'ready' :-) but it should work [15:16] odc: (core18 is bionic-based) [15:16] interesting ;) [15:17] and indeed my snap does not work on xenial [15:19] Chipaca: is there documentation for "base"? I don't know where to put it [15:22] pstolowski: zyga: the issues with 5532 are I think about not checking for Undesired [15:23] there can be an entry in conns that still means the connection is not there [15:23] pedronis: yes i've a fix ready and testing atm [15:23] odc: it goes in the top level (next to 'name:'), but if snapcraft doesn't support it yet you might need to put 'passthrough: base: core18' [15:24] odc: (then once snapcraft supports it it'll let you know to drop it out of passthrough) [15:24] zyga: I just wrote my longest commit message ever, and I'm blaming you [15:24] zyga: (even though most of it was copy-paste of logs :-) ) [15:25] Chipaca: it seems to have worked without passthrough [15:25] odc: yay [15:27] it works! [15:28] well, kindof. The gtk theme is ugly and there is no font/text, but i guess that's because of isolation [15:29] odc: that should work though [15:29] odc: the snap should have access to the system's fonts [15:29] well, assuming the right interfaces [15:29] just use one of the desktop helpers [15:30] >Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory [15:31] right, the desktop helpers help with that [15:31] ok [15:31] but not sure what happens if you try to use them with "base: core18" [15:31] that might badly explode in your face and leave marks ;) [15:33] i'm sure there are gnome snaps using core18, but don't know which ones offhand [15:33] maybe mvo knows [15:33] well, the questio is if the package names used by the desktop wrappers are still the same etc [15:34] *question [15:34] pedronis: mmm, interesting observation, I will check [15:35] Chipaca: *thank you* very much, that really matters [15:35] zyga: pawel said he is on it [15:35] pedronis: perfect, I'm just catching up onw [15:35] *now [15:41] ok, i added these: plugs: [desktop, home, network, thumbnailer-service, x11] [15:41] now my app can load fonts, but i still get the gdk-pixbuf error and ugly theme [15:42] you need to add a desktop helper [15:42] o.O [15:42] * odc looks it up [15:43] https://github.com/snapcrafters/wordpress-desktop/blob/master/snap/snapcraft.yaml#L32 [15:43] here is an example [15:45] thanks! [15:47] (the "after:" bit ... [15:47] = [15:47] ) [15:47] ogra_: what will that do? [15:47] i understand it will build this part first [15:48] nvm, i saw it in the traces [15:49] its a remote part ... it pulls and builds it forst and puts everything into your snap [15:49] *first [15:50] details are at https://wiki.ubuntu.com/snapcraft/parts (scroll down to snapcraft-desktop-helpers) [15:51] the result is still the same, but this may be the cause: [15:51] main.go:192: cannot change mount namespace of snap "ahoviewer" according to change mount (/var/lib/snapd/hostfs/usr/local/share/fonts /usr/local/share/fonts none bind,ro 0 0): cannot create writable mimic over "/usr": cannot create path "/tmp/.snap/usr": cannot mkdir path segment ".snap": permission denied [15:51] uh [15:56] bbl [16:02] zyga: ^ cannot create mimable writer [16:02] or writable mimic or sth [16:04] Mount snap "test-snapd-content-circular2" (2) ([start var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dcircular2-2.mount] failed with exit status 1: Job for var-lib-snapd-snap-test\x2dsnapd\x2dcontent\x2dcircular2-2.mount failed. [16:05] these kind of mount failures seem to be recurring === pstolowski is now known as pstolowski|afk [16:22] odc: hello [16:22] odc: sorry, I was busy, we please talk about this now [16:23] odc: can you tell me about the snap, what features are you using (content interfaces, layouts, etc) [16:26] zyga: bbl [16:27] aha, thanks [16:51] pedronis: I updated 5537 based on your comments, thanks for those! [16:59] aaand i'm back @ zyga [16:59] * odc switches computer [17:02] odc: he's having lunch [17:03] odc: he'll be back in 15' [17:03] Chipaca: which begs the question, why are you not having lunch? [17:03] odc: because I'm having tea [17:04] I'm in London, he's in … somewhere in the east of Canada [17:04] yummy tea yummy [17:04] heh [17:04] montreal, i think [17:05] he's not gonna like me then. I'm a "maudit français" [17:05] odc: hes polish, so most probably dngaf [17:05] lol [17:12] mvo: +1, need a 2nd review [17:19] re [17:19] odc: back, thank you for waiting [17:19] hi zyga [17:20] so, I think you pasted some basic information [17:20] i reproduced the previous error on my desktop [17:20] 1sec [17:20] but because of the risk that I just need to run to another meeting [17:20] can you paste all the details agin please [17:20] I will copy that and look into it after the event, if necessary [17:20] https://usercontent.irccloud-cdn.com/file/T6hxxsx5/snapcraft.yaml [17:21] I will definitely debug it as this part has to be just work and I'm on point for that [17:21] i see :) [17:21] well, the error happens both on ubuntu 16 and 18 [17:22] i had no issue producing the snap [17:22] (i build them inside docker) [17:22]