OpenBVE perhaps return to Debian again...!?

[ginga81]

Relative with #261.

Today, via Twitter, a Debian Developer henrich is conversation to me.
https://twitter.com/henrich

He say that if you mails to Debian's WNPP, he becomes to the sponser.
Please send WNPP to submit@bugs.debian.org.

If recoverly to debian, you(Mr.leeser3) can continue to registration to debian directly.

At https://www.clear-code.com/blog/2014/3/7.html, the WNPP's prototype mail foramat is written.

Additionally, he checked your OpenBVE's .deb, and he advice to me.
He say that some files are still not ready for registration.
For example, debian/copyright.
The deficiency files should to attach based from bellow.
http://snapshot.debian.org/package/openbve/1.4.0.10-3/

Additionally, perhaps you are not use official deb packaging tool.
If you use official deb creating tool, it is so smart.

I will continue to contact to developper henrich.
If you sent to email to submit@bugs.debian.org, please announce to me.
I tweet to him.

[leezer3]

Interesting!

I agree debian/copyright is missing, will add that back again.
The last conversation I had with @directhex (Previous package maintainer) was over email about 2 years ago.

I've got no real experience with Debian packaging, and the current package is based upon a combination of the original scripts and some tweaking of my own.
IIRC Debian would want the compatibility data separated into a second package.

She was relatively happy to chat, but nothing happened, and I think she had a lot of other stuff on her plate too.

[ginga81]

fetch from the http://snapshot.debian.org/package/openbve/1.4.0.10-3/, some more deficiency files.

He said that he will be a sponsor if you prepares and emails the necessary documents and the appropriate deb file.
He said to me that it is busy now to the next debian release, so he said to me that every few days please mention.
So please email me after preparation.

[directhex]

The last active package maintainer in Debian was actually @sladen, I just had some oversight as part of my general control of .NET in Debian

[sladen]

@leezer3 @ginga81: would encourage working with the packaging as-is:

• https://github.com/sladen/openbve/

was a careful import of released .zip snapshots into revision control, until Michelle moved on.

Is there a clear new upstream, from which to make new releases?

[leezer3]

This repository is the upstream these days.
I don't believe there has been any other fork / continuation released with any working development or new features :)

The release branch and the point releases should provide the snapshots you're after I think.

The history should be contiguous from the last source Michelle released although I'd have to check that; the packaging and other build scripts have been later additions on the top, as well as a lot of (ongoing) reorganisation.

Essentially, I think what this needs is a clear list of points Debian would like us to address?

[leezer3]

OK, so I've had a quick look back into the commits and the linked repo from @sladen

The commit tree for this repo starts here:
7416862

I appear to have started from a base of Michelle's last released ZIP source (1.4.3.0), and done some work before importing this into the GIT repo.
This contained the full set of developer tools, data etc.
After that, the history is contiguous.

Sladen has a set of repositories which are split by program, so that each of the tools lives in it's own repository.
I'm not necessarily sure this is the 'correct' method of doing things in a game of this nature, especially as there is a massive amount of commonality between the different tools, and none of them have any real use outside the game. (N.B. One of the ongoing jobs is merging the duplicate code between the tools), either way it's two different / disparate approaches.
Either way, Debian appears never to have distributed the tools, so I'm not sure how relevant this is.

---

Thoughts / TODO List:

• Sort out the missing files from the Debian package. Should just be able to pull these from the main Debian tree.
• Create a separate package for the menu / language / compatibility data? I'm not entirely clear what the original Debian motivation for this was, but presumably something to do with reducing download sizes on an upgrade? Separating the default route / train I can absolutely understand, but I wouldn't have done this personally :)
• We distribute / require various C# libraries / wrappers ( CS-Script, NAudio, NUniversalCharDet. OpenTK, SharpCompress, Ionic.Zlib), which are not available as default Debian imports. All of these have a suitably permissive licence, but I'm not entirely clear how exactly Debian would want these presented?

[sladen]

@leezer3, it's 10 years ago, so things may be a little hazy.

