On Fri, Nov 19, 2021, at 3:23 PM, Zack Weinberg wrote:
> On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>>> Luca Bocassi wrote:
>>> ...
>>>> nobody has actually seen [the file disappe
On Thu, Nov 18, 2021, at 8:06 PM, Luca Boccassi wrote:
>> On Thu, 2021-11-18 at 16:23 -0500, Zack Weinberg wrote:
>> Luca Bocassi wrote:
>> ...
>>> nobody has actually seen [the file disappearance bug]
>>> happen, to the best of my knowledge.
>>
>
Luca Bocassi wrote:
...
> [merged /usr] is the default. It has been the
> default for multiple releases of multiple distributions. All Ubuntu
> installations that were not using this default are now forcibly
> converted upon upgrade to 21.10.
>
> And yet nobody has actually seen [the file
Marco d'Itri wrote:
> On Nov 18, Zack Weinberg wrote:
>> as it has proven to be a genuinely critical problem
> No, it has not.
In the previous long thread on debian-devel on this subject, someone posted a
step-by-step recipe to reproduce a phenomenon where a file that has been mo
>>>>>> "Sam" == Sam Hartman wrote:
>>>>>> "Zack" == Zack Weinberg writes:
Sam> There's a third option. We sit around in the state where /bin is
Sam> a symlink, but where you cannot move files to /usr paths in the
Sam> package
On Wed, Nov 17, 2021, at 1:37 PM, Sam Hartman wrote:
>>>>>> "Zack" == Zack Weinberg writes:
> Zack> Therefore: either someone fixes the bug,
> Zack> or the transition will have to be canceled. It appears to me
> Zack> that the tech ctt
> I would thus like to proceed and change the priority of rsyslog from
> important to optional, which in turn would mean, it is no longer installed by
> default.
Do you know of a tool that does what logcheck does, but operating directly on
the journal? Logcheck is the only reason I still have
Speaking as the /de facto/ upstream maintainer of autoconf, is there anything
we could do from our end to make it easier for dash to turn $LINENO back on? I
don't have a lot of time to work on autoconf at the moment, but this particular
issue is important to me. I'd like to see all the
Luca Bonassi wrote:
> may I also remind participants in this thread that according to our
> Constitution (2.1), no project member is obliged to do work on
> anything they don't want to
Yes, and it follows that the people who want a change to happen are
the people who will have to do the work to
Marco d'Itri wrote:
> On Nov 10, Sam Hartman wrote:
> > I'm sorry, but I think the only way in which that horse is dead is that
> > no one has proposed patches to dpkg.
> Indeed, because the sides of this argument are like three people (one of
> them being the dpkg maintainer) versus everybody
Tomas Pospisek wrote:
> On 22.08.21 00:11, Guillem Jover wrote:
>> I'm personally just not seeing such consensus, despite the attempts of
>> some to make it pass as so. My perception is that this topic has become
>> such a black hole of despair, that people that take issue with it, are
>> simply
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We are pleased to announce beta release 2.69b of GNU Autoconf.
This release includes eight years of development work since the
previous release, 2.69. See below for the detailed list of changes
since the previous version, as summarized by the
> I think there should be one release which is not shipping
> /usr/bin/python before /usr/bin/python should be reused and pointed
> at python (>> 2). This should be good enough to get all scripts
> actively converted which are not part of the distribution.
>
> If that release is buster, we should
Daniel Pocock wrote:
> I wanted to try compiling some upstream projects against OpenSSL 1.1.0
> on jessie, without installing the package though. I tried the following:
>
> dget -x http://http.debian.net/debian/pool/main/o/openssl/openssl_1.1.0c-1.dsc
>
> cd openssl-1.1.0c/
> dpkg-buildpackage
I'd like to provide a data point. On servers that I maintain, this is
the complete list of manually-installed packages, excluding packages
related to what the server actually _does_ -- that is, this, and
nothing else, are what I consider vital to have available on a generic
server that no one
Matthias Urlichs wrote:
I also expect the Jessie upgrade to switch to systemd. Because,
frankly and strictly IMHO, doing anything else makes no sense
whatsoever.
This is exactly the thing I don't agree with.
I think _new installs_ of Jessie should use systemd as init (by
default, anyway),
Steve Langasek wrote:
No, that's not the true package relationship. There's no reason that
you should always get this added service by default when you install
a system with non-systemd init that doesn't need logind. Making this
a recommends would be a workaround for bad metadata in the
On Fri, Sep 5, 2014 at 2:22 PM, Matthias Klumpp matth...@tenstral.net wrote:
2014-09-05 19:52 GMT+02:00 Zack Weinberg za...@panix.com:
Abstractly, I believe the ideal situation would be for all init systems in
the archive to be *completely* co-installable, with /sbin/init a symlink
under
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Mon, 01 Jul 2013 10:17:54 -0400
Source: pngcrush
Binary: pngcrush
Architecture: source amd64
Version: 1.7.65-0.1
Distribution: unstable
Urgency: low
Maintainer: Kapil Hari Paranjape ka...@debian.org
Changed-By: Zack Weinberg za
-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
If we're doing something that ultimately requires modification of
every debian/rules file *anyway*, can we please make
build-arch/build-indep mandatory targets, so that dpkg-buildpackage -B
can *finally* (eight years later!) be changed to call build-arch?
zw
not subscribed to d-devel; please cc:
Ben Pfaff wrote:
(Maybe it's time to get rid of the autoconf2.13 package
altogether, come to think of it.)
It's still needed for just about everything put out by Mozilla, alas
(iceweasel et al, obviously, but also libnspr and libnss, which are
not just used by moz.org applications). There is
-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
-deb...@nongnu.org
Changed-By: Zack Weinberg za...@panix.com
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
Changes
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
Closes
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
Closes
I looked at the page: this seems like an appropriate moment to mention
something that should be a lot more widely known than it is:
sizeof(char) == 1
sizeof(signed char) == 1
sizeof(unsigned char) == 1
Those three equalities are not part of any ABI. They are written into
the C
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
You are essentially telling gcc to pass an option to the linker without
understanding what it does, and, more specifically, an option that tells
the linker to
[EMAIL PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
Changes:
monotone (0.37-4) unstable; urgency=low
.
* debian/rules: Turn compiler optimization back on by default. Doh!
Hopefully this shrinks hppa
[EMAIL PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
[EMAIL PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system - documentation
monotone-server - A distributed version (revision) control system - server
scripts
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system
monotone-server - A distributed version (revision) control system
Closes: 434604
Changes:
monotone (0.36-1
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system
monotone-server - A distributed version (revision) control system
Closes: 432657
Changes:
monotone (0.35-2
PROTECTED]
Changed-By: Zack Weinberg [EMAIL PROTECTED]
Description:
monotone - A distributed version (revision) control system
monotone-doc - A distributed version (revision) control system
monotone-server - A distributed version (revision) control system
Closes: 415496 418213 422936 425907 427687
I'd like to see this say something about what may be assumed of the
standard shell utilities, as well as the shell itself, and in
particular I'd like to see coreutils bug #339085 addressed [please see
the bug log for my personal very strong opinion on which way it should
be addressed].
zw
--
Wouter Verhelst wrote:
[...]
When I first tried to create this setup, about a month after DebConf5
(and about around the time when I announced this), it turned out
that it was plain impossible to build a cross-compiler with the
GCC4 code; not with toolchain-source (because that had not been
Branden Robinson wrote:
No, it's a problem for programs that use cpp to parse X resource files.
In particular, I noticed that xdm broke due to a mangled
/etc/X11/xdm/Xresources file when built with cpp 3.3 instead of cpp 3.2.
I do not know enough about what X resource files are supposed to
On Fri, 10 Oct 2003 01:59:25 -0500, Branden Robinson wrote:
On Thu, Oct 09, 2003 at 08:38:17PM -0700, Zack Weinberg wrote:
My god, that was awful. They still haven't fixed cpp -traditional, as
far as I know. Grumble grumble grumble.
Bug number?
Mumble mumble mumble. Never got
My god, that was awful. They still haven't fixed cpp -traditional, as
far as I know. Grumble grumble grumble.
Bug number?
zw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 3 Sep 2002 11:51:58 -0700
Source: zangband
Binary: zangband
Architecture: source hppa
Version: 1:2.7.1-0.1
Distribution: unstable
Urgency: low
Maintainer: Eric Leblanc [EMAIL PROTECTED]
Changed-By: Zack Weinberg [EMAIL
Get a clue, Linux does not allow setuid scripts.
Irrelevant. Look up IFS in a bugtraq archive.
I shan't do your homework for you.
I did. And guess what, I didn't find one single exploit regarding this
on Linux. Interestingly, I found one exploit that relied on IFS to be set
to
reopen 95420
quit
...
On Fri, Apr 27, 2001 at 12:22:18AM -0700, Zack Weinberg wrote:
ash 0.3.8-1 incorporates changes in word splitting which break common
shell scripts, such as /usr/bin/mktexpk and the 'mklibgcc' script used
when compiling GCC.
#! /bin/ash
OIFS=$IFS
IFS
On Mon, Apr 30, 2001 at 06:34:19PM -0400, Ben Darnell wrote:
This thread is directed at the wrong bug number - the discussion is about
#95430, but the messages are going to #95420. Please adjust the recipients
appropriately in your replies.
My apologies, I mistyped the bug number.
zw
[EMAIL PROTECTED] on Tue, May 01, 2001 at 07:30:14AM +1000
# Let's try this again
reopen 95430
severity 95430 critical
retitle 95430 [SECURITY] ash honors IFS in environment
quit
On Tue, May 01, 2001 at 07:30:14AM +1000, Herbert Xu wrote:
I have consulted the Single Unix Standard and can
severity 95430 critical
quit
I can keep this up just as long as you can.
...
(tests) ... except that ash does honor IFS from the environment. You
realize that this is a gaping security hole, even if IFS is only used
to split the results of expansion? You realize that it is trivial to
On Fri, 14 May 1999 19:04:01 +0100 (BST), Julian Gilbey wrote:
On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
Glad to hear all of this. I just have one comment:
- The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them,
On Sun, 16 May 1999 21:31:14 +0100 (BST), Julian Gilbey wrote:
And having mktex{mf,tfm,pk}
writing to a scratch directory defeats the purpose of making the fonts
directory read only, as anyone could then create a corrupt font file
in the scratch directory and run mktexupd.
This is a
On Thu, 13 May 1999 15:02:40 +0100 (BST), Julian Gilbey wrote:
Glad to hear all of this. I just have one comment:
- The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them, which is unnecessary. Any
extra privileges they require will be
On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote:
[Cc'ing to -devel]
Package: tetex-base
Version: 0.9.990406-1
Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
Therefore all font generation operations get an error:
/usr/share/texmf/web2c/mktexupd:
Hi, I'm with glibc development and I need to know about how some
headers are used by user code.
Specifically, for the 2.2 release of glibc (which is at least a year
away; we're in codefreeze for 2.1 right now) we are thinking about
modifying sys/syscall.h. I would like to know:
1. What
53 matches
Mail list logo
