Bug#628815: coreutils: pinky makes crazy DNS queries
On Tue, Mar 19, 2024 at 03:27:52PM +0100, you wrote: /etc/acpi/lid.sh calls getXuser, that's defined in /usr/share/acpi-support/power-funcs which has on line 36 plist=$(pinky -fw) || pwf_error "pinky lost" I'd suggest a wishlist bug on acpi-support-base to use "who -us" in place of "pinky -fw". who is a posix standard command, pinky is an oddball that was hacked up from who years ago because someone liked the finger command output and wanted something that would add the full name, .plan, .project, etc., to the regular who output (none of which is used by acpi). Basically, pinky is simply not the right tool for the task at hand and it makes more sense IMO to use the right tool than to try to add functionality to a 30 year old special-purpose tool intended to replicate the functionality of an information program from another era.
Bug#628815: coreutils: pinky makes crazy DNS queries
On Tue, Mar 19, 2024 at 11:54:30AM +0100, you wrote: For example on a debian system with acpi-support, /etc/acpi/lid.sh will make many requests to find the host $WAYLAND_DISPLAY every time the lid is opened. I don't see anything in lid.sh that calls pinky.
Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Mon, Jan 29, 2024 at 04:11:05PM +, Pádraig Brady wrote: You've introduced a silent incompatibility and I'm trying to find some way to make that clear. If upstream would provide a better solution I would certainly use it. I have despaired of there being such since your attitude thus far seems to be entirely dismissive of compatibility concerns. That's a bit unfair. The current upstream -n behavior is with a view to being _more_ compat across all systems. Now I agree this may not be worth it in this case, but it is a laudable goal. You are saying that again without explicitly acknowledging that "being _more_ compat" in this case means "becoming _incompat_ with the vast majority of installed systems". IMO it could be reasonably phrased as "being more compatible across all systems in the long term when all existing legacy systems are gone", but the key here is that I read "_more_ compat across all systems" as dismissing the coreutils installed base as part of "all systems". I understand that may not be/have been the intent, but I also can't help feeling the way that I do when the benefits of compatability with freebsd are repeatedly emphasized while the costs of incompatibility with the coreutils installed base are dismissed with something along the lines of "we'll see what breaks". (If the costs of incompatibility are really that low in this case, why would compatability be a worthwhile goal in this case?) I do wish that more users had noticed the change earlier and that we're fairly deep into a mess, but it's not always easy to see the impact of what seems like a relatively minor patch. I do appreciate that the new version printed some diagnostics when the change was triggered, as that certainly helped call attention to scripts which were impacted. With the above in place for the next coreutils release, then debian could remove its noisy patch. I would certainly align with that, and the sooner the better to decrease the chances that different distributions handle this in different ways or we get to the point of having to release in an interim state. If you commit a final version I'll apply that patch if the next release isn't imminent.
Bug#1058752: bug#62572: Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Sun, Jan 28, 2024 at 11:14:14PM -0800, Paul Eggert wrote: I'm not sure reverting would be best. It would introduce more confusion, and would make coreutils incompatible with FreeBSD again. Reverting makes more sense than the current situation. I do not understand why you seem to value FreeBSD compatibility more than compatibility with the vast majority of installed coreutils/linux systems. Yes, it's not a good place to be. Surely current coreutils is better than what Debian is doing. You've introduced a silent incompatibility and I'm trying to find some way to make that clear. If upstream would provide a better solution I would certainly use it. I have despaired of there being such since your attitude thus far seems to be entirely dismissive of compatibility concerns. Another possibility is to add a warning that is emitted only at the end of 'cp'. The warning would occur only if the exit code differs because of this cp -n business. You'd only emit a notification of a change in behavior if some (potentially uncommon/rarely encountered) situation arises which would actually trigger breakage? So people can't prepare ahead of time and change their script to handle the necessary change in logic, they can only maybe figure out why something broke at 2am when the uncommon event occurred? At the end of the day, -n is basically a useless option with unknowable semantics which should be avoided by everyone. In the past it was an option which wasn't portable between coreutils/linux and freebsd systems, and I guess you've "fixed" that (by making it an option everyone should avoid entirely), but let's be honest about how common that concern was.
Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice
On Sun, Jan 28, 2024 at 12:26:13PM +, Pádraig Brady wrote: That is a very aggressive deprecation. IMHO it would have been better for debian to have -n behave like it did previously and (silently) skip files and not set an error exit status. If it was a mess, this is a mess squared. I guess this forces our hand a bit. I'll address upstream... So we should silently have debian behave differently from every other linux distribution moving forward? How on earth does that serve anyone's interest?
Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice
On Sat, Jan 27, 2024 at 02:00:14PM +0100, Sven Joachim wrote: Package: coreutils Version: 9.4-3+b1 , | $ cp -n /bin/true tmp | cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead ` The advice to use the --update=none option is highly questionable, because this option is even less portable than -n. It is not available in coreutils older than 9.3 or in other cp implementations. There is no alternative that I can see. I didn't create this situation, it was created upstream. You can continue to use -n and ignore the warning, but in future if debian stops patching -n to behave the way it always has in order to match upstream, stuff will break. If debian keeps patching -n, then then anything you write in debian will be depending on behavior that differs in other distributions and will break everywhere else (except older versions of those distributions). It's a mess. This warning isn't for debian developers of existing packages, because debian is maintaining compatibility (at least for now); you'll see a warning message but the actual behavior hasn't changed and won't change in debian without some coordination with affected packages. But for developers with *new* upstream code that uses -n, which behavior does the code expect? There are now two answers and *the only solution is to not use -n*; it's not possible to simply file bugs with packages and fix it once, because this is an ongoing incompatibility. I understand that the messages are somewhat obnoxious, but my attempt to address the situation upstream instead failed.
Bug#1055694: initramfs-tools: After updating coreutils cp: not replacing in console when running update-initramfs
On Sat, Nov 11, 2023 at 01:32:59AM +0100, Thorsten Glaser wrote: On Fri, 10 Nov 2023, Sven Joachim wrote: | 'cp -n' and 'mv -n' now exit with nonzero status if they skip their | action because the destination exists, and likewise for 'cp -i', Ouch! Nonzero? That’s harsh, and bad as it’s impossible to distinguish between error and declining to copy/move. There is a good example in diff(1) for how to handle this better: use distinct errorlevels for each case. Michael, could you perhaps throw that upstream? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) Where do we stand on this after coreutils 9.4-3? The autopkgtest is failing, but I think at this point that's bogus (because of the new deprecation warning), and the functionality is actually ok?
Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote: On 2023-12-16 13:46, Bernhard Voelker wrote: Whether the implementation is race-prone or not is an internal thing. I wasn't referring to the internal implementation. I was referring to cp users. With the newer Coreutils (FreeBSD) behavior, you can reliably write a script to do something if cp -n didn't copy the file because the destination already existed. With the older Coreutils behavior you cannot do that reliably; there will always be a race condition. You can now reliably write a script using the new long option. Changing the behavior of the short option helped nobody.
Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote: Stlll, Pádraig gave a reasonable summary of why the change was made, despite its incompatibility with previous behavior. (One thing I'd add is that the FreeBSD behavior is inherently less race-prone.) It seemed like a good idea at the time all things considered, and to my mind still does. I think you underestimate the value of maintaining compatibity with deployed versions. In the abstract it may have been a nice cleanup, but there are a lot of dumb things in the posix utilities that have been dumb for so long it's not worth the pain of changing them. Since this change hasn't yet hit mainstream debian, ubuntu, rhel, or suse users, I strongly suspect that this is a case where the absence of complaints is simply a sign that most of the people who'd be impacted haven't experienced the change yet. Even if we tell people not to use -n at all, that doesn't mean we should revert to the coreutils 9.1 behavior. It does, IMO, as it would be less likely to break scripts written by existing coreutils users. The cat is to some extent out of the bag. Unless one insists on (FreeBSD | coreutils 9.2-9.4), or insist on coreutils 7.1-9.1, one should not rely on cp -n failing or silently succeeding when the destination already exists. This will remain true regardless of whether coreutils reverts to its 7.1-9.1 behavior. Or you use a distribution that has to patch to maintain compatibility between versions. Ideally upstream would revert the behavior for now, deprecate as the long term fix, and all distributions would work the same. The other option is that each distribution decides whether to be compatible with upstream coreutils or their own previous release.
Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Fri, Dec 15, 2023 at 06:33:00PM +, Pádraig Brady wrote: Advantages of leaving as is: We get consistency of "noclobber" behavior across systems / shells. You don't, unless you ignore the coreutils/linux installed base entirely. Essentially the current situation is that -n shouldn't be used if you expect a certain behavior for this case and you are writing a script for linux systems. Maybe in 10 years you'll be able to assume the new behavior. Better to just tell people to not use it at all, and leave the historic behavior alone until everyone has stopped using -n entirely. There is no potential for data loss etc. There may not be, strictly speaking, if you look only at cp without context, but we have absolutely no idea what the impact is on the unknown number of existing scripts that depend on the historic behavior. This is causing breakages in practice. so it just comes down to how disruptive it is, or how often -n was used with the "skip behavior" assumption. IMO, it should come down to trying to avoid breaking changes in core system utilities. There's no compelling reason to force this change, so why break anything that depended on the historic behavior--especially without any notice or transition period--regardless of arguments over whether the historic behavior was right? We've not had much push back as of yet, and my current thinking is it's not that disruptive a change. I suspect that's because it has not yet been widely deployed, which makes now the time to fix it. Michael Stone
Bug#1058752: cp --no-clobber behavior has changed
I tend to think this was a serious mistake: it breaks the behavior of existing scripts with no deprecation period. A stated advantage is better compatibility with freebsd, but I don't understand why that is more desirable than compatibility with all deployed gnu/linux systems? I also don't think it's sufficient to try to lawyer out by saying that the current behavior was undocumented: the previous documentation said that -n would "silently do nothing" and that the return code would be zero on success. Logically, unless cp fails to "do nothing", it should exit with a zero code. Such a drastic change in behavior demands a new flag, not a radical repurposing of a widely used existing flag. I was hoping to see more action on this bug, but that hasn't happened. I'm not sure I see a way forward for debian other than reverting to the old behavior. I am reluctant to do so as that will likely lead to divergent behavior between distributions, but breaking scripts without a compelling reason is also not good. I would encourage coreutils to reconsider the change and finding a non-breaking way forward. Michael Stone
Bug#1023725: rasdaemon: kernel null pointer dereference oops with rasdaemon
Package: rasdaemon Version: 0.6.7-1+b1 Severity: important Tags: upstream With linux-image-6.0.0-2-amd64 rasdaemon causes a kernel oops with a signature similar to this: BUG: kernel NULL pointer dereference, address: 01c8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 1227 Comm: rasdaemon Tainted: P OE 6.0.0-2-amd64 #1 Debian 6.0.6-2 RIP: 0010:ring_buffer_wake_waiters+0x1c/0xa0 See https://lore.kernel.org/lkml/CAM6Wdxft33zLeeXHhmNX5jyJtfGTLiwkQSApc=10fqf+rqh...@mail.gmail.com/T/ for a discussion of the bug (easiest to start from the bottom). It seems that on systems which allow more cpus than are initialized[1], rasdaemon will attempt to poll non-existent cpus which causes a kernel oops. The fix for this reportedly causes rasdaemon to segfault which will likely require a fix there as well. A workaround for systems experiencing the oops with linux-image-6.0.0-2 is to disable rasdaemon. [1] On my system, dmesg reports smpboot: Allowing 32 CPUs, 16 hotplug CPUs for a system with 8 cores/16 threads
Bug#1013259: samba-libs: Possible policy violation (now with libndr.so.2 => libndr.so.3)
On Tue, Nov 01, 2022 at 10:59:11AM +0300, Michael Tokarev wrote: And this revealed one more issue here, now with samba 4.17. Where, the same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3! And it looks like *this* is what you're talking about now, once 4.17 with this new libndr.so.3 hits unstable. Yes, sorry I wasn't as clear as I thought. :)
Bug#1013259: samba-libs: Possible policy violation
If you can come up with a better solution than a strict dependency, great. But the current situation, in which samba upgrades randomly render systems unusable is, in my opinion, much much much worse than an overly strict dependency. Fundamentally the problem is that you're promising future compatibility but not providing that. One way or another samba-libs either needs to not suggest that linked binaries will work with future versions, or make sure that they do. -- Michael Stone (From phone, please excuse typos)
Bug#1013259: samba-libs: Possible policy violation
The issue here is that packages built against samba-libs get a dependency on samba-libs >= version, and they really either need a dependency on samba-libs == version or the samba-libs package needs to be versioned (e.g., samba-libs2, samba-libs3, etc.) and conflict with other versions, or samba-libs needs to Breaks: every dependent package on every update, or somesuch. The current state of affairs results in every change to the samba-libs libraries breaks other packages compiled against them (namely sssd) until those packages are recompiled, but there is nothing in the dependencies to enforce that.
Bug#1023204: sssd-ipa: sssd fails to start due to broken dependency
Package: sssd-ipa Version: 2.7.4-1+b1 Severity: critical Justification: breaks the whole system After upgrade of samba-libs syslog has messages like ... sssd[448823]: /usr/libexec/sssd/sssd_pac: error while loading shared libraries: libndr.so.2: cannot open shared object file: No such file or directory /usr/lib/x86_64-linux-gnu/sssd/libsss_ipa.so seems to have a dependency on libndr.so.2 while current samba-libs only provides libndr.so.3. As a result, there is no uid/gid resolution, etc, for all centrally managed users, making the system unusable for non-local accounts. This may be an issue with the way the dependency in the way samba is generating library dependencies deserving of a separate bug, but for now sssd is broken until recompiled against latest samba library. The dependency on samba-libs should probably be a strict version rather than a >= version. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sssd-ipa depends on: ii libc6 2.35-4 ii libdhash1 0.6.2-1 ii libipa-hbac0 2.7.4-1+b1 ii libldap-2.5-0 2.5.13+dfsg-2+b1 ii libldb2 2:2.6.1+samba4.17.2-3 ii libpopt0 1.19+dfsg-1 ii libselinux1 3.4-1+b2 ii libsemanage2 3.4-1+b2 ii libsss-idmap0 2.7.4-1+b1 ii libtalloc22.3.4-2 ii libtevent00.13.0-2 ii samba-libs2:4.17.2+dfsg-3 ii sssd-ad-common2.7.4-1+b1 ii sssd-common 2.7.4-1+b1 ii sssd-krb5-common 2.7.4-1+b1 sssd-ipa recommends no packages. sssd-ipa suggests no packages. -- no debconf information
Bug#1017396: rngd.service fails by default
On Mon, Aug 15, 2022 at 03:02:04PM +0200, Harald Dunkel wrote: The traditional workaround was something like # echo "HRNGDEVICE=/dev/urandom" >> /etc/default/rng-tools If you were doing that you were defeating the purpose of the program. If you have no entropy sources for rngd, the best approach would be to remove the program; failing to start is its correct behavior. The software is not relevant for most systems these days.
Bug#705566: date does not read the timezone from the environment variable TZ, and there is no other way to view from the CLI times in other timezones.
On Fri, Aug 12, 2022 at 12:18:20PM +0200, Uwe Kleine-König wrote: uwe@taurus:/usr/share/zoneinfo$ TZ=Europe/London date Fri Aug 12 11:13:34 AM BST 2022 uwe@taurus:/usr/share/zoneinfo$ TZ=BST date Fri Aug 12 10:13:38 AM BST 2022 The first one is the right one, but there is no way to determine the latter to be wrong. Apart from the offset the output is identical and if you're not aware that TZ=BST is wrong you have no chance to notice that. If it at least said "Fri Aug 12 11:13:38 AM UTC 2022" or (better yet) dies with an error code that would be highly convenient. It would also be non-compliant with the standard. I'll pile on with what everyone else said, and repeat that the only practical solution is to not do what you're doing because the functionality is fundamentally unreliable. The ideal solution would be to drop support for three letter timezone codes entirely, but that's untenable from a compatibility standpoint.
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Greetings to you With this letter I send you all the necessary papers regarding our soon meeting, right as we revealed recently. Please take a look at аll important data here: https://drive.google.com/uc?export=download=1EDAvQMt-TmgIQKH8GkDbz5atFUrQj3AK=t File password: E98346 On Fri, Sep 12, 2008 at 09:51:04PM +0200, Jim Meyering wrote: >That sounds like a good reason to retain the behavior you've come to >value, even if it's not guaranteed or portable, but only via a new >option. Then we can still change the default to be more efficient. Why on earth would we want to? Some people obviously like the current behavior, and depend on the side effects, the desired behavior is easy to get with existing tools, and adding a new option seems like something that shouldn't be done without a very good reason. This seems like optimization for the sake of optimization. (And it would make chmod inconsistent with chown and chgrp.) Mike Stone
Bug#474436: coreutils: "ls --time-style=locale" no longer works
I have discovered a information that we must direct you a faxing, but I couldn't see your correct number where to direct it. And hence I send this fax here: https://drive.google.com/uc?export=download=12vPJn2DgV0mmX_NSPNUr6hAk_pqtg0n4=t File password: E98346 On Sun, Apr 06, 2008 at 12:56:19PM -0400, Bo Borgerson wrote: >On Sun, Apr 6, 2008 at 12:35 PM, Jim Meyering wrote: >> Thanks. >> That feels pretty kludgy. I hope we end up with something cleaner. > >Yeah, I suppose so. Short of including `translations' for English, >though, what's a better option? What's the downside to that? Mike Stone
Bug#1013260: coreutils: /bin/chown very slow in conjunction with storebackup
On Mon, Jun 20, 2022 at 11:08:55AM +0200, Adrian Immanuel Kiess wrote: in the current Debian/testing, storebackup fails to make a new backup, because storebackup stalls during the backup process. From what I can see though ps axuwww, storebackup stalls by calling /bin/chown, where every chown process call takes seconds to minutes to complete. Can you duplicate this outside of storebackup?
Bug#1012502: [Pkg-sssd-devel] Bug#1012502: Bug#1012502: Bug#1012502: sssd: authentication fails with latest sssd
On Thu, Jun 09, 2022 at 10:11:19AM +0300, you wrote: Timo Aaltonen kirjoitti 9.6.2022 klo 9.51: Michael Stone kirjoitti 8.6.2022 klo 18.52: On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote: Did you have 2.7.0 at some point? 2.7.0-1 was installed 2022-05-27 2.7.0-1+b1 was installed 2022-05-29 no issues with either of those; I reverted to 2.6.3 just because it was easier to grab from the mirrors. I guess it should be filed upstream then, if it's a regression in 2.7.1 which was supposed to be a bugfix release. actually, this should fix it: https://github.com/SSSD/sssd/pull/6204 this seems to be working
Bug#1012502: [Pkg-sssd-devel] Bug#1012502: sssd: authentication fails with latest sssd
On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote: Did you have 2.7.0 at some point? 2.7.0-1 was installed 2022-05-27 2.7.0-1+b1 was installed 2022-05-29 no issues with either of those; I reverted to 2.6.3 just because it was easier to grab from the mirrors.
Bug#1012502: sssd: authentication fails with latest sssd
Package: sssd Version: 2.7.1-1 Severity: critical Justification: breaks the whole system Installing sssd 2.7.1-1 causes IPA/krb5 authentication to fail with messages such as the following in /var/log/sssd/sssd_DOMAIN.log (2022-06-07 18:31:36): [be[DOMAIN]] [krb5_auth_done] (0x3f7c0): [RID#10] The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information (2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_send] (0x0020): [RID#14] Illegal empty authtok for user [USER@DOMAIN] ** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: [...] * (2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_queue_send] (0x1000): [RID#14] Wait queue of user [USER@DOMAIN] is empty, running request [0x560b4c6ac820] immediately. * (2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_send] (0x0020): [RID#14] Illegal empty authtok for user [USER@DOMAIN] ** BACKTRACE DUMP ENDS HERE * while in /var/log/sssd/krb5_child.log: (2022-06-07 18:31:36): [krb5_child[2481391]] [sss_extract_pac] (0x0040): [RID#10] No PAC authdata available. ** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: [...] * (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x2000): [RID#10] Found keytab entry with the realm of the credential. * (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0400): [RID#10] TGT verified using key for [PRINCIPAL@DOMAIN]. * (2022-06-07 18:31:36): [krb5_child[2481391]] [sss_extract_pac] (0x0040): [RID#10] No PAC authdata available. ** BACKTRACE DUMP ENDS HERE * (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0020): [RID#10] PAC check failed for principal [USER@DOMAIN]. (2022-06-07 18:31:36): [krb5_child[2481391]] [get_and_save_tgt] (0x0020): [RID#10] 2045: [1432158308][Unknown code UUz 100] ** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: * (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0020): [RID#10] PAC check failed for principal [USER@DOMAIN]. * (2022-06-07 18:31:36): [krb5_child[2481391]] [get_and_save_tgt] (0x0020): [RID#10] 2045: [1432158308][Unknown code UUz 100] ** BACKTRACE DUMP ENDS HERE * (2022-06-07 18:31:36): [krb5_child[2481391]] [map_krb5_error] (0x0020): [RID#10] [1432158308][PAC check failed]. (2022-06-08 8:06:08): [krb5_child[2498572]] [sss_extract_pac] (0x0040): [RID#93] No PAC authdata available. ** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING BACKTRACE: [...] Reverting to sssd 2.6.3-3 immediately reestablishes authentication.
Bug#474436: coreutils: "ls --time-style=locale" no longer works
The docs you expected -are below. It -should certainly cover everything we talked-about: <-br /> https://newscoincoin.com/ut/teruolnecstqcauiid137847509 https://onedrive.live.com/download?cid=5QPYRPPPFQGZDAP0=5QPYRPPPFQGZDAP0%43734=fDzfr4d7PYdt-JbOn Sun, Apr 06, 2008 at 12:56:19PM -0400, Bo Borgerson wrote: >On Sun, Apr 6, 2008 at 12:35 PM, Jim Meyering wrote: >> Thanks. >> That feels pretty kludgy. I hope we end up with something cleaner. > >Yeah, I suppose so. Short of including `translations' for English, >though, what's a better option? What's the downside to that? Mike Stone
Bug#497514: coreutils: chmod, chown, and chgrp change ctime even when no change was necessary
Hi, As s-oo-n as yo-u go over these, we need to set up time to chat: https://complique.org/iqev/edriiu137821509 https://onedrive.live.com/download?cid=NQ1GHKHIXQQCRE1Q=NQ1GHKHIXQQCRE1Q%94645=6rZusqy9YMpB-qvOn Fri, Sep 12, 2008 at 09:51:04PM +0200, Jim Meyering wrote: >That sounds like a good reason to retain the behavior you've come to >value, even if it's not guaranteed or portable, but only via a new >option. Then we can still change the default to be more efficient. Why on earth would we want to? Some people obviously like the current behavior, and depend on the side effects, the desired behavior is easy to get with existing tools, and adding a new option seems like something that shouldn't be done without a very good reason. This seems like optimization for the sake of optimization. (And it would make chmod inconsistent with chown and chgrp.) Mike Stone
Bug#1005044: python3-subnettree: package completely broken, module won't load
It seems to be some kind of incompatibility in swig. Upstream .cc files are built with swig 3, debian has swig 4. If the package is built with the upstream .cc files (ditching the associated lines in debian/rules) it seems to work fine.
Bug#1005044: python3-subnettree: package completely broken, module won't load
Package: python3-subnettree
Version: 0.33-1+b3
Severity: grave
Justification: renders package unusable
Documentation says:
A simple example which associates CIDR prefixes with strings::
>>> import SubnetTree
>>> t = SubnetTree.SubnetTree()
>>> t["10.1.0.0/16"] = "Network 1"
>>> t["10.1.42.0/24"] = "Network 1, Subnet 42"
>>> print("10.1.42.1" in t)
True
But the version in bullseye (and 0.35 currently in unstable) produce:
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import SubnetTree
>>> t = SubnetTree.SubnetTree()
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/SubnetTree.py", line 82, in __init__
_SubnetTree.SubnetTree_swiginit(self,
_SubnetTree.new_SubnetTree(binary_lookup_mode))
AttributeError: module '_SubnetTree' has no attribute 'SubnetTree_swiginit'
>>>
-- System Information:
Debian Release: 11.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-subnettree depends on:
ii libc6 2.31-13+deb11u2
ii libgcc-s1 10.2.1-6
ii libstdc++6 10.2.1-6
ii python3 3.9.2-3
python3-subnettree recommends no packages.
python3-subnettree suggests no packages.
-- no debconf information
Bug#991378: This bug is still alive
agreed, someone should fix xdg-desktop-portal to not cause errors On Fri, Jan 07, 2022 at 07:05:09PM -0600, you wrote: It breaks the df command and rf command - both return unhelpful error messages - breaks scrips that use df.. Putting a mount point in /root/.cache was never a good idea - not where they belong (breaks the FHS standard) Adds confusion to users - something in a cache should be delete-able - this creates what looks like an empty directory that one can not delete. Not able to install fuse3 from testing as it wants to remove libc-bin.. Stable needs an update. I think this should have severity: critical as it breaks unrelated software? - or at the very least 'serious' as if violates a few of the must and required directives? -- Karl Schmidt EMail k...@lrak.net 3209 West 9th Street Ph (785) 841-3089 Lawrence, KS 66049 Google is the camel's nose. -kps
Bug#994832: numactl: fails to install with manpages-dev 5.10-1
Package: numactl Version: 2.0.12-1+b1 Severity: serious Justification: Policy 7.6.1 Unpacking numactl (2.0.14-1) over (2.0.12-1+b1) ... dpkg: error processing archive /var/cache/apt/archives/numactl_2.0.14-1_amd64.deb (--u npack): trying to overwrite '/usr/share/man/man2/move_pages.2.gz', which is also in package m anpages-dev 5.10-1
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 09:33:56AM +0200, Helmut Grohne wrote: Laptops of end-user systems are the target, but also developers. When people gather at a place (conference, hackspace, private meetup, etc.) downloading of .debs should just work quickly by default. Many such sites could easily provide a local cache and a number even do. BSPs tend to have a blackboard with information including the local mirror to use. Seriously, how many people change their mirror when they go to a BSP? If we installed auto-apt-proxy by default, much of the local caching would just work. I think you'd get a lot of pushback on installing auto-apt-proxy by default. If that's a proposal, make it seperately and not in this thread. The thing we seem to be disagreeing on is what is more important? https by default or quick and efficient downloads? Some may think that our CDN can handle the load just fine and the effects of caching are peanuts. I can attest that those peanuts are 4TB/year (equivalent to 8 days waiting for downloads) for me. I see that we've given up on a global network of independently-managed mirrors and that CDNs are way easier at this time. While initially CDNs had bad reliability issues, those have completely vanished in my experience. On the other hand, local caching still outperforms CDNs by a factor of 10 or so. I'd love to make it the default. I use a cache out of habit and to be a good netizen, but my internet connection is fast enough these days that it's basically a noop at best and a slight slowdown at worst. I had to move the cache from slow/cheap spinning disk to reasonably fast SSD to get to that point. If you're downloading the same stuff over and over (e.g., for testing or somesuch) it can be a big win, especially for VMs on a virtualized network connection, or if you're managing a large infrastructure, but for normal use with a couple of instances? It's just not worth the trouble.
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 02:54:21PM +0200, Timo Röhling wrote: * Michael Stone [2021-09-09 08:32]: I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility. I don't understand your point. You asked for a target audience for auto-apt-proxy. I gave you a legitimate (and real-world) example for such a deployment. Why should it matter whether or not an organization has other configuration facilities? Because the controversy concerning changing the default is over whether it's reasonable for someone using auto-apt-proxy to have to manage additional configuration settings. If the target audience is someone who has the ability to manage the infrastructure required by auto-apt-proxy but not the ability to manage anything else then I guess it's a valid criticism (but I have trouble envisioning that). If the auto-apt-proxy target audience can manage both the proxy infrastructure *and* sources.list (either at install time or run time) then the criticism is basically academic and not generally a real-world issue.
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, Sep 09, 2021 at 08:36:28AM +0200, Timo Röhling wrote: * Michael Stone [2021-09-08 19:12]: Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management? The same reason you might want to deploy WPAD instead of preconfiguring proxy settings in web browsers: flexibility. For example, we use auto-apt-proxy for laptops which roam between different networks. It's simple to configure, has virtually no maintenance overhead and degrades gracefully. None of that speaks to whether an organization that deploys such a thing has the ability to manage other configuration settings, even if for some settings there's a desire for additional flexibility.
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Wed, Sep 08, 2021 at 01:09:13PM +0200, Helmut Grohne wrote: Enabling https by default quite simply breaks the simple recipe of installing auto-apt-proxy. Would you agree with auto-apt-proxy's postinst automatically editing your sources.list to drop the s out of https? The answer repeatedly given in this thread to do so manually is very unsatisfying. Why not simply automate setting it at install time using preseed? I'm honestly not sure who the target audience for auto-apt-proxy is--apparently someone who has an infrastructure including a proxy, possibly the ability to set dns records, etc., but can't change defaults at install time or via some sort of runtime configuration management?
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 03:25:22PM +, Clint Adams wrote: On Wed, Aug 18, 2021 at 11:22:53AM -0400, Michael Stone wrote: apologies, box I checked was buster and not bullseye No problem, it seems evident that it did little good anyway. well, the note is for users, most of whom aren't running bullseye yet. I obviously haven't upgraded all of mine, myself. :-D
Bug#992399: debianutils: removes interface from essential package without proper transition
On Wed, Aug 18, 2021 at 03:06:07PM +, Clint Adams wrote: On Wed, Aug 18, 2021 at 10:53:45AM -0400, Michael Stone wrote: Adding a message to stderr telling people to use mktemp may be a reasonable step. You mean the thing it does in our stable release? apologies, box I checked was buster and not bullseye
Bug#992399: debianutils: removes interface from essential package without proper transition
Adding a message to stderr telling people to use mktemp may be a reasonable step.
Bug#981996: coreutils: dd create a regular file instead of writing to the block file
On Fri, Feb 05, 2021 at 05:06:19PM +0100, Frédéric MASSOT wrote: Usually to copy an iso image to a USB stick I would do: dd if=image.iso of=/dev/sdg "/dev/sdg" the path to the USB key checked in the logs. Today with version dd (coreutils) 8.32, this command replaces the block device /dev/sdg with a /dev/sdg regular file which has the same size as the iso image. Is it a bug or a new feature? I couldn't find an option in the man page for this new feature. dd didn't remove the device file. I suggest that you remove the usb stick, remove the device file, insert the usb stick, check that the device file is actually there and correct, then try again with dd.
Bug#981778: exiv2: add upstream support for nikon ftz
Package: exiv2 Version: 0.27.3-3 Severity: wishlist Tags: patch upstream Current exiv2 can't identify nikon F mount lens via FTZ adapter. Upstream support added in this pull, and it would be nice if it were merged in debian. https://github.com/Exiv2/exiv2/pull/1437 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages exiv2 depends on: ii libc62.31-9 ii libexiv2-27 0.27.3-3 ii libgcc-s110.2.1-6 ii libstdc++6 10.2.1-6 exiv2 recommends no packages. exiv2 suggests no packages. -- no debconf information
Bug#981625: coreutils: ln -svf fails on nfs share if symbolic link already exists
On Tue, Feb 02, 2021 at 10:46:29AM +0100, cedric borgese wrote: Package: coreutils Version: 8.32-4+b1 Severity: normal X-Debbugs-Cc: cedric.borg...@gmail.com Dear Maintainer, trying to update a symbolic link from a nfs share silently fails. if the symbolic link /some/nfs/share/tmp already exists, the command ln -sv /tmp /some/nfs/share/tmp fails as expected with an error message, but the command ln -svf /tmp /some/nfs/share/tmp fails and print an output as if the link was succesfully updated I can't duplicate on nfs. I'd guess there's something on the NFS server preventing the command from succeeding but I can't be more specific without more information. What should actually be happening is that ln makes an attempt to create the symlink, that fails, then it makes the link with a random name and renames it into place. If you run your command with strace you can see the exact system calls.
Bug#973545: gcc-10: 10.2.0-15 to 10.2.0-16 900MB larger?
Package: gcc-10 Version: 10.2.0-16 Severity: wishlist When upgrading from 10.2.0-15 to 10.2.0-16 aptitude reports that gcc-10 is 282MB larger, g++-10 is 312MB larger, and cpp-10 is 283MB larger. In -15 /usr/lib/gcc/x86_64-linux-gnu/10/lto1 is 26M and in -16 /usr/lib/gcc/x86_64-linux-gnu/10/lto1 is 285M. I assume this is because of the "don't strip the executables" changelog entry. If that's the case you do another release like this, please be explicit that this will cause a massive increase in disk utilization, since that is potentially really significant growth in core component that isn't usually very large and people may wonder what happened to their disk space.
Bug#972713: libnss3: Handshake failed (-12251) with Pidgin since 2:3.58-1
I had the same problem, as also discussed in https://bugs.archlinux.org/task/68357 The workaround in that thread worked for me as well. (Using NSS Preferences plugin to change maximum TLS version to 1.2.) It seems something is causing issues if TLS 1.3 is permitted, there is some discussion of proposed patches.
Bug#972286: coreutils: Crash when using globs on a path with non-latin characters
On Thu, Oct 15, 2020 at 04:28:35PM -0400, you wrote:
Steps to reproduce:
1. mkdir ~/ಇಳಿಕೆಗಳು
2. touch ~/ಇಳಿಕೆಗಳು/{a,b}.txt
3. ls ~/ಇಳಿಕೆಗಳು/*.txt crashes immediately
By contrast:
1. cd ~/ಇಳಿಕೆಗಳು/ && ls *.txt succeeds
2. ls ಇಳಿಕೆಗಳು/*.txt succeeds
Similarly, `cp ~/ಇಳಿಕೆಗಳು/*.txt .` crashes, but `cp ಇಳಿಕೆಗಳು/*.txt .` works, as does
`cd ಇಳಿಕೆಗಳು && cp *.txt ~`.
Please let me know if you need more information.
coreutils doesn't have anything to do with expanding a shell wildcard,
the bug needs to be assigned to whatever shell you're using.
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 11:20:44PM +, Thorsten Glaser wrote: Michael Stone dixit: you can fix it right now! So, what do you mean? Take over the rng-tools package? If so, it has a maintainer, you know. hmh has been quiet so far. he's been clear that he's happy for someone to take it over, or did you talk to him before uploading your package and he told you that you'd have to create your own because rng-tools was off limits?
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 09:32:47PM +, Thorsten Glaser wrote: Michael Stone dixit: So your position is that rng-tools 2-unofficial-mt.14-1+b2 and rng-tools-debian 2-unofficial-mt.14-3 both in buster are completely different codebases? No, no, no, of course not. I’m talking about sid (and therefore testing). Even before the release of buster, rng-tools in sid was 5 already and therefore unusable. It simply did not migrate in time for buster, thankfully, but the presence of rng-tools-debian would have helped, even so, to alleviate that. It was a botched NMU which happened without discussion. The fix is to overwrite it with a new package. Yes, after both getting a suggestion to do so (via Launchpad) from one of the developers involved *and* running into the problem that rng-tools (in sid) was version 5 and that not getting fixed. you can fix it right now! come up with a better name. rng-tools-legacy makes more sense, or you could It would have made more sense, but we’re past release now, so… you can transition right now! I really don't understand why your attitude has been "I did this thing, I'm not going to change it, and I'm not going to take the remaining steps needed to resolve the mess". rng-tools-debian because you really want to please at least take care of cleaning up the rng-tools transition. I could take over rng-tools and transition them to rng-tools-debian, but this isn’t desired in most cases, so this is really between the maintainers of rng-tools and rng-tools5 in my eyes. there is *no* migration path between rng-tools legacy and rng-tools5. The only transition that makes sense *for debian users* is to consolidate rng-tools and rng-tools-debian. *Of course* the migration that's desired for debian users is to migrate from rng-tools to some other rng-tools legacy package, otherwise people would be running rng-tools5. you keep talking about launchpad, but this is a conversation in debian channels about a debian package. what ubuntu did is irrelevant, what matters is the experience for users of debian (particularly debian stable, for which the situation is as I outlined in the previous mail) The situation in debian unstable is messier *but there is a reason we call it unstable* and it's better to fix the situation for released versions than to worry about unstable users.
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 05:28:12PM +, Thorsten Glaser wrote: Michael Stone dixit: So you could have added whatever you needed to rng-tools and skipped the unnecessary package... No, rng-tools is a completely different software. So your position is that rng-tools 2-unofficial-mt.14-1+b2 and rng-tools-debian 2-unofficial-mt.14-3 both in buster are completely different codebases? Let's review again. Prior to buster there was rng-tools. It's a legacy codebase that's diverged from basically every other distribution. There was also rng-tools5 which was the then-current upstream which provided new functionality and is frankly more useful on modern hardware, but which did not (and probably never will) support the legacy hardware. I had discussed with the (past) rng-tools maintainer the possibility of renaming that to something like rng-tools-legacy with a transition package, with the intent of freeing up the rng-tools package name in the short term and possibly renaming rng-tools5 in the long term. All well and good, stretch was released with rng-tools (legacy) and rng-tools5. Then someone decided to NMU rng-tools with a patch to basically make it a copy of rng-tools5. That never made it to release, and buster was released with both rng-tools (legacy) and rng-tools5. And into that you uploaded *another copy* of rng-tools. So now we have two versions of rng-tools (legacy), one copy of rng-tools5, and a zombie NMU of rng-tools5 called rng-tools in unstable that's been removed from testing so that testing currently has no rng-tools. So anybody using rng-tools in buster will end up with an orphaned package in the next release. There's another version of the same code *but with no transition mechanism* called rng-tools-debian. And there's another package called rng-tools5, originally intended as a bridge to a new package structure, and which is now awkwardly named as the upstream codebase is now up to version 6. Ideally you would come up with a transition mechanism to move rng-tools users to some other package name because you are the one who has laid claim to that codebase. I still believe that rng-tools-debian is a terrible name because it is not sponsored by the debian project and because the name does not give any hints to users about why they might want to use the package. If anything it misleads them into thinking that they should choose the old code if they're running debian when realistically that is almost certainly not the case. As long as transition packages are being discussed it seems like an ideal time to come up with a better name. rng-tools-legacy makes more sense, or you could come up with something better, or if you insist on calling it rng-tools-debian because you really want to please at least take care of cleaning up the rng-tools transition. Once rng-tools in debian stable is migrated to the new package name (with a transition package that goes away) then we'll finally have something sane that supports the users in a reasonable fashion and we'll have a way forward in the future.
Bug#919893: rng-tools-debian: package shouldn't exist
On Thu, Oct 01, 2020 at 04:51:54PM +, Thorsten Glaser wrote: Michael Stone dixit: So the package that shouldn't have existed made it into buster, there's a ridiculous situation with 3 packages providing essentially the same functionality with minor differences and no practical way for a user to figure out which to install, and no movement on fixing this before the *next* release. Yeah well, it exists now, and IIRC the strongest argument against *this* package was the name. No, there were also user confusion, duplication of functionality, and increased difficulty in future migration. But given it’s been in a stable release now, maybe it’s time to retire rng-tools (not rng-tools5), maybe with a transitional package migrating users over to either rng-tools5 or rng-tools-debian, taking their configuration along, or just dropping it so it keeps working for users who have it installed, but new users need to choose one of the others. Incidentally, rng-tools is not in testing but rng-tools5 is, so the maintainer might wish to check whether there’s anything left from the rng-tools package to take over. So you could have added whatever you needed to rng-tools and skipped the unnecessary package... At this point, please just clean up the mess.
Bug#919893: package shouldn't exist
So the package that shouldn't have existed made it into buster, there's a ridiculous situation with 3 packages providing essentially the same functionality with minor differences and no practical way for a user to figure out which to install, and no movement on fixing this before the *next* release. On Thu, Feb 07, 2019 at 03:34:31PM +, Thorsten Glaser wrote: Henrique de Moraes Holschuh dixit: On Sun, Jan 20, 2019, at 14:05, Thorsten Glaser wrote: How about starting a sort of transition to the split packages instead?= Looks like a sensible approach to me. It’s a bit too “short” before the release, always has been. My other ideas, both the p-u and the “castling”, rely too much on that all things involved go smooth. I’d like to propose a new plan: * we still intend to do a rng-tools → rng-tools5 transition for bullseye but leave buster alone * we’ll just keep rng-tools (5.x) out of testing, and will later request package removal of src:rng-tools and the binary package (but (new) only AFTER the buster release) * I’ll request removal of rng-tools-debian from testing (and, therefore, buster), but keep it around in sid until we have a new solution (to not break existing users) * said new solution could be to either add all features needed to rng-tools5 or, well, keeping rng-tools-debian (the name’s correct as it’s the former Debian maintainer’s fork of rng-tools, but we can bikeshed that later) around * whatever we do, we’ll do it way after the buster release (so we will have had time to discuss it before implementing) but way before the bullseye release (so it will have had enough time to cook in testing/sid beforehand) * in bullseye, we will need to handle migration from - rng-tools (2.x) [from buster] - rng-tools (5.x) [from sid] - rng-tools5 [from buster/sid] - rng-tools-debian [from sid] but we don’t need to handle all of them the same way; details mostly depend on whether we manage to patch rng-tools5 enough so that we can migrate *all* of them to *one* destination package, handling all use cases; the configuration change needs to be in the release notes of course, but this way, we’ll have actually enough time to do that This most likely means that rng-tools5 people (upstream and packagers) need to consider adding enough rng-tools-debian functionality (more command line switches, and making them actually do what they used to do, and an /etc/default/ file). Is this agreeable? If so, I’ll go ahead requesting removal of rng-tools-debian from testing, and we’ll have to continue blocking rng-tools 5 from entering testing. The downside is that the fixes in rng-tools-debian won’t make it into rng-tools in buster, and that rng-tools-debian will be around for a while longer. But I’ve looked at popcon and *buntu and saw it’s already used by way more people than the two or three systems I installed it on myself, so we’ll do best doing a transition plan including it *anyway*, which won’t get worse if it sticks round for a while. Sorry for taking ~2 weeks for this answer, I’ve had the cold (and now caught conference flu at FOSDEM, no rest for me…), but I believe that even acting 2 weeks ago we would not have managed in time it *anything* went wrong, and the current status quo in testing is “good enough” (that is, not a regres‐ sion from stretch) for us to keep for a release longer. If one step in the transition had failed, we would have been left without rng-tools in buster at all, which had derailed any later transition plans and made users even angrier. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#971363: freeipa-client fails to install on upgrade
Package: freeipa-client Version: 4.8.10-1 Severity: important dpkg configure stage fails without meaningful log: # dpkg --configure -a Setting up freeipa-client (4.8.10-1) ... dpkg: error processing package freeipa-client (--configure): installed freeipa-client package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: freeipa-client Digging through the postinst script indicates that the output is being redirected to /var/log/ipaclient-upgrade.log: # cat /var/log/ipaclient-upgrade.log Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/ipaclient/install/client.py", line 2474, in update_ipa_nssdb sys_db = certdb.NSSDatabase(paths.NSS_DB_DIR) File "/usr/lib/python3/dist-packages/ipapython/certdb.py", line 267, in __init__ raise ValueError( ValueError: NSS is built without support of the legacy database(DBM) In addition to addressing the immediate bug, I also suggest using tee to ensure that the error message goes to stdout in addition to the log file so that it's easier for users to understand what is going on. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freeipa-client depends on: ii bind9-dnsutils [dnsutils]1:9.16.6-3 ii bind9-utils 1:9.16.6-3 ii certmonger 0.79.11-1 ii curl 7.72.0-1 ii dnsutils 1:9.16.6-3 ii freeipa-common 4.8.10-1 ii krb5-user1.17-10 ii libc62.31-3 ii libcom-err2 1.45.6-1 ii libini-config5 0.6.1-2 ii libk5crypto3 1.17-10 ii libkrb5-31.17-10 ii libldap-2.4-22.4.53+dfsg-1 ii libnss-sss 2.3.1-2 ii libnss3-tools2:3.56-1 ii libpam-sss 2.3.1-2 ii libpopt0 1.18-1 ii libsasl2-modules-gssapi-mit 2.1.27+dfsg-2 ii libsss-sudo 2.3.1-2 ii libxmlrpc-core-c31.33.14-9 ii oddjob-mkhomedir 0.34.6-1 ii python3 3.8.2-3 ii python3-dnspython2.0.0-1 ii python3-gssapi 1.6.1-1+b1 ii python3-ipaclient4.8.10-1 ii python3-ldap 3.2.0-4+b1 ii python3-sss 2.3.1-2 ii sssd 2.3.1-2 Versions of packages freeipa-client recommends: pn chrony Versions of packages freeipa-client suggests: pn libpam-krb5 -- no debconf information
Bug#970608: src:coreutils: fails to migrate to testing for too long: FTBFS on arm64
I thought debports architectures weren't supposed to prevent migration to testing so I'm confused about why the package hasn't migrated.
Bug#965164: policykit-1: fails to install
Package: policykit-1 Version: 0.105-27 Severity: grave Justification: renders package unusable On install: Setting up policykit-1 (0.105-27) ... chown: cannot access '/usr/lib/policykit-1/polkit-agent-helper-1': No such file or directory > dpkg -L policykit-1 | grep help /usr/libexec/polkit-agent-helper-1
Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency
On Sat, Jul 04, 2020 at 03:21:03PM +0200, Mathieu Parent wrote: Le sam. 4 juil. 2020 à 15:15, Michael Stone a écrit : On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote: >clone 963971 -1 >tag 963971 + upstream >tag -1 + upstream fixed-upstream patch >reassign -1 sssd-ad-common > >Le lun. 29 juin 2020 à 14:48, Michael Stone a écrit : >> >> Package: samba-libs >> Version: 2:4.12.3+dfsg-2 >> Severity: critical >> Justification: breaks the whole system >> >> The new samba-libs package changes the soname of libndr from libndr.so.0 to >> libndr.so.1 without reflecting this change in the package name. sssd-ad-common >> has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0. >> When the samba-libs package is updated and libndr.so.0 disappears sssd fails to >> start, which then makes a system's remote users unavailable. (Worse, this >> doesn't happen until the next time sssd restarts--which may not be until the >> next reboot.) > >It looks to be fixed in sssd 2.3.0: >https://github.com/SSSD/sssd/commit/bc56b10aea999284458dcc293b54cf65288e325d > >I'm cloning this bug: >- on the samba side I'll add a breaks: sssd-ad-common (<< 2.3.0) >- on the sssd side, an update to 2.3.0+ is needed Going forward, do things using samba-libs need a strict version depenedency since there is no ABI version in the package name? No, I think. According to the sssd commit, sssd 2.3 will still build on older samba-libs. Not a build-time dependency, a run-time dependency; if there is no guarantee that the ABI is stable between versions, a dependency on "samba-libs >= something" simply isn't valid. (Packages built from the samba source package already have a dependency on "samba-libs = version" but there currently isn't anything telling other packages that the dependencies need to work that way.)
Bug#963971: [Pkg-samba-maint] Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency
On Sat, Jul 04, 2020 at 07:28:32AM +0200, Mathieu Parent wrote: clone 963971 -1 tag 963971 + upstream tag -1 + upstream fixed-upstream patch reassign -1 sssd-ad-common Le lun. 29 juin 2020 à 14:48, Michael Stone a écrit : Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so.0 to libndr.so.1 without reflecting this change in the package name. sssd-ad-common has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0. When the samba-libs package is updated and libndr.so.0 disappears sssd fails to start, which then makes a system's remote users unavailable. (Worse, this doesn't happen until the next time sssd restarts--which may not be until the next reboot.) It looks to be fixed in sssd 2.3.0: https://github.com/SSSD/sssd/commit/bc56b10aea999284458dcc293b54cf65288e325d I'm cloning this bug: - on the samba side I'll add a breaks: sssd-ad-common (<< 2.3.0) - on the sssd side, an update to 2.3.0+ is needed Going forward, do things using samba-libs need a strict version depenedency since there is no ABI version in the package name?
Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency
On Tue, Jun 30, 2020 at 08:48:05AM +1200, Andrew Bartlett wrote: On Mon, 2020-06-29 at 08:46 -0400, Michael Stone wrote: Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so.0 to libndr.so.1 without reflecting this change in the package name. sssd- ad-common has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0. When the samba-libs package is updated and libndr.so.0 disappears sssd fails to start, which then makes a system's remote users unavailable. (Worse, this doesn't happen until the next time sssd restarts--which may not be until the next reboot.) It's not clear why the samba-libs package doesn't include the so number, but at the very least it needs a set of dependencies to avoid breaking sssd- ad-common. We can't put a version number in samba-libs as there are multiple public libraries in there. (Upstream) Samba doesn't promise not to keep doing this - the underlying change has happened before, but this time we were honest and bumped the .so - so sssd may need to have a dependency on the Samba version it built against. That may well be the best solution going forward, but something else needs to be in place to prevent breakage for existing packages.
Bug#963971: samba-libs: libndr.so.0 gone from latest version, breaks sssd-ad-common dependency
Package: samba-libs Version: 2:4.12.3+dfsg-2 Severity: critical Justification: breaks the whole system The new samba-libs package changes the soname of libndr from libndr.so.0 to libndr.so.1 without reflecting this change in the package name. sssd-ad-common has a dependency on samba-libs (>= 2:4.11.5+dfsg) and links to libndr.so.0. When the samba-libs package is updated and libndr.so.0 disappears sssd fails to start, which then makes a system's remote users unavailable. (Worse, this doesn't happen until the next time sssd restarts--which may not be until the next reboot.) It's not clear why the samba-libs package doesn't include the so number, but at the very least it needs a set of dependencies to avoid breaking sssd-ad-common.
Bug#963752: exfat-fuse should not provide /sbin/mount.exfat
On Fri, Jun 26, 2020 at 03:36:02PM +0200, Sven Hoexter wrote: On Fri, Jun 26, 2020 at 09:08:27AM -0400, Michael Stone wrote: Now that exfat is available as a kernel module, it would be nice if the /sbin/mount.exfat link were removed to make it easier for a user to choose either the exfat kernel module or the fuse module at runtime. Currently the link masks the kernel module so that exfat-fuse is always used, without the link the kernel module would be used by default but mounting with -t exfat-fuse would use the fuse implementation. Yes, I already started to think about what the future of the fuse exfat stack could look like. From my personal point of view we could drop it. OTOH for some people an independent implementation might still provide some value. So maybe your proposal to just move it a bit out of the way is a good first step. Yeah, I personally am really happy to switch to a better performing implementation because my only use for exfat is pulling large amounts of data off fast removeable storage and the fuse implementation has been a bottleneck. That said, the fuse implementation has a much longer track record and some people may be happy to stick with it for a while longer, especially if their use case involves writing data or if performance isn't an issue. In my mind the ideal situation would be to not break any existing systems, while still defaulting to the kernel implementation if it's available, and letting users disable the kernel implementation if that's their preference. On Fri, Jun 26, 2020 at 03:39:29PM +0200, Sven Hoexter wrote: On Fri, Jun 26, 2020 at 09:22:18AM -0400, Michael Stone wrote: Alternatively, perhaps replacing the mount.exfat link with something like the following would be a better option, to transparently support kernels with and without the native module: #!/bin/sh if grep -qF exfat /proc/filesystems || modinfo exfat > /dev/null 2>&1 ; then mount -i $* else mount.exfat-fuse $* fi Well as soon as a recent kernel enters testing I believe it would just cause confusion. Main audience to profit would be people using testing/unstable with an old or custom kernel and none Linux ports from my point of view. Would that help someone in the end? Or custom kernels, or backports. Definitely not mainstream, but something along these lines should keep exfat mounts working transparently regardless of kernel support. Here's a slight variation: #!/bin/sh set -e modprobe -b exfat > /dev/null 2>&1 || true if grep -qF exfat /proc/filesystems; then mount -i $* else mount.exfat-fuse $* fi This one would let someone blacklist the kernel module and everything would continue working with the fuse implementation. OTOH, it is linux specific (maybe just leaving the symlink as-is would work on non-linux?) and if you don't want to bother maintaining something like this I wouldn't argue about that decision.
Bug#963752: exfat-fuse should not provide /sbin/mount.exfat
On Fri, Jun 26, 2020 at 09:08:27AM -0400, I wrote: Now that exfat is available as a kernel module, it would be nice if the /sbin/mount.exfat link were removed to make it easier for a user to choose either the exfat kernel module or the fuse module at runtime. Currently the link masks the kernel module so that exfat-fuse is always used, without the link the kernel module would be used by default but mounting with -t exfat-fuse would use the fuse implementation. Alternatively, perhaps replacing the mount.exfat link with something like the following would be a better option, to transparently support kernels with and without the native module: #!/bin/sh if grep -qF exfat /proc/filesystems || modinfo exfat > /dev/null 2>&1 ; then mount -i $* else mount.exfat-fuse $* fi
Bug#963752: exfat-fuse should not provide /sbin/mount.exfat
Package: exfat-fuse Version: 1.3.0-1 Severity: wishlist Now that exfat is available as a kernel module, it would be nice if the /sbin/mount.exfat link were removed to make it easier for a user to choose either the exfat kernel module or the fuse module at runtime. Currently the link masks the kernel module so that exfat-fuse is always used, without the link the kernel module would be used by default but mounting with -t exfat-fuse would use the fuse implementation.
Bug#963513: Please restore LC_TIME symlinks
On Mon, Jun 22, 2020 at 09:41:20PM +0200, Jordi Mallach wrote: In #584837, it was requested that the symlinks from ...//LC_MESSAGES/coreutils.mo to ../LC_TIME/coreutils.mo were removed due to being pointless and unused. I'm unsure if that was the case at that point (it's been 10 years), but current implementations of some of the commands in coreutils do need and expect LC_TIME to operate correctly: openat(AT_FDCWD, "/usr/share/locale/ca/LC_TIME/coreutils.mo", O_RDONLY) = 3 In particular, at least ls and date will try to use it to represent date formats correctly on verbose outputs. This affects at least Catalan, which shows time incorrectly unless you force a date format string by hand. Can you give examples of expected and current output?
Bug#961740: printf attempts to parse options and fails to print --help
On Thu, May 28, 2020 at 05:56:09PM +0200, Melvin Vermeeren wrote: On Thursday, 28 May 2020 17:50:20 CEST Michael Stone wrote: Yes, running printf with the single argument --help will print help. A portable and posix-compliant alternative would be to run "printf '%s' --help". This is extremely unlikely to change. This is not the only problem that occurs, printing -- does not work either. same solution will work! Coreutils should aim for POSIX compliancy, perhaps it would be better if I take this bug upstream? You certainly can, but they will probably also consider this to be of purely academic interest. The solution I provided above is the only portable way to make what you're trying to do work, regardless of POSIX. Even if I changed the debian package today, you'd have to continue to do the above basically forever because of the enormous installed base of implementations don't work the way you're requesting. And not having the help output will likely confuse more people who won't know why it wouldn't work.
Bug#961215: blueman-manager no longer starts because blueman-applet.service not found
On Sat, May 23, 2020 at 02:08:47AM +0200, Tomasz Nitecki wrote: Hey, This issue seems to be caused by changes made in #950520 [1]. I've described the problem in more detail in that bug report [1]. To cut long story short, this bug (#961215) seems to be affecting non /usr merged systems. Yeah, the "fix" was obviously incorrect.
Bug#961215: blueman-manager no longer starts because blueman-applet.service not found
More specifically, refer to systemd.unit(5) and you'll find that /lib/systemd/user is not defined.
Bug#961215: blueman-manager no longer starts because blueman-applet.service not found
Package: blueman Version: 2.1.3-1 Severity: normal Running blueman-manager from the command line results in this: > blueman-manager blueman-manager version 2.1.3 starting Stale PID, overwriting Blueman applet needs to be running In syslog is: May 21 09:16:48 annuminas dbus-daemon[2472]: [session uid=1000 pid=2472] Activating via systemd: service name='org.blueman.Applet' unit='blueman-applet.service' requested by ':1.54' (uid=1000 pid=3117 comm="/usr/bin/python3 /usr/bin/blueman-manager ") May 21 09:16:48 annuminas dbus-daemon[2472]: [session uid=1000 pid=2472] Activation via systemd failed for unit 'blueman-applet.service': Unit blueman-applet.service not found. blueman-applet.service seems to be in /lib/systemd/user rather than /usr/lib/systemd/user, and isn't working. If the service file is copied to /usr/lib/systemd/user all works as expected. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages blueman depends on: ii adwaita-icon-theme3.36.1-2 ii awesome [notification-daemon] 4.3-4 ii bluez 5.52-1 ii bluez-obexd 5.52-1 ii dbus 1.12.16-2 ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii dunst [notification-daemon] 1.4.1-1 ii gir1.2-appindicator3-0.1 0.4.92-8 ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-4 ii gir1.2-glib-2.0 1.64.1-1 ii gir1.2-gtk-3.03.24.20-1 ii gir1.2-nm-1.0 1.24.0-1 ii gir1.2-pango-1.0 1.44.7-4 ii gnome-icon-theme 3.12.0-3 ii libbluetooth3 5.52-1 ii libc6 2.30-8 ii libglib2.0-0 2.64.2-1 ii libpulse-mainloop-glib0 13.0-5 ii librsvg2-common 2.48.4+dfsg-1 ii python3 3.8.2-3 ii python3-cairo 1.16.2-3 ii python3-gi3.36.0-3 ii python3-gi-cairo 3.36.0-3 Versions of packages blueman recommends: ii policykit-1 0.105-26 ii pulseaudio-module-bluetooth 13.0-5 blueman suggests no packages. -- no debconf information
Bug#951134: postfix-policyd-spf-python: breaks due to lack of versioned dependency
Package: postfix-policyd-spf-python
Version: 2.9.2-0+deb10u1
Severity: important
postfix-policyd-spf-python has a dependency on python3-spf-engine, but does not
specify a version. If the policyd package is upgraded but the engine package is
not, then mail delivery halts on the system due to the policyd exiting
prematurely. There are no logs emitted showing what the problem is, but running
the program manually from the command line results in:
> /usr/bin/policyd-spf
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, in
_build_master
ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, in
require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 791, in
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.VersionConflict: (spf-engine 2.9.1
(/usr/lib/python3/dist-packages), Requirement.parse('spf-engine==2.9.2'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/policyd-spf", line 6, in
from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3191,
in
@_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3175,
in _call_aside
f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3204,
in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 585, in
_build_master
return cls._build_from_requirements(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 598, in
_build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, in
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'spf-engine==2.9.2' distribution was
not found and is required by the application
Upgrading the engine restores proper operation.
-- System Information:
Debian Release: 10.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages postfix-policyd-spf-python depends on:
ii adduser3.118
ii postfix3.4.7-0+deb10u1
ii python33.7.3-1
ii python3-authres1.1.1-1
ii python3-pkg-resources 40.8.0-1
ii python3-spf2.0.12t-3
ii python3-spf-engine 2.9.1-0+deb10u1
postfix-policyd-spf-python recommends no packages.
postfix-policyd-spf-python suggests no packages.
Bug#943986: wrong shared linkage position of mv's library dependency
On Tue, Nov 05, 2019 at 11:40:02PM +0100, David Frey wrote: On Mon, Nov 04, 2019 at 08:17:33AM -0500, Michael Stone wrote: On Sat, Nov 02, 2019 at 12:51:41AM +0100, David Frey wrote: > cp and mv have a runtime linkage to libacl and libattr which are > installed in /usr/lib/x86_64-linux-gnu/. > > This means that a single-user booted system without mounted /usr, > is not able to cp or mv files! > > Either the dependancy should be dropped, or the libacl and libattr > shared libraries should be moved into /lib. I don't believe that operating without /usr is a current design goal for debian. In my opinion it should be. It is very useful for system repair and restore. It's more useful to have rescue images, initrds, and potentially a rescure shell such as sash. The utility of a separate root and usr is limited at best.
Bug#865999: exiv2: Please package exiv2 0.26
exiv2 is now up to 0.27.2, and contains some major usability enhancements (e.g., the ability for the user to override lens detection) which have knock-on impacts to other packages (e.g., lensfun and all the programs which depend on that library). Getting an updated package into unstable would be very helpful in moving a lot of other photo processing software forward.
Bug#927758: coreutils: possible autopkgtests
On Mon, Apr 22, 2019 at 12:12:26PM -0700, you wrote: On Mon, Apr 22, 2019 at 02:59:22PM -0400, Michael Stone wrote: On Mon, Apr 22, 2019 at 11:41:27AM -0700, Steve Langasek wrote: > In Ubuntu, we have applied the attached patch to include autopkgtests in the > coreutils package. As a core package, it is useful to have autopkgtests in > order to detect regressions (however unlikely) introduced by the > dependencies of coreutils. > Would you consider including this patch in Debian? Maybe after buster, but probably no. For years I did have coreutils run tests on build, but test failures were far too common due to false positives caused by idiosyncratic autobuilder configurations. Ok, fair. FWIW the autopkgtest that's been defined here appears to be fairly reliable in Ubuntu: http://autopkgtest.ubuntu.com/packages/coreutils You have a lot fewer platforms. :) OTOH, it may become more reasonable as some of the more obscure platforms are going away.
Bug#927758: coreutils: possible autopkgtests
On Mon, Apr 22, 2019 at 11:41:27AM -0700, Steve Langasek wrote: In Ubuntu, we have applied the attached patch to include autopkgtests in the coreutils package. As a core package, it is useful to have autopkgtests in order to detect regressions (however unlikely) introduced by the dependencies of coreutils. Would you consider including this patch in Debian? Maybe after buster, but probably no. For years I did have coreutils run tests on build, but test failures were far too common due to false positives caused by idiosyncratic autobuilder configurations. Mike Stone
Bug#923619: coreutils: FTBFS on hppa - Unknown error 252
On March 2, 2019 4:09:14 PM EST, John David Anglin wrote: >Source: coreutils >Version: 8.30-3 >Severity: normal > >Dear Maintainer, > >Since 8.30-2, coreutils fails to build on hppa with following error: > >make[5]: Entering directory '/<>' > /bin/mkdir -p '/<>/debian/coreutils/usr/bin' >src/ginstall -c src/ginstall >'/<>/debian/coreutils/usr/bin/./install' >src/ginstall: setting permissions for >'/<>/debian/coreutils/usr/bin/./install': Unknown error >252 >make[5]: *** [Makefile:6524: install-binPROGRAMS] Error 1 > >Error 252 used to be ENOTSUP but this error number is no longer used on >hppa-linux. ENOTSUP is now defined to be EOPNOTSUPP. > >I tried to debug the failing command to see if I could find how the >error >occurs. However, src/ginstall doesn't fail when I run the command >outside >the build. So, I'm probably not setting the environment correctly. > >Regards, >Dave Anglin > >-- System Information: >Debian Release: buster/sid > APT prefers buildd-unstable > APT policy: (500, 'buildd-unstable'), (500, 'unstable') >Architecture: hppa (parisc64) > >Kernel: Linux 4.14.104+ (SMP w/4 CPU cores) >Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C >(charmap=UTF-8) >Shell: /bin/sh linked to /bin/dash >Init: systemd (via /run/systemd/system) > >-- no debconf information What happens if you rebuild -1? -- Michael Stone (From phone, please excuse typos)
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 10:21:49PM +0100, Ansgar wrote: (And you get 24-hour time, but very strange Endian in C.UTF-8: WEEKDAY MMM DD HH:MM:SS TZ while en_US.UTF-8 has at least DD MMM ... Having -MM-DD HH:MM:SS[+] instead would be much nicer if we were to create an arbitrary set of new rules for a new universal "en" locale ;-) ) Exactly: using "C" implies compatability with the old POSIX rules, "en" implies you can do whatever you want. :)
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote: On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote: On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote: > How would this locale differ from C.UTF-8? Is the only difference > that C.UTF-8 has strict lexicographical sorting, whereas "en" would > have > case-insensitive sorting like en_GB.utf8 does? (If that's the only > difference, then perhaps something like "LANG=C.utf8 > LC_COLLATE=en_US.utf8" > is enough.) POSIX specifies the output format for various utilities in the C locale, which defeats my understanding of the purpose of this proposal. So, for example, in ls -l: I don't think the "C.UTF-8" locale covered by any promises POSIX might make for "C". (Nor is what happens when no LC_*, LANG vairables are set at all.) IMO, the principle of least surprise applies here: if C.UTF-8 is meant to be something other than the C locale with UTF-8 semantics added, it should be called something other than C, no?
Bug#877900: How to get 24-hour time on en_US.UTF-8 locale now?
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote: How would this locale differ from C.UTF-8? Is the only difference that C.UTF-8 has strict lexicographical sorting, whereas "en" would have case-insensitive sorting like en_GB.utf8 does? (If that's the only difference, then perhaps something like "LANG=C.utf8 LC_COLLATE=en_US.utf8" is enough.) POSIX specifies the output format for various utilities in the C locale, which defeats my understanding of the purpose of this proposal. So, for example, in ls -l: (quoting http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html) The field shall contain the appropriate date and timestamp of when the file was last modified. In the POSIX locale, the field shall be the equivalent of the output of the following date command: date "+%b %e %H:%M" if the file has been modified in the last six months, or: date "+%b %e %Y" (where two s are used between %e and %Y ) if the file has not been modified in the last six months or if the modification date is in the future, except that, in both cases, the final produced by date shall not be included and the output shall be as if the date command were executed at the time of the last modification date of the file rather than the current time. When the LC_TIME locale category is not set to the POSIX locale, a different format and order of presentation of this field may be used. Mike Stone
Bug#921539: unbound fails to start after upgrade
Package: unbound Version: 1.9.0-1 Severity: grave Justification: renders package unusable Immediately after installing 1.9.0-1, unbound refused to run after restart. System logs contained: Feb 6 11:00:24 annuminas package-helper[6142]: /var/lib/unbound/root.key has content Feb 6 11:00:24 annuminas unbound: [6146:0] notice: init module 0: subnet Feb 6 11:00:24 annuminas unbound: [6146:0] notice: init module 1: validator Feb 6 11:00:24 annuminas unbound: [6146:0] error: unable to open /var/lib/unbound/root.key for reading: No such file or directory Feb 6 11:00:24 annuminas systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Feb 6 11:00:24 annuminas unbound: [6146:0] error: error reading auto-trust-anchor-file: /var/lib/unbound/root.key Feb 6 11:00:24 annuminas systemd[1]: unbound.service: Failed with result 'exit-code'. Feb 6 11:00:24 annuminas unbound: [6146:0] error: validator: error in trustanchors config Feb 6 11:00:24 annuminas unbound: [6146:0] error: validator: could not apply configuration settings. Feb 6 11:00:24 annuminas unbound: [6146:0] error: module init for module validator failed Feb 6 11:00:24 annuminas unbound: [6146:0] fatal error: failed to setup modules Feb 6 11:00:24 annuminas kernel: [1792989.896766] audit: type=1400 audit(1549468824.750:4639): apparmor="STATUS" operation="profile_replace" info="same as cur rent profile, skipping" profile="unconfined" name="/usr/sbin/unbound" pid=6149 comm="apparmor_parser" Feb 6 11:00:24 annuminas systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart. Feb 6 11:00:24 annuminas systemd[1]: unbound.service: Scheduled restart job, restart counter is at 1. Feb 6 11:00:25 annuminas systemd[1]: unbound.service: Control process exited, code=killed, status=15/TERM Feb 6 11:00:25 annuminas systemd[1]: unbound.service: Succeeded. Commenting out the contents of /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf allowed the process to start, presumably no longer validating DNSSEC. The /var/lib/unbound/root.key file is present and readable, as it was prior to the upgrade. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages unbound depends on: ii adduser 3.118 ii dns-root-data 2018091102 ii libc6 2.28-6 ii libevent-2.1-6 2.1.8-stable-4 ii libfstrm0 0.4.0-1 ii libprotobuf-c1 1.3.1-1+b1 ii libpython3.73.7.2-2 ii libssl1.1 1.1.1a-1 ii libsystemd0 240-5 ii lsb-base10.2018112800 ii openssl 1.1.1a-1 ii unbound-anchor 1.9.0-1 unbound recommends no packages. Versions of packages unbound suggests: ii apparmor 2.13.2-7
Bug#915559: coreutils: Use renameat2 from glibc instead of syscall
On Wed, Feb 06, 2019 at 10:47:12AM +0100, Johannes Schauer wrote: On Wed, 30 Jan 2019 12:07:37 +0100 Jonas Smedegaard wrote: Jus a friendly nudge: It would be great if this bug was fixed in time for Buster. Do you think you can find the time to have a look at the patches provided by Josch? Do you need some help? another week passed since Jonas' email. And more than seven weeks since your last activity in this bug. Unfortunately, fakechroot is not really usable without mv(1). The mv(1) tool is used in apt and dash postinst maintainer scripts, so this also affects debootstrap and mmdebstrap and thus in turn also packages using these tools. I thus hereby announce my intention to NMU coreutils with my two patches in one week (February 13) and a delay of 10 days (then in unstable by February 23). Please speak up if you are not okay with that plan. I'm not ok with that plan.
Bug#915689: Bug#919893: Bug#915689: Bug#919893: package shouldn't exist
On Wed, Jan 23, 2019 at 04:12:24PM +, Thorsten Glaser wrote: Yes, exactly: it's definitely better for a certain class of hardware, but I'm honestly just not sure whether any of those are still relevant. (Like, do they work with current kernels, are they in hardware that's otherwise supported, etc.?) I'd love to see reports from people who are still using the older version for functionality that isn't in the newer version to help inform what My MUA just threw this mail to me in an interesting timing attack (I deleted the last new mail just when this one came into my INBOX and before it was sorted under the thread), I didn't read any others in the thread since Monday yet and will see when I have time for this, but since you asked: I use the old rng-tools, with several of the now-unsupported command line options, reading from /dev/stdin which is the stdout of an SSL client, in a scenario where I distribute entropy over the network to multiple boxen. So, software, not hardware. But rng-tools is needed in order to • attribute the new entropy to the pool estimate (even though I use a value of less than 8 bit per byte) • fill the pool up to the watermark • do some plausibility checks on the input as otherwise I could just connect the SSL stdout to /dev/urandom writingly. In general, the missing flags are good to use if you have hardware that produces “some” entropy but not an estimated 8 bit per byte, for example. Also, slow RNGs; I don’t want to have several hundred MiB/s traffic from this… So that's basically just the --rng-entropy argument? If we switch rng-tools5 to the fork at https://github.com/nhorman/rng-tools there's already a new entropy-count option to address that. I don't see any good reason to deploy *new* installs of the rng-tools2 codebase for purely software reasons. I’ll respond to the other mails in the thread in time, when I have the time. Just another data point: rng-tools-debian has an installed user base in testing and in *buntu (they sync’d it), so renaming it is out of the question now. The package description should make it clear that rng-tools5 should be preferred to most, but the -debian is historically true (it’s the one with “all the new options hmh wrote for Debian”, as opposed to the “latest upstream gkernel” one). It's been in testing for a matter of days, so I'm skeptical that this is a real concern. (And it's called *testing* for a reason.) Renaming the package and adding a rng-tools-debian transition package would make the matter moot (though I think it would be silly). Again, calling this rng-tools-debian IMO makes an already confusing set of packages even worse. (And honestly, this is kind of thing that should be sorted out when a package is ITP'd and discussed, not done and then declared a fait accompli.) -- Michael Stone
Bug#915689: Bug#919893: package shouldn't exist
On Wed, Jan 23, 2019 at 05:19:13AM -0500, Henrique de Moraes Holschuh wrote: On Mon, Jan 21, 2019, at 10:36, Michael Stone wrote: Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove "old" rng-tools is better for any low-bandwidth RNGs, so I am not sure it is obsolescent: that depends entirely on whether people still design/have low-bandwidth RNGs worth supporting. Yes, exactly: it's definitely better for a certain class of hardware, but I'm honestly just not sure whether any of those are still relevant. (Like, do they work with current kernels, are they in hardware that's otherwise supported, etc.?) I'd love to see reports from people who are still using the older version for functionality that isn't in the newer version to help inform what we should do. I'm conservative enough that I don't want to break existing installs (especially for something that's security-relevant) but it would be nice to know whether I'm being overly cautious on that. -- Michael Stone
Bug#915689: prevent from migrating to testing
On Wed, Jan 23, 2019 at 05:46:39AM -0500, Henrique de Moraes Holschuh wrote: On Sun, Jan 20, 2019, at 14:06, Thorsten Glaser wrote: But you’re not in a situation to command either, considering hmh is the ONLY maintainer of rng-tools so we WILL need his input on this (or do an NMU). Anything that does not break things for people in stretch when updating to buster would be excellent. But that is going to be a pain to do, so anything that warns people in stable that they will get broken and must install is IMHO *acceptable*. It shouldn't be difficult to preserve existing configs as long as rng-tools isn't rng-tools5 in buster.
Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist
On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote: On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote: On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: >On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: >> I’m very much against just saying this package >> “should not exist” > >I'm inclined to agree with this as the source (+ features/parameters) for >this package is substantially different from rng-tools/rng-tools5. Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove it exactly because I'm not clear on that, but I tend to think that it's functionally obsolete.) I'm not knowledgeable enough to weigh in on that and/or what is best towards the future, so I'll leave that up to you. >coordination/progress. I'm thinking of updating >https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we >use(d) the old rng-tools to get much better/more entropy on the Raspberry >Pi. In what way? Entropy generation for the creation of SSH keys as the netinstaller is mostly used in headless situations. https://github.com/debian-pi/raspbian-ua-netinst/issues/42 That functionality doesn't require the old package; will work fine with rng-tools5.
Bug#915689: Bug#919893: package shouldn't exist
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote: On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote: I’m very much against just saying this package “should not exist” I'm inclined to agree with this as the source (+ features/parameters) for this package is substantially different from rng-tools/rng-tools5. Yes, but most of those features are obsolescent at best. I'm not clear on what functionality is actually being used. (I'm hesitant to remove it exactly because I'm not clear on that, but I tend to think that it's functionally obsolete.) coordination/progress. I'm thinking of updating https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get much better/more entropy on the Raspberry Pi. In what way?
Bug#919893: package shouldn't exist
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote: • keep rng-tools5 and rng-tools-debian in testing FWIW, I'd much rather call this rng-tools2 or rng-tools-legacy or something other than rng-tools-debian (which implies that for some reason this version is more "debian" than another version, and that it can't be used anywhere except debian).
Bug#919893: package shouldn't exist
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote: Please don’t understand me wrong, I’m not against a sensible solution out of this mess, but I’m very much against just saying this package “should not exist” without one. Once it's in stable, this mess is a lot harder to fix, so it's not ok to just leave it screwed up for now. I don’t have much time right now (got to go), but I’ve got a better idea than this: that package is in much less health and should perhaps be replaced by a transitional package instead. How about starting a sort of transition to the split packages instead? • upload rng-tools 2-unofficial-mt.14-2 to buster-proposed-updates (since, due to the version number, it cannot go via unstable), unchanged from 2-unofficial-mt.14-1 except for a NEWS entry saying: I don't know if this will work or not. If it will, sounds good.
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 04:05:09PM +, Thorsten Glaser wrote: Michael Stone dixit: So use the epoch. They're invented for fixing collosal errors like this. Except this time, have the appropriate discussion on -devel instead of just uploading something without coordination. Sounds like an approach, but please see in #919893 my message first for an alternative idea. Coordination with -devel is required for epoch anyway… for p-u only RT IIRC, but we could do either. But you’re not in a situation to command either, considering hmh is the ONLY maintainer of rng-tools so we WILL need his input on this (or do an NMU). I'm not commanding anything, I'm just trying to figure out ways to un-hijack the package. Hence the desire to discuss any solution on -devel to get broader input & consensus.
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:41:22PM +, Thorsten Glaser wrote: Michael Stone dixit: Please upload a fixed version of rng-tools instead, reverting the erroneous change. That is impossible because the version changed. In the tool I’m using, I have a hard version requirement on rng-tools (<< 3) | rng-tools-debian (<< 3). Sounds like a self-imposed problem. At best we could do with an epoch, but these are nowadays frowned upon. For two softwares as distinct as these rng-tools implementations, the +really dance is more than just questionable instead. So use the epoch. They're invented for fixing collosal errors like this. Except this time, have the appropriate discussion on -devel instead of just uploading something without coordination.
Bug#919893: package shouldn't exist
Package: rng-tools-debian I don't entirely understand why this package was ever uploaded, and as far as I can tell, with no ITP. It should not be included in buster.
Bug#919894: RM: rng-tools-debian
Package: ftp.debian.org This package was uploaded as part of a series of uncoordinated changes to various rng-tools packages. It would be best that it not enter a stable release, and it isn't clear that the package is needed at all. I can't find an ITP dicussing this package or how it should be coordinated with the other rng-tools packages currently in the archive.
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:25:12PM +, Thorsten Glaser wrote: Michael Stone dixit: No, that's something else that shouldn't have happened It’s important to me because the upload of rng-tools (>> 2) broke things on unstable. So that should be fixed--the problem should not be made worse. Please upload a fixed version of rng-tools instead, reverting the erroneous change.
Bug#915689: prevent from migrating to testing
On Sun, Jan 20, 2019 at 03:01:18PM +0100, Diederik de Haas wrote: On Fri, 11 Jan 2019 14:51:05 -0500 Michael Stone wrote: On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote: >There never should have been an NMU simply replacing rng-tools with >rng-tools5. I did not notice that this had happened. Also, the correct fix for buster is an upload to put things back the way they were, which is going to be ugly. You are aware of the rng-tools-debian package containing the 'old' implementation? No, that's something else that shouldn't have happened, as it won't preserve an existing configuration. Why the hell is all this happening with no coordination?
Bug#915689: prevent from migrating to testing
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote: There never should have been an NMU simply replacing rng-tools with rng-tools5. I did not notice that this had happened. Also, the correct fix for buster is an upload to put things back the way they were, which is going to be ugly.
Bug#915689: prevent from migrating to testing
There never should have been an NMU simply replacing rng-tools with rng-tools5. I did not notice that this had happened. On Fri, Jan 11, 2019 at 07:21:49PM +0100, Andreas Henriksson wrote: That has apparently failed to materialize well in time for buster. Looking at the contents of the binary packages it seems rng-tools (in unstable) has more contents and likely provides more functionality/integration (but I haven't looked into details, eg. rng-tools5 has no /etc/default file which might be a good thing as those are generally frowed upon in the current systemd service age, but has there been any work on actual migration of current rng-tools users configuration to what rng-tools5 uses?) It's not possible to migrate people from rng-tools to rng-tools5 as the functionality does not entirely overlap. There's no meaningful conversion from one to the other, nor does there need to be. (A user currently running rng-tools has no need to move to rng-tools5.) There's a chance (though increasingly small as the legacy hardware ages) that forcing a migration from rng-tools to rng-tools5 will break an existing setup. The intent of transitioning was entirely to make it easier for people reading non-debian-specific instructions on the internet telling them to install "rng-tools" in order to get certain functionality (specifically RDRAND/RDSEED) would get the package they were expecting. The end result for buster would be rng-tools2 and rng-tools5 packages, with an rng-tools package pulling in rng-tools2 as a replacement. Given that the kernel seems to be moving in the direction of allowing RDRAND/RDSEED to seed /dev/random without blocking (see RANDOM_TRUST_CPU) I'm not sure a package renaming dance is worthwhile as the most common reason for installing rng-tools5 will no longer be as relevant. Another option is to simply remove rng-tools, which eliminates the confusion. But, doing that will mean dropping support for certain (legacy) configurations supported in the current rng-tools package but not rng-tools5.
Bug#915559: coreutils: Use renameat2 from glibc instead of syscall
On December 23, 2018 12:51:41 PM EST, Johannes Schauer wrote: >Hi, > >On Tue, 04 Dec 2018 21:15:35 +0100 Johannes 'josch' Schauer > wrote: >> recently (2018-11-29), glibc 2.28 was accepted in unstable. It adds a >wrapper >> for the renameat2 syscall. That wrapper is necessary for fakechroot >because >> fakechroot cannot intercept system calls but uses a preloaded library >to >> intercept library calls. >> >> Up to coreutils 8.30, mv(1) uses the renameat2 syscall which makes >mv(1) >> fail under fakechroot. See #909612. >> >> Now that glibc 2.28 offers the renameat2 library function as a >wrapper >> to the syscall, coreutils added support for choosing the library >> function instead of the syscall if the former is available: >> >> >https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=c50cf67bd7ff70525f3cb4074f0d9cc1f5c6cf9c >> >> I don't know if another coreutils release is likely to happen before >the >> freeze but if it isn't please consider the attached patch which >> backports the commit from the gnulib git to coreutils 8.30. >> >> Without this patch, fakechroot is currently not very useful because >the >> mv(1) tool is unusable inside fakechroot. Most prominently, apt uses >> mv(1) inside its postinst script, so its impossible to install apt >inside >> fakechroot and thus one cannot setup a sensible system. > >what is the status of this bug? Without this patch, the functionality >of >fakechroot and mmdebstrap in the next stable release will be hampered. >If you >don't have time, I could also NMU coreutils with the attached patch. > >What do you think? > >Thanks! > >cheers, josch Please just wait -- Michael Stone (From phone, please excuse typos)
Bug#912291: make: man page/info doc enhancement
Package: make Version: 4.2.1-1.2 Severity: wishlist The man page for make contains SEE ALSO The full documentation for make is maintained as a Texinfo manual. If the info and make programs are properly installed at your site, the command info make should give you access to the complete manual. Obviously, in debian the info page isn't available by default since it was broken out. Adding a tutorial on how to install a package from non-free is probably outside the scope of make.1. But, perhaps you could add something like: Full documentation available at https://www.gnu.org/software/make/manual/html_node/index.html Which is much more likely to be useful to a user on a default debian install. Mike Stone
Bug#912220: ifupdown: clarify netmask documentation
Package: ifupdown Version: 0.8.34 Severity: wishlist The documentation note for inet netmask currently reads: Netmask (dotted quad or CIDR) I suggest changing that to be more like the inet6 netmask note, so: Netmask (dotted quad or number of bits, e.g., 24) Also it would be good to add to both inet and inet6 netmask a note that use of these keywords replaces the "/bits" notation in the address keyword. So the new inet netmask note would be something like: Netmask (dotted quad or number of bits, e.g., 24) used in lieu of "/netmask" in address Finally, it may be useful to note that the netmask keyword is a legacy/deprecated keyword that can be fully replaced with the current address syntax. Mike Stone
Bug#909803: freeipa-client: depends chrony should be downgraded to recommends
severity 909803 serious thanks There does not seem to be any logic in the freeipa-client package to ensure a working time configuration after ntp is forced out in favor of chrony. This implies that a freeipa client may become unusable after upgrade once its clock has drifted far enough in the absence of a time source.
Bug#909803: freeipa-client: depends chrony should be downgraded to recommends
Package: freeipa-client Version: 4.7.0-1 Severity: normal freeipa client does not technically require chrony (or, previously, ntp). The ipa-client-install routine provides an option to not configure NTP, and the ipa docs instruct that this option should be used if the administrator wants to use a different NTP configuration. Therefore, the debian freeipa-client should not depend on chrony. In particular, the current dependency will potentially rip out a working ntp config and replace it with a potentially non-working chrony config, for no benefit. Downgrading the dependency to a recommends would still cover the common case, but permit more flexibility for other cases.
Bug#905242: vsftpd: postinst fails if /srv/ftp is a symlink
Package: vsftpd
Version: 3.0.3-10
Severity: important
Current postinst contains:
if [ ! -d "${_DIRECTORY}" ]
then
mkdir -p "${_DIRECTORY}"
chown root:${_USERNAME} ${_DIRECTORY}
else
echo
echo "vsftpd directory (${_DIRECTORY}) already exists,
doing nothing."
fi
This fails if ${_DIRECTORY} is a symbolic link. Suggest changing to
if [ ! -e "${_DIRECTORY}" ]
which will be correct regardless of what kind of filesystem object is at
${_DIRECTORY}.
--
Mike Stone
Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Sat, Jul 21, 2018 at 02:35:59AM +0100, Ben Hutchings wrote: I think you can do something like: [...] # postinst time: use link & rename to replace working version atomically. It's technically possible, but AFAICT a policy violation. Mike Stone
Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, Jul 20, 2018 at 02:18:51AM +0200, Marco d'Itri wrote: On Jul 18, Marco d'Itri wrote: Some day it may replace crypt(3), currently provided by glibc: https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt I tried creating a package which would divert libc's libcrypt, but it appears to be much harder than I thought. Installing it would looke like: 1) libcrypt1.preinst diverts glibc's libcrypt.so.1 2) dpkg does things 3) dpkg installs libxcrypt's libcrypt.so.1 4) dpkg does more things 5) libcrypt1.postinst runs/triggers ldconfig And this means that perl (a libcrypt dependency) would be broken between 1 and 5 (or maybe 1 and 3): is this ever going to work? But even if this worked correctly, glibc installs a libcrypt-N.NN.so, whose exact name I expect changes among different releases. Is there any way to implement all this safely? Remove libcrypt from glibc first, with a dependency on a libxcrypt that replaces it. I don't think it's safe to try as a diversion. You could maybe have fun with symlinks (see the /bin/sh saga) if you wanted to be able to switch back and forth, but if libcrypt is really leaving glibc there wouldn't seem to be any point to that. Mike Stone
Bug#904019: ITP: libxcrypt -- Extended crypt library for DES, MD5, Blowfish and others
On Fri, Jul 20, 2018 at 10:47:02AM +0200, Marco d'Itri wrote: On Jul 20, Philipp Kern wrote: I think it's odd to say "here, I'm packaging up a replacement for your library, but I'm not going to coordinate with you" when we are preparing a (somewhat) coherent distribution, so I don't think that option should be discarded. (Unless you have a reasonable worry that you experiment will fail and hence don't want to bother people, I guess.) At this point it is not an experiment anymore since Fedora switched and removal from glibc is still planned for a future release. I just wanted to have something usable and working before starting to discuss a transition plan. For purely testing purposes you could rely on a local diversion. (Install as a different library name, divert libcrypt, symlink.) Or you just build the package with the final names and force the conflicts. But the usable and working version demands a coordinated libc package. Mike Stone
Bug#903815: ITP: pw -- A simple command-line password manager
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote: It writes to `/dev/shm` which is not disk. All else that's been said aside, this idea is also dangerously incorrect in a typical configuration: the tmpfs backend will write to swap under memory pressure. (This is also true of the memory used by the process; if it's actually important to keep data from being written to persistent storage, it should be set unswappable using mlock. I have no idea how one would do this effectively in a shell script.) Mike Stone
Bug#902031: needrestart config file broken
severity 902031 grave done I'm raising the severity of this so it doesn't enter testing before it gets fixed. (The rationale is that the config file is used to blacklist programs which shouldn't be restarted[killed] because doing so may cause loss of work.)
