Jump to content
The Dark Mod Forums

Debian packaging

coldtobi
 Share

Recommended Posts

coldtobi

coldtobi

Posted
Posted (edited)

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

coldtobi

Posted
  • Author
Posted

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

greebo

greebo

Posted
Posted

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.

greebo

greebo

Posted
Posted

For the records, the __DATE__ and __TIME__ macros are now used for the Windows target only, so the Linux compilation should no longer be affected by this (with commit 9dbf788)

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.

×
 Share
Go to topic listing

  • Recent Status Updates

    • Airship-Ballet

      Airship-Ballet

      If anyone would like some ambient sounds for any of their work please do hit me up - I've tons of strings both physical and sampled that I love making loops with
      · 1 reply
    • Airship-Ballet

      Airship-Ballet

      👀
      · 7 replies
    • Ansome

      Ansome

      While updating my first FM, I noticed a lot of silly things I did because I was still new to DR. For example, there was a model for a wheel that I wanted the player to be able to turn that had its origin off-center. I didn't know I could just re-export the model inside DR to fix its origin, so instead that wheel triggers a func_mover it's bound to. A silly solution in retrospect, has anyone else made somewhat janky or roundabout solutions to technical challenges in their maps? I'd love to hear about 'em!
      · 5 replies
    • datiswous

      datiswous

      If you use DarkRadiant in Linux while using a dark theme, a large amount of the icons are hard to see, because it's dark-color on dark background (wish DR darkmode was a little less dark). A workaround is switching to a light theme when using DR. I'm using XFCE as DE, so I made this script (mostly copied from this code), which works as a toggle. Then I set it to a keyboard shortcut. The switch works even when DR is already opened.
      current_theme=$(xfconf-query -c xfwm4 -p /general/theme) if [[ $current_theme == 'Adwaita-dark' ]]; then xfconf-query -c xsettings -p /Net/ThemeName -s 'Mint-X-Grey' xfconf-query -c xfwm4 -p /general/theme -s 'Mint-X-Grey' else xfconf-query -c xsettings -p /Net/ThemeName -s 'Adwaita-dark' xfconf-query -c xfwm4 -p /general/theme -s 'Adwaita-dark' fi This only works for the XFCE DE though.
      · 0 replies
    • datiswous

      datiswous

      I just bought/build a new pc, so probably less performance related whining from my part from now on..
      Sorry in advance!
      Here are the specs
      · 4 replies
×
×
  • Create New...