| mborzecki | morning | 05:02 |
|---|---|---|
| mup | PR snapd#5138 closed: cmd/libsnap: fix compile error on more restrictive gcc <Critical> <Simple> <Squash-merge> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5138> | 05:18 |
| mup | PR snapd#5139 opened: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5139> | 05:23 |
| mborzecki | mvo: morning | 05:36 |
| Son_Goku | mborzecki, mvo: do we have fedora 28 CI live now? | 05:36 |
| mborzecki | mvo: i've merged 5138 and opened a followup for 2.32 -> #5139 | 05:36 |
| mup | PR #5139: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5139> | 05:36 |
| Son_Goku | and maybe even rawhide CI? | 05:36 |
| mborzecki | Son_Goku: don't know if cachio has added f28 image yet | 05:37 |
| Son_Goku | well, unfortunately I'm a bit unable to test much of anything on hotel wifi :/ | 05:37 |
| Son_Goku | so I was hoping that'd be up by now to be sure that the compilation errors are all fixed | 05:37 |
| mvo | mborzecki: thank you! and good morning | 05:39 |
| mvo | Son_Goku: I will followup with cachio on that today | 05:40 |
| Son_Goku | mvo, zyga, I'm in San Francisco for Red Hat Summit this week | 05:40 |
| Son_Goku | so among other things, I intend to talk to Fedora folks on a wide array of topics | 05:40 |
| Son_Goku | which is why I was hoping zyga would have ironed out the issues that prevented a working fedora base snap | 05:41 |
| Son_Goku | and created an app snap that uses a fedora base to demo the concept | 05:41 |
| mvo | Son_Goku: woah, cool! | 05:42 |
| mvo | Son_Goku: he was working on this, but this sounds great, lets catch up with him once he is online and see the status, it would be great to give you something to demo there | 05:43 |
| mborzecki | Son_Goku: great news | 05:43 |
| mborzecki | he mentioned he did play with fedora base on friday (?) last week and he had some progress | 05:43 |
| mborzecki | afk for ~30 minutes | 06:11 |
| mup | PR snapd#5139 closed: cmd/libsnap: fix compile error on more restrictive gcc (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5139> | 06:13 |
| zyga | Hey | 06:16 |
| zyga | Son_Goku: i have something close that you can show | 06:16 |
| zyga | I will share it soon | 06:16 |
| zyga | I have a bit of a hectic day | 06:16 |
| zyga | Need to go with my mom to a hospital | 06:17 |
| zyga | But I will work most of the time | 06:17 |
| Son_Goku | ok | 06:18 |
| * zyga commutes to the hospital | 06:53 | |
| mborzecki | re | 07:07 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:10 |
| mborzecki | pstolowski: hey | 07:10 |
| mborzecki | pushed an update to arch package with gcc build fixes patch | 07:37 |
| mvo | mborzecki: ta | 07:40 |
| zyga | re | 08:01 |
| zyga | mvo: how are we doing for .7? | 08:03 |
| zyga | how can I help | 08:03 |
| mvo | zyga: need an ACK from niemeyer for .7 on naming and approach (forum post is https://forum.snapcraft.io/t/snapd-seeded-target-and-how-to-order-after-it/5310) | 08:04 |
| mvo | zyga: I'm looking at the screenly issue right now | 08:04 |
| zyga | mvo: at the lower vs UPPER thing? | 08:05 |
| zyga | mvo: do you think that we could use my suggestion on mounting fat in a specific way? | 08:05 |
| zyga | mvo: I added one more option on the #5132 naming thing | 08:06 |
| mup | PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5132> | 08:06 |
| mvo | zyga: yeah, the corruption thing, I wrote up https://forum.snapcraft.io/t/snapd-causes-corruption-on-upgrade/5253/20 | 08:06 |
| mvo | zyga: which includes all the details what goes wrong, I have the sd card and looking right now if I can find anything to help with the situation | 08:07 |
| zyga | mvo: canyou check if mounting it with that option helps | 08:07 |
| zyga | it should be a simple tweak to fstab | 08:07 |
| mvo | zyga: I did, I still see two lower-case uboot.env files and cat gives me the wrong one | 08:07 |
| zyga | bummer! | 08:08 |
| zyga | an fsck? | 08:08 |
| mvo | zyga: but let me try to write it | 08:08 |
| zyga | does fscking fixes anything? | 08:08 |
| mvo | zyga: fsck.vfat is clean :/ | 08:08 |
| zyga | well, at this stage I think linux is broken there :/ | 08:09 |
| mborzecki | well, how did they end up with both? | 08:11 |
| mvo | mborzecki: thats the big question - uboot writes it, it contains snap_mode=trying | 08:12 |
| zyga | mborzecki: FAT is apparently still hard | 08:12 |
| mvo | mborzecki: however its unclear why it does it, in most cases it writes the right file | 08:12 |
| mvo | zyga: here is something funny, if I mount with -o shortname=win95 I can see the two files with different filenames - but cat gives me the same output for both | 08:13 |
| zyga | maybe magic sd card controller groking fat? | 08:13 |
| mvo | this also works when I don't use a sd card but just the plain image | 08:13 |
| mborzecki | which one was written by fw_setenv? | 08:13 |
| mvo | and fatcat shows me the right "cluster" | 08:14 |
| mvo | mborzecki: none | 08:14 |
| mvo | mborzecki: the uboot binary writes with its own code (which may be reused in fw_setenv, I don't know) | 08:14 |
| mborzecki | so it's the uboot script that wrote it? | 08:14 |
| mvo | mborzecki: and we write using our own code | 08:14 |
| mvo | mborzecki: correct | 08:14 |
| mvo | mborzecki: one sec, I can paste it | 08:14 |
| mborzecki | mvo: if you do fatls in uboot does it show both files? | 08:15 |
| mvo | mborzecki: https://paste.ubuntu.com/p/7zCCzgh76j/ <- output sucks | 08:15 |
| mvo | mborzecki: I think it does, let me double check, I played with fatls and fatload and md and could only get uboot to read the "wrong" UBOOT.ENV file. but it seems when it writes it always writes the "uboot.env" (lower-case) file | 08:15 |
| mvo | mborzecki: https://paste.ubuntu.com/p/psgTgfwFz5/ - it shows both files | 08:16 |
| zyga | mvo: what is the relationship of uboot.env to uboot.bin? | 08:17 |
| zyga | there's only one .bin | 08:17 |
| zyga | maybe (apart from .env being duplicated) the issue is really in .bin? | 08:17 |
| mvo | mborzecki: doing fatload mmc 0 9999999 UBOOT.ENV gives me the same conent for upper and lower case | 08:18 |
| mvo | zyga: we don't write anything on this sd except UBOOT.ENV | 08:19 |
| zyga | mvo: how are you testing this? using a raspberry pi? | 08:19 |
| Chipaca | moin moin | 08:20 |
| zyga | hey Chipaca! | 08:20 |
| mborzecki | zyga: uboot.bin is the actual uboot, it's loaded by one of the start*.elf binaries | 08:20 |
| zyga | how are you doing? | 08:20 |
| zyga | mborzecki: ah, thanks | 08:20 |
| mborzecki | Chipaca: hey | 08:20 |
| Chipaca | 'm hot =) | 08:20 |
| Chipaca | how're you guys? | 08:20 |
| mvo | zyga: yes, I got the corrupted image and wrote it to a sd card and play with it on my pi | 08:20 |
| zyga | mvo: what happens if you use uboot | 08:21 |
| zyga | and write some new variable | 08:21 |
| zyga | and save that | 08:21 |
| zyga | did you perform such an experiment? | 08:21 |
| zyga | frozbonicator=schnibble | 08:21 |
| zyga | saveenv or whatever that was | 08:21 |
| zyga | and see what's on FAT | 08:21 |
| mvo | zyga: it happens implicitly because snap_mode=try triggers snap_mode=trying and saveenv. I did not try explicitly though, can do | 08:22 |
| zyga | I wonder where it will go | 08:22 |
| mvo | zyga: pretty sur eit will go to uboot.env (lower) but I can try | 08:23 |
| Chipaca | zyga: from snapd's pov that's a file mounted on a vfat fs, yes? | 08:23 |
| zyga | Chipaca: yes | 08:23 |
| Chipaca | zyga: why vfat and not msdos? | 08:23 |
| zyga | Chipaca: mvo tried mounting it in a few ways | 08:23 |
| zyga | Chipaca: ha, perhaps good question | 08:23 |
| zyga | vfat implies long file names | 08:24 |
| zyga | maybe uboot doesn't do that | 08:24 |
| zyga | though msdos is AFAIK a variant of fvat with different options | 08:24 |
| zyga | it would be good if we could reproduce this though | 08:24 |
| zyga | mvo: question | 08:24 |
| zyga | ha | 08:24 |
| zyga | maybe a good one actually :D | 08:24 |
| zyga | mvo: how do we write that file from snapd | 08:24 |
| zyga | are we ... by any chance.. use atomic renames? | 08:24 |
| zyga | write a new _long_ random file name a rename? | 08:24 |
| zyga | could it be that by doing that our file lives in the LFS domain? | 08:25 |
| zyga | and uboot just says "meh, don't grok" | 08:25 |
| zyga | and writes a new file | 08:26 |
| zyga | then stuff goes south | 08:26 |
| zyga | though this doesn't explain why it only happens once in blue moon | 08:26 |
| zyga | maybe the random pattern (if that part is random) needs to be special to trigger this | 08:26 |
| mvo | zyga: we write the file in place iirc, never change the size. this is to avoid it ever moving on disk which seems to cause corruption easily (iirc) | 08:26 |
| zyga | aha, so that's out the door then | 08:27 |
| zyga | hmmmm | 08:27 |
| * zyga looks at the code | 08:27 | |
| mborzecki | this is what writes the env to a file: https://git.denx.de/?p=u-boot.git;a=blob;f=fs/fat/fat_write.c;h=3b77557b3ede57951c4e35e0d5d753fda845e903;hb=HEAD#l902 | 08:27 |
| zyga | mborzecki: thanks | 08:28 |
| zyga | mydata->fatsize | 08:28 |
| zyga | I wonder if it would help if we mounted it as fat16 | 08:28 |
| zyga | is it fat16 or fat32? | 08:28 |
| mvo | mborzecki: yeah, I remember looking at this file a while ago | 08:28 |
| zyga | or fat12, I forgot the variants | 08:28 |
| mvo | I think fat32 | 08:28 |
| mvo | but not 100% certain | 08:28 |
| zyga | 980 downcase(l_filename, INT_MAX); | 08:29 |
| mvo | things are more myserious - now I tried to remove uboot.env from linux, that worked and ls from linux does not show any uboot.env anymore. *but* fatcat still shows *both* and uboot happily show both and load the UBOOT.ENV one | 08:30 |
| mborzecki | mvo: can you try mounting it with check=s ? | 08:30 |
| zyga | so it's essentially using lower case for lookup | 08:31 |
| mvo | mborzecki: done, no change afaict | 08:31 |
| mborzecki | hm wonder what they set ENV_FAT_FILE to | 08:31 |
| Chipaca | augh, laptop is suspend-cycling | 08:32 |
| zyga | hmm | 08:32 |
| Chipaca | wtf | 08:32 |
| zyga | mvo: since both are lower case is there a chance that there's a space or something like that there? | 08:32 |
| mvo | zyga: I can't see spaces with the tools I have, I can write some code though, let me see | 08:33 |
| zyga | can you fatcat | od -t c | 08:33 |
| zyga | from linux | 08:33 |
| zyga | that should show invisibles | 08:33 |
| mvo | zyga: it uses spaces all over the place, "f 18/4/2018 15:44:16 UBOOT.BIN c=11801 s=361144 (352.68K) | 08:34 |
| mvo | " | 08:34 |
| zyga | drat :/ | 08:34 |
| mvo | zyga: how would I know if the space is a space or part of the filename? | 08:34 |
| zyga | yeah | 08:34 |
| zyga | sucks | 08:34 |
| mvo | it does | 08:34 |
| zyga | FAT uses one table or two? | 08:35 |
| mvo | two afaik | 08:35 |
| mvo | fwiw, filesystem is FAT32 | 08:35 |
| zyga | mvo: does fatcat -o show anything? | 08:36 |
| zyga | mvo: and what does fatcat -i say? | 08:36 |
| mvo | zyga: https://paste.ubuntu.com/p/ZmShHTXkYY/ | 08:37 |
| mborzecki | hmm https://git.denx.de/?p=u-boot.git;a=commit;h=2c33b0c7d8deca7e9a907365a59fcbcde531c70d | 08:37 |
| mvo | zyga: https://paste.ubuntu.com/p/HqzptYhJ9C/ | 08:37 |
| zyga | "exactly equals" ;-) | 08:37 |
| zyga | hmmmm | 08:37 |
| zyga | man, this is a curious issue :) | 08:38 |
| zyga | thank you mvo | 08:38 |
| mvo | mborzecki: interessting, worth checking if they have this in their tree | 08:38 |
| zyga | mborzecki: do we have that patch in our uboot | 08:38 |
| zyga | mborzecki: and how does it explain the random aspect | 08:39 |
| mborzecki | zyga: 'our' uboot? where is that? | 08:39 |
| mvo | mborzecki: they use https://github.com/Screenly/u-boot | 08:39 |
| zyga | could it be uninitialized memory | 08:39 |
| zyga | mborzecki: not sure, let me look at pi3 gadget | 08:39 |
| zyga | uboot is fairly (totally?) deterministic | 08:39 |
| zyga | but maybe something on reboot is not cleaned | 08:39 |
| zyga | and uninitialized memory could make some memcmp fial | 08:39 |
| zyga | *fail | 08:39 |
| mborzecki | mvo: can you grab the welcome banner when uboot starts? | 08:40 |
| mvo | mborzecki: sure, one sec | 08:40 |
| mvo | mborzecki: U-Boot 2017.05-dirty (Mar 12 2018 - 09:55:39 +0000) | 08:40 |
| mvo | mborzecki: I guess that is the answer | 08:41 |
| zyga | woah | 08:41 |
| zyga | dirty! | 08:41 |
| mvo | mborzecki: definitely worth investigating | 08:41 |
| mborzecki | haha ;) | 08:41 |
| mborzecki | at least it's not some random chinese manufacturer :) | 08:41 |
| mvo | I am still super puzzled that uboot happily loads uboot.env which I deleted from linux and is no longer visible in linux. apparently fat is hard | 08:42 |
| zyga | mvo: fat is easy, bound checks are hard ;) | 08:42 |
| zyga | mvo: at this stage I'd get back to screenly for their dirty uboot tree | 08:42 |
| zyga | this is a goose chase until we know what they are booting | 08:42 |
| zyga | mvo: would their patched uboot work on a vanilla pi? | 08:42 |
| zyga | mvo: maybe worth trying with that? | 08:43 |
| Chipaca | zyga: is that their uboot, or is it just the regular rpi uboot that's dirty? | 08:43 |
| zyga | Chipaca: good question | 08:43 |
| zyga | and if my pi had a serial port connected | 08:43 |
| mvo | zyga: we have the branch they build from on github | 08:43 |
| zyga | I would check | 08:43 |
| zyga | mvo: who uploaded the gadget? | 08:43 |
| mvo | zyga: their uboot works with my pi2, is that the question? | 08:43 |
| mvo | zyga: I think they do that | 08:43 |
| zyga | mvo: maybe the branch is not the thing that is really uploaed | 08:43 |
| zyga | some dev hacked a little thing and built that | 08:44 |
| zyga | and never commited | 08:44 |
| mvo | possible, but they build from snapcraft.yaml I would give them the benefit of the doubt for now :) | 08:44 |
| mvo | that they don't do crazy stuff | 08:44 |
| zyga | mvo: I don't disagree that they use snapcraft.yaml now, just that the initial build was dirty :) | 08:45 |
| zyga | mvo: can you swap to our pi SD card | 08:45 |
| zyga | mvo: and see if we show the same dirty string | 08:45 |
| zyga | (and if it builds and boots, ship it) | 08:45 |
| mvo | zyga: I can't do this easily right now (would need to reflash the image) | 08:46 |
| mvo | zyga: but iirc we are also dirty | 08:46 |
| zyga | ah | 08:46 |
| * zyga wonders where is ogra | 08:46 | |
| mvo | zyga: I only have one fast sd card :) | 08:46 |
| zyga | anyone with a pi handy? | 08:46 |
| mvo | zyga: maybe washing ;) | 08:46 |
| zyga | mvo: do you have a pi image for vanilla pi? | 08:46 |
| zyga | maybe strings | grep dirty | 08:46 |
| * zyga needs to move closer to the hospital, ttyl | 08:47 | |
| mvo | zyga: good luck | 08:48 |
| pbek | thank you popey, I now closed those channels for qownnotes | 08:56 |
| popey | yay | 08:56 |
| pedronis | pstolowski: hi, so another reason not to do too big PRs seems github performance, I'm still struggling to open your PR :/ | 09:03 |
| pstolowski | pedronis: :( | 09:03 |
| pstolowski | pedronis: pulling my branch and looking at latest commits might be faster? | 09:04 |
| pedronis | maybe but ideally I need to look at the comments too | 09:05 |
| pstolowski | right | 09:05 |
| pedronis | seems to have opened in a different browser | 09:06 |
| === chihchun_afk is now known as chihchun | ||
| zyga | re | 09:20 |
| * zyga waits at the hospital, focuses on existing branches | 09:20 | |
| pstolowski | pedronis: thanks for the NoOption comment, pushed | 09:22 |
| pstolowski | zyga: commented on 5107 | 09:22 |
| zyga | pstolowski: thanks, looking | 09:22 |
| popey | cjwatson: is there some way to get an rss feed from b.s.i builds in lp. feeds.launchpad.net/~build.snapcraft.io/snaps.atom kind of thing? | 09:25 |
| popey | (I couldn't find it) | 09:25 |
| zyga | pstolowski: replied | 09:27 |
| cjwatson | popey: no | 09:28 |
| pstolowski | zyga: thanks! | 09:28 |
| === Caelum_ is now known as Caelum | ||
| pedronis | pstolowski: lgtm | 09:30 |
| pstolowski | pedronis: ty, merge then? i'd squash-merge it.. | 09:31 |
| pedronis | pstolowski: yes, squash merge because there's so many commits | 09:31 |
| pedronis | needs to be green first | 09:31 |
| pstolowski | sure | 09:31 |
| mborzecki | mvo: hm the rspi image from cdimage.ubuntu.com has U-Boot 2016.03-rc3-00013-gf135e8f-dirty | 09:33 |
| mborzecki | let me check if i can build something more recent | 09:33 |
| zyga | mvo: I would check with ogra if we actually use the uboot from snapcraft.yaml | 09:34 |
| zyga | older gadget unpacked something from a tarball | 09:34 |
| zyga | which may have been made manually | 09:34 |
| ogra_ | that is long dead | 09:34 |
| zyga | ogra_: hey | 09:34 |
| zyga | ogra_: do you know what may have caused the "dirty" flag there? | 09:34 |
| ogra_ | sorry, my IRC proxy wendt down unnoticed ... | 09:35 |
| ogra_ | *wnt | 09:35 |
| ogra_ | bah | 09:35 |
| zyga | no worries :) | 09:35 |
| ogra_ | zyga, in stable we still use the old stuff, but screenly never used that | 09:35 |
| zyga | I don't understand | 09:35 |
| ogra_ | we switched to build-uboot-from-source ages ago but couldnt uzpgrade the gadget ... so stable still has the very first tries that used local builds from a tarball | 09:36 |
| mborzecki | i'm building from upstream | 09:37 |
| zyga | ogra_: which version shows the string "dirty" | 09:37 |
| ogra_ | zyga, the very first gadget we built | 09:37 |
| zyga | ogra_: screenly's gadget shows that too | 09:38 |
| zyga | ogra_: and mborzecki checked that rspi image on cdimage shows this too | 09:38 |
| zyga | is that expected? | 09:38 |
| nodeman | http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz | 09:38 |
| ogra_ | i dont have a serial attached pi atm ... perhaps newer ones show it too, not sure (after alkl we have to patch it ) | 09:38 |
| mborzecki | zyga: it's probably due to patching of rspi default env | 09:39 |
| nodeman | I'm having trouble getting this image working on the latest RPi, the model B+. Is it not supported? | 09:39 |
| mborzecki | zyga: hopefully only this | 09:39 |
| ogra_ | zyga, sorry, i got confused ... the one in stable was built from master-tip when pi was initially added to uboot (there was no other branch for pi back then) and was used from a local binary build ... the newer ones come from a stable tag in the upstream u-boot branch and are built dynamically ... | 09:40 |
| ogra_ | zyga, since we patch it to handle the config in a way snapd understands i belive they both get the dirty tag, but one comes from a stable source and the other from an "initial commit for this HW" | 09:41 |
| zyga | I see | 09:41 |
| zyga | thanks | 09:41 |
| ogra_ | zyga, sorry, i mixed up source and binary | 09:41 |
| zyga | mvo: I think #5132 would pass now if master is merged, shall I do that? | 09:43 |
| mup | PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5132> | 09:43 |
| mborzecki | zyga: i think it should be enough to restart the build | 09:44 |
| zyga | mborzecki: not sure, I can just merge | 09:44 |
| zyga | mborzecki: I don't think we re-merge | 09:44 |
| zyga | (on gh side) | 09:45 |
| mvo | zyga: sure, go for it | 09:45 |
| Chipaca | nodeman: the raspberry 1 B+ is not supported, no | 09:45 |
| zyga | done | 09:45 |
| Chipaca | nodeman: you need rpi 2 or 3 | 09:45 |
| zyga | nodeman: there's a preview image I think | 09:45 |
| zyga | nodeman: it's on the forum | 09:46 |
| zyga | ahhh | 09:46 |
| Chipaca | zyga: armel? | 09:46 |
| zyga | 1 | 09:46 |
| zyga | no no sorry | 09:46 |
| Chipaca | right | 09:46 |
| zyga | I confused that with 3B+ | 09:46 |
| Chipaca | wrong architecture | 09:46 |
| zyga | sorry about that, pi 1 is not going to be supported due to CPU incompatibility | 09:46 |
| Chipaca | nodeman: if by 'latest b+' you mean the 3 b+, then it can work as zyga says | 09:46 |
| nodeman | I mean RPi3 B+, getting a rainbow screen every time I boot up. | 09:47 |
| Chipaca | zyga: nodeman didn't specify :-) i started my answer with a question | 09:47 |
| nodeman | Sorry, for not specifying the 3 Chipaca . | 09:47 |
| Chipaca | nodeman: yep, the image from cdimage will not work | 09:47 |
| Chipaca | nodeman: i think it's the wrong bootloader or something; there's a preview image | 09:48 |
| Chipaca | let me find that for you | 09:48 |
| nodeman | Chipaca: thanks, I appreciate it. | 09:48 |
| Chipaca | nodeman: https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509/18?u=chipaca | 09:48 |
| Chipaca | nodeman: read the caveats there =) | 09:48 |
| * Chipaca takes a break | 09:49 | |
| zyga | anyone wants to have a 3rd look at https://github.com/snapcore/snapd/pull/5126 | 09:51 |
| mup | PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5126> | 09:51 |
| zyga | it's +2 and green | 09:51 |
| * Chipaca really breaks | 09:52 | |
| nodeman | Chipaca: thanks again. | 09:54 |
| pstolowski | about to merge interface hooks... if anyone wants to say something, now is the last chance... merging in 3...2...1.. | 10:01 |
| mup | PR snapd#4358 closed: interfaces: interface hooks implementation <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4358> | 10:06 |
| pstolowski | \o/ | 10:07 |
| pedronis | pstolowski: :) almostlunch but once you have merged master into the follow ups, let me know which one I should look at first | 10:10 |
| pstolowski | pedronis: thanks, just re-merging them, will let you know | 10:10 |
| === Faults_ is now known as Faults | ||
| pstolowski | i started getting 'Cannot allocate google:ubuntu-16.04-64: google: could not find default credentials.' from spread without changing anything on my side afaict.. did anything change? | 10:19 |
| zyga | hmm? | 10:22 |
| zyga | no, feels like a bug | 10:22 |
| pstolowski | zyga: does it work for you? | 10:24 |
| zyga | pstolowski: let me try | 10:27 |
| * zyga installs spread from a snap | 10:28 | |
| zyga | weird | 10:28 |
| zyga | I'm sure I had it but maybe I broke something | 10:28 |
| zyga | could not find credentials | 10:28 |
| zyga | whaat? | 10:28 |
| * zyga wonders | 10:28 | |
| zyga | pstolowski: which spread? | 10:29 |
| zyga | pstolowski: it works now (I think) | 10:29 |
| pstolowski | zyga: i've spread from snap | 10:30 |
| zyga | pstolowski: it works | 10:30 |
| pstolowski | zyga: ok, thanks for checking! | 10:30 |
| zyga | pstolowski: spread from snap doesn't work | 10:31 |
| zyga | not sure where the key comes from? | 10:31 |
| zyga | but $SPREAD_GOOGLE_KEY is empty for me? | 10:31 |
| zyga | no idea why | 10:31 |
| * zyga goes out of the hospital, ttyl | 10:36 | |
| pstolowski | zyga: ok, got it working, not sure what happened, but i switched to non-snap based spread and also re-initialized my gcloud config | 10:37 |
| zyga | pstolowski: weird, right? | 10:48 |
| zyga | wait | 10:48 |
| zyga | where's the google auth data storeD? | 10:48 |
| pstolowski | zyga: in ~/.config/gcloud afaict | 10:48 |
| mborzecki | played around with u-boot from our rpi3 image, could not get it to create duplicate files with lowercase/uppercase names | 10:49 |
| mborzecki | building upstream u-boot for rpi is somewhat silly though, none of the linaro toolchains i usually use work, did some extra steps, doesn't work either, i'm downloading official rpi toolchain | 10:51 |
| mborzecki | still amazed why people use it | 10:52 |
| zyga | fun | 10:52 |
| zyga | I spawnet some google machines | 10:53 |
| zyga | closed my laptop | 10:53 |
| zyga | moved out of the hospital | 10:53 |
| zyga | opened my laptop and re-connected to LTE | 10:53 |
| zyga | and I see those machines roll on :) | 10:53 |
| zyga | mborzecki: ouch! | 10:53 |
| zyga | mborzecki: and the bare armhf toolchain from ubuntu archive? | 10:53 |
| zyga | mborzecki: it's the linaro toolchain | 10:53 |
| mborzecki | i'm doing this on arch, besides official rpi toolchain is almost there | 10:54 |
| zyga | mborzecki: does lxd work on arch? | 10:56 |
| zyga | just curious | 10:56 |
| zyga | how portable the snap is | 10:56 |
| mborzecki | mborzecki: last time i used it it worked just fine | 10:59 |
| zyga | nice | 10:59 |
| zyga | Chipaca: should help say "command foo will print yada" or rather "command foo prints yada"? | 11:00 |
| Chipaca | zyga: wat | 11:01 |
| zyga | Chipaca: long help of snap commands | 11:01 |
| zyga | what's the preferred wording? | 11:01 |
| Chipaca | zyga: The foo command does x, y, and z | 11:02 |
| zyga | mmm,thanks | 11:02 |
| zyga | snap debug confinement doesn't follow that | 11:02 |
| zyga | but I will change it separately | 11:02 |
| zyga | thank you | 11:02 |
| Chipaca | zyga: ah, i haven't looked at the debug commands, I don't think | 11:03 |
| Chipaca | as they're hidden and not promised stable | 11:03 |
| zyga | I think they should do the same thing | 11:03 |
| zyga | as in, should be worded the same way | 11:03 |
| Chipaca | agreed, would be good | 11:03 |
| zyga | consistently | 11:03 |
| zyga | just nobody noticed :) | 11:04 |
| zyga | because <emoji> | 11:04 |
| Chipaca | yep, as i say i didn't look at them in my last consistency pass | 11:04 |
| mborzecki | pff what a joke, 'Your GCC is older than 6.0 and is not supported', obviously the official one is 4.7.1 | 11:05 |
| zyga | mborzecki: whaat? pi uses 4.7? | 11:15 |
| zyga | is that the new 2.96? | 11:16 |
| mborzecki | built it now with linaro toolchain, gcc 7.1 | 11:16 |
| pstolowski | pedronis: the next hooks PRs are #5120, #4767 and #4510, but the last two are not green now and i'm deconflicting them (5120 is ready for review and green) | 11:20 |
| mup | PR #5120: interfaces:interface-hooks for refresh <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5120> | 11:20 |
| mup | PR #4767: interfaces: disconnect hooks <Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767> | 11:20 |
| mup | PR #4510: asserts: use Attrer in policy checks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510> | 11:20 |
| === pstolowski is now known as pstolowski|lunch | ||
| === tai271828 is now known as tai271828_ | ||
| === tai271828_ is now known as tai271828 | ||
| * Chipaca ~> lunchy chunch | 11:37 | |
| ogra_ | chipunch | 11:40 |
| ogra_ | ... | 11:41 |
| niemeyer | Hellos! | 11:50 |
| zyga | hey | 11:59 |
| mup | PR snapd#5141 opened: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141> | 12:05 |
| jdstrand | noise][ (cc wgrant, sparkiegeek since natalia and roadmr aren't here): hey, I've been getting 504s on https://dashboard.snapcraft.io/reviewer/ubuntu/ yesterday, today and last friday and have been unable to review the store queue | 12:19 |
| jdstrand | noise][: https://status.snapcraft.io/ still looks ok | 12:20 |
| zyga | woah | 12:21 |
| jdstrand | cprov: fyi, ^ | 12:22 |
| cprov | jdstrand: ack, let me figure something out for you quickly | 12:25 |
| jdstrand | cprov: thanks! (wgrant, sparkiegeek - fyi, cprov is on it) | 12:25 |
| cprov | jdstrand: it loads for me, with a large number of snaps pending review | 12:26 |
| jdstrand | hmm | 12:26 |
| cprov | not really large, 27 new and 2 updated | 12:27 |
| jdstrand | cprov: https://dashboard.snapcraft.io loads for me, and clicking ono random things loads for me. but if navigate to that url, I get a 504 | 12:27 |
| wgrant | https://oops.canonical.com/oops/?oopsid=OOPS-8bc2e0c613f245e2969f321efeb6a431 has 15s of SQL time | 12:28 |
| jdstrand | cprov: most of those are kernel/gadgets that kyleN is a backlog that others are working through | 12:28 |
| zyga | vim crashed while editing api_test.go | 12:28 |
| jdstrand | s/that kyleN// | 12:28 |
| jdstrand | kyleN: (sorry for the noise) | 12:29 |
| cprov | jdstrand: yup, times out frequently here too | 12:29 |
| jdstrand | kyleN: I tried to leave you out of it. I guess my backspace key was broken :) | 12:29 |
| jdstrand | cprov: ah, so you got lucky | 12:29 |
| cprov | jdstrand: exactly | 12:30 |
| jdstrand | I mean, I can keep reloading the page (I had a few times today, yesterday and friday already) | 12:30 |
| jdstrand | ah, I got ucky | 12:30 |
| jdstrand | lucky even | 12:30 |
| jdstrand | yeah, 4 of those need to be looked at by me | 12:31 |
| jdstrand | cprov, wgrant: for the moment, shall I just keep retrying and you'll (get someone) to look into the timeouts? | 12:31 |
| === pstolowski|lunch is now known as pstolowski | ||
| jdstrand | zyga: what is up with hello-classic? is this a test snap? it was uploaded under your account, not the shared one | 12:33 |
| zyga | this is a demonstration snap that people can install and explore | 12:34 |
| zyga | I got a PR for it lately so I thought it should be published | 12:34 |
| cprov | jdstrand: I'd say so, it's not something we can fix instantly, but we should be able to improve things until EOD | 12:34 |
| pedronis | jdstrand: our official test snaps should all start with test-snapd- now | 12:34 |
| zyga | I can add it to a shared account but I don't know the process | 12:34 |
| jdstrand | zyga: did you do a forum request? | 12:34 |
| jdstrand | pedronis: yeah, that is what I thought | 12:34 |
| zyga | jdstrand: no, I'll do one shortly | 12:36 |
| jdstrand | cprov: thanks! | 12:37 |
| Son_Goku | O.o | 12:38 |
| Son_Goku | today I just learned that subiquity's engine can install CentOS?1 | 12:38 |
| Son_Goku | sabdfl, ^ ?! | 12:38 |
| pedronis | Son_Goku: you mean 'curtin' ? | 12:45 |
| Son_Goku | yes | 12:45 |
| Son_Goku | I mean, it's kinda dumb in some ways (based on how I read the logic in there), but I'm more surprised it can do it at all | 12:46 |
| ogra_ | whats the logic ? dd ? | 12:46 |
| ogra_ | or tar xf ? | 12:46 |
| ogra_ | :) | 12:46 |
| pedronis | I think its scope has grown a bit driven by maas use cases | 12:46 |
| Son_Goku | it can _sort of_ detect that it's targeting a CentOS system | 12:49 |
| ogra_ | AI !!! | 12:49 |
| Son_Goku | and write ifcfg network files | 12:49 |
| Son_Goku | and maybe write halfway correct yum repo files | 12:49 |
| zyga | jdstrand: https://forum.snapcraft.io/t/request-for-classic-confinement-hello-classic/5321 | 12:53 |
| zyga | jdstrand: I made an RFC branch that you may be interested in #5142 | 12:57 |
| mup | PR #5142: many: add "snap debug sandbox" and needed bits <Created by zyga> <https://github.com/snapcore/snapd/pull/5142> | 12:57 |
| mup | PR snapd#5142 opened: many: add "snap debug sandbox" and needed bits <Created by zyga> <https://github.com/snapcore/snapd/pull/5142> | 12:57 |
| zyga | mvo: I would look at linux fs/fat/namei_*.c | 13:31 |
| mup | PR snapd#5056 closed: cmd/snap: make confinement mode part of `snap version` output <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5056> | 13:33 |
| zyga | it's very interesting | 13:33 |
| * ogra_ would probably rather describe it as painful over "interesting" :) | 13:34 | |
| zyga | mborzecki: hey, how to check what a given shellcheck disable does? | 13:41 |
| mborzecki | zyga: pick the error and visit https://github.com/koalaman/shellcheck/wiki/SC2164 (change the number as required) | 13:47 |
| zyga | nice, thanks! | 13:47 |
| zyga | I'll review your PR soon | 13:47 |
| Chipaca | mborzecki: zyga: http://www.scp-wiki.net/scp-2164 | 13:48 |
| diddledan | dang, #2120 didn't make 2.42 :-( | 13:48 |
| mup | PR #2120: Fix installed-size not being set in GET v2/snaps <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2120> | 13:48 |
| diddledan | err | 13:48 |
| diddledan | not 2120 | 13:49 |
| Chipaca | snapcraft#2120 ? | 13:49 |
| mup | PR snapcraft#2120: many: dedup environment entries <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2120> | 13:49 |
| diddledan | yeah that one | 13:49 |
| sergiusens | diddledan: well, 2.42 is tagged and bagged, 2.43 or 2.42.1 from the looks of it, will come forward this week | 13:50 |
| diddledan | in related news, though, `snap install --candidate gimp` | 13:50 |
| sergiusens | but SRUing (which is what you want for build.snapcraft.io, takes at least a week of testing) | 13:50 |
| Chipaca | zyga: https://pastebin.ubuntu.com/p/Dmv6qgQcd8/ | 13:53 |
| === chihchun is now known as chihchun_afk | ||
| * zyga drives his mother home | 13:57 | |
| * diddledan drives his mother crazy | 14:01 | |
| zyga | Ooooh | 14:02 |
| zyga | Chipaca: i love that | 14:02 |
| zyga | Can we do an Easter egg where we snap install and run a dungeon snap | 14:03 |
| zyga | Or one of those old zork emulators | 14:03 |
| diddledan | what about some colossal cave quotes/actions? | 14:04 |
| diddledan | snap look: you are in a maze of twisty passages all alike | 14:05 |
| diddledan | snap xyzzy: nothing happens. | 14:06 |
| kyrofa | Hey mvo, if/when you have a minute, I'd appreciate your eyes on https://github.com/snapcore/snapcraft/pull/2119 | 14:15 |
| mup | PR snapcraft#2119: repo: automatically prune unneeded stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2119> | 14:15 |
| kyrofa | mvo, the apt API wasn't quite doing what I thought it was doing | 14:16 |
| Chipaca | zyga: the easter egg can be "snap debug looks for snap-debug-xyzzy when you try snap debug xyzzy", a la git | 14:19 |
| zyga | Chipaca: oh | 14:40 |
| zyga | that's nasty :) | 14:40 |
| zyga | in a good way | 14:40 |
| mborzecki | size-wise very nasty | 14:40 |
| * zyga looks at lwn and notices that https://lwn.net/Articles/753646/ has escallated quickly | 14:40 | |
| mborzecki | zyga: glibc joke? | 14:41 |
| zyga | aha | 14:41 |
| mborzecki | mid age drama :) | 14:42 |
| mup | PR snapd#5132 closed: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps <Critical> <Squash-merge> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5132> | 14:42 |
| zyga | mvo: closed? | 14:42 |
| zyga | $ snap debug sandbox https://www.irccloud.com/pastebin/h9EwxAUO/ | 14:43 |
| zyga | Chipaca: ^ any suggestions on output? | 14:43 |
| zyga | I was wondering if I should prefix all seccomp/apparmor features with something like "kernel-" | 14:43 |
| mborzecki | zyga: hacker news got agitated too https://news.ycombinator.com/item?id=17015644 | 14:44 |
| Chipaca | zyga: what would kernel- add? | 14:50 |
| zyga | Chipaca: allow us to define our own flags | 14:50 |
| Chipaca | zyga: i didn't follow | 14:51 |
| zyga | in case we want to say "kernel-dbus" and "we-do-something" | 14:51 |
| zyga | Chipaca: to namespace things | 14:51 |
| Chipaca | zyga: these flag names come from the kernel itself? | 14:51 |
| zyga | Chipaca: the list for apparmor and seccomp is coming from the kernel | 14:51 |
| zyga | Chipaca: for the rest it's a hard-coded constant | 14:51 |
| zyga | Chipaca: in case we want to have some constants and some kernel derived data | 14:51 |
| zyga | just a thought | 14:51 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5141/files#r186756803 | 14:54 |
| mup | PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141> | 14:54 |
| zyga | mborzecki: all the 1117s feel like a bug on our end | 14:55 |
| mborzecki | zyga: afaict we want the explicit "\n" | 14:57 |
| zyga | mborzecki: my understanding is that it says "\n" works by accident and wants us to use "\\n" which works explicitly | 14:57 |
| zyga | s/accident/fallback/ | 14:57 |
| mborzecki | zyga: hmm, but we do not want a newline ("\\n"), but an actual "\n" because this is passed to grep | 14:59 |
| zyga | then we can use ' ' | 14:59 |
| zyga | hmm | 14:59 |
| zyga | actually | 14:59 |
| zyga | mborzecki: echo "\n" and echo "\\n" | 14:59 |
| mborzecki | heh :) shell quoting | 14:59 |
| zyga | this is what you want | 14:59 |
| zyga | \\n is what we want IMO | 14:59 |
| zyga | without -e "\n" is nothin gspecial | 15:00 |
| zyga | *nothing special | 15:00 |
| zyga | mborzecki: does it make sense? | 15:01 |
| Chipaca | zyga: then yes I'd namespace them, or group them | 15:02 |
| zyga | Chipaca: kernel:foo or kernel<foo> or kernel-foo | 15:02 |
| zyga | Chipaca: what do you think we should use? | 15:02 |
| mvo | zyga: yes, I will summarize in the forum but create a separate PR with the before= fix | 15:02 |
| zyga | : is kind of nice | 15:02 |
| zyga | mvo: ack | 15:02 |
| zyga | thank you :) | 15:02 |
| mvo | zyga: its doing more than we most likley need (and is a bit of a can of worms) | 15:02 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/5141/files#r186759886 | 15:06 |
| mup | PR #5141: tests: shellchecks, part 1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5141> | 15:06 |
| mborzecki | zyga: in this particular case neither exit nor true makes sense probably | 15:11 |
| Chipaca | zyga: kernel:foo to distinguish it from kernel-foo | 15:13 |
| mborzecki | i bet this was refactored from install && exit 1 || true to the current variant with MATCH | 15:13 |
| Chipaca | zyga: ie explicitly namespaced | 15:13 |
| zyga | Chipaca: thanks, I'll tweak that | 15:13 |
| Chipaca | zyga: that way we can have kernel-foo and kernel:foo and they be different (although we should try not to :-) ) | 15:13 |
| mborzecki | Chipaca: if you feel like doing some reviews, can you take a look at 5141? specifically the places where SC1117 is disabled need shell-expert-in-quoting level input | 15:15 |
| Chipaca | heh | 15:18 |
| Chipaca | mborzecki: looking | 15:18 |
| Chipaca | mborzecki: any reason not to instead double up on the \s we do mean? | 15:21 |
| Chipaca | I mean, to give shellcheck credit, in "\d foo \"bar\" meep" it isn't immediately obvious that you want one, and not three, backslashes in the output | 15:22 |
| Chipaca | mborzecki: should i just ask in the pr :-) | 15:22 |
| cjwatson | zyga: you want printf - echo is unportable across different shells as soon as backslashes are involved, basically | 15:22 |
| ogra_ | +1 | 15:23 |
| * Chipaca thinks about mentioning $'' quotes, but decides against it | 15:24 | |
| ogra_ | shellcheck -s sh ... usually even tells you | 15:24 |
| Chipaca | ogra_: to be fair, spread checks are defined to be bash | 15:24 |
| Chipaca | so bashisms are ok (and encouraged when they help legibility) | 15:24 |
| ogra_ | thats insane | 15:24 |
| cjwatson | http://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_16 describes the unportability more precisely but it's basically the above | 15:24 |
| mborzecki | and shellcheck is run with -s bash by the helper | 15:24 |
| ogra_ | but we had this discussion ( niemeyer and I) and I lost back then | 15:24 |
| cjwatson | IMO printf is more legible than remembering when to use echo -e, in any case :) | 15:25 |
| mborzecki | cjwatson: definitely agree! | 15:25 |
| zyga | cjwatson: ack, good suggestion | 15:32 |
| zyga | much nicer "snap debug sandbox" https://www.irccloud.com/pastebin/7juy1qfc/ | 15:33 |
| zyga | Chipaca: ^ :-) | 15:34 |
| Chipaca | you say that, but i might disagree | 15:35 |
| Chipaca | i mean, it's impossibly wide now | 15:35 |
| Chipaca | OTOH it's a debug tool | 15:35 |
| Chipaca | eh | 15:35 |
| Chipaca | zyga: what are the commas adding? | 15:36 |
| zyga | Chipaca: nothing, just a list delimiter | 15:36 |
| Chipaca | zyga: I'd drop them unless you expect a space in the identifiers | 15:37 |
| Chipaca | zyga: either way it's good to go | 15:37 |
| zyga | Chipaca: I can drop them, sure | 15:37 |
| zyga | that's client side | 15:37 |
| zyga | the API just gives you a list | 15:37 |
| zyga | Chipaca: done now | 15:46 |
| zyga | jdstrand: hey | 15:47 |
| zyga | jdstrand: I'd like to query your TODO list, when do you think you can spare time to do a review of https://github.com/snapcore/snapd/pull/5081 | 15:47 |
| mup | PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081> | 15:47 |
| zyga | I would like to plan subsequent work based on that | 15:47 |
| jdstrand | zyga: planning on it today | 15:48 |
| zyga | woot, perfect, thank you! | 15:51 |
| zyga | :-) | 15:51 |
| zyga | Son_Goku: about my fedora-derivative | 15:51 |
| zyga | Son_Goku: I called it "folded hat" as it referes to origami style of snapcraft logo and to the hat reference to fedora | 15:51 |
| zyga | Son_Goku: gustavo suggested a more catchy name in case it sticks longer | 15:52 |
| zyga | Son_Goku: do you have any suggestions or preferences? | 15:52 |
| niemeyer | zyga: How about fcore28? | 15:55 |
| zyga | hmm, I don't personally like that, it's not a nice word | 15:56 |
| zyga | maybe just f28 | 15:56 |
| zyga | would calling it f28 be okay Pharaoh_Atem? | 15:56 |
| zyga | as long as we call f "folded hat" inside | 15:56 |
| zyga | and can rename to fedora once it is approved | 15:56 |
| zyga | f28 would be really short and nice | 15:56 |
| niemeyer | Short, but not quite nice | 16:18 |
| Chipaca | niemeyer: well, the f28 is a fokker | 16:18 |
| Chipaca | so that's nice | 16:18 |
| pedronis | it sounds a fortran version | 16:19 |
| * pedronis ducks | 16:19 | |
| niemeyer | fedcore28 | 16:20 |
| mvo | I declare victory over understanding the vfat uboot.env/UBOOT.ENV and get dinner | 16:20 |
| Chipaca | mvo: congrats! | 16:21 |
| mvo | Chipaca: thank you! | 16:24 |
| Chipaca | mvo: I see some reference to FSCK0000.000 from people complaining about gparted, fwiw | 16:24 |
| Chipaca | mvo: aha! dosfstools creates those files | 16:27 |
| zyga | mvo: what's the root cause? | 16:27 |
| Chipaca | mvo: (dosfstools is where fsck.fat lives … so it's probably not news to you :-|) | 16:29 |
| zyga | niemeyer: I would say that fedcore is too close to fedora that we should not use it without getting this acked by the fedora trademark owners; I honestly think the temporary name I originally selected was okay and it's just for one demo; perhaps I can just send the snap to neal instead of uploading it to the store | 16:29 |
| niemeyer | zyga: The goal is for it to be too close to Fedora, I believe | 16:29 |
| zyga | not really, it's based on fedora but doesn't use the name | 16:29 |
| niemeyer | zyga: We don't need acknoledgement from anyone for the use of the prefix "fed".. I'm pretty sure there's even prior art here ;) | 16:30 |
| zyga | once we can we should just call it what it is, fedora | 16:30 |
| zyga | niemeyer: I don't want it to live on as fedcore, I'm sure fedora would not want that either (they would like to pick the name as they would maintain and publish the snap) | 16:30 |
| === tai271828 is now known as tai271828_ | ||
| zyga | again, this is a demo | 16:30 |
| zyga | the real name will belong to fedora server team | 16:30 |
| niemeyer | zyga: That's a pretty awkward rationale.. you're trying to find something that specifically doesn't sound like it's related to Fedora for something whose only point is being related to Fedora | 16:31 |
| niemeyer | zyga: anti-goal | 16:31 |
| === tai271828_ is now known as tai271828 | ||
| zyga | I can call it zygonix, it's just a demo based on fedora without the trademark | 16:31 |
| niemeyer | zyga: That's not a competition for awkward names | 16:32 |
| niemeyer | zyga: fedcore has no trademark | 16:32 |
| zyga | I'm not a lawyer | 16:32 |
| zyga | I didn't want to use a prefix of the real name | 16:32 |
| niemeyer | zyga: Exactly | 16:32 |
| zyga | it's a _temporary_ name as the real snap will be published by fedora if they choose to pursue this | 16:33 |
| zyga | if not we can remove it from the store | 16:33 |
| niemeyer | zyga: That's what we're talking about | 16:33 |
| pstolowski | pedronis: thanks for the review! | 16:34 |
| pedronis | np | 16:35 |
| pedronis | it was mostly already reviewed in the previous one | 16:35 |
| pedronis | before the splitting out | 16:35 |
| pedronis | sorry it took me a bit, we had long chat after the HO and also my internet connection has been giving me troubles today a couple of times since standup | 16:36 |
| pstolowski | np! | 16:42 |
| * zyga needs to head home | 16:50 | |
| === pstolowski is now known as pstolowski|afk | ||
| * Chipaca calls it a day | 17:00 | |
| mup | PR snapcraft#2126 opened: packaging: load the correct libraries on armhf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2126> | 17:27 |
| mup | PR snapd#5143 opened: tests: speed up save/restore snapd state for all-snap systems suring tests execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5143> | 17:48 |
| mvo | niemeyer: I replied to 5124 (just fyi) happy to implement either approach | 18:26 |
| pedronis | mvo: at the start we are not seeded nor there's a seed change, so just looking for the change or no change at all is fragile | 18:30 |
| pedronis | I commented in the PR about this as well | 18:30 |
| niemeyer | mvo: I think it would make sense in general for the command to have an option to say "wait for the change to exist, if it's not there yet" | 18:32 |
| pedronis | well that doesn't work after the change is done but pruned | 18:33 |
| pedronis | it will never show up | 18:33 |
| pedronis | I fear if we want to reuse watch we need to add some custom code for these kind of changes | 18:33 |
| pedronis | or we don't prune suceeded seed or become-operational changes (but that doesn't cover preexisting systems) | 18:35 |
| mup | PR snapd#5144 opened: tests: update bionic release image on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5144> | 18:40 |
| mup | PR core-build#29 opened: ubuntu-core-rootfs: deal with leftover fsck files <Created by mvo5> <https://github.com/snapcore/core-build/pull/29> | 18:41 |
| mvo | pedronis: good point(s) | 18:43 |
| pedronis | tbh there is some argument to keep the last seed and become-operational forever (for transparency) but wouldn't help for systems already out there since a bit | 18:44 |
| zyga | Im home now | 18:52 |
| zyga | Had to walk a bit because all the bikes were gone | 18:52 |
| === blackboxsw is now known as blackboxs | ||
| === blackboxs is now known as blackboxsw | ||
| mup | PR snapcraft#2127 opened: delta: properly search for in-snap xdelta3 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2127> | 19:09 |
| * cachio_ afk | 19:40 | |
| mup | PR snapcraft#2126 closed: packaging: load the correct libraries on armhf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2126> | 20:22 |
| mwhudson | is there a way to make snap dump out the api requests it's making to snapd? | 22:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!