| mup | PR snapd#7917 opened: snap-bootstrap: trigger udev for new partitions <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7917> | 01:37 |
|---|---|---|
| mup | Bug #1846894 changed: Cannot use PulseAudio in classic confinement <Snappy:Expired> <https://launchpad.net/bugs/1846894> | 04:19 |
| mup | PR snapd#7909 closed: snap: improve squashfs.ReadFile() error <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7909> | 05:53 |
| mup | PR snapd#7911 closed: systemd: fix uc20 shutdown <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7911> | 05:53 |
| mup | PR snapd#7912 closed: boot: write modeenv when creating the run mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7912> | 05:53 |
| mup | PR snapd#7915 closed: lkenv.go: adjust for new location of include file <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7915> | 06:12 |
| mup | PR snapd#7918 opened: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918> | 06:13 |
| mup | PR snapd#7914 closed: bootstrap: reduce runmode mounts from 5 to 2 steps <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7914> | 06:14 |
| mborzecki | morning | 06:35 |
| mvo | hey mborzecki | 06:48 |
| mup | PR snapd#7919 opened: snapstate: do not try up update bootloader in ephemeral mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7919> | 06:49 |
| mborzecki | mvo: hey, any interesting PRs to look at? | 06:50 |
| mvo | mborzecki: 7918,7919 are hopefully interessting | 06:53 |
| mborzecki | mvo: ok, let me see, i saw some chatter yesterday about that but i may not be familiar with the details | 06:56 |
| mup | PR snapd#7920 opened: snapstate: do not try to detect rollback in ephemeral modes <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7920> | 07:11 |
| mvo | mborzecki: yeah, all pretty straightforward but probably needs samuele anayway | 07:13 |
| mborzecki | mvo: #7916 is quite trivial | 07:19 |
| mup | PR #7916: interfaces/browser-support: add more product/vendor paths <Created by Erick555> <https://github.com/snapcore/snapd/pull/7916> | 07:19 |
| pstolowski | morning | 08:01 |
| mborzecki | pstolowski: hey | 08:02 |
| mup | PR snapd#7921 opened: devicestate: run boot.MakeBootable in doSetupRunSystem <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921> | 08:21 |
| === niemeyer_ is now known as niemeyer | ||
| === nniehoff_ is now known as nniehoff | ||
| === plars_ is now known as plars | ||
| === souther_ is now known as souther | ||
| === blackboxsw_ is now known as blackboxsw | ||
| === bloodearnest_ is now known as bloodearnest | ||
| === stoopkid_ is now known as stoopkid | ||
| === cydizen_ is now known as cydizen | ||
| === davecore_ is now known as davecore | ||
| === coreycb_ is now known as coreycb | ||
| === nottrobin_ is now known as nottrobin | ||
| mup | PR snapd#7905 closed: cmd/snap-bootstrap: actually parse snapd_recovery_system label <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7905> | 09:15 |
| pedronis | degville: I don't have enough access to make comments or suggestions to the assertions doc | 09:23 |
| degville | pedronis: sorry - fixed now. I keep expecting docs to default to edit in share mode. | 09:24 |
| Chipaca | degville: 👋 | 09:25 |
| Chipaca | degville: I noticed while on holiday that in the glossary we were mixing up core and core16 | 09:25 |
| Chipaca | degville: if nobody brought that to your attention, here is me doing so :) | 09:25 |
| degville | Chipaca: thanks! pedronis did indeed point it out - hopefully fixed now. | 09:26 |
| Chipaca | degville: good good :) | 09:26 |
| pedronis | degville: thank you, I did a pass | 09:42 |
| degville | pedronis: thank you! | 09:42 |
| mup | PR snapd#7922 opened: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922> | 10:12 |
| pedronis | degville: I did some edits to the glossary, please look at the last diff, feel free to reedit if needed | 10:17 |
| pedronis | degville: we also should tweak the assertions entry once we have agreement in the main doc | 10:17 |
| pedronis | degville: weird, seems for reasons discourse merged my update with your last one | 10:24 |
| pedronis | (that is confusing (tm)) | 10:24 |
| pedronis | degville: pstolowski: I made a couple of suggestions in the preseed help doc | 10:29 |
| degville | pedronis: thanks! I'll take a look at the glossary diff and your other comments! | 10:30 |
| pstolowski | pedronis: thanks! | 10:30 |
| pedronis | pstolowski: the help texts are good for me now | 10:31 |
| pstolowski | pedronis: +1, i can prep a PR once degville makes a pass | 10:33 |
| pedronis | thx | 10:33 |
| degville | pstolowski: looking now, but they're good for me too. | 10:33 |
| degville | pstolowski: +1 from me too... thanks for creating the docs. | 10:36 |
| degville | s/docs/doc | 10:36 |
| pstolowski | np, thanks for feedback! | 10:37 |
| mup | PR snapd#7923 opened: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7923> | 10:56 |
| === cjwatson_ is now known as cjwatson | ||
| cachio | Chipaca, hey | 11:12 |
| Chipaca | cachio: 'sup | 11:12 |
| cachio | last week there was a problem with the apt-hooks test | 11:12 |
| cachio | store started rejecting calls to /names api | 11:13 |
| cachio | I had to set as manual the test | 11:13 |
| cachio | Chipaca, this is the log https://paste.ubuntu.com/p/JY69dz4vwP/ | 11:14 |
| cachio | Chipaca, do you know if anything chante in snapd that could be causing this? | 11:14 |
| Chipaca | cachio: nothing changed in snapd no | 11:15 |
| mup | PR snapd#7924 opened: tests: fix use of MATCH -v <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7924> | 11:15 |
| cachio | Chipaca, so, somethings changed in the store | 11:16 |
| Chipaca | cachio: probably | 11:17 |
| Chipaca | cachio: how often were we getting this, and in what timeframe? | 11:17 |
| mborzecki | Chipaca: ^^ | 11:17 |
| mborzecki | fun PR | 11:17 |
| Chipaca | mborzecki: yep, nice | 11:17 |
| cachio | Chipaca, almost all the runs were failing | 11:17 |
| cachio | Chipaca, and if you run now the whole suite it fails too | 11:18 |
| mborzecki | cachio: 429 Too Many Requests, store doesn't like us anymore? | 11:18 |
| cachio | yesterday I rna the checks pr which wasn't merged to master nad apt-hooks failed | 11:19 |
| cachio | mborzecki, aparently not :) | 11:19 |
| Chipaca | cachio: when did this start? | 11:19 |
| cachio | tuesday / wednesday | 11:20 |
| mborzecki | logger.go:74: DEBUG: < "HTTP/1.0 429 Too Many Requests\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n" | 11:21 |
| mborzecki | it'd be nice to see the content | 11:21 |
| cachio | Chipaca, reviewed the google docs and I see the error started on tuesday | 11:22 |
| mborzecki | cachio: this happens when running on gcp? | 11:22 |
| cachio | mborzecki, yes | 11:22 |
| mborzecki | cachio: ok, trying out something | 11:27 |
| cachio | mborzecki, nice, thanks | 11:30 |
| mvo | 7904 needs a second review | 11:30 |
| mborzecki | cachio: heh, i suppose i can stop spamming api.snapcraft.io, can't reproduce this, maybe curl takes too long between requests | 11:37 |
| cachio | mborzecki, perhaps I could add extra logging and run apt hooks test | 11:38 |
| cachio | does it make sense? | 11:38 |
| mborzecki | cachio: have you seen it pop up in PR travis jobs? | 12:01 |
| mup | PR pc-amd64-gadget#29 opened: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/29> | 12:01 |
| mup | PR snapd#7925 opened: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925> | 12:01 |
| mborzecki | cmatsuoka: question for you in 7917 | 12:06 |
| cmatsuoka | mborzecki: sure | 12:06 |
| mborzecki | cmatsuoka: maybe worth trying, provided the spread tests pass | 12:07 |
| cmatsuoka | mborzecki: let me check what that does exactly... | 12:08 |
| cmatsuoka | mborzecki: so you mean calling it after all nodes are there (and it would act on all block devices, not only the ones we just created)? | 12:09 |
| mborzecki | cmatsuoka: no, just adding --subsystem-match=block to the udevadm trigger call | 12:10 |
| cachio | mborzecki, yes | 12:10 |
| pstolowski | pedronis, degville #7925 is up | 12:10 |
| mup | PR #7925: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925> | 12:10 |
| cachio | mborzecki, initially I saw that in travis | 12:10 |
| degville | pstolowski: thank you! | 12:10 |
| cachio | then I could reproduce it manually here | 12:11 |
| cmatsuoka | mborzecki: since we're already calling it with a block device target, I think it wouldn't change what it's doing | 12:11 |
| cmatsuoka | mborzecki: I'll have a look at the source code to be sure | 12:12 |
| mborzecki | cachio: ah, right | 12:12 |
| mborzecki | cachio: yeah, so it's fine | 12:12 |
| cachio | mborzecki, which should be the best configuration for adding more debug info ? | 12:25 |
| cachio | trying to add more debug without touching the code | 12:25 |
| cachio | mborzecki, currently we use SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=1 | 12:26 |
| mup | PR pc-amd64-gadget#29 closed: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/29> | 12:28 |
| mborzecki | cachio: i think that we only dump the outgoing request data | 12:33 |
| cachio | mborzecki, now is not failing anymore apt-hooks | 12:37 |
| mup | PR snapd#7926 opened: cmd/snap-bootstrap: xxx todos about kernel cross-checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/7926> | 12:45 |
| cachio | mvo, about 2.43 on arm64 | 12:47 |
| cachio | it is not in beta the snapd snap | 12:47 |
| mvo | cachio: oh, let me check. maybe there was a mistake :( sorry for that | 12:49 |
| mvo | cachio: should be fixed now | 12:50 |
| cachio | mvo, thanks | 12:50 |
| === ricab is now known as ricab|lunch | ||
| mborzecki | cachio: pushing some patches to reset the state of failed services after each test run in a couple of minutes | 13:00 |
| cachio | mborzecki, nice, I am going to the hospital now, I'll review it there | 13:02 |
| * cachio afk | 13:06 | |
| mup | PR snapcraft#2845 opened: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2845> | 13:43 |
| mup | PR snapd#7925 closed: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7925> | 13:52 |
| mup | PR snapd#7924 closed: tests: fix use of MATCH -v <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7924> | 14:03 |
| === stgraber_ is now known as stgraber | ||
| === ricab|lunch is now known as ricab | ||
| === heather is now known as hellsworth | ||
| mvo | hrm, lot's of reds in snapd already | 14:47 |
| mvo | eh, travis - has anyone looked? | 14:47 |
| thresh | hello. can someone explain to me why I can not see "real" hostfs root from my VLC snap, but still can access it via /var/lib/snapd/hostfs/ ? i'm on debian, snap/snapd 2.42.5, kernel 5.3.0. vlc is installed in "strict" mode. | 14:48 |
| cachio | mvo, any test that I could take a look? | 15:01 |
| cachio | of those reds? | 15:01 |
| pstolowski | thresh: the filesystem that snaps see is composed on the fly from core snap (or core18) and various bind-mounted dirs, so it's completely different from the host fs. hostfs is mounted on the side under /var/lib/snapd/hostfs/ for some interfaces (such as system-observer or opengl), but access is controlled by apparmor (which i suppose you don't have) | 15:07 |
| thresh | thanks pstolowski | 15:08 |
| thresh | I do have apparmor though, and aa-status reports VLC as enforced mode, as well as ps auxZ: snap.vlc.vlc (enforce) thresh 70717 24.0 0.4 1002360 71556 pts/1 Sl+ 18:09 0:00 /snap/vlc/1049/usr/bin/vlc --config=/home/thresh/snap/vlc/common/vlcrc | 15:09 |
| mvo | cachio: I have not investigated, just noticed in recent PR runs | 15:11 |
| cachio | mvo, ok, your PRs right? | 15:11 |
| cachio | I am gonna take a look | 15:11 |
| pstolowski | thresh: do you have vlc's opengl plug connected? | 15:13 |
| thresh | pstolowski, yes | 15:13 |
| mup | PR snapcraft#2846 opened: base plugin: use shlex quoting for logged command in run() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2846> | 15:13 |
| pstolowski | thresh: opengl interface gives access to portion of hostfs - see https://github.com/snapcore/snapd/blob/702a637803b1da7f55596e6de3d76057929e5f78/interfaces/builtin/opengl.go#L38 | 15:15 |
| thresh | pstolowski, I can reproduce the same behaviour e.g. with "jq" snap, which doesnt have any plugs | 15:17 |
| pstolowski | thresh: do you mean the snap can access entire var/lib/snapd/hostfs ? | 15:17 |
| thresh | and this doesnt really explain why opengl plug allows access to /data/1.mkv in my case | 15:17 |
| thresh | well, rather /var/lib/snapd/hostfs/data/1.mkv | 15:18 |
| thresh | I mean, it's probably due to debian, and confinement being not full | 15:21 |
| thresh | but I'd rather like to understand what exactly causes that | 15:21 |
| mvo | cachio: yeah, it may well be it all real, i was too busy to check | 15:21 |
| cachio | zyga, could you please take a quick look to #7877 | 15:24 |
| mup | PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877> | 15:24 |
| cachio | it is failing in many prs | 15:24 |
| pstolowski | thresh: most likely yes.. i cannot confirm this observation with ubuntu. could you please show the output of:snap debug confinement | 15:26 |
| pstolowski | thresh: snap debug confinement | 15:26 |
| pstolowski | thresh: and 'snap debug sandbox-features' | 15:26 |
| thresh | pstolowski, https://code.videolan.org/snippets/1118 there you go | 15:27 |
| cjp256 | anyone have a good example on how to configure opengl for `classic`? | 15:27 |
| cjp256 | i built an opengl app that just works without any special casing on my nvidia graphics system, but fails on intel. Interesting that nvidia just works in the classic case? | 15:29 |
| pstolowski | thresh: right. that's it | 15:29 |
| pstolowski | thresh: on ubuntu it is strict, and for apparmor it's apparmor: kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full | 15:29 |
| pstolowski | thresh: and also confinement-options: classic devmode strict (yours is missing strict) | 15:31 |
| thresh | right, so the differences are: missing kernel:dbus, and policy:downgraded vs policy:default | 15:33 |
| thresh | there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500 but that seems to be forgotten, too | 15:33 |
| cjp256 | zyga: ^ maybe you have some thoughts wrt opengl? :D | 15:33 |
| pstolowski | cjp256: zyga is off this week; perhaps mborzecki ? ^ | 15:35 |
| mborzecki | hm hm? | 15:35 |
| cjp256 | ah, thanks! | 15:35 |
| mborzecki | cjp256: does the snap include relvant mesa libs and drivers? | 15:36 |
| cjp256 | it does not (yet) - but I assume it should, and should do something like found https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L81 | 15:37 |
| cjp256 | while I'm doing this for specific snap right now, my ultimate goal is to add an "opengl" extension which should just work for classic or strict | 15:38 |
| cjp256 | though it was interesting that without any mesa stuff, nvidia worked | 15:39 |
| pstolowski | thresh: right.. and the last comment there is from zyga.. he may know more where we are with this, but as i just said, he is off | 15:39 |
| mborzecki | cjp256: nvidia is handled slightly differently, especially for confined snaps | 15:39 |
| === AdmWiggin is now known as tianon | ||
| mborzecki | cjp256: fwiw that should be transparent for the snap | 15:40 |
| cjp256 | yeah, this one is classic (alacritty terminal). | 15:40 |
| cjp256 | the mesa packages should also be staged with classic, correct? don't attempt to use the host's? | 15:43 |
| mborzecki | cjp256: looked ad the code again, for classic we don't set up anything nvidia specific, it's only done when snap is confined, but mesa should be part of the snap in both scenarios | 15:44 |
| mborzecki | wish we had some time allocated for the gpu support proposal zyga had, but maybe next cycle | 15:45 |
| mborzecki | cjp256: if you have thoughts/ideas feel free to review https://forum.snapcraft.io/t/gpu-support-proposal/11247/13 and share them | 15:46 |
| cachio | pstolowski, could you take a quick look to #7877 please? | 15:47 |
| mup | PR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877> | 15:47 |
| cjp256 | ah, was not aware of that. thanks mborzecki :) | 15:47 |
| cachio | this is constantly failing on master | 15:47 |
| pstolowski | cachio: sure | 15:47 |
| cachio | pstolowski, thanks | 15:48 |
| * cachio lunch | 15:53 | |
| pstolowski | cachio: a general question there, i'm confused by this change, need more info. if you can provide a more elaborate description it would be super helpful (the sentence "The idea os this test is the rsyslog service when it does not exist." needs fixing) | 16:20 |
| tomwardill | hello! Store team here, downloads are currently having a bad time, and you might get errors. We're looking at it :) | 16:21 |
| cachio | pstolowski, sure | 16:22 |
| pstolowski | cachio: thanks! | 16:22 |
| cachio | pstolowski, yaw | 16:22 |
| tomwardill | downloads should now be working again! | 16:46 |
| roadmr | \o/ | 16:47 |
| cachio | pstolowski, description updated | 16:58 |
| pstolowski | ty | 16:58 |
| pstolowski | cachio: the description is fine. have you seen my reply re uc18? | 17:17 |
| cachio | pstolowski, yes, I am making hte change | 17:20 |
| pstolowski | cachio: i'm about to EOD but don't want to block this PR | 17:20 |
| cachio | 1 sec | 17:20 |
| cachio | pstolowski, nice, thanks | 17:20 |
| pstolowski | ok | 17:20 |
| pstolowski | cachio: i can approve, just push the change to limit it to uc18 | 17:20 |
| pstolowski | before merging | 17:21 |
| cachio | pstolowski, pushed | 17:24 |
| pstolowski | k | 17:24 |
| vidal72[m] | why in snap users aren't allowed to manually connect slots that aren't declared in manifest? | 17:28 |
| cachio | pstolowski, is it ok there or it is better to put is at the begining of the prepare phase? | 17:29 |
| cachio | perhaps that's more clear | 17:29 |
| vidal72[m] | when some slot is missing and snap maintainer is afk then it's a dead end... | 17:29 |
| pstolowski | vidal72[m]: well, that's deliberate, snaps must know what they need and must be upfront about that. otherwise people would start connecting random slots in a hope of getting a broken snap to work. if a snap is missing a slot it should have, it's a bug of the snap like any other bug.. | 17:34 |
| pstolowski | cachio: yes i think beginning would be better | 17:36 |
| pstolowski | cachio: also made one small remark | 17:36 |
| vidal72[m] | pstolowski: yes but the bug remains unfixable by user if publisher doesn't cooperate | 17:37 |
| cachio | pstolowski, nice, already pushed the change | 17:39 |
| cachio | pstolowski, thanks for the review!!! | 17:39 |
| cachio | pstolowski, thanks for the +1 | 17:43 |
| cachio | I'll merge it once it is in gree | 17:43 |
| cachio | n | 17:43 |
| pstolowski | vidal72[m]: yeah, but that's no different than any other software bug. what you propose has secruity implications. nb, you can try repack that snap yourself and change its manifest, then install it with --dangerous | 17:43 |
| cachio | see you tomorrow | 17:43 |
| pstolowski | yep, eod, cu! | 17:44 |
| mup | PR snapd#7877 closed: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877> | 18:42 |
| bdx | hello | 19:09 |
| bdx | I have just registered the snap name "munge" | 19:09 |
| bdx | here is the repo for the snap https://github.com/omnivector-solutions/snap-munge | 19:10 |
| bdx | Omnivector is going to be maintaining this snap | 19:10 |
| bdx | Can I request an approval on the name please? | 19:11 |
| bdx | thanks! | 19:11 |
| bdx | (the snap store wont let me push to "munge" until its approved by someone) | 19:11 |
| roadmr | hi bdx | 19:27 |
| bdx | roadmr: how's it going? | 19:27 |
| roadmr | bdx: to be clear, are you as a snap developer going to be maintaining the snap, or do you envision transferring it to another Omnivector account? | 19:27 |
| bdx | the https://github.com/omnivector-solutions github account is where it will live as far as I can see | 19:29 |
| bdx | there will be others that contribute to the project, but the upstream will always remain https://github.com/omnivector-solutions/snap-munge | 19:30 |
| roadmr | bdx: right, I'm thinking in terms of snap store accounts here | 19:31 |
| bdx | ahh yes, I dont think I have created a snap store account for omnivector yet | 19:31 |
| roadmr | bdx: and no worries, we can approve for your account and then transfer to a more project-centric account | 19:31 |
| roadmr | (if desired, of course) | 19:31 |
| bdx | ok, I see | 19:31 |
| bdx | should I just create the omnivector snap store account now in that case? | 19:31 |
| roadmr | bdx: you could, and then I can transfer the name (which I've just granted to you anyway). | 19:33 |
| roadmr | bdx: the typical pattern is for the snap to be registered under an e.g. "omnivector" account (for the org/project) which is tied to an e-mail address controlled by the project itself, and then individual people (e.g. you) are attached to the snap as collaborators | 19:34 |
| bdx | ahh I see - I was just going to ask abou thtat | 19:34 |
| roadmr | bdx: this helps in the case of a snap maintainer not being able to maintain the snap for some reason - it can then be transferred away from that person but it's easier if the transfer is avoided altogether :) | 19:35 |
| bdx | entirely - is there a way for me to create the "omnivector" org in the snap store? | 19:35 |
| roadmr | bdx: there's no concept of organizations in the snap store :( what you'd do is register an "omnivector" developer account (i.e. set that as the username) | 19:35 |
| roadmr | bdx: it does have to have an e-mail address different from yours, though | 19:36 |
| bdx | ok, np | 19:36 |
| bdx | so, the snapstore wants to use my ubuntu one user | 19:36 |
| bdx | should I create the ubuntuone user "omnivector" then | 19:37 |
| roadmr | bdx: yes, you'd need to create an altogether new ubuntuone user :/ sorry for the extra hoops | 19:37 |
| bdx | roadmr: np | 19:41 |
| bdx | roadmr: I've created a snapstore user "omnivector-solutions" | 19:41 |
| bdx | is it possible for you to transfer the registered name to this user? | 19:42 |
| roadmr | bdx: I'll do so right away :) | 19:44 |
| roadmr | bdx: done! | 19:46 |
| bdx | roadmr: thats awesome! many thanks! | 19:46 |
| roadmr | np, happy to help :) | 19:46 |
| bdx | roadmr: I was able to upload a release to stable and install from the snap store! | 19:48 |
| bdx | one small quirk .... | 19:49 |
| bdx | I think its related to the build functionality | 19:49 |
| bdx | If I click into the "build" tab in the web ui | 19:50 |
| bdx | I am presented with a page that asks me to login with github | 19:50 |
| bdx | after I login with github I am redirected to the jamesbeedy snapstore account | 19:51 |
| roadmr | bdx: hmm. | 19:52 |
| bdx | so, I get here https://imgur.com/a/HfjbnBJ | 19:52 |
| mup | Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30> | 19:52 |
| roadmr | bdx: I'm not super familiar with the build service :/ not sure how it establishes who you are from your github login | 19:52 |
| roadmr | oh but that says you're omnivector, right? | 19:52 |
| bdx | yeah | 19:53 |
| bdx | see in the img ^ it says omnivector | 19:53 |
| bdx | but when I click the login weith github button | 19:53 |
| bdx | it seems to login my jamesbeedy user https://imgur.com/a/lwQZ6Hk | 19:54 |
| bdx | either way, not a big deal for me | 19:54 |
| roadmr | oh I see | 19:54 |
| bdx | just thought I would mention it | 19:54 |
| roadmr | right, we'd have to ask the build service folks, most of them in Europe so probably sleeping now heh | 19:54 |
| bdx | yeah no worries | 19:54 |
| bdx | I can file a bug for it | 19:54 |
| bdx | roadmr: thanks again for your help here | 19:55 |
| roadmr | np | 19:55 |
| roadmr | build service issues here: https://github.com/canonical-web-and-design/snapcraft.io/issues | 19:56 |
| mup | PR snapd#7927 opened: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927> | 20:50 |
| mup | PR snapcraft#2847 opened: Catkin plugin: consider only 'local' workspaces <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2847> | 21:17 |
| bdx | I have a few questions about socket-directories using the content interface | 21:26 |
| bdx | I have one snap that provides a socket-directory plug https://paste.ubuntu.com/p/N7wchfdYhM/ | 21:28 |
| roadmr | bdx: (in case you don't get a reply here, you can always post in the forum :) a bit easier for people to see that asynchronously) | 21:28 |
| bdx | ok, will do - thx | 21:28 |
| === gurmble is now known as grumble | ||
| bdx | we can see the socket that the munge process creates here https://paste.ubuntu.com/p/FwvQ7JQNZw/ in SNAP_DATA | 21:29 |
| bdx | I create another snap to test with munger | 21:30 |
| bdx | https://paste.ubuntu.com/p/GtxZkyy9Dq/ | 21:30 |
| bdx | ^I have one snap that provides a socket-directory slot* | 21:32 |
| bdx | the other snap creates the plug | 21:32 |
| bdx | I install both of the snaps and connect the content interface plug of one to the content-interface slot of the other https://paste.ubuntu.com/ | 21:35 |
| bdx | https://paste.ubuntu.com/p/qhrQQGKFq3/ | 21:35 |
| * cachio eod | 21:36 | |
| bdx | once both the snaps are connected, I can see the socket in the snap that creates it, but I can't see my socket in the snap that has the consuming plug https://paste.ubuntu.com/p/6tJPVs7x9s/ | 21:39 |
| bdx | err .. that didn't come across so well | 21:48 |
| bdx | I've rephrased it a bit on discourse here https://forum.snapcraft.io/t/the-content-interface/1074/9?u=jamesbeedy | 21:48 |
| mup | PR snapd#7928 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7928> | 22:31 |
| mup | PR snapd#7926 closed: cmd/snap-bootstrap: xxx todos about kernel cross-checks <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7926> | 22:35 |
| === ahayzen_ is now known as ahayzen | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!