[05:00] Good morning [05:08] morning [05:45] Hi [05:46] zyga: hey [05:46] zyga: hey ! how if flock? [05:46] hey mborzecki [05:47] mvo: mornings [05:47] zyga: yeah, how's flock? you're gonna miss the morning yoga class [05:50] So far things are very hot because not much a/c [05:50] I was drying my clothing ;-) [05:51] How are things [05:51] When is the next release? [05:55] zyga: beta this week I think [06:56] hmm running into some problems with snapd under lxd on arch (quite a combo) [06:56] snapd actually works again after i made the container privileged, but i see an odd issue with reloading udev rules [07:01] https://paste.ubuntu.com/p/xpK7vgfsMG/ [07:02] Hey mvo [07:02] Flock is just starting [07:02] Looking forward to the release [07:02] zyga: good luck :) === pstolowski|afk is now known as pstolowski [07:03] morning [07:03] zyga: cool, yeah, looking over the open PRs right now [07:03] pstolowski: hey, good morning [07:10] so udevadm control --reload-rules fails with status 2, but no output [07:24] pstolowski: not sure if you got my message from yesterday, I got a bit carried away when reviewing the udevadm output parser. hope its ok [07:24] mvo: yes! thanks for the review and for playing with it! i'm on it [07:34] pstolowski: I really like the go scanner customization possiblities, its pretty simpel but quite powerful at the same time [07:35] pstolowski: anyway, happy that you find it interessting [07:38] and installing any snap that triggers udev rule reload fails too [08:04] mvo: could you take a look at https://forum.snapcraft.io/t/error-cannot-assert-container-build-on-arch-linux-fails/6655/7 ? who would know more about udev & lxc? [08:07] mborzecki: sure, looking [08:20] mvo: addressed your feedback to #5505 [08:37] pstolowski: thank you! this looks great, I went over it in full again and added some more small ideas but feel free to ignore [08:43] something wrong with travis job queue? builds seem to be stuck [08:54] mvo: thanks again; updated [09:03] pstolowski: very nice! thank you. lets merge it once its green [09:05] yay [09:20] pstolowski: nice job, lots is landing right now [09:23] there's also a bunch of snapcraft jobs queued up so there's that :) [09:29] * Son_Goku waves === chihchun is now known as chihchun_afk [10:10] popey: who would be right person to ask for a review of https://github.com/snapcrafters/sentry/pull/8/files ? [10:14] mvo: https://errors.ubuntu.com/?release=Ubuntu%2016.04&period=day <-fun [10:20] mborzecki: hey, is instance work something that is ready to be demonstrated? [10:22] zyga: maybe, you can grab it here https://github.com/snapcore/snapd/pull/5596 , some caveats though, you can install only one snap from the store using _ name, but you can snap install --dangerous --name snap_foo as many as you like [10:22] That is ok [10:22] zyga: things may be rough aroudn the edges, but installing, removing, running should work [10:22] I plan to do locally built demos [10:22] Thanks [10:22] zyga: ping me when you need help === chihchun_afk is now known as chihchun [10:27] Thank you [10:32] Chipaca: uh, all ERROR [daemon-reload] failed with exit status 1: Failed to execute operation: Connection timed out ? [10:32] Chipaca: i.e. have you looked at the details yet? [10:32] Chipaca: thats the stable core refresh interacting badly with the amazon linux agent? [10:32] mvo: the ones I looked at, the syslog seemed bad [10:32] sergiusens: i'm not a python expert, but i can't install black on my xenial box [10:33] https://pastebin.ubuntu.com/p/wnvmdp8HRq/ [10:33] if i pip search, i can see it, but i'm unable to install it [10:33] mvo: but, yes, all amazon-ssm-agent [10:33] is it beacuse it requires python 3.6.0+? [10:33] Chipaca: any hints what goes on that triggers the bug? [10:34] sergiusens: but then we are implicitly requiring python 3.6.0+ for the entire snapcraft project then [10:35] mvo: no [10:35] Chipaca: hm, the random one I just looked at has "Aug 08 10:23:53 ip-10-0-136-110 kernel: INFO: task setfont:701 blocked for more than 120 seconds." [10:35] Chipaca: within a kernel oops [10:35] mvo: same in all the ones i saw [10:36] yep, my feeling is that we moved the requirement to 3.6.x: [10:36] python3-dev | 3.5.1-3 | xenial | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x [10:36] python3-dev | 3.6.5-3 | bionic | amd64, arm64, armhf, i386, ppc64el, s390x [10:37] Chipaca: very strange, I wonder what is going on there [11:09] mthaddon: sorry, missed the ping. me, now. [11:11] mvo, hey, yesterday I tried to mount initrd but I couldn't [11:11] Hey hey [11:12] Still alive and kicking [11:12] Some interesting observations coming from Flock [11:12] Some plenaries left, them more individual sessions [11:12] mvo, https://paste.ubuntu.com/p/tpqnJW5VVD/ [11:17] popey: fantastic, thanks === pstolowski is now known as pstolowski|lunch [11:42] cachio: i thought you couldn't mount initrd [11:42] Chipaca, yes, I couldn't [11:42] Chipaca, any idea how to do it? [11:43] cachio: what does ‘file /home/sergio/test/lab/kernel/initrd.img’ say? [11:44] -rw-r--r-- 1 root root 9684891 jul 31 08:45 initrd.img [11:44] Chipaca, which info do you want? [11:45] cachio: the output of ‘file /home/sergio/test/lab/kernel/initrd.img’ :-) [11:45] cachio: ‘file’ is a command [11:45] Chipaca, hehe, sorry, /home/sergio/test/lab/kernel/initrd.img: ASCII cpio archive (SVR4 with no CRC [11:46] yes, I read fast and did not understand it [11:46] popey: ping https://github.com/snapcrafters/android-studio/pull/32 [11:47] om26er: merged :) [11:47] cachio: so, ‘cpio -t < /home/sergio/test/lab/kernel/initrd.img’ to list it, ‘cpio -x < /home/sergio/test/lab/kernel/initrd.img’ to extract it, etc [11:47] cachio: (man cpio) [11:47] Chipaca, tx [11:47] I'll try it [11:47] popey: thanks, need your eyes on https://github.com/snapcrafters/android-studio/pull/28 as well, that automates releases of android studio [11:48] cachio: mvo: if there's a way to _mount_ initrd, I don't know it [11:48] cachio: if you have 'mc' installed, you can rename it to foo.cpio and navigate it with that [11:48] cachio: or with gvfs (e.g. nautilus) [11:49] ah [11:49] cachio: you can mount it with gvfs, of course [11:49] Chipaca, I am trying to extract it , replace a file and pack it again [11:56] cachio: mounting it with gvfs won't help because it doesn't support writing to it [11:57] Chipaca, I am trying to replace libuuid.so but I can't find it [11:57] it is not indice the initrd.img [11:59] cachio: not the .so on its own, just the .so.1 and .so.1.3.0 [11:59] (at least in the one i have here) [12:00] libuuid.so.1 [12:00] cachio: that'll be a symlink to the .1.3.0 [12:01] Chipaca, but I dont have any [12:01] cachio: where is this initrd from? [12:02] Chipaca, it is from the core-18 image for amd64 [12:02] cachio: the one on people.canonical.com? [12:03] * Chipaca downloads that [12:03] Chipaca, no, I built it by using ubuntu-image [12:03] cachio: ok, i'll look at the one on p.c.c first [12:03] :-) [12:03] Chipaca, I think I'll need to use it as well [12:10] pstolowski|lunch: Chipaca: updated https://github.com/snapcore/snapd/pull/5561 [12:10] that's one annoying PR there :) [12:15] ppisati: snap install black --edge --devmode [12:16] ppisati: btw, mind taking a look https://github.com/snapcore/snapcraft/pull/2202 ? === pstolowski|lunch is now known as pstolowski [12:43] hmm what's ogoing on with travis.. still struggling? [12:46] ppisati: and no,we still require xenial, it is just a tool we depend on that requires a newer python, so it has been snapped, the hacking docs have been updated to reflect that too [12:48] sergiusens: the github page for black said it required 3.6.0+, hence my assumption [12:49] sergiusens: another question - after i git clone the snapcraft repo, nothing happens if i invoke bin/snapcraft [12:49] sergiusens: sergiusens i mean, i don't get any output [12:52] it probably prints black on black, change the terminal bgcolor :P [12:53] ogra: :( [13:00] ppisati: did you read HACKING.md, about using venv? [13:01] Chipaca: yep [13:01] Chipaca: i'm in venv [13:08] ppisati: no output at all, but it just returns? or does it hang? [13:09] Chipaca: https://pastebin.ubuntu.com/p/tZbytBjtG7/ [13:36] cachio: let me look at this initrd now in core18 [13:36] sergiusens: hola [13:36] sergiusens: https://pastebin.ubuntu.com/p/tZbytBjtG7/ <- ppisati hates you [13:37] * Chipaca throws everybody under the bus [13:37] ppisati: pip install -e . [13:37] mvo, sure [13:38] mvo, I checked in the initrd inside the kernel [13:38] Chipaca: yeah, we changed this back then when we decided to support snapcraftctl IIRC. I do not know why we have that bin file still [13:38] mvo, which is inside the core 18 image [13:38] kyrofa: do you recall? [13:39] popey: thanks for the review. What would be the schedule for publishing an updated snap for that? [13:40] sergiusens: oh ok, it took the working snapcraft directory, made a pip package and installed it [13:41] ppisati: yeah, you can easily work in editing mode by doing "pip install -e ." [13:42] sergiusens: so if i modify the src code, and i invoke snapcraft, it'll invoke my modified src code - i guess that's the meaning of editing mode [13:42] ppisati: exactly [13:45] sergiusens: ok, i have all i need now, thanls [13:45] *thanks [13:58] cachio, Chipaca aha, I remember now what the issue is/was with your initramfs - the kernel now concats multiple ones after each other but cpio will only "see" the first one in this mode. this is why it looked so tiny probably [13:58] cachio: this makes working with it even more of a PITA of course [13:58] (sorry got disconnected) [14:00] mvo, ahhh [14:01] mvo, are you going to fix that? [14:01] mvo, or how should I make to extract the correct initramtd [14:02] initrd [14:02] mvo: what can I milestone #5613 to? [14:03] cachio: I'm on it right now [14:03] cachio: half way there (hopefully) [14:04] Chipaca: yes please [14:04] mvo, great, thanks [14:05] mvo: wat [14:06] Chipaca: you mean wat about the multiple initrds? [14:06] Chipaca: or a different "wat"? [14:07] mvo: no i mean: "what can I milestone #5613 to?" "yes" [14:07] Chipaca: I set the milestone to 2.35 now, hope thats ok [14:07] mvo: yes :-) [14:07] Chipaca: I hope we won't need another 2.34 [14:08] *fingers crossed* [14:08] mvo: I just wanted to know what to target it to :-) sorry for the confusion [14:08] Chipaca: no worries, its still very hot :) [14:09] Chipaca: also multiple initrds inside squashfs inside an image make my head spin a little [14:09] Chipaca: but I think I got it under control now [14:09] mvo: https://en.wikipedia.org/wiki/Yo-yo_de-spin [14:10] mthaddon: actually the build failed.. https://build.snapcraft.io/user/snapcrafters/sentry / https://launchpad.net/~build.snapcraft.io/+snap/17fc91e19f932bd8a75175923b533019-xenial/+build/296424 [14:10] Chipaca: woah [14:11] mvo: next time you need to look at multiple initrds inside suqashfs inside an image, grab two yo-yos [14:11] :-) [14:12] I learn so much useful stuff via this channel :) [14:14] mvo, just use multiple initramfs lines in grub.cfg [14:15] ... now i scared him [14:15] om26er: will add the android studio pr to the to-do list, thanks [14:16] mvo: when does 2.35 close? [14:18] Chipaca: the first pre-image today but there is no reaoson not to cherry-pick selected PRs [14:18] Chipaca: especially since it looks like travis is rather busy currently [14:18] heh [14:18] cachio: http://people.canonical.com/~mvo/tmp/core18-amd64-18-alpha20180803-with-lp1783810.img.xz [14:18] cachio: that seems to be working for me [14:19] cachio: I replaced the initramfs there [14:19] mvo, excelent, thanks [14:27] meh, network is a bit unreliable today [14:27] cachio: if it works for you, please mark 1783810 as verified [14:27] cachio: did you write anything after this? [14:27] that didnt even get through [14:28] ogra: heh, thanks [14:29] mvo, it is working now [14:29] it gets stuck like 2 seconds and then it continues [14:29] cachio: with the updated image? [14:29] mvo, yes [14:30] cachio: great [14:31] mvo, but it is taking so long to contact the store [14:31] cachio: I think we can mark the bug as sru-validated then [14:31] it is trying to create the user [14:31] cachio: meh, this delay is probably real entropy :/ [14:31] cachio: I mean, for the store we need real entropy afaik [14:32] cachio: we may need to investigate solutions like polinate [14:32] mvo, it restarted and I ran console conf again [14:32] and it created the user [14:32] ok [14:37] mvo, still https://paste.ubuntu.com/p/vfCr3yw836/ [14:39] cachio: did you refresh core18 and the other bits from edge? [14:39] cachio: i.e. please run "sudo snap refresh --edge core18" [14:45] mvo, in progress [14:46] cachio: ta [14:53] * Chipaca takes a break [15:03] sergio doesn't seem to be around, but Chipaca, ppisati that file is only for Windows packaging. bin/snapcraftctl is what was needed for snapcraftctl [15:03] If you want to run snapcraft from source, install it into a venv [15:04] mvo, after refresh core18 [15:04] the system reboots [15:04] but in the console I don't see the reboot [15:04] cachio: no reboot message there? hm, hm [15:04] and I can't connect to the vm anymore [15:05] cachio: anything in the terminal? [15:05] * mvo tries to reproduce [15:05] well, It did it [15:05] but took much more than usual [15:07] mvo, currently running the tests using external [15:07] mvo, let's see how it goes [15:07] kyrofa: hey [15:08] kyrofa: how do I upload a snap snans snapcraft? [15:08] mvo, it is so weird how it did the reboot [15:08] or how do I tell snapcraft to upload a snap it did not build [15:08] cachio: hm, the image may be problematic [15:08] cachio: because the kernel snap is modified the seeding may not work [15:08] zyga, you can't anymore, store removed that capability [15:08] mvo, in parallel i'll continue doing manual test for this image [15:08] ... I think [15:09] Yeah, looks like it [15:09] kyrofa: what do I need to do to upload a snap that snapcraft did not build [15:09] kyrofa: I can share the makefile I use [15:09] zyga, you can still use snapcraft to push it [15:09] nope, I tried [15:09] it crashes [15:09] How so? [15:09] boom https://www.irccloud.com/pastebin/Kbk2VkV1/ [15:10] not sure why it wants to remove anything [15:10] or why it cares [15:10] I gave it a snap.yaml [15:10] er [15:10] a *.snap file [15:10] zyga, it needs to know the snap name, so it unpacks the meta/snap.yaml [15:10] there is no snapcraft.yaml in the tree [15:10] ok [15:10] But permissions seem odd. How did you create this snap? [15:11] cat Makefile https://www.irccloud.com/pastebin/hdHBMAuP/ [15:11] tip: this requires fedora to run [15:11] or dnf that you don't have on ubuntu to be precise [15:11] note that I even use a "prime" directory [15:11] [zyga@faroe fedora29]$ ls -ld prime/meta/snap.yaml [15:11] -rw-r--r--. 1 root root 1297 Aug 8 17:08 prime/meta/snap.yaml [15:12] the snap.yaml is [15:12] cat snap.yaml https://www.irccloud.com/pastebin/6IJSmdR6/ [15:13] zyga, huh, can you share that snap with me? [15:13] sure [15:14] any ideas how [15:14] there was that thing for sharing files [15:14] wormhole [15:14] zyga, people.canonical, or magic wormhole [15:14] I forgot to sync my ssh key so I don't have access to my personal stuff [15:14] Haha, hi popey [15:14] I'll use wormhole [15:14] wormhole ftw [15:14] thank you popey :) [15:14] np [15:15] kyrofa: I sent you wormhole command to run [15:16] zyga, receiving now [15:16] Done. That really is magical [15:17] woah [15:17] indeed :) [15:17] I'm using snapcraft as a snap [15:17] in case that matters [15:18] cachio: ok, yeah, the reboot is strange [15:20] mvo, is it related to the entropy? [15:25] sil2100, is there any ETA when the new features (gadget connections) will land in the ubuntu-image snap so we can actually make use of them ? [15:25] (i see the code landed since a while) [15:25] cachio: slowness may well be related, did you update the kernel as well or kept that? please try to keep the kernel as it has the fixed initrd [15:26] kyrofa: any ideas? [15:26] kyrofa: I'd like to upload that snap [15:26] to edge [15:27] zyga... I can't explain this. Run `unsquashfs -d /tmp/foo/ fedora29.snap -e meta/snap.yaml` [15:27] k [15:27] zyga, you'll see you own /tmp/foo/meta and everything [15:27] But you can't delete it without sudo [15:27] kyrofa: that worked [15:27] I thought maybe it was an ACL thing, but it doesn't seem so [15:27] that's correct! [15:27] I cannot remove it [15:28] mvo, hmm, looking at #5612 there needs to be some more AI in it ... i.e. on devices where pivot-agent is installed you want that snap to be set up first (to not waste time before a model pivot happens (which includes a factory reset) ) but i.e. on systems where pivot-agent and NM are seeded you want NM to be seeded before pivot-agent ... etc etc [15:28] zyga, what DEMONS did you put on my machine [15:28] one sec [15:28] I think I know [15:29] mvo, you'D want that to happen somewhere between your 2 and 3 in that enumeration [15:30] kyrofa: actually [15:30] not yet :) [15:30] it is _very_ interesting [15:31] zyga, right?! [15:31] it's on tmpfs here [15:31] so not even xattrs [15:31] ogra: hey! I planned to release u-i 1.4 this week, I guess that's still more-or-less possible [15:31] sil2100, awesome, i just wanted to make sure the snap isnt forgotten (i dont use any deb for u-image anymore ... and i guess most of my collegaues dont either) [15:32] zyga, anyway, if you can manage to get to the bottom of that, snapcraft should happily upload this for you [15:32] kyrofa: I think I know [15:32] can you ls -ld meta [15:33] followed by ls -ldZ meta [15:34] doh [15:34] ogra: it won't be forgotten! I'll actually promote 1.4 to stable finally this time, since usually that wasn't part of the process [15:34] kyrofa: it's not what I put [15:34] the /tmp/foo directory is not writable! [15:34] kyrofa: it's snapcraft :D [15:34] kyrofa: chmod +w /tmp/foo [15:34] "daemons" :D [15:36] zyga, what the heck. unsquashfs makes that dir, but this works for other snaps [15:37] kyrofa: so ... why is it read-only? [15:37] zyga, if I run that same unsquashfs command on, say, the snapcraft snap, it's writable [15:37] oh [15:37] a possible hint [15:37] dr-xr-xr-x. 19 root root 4096 Aug 8 15:59 prime [15:37] I'll tweak that [15:38] Oh interesting [15:38] That must be saved somewhere in the image [15:39] yeah [15:39] since prime is the rootfs [15:39] it is not writable for some reason [15:39] (not sure wh) [15:39] Indeed [15:39] trying now [15:40] man, that's an obscure one :) [15:40] That error message was NOT helpful [15:40] * zyga hugs kyrofa [15:40] * kyrofa hugs zyga back [15:41] apparently that's how / is set up on fedora [15:41] it's not root writable [15:41] That's interesting [15:43] is / writable by root on ubuntu? [15:43] mvo, i actually commented on #5612 [15:43] ogra: thanks, thats useful information. note that it won't change any snap ordering if the snaps are not bases or content providers so you can control the order via required snaps. it will just enforce certain things for special types like bases [15:43] zyga, classic ? sure [15:43] kyrofa: pushed :) [15:43] processing [15:44] mvo: now I need your super-powers :) [15:44] zyga: what for? [15:44] zyga, nice! [15:44] mvo: for fedora29 snap, let me see if it actually gets blocked [15:44] still in processing [15:45] mvo, yeah, i'm just wondering if we should perhaps have a "seed priority" value you can give to snaps or some such ... beyond the order in required-snaps so the handling of bases could take that into account ... the prob appreas to be very complex now that bases are a thing :) [15:45] *appears [15:45] ogra: yeah, its definitely complex [15:46] i tried to explain it in the comment ... [15:46] it's still processing [15:46] roadmr: hey [15:47] roadmr: is there a way to check if a snap processing task on the store is stuck / crashed for whatever reason [15:47] roadmr: I just submitted one for "fedora29" [15:47] hi zyga ! [15:47] zyga: is that the snap name? [15:47] zyga: we *are* checking a situation with snaps getting stuck :( [15:47] roadmr: yes [15:48] it's a 29M snap that is processing for a few minutes now [15:48] mvo: btw. I tried latest subiquity from git and sadly it doesn't work, so for now I cherry-picked the branding fixes and pushed that into a PPA [15:48] it's been made on fedora manually so maybe dragons apply [15:48] it's a base snap [15:48] sil2100: ta [15:48] zyga: let me have a look [15:48] thank you [15:48] mvo: Michael mentioned console-conf from subiquity master isn't really usable right now [15:49] sil2100: did you figure anything about about the interface issue on the pis? I would love to build pi images soon(ish) but this is a blocker right now [15:49] sil2100: (not the only one though) [15:49] zyga: I see *no* uploads for fedora29 snap :( that may mean it got rejected even before hitting the database [15:49] roadmr: whoah? [15:49] how is that possible [15:49] zyga: what message did you get from the store? [15:49] I see fedora29.snap 100% uploaded and a spinning processing marker [15:50] zyga: what are you using? snapcraft? [15:50] it's hard to copy paste from the console but it is processing [15:50] yes [15:53] no change still [15:53] I can abort and retry [15:53] but ... no idea [15:53] zyga: no, please hold on a second [15:53] oh [15:53] I just did :< [15:53] :P [15:53] https://www.irccloud.com/pastebin/z7UDGHnq/ [15:53] zyga: do you happen to know if there is a way to ask apparmor for current capabilities? I want to find out if I have mac_admin [15:53] although it's not done yet, the process is alive still [15:53] zyga: https://forum.snapcraft.io/t/degraded-performance-snaps-stuck-in-automated-review/6736 [15:53] mvo: I don't know if there is a way [15:53] you are probably being hit by this, but roadmr is the best one to help :) [15:54] thank you [15:54] zyga: aha, I htink I found code in lxd for this [15:54] zyga: heh, that looks promising [15:54] zyga: fedora29 is crashing the scan / reviewer tools appparently [15:54] roadmr: how? [15:54] zyga: getting yo more details [15:55]