Dear Ruben,
I wonder if you could give us/me a hand in closing the gap between the official packages. In general we are willing to drop backwards compatibility with our install base to reach Debian standards. Ideally a user can easily upgrade from a Debian version to our nightly builds and you and other debian developers can hopefully easily take our source packages and move them forward as well.
Do you have experience with upstream making their own debian packages and a proper package being included in debian as well?
Shall I create tickets in our osmocom.org redmine to coordinate synchronization? Are you aware of different sysv init script names, paths for config/hlr files, package names?
From a very brief look:
+ We never handled the .copyright files correctly you do + debian/control you have nice short and long terms descriptions we should have + You have patches for typos and other parts (i have pushed the ggsn one and will go through the patches later) + Your have manpages and we never bothered with it. I think it is a really good debian rule (and good Unix legacy to force a manpage for binaries in /usr!) - At least for OpenBSC you do not seem to package the -dbg symbols. As a developer I am always annoyed (e.g. with sofia sip) when I can't install the debug symbols. - You seem to not include sysvinit (and systemd) service files?
Do you have a proposal on how we could move forward? How do you manage/maintain the extra debian/ directory?
kind regards holger
Hi Holger!
Just a short answer from me this morning.
I wonder if you could give us/me a hand in closing the gap between the official packages.
Good idea!
In general we are willing to drop backwards compatibility with our install base to reach Debian standards.
I don't have a total overview of the backwards incompatible discrepancies. I probably should have, but hopefully there aren't too many.
Ideally a user can easily upgrade from a Debian version to our nightly builds and you and other debian developers can hopefully easily take our source packages and move them forward as well.
Sounds convenient for the users.
Do you have experience with upstream making their own debian packages and a proper package being included in debian as well?
No, I don't have any experience. But technically, it shouldn't be too hard. The debian dir in the upstream tarball will always be overwritten when building the package, so whatever you do there, will be invisible in the official package unless we manually merge it in.
Shall I create tickets in our osmocom.org redmine to coordinate synchronization? Are you aware of different sysv init script names, paths for config/hlr files, package names?
Sounds like a plan!
From a very brief look:
- We never handled the .copyright files correctly you do
- debian/control you have nice short and long terms descriptions we should have
- You have patches for typos and other parts (i have pushed the ggsn one and will go through the patches later)
- Your have manpages and we never bothered with it. I think it is a really good debian rule (and good Unix legacy to force a manpage for binaries in /usr!)
All the packaging is done with the same license as the upstream software, so you're free (and encouraged!) to pull in all the things you find useful into your source tree or debian dir.
- At least for OpenBSC you do not seem to package the -dbg symbols. As a developer I am always annoyed (e.g. with sofia sip) when I can't install the debug symbols.
-dbg packages are now handled automatically by Debian. Any package with binaries, will automatically get "-dbgsym" packages. Just google it. This is also the case for Ubuntu AFAIK. This will however not be of any help for older Ubuntu and Debian releases (if you desire to support them also with -dbg symbols)
- You seem to not include sysvinit (and systemd) service files?
I'm willing to add this when we're absolutely 100% sure that the default is sane for every user. It was simply excluded from the first versions of the official packages because I'm not familiar enough with the configuration.
Do you have a proposal on how we could move forward? How do you manage/maintain the extra debian/ directory?
The extra debian dir is no problem. As said above, it will be overwritten automatically by the build tools when building the package. To move forward: we just pull interesting stuff from each other's debian dir. However, it may make sense to pull some things out of the debian dir and into the main source tree - for instance the man pages.
Best regards Ruben
Hi again,
Btw. I just noticed that you have actually started the debian packaging on the master branch of osmo-bts - not yet released. Then you're probably not aware of the ongoing effort since Februrary where I've been packaging it:
See this branch: https://anonscm.debian.org/cgit/debian-science/packages/osmo-bts.git/log/
The only thing missing is writing the man pages, the short/long description in d/control and d/copyright, and then it can be uploaded.
Note that I prepared a openbsc-dev package (already in the archive) which provides the gsm_data_shared.h related files, and osmo-bts build-depends on this. I don't know how you solved this.
Cheers, Ruben
On 26 May 2016, at 18:04, Ruben Undheim ruben.undheim@gmail.com wrote:
Hi again,
Btw. I just noticed that you have actually started the debian packaging on the master branch of osmo-bts - not yet released. Then you're probably not aware of the ongoing effort since Februrary where I've been packaging it:
See this branch: https://anonscm.debian.org/cgit/debian-science/packages/osmo-bts.git/log/
oh, I was not aware of it. I mostly created it ad-hoc. I will try to copy as much as possible.
The only thing missing is writing the man pages, the short/long description in d/control and d/copyright, and then it can be uploaded.
Note that I prepared a openbsc-dev package (already in the archive) which provides the gsm_data_shared.h related files, and osmo-bts build-depends on this. I don't know how you solved this.
ah nice! I cheat and copy the file over when building the source package.
On 26 May 2016, at 07:30, Ruben Undheim ruben.undheim@gmail.com wrote:
Hi Holger!
Just a short answer from me this morning.
thank you. Let me merge your better/great description, manpages and symbols. In regard to symbols files when and how to update it? Can you point me to the docs for that?
I don't have a total overview of the backwards incompatible discrepancies. I probably should have, but hopefully there aren't too many.
It's okay, we can have a flag day once if we keep compat after.
No, I don't have any experience. But technically, it shouldn't be too hard. The debian dir in the upstream tarball will always be overwritten when building the package, so whatever you do there, will be invisible in the official package unless we manually merge it in.
Okay, but it would be somehow nice if our descriptions will not drift too much and we re-use the same parts? Can you agree to that?
- At least for OpenBSC you do not seem to package the -dbg symbols. As a developer I am always annoyed (e.g. with sofia sip) when I can't install the debug symbols.
-dbg packages are now handled automatically by Debian. Any package with binaries, will automatically get "-dbgsym" packages. Just google it. This is also the case for Ubuntu AFAIK. This will however not be of any help for older Ubuntu and Debian releases (if you desire to support them also with -dbg symbols)
finally! I never understood (okay compats) why so many packages don't have a -dbg(sym). Should -dbgsym packages be listed on https://packages.debian.org/source/sid/openbsc? So even when going to a mirror I don't see a -dbgsym package next to the other packages? Does one need to raise the compat version for it?
The extra debian dir is no problem. As said above, it will be overwritten automatically by the build tools when building the package. To move forward: we just pull interesting stuff from each other's debian dir. However, it may make sense to pull some things out of the debian dir and into the main source tree - for instance the man pages.
Where would you put them? Makefile.am and install them? Shall we use asciidoc to generate manpages?
holger
In regard to symbols files when and how to update it? Can you point me to the docs for that?
I use: dpkg-gensymbols -plibname0 -Odebian/libname0.symbols -q after building the package.
Then I open up the generated file debain/libname0.symbols and remove the debian suffix from the version number ("-1"). See "man dpkg-gensymbols". There might be easier ways also that I'm not aware of.
I don't have a total overview of the backwards incompatible discrepancies. I probably should have, but hopefully there aren't too many.
It's okay, we can have a flag day once if we keep compat after.
Since I've based the Debian packages on your work (for those you had done back then), there should not really be that much difference, so upgrades should probably go smoothly. We should also be able to make the transition completely smooth using "dependencies" and "conflicts" correctly, if there are any issues.
Okay, but it would be somehow nice if our descriptions will not drift too much and we re-use the same parts? Can you agree to that?
Whenever integrating a new upstream release, I do a diff with the previous version. This is mainly to see if any copyright information has changed, but I will also spot changes to the packaging, and therefore the descriptions. I do of course agree to keep it in sync.
finally! I never understood (okay compats) why so many packages don't have a -dbg(sym). Should -dbgsym packages be listed on https://packages.debian.org/source/sid/openbsc? So even when going to a mirror I don't see a -dbgsym package next to the other packages? Does one need to raise the compat version for it?
One of the reasons mentioned for implementing automatic -dbgsym packages was to prevent waste of disk space on mirrors, so the -dbgsym can be found on some separate servers only and not on every mirror. You'll have to add it explicitly to /etc/apt/sources.list
The extra debian dir is no problem. As said above, it will be overwritten automatically by the build tools when building the package. To move forward: we just pull interesting stuff from each other's debian dir. However, it may make sense to pull some things out of the debian dir and into the main source tree - for instance the man pages.
Where would you put them? Makefile.am and install them? Shall we use asciidoc to generate manpages?
Hmm. I don't really have a strong opinion. Both man/ and doc/man should do fine. If you add it to the Makefile or not, doesn't really matter. I've used txt2man to generate them, since it takes as input an easy human readable text file format. txt2man is a one-file GPL-2 licensed shell script. As long as it dumps out proper man pages, it should be fine.
I hope to get the osmo-bts formal stuff done soon, so it can get uploaded, and then everything for a base station will be available in the official archive!
Cheers, Ruben
On 26 May 2016, at 21:07, Ruben Undheim ruben.undheim@gmail.com wrote:
I hope to get the osmo-bts formal stuff done soon, so it can get uploaded, and then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the last tagged version.
holger
I hope to get the osmo-bts formal stuff done soon, so it can get uploaded, and then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the last tagged version.
It doesn't matter that much. It's very quick to upload a new version after it has been accepted. The hardest part is to get it in there in the first place.
But I'll surely let you know when.
Regards, Ruben
Hi Holger,
It went very quickly this time. osmo-bts was accepted into Debian before I got the time to tell you that it had been uploaded!:
https://tracker.debian.org/pkg/osmo-bts
Now is the time to make a new tag if you want something more fresh in there.
Then both openbsc, osmo-bts and osmo-trx are in Debian making it possible to have a complete base station with an "apt get".
One test case fails ("bursts") for the architecture ppc64el. Unfortunately I forgot to add the code snippet to d/rules which dumps out the test case log.
https://buildd.debian.org/status/fetch.php?pkg=osmo-bts&arch=ppc64el&...
Best regards, Ruben
On Thu, May 26, 2016 at 09:10:38PM +0200, Holger Freyther wrote:
On 26 May 2016, at 21:07, Ruben Undheim ruben.undheim@gmail.com wrote:
I hope to get the osmo-bts formal stuff done soon, so it can get uploaded, and then everything for a base station will be available in the official archive!
great. Please ping us before so we can tag a release that is closer to master than the last tagged version.
holger
-
Holger Freyther -
Ruben Undheim