Bug#1012240: [Pkg-samba-maint] Bug#1012240: winbind does not return AD groups a user is a member of AT ALL, or only one
03.06.2022 05:31, Andrew Bartlett wrote: On Fri, 2022-06-03 at 13:08 +1200, Matt Grant wrote: Otherwise, libwbclient0 ends up being installed when samba-lbs is installed due to depending on samba-libs? I read this like samba-libs uses libwbclient, not like libwbclient uses samba-libs (would be wrong). libwbclient0 should not depend on anything else in Samba (due to licence requirements) so if there is a linking reason for this we should check into this. I did move one more library from samba-libs to libwbclient while packaging 4.16 on debian. Overall, this is the current content of libwbclient0.deb: /usr/lib/x86_64-linux-gnu/libwbclient.so.0.15 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0.0.1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libiov-buf-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libreplace-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libsamba-debug-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libsocket-blocking-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libsys-rw-samba4.so.0 /usr/lib/x86_64-linux-gnu/samba/libtime-basic-samba4.so.0 Some of these has been there before. Some (I think it was just one, can't remember which) were added by me during 4.16 packaging time. One of my todo items about samba states to review which libs are actually used by which binary and move them between packages - somewhat similar to how I moved files between samba-libs and python3-samba packages. When I did 4.16 initially I didn't think much about that aspect, b/c else we'd not have 4.16 now :) Now when I looked at this, I don't see why libsamba-util.so is in there at all. Maybe in 4.13 there was a reason for that, I don't know the reason for it to be there for 4.16. The rest (in /samba/) are ones used by libsamba-utils, it seems. /mjt There have been regressions in the past, so if only expressed in packaging this might be historical.
Bug#1009998: gvfs-backends: Unable to access smb://host/sharing on any file manager after upgrade
Control: tag -1 + moreinfo On Tue, 7 Jun 2022 16:25:47 -0400 Jeremy Bicha wrote: Control: reassign -1 src:samba 2:4.16.0+dfsg-6 Control: affects -1 src:gvfs Control: tags -1 +patch Control: severity -1 important Jeremy, you're adding the "patch" tag here, please tell me which change/patch is supposed to fix the issue. Thanks, /mjt The Debian samba maintainers did not have a chance to see your bug report since this bug is recorded as affecting gvfs not samba. Let me try to fix that up for you now.
Bug#1009998: gvfs-backends: Unable to access smb://host/sharing on any file manager after upgrade
15.06.2022 14:59, L. van Belle wrote: Since im not seeing it apparing in debian mail folder here. Thank you for this Louis! -Oorspronkelijk bericht- Van: L. van Belle Verzonden: woensdag 15 juni 2022 13:47 Aan: '1009...@bugs.debian.org' <1009...@bugs.debian.org> Onderwerp: RE: [Pkg-samba-maint] Processed: Re: Bug#1009998: gvfs- backends: Unable to access smb://host/sharing on any file manager after upgrade Micheal, For the above link/bug reports, which points to : https://gitlab.com/samba-team/samba/- /commit/34771e1931587807d0395c7ac7f4be18654997f4 This fix is already included in 4.16.2. I've just verified the source of 4.16.2 Well, sure I've seen this particular message, but this "fix" is included in 4.16.0 already, FWIW. So the "patch" tag must be due to something else, I guess. This is why I asked for more info here. Thanks, /mjt
Bug#1013205: [Pkg-samba-maint] Bug#1013205: samba-common: samba no longer installable on sparc64 due to impossible version conflict
19.06.2022 03:03, Rich Ercolani wrote: Package: samba-common Version: 2:4.13.5+dfsg-2 Severity: normal X-Debbugs-Cc: rincebr...@gmail.com Dear Maintainer, Pretty simple report - since samba-common is only offered at 2:4.16.2+dfsg-1 in sid currently, and all the binary samba packages for sparc64 are at 2:4.13.14+dfsg-1+b4, it's impossible to install right now without either reaching into the archive snapshots or building yourself. It would be nice if this wasn't breaking "apt upgrade". Samba upstream does not build on sparc. It would be nice it it did, that'd fix this issue. Meanwhile, in order not to break samba on all other architectures, I decided to build current version of samba-common on all other architectures, even if it breaks old version of samba on sparc. Thanks, /mjt
Bug#765936: qemu-system-common: please preserve setuid bit on /usr/lib/qemu/qemu-bridge-helper
Is it sufficient to use dpkg-statoverride --add root root 04755 /usr/lib/qemu/qemu-bridge-helper to fix this on a particular system? (see man dpkg-statoverride for more info). BTW, this helper should be moved to /usr/libexec/qemu/ now.. Thanks, /mjt
Bug#1012240: winbind does not return AD groups a user is a member of AT ALL, or only one
13.06.2022 12:12, Matt Grant wrote: Hi Michael! For the libraries to move from the samba package, just used the following command on each rpcd binary in /usr/libexec/samba: dpkg -S `ldd rpcd_epmapper | grep samba | cut -f 1 -d ' '` I suspected it was something like that. The problem here is that the two libs you moved from samba to the new dcerpc package, are also used by the samba package itself. By moving stuff like this, it is too easy to create a circular dependency, which we had quite a few in the past. I placed libs into the samba package (and to winbind package and some other cases) *only* when those libs are used by those packages and not by other packages. The rest of libraries - the ones which are used by more than a single package - goes to samba-libs. Again, maybe I'm wrong there. Just thought that these libs which are used by a single package *now*, may be used by more than a single package in the future, and I should have a way to check for that, maybe similar to how I check for unneeded inter-package deps in d/rules already, but for more packages. BTW, you forgot the manpage for samba-dcerpcd. For now I moved the executables into samba-common-bin and the two libs into samba-libs. Let's see how it will be, maybe we'll create a new package for it. Thank you for the work and for the inspiration! /mjt
Bug#1012240: winbind does not return AD groups a user is a member of AT ALL, or only one
13.06.2022 10:46, Matt Grant wrote: Hi! Please find attached the patch I made to fix this issue. It moves the DCE RPC binaries in /usr/libexec/samba into their own package along with required libs from the samba package creating the samba-libexec-dcerpc package, and makes samba and winbind depend on it, thus solving all the issues. Matt, how did you find out the 2 libs -- libRPC-SERVER-LOOP-samba4.so.0 & libREG-FULL-samba4.so.0 - which can be moved to the new package too, out of many other libraries in there? Thanks! /mjt
Bug#1012240: winbind does not return AD groups a user is a member of AT ALL, or only one
13.06.2022 10:46, Matt Grant wrote: Hi! Please find attached the patch I made to fix this issue. It moves the DCE RPC binaries in /usr/libexec/samba into their own package along with required libs from the samba package creating the samba-libexec-dcerpc package, and makes samba and winbind depend on it, thus solving all the issues. Michael, could you please incorporate this in the sid samba packages you have created? Thank you for the work Matt! For the start I really want some comments from the samba folks about where/when these binaries are supposed to be used. I understand creating a new package might solve the immediate issue, based on what we observe now. But without knowledge about how it is supposed to work, it's difficult to verify if it's done correctly. And once again, I already suggested moving these binaries to the already existing samba-common-bin - this will definitely fix the issue too, without we waiting for the debian NEW queue processing (there's a separate manual procedure in debian each new binary package have to follow). I'm not convinced a separate binary package is needed (based on what I observe), - yes, smbclient also uses samba-common-bin, but so far it's not a problem, it seems. I might be wrong though. Thank you! /mjt
Bug#1009998: gvfs-backends: Unable to access smb://host/sharing on any file manager after upgrade
13.06.2022 11:49, jim_p wrote: ... Anyway, samba was upgraded to 4.16.2 today from upstream and its changelog mentions something about smbclient, so I hope it is finally fixed. Can you There's nothing in 4.16.2 which is relevant to this issue, FWIW. Thanks, /mjt
Bug#914405: appears to not update auto-trust-anchors without requests
Control: tag -1 - moreinfo It looks there's an upstream TODO item about this: o timers rfc 5011 support. (see /usr/share/doc/unbound/TODO.gz) /mjt
Bug#1003168: qemu-user-static: fails to run lyx user directory configuation
Control: tag -1 + moreinfo On Thu, 13 Jan 2022 16:00:26 +0100 Andreas Beckmann wrote: On 11/01/2022 08.25, Michael Tokarev wrote: > 1. try qemu 6.2 (qemu-user-static is self-contained, more or less, so > it can be installed on earlier debian releases too) same behavior :-( > 2. try to figure out what exactly is failing in there: > >> support/Systemcall.cpp (276): Systemcall: 'python3 -tt >> "/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with >> exit code -1 # t=$(mktemp -d) && cd $t && python3 -tt "/usr/share/lyx/configure.py" --binary-dir="/usr/bin/" ; cd - Succeeds :-( But if that command gets executed from lyx, we are in the realm of Qt::Process. Perhaps if I find time, I can try to extract a minimized example only doing that call... Hi Andreas! Do you know if this issue still present with qemu 7.0? Thanks, /mjt
Bug#1003450: qemu-system: dns resolution does not work within the guest if the host have only nameserver in /etc/resolv.conf
Version: 4.7.0-1 On Mon, 10 Jan 2022 12:40:59 +0100 mc36 wrote: Package: qemu-system Version: 1:6.2+dfsg-1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? i recently moved to an ipv6-only network for testing purposes... * What exactly did you do (or not do) that was effective (or ineffective)? i ceased ipv4 completely from my desktop for a while... * What was the outcome of this action? for example "qemu-system-x86_64 -enable-kvm -cdrom debian-11.2.0-amd64-netinst.iso" cannot complete mirror selection because dns resolution does not work within the guest when resolt.conf have only ipv6 entries... It looks like this problem has been fixed in upstream version 4.7.0 (which I just uploaded but forgot to add the Closes: thisbug). Thanks, /mjt
Bug#1003168: qemu-user-static: fails to run lyx user directory configuation
Control: tag -1 + confirmed
Control: found -1 1:7.0+dfsg-2
I just tried to reproduce this and was able to see the same issue
with qemu-user-static 7.0.
However the issues here is not with python failing.
lyx does not even try to run the python script.
It first spawns /bin/sh -c "python3 -tt -V" in a separate process,
which appears to be successful, next it searches python3 in the $PATH again
(from lyx itself, not from /bin/sh), next it does this:
1790405 faccessat(AT_FDCWD, "/usr/bin/python3", X_OK) = 0
1790405 waitid(P_PIDFD, 2147483647, 0x7fff2c60db70, WNOHANG|WEXITED, NULL) = -1
EBADF (Bad file descriptor)
...
1790405 ppoll([{fd=-1}, {fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=57157936, events=POLLIN}], 4, {tv_sec=180, tv_nsec=0}, NULL, 8) = 3 ([{fd=7,
revents=POLLHUP}, {fd=9, revents=POLLHUP}, {fd=57157936, revents=POLLNVAL}], left {tv_sec=179, tv_nsec=98170})
...
1790405 fcntl(57157936, F_GETFL)= -1 EBADF (Bad file descriptor)
1790405 read(57157936, 0x5503682800, 152) = -1 EBADF (Bad file descriptor)
1790405 write(3, "\1\0\0\0\0\0\0\0", 8) = 8
1790405 close(57157936) = -1 EBADF (Bad file descriptor)
...
1790405 write(2, "support/Systemcall.cpp", 22) = 22
(the last one comes from
support/Systemcall.cpp (276): Systemcall: 'python3 -tt "/usr/share/lyx/configure.py"
--binary-dir="/usr/bin/"' finished with exit code -1
message).
(fd 57157936 is not referenced anywhere except at this place).
I dunno where this fd 57157936 comes from.
And apparently this makes lyx confused.
/mjt
Bug#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host
Control: tag -1 + confirmed upstream Control: found -1 1:7.0+dfsg-1 I was able to reproduce this one, including qemu 7.0 version. /mjt
Bug#999421: qemu-user-static: lli-13/arm64 causes segfault on amd64 host
On Sun, 1 May 2022 13:05:35 +0300 Michael Tokarev wrote: Control: tag -1 + confirmed upstream Control: found -1 1:7.0+dfsg-1 I was able to reproduce this one, including qemu 7.0 version. But unfortunately I hardly can do anything with this bug report. I'd say it is better to ask upstream about this one. /mjt
Bug#995430: qemu-user-static: creates /core dump spontaneously upon upgrade, even when not in use?
Control: tag -1 + moreinfo On Fri, 01 Oct 2021 17:30:16 +1000 Tim Connors wrote: Package: qemu-user-static Version: 1:5.2+dfsg-11 Severity: normal I noticed a /core file in the root directory, dated around about when my machine was upgraded to bullseye. I checked another machine, and it too had the same core file, dated from the upgrade: 24606,4> ls -lA /core -rw--- 1 root root 11542528 Sep 15 00:41 core 0-0-16:27:43, Fri Oct 01 tconnors@fs:/snapshots/dirac/latest (bash) 24607,5> sudo file core core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from '/usr/libexec/qemu-binfmt/s390x-binfmt-P /check /check', real uid: 0, effective uid: 0, real gid: 0, effective gid: 0, execfn: '/check', platform: 'x86_64' Interesting. Do you by a chance also have /check binary? This is apparently something checking for s390x availability, so "not in use" is a bit interesting here in this context. Neither binfmt-support nor systemd does that, and qemu-user-static does not do this either. It is interesting twice: the fact someone tried this s390x abi, and the fact that qemu-s390-static (the binfmt-P is just a symlink to it) crashed with a core dump. It was run as root too (well, or else it wouldn't be able to create /core). It'd be interesting to see the core file and especially the /check binary. Did it happen again since that? Can you reinstall qemu-user-static, or upgrade it again (installing the buster version first) and see if it triggers the issue again? I have no idea what is going on there... Thanks! /mjt
Bug#1010426: ldnsutils: Enable SVCB/HTTPS rrtypes
Control: tag -1 + moreinfo
01.05.2022 14:59, John Shaft wrote:
Package: ldnsutils
Version: 1.8.1-1
Severity: wishlist
Dear Maintainer,
ldns 1.8.0 introduced support for SVCB & HTTPS resource records [1],[2]
It has to be compiled via a specific parameter --enable-rrtype-svcb-https
Could the debian package be shipped with this option enabled ?
From ldns's ./configure --help:
--enable-rrtype-ninfo Enable draft RR type ninfo.
--enable-rrtype-rkeyEnable draft RR type rkey.
--disable-rrtype-openpgpkey
Disable openpgpkey RR type.
--enable-rrtype-ta Enable draft RR type ta.
--enable-rrtype-avc Enable draft RR type avc.
--enable-rrtype-doa Enable draft RR type DOA.
--enable-rrtype-amtrelay
Enable draft RR type AMTRELAY.
--enable-rrtype-svcb-https
Enable draft RR types SVCB and HTTPS.
Neither of these is enabled.
I wonder if we should enable them all.
I don't see any special dependencies for these, it just
an ifdef in rr.c:
#ifdef RRTYPE_SVCB_HTTPS
static const ldns_rdf_type type_svcb_wireformat[] = {
LDNS_RDF_TYPE_INT16,
LDNS_RDF_TYPE_DNAME,
LDNS_RDF_TYPE_SVCPARAMS
};
#endif
#ifdef RRTYPE_SVCB_HTTPS
/* 64 */
{LDNS_RR_TYPE_SVCB, "SVCB", 2, 3, type_svcb_wireformat,
LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },
/* 65 */
{LDNS_RR_TYPE_HTTPS, "HTTPS", 2, 3, type_svcb_wireformat,
LDNS_RDF_TYPE_NONE, LDNS_RR_NO_COMPRESS, 0 },
#else
{LDNS_RR_TYPE_NULL, "TYPE64", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE,
LDNS_RR_NO_COMPRESS, 0 },
{LDNS_RR_TYPE_NULL, "TYPE65", 1, 1, type_0_wireformat, LDNS_RDF_TYPE_NONE,
LDNS_RR_NO_COMPRESS, 0 },
#endif
I wonder why they didn't enable them. If the reason is that these
are DRAFTs, - maybe it's okay to use DRAFT-HTTPS instead of HTTPS there?
Ondřej, do you have any comments about these?
Thanks,
/mjt
Bug#1003063: RFS: su-exec/0.2-1 [ITP] -- switch user and group id, setgroups and exec
03.01.2022 18:05, Matteo Chesi wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "su-exec": * Package name : su-exec Version : 0.2-1 Upstream Author : Natanael Copa * URL : https://github.com/ncopa/su-exec * License : MIT * Vcs : [fill in URL of packaging vcs] Section : admin It builds those binary packages: su-exec - switch user and group id, setgroups and exec How it's different from, say, setpriv? Thanks, /mjt
Bug#924667: qemu-user-static: setting up of binfmt_misc is slightly naive about cpu features
Control: tag -1 + moreinfo On Fri, 15 Mar 2019 15:52:44 + Alex Bennée wrote: Package: qemu-user-static Version: 1:3.1+dfsg-4 Severity: normal Dear Maintainer, Trying to build gitlab-runner on an ThunderX arm64 box it tries to run a docker image with armhf binaries which fails: standard_init_linux.go:207: exec user process caused "exec format error" You can replicate by running: 14:30:41 [root@qemu-test:/v/l/d/info] 1 # uname -a Linux qemu-test 4.20.0 #5 SMP Tue Jan 8 10:57:44 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux 14:30:46 [root@qemu-test:/v/l/d/info] # arch-test -n armhf armhf: not supported on this machine/kernel The underlying reason is because binfmt_misc isn't set up for armhf binaries because qemu-user-static.postinst does: # find which fmts needs to be filtered out, which is arch-dependent. case "$DPKG_MAINTSCRIPT_ARCH" in ... arm | armel | armhf | arm64) omit="arm|aarch64" ;; esac Which is certainly not true for all aarch64 CPUs. Some do not support aarch32. The following change makes it work but requires arch-test as a dependency: ... arm | armel | armhf) omit="arm" ;; arm64 ) if arch-test -n armhf > /dev/null; then omit="arm|aarch64" else omit="aarch64" fi ;; This logic is repeated in the prerm script so there is probably some scope in cleaning up and sharing the logic. Hi Alex! This should be a runtime test on the installed system, I guess. It is more: you might install the system on one hardware but but later run it on a different hardware. So this becomes, I guess, a startup script or a service which checks things at boot and enables/disables this particular format according to arch-test How do you think if this is worth the effort to implement? I understand the basics here (without any knowlege whatsoewer about various arm hardware), but the solution seem to be a bit difficult. FWIW, I'm enabling binfmt.d/ support for binfmt-misc format registration (as an alternative to binfmt-support), - not that it makes it more difficult, just one more condition to check. Thank you for the bugreport! /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:19, Daniel Kahn Gillmor wrote: Hi Michael and Santiago-- I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385. I'm reviewing Michael's changes for 1.8.1, and they're looking good to me. Thank you for all that work, Michael! I think we should consider uploading 1.8.1 into experimental while we wait for 1.7.1-3 to propagate to testing. I don't see a reason to use experimental here, since ldns is not a very popular package, it wont do much good in experimental. The only prob is that the master branch on the ldns repository is seriously messed up. It was for a reason I asked how to resolve this situation. You made it significantly worse. /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:29, Michael Tokarev wrote: The only prob is that the master branch on the ldns repository is seriously messed up. Also you've made similar commits as I did, but in an incomplete way (like the watch file update). Thanks, /mjt
Bug#1001053: also being affected
13.04.2022 22:37, Daniel Lakeland wrote: My wife has a dual mirrored glusterfs file server that is used for central storage of biology research data. They'd been running old versions of Debian, until one of them had a hard drive failure. After replacing hardware and installing the latest Debian release, upgrading the other machine, and synchronizing the gluster fileserver, now no-one can access the server because they are experiencing something similar to this bug. We missed a bugfix from upstream samba 4.13.17, this one: CVE-2020-25717-s3-auth-fix-MIT-Realm-regression.patch which smells like this very bug. Security team imported all security-related patches up to 4.13.16, but did not include any bugfixes, and this is one of the bugfixes. From this patch: BUG: https://bugzilla.samba.org/show_bug.cgi?id=14922 Reported-at: https://lists.samba.org/archive/samba/2021-November/238720.html Please take a look.. I prepared an update for samba in bullseye (it has quite some other issues too, including a serious data corruption issue which bite me hard). I *hope* it will fix your issue too, as it includes the above mentioned change. I should try to push it to stable-proposed-updates. And yes it should hopefully be fixed in 4.16 release too, which is available in unstable. Thanks! /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Fixed my branch on the ldns repo, rebasing it on top of now-okay master. If we ever need one more 1.7 release it will be easier to rebase now with the conflicts resolved. I have to review my branch again, I think something might not be right there after the rebase on top of dkg's changes. I will do this tomorrow. Please don't rush it the next time. People were discussing things for quite some days already, and you aren't even an uploader. Just don't do that again. There's no harm done, we are all people and we all do mistakes. I did it too, by doing an NMU without the 2 commits which were pending in master. Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:19, Daniel Kahn Gillmor wrote: .. reviewed and i'll push that to salsa as a "debian/experimental" branch later today, if either of you want to take a look at what i'm considering for release. The whole thing was ready, polished, everything addressed. If you wanted another 1.7.1 upload that's fine, just add one more commit after my nmu. It was not done in the master branch for a very good reason. Please feel free to use any of my changes you like. Please don't add me to uploaders. This is not how I think package maintenance should be done. I don't want to work in such an unhealthy environment. Thanks, /mjt
Bug#904999: : autodep8: python autopkg tests are always run for all supported python versions
On Mon, 30 Jul 2018 12:37:50 +0200 Matthias Klose wrote: Package: autodep8 Version: 0.13 Severity: important The python autopkg tests are always run for all supported python versions, ignoring, if a module is available for all available versions. This is the case for extensions only built for the default python/python3 version. The tests should be only run for all versions, if - the b-d's contain python-all/python3-all python-all-dev/python3-all-dev AFAICS, this is - at least in parts - due to Build-Depends: python3-dev:ANY suffix. https://salsa.debian.org/ci-team/autodep8/-/blob/master/support/python/generate#L67 grep-dctrl -n -sBuild-Depends -FBuild-Depends -w python3-dev -a '!' -FBuild-Depends -w python3-all-dev debian/control this fails to find python3-dev:any but finds python3-dev without the suffix. This has another interesting implication due to another issue in grep-dctrl: it finds commented-out parts of d/control too. Like this: Build-Depends: # python3-all-dev, -- does not work python3-dev thinking it has dependency on pyhon3-all-dev while in fact it does not. And yet more, it fails to realize there are other types of build dependencies, like Build-Depends-Arch and Build-Depends-Indep. *sigh* :) Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
BTW, Daniel, please re-tag 1.7.1-3 - this is what's at the tip of master now. I hope anyway :) Thanks, /mjt
Bug#1009385: communication
[Resending whole thing. I think it is is important to have it publicly available and to reach you, so adding it to the bugreport too. Apparently team+dns@tracker.d.o isn't working and there's no archives] I want to follow up on the todays ldns incident. I think it was quite interesting. The whole thing of me pushing the 1.7.1-2.1 NMU was not noticed by the current maintainer of ldns package. I don't know why, but after uploading to DELAYED/2, I thought I'd ask Santiago directly, because strangely I did see his reply to other emails but not to my upload. And indeed, he replied he didn't receive my nmudiff emails about the delayed upload. So next, instead of me ensuring the comminication is working correctly, I switched to mostly private email exchange between me and Santiago. We discussed many things, he reviewed my changes, we discussed possible master branch rewrite (the top two commits by Robert), I've asked Robert about his opinion on these 2 commits, -- this all has been done in private email exchange. I was wrong here not to add some Cc to team+dns@ or some bugreport, or anything. On the contrary, the discussion spinned off the python3.10 ftbfs bug, but I replied to Santiago in private, because that discussion has nothing to do with that bugreport really. So initially it was me who made whole thing absolutely unknown to all the dns team, whole team was absolutely unaware about the happenings in there. I apologize for this discussion going on entirely in private. The problem was not because of my incompetence or me being unaware, no, *that*'d be understandable. The thing was that I had this thought many times, I had this feeling every time I replied, that this whole thing should be made public, but I didn't do anything with that, -- the usual "I don't have time right now for this" played its game. And sure thing, Daniel did the best he thought it is, without any knowledge about all the happenings behind the scenes. Hopefully the whole thing is much better now. Yes it required master branch rewrite, because of *my* NMU which went out of order. And it was still the same single rewrite after Daniel changes. Now, to sum it up: mjt-1.8 branch *was* ready for the upload (tho I was more comfortable with another 1.7 upload too). Now I need to review it before it can be merged (now it's just fast-forward, but please let me one more chance for mjt-1.8 branch rewrite if I'll find anything in there which needs a rebase - I'm not asking about master branch rewrite here). I kept it separate from master for 2 reasons now: first I need to review it myself, and second, if by a chance we'll have to fix the 1.7.1-3 upload, we wont need another rewrite. [While I experimented with team+dns@tracker.d.o, I also force-pushed mjt-1.8 branch again, fixing changelog so it will not include already listed entries, and adding two more commits to there. I'm still not entirely sure what I have in there is what I actually want it to be, so I still have to re-review my own changes - whenever they're making sense on top of Daniel's changes. Please be patient there] Thank you all for the patience. This was a good lesson for everyone, I think. /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Okay guys. I thought about this a bit more. One wrong action by one developer does not make the environment unhealthy. I fixed the mess done to the master branch. I think - provided this wont happen again - it's okay to work on this to fix the rest of the mess done. I'm doing this right now. Thanks, /mjt
Bug#1007260: performance regression due to linking against libnettle
On Mon, 14 Mar 2022 23:58:37 +0100 "Steinar H. Gunderson" wrote: Package: libunbound8 Version: 1.13.1-1 Severity: normal Hi, We were investigating a performance regression in production that crept in at some point (we noticed by accident that something had become very slow and started investigating). It turns out the culprit was libunbound; we do a series of DNS lookups against localhost using ub_resolve(), and each of them now takes a bit over 6 ms, which is huge for sending a UDP packet and getting an answer from cache. It turns out that some of this is because libunbound in Debian is now built against libnettle (it wasn't when we built the system). The libnettle code in util/random.c goes through a very slow reseeding phase; and worse, it does it for both creating a context (we create a new one for each call, because Reasons(TM)) and for each and every query (because ub_resolve() starts its own worker, which reseeds). This reseeding is responsible for 60% of the CPU usage or so, according to perf. Wug. This is awful. According to pkg-config --libs libunbound, it seems one links to OpenSSL anyway, This, if true, is a bug. libunbound itself does not link to openssl. On my system with 1.13.1-1 version of libunbound, pkg-config does not list openssl libs for it: $ pkg-config --libs libunbound -lunbound so perhaps the simplest solution is to stop linking against libnettle? Well, you already noted above the "Reasons(TM)". If you want to know the particular reason for this, see #828699 which forced us to build libunbound with nettle. It indeed is "Reasons(TM)" :) Maybe someone from the Debian DNS team can add something here. But it looks like we're sort of stuck here and should address this on the nettle side. Is it at all possible? Or should we reopen #828699? BTW, Robert, do you remember why you had to split libunbound build? The changelog/comments says this build is here to have less dependencies, - which dependencies these are? Optionally, one can use getentropy() (which calls getrandom()) unconditionally on Linux, at least with modern kernels. Doing the latter, and also reusing contexts (which is a pain for us, and I don't think we had to do it before?) takes it down to a more reasonable 0.5 ms. Well, these are workarounds, it seems... Thanks! /mjt
Bug#949156: unbound: Please enable ipset support
Control: tag -1 + confirmed moreinfo On Fri, 17 Jan 2020 22:39:27 +0800 hypeng wrote: Package: unbound Version: 1.9.4-2+b1 Severity: wishlist Hi, On Jun 2019, unbound supported the ipset that could add the domain's ip to a list easily.Like dnsmasq. use "./configure --enable-ipset" to enable this feather. the package libmnl is needed to build and use with this feather. More details at https://github.com/NLnetLabs/unbound/pull/28 not good in english Hi! Yes I've seen this feature and thought maybe we should enable it in our Debian package of unbound. However, it appears that ipset is being obsoleted these days, when nft sets are available. Probably adding ipset support to unbound wont hurt anyway, how do you think? It is an interesting question, and I'm not sure yet for the answer. Thank you! /mjt
Bug#991017: unbound: remote-control port 127.0.0.1:8953 was opened to listen unexpectedly
Control: tag -1 + confirmed On Tue, 13 Jul 2021 01:11:30 + laalaa laalaa wrote: Package: unbound Version: 1.13.1-1 Severity: normal After upgrade from buster to bullseye with same config file, port 127.0.0.1:8953 was additionally listened for. From man page, this is "remote-control" port and the default "control-enable" is "no". When adding extra config section "remote-control" as below, the listening port 127.0.0.1:8953 was gone. remote-control: control-enable: no server: ... The default setting from man page and the observing behavior mismatch. This is due to a debian-specific patch, debian/patches/0001-Enable-remote-control-by-default.patch, which turns on the default value for remote-control (but does not touch the manpage). This is done as a fix for #923314 "systemctl reload unbound broken.." - but there were 2 changes in there actually, one was to switch from unbound-control reload to sending a SIGHUP, and another was to enable remote-control by default. Either of the two should be sufficient to fix #923314. But I think the second change - switching remote-control to on by default - is not a justified change from upstream here. It is not turned on by default upstream, and upstream documentation says it is not enabled by default, too (and even on Debian we forgot to fix the manpage together with this change). To me it looks like we should flip the default back to the default and remove this patch. Thanks, /mjt
Bug#1009309: udhcpc: allow usage without busybox
13.04.2022 09:31, Helmut Grohne wrote: Control: tags -1 + moreinfo On Wed, Apr 13, 2022 at 09:13:58AM +0300, Michael Tokarev wrote: No, as far as I understand. B/c udhcpc package lacks the main binary if there's no busybox... ;) Can you explain please? :) Head -> table. I now understand why udhcpc is so small. Thank you for your kind reply. There is nothing to change here. I'll look into the reverse (and usual) solution to space saving: replace everything else with busybox. That was good Helmut! Thank you! On a related note, I have been wondering whether we could somehow put the integration of busybox on more solid footing. A possible route could be adding tiny symlink packages e.g. iproute2-minimal containing ip, kmod-minimal containing lsmod and friends or procps-minimal containing top et al. These would have to conflict with iproute2, kmod and procps respectively as they're sharing paths. To make that actually useful, downstream packages could update their depends to foo | foo-minimal when they are known to work with busybox. If toybox wants to join, -minimal would refer to the minimal baselines provided by both busybox and toybox. It's a lot of small packages and metadata though. I'm not convinced yet and merely sharing thoughts. Properly minimizing Debian chroots with busybox is not a "it just works" experience yet. I thought about this back when I stepped on as busybox maintainer a few years back. Busybox isn't really suitable as a full-blown implementation for many system utilities. For one, quite some things on the system will break when you replace something with busybox, due to maintscripts, or startup scripts, whatever, usage of options/features/lack-of-bugs of the busybox's large brothers. Eg, file^Wcoreutils or [mg]awk provides much more features than busybox counterparts, and these features are being used in debian. This isn't difficult to fix in most places but you know the drill with cross-compile, how slow this process is :) But busybox is basically not maintained in Debian. I tried to at least reduce the number of active bug reports (there were many of them), updated version to current one (previous update was a few versions behind), tried to sync different configuration with each other and with reality.. until something happened a few debian releases ago and I was pissed off and stepped down. I don't even remember what happened, just a vague memory of someone uploading busybox backing up changes I did and refusing my changes to go, or some such.. So after that, busybox basically froze again. I still maintain it locally for our needs just like I did before, but I don't do that in Debian anymore. Maybe I should try again... /mjt
Bug#1004032: unbound: /etc/resolvconf/update.d/unbound is buggy
On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre wrote: Package: unbound Version: 1.13.1-1 Severity: important Note: The changes I've done on /etc/resolvconf/update.d/unbound is just logging messages (to known what's going on). When /run/resolvconf/interface/NetworkManager is obsolete (which can occur as NetworkManager is not the only was to connect: I use it only for wifi), DNS resolution no longer works. I fear that even when this file is not obsolete, unbound does not work as expected. Well, this file is *disabled*. We added a note to this file telling just that, to clarify: +# +# This update hook is **disabled** by default: the execute bit is not set. +# +# This hook can be problematic, especially if the +# upstream nameservers do not perform DNSSEC validation, or if a +# "forward-zone" declaration for the root zone has been statically +# configured by the administrator. In previous versions, the hook was +# enabled by default, but it is now disabled by default. It can be +# explicitly enabled by running "chmod +x /etc/resolvconf/update.d/unbound". +# +# If enabled (by setting the execute bit), upstream nameservers +# supplied by resolvconf will be configured into the running Unbound instance +# via the "unbound-control forward" command. +# But besides that, what exactly do *you* think is buggy about it? Thanks, /mjt
Bug#997811: unbound crashes, remote dos?
Version: 1.15.0-1 On Mon, 25 Oct 2021 07:57:22 +0300 Aleksi Suhonen wrote: Package: unbound Version: 1.13.1-1 Severity: normal Our unbound crashed a twice over the weekend, until I shut it down and replaced it with different software. Now that I'm back at work, I'm looking at the logs and found these in the kernel logs: Oct 24 04:59:27 resolver1 kernel: [3198942.847376] unbound[1211]: segfault at 108 ip 5623be4dcc39 sp 7febe13c4c40 error 4 in unbound[5623be419000+d6000] .. waiting_tcp_callback (w=0x0, ...) It is hopefully fixed by the 1.15.0-1 upload to experimental. Although the upstream issue #411 is still open, no more crashes like this are observed. Thanks, /mjt
Bug#991586: unbound systemd service should use network-online.target instead of network.target
Control: tag -1 + moreinfo On Tue, 27 Jul 2021 18:05:51 -0400 Marcus Furlong wrote: Package: unbound Version: 1.9.0-2+deb10u2 When starting unbound and binding to a specific interface using the `interface` keyword, unbound can fail if the interface is not configured correctly on boot. Changing the systemd unit to use the `network-online.target` instead of the `network.target` remedies the situation. Once the interface is online, unbound succeeds in binding to the interface and starts correctly. If you explicitly specified an interface name for unbound to bind to in the config file, you can just as easily specify the dependency for systemd. Something like, in /etc/systemd/system/unbound.service.d/, local-dep.conf: Requires = yourwifi.netdev (I don't know how off-hand to specify network devices in the Requires section of the systemd units, - this is just to give you an idea). The problem here is like chicken-n-egg problem. In some configurations, in order to bring network online, one have to have a working name resolution already. For example, it is quite normal when you have a VPN setup and require it to operate before you declare the network is online (so you have protected communications). But this VPN might require DNS resolution to work in order to find the other endpoint. I think it is easier to configure dependency on the particular host-specific interface when you know it is really necessary to bind to that interface, than to switch to a later stage in the system startup. There's one more possibility: if you know an IP address of that interface, you can assign that address to loopback interface (with /32 netmask) _before_ bringing that interface up, and specify an IP address in the unbound.conf instead of the interface name. This way all it will work fine too. Is this enough for you to fix your configuration? Thanks, /mjt
Bug#989959: unbound: Corrupt/empty trust anchor file is not healed upon start
On Wed, 16 Jun 2021 18:57:26 +0200 Dennis Filder wrote: Package: unbound Version: 1.13.1-1 Severity: normal Tags: patch I ran out of space on /var and unbound still tried to update the root trust anchor file which ended up empty. Then later after reboot the package-helper failed to detect and recover from that, and unbound.service failed to start. With the attached patch (which adds a rudimentary sanity check) and freshly freed disk space unbound started normally. However, a better solution might be to test more carefully for sufficient disk space when making changes to the file or using 2 oversized files in rotation and never truncating them. I wonder if we should address the root problem here instead of the symptoms. Maybe we can always update this (very small) file as a part of the daemon startup procedure. And/or, when doing this (it is just being copied to the chroot from /usr/share/dns/root.key), unbound can do it atomically - copying it to a temporary file and renaming it to the right place when done. Unlike install(1), this will never result in having an incomplete file in place (provided the filesystem is doing the right thing). Yet another option is to compare the two files and copy over if the files are different. Neither of that requires verification of the validity of the file. But it will surely change behavior if people used to keep their own file in /var/lib/unbound/root.key - can this *ever* happen at all? But this is not a conffile to begin with, if one wants to have their own root.key, they sure can set ROOT_TRUST_ANCHOR_UPDATE=no in /etc/default/unbound. What do you think? Thank you for the patch! /mjt P.S.: I also noticed that unbound.service under [Service] defines no StateDirectory=/var/lib/unbound to ensure that it is mounted on start. The chroot setup procedure has its own load of issues.
Bug#927435: upgrade-reports: Buster upgrade: had to re-create unbound certs/keys
Control: severity -1 normal Control: tag -1 + confirmed [ https://bugs.debian.org/927435 ] The talk is about stretch -> buster upgrade. John Eikenberry: > Package: upgrade-reports > Severity: normal > > After upgrading to buster, unbound-control would fail to run with this error.. > > error: Error setting up SSL_CTX client cert > 139765110753216:error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small:../ssl/ssl_rsa.c:310: > > To fix this I had to regenerate the certs and keys by removing the old ones and > running unbound-control-setup, then restarting unbound. This fixed the issue. > > $ cd /etc/unbound/ > $ sudo rm *.key *.pem > $ sudo unbound-control-setup > $ sudo systemctl restart unbound This can be done in two ways: 1. detect this and warn about this in postinst 2. detect this and do this procedure in postinst And there's another possible way, and this is the way it has been all this time: just ignore the damn thing. Because stretch=>buster upgrade happened quite some time ago... ;) Seriously, I'm not sure there's a good reason to do proper detection (which requires checking if remote-control is enabled to start with) at this time in the game. Yes, this prob was quite annoying at the time of the upgrade to buster, it hit me too, but that's history now. > Note that with unbound-control broken, that broke `systemctl reload unbound` as > it depends on unbound-control. It is not anymore, reload is now done by sending a SIGHUP. So things are less severe I think. Lowering the severity of this bug to normal. Thanks, /mjt
Bug#1009204: vdirsyncer: diff for NMU version 0.18.0-6.1
Control: tags 1009204 + patch Control: tags 1009204 + pending Dear maintainer, I've prepared an NMU for vdirsyncer (versioned as 0.18.0-6.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. I also prepared a repository update at https://salsa.debian.org/mjt/vdirsyncer , tag debian/0.18.0-6.1 , branch nmu-0.18.0-6.1, at 324bef8b , which you can import to the main repository. Regards. diff -Nru vdirsyncer-0.18.0/debian/changelog vdirsyncer-0.18.0/debian/changelog --- vdirsyncer-0.18.0/debian/changelog 2022-02-23 01:34:53.0 +0300 +++ vdirsyncer-0.18.0/debian/changelog 2022-04-18 17:39:33.0 +0300 @@ -1,3 +1,12 @@ +vdirsyncer (0.18.0-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * add python3-all dependency to d/tests/control: the test is written +so it iterates over all python3 versions but does not depend on +all pythons. Closes: #1009204 + + -- Michael Tokarev Mon, 18 Apr 2022 17:39:33 +0300 + vdirsyncer (0.18.0-6) unstable; urgency=medium * avoid checking flaky test test_fuzzing; diff -Nru vdirsyncer-0.18.0/debian/tests/control vdirsyncer-0.18.0/debian/tests/control --- vdirsyncer-0.18.0/debian/tests/control 2022-02-23 01:23:14.0 +0300 +++ vdirsyncer-0.18.0/debian/tests/control 2022-04-18 17:39:21.0 +0300 @@ -7,4 +7,5 @@ python3-pytest, python3-pytest-cov, python3-pytest-localserver, + python3-all, vdirsyncer,
Bug#971249: waf: CHECK_VALUEOF does not work during cross compilation
On Mon, 28 Sep 2020 06:53:03 +0200 Helmut Grohne wrote: Source: tevent Version: 0.10.2-1 Tags: patch upstream User: debian-cr...@lists.debian.org Usertags: ftcbfs Thank you for applying my previous cross build patches. My previous installment ended with: > 5. waf has a mandatory run test for determining whether mkstemp works. > 6. probably more I've now looked into this and think that there are two bigger steps to solve these. In the "probably more" department, there is a recurring scheme of using a "CHECK_VALUEOF". It is used to determine the value of an integer. If that value happens to be a compile time constant, it can be determined using bisection. waf already does something similar in CHECK_SIZEOF. I've implemented it for CHECK_VALUEOF and it now works similar to autoconf's AC_COMPUTE_INT. In particular, it only does the expensive bisection during cross compilation. In a native build, it continues to use the quick run test it did before. I've attached a patch for this. Umm. waf in samba is doing many "bad" things which can be done in a more efficient way not requiring to run compiled binaries. Yes, sizeof(foo) is a good example, valueof is another example. I think it is too much work to patch all these things out in debian. It might be a good idea to try to ping upstream about this, maybe they'll include similar change(s) to make cross-compilations easier. But probably not in Debian. I'd not spend more time on trying to make waf-based samba builds to be cross-compilable, unless upstream is actually willing to accept the work somehow. So far, it seems like upstream isn't willing even to accept simple spelling fixes. FWIW, Helmut, what do you think about using qemu-user[-static] to help cross-compiling stuff? It should significantly help in situations like this one, to be able to run the small test binaries in an emulated mode, provided you do have the foreign libs installed on the system. Yes it is not the fastest, but for sizeof/valueof tests like this it will Just Work, hopefully... Thanks, /mjt
Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries
Control: tag -1 + moreinfo On Sun, 06 Mar 2022 16:43:09 -0800 Vagrant Cascadian wrote: Source: tevent Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The build path and resulting Build ID for various libraries is embedded: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tevent.html /usr/lib/x86_64-linux-gnu/libtevent.so.0.11.0 /build/1st/tevent-0.11.0/bin/default/../../tevent.c:303 vs. /build/2/tevent-0.11.0/2nd/bin/default/../../tevent.c:303 The attached patch to debian/rules fixes this by passing -ffile-prefix-map via CFLAGS in the dh_auto_configure override. Hm. It looks like this flags is already being in use on unstable these days. At least I see it in all recent unstable builds, eg: https://buildd.debian.org/status/fetch.php?pkg=tevent=amd64=0.12.0-1=1651527651=0 make[3]: Entering directory '/<>' CC="x86_64-linux-gnu-gcc" CFLAGS="-g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat ... I don't really know where it is coming from (my guess is dpkg-buildflags), but it looks like this issue has already been solved in a more general way meanwhile. Can we perhaps close this bugreport now? Thanks, /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
06.05.2022 19:49, Mike Gabriel wrote: .. at least the bugtitle is far to unprecise. Here, I test Debian Edu bullseye really heavily and integrate FAI in Debian Edu. The FAI installer and also the diskless machines I very often boot via iPXE/QEMU. In Debian 11 (and probably beyond), PXE booting in QEMU works, for BIOS legacy VMs as well as for UEFI based VMs. In this bugreport, I see it is/was broken with -machine pc-1.1. There's no indication if it is broken with other machine types. As of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed. /mjt
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
On Sat, 6 Feb 2021 08:54:57 +0100 Dennis Filder wrote: Control: tag -1 - patch + moreinfo After looking into this some more, I don't think this is necessarily a bug in dwz, but it could also be either someone using rogue DW_OP_* definitions with values 0x00 and 0x01 or a buggy compiler/assembler backend emitting junk. While applying the patch probably won't hurt, it will most probably not help either. This prob now started appearing on ppc64el and s390x buildds on regular bullseye builds, f.e. https://buildd.debian.org/status/fetch.php?pkg=qemu=s390x=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1=1651985111=0 https://buildd.debian.org/status/fetch.php?pkg=qemu=ppc64el=1%3A7.0%2Bdfsg-2%7Ebpo11%2B1=1651980296=0 dh_dwz -a -a dwz: debian/qemu-system-misc/usr/bin/qemu-system-alpha: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-hppa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv32: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-riscv64: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-s390x: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-sh4eb: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensa: Unknown DWARF DW_OP_0 dwz: debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb: Unknown DWARF DW_OP_0 dh_dwz: error: dwz -mdebian/qemu-system-misc/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -M/usr/lib/debug/.dwz/powerpc64le-linux-gnu/qemu-system-misc.debug -- debian/qemu-system-misc/usr/bin/qemu-system-alpha debian/qemu-system-misc/usr/bin/qemu-system-avr debian/qemu-system-misc/usr/bin/qemu-system-cris debian/qemu-system-misc/usr/bin/qemu-system-hppa debian/qemu-system-misc/usr/bin/qemu-system-m68k debian/qemu-system-misc/usr/bin/qemu-system-microblaze debian/qemu-system-misc/usr/bin/qemu-system-microblazeel debian/qemu-system-misc/usr/bin/qemu-system-nios2 debian/qemu-system-misc/usr/bin/qemu-system-or1k debian/qemu-system-misc/usr/bin/qemu-system-riscv32 debian/qemu-system-misc/usr/bin/qemu-system-riscv64 debian/qemu-system-misc/usr/bin/qemu-system-rx debian/qemu-system-misc/usr/bin/qemu-system-s390x debian/qemu-system-misc/usr/bin/qemu-system-sh4 debian/qemu-system-misc/usr/bin/qemu-system-sh4eb debian/qemu-system-misc/usr/bin/qemu-system-tricore debian/qemu-system-misc/usr/bin/qemu-system-xtensa debian/qemu-system-misc/usr/bin/qemu-system-xtensaeb returned exit code 1 make[1]: *** [debian/rules:636: install-arch] Error 25 (it is DW_OP_0 not DW_OP_1, but since the above note suggests both should not be seen "in wild", maybe these are related). Is dwz or compiler broken on bullseye? Thanks, /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
Control: severity -1 normal 08.05.2022 02:18, Thorsten Glaser wrote: .. In this bugreport, I see it is/was broken with -machine pc-1.1. There's no indication if it is broken with other machine types. As of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed. This is rather bad, this will break existing VMs on upgrade with almost certainly zero clues why. these machine definitions are more than 10 years old. qemu can not keep them the way it were 10 years ago (and as we observed in this bugreport, this makes it bitrot). That wasn't an easy decision but the line must be drawn somewhere, we can't support really old stuff forever. Please note that in qemu, these machine types are kept mostly in order to make the VMs migratable from one version of qemu to another (which in practice quite often does not work anyway). During reboot it is possible to switch to a more recent machine. I know some operating systems can not tolerate hardware changes though, - at least linux is not one of them. Do you agree with this assessment of the bug you reported? If so, let's tag this bug with buster and bullseye as indeed I conclude it's not a bug in bookworm then. I'd rather consider this a second RC bug in bookworm, if so. I don't see why it is marked with this severity. To me it definitely is a "normal" bug (if not "minor" due to too old hw definitions). It works by default, and even in rare situations when it doesn't, there are easy workarounds (switch to another NIC for example). Or do you refer to the qemu dropping ancient machine types instead of this netbooting thing? If that's the case, such bug will be "wontfix" for sure. I'm lowering severity of this bug to "normal" now. Please feel free to set it to other value and provide the reasons why do you think this way. I'm currently in a really bad situation to look at anything in detail (waiting for my brain to remember the luks password of my work laptop), please excuse brevity. I hope you'll succeed there. It's sad when this happen. Thanks! /mjt
Bug#968670: dwz: Fails with "Unknown DWARF DW_OP_1" (more info needed)
It is the same on arm64 too, eg: https://buildd.debian.org/status/package.php?p=qemu=bullseye-backports /mjt
Bug#862207: error: libcrypto does not provide GOST
27.04.2022 12:08, Ondřej Surý wrote: Hi, GOST has been deprecated for use in DNSSEC, and the actual standard actually says it MUST NOT be used for signing (and MAY be used for verification), see RFC 8624. I think the best course of action here is to actually disable it everywhere where GOST R 34.10-2001 is used as it has been superseded by GOST R 34.10-2012 in [RFC7091]. I don't know which version(s) of GOST is enabled in ldns when built with --enable-gost[-anyway]. Do you? Please note there are at least 4 symbols in the libldns3 library which are gost-related: ldns_gost2pkey_raw@Base 1.7.1 ldns_gost_engine@Base 1.7.1 ldns_key_EVP_load_gost_id@Base 1.7.1 ldns_key_EVP_unload_gost@Base 1.7.1 I'm not sure here, but it looks like we'll have to bump the library soname when removing these symbols. To me it looks like not worth the effort. Especially since we "MAY" (as the RFC suggests) need it to verify some old signatures anyway. Thanks, /mjt
Bug#862207: error: libcrypto does not provide GOST
28.04.2022 15:27, Ondřej Surý wrote: .. Yes, it’s the old one. The 2012 hasn’t been specified for use in DNSSEC - there was a draft, but it has expired. Ok, that makes sense. Thank you for clarification. Please note there are at least 4 symbols in the libldns3 library which are gost-related: .. We can keep the symbols as dummy shims, so the package doesn’t have to bump SOVERSION. Yeah. Formally we should do either one or another. In practice I *highly* doubt anyone is using these 4 symbols, so maybe we can just disable the thing without doing anything. I'm too lazy now to provide the stubs :) .. There are no GOST signatures used in real world deployments, there’s no need to have validation enabled anywhere. Keeping obsoleted algorithm alive is not doing anybody any favor. I for one have no objections whatsoever against removal it besides the extra work which is needed. To me it is like, don't touch it if it does not disturb anyone. FWIW, for me the whole GOST thing is weird, I'd not have/use it at all to begin with. In some contexts it is required though. /mjt
Bug#1010271: unbound-control: Please use unix socket as default control-interface
Control: severity -1 wishlist Control: tag -1 confirmed 27.04.2022 16:48, ceddral wrote: Package: unbound Version: 1.15.0-4 Severity: normal X-Debbugs-Cc: debian...@ceddral.org Dear Maintainer, unbound package upgrade introduced a default config to enable remote-control via tcp socket. Can you tell please which version did you upgrade from? Please note that before, unbound in Debian had a patch to secretly enable remote-control socket which by default is tcp. In this release I just made it explicit instead of doing it secretly. Please change the default config to use a unix socket and avoid the attack surface of a tcp socket with ssl authentication. e.g.: remote-control: control-enable: yes control-interface: /var/lib/unbound/control.socket Actually it was my thought to enable control socket (I'm not sure /var/lib/unbound is a good place for it, /run sounds better but I need to check if it works when unbound is chrooted. unbound.postinst generates the ssl certificates for quite a long time, these probably should go away too. And we'd better check if unbound-control-setup script does the right thing. So I thought I'd keep it the way it were for a long time. And the most important is that it is the upstream default for control socket. Maybe we should specify it in the config file the way I did it in this release. Thanks, /mjt
Bug#821801: smbclient: Problems with smbclient since badlock update
Control: tag -1 + moreinfo Replying to an old bug... On Tue, 19 Apr 2016 13:43:29 +0200 tkla wrote: Package: smbclient Version: 4.2.10 Severity: normal Tags: upstream Dear Maintainer, since the badlock fixes my backup software Amanda stopped working when we're trying to backup Windows shares. Please have a look at the bug report i have opened at upstream https://bugzilla.samba.org/show_bug.cgi?id=11854 Hi! Do you still have this problem with current version of samba and amanda? I suspect the issue you had with stretch samba (4.4) update -- ERROR: MYSERVER: smbclient: Error reading password from file descriptor 3: empty password - has been fixed quite long time ago in amanda. Thank you! /mjt
Bug#900241: no root.key provided by libunbound2
Control: tag -1 + moreinfo So, will adding a Recommends: dns-root-data either to libunbound or to various software packages (eg unbound-host) fix this? I don't think adding this to libunbound is a good idea since software using it isn't necessary being used the root key, but adding it to the binary packages which actually uses that data seems reasonable. How do you think? /mjt
Bug#826241: fixed in unbound 1.5.9-2
Replying to an old bugreport which is marked as fixed since 1.5.9-2 version. This is, in fact, a context of resolvconf, for which we have several other bugreports. This one has a lenghtly discussion and debugging. But I can't understand the main thing there: why on the Earth one needs to reload postfix (or other similar software) due to changes of DNS forwarders, provided there's a caching nameserver running on 127.0.0.1? In this case, all local programs just use the default 127.0.0.1 as nameserver and need no reload whatsoever, /etc/resolv.conf does not change (well, unless a search path is also changing), all the complexity is handled by the caching nameserver internally, without clients even disconnecting. Is it not the case? Having said that, I'm aware of /etc/resolvconf/update.d/unbound being disabled for quite some time (#1003135). Maybe that's the whole reason of all this long debugging in this bug report, and the only thing actually needed was to enable this resolvconf integration? This whole unbound-resolvconf.service seems to be quite messy and it is unclear to me how it works to begin with. There are several pieces of this puzzle. Now we also have #1009928 which needs to be fixed but I don't understand the machinery behind this unbound-resolvconf.service. Also, lintian gives warnings about this: W: unbound: systemd-service-file-refers-to-unusual-wantedby-target unbound.service [lib/systemd/system/unbound-resolvconf.service] I: unbound: package-supports-alternative-init-but-no-init.d-script lib/systemd/system/unbound-resolvconf.service I: unbound: systemd-service-file-missing-documentation-key [lib/systemd/system/unbound-resolvconf.service] The first one is just that: it is _unusual_ to be wanted by anything but multi-user.target or the like. Robert, can you please give some summary of that's going on there if you still remember the context? I'm trying to understand the context provided in this bugreport (which lead to the current unbound-resolvconf.service) but it is a bit difficult to follow. Thank you! /mjt
Bug#862207: error: libcrypto does not provide GOST
28.04.2022 19:22, Ondřej Surý wrote: On 28. 4. 2022, at 15:23, Michael Tokarev wrote: Yeah. Formally we should do either one or another. In practice I *highly* doubt anyone is using these 4 symbols, so maybe we can just disable the thing without doing anything. I'm too lazy now to provide the stubs :) Yeah, I concur. I would recommend doing such upload to experimental first and then we can add couple of versioned Breaks if we find any problems. I see no reason to go to experimental here. I checked all rdepends of libldns3, - none are using any gost symbols. -exp wont do anything useful there I think. It is not the first time I see people suggesting uploading stuff in experimental. Sometimes I do that too (not counting the case like we had with the python transition, and a risk to delay the transition further in case of a problematic upload to unstable) - when I'm not sure if the changes I did are okay and I want to give it some wider testing and when I *know* someone can help me by explicitly install the experimental stuff. But for things like this, I *think* -exp is useless, it wont show anything which we don't know already. Did I miss something? Thank you! /mjt
Bug#927747: bind9_dlz backend is entirely broken in Debian
Control: severity -1 normal On Wed, 8 May 2019 22:35:53 +0200 "Steinar H. Gunderson" wrote: On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote: > Downgrading the severity as the AppArmor side is already fixed it seems in sid. serious and grave are of equal severity; serious is for Policy violations (e.g. package doesn't install), grave is for functionality issues (e.g. program segfaults on start). For some reason it is common to misuse severity. A "package is unusable in almost all configurations" or at least "unusable in default configuration" isn't always equal to "package is unusable *for me*". In this case, if dlz_backend is broken, it does not mean samba is entirely broken. A particular configuration of it - sure. For one, we run a samba AD without dlz_backend and without bind to begin with, and it works just fine.. Thanks, /mjt
Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"
27.04.2022 14:38, Salis, Antonello (NFOD) wrote: The new update 2:4.16.0+dfsg-7 is affected as well. Sure, there was nothing done in there about this issue. Or else I'd mark it as fixed or at least asked you guys to try it out :) Thanks! /mjt
Bug#641704: unbound-host should be preconfigured with DNS root trust anchor
This is interesting from a few other points of view. unbound-host should probably not use /var/lib/unbound/root.key which is an untrusted-owned file in an untrusted-owned directory. So probably the default value for this root.key file should not point to this location. We probably can change both unbound-host and unbound-anchor to use /usr/share/dns/root.key - the same location as shipped by dns-root-data. And keep unbound-owned file as it is now (which is configured in /etc/unbound/unbound.conf*). On the other hand, if we have a more recent file in the unbound libdir than the one shipped by dns-root-data, or if we do not have dns-root-data installed in the first place, we can use that unbound-owned file too. But see the first point above. I think I'll just move it to /usr/share/dns/root.key, that sounds like the best course of action here. Thanks, /mjt
Bug#508053: please provide 'host'
Control: tag -1 + wontfix [Replying to a bug report which is more than 10 years old..] On Tue, 21 Jul 2009 19:13:06 +0200 martin f krafft wrote: .. > if the use case is 'lookup a DNS record and print it like > bind9-host does' then bind9-host and unbound-host fit that > description. Right. And it also supports all of the features of host and bind9-host, I think, so once you have unbound-host installed, the others aren't really necessary anymore, are they? 10+ years has passed but unbound-host does not provide the same or even similar functionality as bind9-host. Yes it prints DNS records, but the interface and the defaults are quite a bit different, to a point when you can't substitute one for the other. So marking as wontfix for now. We can probably make it a low-priority alternative for "host" if we had such alternative, - but we don't, iirc. There are other tools of this theme too, eg my dnsget (udns-utils package). /mjt
Bug#1007260: performance regression due to linking against libnettle
So.. what should we do? Build it with libssl again because it is not ready to be used when built with nettle, and reopen #828699? Steinar, can you raise this upstream please? It'd be good if whole unbound can be built with nettle instead of openssl, and actually work :) Thanks! /mjt
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
03.05.2022 17:08, Simon Deziel wrote: On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: Oh. Yes, you're right, I haven't noticed the difference here between unbound message and kernel message. This explains why I can't fix it by adding stuff for /var/lib/unbound to aparmor.d/. Yes, I chroot it to /etc/unbound, with /var/lib/unbound bind-mounted to /etc/unbound/var/... - the way it was supposed to work by upstream, apparently. The problem with chrooting it to /var/lib/unbound is the copy of all the configuration which must not be done by root into nonroot-owned untrusted directory, and because you lose unbound-control reload. Copying configs is bad, I think. # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. Yes, this one works (with the above comment/restriction). And yes, adding /etc/unbound/var/lib/unbound/* stuff to apparmor profile seems to be working as well, - something which I missed initially, - that's why I filed this bugreport instead of fixing it right away, - b/c I weren't able to figure out why it doesn't work after my attempts to fix the profile. HTH, Definitely, thank you Simon! /mjt
Bug#1009907: Smbclient error: "Failed to mount Window share: invalid argument"
Control: tag -1 + moreinfo Hi! I uploaded 4.16.1 yesterday to unstable. That one, among other things, includes this: https://gitlab.com/samba-team/samba/-/commit/34771e1931587807d0395c7ac7f4be18654997f4 which, according to the archlinux bugreport, fixes a (similar?) issue. Can you please verify if 4.16.1-3 works? Thank you! /mjt
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied There are 2 issues there: the wrong apparmor profile and the behavour of unbound which makes this error to be fatal. /mjt
Bug#1010801: [Pkg-samba-maint] Bug#1010801: Package: samba-common-bin
Control: tag -1 + moreinfo 10.05.2022 12:40, David wrote: Package: samba-common-bin Release: Debian 10 *ii samba-common-bin 2:4.9.5+dfsg-5+deb10u3i386 Samba common files used by both the server and the client* Problem: /usr/bin/net ads testjoin --> Segment violation Please verify if this problem is still present on the current debian stable release (debian 10 is oldstable, and samba 4.9 reached end-of-life quite some time ago). Or better yet, if it is present with the current version of samba (4.16) which is now made available in bullseye-backports. Maybe someone else will help you with this old version of samba, but unfortunately that will not be me. There were just too many differences since that version. Thanks, /mjt
Bug#831770: smbclient needs /run/samba tmpfiles dir under systemd
Version: 2:4.13.13+dfsg-1 On Tue, 19 Jul 2016 12:07:29 +0200 Jan Stattegger-Sievers wrote: Package: smbclient Version: 2:4.2.10+dfsg-0+deb8u3 Severity: normal Hi, here smbclient dies with a segfault, if /var/run/samba aka /run/samba is not present: Unable to create directory /var/run/samba for file gencache_notrans.tdb. Error was Permission denied This does not happen anymore on smbclient version in bullseye (4.13). Closing this bugreport with current bullseye version of samba. Maybe it has been fixed before, I don't know. Thanks, /mjt
Bug#959211: utimensat system call no working properly on SMB shares
On Thu, 30 Apr 2020 16:59:56 -0400 Alberto Sentieri <2...@tripolho.com> wrote:
Package: samba
Version: 4.5.16
The system call utimensat is failing when the protocol version is 2.0 or
upper is selected.
The package samba version 2:4.5.16+dfsg-1+deb9u2 is the last one
available for Debian stretch. Its interaction with Debian buster using
cifs-utils version 2:6.8-2 is causing the particular system call to
fail. In my case, the samba server is running under debian stretch,
while the workstation is running debian buster. A simple program like
of from a ext4 file system to the SMB file system
will store the incorrect time stamp on the samba server.
/bin/cp program executes some code like this, before finishing:
write (fd, buffer, length);
utimensat (fd, NULL, timestamps, 0);
close (fd);
I create a C program which will execute this sequence of statements.
Curiously the time stamp is correct for a small amount of time, and then
it switches to the current time. The program, which I called x2, will be
run by the following batch script:
#!/bin/bash
NAME='/samba_share/test2.txt'
rm -f "${NAME}"
ls -ls "${NAME}"
./x2 "${NAME}"
ls -ls "${NAME}"
sleep 1
ls -ls "${NAME}"
The result of running the script is:
$ ./script.sh
ls: cannot access '/samba_share/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /samba_share/test2.txt
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 16:33 /samba_share/test2.txt
As one can see, the file time stamp is correct just after x2 finishes,
and it become incorrect one second later. If, while mounting the share
with mount.cifs, I specify -o vers=1.0, then the problem does not
happen, I mean, the time stamp will be the same (Feb 5 2017) just after
x2 ends and 1 second after its end.
The program x2 uses the same sequence of commands that /bin/cp -p or
/bin/mv uses. Here is its source code:
Hi!
This is an interesting bug report.
The problem here seems to be some buffering (in samba?). And this your
test script above shows it nicely.
open
write... - this is buffered
utimensat - the file timestamp is set, but the file is empty
close - the file's still empty!
... some time later ...
write the buffer behind the scenes..
obviously the write resets the timestamp
I don't know where this buffering is done. It would be interesting
to find out, -- apparently this is something which should not happen
at least this way, - whomever does the buffering must flush its
buffers before changing file timestamps. And the fact that the
write is still not happened after close() is also at least questionable
behavior: how do we know about the possible write errors? May be
you enabled some extra write cache? (which still should not have
this effect on setting the timestamp).
The fact that the older protocol works means that for *that* set of
available on-wire commands, things are done correctly, but for some
new command available in a more recent protocol, this is not done.
Can you check if this is still the prob with samba 4.16?
This should definitely be reported upstream.
Thank you for the excellent bug report!
/mjt
Bug#822812: samba: NT_STATUS_TOO_MANY_OPENED_FILES after latest upgrade
Control: tag -1 + moreinfo On Wed, 27 Apr 2016 21:49:04 +0200 Christopher Schramm wrote: Package: samba Version: 2:4.2.10+dfsg-0+deb8u2 Severity: normal Dear Maintainer, since the samba version in jessie was updated to 4.2 we have an issue with our server that renders shares unusable. After they've been accessed for a small amount of time, the log constantly shows: single_accept_connection: accept: NT_STATUS_TOO_MANY_OPENED_FILES In fact each samba process' /proc/*/limits file shows: Max open files1024 4096 files Hi! I'm replying to an old bug report, jessie is now very old. Samba is running as root and it adjusts number of open files to at least 16k (see max open files in smb.conf). You have to take look at the process limits of running smbd to see the actual value. And you can't change it externally either. Anyway, is this issue still relevant with the current version of samba (4.13)? Thanks, /mjt
Bug#943903: samba 2:4.11.1+dfsg-1 server breaks mount.cifs from cifs-utils 2:6.9-1
Control: tag -1 + moreinfo On Thu, 31 Oct 2019 11:53:52 -0400 Marvin Renich wrote: Package: samba Version: 2:4.11.1+dfsg-1 Severity: normal I plan to clone this bug to cifs-utils, as it is unclear which package has the bug. After upgrading from samba 2:4.9.13+dfsg-1 to 2:4.11.0+dfsg-10 on a server machine, mount.cifs from cifs-utils 2:6.9-1 on a different machine fails to connect with "mount error(13): Permission denied". Subsequently upgrading samba to 2:4.11.1+dfsg-1 did not help. Downgrading samba to stable 2:4.9.5+dfsg-5+deb10u1 on the server fixes the problem. Adding a snapshot version to figure out what needed to be downgraded to get version 2:4.9.13+dfsg-1 was deemed not worth the effort, as my daily backup on the client machine (which mounts the remote cifs share) was running fine when the server had 2:4.9.13+dfsg-1. Hi! Is this still a problem in current bullseye version of samba (4.13) and cifs-utils? If yes, can you please try samba version 4.16 (available in bullseye-backports)? Thank you! /mjt
Bug#827259: samba-libs: winbind segfault in libsamba-security.so.0 after update to 4.2.10+dfsg-0+deb8u3
Control: tag -1 + moreinfo [ Regarding https://bugs.debian.org/827259 ] Hi. It's been quite some years since this bug report. Do you have issues with this still, with current samba and debian versions? Can we close this bug report now? Thanks, /mjt
Bug#932685: Samba package won't respect the -y switch of apt-get install command
Control; retitle -1 samba-common: DHCP debconf question shouldn't be critical Control: severity -1 wishlist Control: tag -1 + confirmed moreinfo Something went wrong there, and the control command never completed. Re-retitling and also adding "confirmed" tag. On Tue, 23 Jul 2019 23:34:50 +0200 Mathieu Parent wrote: ... However, I agree that asking for wins options today should not be that "critical". I'm keeping this bug to track either: - the lowering of the option, or - the complete removal of dhcp/wins support I think dhcp/wins should be dropped these days indeed. Mathieu, do you have something particular in mind there, besides this postinst question? Thanks, /mjt
Bug#1010801: Package: samba-common-bin
10.05.2022 13:30, L.P.H. van Belle wrote: ... 1) If you can upgrade to bullseye, that’s highly preffered, and give you the option to move to 4.16.1 in backports. Which is what I recommend.. 2) if you cant upgrade - make sure everything is setup as it should, I already seen one thing that’s whould not be running as I stated above. - then choose which samba version you want and can run. for buster I have 4.13 4.14 and 4.15 available only a big sidenote... these packages DON’T support SSSD. so if SSSD is a must, you must stay within debian official packages. Heck. This reminds me that.. I didn't provide sssd backport for bullseye, but sssd from bullseye will NOT work with samba from bullseye-backports. This is because samba changed the path for ldb modules, and sssd-provided module can't be found after samba upgrade. This can be fixed in samba though. Providing a symlink from /usr/lib/x86_64-linux-gnu/samba/ldb/ pointing to /usr/lib/x86_64-linux-gnu/ldb/plugins/.. - I don't remember off-hand where sssd puts its plugin at. But the new libldb2 Breaks sssd in bullseye, so it can't be fixed after install: you can't install it to begin with. I completely forgot about this. It looks like a new samba bpo release is in order. /mjt
Bug#964579: lsblk not included in busybox version used with installer
Control: tag -1 + moreinfo On Wed, 8 Jul 2020 23:23:51 + Holger Levsen wrote: Package: busybox Version: 1:1.30.1-4 Severity: wishlist x-debbugs-cc: Russell Weber submitter: Russell Weber On Wed, Jul 08, 2020 at 02:43:43PM -0600, Russell Weber wrote: > Package: busybox > Version: 1:1.30.1-4 > Severity: wishlist > lsblk is a very useful tool for understanding your current disks and block > devices. It can be used to > query lots of information including disk manufacturer, serial number, model > number, the structure of your disks if the disk is already in use for > another block device. Given that the installer has mission critical goals > associated with the disks, it's a bit of a mystery that lsblk isn't > included into the busy box implementation used in the installer. This is > especially important when seeding automatic/unattended installs for debian > since many of the seed files used will query information from disks in > scripts using the "d-i partman/early_command string" of debconf. I can see > that this issue has been raised in multiple places online: stack overflow, > IRC. However, scanning older tickets, I was not able to find a ticket > which raises the issue. Is there any reason that lsblk as a command is not > included? As far as I can tell, the bloat size would only be around 20-40 > KiB in size. May I suggest that we start including the lsblk binaries in > the next versions of Debian? Hi Russel! Thank you for the detailed bug description. The only question remain is who will write lsblk for busybox, who writes the actual code to do all this? Can you help with that, to collect all the mentioned information in a useful for the user form? This applet is not written. Thanks, /mjt
Bug#921556: busybox: Enable more applets to support initramfs-tools
Control: tag -1 + upstream On Wed, 06 Feb 2019 18:58:06 + Ben Hutchings wrote: Package: busybox Version: 1:1.27.2-3 Severity: wishlist Once we have busybox 1.28.0, we could enable these extra applets on Linux: ipconfig [CONFIG_IPCONFIG] nuke [CONFIG_NUKE] resume[CONFIG_RESUME] run-init [CONFIG_RUN_INIT] So this is almost there, except of ipconfig which is not implemented yet. There's just a wip version, a first draft, klibc-utils/ipconfig.c.txt, not touched since initial import in Sep-2017. It's an interesting goal there, to have everything in busybox to stop providing two libCs and two shells and two everything in initramfs.. Thanks, /mjt
Bug#980127: busybox-static: Please enable the "hush" applet
Control: tag -1 + moreinfo On Thu, 14 Jan 2021 13:12:58 -0800 Josh Triplett wrote: Package: busybox-static Version: 1:1.30.1-6 Severity: wishlist X-Debbugs-Cc: j...@joshtriplett.org For busybox-static, I'd love to have the "hush" applet available. It's a more feature-complete shell, including features such as brace expansion. Please consider enabling CONFIG_HUSH and CONFIG_HUSH_BASH_COMPAT in busybox-static. Hi Josh! Myself I haven't used hush in busybox but I always used ash. If we're to enable hush, I think we should remove ash and make hush the only shell. And do that in regular deb config too, - there's no good reason to keep them different. But I wonder what implications we might have there, if we switch from ash to hush. How compatible the two shells are? I dunno. I think it needs to be verified at least.. busybox's ash is very limited indeed. Thanks, /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
05.05.2022 13:47, Paul Gevers wrote: Hi all, [CC-ing src:debian-edu and src:qemu as they pull in src:ipxe-qemu into the key package set, so I consider them stakeholders in this RC bug.] On Fri, 12 Mar 2021 19:29:55 +0100 (CET) Thorsten Glaser wrote: So we now know without fail that there’s a change in the ipxe-qemu binary package, introduced between jessie and stretch, that breaks netbooting on virtio NICs for at least some qemu machine models in use by libvirt guests. Is there any progress on this front? It would be a shame if we have to -ignore the bug again for bookworm. Well, there's no progress in there, - I weren't aware of this issue is still occurs on bookworm. I don't have a netboot environment handy to test it, either. Help? /mjt
Bug#1010271: unbound-control: Please use unix socket as default control-interface
27.04.2022 19:38, ceddral wrote: .. Tested it, as far as i can tell it works for me with chroot: "/var/lib/unbound" and control-interface: "/run/unbound-control.socket" Thank you for confirming this. I too did the similar test locally, you made me curious. (and BindPaths=/run/systemd/notify:/var/lib/unbound/run/systemd/notify in the systemd service file) This is not necessary anymore, but I guess it is nicer this way. The difference is that the setup script (/usr/libexec/unbound-helper) does the mount already but this mount is visible for all other processes. While .service way makes it private to this process (with its own namespace). This whole thing isn't actually necessary, it is only needed to notify systemd when unbound is finished initializing. It might be easier in cases like this if systemd passed an open file descriptor to the process where it can write to, so there's no need to open a (named) socket. I wonder if there's a way to avoid this bind-mount... My test was `unbound-control stats` says something. Yeah. I think it's a good idea to switch to unix socket. Please also note that linux actually honors the file permissions for the socket files, - unlike on some other systems. And there's one more thing: unbound chowns the socket to unbound user. I don't know why it is doing this, - ditto for the pid file. FWIW, I tend to chroot it to /etc/unbound, - which needs bind-mounting of /var/lib/unbound to /etc/unbound/ somewhere, but reduces the need for copying /etc/unbound to /var/lib. This copying is bad: besides it makes reloading unbound more difficult, it is also very security-sensitive, I highly doubt the copy procedure is "secure enough". Creating files as root in a unprivileged /var/lib/unbound is problematic. See how I did root.key handling in unbound-helper. Thank you! /mjt
Bug#1010271: unbound-control: Please use unix socket as default control-interface
27.04.2022 19:38, ceddral wrote: ... attention now being explicit in the config. Now that I'm aware I do believe a unix socket would be the more sensible default. This variant (the unix socket) weren't always available. It was implemented in version 1.5.2, and I wasn't aware of this until 1.15. /mjt
Bug#993014: cifs-utils non-parallel FTBFS
Control: tag -1 + pending 22.08.2022 17:11, L. van Belle wrote: I can confirm the patch works. I've tested on a Debian Bullseye build with cifs-utils 7.0 from https://ftp.samba.org/pub/linux-cifs/cifs-utils/ I refreshed patch 001. Added the patch shown buy Helmut. And I builded against Debian Bullseye with parallel=7 and parallel=1 Here's the upstream commit which fixes the problem: commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 Author: lizhe Date: Tue May 26 11:54:11 2020 +0800 cifs-utils: fix probabilistic compiling error When we compile cifs-utils, we may probabilistic encounter install error like: cd ***/sbin && ln -sf mount.cifs mount.smb3 ***/sbin: No such file or directory The reason of this problem is that if we compile cifs-utils using multithreading, target 'install-sbinPROGRAMS' may be built after target 'install-exec-hook' of the main Makefile. Target 'install-sbinPROGRAMS' will copy the executable file 'mount.cifs' to the $(ROOTSBINDIR), which target 'install-exec-hook' will do the 'ln' command on. This patch add the dependency of target 'install-exec-hook' to ensure the correct order of the compiling. Signed-off-by: lizhe diff --git a/Makefile.am b/Makefile.am index a95782d..8a17e73 100644 --- a/Makefile.am +++ b/Makefile.am @@ -117,7 +117,7 @@ endif SUBDIRS = contrib -install-exec-hook: +install-exec-hook: install-sbinPROGRAMS (cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3) install-data-hook: I think both are wrong but both do the job. Now, the question is: do we need to fix this for bullseye? It smells like there's no need to, no? Thanks, /mjt
Bug#993014: Processed: Re: cifs-utils non-parallel FTBFS
25.08.2022 11:49, L. van Belle wrote: ... The shown fix, commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is the patch I added. and cifs-utils 7.0 also fails to build without that patch with parallel=1 It's difficult to follow. Commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is wrong by its own because it adds dependency on install-sbinPROGRAMS while it should add dependency on install-root_sbinPROGRAMS (which creates the necessary directory). So that commit just adds unnecessary complexity but does not fix the problem in any way. Was it you who added this commit to upstream samba? I didn't notice this difference either, before closing this bug. I thought I verified the single-job build locally but it turned out my -j1 has been overridden by later -j8 on the same command line. Oh well. Technically this dependency is wrong too because the symlink itself does not need the installation of the binary, it needs only the directory. The right fix would be to create directory in its own target and refer in both install- and hook- to that target but I don't know if it is solvable in terms of regular make. GNU make has order-only targets which fits here nicely. But install-root_sbinPROGRAMS target as whole is generated by automake, together with the mkdir call. So the only way to "fix" this is to add similar mkdir into the hook rule, as Sanvilla did in his patch. Now, you wrote above that cifs-utils 7.0 "also fails to build without this patch", but this patch is included in 7.0. This is even more confusing.. :) Anyway. I'm changing install-sbinPROGRAMS to install-root_sbinPROGRAMS there to do what aeaa786aceb0ea781ded2c151fb68f6b34880ad4 has meant to do. This will fix this issue "the way upstream wanted it to be fixed", so to say. Oh well. /mjt
Bug#1017884: reportbug: qemu-system-x86_64 freezes after i access samba server on a windows-xp host
28.08.2022 16:33, أسامة مخزوم wrote: You have: -net nic,model=rtl8139 -net user -net user,smb=... The -net thing comes in pairs (one is guest side, another is host side). You have 3 of them, and the last one is not paired with the guest side. I suspect this is your problem - qemu does not know how to handle the unpaired -net user. you were right, i change it now and it works. seems AQEMU generates buggy qemu's cmds, i have used it for the vm but i copy cmdline only shall i report separate bug for aqemu ? At the time aqemu has been written, the -net syntax was the only one available. No doubt it is using that syntax. Now, aqemu is not maintained for several years, even if it said there's a new development started in 2016. You're free to do so ofcource ;) [] Now, you use both -net user,smb=... which redirects ports used by windows networking to custom samba instance with its own configuration, with nothing shared from host samba. Yet you attach your smb.conf file. Why? I was just mistaken about samba and qemu , thought it used smbd for its internals... Yes qemu uses smbd. But it uses smbd with its own entirely private configuration, not touching your main smbd/smb.conf in any way. If you want to connect to the "main" smbd, do not override -smb, - this way your main samba "instance" will be used. /mjt
Bug#993014: cifs-utils non-parallel FTBFS
27.08.2022 03:35, Santiago Vila пишет: Hi. Now that this is finally fixed in sid, here is a proposed diff for bullseye, including changelog. Heh. The changelog includes entry by me.. it is not fair for your contribution, I think.. :) BTW, should we drop the .1 from -3.1+deb11u2 release number? Thanks, /mjt
Bug#1017884: reportbug: qemu-system-x86_64 freezes after i access samba server on a windows-xp host
Control: tag -1 + moreinfo Control: severity -1 normal 22.08.2022 02:30, Usama Makhzoum wrote: Package: qemu-system-x86 Version: 1:7.0+dfsg-7+b1 Severity: important X-Debbugs-Cc: osma...@gmail.com I use qemu as the following: /usr/bin/qemu-system-x86_64 -soundhw ac97 -machine accel=kvm -m 1033 -cdrom windowsxp.iso -hda windowsxp.img -boot once=d,menu=off -net nic,model=rtl8139 -net user -net user,smb="/path/to/shared/folder/inside/my/home" -rtc base=localtime -name "Windows XP x32" You have: -net nic,model=rtl8139 -net user -net user,smb=... The -net thing comes in pairs (one is guest side, another is host side). You have 3 of them, and the last one is not paired with the guest side. I suspect this is your problem - qemu does not know how to handle the unpaired -net user. The whole -net syntax is obsolete - partly because of this common misunderstanding and partly because whole architecture behind -net is wrongly designed. You should use -netdev..-device instead of -net..-net. (Unfortunately, many old guides in the internet still suggest to use -net, but this is something we can't change in a moment). Now, you use both -net user,smb=... which redirects ports used by windows networking to custom samba instance with its own configuration, with nothing shared from host samba. Yet you attach your smb.conf file. Why? I suggest you to use -netdev..-device syntax (which has, among other things, detection of disconnected halves like you have now) as a start. Personally I see no reason to try to debug issues coming from -net..-net. Thanks, /mjt
Bug#1019011: -mbuild-constants is broken in gcc-12.2
Package: gcc-12-alpha-linux-gnu
Version: 12.2.0-1cross3
Severity: normal
Starting this version of gcc, -mbuild-constants option causes it to produce
an ICE. Example is below. This is an old code, always worked before, in
particular with gcc-11.
Removing -mbuild-constants fixes the ICE. But this is a bios/firmware code,
and this option is used for purpose. Tho I don't know how important it
really is.
I tried to submit this bug upstream, but failed at the bugzilla registration
step.
// Target: alpha-linux-gnu
// Configured with: ../src/configure -v --with-pkgversion='Debian 12.2.0-1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libssp
--disable-libsanitizer --disable-libquadmath --disable-libquadmath-support
--enable-plugin --with-system-zlib --enable-multiarch --disable-werror
--with-long-double-128 --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=alpha-linux-gnu
--program-prefix=alpha-linux-gnu- --includedir=/usr/alpha-linux-gnu/include
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 12.2.0 (Debian 12.2.0-1)
//
// during RTL pass: expand
// [01m[Kconsole.c:[m[K In function ‘[01m[Kdo_console[m[K’:
// [01m[Kconsole.c:130:12:[m[K [01;31m[Kinternal compiler error: [m[Kin
emit_move_insn, at expr.cc:4010
// 130 | [01;31m[Kvga[0] = 'H' + attr[m[K;
// | [01;31m[K~~~^~~~[m[K
// 0x13117e6 internal_error(char const*, ...)
// ???:0
// 0x5a6f34 fancy_abort(char const*, int, char const*)
// ???:0
// 0xdca64a alpha_split_const_mov(machine_mode, rtx_def**)
// ???:0
// 0xdca7b1 alpha_expand_mov(machine_mode, rtx_def**)
// ???:0
// 0x10d7ea9 gen_movv4hi(rtx_def*, rtx_def*)
// ???:0
// 0x7dcd97 emit_move_insn_1(rtx_def*, rtx_def*)
// ???:0
// 0x7dd15f emit_move_insn(rtx_def*, rtx_def*)
// ???:0
// 0xdccec6 alpha_expand_movmisalign(machine_mode, rtx_def**)
// ???:0
// 0x10d80e6 gen_movmisalignv4hi(rtx_def*, rtx_def*)
// ???:0
// 0xa053f8 expand_insn(insn_code, unsigned int, expand_operand*)
// ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See for instructions.
// /usr/lib/gcc-cross/alpha-linux-gnu/12/cc1 -quiet -imultilib . -imultiarch
alpha-linux-gnu -D SYSTEM_H="sys-clipper.h" console.c -quiet -dumpbase
console.c -dumpbase-ext .c -msmall-text -msmall-data -mno-fp-regs
-mbuild-constants -mcpu=ev67 -g1 -O2 -Wall -fdiagnostics-color=always
-fvisibility=hidden -fno-strict-aliasing -freport-bug -o - -frandom-seed=0
-fdump-noaddr
# 0 "console.c"
# 1 "/build/pkg/qemu-7.1+dfsg/b/qemu-palcode//"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "console.c"
# 21 "console.c"
# 1 "protos.h" 1
# 27 "protos.h"
typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long uint64_t;
typedef unsigned long size_t;
typedef __builtin_va_list va_list;
extern void *memset(void *, int, size_t);
extern void *memcpy(void *, const void *, size_t);
extern size_t strlen(const char *);
static inline void wrent(void *cb, unsigned long which)
{
register void *a0 __asm__("$16") = cb;
register unsigned long a1 __asm__("$17") = which;
asm volatile ("call_pal 0x34"
: "+r"(a0), "+r"(a1)
: : "$1", "$22", "$23", "$24", "$25");
}
static inline unsigned long swpipl(unsigned long newipl)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = newipl;
asm volatile ("call_pal 0x35"
: "=r"(v0), "+r"(a0)
: : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline unsigned long rdps(void)
{
register unsigned long v0 __asm__("$0");
asm volatile ("call_pal 0x36"
: "=r"(v0) : : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline void wrkgp(void)
{
asm volatile ("mov $29, $16\n\tcall_pal 0x37"
: : : "$16", "$1", "$22", "$23", "$24", "$25");
}
static inline unsigned long wtint(unsigned long skip)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = skip;
asm volatile ("call_pal 0x3e"
: "=r"(v0), "+r"(a0)
: : "$1", "$22", "$23", "$24", "$25");
return v0;
}
static inline unsigned long ldq_p(unsigned long addr)
{
register unsigned long v0 __asm__("$0");
register unsigned long a0 __asm__("$16") = 1;
register unsigned long a1 __asm__("$17") = addr;
asm volatile ("call_pal 9"
: "=r"(v0), "+r"(a0), "+r"(a1) :
: "$18", "$19",
Bug#1019096: bullseye-pu: package cifs-utils/2:6.11-3.1+deb11u2
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu There's a FTBFS issue with cifs-utils on bullseye, #993014. This update address that FTBFS issue only, with no other changes [ Reason ] The package fails to build from source when doing non-parallel build (or actually when doing parallel build too, sometimes), due to wrong ordering/dependencies in the upstream Makefile system. The problem is that the install target is two-part, and "second" part relies on mkdir done in "first" part, while not enforcing it. This (usually) succeeds when doing parallel build, but always fails when doing non-parallel build. [ Impact ] There's no other impact for the user besides the failure to build from source. [ Tests ] The build succeeded when doing either parallel or non-parallel build. Since there's no actual code changes, no other testing is necessary. [ Risks ] There's no risks here, since there's no code changes done. Only the build (ordering) fix, the same as applied to testing. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] The changelog entry: cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium * Fix non-parallel build. Closes: #993014. The fix adds an ordering/dependency rule to the Makefile, which ensures that the mkdir is done first and files created there only after that. [ Other info ] [ Debdiff ] diff -Nru cifs-utils-6.11/debian/changelog cifs-utils-6.11/debian/changelog --- cifs-utils-6.11/debian/changelog2022-05-10 23:12:42.0 +0300 +++ cifs-utils-6.11/debian/changelog2022-08-27 03:20:00.0 +0300 @@ -1,3 +1,9 @@ +cifs-utils (2:6.11-3.1+deb11u2) bullseye; urgency=medium + + * Fix non-parallel build. Closes: #993014. + + -- Michael Tokarev Sat, 27 Aug 2022 02:20:00 +0200 + cifs-utils (2:6.11-3.1+deb11u1) bullseye-security; urgency=high * Non-maintainer upload by the Security Team. diff -Nru cifs-utils-6.11/debian/patches/root_sbindir-hook.patch cifs-utils-6.11/debian/patches/root_sbindir-hook.patch --- cifs-utils-6.11/debian/patches/root_sbindir-hook.patch 1970-01-01 03:00:00.0 +0300 +++ cifs-utils-6.11/debian/patches/root_sbindir-hook.patch 2022-08-27 03:20:00.0 +0300 @@ -0,0 +1,11 @@ +--- a/Makefile.am b/Makefile.am +@@ -118,7 +118,7 @@ + + SUBDIRS = contrib + +-install-exec-hook: ++install-exec-hook: install-root_sbinPROGRAMS + (cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3) + + install-data-hook: diff -Nru cifs-utils-6.11/debian/patches/series cifs-utils-6.11/debian/patches/series --- cifs-utils-6.11/debian/patches/series 2022-05-10 23:12:42.0 +0300 +++ cifs-utils-6.11/debian/patches/series 2022-08-27 03:20:00.0 +0300 @@ -5,3 +5,4 @@ 0011-fix-regression-for-CVE-2021-20208.patch CVE-2022-27239-mount.cifs-fix-length-check-for-ip-op.patch mount.cifs-fix-verbose-messages-on-option-parsing.patch +root_sbindir-hook.patch
Bug#1019247: qemu-system-common: qemu-cpu-models documentation should be improved
Control: tag -1 wishlist 06.09.2022 11:31, Bastien Roucariès wrote: Package: qemu-system-common Version: 1:7.0+dfsg-7+b1 Severity: important Tags: upstream Control: affects -1 src:isa-support Dear Maintainer, The documentation qemu-system-common(7) is nice but incomplete: * a lot of arch are not present (we should at least add release arch) * -sse , -mmx and so on flags are not documented for x86 * for each CPU it will be nice to add the contents of getauxval(AT_HWCAP), getauxval(AT_HWCAP2), getauxval(AT_PLATFORM), if relevant getauxval(AT_BASE_PLATFORM), getauxval(AT_L*_CACHE*) * for arm add the supported instruction set, What QEMU calls "arm1136-r2" is actually the 1136 r0p2, i.e. an older core than plain "arm1136". In particular this does not have the v6K features. I'm not sure what to do with this bugreport. Personally I don't know what it is about, what does -sse, -mmx etc mean. As upstream would say, Patches welcome. Thanks, /mjt
Bug#1020776: qemu-system-data in bullseye-backports is too old
On 26.09.2022 17:39, Justin Ossevoort wrote: Package: qemu-system-data Version: 1:5.2+dfsg-11+deb11u2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: deb...@internetionals.nl Dear Maintainer, The latest packages in Debian Bullseye Backports depend on qemu-system-data (>> 1:7.1+dfsg~) But the current version in the Debian APT archives (and according to https://packages.debian.org/bullseye-backports/qemu-system-data) is: qemu-system-data (1:7.0+dfsg-2~bpo11+2) the current q-s-d hasn't been built - that's why it can't be installed. As Diederik correctly noted, this is because of the wrong dependency on gcc-alpha which does not exist on bullseye. Apparently I forgot to re- generate d/control in +bpo11+2 upload so the change didn't propagate to it, keeping q-s-d unbuildable. I'll fix this (with a 3-char change in d/control) when I'll return, hopefully next week. /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 09:41, Michael Tokarev wrote: .. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. And iirc, it was an upstream bug, the dependency should have been listed as non-private-something in the .pc file. /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 00:17, Michael Biebl wrote: .. Patching the upstream provided .pc file in Debian feels odd, tbh. Are you sure Requires.private is only relevant for static linking? Isn't this what Libs.private is for. Yes it feels odd indeed. The problem here is often due to lack of understanding how the .pc files work, which parts should go where. Myself I don't know either how it should be done. I asked about this several times in different places but each time the answers were different. So I ended up working in case-by-case basis: when a .pc file gets new Libs.private or Requires.private, I evaluate how this new library is actually being used, - and in all cases so far it was entirely internal thing not exposed in any way to the users of the said library, *unless* we want static linking (where regular debian shlib mechanism does not work, obviously). Here's just one example of this in one of my packages: https://salsa.debian.org/qemu-team/spice/-/blob/master/debian/rules#L31 (this one comes from #803926) Neither includes nor dynamic libs are needed to build stuff with libsamba-server, the only case where it's needed is when we try to build something statically, so that all libraries used by (non-existing by now) libspice-server.a are needed during link time. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. 18.10.2022 05:27, Adrian Bunk wrote: > The same command with all packages installed outputs: > > $ pkg-config --cflags virglrenderer > -I/usr/include/virgl -I/usr/include/libdrm > $ > > This would be required if headers under /usr/include/libdrm were > included by /usr/include/virgl/virglrenderer.h, but that isn't > the case. Exactly. And this is the case in many other situations too (eg my spice example above). In this very case, all extra dependencies are config-time stuff internal to virglrenderer, it does not change abi/api of its users. It is just that virglrenderer will be able (or not) to use extra features when asked. Even the header files with available options aren't being generated at build time, - it will return ENOSYS-like error at runtime when asked for an optional feature which is not compiled in. The interface of the library does not change in any way. I just don't know how it *should* be done. Maybe pkgconfig should not insist on something.private when asked for cflags? Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
According to the FAQ at
https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq :
My library z uses libx internally, but does not expose libx data types in its
public API.
What do I put in my z.pc file?
Again, add the module to Requires.private if it supports pkg-config. In this
case,
the compiler flags will be emitted unnecessarily, but it ensures that the
linker
flags will be present when linking statically.
So it is a common practice to add stuff to Requires.private, and it is not a
good idea
to ask upstream not to do that. With meson (as it is a case here), it
generates this
Requires.private automatically.
So it looks like removing this tag at install time is the way to go after all,
unless meson grows an easy way to omit these.
An alternative is to maintain "proper" Depends for the foo-dev package.
("proper" is in quotes, because it is only needed to satisfy pkg-config
wishes).
*sigh*.
/mjt
Bug#1021981: qemu: wrong behave for bash in qemu-loongarch64-static
Control: tag - + confirmed upstream Control: retitle -1 qemu-user: faccessat2 is not implemented 18.10.2022 12:02, 张 宁 wrote: Package: qemu-user-static Version: 1:7.1+dfsg-2 Hi, Debian Qemu team I find wrong behave for bash in qemu-loongarch64-static. Well. faccessat2 is not implemented by qemu-user. This is a lack of feature. For all other architectures this is not an issue since the syscall is new and even the programs actually using it usually have a workaround using faccessat() or something else. But for loongarch64 it is an issue, because this whole architecture is new, and it uses faccessat2 *only*, without any fallback to older implementations, - since there was no older implementations to begin with. .. https://patchew.org/search?q=project%3AQEMU+faccessat2 there are 3 patches, any of these can fix this issue. There are 3 patches, neither one of them is complete. But at any rate, I will not "fix" (actually implement) this in Debian before it is fixed/implemented upstream properly. This is definitely a qemu upstream issue, not a debian issue. From this point of view, I don't quite like bugreports like this, debian qemu bts is full of bugreports already, it is very unlikely these will ever be cleaned out: I don't have a time to verify if they're fixed or not on every qemu release, - I definitely have better use for my time. This bugreport will most likely stay like many many other bugreports already filed against the qemu packages in debian. Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
Ok. This package appears to lack some love. Bugs are never closed (I just closed a few bugreports which were fixed years ago), migration status apparently is never checked, bugs actually are not watched/handled (these 2 bugs are here for quite some time already). I pinged the maintainer but he didn't respond. I just uploaded virglrenderer package with current issues fixed, so things can be unblocked. Longterm, I'm fine to move this package under qemu umbrella (especially since it is relevant mostly for qemu these days). Thanks, /mjt
Bug#1022767: samba: Should not build-depend on librados-dev on ppc64 and x32
Control: tag -1 + moreinfo unreproducible 25.10.2022 16:41, John Paul Adrian Glaubitz wrote: Source: samba Version: 2:4.16.6+dfsg-2 Severity: normal User: debian-powe...@lists.debian.org Usertags: ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hi! After ceph support was disabled on ppc64 and x32 as requested in #1012165 and #1020781, there is still a dependency on librados-dev left in debian/ control for ppc64 and x32. Hmm. Just-uploaded 2:4.16.6+dfsg-2 has this in d/control: $ egrep 'libceph|librados)' debian/control libcephfs-dev [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x], librados-dev [amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x], There's no x32 or ppc64. Or do you mean ppc64el should be removed *too*? I know nothing about variants of powerpc. And I don't see buildds in Debian doing builds for ppc64el. At least it is not shown on usual build status pages. What exactly is failing for you? Thanks, /mjt
Bug#941930: smbclient: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX with maxprotocol=NT1
Control: tag -1 + confirmed upstream Control: found -1 2:4.17.2+dfsg-1 Control: found -1 2:4.16.6+dfsg-2 On Mon, 07 Oct 2019 19:13:12 +0200 luca wrote: Package: smbclient Version: 2:4.11.0+dfsg-10 Severity: normal Dear Maintainer, after update in testing of samba pkgs version 2:4.11.0+dfsg-10 maxprotocol=NT1 seems no more working as aspected -- $ smbclient 192.168.0.101\\tmp Unable to initialize messaging context Enter BDEV\ilprof's password: Try "help" to get a list of possible commands. smb: \> -- but with maxprotocol=NT1 -- $ smbclient 192.168.0.101\\tmp -m NT1 Unable to initialize messaging context protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX -- This seems to be a problem with command-line parameter parsing of smbclient, or parameter logic. In man smb.conf, there's "client min protocol" parameter, which is SMB2_02 in current version (4.16) of samba. And smbclient has its own option, -m, or --max-protocol, which is used here. It looks like smbclient *might* error out at least in case min protocol is larger than the specified max protocol. Or better yet, fix min protocol to be the same as max protocol in this case (unless it is explicitly set in the smb.conf file). In order for smbclient to actually use NT1 protocol, one have to also specify "client min prococol = NT1" - either in smb.conf or in additional --option command-line option. I dunno why upstream did it this way - either by design, or it wasn't intended to be this way. Let's ask upstream.. /mjt
Bug#1022775: [Pkg-samba-maint] Bug#1022775: samba: breaks apt upgrade
Control: tag -1 + confirmed pending Control: severity -1 serious 25.10.2022 19:59, Nicolas Patrois wrpte: ... tentative de remplacement de « /etc/pam.d/samba », qui appartient aussi au paquet samba-common 2:4.16.6+dfsg-2 wug. Fixing it. I wonder how it happened to escape my local installation?.. /mjt
Bug#1022574: [Pkg-samba-maint] Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?
24.10.2022 15:47, Samuel Wolf wrote: Is the backports Samba package also monitored for security issues? It is not. Just like bullseye samba package. For security and general bugfix support, we basically rely on upstream samba team. Once a security update is out, I tend to make it available to debian almost available in terms of unstable/testing and backports. Debian bullseye/stable version only receives "easily backportable" fixes. /mjt
Bug#1022826: [Pkg-samba-maint] Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1
Control: tag -1 + moreinfo unreproducible 26.10.2022 17:45, Arnaud Rebillout wrote: Package: samba-common-bin Severity: normal User: de...@kali.org Usertags: origin-kali Dear Maintainer, This command fails: # testparm /etc/samba/smb.conf --suppress-prompt Load smb config files from <> Error loading services. Which version of samba-common-bin is that? I was about to close this bug right away because you didn't specify a version. But I'd give it a try anyway. The thing is that the libpopt is bundled with samba sources, and current samba in debian unstable (4.16.6+dfsg-3) already has the necessary fixes for it. There should be, in theory, no issues with the fixed/new libpopt. I just tested that one with current libpopt, - it works as expected here. /mjt
Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1
Control: found -1 2:4.16.6+dfsg-3 Control: tag -1 - moreinfo unreproducible Control: tag -1 + confirmed 26.10.2022 18:34, Arnaud Rebillout wrote: .. So this is version 2:4.16.6+dfsg-3. Right now I can fire a Debian sid container and reproduce the issue with: Ok, that's excllent, thank you! # apt update && apt install -y smbclient # testparm /etc/samba/smb.conf --suppress-prompt Load smb config files from gW???U Error loading services. NB: you MUST pass /etc/samba/smb.conf in argument to trigger the issue. Aha. Got it. The issue with libpopt seems to be documented at https://github.com/rpm-software-management/popt/issues/80. Lemme see.. However I didn't notice that samba embeds its own libpopt, so now I'm confused. Are you 100% sure it's the embedded lib that is used? I'm 100% sure it is *not* the embedded copy which is used, due to this: https://salsa.debian.org/samba-team/samba/-/blob/debian/2%254.16.6+dfsg-3/debian/rules#L85 --bundled-libraries=NONE,pytevent,ldb # ldd /usr/bin/testparm | grep popt libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x7f52a45d1000) Or does the line above suggests that it uses the shared library? (real question, I'm not familiar with ldd) It uses the system shared lib, exeactly as it should. Samba had adoptations for the libpopt changes and changed internal popt too, that's why I was confused as well. Anyway, lemme look at this now when I know the version and the environment, and was able to reproduce it. Thanks, /mjt
Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1
Control: forward -1 https://bugzilla.samba.org/show_bug.cgi?id=15205 Control: tag -1 + upstream patch Ok, there's a bugreport in samba (see above), and the fixes went to 4.17.1, but not to 4.16.6 (they're in 4.16-test, though. I can probably make another 4.16 upload - was thinking about making 4.17 the default finally but decided to wait for yet another minor release due to another symlink attack issue found in the new 4.17 code. Oh well. I hate useless work, - it is useless to push the already pending patches. But the next 4.16.7 is scheduled for Jan 05 2023, which is quite some time from now. Hwell.. /mjt
Bug#942433: samba: Cannot mount share on samba3 server from samba4 client: protocol negotiation failed
Control: tag -1 + moreinfo Hi! This bug appears to be about an old samba version (4.11). There were a few corner cases with old protocols negotiation fixed meanwhile, including some bugs reported in the Debian BTS. Current 4.16 client can mount shares from older servers, including old samba and windows XP, provided there's a way to enable older protocols. It looks like what's left is a way for qemu slirp (usermode) networking to be able to add an option to enable old protocols when running smbd. And this is definitely a qemu job to do. What do you think? Thanks, /mjt
Bug#931717: samba: CUPS printing fails with NT_STATUS_LOGON_FAILURE in 4.9.11+dfsg-1
Control: tag -1 + moreinfo On Tue, 09 Jul 2019 22:35:34 +0800 Wenbin Lv wrote: Package: samba Version: 2:4.9.11+dfsg-1 Severity: important I can no longer print in CUPS using samba backend after upgrading samba to 4.9.11+dfsg-1. The error code given by CUPS is NT_STATUS_LOGON_FAILURE, although I did not change the smb:// URI so the credentials are known to be correct. Downgrading to 4.9.5+dfsg-5 fixes the problem. Is it still an issue with current samba (4.13 in bullseye and 4.16 in bookworm and bullseye-backports)? Thanks, /mjt
Bug#946419: samba-vfs-modules: Resource forks are truncated when written to fruit-enabled share
Control: tag -1 + moreinfo On Sun, 08 Dec 2019 13:09:44 -0800 Keith Kaisershot wrote: Package: samba-vfs-modules Version: 2:4.11.1+dfsg-3 Severity: important I use vfs_fruit with a Samba share serving various older versions of Mac OS X, from 10.6 up through 10.11, archiving classic Mac files dating back to the mid 80s. With the latest Samba 4.11.1 in Debian testing, writing one of these older files with a resource fork larger than 64K results in the resource fork portion getting truncated to 65454 bytes on the server end. This corrupts old Mac files with resource forks larger than 64K-- executables are the most affected by this, but graphic files such as PICT are too. Looks like this is a regression, as this issue does not occur in 4.9.5 from Debian stable. Repro steps: 1) Copy a classic 68K Mac OS application > 65K from a Mac OS X 10.11 client to a Samba 4.9.5 host. (I used ircle 1.5.6 as a test case here.) I don't have any MacOS systems anywhere around to test this. Is this still an issue with current samba -- 4.13 in bullseye or 4.16 in bookworm and bullseye-backports? Thanks, /mjt
Bug#1022945: smbclient: ambiguous duplications in the smbclient(1) manpage
28.10.2022 10:28, Patrice DUROUX wrote: Package: smbclient Version: 2:4.16.6+dfsg-5 Severity: wishlist Dear Maintainer, The smbclient(1) manpage contains some multiple entries in the OPTIONS section regarding the SYNOPSIS list. Umm. This is all good. But samba upstream is difficult to deal with. I definitely don't have enough time/energy to fight there. If you do have it, please open bug in bugzilla.samba.org, and/or create a merge request for in on gitlab.com - maybe this way it will be easier. This bugreport will most likely stay in the bts forever and uselessly attract my attention... hwell... :( Thanks, /mjt
Bug#1022574: samba: Kerberos 22H2 Samba problem in Debian stable | Backports Version or Stable Update?
Control: tag -1 confirmed upstream patch Control: forwarded -1 https://bugzilla.samba.org/show_bug.cgi?id=15197 Control: severity -1 important 24.10.2022 12:22, Samuel Wolf wrote: Package: samba Version: 2:4.13.13+dfsg-1~deb11u5 Severity: normal Hello, is it possible to patch the Samba version in Debian stable with the Kerberos patch? Yes it is possible, more, it is trivial to _patch_ it. But it is not that easy to make the resulting binaries into the archive. Tomorrow expected another security update for samba, - if that affects bullseye too, I hope to get all fixes together for the next update. Or should we moving forward to the Samba Backports version until the next Debian stable release? This is a preferred way regardless. 4.13 is not supported upstream anymore, and all our support of 4.13 in debian is even more limited than that. More. 4.16 in bpo is much more accurate. https://bugzilla.samba.org/show_bug.cgi?id=15197 Yeah, I know about this issue. Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
16.10.2022 08:04, Adrian Bunk wrote: ... With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A7.1%2Bdfsg-2%2Bb1=1665894634=0 The complete list is currently: $ pkg-config --cflags virglrenderer Package epoxy was not found in the pkg-config search path. Perhaps you should add the directory containing `epoxy.pc' to the PKG_CONFIG_PATH environment variable Package 'epoxy', required by 'virglrenderer', not found Package 'libdrm', required by 'virglrenderer', not found Package 'gbm', required by 'virglrenderer', not found Package 'vulkan', required by 'virglrenderer', not found Package 'libva', required by 'virglrenderer', not found Package 'libva-drm', required by 'virglrenderer', not found $ In practice, most/all of the -dev build dependencies also have to become dependencies of libvirglrenderer-dev. Actually this is an interesting question and a quite common issue. This package does not provide a static library. All the mentioned packages are listed in Requires.private pkgconfig tag: Version: 0.10.3 Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, vulkan, libva, libva-drm The thing is: these are needed by a static-link library (dynamic .so libs are already handled by debian package dependencies). They're not used when building other software with libvirglrenderer. It is only pkg-config which fails to find them, for actual usage these are not needed. I used to remove Requires.private: tags from the .pc files in such cases, entirely, because it makes no sense in this context. And it makes build just a bit faster too. But indeed, many maintainers tend to add lots'a stuff to Depends. I'd remove the Requires.private here as well. What do you guys think? /mjt
