Release download not accessible #1193

Open
opened 2026-03-01 12:05:46 +01:00 by vincenzo · 12 comments

Up to 0.7 there is a valid link at e.g. https://codeberg.org/dwl/dwl/releases/download/v0.7/dwl-v0.7.tar.gz to download the code. For 0.8 this link is not anymore available. Could you please have a look?

The link should look like: https://codeberg.org/dwl/dwl/releases/download/v0.8/dwl-v0.8.tar.gz but it says not found.

I require it to update the Arch package on AUR.

Thanks!

Up to 0.7 there is a valid link at e.g. https://codeberg.org/dwl/dwl/releases/download/v0.7/dwl-v0.7.tar.gz to download the code. For 0.8 this link is not anymore available. Could you please have a look? The link should look like: https://codeberg.org/dwl/dwl/releases/download/v0.8/dwl-v0.8.tar.gz but it says not found. I require it to update the Arch package on AUR. Thanks!
Owner

I am answering from a phone and cannot take care of this right now, but I will have it corrected today.

Thank you for bringing this issue to light.

I am answering from a phone and cannot take care of this right now, but I will have it corrected today. Thank you for bringing this issue to light.
Owner

@vincenzo The expected release link is now present.

Because this issue is likely to come up again and I had to muddle through quite a bit to figure out just what and why @sevz had done with previous releases, I am recording here so that I might have less struggle with the same matter in the future:

The automatically generated .zip (https://codeberg.org/dwl/dwl/archive/vX.Y.zip) and .tar.gz (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) are from the point when the release is originally created (HEAD of the referenced branch at the time of the release). If additional commits are made to that branch, the auto-generated tarball is not updated. To account for this, we manually edit the release and use the Drop files or click here to upload button to add a manually generated .tar.gz with the updated source. Immediately following a new release, the auto-generated and the manually generated .tar.gz (which I did not create until @vincenzo generated this issue) should be identical.

@vincenzo The expected release link is now present. Because this issue is likely to come up again and I had to muddle through quite a bit to figure out just what and why @sevz had done with previous releases, I am recording here so that I might have less struggle with the same matter in the future: The automatically generated .zip (https://codeberg.org/dwl/dwl/archive/vX.Y.zip) and .tar.gz (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) are from the point when the release is originally created (HEAD of the referenced branch at the time of the release). If additional commits are made to that branch, the auto-generated tarball is not updated. To account for this, we manually edit the release and use the `Drop files or click here to upload` button to add a manually generated .tar.gz with the updated source. Immediately following a new release, the auto-generated and the manually generated .tar.gz (which I did not create until @vincenzo generated this issue) should be identical.
Contributor

@fauxmight The link for v0.8 is now reachable at https://codeberg.org/dwl/dwl/releases/download/v0.8/dwl-v0.8.tar.gz however, it unpacks to the directory named "dwl" where v0.7 unpacks to dwl-version (dwl-v0.7).

I came across this when going to update the gentoo ebuild. We can change the gentoo ebuild to work with this but I don't know if this affects other distros build systems.

#> tar -tf dwl-v0.7.tar.gz 
dwl-v0.7/
dwl-v0.7/LICENSE
dwl-v0.7/LICENSE.dwm
dwl-v0.7/LICENSE.sway
dwl-v0.7/LICENSE.tinywl

#> tar -tf dwl-v0.8.tar.gz 
dwl/
dwl/LICENSE
dwl/LICENSE.dwm
dwl/LICENSE.sway
@fauxmight The link for v0.8 is now reachable at https://codeberg.org/dwl/dwl/releases/download/v0.8/dwl-v0.8.tar.gz however, it unpacks to the directory named "dwl" where v0.7 unpacks to dwl-version (dwl-v0.7). I came across this when going to update the gentoo ebuild. We can change the gentoo ebuild to work with this but I don't know if this affects other distros build systems. ``` #> tar -tf dwl-v0.7.tar.gz dwl-v0.7/ dwl-v0.7/LICENSE dwl-v0.7/LICENSE.dwm dwl-v0.7/LICENSE.sway dwl-v0.7/LICENSE.tinywl #> tar -tf dwl-v0.8.tar.gz dwl/ dwl/LICENSE dwl/LICENSE.dwm dwl/LICENSE.sway ```
Author

@fauxmight @fictitiousexistence since it affects multiple distros I propose we keep the pattern aligned with the past. Otherwise we need to make an exception.

e.g. dwl-v0.8.tar.gz decompresses in dwl-v0.8/

@fauxmight @fictitiousexistence since it affects multiple distros I propose we keep the pattern aligned with the past. Otherwise we need to make an exception. e.g. dwl-v0.8.tar.gz decompresses in dwl-v0.8/
vincenzo reopened this issue 2026-03-02 17:36:55 +01:00
Owner

If additional commits are made to that branch, the auto-generated tarball is not updated. To account for this, we manually edit the release and use the Drop files or click here to upload button to add a manually generated .tar.gz with the updated source.

This doesn't sound right to me. Releases shouldn't really be modified. If new commits are added, a minor release should be published. I believe this is how sevz envisioned it with 0.7. But it never happened since he left before there could be a minor release made with the new commits.

> If additional commits are made to that branch, the auto-generated tarball is not updated. To account for this, we manually edit the release and use the Drop files or click here to upload button to add a manually generated .tar.gz with the updated source. This doesn't sound right to me. Releases shouldn't really be modified. If new commits are added, a minor release should be published. I believe this is how sevz envisioned it with 0.7. But it never happened since he left before there could be a minor release made with the new commits.
Owner

@vincenzo and @fictitiousexistence Thank you both for your work packaging dwl for your respective distributions. The tarball is updated in the manner requested.

@Rutherther I have no argument with you regarding what "should be." My description above is my best interpretation of how things have been done for releases prior to this. This issue (#1193) is a request to align with the style expected based on those earlier releases.

If releases cease to be modified, and point releases are made instead (I agree, this is a better way forward), then the manually created tarballs will have no need to be created. The automatically created tarballs (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) will be perfectly usable for each future release. Yes, this will require a one-time change to the source links for distribution packaging, but I can see no significant downside to this pattern for future releases. @thanatos? Any objection?

@vincenzo and @fictitiousexistence Thank you both for your work packaging `dwl` for your respective distributions. The tarball is updated in the manner requested. @Rutherther I have no argument with you regarding what "should be." My description above is my best interpretation of how things have been done for releases prior to this. This issue (#1193) is a request to align with the style expected based on those earlier releases. If releases cease to be modified, and point releases are made instead (I agree, this is a better way forward), then the manually created tarballs will have no need to be created. The automatically created tarballs (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) will be perfectly usable for each future release. Yes, this will require a one-time change to the source links for distribution packaging, but I can see no significant downside to this pattern for future releases. @thanatos? Any objection?
Owner

Summary of the above: yes, the old way is not good. Point releases with auto-generated tarballs are the right way rather than repeatedly modifying manually created tarballs and strapping those to releases. However, packagers are asking us for consistency. If we are changing and asking them to change with us, let's be sure that we will be consistent as we move forward.

Summary of the above: yes, the old way is not good. Point releases with auto-generated tarballs are the right way rather than repeatedly modifying manually created tarballs and strapping those to releases. However, packagers are asking us for consistency. If we are changing and asking them to change with us, let's be sure that we will be consistent as we move forward.
Owner

@fauxmight wrote in #1193 (comment):

Summary of the above: yes, the old way is not good. Point releases with auto-generated tarballs are the right way rather than repeatedly modifying manually created tarballs and strapping those to releases. However, packagers are asking us for consistency. If we are changing and asking them to change with us, let's be sure that we will be consistent as we move forward.

It seems to me there is a misunderstanding. I wasnt addressing the manual generation of the tarballs, but the fact that they are updated with additional commits. I cannot say if previously this has ever been done with dwl, I dont have any data that would say that releases were bumped to a different commit. And it seems strange to me it would be the policy. Bumping tags is an antipattern imo and even more of and antipattern would be making tarballs for release that arent for the tag commit.

@fauxmight wrote in https://codeberg.org/dwl/dwl/issues/1193#issuecomment-11161472: > Summary of the above: yes, the old way is not good. Point releases with auto-generated tarballs are the right way rather than repeatedly modifying manually created tarballs and strapping those to releases. However, packagers are asking us for consistency. If we are changing and asking them to change with us, let's be sure that we will be consistent as we move forward. It seems to me there is a misunderstanding. I wasnt addressing the manual generation of the tarballs, but the fact that they are updated with additional commits. I cannot say if previously this has ever been done with dwl, I dont have any data that would say that releases were bumped to a different commit. And it seems strange to me it would be the policy. Bumping tags is an antipattern imo and even more of and antipattern would be making tarballs for release that arent for the tag commit.
Owner

@fauxmight wrote in #1193 (comment):

@vincenzo and @fictitiousexistence Thank you both for your work packaging dwl for your respective distributions. The tarball is updated in the manner requested.

@Rutherther I have no argument with you regarding what "should be." My description above is my best interpretation of how things have been done for releases prior to this. This issue (#1193) is a request to align with the style expected based on those earlier releases.

If releases cease to be modified, and point releases are made instead (I agree, this is a better way forward), then the manually created tarballs will have no need to be created. The automatically created tarballs (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) will be perfectly usable for each future release. Yes, this will require a one-time change to the source links for distribution packaging, but I can see no significant downside to this pattern for future releases. @thanatos? Any objection?

None from me, I’m surprised it wasn’t done that way prior for the downloads. For @Rutherther’s concern, I think @fauxmight was referring to commits being pulled into the version’s branch rather than tags being moved. That was only done because main was chasing wlroots git, so fixes needed to be backported, and there’s no reason we would need to do that now.

@fauxmight wrote in https://codeberg.org/dwl/dwl/issues/1193#issuecomment-11152244: > @vincenzo and @fictitiousexistence Thank you both for your work packaging `dwl` for your respective distributions. The tarball is updated in the manner requested. > > @Rutherther I have no argument with you regarding what "should be." My description above is my best interpretation of how things have been done for releases prior to this. This issue (#1193) is a request to align with the style expected based on those earlier releases. > > If releases cease to be modified, and point releases are made instead (I agree, this is a better way forward), then the manually created tarballs will have no need to be created. The automatically created tarballs (https://codeberg.org/dwl/dwl/archive/vX.Y.tar.gz) will be perfectly usable for each future release. Yes, this will require a one-time change to the source links for distribution packaging, but I can see no significant downside to this pattern for future releases. @thanatos? Any objection? None from me, I’m surprised it wasn’t done that way prior for the downloads. For @Rutherther’s concern, I think @fauxmight was referring to commits being pulled into the version’s branch rather than tags being moved. That was only done because main was chasing wlroots git, so fixes needed to be backported, and there’s no reason we would need to do that now.
Author

Having a new version every time we add patches is fine for the distros as far as we do not change the download link: https://codeberg.org/dwl/dwl/releases/download/v{ver}/dwl-v{ver}.tar.gz and the name of the decompressed directory.

Having a new version every time we add patches is fine for the distros as far as we do not change the download link: https://codeberg.org/dwl/dwl/releases/download/v{ver}/dwl-v{ver}.tar.gz and the name of the decompressed directory.
Contributor

I'm not completely familiar with this but if the release tarballs can be modified later but the autogenerated archive ones cannot then I would assume the archive link is what I would want to use?
I believe the XZ backdoor issue in 2024 was due to releases being modified but not the git commits.

@fauxmight moving forward the autogenerated archives will unpack to dwl-vX.X.X>?

I'm not completely familiar with this but if the release tarballs can be modified later but the autogenerated archive ones cannot then I would assume the archive link is what I would want to use? I believe the XZ backdoor issue in 2024 was due to releases being modified but not the git commits. @fauxmight moving forward the autogenerated archives will unpack to `dwl-vX.X.X>`?
Owner

For @Rutherther’s concern, I think @fauxmight was referring to commits being pulled into the version’s branch rather than tags being moved.

Exactly and in that case a minor version is made. Not the tarball of already released version, corresponding to the tag changed.

> For @Rutherther’s concern, I think @fauxmight was referring to commits being pulled into the version’s branch rather than tags being moved. Exactly and in that case a minor version is made. Not the tarball of already released version, corresponding to the tag changed.
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
dwl/dwl#1193
No description provided.