coldtobi

Since yesterday-ish, darkradiant is also available in bullseye-backports, so after enabling backports it can be installed with apt install -t bullseye-backports darkradiant

FWIIW: I've uploaded darkradiant 3.4.0 to bullseye-backports, so you can now install it from there.

I'm getting this while trying to package for Debian: CMake Error at cmake_install.cmake:554 (file): file INSTALL cannot find "/build/darkradiant-3.4.0/obj-x86_64-linux-gnu/install/bitmaps/darkradiant_icon_64x64.png": No such file or directory. I'm currently preparing a patch, will make a PR soon. PR: https://github.com/codereader/DarkRadiant/pull/31

nice! Lets see if/how that works Yes, it would be odd to get the sources from a PPA instead of directly… Aslo, uscan(1), the tool responsible to import new upstream tarballs only can verify detached gpg signatures, not taking them from .dsc, that won't help in that part…

I agree, you should be free to use .gitattributes and it should not be the problem; If a generated tarball has the same content everything will be fine… Best thing would be if those .git files where not part of the tarball… No idea as well if github would be doing the right thing if utilizing export-ignore. One thing that might work is to re-normalize the git repo before doing a release: (requires * text=auto in .gitattributes) $ git add --renormalize . $ git status # Show files that will be normalized $ git commit -m "Introduce end-of-line normalization" (Stolen from https://git-scm.com/docs/gitattributes) Another approach could be to make the release tarballs manually, (and possibly also GPG sign them afterwards to ensure that supply chain attacks can not happen -- Debian would appreciate a GPG signature, but I digress) I'd like to avoid creating "upstream" tarballs, as it is recommendation within Debian to use the upstream tarball unmodified when ever possible; (even if there is no GPG signature to break…) (Said that, I found a quite simple workaround to fix the problem locally for me, so I could also live with the status quo. Version 3.0.0 is almost ready to be uploaded to Debia ) Cheers, tobi

Hi greebo, thanks for the new release. I finally had time to look into packaging it for Debian (sorry for the delay) and I have a issue with the tarball: The tarball includes ".gitattributes" which has the line * text=auto As the Debian packaging happens inside a git repo as well, this causes the file darkradiant/install/scripts/commands/count_loot.py to change line endings, which then makes the Debian toolchain to believe that there are changes where they should not be: dpkg-source: info: local changes detected, the modified files are: darkradiant/install/scripts/commands/count_loot.py dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/darkradiant_3.0.0-1.diff.385Qey This complicates the work on the packaging a lot, as git is becoming in the way and no way to convince git to restore to the format as in the tarball, except to extract the file from the tarball again. I can work around this issue locally, so no need to do a release for that, but for future releases I'd appreciate if that could be fixed for future releases, for example by NOT shipping the .gitattributes file in the tarball, making sure that the tarball has the bit-for-bit identical files (by normalizing before releasing (https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings) or making sure that line endings are OK at the time of push/commit (maybe using some git hooks) -- disclaimer: did not research if that is possible/feasible… Thanks for considering! -- tobi

Sorry, I'm not involved in Mint development (/me Debian Developer) But what you can try, as Mint is Ubuntu based and Ubuntu is Debian based, to rebuild the package locally on your machine: # Disclaimer: not tested, typed out of memory. sudo apt install devscripts # not sure if this package exists in mint, but this will allow you to verify the signature on the sources sudo apt install debian-keyring mkdir darkradiant_builddir cd darkradiant_builddir dget -x https://deb.debian.org/debian/pool/main/d/darkradiant/darkradiant_2.11.0-1.dsc # if you could not install debian-keyring, you can skip dget(1)'s signature verification with -ux , e.g # dget -ux https://deb.debian.org/debian/pool/main/d/darkradiant/darkradiant_2.11.0-1.dsc cd darkradiant* # this makes a pseudo-package depending on the build dependencies and installs it sudo mk-build-deps -i -r sudo apt install -f # ensure that once Mint has 2.11, the package from Mint will be installed: dch --bpo "Local backport." # This command starts the bulding of the pacakge: dpkg-buildpackage -b --no-sign # if that worked, you should have some nice debs in the parent directory ready to be installed. # debi(1) can help you with that ;) sudo debi --with-depends darkradiant darkradiant-plugins-darkmod One problem you might run into: If it cannot install debhelper-compat = 13 as Dependency, you might need to reduce compatiblity level. (Chances are good that it will also compile on lower compat level.) rmadison debhelper should give you the version you have on your Mint; if it is 12 (or maybe 11, can't remember when debhelper-compat became a thing in Debian), replace the 13 with 12 (11) in the file debian/control (look for the line with debhelper-compat = 13 ) If is is older, you can try this instead: - create a file debian/compat with your debhelper major version in it -- this is just one interger number -- e.g echo "10" >debian/compat - replace "debhelper-compat = 13" with "debhelper" in debian/control. - retry from the step mk-build-deps onwards. Good luck! PS: You should be careful installing packages on Mint _NOT_ compiled for mint; its easy to really break the system. Read https://wiki.debian.org/DontBreakDebian for more info. (This link is Debian centric, but also true for Debian based distributions)

