[00:30] snappy-m-o autopkgtest 1630 ubuntu:xenial:integration [00:30] Computer says nooo. See logs for details: [00:30] Command '['/tmp/tmp5u8uatg8/retry_autopkgtest.sh', '1630', 'ubuntu:xenial:integration']' returned non-zero exit status 1 [00:30] snappy-m-o autopkgtest 1630 xenial:amd64:integration [00:30] elopio1: I've just triggered your test. === CodeMouse92 is now known as CodeMouse92__ === JoshStrobl is now known as JoshStrobl|zzz [07:06] good morning === JanC is now known as Guest77018 === JanC_ is now known as JanC [07:24] PR snapd#4060 opened: interfaces: clean system apparmor cache on core device [07:25] Chipaca: hey, good morning. how are you? a quick question, currently if you ddo "snap install foo; snap refresh --edge foo; snap revert foo" afterwards you have foo from stable but you still track edge. I was wondering if that is something that users expect, i.e. if we violate the principle of least surprise here [07:28] mvo: I don't know. Maybe? [07:35] mvo: but mostly, no [07:36] mvo: "snap refresh --channel foo bar" is two operations: "snap switch --channel foo bar && snap refresh bar" [07:36] mvo: snap revert just blacklists current and goes back to the previous revision, it does nothing around switch [07:38] mvo: if you're on stable and "snap refresh --beta bar" and beta has the same revision as stable, you're saying a user would expect snap revert to .... what? [07:39] mvo: mostly, if their mental model is wrong, we need to see why and address that; i think revert's behaviour is relatively well defined [07:39] (relatively being about flags that should be per revision but aren't) [07:45] Chipaca: thanks, thats fine, was mostly wondering [07:45] wrt how to fix that, we could make revert comment [07:46] not sure we currently have enough info to do so, but we could [07:47] something like “reverted ‘foo’ to rev 232 (in channel stable), but still tracking beta” [07:47] not sure that wording in particular helps, but something like that? [07:47] Chipaca: aha, nice, I think that that would be a nice improvement [07:50] I suddenly have polkit-enabled snapd and it's magic [07:50] * Chipaca hugs jamesh [07:52] Chipaca: there's still more work to do, but the parts landed in 2.28 are probably most noticeable [07:53] mvo: we _do_ have the info to output that message [07:54] jamesh: is there / should there be a way for it to cache my password though? [07:54] ah, it is [07:54] just per op [07:54] ok [07:54] Chipaca: we show we reverted to what version but we don't show any channel info afaict [07:55] ah no it isn't [07:55] hm [07:55] the flow for login is weird [07:55] it asks for the passwords in the reverse order than before [07:55] mvo: correct [07:55] mvo: but we do store the channel from which we got each revision [07:55] Chipaca: the policy is controlled by /usr/share/polkit-1/actions/io.snapcraft.snapd.policy plus and pkla files that modify the policy [07:56] Chipaca: the policy should be auth_admin_keep for active users, so I'm not sure why that isn't happening [07:57] jamesh: “Operator of unix-session:c4 successfully authenticated as unix-user:john to gain TEMPORARY authorization for action io.snapcraft.snapd.login for unix-process:31007:75416645 [snap login jlenton@gmail.com] (owned by unix-user:john)” says the log [07:59] Chipaca: the intent of the policy is to let an active user (i.e. logged in locally and without the screen locked) retain authorization, and require others to enter password every time [07:59] I'm not sure why that isn't working [07:59] jamesh: is that just not working for me, or do you also see it? [08:00] Chipaca: it seems to ask every time for me too. [08:00] something to investigate, sure. [08:00] ok [08:30] PR snapd#4061 opened: daemon, store: forward SSO invalid credentials errors as 401 Unauthorized responses === morphis_ is now known as morphis [09:07] * kalikiana coffee break [09:26] sergiusens: can you elaborate on your comment that it can still be a stretch goal? I don't see how we can do this without 2/3 bilingual parser code, and making all of snapcraft 2/3 bilingual sounds like considerably more work than splitting out the parser bits ... [09:27] (I don't want to dictate exactly how you do it, just making our reqs clear) [09:36] Bug #1725208 opened: missing interface to exec cc === chihchun_afk is now known as chihchun === LarreaMikel1 is now known as LarreaMikel [10:06] PR snapd#4062 opened: cmd/snap: warn when a snap is not from the tracking channel [10:06] mvo: ^ [10:11] mvo: sorry, for the delay I was looking for the patch I had started years ago to do the profile hashing for cache consistency, it wasn't were I thought it was so it took me a while to find it [10:11] It looks like its 80-90% done but doesn't apply cleanly against the current tree [10:12] Chipaca: nice! [10:13] jjohansen: can I help in some way? [10:13] * zyga-ubuntu -> afk, need a coffee [10:13] jjohansen: thanks for getting back to me :) [10:13] I'll refresh it, and poke at it a little more, at a minimum I'll kick it over to you, but I might play with it this weekend [10:14] zyga-ubuntu: for when you are back, is it just me or are the gnome-shell extension not really working? I tried to add a clock with times from different timezones and nothing works and its all dubious :/ [10:14] jjohansen: great, thanks! [10:15] mvo: so basically, yeah fast hashes are good enough, just hashing the timestamp would be a little faster, and might be sufficient [10:16] jjohansen: great! there is no real rush, so I'm happy to wait until after the weekend. but I would really like to get this upstream fixed to avoid that we run into this again in 1-2y when we change something structual again :) [10:16] jjohansen: and I'm happy to help, just to be clear. [10:16] I like help :) [10:18] mvo: could be just lost in transition, I switched to my phone for stuff like that [10:20] zyga-ubuntu: aha, ok. yeah, the whole extensions story feels very weak, none of the ones I tried worked [10:20] mvo: I tried one that did work just now but it was ugly [10:20] zyga-ubuntu: and its super obscure how to add/manage them, apparently via the browser and a local service [10:20] zyga-ubuntu: which one was it? [10:21] https://extensions.gnome.org/extension/605/multiclock/ this one [10:21] but now that I try again I get an error [10:22] zyga-ubuntu: aha, this works indeed [10:24] zyga-ubuntu: anyway, not important [10:25] zyga-ubuntu: just annoying, I really liked my unity clock that told me what time .br .us etc have [10:25] mvo: yeah, I was using it too [10:25] mvo: as I said I switched to my phone for that, more consistency in features and more longevity [10:26] * mvo nods [10:26] * mvo nods sadly [10:29] "oh boo hoo i cut myself on the bleeding edge with the big warning and the flashing lights" [10:29] * Chipaca grins evily [10:30] Chipaca: and the sign said "fewer features, come right in" [10:32] zyga-ubuntu: did the spinning blades around the entrance not give you a hint? [10:38] Chipaca: the conveyor belt was fused in the "fast forward" mode so like everyone else, I flew right in [10:40] zyga-ubuntu, you get that wrong, the "fewer features" thing is a new feature ;) [10:42] ubunteros have been complaining about losing features since 6.06 at least [10:42] * Chipaca included [10:43] http://images.uncyc.org/commons/4/4f/Gnomehint.png [10:44] * zyga-ubuntu is sorry about this and gets back to work [10:45] zyga-ubuntu: sounds about right === morphis__ is now known as morphis [11:29] mvo: niemeyer suggested I work with sergio on centralied package installation, do you know where that lives? [11:31] zyga-ubuntu: I get lunch now, but we can talk about this afterwards. its in prepare.sh I would assume [11:32] mvo: thank you, enjoy your lunch :) [11:35] cachio: hey :) [11:35] cachio: I just asked about something :) [11:35] 13:29 < zyga-ubuntu> mvo: niemeyer suggested I work with sergio on centralied package installation, do you know where that lives? [11:35] zyga-ubuntu, hey [11:35] zyga-ubuntu, yes, on minute [11:36] * ogra_ notes that #3958 starts to have more traffic than most mailing lists he is subscribed to :P [11:36] PR #3958: many: add support for /home on NFS [11:36] zyga-ubuntu, https://github.com/snapcore/spread-images/pull/9 [11:36] PR spread-images#9: Install dependencies on the images [11:37] cachio: so this will take over the regular installation logic? [11:37] do we have the 'debug build' feature enabled in our travis? [11:37] cachio: can you please add nfs-kernel-server there [11:37] Chipaca: what does that feature do, out of curiosity? [11:38] zyga-ubuntu: lets us ssh into it [11:38] https://docs.travis-ci.com/user/running-build-in-debug-mode/ [11:38] zyga-ubuntu, sure [11:38] cachio: thank you :-) [11:38] ohhh [11:38] shiny [11:45] zyga-ubuntu, we are not currently installing nfs-kernel-server [11:47] should I install it just in ubuntu? [11:59] cachio: yes, that will be fine, thank you [11:59] ogra_: indeed, that PR has exactly 100 comments now :) [12:00] so crazy [12:00] ogra_: review it, you will get 101th comment [12:29] zyga-ubuntu, the test on linode failed, I am rexecuting [12:29] once it passes I'll push the change [12:39] cachio: thank you [12:56] zyga-ubuntu, change added [13:01] * kalikiana break === chihchun is now known as chihchun_afk [13:21] good morning! [13:22] cjwatson let me rephrase privately [13:22] hey sergiusens [13:49] zyga-ubuntu how is it going? [13:49] * sergiusens is procrastinating on presentations he needs to get done [13:50] sergiusens: working on layous and new mount features [13:50] sergiusens: sleepy morning, dind't sleep well but now it's good (feels like 10AM now :) [13:51] zyga-ubuntu and yet you are almost EOD :-P [13:51] no no, I'll stay now [13:51] pstolowski: I ran into a issue sometimes, can you have a look at this and tell me if it rings any bells [13:51] http://pastebin.ubuntu.com/25779014/ [13:51] I'll debug, just want to see if you've seen it [13:52] zyga-ubuntu, wow, i've never seen this kind of issue [13:54] pstolowski: thanks, maybe it's an impact of my work :/ [13:57] hah [13:58] qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# cat /var/lib/snapd/mount/snap.basic-iface-hooks-consumer.fstab [13:58] /snap/basic-iface-hooks-producer/x1/etc /snap/basic-iface-hooks-consumer/x1/initialtarget none bind,ro 0 0 [13:59] Issue snapcraft#1437 closed: cross-compile i386 kernel [13:59] PR snapcraft#1613 closed: cross compilation: enable cross compilation of i386 kernel on x86-64 … [13:59] qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# ls -ld /snap/basic-iface-hooks-producer/x1/etc [13:59] ls: cannot access '/snap/basic-iface-hooks-producer/x1/etc': No such file or directory [13:59] qemu:ubuntu-16.04-64 .../tests/main/interfaces-hooks# ls -ld /snap/basic-iface-hooks-consumer/x1/initialtarget [13:59] ls: cannot access '/snap/basic-iface-hooks-consumer/x1/initialtarget': No such file or directory [13:59] pstolowski: so now those get created [14:00] pstolowski: did you mean for basic-iface-hooks-producer/ to have an $SNAP/etc directory? [14:01] zyga-ubuntu, let me check, i need to refresh my memory [14:01] pstolowski: it's specified in snap.yaml but not in the tree [14:01] pstolowski: maybe it needed a fake file to keep the directory around? [14:05] zyga-ubuntu, ok. the test doesn't are about what's in the filesystem. it just cares about reading the attributes of interface [14:06] pstolowski: ok, I'll probably tweak the test to contain more realistic content interface use [14:06] zyga-ubuntu, can be any other interface if you can find one that has attributes and can be used instead in the test, although afair i had some issues with that and found out that content interface could be "abused" for this test [14:08] pstolowski: well, you could use the network interface [14:08] pstolowski: and then add any set of attributes inside [14:09] (or any other simple interface) [14:09] ah wait, you need the pair [14:09] hmm === JoshStrobl|zzz is now known as JoshStrobl [14:30] sergiusens: kyrofa kalikiana here is my task breakdown: http://pad.ubuntu.com/snapcraft-18-04-elopio [14:35] * zyga-ubuntu -> lunch [14:39] PR snapd#4063 opened: tests: add new kernel refresh/revert test for spread-cron [14:43] PR snapd#4058 closed: interfaces: reduce duplicated code in interface tests mocks [14:59] mvo: hey, can you look at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20171020_131659_7c6aa@/log.gz [14:59] mvo: one test failed there [15:00] zyga-ubuntu: sanity timeout expired: Interrupted system call [15:00] mvo: this says that snap-confine held a lock for more than 3 seconds [15:00] mvo: (we have a sigalrm being sent to us) [15:00] zyga-ubuntu: is it just a very slow vm? can we try 12s? [15:00] mvo: I'd rather not change that amount yet, I just want to raise this in case there's something funny going on and we break in some D state in the kernel [15:01] mvo: I'll monitor tests for this [15:01] zyga-ubuntu: fair enough [15:01] mvo: it could be a slow VM but we usually grab this lock for tiny fractions of a second [15:03] zyga-ubuntu: is it in all tests? i have seen it before I think but not consistently [15:12] mvo: no, I just saw it now for the first time [15:16] * zyga-ubuntu -> fetch water [15:36] man [15:36] I go to fetch some water into canisters [15:36] just to find they finished repairs and it's back on :) [15:49] * zyga-ubuntu breaks, I'll ran into one problem and I need to think about it [15:50] PR snapd#4064 opened: tests: new test for hardware-random-control interface [16:00] mvo: The container based travis is flowing [16:02] mvo: For awareness, there were two different issues.. using the C language meant the checkout from git was done differently and paths didn't match anymore ($GOPATH semantics was gone).. then, the removal of the install section meant Travis cooked up a default install section for us while trying to help, but that broke things out as well [16:02] mvo: I'll write those notes in the forum so we don't lose it [16:02] Will just wait for tests to pass [16:19] PR snapd#3960 closed: travis: switch to container based test runs [16:19] mvo: https://forum.snapcraft.io/t/ci-on-travis-now-using-containers/2547 [17:07] niemeyer: nice, thanks for handling this [17:15] mvo: My pleasure, let's see if that kills the delays we've been observing [17:25] Are questions better in here, or in rocketchat? [17:26] bashfulrobot, here nowadays [17:26] ok, great. [17:27] Man, I do not know The Twitter. I never remember to make sure NOT to start a non-reply with a @ [17:28] soooo.... for 18.04 I would really like tio use snaps for applets in Ubuntu Budgie. Now with V11 in dev, but no ETA, we are staying open at this point if it will be V10 vs V11. But with V10, applets have to reside in a certain folder location. Do snaps at this point have a mechanism to accomplish this? I know with confimenemtn, etc, this goes COMPLETELY against what snaps are... [17:29] ogra_: have you attempted to get your nwjs snap working strictly? https://github.com/ogra1/nwjs [17:35] bashfulrobot, well, what ARE applets for budgie? [17:36] Essentially plugins and added features for teh Budgie Desktop. [17:36] bashfulrobot, so, like, .so ? [17:36] usually added to the panels, etc. [17:36] They can be written (currently) in vala, pythin and c++ [17:37] are they themselves applications? [17:37] (things that run) [17:37] They do not [17:37] run on their own. [17:38] bashfulrobot, i.e. you wouldn't declare any `apps` for them? [17:38] kyrofa - they have to be run and written in a certain way to be consumed by the desktop [17:38] In that case, they aren't technically confined at all [17:39] kyrofa is probably a better expert here, then, but why is a snap a good idea for that? [17:40] nacc The idea is to make it easier for 3rd party people to package. Auto update. Solus in theory could take advantage of them too. We also try to push our core applets into Debian, so that requirement is moot in snaps. [17:41] bashfulrobot: i understand all that, but it does't sound like what you are packaging is actually a snap :) [17:41] (or at leasta confined application in a snap) [17:42] Now you could be compeltely correct and maybe a snap is not the proper mechanism for this. But for the above reasons it "seemed" like it could be a good option (unless there is a reason technically to not do this). [17:42] nacc - this is true [17:42] It is kind of an odd edge case [17:42] I guess more so trying to use it as a delivery mechanism. [17:42] bashfulrobot: i'm curious what kyrofa things -- i have wondered how 'glue' fits into snaps myself. Things that are consumed by other applications. Perhaps what you want is to be a part? [17:43] Heh [17:43] exactly [17:43] Confinement is really only one aspect of snaps. There are a lot more, too [17:43] And as mentioned - I very well may be barking up the wrong tree where. [17:43] Bundling, updates, kind of the generic delivery method [17:44] But wanted to validate and see what the snap ecosystem thought of this. [17:44] bashfulrobot, nah, I hear where you're coming from, but I'll admit it's a bit unconventional [17:44] bashfulrobot, let's think this through [17:44] kryofa for sure. Has this type of thing come up before in discussion/ [17:44] ? [17:45] Not in my experience, but I'm hardly the only snap dev [17:45] ah ha for sure [17:45] So: you have a specific directory where "things" need to be. What are those things? How are they called into? [17:45] e.g. does each applet have a single entry point? [17:46] disclosure... I am more of the packager, and not so much a developer of these applets. so I have to be cautious of what I say here so as to not stick my foot up my arse. [17:47] bashfulrobot, haha, everyone is an expert relative to their colleagues. In this room, I suspect you're the expert ;) [17:47] well a foot up the arse is uncomfortable either way. :-p [17:47] Yeah that sorta sucks [17:48] bashfulrobot, we can start on the other end of the discussion, and I can list possibilities [17:49] awesome. I'm just reviewing a few applets here to be clear on myanswer for your question. [17:49] So: snaps are a single squashfs image, as you know. They get mounted into e.g. /snap/snapname/version [17:49] yup. [17:50] A snap containing an applet would contain the applet itself as well as any of its dependencies [17:51] First question: would budgie itself be one of those dependencies? [17:51] Ignoring that question, I'll continue [17:52] Having applets in /snap isn't useful. You need some way to get the applets into the "applet dir" what is that, in /var somewhere? [17:52] Well budgie itself is needed, but is not a snap. [17:52] What if you made a symlink back to the applet in the snap? [17:53] That was a thought I had. But was concerned that it was a bit of tom folery and hacky. [17:53] fooler* [17:53] foolery* [17:53] Since you'd be using the snap solely as a delivery method, it's really just a lump of libs and assets [17:53] yeah [17:53] exactly that [17:53] You'd need to set up the LD_LIBRARY_PATH such that those things are found [17:54] It could also use the budgie on the system if you strip it out of the applet snaps [17:54] that is hte way it would need ot be today. [17:55] Yeah, I think you could make this happen. It does sound a bit hacky [17:55] kyrofa - also to loop back to an earlier question... [17:56] That you had [17:56] Each applet is a typical libpeas based applet - i.e. a .plugin file and and a module file. Both live in /usr/lib/budgie-desktop/plugins/applet-name/applet.plugin & applet_module [17:56] Each applet can have multiple instances - UUID for each applet. [17:56] So you'd need to symlink both of those out of the snap? [17:57] hi, can i ask noob question about snap packages inside ubuntu here? [17:57] xan_IT, always :) [17:57] kyrofa - yeah that is my concern (hacky). I don't want to do this "just to do it", but rather if it makes sense. And if it was a situation that the team had either looked at, or considered (glue code of sorts). [17:57] bashfulrobot, are they found recursively? e.g. could you symlink a dir? [17:58] bashfulrobot, I think it's interesting, snaps solve some of the problems you'd need to solve yourself otherwise [17:58] bashfulrobot, it's probably going to come down to weighting the pros and cons there [17:58] 1) snap packages are in sandbox area, true? so if i install same packages throught deb and snap, second will not overwrite first. true? [17:58] bashfulrobot, might be worth a prototype [17:59] yeah for sure. [17:59] I could work towards one. [17:59] 2) there is like https://packages.ubuntu.com/ for snap?? [17:59] xan_IT, you're mixing terminology a bit, but yeah: when you install a snap, it typically doesn't mess with any debs [18:00] kyrofa what i mixing ? i want hunderstands :D [18:00] bashfulrobot, you know where to find us if you run into interesting issues there [18:00] xan_IT sandboxed yes, but if you use classic confinement, way more access (almost no confinement if I understand correctly) [18:00] xan_IT: https://uappexplorer.com/snaps has a list of available snaps [18:00] xan_IT deb will not overwrite snap. snap is in a differnt location and a squashfs [18:01] xan_IT, when you say "sandbox" you're mostly talking about confinement, but what you seem to be asking is: "will installing a snap interfere with a deb of the same thing" [18:02] thz, so snap packages can access to all file system ? [18:02] xan_IT: it depends on the confinement of the snap [18:02] kyrofa - I just remembered. We did do sonme testing with symlinks.... [18:02] I know if you symlink /usr/lib/budgie-desktop/plugins/applet-name to somewhere else, then yes budgie-desktop is happy [18:02] BUT [18:02] nacc ? [18:03] updates broke because the link is tied to the version number [18:03] bashfulrobot, did you try symlinking through /snap/snapname/current ? [18:03] so I guess the snap YAML would need logic to recreate on each update [18:03] xan_IT: https://docs.snapcraft.io/reference/confinement [18:03] bashfulrobot, another symlink [18:04] snapd maintains that one [18:04] ahh - did not [18:04] Will ahve to try that [18:05] bashfulrobot, that could work really nicely actually. Snaps can be disabled as well, which removes that symlink (but leaves the snaps in place) [18:05] bashfulrobot, which would break the symlinks, thus ensuring those applets aren't loaded [18:05] (another use-case for current is that, e.g., you can find the core snap always at /snap/core/current) [18:05] that has some use for me, at least [18:05] so there is only 1 repository for snaps for all distributions? [18:06] xan_IT, indeed. Since snaps are designed to work on multiple distributions, there's not really a need for a store for each [18:08] kyrofa well you have given me something to think about. And that the path I was looking at is the way to do it today. I would be interested if more of this type of discussion pops up and what the overall community thinks of this methind and delivering something like a plugin via snap. [18:08] bashfulrobot, well, there are multiple facets to that [18:08] xan_IT just the store. Global to all distros that use snaps [18:08] bashfulrobot, I think we definitely want to support shipping plugins as snaps, the question is how they're consumed [18:08] bashfulrobot, we have a bug for a new interface for this [18:08] last question: who update snap packages? [18:08] bashfulrobot, but that requires the consumer to be a snap [18:09] yeah, it's itneresting. a pluginn is like between a part and app [18:09] xan_IT: the snap owner [18:09] bashfulrobot, having the consumer be not snapped is a different ballgame [18:09] Because interfaces don't help us [18:09] kyrofa, author of app, or a official mantainer for all packages? [18:09] right meaning the deps (like budgie desktop in this case)? [18:10] bashfulrobot, yep [18:10] right - yeah - somethign to consider for sure. [18:10] bashfulrobot, so yeah. Go snap that. You'll be done tomorrow, I expect [18:10] kyrofa, simply like debian repository or like play store/appstore ?? [18:11] bashfulrobot, (kidding) [18:11] kyrofa - it's already done! [18:11] kyrofa, more like the play store [18:11] HA HA [18:11] Wow, sorry, that was for you xan_IT [18:11] Ha! [18:11] :) [18:11] xan_IT, there is no central packaging authority in the snap world [18:12] xan_IT, which means it's very easy to get YOUR app to YOUR users. Just release your update [18:12] xan_IT, in a more traditional packaging world this can be dangerous because you can break dependents, or your dependencies can break you [18:12] xan_IT, but since snaps bundle dependencies, we can skirt a lot of those issues [18:13] xan_IT, I don't mean to say that's a silver bullet, there are obviously tradeoffs there [18:14] xan_IT another perk, can hook up your github repo to build on push, etc too. See https://build.snapcraft.io/ and https://docs.snapcraft.io/build-snaps/ci-integration [18:16] kyrofa - thanks a ton for all of your help and time! Excellent info as always! [18:16] bashfulrobot, yeah man, any time [18:16] I'll work on this and post back if I have success! [18:16] thz to all, so is like a store inside linux [18:17] or like npm [18:17] bashfulrobot, would also like to hear about utter and compete failure [18:18] ok, donlt you worry, my sorry arse will likely be back with questions! [18:18] hahah [18:18] xan_IT, yeah, kinda. Although what happens if you're distributing an npm package that has a system dependency? [18:18] kyrofa ^^ [18:18] bashfulrobot, good [18:19] kyrofa i think npm not manage system dependency [18:20] xan_IT, right. So even with npm, you have to tell your users "install these dependencies... now install npm... now install my package" [18:20] xan_IT, with a snap, it's `snap install my-package` which contains npm, those dependencies, and your package [18:21] kyrofa i understands, is like npm++ :) [18:22] Hahaha, sure [18:22] :) [18:23] i need to go out, thz to all, i love all of you :) [18:25] xan_IT, thanks for stopping by! [18:25] snappy-m-o, autopkgtest 1583 xenial:amd64 [18:25] kyrofa: I've just triggered your test. [18:31] elopio1, I need your python and testing expertise [18:31] elopio1, help me brainstorm bug #1717921 [18:31] Bug #1717921: CI: BlockingIOError about 50% of the time [18:31] It's killing me [18:32] * Pharaoh_Atem sighs [18:33] ogra_: can you help verifying 1712224 ? [18:34] bug 1712224 [18:34] Bug #1712224: netplan should not try to unbind brcmfmac (like brcmfmac-sdio)

