| mborzecki | morning | 06:40 |
|---|---|---|
| mborzecki | school run, back in 30 | 07:28 |
| mborzecki | re | 07:48 |
| mborzecki | mvo: hey | 07:48 |
| mvo | good morning mborzecki | 07:49 |
| mup | PR snapd#9920 closed: many: add Delegate=true to generated systemd units for special interfaces (master) <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9920> | 07:50 |
| mup | PR snapd#9925 opened: release: snapd 2.49 <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9925> | 07:55 |
| mborzecki | mvo: can you upload the release tarballs to github releasese page? | 07:57 |
| mvo | mborzecki: sure, just done | 07:58 |
| mborzecki | thanks! | 07:58 |
| pstolowski | morning | 08:01 |
| mvo | pstolowski: good morning | 08:18 |
| mborzecki | pushed out 2.49 to arch | 08:28 |
| mborzecki | mvo: btw. not really needed at this point, but i noticed the source tarballs for 2.48.1 are missing from github ;) | 08:29 |
| mborzecki | it's probably for posterity only | 08:29 |
| pedronis | #9893 needs a 2nd review | 08:51 |
| mup | PR #9893: store: support validation sets with fetch-assertions action <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9893> | 08:51 |
| pstolowski | yep, i was just going to ask for 2nd review :} | 09:00 |
| mborzecki | mvo: do you need me in the desktop sync? | 09:02 |
| mvo | mborzecki: no, it's fine | 09:02 |
| mborzecki | ok | 09:03 |
| === mcphail2 is now known as mcphail | ||
| mup | PR snapd#9926 opened: interfaces/seccomp: allow copy_file_range by default <Needs security review> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9926> | 09:55 |
| mborzecki | mvo: ^^ quick fix | 09:55 |
| pstolowski | mborzecki: how do you feel about doing 2nd review of 9893? | 10:28 |
| mborzecki | pstolowski: have it open, but haven't looked in detail yet, will try to go through it today | 10:33 |
| pstolowski | ty | 10:33 |
| pstolowski | ijohnson: lol @ your file range copy comment | 13:09 |
| ijohnson | :-) | 13:10 |
| mup | PR snapd#9927 opened: packaging/fedora: sync with downstream packaging in Fedora <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9927> | 13:11 |
| mborzecki | ijohnson: hahaha, yeah, felt kind of familiar but i saw we only had it in the docker iface, so assumed that whatever we hd for master did not land | 13:12 |
| mborzecki | ijohnson: can we land it? :) node14 seems to use that syscall via libuv | 13:13 |
| mborzecki | i mean #9702 | 13:13 |
| mup | PR #9702: interfaces/seccomp/template.go: allow copy_file_range <Needs security review> <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9702> | 13:13 |
| mup | PR snapd#9926 closed: interfaces/seccomp: allow copy_file_range by default <Needs security review> <Simple 😃> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9926> | 13:16 |
| ijohnson | mborzecki: still needs security review :-/ | 13:17 |
| mborzecki | amurray: gentle ping ^^ | 13:19 |
| mup | PR snapd#9928 opened: boot: cmd/snap-bootstrap: handle a candidate recovery system <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9928> | 13:51 |
| mup | PR snapd#9925 closed: release: snapd 2.49 <Skip spread> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9925> | 14:06 |
| pedronis | ijohnson: I think I found some go code that does what you where trying to do | 14:39 |
| pedronis | *were | 14:39 |
| ijohnson | ah nice | 14:39 |
| ijohnson | well as you mentioned what I ended up doing is actually not what we need to do so maybe it is all moot | 14:39 |
| ijohnson | but I would be curious to see in any case | 14:39 |
| pedronis | ijohnson: it's a bit old so it nees changes but I can put it somewhere | 14:40 |
| ijohnson | pedronis: in any case this is what I settled on to create a self-signed account-key, but I'll just ignore that for now https://gist.github.com/anonymouse64/22fd11b48676e1641eb51bd6d7fe4031 | 14:42 |
| pedronis | ijohnson: https://gist.github.com/pedronis/d4ba5849e40814f1fa5ee22d8b525471 | 14:43 |
| ijohnson | pedronis: ah nice I missed some of those fuctions in assertstest I guess | 14:44 |
| ijohnson | pedronis: is there one to output the private gpg encoded private key that can be imported by fakestore to sign the repair assertion ? | 14:45 |
| pedronis | ijohnson: that's the dumpRSAKey thing, see it's consumed later by ReadPrivKey | 14:48 |
| pedronis | to check it works | 14:48 |
| ijohnson | ah right got it | 14:49 |
| pedronis | ijohnson: basically once fixed, the output would need to be embedded in systestkeys | 14:51 |
| pedronis | ijohnson: tbh, I don't remember why I didn't do that at the time I wrote this | 14:53 |
| pedronis | maybe I used the result only locally | 14:53 |
| ijohnson | anyways yes this seems to do what I need for the repair assertion account-key | 14:53 |
| jdstrand | ijohnson: hey, requested a teensy change for copy_file_range | 14:54 |
| ijohnson | hey jdstrand, thanks! I'll have a look in a bit, I have quite a few meetings this morning | 14:54 |
| jdstrand | ijohnson: np at all. have a nice rest of the day :) | 14:55 |
| jdstrand | amurray: you may be interested in ^ | 14:55 |
| pedronis | ijohnson: I think it needs a couple of fixes because some assertstest helpers have changed | 14:56 |
| jdstrand | hey pedronis :) | 14:56 |
| pedronis | jdstrand: hi | 14:56 |
| pedronis | ijohnson: if we haven't grown something like it since, it might be worth adding dumpRSAKey to assertstest | 14:58 |
| ijohnson | pedronis: ack | 14:59 |
| pedronis | ijohnson: are unblocked on this? | 16:11 |
| ijohnson | sorry still in meetings | 16:11 |
| pedronis | sorry, my fault | 16:14 |
| ackk | hi, snapcraft question: in a snap, I have libblas.so.3 (pulled in as a dependency of a stage-packages) ending up in $SNAP/usr/lib/x86_64-linux-gnu/blas, while on a regular install it's under /usr/lib/x86_64-linux-gnu. is that snapcraft doing? | 16:44 |
| bandali | hi, is it intentional that the 'current' symlink of a snap doesn't seem to be changed to the latest version until it's actually run? | 17:02 |
| bandali | i ask because i was hoping to jiggle a few things around in a snap's $XDG_CONFIG_HOME in a post-refresh hook, but i don't think it's working :-/ | 17:04 |
| bandali | any thoughts/suggestions diddledan? | 17:14 |
| pstolowski | bandali: no. current symlinks should be updated when post-refresh hook runs | 17:15 |
| diddledan | the user-level ones aren't, pstolowski | 17:15 |
| pstolowski | diddledan: you're right! | 17:16 |
| diddledan | only the non-user-specific ones are. i.e. $SNAP, $SNAP_DATA and $SNAP_COMMON are updated | 17:16 |
| bandali | err, i'm kind of confused :-/ do you have an example for me to check, for how to update stuff in XDG_CONFIG_HOME in a post-refresh hook? | 17:16 |
| bandali | (if it's at all possible ?) | 17:16 |
| diddledan | it's not possible | 17:16 |
| bandali | oh, dang.. my use case was adding a symlink in XDG_CONFIG_HOME/autostart/ to a desktop file somewhere in $SNAP/ | 17:17 |
| bandali | but the symlink would need to be updated/fixed in each upgrade because $SNAP changes | 17:18 |
| diddledan | symlink it through /snap/$SNAPNAME/current instead of $SNAP | 17:18 |
| bandali | ohh okay cool that might work! thanks for the idea, i'll give that a shot | 17:20 |
| mup | PR snapcraft#3434 closed: build providers: clean environment if project directory is changed <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3434> | 19:05 |
| mup | PR snapcraft#3320 closed: python v2 plugin: consistent linking for interpreter <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3320> | 19:10 |
| mup | PR snapcraft#3363 closed: repo: apt sources management refactor <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3363> | 19:10 |
| mup | PR snapcraft#3370 closed: repo: address issue with fix_symlink() when pointed at directory <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3370> | 19:10 |
| ijohnson | bandali: diddledan: mind filing a bug about only switching $SNAP_USER_* current symlinks at runtime? | 19:16 |
| ijohnson | I know why we don't do it because it's $HARD but it would be nice to track that we don't do it in case it comes up again | 19:16 |
| mvo | just in case soneone wonders - snapd (and more) in hirsute broken because of https://bugs.launchpad.net/ubuntu/+source/fakeroot/+bug/1915250 - only happens if you run hirsute-proposed | 19:20 |
| mup | Bug #1915250: buildd file owner/group for shared libraries <binutils (Ubuntu):Confirmed> <debhelper (Ubuntu):Confirmed> <fakeroot (Ubuntu):Confirmed> <glibc (Ubuntu):Confirmed> <debhelper (Debian):Unknown> <https://launchpad.net/bugs/1915250> | 19:20 |
| tianon | is there a way to see what underlying event triggered builds in https://snapcraft.io/xxx/builds ? (whether it was a GitHub webhook, manual trigger, etc) | 20:40 |
| ijohnson | tianon: builds from snapcraft.io/builds will end up in launchpad at https://launchpad.net/~build.snapcraft.io/+snaps, so you could try to find the snap you are looking for in there, otherwise the #launchpad channel might have more tips | 21:57 |
| cjwatson | I think this was a feature that the old build.snapcraft.io used to have that was lost in the rewrite. | 21:57 |
| cjwatson | IIRC Launchpad was never told the triggering reason for the build - it was only ever stored on the BSI side. | 21:57 |
| tianon | right, the builds themselves show up there, but the trigger doesn't | 21:58 |
| cjwatson | And I think the rewrite decided that they wanted to go from not much persistent state to no persistent state. | 21:58 |
| tianon | I can go into the build logs on snapcraft.io and see the launchpad link for a specific build even (it's the first line) | 21:58 |
| cjwatson | To restore the feature I guess we'd need to extend LP's data model to have some kind of a triggering-reason column, and have snapcraft.io/build pass it so that it could be stored and rendered | 21:59 |
| tianon | but the issue I'm having is that my last commit was 5 days ago and there have been two all-architectures rebulid triggers since that I'm scratching my head about :) | 21:59 |
| tianon | maybe there's a wishlist tracker somewhere this could be filed in? (or already is?) O:) | 22:00 |
| cjwatson | https://github.com/canonical-web-and-design/snapcraft.io/issues | 22:02 |
| cjwatson | I think | 22:02 |
| cjwatson | (Maybe they do have a database on the snapcraft.io side that could be used without a lot of complicated back-and-forth with LP. I'm not sure - I was involved quite a bit with the old BSI but not much with the rewrite.) | 22:03 |
| tianon | searching those now, and I'll file something if I don't find anything; thanks :) | 22:05 |
| tianon | (ended up with https://github.com/canonical-web-and-design/snapcraft.io/issues/3408 for anyone curious or interested) | 22:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!