| mup | PR snapd#8902 closed: tests: fix assertion disk handling for nested UC systems <Squash-merge> <Test Robustness> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8902> | 00:05 |
|---|---|---|
| === jamesh_ is now known as jamesh | ||
| mborzecki | morning | 05:16 |
| zyga | Good morning | 05:39 |
| zyga | I’ll start at 9 | 05:40 |
| zyga | Just checking mail in the morning | 05:40 |
| mborzecki | zyga: hey | 05:41 |
| zyga | My keyboard is already in Warsaw | 05:43 |
| zyga | Maybe it will be delivered a day earlier | 05:43 |
| zyga | Oh 2.45 has regressed Snapcraft and Ubuntu image | 05:44 |
| mborzecki | zyga: hmm? bugs? | 06:52 |
| mborzecki | zyga: do you know what broke? | 06:52 |
| zyga | re | 06:56 |
| zyga | I will look now | 06:56 |
| zyga | I just got mail that autopkgtest regressed | 06:57 |
| zyga | hmmm | 07:00 |
| zyga | the log is rather useless | 07:00 |
| zyga | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/s/snapcraft/20200624_005739_df199@/log.gz | 07:00 |
| zyga | it says | 07:00 |
| zyga | deb2snap FAIL non-zero exit status 1 | 07:00 |
| pstolowski | morning | 07:01 |
| zyga | earlier there's this warning | 07:01 |
| zyga | [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your | 07:01 |
| zyga | hey pawel | 07:01 |
| zyga | (along with ansi escapes, yuck) | 07:01 |
| zyga | maybe something did regress on path? | 07:02 |
| zyga | let's look at the other regressions | 07:02 |
| zyga | there's a rather silly regression in snapd | 07:04 |
| zyga | + snap install --edge test-snapd-hello-multi-arch | 07:04 |
| zyga | error: snap "test-snapd-hello-multi-arch" is not available on edge for this architecture (i386) but exists on other architectures (amd64). | 07:04 |
| mvo | zyga: wuut? how can that happen | 07:05 |
| zyga | good morning mvo! | 07:05 |
| zyga | I was about to ask that :) | 07:05 |
| mvo | zyga: oh, is that on 20.04 where i386 got removed? | 07:05 |
| mvo | zyga: good morning :) | 07:06 |
| zyga | no, this is on 19.10 | 07:06 |
| zyga | https://people.canonical.com/~ubuntu-archive/proposed-migration/eoan/update_excuses.html#snapd | 07:06 |
| zyga | maybe something go removed wrongly | 07:06 |
| zyga | oh oh | 07:06 |
| zyga | OH | 07:06 |
| zyga | my keyboard is coming now | 07:06 |
| mborzecki | haha | 07:07 |
| zyga | mvo: this snap is multi-arch in the sense that it contains i386 binary inside amd64 contianer | 07:08 |
| zyga | *container | 07:08 |
| zyga | so it should work on 20.04+ | 07:09 |
| zyga | there's only one revision | 07:10 |
| zyga | so whatever broke didn't involve the snap changing | 07:10 |
| mvo | zyga: woah | 07:14 |
| mvo | zyga: very strange | 07:14 |
| zyga | mvo: does snapcraft error make any sense to you | 07:14 |
| zyga | I'm trying to make some sense out of the log | 07:14 |
| mvo | zyga: you mean [1mWarning:[0m /snap/bin was not found in your $PATH. If you've not restarted your ? | 07:15 |
| zyga | that seems like a warning that's earlier up the log | 07:15 |
| zyga | the log ends with: | 07:15 |
| zyga | deb2snap FAIL non-zero exit status 1 | 07:15 |
| zyga | what is deb2snap?! | 07:15 |
| zyga | the whole part reads: | 07:16 |
| zyga | https://www.irccloud.com/pastebin/UmCedmeB/ | 07:16 |
| mvo | zyga: it's some sort of helper iirc to transition debs to snaps, iirc it started with chromium | 07:16 |
| zyga | maybe version changed :D | 07:16 |
| * zyga checks | 07:16 | |
| mvo | zyga: I bet | 07:16 |
| zyga | lol | 07:16 |
| zyga | 4 | 07:16 |
| zyga | yes | 07:16 |
| mvo | zyga: the test failure does not make much sense - also autopkgtest | 07:16 |
| mvo | zyga: ha! | 07:17 |
| mvo | fun | 07:17 |
| zyga | current version is 4.05 | 07:17 |
| zyga | 4.0.5 | 07:17 |
| zyga | so where is the test that needs fixing | 07:17 |
| * zyga looks | 07:17 | |
| mvo | 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 |
| zyga | sure :) | 07:17 |
| pedronis | mvo: it seems we broke the snap-auto-mount test on master for core20 | 07:25 |
| mborzecki | pedronis: do you have logs? | 07:26 |
| mborzecki | pedronis: nvm, it failed in my pr too | 07:26 |
| pedronis | mborzecki: yes, as I said seems to be really broken, failing consistently | 07:26 |
| mborzecki | was this modified recently? | 07:27 |
| mborzecki | i did some changes to coldplug auto-import, but it was back in may iirc | 07:28 |
| mborzecki | and debugging is broken too, there's no /var/log/syslog :/ | 07:30 |
| pedronis | mborzecki: not sure, but maybe some of the test assertions were changed | 07:30 |
| pedronis | for other tests | 07:30 |
| mvo | yeah, wonder why it's happening now. maybe something else changed too? | 07:30 |
| mvo | new udev or systemd in core20 maybe? | 07:30 |
| zyga | new systemd! | 07:30 |
| === jamesh_ is now known as jamesh | ||
| mup | PR snapd#8913 opened: tests/core/snap-auto-mount: fix debug section <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913> | 07:37 |
| mborzecki | let's see if there's any useful output | 07:37 |
| * mvo is in a meeting but will follow from the sidelines | 07:37 | |
| pedronis | #8889 needs a 2nd review | 07:55 |
| mup | PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889> | 07:55 |
| mborzecki | heh, the test runs succesfuly in isolation | 08:04 |
| zyga | mborzecki: updated https://github.com/snapcore/snapd/pull/8910 | 08:05 |
| mup | PR #8910: usersession: support additional zoom URL schemes <Bug> <Needs security review> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8910> | 08:06 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/8889#pullrequestreview-436420132 | 08:11 |
| mup | PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889> | 08:11 |
| mborzecki | zyga: lucky us that zoom has no more url schemas ;P | 08:14 |
| zyga | mborzecki: yet :D | 08:16 |
| zyga | keyboard is here | 08:16 |
| zyga | brb | 08:16 |
| mborzecki | zyga: maybe you could reference https://github.com/snapcore/snapd/pull/8761#pullrequestreview-425508154 for the msteams:// | 08:17 |
| mup | PR #8761: usersession/userd: add msteams url support <Needs security review> <Created by call-a3> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8761> | 08:17 |
| zyga | mborzecki: sure, I was looking for it | 08:25 |
| zyga | need a moment to adjust | 08:26 |
| zyga | so weird | 08:30 |
| zyga | so weird and comfortable | 08:31 |
| zyga | getting used to the layout will take a momentt | 08:32 |
| zyga | there are four layers to lean | 08:32 |
| zyga | learn | 08:33 |
| mborzecki | zyga: it's 2 separate pieces right? | 08:33 |
| zyga | yes | 08:33 |
| mborzecki | wireless in between or wired? | 08:33 |
| zyga | wired with a detachable cord | 08:33 |
| mborzecki | zyga: and keyboard -> pc wired too? | 08:33 |
| zyga | RJ11 phone connector | 08:34 |
| zyga | yes | 08:34 |
| zyga | it has a custom app | 08:34 |
| zyga | FOSS, they provide a appimage | 08:34 |
| zyga | an | 08:34 |
| mborzecki | we need a snap then :) | 08:35 |
| mborzecki | but wow, rj11, haven't seen those in a while | 08:35 |
| zyga | it's actually practical | 08:35 |
| zyga | not custom | 08:36 |
| zyga | not USB | 08:36 |
| zyga | mouse layer! | 08:38 |
| zyga | ok, somewhat adjusted now | 08:57 |
| zyga | apart from annoyance when my muscle memory doesn't match | 08:57 |
| zyga | there is no strain now | 08:57 |
| mvo | zyga: thank you, lookin gnow | 09:05 |
| zyga | sure | 09:05 |
| zyga | feel free to push this to me | 09:05 |
| mup | PR snapd#8702 closed: overlord/configstate: add system.kernel.printk.console-loglevel option <Created by EthanHsieh> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8702> | 09:22 |
| mup | PR snapd#8914 opened: o/ifacestate: fix connect undo handler <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8914> | 09:22 |
| zyga | mborzecki: I've added the reference to msteams pull request now | 09:38 |
| mborzecki | zyga: thanks! | 09:38 |
| * zyga small break to move around a little | 09:38 | |
| zyga | I need to focus on https://github.com/snapcore/snapd/pull/8881 now | 09:44 |
| mup | PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs <Bug> <Needs security review> <Created by zyga> <https://github.com/snapcore/snapd/pull/8881> | 09:45 |
| zyga | why do my PRs get 50+ comments ;-) | 09:45 |
| mborzecki | 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 |
| mup | PR #8913: tests/core/snap-auto-mount: fix debug section <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913> | 10:10 |
| mborzecki | meh: 2020-06-24T09:38:28.0114940Z + is_core_nested_system | 10:12 |
| mborzecki | 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 |
| zyga | looking | 10:12 |
| zyga | ah | 10:12 |
| zyga | good old shell | 10:12 |
| mborzecki | duh, how come some of the code runs under -u and other parts do not | 10:13 |
| zyga | -u? | 10:14 |
| mborzecki | set -u | 10:14 |
| zyga | ah | 10:14 |
| mborzecki | hm spread does not set -u for the test scripts, so how did it end up being set there? | 10:15 |
| zyga | IIRC there was something similar | 10:16 |
| zyga | when we learned that set -e is easily lost | 10:16 |
| zyga | with stuff as simple as ( ) | 10:16 |
| mborzecki | zyga: there was some subshell weirdness combined with () and {} | 10:16 |
| mborzecki | 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 |
| mborzecki | 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:16 |
| mborzecki | so importing assertions was succesful? | 10:17 |
| zyga | mborzecki: don't you love our state-sharing shell functions | 10:17 |
| pedronis | mborzecki: some our .sh set set -u | 10:17 |
| zyga | that's why I don't want to see more shared state shell code | 10:17 |
| mborzecki | pedronis: oh, right sourcing those can mutate the state :/ | 10:17 |
| pedronis | isn't this prepare.sh anyway? | 10:17 |
| pedronis | it has a set -eux | 10:18 |
| zyga | only executed programs are possible to reason about | 10:18 |
| mborzecki | pedronis: the unbound error popped up in debug section | 10:18 |
| mvo | zyga: I replied to #8889 | 10:19 |
| mup | PR #8889: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8889> | 10:19 |
| mborzecki | pedronis: iirc those were separate shell instances | 10:19 |
| zyga | thanks mvo | 10:19 |
| mvo | thank you! | 10:19 |
| pedronis | mborzecki: not sure, the log is a bit confusing | 10:19 |
| * pstolowski lunch & errand | 10:20 | |
| ijohnson | morning folks | 10:20 |
| ijohnson | sorry mborzecki | 10:20 |
| ijohnson | that NESTED_TYPE was my fault :-( | 10:20 |
| zyga | mvo: replied | 10:21 |
| zyga | good morning ijohnson! | 10:21 |
| mborzecki | ijohnson: no worries and good morning | 10:21 |
| clmsy | 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:22 |
| clmsy | 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 |
| ijohnson | 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 |
| ijohnson | 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 |
| ijohnson | clmsy: that being said some directories are writable and can be modified | 10:23 |
| ijohnson | clmsy: see writable-paths man page on ubuntu | 10:23 |
| zyga | clmsy: squashfs is pretty much read only and it is unrelated to security | 10:23 |
| mborzecki | was dracut even used for uc16? | 10:24 |
| ijohnson | mborzecki: I don't think so | 10:24 |
| * zyga small break | 10:24 | |
| clmsy | 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:24 |
| ijohnson | 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 |
| zyga | clmsy: on which architecture? | 10:25 |
| ijohnson | clmsy: if you are interested in talking to our Field engineering team, I would refer you to ogra | 10:25 |
| clmsy | we are using this https://fit-iot.com/web/products/fitlet2/ | 10:25 |
| clmsy | intel atom 64bit | 10:25 |
| zyga | if it has TPM I would really go after core20 | 10:26 |
| clmsy | it has tpm yes | 10:26 |
| zyga | it's probably easier than retrofitting this into uc16 | 10:26 |
| clmsy | i should also email ogra maybe to take his opinion | 10:26 |
| zyga | it's a lot of work | 10:26 |
| ijohnson | clmsy: does it have tpm 2.0 ? | 10:26 |
| zyga | really nice box btw! | 10:27 |
| ijohnson | 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 |
| ijohnson | clmsy: also if ogra isn't around, you could also reach out to lool | 10:27 |
| zyga | and uc20 based system can install and use core16 and core18 apps | 10:27 |
| zyga | so you don't lose anything | 10:28 |
| zyga | anyway brb | 10:28 |
| clmsy | i really appreciate your feedback guys, i ve been fiddling and fighting to make it work for the last week | 10:28 |
| clmsy | is there a generic email addr for field engineering team at canonical i can send an email to | 10:28 |
| mborzecki | clmsy: if you have the box around, you can try uc20 beta (just saying) | 10:28 |
| ijohnson | clmsy: yes, let me get email that for you, one minute | 10:29 |
| ijohnson | clmsy: also it seems that device has tpm 2.0 through the intel firmware | 10:29 |
| ijohnson | so it should just work with uc20 beta: https://docs.ubuntu.com/core/en/releases/uc20 | 10:30 |
| clmsy | i actually implemented uc20 beta | 10:30 |
| clmsy | having an issue there | 10:30 |
| clmsy | i used the baseline from snapcore | 10:30 |
| clmsy | in the gadget.yaml file under the repo snapcore | 10:31 |
| clmsy | a volume is defined as ubuntu-boot, but when i bot it says no such device etc | 10:31 |
| clmsy | ill try keep working on it | 10:31 |
| clmsy | let me get an email addr i would really like that | 10:31 |
| clmsy | ^_^ | 10:31 |
| ijohnson | clmsy: the ubuntu-boot missing on first boot is expected, it should continue to boot past that though | 10:32 |
| ijohnson | clmsy: do you have uefi enabled on the device ? it seems relatively new so I assume so | 10:32 |
| clmsy | 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 |
| clmsy | and the model actually does specify all of them | 10:33 |
| clmsy | i actually send an email to a canonical contact of ours | 10:33 |
| clmsy | Ondrej Kubik | 10:33 |
| clmsy | with all the details and screenshots, and even our model json file | 10:33 |
| clmsy | he is the only contact i know | 10:34 |
| ijohnson | 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:34 |
| ijohnson | i.e. the bit that has `snaps: [...]` | 10:35 |
| clmsy | yes 1 sec | 10:36 |
| clmsy | this is the snaps map: https://pastebin.com/Z49qbDVr | 10:37 |
| clmsy | on top of the model base is core20 and grade is secured | 10:37 |
| ijohnson | clmsy: ah you are hitting this bug: https://bugs.launchpad.net/snapd/+bug/1883973 | 10:39 |
| mup | Bug #1883973: cannot boot uc20 model with multiple base snaps <snapd:Fix Committed by pedronis> <https://launchpad.net/bugs/1883973> | 10:39 |
| ijohnson | 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:39 |
| ijohnson | 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:40 |
| clmsy | oooh that seems to be the bug yes | 10:41 |
| clmsy | 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 |
| clmsy | im glad this irc channel exists ^_^ | 10:41 |
| ijohnson | clmsy: give me a minute to get you a script that you can use to fix the kernel snap | 10:41 |
| ijohnson | clmsy: ok so download this script from this gist: https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a018 | 10:47 |
| mup | PR snapd#8889 closed: snapstate: fix autorefresh from classic->strict <Bug> <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8889> | 10:47 |
| ijohnson | then use this script to rebuild the kernel snap (which uses that script): https://pastebin.ubuntu.com/p/J7TXCMrdYZ/ | 10:48 |
| ijohnson | clmsy: ^ | 10:48 |
| clmsy | thank you very much for the help!!!! | 10:50 |
| ijohnson | 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 |
| clmsy | perfect!! most helpful | 10:50 |
| clmsy | i'll get to working on this issue | 10:50 |
| ijohnson | 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:52 |
| clmsy | <3 | 10:53 |
| zyga | re | 10:59 |
| zyga | back to fixes | 10:59 |
| mborzecki | Eighth_Doctor: hey, i see you've started pushing out updates, thank you! | 10:59 |
| Eighth_Doctor | 👍️ | 11:00 |
| mup | PR snapd#8915 opened: gadget: do only one mount point lookup in mounted fs updater <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8915> | 11:27 |
| mborzecki | ijohnson: pushed a fix for NESTED_TYPE to #8913 | 11:31 |
| mup | PR #8913: tests/core/snap-auto-mount: fix debug section <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8913> | 11:31 |
| ijohnson | thanks mborzecki, approved | 11:33 |
| * zyga is slow today, sorry, learning curve | 11:48 | |
| mborzecki | 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 |
| mborzecki | or it's another another udev settle/async thing that pops up randomly | 12:07 |
| pedronis | mborzecki: yes, should be done | 12:15 |
| NerdSnapper | 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:23 |
| mup | PR snapd#8901 closed: tests/lib/tools: apply linger workaround when needed <Precious Logs> <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8901> | 12:58 |
| mup | PR snapd#8908 closed: overlord/snapstate: graceful handling of denied "managed" refresh schedule <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8908> | 12:58 |
| NerdSnapper | sorry if this is the wrong place to get help with a outdated snap package... where can I talk to? | 13:00 |
| mborzecki | NerdSnapper: https://github.com/joedborg/youtube-dl is listed in contact-url, i suggest you try opening an issue there | 13:01 |
| mup | PR snapcraft#3187 opened: cli: use maxval of UnknownLength for pack progress <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3187> | 13:02 |
| mup | PR snapd#8887 closed: bootloader: pull recovery grub config from internal assets <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8887> | 13:03 |
| cjp256 | 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:06 |
| cjp256 | (e.g. x4) | 13:07 |
| zyga | cjp256: hi, can you show me the plug and slot definition please | 13:17 |
| cjp256 | https://www.irccloud.com/pastebin/5fABgBQw/ | 13:20 |
| cjp256 | zyga: ^^ thanks for looking :D | 13:21 |
| zyga | looking | 13:21 |
| zyga | note that in all the cases, / maps to $SNAP, right | 13:23 |
| cjp256 | I would expect so? the gnome-platform uses "/" | 13:23 |
| zyga | sure, just stating that so it's not unclear | 13:24 |
| NerdSnapper | 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 |
| mborzecki | NerdSnapper: whoever published the snap | 13:24 |
| zyga | cjp256: I think I know what's going on | 13:25 |
| zyga | cjp256: in a call, I'll get back to you | 13:26 |
| cjp256 | zyga: k thanks | 13:26 |
| zyga | so, the content interface has two modes of operation | 13:28 |
| zyga | 1:1 and 1:n | 13:28 |
| NerdSnapper | mborzecki: OK I try to find out... | 13:30 |
| mborzecki | NerdSnapper: if you run `snap info <name>` it lists a contact-url for the snap publisher | 13:30 |
| zyga | 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:31 |
| zyga | the latter mode uses the directory name of the source - if you share the whole snap you will get the revision number | 13:33 |
| zyga | if you want to use the 1:1 mode instead please drop the "source" component from the syntax | 13:33 |
| cjp256 | oh | 13:34 |
| zyga | i think this is documented | 13:35 |
| zyga | let me know if this aspect is unclear please | 13:36 |
| zyga | sergiusens: hi | 13:36 |
| NerdSnapper | mborzecki: great thank you, you helped me understand it, that was the contact-url you mentoined... ;) | 13:36 |
| zyga | sergiusens: we got a SRU regression on a test that checks snapcraft version to be 3.* | 13:36 |
| mup | PR snapd#8891 closed: o/servicestate: add updateSnapstateServices helper (5/9) <Needs Samuele review> <Services ⚙️> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8891> | 13:38 |
| NerdSnapper | mborzecki: I see I am not the only one with this issue :) with youtube-dl | 13:39 |
| joedborg | 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:45 |
| NerdSnapper | joedborg: thumbs-up great! thank you very much | 13:48 |
| cjp256 | 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 |
| cjp256 | behavior for a single shared directory. Thanks for helping me out! | 13:48 |
| sergiusens | zyga: hi, Snapcraft is on version 4 now | 14:00 |
| sergiusens | but I guess you know that | 14:00 |
| sergiusens | SRU regression where? | 14:01 |
| mup | PR snapd#8916 opened: tests: adding ubuntu-20.04 to google-sru backend <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8916> | 14:03 |
| zyga | sergiusens: I’m afk for a moment but I will share the SRU link when I am back | 14:06 |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| zyga | By | 14:21 |
| NerdSnapper | o/ wishing you all a nice evening... | 14:24 |
| === benfrancis2 is now known as benfrancis | ||
| === Son_Goku is now known as Eleventh_Doctor | ||
| === Eleventh_Doctor is now known as Son_Goku | ||
| jdstrand | 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 |
| jdstrand | failed: cannot deliver device serial request: Cannot process serial request for device with brand | 14:29 |
| jdstrand | "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" and model "bbb" | 14:29 |
| jdstrand | ogra: have you seen this? | 14:29 |
| mborzecki | errands, bbl | 14:30 |
| ijohnson | jdstrand: that's expected unless you have `serial-authority: [generic]` in your model assertion | 14:30 |
| ogra | jdstrand, well, this device doesnt use a canonical model | 14:30 |
| ijohnson | jdstrand: or unless you have a brand store for your bbb :-) | 14:30 |
| ogra | being core16 i dont think there are ways to make it obtain one | 14:30 |
| ogra | (one = serial) | 14:30 |
| ogra | core20 allows the new "generic" serial | 14:31 |
| ijohnson | ogra: you could try rebuilding that image with a model that uses serial-authority | 14:31 |
| ogra | probably time that i dust off my bbb and create a core20 img | 14:31 |
| ijohnson | ogra: also serial-authority: [generic] is allowed on any uc model, not just uc20 | 14:31 |
| ogra | oh, i didnt know that ! | 14:31 |
| ijohnson | yes it's a generic feature of model assertions now | 14:31 |
| jdstrand | ijohnson: ok, well, this is a new, somewhat noisy message | 14:32 |
| ogra | i'll play with it .. | 14:32 |
| ijohnson | the appliance images which are all uc18 use this | 14:32 |
| ijohnson | jdstrand: it shouldn't be new though ... | 14:32 |
| jdstrand | newish? I feel like I've only started seeing it in my logs. maybe the message changed and my filter isn't catching it... | 14:32 |
| ogra | well, i think snapd used to be quiet about it ... apart from an error in snap changes | 14:32 |
| jdstrand | ok, yes, the message changed | 14:35 |
| jdstrand | it used to say: cannot deliver device serial request: Cannot process serial request for device with brand "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP", store can sign serial only for brand "canonical" | 14:36 |
| * jdstrand updates logcheck | 14:36 | |
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| pedronis | maybe the store error status changed a bit and the effect is different | 15:13 |
| pedronis | I would need to check | 15:13 |
| pedronis | if the http status code is the same the behavior shouldn't be much different | 15:14 |
| ijohnson | cachio: can you explain the purpose or intent of this line in prepare.sh: https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L288 | 15:15 |
| ijohnson | cachio: I keep seeing google-nested:...:tests/nested/classic/ fail to prepare from this line | 15:16 |
| ijohnson | and it's unclear to me why we need that line, since we install the core snap below, why does it matter that we didn't have the core snap before we go to install it? | 15:16 |
| pedronis | ijohnson: I think mvo added that because we had this images that sometimes have core and sometimes don't | 15:17 |
| pedronis | and if core is there you get race errors | 15:17 |
| ijohnson | pedronis: no that line is much older | 15:18 |
| ijohnson | https://github.com/snapcore/snapd/commit/f45e33a299ebfa08f8bdf53c924d5ece1d46f046 | 15:18 |
| cachio | ijohnson, it is because we need to make sure that the env is clean | 15:18 |
| ijohnson | or rather https://github.com/snapcore/snapd/commit/4ba6181f9b4ea724752f48114a4a263897d4197a actually | 15:18 |
| pedronis | ijohnson: ah, it's prepare classic, not core | 15:18 |
| ijohnson | cachio: so why don't we instead try to just purge snapd from the system instead of just failing the test if the core snap is there? | 15:19 |
| ijohnson | I don't know why the core snap is there but it feels like every run I will get the core snap there | 15:19 |
| cachio | ijohnson, so, you face that issue when reuse your system right? | 15:19 |
| cachio | or when using a clean env? | 15:19 |
| ijohnson | cachio: yes it happens when the system is reused afaict | 15:20 |
| ijohnson | err rather after the system was used for a test, restore runs, then the next test prepare runs and fails like this because the core snap is there | 15:20 |
| cachio | ijohnson, in this case we need to make something to clean up better when we restore | 15:20 |
| cachio | because the idea is to make sure the env is clean | 15:21 |
| ijohnson | cachio: ok, I will try something locally to see if it fixes the problem in restore and propose today | 15:21 |
| cachio | ijohnson, perhaps just removing snapd is enough | 15:22 |
| cachio | remove --purge | 15:23 |
| ijohnson | cachio: that is what I was going to try | 15:23 |
| cachio | ijohnson, nice, thakns!! | 15:23 |
| cachio | ijohnson, just ping me, I'll review it | 15:23 |
| cachio | after lunch | 15:24 |
| ijohnson | cachio: sounds good | 15:24 |
| * cachio lunch | 15:46 | |
| mborzecki | heh 2020-06-24T13:49:05.9507944Z 2020-06-24 13:49:05 Cannot allocate google:ubuntu-14.04-64: cannot perform Google request: Get https://www.googleapis.com/compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: 500 Internal Server Error | 15:54 |
| ijohnson | amazing | 15:56 |
| zyga | google ran out of ram | 15:58 |
| mup | PR snapcraft#3187 closed: cli: use maxval of UnknownLength for pack progress <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3187> | 16:02 |
| mup | PR snapd#8916 closed: tests: adding ubuntu-20.04 to google-sru backend <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8916> | 16:29 |
| mup | PR snapd#8913 closed: tests/core/snap-auto-mount: try to make the test more robust <Simple 😃> <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8913> | 16:39 |
| * zyga takes a break, | 17:01 | |
| zyga | tomorrow will be a more productive day | 17:01 |
| mup | PR snapd#8835 closed: POC: skip binary to skip tests in an easy way <Proof of concept> <Skip spread> <⛔ Blocked> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8835> | 17:24 |
| * cachio -> kinesiologist | 17:43 | |
| ogra | Lukewh, did our metrics stop working or did my zoom-client snap simply hit a threshold ? the numbers havent changed i a week now | 17:56 |
| ogra | *in a week | 17:56 |
| === benfrancis0 is now known as benfrancis | ||
| mup | PR snapd#8917 opened: osutil/disks: add mock disk and tests for happy path of mock disks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8917> | 19:39 |
| mup | PR snapcraft#3188 opened: snap: allow for different compressions for pack <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3188> | 20:18 |
| mup | PR snapd#8918 opened: many: make nested spread tests more reliable <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8918> | 20:40 |
| mup | PR snapd#8919 opened: gadget/install,secboot: test if the tpm can be provisioned <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8919> | 21:00 |
| mup | PR snapcraft#3118 closed: plugins: add support for local v2 plugins (core20) <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3118> | 21:38 |
| mup | PR snapd#8920 opened: interfaces: update cups-control and add cups for providing snaps <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920> | 21:55 |
| secretfader | Is there a currently recommended method for self-hosting a snap store? | 23:12 |
| secretfader | (I tried searching the forum, but only came back with posts that seem outdated.) | 23:12 |
| oerheks | one can publish private snaps on snapcraft.io | 23:17 |
| oerheks | but your own or 'offline' snapstore, no. | 23:18 |
| oerheks | one can download snaps and store them, ofcourse | 23:18 |
| oerheks | (correct me if i am wrong) | 23:19 |
| secretfader | oerheks: Thanks for the insight. That's what I understand as well, but hoped I was wrong. (I'd like to investigate p2p distribution methods, in addition to official server/client techniques.) | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!