• openbve-data is cross architecture: consisting of images (which mostly never changed), documentation, and translations (which tended(?) to change quite rapidly, because translations would also be contributed directly, outside of the main source releases)
• openbve is the executable and immediately required configuration programs. ie. everything that has to be compiled at-the-same-time for things to work. Being CLR/CLI this is theoretically cross architecture; but I did have loading of i386 plugin DLLs working, and that code it was not cross-architecture.

For the content side, we had three examples (all thanks to Anthony):

• bve-plugin-uktrainsys, a plugin usable across various routes
• bve-route-cross-city-south, an example route
• bve-train-br-class-323, an example train
• bve-train-br-class-323-3dcab, an example 3D train interior, depending/extending bve-train-br-class-323

The route/train/cab/plugins are not OpenBVE-specific per-se, they are in BVE-CSV fileformat and could also be used with eg. the original BVE Trainsim non-free freeware program + tools. Hence the bve- prefix.

It would be great to bring the tools into the main repository, and I'm sure Debian/Ubuntu would be very happy to follow whatever Upstream does! ;-)

[leezer3]

No trouble.

I've been in this community since 1997 or there abouts, and have seen the entire gamut of BVE.....
Started developing this rather by accident, but now things have rather started to get a lot more complex!

Main Program:

I've actually done some playing with cross-architecture proxying for i386 plugins:
#230

This works acceptably(ish), but it's not code I was ever happy with.
Being honest, it's something which needs someone with considerably more understanding of cross-architecture would need to look into properly again.
We're also still limited to openGL 1.1 & Display Lists, which somewhat rules out most non x86 architectures.

Data:

The data included in the current releases has grown somewhat since the original days. At present, it's this:

• Windows dependancy stub installers (irrelevant to Debian packaging)
• Menu images / data etc- These get added to occasionally to support new features, but are generally largely static.
• Translations- A lot of these are out of date unfortunately; Where new strings have been added, these have been inserted in English. Getting contributions to this is hard, but might change if we get back into Debian....
• An open-source copy of various objects from the Uchibo route by Mackoy- These are called by a lot of early BVE2 / BVE4 Japanese content, and the original is not easily available / installable for users of modern non-Japanese Windows.
• Documentation (?) - A copy of this is included in the main source repo, but not with the downloads.

At 5mb compressed, whether a separate package is worth the trouble is something Debian would have to decide.
Distributing a deb from our site, I made the decision that supplying a single file was just easier, although obviously being in a repo means that it just gets pulled in as a dependancy :)

Tools:

My instinct would be to include with the main program, and use executable names prefixed with openBVE as follows:

openbve-objectviewer
openbve-routeviewer
openbve-traineditor
openbve-carxmlconvertor

etc.

An alternative would be to add a Developer Tools button / dialog to the main menu, which would avoid adding anything to the path?

Content:

I'm happy to provide 3 more fully cross-platform locos & assorted consists ( GWR 81xx, GWR Manor, BR Class 52 ) in public domain / BSD-3 if we feel that is a good idea. None of these work correctly on the original BVE trainsim however. (n.b. openBVE introduced both the 3D cab and train exteriors, so neither of these work per-se with the original BVE Trainsim)

Route-wise is somewhat more complex, and I don't think there's anything easily available that could be added.

As opposed to Michelle's original managed content system. a relatively early implementation was a basic package manager. This isn't anything particularly special, just reads a metadata XML from a zip, and allows installation / removal etc.
I don't know quite how this will relate to the Debian content packages, but it was considered important to have a format which automatically packaged / installed content, and was cross-platform.

Other:

The issue of the licence mess Michelle left us with pops up every once in a while:
#305

We have agreement from all the non-trivial contributors to this repository that a move to BSD is acceptable in principle, and TBQH the current licence probably would allow us to do this anyways.
I'd be interested if you have comments or preferences in this regards.

[leezer3]

OK, have done rather a lot of messing around with the generated deb.

This is now clean of all red lintian warnings, other than the lack of a changelog.
I haven't currently got a good way to pipe this into the requisite file, so it would probably have to be created manually by whoever builds the debian package.

However, there are still some flaws:

