| niemeyer | jdstrand: A bit late, but just in case, are you around? | 00:13 |
|---|---|---|
| niemeyer | jdstrand: It's not urgent | 00:13 |
| mwhudson | 'libc6' is required inside the snap for this part to work properly. | 00:30 |
| mwhudson | this particular part ships a single text file | 00:30 |
| mwhudson | wat | 00:30 |
| mwhudson | oh it's emitted for all parts if is_host_compatible_with_base is not true | 00:32 |
| mwhudson | that's a bit broad :) | 00:33 |
| niemeyer | mwhudson: Yeah, and also the idea of installing packages on the local machine to build.. we had a call today, and have a session in the sprint next week to discuss the future of snapcraft | 00:35 |
| niemeyer | mwhudson: In this sense specifically.. we need significantly simpler and more consistent | 00:36 |
| niemeyer | mwhudson: There are some good ideas in place already, in terms of building from within a container or image with shared access to the data | 00:36 |
| niemeyer | mwhudson: We just need to be a bit more opinionated and have a single workflow that always works | 00:36 |
| mwhudson | niemeyer: my use case is a bit strange because i need to include libraries from bionic | 00:37 |
| mwhudson | (thanks systemd journal format non-stability) | 00:37 |
| mwhudson | but yes | 00:37 |
| niemeyer | mwhudson: That's not too strange.. part of the conversation is precisely making sure it works no matter what the target base is | 00:38 |
| niemeyer | mwhudson: IOW, decoupling local host from build env | 00:38 |
| mwhudson | i guess i really want to use a bionic base... | 00:39 |
| niemeyer | Right | 00:39 |
| niemeyer | We have one of those coming :) | 00:39 |
| niemeyer | core18 | 00:39 |
| mwhudson | niemeyer: due around 18.04.1 time or did i get that wrong? | 00:40 |
| mwhudson | "Files from the build host were migrated into the snap to satisfy dependencies that would otherwise not be met." | 00:40 |
| mwhudson | would looove to know which files had these dependencies | 00:41 |
| niemeyer | mwhudson: :) | 00:42 |
| niemeyer | mwhudson: Yeah | 00:42 |
| mwhudson | oh wow i have far too much in this snap :( | 00:42 |
| === chihchun_afk is now known as chihchun | ||
| pablo_ | hi: i'm begginer with ubuntu core. Trying to add startup comand in rc.local but shell says "read only file syste". How can i solve this? | 00:58 |
| pablo_ | basically i want to automatically start a snap i built in startup | 00:59 |
| nacc | pablo_: wouldn't that be done by shipping a daemon normally? | 01:06 |
| pablo_ | nacc: eh, this is the first snap i build and the tutorials did not helped me too much (or i'm too dumb to understand them). How could i build a daeomn snap? | 01:07 |
| pablo_ | nacc: thanks a lot for the answer btw! :) | 01:07 |
| nacc | pablo_: https://docs.snapcraft.io/build-snaps/metadata | 01:08 |
| nacc | pablo_: i think that hooks into systemd | 01:09 |
| pablo_ | nacc: so i add daeomn: simple and should start at startup? | 01:10 |
| nacc | pablo_: i'm not sure, i've never done it, but that seems worth trying ;) | 01:10 |
| pablo_ | nacc: yes, i'm pakaging the snap right now. I'm worried cause my snap needs root privileges to change GPIO of my board. But if its hooks systemd it may work, doesn't it? | 01:13 |
| nacc | pablo_: you might need to enable an interface, and connect to it, i don't know | 01:13 |
| pablo_ | didn't start at reboot :( | 01:21 |
| mup | PR snapd#4753 opened: tests: fix dependency for ubuntu artful <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4753> | 01:25 |
| nacc | pablo_: are you able to start it manually? | 01:26 |
| pablo_ | IT workied!!! i rebooted again and worked | 01:27 |
| pablo_ | thanks a lot nacc! for answering my noob question | 01:27 |
| nacc | pablo_: not noob! it's a bit confusing | 01:28 |
| chris062689 | Good afternoon! I'm attempting to setup a snap package for Citra (3DS emulator) and was hoping I could work with someone with a bit more knowledge of how snap packages are developed? I'm really flying blind here... I've attempted to read the documentation on snapcraft.io but am still fumbling around quite a bit. | 01:41 |
| pablo_ | chris062689: yes, snapcraft doc is not useful for me either. I wrote a snap of a python script and to be honest, it was all try an error. | 02:03 |
| pablo_ | do you have a snapcrafst.yaml created so far? if you paste it in pastebin perhaps someone can help you | 02:04 |
| chris062689 | I'm slowly hacking away at it. I was just curious if I could partner with someone. If I'm still having trouble and at the end of my rope I'll paste it here :) | 02:06 |
| mup | PR snapd#4754 opened: spread: start moving towards google backend <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4754> | 04:33 |
| mup | PR snapd#4754 closed: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754> | 05:46 |
| mborzecki | morning | 06:01 |
| zyga | good morning | 06:51 |
| zyga | -14C now | 06:51 |
| mborzecki | zyga: hey | 06:52 |
| mborzecki | -17 here | 06:52 |
| zyga | brrr :) | 06:52 |
| * zyga goes for breakfast | 06:55 | |
| zyga | hey mvo | 07:09 |
| mborzecki | zyga: check the build error in this PR https://github.com/snapcore/snapd/pull/4751 maybe it's of interest to you | 07:11 |
| mup | PR #4751: tests: add support for external backend executions on listing test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4751> | 07:11 |
| mborzecki | mvo: hey | 07:11 |
| zyga | checking | 07:11 |
| zyga | hmmmm | 07:12 |
| zyga | no such file or directory... | 07:14 |
| zyga | [Mon Feb 26 20:50:27 2018] audit: type=1400 audit(1519678227.940:302): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/etc/group" pid=13952 comm="3" flags="rw, bind" | 07:14 |
| zyga | deleted entry | 07:14 |
| zyga | so | 07:14 |
| zyga | something killed that file form under us | 07:15 |
| zyga | prepare/restore logic? | 07:15 |
| mborzecki | but that's supposed to be run before/after the test right? | 07:15 |
| zyga | yeah but we saw many times that there is something that definitely runs at the wrong time | 07:17 |
| zyga | I don't know really | 07:18 |
| zyga | what would delete /etc/group otherwise | 07:18 |
| zyga | and note, we normally handle missing things just fine | 07:18 |
| zyga | we stat and look | 07:18 |
| zyga | and if missing create | 07:18 |
| zyga | and only then we proceed to mount | 07:18 |
| zyga | so before we stated and mounted something removed that | 07:19 |
| mvo | mborzecki, zyga good morning! | 07:21 |
| zyga | o/ | 07:21 |
| mborzecki | zyga: can you take another look at #4695? (sorry to be nagging you :) | 07:27 |
| mup | PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695> | 07:27 |
| zyga | yes, sorry for not sending feedback, I have it open all the time but I was checking if I understand the problem space and that took forever | 07:27 |
| kalikiana | sliff | 07:45 |
| pstolowski | morning! | 08:08 |
| mvo | hey pstolowski ! good morning | 08:11 |
| mborzecki | pstolowski: hey | 08:28 |
| mup | PR snapd#4753 closed: tests: fix dependency for ubuntu artful <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4753> | 08:44 |
| mup | Bug #1752031 opened: core `service.ssh.disable` key not taken into account <Snappy:New> <https://launchpad.net/bugs/1752031> | 09:24 |
| Chipaca | on the subject of InstallDate, and using the timestamp from current vs the timestamp from MountDir | 09:31 |
| Chipaca | I seem to remember that we went with current because it was a better indicator of when the thing was last refreshed to whatever is current | 09:31 |
| Chipaca | however if not current, there'd be no install date -- meaning no refreshed in info | 09:31 |
| Chipaca | I _could_ fall back to mountdir timestamp if there is no current | 09:32 |
| Chipaca | how well would that work? | 09:32 |
| Chipaca | (i think it'd work fairly well, but i might be missing something) | 09:32 |
| zyga | my vote goes for simplicity | 09:32 |
| Chipaca | (i could make a table of scenarios, but then people won't look at it) | 09:32 |
| Chipaca | :-) | 09:32 |
| zyga | just show what we know, not what we can make up (sort of) | 09:32 |
| Chipaca | we know both these things, and both can be arguably called an install date, or a refreshed date | 09:33 |
| Chipaca | and both are simple :-) | 09:33 |
| zyga | my point is that I'd personally feel better if the information always came from one source | 09:33 |
| Chipaca | if we use just one, the current timestamp is the right thing, as it's wrong less often (and when it would be wrong it's zero, which isn't printed) | 09:33 |
| zyga | is this a temporary situation and over time we will always have the right data? | 09:33 |
| Chipaca | that is the hope yes | 09:34 |
| Chipaca | we'll be adding this to snapstate at some point | 09:34 |
| mborzecki | anyone know a snap that places a *.desktop file under $SNAP_USER_DATA/.config/autostart? | 09:35 |
| Chipaca | zyga: the plan (small p) is to have, in snapstate, something like {refreshed: <timestamp>, reverted: <...>, ...}, or maybe a short log [(refreshed, <>), (refreshed, <>), (reverted, <>), ...) | 09:35 |
| zyga | log would be nice | 09:36 |
| Chipaca | mborzecki: I don't expect there to be a lot, as it doesn't work | 09:36 |
| zyga | mborzecki nope | 09:36 |
| Chipaca | mborzecki: (there's a bug open for that) | 09:36 |
| Chipaca | maybe on the bug? | 09:36 |
| Chipaca | mborzecki: https://bugs.launchpad.net/snapd/+bug/1736926 | 09:37 |
| mup | Bug #1736926: No way to autostart a snap of a desktop application <snapd:Triaged> <https://launchpad.net/bugs/1736926> | 09:37 |
| pedronis | Chipaca: the log would be truncated ? or just one entry per type, even if its' a log? | 09:38 |
| Chipaca | pedronis: i'm making stuff up on the fly, but I imagine it'd be, say, 5 entries? | 09:38 |
| Chipaca | i mean, all we're seeing immediate use for is the latest entry | 09:38 |
| pedronis | Chipaca: well, keeping installed forever seems useful | 09:38 |
| Chipaca | pedronis: as opposed to refreshed | 09:39 |
| Chipaca | yes | 09:39 |
| pedronis | that's when you introduced the snap into the system | 09:39 |
| Chipaca | but reverted vs refreshed vs enabled/disabled are much the same imho | 09:39 |
| Chipaca | so, well, something for this space :-) | 09:39 |
| Chipaca | point is, yes zyga, temporary until we have proper data instead of inferences | 09:40 |
| mborzecki | Chipaca: yeah, i'm working on that atm | 09:40 |
| pedronis | zyga: I think I understand the problem with that storeSuite.TestCheckAuthority test, otoh it's hard to reproduce the failure | 09:40 |
| Chipaca | mborzecki: popey might be the person to ask then | 09:40 |
| pedronis | I can propose something untested | 09:40 |
| mborzecki | Chipaca: hah, good idea ;) | 09:40 |
| Chipaca | mborzecki: but, is all the above a good enough answer for why the timestamp of current instead of of mountdir, wrt #4735? | 09:40 |
| mup | PR #4735: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <https://github.com/snapcore/snapd/pull/4735> | 09:41 |
| Chipaca | pedronis: not this week -- i want to wrap snapshots | 09:41 |
| Chipaca | pedronis: next week i hear we're going to be idle, so maybe then | 09:41 |
| pedronis | Chipaca: ? | 09:41 |
| Chipaca | <pedronis> I can propose something untested | 09:41 |
| pedronis | Chipaca: that was about my comment to zyga about flaky test | 09:42 |
| Chipaca | ah :-) ok | 09:42 |
| Chipaca | too many threads | 09:42 |
| pedronis | Chipaca: I have a gazillion other things to do | 09:42 |
| zyga | pedronis is it a test failure or a deeper bug? | 09:43 |
| Chipaca | pedronis: i must admit i was a little surprised, but i thought you were itching for something simple to relax | 09:43 |
| pedronis | zyga: it's a test failure | 09:43 |
| mborzecki | Chipaca: mountdir timestap if no current seems fine, but then if you disable/enable that would 'alter' the installed date? | 09:43 |
| pedronis | zyga: it's purely an order of stuff/timing issue, is just hard to reproduce here | 09:43 |
| pedronis | zyga: the fix is swapping two lines | 09:44 |
| pedronis | well two statements | 09:44 |
| popey | Chipaca: mborzecki hmm? | 09:46 |
| mborzecki | popey: do you know of a snap that tries to do autostart by dropping a desktop file under $SNAP_USER_DATA/.config/autostart? | 09:47 |
| popey | mborzecki: yes, discord | 09:47 |
| mborzecki | popey: thanks :) | 09:48 |
| popey | https://www.irccloud.com/pastebin/YcIz40Cr/ | 09:48 |
| popey | I think it does that post first run, it ticks the box by default. | 09:51 |
| mup | PR snapd#4755 opened: snap/squashfs: add BuildDate <Created by chipaca> <https://github.com/snapcore/snapd/pull/4755> | 09:54 |
| mup | PR snapd#4756 opened: asserts: fix flaky storeSuite.TestCheckAuthority <Created by pedronis> <https://github.com/snapcore/snapd/pull/4756> | 09:57 |
| pedronis | zyga: ^ | 09:57 |
| zyga | mborzecki have a look | 10:05 |
| zyga | pedronis looking | 10:05 |
| mup | PR snapd#4756 closed: asserts: fix flaky storeSuite.TestCheckAuthority <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4756> | 10:32 |
| mup | PR # closed: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600, | 10:50 |
| mup | snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755 | 10:50 |
| Chipaca | ooooh, github is dead | 10:50 |
| zyga | oh, what's wrong mup? | 10:50 |
| mup | PR # opened: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600, | 10:51 |
| mup | snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755 | 10:51 |
| zyga | https://github.com/snapcore/snapd/pull/4714 needs 2nd review | 10:54 |
| mup | PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714> | 10:54 |
| zyga | mvo this is from jamie for 2.32 | 10:54 |
| mvo | zyga: ok | 10:55 |
| === ikey|zzz is now known as ikey | ||
| mborzecki | zyga: thanks for the review, i've pushed an update, once it's green i'll merge that pr | 11:04 |
| zyga | sorry for taking so long | 11:04 |
| Chipaca | mvo: do you remember why we made --no-wait hidden? | 11:05 |
| mvo | Chipaca: I think because initially it was meant for our tests | 11:08 |
| mvo | Chipaca: but I think if it is useful outside of that we should just unhide it | 11:08 |
| Chipaca | mvo: I'm +1 for unhiding it, but only because it messes up some help screens and seems unnecessary for it to be hidden | 11:10 |
| mvo | Chipaca: sounds good to me | 11:12 |
| pedronis | Chipaca: it's mostly hidden also because we never had a discussion how to call it properly | 11:14 |
| pedronis | as long as it was for us, that was not a problem | 11:14 |
| Chipaca | pedronis: in what sense? you mean --no-wait might be a bad name for the flag? | 11:14 |
| Chipaca | ah | 11:15 |
| pedronis | yes, how to call the flag | 11:15 |
| Chipaca | ok, i'l raise it as part of this por | 11:15 |
| Chipaca | pr* | 11:15 |
| Chipaca | zyga: do we have a backwards containment checker? | 11:24 |
| zyga | mmmm, what? | 11:24 |
| zyga | what is backwards containment? | 11:24 |
| Chipaca | I know we have a [foo,bar] contains foo checker | 11:24 |
| zyga | aaah | 11:24 |
| Chipaca | do we have a foo in [foo,bar] | 11:25 |
| zyga | I think that's Contains | 11:25 |
| Chipaca | (same check, different error) | 11:25 |
| zyga | no, wait | 11:25 |
| zyga | I mean | 11:25 |
| zyga | we have is x in [x, y, z] checker | 11:25 |
| zyga | is that what you mean? | 11:25 |
| Chipaca | zyga: I think it's just that Contains is used for checking that a container you got from the test has an element you expect it to have, and not viceversa | 11:27 |
| zyga | what is vice versa here? that an element exists in a container? | 11:29 |
| zyga | I mean | 11:29 |
| zyga | the check is the same, the error may be different | 11:30 |
| zyga | like Contained or something? | 11:30 |
| Chipaca | zyga: I'd call it In, but yeah | 11:30 |
| Chipaca | let me get an example for you | 11:30 |
| zyga | jdstrand I have a prototype of per-snap update-ns profiles | 11:31 |
| zyga | it works, I need to adjust some tests | 11:31 |
| zyga | and think about edge cases | 11:31 |
| zyga | where it would break | 11:31 |
| zyga | currently the policy is the same as before though | 11:31 |
| zyga | but I expect that to come in with small patches to policy and interfaces/layouts after this one lands | 11:32 |
| Chipaca | actually seeing the error message from contains, i guess it makes no difference; the expectation that the thing in test is first and the test valyue second is probably just mine | 11:32 |
| Chipaca | the other checkers have an obtained/expected thing though | 11:32 |
| Jasem[m] | hello, I just tried to push a snap using --release beta but it's been saying "Processing..." for an hour now | 11:32 |
| Chipaca | Contains just has container/elem | 11:32 |
| Chipaca | Jasem[m]: I'm not sure at what point snapcraft says "Processing"; is your network or cpu/disk busy? | 11:36 |
| zyga | Jasem[m] (you can use dstat to check) | 11:36 |
| Chipaca | Jasem[m]: otherwise it's possible the store went away for a bit, in which case maybe ^C and try again? | 11:39 |
| Chipaca | but if it's working, maybe let it work | 11:39 |
| * Chipaca might not be a snapcraft nor a store person | 11:39 | |
| * cachio afk | 11:40 | |
| Jasem[m] | ctlr+c doesn't even stop it | 11:52 |
| Jasem[m] | need to kill | 11:52 |
| Chipaca | Jasem[m]: ctrl+\ ? | 11:52 |
| mup | PR snapd#4695 closed: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4695> | 11:52 |
| Jasem[m] | Chipaca: running again, will see how it goes | 11:54 |
| Jasem[m] | Chipaca: ok now 'internal server error' .. try in few minutes the page returned. | 11:55 |
| Chipaca | that's not very good is it | 11:56 |
| Chipaca | Jasem[m]: in the 500 page you probably have (in the source) a OOPS id | 11:56 |
| Chipaca | Jasem[m]: could you look for that? | 11:56 |
| Chipaca | brb, cranking the heating up | 11:56 |
| Chipaca | hands're freezing | 11:56 |
| zyga | Chipaca what's the temperature? | 11:59 |
| zyga | (outside) | 11:59 |
| zyga | here it's gotten much warmer | 11:59 |
| zyga | -8 now | 11:59 |
| Chipaca | yeah you're sending it all this way | 11:59 |
| Chipaca | but nah, it's zero | 11:59 |
| mup | PR snapcraft#1879 closed: extractors: replace desktop file ids with paths <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1879> | 12:00 |
| Chipaca | just that the wind's up, and snow | 12:00 |
| Chipaca | going to hit -4 by sundown | 12:00 |
| ikey | oddly warm here | 12:00 |
| ikey | calm before the storm | 12:00 |
| zyga | I don't mind thinking about spring now | 12:01 |
| Chipaca | my uncle works on the tube, was expecting to be stuck somewhere today | 12:01 |
| zyga | like having +20 would be ... amazing | 12:01 |
| ikey | 3c here atm, "warm" lol | 12:01 |
| ikey | tonight is when the wind and snow is meant to be kicking off.. | 12:02 |
| zyga | still 11C more than here :) | 12:02 |
| ikey | ah yeah but we'll be down to -10C soon | 12:02 |
| zyga | I woke up and sent kids to school at -14 | 12:02 |
| ikey | and a foot of snow | 12:02 |
| ikey | oof | 12:02 |
| zyga | my daughter said she wants to see snow in Poland | 12:02 |
| zyga | (after living in Spain almost her entire life) | 12:02 |
| zyga | I told her "careful what you wish for" | 12:02 |
| zyga | well, she's getting the snow all right | 12:03 |
| zyga | "are you having fun yet?" | 12:03 |
| ikey | lol | 12:04 |
| zyga | speaking of which | 12:07 |
| zyga | my hands are freezing too | 12:07 |
| zyga | this new imac is not making any heat that my old AMD system used to do | 12:08 |
| zyga | how can I fix 12 failing tests when I cannot feel my fingers anymore :/ | 12:08 |
| mup | PR snapd#4757 opened: cmd/snap: unhide --no-wait; make wait use go via waitMixin <Created by chipaca> <https://github.com/snapcore/snapd/pull/4757> | 12:11 |
| Chipaca | niemeyer: how do you feel about --no-wait? :_) | 12:11 |
| * pstolowski lunch | 12:11 | |
| * Chipaca straightens his nose ;-) | 12:11 | |
| Jasem[m] | Chipaca: ok tried again and now it says that a file with the exact content already been uploading | 12:12 |
| Jasem[m] | it's kstars_2.9.3_amd64.snap | 12:12 |
| Chipaca | Jasem[m]: something's going on because now login.ubuntu.com is out | 12:14 |
| zyga | 9 errors left :-) | 12:16 |
| zyga | but all should be trivial two line changes | 12:16 |
| zyga | https://status.snapcraft.io shows stuff is "ok" | 12:16 |
| * Chipaca goes for lunch | 12:18 | |
| Jasem[m] | ok I'm getting the same error of the file already being uploaded :( | 12:21 |
| mup | PR snapd#4696 closed: wrappers: timer services <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4696> | 12:25 |
| mup | PR snapd#4758 opened: tests/main/snap-service-timer: spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758> | 12:27 |
| * zyga food | 12:33 | |
| mup | PR snapd#4735 closed: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4735> | 12:44 |
| niemeyer | Chipaca: The functionality seems nice, the argument name seems awkward | 12:50 |
| niemeyer | Chipaca: --no-wait=false :) | 12:50 |
| mup | PR snapd#4759 opened: [RFC] snap application autostart support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4759> | 12:50 |
| niemeyer | Chipaca: --wait=no | 12:50 |
| Chipaca | niemeyer: i don't understand --no-wait=false | 12:50 |
| niemeyer | Exactly :) | 12:51 |
| Chipaca | i mean, what? | 12:51 |
| Chipaca | niemeyer: i mean, i don't understand what you mean | 12:51 |
| niemeyer | Chipaca: I mean pretty much what you mean too: negatives makes it a bit awkward, when it could be a straight positive | 12:51 |
| Chipaca | niemeyer: what'd be the positive? | 12:52 |
| niemeyer | Chipaca: 1/yes/true | 12:52 |
| Chipaca | niemeyer: that's the side of the thing I knew | 12:53 |
| niemeyer | Chipaca: Yeah, it's a bit of an early morning conversation I suppose.. :) | 12:54 |
| niemeyer | Chipaca: Let's chat in a few mins | 12:54 |
| Chipaca | niemeyer: and a good morning to you too sir :-D | 12:54 |
| niemeyer | Morning! | 12:54 |
| niemeyer | It'll be even better if I learn that the google backend is working smoothly | 12:54 |
| niemeyer | Looks fine! | 12:57 |
| niemeyer | mborzecki: This failure on master probably needs some attention: https://travis-ci.org/snapcore/snapd | 12:57 |
| niemeyer | mborzecki: Ah, it's not master.. | 12:58 |
| niemeyer | mborzecki: It's a PR for master.. confusing Travis | 12:58 |
| niemeyer | It's this: https://github.com/snapcore/snapd/pull/4758 | 12:59 |
| mup | PR #4758: tests/main/snap-service-timer: spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758> | 12:59 |
| ikey | jdstrand, ping | 13:04 |
| niemeyer | https://usercontent.irccloud-cdn.com/file/UhcAcUK4/gce.png | 13:06 |
| Chipaca | mvo: #4748 is for 2.31 (or is that 2.32), fwiw | 13:25 |
| mup | PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748> | 13:25 |
| mvo | Chipaca: .32 - but yeah, I was almost looking at it | 13:26 |
| Chipaca | mvo: I'll milestone it | 13:26 |
| mvo | Chipaca: ta | 13:26 |
| Chipaca | mvo: there's one in the review queue milestoned for .31, should i change it to .32? | 13:26 |
| * ikey fixes yama in solus kernels | 13:28 | |
| mvo | Chipaca: if we need it for .31 we should make sure it goes to both | 13:38 |
| mvo | Chipaca: does .31 already ask for snap_yaml_raw? | 13:38 |
| Chipaca | mvo: I don't know | 13:41 |
| Chipaca | pedronis might | 13:41 |
| * kalikiana lunch time | 13:45 | |
| pedronis | Chipaca: I think it came with the default-provider stuff | 13:48 |
| pedronis | which is 2.32 afaik | 13:49 |
| mup | PR snapcraft#1956 closed: snap: actually plug the completer in <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1956> | 13:54 |
| mvo | Chipaca: yeah, that is my understanding, its the default-provider so 2.32, so lets retarget | 13:55 |
| jdstrand | mwhudson: hey, I just saw this 'thanks systemd journal format non-stability'. Not sure what your plan is, but I looked at this before and found that older journald's didn't work with newer journals *and* vice versa (I was using the python bindings). it was frustrating | 13:56 |
| jdstrand | mwhudson: fyi only | 13:57 |
| jdstrand | zyga: re per s-u-n profiles. cool :) seems fine to factor out now and tailor policy later | 14:03 |
| zyga | yep :) | 14:03 |
| jdstrand | niemeyer: hi! I'm here now if you still need me | 14:05 |
| jdstrand | ikey: hi! | 14:05 |
| ikey | jdstrand, howya | 14:05 |
| ikey | jdstrand, so just seen your forum reply sorry (transitioned to a craptop) | 14:05 |
| jdstrand | ikey: heh | 14:06 |
| jdstrand | ikey: I was going to ping you this week if didn't hear from you :) | 14:06 |
| ikey | so the original PR had some problems that we encountered, in that it somehow conflicted with core | 14:06 |
| jdstrand | ikey: right. we can work through all that | 14:07 |
| ikey | like on a fresh install with no snapd state no new snaps could be installed | 14:07 |
| ikey | in the mean time im enabling yama in the kernels per your advice | 14:07 |
| ikey | but yeah the actual how-the-interface-fits bit i think is the one i need most help with | 14:07 |
| ikey | and with devmode snaps changing soon i think now is certainly the time to do it | 14:08 |
| jdstrand | ikey: nice! I think you'll like that as a feature in general. do note, you'll likely need some docs stating how to disable it for your devs. in the beginning, Ubuntu carried a patch to strace and gdb iirc to let devs know (users never cared) | 14:08 |
| niemeyer | jdstrand: Thanks! Not quite sure what it was about, but I'll probably remember as I go through the notes again :) | 14:08 |
| ikey | yeah patching those seems sufficient | 14:08 |
| jdstrand | niemeyer: hehe, ok :) | 14:09 |
| ikey | building kernels on this laptop isn't the fastest thing in the world :( | 14:11 |
| jdstrand | ikey: ok, so I see you responded in the forum. I'll move it to the top of my list to go through the PR with a fine-toothed comb and we'll iterate get it into mergeable state. if the fresh install or other bugs remain and we can't solve them, we'll get help | 14:12 |
| ikey | cheers jdstrand - i think i just got the initial declaration part wrong | 14:12 |
| ikey | but the apparmor bits seem ok | 14:12 |
| jdstrand | cool | 14:12 |
| jdstrand | I just came online, but hopefully I can get to this today (famous last words, haven't seen inbox yet ;) | 14:13 |
| ikey | hah my inbox is closed today | 14:13 |
| ikey | too much to do | 14:13 |
| jdstrand | smart | 14:13 |
| jdstrand | :) | 14:13 |
| ikey | had to get the mesa 17.3.6 emergency update out as they'd broken igp | 14:13 |
| jdstrand | icky | 14:13 |
| ikey | mm | 14:13 |
| jdstrand | hopefully for an emergency update, all the depends didn't sping out | 14:14 |
| jdstrand | spin* | 14:14 |
| pedronis | mvo: niemeyer: I noticed https://forum.snapcraft.io/t/the-content-interface/1074 doesn't mention default-provider | 14:14 |
| niemeyer | pedronis: What a great opportunity! ;) | 14:14 |
| jdstrand | I don't do much with mesa, but when I do, I update all the libs | 14:14 |
| jdstrand | :P | 14:14 |
| ikey | jdstrand, luckily not in this case | 14:14 |
| ikey | no abi change | 14:14 |
| ikey | no dep changes, etc | 14:14 |
| jdstrand | nice | 14:14 |
| * ikey likes when cherry-picks live up to their name | 14:15 | |
| jdstrand | still, emergencies aren't conducive to getting to planned stuff :) | 14:15 |
| ikey | really not | 14:15 |
| ikey | that and waiting for this storm to kick in any minute | 14:15 |
| ikey | started snowing already | 14:15 |
| jdstrand | we're waiting for the rains to stop | 14:16 |
| jdstrand | fingers crossed, soon | 14:16 |
| ikey | id love to cross my fingers but they're too cold xD | 14:16 |
| jdstrand | hehe | 14:16 |
| ikey | alright once i have the kernels done ill ping you again | 14:17 |
| pedronis | niemeyer: I asked the question about hold | 14:17 |
| niemeyer | pedronis: Replying as we speak | 14:17 |
| niemeyer | or sort of :) | 14:17 |
| jdstrand | ok | 14:18 |
| pedronis | niemeyer: thanks | 14:24 |
| niemeyer | pedronis: np, hope it makes sense | 14:24 |
| niemeyer | pedronis: More seriously, would you mind to fix the lack of content-provider there? We need to get used to doing those opportunistic fixes to bring docs up-to-date | 14:25 |
| pedronis | niemeyer: I can try, in a little bit, trying to wrap up some things | 14:26 |
| mborzecki | Chipaca: posted a note https://forum.snapcraft.io/t/how-to-autostart-a-snap-of-a-desktop-application/2449/17 | 14:31 |
| mborzecki | zyga: layout test failed again https://api.travis-ci.org/v3/job/346757570/log.txt | 14:32 |
| zyga | looking | 14:33 |
| zyga | hmm, I haven't seen this kind of failure | 14:33 |
| zyga | looks like snap install failed (hanged?) | 14:33 |
| zyga | ah, no wait | 14:33 |
| zyga | wrong part of the log | 14:33 |
| zyga | there's no /etc!? | 14:34 |
| zyga | hmm hmm | 14:34 |
| mup | PR snapd#4759 closed: [RFC] snap application autostart support <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4759> | 14:36 |
| zyga | niemeyer can you please share credentials / tokens / whatever needed to run against google backend? | 14:37 |
| niemeyer | zyga: Right on.. what's your gmail email? | 14:38 |
| zyga | zkrynicki@gmail.com | 14:38 |
| niemeyer | zyga: Done.. | 14:39 |
| niemeyer | zyga: You'll need to install gcloud, then: | 14:40 |
| niemeyer | zyga: gcloud auth application-default login | 14:40 |
| niemeyer | zyga: and you should be good to go | 14:40 |
| zyga | this thing? https://cloud.google.com/sdk/downloads | 14:41 |
| niemeyer | zyga: Yeah.. we really need a snap for that.. I'm hoping they will do it :) | 14:41 |
| ackk | hi, is it possible to specify constraints on package versions in 'stage-packages'? | 14:41 |
| niemeyer | ackk: I don't think so.. it doesn't match the apt model super well | 14:41 |
| Chipaca | mborzecki: thank you for the heads-up; replied | 14:42 |
| zyga | Pharaoh_Atem FYI, I hate bugzilla | 14:42 |
| niemeyer | ackk: But I'm guessing.. sergiusens (when he's around) will know for sure | 14:42 |
| niemeyer | zyga: FYI, everybody does | 14:42 |
| zyga | I got 30 email notifications about some CC change that someone is doing to a selinux+snapd bug | 14:42 |
| zyga | my iphone beeps every 5 seconds | 14:42 |
| ackk | niemeyer, yeah that's true, I was wondering how could you have reproducible builds for snaps that use dependencies from debs | 14:42 |
| zyga | how do people use this?! | 14:43 |
| zyga | every tiny action sends more mail | 14:43 |
| niemeyer | zyga: Most people don't nowadays.. it was fairly popular in the 90s though | 14:43 |
| zyga | there's no conservation of energy there, you touch your mouse and bam, that's an email to everyone that had a browser open on this bug ever | 14:44 |
| zyga | 40 emails now | 14:44 |
| zyga | the notifications are so bad I don't even know what's being changed | 14:44 |
| mborzecki | bugzilla & mantis, both supper chatty | 14:44 |
| niemeyer | ackk: It's a problem outside the realm of snapcraft a bit.. there solutions to control a repository of packages so they don't change out of control | 14:44 |
| ackk | niemeyer, can you specify the source where debs are taken from? | 14:45 |
| zyga | niemeyer apparently RH still uses it for everything though | 14:46 |
| ackk | ah, I see https://forum.snapcraft.io/t/proposal-additional-package-sources/2199 | 14:49 |
| kalikiana | re | 14:49 |
| Son_Goku | zyga: it's supposed to be motivation to fix things, so you make bugzilla shut up :) | 14:49 |
| niemeyer | ackk: Yeah | 14:49 |
| Son_Goku | zyga: and maybe now you'll make the mystical SELinux backend :D | 14:50 |
| ackk | niemeyer, yeah that's a nice feature | 14:50 |
| zyga | jdstrand running tests now, so far so good | 14:57 |
| zyga | jdstrand can you please look at https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-af477950316a096b57d91c74478bc4d2R160 | 15:02 |
| zyga | is this all that I have to do on snap-confine side? | 15:02 |
| zyga | (the rest of the changes in C just push the argument through the functions) | 15:02 |
| pedronis | niemeyer: I wrote something about default-provider | 15:03 |
| niemeyer | pedronis: Thank you! | 15:03 |
| zyga | jdstrand and unrelated to that, is this line still required? I how do implicit and explicit profile transitions interact with each other? https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-798ce6f0668878eda67847b4ab492745L467 | 15:04 |
| mup | PR snapd#4760 opened: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760> | 15:29 |
| cachio | elopio, hey | 15:32 |
| * zyga is interrupted by arrival of construction team | 15:32 | |
| zyga | jdstrand I will look at results of 4760 when they show up | 15:32 |
| zyga | I want to break out one part to a separate PR | 15:32 |
| cachio | elopio, I have seen some snapcraft errors on the autopackgtests exec for snapd | 15:32 |
| zyga | jdstrand but if you can look at it and give me some early feedback I can iterate on it today | 15:33 |
| cachio | elopio, things like these https://paste.ubuntu.com/p/9q6NzrtZR5/ https://paste.ubuntu.com/p/2wjfMRBw7k/ https://paste.ubuntu.com/p/FYfgJ2nD3J/ | 15:33 |
| zyga | I suspect we can mostly merge it in the next few hours | 15:33 |
| cachio | mostly on armhf | 15:33 |
| cachio | elopio, those don't seem to be related to snapd, could you please confirm that? | 15:35 |
| cachio | elopio, most of them are here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd | 15:35 |
| ackk | niemeyer, is the PPA option for "Source archive for automatic builds" on LP snap builds basically what I was asking about? or is that just for build-packages? | 15:36 |
| Chipaca | brb, reboot | 15:38 |
| mup | PR snapcraft#1947 closed: errors: add ability to send stack traces to sentry <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1947> | 15:49 |
| ackk | sergiusens, I see that launchpad-build passes SNAPCRAFT_LOCAL_SOURCES to make snapcraft use the host apt repos, but I see no mention of it in the snapcraft source | 15:52 |
| mup | PR snapcraft#1961 opened: Sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1961> | 15:52 |
| ondra | sergiusens one more bug about that sanity check, if you are using environment part to update PATH, so it can find executable, snapcraft will not honour it fail with error that executable does not exist | 15:53 |
| sergiusens | ackk: because it is the default | 15:53 |
| sergiusens | ondra: use the full relative path | 15:54 |
| ackk | sergiusens, oh, so if you build a snap for the xenial base on xenial and you have PPAs on your machine, you have stage-packages that come from those PPAs? | 15:54 |
| ondra | sergiusens I know that workaround, but sure if executable is PATH then snapcraft should honour it and see it | 15:55 |
| ondra | sergiusens because snap works, it's only snapcraft refusing to build it | 15:55 |
| sergiusens | ackk: yes, this is why we want to move to building in containers for everything, using a container which's host would match that base to avoid all the confusion during "deployment" time (local installation or ci) | 15:55 |
| sergiusens | ondra: if you use `adapter: none` it will not, the snap runtime now expects `command` to be a full path to the binary | 15:56 |
| sergiusens | we don't want to deviate from that, sorry; hard line on that one | 15:56 |
| ikey | jdstrand, nearly finished doing all the kernel jankery | 15:57 |
| ikey | my guess is we'd reconvene on the steam thingy tomorrow | 15:58 |
| ackk | sergiusens, you mean having snapcraft do the build in the container (vs manually setting up a container and running snapcraft in it)? | 15:58 |
| ondra | sergiusens so command requires full path regardless adapter? | 15:59 |
| sergiusens | ondra: yes, it is masked by the fact we create a wrapper which is incidentally the actual relative path inside the snap to the command | 16:00 |
| ondra | sergiusens OK | 16:00 |
| sergiusens | ackk: yes, essentially bringing up SNAPCRAFT_CONTAINER_BUILDS to the front lines | 16:00 |
| ondra | sergiusens still it seems to be picky, if executable is in PATH snapcraft it happy, if PATH is updated using environment, it will fail | 16:01 |
| sergiusens | and leaving "building on host" as an advanced mechanism "I get to keep my broken pieces to myself" mode | 16:01 |
| ondra | sergiusens so there is inconsistency | 16:01 |
| sergiusens | ondra: ok, I am willing to go the other way and making it be a full path as something mandatory (we will warn though to not break existing builds) | 16:02 |
| ackk | sergiusens, cool, thanks | 16:02 |
| === Savicq is now known as Saviq | ||
| ondra | sergiusens yeah I don't know if how it is now breaks anything existing, but if it was like this then better to leave it | 16:06 |
| sergiusens | ondra: IOW, using `environment` in `apps` is a runtime thing, not a build time one | 16:06 |
| ondra | sergiusens yes, but snapcraft checks should not fail on something that will be correct in run time, erroring that executable is not there | 16:08 |
| sergiusens | ondra: that's the thing, in the future, it won't | 16:08 |
| sergiusens | once we get rid of the wrappers | 16:08 |
| ondra | sergiusens right, that makes more sense | 16:08 |
| niemeyer | Chipaca: If you have a moment soonish, can we please have a quick hangout? | 16:09 |
| mup | PR snapd#4761 opened: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4761> | 16:10 |
| Chipaca | niemeyer: yes | 16:10 |
| Chipaca | niemeyer: anything in particular? | 16:10 |
| niemeyer | Chipaca: Yeah, it's quick.. just want to get you interested on something :) | 16:11 |
| Chipaca | doom doom doooooom | 16:11 |
| Chipaca | just finishing a (let's keep it between us: rather disgusting) pizza the boys made for me at school, and i'll be free | 16:11 |
| Chipaca | I need something to unclog my chest | 16:12 |
| niemeyer | Chipaca: Great, enjoy, and just ping me | 16:12 |
| kyrofa | Haha, Chipaca what kind? | 16:13 |
| zyga | Chipaca pizza is never bad | 16:14 |
| zyga | it's just sometimes in the wrong week | 16:14 |
| zyga | wait a little, it will get better | 16:14 |
| zyga | like wine | 16:14 |
| Chipaca | kyrofa: tea is fine | 16:14 |
| zyga | mborzecki can you please look at 4761 | 16:14 |
| kyrofa | Chipaca, I mean the pizza | 16:14 |
| Chipaca | kyrofa: there's three different cheeses in there | 16:15 |
| Chipaca | kyrofa: and pepperoni | 16:15 |
| Chipaca | and gluten free pastry, because that's how they roll | 16:15 |
| Chipaca | maybe it's the wrong time of day for so much stodge | 16:15 |
| Chipaca | niemeyer: ready; standup ho? | 16:16 |
| mup | PR snapcraft#1962 opened: store: stringify message for StoreDeltaApplicationError <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1962> | 16:16 |
| mup | PR snapd#4762 opened: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/4762> | 16:16 |
| niemeyer | Chipaca: Let's do it | 16:16 |
| mup | PR snapd#4763 opened: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4763> | 16:21 |
| niemeyer | zyga: I've removed your gmail address and added your canonical one.. if you've logged in, you'll need to do it again | 16:28 |
| zyga | niemeyer thanks, I haven't logged in yet; I'll try that soon | 16:30 |
| jdstrand | ikey: ok. feel free to look at the PR, get it into shape for me to review and just reference me with @jdstrand and I'll get to it (if all you do is get it to apply clean to master, that's fine with me) | 16:35 |
| * Chipaca hugs pstolowski | 16:35 | |
| ikey | yeah ill need to redo as i closed the old one | 16:35 |
| jdstrand | zyga: sorry, buried in email and was in a meeting (out now) | 16:36 |
| zyga | whee | 16:36 |
| pstolowski | Chipaca, thanks for the review! | 16:36 |
| zyga | it's always good to get out of a meeting ;) | 16:36 |
| zyga | jdstrand have a look at the initial shape of the PR | 16:37 |
| zyga | it feels too easy, I wanted to make sure I didn't miss anything | 16:37 |
| jdstrand | https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-798ce6f0668878eda67847b4ab492745L467 isn't needed with change_onexec. you will need a rule to allow that change_onexec | 16:37 |
| zyga | ah, I see, how does such rule look like? | 16:38 |
| zyga | btw, there's a PR now | 16:38 |
| zyga | so you can comment there if you want | 16:38 |
| ikey | jdstrand, ill have that PR in for you tomorrow | 16:40 |
| jdstrand | change_profile -> snap-update-ns.*, | 16:40 |
| ikey | then we can redo the snaps as strict and set a minimum version | 16:40 |
| ikey | and generally kick ass | 16:40 |
| jdstrand | ikey: +1 :) | 16:40 |
| jdstrand | zyga: what is the pr number? | 16:41 |
| zyga | 4760 | 16:41 |
| jdstrand | zyga: ok, I'll take a look. btw, I'm not neglecting a review for the portals work, am I? afaik, I'm caught up... | 16:45 |
| zyga | jdstrand no no | 16:45 |
| zyga | jdstrand I want this finished as 2.32 is soon going to be released | 16:45 |
| jdstrand | I see | 16:45 |
| zyga | with the FIXMEs that this will help addressing | 16:45 |
| jdstrand | we need livecd PR in 2.32 so willcooke, seb128 and the gang can test. I saw that you asked mvo for an additional review (thanks!) | 16:46 |
| zyga | jdstrand yes, I think that PR is ready but I didn't want to just land it myself | 16:47 |
| seb128 | jdstrand, when is 2.32 due? | 16:47 |
| jdstrand | zyga: I also don't need your testsuite fixes in 2.32, but I need to know if they will be in 2.32 | 16:47 |
| mvo | seb128: in ~2 weeks | 16:47 |
| zyga | jdstrand testsuite fixes? | 16:47 |
| jdstrand | zyga: I phrased that weird | 16:48 |
| zyga | the profile hardening | 16:48 |
| jdstrand | zyga: the nfs_test.go and overlay_test.go bits | 16:48 |
| zyga | ah, that | 16:48 |
| zyga | that is done though :) | 16:48 |
| Chipaca | huh, snap on fc25 never comes back from the polkit dialog | 16:48 |
| seb128 | mvo, thanks, I guess that will have to do, some apps not working in the live session in not the end of the world | 16:48 |
| zyga | I was working on that to prepare for conservative mount changes that also need to mock things | 16:48 |
| zyga | and I didn't want to get into a huge PR that changes test infra in one go | 16:49 |
| zyga | Chipaca F25 is not supported, is it better in F27? | 16:49 |
| Chipaca | zyga: I don't have f27 :-) | 16:49 |
| zyga | Chipaca update :) | 16:49 |
| Chipaca | I'll get that set up when I get my new machine | 16:49 |
| Chipaca | (or when I dedicate the old one to fedora) | 16:49 |
| zyga | Chipaca offtopic, can you please look at small https://github.com/snapcore/snapd/pull/4761 | 16:50 |
| mup | PR #4761: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4761> | 16:50 |
| jdstrand | zyga: again, I don't need you to do anything other than let me know if you are pushing it to 2.32. it sounds like you are not, so I'll just do a separate 2.32 that isn't all cherrypicks | 16:50 |
| zyga | there's a similar 2.32 backport branch but you don't have to review it separately | 16:50 |
| Chipaca | zyga: in a mo' | 16:50 |
| zyga | Chipaca thanks | 16:50 |
| Chipaca | my fedora just lit up the 'check engine' light | 16:50 |
| zyga | jdstrand ah, I see | 16:50 |
| Chipaca | so i'm going to set it on fire and run | 16:50 |
| zyga | jdstrand I'm not doing a separate 2.32 one | 16:50 |
| zyga | yes we will need more cherry picks | 16:50 |
| jdstrand | ok | 16:50 |
| Chipaca | that's what you do when a car you downloaded off the internet tells you to check engine, right? | 16:51 |
| jdstrand | seb128: you may want to be aware of https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1751667 | 16:51 |
| mup | Bug #1751667: classic snap does not run on live session <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1751667> | 16:51 |
| zyga | sorry, I took forever to understand what you meant there | 16:51 |
| seb128 | jdstrand, oh, thanks | 16:51 |
| seb128 | kenvandine, ^ | 16:52 |
| jdstrand | seb128: I *think* once the PR in question lands, that becomes a non-issue. if it doesn't, the foundations team may be doing something with apparmor that is preventing apparmor to load policy on boot | 16:52 |
| zyga | seb128 yes, it should just work soon | 16:52 |
| jdstrand | (doesn't become on non-issue that is) | 16:52 |
| jdstrand | seb128, kenvandine: I commented in the bug | 16:52 |
| seb128 | thx | 16:52 |
| niemeyer | jdstrand, zyga: Can you have a look here: https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203/5 | 16:54 |
| jdstrand | seb128, kenvandine: to be very clear, you'll need https://github.com/snapcore/snapd/pull/4714 in the snapd deb in the livecd for you to be able to run any snaps before a core refresh | 16:54 |
| mup | PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714> | 16:54 |
| zyga | looking | 16:54 |
| niemeyer | jdstrand, zyga: This is not just about Debian.. I found the same problem in the GCE images | 16:54 |
| niemeyer | cachio: ^ | 16:55 |
| cachio | niemeyer, yes | 16:55 |
| zyga | niemeyer I think this was the bug in ubuntu that was fixed with a new kernel | 16:55 |
| zyga | where apparmor profiles would not be loaded by the apparmor service | 16:55 |
| zyga | let me look up the # | 16:55 |
| jdstrand | niemeyer, zyga: this is a known issue to me | 16:55 |
| jdstrand | let me triple check that statement | 16:55 |
| niemeyer | jdstrand: This looks like a pretty serious issue LXD is just not working | 16:56 |
| * zyga is still looking | 16:57 | |
| jdstrand | actually, the issue I knew about was: https://github.com/lxc/lxd/issues/4198 | 16:57 |
| jdstrand | that has to do with partial confinement and newer kernels | 16:57 |
| jdstrand | and is high on my list | 16:58 |
| jdstrand | let me look at the forum again | 16:58 |
| niemeyer | jdstrand, zyga, stgraber: For context, our entire suite passed in GCE's 16.04 image, except for lxd that failed with that error message | 16:58 |
| zyga | oh | 16:58 |
| zyga | GCE 16.04 image on ubuntu kernel or on google kernel? | 16:58 |
| jdstrand | that is different from https://github.com/lxc/lxd/issues/4198 then | 16:58 |
| niemeyer | zyga: The GCE image is produced by Canonical | 16:59 |
| jdstrand | well, yes, I was assuming ubuntu kernel | 16:59 |
| zyga | I see | 16:59 |
| jdstrand | ok | 16:59 |
| jdstrand | this is lxc running a snap inside a container | 16:59 |
| jdstrand | and the snap-confine in the container doesn't have the profile loaded | 17:00 |
| jdstrand | on Debian, this is I think expected | 17:00 |
| jdstrand | 4.9.0-5-amd64 | 17:00 |
| jdstrand | that kernel doesn't support apparmor stacked policy | 17:00 |
| stgraber | jdstrand: where did you see that this is inside a container? | 17:01 |
| jdstrand | the Ubuntu container comes up, notices that the kernel doesn't have stacking support and skips profile loads | 17:01 |
| jdstrand | stgraber: https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203 | 17:01 |
| stgraber | jdstrand: right, where do you see in there that this is inside a container? | 17:02 |
| jdstrand | stgraber: I was thinking the lxc list indicated that, but looking more carefully, no, that would still be the host policy | 17:02 |
| jdstrand | I thought that was trying to launch a snap, it is just list though | 17:02 |
| jdstrand | that kernel should have partial apparmor support | 17:03 |
| stgraber | yeah, AFAIK he's using a normal Debian system with snapd installed and the lxd snap installed. He can run the "lxc" command as root but not as a normal user and some update changed that for him (it used to work) | 17:03 |
| stgraber | and he says he's on stable, so it's unlikely to be the apparmor enablement that's going on with buster | 17:04 |
| jdstrand | the error there shouldn't make a difference if root or not | 17:04 |
| stgraber | yeah, though it does, he can interact with lxd fine as root | 17:04 |
| stgraber | https://discuss.linuxcontainers.org/t/snap-confine-issues-more-things-changing-without-my-doing-things/1276 is where he initially reported the issue before I sent him over to snapd | 17:05 |
| zyga | well, the error simply says that snap confine detected it is not running under confinement but apparmor is enabled and available in the kernel | 17:05 |
| jdstrand | hrm. btrfs is in the picture | 17:05 |
| zyga | that seems to say that either it's a non-standard setting that has apparmor enabled | 17:05 |
| zyga | or that the kernel in stable got updated to enable it (unlikely) | 17:05 |
| mborzecki | zyga: 4761 fixes the /etc thing we were seeing? | 17:05 |
| cachio | mvo, there? | 17:06 |
| zyga | mborzecki no, it's not related, it's a new bug I ran into while trying to use the multi-glob dir sync | 17:06 |
| cachio | I found a problem with refresh in 2.32 | 17:06 |
| zyga | mborzecki we don't use syncdir for any of the mimic construction code | 17:06 |
| mvo | cachio: yes | 17:06 |
| mborzecki | zyga: ahh ok | 17:06 |
| cachio | mvo, look at this https://paste.ubuntu.com/p/RwPt9qRNjc/ | 17:07 |
| jdstrand | that bug is all over the place | 17:07 |
| mborzecki | zyga: review swap can you take a look at https://github.com/snapcore/snapd/pull/4758 ? | 17:07 |
| mup | PR #4758: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758> | 17:07 |
| cachio | mvo, refresh starts | 17:07 |
| cachio | mvo, there is a connection refused | 17:07 |
| zyga | ack | 17:08 |
| mvo | cachio: yeah, looks like dns is not ready | 17:08 |
| cachio | and then network configuration is changed | 17:08 |
| mvo | cachio: actually it is trying to do a ipv6 connection | 17:08 |
| jdstrand | zyga: nice comment in the forum | 17:09 |
| cachio | mvo, weird, I should disable ipv6 and try again | 17:10 |
| cachio | I didn't enable ipv6 | 17:10 |
| mvo | cachio: good luck | 17:10 |
| niemeyer | jdstrand, zyga, stgraber: Again, we see the exact same error in our own tests in GCE, in Ubuntu | 17:11 |
| jdstrand | niemeyer: what kernel is that? | 17:11 |
| niemeyer | So trivial reproducer: grab spread, run google:ubuntu-16.04-64:tests/main/<the lxd test> | 17:11 |
| niemeyer | jdstrand: Whatever is in GCE | 17:12 |
| niemeyer | jdstrand: I don't have any machines live right now, but can have | 17:12 |
| zyga | I haven't installed the new google-enabled spread and the google SDK required yet but that will be my next step | 17:12 |
| jdstrand | right, I don't know what that is :) | 17:12 |
| niemeyer | jdstrand: We're even then! ;) | 17:12 |
| mvo | cachio: do you think you could try to reproduce 1752031 on a regular amd64 image? | 17:12 |
| jdstrand | heh | 17:12 |
| niemeyer | jdstrand: The point is that someone needs to investigate, and probalby not all of us | 17:12 |
| jdstrand | zyga: we need a google sdk installed? | 17:12 |
| niemeyer | jdstrand: Yes, just to auth.. | 17:13 |
| zyga | jdstrand for the auth, as far as I know | 17:13 |
| niemeyer | jdstrand: Then run: gcloud auth application-default login | 17:13 |
| niemeyer | jdstrand: Meanwhile, I'm adding you to the project so you have access | 17:13 |
| jdstrand | if it isn't obvious yet, I'm not setup for this either | 17:13 |
| niemeyer | jdstrand: What? How come!? This is working since at least 3AM my time! | 17:13 |
| zyga | mborzecki done | 17:14 |
| mvo | cachio: and if you can, the outpt of the ls command would be great and whatever you can find out about this. we are "masking" the service, so there should be a symlink from sshd.service to devnull in that /etc/ dir | 17:14 |
| jdstrand | niemeyer: hehe | 17:14 |
| niemeyer | jdstrand: Add you to the project.. if you grab snapd's master and do the auth suggested above, you should have access.. I'll grab the command line to run spread for you, just a sec | 17:15 |
| * kalikiana heading out for the day | 17:16 | |
| jdstrand | niemeyer: where does 'gcloud' come from? is this a pay service like with amazon? do I give my canonical google info? | 17:16 |
| niemeyer | jdstrand: gcloud is their CLI client for all things cloudy | 17:17 |
| jdstrand | niemeyer: right. where does one obtain that? snap install? :) | 17:17 |
| * jdstrand hasn't used gce before. can you tell? | 17:17 | |
| niemeyer | jdstrand: I wish it was a snap, but I think it still isnt' | 17:18 |
| niemeyer | jdstrand: It is a paid service, but you don't need to worry about it.. the project pays the bill | 17:18 |
| niemeyer | jdstrand: https://cloud.google.com/sdk/ | 17:18 |
| niemeyer | and yes, this is a great candidate for being a snap | 17:19 |
| jdstrand | ugh, tar balls with install.sh | 17:19 |
| jdstrand | ah, debs down below. slightly better | 17:20 |
| zyga | jdstrand those are debs with sudo install.sh :D | 17:20 |
| zyga | aka postinst | 17:20 |
| jdstrand | maybe I'll just do this in a vm | 17:20 |
| mborzecki | zyga: thanks, i've added the comments around timers :) | 17:21 |
| jdstrand | or a container. ugh | 17:21 |
| niemeyer | jdstrand: You can run the test with "spread -reuse -debug google:ubuntu-16.04-64:tests/main/lxd" | 17:21 |
| Chipaca | zyga, i've got a silly / funny question for you | 17:22 |
| niemeyer | jdstrand: You'll need to change the "systems" setting in the test, though, because I've removed that specific system so we could move on with the migration | 17:22 |
| zyga | yes | 17:22 |
| niemeyer | jdstrand: You can see the change here: https://github.com/snapcore/snapd/pull/4754/files | 17:22 |
| mup | PR #4754: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754> | 17:22 |
| Chipaca | zyga: i'm working on snap-exec right now | 17:22 |
| Chipaca | zyga: so I change it, build it, copy it to /usr/lib/snapd | 17:22 |
| zyga | "how do you test this" | 17:22 |
| zyga | is the question | 17:23 |
| zyga | that's not useful | 17:23 |
| Chipaca | zyga: and i never see the new one | 17:23 |
| Chipaca | (it's not reexec) | 17:23 |
| zyga | we don't use that one | 17:23 |
| zyga | snap-exec is almost always used after pivot_root | 17:23 |
| Chipaca | ajjj | 17:23 |
| Chipaca | of course | 17:23 |
| Chipaca | zyga: thank you | 17:23 |
| zyga | so you have to bind mount your snap-exec to /snap/core/current/usr/lib/snapd/snap-exec | 17:23 |
| zyga | :) | 17:23 |
| Chipaca | yep yep | 17:23 |
| * zyga hugs Chipaca | 17:23 | |
| Chipaca | say no moew | 17:23 |
| Chipaca | also, say no more | 17:23 |
| * Chipaca hugs back | 17:23 | |
| zyga | meow | 17:24 |
| niemeyer | jdstrand: I think it's kept entirely inside the source directory | 17:24 |
| * zyga is distracted by drilling, cutting and other noises | 17:25 | |
| zyga | on the up side, I will finally not have to store clothing and books on the floor so | 17:25 |
| zyga | whee | 17:25 |
| Chipaca | man i wish there were a flag equivalent of .hushlogin | 17:25 |
| zyga | take that neighbours! | 17:25 |
| Chipaca | zyga: ? | 17:25 |
| zyga | a team is constructing some furniture in the room next to me | 17:26 |
| zyga | they were supposed to be here in the morning | 17:26 |
| zyga | but ... reality | 17:26 |
| zyga | they will keep assembling things for the next few hours at least | 17:26 |
| zyga | <sound of electric saw> | 17:26 |
| niemeyer | jdstrand: That's how I run it at least.. it has bin/gcloud, and it all works | 17:26 |
| zyga | stgraber do you test LXD in GCE? | 17:27 |
| pstolowski | Chipaca, addressed your feedback | 17:40 |
| pstolowski | eod o/ | 17:40 |
| cachio_ | niemeyer, did you call me? | 18:13 |
| cachio_ | niemeyer, do you want to start with the new backend migration? | 18:13 |
| zyga | jdstrand any feedback? | 18:27 |
| pedronis | cachio_: I'm trying staging tests again (to test the new api), when you have a moment could you copy over a recent edge core | 18:32 |
| cachio_ | pedronis, sure, I'll finish with a bug that was raised and I'll take that | 18:33 |
| pedronis | thank you | 18:33 |
| jdstrand | zyga: in the PR? I gave it a little while ago. did you not get the email? | 18:35 |
| zyga | no, refreshing | 18:35 |
| zyga | I installed debian 9 with snapd | 18:36 |
| zyga | but | 18:36 |
| zyga | I cannot install core | 18:36 |
| zyga | search.apps.ubuntu.com is not working anymore? | 18:37 |
| zyga | oh, I see store is down | 18:37 |
| zyga | bummer | 18:37 |
| jdstrand | yeah, I'm stuck too | 18:37 |
| pedronis | yes, store is hiccuping again | 18:37 |
| zyga | seems totally down | 18:38 |
| zyga | jdstrand I didn't get any email | 18:38 |
| niemeyer | Oh no | 18:38 |
| zyga | I can see the feedback now | 18:38 |
| * niemeyer looks | 18:38 | |
| jdstrand | zyga: I don't know what to say... https://github.com/snapcore/snapd/pull/4760#pullrequestreview-99778381 | 18:38 |
| mup | PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760> | 18:38 |
| zyga | niemeyer do you know about https://status.snapcraft.io ? | 18:38 |
| zyga | jdstrand read your review | 18:43 |
| zyga | jdstrand I think the only thing I want to ensure we are in sync on is... | 18:44 |
| zyga | https://github.com/snapcore/snapd/pull/4760#discussion_r171024214 | 18:44 |
| mup | PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760> | 18:44 |
| niemeyer | zyga: I didn't | 18:44 |
| ikey | cat /proc/sys/kernel/yama/ptrace_scope | 18:44 |
| ikey | 1 | 18:44 |
| ikey | yay. | 18:44 |
| niemeyer | cachio_: So, you have access to the google back already right now.. just login with your canonical email address | 18:45 |
| niemeyer | cachio_: To login, install the google cloud sdk, and run: gcloud auth application-default login | 18:45 |
| niemeyer | cachio_: That's all | 18:45 |
| niemeyer | cachio_: spread should work from then on | 18:45 |
| cachio_ | niemeyer, perfect | 18:46 |
| cachio_ | niemeyer, so the idea is to make spread suite for in all the systems that we have right now, right? | 18:46 |
| kyrofa | Linode was just too unstable, eh? | 18:47 |
| cachio_ | ubuntu-16.04-64 is already working | 18:47 |
| ikey | jdstrand, valgrind + gdb still work nicely | 18:47 |
| ikey | and ltrace/strace, yay. | 18:47 |
| niemeyer | cachio_: HAve you seen the initial PR? | 18:47 |
| niemeyer | cachio_: Let me get you a link, just a sec | 18:48 |
| zyga | https://github.com/snapcore/snapd/pull/4754/files ? | 18:48 |
| mup | PR #4754: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754> | 18:48 |
| jdstrand | ikey: yeah. where they don't is -p | 18:48 |
| niemeyer | zyga: Thanks! | 18:48 |
| niemeyer | cachio_: That one ^ | 18:49 |
| ikey | right, attaching to a random process | 18:49 |
| ikey | so we probably want a simple set of scripts to "start" and "stop" secure modes | 18:49 |
| ikey | or rather, enter dev mode | 18:49 |
| niemeyer | cachio_: As you see there, I've preserved the system name, and just moved the system across from one backend to the other | 18:49 |
| niemeyer | cachio_: I also had to disable one test which jdstrand is looking into right now (lxd) | 18:49 |
| ikey | jdstrand, strace: attach: ptrace(PTRACE_SEIZE, 1574): Operation not permitted | 18:50 |
| ikey | :D | 18:50 |
| mvo | niemeyer: nice! | 18:50 |
| niemeyer | cachio_: But that's the idea.. we want to gradually move every one of those systems there.. I suggest starting with systems for which images are already available | 18:50 |
| jdstrand | ikey: nice! | 18:50 |
| jdstrand | niemeyer: fyi, spread -reuse -debug google:ubuntu-16.04-64:tests/main/lxd | 18:50 |
| jdstrand | error: backend "google" has unsupported type "google" | 18:50 |
| cachio_ | niemeyer, ok | 18:50 |
| ikey | also wow my strace -p tab completion is awesome | 18:50 |
| niemeyer | jdstrand: I assume you are using the snap? Will rebuild it | 18:50 |
| jdstrand | niemeyer: I'm in a checkout of master | 18:50 |
| niemeyer | jdstrand: So just update it | 18:50 |
| niemeyer | jdstrand: Exists as of last night | 18:51 |
| cachio_ | niemeyer, could you please push the change to support google bacjkend | 18:51 |
| cachio_ | I have the same problem | 18:51 |
| jdstrand | niemeyer: what snap are you talking about? | 18:51 |
| niemeyer | Is it not pushed? | 18:51 |
| zyga | jdstrand git pull in snapd/spread | 18:51 |
| jdstrand | spread is still r34 everywhere afaict | 18:51 |
| zyga | jdstrand the code is there | 18:51 |
| jdstrand | zyga: I already did that | 18:51 |
| niemeyer | jdstrand, cachio_: Everything is up-to-date, apparently... | 18:51 |
| zyga | jdstrand did you go install? | 18:51 |
| cachio_ | niemeyer, yes, it is pushed | 18:52 |
| jdstrand | I have c1d1c84e975e2d96ec665de7241c0a1495e2c098 | 18:52 |
| cachio_ | git was stuck | 18:52 |
| niemeyer | 5c9c4856e38fa8a757c6c22969585bdb353a0576 | 18:52 |
| niemeyer | jdstrand: % | 18:52 |
| niemeyer | ^ | 18:52 |
| cachio_ | niemeyer, so, I'll start migrating one by one | 18:52 |
| jdstrand | niemeyer: for snapd or spread? | 18:52 |
| niemeyer | jdstrand: For spread | 18:53 |
| jdstrand | zyga: I don't know what you are talking about | 18:53 |
| jdstrand | niemeyer: oh, no upload in the store? ok. I was curious why it wasn't there | 18:53 |
| niemeyer | jdstrand: Okay, wait.. :) | 18:53 |
| pedronis | I think jdstrand like me uses the snap | 18:53 |
| jdstrand | oh yes | 18:53 |
| jdstrand | everyone doesn't? | 18:53 |
| niemeyer | Okaaay.. :) | 18:53 |
| pedronis | I don't know | 18:53 |
| niemeyer | jdstrand: You said you used master, when I said I was going to update the snap :) | 18:53 |
| niemeyer | Anyway, all good.. updating it | 18:54 |
| zyga | I used a local build because I have some patches | 18:54 |
| jdstrand | niemeyer: sorry, I meant snapd master. I missed I needed to update spread (I figured I did, but when I saw it wasn't updated I focused on snapd | 18:54 |
| jdstrand | ) | 18:54 |
| niemeyer | jdstrand: All good! Working on it already, just a sec | 18:55 |
| niemeyer | jdstrand: Done | 18:58 |
| jdstrand | ok, snagged r35 and it is doing stuff | 18:58 |
| jdstrand | niemeyer: thanks! | 18:58 |
| niemeyer | jdstrand: Thanks a lot for digging into this issue, and sorry for the confusion | 18:59 |
| zyga | niemeyer, jdstrand: snapd + lxd works ok on debian 9 vanilla install | 19:02 |
| zyga | but apparmor is disabled in vanilla installs | 19:02 |
| zyga | I just tested that all the way from downloading debian, installing it in a VM, setting up lxd snap and creating a xenial container inside | 19:03 |
| niemeyer | zyga: Thanks, the GCE case is an easy target to look into.. I bet we'll learn something about Debian there too | 19:04 |
| zyga | yeah, GCE is next | 19:05 |
| zyga | I wanted to follow up on what the reporter was using | 19:05 |
| jdstrand | zyga: it is strange though that having apparmor enabled caused that issue. is this a 2.29 bug partial support bug? | 19:11 |
| zyga | I suspect that it indicates we don't generate the profile if apparmor is partially on | 19:12 |
| * zyga looks at the source | 19:12 | |
| niemeyer | mvo: cloud team already has bionic under the ubuntu-os-cloud-devel project! | 19:12 |
| jdstrand | I've reproduced in gce | 19:12 |
| jdstrand | the issue is different in gce though | 19:14 |
| jdstrand | in debian, it was 'lxc list' that caused the issue | 19:14 |
| niemeyer | cachio_: "image: ubuntu-os-cloud-devel/ubuntu-18.04-64" | 19:15 |
| jdstrand | in gce, that works fine. it is this that fails: lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-tools.echo from-the-inside' ubuntu | 19:15 |
| cachio_ | ogra_, hey, any idea why it could be happening? https://bugs.launchpad.net/snappy/+bug/1752031 | 19:15 |
| mup | Bug #1752031: core `service.ssh.disable` key not taken into account <Snappy:In Progress> <https://launchpad.net/bugs/1752031> | 19:15 |
| niemeyer | cachio_: This should give us bionic | 19:15 |
| zyga | jdstrand when apparmor is totally disabled we don't load the backend so there's nothing that happens, how can I enable apparmor on debian 9? (even partial support is good) | 19:15 |
| cachio_ | niemeyer, perfect | 19:15 |
| jdstrand | which is what I was talking about before-- the policy isn't loaded in the container | 19:15 |
| zyga | jdstrand is that a kernel bug? the one where detection of containers doesn't function? | 19:16 |
| jdstrand | zyga: boot with security=apparmor apparmor=1 | 19:17 |
| zyga | ok | 19:17 |
| * zyga snapshots and tries | 19:17 | |
| jdstrand | right, in the container, the reexec profiles are loaded, but not the one from /etc/apparmor.d | 19:18 |
| jdstrand | this is a 4.13 | 19:18 |
| zyga | I see | 19:18 |
| jdstrand | this is that bug | 19:18 |
| * jdstrand finds | 19:18 | |
| zyga | right | 19:18 |
| zyga | so, since this happens in GCE but not in linode does it indicate that GCE kernel is older? | 19:18 |
| zyga | or that the base set of packages (apparmor) in the container is older (not sure where the bug was fixed) | 19:19 |
| * zyga enabled apparmor on debian 9 and rebooted | 19:20 | |
| zyga | with partial confinement LXD works ok | 19:21 |
| jdstrand | zyga: gce has a 4.13 kernel. that is the kernel that changed what the unit is looking at | 19:22 |
| mvo | niemeyer: yay for bionic tests | 19:22 |
| jdstrand | jjohansen: hey, the fix for https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463, I thought that needed to be fixed in the kernel? | 19:24 |
| mup | Bug #1746463: apparmor profile load in stacked policy container fails <apparmor (Ubuntu):Confirmed> <apparmor (Ubuntu Artful):Fix Committed> <apparmor (Ubuntu Bionic):Confirmed> <https://launchpad.net/bugs/1746463> | 19:24 |
| jdstrand | jjohansen: see https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463/comments/3 for context | 19:24 |
| jdstrand | zyga: there is no need for you to look at gce (at least wrt this) | 19:25 |
| niemeyer | mvo: Yeah, and with an official image even | 19:25 |
| zyga | jdstrand ack, thank you | 19:25 |
| jdstrand | niemeyer: where do you want me to comment on gce? the lxc topic doesn't mention it | 19:25 |
| zyga | niemeyer, jdstrand: so at least in debian 9, even if I enable apparmor (non default configuration) snapd and LXD works correctly | 19:25 |
| jdstrand | zyga: sounds like you can report that and ask for more info to reproduce the reporter's environment | 19:26 |
| niemeyer | jdstrand: Seems okay to mention it there, since the error message and the context (lxd) is exactly the same | 19:26 |
| jdstrand | niemeyer: note, it is the same message, but coming from inside of the container. the reporter said it was outside the container, so the cause is different, but I'll comment | 19:26 |
| niemeyer | jdstrand: Cool, just mention that we were already looking into this related issue which looks a lot like it but is slightly different | 19:27 |
| jdstrand | yep | 19:27 |
| pypt | hello! not sure if it's been reported already, but api.snapcraft.io does not seem to be accessible from Travis: https://travis-ci.org/StreisandEffect/streisand/jobs/346906976#L1802 | 19:28 |
| zyga | pypt it was down a moment ago but it should be back up again | 19:29 |
| zyga | pypt have a look at status.snapcraft.io | 19:29 |
| pypt | thank you, retrying | 19:30 |
| pypt | seems to work! | 19:31 |
| zyga | jdstrand question about change_profile | 19:35 |
| zyga | I get how that works and makes sense | 19:35 |
| zyga | but what should I do to rules like this | 19:35 |
| zyga | /var/lib/snapd/hostfs/usr/lib{,exec,64}/snapd/snap-update-ns Cxr -> snap_update_ns, | 19:35 |
| zyga | I want to keep the path expression but drop the profile transition | 19:36 |
| zyga | should I just say "xr" there? | 19:36 |
| pedronis | mvo: did you see this https://forum.snapcraft.io/t/how-to-figure-out-why-ubuntu-core-keeps-restarting/4257 ? | 19:36 |
| mvo | pedronis: I have not | 19:36 |
| * mvo looks | 19:36 | |
| jdstrand | zyga: you should delete those rules. those rules are for binary attachment. you are using libapparmor so you need the change_profile rules. you probably need an r rule still. otoh, I don't remember, but it is easy for you to test. comment out the Cx rules, add the change_profile and see what pops out | 19:39 |
| mvo | pedronis: " snap “core” has “refresh-snap”" is strange, it seems to lack context | 19:39 |
| zyga | yep | 19:39 |
| zyga | thanks | 19:39 |
| jdstrand | np | 19:39 |
| pedronis | mvo: what's on errors | 19:39 |
| mvo | pedronis: looking now, need to get my 2fa token | 19:40 |
| mvo | pedronis: " ERROR cannot finish core installation, there was a rollback across reboot" | 19:43 |
| zyga | gadget issue? | 19:44 |
| mvo | pedronis: looks like some blacklist on core revert is needed | 19:44 |
| zyga | try/trying thig? | 19:44 |
| pedronis | mvo: well it rolled back | 19:44 |
| pedronis | so it wouldn't work either way | 19:44 |
| pedronis | mvo: that message means a rollback from initrd | 19:44 |
| mvo | pedronis: do you know more about this? or is all the info in this forum post? | 19:44 |
| pedronis | I just saw the post there | 19:45 |
| pedronis | I know nothing more | 19:45 |
| pedronis | mvo: ah, you mean apply blocked ? | 19:45 |
| pedronis | we don't set blocked indeed | 19:45 |
| mvo | yeah | 19:45 |
| pedronis | if the revert is from initrd | 19:45 |
| mvo | I think that would help a little bit | 19:46 |
| pedronis | but not sure | 19:46 |
| mvo | its an open question | 19:46 |
| pedronis | I don't remember the logic | 19:46 |
| mvo | I replied | 19:47 |
| mvo | in the forum, I hope we learn why it fails | 19:48 |
| jjohansen | jdstrand: needed? no, there are work arounds, as the bug is to due with the kernel not displaying the ns_name as userspace expects it. | 19:49 |
| pedronis | mvo: do we have other similar errors on errors? | 19:50 |
| pedronis | or is an isolated case | 19:50 |
| jjohansen | jdstrand: the kernel fix has been sent to the kt, but it got put in the backlog due to spectre/meltdown retpoline kernel respins. | 19:51 |
| mvo | pedronis: I don't know and I can't find out without help from the foundations team, we don't get a data export from the error tracker anymore :( | 19:51 |
| jdstrand | jjohansen: right. the bug task if for apparmor, but it is the kernel that will be fixed. that is what I wanted to know | 19:52 |
| jdstrand | jjohansen: thanks! | 19:52 |
| zyga | jdstrand I adjusted the rules and started a local run, fingers crossed | 19:57 |
| zyga | it also works on my desktop | 19:57 |
| jdstrand | nice | 19:57 |
| zyga | anything I should change apart from the profile transition rule? | 19:59 |
| zyga | I will iterate for sure but I want to know if anything is blocking this now | 19:59 |
| jdstrand | jjohansen: I added a couple of tasks to the bug. feel free to adjust if I got anything wrong (I wasn't sure if Fix Committed for the apparmor task translated to Fix Committed for the artful 'linux' task) | 20:02 |
| zyga | mvo, pedronis: do you have a moment for 2nd review of 4761? | 20:02 |
| mup | PR snapcraft#1963 opened: Fix Store integration tests with updated snap name registration error messages <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/1963> | 20:02 |
| jdstrand | zyga: I left a few comments and questions... did you not see them? I haven't gotten back to the pr for a few minutes | 20:02 |
| zyga | jdstrand wording changes, yes | 20:03 |
| zyga | jdstrand I was worried that we don't understand each other on when the profiles are generated | 20:03 |
| zyga | not sure if you saw my question on IRC earlier | 20:03 |
| jdstrand | I don't think I did | 20:05 |
| zyga | jdstrand my main point was that we generate the per-snap profile always | 20:05 |
| jdstrand | zyga: you have a comment to the contrary | 20:06 |
| zyga | because I don't want to use it for just layouts (that can be arguably "rare") | 20:06 |
| zyga | if so I will remove that comment, probably from an earlier draft | 20:06 |
| zyga | but also for content interface and for other things that we may need to do | 20:06 |
| zyga | and with your suggestions (per-snap) I think this is a good idea even more than originally so | 20:07 |
| jdstrand | zyga: https://github.com/snapcore/snapd/pull/4760/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR364 | 20:07 |
| mup | PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760> | 20:07 |
| zyga | I went this way to not have to duplicate the apparmor profile for snap-update-ns | 20:07 |
| zyga | ah | 20:07 |
| zyga | yes, stale comment, | 20:07 |
| zyga | I will remove it and re-read the diff to ensure they are all up-to-date | 20:07 |
| jdstrand | it looked like the comment was stale from the code, but I wanted to bring it up | 20:07 |
| zyga | cool! I think we are in sync then | 20:08 |
| zyga | I will go over all the things you mentioned on the next push, after tests turn green locally | 20:08 |
| jdstrand | zyga: I do worry about an extra profile, but at least it is only an extra one per snap instead of an extra one per command | 20:09 |
| zyga | yeah, it's not _that_ bad | 20:09 |
| zyga | and it will allow us to be much stricter WRT securiy | 20:09 |
| zyga | as it will allow us to essentially expand $SNAP_NAME and remove a lot of globs | 20:10 |
| mup | PR snapd#4761 closed: osutil: handle file being matched by multiple patterns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4761> | 20:11 |
| Chipaca | niemeyer: you still there? | 20:17 |
| pedronis | cachio_: I'm going afk, can you leave me a note if you manage to update core edge in staging still today? | 20:20 |
| cachio_ | pedronis, I am running right now | 20:21 |
| cachio_ | pedronis, It took time because I am running in google | 20:21 |
| cachio_ | and I had to recompile spread with the latest changes | 20:22 |
| pedronis | ah | 20:22 |
| cachio_ | pedronis, which issue do you see? | 20:22 |
| cachio_ | pedronis, tests failing? | 20:22 |
| pedronis | cachio_: yes, some are missing snaps (that's ok, I'm just sanity checking something) | 20:22 |
| pedronis | but I see a lot of | 20:23 |
| pedronis | of errors about snap-update-ns | 20:23 |
| pedronis | that I think is because core is too old | 20:23 |
| cachio_ | pedronis, ok, I'll send you an email with the results | 20:23 |
| cachio_ | ot a note here | 20:23 |
| cachio_ | as you wish | 20:23 |
| pedronis | cachio_: so I think with a new core in edge copied from prod | 20:24 |
| pedronis | errors should be mostly down to missing new snaps | 20:24 |
| pedronis | that's my hope at least | 20:24 |
| cachio_ | pedronis, I copied the core 2 weeks ago | 20:25 |
| cachio_ | I'll copy the latest one | 20:25 |
| pedronis | I know | 20:25 |
| pedronis | but layout happened since | 20:25 |
| pedronis | I think | 20:25 |
| zyga | layotu? | 20:25 |
| zyga | *layout? | 20:25 |
| pedronis | zyga: I see a lot snap-update-ns errors when running tests against staging | 20:26 |
| pedronis | given that doesn't relate to store | 20:26 |
| pedronis | I suspect is just that staging edge core (that we tweak) is too old | 20:26 |
| zyga | what does such an error look like? | 20:26 |
| zyga | ah | 20:26 |
| zyga | that's possible | 20:26 |
| pedronis | because of layouts related changes | 20:26 |
| pedronis | that's my theory atm | 20:26 |
| zyga | layouts, perhaps, maybe snap-device helper change? | 20:26 |
| zyga | do you have an error handy? | 20:27 |
| pedronis | some permission denied when running snap-update-ns | 20:29 |
| pedronis | seems I lost the scroolback with the exact error | 20:30 |
| zyga | if you get it I would love to see but yeah, I think getting staging in sync with prod would be useful | 20:33 |
| nacc | niemeyer: is this part of the new c-n-f? https://paste.ubuntu.com/p/jb76TmdG3V/ | 20:37 |
| nacc | niemeyer: and if so, can i strongly request it be rethought? that's not user-helpful output | 20:37 |
| pedronis | zyga: [Tue Feb 27 20:37:43 2018] audit: type=1400 audit(1519763863.485:46): apparmor="DENIED" operation="exec" profile="/snap/core/375/usr/lib/snapd/snap-confine" name="/snap/core/375/usr/lib/snapd/snap-update-ns" pid=17068 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 | 20:39 |
| zyga | hmm | 20:39 |
| zyga | if staging uses very old stuff then perhaps | 20:40 |
| zyga | but this doesn't seem immediately layout-y to me | 20:40 |
| pedronis | I have no changes but related to store bits | 20:40 |
| pedronis | and I just rebased on master very recently | 20:41 |
| zyga | ok | 20:41 |
| pedronis | just seems the snap-confine is wrong/old | 20:41 |
| pedronis | sorry, snap-confine profile | 20:41 |
| pedronis | I can also try to run without my changes | 20:41 |
| pedronis | but agains staging | 20:42 |
| mup | PR snapd#4764 opened: configstate: when disable "ssh" we must disable the "sshd" service <Created by mvo5> <https://github.com/snapcore/snapd/pull/4764> | 20:42 |
| pedronis | trying that | 20:42 |
| * pedronis really needs to stop sitting for a bit | 20:43 | |
| stgraber | sergiusens: hey, for LXD with clustering we need to set some custom CGO_LDFLAGS and CGO_CFLAGS variables, is there a clean way to do so with snapcraft? | 20:44 |
| Chipaca | stgraber: you can't do it with //cgo: stuff? | 20:45 |
| stgraber | Chipaca: nope because that includes a filesystem path | 20:46 |
| Chipaca | stgraber: I didn't follow, but I trust | 20:46 |
| stgraber | Chipaca: I basically need to set something along the lines of: | 20:47 |
| stgraber | CGO_LDFLAGS=-L/home/stgraber/data/code/lxc/sqlite/.libs/ | 20:47 |
| stgraber | CGO_CFLAGS=-I/home/stgraber/data/code/lxc/sqlite/ | 20:47 |
| stgraber | so an include and lookup path for the compiler and linker | 20:47 |
| Chipaca | stgraber: and you can't convince it via PKG_CONFIG_PATH? | 20:47 |
| Chipaca | if sergiusens isn't around maybe kyrofa knows | 20:48 |
| * kyrofa jerks awake | 20:48 | |
| Chipaca | unless he's lost his beard | 20:49 |
| stgraber | Chipaca: it's not using pkg-config so no | 20:49 |
| kyrofa | Chipaca, don't joke, I think it'll be gone in the next few days. My newborn HATES it and I can't snuggle him at all | 20:49 |
| Chipaca | kyrofa: I joke because I know :-) | 20:49 |
| Chipaca | kyrofa: less joking, more making fun of you | 20:49 |
| sergiusens | stgraber: we need to implement the build-env part attribute for this to work cleanly | 20:49 |
| * kyrofa pouts | 20:49 | |
| * Chipaca hugs kyrofa | 20:50 | |
| sergiusens | stgraber: so the sorried answer is, not yet | 20:50 |
| kyrofa | Yeah, a local plugin could do it, but it's not quite as clean | 20:50 |
| sergiusens | stgraber: while I have your attention though, is there a way to query lxd to if it has been through `lxd init`? | 20:50 |
| mup | PR snapcraft#1941 closed: project_loader: handle invalid unicode chars <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1941> | 20:50 |
| stgraber | sergiusens: not really because you can go through lxd init and not actually do any configuring :) | 20:51 |
| stgraber | sergiusens: best to look for what you actually need the user to configure | 20:51 |
| sergiusens | stgraber: ok, sounds good; I will probably be looking you up next week with a couple of things I'd like to solve wrt integration | 20:53 |
| stgraber | ok | 20:53 |
| sergiusens | we want lxd to be the default go-to setup for snapcraft | 20:53 |
| mup | PR snapcraft#1927 closed: catkin plugin: extract Wstool into its own module <enhancement> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1927> | 21:02 |
| Chipaca | ooh, ooh, can i also jump on the 'i am stgraber AMA'? | 21:03 |
| Chipaca | stgraber: the 'container' env var set in lxd, is that part of a standard of some sort? does it nest? :_) | 21:04 |
| Chipaca | lxc* | 21:04 |
| stgraber | Chipaca: not sure who started it, we might have :) but yeah, liblxc will container=lxc, I think vserver, openvz and docker also set something | 21:04 |
| Chipaca | should snaps set it, and should snaps running in lxc have something more complicated, and what if lxd is a snap :-) | 21:05 |
| mup | PR snapcraft#1852 closed: Added a missing step in Hacking.md <codein> <Created by Tanesh1701> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1852> | 21:05 |
| Chipaca | (i'm going to propose we expose it in PS1 in 'snap run --shell' if set, but might not if it's going to get messy) | 21:06 |
| zyga | jdstrand updated update-ns PR | 21:18 |
| zyga | jdstrand I added a comment that describes the changes made so that it is easier to follow | 21:19 |
| jdstrand | thanks | 21:19 |
| zyga | jdstrand I force-pushed to be friendlier to cherry-pick this | 21:19 |
| pedronis | niemeyer: can I be added to use the gce backend? | 21:34 |
| zyga | jdstrand thank you! | 21:35 |
| zyga | jdstrand tomorrow I'll prepare another single PR that changes layout-induced open rules to update-ns snippets | 21:36 |
| zyga | jdstrand and hopefully there are no more FIXMEs for layouts left :) | 21:36 |
| pedronis | jdstrand: did the spread snap work for you with gcloud? | 21:36 |
| zyga | jdstrand I also added tests and extra escaping in https://github.com/snapcore/snapd/pull/4745 | 21:38 |
| mup | PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745> | 21:38 |
| jdstrand | pedronis: as it happens, I use the spread snap, but unconventionally. I download r35 and was able to run tests in gcloud, yes | 21:38 |
| pedronis | jdstrand: I'm a bit confused because the creds are under ~/.config | 21:39 |
| * zyga EODs | 21:39 | |
| zyga | this has been a good day :) | 21:39 |
| pedronis | anyway I don't have access so it's moot :) | 21:39 |
| jdstrand | pedronis: right, my dev environment is an lxd container. I don't run the spread snap, I download it, unsquash it and use the binary | 21:40 |
| jdstrand | like I said, 'unconventional' | 21:40 |
| jdstrand | :) | 21:40 |
| jdstrand | zyga: thanks! | 21:40 |
| pedronis | ah | 21:40 |
| jdstrand | I could use spread git, but do it this way so I have released versions | 21:40 |
| zyga | jdstrand the container has apparmor applied? | 21:41 |
| jdstrand | zyga: no | 21:41 |
| pedronis | jdstrand: I was really using the snap, but I see a problem now that needed creds are under ~/.foo | 21:42 |
| jdstrand | well, it would except I have the 4.13 kernel | 21:42 |
| jdstrand | pedronis: yes, that makes sense. you would need to copy your creds over to ~/snap/spread/current/... I guess | 21:42 |
| niemeyer | pedronis: Yeah, everybody is in already | 21:43 |
| niemeyer | pedronis: Just log in with your Canonical email using "gcloud auth application-default login" and spread should work | 21:43 |
| pedronis | niemeyer: I see except that I was really using the snap, and the creds are under ~ /.config | 21:43 |
| niemeyer | pedronis: Oh, I see | 21:44 |
| niemeyer | pedronis: The other alternative is to export the credentials json file (or just copy it I guess) and define SPREAD_GOOGLE_KEY as the filename | 21:44 |
| niemeyer | pedronis: Should just equally well | 21:45 |
| niemeyer | nacc: Yes, it should be something along those lines.. what's the part you feel strongly about? | 21:46 |
| pedronis | niemeyer: yes, that works it seems | 21:49 |
| niemeyer | pedronis: Sweet | 21:50 |
| niemeyer | pedronis: Did you copy the file over or export it via the CLI? | 21:51 |
| pedronis | I copied it | 21:51 |
| pedronis | cachio_: sorry, I confused myself, these are the failures I get: https://pastebin.ubuntu.com/p/JRVqzgkX9B/ so new snaps and core transition | 22:09 |
| pedronis | which I don't know if I broke (I touch that code) or is a fluke | 22:10 |
| pablo_ | hi: it's beeing impossible to me to make a snap from a Qt/QML app i wrote. If i paste the *.yaml file in pastebin, could anyone help me a lil bit? | 22:43 |
| nacc | niemeyer: it's totally contrary to what we have now | 22:47 |
| niemeyer | nacc: Looks quite related to me.. still can't tell where your strong feelings come form | 22:49 |
| niemeyer | from | 22:49 |
| nacc | niemeyer: run 'deb jq' at your shell | 22:49 |
| nacc | niemeyer: run 'snap jq' at your shell | 22:49 |
| nacc | niemeyer: not at all what c-n-f emits now | 22:49 |
| nacc | niemeyer: i've commented in LP: #1749777 for mvo | 22:50 |
| mup | Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777> | 22:50 |
| niemeyer | nacc: Reading your comment, I guess what you mean is that the example command is not being shown? | 22:51 |
| nacc | niemeyer: and command-like output that is not commands at all, instead | 22:51 |
| niemeyer | nacc: This is command-not-found in 16.04: | 22:52 |
| niemeyer | $ blah | 22:52 |
| niemeyer | No command 'blah' found, did you mean: | 22:52 |
| niemeyer | Command 'blam' from package 'blam' (universe) | 22:52 |
| nacc | niemeyer: it doesn't emit the 'sudo apt install ...' line? | 22:53 |
| niemeyer | So there's nothing quite "contrary" here, or even so extremely different.. we are actually quite sensitive to not producing a lot of output on that command for obvious reasons, and we've already spent several hours discussing this exact issue. | 22:53 |
| nacc | niemeyer: and, afaict, the cnf chagne is happening in bionic not xenial currently | 22:53 |
| niemeyer | nacc: Right, it doesn't for this case | 22:53 |
| nacc | niemeyer: it does on bionic for actual packages | 22:54 |
| niemeyer | nacc: Because it favors compactness | 22:54 |
| niemeyer | nacc: Not for this case either, I believe | 22:54 |
| nacc | niemeyer: i think you're conflating things | 22:54 |
| niemeyer | nacc: It hasn't changed | 22:54 |
| nacc | niemeyer: there are two cases for cnf: mistyped commands and not-yet-installed commands | 22:54 |
| nacc | i don't care about the former | 22:54 |
| nacc | but the latter should not change in behavior because snaps are available | 22:54 |
| nacc | and it has now | 22:54 |
| niemeyer | nacc: No, I'm explaining the rationale.. command-not-found aims at producing compact output and helpful output.. now and in the past, when facing with too much data, it would choose sensible over writing command lines out | 22:55 |
| nacc | niemeyer: but the case you provided is 100% *not* the case i'm talking about | 22:55 |
| nacc | niemeyer: so, again, for a package that is available and you didn't typo, please don't regress the output | 22:56 |
| niemeyer | nacc: Command lines, as demonstrated with actual output from 2016, were not paramount to its working.. | 22:56 |
| nacc | niemeyer: glad your opinion gets to decide this :) | 22:56 |
| niemeyer | nacc: So the discussions we have today, preserve that aspect, and preserve the intention of being helpful and sensible in its output | 22:56 |
| nacc | niemeyer: since it feels like policy which should go to ubuntu-devel-discuss | 22:56 |
| niemeyer | nacc: Ironically, the output you see wasn't suggested by me | 22:56 |
| nacc | niemeyer: you have not preserved the output, as i have put in teh bug | 22:56 |
| niemeyer | nacc: My suggestion had more output, and I decide not to argue about it because I appreciate the short output | 22:57 |
| nacc | niemeyer: more output than what? | 22:57 |
| niemeyer | More output than what the latest proposal you are discussing presents. | 22:58 |
| nacc | niemeyer: what i proposed is what is already in bionic | 22:58 |
| nacc | or was until this latest upload published | 22:58 |
| nacc | niemeyer: regular users do not necessarily even know what "deb" is | 22:59 |
| nacc | niemeyer: you should never have exposed that in that manner | 22:59 |
| niemeyer | nacc: There's no need to be so aggressive and confrontational when discussing ideas.. | 23:00 |
| niemeyer | nacc: Already in 2016, command-not-found might not present commands in certain cases.. we're tuning behavior, and I'm willing to discuss ideas for improvement as there's still time for that, but we need to be willing to look at the data and stop handling this as the end of the world. | 23:01 |
| dpb1 | sorry didn't know you were discussing here. I just filed: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1752185 | 23:02 |
| nacc | niemeyer: ok, i don't feel like i can actually have this discussion with you. I think you've made a bad UX decision, I've articulated my reasoning in the bug. | 23:02 |
| mup | Bug #1752185: Formatting of command-not-found with snap addition could use cleanup <command-not-found (Ubuntu):New> <https://launchpad.net/bugs/1752185> | 23:02 |
| niemeyer | nacc: That's understandable, thank you | 23:03 |
| niemeyer | dpb1: Can you please copy over your comment to the original ticket | 23:04 |
| dpb1 | the original ticket == https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1749777 ? | 23:04 |
| mup | Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777> | 23:04 |
| dpb1 | niemeyer: ^ | 23:04 |
| niemeyer | dpb1: You are articulating the issue nicely.. I also don't like the header of those lines.. the listing is even okayish, but it'd be nice to have some better wording there | 23:04 |
| niemeyer | dpb1: Yeah, the 777 one | 23:05 |
| dpb1 | k, will do | 23:05 |
| niemeyer | Thanks! | 23:05 |
| dpb1 | ty, will follow the bug progress | 23:08 |
| cachio_ | pedronis, email sent with the restults | 23:50 |
| cachio_ | pedronis, all the tests passing with the new core | 23:50 |
| cachio_ | pedronis, using google backend | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
