Package: wnpp
Severity: wishlist
Owner: Ondřej Nový
* Package name: python-pyfakefs
Version : 3.7.1
Upstream Author : Mike Bland
* URL : http://pyfakefs.org/
* License : Apache-2
Programming Lang: Python
Description : implements a fake file system that
On Saturday, 1 February 2020 2:05:55 PM AEDT Michael Biebl wrote:
> Depending on how it goes, I might ask the ftp-masters to lower the
> priority of rsyslog from important to optional, so it would no longer be
> installed by default on new bullseye installations.
I have a mixed feelings about that
Package: wnpp
Severity: wishlist
Owner: Sebastien Badia
* Package name: ruby-nfnetlink
Version : 1.0.2
Upstream Author : Guillaume Delugré
* URL : https://github.com/gdelugre/ruby-nfnetlink
* License : GPL-3+
Programming Lang: Ruby
Description : Wrappe
Hey folks,
Apologies - I should have sent this mail quite a while back. :-/
Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
the 2038 problem in the Linux world. I've spoken about this before,
e.g. at DebConf17. He's been pushing a lot of updates throughout the
Linux kernel,
On Tue, Feb 04, 2020 at 01:14:10PM +, Steve McIntyre wrote:
> B Decide which 32-bit ports we expect to care about by 2038, and
... and consider options taking into account the size of the result list.
--
WBR, wRAR
signature.asc
Description: PGP signature
On Tue, 2020-02-04 at 13:14 +, Steve McIntyre wrote:
> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs b
On Tue, Feb 04, 2020 at 03:17:50PM +0100, Ansgar wrote:
At least for i386, I expect it to be used mostly for legacy
applications (and legacy installations). So breaking ABI by switching
to a "new" architecture or by just changing major libraries like libc6
probably diminishes its value so much t
Hi Steve,
many thanks for this heads-up report!
On Tue, Feb 04, 2020 at 01:14:10PM +, Steve McIntyre wrote:
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe.
for being able to reproducibly rebuild more Debian pack
On Feb 04, Steve McIntyre wrote:
>We'd need to decide exactly which of our 32-bit ports we would want
>to do this path with (probably armhf->arhmft?, maybe
>armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
I agree with Ansgar here: there is no point in rebuilding i386
Package: wnpp
Severity: wishlist
Owner: "Diego M. Rodriguez"
* Package name: python-pylatexenc
Version : 2.1
Upstream Author : Philippe Faist
* URL : https://github.com/phfaist/pylatexenc
* License : Expat
Programming Lang: Python
Description : Simple
Hi!
On Tue, 2020-02-04 at 13:14:10 +, Steve McIntyre wrote:
> The glibc folks have taken an interesting approach.
>
> * 64-bit ABIs/architectures are already using 64-bit time_t
>throughout. The design is sane and so we should already be mostly
>safe here, modulo silly code bugs (we'
On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> >default* to use 32-bit time_t to keep compatibility with existing
> >code. This will *not* be safe as we approach 2038.
> >
> > * 32-bit ABIs/arches *can*
On Feb 04, Guillem Jover wrote:
> Well, I guess such a new (conditinally selectable) name could be
> coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
> (We already have precedent in some ports that do not use the same
> prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.
Package: wnpp
Severity: wishlist
Owner: Alper Nebi Yasak
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: partman-cros
Version : 1
Upstream Author : Alper Nebi Yasak
* URL : http://salsa.debian.org/alpernebbi-guest/partman-cros
* License : GPL-2.0+
Package: wnpp
Severity: wishlist
Owner: Alper Nebi Yasak
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: depthcharge-tools
Version : 0.3.0
Upstream Author : Alper Nebi Yasak
* URL : http://github.com/alpernebbi/depthcharge-tools
* License : GPL-2.0
On Tue, Feb 04, 2020 at 06:13:12PM +0100, Marco d'Itri wrote:
> On Feb 04, Guillem Jover wrote:
> > Well, I guess such a new (conditinally selectable) name could be
> > coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
> > (We already have precedent in some ports that do not u
On Tue, 2020-02-04 at 11:03 -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >default* to use 32-bit time_t to keep compatibility with existing
> > >code. This will *not
Dmitry Smirnov writes:
> On Saturday, 1 February 2020 2:05:55 PM AEDT Michael Biebl wrote:
>> Depending on how it goes, I might ask the ftp-masters to lower the
>> priority of rsyslog from important to optional, so it would no longer
>> be installed by default on new bullseye installations.
> I
Ansgar writes:
> So maybe just recommend people to move to 64-bit architectures and put
> 32-bit applications in a time namespace so they believe they are still
> in 2001 ;-) 32-bit architectures will probably still be useful in
> embedded contexts for a long time and there it might be easier to
Hi Colin,
On Tue, Feb 04, 2020 at 06:48:43PM +, Colin Watson wrote:
> > This may be a good time to mention that SONAMEs like libc6.1 are not
> > supported by libtool, so in libxcrypt I had to conditionally patch the
> > generated libtool executable for the architectures that did this.
> Wh
❦ 4 février 2020 11:30 -08, Russ Allbery :
>> As a heavy user or Rsyslog features I feel that switching default
>> logging system yields no benefits to say the least.
>
> As a heavy user, perhaps you're not the target audience for a default?
> You're going to install rsyslog no matter what, sinc
On Tue, Feb 04, 2020 at 11:03:03AM -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > >default* to use 32-bit time_t to keep compatibility with existing
> > >code. This wi
On Wednesday, 5 February 2020 6:30:03 AM AEDT Russ Allbery wrote:
> The primary benefit that I can see is one fewer daemon running on a
> default installation, one fewer thing to have security vulnerabilities or
> some other problems, one fewer thing to keep up to date, and a smaller
> base install
On Tuesday, February 4, 2020 5:22:15 PM EST Vincent Bernat wrote:
> ❦ 4 février 2020 11:30 -08, Russ Allbery :
> >> As a heavy user or Rsyslog features I feel that switching default
> >> logging system yields no benefits to say the least.
> >
> > As a heavy user, perhaps you're not the target au
On Tuesday, February 4, 2020 5:39:19 PM EST Dmitry Smirnov wrote:
> On Wednesday, 5 February 2020 6:30:03 AM AEDT Russ Allbery wrote:
> > The primary benefit that I can see is one fewer daemon running on a
> > default installation, one fewer thing to have security vulnerabilities or
> > some other
On Tue, Feb 4, 2020 at 5:15 PM Scott Kitterman wrote:
>
> On Tuesday, February 4, 2020 5:22:15 PM EST Vincent Bernat wrote:
> > ❦ 4 février 2020 11:30 -08, Russ Allbery :
> > >> As a heavy user or Rsyslog features I feel that switching default
> > >> logging system yields no benefits to say the
Dmitry Smirnov writes:
> On Wednesday, 5 February 2020 6:30:03 AM AEDT Russ Allbery wrote:
>> The primary benefit that I can see is one fewer daemon running on a
>> default installation, one fewer thing to have security vulnerabilities
>> or some other problems, one fewer thing to keep up to date
On Tue, 2020-02-04 at 18:10 -0800, Russ Allbery wrote:
> It does take a bit of retraining to use journalctl instead (and I'm
> personally not horribly fond of its UI, although that's probably
> because I'm using it wrong), but it's a lot better at effectively
> narrowing log messages to the things
On Tuesday, February 4, 2020 9:01:55 PM EST Matt Zagrabelny wrote:
> On Tue, Feb 4, 2020 at 5:15 PM Scott Kitterman wrote:
> > On Tuesday, February 4, 2020 5:22:15 PM EST Vincent Bernat wrote:
> > > ❦ 4 février 2020 11:30 -08, Russ Allbery :
> > > >> As a heavy user or Rsyslog features I feel th
❦ 5 février 2020 01:01 -05, Scott Kitterman :
> Not particularly useful IMO. In /var/log/mail.log I can see log entries from
> all the programs configured to log to the mail facility. That way I can see
> the interaction between them. On a typical server that is for sending mail I
> often
On Wed, Feb 05, 2020 at 09:39:19AM +1100, Dmitry Smirnov wrote:
> For example, if a certain daemon manifested a condition when a message is
> logged too often, then with Rsyslog I could suppress noise by something like
> the following
This is a workaround for another problem. Fix the real probl
Am 05.02.20 um 07:01 schrieb Scott Kitterman:
> Not particularly useful IMO. In /var/log/mail.log I can see log entries from
> all the programs configured to log to the mail facility. That way I can see
> the interaction between them. On a typical server that is for sending mail I
> often ne
Am 05.02.20 um 07:01 schrieb Scott Kitterman:
> Of course the fact that I can't use all the tools available to manipulate
> text
> files to follow or analyze logs is problematic.
Fwiw, you can still run
journalctl -f | grep bla | awk and what not
which will filter / process incoming messages
or j
Am 05.02.20 um 06:08 schrieb Russell Stuart:
> journald has nits I mention below, but I was prepared to put up with
> them and drop rsyslog until one day a server stopped in a nasty way and
> journalctl refused to display what lead up to the crash because it's
> binary logs were corrupt. As far as
Am 05.02.20 um 07:49 schrieb Michael Biebl:
> Am 05.02.20 um 07:01 schrieb Scott Kitterman:
>
>> Not particularly useful IMO. In /var/log/mail.log I can see log entries
>> from
>> all the programs configured to log to the mail facility. That way I can see
>> the interaction between them. On
35 matches
Mail list logo
