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#1039974: tomcat10: tomcat user has wrong home "/var/lib/tomcat" directory in /etc/passwd
Package: tomcat10 Version: 10.1.6-1 Severity: important Dear Maintainer, * What led up to the situation? deploy .war in tomcat10 got errors from tomcat10 in "journalctl -f" * What exactly did you do that was effective ? change tomcat user home in /etc/passwd to /var/lib/tomcat10 * What was the outcome of this action? Problem solved -- System Information: Debian Release: 12.0 amd64
Bug#1031046: Asterisk removed from Debian Bookworm
Thanks for the explanation. I am indeed interested in finding out what would be involved / required / expected in order to help keep Asterisk as a package in a future release of Debian Stable - and in the meantime, to ensure that it remains available in Backports. I have asked on the Asterisk community list / forum to find out whether anyone else would be willing to join in, but I think the starting point for anyone agreeing to this needs to be - what would you want someone to do, if they have the time and interest to help in keeping Asterisk in Debian? Thanks, Antony. -- "The future is already here. It's just not evenly distributed yet." - William Gibson
Bug#1031046: Asterisk removed from Debian Bookworm
I've just discovered this "bug report" and I'm very disappointed by it. Please can someone tell me: 1. How many people are involved as Asterisk Debian Package Maintainers? 2. Has this number decreased noticeably since the previous Debian release Bullseye? 3. Has anyone contacted the Asterisk community (for example via https://community.asterisk.org ) to see whether additional volunteers would be willing to help with the effort involved in keeping Asterisk in the Debian project? Thanks, Antony.
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#1021735: libffi upgrade breaks Wayland on aarch64
Hi, This libffi upgrade also completely breaks all use of Wayland on aarch64. We use libffi to dispatch protocol messages (requests received by the server and events received by the client) to native-code handlers, and we are now getting completely nonsensical values from it. Can this upgrade please be rolled back until it can be root-caused and fixed? Cheers, Daniel
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#1004879: acpitool: New upstream development?
On 02 Feb 2022 22:25, Guillem Jover wrote: > Source: acpitool > Source-Version: 0.5.1-6 > Severity: wishlist > Tags: upstream > X-Debbugs-Cc: Al Stone > > Hi! > > I just noticed that Al Stone forked the upstream of this project > at <https://pagure.io/acpitool>, collected several of the distro > patches and prepared a 0.5.2 release. Although no more activity > happened since 3 years ago, so I'm not sure what the current status > is there. I'm CCing Al to try to clarify whether this is abandoned > or in maintenance mode, and further patches and similar would be > accepted (we have some in the Debian Bug Tracking System). Which > means we could switch to use that as our upstream. > > Thanks, > Guillem I resigned from Debian some time ago. Do with this whatever you'd like. I am no longer willing to volunteer my time to this distro. -- ciao, al
Bug#773731:
Still an issue in 2022...
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#985233: O: lmbench -- Utilities to benchmark UNIX systems
On 22 Mar 2021 22:37, Andreas Beckmann wrote: > Hi Al, > > On Sun, 14 Mar 2021 15:17:52 -0600 Al Stone wrote: > > I intend to orphan the lmbench package. I no longer use it, > > Can you push the changes and tag from the -5 upload, please? > > And could you try to move the package on salsa from your personal namespace > to the 'debian' or 'hpc-team' namespace? (I think that should be Settings -> > General -> Advanced -> Transfer project, but I have never used it.) There is > no need to do an upload to update the Vcs URLs. > > Thanks, > > Andreas, who might adopt it for the HPC team Howdy, Andreas. I tried to transfer the package but the only namespace I was able to enter was my own. I can't tell if that's the way the other namespaces are set up or just operator error on my part -- either way, salsa won't let me. Sorry :(. -- Ciao, al -- Al Stone E-mail: a...@ahs3.net --
Bug#985679: O: gnucobol -- COBOL compiler
Package: wnpp Severity: normal Control: affects -1 src:gnucobol I am orphaning the gnucobol package. The package description is: GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL implements a substantial part of the COBOL 85, COBOL 2002 and COBOL 2014 standards and X/Open COBOL, as well as many extensions included in other COBOL compilers (IBM COBOL, MicroFocus COBOL, ACUCOBOL-GT and others). . GnuCOBOL translates COBOL into C and compiles the translated code using a native C compiler. . Build COBOL programs on various platforms, including GNU/Linux, Unix, Mac OS X, and Microsoft Windows. GnuCOBOL has also been built on HP/UX, z/OS, SPARC, RS6000, AS/400, along with other combinations of machines and operating systems. . While being held to a high level of quality and robustness, GnuCOBOL does not claim to be a “Standard Conforming” implementation of COBOL. . GnuCOBOL passes over 9600 of the NIST COBOL 85 test suite tests and over 750 internal checks during build.
Bug#985678: O: rasdaemon -- utility to receive RAS error tracings
Package: wnpp Severity: normal Control: affects -1 src:rasdaemon I orphaning the rasdaemon package. The package description is: rasdaemon is a RAS (Reliability, Availability and Serviceability) logging tool. It currently records memory errors, using the EDAC tracing events. EDAC are drivers in the Linux kernel that handle detection of ECC errors from memory controllers for most chipsets on x86 and ARM architectures. This userspace component consists of an init script which makes sure EDAC drivers and DIMM labels are loaded at system startup, as well as a utility for reporting current error counts from the EDAC sysfs files.
Bug#985677: O: acpica-unix -- ACPICA tools for the development and debug of ACPI tables
Package: wnpp Severity: normal Control: affects -1 src:acpica-unix I am orphaning the acpica-unix package. The package description is: The ACPI Component Architecture (ACPICA) project provides an OS-independent reference implementation of the Advanced Configuration and Power Interface Specification (ACPI). ACPICA code contains those portions of ACPI meant to be directly integrated into the host OS as a kernel-resident subsystem, and a small set of tools to assist in developing and debugging ACPI tables. . This package contains only the user-space tools needed for ACPI table development, not the kernel implementation of ACPI. The following commands are installed: -- iasl: compiles ASL (ACPI Source Language) into AML (ACPI Machine Language), suitable for inclusion as a DSDT in system firmware. It also can disassemble AML, for debugging purposes. -- acpibin: performs basic operations on binary AML files (e.g., comparison, data extraction) -- acpidump: write out the current contents of ACPI tables -- acpiexec: simulate AML execution in order to debug method definitions -- acpihelp: display help messages describing ASL keywords and op-codes -- acpinames: display complete ACPI name space from input AML -- acpisrc: manipulate the ACPICA source tree and format source files for specific environments -- acpixtract: extract binary ACPI tables from acpidump output (see also the pmtools package)
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
On 21 Mar 2021 20:50, Adrian Bunk wrote: > On Sun, Mar 21, 2021 at 11:31:45AM -0600, Al Stone wrote: > > On 21 Mar 2021 14:20, Adrian Bunk wrote: > > > On Sat, Mar 20, 2021 at 11:06:01AM -0600, Al Stone wrote: > > > > On 20 Mar 2021 00:09, Ivo De Decker wrote: > > > > > Control: tags -1 moreinfo > > > > > > > > > > Hi, > > > > > > > > > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote: > > > > > > Please remove the version of gnucobol in unstable. Per upstream, > > > > > > this version in not backwards compatible with any prior version. > > > > > > I made a mistake in packaging it at all. > > > > > > > > > > > > An upload of the proper version (3.1.2) is being prepared. > > > > > > > > > > Removing a package from unstable and then uploading the same package > > > > > with a > > > > > lower version isn't possible. If you want to go back to version 3.x, > > > > > you'll > > > > > need to do an upload with a version higher than the current one. > > > > > > > > > > Cheers, > > > > > > > > > > Ivo > > > > > > > > Understood. My only option may be to increase the epoch. > > > > > > An epoch is not the only option, and it is the wrong option: > > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly > > > > Why are you assuming I have not read the documentation? ... > > You wrote "My only option", which implied to me that you were not aware > of the other option that is actually the recommended option. > > > Or that I do not know that that particular bit of Policy > > does not exist? That is precisely why the word "may" > > was used. > > I'm really getting tired of these sorts of assumptions > that everyone is a native English speaker. > > I am not. > > My understanding of "only" is that it means "there is not any other". > > Fancy interactions between the words "only" and "may" are beyond my > knowledge of the English language. Yet another assumption. I taught English as a second language. I speak at least two others. I am very aware of the strangeness of the English language and write intentionally simple English. I deal with this on a daily basis with colleagues from multiple countries. > > I'm really getting tired of these sorts of assumptions. > > It would be much more useful to assume good intent on > > the part of others. > > This is an impossible proposition when it comes across as if the other > person is about to make an irreversible mistake, like adding an epoch > without first getting consensus on debian-devel. No, it is not impossible. You see it as impossible. I do not. And, this highlights the problem: you are assuming I do not know about the need for consensus. You have no idea what I'm planning to do next, and you have no idea what I do and do not know. Yet, you assume I am going to make a mistake. All I'm asking is that you find a way to do as many others do -- assume that people know what they are doing until proven otherwise. > cu > Adrian > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
On 20 Mar 2021 00:09, Ivo De Decker wrote: > Control: tags -1 moreinfo > > Hi, > > On Fri, Mar 19, 2021 at 04:25:01PM -0600, Al Stone wrote: > > Please remove the version of gnucobol in unstable. Per upstream, > > this version in not backwards compatible with any prior version. > > I made a mistake in packaging it at all. > > > > An upload of the proper version (3.1.2) is being prepared. > > Removing a package from unstable and then uploading the same package with a > lower version isn't possible. If you want to go back to version 3.x, you'll > need to do an upload with a version higher than the current one. > > Cheers, > > Ivo Understood. My only option may be to increase the epoch. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#985557: RM: gnucobol -- ROM; wrong version of compiler, breaks compatibility
Package: ftp.debian.org Severity: normal Please remove the version of gnucobol in unstable. Per upstream, this version in not backwards compatible with any prior version. I made a mistake in packaging it at all. An upload of the proper version (3.1.2) is being prepared.
Bug#985409: RM: gnucobol/4.0~early~20200606-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm ROM: the wrong upstream version was packaged; I made a mistake. This version completely breaks any backwards compatibility and should not have been used. It is not recommended by upstream because it breaks compatibility. If this version of the package stays in Debian at all, it should be in experimental, at best.
Bug#985233: O: lmbench -- Utilities to benchmark UNIX systems
Package: wnpp Severity: normal X-Debbugs-Cc: da...@debian.org Control: affects -1 src:lmbench I intend to orphan the lmbench package. I no longer use it, and have not for quite some time, and no longer have the time to maintain it properly. Upstream seems to be static (perhaps reasonably so for a benchmark) but we have cleaned up things a bit over the years. Cleaned up most of the lintian issues on the last update, too, but there are still a couple of minor bugs left. The package description is: Lmbench is a set of utilities to test the performance of a unix system producing detailed results as well as providing tools to process them. It includes a series of micro benchmarks that measure some basic operating system and hardware metrics: . * file reading and summing * memory bandwidth while reading, writing and copying * copying data through pipes * copying data through Unix sockets * reading data through TCP/IP sockets
Bug#985165: O: python-jenkinsapi -- bindings for Python usage of the Jenkins remote API
Package: wnpp Severity: normal Control: affects -1 src:python-jenkinsapi I intend to orphan the python-jenkinsapi package. I no longer use it nor have a need for it; hopefully, someone else does. The package description is: Jenkins is the market leading continuous integration system, originally created by Kohsuke Kawaguchi. This API makes Jenkins even easier to use by providing an easy to use conventional Python interface. . Jenkins (and its predecessor Hudson) are useful projects for automating common development tasks (e.g., unit-testing, production batches) - but they are somewhat Java-centric. Thankfully the designers have provided an excellent and complete REST interface. This library wraps up that interface as more conventional Python objects in order to make most Jenkins-oriented tasks simpler.
Bug#748783: need another packager, if there is interest
I thought I would have time to package this but clearly I do not. Moving this back to RFP in case someone is interested. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
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#921257:
Hi, Is it possible to update the version of khal that is being built here? One of the failures in the latest build log was fixed in 0.10.2 and I'm not sure about the other, and there's currently no version in testing. Thanks!
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#971908: hinawa-utils: hinawa-apogee-duet-cli is missing FwUnit
Package: hinawa-utils Version: 0.2.0-3 Severity: important X-Debbugs-Cc: v...@linuxgamecast.com Dear Maintainer, * What led up to the situation? Upgrading from Buster to Testing or Unstable. * What was the outcome of this action? hinawa-apogee-duet-cli no longer functions. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-2-amd64 (SMP w/16 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hinawa-utils depends on: ii python3 3.8.2-3 ii python3-hinawa-utils 0.2.0-3 hinawa-utils recommends no packages. hinawa-utils suggests no packages. -- no debconf information
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#966680: src:acpica-unix: fails to migrate to testing for too long: FTBFS on s390x
On 24 Sep 2020 11:23, Paul Gevers wrote: > Hi Al, > > ping > > On Sat, 1 Aug 2020 21:34:14 +0200 Paul Gevers wrote: > > This bug will trigger auto-removal when appropriate. As with all new > > bugs, there will be at least 30 days before the package is auto-removed. > > acpica-unix is a key package and will not be autoremoved. Can you please > fix the situation? > > Paul Yup, working on it. I may have to turn off s390x support for the short term; the issue is that this package is solely little-endian upstream and it has been patched and bodged so many times for big-endian support, it has been become unmaintainable for big- endian. These patches are being re-done and made straightforward but it is taking a lot longer than hoped; ideally, I can get them upstreamed and simplify further. -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org -- signature.asc Description: PGP signature
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#966099: gnucobol: install gnucobol 3.1-rc1 by default instead of unstable version
Package: gnucobol Version: 4.0~early~20200606-3 Severity: normal Dear Maintainer, This version of the compiler unfortunately requires a recompile of all COBOL modules in order to be used. Further, this is still considered pretty unstable and upstream does not recommend it for daily use. Please revert the default version of the compiler to 3.1-rc1, the current stable version. Any of the 4.0+ versions should be in a separate package so as not to disturb stable development environments. -- System Information: Debian Release: bullseye/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/8 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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnucobol depends on: ii gcc 4:9.2.1-3.1 ii libc6 2.30-8 ii libcob5 4.0~early~20200606-3 ii libcob5-dev 4.0~early~20200606-3 ii libgmp-dev2:6.2.0+dfsg-6 ii libncurses-dev [libncurses5-dev] 6.2-1 ii libncurses5-dev 6.2-1 gnucobol recommends no packages. gnucobol suggests no packages. -- no debconf information
Bug#962276: (no subject)
Possibly related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961206 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961741
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#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
On 05 Jun 2020 19:02, Petter Reinholdtsen wrote: > > I discovered what the problem is. The test [ $res ] do not work the way > you want it to. It need to compare with 0, like this: Which is kind of strange, and makes autopkgtest very hard to use since this works fine when run locally like so: # cd # autopkgtest -- null Everything passes when run this way. Easy fix now that you've pointed it out, but passing strange. > diff --git a/debian/tests/test01 b/debian/tests/test01 > index 1c0d63f..73e1fac 100755 > --- a/debian/tests/test01 > +++ b/debian/tests/test01 > @@ -1,4 +1,5 @@ > #!/bin/sh > + > cd debian/tests > > echo "info: compiling" > @@ -7,7 +8,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act > res=$? > -if [ $res ] ; then > +if [ 0 = $res ] ; then > echo "success: test01 produced proper results" > else > echo "error: test01 did not produce proper results" > diff --git a/debian/tests/test02 b/debian/tests/test02 > index fb85d2e..cb4359d 100755 > --- a/debian/tests/test02 > +++ b/debian/tests/test02 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test02 produced proper results" > else > echo "error: test02 did not produce proper results" > diff --git a/debian/tests/test03 b/debian/tests/test03 > index c028d8b..07d679c 100755 > --- a/debian/tests/test03 > +++ b/debian/tests/test03 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test03 produced proper results" > else > echo "error: test03 did not produce proper results" > diff --git a/debian/tests/test04 b/debian/tests/test04 > index fd2a6ad..ee31d4a 100755 > --- a/debian/tests/test04 > +++ b/debian/tests/test04 > @@ -7,7 +7,7 @@ echo "info: compiling" > echo "info: running" > cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act > res=$? > -if [ $res ] ; then > +if [ 0 == $res ] ; then > echo "success: test04 produced proper results" > else > echo "error: test04 did not produce proper results" > > -- > Happy hacking > Petter Reinholdtsen > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
Bug#962081: gnucobol: Failing autopkgtest scripts should report what went wrong
On 03 Jun 2020 14:30, Petter Reinholdtsen wrote: > > Could > https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html > > contain the key to why these test are failing? It states > > "The cwd of each test is guaranteed to be the root of the source > package, which will have been unpacked but not built. However note > that the tests must test the installed version of the program. Tests > may not modify the source tree (and may not have write access to it)." Hrm. So write access seems to be more constrained than this led me to believe; I'll try these patches out and rebuild tonight. I did think about using AUTOPKGTEST_TMP but had not convinced myself it was absolutely required. Thank you for all the help, Petter! > If so, the following patch might help: > > diff --git a/debian/tests/hello b/debian/tests/hello > index 60943be..15c3985 100755 > --- a/debian/tests/hello > +++ b/debian/tests/hello > @@ -1,4 +1,5 @@ > #!/bin/sh > +cd $AUTOPKGTEST_TMP > cat > HELLO.cob< HELLO * HISTORIC EXAMPLE OF HELLO WORLD IN COBOL > IDENTIFICATION DIVISION. > diff --git a/debian/tests/test01 b/debian/tests/test01 > index 22d943e..783901b 100755 > --- a/debian/tests/test01 > +++ b/debian/tests/test01 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test01.cob > test01.act 2>&1) > +(cobc test01.cob > $AUTOPKGTEST_TMP/test01.act 2>&1) > > echo "info: running" > -cmp -s test01.exp test01.act > +cmp -s test01.exp $AUTOPKGTEST_TMP/test01.act > res=$? > if [ $res ] ; then > echo "success: test01 produced proper results" > diff --git a/debian/tests/test02 b/debian/tests/test02 > index 2e06f74..99f0978 100755 > --- a/debian/tests/test02 > +++ b/debian/tests/test02 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test02.cob > test02.act 2>&1) > +(cobc test02.cob > $AUTOPKGTEST_TMP/test02.act 2>&1) > > echo "info: running" > -cmp -s test02.exp test02.act > +cmp -s test02.exp $AUTOPKGTEST_TMP/test02.act > res=$? > if [ $res ] ; then > echo "success: test02 produced proper results" > diff --git a/debian/tests/test03 b/debian/tests/test03 > index f378787..701ade9 100755 > --- a/debian/tests/test03 > +++ b/debian/tests/test03 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test03.cob > test03.act 2>&1) > +(cobc test03.cob > $AUTOPKGTEST_TMP/test03.act 2>&1) > > echo "info: running" > -cmp -s test03.exp test03.act > +cmp -s test03.exp $AUTOPKGTEST_TMP/test03.act > res=$? > if [ $res ] ; then > echo "success: test03 produced proper results" > diff --git a/debian/tests/test04 b/debian/tests/test04 > index 04b325e..c50b157 100755 > --- a/debian/tests/test04 > +++ b/debian/tests/test04 > @@ -2,10 +2,10 @@ > cd debian/tests > > echo "info: compiling" > -(cobc test04.cob > test04.act 2>&1) > +(cobc test04.cob > $AUTOPKGTEST_TMP/test04.act 2>&1) > > echo "info: running" > -cmp -s test04.exp test04.act > +cmp -s test04.exp t$AUTOPKGTEST_TMP/est04.act > res=$? > if [ $res ] ; then > echo "success: test04 produced proper results" > > -- > Happy hacking > Petter Reinholdtsen > -- Ciao, al -- Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
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#959120: O: libbrahe -- heterogeneous C library of numeric functions
Package: wnpp Severity: normal I intend to orphan the libbrahe package. I no longer have an interest and upstream seems to have slowed to a halt, if not abandoned it. The package description is: This library provides: . * a function for rounding floating point values to a specific number of digits * several pseudo-random number generators, including the Mersenne Twister, various algorithms by Marsaglia, and ISAAC * least common multiple and greatest common denominator functions * a few trigonometry functions for finding the inversions of hyperbolic sine, cosine, and tangent . This library is also used by libevocosm, which is in turn the foundation for Acovea, used to determine optimal compiler optimizations
Bug#945816: O: gnucobol -- COBOL compiler
On 21 Apr 2020 08:23, Petter Reinholdtsen wrote: > [Ludwin Janvier] > > I intend to orphan the gnucobol package. > > Hi. I really enjoyed finding GNU Cobol in Debian, and hope it will stay > here for a long time. Unfortunately I do not have the capacity to > maintain it myself in Debian. > > Can you tell something about the problems with maintaining this package, > or what a future maintainer should keep in mind? > > I visited what I believe is the official IRC channel for the project, > irc://irc.oftc.net/#gnucobol, and there were no-one there, which I found > worrying. > -- > Happy hacking > Petter Reinholdtsen For somewhat nostalgic reasons on my part, I'm looking at this package and thinking about adopting it. It looks like the package has not been touched in some time, but upstream still seems to be active (commits within the last day, for example). Petter, if you'd rather adopt it, let me know. Otherwise, assuming it is in reasonably decent shape to start with, which it seems to be, I'll adopt it. -- Ciao, al ------ Al Stone Debian Developer E-mail: a...@ahs3.nethttp://www.debian.org a...@debian.org --
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#949013: Upgrade of Perl stymied by a dependency issue
Package: libgtk2-perl Version: 2:1.24993-1 Whilst running a dist-upgrade, the Perl packages cannot be upgraded due to an erroneous dependency. libgtk2-perl : Depends: perlapi-5.28.1 which is a virtual package, provided by: - perl-base (5.28.1-6), but 5.30.0-9 is to be installed
Bug#949012: Error generating boot image
Package: initramfs-tools Version: 0.135 uname -a output:- Linux roblaptop 5.4.0-2-amd64 #1 SMP Debian 5.4.8-1 (2020-01-05) x86_64 GNU/Linux Processing triggers for libglib2.0-0:amd64 (2.62.4-1) ... Processing triggers for libc-bin (2.29-7) ... Processing triggers for systemd (244-3) ... Processing triggers for man-db (2.9.0-2) ... Processing triggers for dbus (1.12.16-2) ... Processing triggers for initramfs-tools (0.135) ... update-initramfs: Generating /boot/initrd.img-5.4.0-2-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169 depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_kzFpRd/lib/modules/5.4.0-2- amd64/modules.builtin.bin' depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '/var/tmp/mkinitramfs_kzFpRd/lib/modules/5.4.0-2- amd64/modules.builtin.bin' The depmod: error lines repeat dozens of times until the boot image generation finishes. I have no idea which package is at fault. However, the laptop boots normally afterwards.
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#841238: acpidump: "turbostat" binary silently dropped?
Package: acpica-tools Followup-For: Bug #841238 I am closing this bug since turbostat has been moved to a different package. Please install linux-cpupower to install turbostat.
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#922431: Upstream is confused about Tracing consisting on non-source JS
On Fri, 2 Aug 2019 20:57:37 -0400 Michael Gilbert wrote: > The sourceless files are in third_party/catapult/tracing, which is now > stripped out of the debian source package. Looking through http://commondatastorage.googleapis.com/chromium-browser-official/chromium-76.0.3809.71-lite.tar.xz (the file that appears to be fetched in debian/rules), I'm seeing a few minified .js files in third_party/catapult/tracing/third_party; are these the ones you're talking about? I just want to make sure I'm getting it right so we can work with upstream to get sources shipped properly. Thanks, -Andrew
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. :)
