[06:40] <mborzecki> morning
[07:28] <mborzecki> school run, back in 30
[07:48] <mborzecki> re
[07:48] <mborzecki> mvo: hey
[07:49] <mvo> good morning mborzecki
[07:50] <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:55] <mup> PR snapd#9925 opened: release: snapd 2.49 <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9925>
[07:57] <mborzecki> mvo: can you upload the release tarballs to github releasese page?
[07:58] <mvo> mborzecki: sure, just done
[07:58] <mborzecki> thanks!
[08:01] <pstolowski> morning
[08:18] <mvo> pstolowski: good morning
[08:28] <mborzecki> pushed out 2.49 to arch
[08:29] <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:51] <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>
[09:00] <pstolowski> yep, i was just going to ask for 2nd review :}
[09:02] <mborzecki> mvo: do you need me in the desktop sync?
[09:02] <mvo> mborzecki: no, it's fine
[09:03] <mborzecki> ok
=== mcphail2 is now known as mcphail
[09:55] <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
[10:28] <pstolowski> mborzecki: how do you feel about doing 2nd review of 9893?
[10:33] <mborzecki> pstolowski: have it open, but haven't looked in detail yet, will try to go through it today
[10:33] <pstolowski> ty
[13:09] <pstolowski> ijohnson: lol @ your file range copy comment
[13:10] <ijohnson> :-)
[13:11] <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:12] <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:13] <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:16] <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:17] <ijohnson> mborzecki: still needs security review :-/
[13:19] <mborzecki> amurray: gentle ping ^^
[13:51] <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>
[14:06] <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:39] <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:40] <pedronis> ijohnson: it's a bit old so it nees changes but I can put it somewhere
[14:42] <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:43] <pedronis> ijohnson: https://gist.github.com/pedronis/d4ba5849e40814f1fa5ee22d8b525471
[14:44] <ijohnson> pedronis: ah nice I missed some of those fuctions in assertstest I guess
[14:45] <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:48] <pedronis> ijohnson: that's the dumpRSAKey thing,  see it's consumed later by ReadPrivKey
[14:48] <pedronis> to check it works
[14:49] <ijohnson> ah right got it
[14:51] <pedronis> ijohnson: basically once fixed, the output would need to be embedded in systestkeys
[14:53] <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:54] <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:55] <jdstrand> ijohnson: np at all. have a nice rest of the day :)
[14:55] <jdstrand> amurray: you may be interested in ^
[14:56] <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:58] <pedronis> ijohnson: if we haven't grown something like it since, it might be worth adding dumpRSAKey to assertstest
[14:59] <ijohnson> pedronis: ack
[16:11] <pedronis> ijohnson: are unblocked on this?
[16:11] <ijohnson> sorry still in meetings
[16:14] <pedronis> sorry, my fault
[16:44] <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?
[17:02] <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:04] <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:14] <bandali> any thoughts/suggestions diddledan?
[17:15] <pstolowski> bandali: no. current symlinks should be updated when post-refresh hook runs
[17:15] <diddledan> the user-level ones aren't, pstolowski
[17:16] <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:17] <bandali> oh, dang.. my use case was adding a symlink in XDG_CONFIG_HOME/autostart/ to a desktop file somewhere in $SNAP/
[17:18] <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:20] <bandali> ohh okay cool that might work! thanks for the idea, i'll give that a shot
[19:05] <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:10] <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:16] <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:20] <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>
[20:40] <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)
[21:57] <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:58] <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:59] <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 :)
[22:00] <tianon> maybe there's a wishlist tracker somewhere this could be filed in? (or already is?) O:)
[22:02] <cjwatson> https://github.com/canonical-web-and-design/snapcraft.io/issues
[22:02] <cjwatson> I think
[22:03] <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:05] <tianon> searching those now, and I'll file something if I don't find anything; thanks :)
[22:24] <tianon> (ended up with https://github.com/canonical-web-and-design/snapcraft.io/issues/3408 for anyone curious or interested)