| mup | PR snapcraft#1340 closed: state: save all the build packages as global <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1340> | 01:25 |
|---|---|---|
| mup | PR snapcraft#1343 closed: go plugin: Cross compile with CGo <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1343> | 01:28 |
| mup | PR snapcraft#1358 opened: release changelog for 2.31 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1358> | 02:10 |
| Amorris | Is it possible to install snap on Arch Linux without pacman? | 02:12 |
| Amorris | Such as through a .tar.gz file? | 02:12 |
| === chihchun_afk is now known as chihchun | ||
| morphis_ | mvo: would be awesome if you can look at https://github.com/snapcore/snapd/pull/3365 again this morning and if you're ok, merge it now that niemeyer approved it | 06:04 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 06:04 |
| morphis_ | CI is already green | 06:04 |
| zyga | good morning | 07:07 |
| mup | PR snapd#3443 opened: Unity7 interface grows gtk2/3 settings and user's specific ini <Created by didrocks> <https://github.com/snapcore/snapd/pull/3443> | 07:19 |
| mvo | fgimenez: 2.26.4 is in -proposed now everywhere, could you please kick of the SRU verification? | 07:27 |
| fgimenez | mvo: sure! on it, the automated tests were actually triggered a few days ago but there was a problem in the logic that determines the release branch to execute the tests from https://travis-ci.org/snapcore/spread-cron/builds/238479940#L300 i'll fix that and retrigger | 07:29 |
| mvo | fgimenez: thank you | 07:31 |
| fgimenez | mvo: np i'll begin too with the changelog review, will keep you posted | 07:32 |
| mvo | morphis_: do you happen to know if the "proxy" helper is installed on fedora/suse by default? | 07:36 |
| fgimenez | mvo: btw i see that the deb was detected in -proposed about 6 days ago, is that correct? has it been updated since then? (just to make sure that we are detecting changes in proposed correctly) | 07:38 |
| mvo | fgimenez: updates arrived yesterday | 07:41 |
| mvo | fgimenez: 6 days looks not quite right | 07:41 |
| fgimenez | mvo: ok thx i'll take a look | 07:42 |
| mvo | fgimenez: https://launchpad.net/ubuntu/+source/snapd has the exact times, ~21h ago | 07:42 |
| icey | flexiondotorg: cholcombe and I have already done some poking around on https://github.com/rust-lang-nursery/rustup.rs/issues/1144 | 07:43 |
| fgimenez | mvo: ok thanks, in spread-cron we are currently watching http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html (interestingly there's no snapd in that page now, and it seems that it was there 6 days ago..), i'll update it to look into https://launchpad.net/ubuntu/+source/snapd | 07:47 |
| morphis_ | mvo: proxy helper? | 07:55 |
| mvo | morphis_: its a binary from libproxy called "proxy" | 07:55 |
| morphis_ | ah, let me check | 07:55 |
| mvo | morphis_: is that there by any chance? | 07:55 |
| morphis_ | not installed by default | 07:56 |
| morphis_ | but libproxy-bin provides it | 07:56 |
| morphis_ | let me try | 07:56 |
| mvo | morphis_: if its not there by default, thats all I need to know. that is on fedora or suse? | 07:56 |
| morphis_ | mvo: fedora 25 | 07:56 |
| morphis_ | mvo: let me try suse | 07:56 |
| mvo | morphis_: thank you | 07:57 |
| morphis_ | mvo: if you're adding a dependency can you add it for suse and fedora in packging too? | 07:57 |
| mvo | morphis_: I will explore it a bit, maybe dlopen(libproxy) is fine | 07:58 |
| morphis_ | mvo: is that for adding proxy support system wide? | 07:59 |
| morphis_ | mvo: libproxy-tools it is on suse and not installed by default | 07:59 |
| Chipaca | interestingly proxy itself doesn't look at the usual env vars | 08:01 |
| mvo | morphis_: yeah | 08:01 |
| mvo | Chipaca: oh? that sounds very wrong | 08:01 |
| Chipaca | ¯\_(ツ)_/¯ a matter of looking at the env and falling back to libproxy i guess? | 08:01 |
| mvo | morphis_: I talked to Son_Goku yesterday and he mentioned that fedora is not setting the systemwide proxy via environment but instead uses network-manager and the best option to talk to it seems to be libproxy | 08:02 |
| mvo | Chipaca: indeed | 08:02 |
| morphis_ | mvo: yeah libproxy looks really good for this | 08:02 |
| mvo | Chipaca: it will also mean we need to (potentially) create a new http.Client{} for each request as the proxy is per-url in this model | 08:02 |
| Chipaca | http.Transport | 08:03 |
| Chipaca | but yes | 08:03 |
| mvo | morphis_: the cheapest option is the exec.Command("proxy", url).Output() but adding a dependencies feels slightly ugly | 08:03 |
| mvo | Chipaca: yeah, sorry, a transport into the client of course | 08:03 |
| zyga | it's terrible that after decades of broad deployments proxy support in linux is not in libc | 08:03 |
| zyga | and everyone has to muck around with their special little snowflake | 08:04 |
| morphis_ | mvo: implementing our own libproxy isn't much better, isn't it? | 08:04 |
| zyga | (contrasting other platforms that do this right) | 08:04 |
| morphis_ | zyga: yeah, bionic has this AFAIK | 08:04 |
| mvo | morphis_: of course not :) sorry, what I mean is adding a hard dependency, I was curious to see if we could just dlopen(libproxy) and just ignore if its not there | 08:05 |
| morphis_ | mvo: however, how would applications get the proxy configuration? | 08:05 |
| morphis_ | mvo: ah | 08:05 |
| morphis_ | why not | 08:05 |
| mvo | morphis_: looking again it is probably ok nowdays, it used to be heavy on further dependencies but it seems like all of those are now pulled in via plugns. to support "pac" proxy configuration a JS interpreter is needed iirc | 08:07 |
| Chipaca | mvo: the biggest problem i see with all this is the "here's a list of proxies, try them in order" idea | 08:07 |
| mvo | Chipaca: hm, we could simply not support that (initially at least)? | 08:08 |
| Chipaca | mvo: also note proxy can return something that looks like socks://.... | 08:08 |
| Chipaca | lel | 08:08 |
| mvo | Chipaca, morphis_: thinking about it some more I guess we need to call an external helper or we pull in cgo again into the deamon | 08:08 |
| mvo | Chipaca: yeah | 08:08 |
| * mvo scratches head | 08:09 | |
| Chipaca | this sounds like *fun*! | 08:12 |
| morphis_ | mvo, zyga: I would like to get https://github.com/snapcore/snapd/pull/3365 merged now | 08:17 |
| mup | PR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365> | 08:17 |
| * zyga looks | 08:19 | |
| Chipaca | mvo: one more fun thing about using libproxy | 08:22 |
| Chipaca | it brings lin libstdc++ | 08:23 |
| ogra | hmm | 08:23 |
| ogra | ogra@sabrelite:~$ snap info core |grep refreshed | 08:23 |
| ogra | refreshed: 2017-06-08 04:24:21 +0000 UTC | 08:23 |
| ogra | ogra@bbb:~$ snap info core|grep refreshed | 08:23 |
| ogra | refreshed: 2017-06-07 04:23:44 +0000 UTC | 08:23 |
| ogra | why is that different ? isnt the refreshed value coming from the server ? | 08:24 |
| pedronis | no, that's refreshed as in the device refreshed | 08:24 |
| pedronis | I think | 08:24 |
| ogra | that doesnt match uptime | 08:24 |
| ogra | 4:20 UTC is actually the time the cron job runs for armhf | 08:25 |
| ogra | so that should be generation time | 08:25 |
| ogra | oh ... but the bbb didnt refresh ... it is the generation time of the currently installed snap | 08:26 |
| zyga | morphis_: merged | 08:28 |
| mvo | Chipaca: yeah, ugly but we also have that I think | 08:28 |
| morphis_ | zyga: you're my hero! | 08:28 |
| mup | PR snapd#3365 closed: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3365> | 08:29 |
| Chipaca | mvo: have that where? | 08:29 |
| morphis_ | zyga: lets wait until the suse one finishes then we can merge that one too | 08:29 |
| mvo | Chipaca: in the core snap | 08:31 |
| mvo | Chipaca: libstdc++ I mean | 08:31 |
| Chipaca | mvo: ah! i meant into the snapd binary itself | 08:31 |
| zyga | mvo: ok to land the --base branch? | 08:31 |
| mvo | Chipaca: yeah, I think we don't want this directly, probably via helper | 08:32 |
| mvo | zyga: which one? 3439? or the older 3317 ? | 08:33 |
| zyga | 3439 | 08:33 |
| mvo | zyga: it needs reviews first, no? I will do the first review next | 08:34 |
| flexiondotorg | icey Excellent! | 08:34 |
| zyga | mvo: yes, I meant that I wanted you to review it :) | 08:34 |
| mvo | zyga: aha, yes, will do | 08:34 |
| iliv | why does build.snapcraft.io needs access to organizations? | 08:34 |
| ogra | iliv, to put webhooks into the tree | 08:34 |
| zyga | iliv: for hooks | 08:34 |
| ogra | (well, endpoints( | 08:35 |
| iliv | well.. | 08:35 |
| iliv | my account has access to a number of organizations that have nothing to do with my repos that I'd like to use with build.snapcraft.io | 08:35 |
| zyga | iliv: I see, I think it would make sense to allow partial access to just the things that are needed | 08:36 |
| iliv | I kinda trust you people but most of those organizations will not be happy seeing build.snapcraft.io having access to their accounts | 08:37 |
| ogra | it is only needed to put the hook in place once though ... | 08:38 |
| ogra | theyx could turn it off afterwards (i know that doesnt help much in most cases) | 08:38 |
| iliv | so, what exactly will be done to those organization accounts? | 08:40 |
| iliv | you say a webook will be created.. but in which repo (if there are more than one)? | 08:40 |
| * ogra doesnt know the tech details, perhaps cjwatson can help | 08:41 | |
| cjwatson | iliv: the github access page lets you control this on a per-org basis; you don't have to grant access to all your orgs. build.snapcraft.io will only install a webhook in repositories that you specifically enable there. | 08:49 |
| fgimenez | mvo: zyga Chipaca can we land snapd#3348? it has two +1 and is almost green (just an autopkgtest failure due to the reexec flakiness), it will fix two nightly suites and unblock the spread-cron branches for executing the core-revert test automatically | 08:49 |
| mup | PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348> | 08:49 |
| mup | PR snapd#3348 closed: tests: add core revert test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3348> | 08:51 |
| cjwatson | and in fact the org access is only needed so that BSI can list org-owned repos through the github API; there's a separate permission for installing webhooks | 08:51 |
| fgimenez | mvo: thanks! :) | 08:51 |
| iliv | cjwatson, I can't control it, though. All I see is a green check mark against organization name and it is not interactive. | 08:51 |
| cjwatson | (we ask for admin:repo_hook read:org, in the github scopes language) | 08:51 |
| cjwatson | iliv: you can control it on https://github.com/settings IIRC (I would check more specifically but my internet connection is being unusually terrible today) | 08:52 |
| zyga | fgimenez: looking | 08:53 |
| zyga | fgimenez: that PR had my upublished review | 08:54 |
| zyga | darn github | 08:54 |
| cjwatson | iliv: oh, I think if it's just a green tick then that's because the org owner has allowed it | 08:54 |
| cjwatson | iliv: we don't get to control any of this stuff, it's all up to github | 08:54 |
| zyga | fgimenez: can you please look at the PR again? | 08:55 |
| cjwatson | https://help.github.com/articles/about-oauth-app-access-restrictions/ has some more details | 08:55 |
| fgimenez | zyga: sure, thanks! i'll prepare a follow addressing your comments | 08:57 |
| zyga | fgimenez: thank you, I'm sorry I didn't realize I never submitted this review | 08:57 |
| zyga | the snap-confine-from-core and the other re-exec tests keep failing randomly | 08:58 |
| zyga | I don't remember any branch that didn't fail on this in the past week | 08:58 |
| zyga | I'll try to figure out WTF is going on there :/ | 08:59 |
| mup | PR snapd#3370 closed: many: derive implicit slots from interface meta-data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3370> | 08:59 |
| fgimenez | thank you zyga, i think sergio is also lookign into it | 08:59 |
| cjwatson | anyway, as far as I can tell we ask for the absolute bare minimum that we need to install webhooks and see any org-owned repos at all | 09:00 |
| zyga | does anyone know of a vim extension that would add a tab to an exsiting vim whenever vim is invoked from command line but another process exists somewhere? | 09:02 |
| iliv | cjwatson, yes, it seems to work like you said. kinda weird... | 09:03 |
| morphis_ | mvo, zyga: approval and a merge of https://github.com/snapcore/snapd/pull/3406 would be nice :-) | 09:06 |
| mup | PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 09:06 |
| zyga | morphis_: looking | 09:10 |
| mup | PR snapd#3444 opened: interfaces: compose the base declaration from interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3444> | 09:10 |
| zyga | morphis_, mvo: can you please look at 3444 | 09:10 |
| morphis_ | zyga: sure | 09:11 |
| zyga | morphis_: can you merge master into 3406? | 09:11 |
| morphis_ | zyga: I did this 45min ago | 09:11 |
| zyga | morphis_: merging it now would shorten the diff | 09:12 |
| morphis_ | sure | 09:12 |
| zyga | morphis_: correct me if I'm wrong but I still see the fedora changes there | 09:12 |
| morphis_ | I merged before the merge of the fedora branch | 09:12 |
| morphis_ | isn't travis doing an automatic merge with master when it runs? | 09:13 |
| morphis_ | zyga: but merge now | 09:13 |
| zyga | morphis_: it's optional | 09:13 |
| zyga | morphis_: and we don't do it | 09:14 |
| morphis_ | zyga: shouldn't travis fail when a merge with master breaks any tests? | 09:16 |
| mvo | zyga: base snap branch looks good | 09:18 |
| pedronis | morphis_: well if the run is old you don't know because master has moved | 09:18 |
| morphis_ | pedronis: right but at the point where travis starts, shouldn't it start testing from a combination of master + branch? otherwise test results will always be a lie if master has evolved | 09:19 |
| pedronis | it does afaik | 09:20 |
| morphis_ | ok | 09:20 |
| pedronis | but we might still break master because the check is not done on the merging | 09:20 |
| zyga | mvo: thanks! | 09:23 |
| zyga | Chipaca: can you do a 2nd review so that mvo can iterate on base snaps? | 09:23 |
| zyga | morphis_: github has a setting where you can enable a check that disables merging if master has moved | 09:24 |
| zyga | morphis_: bue we're not using it | 09:24 |
| zyga | morphis_: as it requires a rebase-based workflow | 09:24 |
| * zyga hugs rebase | 09:24 | |
| morphis_ | zyga: reviewed #3444 | 09:24 |
| morphis_ | zyga: I see | 09:24 |
| Chipaca | zyga: on which pr? | 09:26 |
| zyga | Chipaca: on 3439 | 09:26 |
| mup | PR snapd#3439 closed: cmd/snap-confine: add support for --base snap <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3439> | 09:29 |
| zyga | morphis_: reviewed | 09:29 |
| mup | PR snapd#3445 opened: tests: add linode-sru backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3445> | 09:33 |
| zyga | morphis_: updated | 09:34 |
| morphis_ | zyga: ok | 09:34 |
| zyga | morphis_: sorry for being so picky about those comments but I think it is essential | 09:45 |
| zyga | morphis_: in a few weeks nobody will remember why fedora or suse is not included in a given test | 09:45 |
| morphis_ | zyga: commented on all and fixed most | 09:47 |
| morphis_ | zyga: np, but basically we have all test cases disabled right now | 09:47 |
| morphis_ | that is why we switched from a blacklist to a whitelist approach | 09:47 |
| zyga | morphis_: thanks, ping me and I'll re-read it | 09:47 |
| morphis_ | a followup PR will clean this up and enable most tests | 09:48 |
| morphis_ | zyga: ping :-) | 09:48 |
| zyga | aha :D | 09:48 |
| zyga | reading then | 09:48 |
| morphis_ | thanks | 09:49 |
| morphis_ | zyga: approved #3444, thanks for doing the cahnges! | 09:53 |
| zyga | morphis_: thank you! | 09:53 |
| zyga | morphis_: re-reviewed | 10:03 |
| zyga | morphis_: fix one typo and +1 | 10:03 |
| zyga | morphis_: some heavy conflicts on 3411 | 10:07 |
| ogra | zyga, hmm | 10:10 |
| ogra | "On core systems we don't pivot_root and that | 10:11 |
| ogra | has to change before base snaps are fully operational" | 10:11 |
| ogra | zyga, can we make sure to get proper ram usage statistics before implementing such a thing (or do i mis-read that ... you want to exec every snap on a core install in pivot_root ?) | 10:11 |
| mup | PR snapd#3446 opened: errtracker: Include /etc/apparmor.d/usr.lib.snap-confine md5sum in err reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/3446> | 10:13 |
| zyga | ogra: yes, this is required for base snaps | 10:16 |
| zyga | ogra: core and classic will behave (finally) exactly the same | 10:16 |
| ogra | zyga, well, why do we need base snaps on core installs ... i though they are a lib layer on top of core | 10:16 |
| zyga | ogra: no, they are not | 10:17 |
| zyga | ogra: base snaps are needed so that we can run snaps that use base snaps (which will soon be most snaps, I think) | 10:18 |
| ogra | zyga, in any case we are supporting embedded boards and i suspect pivot_root means there will be more copies of libs and env in ram that we should really measure before | 10:18 |
| zyga | ogra: base snaps, roughly, will just use snaps other than core as the root filesystem | 10:18 |
| ogra | right, so whats the use case on a core install for that ? | 10:18 |
| zyga | ogra: note that we will have less things in the core snap this way | 10:18 |
| zyga | ogra: *every* snap will use a base snap | 10:18 |
| zyga | ogra: have you been following the base snap discussions on the forum/ | 10:19 |
| ogra | not closely the last days | 10:19 |
| zyga | ogra: core will become a snap with just snapd in it | 10:19 |
| ogra | but that sounds really awkward for low end | 10:19 |
| zyga | ogra: and what is currently in core will become ubuntu-16 base snap | 10:19 |
| ogra | ok | 10:19 |
| zyga | ogra: it is required for 16-18 migration | 10:19 |
| ogra | that is what i grokked before | 10:19 |
| zyga | ogra: and to allow running snaps with different bases on one system | 10:20 |
| ogra | but that you plan to pivot_root each and every snap is new to me | 10:20 |
| zyga | ogra: how would those work otherwise? | 10:20 |
| ogra | or that you want to support different base snaps on some 256M 200MHz IoT board installs | 10:20 |
| zyga | ogra: yes, we don't want to have 2nd class devices that don't support an essential feature | 10:20 |
| ogra | by simply merging the rootfs on boot | 10:20 |
| zyga | what do you mean by merging? | 10:21 |
| ogra | and keeping the snaps as they are without duplicating the world in ram | 10:21 |
| zyga | why do you think we'd be duplicating something in ram? | 10:21 |
| mup | PR snapd#3447 opened: debian: unify built_using between the 14.04 and 16.04 packaging branch <Created by mvo5> <https://github.com/snapcore/snapd/pull/3447> | 10:21 |
| ogra | merge core and base on booot ... execute natively | 10:21 |
| ogra | like we do today ... just with an additional split of the snapd bits into another snap | 10:21 |
| mvo | fwiw, libraries are mapped into ram based on inode number, if that stays the same nothing will be duplicated (someone needs to double check that) | 10:22 |
| ogra | if you want to go that route that really should see some measurements | 10:22 |
| zyga | ogra: I'm open to suggestions but IMO there is no other route | 10:22 |
| mvo | (double check that the inode number stays the same, the mmap mechanism is well understood) | 10:22 |
| * zyga checks | 10:22 | |
| ogra | mvo, thats what i'm saying ... not saying it is wrong or anything but on that low end we shouldnt operate without ameasurments and data | 10:22 |
| ogra | *measurements | 10:23 |
| ogra | i'm sure pivot_root will have overheard, the question is if that is bytes or megabytes | 10:23 |
| ogra | *overhead | 10:23 |
| zyga | inode number is the same | 10:23 |
| zyga | ogra: why would pivot_root have overhead? | 10:24 |
| ogra | because it wraps around something, it is an additional layer | 10:24 |
| zyga | I don't think that's true | 10:24 |
| zyga | it's a chroot on steroids | 10:24 |
| ogra | yes | 10:24 |
| zyga | (kind of) | 10:25 |
| zyga | ogra: the only overhead is that as core and bases diverge we will see extra copy of libc used by the few services in the core snap, for everything else they will operate exactly the same as today | 10:25 |
| ogra | zyga, well, still, it would be good to measure the differences between with and without pivot_root regarding system resources ... we're in embedded territory here ... | 10:27 |
| zyga | ogra: that I agree with | 10:27 |
| zyga | ogra: it'd be good to come up with a benchmark we can repeat | 10:27 |
| ogra | well, just measure rem and cpu usage for the same app snap in both cases | 10:28 |
| ogra | *ram | 10:28 |
| zyga | ogra: specific snap (revision), specific board, specific script | 10:28 |
| ogra | sure | 10:28 |
| zyga | so that we can just run this via spread and stay aware | 10:28 |
| ogra | well, not needed to do it regulary ..… thats simply stuff you should research before coming up with such an implementation ... once you know if there is a difference and how big it is thats enough | 10:29 |
| ogra | it wont change over time so doesnt need to be a regular test | 10:29 |
| ogra | ppisati_, do you have a sabrelite ? | 10:33 |
| ogra | ppisati_, i'm seeing weird console distrotion when i boot with hdmi and console=tty0 with the current linux-generic from xenial | 10:36 |
| zyga | ogra: note that we came up with pivot_root last year, this is nothing new | 10:36 |
| zyga | ogra: given what we need to do there's no other way to implement base snaps | 10:37 |
| zyga | ogra: I suspect we actually use less memory now as before persistent mount namespaces *each process* would independently pivot_root | 10:37 |
| ogra | zyga, well, we get along without base snaps today ... and merging core and base on boot with keeping the native execution would work too ... core specific indeed | 10:38 |
| morphis_ | zyga: fixe | 10:38 |
| zyga | ogra: no it would not work because the whole idea of base snaps is to have more than one | 10:38 |
| ogra | zyga, note that i'm not saying anything is wrong though ... but we should have numbers before jumping ahead with implementation | 10:39 |
| zyga | ogra: so you cannot use your current rootfs as the rootfs for snaps | 10:39 |
| pedronis | zyga: either we way we likely need a root filesystem, there still the question what really goes into core vs base | 10:39 |
| zyga | pedronis: I agree, I think this will clear up as we come closer to the sprint | 10:39 |
| ogra | zyga, we do that today ... and why would you want to support multiple base snaps on super-low-end devices ? | 10:40 |
| ogra | i always understood that this is not wanted for ubuntu core | 10:40 |
| zyga | ogra: we cannot do that once we have more than one base snap | 10:40 |
| zyga | ogra: and we want to have more than one base snap so that we can transition to 18 series | 10:40 |
| ogra | sure we can ... we can restrict what can be installed on a core installation | 10:40 |
| zyga | ogra: and to allow other distributions to equally participate in the snap distribution | 10:40 |
| zyga | ogra: if we restrict we will have to have a flag day for 18 transition and we don't want that | 10:41 |
| ppisati_ | ogra: nope, i don't have one | 10:42 |
| ppisati_ | ogra: what is that? | 10:42 |
| ogra | imagine you have something like a beaglebone, your ram is limited, your cpu is limited ... do you really want to allow people that install three snaps to have three oses running on that setup because the three snaps use three different bases ? | 10:42 |
| pedronis | zyga: notice also that because of the configure hook the core snap will need a base snap too | 10:42 |
| zyga | ogra: yes, if that's what those people want to run I don't want to stand in their way | 10:42 |
| ogra | ppisati_, they renamed it to nitrogen6 ... its an IMX board | 10:42 |
| pedronis | (at least the configure hook is a likely reason to need one) | 10:42 |
| zyga | pedronis: configure hook for which snap? | 10:42 |
| pedronis | for teh core snap | 10:42 |
| pedronis | the core snap has a hook | 10:42 |
| pedronis | nowadays | 10:43 |
| zyga | pedronis: right, I was just checking | 10:43 |
| ogra | zyga, well, then we can simply give up on IoT boards will just come to hang and crawl with that | 10:43 |
| zyga | pedronis: yes, it is likely that the core snap will be special cased to be its own base snap | 10:43 |
| zyga | ogra: I doubt that | 10:43 |
| pedronis | zyga: well that start to be weird | 10:43 |
| pedronis | I fear duplication then | 10:44 |
| zyga | duplication of? | 10:44 |
| pedronis | stuff that needs to be in the core snap and the base snap | 10:44 |
| pedronis | like python or something | 10:44 |
| zyga | pedronis: the good thing that base snaps will allow us to do is to almost freely shape the core snap | 10:45 |
| pedronis | not really | 10:45 |
| zyga | pedronis: as it will no longer affect how anything runs | 10:45 |
| pedronis | if the core snap isn't really minimal | 10:45 |
| ogra | zyga, well, if i install the mysql snap from that fedora guy, along with the webserver snap from this arch guy on top of my ubuntu core board, i end up with three OSes on disk and in ram | 10:45 |
| zyga | pedronis: the initial ubuntu-16 will fork from the current core (snaps snapd) | 10:45 |
| ogra | zyga, thats definitely not feasible | 10:45 |
| zyga | ogra: yes but this is what you _wanted_ | 10:45 |
| zyga | ogra: if you don't want to do that, don't do that | 10:45 |
| ogra | zyga, how did i know ? | 10:45 |
| zyga | ogra: or get the stack from one vendor | 10:45 |
| zyga | ogra: snap info will tell you that | 10:46 |
| ogra | zyga, you are saying that a user of our SW should know the source in and out ? | 10:46 |
| zyga | ogra: anyway, I think this discussion is moot now | 10:46 |
| ogra | and why would i look at snap info | 10:46 |
| zyga | ogra: same could be said for base-16 and base-18 | 10:46 |
| ogra | all i wanted was the webserver to act as frontend to a mysql db ... | 10:46 |
| ogra | on my $mini-board | 10:47 |
| ogra | so i just picked the packages ... done | 10:47 |
| ogra | and then notice that the whole thing eats my disk and ram | 10:47 |
| pedronis | zyga: anyway there's a problem that likely some core snap config should be part of a base snap configure, but that concept doesn't make sense | 10:47 |
| zyga | pedronis: can you give me an example? | 10:48 |
| ogra | we could surely make that an optional switch to allow additional base snaps ..… but thats definitely nothing we should have OOTB | 10:48 |
| zyga | pedronis: I suspect that base snaps won't have much configuration at first | 10:48 |
| pedronis | where would sshd live? | 10:48 |
| zyga | pedronis: in the base snap | 10:48 |
| pedronis | see | 10:48 |
| zyga | er | 10:48 |
| zyga | core snap | 10:48 |
| zyga | unless we start to allow apps and services on base | 10:48 |
| pedronis | see | 10:49 |
| zyga | which is something we never discussed | 10:49 |
| zyga | base snaps won't have any configuration intially because they won't run any services | 10:49 |
| ogra | where else would system services live ? | 10:49 |
| pedronis | in the core snap it seems | 10:49 |
| ogra | err | 10:49 |
| zyga | if we choose to move them to a blessed base snap | 10:49 |
| pedronis | but I think we also had a different vision | 10:49 |
| zyga | we could do that | 10:49 |
| pedronis | where the core snap was mostly just snapd | 10:49 |
| pedronis | and its deps | 10:49 |
| _28Kb | services must be snaps i guess | 10:50 |
| ogra | <zyga> ogra: core will become a snap with just snapd in it | 10:50 |
| zyga | pedronis: yes, but that is the road ahead, for now we can start with just a copy of the current core as core and base and then trim them as we go | 10:50 |
| ogra | so the system services must be in the base snap | 10:50 |
| zyga | ogra: _will become_ :) | 10:50 |
| ogra | (in that setup at least) | 10:50 |
| pedronis | well or we have a services snap | 10:50 |
| abeato | ogra, mvo could we move forward https://github.com/snapcore/core-build/pull/13 ? | 10:50 |
| mup | PR core-build#13: Androidboot support <Created by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/13> | 10:50 |
| zyga | I think it is all doable but we need to discuss one more thing at the sprint: if we are going to get rid of bootable bits from the core snap | 10:51 |
| ogra | well | 10:51 |
| ogra | we cant get rid of them ... we can probably move them around though | 10:51 |
| zyga | it those go to a new helper snap (ubuntu-core maybe) then this will resolve other questions | 10:51 |
| zyga | that's what I meant | 10:51 |
| zyga | then on classic systems you'd need base snaps only | 10:51 |
| zyga | not even core or ubuntu-core | 10:52 |
| zyga | on systems that re-exec you'd pull in core and base snaps | 10:52 |
| zyga | and on core systems we'd pull in everything | 10:52 |
| * ogra isnt so worried about the resulting rootfs and how we assemble it, thats all easily solvable | 10:52 | |
| ogra | but the "multiple base snaps allowed" is really bothering on core | 10:52 |
| zyga | ogra: do you have a plan for 18 transition? | 10:53 |
| ogra | thats fine if you have endless ressources like on a PC | 10:53 |
| ogra | zyga, allow exactly one base snap | 10:53 |
| zyga | ogra: that doesn't involve running both 16 and 18 snaps at the same time? | 10:53 |
| ogra | or allow two ... still better than "any" | 10:53 |
| zyga | ogra: that's one way to make sure nobody can transition until *everything* has a 18 snap as well | 10:53 |
| zyga | ogra: if we allow two we might as well allow any | 10:53 |
| zyga | ogra: until we measure and show this is terrible (doubtful) I think this is not a thing worth discussing now | 10:54 |
| ogra | what i really dont like is that you end up with the fedora, arch, suse base snaps being pulled in silently when installing some app snap | 10:54 |
| ogra | (on core that is) | 10:54 |
| zyga | ogra: we could lazily mount snaps to save memory (keep old revisions unmounted) | 10:54 |
| zyga | ogra: it's just like docker really, but more integrated and better | 10:55 |
| ogra | zyga, you will still have multiple libs and envs in ram | 10:55 |
| zyga | ogra: we can put confirmations in place but it doens't change that users are in control | 10:55 |
| ogra | core should simply be restricted by default to only use ubuntu base snaps (16 and 18 if you feel thats needed) | 10:56 |
| ogra | but using foreign bases should be a switch rthat is disabled by default | 10:56 |
| ogra | we have very limited resources on core | 10:56 |
| ogra | and that implementationm is very wasteful | 10:56 |
| ogra | (and did you wonder why people dont run their whole OS in docker n raspberry pi's ? :) ) | 10:57 |
| mvo | a second review for https://github.com/snapcore/core/pull/48 would be great | 10:58 |
| mup | PR core#48: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <https://github.com/snapcore/core/pull/48> | 10:58 |
| zyga | mvo: some comments there | 11:16 |
| mvo | zyga: ta | 11:16 |
| zyga | mvo: don't mind the -1, just a voice of concern for the hook | 11:18 |
| zyga | mvo: do you think we could write it in go instead? | 11:18 |
| zyga | mvo: you know (remember) better the discussion around that AFAIR | 11:19 |
| mvo | zyga: well, I wrote it in python but that got shoot down, I can give it another go in go. it just a bit of work | 11:21 |
| mvo | zyga: and yeah, no disagreement that sh sucks for this kind of things | 11:22 |
| zyga | mvo: what was the reason for the python _1? | 11:22 |
| zyga | oho | 11:22 |
| mvo | zyga: there is a forum discussion | 11:22 |
| mvo | zyga: that has the discussion | 11:22 |
| zyga | look at this | 11:23 |
| zyga | https://travis-ci.org/snapcore/snapd/builds/240716712?utm_source=github_status&utm_medium=notification | 11:23 |
| zyga | https://paste.gnome.org/pvdpi4vbu | 11:25 |
| zyga | some crazy linode stuff is going on there | 11:26 |
| zyga | fgimenez: ^^ did you ever see a failure like that? | 11:27 |
| morphis_ | zyga: happy to merge https://github.com/snapcore/snapd/pull/3406? | 11:29 |
| mup | PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 11:29 |
| fgimenez | zyga: nope, seems that the linode api stopped working for a while and started returning html instead of json, anyway "Our development team has been alerted to this error. If you continue to have problems please contact support <a href="mailto:support@linode.com">support@linode.com</a>" | 11:29 |
| zyga | morphis_: we need a 2nd review but yes | 11:34 |
| morphis_ | mvo: you have time for second review on #3406? or fgimenez? | 11:35 |
| mup | PR snapd#3438 closed: daemon: make snapd a "Type=notify" daemon and notify when startup is done <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3438> | 11:40 |
| morphis_ | Pharaoh_Atem: can you have a look at https://github.com/snapcore/snapd/pull/3398 ? | 11:47 |
| mup | PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al <Created by sergiusens> <https://github.com/snapcore/snapd/pull/3398> | 11:47 |
| morphis_ | Pharaoh_Atem: is there some better place in Fedora to do this kind of thing? | 11:47 |
| zyga_ | morphis_: there's a new systemd thing | 11:48 |
| morphis_ | zyga_: you have a link? | 11:48 |
| zyga_ | yes, one sec | 11:48 |
| morphis_ | new as in too old for 14.04? | 11:48 |
| morphis_ | 16.04 I mean | 11:49 |
| zyga_ | morphis_: starting with systemd 233 you can use /run/environment.d/ http://in.waw.pl/~zbyszek/blog/environmentd.html | 11:51 |
| morphis_ | interesting | 11:51 |
| zyga_ | cachio_: some comments on 3409 | 12:00 |
| zyga_ | mvo: I +1 3317, if you can get a 2nd review (perferrably from niemeyer as it affects snap.yaml syntax) I'd love to have it | 12:23 |
| zyga_ | mvo: I also wonder about the tech review board | 12:23 |
| zyga_ | mvo: we should get an approval from them from snap format changes, right? | 12:23 |
| zyga_ | mvo: but I wouldn't like to block R&D on that | 12:23 |
| zyga_ | mvo: perhaps we can create a branch (say base-snaps) where we land things in anticipation of the sprint | 12:24 |
| zyga_ | mvo: where we can prepare and brew enough of this to run a base snap for real | 12:24 |
| zyga_ | mvo: and get the experience and measurements we need | 12:24 |
| mvo | zyga_: good point, we need approval from niemeyer at least | 12:24 |
| zyga_ | ok, since nothing can land because of reexec mystery I'll look at that instead of anything else now | 12:28 |
| * ogra glares ... | 12:28 | |
| ogra | ogra@anubis:~/datengrab/hikey-lemaker$ ls /mnt/ | 12:28 |
| ogra | dtbs hikey-kernel_0.snap install.yaml snappy-system.txt uboot.env | 12:28 |
| ogra | wow | 12:28 |
| ogra | so thats an all-snap image ... but using an install.yaml for ubuntu-device-flash | 12:29 |
| ogra | kind of a hybrid between actual all-snap and old a/b partition setup | 12:29 |
| ogra | (and uboot.env is full of snappy_* variables ... this will explode really badly on first upgarde i guess) | 12:32 |
| ogra | (if it would even upgrade at all ... it installs ubuntu-core 111 ) | 12:32 |
| zyga_ | pstolowski: hey, I added some comments to 3340 | 12:37 |
| fgimenez | zyga_: i'm getting this error on 14.04 with the 2.26.4 deb installed http://paste.ubuntu.com/24807633/ (executing the tests from the release/2.26 branch) could you please take a look? | 12:38 |
| zyga_ | sure | 12:38 |
| zyga_ | looking | 12:38 |
| zyga_ | fgimenez: which kernel are you on? | 12:38 |
| fgimenez | zyga_: aah let me check, probably an old one, the new kernel debs should be in place but the reboot didn't happen | 12:39 |
| cachio_ | zyga_, nice | 12:39 |
| pstolowski | zyga, thanks, looking | 12:39 |
| cachio_ | zyga_, the 3433 is ready if you have a minute | 12:40 |
| zyga_ | cachio_: sure, I'm doing PRs anyway (while chasing the re-exec bug) | 12:40 |
| fgimenez | zyga_: indeed, it had installed 4.4.0-79 but was still using 3.13.0-119 http://paste.ubuntu.com/24807695/ trying now with a reboot after the upgrade, thanks! | 12:51 |
| zyga_ | fgimenez: my pleasure, I may add a feature to snap-confine to bail out with a nicer message | 12:52 |
| === chihchun is now known as chihchun_afk | ||
| zyga_ | cachio_: +1 | 12:54 |
| cachio_ | zyga_, awesome | 12:54 |
| zyga_ | cachio_: did you trace that as a possible cause of the re-exec issue? | 12:54 |
| mup | PR snapd#3433 closed: tests: restoring the /etc/environment and service units config for each test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3433> | 12:54 |
| fgimenez | zyga_: sounds good, btw snapd#3391 takes care of the reboot during the sru validation for 14.04, a review would be great | 12:55 |
| mup | PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391> | 12:55 |
| zyga_ | fgimenez: sure | 12:55 |
| cachio_ | zyga_, I could not reproduce it, and I added some debugs to get information but I didn't get much more | 12:55 |
| zyga_ | cachio_: it hapepns many times a day | 12:56 |
| zyga_ | cachio_: but yes, reproducing it is hard sometimes | 12:56 |
| zyga_ | fgimenez: done | 12:56 |
| cachio_ | zyga_, could you reproduce it? | 12:56 |
| zyga_ | cachio_: I'm still trying, I have some tools to help me find the possible cause | 12:57 |
| cachio_ | zyga_, I would like to see if after this change in the environemnt variables the bug is being reproduced | 12:58 |
| zyga_ | allocation failed on all instances on https://travis-ci.org/snapcore/snapd/builds/240716184?utm_source=github_status&utm_medium=notification | 12:59 |
| zyga_ | cachio_: indeed, I want to see new test runs | 12:59 |
| fgimenez | zyga_: thx! | 12:59 |
| cachio_ | niemeyer, I'll be 3 minutes late | 13:00 |
| niemeyer | cachio_: Thanks for the note | 13:00 |
| niemeyer | Chipaca, pstolowski: Stand up? | 13:03 |
| Chipaca | oops | 13:03 |
| Chipaca | omw | 13:03 |
| mvo | jdstrand: did you had a chance to look (high level) on https://github.com/snapcore/snapd/pull/3431 yet? | 13:42 |
| mup | PR snapd#3431: interfaces: simplify snap-confine by just loading pre-generated bpf code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3431> | 13:42 |
| Chipaca | pedronis: before I forget again, could you revisit snapd#3420 ? | 13:50 |
| mup | PR snapd#3420: many: slight improvement of some snap error messaging <Created by chipaca> <https://github.com/snapcore/snapd/pull/3420> | 13:50 |
| cachio_ | zyga_, https://travis-ci.org/snapcore/snapd/builds/240775990#L4193 | 13:50 |
| * Chipaca ~> reboot because busted snap-confine | 13:50 | |
| * zyga_ runs for lunch | 13:52 | |
| pedronis | Chipaca: are you sure tr.Get returns ErrNoState ? | 13:53 |
| fgimenez | niemeyer: could you please give another shot at snapd#3391 ? sru tests were failing on 14.04 because of the issue this PR fixes | 13:53 |
| mup | PR snapd#3391: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391> | 13:53 |
| zyga_ | Chipaca: what happened? | 13:55 |
| Chipaca | zyga_: same as the other day? | 13:55 |
| Chipaca | but this time it won't go away | 13:55 |
| fgimenez | niemeyer: your input on snapd#3445 would be great too | 13:55 |
| mup | PR snapd#3445: tests: add linode-sru backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3445> | 13:55 |
| zyga_ | Chipaca: what was it? | 13:55 |
| jdstrand | mvo: I haven't yet, but I finished the thing that was in front of it so plan to get to it today | 13:55 |
| niemeyer | fgimenez: Ack, will look, thanks | 13:55 |
| jdstrand | well, finished is strong. I'm blocked, but that is neither here nor there for you request | 13:55 |
| jdstrand | your* | 13:55 |
| fgimenez | niemeyer: thx! | 13:55 |
| Chipaca | zyga_: http://pastebin.ubuntu.com/24808074/ | 13:55 |
| zyga_ | Chipaca: unmount /run/snapd/ns/core.mnt | 13:56 |
| zyga_ | Chipaca: I think that should cure it | 13:56 |
| * zyga_ runs to eat for real | 13:56 | |
| Chipaca | zyga_: when you get back from eating for real, why is it getting confused by that? | 13:58 |
| Chipaca | I mean, it created that mountpoint in the first place | 13:58 |
| Chipaca | zyga_: and no that has not fixed it | 13:59 |
| jdstrand | mvo: there was talk of a meeting with me to discuss race-free profile loads. I see https://github.com/snapcore/snapd/pull/3442 but it falls back to old profiles (thus not addressing my concern). did a meeting happen without me? is something else being done? | 13:59 |
| mup | PR snapd#3442: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442> | 13:59 |
| Chipaca | although the error is slightly different | 13:59 |
| pedronis | Chipaca: I don't see tr.Get producing ErrNoState, can you check if we have a test for doing conf get on a missing snap | 13:59 |
| Chipaca | pedronis: ack | 14:00 |
| Chipaca | zyga_: http://pastebin.ubuntu.com/24808102/ | 14:00 |
| pedronis | Chipaca: and sorry, anyway what I spotted was the other one | 14:00 |
| morphis_ | mvo: do you have an idea about what could be wrong in https://paste.ubuntu.com/24808137/ ? | 14:08 |
| morphis_ | mvo: snapd seems to be terminated at the end | 14:08 |
| morphis_ | wondering if this is related to re-execution | 14:08 |
| morphis_ | zyga: ^^ | 14:08 |
| mvo | morphis_: definitely strange, systemctl shows its up in the log, re-exec appears to be disabled (as it should) | 14:09 |
| morphis_ | mvo: yes, wondering what happens here and what causes snapd to terminate | 14:10 |
| mvo | jdstrand: no worries, the seccomp PR is just one step, there is one more https://github.com/snapcore/snapd/pull/3442 | 14:10 |
| mup | PR snapd#3442: snap: ensure security polices are re-created <Created by mvo5> <https://github.com/snapcore/snapd/pull/3442> | 14:10 |
| morphis_ | mvo: just running the test again, to do a few more checks | 14:10 |
| mvo | morphis_: are you in the system? or is that just output from e.g. linode? | 14:11 |
| mvo | morphis_: if you can run with -debug that might be helpful | 14:11 |
| morphis_ | it's from linode, yes | 14:11 |
| mvo | jdstrand: but gustavo was keen to do some more changes there I think, I was mostly asking about seccomp to see if there are concerns from a security POV | 14:11 |
| morphis_ | mvo: have a shell again in a few min | 14:13 |
| jdstrand | mvo: I realize seccomp 3431 was the first step. I saw 3441 and wasn't sure if it was the 2nd or final step. if final, again, it doesn't address my concerns. note I commented in 3441 | 14:13 |
| jdstrand | mvo: thanks for the update. I'm not terribly sure we are in alignment as the meeting never happened... I guess I'll just try to keep an eye on things | 14:14 |
| mvo | jdstrand: aha, thank you. so its just about the timeout (your concern). thta should be straightforward to fix | 14:14 |
| jdstrand | mvo: for that PR, there is a concern about the timeout, yes | 14:16 |
| jdstrand | mvo: but I don't know what a reasonable value is there | 14:16 |
| jdstrand | mvo: to me, if you do that pr and instead of falling back to old profiles, trigger the regeneration for that snap, then that would address all of my concerns (I realize there is a lock contention there, but that is surmountable) | 14:17 |
| iliv | are amd64 and armhf the only architecutre currently supported by build.snapcraft.io? | 14:17 |
| mvo | jdstrand: I see, thank you. so intead of the current PRs wait-for-all-profiles approach it would be snap run would trigger *just the current* profile? which would be a no-op if its current. and if snapd is not up snap run would still continue (to avoid it being in the criticial path)? | 14:19 |
| mvo | jdstrand: did I understand this correctly? | 14:19 |
| mvo | jdstrand: maybe its better to continue in the forum, let me write up something there | 14:20 |
| ogra | iliv, afaik yes ... you can mirror your branch to launchpad (with a regular scheduled auto-sync) to have the more exotic arches | 14:20 |
| iliv | also, there appears to be a problem with snap package installation example. once a package was built the page showed me this: "To test this snap on your PC or cloud instance: sudo snap install --edge iliv-test-0". Running this command results in "error: cannot install "iliv-test-0": snap not found". | 14:21 |
| jdstrand | mvo: yes. if snap run can call out to something that is able to regenerate the profiles without snapd, then yes-- snapd is out of the critical path, the normal case is snapd loaded everything and the lose the race case is handled | 14:22 |
| iliv | however, when I clicked on the green text link "Built and published", it took me to a page where the same command example was a little different: "sudo snap install --edge iliv-test-0 --revision=1". this works. | 14:22 |
| jdstrand | mvo: I am *not* saying that is required for 3441. I am saying that if 3441 did that, all concerns would be addressed. if it is in a future PR, I'd like that PR to be sooner than later so the concerns are addressed | 14:23 |
| mvo | jdstrand: this out-of-snapd profile handling is slightly tricky currently, we store a bunch of important information about this in the state.json and we do not support concurrent access to this currently | 14:23 |
| jdstrand | right-- I knew there was locking contention so certainly not blocking on that | 14:23 |
| mvo | jdstrand: thanks in update the forum now and then scratch my head a bit more over this | 14:24 |
| zyga_ | mvo: I was thinking about it | 14:24 |
| zyga_ | mvo: and perhaps we are OK | 14:24 |
| mvo | jdstrand: one more - the systemctl check could also be done inside snap-confine, the upside would be that it works reliable on 14.04 then, the downside that systemctl would be something we allow in the snap-confine apparmor profile. how do you feel about that? | 14:24 |
| zyga_ | mvo: the state is rewritten atomically | 14:24 |
| zyga_ | mvo: so a open fd + flock (shared) is sufficient to know that snapd is done updating and you see an atomic snapshot | 14:25 |
| zyga_ | mvo: in fact, even just fd | 14:25 |
| mvo | interessting | 14:25 |
| zyga_ | mvo: right? no flock needed | 14:26 |
| jdstrand | mvo: I don't feel great about that since snap-confine is setuid root. that means that if there is a problem with snap-confine, the user could potentially be able to access systemctl as root | 14:26 |
| zyga_ | mvo: snapd is the only writer | 14:26 |
| zyga_ | mvo: snapd does the rename | 14:26 |
| zyga_ | mvo: any reader can open state.json to see the snapshot | 14:26 |
| mvo | jdstrand: yeah, I have the same feeling, so lets go with the snap run approach | 14:26 |
| * zyga_ really goes to eat lunch | 14:27 | |
| zyga_ | but I'll be back :) | 14:27 |
| ogra | hehg, you had lunch at least two times already :P | 14:27 |
| zyga_ | except I didn't go :/ | 14:27 |
| zyga_ | I was working | 14:27 |
| ogra | yeah | 14:27 |
| ogra | go! | 14:27 |
| cachio_ | mvo, I see the postrm test is deleting /var/lib/snapd and it is making fail the restore | 14:27 |
| jdstrand | mvo: and to be crystal clear-- I really don't care about the implementation details of the profile loading so long as it is race free (not talking about systemctl here, but the forum topic where Gustavo and I never seemed to sync) | 14:28 |
| cachio_ | so the test postrm-purge is failing | 14:28 |
| jdstrand | mvo: so when I'm suggesting something on that topic, it is more ideas of what could be done rather than proposals of what should be done | 14:29 |
| niemeyer | jdstrand: I think you're downplaying it a bit, in the sense that "race free" is obviously a strict requirement of anything we do | 14:29 |
| mvo | jdstrand: ok | 14:29 |
| cachio_ | mvo, /var/lib/snapd | 14:29 |
| cachio_ | https://travis-ci.org/snapcore/snapd/builds/240775990#L4193 | 14:29 |
| jdstrand | niemeyer: it depends on what we are talking about as racing | 14:29 |
| jdstrand | niemeyer: profile loading at all vs profile loads that match the running snapd/snap-confine | 14:30 |
| niemeyer | jdstrand: What I said above is true for any accepted meaning of "race" in software development | 14:30 |
| cachio_ | mvo, did it change last days? I did not see this error before | 14:31 |
| jdstrand | niemeyer: ok, well then if we all agree that 'profile loads that match the running snapd/snap-confine' is what we want to get to, fantastic! it wasn't clear to me based on submitted PRs that was the case | 14:31 |
| cachio_ | mvo, and it is cause because of the cleanup that I did | 14:31 |
| mvo | cachio_: I don't think so, I'm curious what it is deleting that causes the problem | 14:31 |
| niemeyer | jdstrand: That's the key.. this is not just a race :) | 14:32 |
| niemeyer | jdstrand: But yes, that's the goal, and it's not solely about snap-confine or snapd either | 14:32 |
| niemeyer | jdstrand: The kernel also plays a role | 14:32 |
| jdstrand | sure | 14:32 |
| niemeyer | jdstrand: and the kernel is outside the control of anything internal to the system | 14:33 |
| niemeyer | jdstrand: The user can pick a different kernel to load behind the back of snapd | 14:33 |
| jdstrand | yep | 14:33 |
| niemeyer | jdstrand: Which makes the whole problem more delicate | 14:33 |
| jdstrand | sure | 14:33 |
| niemeyer | jdstrand: So, we'll need to introduce profile generation at boot because of that, at least in specific circumstances | 14:34 |
| cachio_ | mvo, well it is doing "rm -rf /var/lib/snapd" | 14:34 |
| jdstrand | niemeyer: and that is what I was saying about alignment-- I understand all that. I was saying we are aligned on the *goals* for where we want to be | 14:34 |
| jdstrand | even if we don't yet know the implementation | 14:34 |
| niemeyer | jdstrand: No, at least in that topic you did not understand | 14:34 |
| niemeyer | jdstrand: You specifically said we could generate the profile ahead of time in all cases | 14:34 |
| jdstrand | I was not considering the kernel the whole time, no, but when you mentioned it, I figured that is something that could be part of the whole thing | 14:35 |
| niemeyer | jdstrand: That's why the topic never ended in agreeement | 14:35 |
| jdstrand | fair enough | 14:35 |
| mvo | cachio_: I know its doing that :) snapd should be able to re-generate all files/dirs in there if any is missing, this is why I wonder why it is chocking | 14:35 |
| cachio_ | mvo, ah, ok | 14:36 |
| jdstrand | niemeyer, mvo: not sure why it took so long to sync on the goals this time around (sorry for my part in that), but I'm happy that we agree on the end goal. for my part in reviews, I'll keep that in mind | 14:38 |
| niemeyer | jdstrand: No problem, we should just have hopped into a hangout.. | 14:39 |
| jdstrand | niemeyer: yeah, it was funny cause it felt like we were getting close, then we darted away, then got close again, etc :) | 14:40 |
| jdstrand | still, that email thread did at least solidify what the goals are for everyone (even if it wasn't the most efficient means to get there) | 14:40 |
| mvo | jdstrand, niemeyer: thanks. I updated the forum with the approach for 3442 and the snap-geneate-profiles ideas we have so far | 14:41 |
| Chipaca | jdstrand: what needs happening for services that are type=notify to be able to do their notifyish thing? (currently getting a DENIED because of trying to sendmsg to /run/systemd/notify) | 14:41 |
| Chipaca | jdstrand: (is this on your radar at all) | 14:42 |
| jdstrand | Chipaca: it is not. if you point me at a PR/bug, I can take a look | 14:42 |
| jdstrand | Chipaca: I need to step away for a little bit (and then have a meeting), but can look after | 14:42 |
| Chipaca | ok | 14:42 |
| Chipaca | jdstrand: I'll probably not get around to doing the paperwork until tomorrow, fwiw | 14:44 |
| Chipaca | it's not a new breakage | 14:44 |
| niemeyer | mvo: Thanks for the update | 14:45 |
| mvo | niemeyer: I can make this branch much smarter my main question now is if we want it at all or if we should jump straight for the profile-regenerate helper | 14:46 |
| niemeyer | mvo: I'll add some notes in the forum | 14:48 |
| mvo | ta | 14:48 |
| mvo | cachio_: would be nice to get the systemctl status snapd.service output when this error happens | 14:56 |
| cachio_ | mvo, sure, I'll add it | 14:57 |
| ogra | mvo, is snapd actually re-creating the dir ? sems it comes in the deb with a lot of content actually | 14:57 |
| ogra | *seems | 14:57 |
| ogra | at least according to dpkg -L snapd | 14:57 |
| niemeyer | mvo: Sent | 15:02 |
| morphis_ | mvo, fgimenez: can one of you do a second review on https://github.com/snapcore/snapd/pull/3406/ ? | 15:04 |
| mup | PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 15:04 |
| fgimenez | morphis_: sure on it | 15:05 |
| morphis_ | fgimenez: awesome! | 15:05 |
| cachio_ | going to lunch | 15:05 |
| mvo | niemeyer: thank you, I will ponder over this | 15:06 |
| niemeyer | mvo: np, and thanks! | 15:10 |
| === ratliff_ is now known as ratliff | ||
| zyga_ | re | 15:21 |
| * zyga_ reads backlog | 15:21 | |
| mvo_ | niemeyer: I replied, if it sounds sensible I can start hacking on it. | 15:25 |
| zyga_ | cachio_: hey, did you see postrm-purge failures? | 15:27 |
| stgraber | kyrofa: around? | 15:27 |
| zyga_ | morphis_: one conflict on https://github.com/snapcore/snapd/pull/3406 | 15:28 |
| mup | PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 15:28 |
| ogra | stgraber, you got a sabrelite, right ? did you ever use it with HDMI attached with a recent 4.x kernel ? | 15:28 |
| stgraber | kyrofa: snapcraft is failing autopkgtest and is blocking LXD from being pushed to the release pocket | 15:29 |
| stgraber | kyrofa: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170608_070900_635cb@/log.gz | 15:29 |
| stgraber | kristbaum: AFAICT that's not LXD related so I'm about to push an archive hint to work around this | 15:29 |
| stgraber | ogra: I've got a wandboard (imx6 quadcore), but I use it as the LXC/LXD armhf buildd so it's never seen an hdmi display :) | 15:30 |
| ogra | yeah, thought so :) | 15:30 |
| niemeyer | mvo_: Thanks, I'll step out for lunch and ponder meanwhile | 15:31 |
| morphis_ | zyga_: can you merge https://github.com/snapcore/snapd/pull/3406/ now that we have two approvals? | 15:36 |
| mup | PR snapd#3406: tests,packaging: add package build support for openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3406> | 15:36 |
| zyga_ | morphis_: looking | 15:41 |
| zyga_ | morphis_: it has a conflict | 15:41 |
| morphis_ | narf | 15:41 |
| mup | PR snapcraft#1359 opened: tests: replace grub-doc with haskell-doc in build-packages tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1359> | 15:44 |
| kyrofa | stgraber, sorry for the delay, I am now | 16:01 |
| kyrofa | stgraber, we're on it | 16:03 |
| cachio_ | zyga, yes I saw that | 16:04 |
| cachio_ | zyga, we were discussing that with mvo | 16:04 |
| zyga | cachio_: aha, is this solved in master? should I merge and try again? | 16:05 |
| cachio_ | I am adding sthe snapd.service status | 16:06 |
| cachio_ | zyga, https://travis-ci.org/snapcore/snapd/builds/240775990#L4193 | 16:06 |
| cachio_ | this is the error | 16:06 |
| cachio_ | zyga, not sure why snapd is not creating this directory | 16:07 |
| zyga_ | cachio_: is this issue solved now, can I help somehow? | 16:12 |
| pedronis | Chipaca: what the's plan about my comment on your PR ? revert that bit? add a test? change the logic to do snapstate.Get first? | 16:12 |
| cachio_ | zyga_, it is not | 16:12 |
| zyga_ | ok | 16:12 |
| cachio_ | zyga_, I am making working on this one | 16:13 |
| cachio_ | zyga_, I'll ping you as soon as I have any info | 16:13 |
| Chipaca | pedronis: does it make sense for config to return a different error if trying to get something for which there is no snap? | 16:18 |
| === koza is now known as koza|away | ||
| Tribaal | Chipaca: so in relation to my article - can I ask you for a snappy question? | 16:31 |
| Tribaal | Chipaca: what is the best solution to put a simple file in /usr/share/backgrounds/ ? | 16:31 |
| Tribaal | Chipaca: right now I have something that's working -ish but it's a bit ugly in that it has classic confinement | 16:32 |
| Chipaca | Tribaal: right now, you don't | 16:32 |
| Tribaal | that's not going to be a great article then :) | 16:33 |
| pedronis | Chipaca: maybe, anyway that chaneg is also not backward compatible | 16:33 |
| pedronis | sorry maybe not | 16:34 |
| pedronis | Chipaca: maybe reverting that bit is the easiest until we have a reason to do something else | 16:35 |
| zyga_ | Tribaal: hey | 16:36 |
| zyga_ | Tribaal: I have code for that but it's not finished | 16:36 |
| pedronis | Chipaca: if you want to distinguish BadRequest vs InternalError there's, config.IsNoOption I think | 16:36 |
| pedronis | or something like that | 16:36 |
| zyga_ | Tribaal: I discussed this with jdstrand earlier, it will be a new interface and a new security backend | 16:36 |
| cachio_ | zyga_, this is the info I get when I run the status https://paste.ubuntu.com/24809011/ | 16:36 |
| Tribaal | zyga_: ah, that was my next attempt at code - writing a new interface | 16:36 |
| zyga_ | Tribaal: given that I'm busy on other things and there's an upcoming sprint I suspect the code for making this work will be mid july | 16:36 |
| zyga_ | Tribaal: it's not just a new interface | 16:36 |
| Chipaca | pedronis: right, IsNoOption is returned if the snap doesn't exist, or if it exists and isn't configurable, or if it exists, is configurable, and has no config set for that key | 16:37 |
| Tribaal | zyga_: was the interface you had in mind *just* for backgrounds, or did you think of a wider permission? | 16:37 |
| zyga_ | Tribaal: unless you are happy to jump into the frays of daily snapd development I'd recommend against it as it is unlikely to land | 16:37 |
| zyga_ | Tribaal: I was thinking of a wider system where snaps can provide content to the classic system | 16:37 |
| zyga_ | Tribaal: but it is not trivial, it involves several things that don't exist yet | 16:37 |
| zyga_ | cachio_: do you have more logs? | 16:38 |
| zyga_ | cachio_: what does systemd say? | 16:38 |
| * ogra would add a "journalctl -u snapd.service" | 16:38 | |
| pedronis | Chipaca: which seems the original intention of that code, you asked for the wrong thing (but I agree that's not the only failure mode, so check and InternalError otherwise) | 16:38 |
| ogra | to get that output | 16:38 |
| zyga_ | Tribaal: I have some initial code for that on my fedora workstation where I'm hacking on it, my goal is to provide the generic framework and an interface designed for shipping backgrounds | 16:38 |
| Chipaca | pedronis: fair 'nuf | 16:39 |
| Chipaca | pedronis: i'll get to it | 16:39 |
| Tribaal | zyga_: ok, so my end goal is to write a blog post about how to do the equivalent of another post I wrote using snaps. I'd like the comparaison to be favorable, so it's probably best for me to just wait for the way to be "clean" before I write anything | 16:39 |
| pedronis | Chipaca: thx | 16:39 |
| Chipaca | knee deep in other stuff right now, and close to eod | 16:39 |
| zyga_ | Tribaal: yes, I think you just need to wait, this is a new concept that snaps have traditionally not supported | 16:39 |
| pedronis | Chipaca: fwiw I didn't see that path, just spotted the NotFound on setConf | 16:40 |
| pedronis | which was sying snap not found | 16:40 |
| Tribaal | zyga_: ack | 16:40 |
| zyga_ | popey: big big hug for the wethr snap!!! | 16:43 |
| zyga_ | I love everything about it | 16:43 |
| zyga_ | popey: does it support any options? | 16:43 |
| ogra | like "--make-it-not-rain" ? | 16:44 |
| ogra | :) | 16:44 |
| zyga_ | ogra: only with sudo :DD | 16:44 |
| zyga_ | hehe | 16:44 |
| zyga_ | godo | 16:44 |
| ogra | :) | 16:44 |
| cachio_ | zyga_, it is getting stuck on the start | 16:50 |
| cachio_ | zyga_, https://paste.ubuntu.com/24809096/ | 16:53 |
| cachio_ | this is the log that I have | 16:53 |
| cachio_ | zyga_, error: fatal: directory "/var/lib/snapd" must be present | 16:58 |
| cachio_ | https://paste.ubuntu.com/24809119/ | 16:59 |
| cachio_ | mvo_, https://paste.ubuntu.com/24809119/ | 17:01 |
| cachio_ | mvo_, if I manually delete /var/lib/snapd | 17:02 |
| cachio_ | and restart snapd | 17:02 |
| cachio_ | it fails | 17:02 |
| cachio_ | mvo_, with the same error | 17:02 |
| ogra | yeah, as i said above, that dir is usually shipped with the deb | 17:02 |
| ogra | the postrm should instead do a rm -rf /var/lib/snapd/* | 17:03 |
| ogra | so only content gets removed | 17:03 |
| ogra | the dir would go away anyway if the deb is removed | 17:03 |
| Chipaca | hah! found a bug in getSnapConf because i dared to write a test for it :-D | 17:04 |
| cachio_ | ogra, ok | 17:06 |
| ogra | (or alternatively snapd should do a mkdir on startup if the dir doesnt exist) | 17:07 |
| cachio_ | it seems to be better | 17:07 |
| cachio_ | mvo_, zyga_ your opinion is welcome :) | 17:08 |
| cachio_ | niemeyer, your too | 17:09 |
| mup | PR snapcraft#1360 opened: cli: stop leaking green text <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1360> | 17:20 |
| Chipaca | pedronis: I think that should do it (let me know if I got it wrong _again_) | 17:31 |
| * Chipaca EOD | 17:31 | |
| mup | PR snapcraft#1359 closed: tests: replace grub-doc with haskell-doc in build-packages tests <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1359> | 17:32 |
| cachio_ | niemeyer, there? | 17:42 |
| niemeyer | cachio_: Yep | 17:48 |
| cachio_ | niemeyer, there is an issue with the snapd.postrm scrnpt | 17:49 |
| cachio_ | it is doing "rm -rf /var/lib/snapd" | 17:49 |
| niemeyer | cachio_: Oh? | 17:49 |
| niemeyer | cachio_: Well, that by itself is not an issue | 17:49 |
| cachio_ | and then if I do systemctl start snapd.service | 17:50 |
| cachio_ | niemeyer, we get this https://paste.ubuntu.com/24809119/ | 17:50 |
| cachio_ | not sure why this test could not be reproduced before | 17:51 |
| niemeyer | cachio_: We need some more context.. it doesn't make sense to purge the snap and then start it | 17:51 |
| cachio_ | niemeyer, make sense that, so I should fix postrm-purge test | 17:52 |
| cachio_ | because after the clean of environment variables was merged, this test started to fail | 17:53 |
| cachio_ | niemeyer, in ci | 17:53 |
| niemeyer | cachio_: It would be good to understand what's going on there.. | 17:53 |
| niemeyer | cachio_: Why was it not failing before? | 17:53 |
| niemeyer | cachio_: The lack of understanding in those cases generally means we're not seeing the whole picture | 17:54 |
| cachio_ | niemeyer, agree, I would take a look to the last code merge in the master before this restore was merged | 17:55 |
| cachio_ | niemeyer, something has to be changed in the master between the last rebase I did against the master and the moment it was merged | 17:56 |
| niemeyer | cachio_: Yeah, perhaps related to the Fedora changes, which were quite spread out | 17:57 |
| niemeyer | cachio_: Still, the outcome seems a bit surprising.. that doesn't seem related to the environment | 17:57 |
| cachio_ | niemeyer, it is not, do you have a convention for the tests about how should the the snapd state after the restore? | 17:59 |
| cachio_ | niemeyer, because I see snapd is reseted in the prepare | 18:00 |
| cachio_ | niemeyer, but some tests like the postrm-purge are leaving snapd in a bad state | 18:00 |
| cachio_ | niemeyer, no, not sure if I need to fix this test to leave snapd working, or I just move the environment variables clean up to the reset | 18:01 |
| niemeyer | cachio_: We restore a number of things, such as the core snap and the entire snapd state via that tarball which you have probably passed by | 18:24 |
| niemeyer | cachio_: These are the things tests don't need to care about | 18:24 |
| cachio_ | niemeyer, ok, in that case I'll move the environment variables restore to the reset where the snapd state is restored | 18:25 |
| niemeyer | cachio_: Sounds sensible.. I even assumed that was happening as part of the tarball | 18:25 |
| cachio_ | niemeyer, in the tarball is being saved /etv/environment | 18:26 |
| cachio_ | but also I am cleaning up the systemd unit directories | 18:26 |
| cachio_ | because some tests are creating files with environment variables to be used by the systemd unit on there | 18:27 |
| cachio_ | this part is being done suring the restore of the test | 18:27 |
| cachio_ | to leave the systemd configuration as it was received | 18:28 |
| niemeyer | Ah, nice | 18:29 |
| cachio_ | zyga_, there= | 18:32 |
| cachio_ | ? | 18:32 |
| zyga | yes | 18:32 |
| cachio_ | about the reexec issue | 18:32 |
| cachio_ | in the prepare.sh prepare_each_classic | 18:33 |
| cachio_ | do you know why it is being created this reexec.conf file | 18:33 |
| cachio_ | ? | 18:33 |
| cachio_ | if then snapd service is not restarted? | 18:34 |
| zyga | cachio_: let me look | 18:34 |
| cachio_ | it is wird | 18:34 |
| cachio_ | weird | 18:34 |
| zyga | cachio_: no idea, I just had a look at it, maybe check git log or ask federico in the morning | 18:35 |
| zyga | cachio_: I was thinking that perhaps we should revert whatever change broke master | 18:36 |
| cachio_ | zyga something changed during the last days, after I did the last rebase and before the envinroment cleanup cranch was landed | 18:37 |
| cachio_ | zyga, becasuse the tests were not failing or the branch | 18:37 |
| cachio_ | zyga, I can do a mkdir in the restore of the postrm-purge to make that test pass leaving a comment and create a bug to fix | 18:40 |
| zyga | cachio_: let's do it | 18:46 |
| cachio_ | zyga, where should I create the issue? in the forum or in launchpad? | 18:47 |
| zyga | cachio_: just make a PR :) | 18:47 |
| zyga | cachio_: and let's get it fixed tomorrow as well | 18:47 |
| zyga | cachio_: I think nothing creates /var/snap today | 18:47 |
| zyga | cachio_: if you want to discuss this a forum topic is the best, it works way better than bug trackers | 18:48 |
| * zyga will be back later | 18:59 | |
| cachio_ | zyga_, when you have a minute, PR 3448 | 19:54 |
| cachio_ | zyga_, this is to fix the error in master | 19:54 |
| mup | PR snapd#3448 opened: tests: fix for the test postrm-purge <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3448> | 19:55 |
| === JanC_ is now known as JanC | ||
| ssbash | hi | 21:29 |
| ssbash | does anyone here have experience building python snaps for large python projects? | 22:04 |
| Chipaca | ssbash: only a small python thing, myself | 22:21 |
| ssbash | I'm having trouble getting my pythong packages to build as wheels | 22:24 |
| ssbash | python-packages: [lockfile==0.12.2, lxml==3.6.4, msgpack-python==0.4.8, pexpect==4.2.1, psutil==5.0.0, pyshark==0.3.6.1, requests==2.12.2, xmltodict==0.9.2, bottle==0.10.2, ecdsa= =0.13, rsa==3.4.2, pyOpenSSL==16.2.0, pygtail==0.7.0, python-dateutil==2.6.0, beautifulsoup 4==4.5.1, robobrowser==0.5.3, pytest==3.0.4, pytest-cov==2.4.0] | 22:24 |
| ssbash | this is what i have in my snapcraft.yaml file | 22:24 |
| popey | maybe paste your yaml at http://paste.ubuntu.com/ | 22:25 |
| ssbash | http://paste.ubuntu.com/24811130/ | 22:28 |
| ssbash | thats my yaml file ^ | 22:28 |
| Chipaca | ssbash: some of those specifiers seem wrong | 22:34 |
| Chipaca | e.g. the beautifulsoup one | 22:34 |
| Chipaca | ssbash: see if this fares better: http://pastebin.ubuntu.com/24811186/ | 22:35 |
| Chipaca | popey: ^ cleaned it up a little | 22:35 |
| Chipaca | ssbash: (just to be clear, I don't know if this is right, i've never used python-packages in snapcraft.yaml) | 22:36 |
| ssbash | are you allowed to list packages like that? the documentations refers to a list https://snapcraft.io/docs/reference/plugins/python | 22:37 |
| === cpaelzer_ is now known as cpaelzer | ||
| popey | i think it's syntactically valid | 22:39 |
| Chipaca | ssbash: yes, both are valid yaml | 22:39 |
| Chipaca | ssbash: when it's short, the inline one is arguably better | 22:40 |
| popey | ssbash: it's a bit late here, I'd recommend posting to http://forum.snapcraft.io/ - you'll get more visibility there tbh | 22:40 |
| Chipaca | ssbash: but as soon as it gets long it's unreadable | 22:40 |
| ssbash | ah i see | 22:40 |
| Chipaca | yeah, i'm only up because elections | 22:40 |
| ssbash | thanks for your help, I'll see if it works now | 22:40 |
| Chipaca | ssbash: I thought I'd try running this locally but it asks me for a bitbucket account and stuff | 22:41 |
| Chipaca | ¯\_(ツ)_/¯ | 22:41 |
| ssbash | yea unfortunately i can't share the code, its a private repo | 22:41 |
| Chipaca | no worries | 22:42 |
| Chipaca | let me know if it works (if i'm still around) | 22:42 |
| Chipaca | ssbash: if in doubt about yaml, I've found http://yaml-online-parser.appspot.com/ very useful | 22:43 |
| cachio_ | Chipaca, if you have 1 minute to check this https://github.com/snapcore/snapd/pull/3448 | 22:52 |
| mup | PR snapd#3448: tests: fix for the test postrm-purge <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3448> | 22:52 |
| cachio_ | this is to fix a problem in the master | 22:52 |
| Chipaca | cachio_: I'm eagerly waiting for it to go green | 22:52 |
| Chipaca | as the problem in master is blocking a branch of mine :-) | 22:53 |
| Chipaca | 838/842, should be done soon | 22:53 |
| Chipaca | and no error yet :-) | 22:53 |
| cachio_ | Chipaca, great, final version is running | 22:53 |
| cachio_ | Chipaca, Successful tasks: 842 :) | 22:56 |
| Chipaca | cachio_: +1'ed, and a vote to merge as is | 22:58 |
| Chipaca | cachio_: (also a diatribe on logs because typing is cheap) | 22:59 |
| cachio_ | Chipaca, awesome | 23:00 |
| cachio_ | Chipaca, so, this is going to be merged once all the tests pass? | 23:03 |
| Chipaca | cachio_: I think it's fine to merge right now, but it's your call -- you're the one that'll be left holding the pieces if it breaks :-) | 23:04 |
| cachio_ | Chipaca, just wait until all the tests pass | 23:05 |
| ssbash | Chipaca I was able to fix my issue, i was missing my libffi package | 23:16 |
| Chipaca | ssbash: ah, ok | 23:16 |
| mup | PR snapcraft#1358 closed: release changelog for 2.31 <Created by sergiusens> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1358> | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!