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 disappear
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 be
>>>>>> "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> pac
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 configu
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 ma
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 el
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 NEWS
> 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 r
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 -rfa
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 logs
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),
On Fri, Sep 5, 2014 at 2:22 PM, Matthias Klumpp wrote:
> 2014-09-05 19:52 GMT+02:00 Zack Weinberg :
>> 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 control
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
libpam
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
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 standard,
> 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 link
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
--
To
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 t
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.
> &
> My god, that was awful. They still haven't fixed cpp -traditional, as
> far as I know. Grumble grumble grumble.
Bug number?
zw
> > > 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
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 t
[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 f
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
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 compili
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 mktexup
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
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 requ
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/mk
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 packages
37 matches
Mail list logo