[00:05] PR snapd#8902 closed: tests: fix assertion disk handling for nested UC systems === jamesh_ is now known as jamesh [05:16] morning [05:39] Good morning [05:40] I’ll start at 9 [05:40] Just checking mail in the morning [05:41] zyga: hey [05:43] My keyboard is already in Warsaw [05:43] Maybe it will be delivered a day earlier [05:44] Oh 2.45 has regressed Snapcraft and Ubuntu image [06:52] zyga: hmm? bugs? [06:52] zyga: do you know what broke? [06:56] re [06:56] I will look now [06:57] I just got mail that autopkgtest regressed [07:00] hmmm [07:00] the log is rather useless [07:00] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/snapcraft/20200624_005739_df199@/log.gz [07:00] it says [07:00] deb2snap FAIL non-zero exit status 1 [07:01] morning [07:01] earlier there's this warning [07:01] [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your [07:01] hey pawel [07:01] (along with ansi escapes, yuck) [07:02] maybe something did regress on path? [07:02] let's look at the other regressions [07:04] there's a rather silly regression in snapd [07:04] + snap install --edge test-snapd-hello-multi-arch [07:04] error: snap "test-snapd-hello-multi-arch" is not available on edge for this architecture (i386) but exists on other architectures (amd64). [07:05] zyga: wuut? how can that happen [07:05] good morning mvo! [07:05] I was about to ask that :) [07:05] zyga: oh, is that on 20.04 where i386 got removed? [07:06] zyga: good morning :) [07:06] no, this is on 19.10 [07:06] https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#snapd [07:06] maybe something go removed wrongly [07:06] oh oh [07:06] OH [07:06] my keyboard is coming now [07:07] haha [07:08] mvo: this snap is multi-arch in the sense that it contains i386 binary inside amd64 contianer [07:08] *container [07:09] so it should work on 20.04+ [07:10] there's only one revision [07:10] so whatever broke didn't involve the snap changing [07:14] zyga: woah [07:14] zyga: very strange [07:14] mvo: does snapcraft error make any sense to you [07:14] I'm trying to make some sense out of the log [07:15] zyga: you mean [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your ? [07:15] that seems like a warning that's earlier up the log [07:15] the log ends with: [07:15] deb2snap FAIL non-zero exit status 1 [07:15] what is deb2snap?! [07:16] the whole part reads: [07:16] https://www.irccloud.com/pastebin/UmCedmeB/ [07:16] zyga: it's some sort of helper iirc to transition debs to snaps, iirc it started with chromium [07:16] maybe version changed :D [07:16] * zyga checks [07:16] zyga: I bet [07:16] lol [07:16] 4 [07:16] yes [07:16] zyga: the test failure does not make much sense - also autopkgtest [07:17] zyga: ha! [07:17] fun [07:17] current version is 4.05 [07:17] 4.0.5 [07:17] so where is the test that needs fixing [07:17] * zyga looks [07:17] zyga: this is a silly test then - will you tell sergiusens about "autopkgtest [00:57:26]: test deb2snap: [-----------------------" failing because the version number changes :) ? [07:17] sure :) [07:25] mvo: it seems we broke the snap-auto-mount test on master for core20 [07:26] pedronis: do you have logs? [07:26] pedronis: nvm, it failed in my pr too [07:26] mborzecki: yes, as I said seems to be really broken, failing consistently [07:27] was this modified recently? [07:28] i did some changes to coldplug auto-import, but it was back in may iirc [07:30] and debugging is broken too, there's no /var/log/syslog :/ [07:30] mborzecki: not sure, but maybe some of the test assertions were changed [07:30] for other tests [07:30] yeah, wonder why it's happening now. maybe something else changed too? [07:30] new udev or systemd in core20 maybe? [07:30] new systemd! === jamesh_ is now known as jamesh [07:37] PR snapd#8913 opened: tests/core/snap-auto-mount: fix debug section [07:37] let's see if there's any useful output [07:37] * mvo is in a meeting but will follow from the sidelines [07:55] #8889 needs a 2nd review [07:55] PR #8889: snapstate: fix autorefresh from classic->strict [08:04] heh, the test runs succesfuly in isolation [08:05] mborzecki: updated https://github.com/snapcore/snapd/pull/8910 [08:06] PR #8910: usersession: support additional zoom URL schemes [08:11] mvo: https://github.com/snapcore/snapd/pull/8889#pullrequestreview-436420132 [08:11] PR #8889: snapstate: fix autorefresh from classic->strict [08:14] zyga: lucky us that zoom has no more url schemas ;P [08:16] mborzecki: yet :D [08:16] keyboard is here [08:16] brb [08:17] zyga: maybe you could reference https://github.com/snapcore/snapd/pull/8761#pullrequestreview-425508154 for the msteams:// [08:17] PR #8761: usersession/userd: add msteams url support [08:25] mborzecki: sure, I was looking for it [08:26] need a moment to adjust [08:30] so weird [08:31] so weird and comfortable [08:32] getting used to the layout will take a momentt [08:32] there are four layers to lean [08:33] learn [08:33] zyga: it's 2 separate pieces right? [08:33] yes [08:33] wireless in between or wired? [08:33] wired with a detachable cord [08:33] zyga: and keyboard -> pc wired too? [08:34] RJ11 phone connector [08:34] yes [08:34] it has a custom app [08:34] FOSS, they provide a appimage [08:34] an [08:35] we need a snap then :) [08:35] but wow, rj11, haven't seen those in a while [08:35] it's actually practical [08:36] not custom [08:36] not USB [08:38] mouse layer! [08:57] ok, somewhat adjusted now [08:57] apart from annoyance when my muscle memory doesn't match [08:57] there is no strain now [09:05] zyga: thank you, lookin gnow [09:05] sure [09:05] feel free to push this to me [09:22] PR snapd#8702 closed: overlord/configstate: add system.kernel.printk.console-loglevel option [09:22] PR snapd#8914 opened: o/ifacestate: fix connect undo handler [09:38] mborzecki: I've added the reference to msteams pull request now [09:38] zyga: thanks! [09:38] * zyga small break to move around a little [09:44] I need to focus on https://github.com/snapcore/snapd/pull/8881 now [09:45] PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [09:45] why do my PRs get 50+ comments ;-) [10:10] pedronis: zyga: got some debug logs in snap-auto-mount PR https://github.com/snapcore/snapd/pull/8913/checks?check_run_id=802673638 [10:10] PR #8913: tests/core/snap-auto-mount: fix debug section [10:12] meh: 2020-06-24T09:38:28.0114940Z + is_core_nested_system [10:12] 2020-06-24T09:38:28.0115148Z /home/gopath/src/github.com/snapcore/snapd/tests/lib/nested.sh: line 158: NESTED_TYPE: unbound variable [10:12] looking [10:12] ah [10:12] good old shell [10:13] duh, how come some of the code runs under -u and other parts do not [10:14] -u? [10:14] set -u [10:14] ah [10:15] hm spread does not set -u for the test scripts, so how did it end up being set there? [10:16] IIRC there was something similar [10:16] when we learned that set -e is easily lost [10:16] with stuff as simple as ( ) [10:16] zyga: there was some subshell weirdness combined with () and {} [10:16] 2020-06-24T09:38:27.4134740Z Jun 24 09:38:27 ubuntu snapd[2470]: daemon.go:313: DEBUG: pid=2735;uid=0;socket=/run/snapd.socket; POST /v2/assertions 10.868987ms 200 [10:16] 2020-06-24T09:38:27.4135673Z Jun 24 09:38:27 ubuntu snapd[2470]: daemon.go:313: DEBUG: pid=2735;uid=0;socket=/run/snapd.socket; POST /v2/users 446.144µs 200 [10:17] so importing assertions was succesful? [10:17] mborzecki: don't you love our state-sharing shell functions [10:17] mborzecki: some our .sh set set -u [10:17] that's why I don't want to see more shared state shell code [10:17] pedronis: oh, right sourcing those can mutate the state :/ [10:17] isn't this prepare.sh anyway? [10:18] it has a set -eux [10:18] only executed programs are possible to reason about [10:18] pedronis: the unbound error popped up in debug section [10:19] zyga: I replied to #8889 [10:19] PR #8889: snapstate: fix autorefresh from classic->strict [10:19] pedronis: iirc those were separate shell instances [10:19] thanks mvo [10:19] thank you! [10:19] mborzecki: not sure, the log is a bit confusing [10:20] * pstolowski lunch & errand [10:20] morning folks [10:20] sorry mborzecki [10:20] that NESTED_TYPE was my fault :-( [10:21] mvo: replied [10:21] good morning ijohnson! [10:21] ijohnson: no worries and good morning [10:22] hi, quick question, there are some packages that their snaps dont exist, such as dracut, clevis etc (things i need to implement full disk encryption on ubuntu core 16 based image). I decided to do stage-packages into the gadget snap and when the machine boots i could reorg files under /etc /usr/lib /usr/bin etc but i ofc forgot for a moment that its read-only for security [10:23] am i completely bound to the fact that i need these packages as snaps so they can be used by the system, i cant just prime them into the gadget than try to move them under main paths like /usr/.. [10:23] clmsy: iiuc trying to use dracut on an ubuntu-core system will not work, as the initramfs is in the kernel snap and that is read-only [10:23] clmsy: yes you cannot add things to the root filesystem that is not already in the base snap (which for ubuntu core 16 is the core snap) [10:23] clmsy: that being said some directories are writable and can be modified [10:23] clmsy: see writable-paths man page on ubuntu [10:23] clmsy: squashfs is pretty much read only and it is unrelated to security [10:24] was dracut even used for uc16? [10:24] mborzecki: I don't think so [10:24] * zyga small break [10:24] does this mean guys that i am bound to wait for ubuntu core 20 for full disk encryption that i just cannot implement it for 16 [10:25] clmsy: it is implementable for uc16, we have had commercial customers for whom Canonical Field Engineering team implemented full disk encryption, but I don't recall more details than that [10:25] clmsy: on which architecture? [10:25] clmsy: if you are interested in talking to our Field engineering team, I would refer you to ogra [10:25] we are using this https://fit-iot.com/web/products/fitlet2/ [10:25] intel atom 64bit [10:26] if it has TPM I would really go after core20 [10:26] it has tpm yes [10:26] it's probably easier than retrofitting this into uc16 [10:26] i should also email ogra maybe to take his opinion [10:26] it's a lot of work [10:26] clmsy: does it have tpm 2.0 ? [10:27] really nice box btw! [10:27] clmsy: also yes what zyga said, we designed uc20 with full disk encryption in mind so that it's easier than it used to be for ubuntu core 16 and 18 to implement full disk encryption [10:27] clmsy: also if ogra isn't around, you could also reach out to lool [10:27] and uc20 based system can install and use core16 and core18 apps [10:28] so you don't lose anything [10:28] anyway brb [10:28] i really appreciate your feedback guys, i ve been fiddling and fighting to make it work for the last week [10:28] is there a generic email addr for field engineering team at canonical i can send an email to [10:28] clmsy: if you have the box around, you can try uc20 beta (just saying) [10:29] clmsy: yes, let me get email that for you, one minute [10:29] clmsy: also it seems that device has tpm 2.0 through the intel firmware [10:30] so it should just work with uc20 beta: https://docs.ubuntu.com/core/en/releases/uc20 [10:30] i actually implemented uc20 beta [10:30] having an issue there [10:30] i used the baseline from snapcore [10:31] in the gadget.yaml file under the repo snapcore [10:31] a volume is defined as ubuntu-boot, but when i bot it says no such device etc [10:31] ill try keep working on it [10:31] let me get an email addr i would really like that [10:31] ^_^ [10:32] clmsy: the ubuntu-boot missing on first boot is expected, it should continue to boot past that though [10:32] clmsy: do you have uefi enabled on the device ? it seems relatively new so I assume so [10:33] uefi is enabled, secure boot is also enabled, it does continue to recovery boot but than you know what happens, the-tool service fails with exit code (1) and says the following: model does not specify all the requestted essential snaps: [base kernel snapd] [10:33] and the model actually does specify all of them [10:33] i actually send an email to a canonical contact of ours [10:33] Ondrej Kubik [10:33] with all the details and screenshots, and even our model json file [10:34] he is the only contact i know [10:34] clmsy: can you show your model assertion snaps header ? (and sorry I'm still waiting trying to figure out an email to give you) [10:35] i.e. the bit that has `snaps: [...]` [10:36] yes 1 sec [10:37] this is the snaps map: https://pastebin.com/Z49qbDVr [10:37] on top of the model base is core20 and grade is secured [10:39] clmsy: ah you are hitting this bug: https://bugs.launchpad.net/snapd/+bug/1883973 [10:39] Bug #1883973: cannot boot uc20 model with multiple base snaps [10:39] clmsy: unfortunately the fix that bug has not yet been released, but you can kinda fix it locally until it gets released to the pc-kernel [10:40] clmsy: also I would suggest using latest/beta for all your snaps for now, rather than latest/stable, as right now all the stable snaps for uc20 are not quite stable, I mean they should be good, but we are much more actively testing the beta snaps right now rather than the stable ones [10:41] oooh that seems to be the bug yes [10:41] thank you for letting me know! i really appreciate it... i was trying a lot of different things to see if i can do a workaround [10:41] im glad this irc channel exists ^_^ [10:41] clmsy: give me a minute to get you a script that you can use to fix the kernel snap [10:47] clmsy: ok so download this script from this gist: https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a018 [10:47] PR snapd#8889 closed: snapstate: fix autorefresh from classic->strict [10:48] then use this script to rebuild the kernel snap (which uses that script): https://pastebin.ubuntu.com/p/J7TXCMrdYZ/ [10:48] clmsy: ^ [10:50] thank you very much for the help!!!! [10:50] clmsy: also to contact field engineering please reach out to sales@canonical.com and you can mention that you were referred there by snapd developers on #snappy IRC channel [10:50] perfect!! most helpful [10:50] i'll get to working on this issue [10:52] yes please reach out again if you are having more trouble with uc20, we are happy to help and welcome any feedback/bugs you have about it :-) [10:53] <3 [10:59] re [10:59] back to fixes [10:59] Eighth_Doctor: hey, i see you've started pushing out updates, thank you! [11:00] 👍️ [11:27] PR snapd#8915 opened: gadget: do only one mount point lookup in mounted fs updater [11:31] ijohnson: pushed a fix for NESTED_TYPE to #8913 [11:31] PR #8913: tests/core/snap-auto-mount: fix debug section [11:33] thanks mborzecki, approved [11:48] * zyga is slow today, sorry, learning curve [12:07] hm maybe snap-auto-mount is racy, but afaict (pedronis please correct me), by the time the POST /api/v2/assert request returns all processing is done [12:07] or it's another another udev settle/async thing that pops up randomly [12:15] mborzecki: yes, should be done [12:23] o/ need help with youtube-dl snap, seems to be an outdated version not working anymore. can i manually update the binary in the snap packet? [12:58] PR snapd#8901 closed: tests/lib/tools: apply linger workaround when needed [12:58] PR snapd#8908 closed: overlord/snapstate: graceful handling of denied "managed" refresh schedule [13:00] sorry if this is the wrong place to get help with a outdated snap package... where can I talk to? [13:01] NerdSnapper: https://github.com/joedborg/youtube-dl is listed in contact-url, i suggest you try opening an issue there [13:02] PR snapcraft#3187 opened: cli: use maxval of UnknownLength for pack progress [13:03] PR snapd#8887 closed: bootloader: pull recovery grub config from internal assets [13:06] I created a content snap mirroring gnome 3.x platform ones. it's supposed to share "$SNAP" or "/", like the gnome snap, but when it surfaces inside of the snap, I get the content's snap revision number as the first level directory? Is that supposed to happen? [13:07] (e.g. x4) [13:17] cjp256: hi, can you show me the plug and slot definition please [13:20] https://www.irccloud.com/pastebin/5fABgBQw/ [13:21] zyga: ^^ thanks for looking :D [13:21] looking [13:23] note that in all the cases, / maps to $SNAP, right [13:23] I would expect so? the gnome-platform uses "/" [13:24] sure, just stating that so it's not unclear [13:24] mborzecki: if a snap package (e.g. youtube-dl) is outdated, who provides an update for snap? the original software seems to be actual and working fine, only the snap version is old...? [13:24] NerdSnapper: whoever published the snap [13:25] cjp256: I think I know what's going on [13:26] cjp256: in a call, I'll get back to you [13:26] zyga: k thanks [13:28] so, the content interface has two modes of operation [13:28] 1:1 and 1:n [13:30] mborzecki: OK I try to find out... [13:30] NerdSnapper: if you run `snap info ` it lists a contact-url for the snap publisher [13:31] the former uses the target directory and replaces it with the connected content; the latter uses the target directory to enunerate the connected slots [13:33] the latter mode uses the directory name of the source - if you share the whole snap you will get the revision number [13:33] if you want to use the 1:1 mode instead please drop the "source" component from the syntax [13:34] oh [13:35] i think this is documented [13:36] let me know if this aspect is unclear please [13:36] sergiusens: hi [13:36] mborzecki: great thank you, you helped me understand it, that was the contact-url you mentoined... ;) [13:36] sergiusens: we got a SRU regression on a test that checks snapcraft version to be 3.* [13:38] PR snapd#8891 closed: o/servicestate: add updateSnapstateServices helper (5/9) [13:39] mborzecki: I see I am not the only one with this issue :) with youtube-dl [13:45] NerdSnapper: hi there, i've just checked the snap. due to a merge conflict from upstream, the automatic builds had stopped and gone unnoticed. it's now back up and there'll be a new build very soon. [13:48] joedborg: thumbs-up great! thank you very much [13:48] zyga: makes perfect sense as you explain it. and it works now! I don't think that's an obvious in the documentation, and it feels like an error case maybe worthy of a snap warning? I'm not sure how the consumer snap would account for a unknown revision tag unless wildcarding? Docs say source is `presents one or more sub-directories` which is true, but doesn't elaborate on this case as to a potential difference in [13:48] behavior for a single shared directory. Thanks for helping me out! [14:00] zyga: hi, Snapcraft is on version 4 now [14:00] but I guess you know that [14:01] SRU regression where? [14:03] PR snapd#8916 opened: tests: adding ubuntu-20.04 to google-sru backend [14:06] sergiusens: I’m afk for a moment but I will share the SRU link when I am back === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [14:21] By [14:24] o/ wishing you all a nice evening... === benfrancis2 is now known as benfrancis === Son_Goku is now known as Eleventh_Doctor === Eleventh_Doctor is now known as Son_Goku [14:29] ogra: hi! I still have a bbb kicking but lately I've been seeing: snapd[1122]: taskrunner.go:271: [change 1688 "Request device serial" task] [14:29] failed: cannot deliver device serial request: Cannot process serial request for device with brand [14:29] "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" and model "bbb" [14:29] ogra: have you seen this? [14:30] errands, bbl [14:30] jdstrand: that's expected unless you have `serial-authority: [generic]` in your model assertion [14:30] jdstrand, well, this device doesnt use a canonical model [14:30] jdstrand: or unless you have a brand store for your bbb :-) [14:30] being core16 i dont think there are ways to make it obtain one [14:30] (one = serial) [14:31] core20 allows the new "generic" serial [14:31] ogra: you could try rebuilding that image with a model that uses serial-authority [14:31] probably time that i dust off my bbb and create a core20 img [14:31] ogra: also serial-authority: [generic] is allowed on any uc model, not just uc20 [14:31] oh, i didnt know that ! [14:31] yes it's a generic feature of model assertions now [14:32] ijohnson: ok, well, this is a new, somewhat noisy message [14:32] i'll play with it .. [14:32] the appliance images which are all uc18 use this [14:32] jdstrand: it shouldn't be new though ... [14:32]