| mup | PR snapcraft#1975 closed: python plugin: find setup.py when source-subdir is used <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1975> | 03:25 |
|---|---|---|
| mup | PR snapcraft#1976 opened: elf: only consider regular files as possible ELF binaries <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1976> | 03:31 |
| mup | PR snapcraft#1977 opened: lifecycle: when priming dependencies need to be primed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1977> | 03:49 |
| mborzecki | morning | 06:05 |
| zyga | re | 06:44 |
| mborzecki | zyga: hey | 06:49 |
| zyga | good morning :) | 06:49 |
| mborzecki | damn cold outside, -16 right here | 06:49 |
| zyga | but hey | 06:51 |
| zyga | it's spring :) | 06:51 |
| zyga | city bikes have been re-installed and enabled today | 06:51 |
| zyga | :D | 06:51 |
| mborzecki | it's spring in ~3 weeks from now :P | 06:51 |
| * zyga runs content interface tests and goes for some tea | 07:20 | |
| mup | PR snapd#4764 closed: configstate: when disable "ssh" we must disable the "sshd" service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4764> | 07:27 |
| mup | PR core#82 closed: xdg-open: add implementation capable of opening local files <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/82> | 07:29 |
| kalikiana | good morning | 07:55 |
| pstolowski | morning | 08:12 |
| mup | PR snapd#4751 closed: tests: add support for external backend executions on listing test (2.32) <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4751> | 08:21 |
| mup | PR snapd#4752 closed: tests: make interface-broadcom-asic-control test work on rpi (2.32) <go go go go!> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4752> | 08:21 |
| Chipaca | mvo: good morning! | 08:24 |
| mvo | hey Chipaca | 08:25 |
| Chipaca | mvo: I'll merge master into #4750, maybe that'll help | 08:25 |
| mup | PR #4750: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750> | 08:25 |
| mvo | Chipaca: aha, ok | 08:25 |
| Chipaca | mvo: there | 08:26 |
| Chipaca | mvo: the motivation for that PR is a silly / small one (it's a silly little pr): those are some bick heckin' structs :-) | 08:27 |
| Chipaca | big* | 08:27 |
| Chipaca | my hands were already writing heck | 08:28 |
| zyga_ | hey Chipaca | 08:33 |
| Chipaca | zyga_: you like what I did to the NG-using pr? | 08:35 |
| Chipaca | zyga_: also as a directo consequence of that, the NG-improving pr :-) | 08:35 |
| zyga_ | NG-using pr | 08:35 |
| zyga_ | I think I need another coffee to parse that | 08:35 |
| zyga_ | NG | 08:35 |
| zyga_ | what is that | 08:35 |
| Chipaca | i18n.NG | 08:36 |
| Chipaca | or was that GN | 08:36 |
| * Chipaca looks | 08:36 | |
| Chipaca | NG | 08:36 |
| zyga_ | are you referring to ngettext? | 08:36 |
| Chipaca | #4775 | 08:36 |
| mup | PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775> | 08:36 |
| * zyga_ looks | 08:36 | |
| zyga_ | ah | 08:37 |
| zyga_ | I wasn't aware it's called NG | 08:37 |
| Chipaca | zyga_: and #4777 | 08:37 |
| mup | PR #4777: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <https://github.com/snapcore/snapd/pull/4777> | 08:37 |
| zyga_ | is the empty argument sensible? | 08:37 |
| zyga_ | if this is anything like gettext I would expect | 08:37 |
| zyga_ | NG("%d day ago", "%d days ago", someNumber) | 08:37 |
| zyga_ | and why does it now say "at 15:04 MST" ?!? | 08:38 |
| zyga_ | Chipaca feel free to correct me, maybe I'm not really awake yet | 08:38 |
| Chipaca | zyga_: mborzecki feedback, that named timezones are more friendly | 08:38 |
| Chipaca | zyga_: the first entry is for n==1, and n is never one there, that's why it's empty | 08:39 |
| zyga_ | but why does humanTimeSince use a hard-coded string "15:04 MST" | 08:39 |
| Chipaca | that's the format | 08:39 |
| Chipaca | go's t.Format("<the string of how you want a particular date to look>") | 08:40 |
| zyga_ | ahh | 08:40 |
| mborzecki | zyga_: time referecen format https://godoc.org/time#pkg-constants | 08:40 |
| zyga_ | that's cool I didn't know htat | 08:40 |
| mvo | Chipaca: I tripped over this too, maybe a comment? | 08:40 |
| Chipaca | / RTFM | 08:40 |
| Chipaca | :-P | 08:40 |
| zyga_ | who designed that :) | 08:40 |
| mvo | Chipaca: I remembered this format thing then and forgot abou tit | 08:40 |
| * Chipaca is laughing, but at himself | 08:40 | |
| mvo | zyga_: someone who loves this particular date | 08:40 |
| zyga_ | at HH:MM XXX would be much nicer | 08:40 |
| Chipaca | how could you forget abou tits | 08:40 |
| zyga_ | Chipaca never forget about tits | 08:40 |
| * zyga_ gets that coffee | 08:41 | |
| Chipaca | ikr | 08:41 |
| * mvo wonders about the backstory of that date | 08:41 | |
| zyga_ | <quote day> | 08:41 |
| mvo | eh? this is a family channel! | 08:41 |
| Chipaca | mvo: families dont have 'em? | 08:41 |
| mborzecki | FWIW that format spec is pretty smart compared to the str[fp]time madness | 08:41 |
| mvo | *cough* | 08:41 |
| mborzecki | it's much more WYSIWYG than other 'formats' | 08:42 |
| zyga_ | this is like a := 1, b := 3; assert eval("2 + 2", a, b) == 3 | 08:42 |
| Chipaca | mborzecki: i wish you could precompute them though | 08:43 |
| Chipaca | that's a lot of repetitive jiggery to do in a loop | 08:43 |
| mborzecki | yeah, the implementation is a bit convoluted :P | 08:43 |
| zyga_ | last few loops on hardening | 08:50 |
| zyga_ | the base template got a lot shorter :) | 08:50 |
| zyga_ | and there are almost no globs left :) | 08:51 |
| zyga_ | there's one more chunk left but it will become visible with this test pass (extra directory writability permissions) | 08:52 |
| zyga_ | https://github.com/snapcore/snapd/pull/4765 has a lot of WIP patches, sorry for that, I'll get rid of them | 08:58 |
| mup | PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 08:58 |
| zyga_ | I'll tidy this up soon | 08:58 |
| Chipaca | mvo: zyga_: so, should ngettext _always_ have a first, reasonable string even when you know it's never singular? is there a case where ngettext will return the singular for n>1? | 09:10 |
| zyga_ | not in english, | 09:10 |
| zyga_ | in english it is only for n==1 | 09:10 |
| zyga_ | in other languages you have many cases and you should not assume there's no "singular" because of the value | 09:10 |
| Chipaca | right, but it'd not be using the empty string in those cases | 09:11 |
| Chipaca | unless it confuses things because msgid? | 09:11 |
| zyga_ | hmm, I don't know | 09:11 |
| zyga_ | I don't suppose it hurts to just use the singular string | 09:11 |
| Chipaca | eh, ok, i'll change it | 09:12 |
| Chipaca | drat, it needs to have a %d doesn't it | 09:13 |
| mvo | Chipaca: I was thinking about this too, all the plural forms I know have only a single singular and many multiple plurals (> 2, >10 etc) but *maybe* there are more so it does not hurt to have the singular | 09:17 |
| mvo | plus the comment | 09:17 |
| === ikey|busy is now known as ikey | ||
| Chipaca | mvo: like https://github.com/snapcore/snapd/pull/4775/commits/75cc9c7966e0eb67d4f637e3d31e8628f85d9006 ? | 09:18 |
| mup | PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775> | 09:18 |
| mvo | Chipaca: :+1: | 09:19 |
| sergiusens | Chipaca: we did time formatting like that for ubuntu-push-notifications iirc | 09:51 |
| Chipaca | sergiusens: anything learned? | 09:51 |
| sergiusens | good morning and good day (parting towards next weeks destination) | 09:51 |
| sergiusens | Chipaca: I still don't like it if you asked me again :-P | 09:51 |
| Chipaca | sergiusens: is there anywhere in snapcraft you check summaries don't have \n's? | 09:51 |
| sergiusens | Chipaca: I am not sure, but I need to shutdown, will continue from the airport (where irc is blocked) | 09:52 |
| Chipaca | sergiusens: telegram me :-) | 09:52 |
| Chipaca | sergiusens: o/ | 09:52 |
| sergiusens | o/ | 09:52 |
| Chipaca | ok, physio time | 10:10 |
| * Chipaca afk for a while | 10:10 | |
| mvo | jdstrand: does 4766 look good to you after the latest changes from james? | 10:30 |
| mup | PR snapd#4780 opened: snap: add autostart app property <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4780> | 10:44 |
| mvo | zyga_: I just pushed a fix for 4779 | 11:10 |
| zyga_ | Thank you! | 11:10 |
| === zyga_ is now known as zyga | ||
| * pstolowski lunch | 11:36 | |
| ackk | mvo, hi, I see your last commit on base-18 is about adding tzdata, but it doesn't seem that the snap actually has /usr/share/zoneinfo files? | 11:54 |
| ackk | (was testing the maas snap with it, but postgres still fails because of missing timezones) | 11:54 |
| zyga | jdstrand hey | 11:57 |
| zyga | jdstrand please have a look at 4765 again | 11:57 |
| zyga | I can split it if that makes it easier | 11:57 |
| zyga | I just fired one more run and it shoud *fingers crossed* work | 11:57 |
| mup | PR snapd#4780 closed: snap: add autostart app property <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4780> | 11:58 |
| mborzecki | Chipaca: guess what failed https://paste.ubuntu.com/p/G2wTbP4f6r/ SquashfsTestSuite.TestBuildDate | 12:01 |
| mvo | ackk: hm, maybe it was not build or something, let me check | 12:03 |
| mup | PR snapd#4781 opened: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781> | 12:06 |
| mborzecki | mvo: have you looked into adding some shlexer to our codebase? | 12:09 |
| sborovkov | is there some env variable that has core version? Or how can I find out snapd version from my own snap? | 12:14 |
| zyga | sborovkov there's no such variable | 12:15 |
| zyga | why do you need to know the version of snapd? | 12:15 |
| zyga | there are a few ways perhaps but not sure why you'd want to know that | 12:15 |
| sborovkov | well we want to report node info | 12:20 |
| sborovkov | in case there are issues on the customer's device | 12:20 |
| sborovkov | having snapd version would help | 12:20 |
| zyga | I think you can get it the same way snap --version does | 12:20 |
| zyga | there's an API endpoint for this | 12:20 |
| zyga | I think it is /v2/system-info | 12:21 |
| zyga | just GET that | 12:21 |
| zyga | over the snapd socket | 12:21 |
| sborovkov | ok thanks | 12:22 |
| mborzecki | Chipaca: bad news, there does not appear to be any no timezone information in squashfs files | 12:23 |
| mborzecki | Chipaca: well, at least in unsuqashfs -s output | 12:24 |
| * zyga small break | 12:32 | |
| pedronis | mborzecki: does it respect TZ if set ? | 12:35 |
| pedronis | that might be a way out | 12:35 |
| mborzecki | pedronis: yes, i'm fixing it right now | 12:35 |
| mup | PR snapd#4776 closed: Do not auto-import from loop/ram devices <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4776> | 12:40 |
| Chipaca | mborzecki: gah | 12:42 |
| Chipaca | mborzecki: yes, squashfs times are always local | 12:42 |
| Chipaca | so there's a bug in the test | 12:43 |
| mborzecki | Chipaca: i'm opening a PR in a minute | 12:43 |
| ackk | mvo, AFAICS LP did build it and publish, not sure what happened thouhg | 12:43 |
| Chipaca | mborzecki: ah ok | 12:43 |
| mup | PR snapd#4782 opened: snap/squashfs: set timezone when calling unsquashfs to get the build date <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4782> | 12:44 |
| mborzecki | Chipaca: ^^ | 12:44 |
| Chipaca | ogra_: you around? | 12:44 |
| mborzecki | linode is down? https://paste.ubuntu.com/p/4v2qHSsnV9/ | 12:45 |
| Chipaca | mborzecki: silly question, does it work if you _just_ set Env to TZ=UTC? | 12:45 |
| mborzecki | Chipaca: without append(os.Environ()..) ? | 12:45 |
| Chipaca | mborzecki: yep | 12:46 |
| mborzecki | let me check | 12:46 |
| Chipaca | mborzecki: that's a very clever way of fixing it, we should do it in Walk as well | 12:46 |
| mborzecki | Chipaca: yeah, just TZ=.. works too | 12:47 |
| Chipaca | mborzecki: hmm | 12:48 |
| Chipaca | mborzecki: so, the way Walk handles it is by doing time.ParseInLocation(..., time.Local) | 12:48 |
| Chipaca | mborzecki: see parseTime in snap/squashfs/stat.go | 12:49 |
| mborzecki | Chipaca: right, that might be even nicer than enforcing TZ | 12:49 |
| Chipaca | well, maybe | 12:50 |
| Chipaca | what happens if you're just before DST | 12:50 |
| Chipaca | such that time.Local and unsquashfs have different opinions on what side of the change you are | 12:50 |
| pedronis | TZ=UTC and ParseInLocation(time.UTC) then | 12:50 |
| pedronis | or is that the default for Parse ? | 12:51 |
| Chipaca | it is | 12:51 |
| mborzecki | hm time.Parse(time.ANSIC..) implies UTC | 12:51 |
| jdstrand | mvo: hey. re 4766> no. nothing was done with snapFromSenderImpl (that's also the bit I asked you to look at) | 12:52 |
| mborzecki | for that matter, any time.. format that lacks timezone placeholder implies UTC, i ca make it explicit though, Chipaca pedronis what do you think? | 12:52 |
| zyga | jdstrand hey! | 12:52 |
| jdstrand | hey zyga :) | 12:53 |
| zyga | jdstrand https://github.com/snapcore/snapd/pull/4765 may be ready, I am looking at fixing the bug in /etc and other similar places | 12:53 |
| jdstrand | looking at 4765 now | 12:53 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 12:53 |
| zyga | thanks! | 12:53 |
| pedronis | mvo: mborzecki: any reason not to fix the todo about passing MaxDuration into timeutil.Next , I need to reuse maxDuration in snapstate so I would like to do that change | 12:53 |
| Chipaca | i like the garters-and-belt approach of TZ=UTC and Parse | 12:53 |
| jdstrand | zyga: cool | 12:53 |
| zyga | jdstrand it ended up big, feel free to request extra tests and other refactorings | 12:53 |
| Chipaca | (Parse picks up location from the value but falls back to UTC, so there's an extra layer of strapping there) | 12:54 |
| jdstrand | zyga, mvo: if you could look at PR 4779, that would be great :) | 12:54 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 12:54 |
| zyga | jdstrand ack | 12:54 |
| Chipaca | mborzecki: can you do the same thing to the one over in stat? | 12:54 |
| pedronis | mvo: mborzecki: I'm talking about this: https://github.com/snapcore/snapd/blob/master/timeutil/schedule.go#L401 | 12:54 |
| mborzecki | pedronis: go ahead as far as i'm concerned, iirc niemeyer wanted get rid of it too | 12:55 |
| jdstrand | pedronis: hey, curious if you were going to backport the go vet fix to 2.32 for: overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields | 12:56 |
| mborzecki | Chipaca: just Parse(), no InLocation? | 12:57 |
| jdstrand | exit status 1I saw you fixed it in master (thanks!) | 12:57 |
| jdstrand | err | 12:57 |
| pedronis | jdstrand: I can if needed | 12:57 |
| mup | PR snapd#4775 closed: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4775> | 12:57 |
| Chipaca | mborzecki: yes | 12:57 |
| jdstrand | I saw you fixed it in master (thanks!) | 12:57 |
| jdstrand | pedronis: I mean, it would be handy for me (I develop in a 16.04 container), but I don't know who else is affected | 12:58 |
| jdstrand | I can work around it | 12:58 |
| pedronis | jdstrand: np, I just didn't bothered because it didn't seem to affect anything else | 12:58 |
| pedronis | but it's useful I can | 12:58 |
| pedronis | there's also a flaky test fix that I was asked to backport | 12:58 |
| jdstrand | like I said, it would be to me, but I don't know how hard the fix is and would hate to add more to your plate (I was mostly asking out of curiosity). I can work around it | 12:59 |
| jdstrand | so I'll leave it up to you | 12:59 |
| pedronis | jdstrand: I'm a bit juggling many things (aren't we all), but I'll look into it today | 13:01 |
| mvo | sborovkov: hey, you mentioned a boot failure right? do you have more details like what the fs looks like (post-mortem) or even give us access to a copy of the fs? | 13:02 |
| jdstrand | pedronis: if you get to it, thanks. if not, that's totally fine and thank you for considering it :) | 13:04 |
| mborzecki | Chipaca: pushed | 13:10 |
| zyga | jdstrand how do you feel about that hardening PR? | 13:13 |
| Chipaca | pedronis: I fixed the comment on #4738 fwiw | 13:17 |
| mup | PR #4738: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <https://github.com/snapcore/snapd/pull/4738> | 13:17 |
| jdstrand | zyga: I'm still looking at it | 13:18 |
| sborovkov | mvo: so this happens after snapd updates from 2.31 to 2.31.1 here | 13:21 |
| sborovkov | sure I have what fs looks like | 13:21 |
| sborovkov | give me few mins to download that | 13:21 |
| mvo | sborovkov: ohhhhh | 13:21 |
| mvo | sborovkov: that is interessting | 13:21 |
| sborovkov | https://www.dropbox.com/s/gx17h6emu9uott5/corrupt-disk.img.7z?dl=0 | 13:22 |
| mvo | sborovkov: we have an independent report about an upgrade issue on bionic (but only there) | 13:22 |
| sborovkov | this is the dump of the SD card | 13:22 |
| mvo | sborovkov: \o/ thank you | 13:22 |
| sborovkov | I also have an image where this reproduces :) | 13:23 |
| sborovkov | I managed to reproduce it 3 times today | 13:23 |
| mvo | sborovkov: can I haz? | 13:23 |
| mvo | sborovkov: I'm really keen to get to the bottom of this | 13:23 |
| sborovkov | yeah sure | 13:23 |
| sborovkov | but you will need ssh assertion to login to that system | 13:24 |
| sborovkov | https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-09-bbc27f2.img.zip.md5 | 13:24 |
| sborovkov | this is the image | 13:24 |
| sborovkov | so today I did this few times - flashed it out. Let it initialize | 13:24 |
| mvo | sborovkov: ok, let me first look at the broken one | 13:24 |
| mvo | sborovkov: maybe that gives me some clues | 13:24 |
| sborovkov | it works great after reboots | 13:24 |
| sborovkov | as soon as I do snap refresh core | 13:24 |
| sborovkov | it fails at the next reboot | 13:25 |
| sborovkov | or one after next | 13:25 |
| mvo | sborovkov: so this is 2.31 -> 2.31.1 ? | 13:25 |
| sborovkov | yes | 13:25 |
| sborovkov | image was created from stable 1 week ago | 13:25 |
| mvo | ta | 13:25 |
| sborovkov | image is created by ubuntu-disk-image with 2 extra snaps | 13:26 |
| sborovkov | one is our own snap. another one is udisks. | 13:26 |
| * kalikiana lunch | 13:32 | |
| sborovkov | mvo: I also can flash another one of that and run some logging during/after core update if needed | 13:34 |
| sborovkov | but only today as I have flight to Shanghai tomorrow | 13:34 |
| mvo | sborovkov: I need to travel soon too so today is definitely my preference | 13:38 |
| mvo | sborovkov: I am looking at the diff right now | 13:39 |
| niemeyer | sborovkov: ping | 13:44 |
| niemeyer | sborovkov: Do you have a moment for a call with some of us? Would be nice to have a quick conversation with more bandwidth | 13:45 |
| niemeyer | sborovkov: In 45 minutes maybe, if that works for you (30 mins past the hour) | 13:46 |
| mvo | I just tested a 2.31->2.31.1 on amd64 and that went fine, I'm trying on armhf now | 13:50 |
| jdstrand | zyga: https://github.com/snapcore/snapd/pull/4765#pullrequestreview-100766399 | 13:54 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 13:54 |
| sborovkov | niemeyer, sure | 13:54 |
| zyga | Thank you! | 13:54 |
| zyga | looking | 13:54 |
| jdstrand | zyga: I have an appt in a few minutes and will step away for a little bit, but will be back after not too long | 13:54 |
| zyga | ok | 13:55 |
| zyga | thank you for letting me know | 13:55 |
| mvo | ok, 2.31 -> 2.31.1 on pi3 is also fine | 14:05 |
| * mvo scratches head | 14:05 | |
| sborovkov | mvo, another thing that we noticed is that it does not fail all the time. One of test nodes is still running, but for all devices that are broken we did insert the USB stick to RPI (in my case for assertion with ssh). | 14:08 |
| mup | PR snapd#4782 closed: snap/squashfs: set timezone when calling unsquashfs to get the build date <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4782> | 14:10 |
| mvo | sborovkov: thanks, that is a very useful data-point, let me try this too. maybe some bad interaction with the udisk snap or something like this | 14:12 |
| === ikey is now known as ikey|busy | ||
| mup | PR snapd#4783 opened: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4783> | 14:24 |
| mup | PR snapd#4784 opened: asserts: use a timestamp for the assertion after the signing key has been created (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4784> | 14:25 |
| pedronis | mvo: zyga: jdstrand: I created a couple of trivial cherry-picks for 2.32 ^^^ | 14:25 |
| zyga | kk | 14:26 |
| sborovkov | niemeyer, i am ready :) | 14:30 |
| niemeyer | sborovkov: Let's go.. let me get a link | 14:30 |
| niemeyer | sborovkov, mvo, zyga: https://hangouts.google.com/hangouts/_/canonical.com/debug-session | 14:32 |
| cachio__ | mvo, hey | 14:33 |
| cachio__ | mvo, dod you already know when the 2.32 rc2 is comming? | 14:34 |
| mvo | cachio__: on hold right now, zyga found a critical bug with layouts | 14:37 |
| zyga | I will propose a fix for this later today | 14:37 |
| cachio__ | perfect | 14:38 |
| cachio__ | zyga, it is related with the error on the test that I sent you yesterday? | 14:38 |
| cachio__ | i also saw it on linode today | 14:38 |
| zyga | not sure which one was that | 14:38 |
| zyga | about /etc, yes | 14:38 |
| zyga | if not about /etc then no | 14:38 |
| cachio__ | yes | 14:38 |
| cachio__ | that one | 14:38 |
| cachio__ | nice | 14:38 |
| cachio__ | zyga, so | 14:39 |
| cachio__ | thanks for fixing it | 14:39 |
| * Chipaca afk for a bit | 14:47 | |
| mup | PR snapcraft#1978 opened: ci: switch to stable lxd and unconfined containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1978> | 14:55 |
| zyga_ | popey who is managing sublime-text-3 snap? | 15:08 |
| zyga_ | I'd love edge to have the more recent dev build | 15:08 |
| zyga_ | (dev build has a feature I like) | 15:08 |
| popey | https://github.com/snapcrafters/sublime-text | 15:10 |
| popey | pull requests welcome ;) | 15:10 |
| zyga_ | Chipaca should snap list show the size of the snap? | 15:14 |
| Chipaca | zyga_: it doesn't | 15:14 |
| zyga_ | I know | 15:14 |
| zyga_ | I was thinking what if it did | 15:14 |
| Chipaca | zyga_: let's talk at the sprint | 15:15 |
| sborovkov | mvo: what's your pgp key? will send you an assertion encrypted | 15:15 |
| zyga_ | Chipaca sounds good | 15:15 |
| zyga_ | sborovkov https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0xDA6C6754D8887626CD06A12898CABB3ABD4CA59E | 15:16 |
| mvo | sborovkov: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x98CABB3ABD4CA59E | 15:19 |
| * Chipaca really afk this time | 15:22 | |
| sborovkov | mvo: https://fd-files-production.s3.amazonaws.com/private/190661/25604/iY9HQ7y0B_z3z_NPI7WKhA?X-Amz-Expires=300&X-Amz-Date=20180302T152436Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIA2QBI5WP5HA3ZEA/20180302/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=e3f124f18e208640518bf87e62cdcd31b2ab6bca8ad59eb926ad96c17b207796 | 15:24 |
| sborovkov | and this is link to image - https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-20.img.zip | 15:25 |
| zyga-ubuntu | hmm hm | 15:31 |
| mvo | sborovkov: downloading the image now | 15:31 |
| mvo | sborovkov: the other link is expired, please jsut mail it to me | 15:31 |
| mvo | zyga-ubuntu: any clues? | 15:32 |
| zyga-ubuntu | mvo: no, looking at the raw image | 15:32 |
| mvo | zyga-ubuntu: yeah I find it interessting that only hte old core is on the image | 15:32 |
| mvo | zyga-ubuntu: no trace of the new one | 15:32 |
| mvo | zyga-ubuntu: I was also browsing the logs | 15:32 |
| mup | PR snapd#4785 opened: tests: moving ubuntu core from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4785> | 15:35 |
| jdstrand | mvo: does PR 4779 need a second +1? I see you fixed up an unrelated merge issue and the tests now pass | 15:40 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 15:40 |
| zyga-ubuntu | mvo: after mounting p1 I see that there are two "uboot.env" files | 15:40 |
| zyga_ | -rwxr-xr-x 1 root root 131072 lut 28 13:34 uboot.env* | 15:41 |
| zyga_ | -rwxr-xr-x 1 root root 131072 lut 28 13:34 uboot.env* | 15:41 |
| === zyga_ is now known as zyga | ||
| mvo | jdstrand: I think its fine to land, I wanted to have a closer look but $things happend to me :/ | 15:41 |
| mvo | zyga: how is that even possible | 15:42 |
| * mvo looks | 15:42 | |
| zyga-ubuntu | mvo: no idea, just mount p1 and see | 15:42 |
| zyga-ubuntu | maybe we can use some low-level fat tool to list and read that file | 15:42 |
| zyga-ubuntu | (there is such a thing, I will look at that) | 15:42 |
| mvo | zyga-ubuntu: I see it too | 15:42 |
| mvo | zyga-ubuntu: hm - no error from fsck.vfat (well, dirty bit set but no real error) but still two uboot.env files | 15:44 |
| zyga | this is from fatcat | 15:44 |
| zyga | https://pastebin.ubuntu.com/p/mnhDXb7jXP/ | 15:44 |
| mvo | sborovkov: I have things ready here, just need the ssh assertion, will step out for some minutes but will read scrollback | 15:44 |
| mvo | zyga looking | 15:45 |
| zyga | there's a lower-case and an upper-case version of that file | 15:45 |
| zyga | as _separate_ files | 15:45 |
| mvo | zyga haha, of course | 15:45 |
| zyga | one is from 1980 | 15:45 |
| zyga | and another one from 2018 | 15:45 |
| zyga | hold on, I think I can remount the fs to see them | 15:45 |
| mvo | zyga is it possible to diff them | 15:45 |
| zyga | yes, they are identical | 15:46 |
| zyga | this is probably not perfect but doesn't look like a bug | 15:47 |
| zyga-ubuntu | mvo: core snap is at revision 4020, nothing else is around | 15:49 |
| jdstrand | zyga: saw your comments on PR 4765. I responded and think with just the small tweak you mentioned (though see my comment) that it can land | 15:49 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 15:49 |
| mvo | zyga-ubuntu: yeah, but uboot.env has snap_try_core=41.. | 15:49 |
| mvo | zyga-ubuntu: right? which is very strange | 15:50 |
| zyga-ubuntu | jdstrand: thank you, I will look shortly | 15:50 |
| zyga-ubuntu | jdstrand: I'm in the same place that mvo debugs | 15:50 |
| jdstrand | zyga: well, it sounded like you might want to make another tweak for that redundant-looking rule-- I'll let you decide how to handle that | 15:50 |
| zyga-ubuntu | jdstrand: do you think there's something to harden further? | 15:50 |
| zyga-ubuntu | (apart from this PR) | 15:50 |
| jdstrand | s/rule/line of code/ | 15:50 |
| zyga-ubuntu | jdstrand: yes, I forgot to change that, I will look at your feedback and push another round | 15:50 |
| zyga-ubuntu | mvo: the snap in the cache is core with snapd 2.31.1 | 15:52 |
| jdstrand | zyga-ubuntu: re more hardening> this is really nice. nothing else would be needed for 2.32 imho. we may want to tweak later, but this is way better than 2.3*1*. really liking this | 15:54 |
| zyga-ubuntu | jdstrand: woot, that's great :-) | 15:55 |
| zyga-ubuntu | I will go and check the feedback in a moment | 15:55 |
| jdstrand | zyga-ubuntu: yes it is. thank you :) | 15:56 |
| zyga-ubuntu | mvo: I'm looking at state.json, nothing out of the oridinary yet | 15:56 |
| jdstrand | zyga-ubuntu: note I think you missed this comment: https://github.com/snapcore/snapd/pull/4765/files#r171846644 (just a comment addition) | 15:57 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 15:57 |
| zyga-ubuntu | mvo: so I see the change where we wanted to do a refresh to 4114 | 15:57 |
| jdstrand | at least, I didn't see a commit, thumbs up or a comment | 15:58 |
| zyga-ubuntu | jdstrand: I saw that, I was wondering how to do that since the comment is from a totally generic piece of code | 15:58 |
| jdstrand | (just mentioning it in the interest of time) | 15:58 |
| mup | Bug #1752916 opened: Desktop interface should allow accessing to recent files and xdg dirs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1752916> | 15:58 |
| zyga-ubuntu | jdstrand: thank you | 15:58 |
| jdstrand | zyga-ubuntu: yeah, I know. that's why I said a code comment would be sufficient instead of contorting to create a policy comment | 15:58 |
| pedronis | mborzecki: I'm getting this from run-checks recently: [[: not found it seems you added that ... afaict on ubuntu that is run with dash , not bash | 15:59 |
| jdstrand | zyga-ubuntu: "// This will generate rules that expected to be in the per-snap mount namespace" or some such | 15:59 |
| jdstrand | zyga-ubuntu: your call. I don't mind where the comment is and don't want you to have to add undue complexity | 16:00 |
| jdstrand | zyga-ubuntu: maybe wording the policy comment to have 'may' in it works. anyway, think about it, but not too hard :) | 16:01 |
| jdstrand | zyga-ubuntu: you know, we lost all specific policy comments such as: https://github.com/snapcore/snapd/pull/4765/files#diff-a34e166c5b3016c122430c5884f41e9bL588. I wonder if it makes sense to have a code comment that coherently summarizes what the template and snippet policy intends to achieve the call it a day. | 16:04 |
| mup | PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765> | 16:04 |
| jdstrand | zyga-ubuntu: ie, taking all the contextual policy comments that were removed, rewording and smoothing the language in a code comment | 16:05 |
| zyga-ubuntu | jdstrand: right | 16:05 |
| zyga-ubuntu | jdstrand: do you want to write that? :-) You are much better at wordsmith that intersects with policy | 16:06 |
| zyga-ubuntu | mvo: I put this on hold to finish the branch I'm discussing with jamie | 16:06 |
| jdstrand | zyga-ubuntu: yeah I can do that | 16:06 |
| pedronis | Chipaca: around? | 16:06 |
| jdstrand | zyga-ubuntu: I'm going to pivot to steam-support and then circle back a bit later | 16:06 |
| zyga-ubuntu | jdstrand: ok, I'll go through your comments and before I push another batch I will check your comments again | 16:07 |
| zyga-ubuntu | jdstrand: sounds good, thank you | 16:07 |
| zyga-ubuntu | IRC from a phone is interesting | 16:08 |
| Chipaca | pedronis: yes | 16:09 |
| Chipaca | git st | 16:09 |
| Chipaca | why no head tracking | 16:09 |
| mvo | zyga-ubuntu: ok | 16:10 |
| pedronis | Chipaca: I'm a bit confused why is not failing more but https://github.com/snapcore/snapd/pull/4743/files added a bashism ([[) to run-checks | 16:10 |
| mup | PR #4743: packaging/arch: sync with snapd/snapd-git from AUR <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4743> | 16:10 |
| pedronis | Chipaca: bun run-checks is run with dash (at least on default with the usual sh) | 16:10 |
| sborovkov | mvo: did you manage to decrypt it? | 16:10 |
| Chipaca | pedronis: wow | 16:10 |
| pedronis | Chipaca: we should just /sh/bash in the #! I suppose | 16:11 |
| pedronis | unless there was a reason to use dash | 16:11 |
| Chipaca | pedronis: no strong reason | 16:12 |
| mvo | sborovkov: yes, for some reason it wasn't imported on the system though, maybe a faulty usb-stick. I named it auto-import.assert and put it on the root of the usb-stick, thats enough iirc? | 16:12 |
| Chipaca | pedronis: beyond that if bash is not needed, why require it | 16:12 |
| Chipaca | pedronis: i'll fix | 16:12 |
| sborovkov | mvo: it should be inserted after system starts up | 16:12 |
| sborovkov | that's all I think | 16:13 |
| pedronis | Chipaca: it's the [[ toward the end: ./run-checks: 250: ./run-checks: [[: not found | 16:13 |
| Chipaca | pedronis: yep yep | 16:13 |
| pedronis | it got me staring/puzzled for a bit, even wondering if my disk was corrupted or what | 16:13 |
| Chipaca | pedronis: sorry :-( | 16:14 |
| mvo | sborovkov: thanks, I try again with a different stick | 16:14 |
| mup | PR snapd#4786 opened: run-checks: remove accidental bashism <Created by chipaca> <https://github.com/snapcore/snapd/pull/4786> | 16:15 |
| Chipaca | pedronis: ^ | 16:15 |
| pedronis | Chipaca: also you had a comment about the line before ? | 16:16 |
| pedronis | that I don't if it was addressed | 16:16 |
| Chipaca | pedronis: it was | 16:16 |
| Chipaca | although... maybe that's a bashism as well | 16:16 |
| Chipaca | drat, let me look | 16:16 |
| Chipaca | pedronis: not a bashism | 16:17 |
| Chipaca | pedronis: all the :- := etc have a :-less version that only checks for unset | 16:17 |
| Chipaca | pedronis: “use of the colon in the format results in a test for a parameter that is unset or null; omission of the colon results in a test for a parameter that is only unset.” | 16:18 |
| Chipaca | pedronis: (that's from 'man dash'; bash says something similar; also, shellcheck said it was ok \o/) | 16:19 |
| pedronis | Chipaca: it's ok, I still wonder if it's worth the trouble to keep this one as dash | 16:19 |
| pedronis | seems we have a mixture | 16:20 |
| Chipaca | pedronis: everything spread-ish is bash, everything complete-ish is bash | 16:20 |
| pedronis | everything packaging is sh | 16:21 |
| pedronis | or so it seems | 16:21 |
| Chipaca | pedronis: that's a requirement afaik, but not sure | 16:21 |
| pedronis | likely so | 16:21 |
| mvo | yeah its a software requirement - packaging should be sh, but we could use bash would just be odd | 16:23 |
| mup | PR snapd#4777 closed: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4777> | 16:30 |
| mborzecki | pedronis: yes, sorry for that, Chipaca thanks for fixing this | 16:59 |
| pedronis | mvo: seems something backported one of my tests rename to 2.32 and now release/2.32 is red | 16:59 |
| pedronis | mvo: store/store_test.go:2563: undefined: storeTestSuite | 17:01 |
| mup | PR snapcraft#1978 closed: ci: switch to stable lxd and unconfined containers <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1978> | 17:02 |
| pedronis | Chipaca: seems to be your change about getStructField | 17:03 |
| pedronis | it could not be just cherry-picked | 17:03 |
| pedronis | because of renames I did | 17:03 |
| mup | PR snapd#4786 closed: run-checks: remove accidental bashism <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4786> | 17:03 |
| Chipaca | pedronis: D: | 17:03 |
| pedronis | but it was | 17:04 |
| pedronis | and now 2.32 is red | 17:04 |
| Chipaca | i can fix | 17:04 |
| Chipaca | where's 2.32 at | 17:04 |
| pedronis | in flux? | 17:04 |
| pedronis | Chipaca: release/2.32 | 17:04 |
| mvo | pedronis: yeah, there is a fix as part of a jamie PR | 17:05 |
| Chipaca | ah! | 17:05 |
| mvo | pedronis: I noticed this afternoon | 17:05 |
| Chipaca | ok | 17:05 |
| mvo | https://github.com/snapcore/snapd/pull/4779 | 17:05 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 17:05 |
| pedronis | isn't that one undecided? | 17:05 |
| pedronis | I think we probably want to fix it alone | 17:06 |
| pedronis | unless that one goes in now | 17:06 |
| Chipaca | ah, i'd reviewed this one for master | 17:08 |
| Chipaca | +1'ing | 17:08 |
| mup | PR snapd#4787 opened: strutil: introduce UnsafeString and UnsafeParagraph <Created by chipaca> <https://github.com/snapcore/snapd/pull/4787> | 17:08 |
| Chipaca | mvo: pedronis: #4779 gtg | 17:08 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 17:08 |
| mvo | Chipaca: I think so | 17:10 |
| * kalikiana wrapping up for the week | 17:19 | |
| * ikey|busy has literally been wrapping up all week | 17:19 | |
| ikey|busy | jdstrand, if you're around and before the EOW kicks in , where do we stand on that PR? | 17:19 |
| pstolowski | eow.. see you all on the sprint o/ | 17:22 |
| jdstrand | ikey|busy: I've literally been looking at it for the last hour and a half :) | 17:25 |
| ikey|busy | sorry XD | 17:26 |
| jdstrand | ikey|busy: no worries. I thought that I could do it yesterday, so I was owed a question on when :) | 17:27 |
| * ikey|busy just likes chasing | 17:27 | |
| ikey|busy | :3 | 17:27 |
| pedronis | jdstrand: could you merge #4779 | 17:27 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 17:27 |
| jdstrand | pedronis: I plan to after the steam-support PR review. I want to check one thing with PR 4779 before I do | 17:29 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 17:29 |
| pedronis | jdstrand: #4783 is red and needs the fix that mvo piggy-backed on #4779 | 17:33 |
| mup | PR #4783: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4783> | 17:33 |
| mup | PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 17:33 |
| jdstrand | pedronis: almost done with steam-support. I'm coming! :) | 17:53 |
| ikey|busy | *cue runaround sue background track* | 17:58 |
| jdstrand | ikey|busy: ok, done. I'll be sprinting next week, but it is an engineering sprint so I'll be able to keep an eye on the PR. thanks for the updates! | 18:00 |
| ikey|busy | i see no existing open questions | 18:00 |
| jdstrand | ikey|busy: go here: https://github.com/snapcore/snapd/pull/4538#pullrequestreview-100828987 | 18:01 |
| mup | PR #4538: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538> | 18:01 |
| ikey|busy | also that concat didnt work for me | 18:01 |
| ikey|busy | go cried | 18:01 |
| ikey|busy | thats why it is like it is now | 18:01 |
| ikey|busy | btw we *removed* the allow-installation line already cuz that was what was breaking core... | 18:02 |
| jdstrand | ikey|busy: I think we can make that work somehow. just comment that you tried, it didn't work, then we can look at it | 18:02 |
| ikey|busy | https://github.com/snapcore/snapd/pull/4538/commits/6006da7a5d78f878c95dfbb48800a2a99c8e6f27 | 18:02 |
| mup | PR #4538: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538> | 18:02 |
| ikey|busy | (also, 4.15 kernel :P) | 18:03 |
| jdstrand | ikey|busy: your allow-installation was different than mine | 18:04 |
| ikey|busy | ok - but just as a headsup half of this stuff isnt documented at all - or very poorly | 18:04 |
| ikey|busy | so a lot of this is copy paste | 18:04 |
| ikey|busy | and capability sys_ptrace *is* needed, thats why i aded it | 18:04 |
| ikey|busy | it used to kill the processes before :) | 18:05 |
| ikey|busy | ill fix up the rest of it and see whatcha think of it next week | 18:05 |
| ikey|busy | also please note you've reopened some old comments that aren't valid | 18:06 |
| jdstrand | ikey|busy: can you test without it? not having the 'ptrace' syscall kills. lack of 'capability sys_ptrace,' in apparmor would not kill | 18:06 |
| ikey|busy | like [0-9] stuff | 18:06 |
| ikey|busy | we tried that stuff already months ago | 18:06 |
| ikey|busy | apparmor imitates fnmatch | 18:06 |
| ikey|busy | isn't quite there | 18:06 |
| ikey|busy | and i *added* the capability because it crashed before | 18:06 |
| ikey|busy | this is questions 3+ months after the bug | 18:06 |
| jdstrand | I don't know what happened months ago or how the rules were added in which order | 18:06 |
| jdstrand | as in, you probably had a seccomp kill, so you added ptrace syscall | 18:07 |
| ikey|busy | ya | 18:07 |
| ikey|busy | wasnt apparmor doing the murdering | 18:07 |
| ikey|busy | and that was pre-yama too | 18:07 |
| ikey|busy | so nothing has happened to make that any looser | 18:07 |
| ikey|busy | also the notion that this snap is only being used on solus is flawed | 18:07 |
| ikey|busy | no point in making the snap if its solus specific | 18:08 |
| jdstrand | please feel free to respond to my comments in the PR so everyone can benefit | 18:08 |
| jdstrand | the comment about solus specific was *today* it is | 18:08 |
| jdstrand | and *today* this is where this is being tested | 18:09 |
| ikey|busy | no it isnt - its being tested on ubuntu and arch | 18:09 |
| ikey|busy | and *Developed* on solus | 18:09 |
| jdstrand | *tomorrow* we need to add the 4.8 kernel stuff and likely things to make this work on ubuntu | 18:09 |
| ikey|busy | i dont know where these assertions are coming from | 18:09 |
| jdstrand | ikey|busy: I'm basing this on what I thought I remembered from our conversations | 18:09 |
| jdstrand | ikey|busy: if it is wrong, correct me in the PR | 18:10 |
| * mvo loves that he can just do "snap watch 4" and see how the auto-refresh is doing | 18:10 | |
| ikey|busy | jdstrand, you'll forgive me if i seem a bit frustrated in repeating myself since before december. | 18:10 |
| jdstrand | ikey|busy: but I'm trying to unblock this interface for you | 18:10 |
| jdstrand | ikey|busy: I'm sorry, there is a tremendous amount of context for this PR. I'm doing the best I can | 18:11 |
| ikey|busy | ill make the /necessary/ edits over the weekend as im assuming you'll not be around before the weekstart | 18:11 |
| ikey|busy | (like normal hoomans) | 18:11 |
| ikey|busy | is hardware-observe something autoconnectable? | 18:12 |
| ikey|busy | (with forum request ofc.) | 18:12 |
| jdstrand | ikey|busy: please correct my statement that this is intended to work on ubuntu right away, cause we may need to do something about 4.8 right away | 18:12 |
| jdstrand | ubuntu/arch/whatever | 18:12 |
| ikey|busy | jdstrand, well its "universal" applications, right? | 18:12 |
| jdstrand | I think ubuntu is the only one with affected kernels though | 18:12 |
| jdstrand | ikey|busy: of course. but trying to do things in steps | 18:12 |
| ikey|busy | we can keep initial scope to 4.9+ | 18:13 |
| ikey|busy | and maybe add a uname check in LSI itself | 18:13 |
| ikey|busy | throwing a big warning for pre 4.9 usage | 18:13 |
| jdstrand | ikey|busy: if it happened to be true that this was tested on solus and not on ubuntu, then I would still allow the PR to land | 18:13 |
| jdstrand | ikey|busy: and others interested in ubuntu could improve the interface for it | 18:13 |
| jdstrand | ikey|busy: you're saying that isn't the case (I thought it was), so correct me in the PR | 18:14 |
| ikey|busy | im saying we target all snap enabled distros and primary development happens on solus | 18:14 |
| jdstrand | ikey|busy: don't add 4.9 stuff to the PR yet. niemeyer has thoughts and I have an open question to him | 18:14 |
| ikey|busy | not the PR | 18:14 |
| jdstrand | ikey|busy: I know what your saying | 18:14 |
| ikey|busy | to LSI | 18:14 |
| jdstrand | if you do that in LSI, that's fine, but a potentially bad experience for users | 18:15 |
| jdstrand | the right place is in snapd | 18:15 |
| ikey|busy | occurs to me life would be far simpler had feral not used ptrace | 18:15 |
| jdstrand | ikey|busy: what your saying wasn't what I thought was the case when I wrote the comment. so, again, please correct me in the PR so the others looking at the PR have the correct context | 18:15 |
| ikey|busy | assuming i send you fixed on Monday for the PR, likelihood of merge next week? | 18:16 |
| jdstrand | ikey|busy: don't get hung up on the 4.9 stuff. I don't think it should block the PR | 18:16 |
| ikey|busy | obviously testing is limited to anyone who then has snapd with steam-support interface | 18:16 |
| ikey|busy | in terms of scope limitations | 18:16 |
| mvo | idle though: when the system is seeding it would be nice if "snap list" would show a better message than: "no snaps installed yet" | 18:17 |
| mvo | seeding is really slow on arm | 18:17 |
| jdstrand | ikey|busy: I expect light iteration after the fixes on monday. I don't see why it couldn't be approved next week | 18:17 |
| * mvo notices that `snap changes` while seeding takes a long time, like a minute or so without any user visible feedback | 18:18 | |
| ikey|busy | general difference between approved vs merged? | 18:18 |
| jdstrand | ikey|busy: another option with 4.9 is that since I think Ubuntu is the only kernel that is affected, we patch our kernels | 18:18 |
| * mvo thinks we need to improve the UX on slow hardware | 18:18 | |
| ikey|busy | jdstrand, backporting the ptrace changes..? | 18:18 |
| jdstrand | yes | 18:18 |
| jdstrand | it is just an ordering problem | 18:19 |
| ikey|busy | sure | 18:19 |
| jdstrand | small fix | 18:19 |
| ikey|busy | but time and goals and sequence | 18:19 |
| jdstrand | difference between approved and merged is that it will need 2 people to approve to merge. I can say I can approve. I would think zyga would be able to, but I'm not his boss, so.. | 18:20 |
| jdstrand | it should be able to be merged | 18:20 |
| ikey|busy | sure | 18:20 |
| ikey|busy | just wanting to understand the processing is all | 18:20 |
| jdstrand | I'm not the project lead, so I can't commit to merged :) | 18:20 |
| ikey|busy | mainly so i can sorta juggle my own time for next week too | 18:20 |
| ikey|busy | i sorta have a distro to run at the same time :P | 18:20 |
| jdstrand | ikey|busy: now that we have the agreed upon approach, things can move fast. you did the PR, I did the big initial review. we can iterate fast | 18:21 |
| ikey|busy | much appreciated, ill take a spork to it over the weekend and make sure any remaining items are ticked off | 18:21 |
| jdstrand | I will try to be responsive to the PR to keep it moving | 18:21 |
| jdstrand | yes, and please correct me if I mispoke | 18:22 |
| jdstrand | (in the pr) | 18:22 |
| ikey|busy | ya it can wait til monday, just figured id ask those bits while you were still reachable | 18:22 |
| jdstrand | ikey|busy: I'll try to be on irc next week. it is just tricky at a sprint. but like I said, it is an *engineering* sprint, so I will have time to respond | 18:23 |
| jdstrand | and review | 18:23 |
| ikey|busy | yeah no worries ill just look out for the pings on github | 18:23 |
| jdstrand | perfect | 18:23 |
| ikey|busy | as long as i roughly know what direction things are moving in and what timescale,then i can adjust to it | 18:24 |
| ikey|busy | all comes down to communication :P | 18:24 |
| ikey|busy | then im fine | 18:24 |
| jdstrand | ikey|busy: they are moving in a positive direction quickly now :) | 18:24 |
| ikey|busy | aye, once its merged then its just add "missing" bits | 18:24 |
| jdstrand | and yes, we'll keep discussing int he PR | 18:24 |
| ikey|busy | like improving joystick | 18:24 |
| jdstrand | ikey|busy: ok, so it sounds like joystck will be a different pr (fine) | 18:24 |
| ikey|busy | yeah i need the groundwork in first | 18:25 |
| jdstrand | the other 'move these 5 rules to interface foo' don't have to be separate | 18:25 |
| jdstrand | oh right | 18:25 |
| ikey|busy | need folk to be able to test the snap before we can extend it :D | 18:25 |
| ikey|busy | and devmode cripples it | 18:25 |
| jdstrand | I meant to say, anything that isn't autoconnected that needs to be, we'll auto-conect via snap declaration | 18:25 |
| ikey|busy | ah yeah | 18:25 |
| jdstrand | so, hardware-observe, joystick, etc | 18:25 |
| ikey|busy | joystick, hardwa... | 18:25 |
| ikey|busy | :D | 18:25 |
| ikey|busy | alright if theres nothing else i gotta go walk through a blizzard | 18:26 |
| * ikey|busy wishes he was joking | 18:26 | |
| jdstrand | and since I've been involved in all of this, I will be a strong advocate in that process (meaning, there shouldn't be any issues) | 18:26 |
| jdstrand | ikey|busy: stay warm! | 18:26 |
| ikey|busy | cheers, and yourself if you're also being attacked by porchbournesnowballs | 18:27 |
| jdstrand | ikey|busy: nope, I'm in Texas. weird, annoying weather lately, but no snow | 18:28 |
| jdstrand | pedronis: merged! | 18:40 |
| mup | PR snapd#4779 closed: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4779> | 18:41 |
| * mvo grumbles about "cannot finish core install, there was a rollback accross reboot" vs "... (%d != %d)", snapInfo.Revision, rev) so that debugging give some more clues | 18:46 | |
| pedronis | mvo: don't we have some of that info in the traces | 18:49 |
| mvo | pedronis: this is what I have https://paste.ubuntu.com/p/CgTM2cZvpm/ | 18:51 |
| mvo | pedronis: I need to look if debug will help | 18:51 |
| * mvo tries that | 18:51 | |
| pedronis | mvo: I see we know what we are installing 4114 | 18:52 |
| pedronis | but don't see the previous rev | 18:52 |
| pedronis | or if there's a rev at all | 18:52 |
| pedronis | mvo: that code should also mark the revision as blocked (though we need to extend the way we track that) | 18:53 |
| pedronis | because normal revert assumes the revision stays around, which is not the case here | 18:53 |
| pedronis | we remove it again | 18:53 |
| mvo | pedronis: yeah | 18:53 |
| mvo | pedronis: maybe I can find out things from looking at the state and snapsetup | 18:54 |
| pedronis | mvo: well what that code is looking at really | 18:54 |
| pedronis | is the boot env vars | 18:54 |
| mvo | pedronis: yeah, a debug trace of those would be great | 18:54 |
| mvo | pedronis: or when we update the core_snap env | 18:55 |
| pedronis | CurrentBootNameAndRevision | 18:55 |
| mvo | https://paste.ubuntu.com/p/ChcW6xKhpr/ <- looks good before the reboot | 18:55 |
| mvo | pedronis: yeah | 18:55 |
| pedronis | anyway in my open PR | 18:56 |
| pedronis | that code is factored better in a helper | 18:56 |
| mvo | pedronis: oh, nice | 18:56 |
| pedronis | right now it hangs oddly in ifacestate | 18:56 |
| pedronis | https://github.com/snapcore/snapd/pull/4497 | 18:56 |
| mup | PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497> | 18:56 |
| mvo | pedronis: ok, this gets stranger and stranger, it claims the rev is wrong, however: # snap version | 18:58 |
| mvo | snap 2.31.1 | 18:58 |
| mvo | snapd 2.31.1 | 18:58 |
| mvo | pedronis: so it looks like the uboot update is too late maybe | 18:58 |
| pedronis | mvo: dit it actually reboots btw? | 18:58 |
| pedronis | is not that snapd restarts? | 18:59 |
| mvo | pedronis: yes, it did reboot | 18:59 |
| chachasmooth | `snap refresh` (without providing a snap name) always returns "All snaps are up to date" | 19:25 |
| chachasmooth | even if some snaps have upgrades available | 19:25 |
| chachasmooth | seems like a bug to me? | 19:25 |
| nacc | chachasmooth: --^ is on debian fyi | 19:26 |
| nacc | (may help know if it's an already fixed thing upstream, etc) | 19:26 |
| chachasmooth | snapd 2.21-2+b1 amd64 | 19:29 |
| zyga-ubuntu | re | 19:33 |
| * zyga-ubuntu was preparing for the trip | 19:33 | |
| Chipaca | mvo: it wasn't the mounts, then? | 19:37 |
| mup | PR snapd#4783 closed: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4783> | 19:38 |
| mvo | Chipaca: I think not | 19:43 |
| mvo | (he said and vanished in a puff of logic) | 19:44 |
| mvo | (sorry, silly descartes joke) | 19:44 |
| mvo | Chipaca: I think I'm close to figuring it out | 19:44 |
| zyga-ubuntu | mvo: hey, how are things? | 19:45 |
| mvo | zyga-ubuntu: good, I think I'm close | 19:46 |
| zyga-ubuntu | chachasmooth: you are on debian and you have 2.21-2+b1? is that what snap version says as well or just dpkg | 19:46 |
| zyga-ubuntu | mvo: want me to be your garden troll? | 19:46 |
| zyga-ubuntu | (so you tell me what the bug is and that's how you get the last bit) | 19:46 |
| chachasmooth | zyga-ubuntu ^ was the output of dpkg | 19:49 |
| zyga-ubuntu | chachasmooth: in debian stable that is expected | 19:49 |
| chachasmooth | well, it's still misbehaving | 19:50 |
| chachasmooth | it shouldn't say "snaps are up to date" when they are not | 19:50 |
| zyga-ubuntu | chachasmooth: so that's interesting, how do you determine that there are snaps that are out of date? | 19:50 |
| zyga-ubuntu | chachasmooth: and what does "snap changes" say | 19:50 |
| chachasmooth | after running snap refresh lxd the snap upgraded | 19:50 |
| chachasmooth | ^ zyga-ubuntu | 19:52 |
| zyga-ubuntu | can you paste "snap changes" | 19:52 |
| zyga-ubuntu | and snap version, please | 19:52 |
| chachasmooth | 23 Done 2018-03-02T19:20:39Z 2018-03-02T19:20:39Z Refresh all snaps: no updates | 19:53 |
| chachasmooth | that's the only line returned | 19:53 |
| chachasmooth | snap --version | 19:54 |
| chachasmooth | snap 2.31.1 | 19:54 |
| chachasmooth | snapd 2.31.1 | 19:54 |
| chachasmooth | series 16 | 19:54 |
| chachasmooth | debian 9 | 19:54 |
| chachasmooth | kernel 4.9.0-6-amd64 | 19:54 |
| zyga-ubuntu | this looks fine, hmm | 19:54 |
| zyga-ubuntu | and when you "snap refresh lxd", which revision did you get? | 19:54 |
| chachasmooth | I don't remember, the most recent one | 19:55 |
| chachasmooth | it's been a week or so since | 19:55 |
| chachasmooth | haven't upgraded lxd in a few months | 19:55 |
| zyga-ubuntu | chachasmooth: can you open a forum topic about this, I just don't want it to get lost | 19:55 |
| chachasmooth | where? | 19:55 |
| zyga-ubuntu | lxd would refresh by itself | 19:55 |
| zyga-ubuntu | on forum.snapcraft.io | 19:55 |
| chachasmooth | ok, might take a few days though | 19:56 |
| zyga-ubuntu | next week will be very busy but we'll try to look at it | 19:56 |
| zyga-ubuntu | no worries, thank you for reporting this | 19:56 |
| zyga-ubuntu | I'm worried that snap changes doesn't show the LXD refresh | 19:56 |
| zyga-ubuntu | maybe it already got garbage collected | 19:56 |
| zyga-ubuntu | (the change, that is) | 19:56 |
| chachasmooth | I did a reboot since fyi | 19:57 |
| zyga-ubuntu | succesful changes are discarded relatively quickly but I forgot how often that is | 19:59 |
| chachasmooth | it should be rather easy to check what a plain `snap refresh` does | 20:00 |
| zyga-ubuntu | yes, I know what it does | 20:00 |
| chachasmooth | what does it do? | 20:00 |
| zyga-ubuntu | I'm wondering how this could happen | 20:00 |
| zyga-ubuntu | it mainly asks the store if there's a refresh for any of the snaps that are installed, | 20:01 |
| chachasmooth | it should get a list of all snaps installed and execute `snap refresh $SNAP` for each | 20:01 |
| zyga-ubuntu | it has some logic to not refresh snaps that have changes in progress | 20:01 |
| chachasmooth | what does "in progress" mean? | 20:01 |
| zyga-ubuntu | it's doing that but has some logic to not be too silly if a refresh is in progress | 20:01 |
| zyga-ubuntu | well | 20:01 |
| zyga-ubuntu | many things | 20:01 |
| zyga-ubuntu | if you are refreshing a snap | 20:01 |
| zyga-ubuntu | and it's pullling updates | 20:02 |
| zyga-ubuntu | then you run a refresh in another terminal | 20:02 |
| zyga-ubuntu | it will not refresh that snap | 20:02 |
| chachasmooth | it was not doing that | 20:02 |
| zyga-ubuntu | that's a kind of change | 20:02 |
| zyga-ubuntu | there are all kinds of other changes as well | 20:02 |
| zyga-ubuntu | but it's unlikely those were running at the time | 20:02 |
| zyga-ubuntu | one last obvious thing is that when you ran "snap refresh" lxd was about to be published | 20:02 |
| zyga-ubuntu | and then a moment later it was published and you managed to refresh it manually | 20:03 |
| chachasmooth | no, stgraber did the release a few weeks earlier | 20:03 |
| zyga-ubuntu | another possibility is a store bug | 20:03 |
| chachasmooth | well, but `snap refresh lxd` worked, so how could this be a store bug? | 20:03 |
| zyga-ubuntu | because the query is different | 20:04 |
| zyga-ubuntu | not sure | 20:04 |
| zyga-ubuntu | the person that's the expert on this is probably EOD'd | 20:04 |
| zyga-ubuntu | Chipaca: ^ | 20:04 |
| chachasmooth | is there a way to reproduce by installing some outdated snap which has a newer stable release to which I can upgrade? | 20:04 |
| zyga-ubuntu | yes but you have to be the developer of a given snap to install an older revision | 20:05 |
| zyga-ubuntu | I'll talk to chipaca next week, he knows that code much better than I do | 20:05 |
| mup | PR snapcraft#1976 closed: elf: only consider regular files as possible ELF binaries <bug> <Created by jhenstridge> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1976> | 20:24 |
| mup | PR snapd#4784 closed: asserts: use a timestamp for the assertion after the signing key has been created (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4784> | 20:27 |
| mvo | zyga-ubuntu: I replied in the forum, the reason is that we have two uboot.env files, UBOOT.env and uboot.env and uboot sets one of them to `snap_mode=trying` but snapd reads the other one with `snap_mode=try` | 20:45 |
| zyga-ubuntu | mvo: wow | 21:12 |
| * zyga-ubuntu goes to read the forum | 21:12 | |
| zyga-ubuntu | mvo: there's a mount flag to control file names like that | 21:13 |
| mvo | zyga-ubuntu: i tried them and could not find one | 21:14 |
| zyga-ubuntu | looking | 21:15 |
| zyga-ubuntu | ah, one more sec | 21:15 |
| mvo | zyga-ubuntu: its also very unclear why this started to happening suddenly | 21:15 |
| zyga-ubuntu | it's not a mount option, it's a switch in proc somewhere (or sys) | 21:15 |
| zyga-ubuntu | yeah | 21:16 |
| mvo | zyga-ubuntu: ohhhh | 21:16 |
| zyga-ubuntu | maybe a new gadget? | 21:16 |
| zyga-ubuntu | new uboot? | 21:16 |
| zyga-ubuntu | or just bad luck | 21:16 |
| mvo | zyga-ubuntu: they have their own, but its the same uboot afaict | 21:16 |
| zyga-ubuntu | btw, how did you get to the point where the files differed? | 21:16 |
| zyga-ubuntu | they did not differ in the corrupted image | 21:16 |
| mvo | zyga-ubuntu: after the refresh they started to differ I think the difference is subtle, try vs trying | 21:17 |
| zyga-ubuntu | I see | 21:17 |
| mvo | but it seems like it is the unix side that mis-behaves, it starts writing lower case | 21:18 |
| zyga-ubuntu | found it | 21:19 |
| zyga-ubuntu | mvo: shortname=lower|win95|winnt|mixed | 21:19 |
| zyga-ubuntu | default is mixed | 21:19 |
| zyga-ubuntu | https://www.kernel.org/doc/Documentation/filesystems/vfat.txt | 21:19 |
| zyga-ubuntu | we could try shortname=lower | 21:20 |
| mvo | zyga-ubuntu: when I played with that I couldn't see a difference | 21:20 |
| zyga-ubuntu | and see if that changes how the file is opened | 21:20 |
| zyga-ubuntu | or we could mount it as msdos (not vfat) | 21:20 |
| mvo | zyga-ubuntu: oh, I think I did not try that, I tried the iocharset ones | 21:20 |
| mvo | zyga-ubuntu: thats a nice idea | 21:20 |
| zyga-ubuntu | msdos doesn't support long file names | 21:20 |
| * zyga-ubuntu tries with mount -t msdos | 21:21 | |
| zyga-ubuntu | 2018 and we are fighting bootloaders and msdos filenames | 21:21 |
| mvo | zyga-ubuntu: yeah, please update the forum if you find anything, I need some sleep | 21:22 |
| zyga-ubuntu | I will | 21:22 |
| mvo | zyga-ubuntu: it might also be that their usage fiddles with mount options somehow | 21:23 |
| mvo | zyga-ubuntu: what is also interessting is why eventually things get corrupted and stop booting but my gut feeling is that its all related | 21:24 |
| mvo | anyway, I need to get some rest | 21:24 |
| * mvo waves | 21:24 | |
| mup | PR snapcraft#1979 opened: pluginhandler: simplify logic when elf patching is required <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1979> | 22:57 |
| mup | PR snapcraft#1980 opened: elf: remove all un-primed libs from soname cache <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1980> | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!