<sad_plan>
wait, does codeberg not accept ssh keys as signingkeys?
<testuser[m]>
It does
<sad_plan>
hm. I just got an error when trying to add mine
<testuser[m]>
send
<sad_plan>
although I cant even get git to recognize them either tbh
<testuser[m]>
are u uploading private key to codeberg
<sad_plan>
no, public
<sad_plan>
error: No private key found for "/tmp/.git_signing_key_tmpbg4JMA"?
<sad_plan>
I have added my key to gitconfig though
<testuser[m]>
send
<testuser[m]>
I had the same but made wrong gitconfig
<testuser[m]>
Didn't u ask this like 2 weeks back
<sad_plan>
not directly. I tried to use dropbear with github, which works, but it cant sign commits. doesnt have that feature. mcf created a patch for signing, but not verifying.
<sad_plan>
mustve been messed up when trying to add the key
<sad_plan>
which of them is initially essential? only the global one?
<sad_plan>
I fixed it
<sad_plan>
now just try again to add the key to codeberg
fitrh has joined #kisslinux
<wael_>
codeberg more like
<wael_>
cantsearchbecausegitea
<sad_plan>
lol
<testuser[m]>
sad_plan: ill fix iproute2
<testuser[m]>
wireguard seems to work fine without iptables in iproute
<sad_plan>
nice
<sad_plan>
ffs, is the option to use ssh key as signing key some place else than in the ssh/gpg keys section? adding the ssh key to gpg section obviously dont work I mean
<sad_plan>
on codeberg
<sad_plan>
'Can not verify your GPG key: failed to parse gpg key openpgp: invalid argument: no armored data found' do I have to verify the ssh key?
GalaxyNova has quit [Remote host closed the connection]
<testuser[m]>
what
<sad_plan>
thats the error I get when trying to add the ssh keys to the gpg section
<sad_plan>
signing. theres no indication wether I can use ssh keys to sign. I now have it enabled in git, but codeberg wont recognize it, because its not added to codeberg
<testuser[m]>
then add it
<sad_plan>
I have added the ssh key there
<sad_plan>
but codeberg wont recognize it as a signing key. so itll just say unverified or w/e it says on codeberg when a commit is unsigned
<sad_plan>
no I tried that, but it errors out on ssh-askpass not existing. then incorrect pasphrase supplied, but it never prompts, because ssh_askpass isnt found
<phoebos>
sad_plan: you might find it helps to ssh-add your key
<sad_plan>
thought I did that already
<sad_plan>
oh, so noooow it worked
<sad_plan>
ok, so the ssh key is verified now, but this doesnt really solve the ssh key for signing
* sad_plan
sighs
<testuser[m]>
hmm b3 change broke a lot of stuff in etcsums
<testuser[m]>
it doesnt save file as *.new if it already exists if pkg was never installed, and saves files as *.new if they never existed before
<testuser[m]>
but it didnt change any of that code
<sad_plan>
I was wondering when that patch was going into a new release, but I suppose I got my answer :p not yet
<sad_plan>
just run the scripts from top to bottom you mean?
<testuser[m]>
wat
<sad_plan>
isnt that what you ment? *testing*
<testuser[m]>
automated tests
<testuser[m]>
yeah
<phoebos>
testuser[m]: nice find. i noticed that when we were testing tar perms
rohan has joined #kisslinux
<testuser[m]>
phoebos for fixing etcsums do I remove the reversal from tar generation itself so that broken sums never make their way into system or re-reverse / unreverse them as needed in other places?
<testuser[m]>
i think first is OK cuz u can't break what's already broken
<testuser[m]>
it also needs to handle files being skipped from checksum generation eg /etc/sv/*/supervise files
<testuser[m]>
otherwise it compares more entries than exist in etcsums which again breaks everything
<illiliti>
first is better
<phoebos>
yes first sounds better
<phoebos>
how do you identify broken sums?
<testuser[m]>
wc -l etcsums > 1
<phoebos>
ah
<testuser[m]>
phoebos: test -h vs test -L
<testuser[m]>
their descriptions are character for character same
<testuser[m]>
sus
<illiliti>
-h is preferred
<testuser[m]>
any reason
<illiliti>
openbsd man page says so
<illiliti>
freebsd says otherwise
<illiliti>
bruh
<testuser[m]>
lol
sad_plan has quit [Quit: nyaa~]
<testuser[m]>
illiliti: phoebos any idea about solving issue of symlinks in /etc
<testuser[m]>
i thought of just checking -h but that doesn't work for removal if user modifies that file to not be a symlink
<testuser[m]>
other way is just to echo dummy value for that file in checksums
<testuser[m]>
like SYMLINK
<illiliti>
no need to be too smart
<illiliti>
if user modifies something, that's their problem
<illiliti>
handle basic case
<testuser[m]>
so just -h check
<phoebos>
we target posix, -h and -L are equivalent
<testuser[m]>
also this seems like a valid bug to me since it has a cascading effect on all other entries, maybe we could just add something like hash of /dev/null in place of all symlink files? That way there's no chance for mismatch of no. of entries and no.of files checked so at most only symlinks will be broken. Also easier than adding -h checks to 3-4 places
<testuser[m]>
adding special value like "SYMLINK" would need adhoc logic in b3() itself which is bad
<testuser[m]>
btw what damage do charset.alias and .la files cause that they're hardcoded to be removed in KISS?
<testuser[m]>
oh > Remove this unneeded file from all packages as it is an endless source of conflicts. This is used with info pages we we do not support.
<illiliti>
dylan said that fix requires refactoring of pkg_remove_files
<illiliti>
which i think the proper option
<testuser[m]>
we can do that later ig, i'd be wary of modifying anything greater than 2 lines without adding some tests
<testuser[m]>
lot of stuff needs to be refactored like even removal of existing files in etcsums (removing f2 from f1 f2 f3 in /etc)
<macslash1[m]>
qwhta
<testuser[m]>
why is there no tar library for C other than libarchive :bruh: