Jump to content
The Dark Mod Forums


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About coldtobi

  • Rank
  1. 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
  2. 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
  3. 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
  4. (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)
  5. 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
  • Create New...