Re: Re: Cannot create chroots with cowbuilder because of usr-is-merged
Hi Luca, Am Mon, Oct 30, 2023 at 05:50:19PM + schrieb Luca Boccassi: Try DEBOOTSTRAPOPTS="--merged-usr" in your ~/.pbuilderrc In trixie and sid, all chroots, including those to build packages, are already supposed to be usr-merged. Enabling proposed-updates on Debian 11 or 12, to get the new debootstrap, will also allow to create new unstable/testing chroots out of the box, without config changes.a Thanks a lot,that helped. Still on bookworm here. Best, Markus
Cannot create chroots with cowbuilder because of usr-is-merged
Hi, I cannot create or update chroots (for sid or unstable) with cowbuilder anymore, neither on Debian 12 nor 11. $ sudo cowbuilder create I: Invoking pbuilder I: forking: pbuilder create --buildplace /var/cache/pbuilder/base.cow --mirror http://ftp.de.debian.org/debian/ --distribution sid --no-targz --extrapackages cowdancer W: /root/.pbuilderrc does not exist I: Running in no-targz mode I: Distribution is sid. I: Current time: Mon Oct 30 17:13:56 CET 2023 I: pbuilder-time-stamp: 1698682436 I: Building the build environment I: running debootstrap /usr/sbin/debootstrap I: Target architecture can be executed I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id 4CB50190207B4758A3F73A796ED0E7B82643E131) I: Retrieving Packages ... I: Unpacking usr-is-merged... I: Unpacking zlib1g:amd64... W: Failure while unpacking required packages. This will be attempted up to five times. W: See /var/cache/pbuilder/base.cow/debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/usr-is-merged_38_all.deb is at fault) (this is tried another 4 times) ... I: Unpacking zlib1g:amd64... W: Failure while unpacking required packages. This will be attempted up to five times. W: See /var/cache/pbuilder/base.cow/debootstrap/debootstrap.log for details (possibly the package /var/cache/apt/archives/usr-is-merged_38_all.deb is at fault) E: debootstrap failed E: Tail of debootstrap.log: util-linux pre-depends on libmount1 (>= 2.39.1) libmount1:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libpam0g (>= 0.99.7.1) libpam0g:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libselinux1 (>= 3.1~) libselinux1:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libsmartcols1 (>= 2.38) libsmartcols1:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libsystemd0 libsystemd0:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libtinfo6 (>= 6) libtinfo6:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libudev1 (>= 183) libudev1:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on libuuid1 (>= 2.16) libuuid1:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! dpkg: regarding .../util-linux_2.39.2-4_amd64.deb containing util-linux, pre-dependency problem: util-linux pre-depends on zlib1g (>= 1:1.1.4) zlib1g:amd64 is unpacked, but has never been configured. dpkg: warning: ignoring pre-dependency problem! Preparing to unpack .../util-linux_2.39.2-4_amd64.deb ... Unpacking util-linux (2.39.2-4) over (2.39.2-4) ... Preparing to unpack .../zlib1g_1%3a1.2.13.dfsg-3_amd64.deb ... Unpacking zlib1g:amd64 (1:1.2.13.dfsg-3) over (1:1.2.13.dfsg-3) ... Errors were encountered while processing: /var/cache/apt/archives/usr-is-merged_38_all.deb E: End of debootstrap.log W: Aborting with an error E: pbuilder create failed I: forking: rm -rf /var/cache/pbuilder/base.cow Any ideas what I might be doing wrong? Thanks a lot for the help. Best, Markus
How are parallel build parameters choosen by buildd,
Hi, from time to time i am experiencing some hanging builds that get killed due to inactivity, or even failing tests. I am not 100% sure why that happens but my suspicion is that the available memory per make thread might be insuffient. It fluctuates quite a bit between machines used by buildd. A current example is the failing build of opm-common on mipsel64 [0] on mipsel-aql-03 [1] It uses "DEB_BUILD_OPTIONS=parallel=4" on machine with 8 GB of ram according to the build log [2]. A previous build (with nearly no changes) on mipsel-osuosl-03 [3] worked. It used 4 make threads but the machine had 16 GB. That is double the memory. Is that on purpose? How are the parallel options chosen usually (e.g. min 2GB RAM per make thread)? Should I try to limit parallel builds based on available ram? E.g. using free_ram = $(shell free -g | sed -n 2p| sed "s/ \+/ /g"| cut -d " " -f 2) max_procs = $(shell echo $(free_ram)/4 | bc) parallel_procs =$(shell if test "$(max_procs)" -lt "1"; then echo 1; else echo "$(max_procs)"; fi) %: dh $@ --builddirectory=build --max-parallel=$(parallel_procs) Cheers, Markus [0] https://buildd.debian.org/status/logs.php?pkg=opm-common=mips64el [1] https://db.debian.org/machines.cgi?host=mipsel-aql-03 [2] https://buildd.debian.org/status/fetch.php?pkg=opm-common=mips64el=2022.10%2Bds-4=1675076235=0 [3] https://buildd.debian.org/status/fetch.php?pkg=opm-common=mips64el=2022.10%2Bds-3=1673902669=0
Might failed builds for unofficial ports block migration?
Hi, I am currently preparing/testing Debian packages of the upcoming OPM release by uploading them to experimental. I noted that packages for both hppa and riscv64 are failing for this release of opm-common [1] that did build before. riscv64 [2] might be a compiler issue of g++-12 and hence not happen unstable. For hppa [3] it is due to added tests which fail because wrong treatment of endianness. Both are "unofficial ports". Would these failing builds block migration to testing if uploaded to unstable? Cheers, Markus [1] https://qa.debian.org/developer.php?login=markus%40dr-blatt.de [2] https://buildd.debian.org/status/fetch.php?pkg=opm-common=riscv64=2022.04%7Erc1-1=1651151421=0 [3] https://buildd.debian.org/status/fetch.php?pkg=opm-common=hppa=2022.04%7Erc1-1=1651103022=0 signature.asc Description: PGP signature
Re: Do autopkgtest for non-listed architectures prevent migration?
Hi, Am Mon, Jan 24, 2022 at 10:38:32AM +0100 schrieb Helge Deller: On 1/24/22 09:10, Ole Streicher wrote: Wookey writes: If the package builds on the 32bit arches then I would advise that you let it build. We always try to build for all arches in debian and it is very annoying if you have say an armhf machine and something is not available just because there was some test failure so upstream simply excluded builds completely. Packges should only be excluded on an arch if they are known not to build or to be genuinely useless there. I would disagree here: If we can't support a certain package on a platform, then we shouldn't build it there. If neither upstream nor the Debian maintainer is going to support armhf, then it should not be built. I'm not sure if there is a misunderstanding here. I think every package (unless it doesn't fit to a platform like a boot loader, or the target architecture is really not meant for that package) should be *built*. It may fail tests, in which case it should still be built, but the build should be marked failed and as such no *binary* package should be produced and uploaded. But since it was built, platform maintainers may see it, can check the build logs and may help to fix. The worst thing for arches is, if a package is being *excluded* from building on certain arches just because there was a build- or test error. That way nobody will notice and there will never someone look into it. Thanks for the valuable input. In my case the tests will fail and there will be no binary packages on 32bit platforms. I have read a bit on older mentors-list threads about listing Architectures and come to the same conlusion as Wookey and Helge. If possible it should be prevented. My main reason to build on all platforms is: If a new Platform is added and architecture is a limited list then chances are very high that nobody will try to add the new architecture to the architecture list. If buildd resources are an issue, I could patch upstream such that CMake will error out if it is a 32bit platform. Cheers, Markus
Do autopkgtest for non-listed architectures prevent migration?
Hi, still an newbie and so many questions. Please bear with me. My package opm-common list as one of the blocking migration that autopkgtest fails for armhf and i386. https://qa.debian.org/excuses.php?package=opm-common The reason is that there are no packages built for these architecture as I limit the architecture to only 64bit architectures by having "Architecture: amd64 arm64 ia64 mips64el ppc64el" in d/control. Yet this does not seem to respected for autopkgtest as it still tries to run the test for i386 and armhf. Does that mean that no packages will migrate for any architecture? Then I would need to change this. Or will the binaries for passing architectures migrate? For why 32bit architectures are not listed: Many tests of the buildsystem of the upstream package fail because of Y2K38 bugs. Upstream does not see that as a problem as running a simulation on these architectures or simulations of just 16 years is not a goal. Fixing this in Debian would be much hard work and might not be worth it. Which is why would like to prevent it. If limiting the architectures to 64bit is a problem an alternative would be to skip the tests of the build system on 32bit architectures. I just need to find out how to do this. Markus
How to resolve unsatisfied dependency (verisoned) after ftpmaster acception
Hi, I have created a new Debian package that finally got accepted into unstable by ftpmaster. Thanks a lot. This is really great. When I look at the package tracker https://tracker.debian.org/pkg/opm-common I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2. As debian/control does only specify a dependency on libfmt-dev without a version, I assume that this version dependency was added when the packages were built some time ago. What is the recommend way to resolve this? Cheers, Markus
lib package name of dependency changed after ftpmaster acceptance (was Re: How to resolve unsatisfied dependency (verisoned) after ftpmaster acception)
Hi Am Fri, Jan 21, 2022 at 10:06:22AM +0100 schrieb Markus Blatt: When I look at the package tracker https://tracker.debian.org/pkg/opm-common I see "unsatisfied dependency on libfmt7 (>= 7.1.3+ds1)" that is blocking migration to testing. Current version of libfmt in unstable is 8.1.1+ds1-2. And the current library package of libfmt source package is called libfmt8 and not libfmt7. To resolve this I guess the package needs to be rebuilt. Does that require reuploading or is there another way? Markus
Bug#994272: New packages for release 2021.10 of OPM
Dear all, I have packaged the new release 2021.10-1. You can find the packages on mentors.debian.org: https://mentors.debian.net/package/opm-common/ https://mentors.debian.net/package/opm-material/ https://mentors.debian.net/package/opm-grid/ https://mentors.debian.net/package/opm-models/ https://mentors.debian.net/package/opm-simulators/ https://mentors.debian.net/package/opm-upscaling/ or salsa.debian.org: https://salsa.debian.org/science-team/opm-common https://salsa.debian.org/science-team/opm-material https://salsa.debian.org/science-team/opm-grid https://salsa.debian.org/science-team/opm-models https://salsa.debian.org/science-team/opm-simulators https://salsa.debian.org/science-team/opm-upscaling Looking forward to the reviews and comments. Cheers, Markus
Bug#994272: Continuing packaging effort (was: Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)
Hi, We are still looking for a sponsor for the OPM packages. FYI: We are about to release the next upstream version 2021.10 and intend to update the prospective Debian packages (see [0], [1] for all details). Any comments and recommendations about the current packages are of course welcome and we will try to incorporate them. It might of course make sense to wait with uploading to NEW for the new release. I will report when the packages for the new release are available. What OPM is and why it should be in Debian: The Open Porous Media (OPM) software suite provides libraries and tools for modeling and simulation of porous media processes, especially for simulating CO2 sequestration and improved and enhanced oil recovery. Its main part is a blackoil reservoir simulator with file input and output compatible with a major commercial oil reservoir simulator. On some cases it clearly outperforms the commercial one. Being open source it lowers the bar for starting simulations and is used by industry, research institutes and quite a few small consultancies. Looking foward to your reviews and sponsoring efforts Cheers, Markus [0] https://lists.debian.org/debian-mentors/2021/09/msg00055.html [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994272
Bug#994272: Acknowledgement (RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite)
Hi Two additional comments: These packages depend on dune-common, dune-geometry, dune-grid, dune-istl, for which Debian is currently uploading new versions to experimental. Therefore I have also tested the build with the dune packages from experimental. If it is more suitable for you to have RFS for each individual package, I will gladly do that. The intention of just one ITP and RFS bug was to make clear that there are dependencies between these packages. Regads, -- Markus
Bug#994272: RFS: opm-{common|material|grid|models|simulators|upscaling}/2021.04-1 [ITP] -- opm -- Open Porous Media Software Suite
tors - Python wrappers for the Open porous media / reservoir simulators libopm-simulators-doc - Open porous media / reservoir simulators -- documentation libopm-simulators-bin - Parallel porous media / reservoir simulators -- applications libopm-simulators - Open porous media / reservoir simulators -- library libopm-simulators-dev - Parallel porous media / reservoir simulators -- development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opm-simulators/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opm-simulators/opm- simulators_2021.04-1.dsc Changes for the initial release: opm-simulators (2021.04-1) unstable; urgency=medium . * Initial release (Closes: #987381) 6. opm-upscaling * Package name: opm-upscaling Version : 2021.04-1 Upstream Author : o...@opm-project.org * URL : http://opm-project.org * License : GPL-3.0+ * Vcs : https://salsa.debian.org/science-team/opm-upscaling Section : libs It builds those binary packages: libopm-upscaling-doc - Porous media upscaling tools -- documentation libopm-upscaling - Porous media upscaling tools -- library libopm-upscaling-bin - Porous media upscaling tools -- applications libopm-upscaling-dev - Porous media upscaling tools -- development files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/opm-upscaling/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/o/opm-upscaling/opm- upscaling_2021.04-1.dsc Changes for the initial release: opm-upscaling (2021.04-1) unstable; urgency=medium . * Initial release (Closes: #987381) Thanks a lot for your help Regards, -- Markus Blatt -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
