Jump to content
The Dark Mod Forums

Debian packaging


Recommended Posts

(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:

Thanks for asking!

Regarding the Debian directory:
If you want, you can sync back the changes to the debian/ directory, but it won't make a difference for the packaging (@Debian we usually recommend that upstream do not ship a Debian directories, but our packaging tool will ignore the directory e.g if I import a new version*). However, the debian directory in the github repository is a quite old packaging style, so it wouldn't hurt to update them; though you need to see if you want all the changes, e.g I did drop the i20n package.

Another wish:
I'm currently carrying a patch to make darkradiant builds reproducible, (
http://reproducible.debian.net/ [^]). I did not yet bother to submit it to you, as it is qwritten uite Debian specific. Though, maybe you want to take a look and eliminate all __DATE__ and __TIME__s? https://anonscm.debian.org/git/pkg-games/darkradiant.git/tree/debian/patches/01-reproducible-build.patch. [^]


* BTW, there is a wiki page for upstreams, which might be a interesting read:
https://wiki.debian.org/UpstreamGuide; [^] But you're doing fine here, as far as I can see..

 

 

greebo:

Ok, I just tried to merge changes from your repo (https://anonscm.debian.org/git/pkg-games/darkradiant.git [^]) to mine, but it produced tons of conflicts. Is the repo at debian.org a clone or have the files been imported by copy?

What's the best approach to make the __DATE__ stuff compatible with the repro builds? I'd like to have some sort of timestamp in the app since that's the only thing I can get from some users in terms of info. I usually don't bump versions for pre-release binaries handed out for testers.

Is it possible to define a build timestamp for Linux builds at the time the ./configure script is run? Or is that even worse?

As far as the Debian folder goes - I'd be perfectly fine with giving you write access to the repo at github such that you can work in the upstream repo directly without applying the same things over and over again each time you look into packaging. Since you as a packager are doing work that would otherwise be left for me to do, I'm willing to make your life easier here.

 

 

(I will follow up later)

Edited by coldtobi
Link to comment
Share on other sites

Ok, I just tried to merge changes from your repo (https://anonscm.debi...darkradiant.git [^]) to mine, but it produced tons of conflicts. Is the repo at debian.org a clone or have the files been imported by copy?

 

 

 

 

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.

 

What's the best approach to make the __DATE__ stuff compatible with the repro builds? I'd like to have some sort of timestamp in the app since that's the only thing I can get from some users in terms of info. I usually don't bump versions for pre-release binaries handed out for testers.

 

Is it possible to define a build timestamp for Linux builds at the time the ./configure script is run? Or is that even worse?

 

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.

 

As far as the Debian folder goes - I'd be perfectly fine with giving you write access to the repo at github such that you can work in the upstream repo directly without applying the same things over and over again each time you look into packaging. Since you as a packager are doing work that would otherwise be left for me to do, I'm willing to make your life easier here.

 

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.)

 

Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).

 

Tobi

Link to comment
Share on other sites

I'll try to rethink the numbering of pre-release builds, I guess. Still, I want users to immediately recognise a pre-release build as such. And I'll get rid of the build date in the code to save you from patching the tarball.

 

I'm not a fan of odd/even versioning schemes some projects have (wxWidgets, or GTK+), where stable releases get 2.8.x and unstable releases become 2.9.x, with 2.10 being the next stable one. Or only mentioning it in the release notes that this version is stable and the other one is not. Every project appears to have different versioning schemes and I don't want users to learn that scheme to know what's what.

 

The current public DarkRadiant release is 2.1.0, the next one will be 2.2.0 as there are new features already in git. I'm leaning towards versioning the pre-release builds as 2.2.0, but tagging them as pre1, or beta2 in the actual version string.

 

How often are you going to package something for Debian? You probably don't want to package pre-release builds, am I right? Maybe all this pre-release build versioning doesn't affect you that much.

 

Re: debian folder: as long as it doesn't hurt your packaging process I'm going to keep it even if it's somewhat out of date, should I ever need to build a .deb package myself. I wouldn't want to build it from scratch in that case. As long as there aren't any actual mistakes in those files I'm going to occasionally bump the version or update the changelog perhaps. If there are mistakes, please just point them out and I'll try to fix them right in source.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Query: when was the last time a zombie in a video game was unnerving or scary to you? I'm chipping away at my anniversary submission and I've been trying to gather opinions on the subject. I'm perfectly capable of lighting them well, changing their sfx, and creating effective ambience, but I'm worried that zombies at their core are just too overdone to be an effective payoff to the tension I'm creating.
      · 4 replies
    • nbohr1more

      The Lieutenant 3 is out! Congrats Frost_Salamander! ( raising awareness )
      · 2 replies
    • OrbWeaver

      Has anyone had any luck with textures from Polyhaven? Their OpenEXR normal maps seem too washed out and give incorrect shading in the engine.
      · 5 replies
    • datiswous

      I tried to upscale the TDM logo video. First try:

      briefing_video.mp4 You can test it ingame by making a copy of the core tdm_gui.mtr and place it in your-tdm-root/materials/ , then edit line 249 of that file into the location where you placed the new briefing.mp4 file.
      What I did was I extracted all the image files, then used Upscayl to upscale the images using General photo (Real-Esrgan) upscale setting and then turn it back into a video.
      I might have to crop it a bit, the logo looks smaller on screen (or maybe it's actually better this way?). My video editor turned it into a 16:9 video, which I think overal looks better than 1:1 video of original.
      · 1 reply
    • nbohr1more

      Trying to be productive on my down-time before Capcom releases Akuma and my son is constantly on my PC playing Street Fighter...
      · 1 reply
×
×
  • Create New...