(Ubuntu):Fix Released by cyphermox> [18:45] elopio1, unrelated question spawned by niemeyer's forum post: are we not using docker pretty much exclusively for our tests, now? Does that make getting off the VM system a possibility for us as well? [18:46] Or wait... maybe we only use docker to build the snap [18:48] refresh my memory $SNAPCRAFT_PART_INSTALL is reltive to what? teh snap dir? [18:49] bashfulrobot, I believe it's absolute [18:49] bashfulrobot, it's only used when building in snapcraft, and it points to that specific part's installdir [18:50] bashfulrobot, put files in there, and they'll be migrated into stage, prime, and finally the snap [18:50] bashfulrobot, that variable is not defined at runtime [18:52] kyrofa - thanks again! [18:52] * bashfulrobot starting to refresh to finially finish mumble snap === JoshStrobl is now known as JoshStrobl|Food [19:54] bashfulrobot \o/ [19:59] kyrofa moving to docker won't help us as we need snapd; well we could move to docker with some hacks to have something running (snapd), but I don't really want to rely on that [19:59] the path to success elopio1 has layed out sounds better (dispatching though webhooks), but then we are at ground zero again with supporting our own infra [19:59] * sergiusens heads to the train station [20:57] sergiusens, bin/snapcraft-classic still sets LD_LIBRARY_PATH [20:58] sergiusens, which I believe leaks into its calling environment, making cmake look there for libs as well [20:58] sergiusens, which on trusty results in cmake: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /snap/snapcraft/x1/usr/lib/x86_64-linux-gnu/libicuuc.so.55) [20:58] Does that sound accurate? [20:59] I didn't think LD_LIBRARY_PATH was needed [20:59] I'll try blowing it away and see what happens === JoshStrobl|Food is now known as JoshStrobl [21:06] sergiusens, yes, that fixes things. Are you sure that LD_LIBRARY_PATH is still needed? I'm not seeing problems removing it in my limited tests [21:07] sergiusens, now I'm running into the issue that I think your PR fixes [21:07]