https://bugs.winehq.org/show_bug.cgi?id=42735
Bug ID: 42735 Summary: Add Debian testing WineHQ repository Product: Packaging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-packages Assignee: wine-bugs@winehq.org Reporter: shtetldik@gmail.com CC: michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Currently, Wine HQ debian repo provides named repositories for: wheezy, jessie, stretch, sid. See https://dl.winehq.org/wine-builds/debian/dists/
Please add one for "testing", so users of Debian testing wouldn't need to refer to specific named releases.
Wine staging Debian repo used to do that, but now it's being deprecated.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #1 from Shmerl shtetldik@gmail.com --- See staging repo example: https://repos.wine-staging.com/debian/dists/
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #2 from Michael Müller michael@fds-team.de --- This is already implemented in the new build server and will automatically be fixed when we push the next release builds.
https://bugs.winehq.org/show_bug.cgi?id=42735
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jnewman@codeweavers.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #3 from Michael Müller michael@fds-team.de --- After the syncing the release, the symlinks are in place, but the CDN returns 403 when accessing them. Example:
http://dl.winehq.org/wine-builds/debian/dists/testing/
This seems to be configuration issue of the CDN or webserver. The symlinks are relative and point to the correct directory, so I can not explain why this should cause a 403 error. The target of the symlink can be accessed without problems:
http://dl.winehq.org/wine-builds/debian/dists/stretch/?flush_cache
I don't have any permissions to change the configuration, so CCing Jeremy Newman.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #4 from Shmerl shtetldik@gmail.com --- Did anyone manage to figure out what's wrong?
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #5 from Michael Müller michael@fds-team.de --- No answer from Jeremy so far. I don't have access to the webserver / cdn configuration and can only recommend to use the original source server https://repos.wine-staging.com/wine/ as a workaround.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #6 from Shmerl shtetldik@gmail.com --- It's not a big deal, I just use "stretch" for now, but would be nice to avoid changing that name, and just use "testing" for instance.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #7 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Shmerl from comment #6)
It's not a big deal, I just use "stretch" for now, but would be nice to avoid changing that name, and just use "testing" for instance.
If you are using "testing" for the rest of your system, you will have to switch to "buster" to ensure you get compatible Wine packages. Stretch is now stable.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #8 from Shmerl shtetldik@gmail.com --- Yep, I actually just did.
https://bugs.winehq.org/show_bug.cgi?id=42735
Jeremy Newman jnewman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #9 from Jeremy Newman jnewman@codeweavers.com --- Fixed. The vserver in apache was previously not setup to follow symbolic links.
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #10 from Shmerl shtetldik@gmail.com --- For some reason, when I set in sources:
deb https://dl.winehq.org/wine-builds/debian/ testing main
apt-get update && apt-get dist-upgrade didn't find any updates to recent wine staging package (wine-staging-amd64 2.12.0~buster). But when I changed it to
deb https://dl.winehq.org/wine-builds/debian/ buster main
It worked. I suppose symlink alone isn't enough to make it work?
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #11 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Shmerl from comment #10)
It worked. I suppose symlink alone isn't enough to make it work?
I fear the new problem is related to the CDN cache. The cache is only updated when a new version is pushed, but unfortunately those paths containing a symlink are not properly invalidated. :/ Jeremy, do you have an idea how to fix this?
https://bugs.winehq.org/show_bug.cgi?id=42735
--- Comment #12 from Jeremy Newman jnewman@codeweavers.com --- We use inotifywait to watch the directory and when a file is updated, it requests a purge of the CDN for that file. Unfortunately, inotifywait DOES not transverse symbolic links, so it will not request a purge of anything in that dir.
We could possibly hack the script, and add a manual list of directories that are known symbolic links, but then it would need to be updated every time there is a new release of Debian/Ubuntu.
I'm open to suggestions, but all I can think of currently is for you to not use symbolic links and make full copies of the structure.
https://bugs.winehq.org/show_bug.cgi?id=42735
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Rosanne DiMesio dimesio@earthlink.net --- Closing fixed packaging bug.
-
wine-bugs＠winehq.org