You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug(winegui): now fails CI test due to upstreamΒ #1699
They now have separate .deb files for each version of Debian and Ubuntu, instead of one deb for everything. That's easy enough to fix. (Although they don't have debs for Sid and Questing, the Forky and Plucky debs install fine in them, respectively.)
The other problem is that their server seems to be rejecting the connection when using wget. The same URL works fine in a browser.
Here's the result when I try to download the assets json manually:
EDIT: Their site is also not loading for me in Waterfox and Ungoogled Chromium. It also won't connect if I switch to a Private Window in Brave. This makes me think it won't be fixable on our end.
I block many data center due to their DDos behavior and other malicious bot activity. I notice you are trying to download deb files from a Microsoft GitHub workflow. I block most of Microsoft GitHub IPs, so that is why I'm not surprised you have issues here. Again, its not personal.
I will try to look into whether I can also publish the same files on GitHub for example, which will allow you to retrieve the files without issues that at point.
I recently migrated WineGUI to GTK4 indeed, which makes the project future proof (for at least the coming 10 years if not more), however this also comes with some limitations like very old distros will not support GTK4 out of the box.
During this migration to GTK4 I also improved the build processes - which was actually a must have - and compiling the code on specific debian and ubuntu based docker images, due to different GTK4 versions and other dependencies that wasn't an issue before in GTK3. Hence, I can not deliver a single deb file, even if I wish. That would fail hard on other distributions.
Ah yes.. and I block wget commands, but I got ddosed by them as well.. Maybe that was you all alone π ?
We could work around the blocking of GitHub breaking CI if end-users/maintainers weren't also blocked. Blocking wget is a bit of a show-stopper though. If you could publish releases on GitHub (or GitLab.org ) that would I hope be very helpful for us (and any WineGUI via deb-get).
Sorry you've had to deal with bad behaviour and ddos from bots. We try to have deb-get behave respectfully and sensibly so I'm confident the ddos-ing was not our users or our CI (or me alone!). π§―π₯
We try to have deb-get behave respectfully and sensibly so I'm confident the ddos-ing was not our users or our CI
I think if you would set a custom user-agent string, instead of the default wget that would already help to identify your tool better at reverse proxy level / fail2ban etc. By simply using --user-agent=deb-get/<version> parameter in this case.
But I will also look into publishing releases on GitHub if that is not too hard to-do and keep in sync with GitLab.
Sorry you've had to deal with bad behaviour and ddos from bots
Yeah, the internet isn't what it used to be too bad.
I now both release my build artifacts on my own server/GitLab like before, but I now also publish the same build artifacts on GitHub as well, see: https://github.com/winegui/WineGUI/releases (this will resolve your issue with the workflow for sure)
Activity
silentJET85 commentedon Feb 15, 2026
There seems to be two problems:
They now have separate .deb files for each version of Debian and Ubuntu, instead of one deb for everything. That's easy enough to fix. (Although they don't have debs for Sid and Questing, the Forky and Plucky debs install fine in them, respectively.)
The other problem is that their server seems to be rejecting the connection when using
wget. The same URL works fine in a browser.Here's the result when I try to download the assets json manually:
EDIT: Their site is also not loading for me in Waterfox and Ungoogled Chromium. It also won't connect if I switch to a Private Window in Brave. This makes me think it won't be fixable on our end.
philclifford commentedon Feb 18, 2026
the refusal seems to have been transient π€
Hopefully fixing up the new filenames (and setting the supported codenames) will be sufficient .
philclifford commentedon Feb 18, 2026
No - it's back :
melroy89 commentedon Feb 18, 2026
Hi. Its me, Melroy. The creator of WineGUI.
I will try to look into whether I can also publish the same files on GitHub for example, which will allow you to retrieve the files without issues that at point.
During this migration to GTK4 I also improved the build processes - which was actually a must have - and compiling the code on specific debian and ubuntu based docker images, due to different GTK4 versions and other dependencies that wasn't an issue before in GTK3. Hence, I can not deliver a single deb file, even if I wish. That would fail hard on other distributions.
Ah yes.. and I block
wgetcommands, but I got ddosed by them as well.. Maybe that was you all alone π ?philclifford commentedon Feb 18, 2026
Hi @melroy89 ! Thanks for the response.
We could work around the blocking of GitHub breaking CI if end-users/maintainers weren't also blocked. Blocking
wgetis a bit of a show-stopper though. If you could publish releases on GitHub (or GitLab.org ) that would I hope be very helpful for us (and any WineGUI viadeb-get).Sorry you've had to deal with bad behaviour and ddos from bots. We try to have
deb-getbehave respectfully and sensibly so I'm confident the ddos-ing was not our users or our CI (or me alone!). π§―π₯melroy89 commentedon Feb 18, 2026
I think if you would set a custom user-agent string, instead of the default
wgetthat would already help to identify your tool better at reverse proxy level / fail2ban etc. By simply using--user-agent=deb-get/<version>parameter in this case.But I will also look into publishing releases on GitHub if that is not too hard to-do and keep in sync with GitLab.
Yeah, the internet isn't what it used to be too bad.
melroy89 commentedon Feb 21, 2026
@philclifford got it working for you, here you go.
I now both release my build artifacts on my own server/GitLab like before, but I now also publish the same build artifacts on GitHub as well, see: https://github.com/winegui/WineGUI/releases (this will resolve your issue with the workflow for sure)
philclifford commentedon Feb 23, 2026
Many thanks @melroy89 - all sorted for us as soon as this is closed.
fix(winegui): adapt to upstream packaging changes (wimpysworld#1736)
fix(winegui): adapt to upstream packaging changes (wimpysworld#1736)
fix(winegui): adapt to upstream packaging changes (wimpysworld#1736)