A release would help Debian packaging

[smoe]

Hello,
it is not ultimately required, a mere date plus hash would do, but it would nonetheless be nice to somehow have synchronised releases on github with what appears on the Linux distributions. I got positive initial vibes on axn/bmx6#3 (comment) about this idea. Just prime me on how you think an appearance on Debian would be supportive of what you are doing.
Best,
Steffen

[axn]

I am aware of several communities that use bmx on debian in some GW nodes to internet or other BGP connected networks. Currently they are forced to compile bmx from source and make sure all dependencies are satisfied. A debian package would be very useful here.

I could add a release tag to the current bmx6 code and then be happy to forward the ticket to you ( @smoe ) or @aparcar for taking over.

BTW, This is related to the debian package request for bmx7 bmx-routing/bmx7#24

[aparcar]

@smoe hey can you help out with a bmx6/7 package? I have no experience in this area.

[smoe]

Hi @aparcar, yes, can do. You see my profile of packages in Debian on https://qa.debian.org/developer.php?login=moeller%40debian.org and fastd, alfred and libuecc are packages I had helped with before. So, it kind of fits, but you also understand that I would be exceptionally happy to see someone of yours to eventually slide his/her interest towards adopting that effort.

Would you fancy a separate branch of the respectivive bmx6 (7) repository for the packaging? Then we can share the progress and you can help with improving descriptions and testing. If so, maybe you could create a "debian" branch of - shall I start with bmx6? - that I could send pull requests against? Hm. This sounds quite right: You create the "debian" branch and I start working on an initial package. We then see where this has problems and which of these problems should be fixed in master. That could be ambigious documentation or an init script missing something or the man page ... whatever. Once you are happy, you do the release tag and we (I) upload to the distribution. It likely makes sense to have a pre-release sent up at some point to attract some early adopters' feedback. The release tag is optional but tremendously helpful to later bisect problems.

[aparcar]

@smoe here you go: https://github.com/bmx-routing/bmx6/tree/debian
If you create the bmx6 package I'd copy the efforts for bmx7 and thereby learn how it's done - hope thats fits you.

Regarding any tagging, that's @axn job

[aparcar]

@axn ping

[axn]

If not done already, I'll amend control file and add tags till Monday. But feel free to advance here as well. Any suggestions for a versioning scheme that facilitates frequent (interoprrable) updates? thanks for good progress Am 17. Mai 2018 17:52:37 MESZ schrieb Paul Spooren <[email protected]>:

…

@axn ping -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #13 (comment)

-- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[smoe]

I strongly propose to remain upward-compatible within bmx6. This is the main reason you have two packages for these two versions of bmx (6+7). I do not think I can suggest much to you guys wrt versioning. If you are thinking about an upcoming 1.0 release then maybe have 0.9 out now and ask for an extensive testing in the community.

In my perception as an outsider you need to explain more what bmx is about for your first larger public appearance with an 1.0 version. This involves all the obvious stuff, like in what situations one would like to use that software. This is not only helpful for new users to learn what bmx is about, it also helps search engines to propose your software as answer to a question typed in as a search phrase. As for debian/control, consider also to tell the README.md how bmx6 differs from other solutions. Some benchmarks would also be nice.

I would be honoured if the man page in debian/bmx.1 would make it to master, then please adjust the file debian/manpages (of the debian branch) accordingly to match its new location. Again, have extra information about the project also in there since man pages are likely to be indexed in various web sites and google then finds the information better.

The bmx6 Debian package yet lacks support for sysvinit or systemd. And I yet do not know enough about bmx6 to help you out on that front. Also I have no clue whatsoever about config files that bmx6 may needs.

Should English as a foreign language slow you down, then feel free to send me a brain dump in your respective mother tongue to my debian.org address.

[axn]

I extended debian/control, set version to 1.0-dev and tagged current head of debian branch as v1.0. Assuming it can be merged back into master soon and later increased to 1.0.1 as needed. I don't expect bigger changes with bmx6 as its current code-base is used since years, only some cleanup could be useful.

Regarding the other remarks and further TODOs:

• Remaining backwards- and upward-compatible with bmx6 is high priority (and was achieved since several years already). Future bugfixes and enhancements shall definitely maintain compatibility

• The README.md can be extended. There are plenty of real-world deployments in production since years such as here http://tomir.ac.upc.edu/qmpmon or https://nycmesh.net/map/
  I am a bit reluctant to argue too much for bmx6 in the README.md as I consider it more as a technical HOWTO. Maybe some general references could be given to related work such as http://www2.ic.uff.br/~celio/classes/cmovel/slides/community-mesh-2015.pdf

• Regarding configuration we yet focused on openWrt based devices with the uci-config plugin. Bmx6 could be controlled with startup-parameters and most of them can also be reconfigured on the fly. Support for sysvinit or systemd can be scripted based on this or via a separate plugin. In either way I'd be happy to delegate this task and help out where needed.

• manpage in debian/bmx6.1 still needs to be improved/fixed.

Can you post a commandling to build a debian package based on current debian branch? I am a bit stuck with gdb-buildpackage arguments to succeed.

[smoe]

Well done!

Please merge #17 to fix the YAML syntax of the debian/control file.

You do not need anything special to compile the Debian package. The debian/rules file is a Makefile that knows how to do it all. The packages you need are

• build-essential
• fakeroot
• debhelper
• libjson-c-dev
  The debian/rules file then invokes a regular build. The debian/bmx6.install file knows what file should go where. In the end, a subfolder in the debian folder has the name of the respective binary package (there is only one, bmx6) and below that you arrange files such that you could create a tar file that you can unpack from root (/) when the package is installed.

This is all invoked by
fakeroot ./debian/rules binary
which does the above and creates the .deb files. Run "./debian/rules clean" to start over.

Prior to committing back to the debian branch, please ensure that you do not have anything outside debian to commit and avoid "git commit -a" to be extra careful.

[smoe]

Changes with some relevance to the package as a whole (like to the README.md) should go to the master branch and then be merged with the debian branch - sorry if this was obvious. Any success so far? I would have two rented Debian machines that we could use for testing, happily grant you access.