[05:02] morning [05:18] PR snapd#5138 closed: cmd/libsnap: fix compile error on more restrictive gcc

[05:23] PR snapd#5139 opened: cmd/libsnap: fix compile error on more restrictive gcc (2.32) [05:36] mvo: morning [05:36] mborzecki, mvo: do we have fedora 28 CI live now? [05:36] mvo: i've merged 5138 and opened a followup for 2.32 -> #5139 [05:36] PR #5139: cmd/libsnap: fix compile error on more restrictive gcc (2.32) [05:36] and maybe even rawhide CI? [05:37] Son_Goku: don't know if cachio has added f28 image yet [05:37] well, unfortunately I'm a bit unable to test much of anything on hotel wifi :/ [05:37] so I was hoping that'd be up by now to be sure that the compilation errors are all fixed [05:39] mborzecki: thank you! and good morning [05:40] Son_Goku: I will followup with cachio on that today [05:40] mvo, zyga, I'm in San Francisco for Red Hat Summit this week [05:40] so among other things, I intend to talk to Fedora folks on a wide array of topics [05:41] which is why I was hoping zyga would have ironed out the issues that prevented a working fedora base snap [05:41] and created an app snap that uses a fedora base to demo the concept [05:42] Son_Goku: woah, cool! [05:43] 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] Son_Goku: great news [05:43] he mentioned he did play with fedora base on friday (?) last week and he had some progress [06:11] afk for ~30 minutes [06:13] PR snapd#5139 closed: cmd/libsnap: fix compile error on more restrictive gcc (2.32) [06:16] Hey [06:16] Son_Goku: i have something close that you can show [06:16] I will share it soon [06:16] I have a bit of a hectic day [06:17] Need to go with my mom to a hospital [06:17] But I will work most of the time [06:18] ok [06:53] * zyga commutes to the hospital [07:07] re === pstolowski|afk is now known as pstolowski [07:10] morning [07:10] pstolowski: hey [07:37] pushed an update to arch package with gcc build fixes patch [07:40] mborzecki: ta [08:01] re [08:03] mvo: how are we doing for .7? [08:03] how can I help [08:04] 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] zyga: I'm looking at the screenly issue right now [08:05] mvo: at the lower vs UPPER thing? [08:05] mvo: do you think that we could use my suggestion on mounting fat in a specific way? [08:06] mvo: I added one more option on the #5132 naming thing [08:06] PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps

