| === zarcade_droid is now known as Guest19897 | ||
| === devil is now known as Guest39994 | ||
| === ShibaInu is now known as Shibe | ||
| mup | Bug #1761363 opened: Add interface to access to Zeitgeist <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1761363> | 03:04 |
|---|---|---|
| mborzecki | morning | 04:57 |
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 05:11 |
| mup | PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 05:11 |
| mup | PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 05:11 |
| mup | PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 05:12 |
| mup | PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 05:12 |
| mup | PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 05:12 |
| === devil is now known as Guest38148 | ||
| mup | PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 05:59 |
| mup | PR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 05:59 |
| mup | PR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 05:59 |
| mup | PR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11> | 06:00 |
| mup | PR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22> | 06:00 |
| mup | PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26> | 06:00 |
| mvo | good morning | 06:14 |
| mborzecki | mvo: morning | 06:22 |
| mvo | mborzecki: hey! how are you? anything interessting happend in the early morning? | 06:22 |
| mborzecki | mvo: nope, casually browsing through reviews | 06:23 |
| mborzecki | mvo: any leads on the mounting thing from yesterday? | 06:23 |
| mvo | mborzecki: yes, the reason was eventually figured out by zyga and pedronis. there is some connection related state we only keep in memory and when snapd restarts this state is lost so we need to store more in the state | 06:25 |
| mborzecki | nice | 06:26 |
| zyga | Hey ho | 06:27 |
| mvo | mborzecki: there are some complications apparently, I did not follow all the details | 06:27 |
| zyga | Sorry for being late. I had to sleep longer | 06:28 |
| mborzecki | zyga: hey | 06:28 |
| mvo | mborzecki: I think we need to revert, cachio did a great deal of testing and we think its safe | 06:28 |
| zyga | Well. Had to sleep | 06:28 |
| mvo | zyga: no worries, same here | 06:28 |
| zyga | Coffee, walk the dog, then coding | 06:29 |
| zyga | We need new top-level structure in the state to fix the issue | 06:29 |
| zyga | I can explain why when I am at my desk | 06:30 |
| mup | PR snapd#4971 closed: errtracker: add more fields to aid debugging <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4971> | 06:33 |
| mup | PR snapd#4985 opened: errtracker: add more fields to aid debugging <Created by mvo5> <https://github.com/snapcore/snapd/pull/4985> | 06:36 |
| === Mirv_ is now known as Mirv | ||
| pedronis` | hi | 06:59 |
| === pedronis` is now known as pedronis | ||
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings | 07:00 |
| pedronis | mvo: hi, don't know if you saw the logs but we have both a very specific issue with the snapctl socket, but also likely a general issue with all operations on a snap at the same time we operate on its base (if the op involves running things like hooks or starting services) | 07:06 |
| kalikiana | buenos dias | 07:06 |
| mborzecki | 2018-04-05 09:09:46 Preparing google:arch-64 (google:arch-64 (apr050907-716531))... yay! | 07:10 |
| zyga | Hey Pedronis, good morning | 07:11 |
| pstolowski | morning zyga | 07:14 |
| mvo | pedronis: aha, no, I did miss this part of the conversation | 07:15 |
| mvo | good morning pstolowski, did you see my test run from last night? | 07:15 |
| pstolowski | mvo: yes, thank you | 07:15 |
| pedronis | pstolowski: afaiu is because of the placement , being after setup-profiles is too early for those tasks | 07:16 |
| mvo | pstolowski: I have the system still in this state, I can do another run to see if it consistent, but I wanted to keep it for now in case there is anything that might help understanding it | 07:16 |
| pedronis | pstolowski: doInstall puts them after link-snap | 07:17 |
| pstolowski | pedronis: mvo yep, i saw your comments on irc yesterday, investigating this | 07:17 |
| pstolowski | pedronis, mvo is it possible to install lxd as the first snap and force core from edge? | 07:17 |
| pedronis | pstolowski: not with the stable deb, not really, you could use the enterprise proxy locally, except that the stable deb doesn't support it | 07:19 |
| pedronis | pstolowski: mvo: as I said, maybe we should add a envvar to control the channel from which we get core (or any base), but that will only help this sort of testing going forward | 07:20 |
| pedronis | mvo: should we do a HO in a bit to see where we are, we need a bit to decide which bugs needs fixing for 2.32.x and which can wait | 07:21 |
| mvo | pedronis: sounds good | 07:21 |
| mvo | pedronis: we need to wait for zyga too | 07:24 |
| pstolowski | mvo: how exactly did you provoke the errnostate? | 07:25 |
| mup | PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 07:25 |
| mup | PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 07:25 |
| pstolowski | HO sounds good | 07:25 |
| zyga | and back now | 07:26 |
| zyga | I can have a call | 07:26 |
| mup | PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38> | 07:26 |
| mup | PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83> | 07:26 |
| mvo | pstolowski: so it seems the fix for the inject task is to put the auto-connect a bit later (after link-snap) - thats my naive view at least - or do you think there is more too it? | 07:29 |
| pstolowski | mvo: just trying to trigger the problem with edge from core atm but unclear how | 07:30 |
| mvo | pstolowski: what I did yesterday is essentially: 1. git checkout upstream/release/2.29 2. modify it so that defaultBaseSnapsChannel is "edge" 3. sudo systemctl stop snapd snapd.socket && go build && sudo ./snapd && sudo systemctl start snapd 4. snap install lxd | 07:32 |
| mvo | pstolowski: with an empty state of course | 07:32 |
| mvo | pstolowski: e.g. on 17.10 apt purge snapd first and then install it | 07:32 |
| * zyga is in the standup HO | 07:32 | |
| mvo | pstolowski: https://paste.ubuntu.com/p/BxmxD3VFCD/ contians a rough outline of the above including the diff I used | 07:32 |
| mvo | pstolowski: trouble is of course that you cannot test anything local wit hthat method, only testing after it landed in edge :( | 07:33 |
| pstolowski | mvo: thanks (in HO too) | 07:33 |
| Chipaca | moin moin | 07:53 |
| mborzecki | sometimes i hate pacman -Syu vs -Sy when installing packages :/ | 08:10 |
| Chipaca | mborzecki: what's the difference? | 08:12 |
| Chipaca | mvo: did you see the (fleeting) PR about dropping privileges, yesterday? | 08:12 |
| mvo | Chipaca: I did but didn't look, sorry | 08:12 |
| Chipaca | mvo: no worries, it didn't work :-) | 08:12 |
| === cpaelzer_ is now known as cpaelzer | ||
| mvo | Chipaca: haha | 08:13 |
| Chipaca | mvo: but, thing is, there's a bug that that pr was trying to fi | 08:13 |
| Chipaca | fix* | 08:13 |
| Chipaca | mvo: (FWIW the approach tehre would work from Go 1.10 on! so let's go there someday) | 08:13 |
| mborzecki | Chipaca: `-Syu foo` does a full system ugprade and installs foo, just doing `-Sy foo` will install foo but if its dependencies are already installed they will not get updated, which in turn may or may not hurt you badly | 08:13 |
| Chipaca | mvo: https://bugs.launchpad.net/snapd/+bug/1761193 | 08:13 |
| mup | Bug #1761193: ~/.snap/ not available for root on some systems <snapd:New> <https://launchpad.net/bugs/1761193> | 08:13 |
| mborzecki | still don't get why it's so hard to record versioned library dependencies | 08:13 |
| Chipaca | mvo: so... I could change the code to use 'su' to touch that file, but it feels icky | 08:15 |
| mvo | Chipaca: in a meeting right now, let me get back in a bit | 08:15 |
| Chipaca | mvo: yeah no worries, i'll brain dump and you read and respond when you're able | 08:15 |
| mvo | +1 | 08:15 |
| Chipaca | mvo: the ops we need to do on the file are read, write, and remove. 'su'ing to cat and rm works. The other approach is to use cgo, and do the setuid/setgid in a C thread we manage ourselves. I have tested neither of these approaches, and both seem rather unpalatable, so I think I'd go with the less sophisticated one =) | 08:18 |
| Chipaca | mvo: <end dump> i think :-) | 08:19 |
| Chipaca | or we could move to go 1.10 \o/ | 08:19 |
| Chipaca | mborzecki: that manpage looks terrifying =) | 08:23 |
| mborzecki | Chipaca: pacman? | 08:24 |
| Chipaca | yeah | 08:24 |
| zyga | that was a nice case of internet counselling session | 08:24 |
| Chipaca | zyga: ? | 08:24 |
| Chipaca | zyga: BTW thank you once again for having your lab machines; last night I was able to help a customer thanks to that | 08:25 |
| zyga | Chipaca: woot! | 08:25 |
| zyga | Chipaca: that's awesome, let me know if I can expand it to be more useful in some way | 08:25 |
| zyga | Chipaca: ask mvo about how we're doing :) | 08:26 |
| Chipaca | zyga: oh, your counselling session was the same as mvo's meeting? | 08:26 |
| zyga | yes :D | 08:26 |
| mvo | Chipaca: reading now, thanks for tackling this issue! | 08:31 |
| mvo | Chipaca: +1 for su - even though it feels fugly | 08:32 |
| === zarcade_droid is now known as Guest26743 | ||
| Chipaca | mvo: ok | 08:33 |
| mvo | Chipaca: what exactly do we need to do to that file? we need to append (and create if needed) and remove? | 08:33 |
| Chipaca | mvo: and read | 08:33 |
| Chipaca | mvo: not append, i think -- just create, read and remove | 08:34 |
| mvo | Chipaca: ok | 08:34 |
| Chipaca | mvo: another approach would be to not report the error to the user, ie any error on reading the file gets ignored | 08:35 |
| Chipaca | mvo: but that will make it hard to debug | 08:35 |
| Chipaca | I'll take a stab at using su, let's see how it goes :-) | 08:36 |
| mvo | Chipaca: thank you | 08:37 |
| mvo | Chipaca: we could also have helper that does the things we need doing and we just spawn that with su. but yeah, I'm sure it is interessting | 08:38 |
| Chipaca | mvo: that actually better than cat and rm, i'll do that | 08:39 |
| Chipaca | mvo: (to be clear, it's better because the 'write' case is hard to do properly otherwise) | 08:43 |
| * mvo nods | 08:43 | |
| jlorenzo | hi there! | 08:49 |
| jlorenzo | I have a quick question about the snap store | 08:49 |
| jlorenzo | is snapcraft 2.39.2 still supported by the store? | 08:50 |
| jlorenzo | (I'm trying to push and release a snap with this version) | 08:50 |
| * jlorenzo sees 2.40.x is still marked as pre-version https://github.com/snapcore/snapcraft/releases | 08:56 | |
| jlorenzo | is anybody aware of a server-side change that produces blank errors like this one https://tools.taskcluster.net/groups/GYT_nZNyQzGn7wjcwBTajw/tasks/fFIauoJaQQCFAYJVeQqheg/runs/0/logs/public%2Flogs%2Flive_backing.log#L892 ? | 08:57 |
| zyga | kalikiana: ^ | 09:00 |
| popey | snap refresh foo --amend seems to have broken for me recently | 09:01 |
| popey | I get error: cannot communicate with server: Post http://localhost/v2/snaps/mame: EOF | 09:01 |
| popey | that kind of thing every time I try and refresh a local snap into the store | 09:01 |
| popey | running snapd 2.32.2 | 09:02 |
| popey | pretty sure flexiondotorg also had the same issue | 09:07 |
| flexiondotorg | Yes, I've seen that --amend isn't working yesterday. | 09:09 |
| mvo | let me look | 09:09 |
| mborzecki | am i missing something or is this check exactly the same as one below https://github.com/snapcore/snapd/blob/master/tests/main/manpages/task.yaml#L14 ? | 09:13 |
| mvo | popey: I just tried with hte hello snap and snap refresh --amend worked for me, what snaps are you using? | 09:18 |
| popey | I tried with a few, mame for example and signal-desktop, which I'd built locally then pushed to the store | 09:19 |
| mup | PR snapd#4985 closed: errtracker: add more fields to aid debugging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4985> | 09:21 |
| mvo | popey: thanks, I will try harder then | 09:27 |
| mvo | popey: aha! signal-desktop reproduces it | 09:29 |
| popey | \o/ | 09:30 |
| mvo | popey: I think its because its not in stable, obviously a bug and I think I know what it is | 09:33 |
| popey | ooh, interesting | 09:33 |
| popey | (I did pass --beta) fwiw | 09:33 |
| mvo | popey: yeah, this is not passed to the right place unfortunately | 09:35 |
| mvo | popey: so two things to fix: not crash, pass channel | 09:35 |
| popey | ok. thanks | 09:37 |
| popey | shall i file a bug? | 09:37 |
| kalikiana | jlorenzo: Hmmm haven't seen that before. Looking | 09:40 |
| jlorenzo | kalikiana: thanks! Last time I saw the same error was when we were using snapcraft 2.25. Back then, Ken VanDine told me to upgrade to the latest version, which solved it | 09:43 |
| mvo | popey: either way is fine, I have a fix locally, just need to write proper tests for it | 09:46 |
| popey | https://bugs.launchpad.net/snapd/+bug/1761435 | 09:47 |
| mup | Bug #1761435: Can't refresh some local snaps to store snaps with --amend <snapd:New> <https://launchpad.net/bugs/1761435> | 09:47 |
| popey | diddledan: I'm running irccloud-desktop from edge, yay! Thanks! | 10:05 |
| popey | diddledan: I have fixed the icon (changed 512x512 to 256x256 should do it) and will check the next build when it comes out. If fixed we shoul push to stable, right? | 10:10 |
| zyga | mvo: back to hacking hten | 10:12 |
| mborzecki | got a weird problem with arch and spread tests that use dbus, when we install a snap eg test-snapd-network-status-provider, those will generate dbus policy files, then the test fails because the provider service is denied owning the name on the bus, the only way to fix it is to systemctl reload dbus.service | 10:27 |
| mborzecki | now the questions are, why does it work elsewhere and should we reload the service automatically? | 10:28 |
| mvo | mborzecki: hm, afaik the daemon does a inotify watch on the dirs where we drop files | 10:35 |
| mvo | mborzecki: but maybe there is a config file in your case missing, let me double check | 10:35 |
| mvo | mborzecki: what is the dir? | 10:36 |
| mvo | mborzecki: no, there is no config file we use so it ought to work | 10:37 |
| mborzecki | mvo: /etc/dbus-1/system.d | 10:39 |
| mborzecki | mvo: weird, i see --enable-inotify passed explicitly to dbus configure | 10:40 |
| mvo | mborzecki: this is on arch? or a more general problem? maybe its not monitoring that dir for some strange reason on arch | 10:40 |
| mborzecki | mvo: it's on arch, there's a couple of tests failing because of this | 10:40 |
| mborzecki | hmm similar issue reported for avahi https://bugs.archlinux.org/task/55738 | 10:46 |
| mup | PR snapd#4986 opened: snapstate: fix `snap refresh --amend` when the snap is not available in stable <Created by mvo5> <https://github.com/snapcore/snapd/pull/4986> | 10:50 |
| pedronis | mvo: I changed the code in this ^ one in my new api work | 10:52 |
| mvo | pedronis: oh, cool, I can run my test on the new PR to see if it fully fixes it | 10:56 |
| mvo | pedronis: or base a new fix on top of your new-api work | 10:56 |
| mvo | pedronis: also - I need to finish that review :/ sorry for letting you wait for so long | 10:56 |
| pedronis | mvo: I think it should be fixed, because there is not more snapNameToID | 10:57 |
| mvo | pedronis: neato, I will run my updated test to double check. that test is useful in any case | 10:58 |
| pedronis | mvo: in the new world amend is an install, not a refresh | 11:00 |
| pedronis | talking to the store at least | 11:00 |
| pedronis | pstolowski: how it's going? | 11:01 |
| mvo | pedronis: thanks, test is running now, I will either debug or push a PR with the updated test (I think its good to excercise the != stable path) | 11:02 |
| pstolowski | pedronis: almost there i think; i've added similiar inject code into doLinkSnap for snap!=core, restricted the one in doSetupProfiles to core snap-phase2 only. what's missing is restricting link-snap more | 11:05 |
| pstolowski | adjusted the tests, all passing atm | 11:05 |
| pedronis | thanks | 11:06 |
| zyga | pedronis: I'm working on the state changes, I will have some skeleton to review soon | 11:12 |
| mup | PR snapd#4987 opened: tests: add test to ensure `snap refresh --amend` works with different channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/4987> | 11:18 |
| Chipaca | zyga: did you say yesterday that the userd unit test panics? | 11:23 |
| zyga | yep | 11:24 |
| Chipaca | zyga: did you resolve that? | 11:24 |
| zyga | nope | 11:24 |
| zyga | it's been that for months | 11:24 |
| Chipaca | oh? | 11:24 |
| Chipaca | it hasn't -- i've been running the full test suite and it passed | 11:24 |
| zyga | https://www.irccloud.com/pastebin/qKbODxHV/ | 11:24 |
| zyga | no idea | 11:24 |
| zyga | it happens for me for _some_ reason | 11:24 |
| Chipaca | but maybe there's a missing dep that i had on my other machine that's missing here | 11:24 |
| Chipaca | jamesh: you around? | 11:25 |
| pedronis | mvo: so seems the new code deals better with --amend (it's more regular, not extra calls, so not unexpected) | 11:25 |
| mborzecki | mvo: i think i know what's happening, there's no /etc/dbus-1/system.d on clean install because arch does not like empty dirs, so if dbus calls intify_add_watch(.., "/etc/dbus-1/system.d"..) it will fail and the error probably gets swallowed | 11:25 |
| pedronis | mvo: but yes we need to decide what to do about 4900 and get it at least on master soon, if we need to prepare the cherry-pick for 2.32.4 | 11:26 |
| mborzecki | standup is at 3pm right? | 11:31 |
| zyga | I think so | 11:37 |
| pstolowski | mborzecki: yes | 11:37 |
| mup | PR snapd#4988 opened: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988> | 11:45 |
| mborzecki | cachio: i'm close to having all of the tests passing on arch (all of those that can run ofc) | 11:45 |
| pstolowski | pedronis, mvo https://github.com/snapcore/snapd/pull/4988 | 11:47 |
| mup | PR #4988: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988> | 11:47 |
| cachio | mborzecki, great news | 11:48 |
| cachio | mborzecki, I am working on the script to update that image | 11:49 |
| cachio | mborzecki, it should be ready today | 11:49 |
| cachio | zyga, hey, should we unblock this one right? https://github.com/snapcore/snapd/pull/4832 | 11:51 |
| mup | PR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832> | 11:51 |
| zyga | cachio: please see comment from mborzecki there | 11:51 |
| zyga | oh, not there perhaps | 11:51 |
| zyga | we need 7 more days | 11:51 |
| zyga | before the package propagates | 11:52 |
| mborzecki | yup | 11:52 |
| zyga | https://github.com/snapcore/snapd/pull/4980 | 11:52 |
| mup | PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <https://github.com/snapcore/snapd/pull/4980> | 11:52 |
| cachio | zyga, ah, ok | 11:52 |
| zyga | so next week | 11:52 |
| mborzecki | idk if voting speeds up the process | 11:52 |
| zyga | I think so | 11:52 |
| jlorenzo | kalikiana: do you want me to file a bug in https://bugs.launchpad.net/snapstore, in the meantime? | 11:53 |
| kalikiana | jlorenzo: Yes, please. Sorry for my delayed response. I narrowed this down in the code but still need to confirm the actual cause. | 11:54 |
| jlorenzo | np! | 11:54 |
| pedronis | pstolowski: lgtm, comment could say more about placement | 11:59 |
| pedronis | left some notes | 11:59 |
| pedronis | in the PR | 11:59 |
| Chipaca | is the standup now, or later, today? | 12:00 |
| pedronis | later | 12:00 |
| Chipaca | ok :) | 12:01 |
| mborzecki | off to pick up the kids from school, bb for standup | 12:02 |
| jlorenzo | kalikiana: https://bugs.launchpad.net/snapstore/+bug/1761488 | 12:03 |
| mup | Bug #1761488: snapcraft 2.39.2 failed to release a snap: snapcraft.storeapi.errors.StoreReleaseError: <exception str() failed> <Snap Store:New> <https://launchpad.net/bugs/1761488> | 12:03 |
| pstolowski | pedronis: thanks | 12:03 |
| === pstolowski is now known as pstolowski|lunch | ||
| * zyga is super sleepy, needs coffee | 12:05 | |
| pedronis | zyga: btw I was thinking that the fix for the issue will have interactions with the double setup-profiles we do for core | 12:06 |
| pedronis | zyga: we basically do AddSnap twice for core but it works because in the old world we restart in the middle | 12:07 |
| zyga | mmm, but is that an issue, all we will record is the revision then | 12:07 |
| pedronis | zyga: well you said we cannot do AddSnap twice | 12:07 |
| pedronis | now we will do at restart and then again in the 2nd setup-profiles | 12:08 |
| pedronis | which will fail? | 12:08 |
| zyga | I don't think it will, setup profiles removes the snap and adds it again | 12:08 |
| zyga | this essentially refreshes the state of the repo | 12:08 |
| zyga | this is in helpers.go in ifacemgr | 12:08 |
| zyga | one sec | 12:08 |
| pedronis | ah, it does remove? | 12:09 |
| zyga | yes | 12:09 |
| pedronis | and that doesn't fail if the snap is not there? | 12:09 |
| zyga | to have consistent view of that snap for setpu | 12:09 |
| zyga | I don't know | 12:09 |
| zyga | but I don't suppose so | 12:09 |
| zyga | https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L175 | 12:09 |
| zyga | looking at remove snap now | 12:10 |
| pedronis | remove never fails | 12:10 |
| pedronis | that's good | 12:10 |
| zyga | https://github.com/snapcore/snapd/blob/master/interfaces/repo.go | 12:10 |
| zyga | it only fails if the thing is connected, which is shouldn't be | 12:10 |
| zyga | so it's good | 12:10 |
| zyga | we disconnect the snap as well | 12:10 |
| zyga | https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/handlers.go#L169 | 12:11 |
| zyga | just prior to calling remove snap | 12:11 |
| zyga | I think we are good | 12:11 |
| === ahasenac` is now known as ahasenack | ||
| === ahasenack is now known as Guest7888 | ||
| * zyga explores how the state access works and how the raw json messages behave | 12:16 | |
| pedronis | zyga: mmh, maybe we don't new state | 12:24 |
| zyga | ohhh? | 12:24 |
| pedronis | zyga: we always do setup-profiles -> link-snap (this make sense because setup-profiles is the "activating" of the ifacestate world) | 12:25 |
| zyga | pedronis: and? | 12:29 |
| pedronis | zyga: so we are interested in all active snaps, and all snaps with a pending (not ready) link-snap that is waiting on a done setup-profiles | 12:29 |
| pedronis | the revision in the sna-setup of those tasks | 12:29 |
| zyga | so we could look through the state and fish that | 12:29 |
| pedronis | yes | 12:29 |
| pedronis | it has it's pro and cons as usual | 12:30 |
| zyga | but who would do this? the interface repo on startup | 12:30 |
| zyga | or setup profiles? | 12:30 |
| zyga | or snap manager | 12:30 |
| zyga | feels cross-manager | 12:30 |
| * zyga finds working with state to be hard | 12:30 | |
| zyga | the get/set marshal/unmarshal | 12:30 |
| pedronis | just done as a replacement of ActiveInfos | 12:30 |
| zyga | the raw messages | 12:30 |
| pedronis | SnapsWithProfiles | 12:31 |
| zyga | ah, that makes sense | 12:31 |
| pedronis | it would break if we started putting stuff between setup-profiles and link-snap | 12:31 |
| pedronis | but I would question such a move | 12:31 |
| === Guest7888 is now known as ahasenack | ||
| zyga | I'll play with the state variant first | 12:36 |
| zyga | but I think your solution is better for upgrades | 12:36 |
| zyga | it would have 0 "borken" moments | 12:36 |
| * kalikiana lunch | 12:37 | |
| zyga | *broken | 12:37 |
| pedronis | yea, the state solution and revert worry me a bit | 12:37 |
| pedronis | not because problems are likely but if they appear they will be very confusing | 12:37 |
| zyga | yes, it feels like something that would warrant epoch | 12:38 |
| zyga | and epochs and customers are another thing | 12:38 |
| pedronis | when we are more tools and time we can explore the idea of a more generalized concept of readiness | 12:40 |
| pedronis | and then we could use that instead of looking at changes | 12:41 |
| pedronis | s/are more/have more/ | 12:41 |
| pedronis | but looking at changes seems attractive if a bit delicate, right now | 12:41 |
| pedronis | zyga: I'm exploring a bit how that would look like | 12:57 |
| jdstrand | popey: hey, do you know if the remmina developer hangs out here? | 12:59 |
| jdstrand | popey: or where the remmina snap developer can be found? | 13:00 |
| === pstolowski|lunch is now known as pstolowski | ||
| zyga | pedronis: standup? | 13:01 |
| jdstrand | cjwatson: hi! curious when snapcraft 2.40 will be in LP builds (if it isn't already)? | 13:02 |
| seb128 | jdstrand, Trevinho submitted the snapcraft file upstream and seems to still care about it some maybe he can help you? | 13:03 |
| mup | PR snapd#4989 opened: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989> | 13:04 |
| cjwatson | jdstrand: when it's in xenial-updates | 13:05 |
| jdstrand | cjwatson: ok, it is in xenial-updates | 13:05 |
| cjwatson | jdstrand: then builds will use it (unless oddly-configured) | 13:05 |
| jdstrand | it seems remmina is not using LP | 13:06 |
| mborzecki | cachio: 2018-04-05 14:32:39 Successful tasks: 225 ^^^ | 13:06 |
| jdstrand | I look forward to when we can see where a snap build comes from (and, if LP, the build log) | 13:07 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| popey | jdstrand: i do not off hand | 13:11 |
| mup | Issue snapcraft#2031 closed: Inconsistent results when building, cleaning stage and rebuilding <bug> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/2031> | 13:14 |
| mup | PR snapcraft#2047 closed: pluginhandler: organize in build instead of stage <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047> | 13:14 |
| jdstrand | popey: I just filed an upstream bug | 13:19 |
| popey | ok cool. | 13:20 |
| popey | jdstrand: is there anything else needed on emoj - I am still getting rejection mails about the x11 desktop thing | 13:21 |
| seb128 | jdstrand, sorry, I dropped offline, I was saying that maybe Trevinh_o can help you | 13:23 |
| Chipaca | zyga: found the cause of my userd panic and it was totally my code =) | 13:39 |
| === iMadper` is now known as iMadper | ||
| mvo | pstolowski: tests for 4988 failed again, this time because opensuse is out of diskspace. so feel free to push any further changes to this branch | 13:41 |
| mborzecki | https://forum.snapcraft.io/t/cannot-create-directory-tmp-snap-rootfs-var-lib-snapd-lib-gl32-permission-denied/4868/4 has anyone seen it on their 16.04 systems? | 13:43 |
| pstolowski | mvo: ok | 13:50 |
| diddledan | popey, the irccloud icon is an electron icon, so I've forced it in PR https://github.com/snapcrafters/irccloud-desktop/pull/7 | 14:06 |
| mup | PR snapcrafters/irccloud-desktop#7: fix desktop icon <Created by diddledan> <https://github.com/snapcrafters/irccloud-desktop/pull/7> | 14:06 |
| cjwatson | jdstrand: next launchpad-buildd and snapcraft releases combined should handle that | 14:10 |
| * zyga enjoys self-made lunch | 14:10 | |
| cjwatson | jdstrand: actually not sure it even needs a new snapcraft release, just launchpad-buildd | 14:11 |
| popey | diddledan: oh bum, sorry | 14:12 |
| jdstrand | cjwatson: nice! :) | 14:12 |
| diddledan | no probs :-) | 14:13 |
| diddledan | I've just resolved the conflict so it's pushbutton mergable | 14:13 |
| * popey pushes the button | 14:13 | |
| mup | PR snapd#4990 opened: many: implement a poor man's privileges drop, use for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4990> | 14:13 |
| diddledan | I originally fixed it the way you did, but that icon seems to be the electron stock icon rather than the irccloud icon, so I've bundled the proper icon now | 14:13 |
| popey | you're right, i have the electron icon here now :) | 14:14 |
| popey | if this works shall i push to stable? | 14:14 |
| diddledan | defo! | 14:14 |
| diddledan | OT: doom runs on everything these days: https://www.youtube.com/watch?v=VnmIXK3PYFw | 14:16 |
| kyrofa | cprov... we need to talk about store errors | 14:34 |
| kyrofa | We need some consistency | 14:34 |
| cprov | kyrofa: sure, do you have an example ? | 14:35 |
| kyrofa | cprov, sometimes we get an error_list, sometimes we get a message, and sometimes we get an error_message | 14:37 |
| kyrofa | And the only time we know when is when someone reports a traceback :P | 14:37 |
| kyrofa | Oh! And a release error gives us a detail, that's nice | 14:37 |
| kyrofa | We need a more standard error response, ever API call seems to have its own way of doing things | 14:38 |
| cprov | kyrofa: the new pattern is `error_list`, we should fix specific cases where it's not honoured | 14:38 |
| kyrofa | cprov, and do the contents of error_list follow a standard pattern? | 14:39 |
| * zyga wonders why all things evolve to resemble xml-rpc | 14:39 | |
| kyrofa | I've never seen a error_list with more than one item | 14:39 |
| cprov | kyrofa: https://dashboard.snapcraft.io/docs/api/snap.html#errors | 14:39 |
| kyrofa | cprov, ah, very good. And those codes won't change out from under us? | 14:40 |
| kyrofa | cprov, haha, I see the "Important: Not all API endpoints are migrated yet to this new error format" | 14:40 |
| cprov | kyrofa: yeah, most of the errors are single, but there are few with multiple item, push is an example I remember | 14:41 |
| kyrofa | cprov, are you actively working to migrate all API endpoints to use that new error format? | 14:42 |
| thresh | hey popey, how would I go about building in an lxd? | 14:42 |
| cprov | kyrofa: the fact we didn't finished the migration is bad, I am more than happy to fix any remaining endpoints | 14:43 |
| kyrofa | cprov, I guess what I'm asking is: do you know what the "remaining endpoints" are, or am I just going to hit them and need to report them? | 14:43 |
| mup | PR snapd#4991 opened: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 14:44 |
| kyrofa | Because there's no way for us to know all the possible error responses coming from the store | 14:44 |
| kyrofa | So that would be the status quo | 14:45 |
| popey | thresh: hello! do you have lxd installed? | 14:45 |
| thresh | yep, creating a VM for that atm | 14:45 |
| popey | thresh: "lxc launch ubuntu:16.04 vlctest" then "lxc shell vlctest" and you're in the container | 14:45 |
| cprov | kyrofa: I don't know, but file a bug about what is what is blocking you and I will walk the whole API. | 14:45 |
| thresh | popey, ah well, I was thinking there was some snapcraft command to do that for me etc :-) | 14:46 |
| kyrofa | cprov, alright, I'll make a note to log a bug when we encounter API responses that don't follow that pattern, thank you | 14:46 |
| cprov | kyrofa: thanks, do the same for any inconsistency to what is already documented | 14:47 |
| pedronis | mvo: zyga: #4991, after thinking a bit this is good , but doesn't fix the same kind of problem on undo, for that we really need new state I fear, because the tasks are too ambiguous for that | 14:48 |
| mup | PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 14:48 |
| popey | thresh: ah, there is, for sure. But you'd end up with a clean 16.04 container, not including the neon bits | 14:49 |
| kyrofa | cprov, another similar question. Let's say I'm releasing to a channel, but I don't have permission to do that | 14:55 |
| kyrofa | cprov, I get an error_list containing {'code': 'macaroon-permission-required', 'message': 'Permission is required: channel'} | 14:55 |
| kyrofa | But that doesn't actually give me enough info to give a helpful error message | 14:55 |
| kyrofa | I have to reach outside of the error_list to the 'permission' attribute to see what the issue was, and there is also the 'channel' attribute | 14:55 |
| kyrofa | But I never know when those will or will not be present | 14:56 |
| kyrofa | So my error handling code turns into spaghetti | 14:56 |
| kyrofa | You see what I mean? | 14:56 |
| cprov | kyrofa: I do and we can work this out | 14:57 |
| pstolowski | mvo: everything is terrible | 14:57 |
| mup | PR snapd#4992 opened: tests/main/interfaces-opengl-nvidia: verify access to 32bit libraries <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4992> | 14:57 |
| popey | diddledan: do you have any snaps in your dusty archive that are unblocked by 2.32? I had a few and I need to dust them off at the weekend. | 14:57 |
| cprov | kyrofa: the premise of using error-codes is that they should have specific handlers | 14:57 |
| diddledan | I need to check wine | 14:58 |
| pstolowski | https://github.com/snapcore/snapd/pull/4988 failed again because of opensuse and because of 502 when fetching "golang.org/x/net/context" | 14:58 |
| mup | PR #4988: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4988> | 14:58 |
| kyrofa | cprov, so if I get a 'macaroon-permission-required' I can assume that the 'permission' and 'channel' properties are present? | 14:58 |
| kyrofa | Because that error code sounds kinda generic | 14:58 |
| cprov | kyrofa: yes | 14:58 |
| diddledan | this is my current checked-out or in-progress snaps: https://usercontent.irccloud-cdn.com/file/0ensUQkd/image.png | 14:59 |
| popey | haha | 14:59 |
| kyrofa | cprov, okay, I can work with that | 14:59 |
| popey | ooh, you have snapcraft, that looks cool ;) | 14:59 |
| diddledan | :-p | 14:59 |
| popey | diddledan: revision 41 of irccloud still has broken icon. do i need to wait for the next build? | 15:04 |
| diddledan | o_O | 15:04 |
| * diddledan checks | 15:04 | |
| thresh | man I shouldve launched that VM on a ssd | 15:05 |
| diddledan | revision 41 was the one built in response to the PR I think. perhaps it's still broke? | 15:08 |
| zyga | jdstrand: hey | 15:09 |
| diddledan | popey: it has the correct icon for me | 15:13 |
| popey | Oh maybe font cache nonsense here maybe | 15:14 |
| diddledan | I had to uninstall irccloud and reinstall though, because I'd installed 3 separate testing builds locally causing snapd to decide the snap no longer exists in the store | 15:14 |
| diddledan | that's really ducked up | 15:15 |
| diddledan | I get not installing store snaps over locally installed ones automatically. but I tried explicitly telling it which revision to install and it still said the snap doesn't exist in the store | 15:15 |
| mvo | pstolowski: you mean because golang.org gives us 502 ? | 15:16 |
| mvo | pstolowski: or terrible for different reasons? | 15:16 |
| diddledan | htf are you supposed to switch between a test you built several times locally and the store snap?! | 15:16 |
| mup | PR snapd#4993 opened: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/4993> | 15:16 |
| pstolowski | no, just 502 | 15:17 |
| popey | diddledan: you have to snap refresh foo --edge --amend | 15:17 |
| diddledan | tried it | 15:17 |
| popey | the --amend is important | 15:17 |
| diddledan | didn't work | 15:17 |
| popey | there is a bug with amend, which m vo is fixing | 15:17 |
| popey | if the snap concerned isn't in stable | 15:18 |
| diddledan | https://www.irccloud.com/pastebin/pTpa2npd/ | 15:18 |
| thresh | popey, hmm, I'm able to repro that appmenu issue; let me check why it works on my docker image | 15:18 |
| popey | thresh: "great!" | 15:19 |
| diddledan | also | 15:19 |
| thresh | yeah, no | 15:19 |
| thresh | :) | 15:19 |
| diddledan | https://www.irccloud.com/pastebin/TAGOrUGZ/ | 15:19 |
| popey | maybe you need the channel too | 15:19 |
| popey | as well as the revision | 15:19 |
| zyga | pedronis: ack | 15:20 |
| popey | diddledan: either way, wimpy tested so I'm gonna promote that to stable. Thank you! | 15:21 |
| thresh | I wonder why this package is pulled in anyway | 15:22 |
| diddledan | yey | 15:22 |
| zyga | pedronis: nice work there | 15:22 |
| zyga | pedronis: I think this is good enough for this issue for thie .3 release | 15:22 |
| zyga | jdstrand: can you pleaes look at https://github.com/snapcore/snapd/pull/4993 | 15:22 |
| mup | PR #4993: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <https://github.com/snapcore/snapd/pull/4993> | 15:22 |
| zyga | am I right there? | 15:23 |
| om26er | https://github.com/snapcrafters/sublime-text/pull/9 | 15:23 |
| mup | PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9> | 15:23 |
| om26er | popey: ^ and happy birthday :) | 15:23 |
| zyga | ohhh | 15:23 |
| zyga | once that's in edge I can test again :) | 15:23 |
| jdstrand | zyga: you want to creat the dir and files in the dir? | 15:24 |
| zyga | I really want s-t from a snap :) | 15:24 |
| zyga | yes | 15:24 |
| jdstrand | approved | 15:24 |
| om26er | that makes the two of us. | 15:24 |
| zyga | jdstrand: thank you! | 15:24 |
| zyga | mborzecki: ^ FYI | 15:24 |
| zyga | mborzecki: another 2.32.x backport needed I suspect | 15:25 |
| om26er | also could anyone help with https://forum.snapcraft.io/t/right-click-menu-items-dont-work/4724 ? | 15:25 |
| pstolowski | mvo, cachio i suppose the tests will keep failing unless we fix the problem of space on opensuse | 15:26 |
| cachio | pstolowski, let me take a look | 15:26 |
| zyga | om26er: oh, interesting | 15:26 |
| zyga | om26er: I think our sanitization breaks the desktop file | 15:27 |
| zyga | om26er: can you pastebin the generated destkop file in /var/lib/snapd/desktop/applications | 15:27 |
| pstolowski | cachio: thanks! | 15:27 |
| zyga | om26er: or better, a diff from the vanilla one | 15:27 |
| zyga | om26er: I suspect we strip something and it's broken then | 15:27 |
| cachio | pstolowski, do you have a link? | 15:30 |
| cachio | I see most of them in green | 15:30 |
| pstolowski | cachio: nah, not anymore, i kicked the tests again, sorry; let's see if it fails again on opensuse | 15:33 |
| pstolowski | another bunch of 5xx from golang.org there :( | 15:33 |
| mvo | pstolowski: right now tests are going strong | 15:37 |
| mvo | pstolowski: fingers crossed (half done, no error yet) | 15:37 |
| cachio | pstolowski, it is weird because we have a fixed image | 15:37 |
| cachio | for opensuse 42.3 | 15:38 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| cachio | but let's see | 15:38 |
| zyga | cachio: hey | 15:38 |
| pedronis | zyga: btw I think undo of Enable is also buggy | 15:38 |
| zyga | about opensuse | 15:38 |
| zyga | can you make sure our images don't run snapper | 15:38 |
| zyga | it's a tool built into opensuse | 15:39 |
| zyga | that takes snapshot of the system all the frelling time | 15:39 |
| zyga | and it keeps them | 15:39 |
| zyga | it makes 40GB VMs useless | 15:39 |
| zyga | pedronis: in which way, looking at the code now | 15:39 |
| pedronis | zyga: I think the undo of setup-profiles makes assumption that don't make sense for the undo of enable | 15:40 |
| pedronis | it's again an issue of not enough info | 15:40 |
| cachio | zyga, ah, ok, I'll take a look to that | 15:40 |
| pedronis | zyga: afaict the undo of setup-profiles will put back profiles as long as there's a current revision (active or not) | 15:41 |
| cachio | perhaps the best option is to have our own opensuse 42.3 image | 15:41 |
| pedronis | this is correct for the undos of refresh/install | 15:41 |
| pedronis | but not enable | 15:41 |
| cachio | so we can control what's inside | 15:41 |
| zyga | pedronis: yes | 15:41 |
| cachio | corrently we are using the one published by opensuse | 15:41 |
| pedronis | not sure I care a lot atm | 15:41 |
| pedronis | but is part of the messy picture of not enough state | 15:41 |
| zyga | cachio: well, it'd be nice to be true to real opensuse images but perhaps they are not so suitable for cloud; can you ask in #opensuse-buildservice perhaps? | 15:42 |
| cachio | zyga, ok | 15:42 |
| pstolowski | mvo: it failed again, this time on 2 ubuntu systems on prepare :( | 15:42 |
| pstolowski | https://api.travis-ci.org/v3/job/362640777/log.txt | 15:43 |
| zyga | mmmm | 15:44 |
| zyga | pedronis: so on undo we essentially setup security for the prior revision | 15:44 |
| pstolowski | 502 from govendor syncs | 15:44 |
| zyga | pedronis: (whatever it was) | 15:44 |
| pedronis | yea, but disabled state | 15:44 |
| pedronis | should have no profiles | 15:44 |
| pedronis | disable does remove-profiles | 15:44 |
| pedronis | anyway as I said, not super important right now, I noticed because I was staring | 15:45 |
| pedronis | at undo paths with setup-profiles link-snap in them | 15:45 |
| pedronis | wondering if we can extend the fix to the undo case | 15:45 |
| zyga | pedronis: I don't see it yet, sorry, i'm not that fast, is the issue with lack of state in setup-profiles or in how they are used to enable/disable | 15:45 |
| zyga | ah | 15:46 |
| zyga | sideInfo := snapst.CurrentSideInfo() | 15:46 |
| pedronis | it's lack of state I think | 15:46 |
| pedronis | active false | 15:46 |
| pedronis | means disabled | 15:46 |
| zyga | this will return nil when snap is inactive | 15:46 |
| pedronis | but also I'm going through being refreshed | 15:46 |
| pedronis | ? | 15:46 |
| zyga | yeah, I see | 15:47 |
| pedronis | no Current is always set | 15:47 |
| pedronis | unless during installation | 15:47 |
| zyga | the whole thing is just so complex now | 15:47 |
| pedronis | irrespective of enabled or disabled | 15:47 |
| zyga | ah, right | 15:47 |
| zyga | pedronis: so in ifacestate/handlers.go on line 252 where we check if sideInfo is nil we should also check if it was active or not | 15:49 |
| pedronis | that's not enough | 15:49 |
| pedronis | I think | 15:49 |
| pedronis | because of how we use active during refreshes | 15:49 |
| zyga | I must say I'm very lost in how it's used | 15:50 |
| pedronis | in both cases we enter | 15:50 |
| pedronis | setup-profiles with active false | 15:50 |
| pedronis | we really don't know | 15:50 |
| pedronis | do I have profiles on disk or not | 15:50 |
| pedronis | it's really related to the bug | 15:51 |
| pedronis | and the idea of having a profiles-revision | 15:51 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| pedronis | in the state | 15:51 |
| zyga | one thing to remember is that setup / remove will do the right thing for given input state | 15:51 |
| zyga | they largely don't care about what is on disk | 15:51 |
| pedronis | here they don't though | 15:51 |
| zyga | the system there is designed to reach a stable state, given the desired stable state | 15:51 |
| pedronis | we simply don't know enough | 15:51 |
| zyga | if we tell the repo to setup security, we will | 15:52 |
| zyga | it's juts that we don't know _what_ to say | 15:52 |
| zyga | and that I understand is the issue | 15:52 |
| pedronis | we don't know if there was a previous set of profiles or disk or not | 15:52 |
| zyga | I really honestly am lost in the state/task system now | 15:52 |
| pedronis | we just assume that if current is set | 15:52 |
| pedronis | that was the set | 15:52 |
| pedronis | that's untrue when we undo enable | 15:52 |
| zyga | and I think it warrants a whiteboard diagram that people discuss and collectively understand | 15:52 |
| zyga | in this specific case the worse that can happen is that snap will have profiles that it doesn't need | 15:53 |
| zyga | that's bad but harmless IMO | 15:53 |
| pedronis | as I said I don't care about it as a bug that needs immediate fixing | 15:53 |
| pedronis | it just points out we don't have enough state | 15:54 |
| pedronis | from a similar/slightly different angle | 15:54 |
| om26er | zyga: replied on snapcraft.io | 15:55 |
| zyga | mborzecki: maybe you want to look at https://forum.snapcraft.io/t/right-click-menu-items-dont-work/4724/6 | 15:56 |
| zyga | you touched destkop files recently and it's related | 15:56 |
| pedronis | zyga: as we said yesterday ifacestate is trying to "reuse" the state as kept by snapstate but there are matches/confusion | 15:57 |
| pedronis | is not that the state is too complicated, is more that is slight out of phase/sync wrt what ifacestate does/needs | 15:57 |
| pedronis | s/matches/mismatches/ | 15:57 |
| popey | om26er: zyga you guys clear with my proposal in the s-t pr? | 15:58 |
| zyga | popey: https://github.com/snapcrafters/sublime-text/pull/9/files ? | 16:00 |
| mup | PR snapcrafters/sublime-text#9: ship gtk2 and fix desktop file shortcuts <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/9> | 16:00 |
| om26er | popey: We never released sublime to stable under sublime-text-3 name, so if we make an "announcement" of a type, I believe all those who have installed it currently will move to the new name. | 16:00 |
| zyga | pedronis: I think the complexity in our design is derived from the delayed execution and state keeping and how the do/undo logic is structured | 16:05 |
| thresh | :O | 16:05 |
| zyga | pedronis: if ifacemgr gets to keep its own state | 16:05 |
| zyga | pedronis: we can simplify some of it but only to the point where we need the interaction across managers | 16:06 |
| pedronis | isn't the lesson instead that the best if the managers can ignore each other | 16:07 |
| thresh | popey, I don't understand why this is happening: http://thre.sh/stuff/snapcraft-debug-docker.txt (docker image), appmenu-qt5 is marked to be fetched, but silently ignored | 16:07 |
| zyga | pedronis: I think that's true but then again managers are all kind of "we manage snaps" in some way and the separation of interface manager is more of a "two people coded this" than deliberate design | 16:07 |
| * thresh goes on comparing apt-conf dump | 16:08 | |
| pedronis | zyga: yes, in the sense that a solution to some extent would be to merge into doLinkSnap both what it does and doSetupProfiles, then active would mean one thing, there are probably still issues though | 16:10 |
| zyga | pedronis: yes, especially if it finishes half way and needs to clea nup | 16:11 |
| zyga | on one hand side if every little thing is a task undo is easy | 16:11 |
| zyga | on the other hand big tasks are easier to understand | 16:11 |
| zyga | and regardless, making changes to task structure across snapd versions sucks | 16:11 |
| zyga | we don't version them | 16:11 |
| diddledan | popey: if you're looking for snap news, besides irccloud being updated today, I've just pushed openra 20180307 to stable | 16:19 |
| diddledan | previous version was 20171014, and upstream have been doing a lot of work FWICT | 16:21 |
| cachio | zyga, snapper is installed in opensuse | 16:21 |
| diddledan | release notes from upstream: https://www.openra.net/news/release-20180307/ | 16:21 |
| cachio | zyga, who is running it? | 16:22 |
| zyga | it's a systemd unit AFAIR | 16:22 |
| zyga | removing it is a good idea | 16:22 |
| zyga | it uses lots of disk space | 16:22 |
| diddledan | popey: this is a choice quote from the release notes in the middle: "A fix for the AI cheating when it uses superweapons and support powers" | 16:24 |
| diddledan | :-p | 16:24 |
| diddledan | damned AIs. if they decide to murder us they'll cheat! | 16:24 |
| cachio | zyga, all the snapper services are already disabled | 16:25 |
| popey | diddledan: yay! :) | 16:25 |
| zyga | cachio: cool, that's good then | 16:25 |
| cachio | so, the problem is something else | 16:25 |
| zyga | cachio: what's the partition layout | 16:25 |
| cachio | I'll execute the test suite from here and debug it | 16:26 |
| cachio | zyga, https://paste.ubuntu.com/p/Tmwbnj6X89/ | 16:26 |
| mvo | cachio: could you give me a quick heads up when the revert happend? I will write a note in the forum about it then | 16:26 |
| zyga | nice, simple, good | 16:26 |
| cachio | mvo, who is triggering the revert? | 16:27 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| cachio | I? | 16:27 |
| cachio | or the store team? | 16:27 |
| thresh | popey, welp, now I can reproduce the error with appmenu even on my docker image -- I had to upgrade snapcraft to 2.40 from 2.39.3+really2.35 | 16:27 |
| thresh | now that's something already | 16:28 |
| mvo | cachio: its a change to the stable channel so if you could trigger it that would be great (once the store is ready) | 16:29 |
| cachio | ok, just to release the previous versions to stable, right? | 16:29 |
| cachio | 2.31.2 | 16:29 |
| mvo | cachio: yeah, correct 4205..4210 iirc, but let me quickly double check | 16:30 |
| cachio | sure | 16:30 |
| mvo | cachio: yeah, those are the versions | 16:30 |
| cachio | nice | 16:30 |
| cachio | pstolowski, hey you have a machine in google since yesterday | 16:32 |
| cachio | is it ok | 16:32 |
| cachio | can I kill it? | 16:33 |
| pstolowski | cachio: ah yes, i forgot to free it. yes you can kill it | 16:43 |
| cachio | pstolowski, thanks | 16:44 |
| nacc | is the store still "sick" wrt. downloading the core snap? | 16:51 |
| nacc | our CI is failing a bunch again | 16:51 |
| nacc | (git-ubuntu) | 16:51 |
| nacc | https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/372/console e.g | 16:51 |
| mvo | pstolowski: it is jinxed, the inject PR failed again | 16:56 |
| mvo | nacc: we released a new core some minutes ago, maybe that is the problem? | 16:56 |
| mvo | nacc: a bit of an overload | 16:56 |
| mvo | zyga: do we need 4993 for 2.32? | 16:57 |
| nacc | mvo: ok, i'll see | 16:57 |
| zyga | checking | 16:57 |
| zyga | yes, please take it | 16:58 |
| zyga | it's a minor fix but people will like it | 16:58 |
| mvo | zyga: sure, will do | 16:58 |
| zyga | and it cannot regress | 16:58 |
| zyga | it's adding permissions | 16:58 |
| zyga | thank you | 16:58 |
| mvo | zyga: ta | 16:59 |
| zyga | thanks for checking :) | 16:59 |
| mvo | jdstrand: hey, just wanted to (friendly) check if you will have time soon(ish) for a review of 4942? | 17:01 |
| cachio | pstolowski, worked on opensuse | 17:03 |
| cachio | no errorrs | 17:03 |
| pstolowski | cachio: yes... but we have other failures again | 17:08 |
| pedronis | mvo: don't know if you saw but I pushed #4991 | 17:13 |
| mup | PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 17:13 |
| zyga | pedronis: +1 from me, just one question | 17:15 |
| zyga | I will push the state on top | 17:15 |
| jdstrand | mvo: my understanding is that is for 2.33, not for 2.32. I've been tasked with some 18.04 distro work and therefore put that review (and other non-2.32 snapd work) behind that work | 17:15 |
| zyga | AFAIK we said all snap info loading would go through a helper in snapstate that loads from cache | 17:15 |
| pedronis | there is no such helper | 17:16 |
| pedronis | atm | 17:16 |
| jdstrand | mvo: is this for 2.32? | 17:16 |
| jdstrand | mvo: (it's already in our queue) | 17:16 |
| zyga | ah, that's okay than | 17:17 |
| pedronis | zyga: snapstate itself uses readInfo (you changed it recently), that's not public, not it is caching | 17:18 |
| pedronis | s/not it/nor it/ | 17:19 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mvo | jdstrand: it was for 2.33 but its one of these things we really want and its relatively small and self-contained so we aim for it for 2.32. but of course time is in short supply so if you are busy you are busy :) | 17:27 |
| jdstrand | mvo: I thought 2.32 was closed and bug fix only. you are saying that if I review this, you will put it in 2.32? | 17:29 |
| jdstrand | mvo: if so, when does it need to be reviewed by? eod tomorrow? (I read 2.32 is now planned for next week) | 17:32 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| mup | PR snapcraft#2050 opened: storeapi: properly handle lacking permission for channel <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2050> | 17:33 |
| mvo | jdstrand: we have 2.32 open right now because we are waiting for two critical fixes. so small/low risk/high gain can still go in. probably until tomorrow(ish). depends a bit on the pending fix(es) | 17:35 |
| mup | PR snapd#4988 closed: snapstate, ifacestate: inject auto-connect tasks try 2 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4988> | 17:35 |
| mup | PR snapd#4993 closed: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4993> | 17:35 |
| zyga | thanks mvo | 17:35 |
| mup | PR snapd#4994 opened: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by mvo5> <https://github.com/snapcore/snapd/pull/4994> | 17:36 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| mup | PR snapd#4995 opened: snapstate: inject autoconnect tasks in doLinkSnap for regular snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4995> | 17:37 |
| jdstrand | mvo: I should be able to get to it tomorrow. I may have some small policy updates to add to 2.32 too | 17:39 |
| zyga | jdstrand: ping me for those, I will review them ASAP | 17:39 |
| mvo | jdstrand: sounds good | 17:39 |
| pstolowski | mvo: wow, you merged it; did it pass finally? | 17:41 |
| mvo | pstolowski: yes, it finally did | 17:42 |
| mvo | pstolowski: i'm trying to build the new core now | 17:42 |
| pstolowski | mvo: great, thank you! let me know when it's available | 17:42 |
| mvo | pstolowski: probably ~30min or so, just triggered the ppa build for the deb once that is done will do the core build | 17:43 |
| jdstrand | oSoMoN: fyi: apparmor="DENIED" operation="chmod" profile="snap.chromium.chromium" name="/home/jamie/.config/ibus/bus/" pid=11621 comm="chromium-browse" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000 | 17:49 |
| jdstrand | oSoMoN: the dir exists and is already 0700. why is chromium trying to change that? | 17:49 |
| zyga | pedronis: conflict on https://github.com/snapcore/snapd/pull/4991 | 17:50 |
| mup | PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 17:50 |
| pedronis | zyga: btw, did you try it with reproducer? | 17:52 |
| hyperreal | Hello all. Is there a way to just browse the snapcraft store? Like with categories or A-Z? | 17:52 |
| zyga | pedronis: no, I'm about to try, just pushing my simple PR | 17:52 |
| oSoMoN | jdstrand, that's probably caused by https://github.com/ubuntu/snapcraft-desktop-helpers/pull/104/files | 17:53 |
| Chipaca | hyperreal: limitidly, yes | 17:53 |
| mup | PR ubuntu/snapcraft-desktop-helpers#104: Add missing stage packages and copy ibus socket files to enable ibus for GTK3 applications out-of-the-box <Created by oSoMoN> <Merged by kenvandine> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/104> | 17:53 |
| zyga | pedronis: https://github.com/snapcore/snapd/compare/master...zyga:fix/reload-repo-inactive-snaps?expand=1 | 17:53 |
| Chipaca | hyperreal: try "snap find --section" | 17:53 |
| zyga | pedronis: not sure if correct, not super familiar with state handling | 17:54 |
| hyperreal | Chipaca: thanks, I'll try that. | 17:54 |
| jdstrand | oSoMoN: that would do it | 17:54 |
| Chipaca | hyperreal: it needs more work on many fronts, but it's the beginning of the 'browse' journey | 17:54 |
| oSoMoN | jdstrand, what would cause the chmod call? the call to ln ? | 17:55 |
| jdstrand | oSoMoN: so, seems you could test -d $IBUS_CONFIG_PATH || mkdir $IBUS_CONFIG_PATH | 17:55 |
| pedronis | zyga: I fixed the conflict | 17:55 |
| zyga | thanks | 17:55 |
| jdstrand | oSoMoN: well, wait a sec | 17:56 |
| jdstrand | oSoMoN: XDG_CONFIG_HOME is in ~/snap at this point | 17:56 |
| jdstrand | oSoMoN: I don't see where a chmod is happening | 17:56 |
| popey | thresh: maybe follow up on that forum post and we can see if kyle can take another look. | 17:57 |
| jdstrand | oSoMoN: perhaps there is an unconditional chmod in the ibus libs. I would argue that should be fixed to only chmod if it isn't what it expects. that would be something for SRU and then anything using the desktop launcher won't be affected by it | 17:58 |
| thresh | popey, that's what I did, thanks! | 17:58 |
| popey | oh great :D | 17:58 |
| jdstrand | oSoMoN: as it stands, it sounds like if the lib is doing that, *every* snap that uses the part will trigger this denial, which will lead to confused users | 17:59 |
| pedronis | zyga: it looks it's going in the right direction, but yes that would be more work to do around the undo code paths to consider/use that new state | 17:59 |
| zyga | yes, that's how I re-purposed it after your idea | 18:00 |
| pedronis | also thinking when it gets written to disk (state.Unlock) | 18:00 |
| zyga | I think we want to store it for now | 18:00 |
| zyga | and eventually switch over | 18:00 |
| zyga | oh, good point | 18:00 |
| pedronis | zyga: if you look at snapstate handlers, they tend to do Set almost always at the end | 18:01 |
| pedronis | OTOH ifacestate stuff releases the lock more often (or did at some point) | 18:01 |
| pedronis | so there's some thinking to do what we want, what are the trade offs | 18:01 |
| pedronis | it might not release the lock anymore though now that I think | 18:01 |
| pedronis | we changed that | 18:01 |
| pedronis | because it was actually making things slower | 18:02 |
| zyga | I haven't looked yet but this is an important aspect of the correctness | 18:02 |
| pedronis | mmh | 18:03 |
| zyga | doSetupProfiles unlocks | 18:03 |
| pedronis | no we still do unlock | 18:03 |
| zyga | the stask state | 18:03 |
| pedronis | before calling the backends | 18:03 |
| zyga | is that the full state? | 18:03 |
| pedronis | yes, there is nothing but the full state | 18:03 |
| pedronis | we never write partial bits | 18:03 |
| zyga | ok | 18:04 |
| pedronis | so one should always be careful | 18:04 |
| pedronis | to have set something coherent into state | 18:04 |
| pedronis | before Unlock is done or can happen | 18:04 |
| zyga | so doSetupProfiles and doRemoveProfiles only unlocks at the end | 18:04 |
| zyga | that feels correct for now | 18:04 |
| pedronis | zyga: not really | 18:05 |
| zyga | so each setup will unlock, giving us some idea of where we are | 18:05 |
| zyga | no? | 18:05 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| pedronis | because they call setupSnapSecurity | 18:05 |
| pedronis | does unlock in the middle | 18:05 |
| zyga | ah, I see now | 18:06 |
| zyga | because backends run processes | 18:06 |
| zyga | and that's "slow" | 18:06 |
| pedronis | yes, I think we wanted to remove those Unlock | 18:06 |
| pedronis | especially the systemd backend was problematic | 18:07 |
| pedronis | so we didn't in the end | 18:07 |
| zyga | hmm I don't recall what the problems were | 18:08 |
| Chipaca | Stop can take infinite time, for example | 18:08 |
| zyga | interesting | 18:09 |
| zyga | we call get/set (in my patch) just prior to that | 18:09 |
| zyga | so we'd save the state then | 18:09 |
| zyga | Chipaca: physicists tell me that if you got an infinitiy its a problem in your calculation ;) | 18:10 |
| Chipaca | zyga: mumble "dirac's delta" at them and they'll shut up and bugger off | 18:10 |
| oSoMoN | jdstrand, that denial is harmless though, isn't it? | 18:11 |
| pedronis | zyga: we should call Set at the end as snapstate does | 18:12 |
| jdstrand | oSoMoN: it doesn't seem to affect the snap no. however, there will be bug reports where people think it is causing trouble and people will have to constantly refute that it is an issue | 18:12 |
| jdstrand | isn't* | 18:12 |
| oSoMoN | true | 18:12 |
| pedronis | zyga: when we are sure we are done | 18:12 |
| zyga | pedronis: after setup succeeds | 18:12 |
| zyga | yeah | 18:12 |
| zyga | we should also remove but I haven't done that yet | 18:12 |
| zyga | I could Set(st, snapName, nil) in the remove path but I didn't want to (since the struct can grow later) | 18:13 |
| jdstrand | oSoMoN: traditionally we would add an explicit deny rule, but we don't like to do that since they override allow rules, and interfaces that use them will undo interfaces that are meant to allow it | 18:13 |
| oSoMoN | jdstrand, it seems you are right: | 18:13 |
| oSoMoN | osomon@bribon:/tmp/ibus-1.5.17$ grep -rn chmod | 18:13 |
| oSoMoN | src/ibusregistry.c:475: g_chmod (filename, 0644); | 18:13 |
| oSoMoN | src/ibusbus.c:560: g_chmod (path, 0700); | 18:13 |
| jdstrand | oSoMoN: and by traditionally, I mean, outside of snapd | 18:13 |
| jdstrand | there you go. a quick stat() check is all that is needed | 18:14 |
| oSoMoN | jdstrand, I'll file a bug after dinner and will propose a fix | 18:14 |
| jdstrand | oSoMoN: in this case, it is src/ibusbus.c:560 | 18:14 |
| jdstrand | oSoMoN: thanks! | 18:14 |
| oSoMoN | yep | 18:14 |
| oSoMoN | thanks for pointing it out! | 18:14 |
| zyga | pedronis: I wonder if we should store revision if affected snaps failed | 18:14 |
| zyga | I think yes, we should | 18:14 |
| jdstrand | oSoMoN: thanks for working on a fix and even more thanks for getting ibus to work :) | 18:14 |
| zyga | because that's really the truth | 18:14 |
| pedronis | the truth in which sense? | 18:15 |
| pedronis | we are interested in whether we need to AddSnap this snaps at that revision | 18:15 |
| pedronis | if we should not do that, we shouldn't set it | 18:15 |
| pedronis | if we should, we should set it | 18:15 |
| zyga | pedronis: truth as in the profiles are on disk for that snap at that time | 18:17 |
| zyga | https://github.com/snapcore/snapd/compare/master...zyga:fix/reload-repo-inactive-snaps?expand=1#diff-145e00c2f5e1d200010c00f39691a09cL200 | 18:17 |
| zyga | (please refresh, force pusheD) | 18:17 |
| pedronis | should they be? | 18:17 |
| pedronis | I suppose this related to undo on error | 18:17 |
| zyga | I think this is okay because even if affected snaps fail this snap is in the repo and it's meant to be reloaded | 18:18 |
| pedronis | (which is not done by undo) | 18:18 |
| zyga | yes, it certainly is, this is purely in the error path | 18:18 |
| pedronis | I mean, in snapstate tasks try to undo themselve if they error | 18:19 |
| zyga | yes, and if they undo themselves correctly they will remove profiles (or setup another revision) which would update the state | 18:19 |
| pedronis | does the code in ifacestate do that? | 18:20 |
| zyga | probably not, let's see | 18:20 |
| pedronis | I don't think it does | 18:20 |
| zyga | I don't see any evidence of that, no | 18:21 |
| pedronis | if setup profile of revion X fails, we might have the profiles for revision X on disk | 18:21 |
| pedronis | but the rest of the undo | 18:22 |
| pedronis | will remove revision X | 18:22 |
| pedronis | from the system otherwise | 18:22 |
| zyga | we don't stash them | 18:22 |
| zyga | and it's not just revision X | 18:22 |
| zyga | it's also "whatever old snapd wrote" | 18:22 |
| zyga | maybe we are busted | 18:22 |
| zyga | so we'd have to rethink the logic around that for individual tasks to undo themselves mid-throgh-task | 18:22 |
| pedronis | well in theory having profile-revision in state | 18:23 |
| pedronis | should help knowing what is on disk | 18:24 |
| pedronis | (except during the transition from not having it to having it) | 18:24 |
| zyga | in some sense the undo task for setup profiles is the right undo for partially broken setup profiles | 18:24 |
| zyga | we just don't use that | 18:24 |
| zyga | undo unly runs if setup works all the wy | 18:25 |
| zyga | *way | 18:25 |
| pedronis | I know | 18:25 |
| pedronis | some things in snapstate do that | 18:25 |
| pedronis | they basically call they undo* code | 18:25 |
| pedronis | on error paths | 18:25 |
| pedronis | not all of them | 18:25 |
| pedronis | it depends | 18:25 |
| zyga | yeah | 18:25 |
| zyga | I think it would be nice to make that implicit | 18:25 |
| zyga | (eventually) | 18:25 |
| zyga | it is sane and nicer conceptually | 18:25 |
| pedronis | it also true that most things snapstate (except aliases) | 18:25 |
| pedronis | deal with the one snap | 18:26 |
| pedronis | security touches more than one snap | 18:26 |
| pedronis | the affected snap bit | 18:26 |
| mvo | pstolowski: edge with inject-tasks v2 should be ready in 10min or so, core snap is building right now | 18:27 |
| pstolowski | mvo: ack | 18:27 |
| pedronis | zyga: basically there's a lot of things to think about in this area, if we start cleaning up | 18:29 |
| zyga | pedronis: I agree | 18:31 |
| zyga | pedronis: I opened a PR with this code as is | 18:31 |
| zyga | it's not interacting with your fix yet | 18:32 |
| zyga | not sure if that's something we can merge before gustavo is back | 18:32 |
| mup | PR snapd#4996 opened: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996> | 18:32 |
| pedronis | zyga: we should remove the state in discard-conns, no? that's the task we use in ifacestate when a snap goes completely away? | 18:37 |
| zyga | that's a good point | 18:37 |
| zyga | yes, I'll do that | 18:37 |
| zyga | force pushed one liner | 18:39 |
| pedronis | pstolowski: mvo: there's a new core in edge it seems | 18:50 |
| mvo | yes | 18:50 |
| mvo | ! | 18:50 |
| cwayne | Beta expected today? | 18:53 |
| pstolowski | mvo: pedronis ok, checking | 18:54 |
| mvo | pstolowski: good luck, I'm running my own test here too | 18:54 |
| mvo | pstolowski: looking good here | 18:57 |
| mvo | zyga: I assume 4996 is for 2.32? | 18:57 |
| zyga | Hey | 18:58 |
| pedronis | mvo: maybe .4 but not .3 | 18:58 |
| zyga | We don’t need it, it is not a fix | 18:58 |
| pedronis | is just to start storing things | 18:58 |
| zyga | It’s long term | 18:58 |
| pedronis | mvo: #4991 we need to decide if we want it for .3 or wait | 18:59 |
| mup | PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 18:59 |
| pstolowski | mvo: all looks fine here as well | 19:01 |
| mvo | pstolowski: yay | 19:01 |
| mvo | pstolowski: I have the backport ready | 19:01 |
| pstolowski | mvo: lxd interfaces reported as connected (haven't tested lxd functionality though); no errors in snap change(s), and I see a series of connect task added there as expected | 19:02 |
| pedronis | great | 19:02 |
| pstolowski | mvo: awesome | 19:02 |
| mvo | pstolowski: yeah, lxc (the command) runs | 19:04 |
| mvo | pstolowski: and lxc info as well | 19:04 |
| mup | PR snapcraft#2051 opened: elf: use snapped strip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2051> | 19:04 |
| pstolowski | great | 19:04 |
| mup | PR snapd#4994 closed: cmd/snap-confine: allow creating missing gl32, gl, vulkan dirs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4994> | 19:05 |
| mvo | pedronis, zyga how safe do you consider the PR? | 19:09 |
| pstolowski | eod, cu | 19:10 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | pedronis: which one? | 19:10 |
| zyga | er | 19:10 |
| zyga | mvo: which one? | 19:10 |
| zyga | the one from pedronis? | 19:10 |
| mvo | zyga: 4996 was the one I just looked at. but its different from what we discussed earlier, didn't we? | 19:11 |
| zyga | ah, this one | 19:11 |
| pedronis | mvo: 4996 is not a fix | 19:11 |
| zyga | I think it's not critical | 19:11 |
| zyga | it's not the fix, it's probably going to get renamed / changed | 19:11 |
| pedronis | mvo: the fix (for the do path) is #4991 | 19:11 |
| mup | PR #4991: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4991> | 19:11 |
| zyga | what pedronis did is the real thing | 19:11 |
| zyga | mvo: review and squash 4991 | 19:12 |
| mvo | zyga: ok, checking | 19:12 |
| mvo | pedronis: oh, thank you | 19:12 |
| mup | PR snapd#4991 closed: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Squash-merge> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4991> | 19:22 |
| mup | PR snapd#4997 opened: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles <Created by mvo5> <https://github.com/snapcore/snapd/pull/4997> | 19:24 |
| === phoenix_firebrd is now known as phoenix_firebrd_ | ||
| mup | PR snapd#4995 closed: snapstate: inject autoconnect tasks in doLinkSnap for regular snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4995> | 19:36 |
| === phoenix_firebrd_ is now known as phoenix_firebrd | ||
| pedronis | I have updated the forum topic with links to the PRs | 19:45 |
| mvo | hrm, hrm, no travis slots | 20:09 |
| zyga | pedronis: thank you | 20:13 |
| zyga | mvo: bummer :/ | 20:13 |
| zyga | I'm waiting for kids to finally go to slepe | 20:13 |
| zyga | *sleep | 20:13 |
| mup | PR snapcraft#2052 opened: many: add override-prime scriptlet <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2052> | 20:16 |
| zyga | mvo: can I help or shall we wrap and do it tomorrow | 20:29 |
| mvo | zyga: looks like tomorrow, no slot from travis | 20:29 |
| mvo | zyga: which is a bummer, its the last pending PR | 20:29 |
| mvo | oh well | 20:29 |
| mvo | zyga: I will get up early and continue with this | 20:29 |
| cachio | mvo, any idea if travis is stuck? | 20:30 |
| mvo | cachio: its probably just that we used to many travis slots today that they don't give us new ones right away | 20:30 |
| zyga | well | 20:30 |
| zyga | did it pass on master? | 20:30 |
| zyga | run unit tests and merge it | 20:31 |
| cachio | mvo, ah, ok | 20:31 |
| zyga | it's not disto specific | 20:31 |
| mvo | zyga: yeah, well, would love to have a full run | 20:31 |
| mvo | zyga: but maybe you are right | 20:31 |
| zyga | you could have done a full run by now :) | 20:32 |
| zyga | it's 25~ for a full run | 20:32 |
| zyga | not saying it's bad you didn't it's just not exclusive to travis | 20:32 |
| cachio | mvo, do you know which travis machines have the google credentials? | 20:33 |
| mup | PR snapd#4997 closed: ifacestate: add to the repo also snaps that are pending being activated but have a done setup-profiles (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4997> | 20:34 |
| cachio | I think the trusty ones don't | 20:34 |
| cachio | I updated all the spread branches but they fail because of lack of credentials on travis machine | 20:34 |
| mup | PR snapd#4998 opened: release: 2.32.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4998> | 20:44 |
| mup | PR snapd#4999 opened: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999> | 20:54 |
| mup | PR snapd#5000 opened: errtracker: make TestJournalErrorSilentError work on gccgo <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5000> | 20:54 |
| mvo | zyga: and the build failed on pwerpc :( | 20:54 |
| zyga | uhhhh | 20:54 |
| zyga | why? | 20:54 |
| mvo | zyga: so we will need one more release for the deb | 20:54 |
| zyga | mvo: can we retry? | 20:54 |
| mvo | zyga: but thats ok, the core can still go to beta | 20:54 |
| zyga | or is it really broken | 20:54 |
| mvo | zyga: no, see PR above | 20:54 |
| mvo | zyga: its a new test in errtracker that breaks | 20:55 |
| zyga | ahhh | 20:55 |
| mvo | zyga: in very silly ways | 20:55 |
| zyga | s....t | 20:55 |
| zyga | can we not build for ppc in the future or would that cause migration issues? | 20:55 |
| mvo | zyga: we need to haggle with the distro about this | 20:55 |
| mvo | zyga: I would love to stop doing that but so far keeping it alive was more cost effective (less time spend) than to argue this | 20:56 |
| mvo | zyga: but maybe we are reaching the tipping point | 20:56 |
| zyga | mvo: bionic is about to ship | 20:56 |
| zyga | is bionic ppc-free? | 20:56 |
| mvo | zyga: it is!!! | 20:56 |
| mvo | zyga: happy days | 20:56 |
| zyga | my poor ppc box ;( | 20:56 |
| zyga | good :) | 20:56 |
| mvo | zyga: xenial has 3 more years | 20:56 |
| mvo | zyga: and there is always debian ;) | 20:56 |
| mvo | zyga: lol@your comment | 20:57 |
| mvo | zyga: I wish I could :heart: that | 20:57 |
| zyga | https://github.com/snapcore/snapd/pull/4999/files#r179598750 | 20:58 |
| mup | PR #4999: advisor: use json for package database <Created by mvo5> <https://github.com/snapcore/snapd/pull/4999> | 20:58 |
| mvo | zyga: thank you! | 21:00 |
| mvo | zyga: hrm, hrm, I really hope the ppa build finishes soon, I want to sleep :) | 21:01 |
| mvo | or :/ | 21:01 |
| mvo | or even :( | 21:01 |
| zyga | my eyes are closing | 21:01 |
| zyga | I'm closing my laptop now, sleep well and rest tomorrow | 21:01 |
| zyga | all work and no play makes mvo a dull developer | 21:01 |
| zyga | remember that ;) | 21:01 |
| zyga | it ends bad in the movie | 21:01 |
| oSoMoN | jdstrand, bug #1761585 | 21:02 |
| mup | Bug #1761585: ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus <amd64> <apport-bug> <bionic> <ibus (Ubuntu):New> <https://launchpad.net/bugs/1761585> | 21:02 |
| jdstrand | oSoMoN: thanks! | 21:24 |
| mvo | cachio: just fyi (no rush) - 2.32.3 for amd64/i386 is in beta now. once arm/arm64 is ready I will publis hthat too | 21:29 |
| cachio | mvo, nice, I'll start today | 21:30 |
| cachio | so for tomorrow morning we have some results | 21:30 |
| mvo | cachio: yay | 21:30 |
| cachio | mvo, did you see my comment about travis? | 21:30 |
| cachio | about in spread cron the jobs are failing because we dont have credentials | 21:31 |
| mvo | cachio: let me read | 21:31 |
| mvo | cachio: ohhh | 21:31 |
| mvo | cachio: that makes sense. what can we do? | 21:31 |
| cachio | could be happening because we are runing on trusty? | 21:31 |
| cachio | I have removed the trusty config but I could not validate if it is the cause | 21:32 |
| cachio | because we don't have more slots :( | 21:32 |
| mvo | cachio: :( | 21:32 |
| mvo | cachio: yeah, its really annoying | 21:33 |
| cachio | tomorrow we will have more? | 21:33 |
| mvo | cachio: yeah | 21:34 |
| cachio | ok, I'll wait | 21:34 |
| cachio | today I updated like 40 branches | 21:34 |
| cachio | and all of them failed because of that :( | 21:34 |
| cachio | parhaps it is my fault | 21:35 |
| cachio | I mean the reason why we don't have more travis slots | 21:35 |
| mvo | cachio: don't worry, but yeah, I think we get rate limited by travis at some point | 21:39 |
| mvo | cachio: armhf is now ready too in beta, I will do arm64 in my morning | 22:32 |
| Trevinho | question.. Is build.snapcraft.io now reading the yaml `base:` stanza to decide were to build the snap or will it use just core16 for everything? | 22:33 |
| Caelum | zyga: it doesn't look like they're regenerating the website | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
