GitHub Actions builds in winget

[networkException]

I think it would be good to have the automated releases from this repository on winget, let me know what you think and if thats something you are willing to maintain

[teeminus]

I like the idea. Can this be automated as well?

[networkException]

Looks like it: https://github.com/microsoft/winget-pkgs/issues/1515

[teeminus]

Looks like we setup it up once and it works automatically.

[tomasz1986]

Are the releases from this repository going to be linked to from https://ungoogled-software.github.io/ungoogled-chromium-binaries as well?

[Nifury]

But there is already a winchrome's build on winget. https://github.com/microsoft/winget-pkgs/blob/4696b9dc18a5b8cc0eca4923f0034e9759b7efce/manifests/e/eloston/ungoogled-chromium/102.0.5005.63/eloston.ungoogled-chromium.locale.en-US.yaml

Is it necessary to push releases from this repo to winget, and if so, how are we going to name the package?

[tomasz1986]

But there is already a winchrome's build on winget.

Yeah, but it's not done through GitHub actions (so it can't be verified in terms of trust), and it's also limited to Win64 only.

[networkException]

But there is already a winchrome's build on winget.

I would be in favor of replacing winchrome builds for future versions of eloston.ungoogled-chromium.

Third party binaries being advertised as eloston. is quite problematic in my opinion and I'd like to reduce the possibilities of malicious actors to infect users with malware as much as possible.

---

This is all part of a greater discussion about authenticity and how happy people are with using binaries from specific sources (see https://github.com/ungoogled-software/ungoogled-chromium/issues/1549)

I draw the line of acceptable prebuilt packages that we can publish between user submitted and CI generated with public logs on "well known" infrastructure. Other team members and users will probably draw the line somewhere else

[teeminus]

When I started looking of an alternative to the chrome based browser I used before I stumbled across the mentioned binary release as well. When I dug into I found it's just a binary release which no source provided which made we wonder, because that repos was up to date while this repo was way behind. That's what initially lead to updating and compiling this repo myself.

I'm with @networkException. Having binary releases floating around with no build instructions and source present while referencing the ungoogled-chromium repo is problematic. I don't say the winchrome release is not trustworthy but on the other hand, there is no information available on how these binaries are build, which flags, patches, etc. are used.

Having an "official" ungoogled-chromium-windows release with a transparent code-, patch- and tool-base as well as a transparent build and release process makes totally sense to me. We made great progress in automating the build and release process and publishing the releases elsewhere to increase the availability seems like the next logical step to me.

[redstreet]

There is now a winget releaser in the github Actions marketplace. Wouldn't it be very simple to get ungoogled-chromium-windows to use this?

This would fix the fact that the latest releases are not in winget, right?

[networkException]

Well I don't like that action pulling a powershell script from main even on tagged releases but in principle we'd use something like that yes

[redstreet]

I see. I can't say I know anything at all about the implications of powershell scripts to understand. I'm sure you thought of it, but couldn't that marketplace action be modified to fit what is needed?

Or is this just a matter of writing a small python script or such to produce the yaml files that winget seems to require?

Anyway, I don't know what is required to make this happen, and I don't personally have experience around Windows to contribute (if that is needed), but I certainly hope ungoogled-chromium soon gets to having automated winget updates! It would be very valuable since there is no official update mechanism so far.

[networkException]

Yea we might just fork it.

@Nifury do you want to take a look at that? I'd happily do it as well but as the author you have more experience with the Windows workflows.

If you want to have a fork of that action in the organisation or need some other permission just tell me

[Nifury]

Sure, just leave it to me.

[Nifury]

I think I'm going to submit a PR manually to include both x86 and x64 installers, and the subsequent update can be done via wingetcreate.exe update --urls <x86_installer> <x64_installer> eloston.ungoogled-chromium.

@networkException Yeah we need a PAT to create a pull request in the winget repository.

[networkException]

I think I'm going to submit a PR manually

sounds good

Yeah we need a PAT to create a pull request in the winget repository.

Oh I see. I think it would be good to have to fork in ungoogled-software, sadly GitHub doesn't allow limiting them to specific repositories. Do you want to use a token linked to your account? Should I create a new account for this?

[teeminus]

I am not sure if you already thought about it, but we should use a winget path like eloston.ungoogled-chromium-windows or eloston.ungoogled-chromium.ungoogled-chromium-windows.

[networkException]

why that? I think it would be better to just update the existing package

[teeminus]

Can we update an existing path? Don't we need a kind of key to authenticate in order to publish our release? And don't we risk getting our release to be overwritten by the other author?

[networkException]

Can we update an existing path? Don't we need a kind of key to authenticate in order to publish our release?

I believe we only require approval from one of the maintainers

And don't we risk getting our release to be overwritten by the other author?

The previous maintainer hasn't submitted a new version since 102. Since then a different user has actually updated to 103 with the GitHub Action binaries https://github.com/microsoft/winget-pkgs/blob/11c87363b08b6167a9c5a372090754a83c8a047d/manifests/e/eloston/ungoogled-chromium/103.0.5060.53/eloston.ungoogled-chromium.installer.yaml#L24

[teeminus]

Okay. There is a mistake in the file linked, there are two x64 binaries listed.

[networkException]

Its the same binary with different install scopes

[Nifury]

Do you want to use a token linked to your account? Should I create a new account for this?

I'm fine with either, but creating a new account is probably a better option. I don't have access to add my token to environment secrets.

[networkException]

well those permissions can be adjusted

i guess an actual maintainer account would also have its advantages

[Nifury]

What should we do with revision? winget-pkgs doesn't have a revision number at the end.

[networkException]

I guess we could add .1.1 or something

It's not obvious to me how winget determines the latest version but as long as we don't break that mechanism adding more segments is fine

[redstreet]

This is awesome! Thank you for adding this!

[redstreet]

I assume this link is correct, right? https://winstall.app/apps/eloston.ungoogled-chromium

Specifically, is the package name below correct?

winget install --id=eloston.ungoogled-chromium  -e

If so, it'd be great if this could be added to the main README.md. This advertises installation via winget, while ensuring that the package name is correct (which lets users avoid installing similarly named packages in the future).

[networkException]

I added a simple install command for now, in the future I want to look at unifying the README layout across packaging repos