[08:06] zyga: yeah, the corruption thing, I wrote up https://forum.snapcraft.io/t/snapd-causes-corruption-on-upgrade/5253/20 [08:07] 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] mvo: canyou check if mounting it with that option helps [08:07] it should be a simple tweak to fstab [08:07] zyga: I did, I still see two lower-case uboot.env files and cat gives me the wrong one [08:08] bummer! [08:08] an fsck? [08:08] zyga: but let me try to write it [08:08] does fscking fixes anything? [08:08] zyga: fsck.vfat is clean :/ [08:09] well, at this stage I think linux is broken there :/ [08:11] well, how did they end up with both? [08:12] mborzecki: thats the big question - uboot writes it, it contains snap_mode=trying [08:12] mborzecki: FAT is apparently still hard [08:12] mborzecki: however its unclear why it does it, in most cases it writes the right file [08:13] 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] maybe magic sd card controller groking fat? [08:13] this also works when I don't use a sd card but just the plain image [08:13] which one was written by fw_setenv? [08:14] and fatcat shows me the right "cluster" [08:14] mborzecki: none [08:14] mborzecki: the uboot binary writes with its own code (which may be reused in fw_setenv, I don't know) [08:14] so it's the uboot script that wrote it? [08:14] mborzecki: and we write using our own code [08:14] mborzecki: correct [08:14] mborzecki: one sec, I can paste it [08:15] mvo: if you do fatls in uboot does it show both files? [08:15] mborzecki: https://paste.ubuntu.com/p/7zCCzgh76j/ <- output sucks [08:15] 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:16] mborzecki: https://paste.ubuntu.com/p/psgTgfwFz5/ - it shows both files [08:17] mvo: what is the relationship of uboot.env to uboot.bin? [08:17] there's only one .bin [08:17] maybe (apart from .env being duplicated) the issue is really in .bin? [08:18] mborzecki: doing fatload mmc 0 9999999 UBOOT.ENV gives me the same conent for upper and lower case [08:19] zyga: we don't write anything on this sd except UBOOT.ENV [08:19] mvo: how are you testing this? using a raspberry pi? [08:20] moin moin [08:20] hey Chipaca! [08:20] zyga: uboot.bin is the actual uboot, it's loaded by one of the start*.elf binaries [08:20] how are you doing? [08:20] mborzecki: ah, thanks [08:20] Chipaca: hey [08:20] 'm hot =) [08:20] how're you guys? [08:20] zyga: yes, I got the corrupted image and wrote it to a sd card and play with it on my pi [08:21] mvo: what happens if you use uboot [08:21] and write some new variable [08:21] and save that [08:21] did you perform such an experiment? [08:21] frozbonicator=schnibble [08:21] saveenv or whatever that was [08:21] and see what's on FAT [08:22] zyga: it happens implicitly because snap_mode=try triggers snap_mode=trying and saveenv. I did not try explicitly though, can do [08:22] I wonder where it will go [08:23] zyga: pretty sur eit will go to uboot.env (lower) but I can try [08:23] zyga: from snapd's pov that's a file mounted on a vfat fs, yes? [08:23] Chipaca: yes [08:23] zyga: why vfat and not msdos? [08:23] Chipaca: mvo tried mounting it in a few ways [08:23] Chipaca: ha, perhaps good question [08:24] vfat implies long file names [08:24] maybe uboot doesn't do that [08:24] though msdos is AFAIK a variant of fvat with different options [08:24] it would be good if we could reproduce this though [08:24] mvo: question [08:24] ha [08:24] maybe a good one actually :D [08:24] mvo: how do we write that file from snapd [08:24] are we ... by any chance.. use atomic renames? [08:24] write a new _long_ random file name a rename? [08:25] could it be that by doing that our file lives in the LFS domain? [08:25] and uboot just says "meh, don't grok" [08:26] and writes a new file [08:26] then stuff goes south [08:26] though this doesn't explain why it only happens once in blue moon [08:26] maybe the random pattern (if that part is random) needs to be special to trigger this [08:26] 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:27] aha, so that's out the door then [08:27] hmmmm [08:27] * zyga looks at the code [08:27] 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:28] mborzecki: thanks [08:28] mydata->fatsize [08:28] I wonder if it would help if we mounted it as fat16 [08:28] is it fat16 or fat32? [08:28] mborzecki: yeah, I remember looking at this file a while ago [08:28] or fat12, I forgot the variants [08:28] I think fat32 [08:28] but not 100% certain [08:29] 980 downcase(l_filename, INT_MAX); [08:30] 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] mvo: can you try mounting it with check=s ? [08:31] so it's essentially using lower case for lookup [08:31] mborzecki: done, no change afaict [08:31] hm wonder what they set ENV_FAT_FILE to [08:32] augh, laptop is suspend-cycling [08:32] hmm [08:32] wtf [08:32] mvo: since both are lower case is there a chance that there's a space or something like that there? [08:33] zyga: I can't see spaces with the tools I have, I can write some code though, let me see [08:33] can you fatcat | od -t c [08:33] from linux [08:33] that should show invisibles [08:34] 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] " [08:34] drat :/ [08:34] zyga: how would I know if the space is a space or part of the filename? [08:34] yeah [08:34] sucks [08:34] it does [08:35] FAT uses one table or two? [08:35] two afaik [08:35] fwiw, filesystem is FAT32 [08:36] mvo: does fatcat -o show anything? [08:36] mvo: and what does fatcat -i say? [08:37] zyga: https://paste.ubuntu.com/p/ZmShHTXkYY/ [08:37] hmm https://git.denx.de/?p=u-boot.git;a=commit;h=2c33b0c7d8deca7e9a907365a59fcbcde531c70d [08:37] zyga: https://paste.ubuntu.com/p/HqzptYhJ9C/ [08:37] "exactly equals" ;-) [08:37] hmmmm [08:38] man, this is a curious issue :) [08:38] thank you mvo [08:38] mborzecki: interessting, worth checking if they have this in their tree [08:38] mborzecki: do we have that patch in our uboot [08:39] mborzecki: and how does it explain the random aspect [08:39] zyga: 'our' uboot? where is that? [08:39] mborzecki: they use https://github.com/Screenly/u-boot [08:39] could it be uninitialized memory [08:39] mborzecki: not sure, let me look at pi3 gadget [08:39] uboot is fairly (totally?) deterministic [08:39] but maybe something on reboot is not cleaned [08:39] and uninitialized memory could make some memcmp fial [08:39] *fail [08:40] mvo: can you grab the welcome banner when uboot starts? [08:40] mborzecki: sure, one sec [08:40] mborzecki: U-Boot 2017.05-dirty (Mar 12 2018 - 09:55:39 +0000) [08:41] mborzecki: I guess that is the answer [08:41] woah [08:41] dirty! [08:41] mborzecki: definitely worth investigating [08:41] haha ;) [08:41] at least it's not some random chinese manufacturer :) [08:42] 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] mvo: fat is easy, bound checks are hard ;) [08:42] mvo: at this stage I'd get back to screenly for their dirty uboot tree [08:42] this is a goose chase until we know what they are booting [08:42] mvo: would their patched uboot work on a vanilla pi? [08:43] mvo: maybe worth trying with that? [08:43] zyga: is that their uboot, or is it just the regular rpi uboot that's dirty? [08:43] Chipaca: good question [08:43] and if my pi had a serial port connected [08:43] zyga: we have the branch they build from on github [08:43] I would check [08:43] mvo: who uploaded the gadget? [08:43] zyga: their uboot works with my pi2, is that the question? [08:43] zyga: I think they do that [08:43] mvo: maybe the branch is not the thing that is really uploaed [08:44] some dev hacked a little thing and built that [08:44] and never commited [08:44] possible, but they build from snapcraft.yaml I would give them the benefit of the doubt for now :) [08:44] that they don't do crazy stuff [08:45] mvo: I don't disagree that they use snapcraft.yaml now, just that the initial build was dirty :) [08:45] mvo: can you swap to our pi SD card [08:45] mvo: and see if we show the same dirty string [08:45] (and if it builds and boots, ship it) [08:46] zyga: I can't do this easily right now (would need to reflash the image) [08:46] zyga: but iirc we are also dirty [08:46] ah [08:46] * zyga wonders where is ogra [08:46] zyga: I only have one fast sd card :) [08:46] anyone with a pi handy? [08:46] zyga: maybe washing ;) [08:46] mvo: do you have a pi image for vanilla pi? [08:46] maybe strings | grep dirty [08:47] * zyga needs to move closer to the hospital, ttyl [08:48] zyga: good luck [08:56] thank you popey, I now closed those channels for qownnotes [08:56] yay [09:03] pstolowski: hi, so another reason not to do too big PRs seems github performance, I'm still struggling to open your PR :/ [09:03] pedronis: :( [09:04] pedronis: pulling my branch and looking at latest commits might be faster? [09:05] maybe but ideally I need to look at the comments too [09:05] right [09:06] seems to have opened in a different browser === chihchun_afk is now known as chihchun [09:20] re [09:20] * zyga waits at the hospital, focuses on existing branches [09:22] pedronis: thanks for the NoOption comment, pushed [09:22] zyga: commented on 5107 [09:22] pstolowski: thanks, looking [09:25] 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] (I couldn't find it) [09:27] pstolowski: replied [09:28] popey: no [09:28] zyga: thanks! === Caelum_ is now known as Caelum [09:30] pstolowski: lgtm [09:31] pedronis: ty, merge then? i'd squash-merge it.. [09:31] pstolowski: yes, squash merge because there's so many commits [09:31] needs to be green first [09:31] sure [09:33] mvo: hm the rspi image from cdimage.ubuntu.com has U-Boot 2016.03-rc3-00013-gf135e8f-dirty [09:33] let me check if i can build something more recent [09:34] mvo: I would check with ogra if we actually use the uboot from snapcraft.yaml [09:34] older gadget unpacked something from a tarball [09:34] which may have been made manually [09:34] that is long dead [09:34] ogra_: hey [09:34] ogra_: do you know what may have caused the "dirty" flag there? [09:35] sorry, my IRC proxy wendt down unnoticed ... [09:35] *wnt [09:35] bah [09:35] no worries :) [09:35] zyga, in stable we still use the old stuff, but screenly never used that [09:35] I don't understand [09:36] 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:37] i'm building from upstream [09:37] ogra_: which version shows the string "dirty" [09:37] zyga, the very first gadget we built [09:38] ogra_: screenly's gadget shows that too [09:38] ogra_: and mborzecki checked that rspi image on cdimage shows this too [09:38] is that expected? [09:38] http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ubuntu-core-16-pi3.img.xz [09:38] i dont have a serial attached pi atm ... perhaps newer ones show it too, not sure (after alkl we have to patch it ) [09:39] zyga: it's probably due to patching of rspi default env [09:39] I'm having trouble getting this image working on the latest RPi, the model B+. Is it not supported? [09:39] zyga: hopefully only this [09:40] 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:41] 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] I see [09:41] thanks [09:41] zyga, sorry, i mixed up source and binary [09:43] mvo: I think #5132 would pass now if master is merged, shall I do that? [09:43] PR #5132: snap,wrappers: allow "external:{snapd,snapd.seeded}" for snap apps

[09:44] zyga: i think it should be enough to restart the build [09:44] mborzecki: not sure, I can just merge [09:44] mborzecki: I don't think we re-merge [09:45] (on gh side) [09:45] zyga: sure, go for it [09:45] nodeman: the raspberry 1 B+ is not supported, no [09:45] done [09:45] nodeman: you need rpi 2 or 3 [09:45] nodeman: there's a preview image I think [09:46] nodeman: it's on the forum [09:46] ahhh [09:46] zyga: armel? [09:46] 1 [09:46] no no sorry [09:46] right [09:46] I confused that with 3B+ [09:46] wrong architecture [09:46] sorry about that, pi 1 is not going to be supported due to CPU incompatibility [09:46] nodeman: if by 'latest b+' you mean the 3 b+, then it can work as zyga says [09:47] I mean RPi3 B+, getting a rainbow screen every time I boot up. [09:47] zyga: nodeman didn't specify :-) i started my answer with a question [09:47] Sorry, for not specifying the 3 Chipaca . [09:47] nodeman: yep, the image from cdimage will not work [09:48] nodeman: i think it's the wrong bootloader or something; there's a preview image [09:48] let me find that for you [09:48] Chipaca: thanks, I appreciate it. [09:48] nodeman: https://forum.snapcraft.io/t/support-for-raspberry-pi-3-model-b/4509/18?u=chipaca [09:48] nodeman: read the caveats there =) [09:49] * Chipaca takes a break [09:51] anyone wants to have a 3rd look at https://github.com/snapcore/snapd/pull/5126 [09:51] PR #5126: cmd/snap-update-ns: add support for ignoring mounts with missing source/target [09:51] it's +2 and green [09:52] * Chipaca really breaks [09:54] Chipaca: thanks again. [10:01] about to merge interface hooks... if anyone wants to say something, now is the last chance... merging in 3...2...1.. [10:06] PR snapd#4358 closed: interfaces: interface hooks implementation [10:07] \o/ [10:10] pstolowski: :) almostlunch but once you have merged master into the follow ups, let me know which one I should look at first [10:10] pedronis: thanks, just re-merging them, will let you know === Faults_ is now known as Faults [10:19] 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:22] hmm? [10:22] no, feels like a bug [10:24] zyga: does it work for you? [10:27] pstolowski: let me try [10:28] * zyga installs spread from a snap [10:28] weird [10:28] I'm sure I had it but maybe I broke something [10:28] could not find credentials [10:28] whaat? [10:28] * zyga wonders [10:29] pstolowski: which spread? [10:29] pstolowski: it works now (I think) [10:30] zyga: i've spread from snap [10:30] pstolowski: it works [10:30] zyga: ok, thanks for checking! [10:31] pstolowski: spread from snap doesn't work [10:31] not sure where the key comes from? [10:31] but $SPREAD_GOOGLE_KEY is empty for me? [10:31] no idea why [10:36] * zyga goes out of the hospital, ttyl [10:37] 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:48] pstolowski: weird, right? [10:48] wait [10:48] where's the google auth data storeD? [10:48] zyga: in ~/.config/gcloud afaict [10:49] played around with u-boot from our rpi3 image, could not get it to create duplicate files with lowercase/uppercase names [10:51] 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:52] still amazed why people use it [10:52] fun [10:53] I spawnet some google machines [10:53] closed my laptop [10:53] moved out of the hospital [10:53] opened my laptop and re-connected to LTE [10:53] and I see those machines roll on :) [10:53] mborzecki: ouch! [10:53] mborzecki: and the bare armhf toolchain from ubuntu archive? [10:53] mborzecki: it's the linaro toolchain [10:54] i'm doing this on arch, besides official rpi toolchain is almost there [10:56] mborzecki: does lxd work on arch? [10:56] just curious [10:56] how portable the snap is [10:59] mborzecki: last time i used it it worked just fine [10:59] nice [11:00] Chipaca: should help say "command foo will print yada" or rather "command foo prints yada"? [11:01] zyga: wat [11:01] Chipaca: long help of snap commands [11:01] what's the preferred wording? [11:02] zyga: The foo command does x, y, and z [11:02] mmm,thanks [11:02] snap debug confinement doesn't follow that [11:02] but I will change it separately [11:02] thank you [11:03] zyga: ah, i haven't looked at the debug commands, I don't think [11:03] as they're hidden and not promised stable [11:03] I think they should do the same thing [11:03] as in, should be worded the same way [11:03] agreed, would be good [11:03] consistently [11:04] just nobody noticed :) [11:04] because [11:04] yep, as i say i didn't look at them in my last consistency pass [11:05] pff what a joke, 'Your GCC is older than 6.0 and is not supported', obviously the official one is 4.7.1 [11:15] mborzecki: whaat? pi uses 4.7? [11:16] is that the new 2.96? [11:16] built it now with linaro toolchain, gcc 7.1 [11:20] 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]