Bug#989552: [patch] expand description of --variant
Package: debootstrap Severity: wishlist Tags: patch Thanks Hello please consider applying this small patch to the manpage. Kind regards Vince From 1e15507bacfb2547e1c2bace7c3781dd3ab2f45c Mon Sep 17 00:00:00 2001 From: Vincent McIntyre Date: Mon, 7 Jun 2021 20:29:08 +1000 Subject: [PATCH] Improve description of --variant A discussion on debian-boot@lists.d.o elicited an explanation of how deboostrap selects packages to install, which seems to be a point of confusion for some users While here, add a colon before the first item in the list of variants. --- debootstrap.8 | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/debootstrap.8 b/debootstrap.8 index e3ed5d7..2527707 100644 --- a/debootstrap.8 +++ b/debootstrap.8 @@ -80,7 +80,10 @@ set this option to track them through debootstrap.log. .IP .IP "\fB\-\-variant=minbase|buildd|fakechroot\fP" Name of the bootstrap script variant to use. -Currently, the variants supported are minbase, which only includes +Debootstrap reads the Packages file and determines which packages +to install based on the \fIPriority:\fR field of each package and +the selected variant. +Currently, the variants supported are: minbase, which only includes \fIrequired\fR packages and apt; buildd, which installs the build-essential packages and fakechroot, which installs the packages without root privileges. The default, with no \fB\-\-variant=X\fP argument, is to create a -- 2.31.1 --
Bug#985502: release-notes: suggestions for usrmerge section
On Sun, Mar 21, 2021 at 11:33:38AM +, Justin B Rye wrote: >Paul Gevers wrote: >>> I'd forgotten the *Buster* release notes *do* mention usrmerge: >>> >>> https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.html#merged-usr >>> >>> but we've taken that part out now. Could we perhaps recycle the >>> phrase "the usrmerge package exists to do the conversion if desired"? >> >> Sounds like a plan. > >That would give us something like the attached... >-- >JBRwith qualifications in linguistics, experience as a Debian > sysadmin, and probably no clue about this particular package >diff --git a/en/issues.dbk b/en/issues.dbk >index 4377402b..f926c775 100644 >--- a/en/issues.dbk >+++ b/en/issues.dbk >@@ -231,12 +231,18 @@ information mentioned in . > > > >-Historically there was a reason to split root level >-bin, sbin and >-lib directories into >-/usr/, but that is no more. Debian >-bullseye will be the last Debian release that supports the >-non-merged-usr layout. >+ The historical justifications for the filesystem layout with >+ /bin, /sbin, and >+ /lib directories separate from their >+ equivalents under /usr no longer apply >+ today; see the + >url="https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge;>Freedesktop.org >+ summary. Debian bullseye will be the last Debian >+ release that supports the non-merged-usr layout; for systems >+ with a legacy layout that have been upgraded without a >+ reinstall, the + role="package">usrmerge package exists to do >+ the conversion if desired. > > > This looks pretty good but that last sentence makes me wish for something blunter (at the cost of more translation effort I guess) + summary. Debian bullseye will be the last Debian + release that supports the non-merged-usr layout. If you + want to convert your system from the legacy layout to the + new layout, install the + usrmerge package. Thanks for your work on this issue Vince
Bug#984560: NIS binary maps could be broken after upgrades, due to GDBM oddities
On Fri, Mar 05, 2021 at 09:51:34AM +0100, Francesco P. Lovergine wrote: Thank you for the quick reply. I agree with all your points and that there's little to be done but document the issue. I'm happy for this to be closed. If both buster & bullseye link with libgdbm6 then I agree it's unlikely this issue will arise during upgrades. I plan to send a wishlist patch for the nis.debian.howto, or a new README.Debian file - hopefully that will be useful. Do you prefer bugs+patches or PRs? Kind regards Vince
Bug#984560: nis: first byte in map changed
Package: nis
Version: 3.17.1-3+b1
Severity: important
This is a very irritating bug.
It may not be worth fixing but it should be recorded.
Between stretch and buster, something subtle changed in makedbm.
A map produced by the makedbm in stretch starts with the byte 0xCE.
A map produced by the nakedbm in buster starts with the byte 0xCF.
This makes it impossible for stretch clients to understand the
contents of the map file, they just give up.
Steps to reproduce:
run the comamds below on a stretch & a buster host
1. cat >test.source
one
two
three
^D
2. awk -F: '{printf "%s\t%s\n",$1,$1}' test.source | \
/usr/lib/yp/makedbm --no-limit-check -c \
-m testhost -i /tmp/test.source -o /tmp/test.map - test.map
3. xxd -l 10 test.map
: ce9a 5713 0010 0010 ..W...
On a stretch host you get the result above.
On a buster host you get
xxd -l 10 test.map
: cf9a 5713 0010 0010 ..W...
On a buster host, makedbm is happy with the new format
buster$ /usr/lib/yp/makedbm -u test.map
one one
three three
YP_INPUT_NAME /tmp/test.source
YP_LAST_MODIFIED 1614914067
YP_MASTER_NAME testhost
two two
YP_OUTPUT_NAME /tmp/test.map
On a stretch host, not so much
stretch$ scp buster:/tmp/test.map buster.map
stretch$ makedbm -u buster.map
makedbm: Cannot open buster.map
stretch's ypxfr is also unimpressed with the shiny new format.
This poses a problem when you are upgrading a mix of
stretch & buster hosts. The problem can likely be avoided
if you upgrade any NIS slave servers before the master,
but can create a significant issue if you do the master first.
The change might have occurred because makedbm, ypxfr etc on buster
are making use of libgdbm6 while stretch uses libgdbm3.
sretch$ ldd /usr/lib/yp/makedbm
linux-vdso.so.1 (0x7ffd474f8000)
libgdbm.so.3 => /usr/lib/x86_64-linux-gnu/libgdbm.so.3
(0x7f535fc5e000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f535fa46000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f535f6a7000)
buster$ ldd /usr/lib/yp/makedbm
linux-vdso.so.1 (0x7ffc95de3000)
libgdbm.so.6 => /lib/x86_64-linux-gnu/libgdbm.so.6 (0x7f5d78069000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f5d7805)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5d77e8f000)
/lib64/ld-linux-x86-64.so.2 (0x7f5d78091000)
Suggested fix: a nice fat NEWS entry explaining the change in
libgdm depenency and admonishing people to update slaves first.
(Assuming my theory is right, of course...)
Kind regards
Vince
Extra info:
affected release: buster
linux kernel: 4.19.0-14-amd64 4.19.171-2 (2021-01-30) x86_64
Related packages: libgdbm3 1.8.3-14, libgdbm6 1.18.1-4
Bug#906918: fixed upstream
I think these issues should be fixed by upstream now https://github.com/karelzak/util-linux/commit/4b447adf50c61125c57922cc01ec3e6792cc48af#diff-ebbebd514b5c6a5308506642a9de143627256373989a032476e00fb44ec2a27a --
Bug#966172: possible fix
Tags: patch This (tested) patch works around the FTBFS in a sid amd64 schroot. @@ -68,9 +68,9 @@ build-stamp: $(64-BIT_BUILD_STAMP) cd $(bdir); $(curdir)/makemake $(curdir) linux g77_gcc # changeperl no longer necessary - upstream uses /usr/bin/perl now # perl debian/changeperl - cd $(bdir);make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU -O3" all;make clean;make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU -O3" cpg;make pgplot.html;make pgplot-routines.tex + cd $(bdir);make FFLAGC="-u -Wall -O2 -fallow-argument-mismatch" CFLAGC="-Wall -DPG_PPU -O3" all;make clean;make FFLAGC="-u -Wall -O2" CFLAGC="-Wall -DPG_PPU -O3" cpg;make pgplot.html;make pgplot-routines.tex # -cd $(bdir); rm *.o - cd $(bdir) ; make clean; make FFLAGC="-u -Wall -O2 -fPIC" CFLAGC="-Wall -fPIC -D_REENTRANT -DPG_PPU -O3" VM="$(version_major)" shared cpg-shared + cd $(bdir) ; make clean; make FFLAGC="-u -Wall -O2 -fPIC -fallow-argument-mismatch" CFLAGC="-Wall -fPIC -D_REENTRANT -DPG_PPU -O3" VM="$(version_major)" shared cpg-shared touch build-stamp clean: --
Bug#973269: Acknowledgement (openjdk-11-jdk-headless - upgrade to 11.0.9+11-1~deb10u1 removes default-jdk)
please close this duplicate of 973268. apologies for the resend.
Bug#973269: openjdk-11-jdk-headless - upgrade to 11.0.9+11-1~deb10u1 removes default-jdk
Package: openjdk-11-jdk-headless Version: 11.0.9+11-1~deb10u1 Severity: minor This was a suprise, but perhaps it's intended behaviour. Please close if so. * What led up to the situation? These packages were waiting for upgrade openjdk-11-jre 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 openjdk-11-jdk-headless 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 openjdk-11-jre-headless 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 but were being held back. * What exactly did you do (or not do)... # apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following package was automatically installed and is no longer required: default-jdk-headless Use 'sudo apt autoremove' to remove it. The following packages will be REMOVED: default-jdk openjdk-11-jdk The following packages will be upgraded: openjdk-11-jdk-headless openjdk-11-jre openjdk-11-jre-headless 3 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. Need to get 254 MB of archives. After this operation, 1,438 kB disk space will be freed. Do you want to continue? [Y/n] y * What was the outcome of this action? Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done (Reading database ... 272409 files and directories currently installed.) Removing default-jdk (2:1.11-71) ... Removing openjdk-11-jdk:amd64 (11.0.8+10-1~deb10u1) ... (Reading database ... 272393 files and directories currently installed.) Preparing to unpack .../openjdk-11-jre_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Preparing to unpack .../openjdk-11-jdk-headless_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jdk-headless:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Preparing to unpack .../openjdk-11-jre-headless_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre-headless:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Setting up openjdk-11-jre-headless:amd64 (11.0.9+11-1~deb10u1) ... Installing new version of config file /etc/java-11-openjdk/jfr/default.jfc ... Installing new version of config file /etc/java-11-openjdk/jfr/profile.jfc ... Installing new version of config file /etc/java-11-openjdk/security/blacklisted.certs ... Installing new version of config file /etc/java-11-openjdk/security/java.security ... Installing new version of config file /etc/java-11-openjdk/security/public_suffix_list.dat ... Setting up openjdk-11-jre:amd64 (11.0.9+11-1~deb10u1) ... Setting up openjdk-11-jdk-headless:amd64 (11.0.9+11-1~deb10u1) ... Processing triggers for mime-support (3.62) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for desktop-file-utils (0.23-4) ... * What outcome did you expect instead? I wasn't expecting the default-* packages to be removed and I'm not quite sure why they were, because they don't declare a versioned dependency on the specific implementation, details below. It notice there is a versioned Conflicts but it's unclear to me how that could be the problem. $ apt-cache show default-jdk| egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: default-jre (= 2:1.11-71), default-jdk-headless (= 2:1.11-71), openjdk-11-jdk $ apt-cache show default-jdk-headless | egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: default-jre-headless (= 2:1.11-71), openjdk-11-jdk-headless $ apt-cache show default-jre-headless | egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: openjdk-11-jre-headless, java-common $ apt-cache show openjdk-11-jdk | egrep -e '(Ver|Dep|Conf)' Version: 11.0.9+11-1~deb10u1 Depends: openjdk-11-jre (= 11.0.9+11-1~deb10u1), openjdk-11-jdk-headless (= 11.0.9+11-1~deb10u1), libc6 (>= 2.2.5), zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jre-headless (<< 11~19-2) Version: 11.0.8+10-1~deb10u1 Depends: openjdk-11-jre (= 11.0.8+10-1~deb10u1), openjdk-11-jdk-headless (= 11.0.8+10-1~deb10u1), libc6 (>= 2.2.5), zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jre-headless (<< 11~19-2) $ apt-cache show openjdk-11-jre-headless | egrep -e '(Ver|Dep|Conf)' Version: 11.0.9+11-1~deb10u1 Depends: ca-certificates-java (>= 20190405~), java-common (>= 0.28), libcups2, liblcms2-2 (>= 2.2+git20110628), libjpeg62-turbo (>= 1.3.1), libfontconfig1, libnss3 (>= 2:3.17.1), util-linux (>= 2.26.2-4), libasound2 (>= 1.0.16), libc6 (>= 2.27), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:3.4), libpcsclite1 (>= 1.3.0), libstdc++6 (>= 4.1.1), libx11-6, libxext6, libxi6, libxrender1, libxtst6, zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jdk-headless (<< 11~18-2), oracle-java11-installer Version: 11.0.8+10-1~deb10u1 Depends: ca-certificates-java (>= 20190405~), java-common (>= 0.28), libcups2, liblcms2-2 (>= 2.2+git20110628), libjpeg62-turbo (>= 1.3.1), libfontconfig1, libnss3 (>= 2:3.17.1), util-linux (>= 2.26.2-4), libasound2 (>= 1.0.16), libc6 (>= 2.27), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:3.4),
Bug#973268: openjdk-11-jdk-headless - upgrade to 11.0.9+11-1~deb10u1 removes default-jdk
Package: openjdk-11-jdk-headless Version: 11.0.9+11-1~deb10u1 Severity: minor This was a suprise but perhaps intended. Please close if so. * What led up to the situation? These packages were waiting for upgrade openjdk-11-jre 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 openjdk-11-jdk-headless 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 openjdk-11-jre-headless 11.0.8+10-1~deb10u1 -> 11.0.9+11-1~deb10u1 but were being held back. * What exactly did you do (or not do)... # apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following package was automatically installed and is no longer required: default-jdk-headless Use 'sudo apt autoremove' to remove it. The following packages will be REMOVED: default-jdk openjdk-11-jdk The following packages will be upgraded: openjdk-11-jdk-headless openjdk-11-jre openjdk-11-jre-headless 3 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. Need to get 254 MB of archives. After this operation, 1,438 kB disk space will be freed. Do you want to continue? [Y/n] y * What was the outcome of this action? Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done (Reading database ... 272409 files and directories currently installed.) Removing default-jdk (2:1.11-71) ... Removing openjdk-11-jdk:amd64 (11.0.8+10-1~deb10u1) ... (Reading database ... 272393 files and directories currently installed.) Preparing to unpack .../openjdk-11-jre_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Preparing to unpack .../openjdk-11-jdk-headless_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jdk-headless:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Preparing to unpack .../openjdk-11-jre-headless_11.0.9+11-1~deb10u1_amd64.deb ... Unpacking openjdk-11-jre-headless:amd64 (11.0.9+11-1~deb10u1) over (11.0.8+10-1~deb10u1) ... Setting up openjdk-11-jre-headless:amd64 (11.0.9+11-1~deb10u1) ... Installing new version of config file /etc/java-11-openjdk/jfr/default.jfc ... Installing new version of config file /etc/java-11-openjdk/jfr/profile.jfc ... Installing new version of config file /etc/java-11-openjdk/security/blacklisted.certs ... Installing new version of config file /etc/java-11-openjdk/security/java.security ... Installing new version of config file /etc/java-11-openjdk/security/public_suffix_list.dat ... Setting up openjdk-11-jre:amd64 (11.0.9+11-1~deb10u1) ... Setting up openjdk-11-jdk-headless:amd64 (11.0.9+11-1~deb10u1) ... Processing triggers for mime-support (3.62) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for desktop-file-utils (0.23-4) ... * What outcome did you expect instead? I wasn't expecting the default-* packages to be removed and I'm not quite sure why they were, because they don't declare a versioned dependency on the specific implementation, details below. I notice there is a versioned Conflicts but it's unclear to me how that could be the problem. Kind regards $ apt-cache show default-jdk| egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: default-jre (= 2:1.11-71), default-jdk-headless (= 2:1.11-71), openjdk-11-jdk $ apt-cache show default-jdk-headless | egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: default-jre-headless (= 2:1.11-71), openjdk-11-jdk-headless $ apt-cache show default-jre-headless | egrep -e '(Ver|Dep)' Version: 2:1.11-71 Depends: openjdk-11-jre-headless, java-common $ apt-cache show openjdk-11-jdk | egrep -e '(Ver|Dep|Conf)' Version: 11.0.9+11-1~deb10u1 Depends: openjdk-11-jre (= 11.0.9+11-1~deb10u1), openjdk-11-jdk-headless (= 11.0.9+11-1~deb10u1), libc6 (>= 2.2.5), zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jre-headless (<< 11~19-2) Version: 11.0.8+10-1~deb10u1 Depends: openjdk-11-jre (= 11.0.8+10-1~deb10u1), openjdk-11-jdk-headless (= 11.0.8+10-1~deb10u1), libc6 (>= 2.2.5), zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jre-headless (<< 11~19-2) $ apt-cache show openjdk-11-jre-headless | egrep -e '(Ver|Dep|Conf)' Version: 11.0.9+11-1~deb10u1 Depends: ca-certificates-java (>= 20190405~), java-common (>= 0.28), libcups2, liblcms2-2 (>= 2.2+git20110628), libjpeg62-turbo (>= 1.3.1), libfontconfig1, libnss3 (>= 2:3.17.1), util-linux (>= 2.26.2-4), libasound2 (>= 1.0.16), libc6 (>= 2.27), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:3.4), libpcsclite1 (>= 1.3.0), libstdc++6 (>= 4.1.1), libx11-6, libxext6, libxi6, libxrender1, libxtst6, zlib1g (>= 1:1.1.4) Conflicts: openjdk-11-jdk-headless (<< 11~18-2), oracle-java11-installer Version: 11.0.8+10-1~deb10u1 Depends: ca-certificates-java (>= 20190405~), java-common (>= 0.28), libcups2, liblcms2-2 (>= 2.2+git20110628), libjpeg62-turbo (>= 1.3.1), libfontconfig1, libnss3 (>= 2:3.17.1), util-linux (>= 2.26.2-4), libasound2 (>= 1.0.16), libc6 (>= 2.27), libfreetype6 (>= 2.3.5), libgcc1 (>= 1:3.4),
Bug#966172: possible fix
I'm wondering if the error gcc is throwing is really a valid error. These mismatches are coming because an INGEGER*8 is being passed via %VAL() so this is actually passing by value (instead of the usual fortran pass-by-reference). For the first error at line 248, - PIXMAP is initialised by a GRGMEM call at line 238 which is a C function (sys/grgmem.c). - the GRGIO3 function declares the relevant argument type BYTE. It's a similar situation for the other errors. I think there's a resonable case for handling this FTBFS by adding -fallow-argument-mismatch to the compiler arguments for the make rules that build this module. Vince
Bug#964361: wsclean: FTBFS in sid schroot with 'debian/rules binary'
Package: wsclean Version: 2.9-2 Severity: minor I was trying to build this version on buster and got build failures. I tried in a sid schroot and got the same failure, so reporting. I was building with 'debian/rules binary'. Also tried 'debian/rules build; debian/rules binary', as per [1]. Building with 'dpkg-buildpackage -us -uc -b' does work, however. If this is expected behaviour, please just close the bug. Everything is fine up until the dh_install stage, which fails like this: make[2]: Entering directory '/var/tmp/wsclean/obj-x86_64-linux-gnu' make[2]: Nothing to be done for 'preinstall'. make[2]: Leaving directory '/var/tmp/wsclean/obj-x86_64-linux-gnu' Install the project... /usr/bin/cmake -P cmake_install.cmake -- Install configuration: "None" -- Installing: /var/tmp/wsclean/debian/tmp/usr/bin/wsclean -- Set runtime path of "/var/tmp/wsclean/debian/tmp/usr/bin/wsclean" to "/usr/lib:/usr/lib/x86_64-linux-gnu/hdf5/serial" -- Installing: /var/tmp/wsclean/debian/tmp/usr/lib/libwsclean.a -- Installing: /var/tmp/wsclean/debian/tmp/usr/include/wscleaninterface.h make[1]: Leaving directory '/var/tmp/wsclean/obj-x86_64-linux-gnu' dh_install dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean*.so.*" (tried in ., debian/tmp) dh_install: libwsclean2 missing files: usr/lib/*/libwsclean*.so.* dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean.a" (tried in ., debian/tmp) dh_install: wsclean-dev missing files: usr/lib/*/libwsclean.a dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean.so" (tried in ., debian/tmp) dh_install: wsclean-dev missing files: usr/lib/*/libwsclean.so dh_install: missing files, aborting make: *** [debian/rules:10: binary] Error 25 I noticed that libwsclean.a ends up in debian/tmp/usr/lib/libwsclean.a rather than in debian/tmp/usr/lib/x86_64-linux-gnu/libwsclean.a which may be significant. There are no files in debian/tmp/usr/lib/x86_64-linux-gnu/ and that directory does not exist. Kind regards Vince [1] https://www.debian.org/doc/manuals/maint-guide/build.en.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages wsclean depends on: ii libc62.30-8 ii libgcc-s110.1.0-4 ii libstdc++6 10.1.0-4 pn libwsclean2 wsclean recommends no packages. Versions of packages wsclean suggests: pn wsclean-dev # git remote -v origin https://salsa.debian.org/debian-astro-team/wsclean.git (fetch) origin https://salsa.debian.org/debian-astro-team/wsclean.git (push) # git log -1 commit 387fecd8cfdc88c86b46c0a8c1195b2e779e6d2d (HEAD -> master, tag: debian/2.9-2, origin/master, origin/HEAD) Author: Ole Streicher Date: Tue Apr 28 08:37:40 2020 +0200 No-change source-only re-upload
Bug#964112: collectd: [patch] update debian/watch
Source: collectd Version: [patch] update debian/watch Severity: minor Tags: patch The naming scheme for github tags seems to differ from collectd.org. diff --git a/debian/watch b/debian/watch index 5ba76a4..a07f606 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,2 @@ version=3 -https://github.com/collectd/collectd/tags /collectd/collectd/archive/stable-([0-9.-]+).tar.gz +https://github.com/collectd/collectd/tags /collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz % uscan -v uscan info: uscan (version 2.19.5+deb10u1) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="collectd" version="5.11.0-3" (as seen in debian/changelog) uscan info: package="collectd" version="5.11.0" (no epoch/revision) uscan info: ./debian/changelog sets package="collectd" version="5.11.0" uscan info: Process watch file at: debian/watch package = collectd version = 5.11.0 pkg_dir = . uscan info: Last orig.tar.* tarball version (from debian/changelog): 5.11.0 uscan info: Last orig.tar.* tarball version (dversionmangled): 5.11.0 uscan info: Requesting URL: https://github.com/collectd/collectd/tags uscan info: Matching pattern: (?:(?:https://github.com)?\/collectd\/collectd\/tags)?/collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz uscan info: Found the following matching hrefs on the web page (newest first): /collectd/collectd/archive/collectd-5.11.0.tar.gz (collectd.5.11.0) index=collectd.5.11.0-1 /collectd/collectd/archive/collectd-5.10.0.tar.gz (collectd.5.10.0) index=collectd.5.10.0-1 /collectd/collectd/archive/collectd-5.9.2.tar.gz (collectd.5.9.2) index=collectd.5.9.2-1 /collectd/collectd/archive/collectd-5.9.1.tar.gz (collectd.5.9.1) index=collectd.5.9.1-1 /collectd/collectd/archive/collectd-5.9.0.tar.gz (collectd.5.9.0) index=collectd.5.9.0-1 /collectd/collectd/archive/collectd-5.8.1.tar.gz (collectd.5.8.1) index=collectd.5.8.1-1 /collectd/collectd/archive/collectd-5.8.0.tar.gz (collectd.5.8.0) index=collectd.5.8.0-1 /collectd/collectd/archive/collectd-5.6.3.tar.gz (collectd.5.6.3) index=collectd.5.6.3-1 /collectd/collectd/archive/collectd-2.0.1.tar.gz (collectd.2.0.1) index=collectd.2.0.1-1 uscan info: Looking at $base = https://github.com/collectd/collectd/tags with $filepattern = /collectd/collectd/archive/(collectd|stable)-([0-9.-]+).tar.gz found $newfile = /collectd/collectd/archive/collectd-5.11.0.tar.gz $newversion = collectd.5.11.0 which is newer than $lastversion = 5.11.0 uscan info: Matching target for downloadurlmangle: https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz uscan info: Upstream URL(+tag) to download is identified as https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz uscan info: Filename (filenamemangled) for downloaded file: collectd-5.11.0.tar.gz uscan: Newest version of collectd on remote site is collectd.5.11.0, local version is 5.11.0 uscan:=> Newer package available from https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz uscan info: Downloading upstream package: collectd-5.11.0.tar.gz uscan info: Requesting URL: https://github.com/collectd/collectd/archive/collectd-5.11.0.tar.gz uscan info: Successfully downloaded package: collectd-5.11.0.tar.gz uscan info: Start checking for common possible upstream OpenPGP signature files uscan info: End checking for common possible upstream OpenPGP signature files uscan info: Missing OpenPGP signature. uscan info: New orig.tar.* tarball version (oversionmangled): collectd.5.11.0 uscan info: Launch mk-origtargz with options: --package collectd --version collectd.5.11.0 --compression default --directory .. --copyright-file debian/copyright ../collectd-5.11.0.tar.gz Successfully symlinked ../collectd-5.11.0.tar.gz to ../collectd_collectd.5.11.0.orig.tar.gz. uscan info: New orig.tar.* tarball version (after mk-origtargz): collectd.5.11.0 uscan info: Scan finished -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) --
Bug#963834: isync: new upstream version
Package: isync Version: 1.3.0-2 Severity: wishlist Dear Maintainer, there seems to be a new upstream version (mid-2019) but for some reason the PTS is not noticing that. Updating looks relatively straightforward, though obviously more involved than my simple test below. Kind regards Vince % git clone https://salsa.debian.org/debian/isync.git % cd isync % uscan uscan: Newest version of isync on remote site is 1.3.1, local version is 1.3.0 uscan:=> Newer package available from https://qa.debian.org/watch/sf.php/isync/isync-1.3.1.tar.gz Successfully symlinked ../isync-1.3.1.tar.gz to ../isync_1.3.1.orig.tar.gz. % uupdate ../isync_1.3.1.orig.tar.g % cd ../isync-1.3.1 % debuild -uc -uc -b % echo $? 0 -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages isync depends on: ii libc6 2.28-10 ii libdb5.35.3.28+dfsg1-0.5 ii libsasl2-2 2.1.27+dfsg-1+deb10u1 ii libssl1.1 1.1.1d-0+deb10u3 ii zlib1g 1:1.2.11.dfsg-1 isync recommends no packages. Versions of packages isync suggests: ii mutt 1.10.1-2.1+deb10u2 -- no debconf information
Bug#962925: partman-efi: improve non_efi_system question
Package: partman-efi Version: 84 Severity: minor If find the partman-efi/non_efi_system question somewhat confusing. If one sets it to 'false' that means the installer will configure the system for BIOS mode booting, even if the installer is running in EFI mode. If one sets it 'true', then even if there are partitions that look like they require non-EFI booting, the system will be set up to boot in EFI mode. The default is not indicated in the template but seems to be 'false'. I feel this could be improved by either inverting the logic of the setting or changing the question name. If we think how 'non_efi_system: false' reads (to a nonspecialist) it suggests we have an EFI(-only) system, does it not? But in fact it is intended to mean the opposite case. A better question name might be: partman-efi/efi_boot_only. This would work with the existing logic settings and I think conveys the intent of the question more clearly. I'm not sure how name changes like this are effected in d-i, presumably one adds the new one and starts a deprecation of the old one? Kind regards Vince tiny patch to show what the default setting is: diff --git a/debian/partman-efi.templates b/debian/partman-efi.templates index af3f8e4..cf766da 100644 --- a/debian/partman-efi.templates +++ b/debian/partman-efi.templates @@ -44,6 +44,7 @@ _Description: EFI partition too small Template: partman-efi/non_efi_system Type: boolean +Default: false # :sl2: _Description: Force UEFI installation? This machine's firmware has started the installer in UEFI mode but
Bug#924290: [rfc] information about EFI partitions
On Mon, Jun 01, 2020 at 02:34:40PM +1000, Vincent McIntyre wrote:
>
>Revised patch below. I'll test it on amd64 and let you know
>if it works.
This has now been tested on a number of installs and works ok.
I think it's good to go now.
The partman-efi/non_efi_system question is somewhat confusing,
but setting it to 'true' is what one wants if you want to be sure
the system boots in EFI mode.
Regards
Vince
>diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
>index d7570d6b3..9757883b3 100644
>--- a/en/appendix/preseed.xml
>+++ b/en/appendix/preseed.xml
>@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
># system labels, volume group names and which physical devices to include
># in a volume group.
>
>+## Partitioning for EFI
>+# If your system needs an EFI partition you could add something like
>+# this to the recipe above, as the first element in the recipe:
>+# 538 538 1075 free \
>+# $iflabel{ gpt } \
>+# $reusemethod{ } \
>+# method{ efi } \
>+# format{ } \
>+# . \
>+#
>+# The fragment above is for the amd64 architecture; the details may be
>+# different on other architectures. The 'partman-auto' package in the
>+# D-I source repository may have an example you can follow.
>+
># This makes partman automatically partition without confirmation, provided
># that you told it what to do using one of the methods above.
>d-i partman-partitioning/confirm_write_new_label boolean true
>@@ -1213,6 +1232,12 @@ d-i partman/choose_partition select finish
>d-i partman/confirm boolean true
>d-i partman/confirm_nooverwrite boolean true
>
>+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
>+#d-i partman-efi/non_efi_system boolean true
>+# Ensure the partition table is GPT - this is required for EFI
>+#d-i partman-partitioning/choose_label string gpt
>+#d-i partman-partitioning/default_label string gpt
>+
># When disk encryption is enabled, skip wiping the partitions beforehand.
>#d-i partman-auto-crypto/erase_disks boolean false
>
>
--
Bug#911751: fixed in version 0.22.11
Fixed: 0.22.11 I think this bug can be closed. $ apt-show-versions apt-show-versions apt-show-versions:all/buster 0.22.11 uptodate $ sudo apt-mark hold linux-image-amd64 $ apt-show-versions | grep upgradeable linux-image-4.19.0-8-amd64:amd64/buster 4.19.98-1 upgradeable to 4.19.98-1+deb10u1 linux-image-amd64:amd64/buster 4.19+105+deb10u3 upgradeable to 4.19+105+deb10u4 $ apt-show-versions -nh | grep upgradeable linux-image-4.19.0-8-amd64:amd64/buster 4.19.98-1 upgradeable to 4.19.98-1+deb10u1 Kind regards Vince
Bug#961959: Acknowledgement (apt-show-versions: ensure cached files are world-readable)
ah yes, the attachment...
diff --git a/apt-show-versions b/apt-show-versions
index fd0dab4..9bfa3b0 100755
--- a/apt-show-versions
+++ b/apt-show-versions
@@ -36,6 +36,7 @@ use Storable qw(nstore retrieve);
my $apackagescachefile="/var/cache/apt-show-versions/apackages-multiarch";
my $ipackagescachefile="/var/cache/apt-show-versions/ipackages-multiarch";
my $filescachefile="/var/cache/apt-show-versions/files";
+my $cachefilemode=0644;
use AptPkg::Cache;
use AptPkg::Config '$_config';
@@ -195,6 +196,8 @@ if (!-e $filescachefile or -M $list_dir < -M $filescachefile or !ref($filesref))
@files = map { $list_dir . $_} grep /Packages$/, readdir(DIR);
($< == 0) and (nstore(\@files, $filescachefile) or
warn "Can't write $filescachefile\n");
+($< == 0) and (chmod($cachefilemode, $filescachefile) or
+warn "Can't chmod $filescachefile\n");
closedir DIR ;
}
@@ -218,6 +221,8 @@ if (!-e $ipackagescachefile or -M $status_file < -M $ipackagescachefile or !ref(
($ipackages, undef) = parse_file ($status_file, 1);
($< == 0) and (nstore($ipackages, $ipackagescachefile) or
warn "Can't write $ipackagescachefile\n");
+($< == 0) and (chmod($cachefilemode, $ipackagescachefile) or
+warn "Can't chmod $ipackagescachefile\n");
}
# Get available packages list from cache if possible
@@ -274,6 +279,8 @@ if (defined $Storable::recursion_limit_hash) {
# Store if we are root
($< == 0) and (nstore($apackages, $apackagescachefile) or
("Warning: Can't write to $apackagescachefile!\n"));
+($< == 0) and (chmod($cachefilemode, $apackagescachefile));
+
# Exit if we are root and using the -i option
($< == 0) and (exists $opts{'initialize'}) and exit;
Bug#961959: apt-show-versions: ensure cached files are world-readable
Package: apt-show-versions Version: 0.22.11 Severity: normal Tags: patch Dear Maintainer, when root has a restrictive umask, the files it writes in /var/cache/apt-show-versions end up not being readable by normal users, which is somewhat irritating. The attached patch addresses this. It was inspired by https://github.com/rickysarraf/apt-offline/pull/115 Kind regards Vince -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU: en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-show-versions depends on: ii apt 1.8.2.1 ii libapt-pkg-perl 0.1.34+b1 ii perl [libstorable-perl] 5.28.1-6 apt-show-versions recommends no packages. apt-show-versions suggests no packages. -- no debconf information
Bug#924290: [rfc] information about EFI partitions
On Fri, May 29, 2020 at 11:29:17PM +0200, Holger Wansing wrote:
>Hi,
>
>"McIntyre, Vincent (CASS, Marsfield)" wrote:
>> diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
>> index d7570d6b3..817749bb9 100644
>> --- a/en/appendix/preseed.xml
>> +++ b/en/appendix/preseed.xml
>> @@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
>> # system labels, volume group names and which physical devices to include
>> # in a volume group.
>>
>> +## Partitioning for EFI
>> +# If your system needs an EFI partition you could add something like
>> +# this to the recipe above, as the first element in the recipe:
>> +# 538 538 1075 free \
>> +# $iflabel{ gpt } \
>> +# $reusemethod{ } \
>> +# method{ efi } \
>> +# format{ } \
>> +# . \
>> +#
>> +# The fragment above is for the amd64 architecture; the details may be
>> +# different on other architectures. The 'partman-auto' package in the
>> +# D-I source repository may have an example you can follow.
>> +
>> # This makes partman automatically partition without confirmation, provided
>> # that you told it what to do using one of the methods above.
>> d-i partman-partitioning/confirm_write_new_label boolean true
>> @@ -1213,6 +1232,16 @@ d-i partman/choose_partition select finish
>> d-i partman/confirm boolean true
>> d-i partman/confirm_nooverwrite boolean true
>>
>> +# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
>> +#d-i partman-efi/non_efi_system boolean true
>> +# Ensure the partition table is GPT - this is required for EFI
>> +#d-i partman-basicfilesystems/choose_label string gpt
>> +#d-i partman-basicfilesystems/default_label string gpt
>> +#d-i partman-partitioning/choose_label string gpt
>> +#d-i partman-partitioning/default_label string gpt
>> +#d-i partman/choose_label string gpt
>> +#d-i partman/default_label string gpt
>
>I might wonder why this is needed: to set the same setting in three different
>packages...
>However there seem to be a reason for this?
>
I went back and double-checked (this _was_ marked RFC...).
The partman/ questions don't appear to exist, doh! Sorry about that.
partman-basicfilesystems/{choose,default}_label
refer to a +filesystem+ label, tsk. So shouldn't be needed either.
partman-partitioning/default_label
has a platform-specific default that also depends on the disk size
(packages/partman-partitioning/lib/disk-label.sh)
Revised patch below. I'll test it on amd64 and let you know
if it works.
Regards
Vince
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index d7570d6b3..9757883b3 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
# system labels, volume group names and which physical devices to include
# in a volume group.
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+# 538 538 1075 free \
+# $iflabel{ gpt } \
+# $reusemethod{ } \
+# method{ efi } \
+# format{ } \
+# . \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1213,6 +1232,12 @@ d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+# Ensure the partition table is GPT - this is required for EFI
+#d-i partman-partitioning/choose_label string gpt
+#d-i partman-partitioning/default_label string gpt
+
# When disk encryption is enabled, skip wiping the partitions beforehand.
#d-i partman-auto-crypto/erase_disks boolean false
Bug#886642: fixed? (please default to a larger /boot for guided partitioning)
Hi I thought this would have been fixed by this commit https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22 which will be available in the 'daily' build of the installer. I don't know what the prospects are for having this applied to the 'stable' installer. Kind regards Vince
Bug#924290: [rfc] information about EFI partitions
On Sun, May 17, 2020 at 02:34:47PM +0200, Holger Wansing wrote:
>Hi,
>
> wrote:
>> Package: installation-guide
>> Version: 20180930
>> Severity: wishlist
>> Tags: patch
>>
>> Hi
>>
>> recently I was learning about presseding UEFI installs and
>> I think the install guide could use a small addition to make
>> that journey easier. I also sent a patch to partman-auto-recipe.txt
>> but I am sure the readership of that is much less than the d-i manual.
>
>I am unable to proof the patch correct or not, could anyone comment on that?
All I can say is It Works For Us, on plenty of amd64 installs
over the last year. The patch has evolved a little since then,
inline below. Please let me know if you'd rather a MR.
Vince
diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index d7570d6b3..817749bb9 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -1206,6 +1211,20 @@ d-i partman-auto/choose_recipe select atomic
# system labels, volume group names and which physical devices to include
# in a volume group.
+## Partitioning for EFI
+# If your system needs an EFI partition you could add something like
+# this to the recipe above, as the first element in the recipe:
+# 538 538 1075 free \
+# $iflabel{ gpt } \
+# $reusemethod{ } \
+# method{ efi } \
+# format{ } \
+# . \
+#
+# The fragment above is for the amd64 architecture; the details may be
+# different on other architectures. The 'partman-auto' package in the
+# D-I source repository may have an example you can follow.
+
# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
@@ -1213,6 +1232,16 @@ d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
+# Force UEFI booting ('BIOS compatibility' will be lost). Default: false.
+#d-i partman-efi/non_efi_system boolean true
+# Ensure the partition table is GPT - this is required for EFI
+#d-i partman-basicfilesystems/choose_label string gpt
+#d-i partman-basicfilesystems/default_label string gpt
+#d-i partman-partitioning/choose_label string gpt
+#d-i partman-partitioning/default_label string gpt
+#d-i partman/choose_label string gpt
+#d-i partman/default_label string gpt
+
# When disk encryption is enabled, skip wiping the partitions beforehand.
#d-i partman-auto-crypto/erase_disks boolean false
Bug#928813: libapache2-mod-jk: Jk can not find any configured worker
Package: libapache2-mod-jk Version: 1:1.2.46-1 Tags: patch Followup-For: Bug #928813 I am seeing this too. I worked around like this # cd /etc/apache2/mods-available # ln -s httpd-jk.conf jk.conf # a2enmod jk Enabling config file jk.conf. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2 # echo $? 0 If there really is a need to maintain the discordant file naming (which I also think is silly) then either the package needs this change diff --git a/debian/libapache2-mod-jk.links b/debian/libapache2-mod-jk.links index 2baa729..24df524 100644 --- a/debian/libapache2-mod-jk.links +++ b/debian/libapache2-mod-jk.links @@ -1 +1,2 @@ /etc/apache2/mods-available/httpd-jk.conf /etc/libapache2-mod-jk/httpd-jk.conf +/etc/apache2/mods-available/httpd-jk.conf /etc/libapache2/jk.conf or perhaps a modification to the auto-generated postinst --- /var/lib/dpkg/info/libapache2-mod-jk.postinst 2018-10-14 21:26:05.0 +1100 +++ /var/lib/dpkg/info/libapache2-mod-jk.postinst.new 2020-03-09 17:55:20.261264046 +1100 @@ -4,7 +4,7 @@ if true; then if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then . /usr/share/apache2/apache2-maintscript-helper - for conf in jk ; do + for conf in jk httpd-jk ; do apache2_invoke enmod $conf || exit 1 done fi Kind regards Vince -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/16 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libapache2-mod-jk depends on: ii apache2-bin [apache2-api-20120211] 2.4.38-3+deb10u3 ii libc6 2.28-10 libapache2-mod-jk recommends no packages. Versions of packages libapache2-mod-jk suggests: pn libapache-mod-jk-doc ii tomcat9 9.0.16-4 -- Configuration Files: /etc/libapache2-mod-jk/workers.properties changed [not included] -- no debconf information
Bug#952666: typo in dla-2123
Hello Not sure quite where to direct this. This recent DLA https://www.debian.org/lts/security/2020/dla-2123 references the wrong debian bug, 925666. The correct number is 952666. Kind regards Vince
Bug#872890: this can be closed
The issue I reported is fixed in upstream's 1.43.
Bug#947045: Acknowledgement (undefined symbol in libpixbufloader-tiff.so: g_uint_checked_mul)
Forgot to add this $ ldd /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so linux-vdso.so.1 (0x7fff12fb5000) libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x7f2c236e5000) libgdk_pixbuf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x7f2c234c3000) libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x7f2c232bf000) libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x7f2c22f45000) libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x7f2c22cf2000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x7f2c229e3000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7f2c227bc000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2c224bb000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2c2229e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2c21ef3000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2c21cd) libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x7f2c21ac1000) libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7f2c2186a000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2c2164f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2c2144b000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x7f2c21226000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f2c2100f000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f2c20e06000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f2c20b98000) /lib64/ld-linux-x86-64.so.2 (0x7f2c23b61000)
Bug#947045: undefined symbol in libpixbufloader-tiff.so: g_uint_checked_mul
Package: libgdk-pixbuf2.0-0 Version: 2.31.1-2+deb8u8 Severity: normal Dear LTS Maintainer, I noticed this and thought I should report it. ... The following packages will be upgraded: libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 463 kB of archives. After this operation, 2,048 B disk space will be freed. Do you want to continue? [Y/n] Get:1 http://:/security/ jessie/updates/main libgdk-pixbuf2.0-0 amd64 2.31.1-2+deb8u8 [168 kB] Get:2 http://:/security/ jessie/updates/main libgdk-pixbuf2.0-common all 2.31.1-2+deb8u8 [295 kB] Fetched 463 kB in 0s (3,072 kB/s) Reading changelogs... Done (Reading database ... 56214 files and directories currently installed.) Preparing to unpack .../libgdk-pixbuf2.0-0_2.31.1-2+deb8u8_amd64.deb ... Unpacking libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) over (2.31.1-2+deb8u7) ... Preparing to unpack .../libgdk-pixbuf2.0-common_2.31.1-2+deb8u8_all.deb ... Unpacking libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) over (2.31.1-2+deb8u7) ... Setting up libgdk-pixbuf2.0-common (2.31.1-2+deb8u8) ... Setting up libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u8) ... g_module_open() failed for /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so: /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-tiff.so: undefined symbol: g_uint_checked_mul Processing triggers for libc-bin (2.19-18+deb8u10) ... [ Rootkit Hunter version 1.4.2 ] File updated: searched for 177 files, found 149 -- System Information: Debian Release: 8.11 APT prefers oldoldstable APT policy: (990, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-10-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgdk-pixbuf2.0-0 depends on: ii libc62.19-18+deb8u10 ii libgdk-pixbuf2.0-common 2.31.1-2+deb8u8 ii libglib2.0-0 2.42.1-1+deb8u3 ii libjasper1 1.900.1-debian1-2.4+deb8u6 ii libjpeg62-turbo 1:1.3.1-12+deb8u2 ii libpng12-0 1.2.50-2+deb8u3 ii libtiff5 4.0.3-12.3+deb8u10 ii libx11-6 2:1.6.2-3+deb8u2 ii multiarch-support2.19-18+deb8u10 libgdk-pixbuf2.0-0 recommends no packages. libgdk-pixbuf2.0-0 suggests no packages. -- no debconf information
Bug#429510: lintian check
Hello lintian is now checking for this case (NEWS|TODO), see #946126. Regards Vince
Bug#946126: lintian: Please complain about debian/NEWS.Debian
On Thu, Dec 05, 2019 at 03:13:09PM -0800, Felix Lechner wrote:
>Hi Vincent,
>
>On Thu, Dec 5, 2019 at 2:32 PM McIntyre, Vincent (CASS, Marsfield)
> wrote:
>>
>> +} elsif ($basename =~
>> m/^(?:.*\.)?(?:changelog|NEWS|TODO).[dD]ebian$/o) {
>
>My check does not currently implement the lowercase 'd'. Please let me
>know if you would like to have it.
I really don't know what's better. I lean toward adding it.
>> Do you think there should be some restriction to avoid this warning
>> when something other than debhelper is in use?
>
>On something like this, which is both useful and rare, I will wait for
>bug reports to complain.
Sounds like the right choice to me.
>> I'm not sure what that something other would be.
>
>There are other build systems. You can find a relative measure of
>their popularity on https://trends.debian.net/#build-systems.
>
>> - debian/README is ignored
>
>I am reluctant to do anything about it. Is the file sometimes used for
>unpublished developer notes?
I don't know, it seems possible. Now I'm reluctant too.
>> - debian/TODO gets shipped as /usr/share/doc/rkhunter/TODO.Debian,
>>ie not gzipped.
>> - debian/TODO.Debian is ignored.
>
>Thanks for looking into it. I also added TODO:
>
>
> https://salsa.debian.org/lintian/lintian/commit/54e2611c0a65d5377ddb0abb055b8105019e974b
>
>> This was debhelper 12.1.1~bpo9+1, if that matters.
>
>You may wish to amend #429510 with information about the new Lintian
>tags if they work for you. You could even mention the unison bug and
>gently remind the debhelper folks that the issue remains open.
>
Ok.
Regards
Vince
Bug#946126: lintian: Please complain about debian/NEWS.Debian
On Thu, Dec 05, 2019 at 09:50:32AM -0800, Felix Lechner wrote:
>Implemented for NEWS, which was your primary concern:
>
>
> https://salsa.debian.org/lintian/lintian/commit/ae38f4d7301ba8a6064025b86984d49843d61355
>
Looks awesome. I was working on a hack but this is much better.
One question though. This is primarily an issue for debhelper,
I can't see anything in policy that requires these naming minutiae.
So when I started hacking I was playing with checks/debhelper.pm,
something like
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -401,6 +401,9 @@ sub run {
# Handle "control", [.]copyright, [.]changelog
# and [.]NEWS
_tag_if_executable($file);
+} elsif ($basename =~
m/^(?:.*\.)?(?:changelog|NEWS|TODO).[dD]ebian$/o) {
+# Debhelper will ignore changelog-ish files with a .Debian suffix
+tag 'dh-misnamed-changelog-in-source', $file;
} elsif ($basename =~ m/^ex\.|\.ex$/i) {
tag 'dh-make-template-in-source', $file;
} elsif ($basename =~ m/^(?:(.*)\.)?maintscript$/) {
Do you think there should be some restriction to avoid this warning
when something other than debhelper is in use? I'm not sure what
that something other would be.
>> There may already be a similar check for debian/[README|TODO].Debian
>
>I could not find those checks, but would be happy to add the files.
>Unfortunately, I could not figure out from #429510 what the correct
>behavior should be. (For example, both README and README.Debian seem
>to be in use, but only the latter is shipped.) Please reopen the bug
>to add more files.
I think I overinterpreted one of the comments in that bug.
After rereading it (and checking by building a package - rkhunter fwiw),
- debian/README is ignored
- debian/README.Debian is shipped as README.Debian.gz
It seems best to leave things as they are for the README case;
the maintainer may want to have an ignored debian/README file.
I also tested TODO.
- debian/TODO gets shipped as /usr/share/doc/rkhunter/TODO.Debian,
ie not gzipped.
- debian/TODO.Debian is ignored.
This was debhelper 12.1.1~bpo9+1, if that matters.
Cheers
Vince
Bug#946126: lintian: Please complain about debian/NEWS.Debian
On Tue, Dec 03, 2019 at 08:38:55PM -0800, Felix Lechner wrote: >Hi Vincent, > > >> There may already be a similar check for debian/[README|TODO].Debian > >Which tag are you referring to, please? > I'm sorry, I don't know of one. I was just speculating that lintian may have a check like this. Kind regards Vince
Bug#946041: fixed in unison 2.48.4-3 (NEWS.Debian not included)
That would appear to be #429510. This seems like a job for lintian. #946126.
