Bug#1017780: Version bump: 1.4.230
Thanks, that clears things up. I've not worked with gbp / uscan before, but that makes things a whole lot easier - I've now got my local branches cleaned up and in line with the rest. I'll hold off on the MR, then, but will keep my Salsa copy updated with what I do and we can sync up later. We're doing a 1.4 build for internal use at work, so hopefully we can contribute back parts of what we do to make that happen. On Wed, 15 Feb 2023 at 23:13, Chris Knadle wrote: > > Hello Jarl. > > Jarl Gullberg: > > I've got a patchset that reworks the control files for proper CMake > > support and a couple of fixes to the existing patches in order to make > > 1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the > > upstream source in line with policy for this package, though, and > > could use some help making sure I'm doing it right. > > Debian Unsable is currently in "soft freeze" because of the upcoming release > of > Debian 12 "Bookworm", such that only small targeted fixes can be uploaded at > this point. > > https://release.debian.org/testing/freeze_policy.html > > It's not realistic to try to upload 1.4.287 to Debian to get it into the next > release at this point. However; it would still be useful to have a newer > version > packaged in order to release it for the Mumble Ubuntu PPA which is also out of > date. I've been working on the Mumble 1.5.517 snapshot release, but > unfortunately its not ready for release because the systemd service file it > ships is broken and the sysv init file was removed. > > I'll send another email to this bug + all involved with the bug as to the > status > of the 1.5.517 work and what got uploaded to Debian (1.3.4-4) and the MR > requests that were incorporated. > > > At the moment, this is what I've done: > > 1. downloaded the upstream release tarball > > 3. renamed it to mumble_1.4.287.orig.tar.gz > > 2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz > > 3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287' > > 4. merge 'upstream' into 'debian' > > I haven't tested doing the above manually, but on first glance it looks right. > I believe these are the same general steps that git-buildpackage does when > running 'gbp import-orig '. If you don't use git-buildpackage yet and > are interested there are some hints about using it here: > >https://wiki.debian.org/PackagingWithGit > > And the DebConf conferences have recorded videos on using git-buildpackage > also, > I think starting around 2013. > > > I only found the 'extras/make-mumble-git-tarball.sh' script after the > > fact, and I do see that that script does some cleanup. I'm also seeing > > a lot of dpkg-source warnings about removed files when I build, so I'm > > pretty sure I've done something wrong. > > If you're importing a tarball, make-mumble-git-tarball.sh isn't meant to be > used. > > The make-mumble-git-tarball.sh was specifically written for mumble 1.3 from > Git > and isn't meant for Mumble 1.4 and above; 1.4 changes file structure > significantly. It was a script I had to build because at the time upstream > wanted me to release Mumble 1.3 and there wasn't a tarball available to do it > from, and Mumble's git repo uses submodules such that a standard 'git archive' > command to build a tarball won't work alone. > > Upstream built another tool to extract a tarball from git which is a Python 3 > script which is part of the upstream Git repo, so the > make-mumble-git-tarball.sh > script I created is outdated. > >https://github.com/mumble-voip/mumble/pull/6016 > > This is how to create a 1.5.x tarball within the 1.5.x Git checkout: > > scripts/create_source_archive.py --revision 1.5.x --format=tar > > But again this is only for the situation of creating a tarball from Git to > work > from; it's not needed if there's already a tarball to import. > > > That aside, everything seems to run fine (with some hiccups related to > > config files for mumble-server that I assume has something to do with > > the above). I can open up a couple of MRs on Salsa if you want, > > provided I can get some handholding in regards to how you want it done > > :) > > Please do not open an MR right now, as I have 1.5.517 to push to the repo, so > I > won't be able to pull an MR for 1.4.287 unless its to a Git branch, which I > don't know how to do off the top of my head. > > Also, MRs for the Mumble repo in Salsa are disabled for all but those within > the > VoIP team for now, because they've been happening without my knowledge. I need > to figure out how to configure email notifications -- there were MRs put there > for a long time that I was never notified by, with no BTS bug report > associated > with. I never knew MRs in Salsa were a thing until discussion about them in > this > particular bug. > > -- Chris > > -- > Chris Knadle > chris.kna...@coredump.us >
Bug#1017780: Version bump: 1.4.230
Hello Jarl. Jarl Gullberg: I've got a patchset that reworks the control files for proper CMake support and a couple of fixes to the existing patches in order to make 1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the upstream source in line with policy for this package, though, and could use some help making sure I'm doing it right. Debian Unsable is currently in "soft freeze" because of the upcoming release of Debian 12 "Bookworm", such that only small targeted fixes can be uploaded at this point. https://release.debian.org/testing/freeze_policy.html It's not realistic to try to upload 1.4.287 to Debian to get it into the next release at this point. However; it would still be useful to have a newer version packaged in order to release it for the Mumble Ubuntu PPA which is also out of date. I've been working on the Mumble 1.5.517 snapshot release, but unfortunately its not ready for release because the systemd service file it ships is broken and the sysv init file was removed. I'll send another email to this bug + all involved with the bug as to the status of the 1.5.517 work and what got uploaded to Debian (1.3.4-4) and the MR requests that were incorporated. At the moment, this is what I've done: 1. downloaded the upstream release tarball 3. renamed it to mumble_1.4.287.orig.tar.gz 2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz 3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287' 4. merge 'upstream' into 'debian' I haven't tested doing the above manually, but on first glance it looks right. I believe these are the same general steps that git-buildpackage does when running 'gbp import-orig '. If you don't use git-buildpackage yet and are interested there are some hints about using it here: https://wiki.debian.org/PackagingWithGit And the DebConf conferences have recorded videos on using git-buildpackage also, I think starting around 2013. I only found the 'extras/make-mumble-git-tarball.sh' script after the fact, and I do see that that script does some cleanup. I'm also seeing a lot of dpkg-source warnings about removed files when I build, so I'm pretty sure I've done something wrong. If you're importing a tarball, make-mumble-git-tarball.sh isn't meant to be used. The make-mumble-git-tarball.sh was specifically written for mumble 1.3 from Git and isn't meant for Mumble 1.4 and above; 1.4 changes file structure significantly. It was a script I had to build because at the time upstream wanted me to release Mumble 1.3 and there wasn't a tarball available to do it from, and Mumble's git repo uses submodules such that a standard 'git archive' command to build a tarball won't work alone. Upstream built another tool to extract a tarball from git which is a Python 3 script which is part of the upstream Git repo, so the make-mumble-git-tarball.sh script I created is outdated. https://github.com/mumble-voip/mumble/pull/6016 This is how to create a 1.5.x tarball within the 1.5.x Git checkout: scripts/create_source_archive.py --revision 1.5.x --format=tar But again this is only for the situation of creating a tarball from Git to work from; it's not needed if there's already a tarball to import. That aside, everything seems to run fine (with some hiccups related to config files for mumble-server that I assume has something to do with the above). I can open up a couple of MRs on Salsa if you want, provided I can get some handholding in regards to how you want it done :) Please do not open an MR right now, as I have 1.5.517 to push to the repo, so I won't be able to pull an MR for 1.4.287 unless its to a Git branch, which I don't know how to do off the top of my head. Also, MRs for the Mumble repo in Salsa are disabled for all but those within the VoIP team for now, because they've been happening without my knowledge. I need to figure out how to configure email notifications -- there were MRs put there for a long time that I was never notified by, with no BTS bug report associated with. I never knew MRs in Salsa were a thing until discussion about them in this particular bug. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: Version bump: 1.4.230
I've got a patchset that reworks the control files for proper CMake support and a couple of fixes to the existing patches in order to make 1.4.287 play nice with OpenSSL 3.0. I'm not sure if I've updated the upstream source in line with policy for this package, though, and could use some help making sure I'm doing it right. At the moment, this is what I've done: 1. downloaded the upstream release tarball 3. renamed it to mumble_1.4.287.orig.tar.gz 2. cd mumble && pristine-tar commit ../mumble_1.4.287.orig.tar.gz 3. unpack tarball in upstream branch, commit and tag as 'upstream/1.4.287' 4. merge 'upstream' into 'debian' I only found the 'extras/make-mumble-git-tarball.sh' script after the fact, and I do see that that script does some cleanup. I'm also seeing a lot of dpkg-source warnings about removed files when I build, so I'm pretty sure I've done something wrong. That aside, everything seems to run fine (with some hiccups related to config files for mumble-server that I assume has something to do with the above). I can open up a couple of MRs on Salsa if you want, provided I can get some handholding in regards to how you want it done :)
Bug#1017780: Version bump: 1.4.230
Hi Diederik, Quoting Diederik de Haas (2022-12-16 15:57:37) > On Tuesday, 13 December 2022 10:55:18 CET Jonas Smedegaard wrote: > > perhaps I can point you to other examples as well > > I'd love to have several examples to look at :-) > Especially if you know of one (or more) who write extensive commit messages > explaining the reasons/rational of their changes. This should help me get an > understanding of how, what and why to do (packaging) things. Sorry, what I have intimate knowledge on (and therefore can offer to select amongst) are packages that I maintain myself - and while I try hard to make the packaging tight and include comments for unusual details, I almost never write multi-line commit messages. Feel free to ask, and I shall elaborate on details... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1017780: Version bump: 1.4.230
Hi Jonas, On Tuesday, 13 December 2022 10:55:18 CET Jonas Smedegaard wrote: > perhaps I can point you to other examples as well I'd love to have several examples to look at :-) Especially if you know of one (or more) who write extensive commit messages explaining the reasons/rational of their changes. This should help me get an understanding of how, what and why to do (packaging) things. TIA, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1017780: Version bump: 1.4.230
Hi Chris (and Diederik), Quoting Chris Knadle (2022-12-13 08:51:00) > Diederik de Haas: > > On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: > >> What I really need is a Debian source package that uses CMake to see an > >> example of how to build a package. I'm looking at list of packages that > >> reverse depend on cmake, maybe I can find a Debian source package that > >> build-depends on CMake that way. > > > > Maybe https://salsa.debian.org/cryptocoin-team/monero ? > > It uses CMake and upstream uses .gitsubmodules > > Yes the Debian monero package uses cmake and the debian/rules file does too > which is indicated by this: > > DH_OPTIONS = -O--buildsystem=cmake > > %: > dh $@ $(DH_OPTIONS:-O%=%) > > When I was looking at Debian packaging with cmake I saw that it's possible to > differentiate files into binary packages in a new way. Instead the > monero.install and monero-tests.install files in debian/ for the monero and > monero-tests binary packages look traditional, which may simplify the > transition, so that's something useful. I am happy that you find my composition of the monero package inspirational. As you might have noticed I have orphaned the package, but I am still around and am happy to answer any question you have about how that packaging was done - and perhaps I can point you to other examples as well (I have grown quite a collection by now). Kind regards, and enjoy your new packaging task, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1017780: Version bump: 1.4.230
Diederik de Haas: On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: What I really need is a Debian source package that uses CMake to see an example of how to build a package. I'm looking at list of packages that reverse depend on cmake, maybe I can find a Debian source package that build-depends on CMake that way. Maybe https://salsa.debian.org/cryptocoin-team/monero ? It uses CMake and upstream uses .gitsubmodules Yes the Debian monero package uses cmake and the debian/rules file does too which is indicated by this: DH_OPTIONS = -O--buildsystem=cmake %: dh $@ $(DH_OPTIONS:-O%=%) When I was looking at Debian packaging with cmake I saw that it's possible to differentiate files into binary packages in a new way. Instead the monero.install and monero-tests.install files in debian/ for the monero and monero-tests binary packages look traditional, which may simplify the transition, so that's something useful. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: Version bump: 1.4.230
Diederik de Haas: Hi Chris, On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: So I'd suggest skipping 1.4 altogether and go straight for 1.5. You _could_ now release a development snapshot (to Experimental?), especially if the package needs to go through NEW and then the update to the 1.5 released version should be (relatively) small (I'd guess). I want to release Mumble 1.5 when possible ... but this isn't about releasing to Unstable vs Experimental -- The reason I mentioned Experimental is that you can use that to get things through NEW if needed, while not blocking potential updates for Unstable/ Testing/Bookworm. Mostly because one doesn't know how long that'll take. I'm aware of Experimental, I believe I've uploaded to Experimental before. It's a worthwhile thought for aa release that may not be fitting (yet) for Unstable, which the current Mumble 1.5 would theoretically fit that because it's not released yet. Keep in mind -- any release to Experimental cannot be uploaded to Unstable with the same version #. i.e. anything in Experimental is strictly a work-in-progress. I believe once a package is released to Unstable with a higher version # than that of Experimental, the Experimental version is removed. it's about the fact that there isn't a 1.5 source tarball to work from to do any release at all. With snapshot I did mean using 'some' upstream git commit, like current HEAD. I'll try to find an example of that as I *know* they exist. Yes, I know. Many upstream packages that are in Git can be exported directly to a tarball and then built as a Debian package. Mumble is NOT one of those. Mumble's Git repo has submodules that are considered separate such that "git archive" won't export the submodules, and the code won't build without them. Also the submodules contain files that have restrictive copyright, making them unreleasable. So the process of /building/ a releasable tarball from several "git archive" operations, extraction, file deletion, re-tarring is messy with Mumble when trying to export it from Git. -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#1017780: Version bump: 1.4.230
On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: > What I really need is a Debian source package that uses CMake to see an > example of how to build a package. I'm looking at list of packages that > reverse depend on cmake, maybe I can find a Debian source package that > build-depends on CMake that way. Maybe https://salsa.debian.org/cryptocoin-team/monero ? It uses CMake and upstream uses .gitsubmodules signature.asc Description: This is a digitally signed message part.
Bug#1017780: Version bump: 1.4.230
Hi Chris, On Wednesday, 7 December 2022 10:13:00 CET Chris Knadle wrote: > > So I'd suggest skipping 1.4 altogether and go straight for 1.5. > > You _could_ now release a development snapshot (to Experimental?), > > especially if the package needs to go through NEW and then the update to > > the 1.5 released version should be (relatively) small (I'd guess). > > I want to release Mumble 1.5 when possible ... but this isn't about > releasing to Unstable vs Experimental -- The reason I mentioned Experimental is that you can use that to get things through NEW if needed, while not blocking potential updates for Unstable/ Testing/Bookworm. Mostly because one doesn't know how long that'll take. > it's about the fact that there > isn't a 1.5 source tarball to work from to do any release at all. With snapshot I did mean using 'some' upstream git commit, like current HEAD. I'll try to find an example of that as I *know* they exist. signature.asc Description: This is a digitally signed message part.
Bug#1017780: Version bump: 1.4.230
Hello Diederik. Diederik de Haas: On Tuesday, 6 December 2022 13:39:23 CET Diederik de Haas wrote: On 3 Nov 2022 08:00:00 + Chris Knadle wrote: tags 1017780 + help I've mentioned this bug in #debian-mentors (on OFTC), but it could help if you'd join that channel and ask yourself so you can get direct feedback on direct questions/issues you're encountering. I referenced this bug in the upstream repo and got a response which I think is REALLY helpful with dealing with this bug and the OpenSSL issue... On 3 Nov 2022 08:00:00 + Chris Knadle wrote: Mumble 1.5.x works with OpenSSL 3.0 but is still in development and not ready for release. Krzmbrzl in https://github.com/mumble-voip/mumble/pull/5354#issuecomment-1339277805: However, I will work on releasing 1.5 as soon as I find the time for it (maybe around Christmas?), which should solve the issue anyway So I'd suggest skipping 1.4 altogether and go straight for 1.5. You _could_ now release a development snapshot (to Experimental?), especially if the package needs to go through NEW and then the update to the 1.5 released version should be (relatively) small (I'd guess). I want to release Mumble 1.5 when possible ... but this isn't about releasing to Unstable vs Experimental -- it's about the fact that there isn't a 1.5 source tarball to work from to do any release at all. Here's the Stable releases: https://dl.mumble.info/stable/ Here's the snapshots: https://dl.mumble.info/snapshot/ The Stable release area has a source tarball available for 1.4 only, and the snapshots don't have any source tarballs for any version at all. So there's no 1.5 source snapshots available that I can find to make a package from. In order to get the source for 1.5 right now, as far as I know one would have to use Git to /build/ it using multiple 'git archive' operations, extract, and re-combine in order to build a custom tarball due to use of git submodules, while removing unreleasable files from the tarball that exist in the submodules. This is error prone enough that I built a script 'debian/extras/make-mumble-git-tarball.sh' in the Debian Mumble 1.3.0~git20190125.440b173+dfsg-2 release to do this, because at the time a Mumble 1.3 release was needed and there wasn't a better option than to do this. I'm attaching that script to this email so you can see for yourself what's involved. Mumble 1.5 reorganized a lot of files with the CMake redesign, so I'm quite sure this old script could not be used as-is to do the same thing today without a lot of tweaking. I've discussed the possibility of doing this with upstream and we mutually agreed against it, and that for now it's better to wait for an upstream tarball release of Mumble 1.5. Assuming a Mumble 1.5 source tarball did exist or was generated from Git, I still don't know how to properly create a Debian package's debian/rules for a source that uses CMake. I've got a package that sort of builds sometimes, depending on build dependencies, but I still haven't figured out how to move the built binaries in to the proper binary Debian packages yet. What I really need is a Debian source package that uses CMake to see an example of how to build a package. I'm looking at list of packages that reverse depend on cmake, maybe I can find a Debian source package that build-depends on CMake that way. I hope this clarifies the issue a bit more. If any of this isn't clear, let me know if there's something I could clarify further. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us make-mumble-git-tarball.sh Description: application/shellscript
Bug#1017780: Version bump: 1.4.230
On Tuesday, 6 December 2022 13:39:23 CET Diederik de Haas wrote: > On 3 Nov 2022 08:00:00 + Chris Knadle wrote: > > tags 1017780 + help > > I've mentioned this bug in #debian-mentors (on OFTC), but it could help if > you'd join that channel and ask yourself so you can get direct feedback on > direct questions/issues you're encountering. I referenced this bug in the upstream repo and got a response which I think is REALLY helpful with dealing with this bug and the OpenSSL issue... On 3 Nov 2022 08:00:00 + Chris Knadle wrote: > Mumble 1.5.x works with OpenSSL 3.0 but is still in development and not > ready for release. Krzmbrzl in https://github.com/mumble-voip/mumble/pull/5354#issuecomment-1339277805: >However, I will work on releasing 1.5 as soon as I find the time for it (maybe >around Christmas?), which should solve the issue anyway So I'd suggest skipping 1.4 altogether and go straight for 1.5. You _could_ now release a development snapshot (to Experimental?), especially if the package needs to go through NEW and then the update to the 1.5 released version should be (relatively) small (I'd guess). HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1017780: Version bump: 1.4.230
On 3 Nov 2022 08:00:00 + Chris Knadle wrote: > tags 1017780 + help I've mentioned this bug in #debian-mentors (on OFTC), but it could help if you'd join that channel and ask yourself so you can get direct feedback on direct questions/issues you're encountering. HTH, Diederik signature.asc Description: This is a digitally signed message part.
Bug#1017780: Version bump: 1.4.230
tags 1017780 + help thanks Greetings. Adding "help" tag to this bug because I'm currently overwhelmed. It's going to be one hell of a life story assuming I get through it all. Valentin: Package: mumble-server Version: 1.3.4-1 Source: mumble Severity: wishlist Mumble released a new version in January, and I would very much like to use this on my server. I want it too, but unfortunately it's not simple or straightforward. I've had a number of discussions with upstream and others about Mumble 1.4.x and right now it's problematic -- Mumble 1.4 does not currently work with OpenSSL 3.0, and OpenSSL 3.0 is the version that's in Debian Unstable/Sid. Building Mumble against a static OpenSSL 1.0 would violate Debian Policy section 4.13 which states that libraries in the Debian archive should be used over convenience copies, so that's not an option: https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies Mumble 1.5.x works with OpenSSL 3.0 but is still in development and not ready for release. It might be possible to find a patch to allow Mumble 1.4 to work with OpenSSL 3.0, similar to how Mumble 1.3.4 was patched by Steve Langasek and Judit Foglszinger. [Thanks to them both!] If someone would like to work on a patch for OpenSSL 3.0 for Mumble 1.4 (please), here are the necessary links and hints that I got from an email discussion with Robert Adam from Mumble upstream: I'd like to think that a similar patch could be made to get Mumble 1.4.x working with OpenSSL 3.0 and that that would be better than Mumble 1.3.4 patched for OpenSSL 3.0. I'd like to know what you think of that idea. Yes, such a patch could very certainly also be made against 1.4. See e.g. https://github.com/mumble-voip/mumble/pull/5354. But be sure to also include the changes from https://github.com/mumble-voip/mumble/pull/5364. I _think_ that was the only major issue we encountered with the OpenSSL switch. In any case you should test whether Mumble is stable after the patch. As to what I think of it: It would absolutely be better to have a patched 1.4 version in the Debian repos than a patched 1.3 version. The latter has the same risk of encountering regressions because of this patch (maybe even higher as the original patch was made to a much newer version of the source code), but of course has the disadvantage of still missing all features and fixed introduced with 1.4. Mumble 1.4 also switched to using CMake which requires changing the debian/rules file to account for that in ways that I don't yet understand. I've tried to follow some documentation that I had found, but there are few references in the Debian Developer documentation for building packages with CMake when I search, and I haven't found a suitable package in Debian that uses CMake to use as an example either. I was last working with dh-cmake (which I'm not sure if using the package is necessary or not) and calling: dh $@ -0buildsystem=cmake and there's a bunch of debhelper overrides that are necessary; for instance I was last trying using this based on reading the Mumble CMake hints: override_dh_auto_configure: dh_auto_configure -- \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_OVERLAY_XCOMPILE=ON \ -Dbundle-qt-translations=OFF \ -Dbundled_celt=ON \ -Dbundled_opus=OFF \ -Dbundled_speex=OFF \ -Donline-tests=OFF \ -Dsymbols=ON \ -Dtests=OFF \ -Dupdate=OFF \ -Dwarnings-as-errors=OFF The build-depends in the debian/control file seems to be more sensitive than expected and adding certain build-depends mentioned as optional for building the Mumble source for Debian can cause the build to fail. There are changes needed for CMake for how to separate which built files go into which Debian binary package after the build, I haven't yet worked that out. Some more hints on Debian packaging with CMake here: [These hints are for me as well as anyone else] https://www.debian.org/doc/manuals/debmake-doc/ch08.en.html#cmake-multi https://gitlab.kitware.com/debian/dh-cmake https://unix.stackexchange.com/questions/519986/packaging-cmake-components-for-debian So if someone can give me some useful hints for Debian packaging with CMake, such as an example Debian package that uses it with multiple Debian binary package outputs, and/or a patch for Mumble 1.4.287 for building with OpenSSL 3.0 that would be greatly appreciated. Thanks -- Chris -- Chris Knadle chris.kna...@coredump.us