And it has been uploaded to Debian (unstable) already! Soon to be available on a Debian mirror near you!

No worry, Debian 9 ("Stretch") will have at least version 2.1.0. Bugfixes for a stable are possible, but only to fix (severe) problems (like that what I described for Ubuntu in the boost::python thread) New versions, though, are generally out of scope -- Even if it would fix a (severe) problem; the fix would be "backported" to the old version instead. Tobi

Hi greebo, do you have some release date in mind? (Debian's freeze is approaching [1] -- so if it is ready by mid-Jan* I'll make sure to upload in time ) [1] https://lists.debian.org/debian-devel-announce/2016/11/msg00002.html -- * It has to be uploaded >10 days before freeze -- deadline around Jan 25, but I also need a few days on my side. -- tobi

Debian's repository is based on the release tarballs (importing them into the repository with git-buildpackage), so there is no direct relation between your and the repository I use.. This is probably the reason why it won't merge However, I can try to come up with a PR to bring up the debian/ accordingly, but this will take me a while due to some imminent buisiness trip.. See also below. I understand your requirement... However, I'd discourage to recycle version numbers.. Some ideas: Maybe something like git-describe* to generate some version string at build time, at least when there is a git repository (on the Debian buildds there won't) (* or maybe using autorevision https://autorevision.github.io/)Ignoring the issue for your builds -- (the patch required for this is tiny, so I can carry it in Debian only, and it might be indeed already fixed by newer gccs: https://reproducible-builds.org/specs/source-date-epoch/ -- I did not test this though) Using __DATE__ only for debug builds / pre-release (by definging some macro at configure time and using those __DATE__ __TIMES__ only if that is #defined. No need for me to have write access to the repo Also note that Debian's tools are smart enough to ignore any "upstream" debian directory, so when I pull in a new tarball from you your's will just be ignored.. (At least for the tools I'm using .. some other toolchains get a bit more complicated when there is a debian directory.) The Debian's upstream guide recommends this, though, as said, for me it is ok as it. (Even if get out of sync,it won't get unusuable soon to self-compilers.) Tobi

(This in reference to http://bugs.thedarkmod.com/view.php?id=4360 where greebo and I discussed already and then decided to move the thread over here.) Quoted here again for conveniene greebo: tobi: greebo: (I will follow up later)

Hi Nightcrawler, I don't know about the release policy of Ubuntu in detail (as I'm a Debian Dev), but a quick search on the net shows that they're doing it like Debian [1]: Fixes are only done to correct severe problems. While a crash is one, I guess it will still be out of scope for Ubuntu to update... As I'm pretty sure that boost::python is causing this crash, so we'd need to find and fix that boost::python problem and patch it in the very specific version that has been used in xenial. As it seems that this bug is not exposed widely, I guess the release managers won't be happy if we'd approach them for this problem... So, sorry, not much to do for Xenial (or Debian's Jessie) except you want to invest some time bisecting boost... What you can try is to e.g run darkradiant from e.g debootstrap'ed chroot environment from a newer release (e.g Debian Stretch) (alternatively some VM). Or -- if you are the adventurous guy -- install darkradiant and its dependencies from a newer Ubuntu (but read [2] before; as there'll be dragons.) tobi [1] https://wiki.ubuntu.com/StableReleaseUpdates [2] https://wiki.debian.org/FAQsFromDebianUser#How_dangerous_is_it_to_run_a_mixed_system.3F