<andi->
don't most of us have a local copy of the tags?
<qyliss>
andi-: yes, but I'd like to know what happened to them
<qyliss>
can you go back in time further? If you have text search you could just look for any "ref_type":"tag", since I doubt there'll be many.
<qyliss>
(I'm assuming "tag" is the other ref_type, but since we haven't seen any I don't know for sure...)
<andi->
I have it in a postgresql JSON typed column.. let me see if I can search for strings in there...
<qyliss>
If it's jsonb I don't think you can.
<qyliss>
If it's literally the "json" type I think you can.
<andi->
it should be jsonb
<andi->
ok, what event types might also be the right ones?
<qyliss>
I think it'll definitely be a "delete" event, unless the docs are just lying.
<qyliss>
And I'm fairly sure it'll have data.ref_type != "branch"
<andi->
there are the types that I've received so far: issues, fork, commit_comment, create, status, pull_request_review, milestone, pull_request, pull_request_review_comment, ping, project_card, check_suite, repository_vulnerability_alert, label, project, check_run, push, delete, project_column, watch, star, issue_comment
<andi->
and yeah delete sound like the most promising one
<qyliss>
If there are no events for this that would make me wonder whether GitHub just lost our tags...
<andi->
or if they do not send deletes for tags..
<qyliss>
They say they do in their documentation.
<qyliss>
Oh wait I'm looking at the actions documentation
<qyliss>
I hope that's not different
<qyliss>
their webhook documentation 503s...
<andi->
A Git branch or tag is deleted. For more information, see the "Git data" REST API.
<andi->
Note: You will not receive a webhook for this event when you delete more than three tags at once.
<qyliss>
yeah I just saw
<qyliss>
hmm
<qyliss>
would still be good to check earlier just in case, but I'm assuming they were all deleted at once.
<andi->
I only started in december and didn't add any date restrictions in the last exports
<qyliss>
oh :(
<qyliss>
then I guess we're not going to find out what happened, unless anybody can think of anything else we could check.
pmy has joined #nixos-dev
<ekleog>
Anyone knows whether we have CI builders with nvidia GPUs? I know someone who did nvidia changes and would like to check things work not-on-their-machine, but I'm far from sure we actually have such hardware?
<qyliss>
Okay, I think we should just put the tags back
<qyliss>
Can I get a +1 from somebody to restore the tags from a local copy?
<qyliss>
cc primeos
pmy has quit [Quit: WeeChat 3.0]
<primeos>
qyliss: Sorry, I missed the initial notification. I have no idea what happened and why but I guess it can't/shouldn't hurt to restore them from a local clone.
pmy has joined #nixos-dev
<qyliss>
primeos: could you run git tag | while read tag; do echo "$(git rev-parse "$tag") $tag"; done and diff your output with https://paste.rs/Cwj?
<qyliss>
just to make sure I have the hashes right
<primeos>
The hashes match but some release tags are missing in your paste (e.g. 20.03 and all three tags for 20.09)
<qyliss>
they're coming from some other thing I've fetched
<qyliss>
ugh, this is why I wanted to check
<primeos>
qyliss: The second paste LGTM (all of the release tags and their revisions match) some of the other tags are missing on my clone or your paste but that's to be expected I guess
<primeos>
I guess only the release tags really matter anyway
<qyliss>
hmm, I'd like to restore them all
<qyliss>
but I can check against andi-'s repo and judge based on that
<qyliss>
okay, I'm going to fill in everything from andi-'s. I've checked all the release tags matched other things, for other I was missing I'm just going to trust andi-. It doesn't really matter since any of us can overwrite the tags at any time.
<asbachb>
Hi I try to introduce a new folder `thumbnailers` in `/run/current-system/sw/share/` to create a thumbnailer for raw files. Any suggestions where to start?
<qyliss>
It's weird that some other tags are still here
<qyliss>
but the release tags are all gone
<gchristensen>
wtf
<gchristensen>
uh qyliss I have suspicion
<gchristensen>
who pushed all these backups/ tags?
<{^_^}>
isaacs/github#1091 (by alecbz, 3 years ago, open): Locking/auditing for tags
<gchristensen>
lol.
<lukegb>
"maybe at some point eh"
<andi->
I wonder *why* that is such a different beast..
<asbachb>
Are you sure nobody with commit rights removed them by accident?
<qyliss>
asbachb: that's the most likely explanation
<gchristensen>
pretty sure somebody did
<gchristensen>
it'd be nice to know who and when, though!
<qyliss>
what we're wondering is why GitHub didn't tell us
<asbachb>
I see.
<tilpner>
This is a good example for the next time someone claims granular git permissions (see gitolite) are unnecessary
srk has quit [Ping timeout: 240 seconds]
<gchristensen>
this could be a nice thing for github to do actually as a extra service on top of git: github providing attesting to a tag never being manipulated
<qyliss>
we should sign our tags
<tilpner>
But that doesn't prevent them from being removed
<qyliss>
it does make sure the right ones get put back though
<gchristensen>
well, yeah, that only makes sense if they also prevent removal :P
<gchristensen>
I'm assuming competent product leadership there, which I know isn't a reasonable expectation anymore
<qyliss>
tilpner: chmod -w refs/tags :P
<tilpner>
I see no reason (other than product segmentation or perhaps UI design) to keep the permissions system as coarse as it is right now
<tilpner>
Even restricting people to only be able to push to specific subtrees is obiously useful to many projects, and... supported only by gitolite?
srk has joined #nixos-dev
<tilpner>
qyliss: Hah, but you know I meant an ACL that wasn't universal :)
<qyliss>
you can even ban tag deletion: chown +s refs/tags
<qyliss>
oh but that would let you delete tags you created
<qyliss>
I need to think about this longer :P
<qyliss>
probably have to get chattr involved
<lukegb>
asbachb: heh, I linked that above :o)
<asbachb>
I'm so slow...
thibm has quit [Ping timeout: 272 seconds]
thibm has joined #nixos-dev
<gchristensen>
no worries, asbachb, I appreciate your being here
<lukegb>
^
<lukegb>
Wasn't really meant as a slight on you :p
<lukegb>
(I was expecting people to miss it anyway because putting two links one after the other is usually basically invisible)
<qyliss>
gchristensen: {^_^} just reported some tag deletions in #nixos
<gchristensen>
iiinteresting
<andi->
qyliss: ref_type is indeed 'tag' for these
<andi->
Where those three tags deleted via the website?
<gchristensen>
I doubt it: exact same timestamp, and immediately prior to a PR opening
<andi->
a PR from the very same person
<gchristensen>
exactly
<andi->
So I wonder how much we can trust the events then.
<qyliss>
i'm now repeatedly anxiously checking that the release tags haven't disappeared again.
<andi->
I really feels like some git client going mad.
<qyliss>
I had assumed those three tag deletions were just that person deleting tags they thought were no longer necessary (which tbf it does look like they are)
<qyliss>
will be interesting to see what they say
<qyliss>
The GitHub docs don't mention the 3 tag limit on the GH actions workflow for "delete"
<qyliss>
Maybe we should set one of those up
edwtjo has quit [Read error: Connection reset by peer]
thibm has quit [Quit: WeeChat 2.6]
edwtjo has joined #nixos-dev
edwtjo has quit [Changing host]
edwtjo has joined #nixos-dev
obadz has quit [Quit: WeeChat 3.0]
<lukegb>
Set up a GH action that just puts the tag back if you delete it :p
<gchristensen>
magit once erased my home directory
<qyliss>
o_O
<gchristensen>
and it was before I had my current thoughts of "that'd be good actually"
<qyliss>
lol
<gchristensen>
what happened is I accidentally opened magit then typed the sequence to git clean -dfx, but I was in my home directory and had at some point accidentally run `git init` in ~
* andi-
checks for a git repo in ~
<qyliss>
can't do that with a read-only home directory ;D
<andi->
I'd love to at least have ~ r/o with only a few exceptions exiting...
<qyliss>
you can manually create the exceptions
<etu>
I believe a tmpfs home would save you as well since it could only remove symlinks and should ignore other filesystems such as bind mounts?
<qyliss>
or let tmpfiles.d do it
<etu>
Unless git recurses into symlinks and mounts and remove files...
<andi->
The important bit is that my user shouldn't own the directory. No tmpfs hacks tha tremove files on reboot. They should simply never be allowed there.
<qyliss>
my user owns my home directory but its permissions are 0555
<qyliss>
which means I can temporarily chmod it if I want to create something in there without needing to sudo, which is quite convenient.
<gchristensen>
neat
rajivr has quit [Quit: Connection closed for inactivity]
asbachb has quit [Remote host closed the connection]
ris has quit [Read error: Connection reset by peer]
ris has joined #nixos-dev
asbachb has joined #nixos-dev
<asbachb>
Is anyone aware how the symlinks of `/var/run/current-system/sw/share/applications` are beeing created?
<symphorien[m]>
with pathsToLink = [ "/share/applications" ];
<symphorien[m]>
something in environment.systemPackages has $out/share/applications
<asbachb>
symphorien[m]: So every derivation which writes to $out/share/application is symlinked there?
<symphorien[m]>
only those in environment.systemPackages
<asbachb>
symphorien[m]: Thanks!
justanotheruser has joined #nixos-dev
cole-h has joined #nixos-dev
<sreybastien>
@marek hi, i see that you commit on the luksroot nix source code in the last past month, perhaps you could help me to find the bug or give me some hint to solve this issue ? I'm trying desperatly to use gpg-smartcard functionality from remote ssh connection at startup to unlock LUKS lvm