On 11/07/2024 15.07, Charles Plessy wrote:
Hi Michael, Le Thu, Jul 11, 2024 at 12:22:32PM +0200, Michael R. Crusoe a écrit :If there are no objections, I'd like to upload the new r-bioc-biocgenerics to experimental and continue on with the rest of bioconductor 3.19I do not want to stop you doing it, but I have a question.
Thanks. Unless I hear otherwise, I'll start uploading tomorrow. More below
``` git checkout -b debian/experimental routine-update --no-build --experimental --branch debian/experimental -tGreat news that we have it and sorry that I overlooked it. Is there also a trick for automatically merging the experimental branch into master once we start uploading to unstable ?
I guess I would do git checkout master git pull git merge debian/experimental dch --newversion $(dpkg-parsechangelog -SVersion | sed 's/~.*//') 'Upload to unstable' && dch --release "" debcommit -a git clean -fdx gbp tag gbp buildpackage -S -d # test the package # and then debrelease -S --dput && gbp push
Apart from that,I understand that. Did we have problems skipping releases before?I think that we never skipped releases. The main problem is that the old release causes incompatibilities in Testing. Last time, I proposed to skip a release and remove the packages from Testing in the meantime, but the Release team refused to do so. This is one of the reasons I took time this time: I wanted to see if something would happen if we would wait for autoremoval. The answer is no, nothing happens and the release team does not complain. If it makes the migration simpler, next time I want to ask again the release team again to kindly help us by removing the old BioC packages from testing.
Thanks for the history!
As it was, I had to do a local build of over 90 bioc packages to confirm that the newly needed packages for 3.19 worked. So it would be about another 80 packages to update, which I don't mind doing now that I've gotten practive.That is really great. Can you share the part of your gbp configuration that allows sbuild to pick locally built packages to resolve dependencies? Do you run autopktest through sbuild's hooks?
I only use `gbp buildpackage` to make the source package. Normally I use autopkgtest, but for this project I use pbuilder (in the form of cowbuilder-dist) plus this trick https://wiki.debian.org/PbuilderTricks#How_to_include_local_packages_in_the_build
To make that trick work, I apply a small patch to https://git.launchpad.net/ubuntu-dev-tools/tree/pbuilder-dist#n407
*** /usr/bin/pbuilder-dist 2023-09-15 10:20:05.534821567 +0200
--- /home/michael/debian/pbuilder-dist.orig 2024-07-11 16:05:17.401024393 +0200
***************
*** 400,406 ****
"DISTRIBUTION=" + self.target_distro,
"ARCH=" + self.build_architecture,
"DIST=" + self.target_distro,
- "DEPS=" + os.environ.get("DEPS", ""),
"ADT=" + os.environ.get("ADT", ""),
"DEB_BUILD_OPTIONS=" + os.environ.get("DEB_BUILD_OPTIONS", ""),
self.builder,
--- 400,405 ----
To run the autopkgtests during package building, I've long had https://salsa.debian.org/pbuilder-team/pbuilder/-/blob/master/examples/B20autopkgtest?ref_type=heads installed in my personal pbuilder hooks directory
If they are 32-bit issues, then I'm fine with excluding them using `architecture-is-64-bits` and allowing the relevant autopkgtests to skip archs where the dependencies aren't available.I think that 32-bit issues are bound to pop up with time, in an unpredictable frequency. I fear that adding architecture-is-64-bits information package per package on a case-by-case basis is going to be quite some work. Opening bugs, closing bugs, adding patches, removing patches. And I am not aware of Bioconductor does not support non-64 bit arches. I will not stand on the way of people working on providing 32-bit surpport for Bioconductor in Debian. But if there is no appetite or excitement for that task, why don't we take the opportunity of this Bioc release for adding architecture-is-64-bits everywhere?
Looks like they dropped support for 32-bit MS Windows starting with 3.16, so adding architecture-is-64-bits as a build-dep for all binary-producing source packages is fine by me. https://bioconductor.org/news/bioc_3_16_release/
Have a nice day, Charles
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature