[03:25] PR snapcraft#1975 closed: python plugin: find setup.py when source-subdir is used [03:31] PR snapcraft#1976 opened: elf: only consider regular files as possible ELF binaries [03:49] PR snapcraft#1977 opened: lifecycle: when priming dependencies need to be primed [06:05] morning [06:44] re [06:49] zyga: hey [06:49] good morning :) [06:49] damn cold outside, -16 right here [06:51] but hey [06:51] it's spring :) [06:51] city bikes have been re-installed and enabled today [06:51] :D [06:51] it's spring in ~3 weeks from now :P [07:20] * zyga runs content interface tests and goes for some tea [07:27] PR snapd#4764 closed: configstate: when disable "ssh" we must disable the "sshd" service [07:29] PR core#82 closed: xdg-open: add implementation capable of opening local files [07:55] good morning [08:12] morning [08:21] PR snapd#4751 closed: tests: add support for external backend executions on listing test (2.32) [08:21] PR snapd#4752 closed: tests: make interface-broadcom-asic-control test work on rpi (2.32) [08:24] mvo: good morning! [08:25] hey Chipaca [08:25] mvo: I'll merge master into #4750, maybe that'll help [08:25] PR #4750: store: getStructFields now take pointers [08:25] Chipaca: aha, ok [08:26] mvo: there [08:27] 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] big* [08:28] my hands were already writing heck [08:33] hey Chipaca [08:35] zyga_: you like what I did to the NG-using pr? [08:35] zyga_: also as a directo consequence of that, the NG-improving pr :-) [08:35] NG-using pr [08:35] I think I need another coffee to parse that [08:35] NG [08:35] what is that [08:36] i18n.NG [08:36] or was that GN [08:36] * Chipaca looks [08:36] NG [08:36] are you referring to ngettext? [08:36] #4775 [08:36] PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t [08:36] * zyga_ looks [08:37] ah [08:37] I wasn't aware it's called NG [08:37] zyga_: and #4777 [08:37] PR #4777: i18n: simplify NG usage by doing the modulo math in-package [08:37] is the empty argument sensible? [08:37] if this is anything like gettext I would expect [08:37] NG("%d day ago", "%d days ago", someNumber) [08:38] and why does it now say "at 15:04 MST" ?!? [08:38] Chipaca feel free to correct me, maybe I'm not really awake yet [08:38] zyga_: mborzecki feedback, that named timezones are more friendly [08:39] zyga_: the first entry is for n==1, and n is never one there, that's why it's empty [08:39] but why does humanTimeSince use a hard-coded string "15:04 MST" [08:39] that's the format [08:40] go's t.Format("") [08:40] ahh [08:40] zyga_: time referecen format https://godoc.org/time#pkg-constants [08:40] that's cool I didn't know htat [08:40] Chipaca: I tripped over this too, maybe a comment? [08:40] / RTFM [08:40] :-P [08:40] who designed that :) [08:40] Chipaca: I remembered this format thing then and forgot abou tit [08:40] * Chipaca is laughing, but at himself [08:40] zyga_: someone who loves this particular date [08:40] at HH:MM XXX would be much nicer [08:40] how could you forget abou tits [08:40] Chipaca never forget about tits [08:41] * zyga_ gets that coffee [08:41] ikr [08:41] * mvo wonders about the backstory of that date [08:41] [08:41] eh? this is a family channel! [08:41] mvo: families dont have 'em? [08:41] FWIW that format spec is pretty smart compared to the str[fp]time madness [08:41] *cough* [08:42] it's much more WYSIWYG than other 'formats' [08:42] this is like a := 1, b := 3; assert eval("2 + 2", a, b) == 3 [08:43] mborzecki: i wish you could precompute them though [08:43] that's a lot of repetitive jiggery to do in a loop [08:43] yeah, the implementation is a bit convoluted :P [08:50] last few loops on hardening [08:50] the base template got a lot shorter :) [08:51] and there are almost no globs left :) [08:52] there's one more chunk left but it will become visible with this test pass (extra directory writability permissions) [08:58] https://github.com/snapcore/snapd/pull/4765 has a lot of WIP patches, sorry for that, I'll get rid of them [08:58] PR #4765: interfaces/apparmor: use snap name instead of wildcards [08:58] I'll tidy this up soon [09:10] 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] not in english, [09:10] in english it is only for n==1 [09:10] in other languages you have many cases and you should not assume there's no "singular" because of the value [09:11] right, but it'd not be using the empty string in those cases [09:11] unless it confuses things because msgid? [09:11] hmm, I don't know [09:11] I don't suppose it hurts to just use the singular string [09:12] eh, ok, i'll change it [09:13] drat, it needs to have a %d doesn't it [09:17] 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] plus the comment === ikey|busy is now known as ikey [09:18] mvo: like https://github.com/snapcore/snapd/pull/4775/commits/75cc9c7966e0eb67d4f637e3d31e8628f85d9006 ? [09:18] PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t [09:19] Chipaca: :+1: [09:51] Chipaca: we did time formatting like that for ubuntu-push-notifications iirc [09:51] sergiusens: anything learned? [09:51] good morning and good day (parting towards next weeks destination) [09:51] Chipaca: I still don't like it if you asked me again :-P [09:51] sergiusens: is there anywhere in snapcraft you check summaries don't have \n's? [09:52] Chipaca: I am not sure, but I need to shutdown, will continue from the airport (where irc is blocked) [09:52] sergiusens: telegram me :-) [09:52] sergiusens: o/ [09:52] o/ [10:10] ok, physio time [10:10] * Chipaca afk for a while [10:30] jdstrand: does 4766 look good to you after the latest changes from james? [10:44] PR snapd#4780 opened: snap: add autostart app property [11:10] zyga_: I just pushed a fix for 4779 [11:10] Thank you! === zyga_ is now known as zyga [11:36] * pstolowski lunch [11:54] 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] (was testing the maas snap with it, but postgres still fails because of missing timezones) [11:57] jdstrand hey [11:57] jdstrand please have a look at 4765 again [11:57] I can split it if that makes it easier [11:57] I just fired one more run and it shoud *fingers crossed* work [11:58] PR snapd#4780 closed: snap: add autostart app property [12:01] Chipaca: guess what failed https://paste.ubuntu.com/p/G2wTbP4f6r/ SquashfsTestSuite.TestBuildDate [12:03] ackk: hm, maybe it was not build or something, let me check [12:06] PR snapd#4781 opened: wrappers: refactor desktop file sanitizer to support autostart files [12:09] mvo: have you looked into adding some shlexer to our codebase? [12:14] is there some env variable that has core version? Or how can I find out snapd version from my own snap? [12:15] sborovkov there's no such variable [12:15] why do you need to know the version of snapd? [12:15] there are a few ways perhaps but not sure why you'd want to know that [12:20] well we want to report node info [12:20] in case there are issues on the customer's device [12:20] having snapd version would help [12:20] I think you can get it the same way snap --version does [12:20] there's an API endpoint for this [12:21] I think it is /v2/system-info [12:21] just GET that [12:21] over the snapd socket [12:22] ok thanks [12:23] Chipaca: bad news, there does not appear to be any no timezone information in squashfs files [12:24] Chipaca: well, at least in unsuqashfs -s output [12:32] * zyga small break [12:35] mborzecki: does it respect TZ if set ? [12:35] that might be a way out [12:35] pedronis: yes, i'm fixing it right now [12:40] PR snapd#4776 closed: Do not auto-import from loop/ram devices [12:42] mborzecki: gah [12:42] mborzecki: yes, squashfs times are always local [12:43] so there's a bug in the test [12:43] Chipaca: i'm opening a PR in a minute [12:43] mvo, AFAICS LP did build it and publish, not sure what happened thouhg [12:43] mborzecki: ah ok [12:44] PR snapd#4782 opened: snap/squashfs: set timezone when calling unsquashfs to get the build date [12:44] Chipaca: ^^ [12:44] ogra_: you around? [12:45] linode is down? https://paste.ubuntu.com/p/4v2qHSsnV9/ [12:45] mborzecki: silly question, does it work if you _just_ set Env to TZ=UTC? [12:45] Chipaca: without append(os.Environ()..) ? [12:46] mborzecki: yep [12:46] let me check [12:46] mborzecki: that's a very clever way of fixing it, we should do it in Walk as well [12:47] Chipaca: yeah, just TZ=.. works too [12:48] mborzecki: hmm [12:48] mborzecki: so, the way Walk handles it is by doing time.ParseInLocation(..., time.Local) [12:49] mborzecki: see parseTime in snap/squashfs/stat.go [12:49] Chipaca: right, that might be even nicer than enforcing TZ [12:50] well, maybe [12:50] what happens if you're just before DST [12:50] such that time.Local and unsquashfs have different opinions on what side of the change you are [12:50] TZ=UTC and ParseInLocation(time.UTC) then [12:51] or is that the default for Parse ? [12:51] it is [12:51] hm time.Parse(time.ANSIC..) implies UTC [12:52] mvo: hey. re 4766> no. nothing was done with snapFromSenderImpl (that's also the bit I asked you to look at) [12:52] 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] jdstrand hey! [12:53] hey zyga :) [12:53] 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] looking at 4765 now [12:53] PR #4765: interfaces: harden snap-update-ns profile [12:53] thanks! [12:53] 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] i like the garters-and-belt approach of TZ=UTC and Parse [12:53] zyga: cool [12:53] jdstrand it ended up big, feel free to request extra tests and other refactorings [12:54] (Parse picks up location from the value but falls back to UTC, so there's an extra layer of strapping there) [12:54] zyga, mvo: if you could look at PR 4779, that would be great :) [12:54] PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 [12:54] jdstrand ack [12:54] mborzecki: can you do the same thing to the one over in stat? [12:54] mvo: mborzecki: I'm talking about this: https://github.com/snapcore/snapd/blob/master/timeutil/schedule.go#L401 [12:55] pedronis: go ahead as far as i'm concerned, iirc niemeyer wanted get rid of it too [12:56] 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:57] Chipaca: just Parse(), no InLocation? [12:57] exit status 1I saw you fixed it in master (thanks!) [12:57] err [12:57] jdstrand: I can if needed [12:57] PR snapd#4775 closed: timeutil: timeutil.Human(t) gives a human-friendly string for t [12:57] mborzecki: yes [12:57] I saw you fixed it in master (thanks!) [12:58] 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] I can work around it [12:58] jdstrand: np, I just didn't bothered because it didn't seem to affect anything else [12:58] but it's useful I can [12:58] there's also a flaky test fix that I was asked to backport [12:59] 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] so I'll leave it up to you [13:01] jdstrand: I'm a bit juggling many things (aren't we all), but I'll look into it today [13:02] 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:04] pedronis: if you get to it, thanks. if not, that's totally fine and thank you for considering it :) [13:10] Chipaca: pushed [13:13] jdstrand how do you feel about that hardening PR? [13:17] pedronis: I fixed the comment on #4738 fwiw [13:17] PR #4738: snap: unify snap name validation w/python; enforce length limit [13:18] zyga: I'm still looking at it [13:21] mvo: so this happens after snapd updates from 2.31 to 2.31.1 here [13:21] sure I have what fs looks like [13:21] give me few mins to download that [13:21] sborovkov: ohhhhh [13:21] sborovkov: that is interessting [13:22] https://www.dropbox.com/s/gx17h6emu9uott5/corrupt-disk.img.7z?dl=0 [13:22] sborovkov: we have an independent report about an upgrade issue on bionic (but only there) [13:22] this is the dump of the SD card [13:22] sborovkov: \o/ thank you [13:23] I also have an image where this reproduces :) [13:23] I managed to reproduce it 3 times today [13:23] sborovkov: can I haz? [13:23] sborovkov: I'm really keen to get to the bottom of this [13:23] yeah sure [13:24] but you will need ssh assertion to login to that system [13:24] https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-09-bbc27f2.img.zip.md5 [13:24] this is the image [13:24] so today I did this few times - flashed it out. Let it initialize [13:24] sborovkov: ok, let me first look at the broken one [13:24] sborovkov: maybe that gives me some clues [13:24] it works great after reboots [13:24] as soon as I do snap refresh core [13:25] it fails at the next reboot [13:25] or one after next [13:25] sborovkov: so this is 2.31 -> 2.31.1 ? [13:25] yes [13:25] image was created from stable 1 week ago [13:25] ta [13:26] image is created by ubuntu-disk-image with 2 extra snaps [13:26] one is our own snap. another one is udisks. [13:32] * kalikiana lunch [13:34] mvo: I also can flash another one of that and run some logging during/after core update if needed [13:34] but only today as I have flight to Shanghai tomorrow [13:38] sborovkov: I need to travel soon too so today is definitely my preference [13:39] sborovkov: I am looking at the diff right now [13:44] sborovkov: ping [13:45] 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:46] sborovkov: In 45 minutes maybe, if that works for you (30 mins past the hour) [13:50] I just tested a 2.31->2.31.1 on amd64 and that went fine, I'm trying on armhf now [13:54] zyga: https://github.com/snapcore/snapd/pull/4765#pullrequestreview-100766399 [13:54] PR #4765: interfaces: harden snap-update-ns profile [13:54] niemeyer, sure [13:54] Thank you! [13:54] looking [13:54] 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:55] ok [13:55] thank you for letting me know [14:05] ok, 2.31 -> 2.31.1 on pi3 is also fine [14:05] * mvo scratches head [14:08] 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:10] PR snapd#4782 closed: snap/squashfs: set timezone when calling unsquashfs to get the build date [14:12] 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 === ikey is now known as ikey|busy [14:24] PR snapd#4783 opened: ifacestate: be consistent passing Retry.After as named field (2.32) [14:25] PR snapd#4784 opened: asserts: use a timestamp for the assertion after the signing key has been created (2.32) [14:25] mvo: zyga: jdstrand: I created a couple of trivial cherry-picks for 2.32 ^^^ [14:26] kk [14:30] niemeyer, i am ready :) [14:30] sborovkov: Let's go.. let me get a link [14:32] sborovkov, mvo, zyga: https://hangouts.google.com/hangouts/_/canonical.com/debug-session [14:33] mvo, hey [14:34] mvo, dod you already know when the 2.32 rc2 is comming? [14:37] cachio__: on hold right now, zyga found a critical bug with layouts [14:37] I will propose a fix for this later today [14:38] perfect [14:38] zyga, it is related with the error on the test that I sent you yesterday? [14:38] i also saw it on linode today [14:38] not sure which one was that [14:38] about /etc, yes [14:38] if not about /etc then no [14:38] yes [14:38] that one [14:38] nice [14:39] zyga, so [14:39] thanks for fixing it [14:47] * Chipaca afk for a bit [14:55] PR snapcraft#1978 opened: ci: switch to stable lxd and unconfined containers [15:08] popey who is managing sublime-text-3 snap? [15:08] I'd love edge to have the more recent dev build [15:08] (dev build has a feature I like) [15:10] https://github.com/snapcrafters/sublime-text [15:10] pull requests welcome ;) [15:14] Chipaca should snap list show the size of the snap? [15:14] zyga_: it doesn't [15:14] I know [15:14] I was thinking what if it did [15:15] zyga_: let's talk at the sprint [15:15] mvo: what's your pgp key? will send you an assertion encrypted [15:15] Chipaca sounds good [15:16] sborovkov https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0xDA6C6754D8887626CD06A12898CABB3ABD4CA59E [15:19] sborovkov: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x98CABB3ABD4CA59E [15:22] * Chipaca really afk this time [15:24] 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:25] and this is link to image - https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-20.img.zip [15:31] hmm hm [15:31] sborovkov: downloading the image now [15:31] sborovkov: the other link is expired, please jsut mail it to me [15:32] zyga-ubuntu: any clues? [15:32] mvo: no, looking at the raw image [15:32] zyga-ubuntu: yeah I find it interessting that only hte old core is on the image [15:32] zyga-ubuntu: no trace of the new one [15:32] zyga-ubuntu: I was also browsing the logs [15:35] PR snapd#4785 opened: tests: moving ubuntu core from linode to google backend [15:40] mvo: does PR 4779 need a second +1? I see you fixed up an unrelated merge issue and the tests now pass [15:40] PR #4779: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 [15:40] mvo: after mounting p1 I see that there are two "uboot.env" files [15:41] -rwxr-xr-x 1 root root 131072 lut 28 13:34 uboot.env* [15:41] -rwxr-xr-x 1 root root 131072 lut 28 13:34 uboot.env* === zyga_ is now known as zyga [15:41] jdstrand: I think its fine to land, I wanted to have a closer look but $things happend to me :/ [15:42] zyga: how is that even possible [15:42] * mvo looks [15:42] mvo: no idea, just mount p1 and see [15:42] maybe we can use some low-level fat tool to list and read that file [15:42] (there is such a thing, I will look at that) [15:42] zyga-ubuntu: I see it too [15:44] zyga-ubuntu: hm - no error from fsck.vfat (well, dirty bit set but no real error) but still two uboot.env files [15:44] this is from fatcat [15:44] https://pastebin.ubuntu.com/p/mnhDXb7jXP/ [15:44] sborovkov: I have things ready here, just need the ssh assertion, will step out for some minutes but will read scrollback [15:45] zyga looking [15:45] there's a lower-case and an upper-case version of that file [15:45]