add package to void repo

[kzkin]

Why not add this package to one of the void repositories ?

[DAINRA]

Because they don't accept browser forks (you can search their github page for past requests of browsers like ungoogled-chromium or brave).

[uuuvn]

@DAINRA @kzkin maybe close issue?

[DAINRA]

Doesn't bother me too much if it's left open, but since it's been around 30 days and there is nothing more to add I'll close it.

[siduck]

@DAINRA would it be possible to make a custom repo for this? this pkg gets frequently updated so it would be nice to have a custom repo and it'd be easy to update :D

example of a custom repo https://github.com/DBLouis/void-linux-liquorix

[KF-Art]

We, at Cereus Linux team (Void derivative), would be happy to maintain the package at our cereus-extra repository (which is like a Chaotic VUR), intended for use on any Void-based distribution (and Void itself, of course).

[siduck]

oh cool! btw @KF-Art what is the storage limit at source forge?

[KF-Art]

oh cool! btw @KF-Art what is the storage limit at source forge?

It seems that SourceForge does not have a storage limit per project. Per file, I remember the limit was around 2GB (not sure).

We are mirroring to OSDN too, which also does not have a limit for project and per-file size limit is 4.7GB. We currently package some browsers like Waterfox, LibreWolf and Brave (in *-bin format, of course), so I think it would be no problem mantaining Ungoogled Chromium too.

[DAINRA]

A few notes:

• @siduck While that is one way of doing it, it's also a terrible way to do it since it would require a second repository and some workarounds.
• The second option would be to use the existing releases and add a step for signatures and repo data, though I'll have to do a test when I have some time since the "static" links for the latest release do some redirecting and I'm not sure xbps handles that.
• The third option would be what @KF-Art suggested. Now I'm not an expert on xbps and how the signing works, but if I understand it correctly even if @KF-Art signs the files with their key the archive itself should still be untouched (meaning the sha sums provided by the workflow at build time should still be valid).

[siduck]

@DAINRA i think you can do it in this repo itself

[KF-Art]

Yes, that's correct. XBPS handles separatedly both SHA256 checksum of the package and repository signing. So, using the binaries of the releases and signing them is doable.

[DAINRA]

@siduck There is a bigger discussion to be had about that approach, but the main points: it would force the people (there are quite a few that prefer building for themselves) to download the binaries instead of just the source template, it would also force 2 commits per release (one for building one for the actual files). Besides that there is also the problem of file limits (releases have a 2gb/file limit while repository files are only 100mb) and while it's not there yet it will be a problem in the future.

Anyway from the test I did in another repository it looks like the releases page will work fine if the needed files are added.

[siduck]

oh nvm it then @DAINRA,btw how do i know if through a script if the release has a new update? idk much scripting but i would like to download & install new releases by a script

[DAINRA]

curl https://api.github.com/repos/DAINRA/ungoogled-chromium-void/releases/latest gives the release info in json format

[siduck]

curl https://api.github.com/repos/DAINRA/ungoogled-chromium-void/releases/latest gives the release info in json format

thx a lot!

[siduck]

@DAINRA

ERROR: [reposync] failed to fetch file `https://github.com/DAINRA/ungoogled-chromium-void/releases/latest/download/x86_64-repodata': Not Found

you need to have the repodata too i think

[DAINRA]

Workflow in progress >.>

Edit: It's going to take a while because it's partly rebuilding the cache (from 105.0.5195.52 to 105.0.5195.102).

[siduck]

oh why would the CI take this much time

[siduck]

Oh nvm I forgot chromium was building :joy:

I can sleep in the meantime :sleeping: