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
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.
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
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
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
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
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
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)
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
been widely deployed, which
makes now the time to fix it.
Michael Stone
m 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
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:
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
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)
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
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
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
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
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
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
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
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
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.
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 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
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
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.
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"
>>>
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 -
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
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
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
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
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
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
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
Adding a message to stderr telling people to use mktemp may be a
reasonable step.
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
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
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
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
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
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,
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
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
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
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
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*
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
I thought debports architectures weren't supposed to prevent migration
to testing so I'm confused about why the package hasn't migrated.
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
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 ss
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
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
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 (>=
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
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
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
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),
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
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.
More specifically, refer to systemd.unit(5) and you'll find that
/lib/systemd/user is not defined.
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]:
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
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-lin
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
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
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
64)
>
>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)
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
On Thu, Feb 07, 2019 at 04:08:21PM +0100, Ansgar wrote:
On Thu, 2019-02-07 at 09:59 -0500, Michael Stone wrote:
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
> How would this locale differ from C.UTF-8? Is the only difference
> that C.UTF-8 has strict lexicographical s
On Thu, Feb 07, 2019 at 02:40:06PM +, Simon McVittie wrote:
How would this locale differ from C.UTF-8? Is the only difference
that C.UTF-8 has strict lexicographical sorting, whereas "en" would have
case-insensitive sorting like en_GB.utf8 does? (If that's the only
difference, then perhaps
Package: unbound
Version: 1.9.0-1
Severity: grave
Justification: renders package unusable
Immediately after installing 1.9.0-1, unbound refused to run after restart.
System logs contained:
Feb 6 11:00:24 annuminas package-helper[6142]: /var/lib/unbound/root.key has
content
Feb 6 11:00:24
On Wed, Feb 06, 2019 at 10:47:12AM +0100, Johannes Schauer wrote:
On Wed, 30 Jan 2019 12:07:37 +0100 Jonas Smedegaard wrote:
Jus a friendly nudge: It would be great if this bug was fixed in time for
Buster.
Do you think you can find the time to have a look at the patches
provided by Josch?
of thing that should
be sorted out when a package is ITP'd and discussed, not done and then
declared a fait accompli.)
--
Michael Stone
On Wed, Jan 23, 2019 at 05:19:13AM -0500, Henrique de Moraes Holschuh wrote:
On Mon, Jan 21, 2019, at 10:36, Michael Stone wrote:
Yes, but most of those features are obsolescent at best. I'm not clear
on what functionality is actually being used. (I'm hesitant to remove
"old"
On Wed, Jan 23, 2019 at 05:46:39AM -0500, Henrique de Moraes Holschuh wrote:
On Sun, Jan 20, 2019, at 14:06, Thorsten Glaser wrote:
But you’re not in a situation to command either, considering
hmh is the ONLY maintainer of rng-tools so we WILL need his
input on this (or do an NMU).
Anything
On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote:
On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote:
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
>On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
>> I’m very much against ju
On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
I’m very much against just saying this package
“should not exist”
I'm inclined to agree with this as the source (+ features/parameters) for this
package is
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote:
• keep rng-tools5 and rng-tools-debian in testing
FWIW, I'd much rather call this rng-tools2 or rng-tools-legacy or
something other than rng-tools-debian (which implies that for some
reason this version is more "debian" than
On Sun, Jan 20, 2019 at 03:59:11PM +, Thorsten Glaser wrote:
Please don’t understand me wrong, I’m not against a sensible solution
out of this mess, but I’m very much against just saying this package
“should not exist” without one.
Once it's in stable, this mess is a lot harder to fix, so
On Sun, Jan 20, 2019 at 04:05:09PM +, Thorsten Glaser wrote:
Michael Stone dixit:
So use the epoch. They're invented for fixing collosal errors like
this. Except this time, have the appropriate discussion on -devel
instead of just uploading something without coordination.
Sounds like
On Sun, Jan 20, 2019 at 03:41:22PM +, Thorsten Glaser wrote:
Michael Stone dixit:
Please upload a fixed version of rng-tools instead, reverting the erroneous
change.
That is impossible because the version changed.
In the tool I’m using, I have a hard version requirement on
rng-tools
Package: rng-tools-debian
I don't entirely understand why this package was ever uploaded, and as
far as I can tell, with no ITP. It should not be included in buster.
Package: ftp.debian.org
This package was uploaded as part of a series of uncoordinated changes
to various rng-tools packages. It would be best that it not enter a
stable release, and it isn't clear that the package is needed at all. I
can't find an ITP dicussing this package or how it should
On Sun, Jan 20, 2019 at 03:25:12PM +, Thorsten Glaser wrote:
Michael Stone dixit:
No, that's something else that shouldn't have happened
It’s important to me because the upload of rng-tools (>> 2)
broke things on unstable.
So that should be fixed--the problem should not be made
On Sun, Jan 20, 2019 at 03:01:18PM +0100, Diederik de Haas wrote:
On Fri, 11 Jan 2019 14:51:05 -0500 Michael Stone wrote:
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote:
>There never should have been an NMU simply replacing rng-tools with
>rng-tools5. I did not
On Fri, Jan 11, 2019 at 01:57:28PM -0500, Michael Stone wrote:
There never should have been an NMU simply replacing rng-tools with
rng-tools5. I did not notice that this had happened.
Also, the correct fix for buster is an upload to put things back the way
they were, which is going to be ugly.
There never should have been an NMU simply replacing rng-tools with
rng-tools5. I did not notice that this had happened.
On Fri, Jan 11, 2019 at 07:21:49PM +0100, Andreas Henriksson wrote:
That has apparently failed to materialize well in time for buster.
Looking at the contents of the binary
nsible system.
>
>what is the status of this bug? Without this patch, the functionality
>of
>fakechroot and mmdebstrap in the next stable release will be hampered.
>If you
>don't have time, I could also NMU coreutils with the attached patch.
>
>What do you think?
>
>Thanks!
>
>cheers, josch
Please just wait
--
Michael Stone
(From phone, please excuse typos)
Package: make
Version: 4.2.1-1.2
Severity: wishlist
The man page for make contains
SEE ALSO
The full documentation for make is maintained as a Texinfo manual. If
the info and make programs are properly installed at your site, the
command
info make
Package: ifupdown
Version: 0.8.34
Severity: wishlist
The documentation note for inet netmask currently reads:
Netmask (dotted quad or CIDR)
I suggest changing that to be more like the inet6 netmask note, so:
Netmask (dotted quad or number of bits, e.g., 24)
Also it would be good to add to
severity 909803 serious
thanks
There does not seem to be any logic in the freeipa-client package to
ensure a working time configuration after ntp is forced out in favor of
chrony. This implies that a freeipa client may become unusable after
upgrade once its clock has drifted far enough in the
Package: freeipa-client
Version: 4.7.0-1
Severity: normal
freeipa client does not technically require chrony (or, previously, ntp). The
ipa-client-install routine provides an option to not configure NTP, and the
ipa docs instruct that this option should be used if the administrator wants
to use a
Package: vsftpd
Version: 3.0.3-10
Severity: important
Current postinst contains:
if [ ! -d "${_DIRECTORY}" ]
then
mkdir -p "${_DIRECTORY}"
chown root:${_USERNAME} ${_DIRECTORY}
else
On Sat, Jul 21, 2018 at 02:35:59AM +0100, Ben Hutchings wrote:
I think you can do something like:
[...]
# postinst time: use link & rename to replace working version atomically.
It's technically possible, but AFAICT a policy violation.
Mike Stone
On Fri, Jul 20, 2018 at 02:18:51AM +0200, Marco d'Itri wrote:
On Jul 18, Marco d'Itri wrote:
Some day it may replace crypt(3), currently provided by glibc:
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
I tried creating a package which would divert libc's
On Fri, Jul 20, 2018 at 10:47:02AM +0200, Marco d'Itri wrote:
On Jul 20, Philipp Kern wrote:
I think it's odd to say "here, I'm packaging up a replacement for your
library, but I'm not going to coordinate with you" when we are preparing
a (somewhat) coherent distribution, so I don't think that
On Mon, Jul 16, 2018 at 03:14:20PM +0200, Dashamir Hoxha wrote:
It writes to `/dev/shm` which is not disk.
All else that's been said aside, this idea is also dangerously incorrect
in a typical configuration: the tmpfs backend will write to swap under
memory pressure. (This is also true of
severity 902031 grave
done
I'm raising the severity of this so it doesn't enter testing before it
gets fixed. (The rationale is that the config file is used to blacklist
programs which shouldn't be restarted[killed] because doing so may cause
loss of work.)
1 - 100 of 679 matches
Mail list logo
