=== petevg is now known as petevg_afk [03:22] Bug #1684343 opened: For candicate release is appearing on dragonboard the message "ERROR hal_remove_bsskey response failed err" [03:22] PR snapcraft#1266 closed: tests: report coverage only in unit tests [06:18] good morning [06:21] hey [07:09] PR snapd#3201 closed: interfaces: re-add reverted ioctl and quotactl (revert 21bc6b9f) [07:12] hey mvo, how are you doing today? [07:12] PR snapd#3206 closed: [2.24] Add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine [07:12] PR snapd#3210 closed: [2.24] tests: relax network-bind interface regexps [07:12] hey zyga! I'm doing fine, how are you? [07:13] mvo: good, 3rd night in the tent now :) I used a sleeping bag this time, had a full night sleep for the first time (earlier I would wake up as it's not that warm at night yet) :-) [07:13] mvo: doing reviews, then will jump into a problem I didn't solve last evening [07:14] zyga: tent> fun! [07:26] pstolowski: commented on the disconnect PR, have look please [07:26] zyga, sure, thanks [07:31] zyga, and i commented on 3208 [07:32] pstolowski: repliiied [07:33] zyga, very good point about new snapd running old tasks, thanks! [07:33] pstolowski: my suggestion would be a patch that converts such a task to the new configuration [07:33] pstolowski: but that's not without issues itself [07:34] pstolowski: though unlike other patches it would not need to be undone [07:34] pstolowski: as old snapd can handle that too [07:34] let's create a forum topic maybe [07:34] OK === chihchun_afk is now known as chihchun [07:36] actually existing topic is fine for that [07:56] pstolowski: looks like 3070 has a open question from gustavo - is that addressed? if so, I think the PR is good to go [07:56] PR snapd#3207 closed: tests: relax network-bind interface regexps [07:59] mvo, thanks, if you mean the comment re having a test for revert case, than yes, it's addressed, i've just added a comment [08:00] pstolowski: great, thank you. [08:00] pstolowski: it looekd addressed to me but I wanted to double check :) [08:02] PR snapd#3070 closed: overlord: maintain per-revision snapshots of snap configuration [08:06] good morning! [08:07] Chipaca: good morning, how are you feeling? [08:07] * Chipaca is back from the dead [08:07] zyga— no fever today, but something is still up [08:07] as if my vision had lag [08:08] https://forum.snapcraft.io/t/snapcraft-autopkgktest-failure-in-zesty/337 oh god [08:09] can we tell it >= instead of =? [08:10] no, we can't ("E: Unable to locate package hello>") [08:13] do we actually need to specify version number there? [08:13] you could make a dummy package that depended on hello (>= whatever) [08:13] and install that [08:14] sbuild and pbuilder both have helpers for that iirc [08:14] bit of a run around though [08:21] mwhudson: hey! if you didn't saw it yet: https://github.com/snapcore/snapd/pull/3156 [08:21] PR snapd#3156: many: support debian in our CI [08:34] morphis_: nice [08:34] mwhudson: its close to be ready, just three remaining tests I need to debug [08:34] mwhudson: btw. are there any big differences in the debian packaging bits to what we have in the snapd tree? [08:35] morphis_: well the devendoring is the big thing i guess? [08:35] otherwise, no not really i think [08:35] * mwhudson is not here btw [08:35] mwhudson: you mean you have individual deb packages in debian for each golang package snapd uses [08:36] mwhudson: ah :-) [08:36] morphis_: 3177 has a unit test failure it seems (just in case you have not seen it already) [08:40] Chipaca, is https://bugs.launchpad.net/snapd/+bug/1660970 going to be covered by your tab-completion work? [08:40] Bug #1660970: snap info could autocomplete against installed snaps [08:43] mvo: yeah, thanks, already looking into that one [08:43] pstolowski— umm [08:43] pstolowski— so, no [08:44] mvo: looks like something broke after my last rebase on master [08:44] but let me read the bug; it's probably invalid, at least as stated in the title [08:46] pstolowski— i can fix this easily :-) [08:47] Chipaca, :) cool [08:47] Hi! It's Renat from Screenly=) I have another question to you=) [08:48] hey renat [08:48] We configured auto-connection for our snap almost successfully, but dbus plugs and slots don't connect automatically to each other=( [08:49] Let me post here our snap config [08:49] to each other where? in one snap? [08:50] zyga, yes [08:50] https://paste.ubuntu.com/24419051/ [08:52] renat: not sure why yet BUT, if you use core from the edge channel then each auto-connect logs why it doens't do something [08:52] renat: so you could install your snap and just read the message [08:53] I will try, thanks! === chihchun is now known as chihchun_afk [09:03] zyga— is there any reason why 'snap interfaces' isn't completing? (i mean one level up from "because the code isn't written") [09:05] Chipaca: no [09:05] zyga— same question but about disconnect, now :-) [09:05] Chipaca: also completion for connect is not as smart as I wish it was [09:05] Chipaca: same answer :) [09:05] zyga— oh? tell me more [09:05] I think connect was a proof of concept [09:05] and that was just merged but I didn't iterate [09:05] ah [09:05] if you look at connect, it's really dumb [09:05] what it should really do [09:05] is complete only those that you can connect in practice [09:06] * zyga is stuck at a harder part of update-ns [09:07] zyga— how can you know what you can connect? [09:07] I think I will break for a moment and do something else, explore the easier parts again and write spread tests [09:07] Chipaca: well, the interfaces must match [09:07] zyga— oh you mean for the second argument? [09:07] Chipaca: but also you need to see that something can have more than one connection at a time [09:07] Chipaca: and when you factor in hooks it's even more interesting [09:07] right now the second arg doesn't complete at all [09:07] Chipaca: yes [09:08] Chipaca: anyway, look at it and think, I'm sure you will come up with a more complete picture than my rusty memory [09:08] grmbl [09:10] zyga— I'll start with the simpler stuff :-) [09:17] any ideas why suddenly I have `Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path` [09:17] well, with apt or source, snap seems to work fine :) [09:18] Bug #1684525 opened: panic: assignment to entry in nil map [09:29] zyga— ^ that backtrace talks about content interface [09:29] Chipaca: I fixed that yesterday [09:29] :-) [09:33] I need to log into a webex meeting, I know it can be a pain to set up on ubuntu 16.04 64 bit. Would it be possible to create a snap with firefox and the correct java packages so that everything will just work? It should also connect to webcam and sound. What would the difficulty level be? [09:33] wligtenberg: after a firefox snap exists, not high [09:33] wligtenberg: before, I'd wait [09:35] zyga: does a firefox snap exist? I am not fully aware of all snaps :) [09:35] wligtenberg: I don't think a stable one exists yet [09:36] zyga: ok, thanks. Then I will have to resort to the windows VM I guess. It would be a very cool use case I think. No more try all these things and you might get it to work, but just use this snap. :) [09:36] iirc there is a chrome one though (but also only in the edge channel) [09:37] I agree, I think it's coming though [09:37] Although it would be even better if Cisco would just play nice with Linux... [09:37] snap install chrome-test --edge [09:37] ogra_: As far as I know, chrome is more difficult since it has stopped java support, which is required. [09:38] thats the proprietary chrome though ... it might have more than chromium (it takes 5min to try out if you want to check ,... snaps are easily installed/uninstalled without any harm for your system) [09:39] ogra_: good point, will just see if it works. :) [09:39] ;) [09:47] and that's 5 minutes on *ogra_'s* connection :-) [09:47] haha, yeah [09:47] he's got a very speedy dialup [09:47] :-) [09:49] I-S-D-N === chihchun_afk is now known as chihchun [09:55] of them get you 1.2Mbit!) [09:55] bah [09:55] (10 of them get you 1.2Mbit!) [09:59] wligtenberg: curious to know if you can get this to work. Was hoping to join a webex next week [10:08] hi [10:12] PR snapd#3213 opened: snap: require snap name for 'revert' [10:49] ogra_ mcpahil: using the chrome snap does not work. It downloads a java webstart thingy but cannot execute that. [10:50] well, was worth a try at least [10:51] ogra_ I agree, it is the beauty of snaps :) [10:52] niemeyer: if you could add tags for sergio and elopio to the forum, that would be great! this way we can use @upcoming @sergio to assign things to them :) [10:55] refresh-delta-from-core failed in my branch https://travis-ci.org/snapcore/snapd/builds/223897482 [10:56] pstolowski: when did that fail? about ~3h ago there was a misconfiguration in u1 [10:56] pstolowski: if its a recent failure we need to talk to them again [10:56] mvo, 4 minutes ago if travis is not laying [10:57] pstolowski: hm, then I think we need to talk to #u1 [10:58] mvo, who is our person to talk to? [10:59] mvo, ah, ok, i see you raised that already [10:59] pstolowski: yes [10:59] thanks! [11:02] pstolowski: FYI I saw that many times this week [11:04] PR snapcraft#1267 closed: meta: override the version with version-script [11:15] mvo, hmm ... i think we need to either finally land the systemd changes in xenial or at least update our package https://forum.snapcraft.io/t/cant-install-libudev-dev-in-classic/333/3 [11:31] mcpahil: This docker approach seems to work https://hub.docker.com/r/dnk8n/docker-webex/ , at least I can join the webex test. After tonight I will know more. I will try this, and have my windows VM as backup. [11:32] PR snapd#3214 opened: cmd/snap: iterate interface tab completion [11:32] So I was definitely not the first person with the idea :) [11:44] PR core-build#6 opened: add the initramfs-tools-ubuntu-core package source [11:48] ogra_: yeah, just noticed this too. very annoying, its the result of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1659195 [11:48] Bug #1659195: resolver regression on ubuntu-core from #1636912 [11:48] yeah [12:00] mvo, nice idea with using iptables for 3197! looks very promising [12:19] PR snapcraft#1268 opened: Added link to forums in the Get in touch section [12:24] Hi, again=) [12:25] zyga, seems, it doesn't connect because of multiple candidates for connection. [12:25] Apr 20 09:02:10 localhost.localdomain /usr/lib/snapd/snapd[1181]: task.go:303: DEBUG: 2017-04-20T09:02:10Z INFO cannot auto connect udisks2:service (slot auto-connection), candidates found: "screenly-client:udisks2, udisks2:client" [12:25] [12:25] For example. [12:25] How do I specify slots for auto-connection? [12:26] In this particular situation - I want both, but there is another message: [12:26] auto connect screenly-client:command-dbus-client (plug auto-connection), candidates found: "screenly-client:command-dbus-server, screenly-client:ping-dbus-server, screenly-client:playlist-dbus-server" [12:26] [12:26] And I only want to connect to one of them. [12:30] renat``: I started discussing this topic here https://forum.snapcraft.io/t/what-should-the-auto-connect-logic-be-like/312 [12:31] Thanks! Joining [12:31] zyga: joining us? [12:32] oh [12:32] sorry sure [12:32] no notification :/ [12:53] mvo: 2.24 is going out today or next thursday? [12:53] morphis_: the tenative plan is today, we will talk about it in todays standup, feel free to join, its in 7min [12:54] morphis_: tenative because there is a lot of stuff tagged as 2.25 which is not in yet [12:55] mvo: ok, I have another meeting in 5min but that is already all I wanted, thanks :-) [12:57] morphis_: we need to consult JamieBennett on this too, the stable release is currently done by him. if 2.24 goes out today or not is something we also discussed via mail with tony but no final decision yet afaik [12:58] ok [12:58] mvo: I was more interested of the perspective when we can push the packages for fedora/suse/yocto out [13:00] morphis_: aha, I see. for those 2.24 is fine to push out (it is already released upstream). if you mean 2.25 (which is the next release which is currently wrapped up), then today is the tentative plan but things might get delayed because of $stuff [13:01] mvo: I was thinking more of we should always align to the stable core snap with that release as their may be dependencies [13:02] zyga— standup [13:03] ah, sorry [13:38] PR snapcraft#1269 opened: tests: fix package version pinning tests [13:40] mvo: let me know if we are releasing 2.24 today, so that I can push the button to release it for all Fedora releases [13:45] mvo: fwiw systemd-run takes a --slice= and I see a user-USER.slice but then there's also a session-xx.scope under the slice and I don't see systemd-run taking a scope [13:58] * zyga -> lunch [14:04] mvo: Done [14:04] 527 members on the devices mailing list.. there we go again [14:17] PR snapd#3213 closed: snap: require snap name for 'revert' [14:23] niemeyer, FYI https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L28 is what we allow today ... when we change the whole thing i think snap-confine should actually look up which mimetypes are supported on the desktop side and put some file on top of that mimeapps.list file relfecting reality on the desktop side ... (would be a quesrtion to zyga how hard that would be to implement) [14:24] ogra_— note there are two sides to the allowing, and i think niemeyer was pointing to the other side [14:24] ah [14:24] *that* was the misunderstanding then :) [14:25] ogra_— either that, or there are two implementations of the same thing written in completely different languages [14:25] ogra_: Yes, what is inside core or the snap is irrelevant.. [14:25] niemeyer, not for the snaps [14:25] niemeyer, if my snap wants a file:// url this will not work today [14:26] ogra_: In terms of security, the snap can perform that dbus-send call with whatsoever it wants [14:26] so the info that the desktop knows how to handle file:// is a valuable info we should forward to the inside of core (which is what my question above is about, regarding snap-confine) [14:27] sure but it will be a no-op for anything we dont define in that file [14:27] (or even cause an error on the snap dside, havent tested this) [14:27] !?!? [14:27] ogra_: This is completely irrelevant.. dbus won't consult that file to perform the call, nor will the daemon on the other side [14:28] * ogra_ has the feeling ou dont understand me ... [14:28] ogra_— gustavo is talking about security [14:28] ogra_— you're talking about usability [14:28] both are needed [14:28] right [14:29] ogra_: I have the feeling we're talking across purposes indeed.. you raised security concerns in our call today. That's what I'm talking about. [14:29] i talk about what the snap sees and what the user ends up with in the current situation [14:29] if we re-do the world we need to re-do this bit too ... thats all i'm saying [14:29] (and i propose that snap-confine handles it) [14:30] niemeyer, that were no security concerns but rather "xdg-open will open anything, not just a browser ... completely unrelated to security [14:31] ogra_: If a snap could open anything with xdg-open, that'd be a major security concern.. that's exactly the topic above. [14:32] ogra_: It can't, and it's not because of those files you referred to [14:32] well, thats an xdg-open thing ... [14:32] ogra_: But because the daemon will anything not accepted [14:32] * the daemon will reject [14:32] ogra_: We don't use xdg-open *at all* today.. it's simply an executable with the same name [14:32] right, currently the mimeapps.list file makes us reject even before it goes anywhere [14:33] ogra_: Once more (and last, I think), mimeapps is irrelevant.. the dbus call that is inside that xdg-open call can be carried with any URL.. it's the daemon that will prevent arbitrary URLs from being opened [14:33] what i'm saying from a UX/snap perspective is that we should have that bit dynamically based on the capabilities the actual desktop exposes [14:34] ogra_: You're flipping back and forth between UX and statements such as "xdg-open can open anything".. [14:34] ogra_: Our xdg-open can't... [14:34] and it shouldn't [14:35] it should allow the exact same any other desktop app is capable to when using a MRL/URL [14:35] which is defined on the desktop side [14:35] but not carried through as info to the core snap [14:35] ogra_: Nope, our xdg-open needs to be security aware... [14:36] ogra_: and btw, mvo is right.. polkit is unrelated.. the daemon would need to integrate with polkit for it to work, and it doesn't today [14:36] well, then we shoudl make that work ... but since you want to drop that anyway i wont argue about security anymore ;) [14:37] ogra_: Don't worry about that feature. We'll sort it out. [14:37] niemeyer, ogra_: I think there are two things we're mixing here, one is carrying what we have right now (http://) forward also to other distributions and the other thing is support for other URI's like tel:// or similar [14:37] ogra_: We're not dropping anything.. we're evaluating a different way of doing it that might help cross-distribution support. It's about being open minded enough to accept exploring ideas and perhaps falling back if it turns out to be a dead end. [14:37] once we have sorted the first one we can use the same implementation to add more things if needed [14:38] morphis, right, that was my point ... the core snap should have the info what the desktop side supports before even offering it to the snap [14:38] morphis: Right [14:38] ogra_: what do you mean by that? what kind of info should the core snap have? [14:38] morphis, mime types [14:39] right, but that is a different story we can solve later on [14:39] morphis, https://github.com/snapcore/core/blob/master/live-build/hooks/500-create-xdg-wrapper.binary#L23 defines the supported mime types a snap sees [14:39] we first need a way to talk with the classic desktop at all [14:39] ogra_: You had several points, actually, and most of your posts on that thread don't contribute to the conversation but rather just create controversy.. and in some cases are just plain wrong, such as the polkit statements. Please try to collaborate towards a solution. [14:39] morphis, and since i try to drop any arguing about security, thats another bit i would like to see solved which is why i brought it up here [14:39] ogra_: For contrast, see morphis's last post on the thread. This is what good feedback looks like. [14:40] ogra_: shouldn't that be just x-scheme-handler/http;x-scheme-handler/https ? [14:40] ogra_: as that are the only two mime types snapd-xdg-open currently allows [14:41] morphis, PRs accepted :) i thought we hand through mailto as well at least [14:41] ogra_: we do? [14:41] (that script isnt mine, i think tvoss wrote it initially) [14:41] ah right [14:41] https://github.com/snapcore/snapd-xdg-open/blob/master/src/snapd-xdg-open.c#L67 [14:42] both should be in sync always and I agree there could be a better way to keep both in sync [14:42] rigth [14:42] ala letting snapd ship both xdg-open and xdg-open.desktop so we can control both [14:42] in the same place [14:42] hey all, any idea which plug we'd need to connect to get an Electron app to work confined? http://pastebin.ubuntu.com/24420540/ is the denial I'm getting [14:43] Saviq, i thought only browser-support [14:43] Saviq: there is an attribute for the browser-support interface you may have to set too [14:43] https://github.com/snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L250 [14:43] allow-sandbox: true [14:44] morphis, aha, any idea if that can be done with auto connection? [14:44] Saviq: you need to ask at the store level for a proper snap-declaration assertion for this [14:44] Saviq, all my electron snaps did auto-connect over here ... [14:45] so that shoudl definitely work fine [14:45] Saviq: but could be that you can set some switches for electron too to disable sandboxing for chrome [14:45] snap install snapcraft-forum ... or rocketchat-desktop ... [14:45] niemeyer: so how do we take this further? do you want some more time to think about this or should I get a meeting up to discuss this with all involved people? [14:45] ogra_, you using electron-builder? [14:46] Saviq, i think ryan uses it for the snapcraft-forum one ... not sure about the rocketchat one [14:46] (sadly ryan didnt publish his snapcraft.yaml) [14:46] might be because it's autogenerated by electron-builder ;) [14:46] morphis: My last hope is being able to properly ask systemd itself to fire the process inside the user session.. mvo is not super optimistic, but said he'd have a quick look into it. If that turns out difficult or awkward, then we'll need to go back to having a daemon inside the user session. [14:46] ah [14:47] niemeyer: the problem with that is that systemd doesn't control the user session on all distros [14:47] niemeyer, you dont need any daemon (and we never had one) [14:47] niemeyer: on 14.04 and 16.04 it doesn, on 16.10 you could use systemd-run --user to do that [14:47] niemeyer, there is just a dbus listener service ... that doesnt mean anything is running [14:47] niemeyer: so it is possible but not really portable [14:47] ogra_: I'm sure morphis understands what I'm talking about [14:48] morphis: I see.. hmmm [14:48] niemeyer: I can give `systemd-run --user`a try later on on 16.10 if that would solve it but that would be a super long term solution [14:49] morphis: Isn't that a short cut for a more complex set of options that might be used in 14.04.. I note it supports --slice [14:49] niemeyer: given that we need to support 14.04 / 16.04 till 2020 [14:49] niemeyer: --slice isn't enough as it doesn't affect the process hiearchy [14:50] I used that in my example I gave on the forum post [14:50] morphis: --user is a way of selecting which service manager it's talking to, right? [14:50] right [14:51] morphis: Can't we explicitly select that service manager some other way? [14:51] morphis: Manipulating environment or whatever [14:51] niemeyer: we can hack and get the DBUS_SESSION_ADDR from a process inside the session and then talk to it [14:51] morphis: How does it find out the proper service manager nowadays? [14:51] morphis: Sounds promising [14:51] however that doesn't solve the problem that we have to support upstart and systemd [14:52] niemeyer: its defined somewhere within the lightdm configuration if I am not wrong [14:52] morphis: snapd doesn't work with upstart today, I think [14:52] niemeyer: right [14:52] morphis: Ah, wait, I get what you mean [14:52] Need to step out for a couple of minutes.. brb [14:52] niemeyer: we basically need to support for initctl --user and systemctl --user and for the upstart variant we need to craft our own .conf file and ship it as part of the snapd deb package [14:53] niemeyer: I think that really adds only more complexity to the whole situation than we want [14:55] Saviq: briwser-support should be all you need. don't specify 'allow-sandbox: true' since electron apps don't need it [14:55] morphis, well, things like openbox dont even use upstart or systemd as session managers (while the DM cares for logind and dbus to always run for any desktop) [14:56] ogra_: right, that is what I meant with my last comment more or less, we have too many case to consider if we go this route which takes aways the simplicity we want to achive [14:56] Saviq: you might have to set an env var or something to disable the sandbox, but I don't think that is necessary (someone could correct me) [14:56] exactly [14:56] jdstrand, I didn't, but still getting denials like http://pastebin.ubuntu.com/24420628/ - doesn't work unless --devmode [14:57] jdstrand: the electron apps don't use chromium sanboxing? [14:57] i dont think any webapps can [14:57] only thing about sandbox I can find is https://electron.atom.io/docs/api/sandbox-option/ but that doesn't seem to be that [14:57] iirc you have to actually invoke the binary with --no-snadbox [14:58] yeah [14:58] morphis: Ack, does feel like a can of worms [14:58] /snap/snapcraft-forum/4/snapcraft-forum --type=renderer --no-sandbox --primordial-pipe-token=31B373498D [14:58] niemeyer: yes :-) [14:58] Saviq, ^^^ [14:58] ogra_: ah! [14:59] --no-sandbox is the key here [14:59] yeah [14:59] ogra_: is electron using that by default? [14:59] ogra_, ack, thanks! [14:59] morphis, i dont know ... i would expect electron-builder to actually default to it [14:59] when building a snap :) [14:59] morphis: they can use seccomp but not userns. electron apps don't need it, they are snappy sandboxed [14:59] jdstrand: right [15:00] allow-sandbox: true allows use of userns but grants a ton of privilege, so it is only used for official browsers [15:01] * jdstrand takes a note to update the review tools to mention --no-sandbox with electron apps [15:01] * jdstrand also updates the wiki [15:04] sergiusens, github sends me mondrian artwork about snaopcraft by mail suddenly ! [15:04] (the color selection is a bit boring though ... only red, green and grey) [15:16] ogra_, hey did we jsut release a new core snap ? [15:17] i seem to have a lost loop device showing up which looks to be the 1337 version of the core snap [15:33] ogra_, hrmf, should I see something when running snapcraft-forum? I'm seeing "mmap() failed: Permission denied" and the same DENIAL... nothing else ¿? [15:35] hmm hmm, works with --devmode, /me starts thinking this is something special about his host... [15:35] like... zesty [15:50] Bug #1684893 opened: "fonts", "themes" and "icons" interfaces for desktop apps [15:50] Bug #1684896 opened: sha3-384 mismatch downloading lxd === chihchun is now known as chihchun_afk [16:02] ogra_: err, what? [16:03] apw, not me, either JamieBennett or mvo do the releases nowadays [16:03] Saviq: kernel >=4.10 needs snapd 2.24 [16:03] Saviq, yeah there was a forum thread about it [16:03] * sergiusens wonders why people still discuss things here :-P [16:05] Bug #1684896 changed: sha3-384 mismatch downloading lxd [16:06] * Saviq upgrades snapd [16:10] mvo: are you pushing to zesty as the latest distro series possible and are you finding hassle in trying to do that? [16:12] sergiusens: I'm pushing to zesty via the normal SRUs, I find it the same hassle as the other SRUs. or is that not the question? [16:12] mvo: great, that is what I wanted to hear; was wondering if we were asked to wait for z+1 and anything like that [16:13] ogra_, hey, I am starting some test automation for console conf, any advice about how to start that? [16:13] cachio, you want to read up about system-user assertions ... [16:14] not sure if we have anything for the networking side though ... [16:14] ogra_, ok, nice [16:15] ogra_, do you know where is the code stored for console conf? [16:16] cachio, it is the source package of "subiquity" ... not sure where the actual code lives, i would suspect on launchpad ... mwhudson is your man for details, he maintains it [16:17] PR snapcraft#1269 closed: tests: fix package version pinning tests [16:17] ogra_, ok I'll look up tx [16:17] i guess you can somehow find it under the subiquity project on LP [16:23] ogra_, that's on GH now I think: https://github.com/CanonicalLtd/subiquity [16:23]