• A bunch of the stuff in the assets directory has permissions which Lintian thinks is incorrect. This can probably be sorted easily enough with a permissions commit in GIT. (Just how important is this anyway?)
• Some of the built code seems to be getting again 'incorrect' permissions. I'm tempted to just recursively chmod all exe files to 0755 and anything else to 0644 as a post-build step, but it'd probably be 'better' to fix this in the makefile.
• The small usertool we use to add the LBA header is getting packaged. Harmless, but should be squashed after it's used.

This really needs someone familiar with Debian packaging to take a look now though.
I can read Lintian warnings just fine, but I don't know enough about the fine details of what's happening.

[directhex]

Okay, so, taking a look at the packaging metadata, I feel it would be much easier to maintain in the longer term by using some newer conventions - right now it's using format version 5 from 2005 (https://github.com/sladen/openbve/blob/debian/debian/compat) and 75% of that file would go away with version 7 from 2008. https://salsa.debian.org/dotnet-team/xsddiagram/blob/master/debian/rules is an example of a Debhelper 7 rules file for a project built entirely from sln/csproj - and half of that file is a custom rule for downloading the .tar.gz.

Some of the automagic things in dh7 would likely help you

[directhex]

Sorry, I should have given a bit more context as to what's happening.

%:
	dh $@ --with cli

Means "for every Debian packaging rule, just do whatever the dh command wants to do, but add the .NET-specific commands defined in /usr/share/perl5/Debian/Debhelper/Sequence/cli.pm"

Then for every command dh wants to shell out to, you can choose to override it by adding a override_dh_foo: target, e.g. override_dh_auto_build (which detects things like autotools or cmake or meson) to instead call xbuild on the sln. You'd throw away everything in the existing rules and leave something like:

#!/usr/bin/make -f
export DH_VERBOSE=15
BUILDDIRS = openBVE/OpenBve openBVE/OpenBveApi \
 openBVE/OpenBveAts \
 openBVE/Sound.Flac openBVE/Sound.RiffWave \
 openBVE/Texture.Ace openBVE/Texture.BmpGifJpegPngTiff
TARGET = $(CURDIR)/debian/openbve
EXEC_TARGET = $(TARGET)/usr/lib/openbve
EXEC_PLUGIN_TARGET = $(EXEC_TARGET)/Plugins
#DEBUG_CONFIGURATION=Debug
DEBUG_CONFIGURATION=Release

override_dh_auto_build:
	for builddir in $(BUILDDIRS); do \
	  (cd $$builddir && xbuild /p:Configuration=$(DEBUG_CONFIGURATION) *.csproj) || exit 1; \
	done

override_dh_auto_clean:
	for builddir in $(BUILDDIRS); do \
	  (cd $$builddir && xbuild /t:Clean *.csproj); \
	  rm -rf $$builddir/bin $$builddir/obj; \
	done

override_dh_auto_install
	#do most of this stuff in debian/install, maybe with dh-exec
	lynx -dump -nolist $(CURDIR)/debian/changelog.html > $(TARGET)/usr/share/doc/openbve/changelog

override_dh_clideps:
	dh_clideps -d -r --exclude-moduleref=AtsPluginProxy.dll

%:
	dh $@ --with cli

[leezer3]

Thanks!

The current in-tree script we've got (and which I've been modifiying today) actually builds the solution (Uses mcs , not xbuild) before copying it into the Debian package structure and calling dpkg-deb to build the thing.
IIRC the only thing that got used from the original package was a stripped down metadata file so that we'd install over an existing install gracefully.

After today's work, it declares format V7, which if I understand correctly isn't actually doing much in this case, as I'm essentially just packing binary files.

If I understand what's going on with the rules file correctly, the only real advantage would be that we could just call the dpkg creation command in the root directory, and dpkg would sort everything else out?
Not entirely clear whether it's a Debian requirement for things to work in this way, or just whether the deb must conform to standards?

[directhex]

For a "use Debian packaging on a tarball of binaries not source" your example is https://github.com/mono/linux-packaging-nuget

But bear in mind this strategy isn't ok for inclusion in packaging repositories