one of (/run /dev/shm /tmp)
What will happen on systems where users changed the configuration files
and these changes are not applied automatically?
Ansgar
@INC by default. It also wasn't seen as
a security problem when I reported it as such (or not worth fixing at
the time), but only years later when someone else reported it again. So
maybe awareness changed a bit.
But "<>" isn't the only problem, there are way too many uses of the
two-argument form of Perl's "open" too...
Ansgar
for example.
No, that already stops working when package are named differently which
is frequently the case. There is no readline-devel package in Debian
and no libreadline-dev in Red Had or Gentoo.
Also what you suggest already exists, for example in the form of
"pacapt" (but there are alternatives too!). What is the benefit of
adding yet another version of these scripts?
Ansgar
,
> which defeats my understanding of the purpose of this proposal. So, for
> example, in ls -l:
I don't think the "C.UTF-8" locale covered by any promises POSIX might
make for "C". (Nor is what happens when no LC_*, LANG vairables are
set at all.)
Ansgar
dian 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 ;-) )
Ansgar
e from jessie-security; arm64 wasn't
removed from -backports as there is no LTS for backports and jessie-
backports will eventually be archived as is.)
Ansgar
[1] https://www.debian.org/News/2018/20180623
the keys.
IMHO installing a non-Debian keyring should *not* make the keys trusted
by APT by default (i.e. with the default answer if debconf is used).
ubuntu-keyring does that; most other keyrings sadly do not follow this.
Ansgar
d environments is in contrast a fairly
friendly failure mode. So it should not be a serious bug (whether RC or
not is something for the release team).
> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.
I doubt we have, but let's ignore that.
Ansgar
ng the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.
As far as I know maintainer scripts are only required for moving files
from / to /usr when (a) a compat symlink is required, and (b) only when
both merged-/usr and non-merged-/usr is supported.
Ansgar
Guillem Jover writes:
> On Tue, 2019-02-19 at 08:54:12 +0100, Ansgar wrote:
>> Guillem Jover writes:
>> > 3) Switching packages to the merged-/usr layout could have been
>> >accomplished automatically via debhelper for a coverage of around
>> >99% (?)
kg-deb to
> convert the results to Debian packages?
How should this handle dependencies (probably named differently in
Debian) or maintainer scripts?
Tools like `alien` to convert RPM and Debian packages have similar
limitations and I don't remember them working that well.
Ansgar
ot;verifying a git
> tag".
Doesn't Git also only use hash algorithms that are no longer recommended
for cryptographic applications? Or have they finished moving to
stronger algorithms?
I don't think we should downgrade to SHA-1 for new services.
Ansgar
elease, I ideally just have
to drop the new upstream tarball, update d/changelog and am done.
Compare with [1] which is much more complicated, even ignoring the extra
complexity using dgit adds compared to just using git.
Ansgar
[1]
https://manpages.debian.org/stretch-backports/dgit/dgit-maint-merge.7.en.html#NEW_UPSTREAM_RELEASES
On Thu, 2019-05-02 at 13:45 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > On Tue, 2019-04-30 at 16:00 -0700, Sean Whitton wrote:
> > > As a package maintainer, if you don
On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> Ansgar writes:
>
> > Having to know about branches, merging, dealing with multiple remotes,
> > ... *is* an entry barrier compared to not having to know about it. Now
> > you have to teach people that before you ev
On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream moves from
> tarballs to git"):
> > On Thu, 2019-05-02 at 09:15 -0700, Russ Allbery wrote:
> > > Ansgar writes:
> > > > Having to
On Fri, 2019-05-03 at 17:39 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Preferred git branch structure when upstream
> moves from tarballs to git"):
> > On Fri, 2019-05-03 at 15:59 +0100, Ian Jackson wrote:
> > > Ansgar writes ("Re: Preferred git branch stru
aging information), and possibly other directories below base for
build artifacts (instead of unpredictable locations under base/debian).
Which leads back to the beginning of the subthread[1].
[1] https://lists.debian.org/debian-devel/2019/04/msg00462.html
Ansgar
On Tue, 2019-05-07 at 12:51 +0100, Ian Jackson wrote:
> Ansgar Burchardt writes ("Re: Preferred git branch structure when
> upstream moves from tarballs to git"):
> > Sam Hartman writes:
> > > OK, I didn't hear that as an answer but think I'm coming to the
the chance to move away
from tar?
We have various applications that only want to extract single members of
the package (changelog, NEWS, copyright, ...); tar is a really bad
format for such an operation. Other formats (zip, 7z, ...) are more
suited for them.
Ansgar
Jeremy Stanley writes:
> On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote:
>> Switching to a different binary format will break various tools. If we
>> want to do this, I wonder if we shouldn't take the chance to move away
>> from tar?
>>
>> We have
Adam Borowski writes:
> On Wed, May 08, 2019 at 10:35:58PM +0200, Ansgar wrote:
>> Adam Borowski writes:
>> > I've recently did some research on how can we improve the speed of
>> > unpacking
>> > packages. There's a lot of other stages that can b
ished is what is the actual preferred form of
modification (as it is what the maintainer uses), but if so desired one
can still get a "dgit view". (Though for contributing changes to the
maintainer, one should probably base them on the maintainer view...)
In this case the published history also matches the "git histories we
are actually using ourselves", a design goal not met currently; one
could also apply the mangling feature to repositories not published on
the dgit server.
Ansgar
atible change, it is an appropriate time to bundle any other
incompatible changes (if there are any). That is why I suggested that
it might be useful to also replace the `tar` archives with another
format.
Ansgar
n just seek from
one header to the next and only need to do so few times).
Ansgar
archive; though for 7z one would
need to check if it does the right thing first...
Ansgar
[1] https://en.wikipedia.org/wiki/Solid_compression
Adam Borowski writes:
> On Mon, May 13, 2019 at 11:25:11AM +0200, Ansgar wrote:
>> It supports solid compression[1] which
>> compresses multiple files into one block like tar.xz, but unlike tar.xz
>> can use more than one block: "Later versions of 7-zip use a variable
&g
mething Debian
would probably not like that much...)
Ansgar
asons.
>
> Use the $300,000 on our bank accounts?
I heard that this didn't work out well the last time ("dunc tank"),
though that was before the time I followed Debian development.
Ansgar
esterday. The move should be completed with this.
Ansgar
uot;bionic" instead of just writing the version in
sources.list is annoying (I always have to look up the codename to be
sure as I don't use Ubuntu that much).
Ansgar
. Also, parental
| monitoring and guidance can reduce likehood of teens breaking such
| systems. Maybe because teens are largest marketshare for TVs.
Ansgar
- rating "kill -KILL" X-rated for extreme violence
On Tue, 2019-06-25 at 16:39 +0800, Paul Wise wrote:
> On Tue, Jun 25, 2019 at 2:08 PM Ansgar wrote:
> > what do people think about getting rid of current suite names ("stable",
> > "testing", "unstable") for most purposes? We already recommend usin
Sean Whitton writes:
> On Fri 12 Jul 2019 at 02:06PM +02, Ansgar wrote:
>> Depends on a lot of things. As far as I understand this work is in a
>> very early stage and a first brainstorming session on what problem this
>> is intended to solve, why one should consider d
it so far, but at least "whalebuilder" exists.
The gitlab-ci used on salsa.d.o also uses Docker containers; people also
build packages using this (mostly for testing though, see for example [1]).
Ansgar
[1] https://salsa.debian.org/salsa-ci-team/pipeline
x27;t rely on a third-party service for this.
(In particular the service in question here doesn't do that as far as
I can tell.)
Ansgar
ght make things a bit easier for Hurd/kFreeBSD, but
it's not an absolute requirement for such a port to exist.
Ansgar
s is
not future-proof (and hasn't been for a while); even phones have started
to move to 64bit systems a while ago.
Ansgar
file.
I think a name without abbreviations like "no-installed-tests" is
better. While it is clear what the name means for people working with
build profiles all the time, a more expressive name might be easier on
people only dealing with them occasionally.
Ansgar
balls are probably also the easiest way for upstream to
provide a signed version of their software which we have tried to
encourage (for example by including such signatures in Debian's
archive).
Ansgar
isions
might need to be sneaked in there to get included in release tarballs[1].
Ansgar
[1]
https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/
ion
| (e.g. merge-request or mail) is expected.
+---[
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
]
Ansgar
use that.
(Using dgit to upload packages is sadly incompatible with best
practices around packaging.)
Ansgar
emented.
It's probably easier to use DNSSEC with DoH as you avoid broken
resolvers at ISP or customer routers that don't speak DNSSEC or not even
proper DNS. I've encountered customer routers that knew only about `A`
RRs and lied about `PTR` which breaks stuff in interesting ways...
Ansgar
Anthony DeRobertis writes:
> On 9/12/19 8:57 AM, Ansgar wrote:
>> I don't see much value in this requirement (besides additional work).
>> One should look at the repository anyway whan planning to do changes
>> (to match the existing style used); one would naturally see
On Mon, 2023-03-27 at 00:40 +0200, Ansgar wrote:
> the stretch, stretch-debug and stretch-proposed-updates suites have now
> also been imported on archive.debian.org. People still interested in
> these should update their sources.list.
>
> I plan to remove the suites from the
le.
Not handling diversions can lead to files disappearing, data loss or
other breakage, but it's very rare a package considers this.
Ansgar
limited... Alternatively forbid *all* changes that would
require this, i.e., require stable interfaces. However we do not do
this.)
But for all these issues we just say "meh, you are out of luck".
Ansgar
On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > Debian's dependency system requires to explicitly declare
> > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we
> > cannot do
> > that for pac
Hi Russ,
On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
> Ansgar writes:
> > As far as I understand, we do explicitly *not* care about our
> > derivatives with regard to merged-/usr as some packages in Debian
> > recommend users to move *away* from merged-
Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton
, Helmut Grohne , Luca Boccassi
, debian-d...@lists.debian.org, debian-devel@lists.debian.org
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote:
> On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> >
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
>
it
could be dropped in other places (CONTROL in .deb and Packages indices)
as well.
Regards,
Ansgar
PS: Please note the following disclaimer: I might or might not be payed
for this change and refuse to disclose financial incentives or other
conflicts of interest; I might or might not suggest
i386 and no longer provide installation media for i386.
|
| We recommend hosts still running the i386 port to be upgraded
| to amd64. Legacy i386 software can be run using multi-arch,
| chroot environments or containers.
+---
Ansgar
keep generating i386 install
media.
> Not a major thing, but if you're going to keep most of i386 anyway...
I would hope we could eventually drop some expensive, useless packages
from i386 like src:linux.
Ansgar
is the bias of systems having popcon enabled at
all (it seems to be mostly desktop systems) and how it looks on the
total population.
Ansgar
cases for old i386 hardware.
I don't think that is a good use case to keep i386 installations on
i386 hardware alive beyond 2028 (which is what we are talking about):
just grab a slightly newer amd64 netbook out of the junk by the time
LTS support for Debian bookworm ends.
Ansgar
Hi Russ,
On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
>
s might result in non-booting systems.
That is what we sign up to accept by having the warning in dpkg.
Ansgar
c569c0080e92d057b
| ld.so: Do not export free/calloc/malloc/realloc functions [BZ #25486]
+---
Which is an incompatible ABI change.
Ansgar
i386 on
https://release.debian.org/testing/arch_qualify.html
I would not be surprised if we consider dropping leaf software where
builds start to hit the address space limit (I expect browsers & such).
Plus the broken FPU implementation as we don't require SSE.
And it *is* our choice to make to not spend time on dead architectures.
Ansgar
[1]: It also works for other carbon emissions!
y is available from
https://defi.43-1.org/defibrillator-test-key.asc
Ansgar
p environments and I
personally like systemd-networkd for other environments. In both cases
these replace both ifupdown and isc-dhcp-client.
I also think that installing both ifupdown and NetworkManager on
desktop environments is worse than only NM.
Ansgar
also
include a subset of desktop computers, but I think the better default
is still NM and it is up to the administrator to configure an
alternative.
Ansgar
h, for example, systemd-shim which was
promised to get maintained and timely updated...
Less prone to errors than a manual process might be to watch
automatically where legacy startup scripts disappear anyway; it's not
that complicated to do. People tend to forget things.
Ansgar
sider removing sysvinit and init scripts from
Debian. The non-technical cost of having them is too high.
Ansgar
warnings in dpkg or for other
reasons), it's their own problem...
Ansgar
On Fri, 2023-06-30 at 11:10 +0100, Sean Whitton wrote:
> On Wed 28 Jun 2023 at 06:20PM +02, Ansgar wrote:
>
> > On Thu, 2023-06-29 at 00:32 +0900, Simon Richter wrote:
> > > According to Policy as currently published, systemd units are
> > > encouraged,
d to write in the helpful style the mail I
replied to uses. I skipped stating {sysvinit,dpkg} proponents haven't
done their homework, using {sysvinit,dpkg} incurs technical debt, they
failed us as community projects, it's impossible to onboard people to
them[1], and possibly some other mi
should just be extended to include
"__pycache__" as well and these would be non-issues.
Ansgar
y
made up guess and one could just as well claim that those are the least
valuable 0.61%?
Ansgar
Please consider to just use openssl everywhere or also explicitly
disable/enable build options per arch. (Personally I would in this case
probably just enable openssl everywhere and recommend people to improve
openssl in case it is slower than the built-in implementation; openssl
is probably use widely enough to warrant that.)
Ansgar
2:1, but I don't think there is a reason for it to be higher than a
simple majority.
Should we look at changing these?
Ansgar
t; /etc/alternatives/editor -> /usr/local/bin/emacs
Users should just set the VISUAL environment variable.
Alternatives are the wrong tool to set user preferences as they can
only be set globally and only by root.
(editor-is-emacs has the same problem of course...)
Ansgar
iew is requested here, too.
Is there any reason to not just use systemd-cryptenroll?
It seems to be a more featureful implementation and also doesn't
require storing PINs in plain text in configuration files like
/etc/cryptsetup/2fa/2fa.conf as README instructs users to do here.
Nor does it st
openai-thing" package to
the general public?
Ansgar
On Fri, 2024-01-05 at 08:50 -0500, Mo Zhou wrote:
>
> On 1/5/24 03:48, Ansgar wrote:
> > On Thu, 2024-01-04 at 21:30 -0500, Mo Zhou wrote:
> > > Dependency of DebGPT. Will be maintained by deep learning team.
> > > It will go to the contrib section based on polic
s (DBus services, DBus
itself, daemons, ...).
A quick poll on IRC in #-devel seemed to show a majority of people who
responded agreeing with this.
(This does not have to apply to libnss-* or libpam-* which are not
actually libraries, but plugins.)
Ansgar
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.
Ansgar
s fine.
Otherwise provider and consumer would disagree about ABI and likely not
work fully correct.
> But fundamentally, how do we know how third-party binaries are
> compiled ?
They have to use `dpkg-buildflags` with equivalent ABI settings.
Ansgar
): make it mandatory to migrate old systems to
merged-/usr on upgrade. Possibly by allowing the existing usrmerge
program to run from the initramfs.
- For Debian 13 (trixie): packages should no longer install to /bin,
/sbin, /lib, but to the respective locations under /usr.
Ansgar
[1
On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > I would like to propose to plan to move to support merged-usr-only over
> > the following releases. The motivation is bugs like [1] where upstream
> > deve
On Fri, 2020-11-20 at 11:12 +0100, Ansgar wrote:
> On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > So let's make it so a canonical path to a file never includes a directory
> > symlink; if you insist on /usr/bin/rm then /bin/rm should be
> > /bin/{rm->/u
ay and no migration would be needed, i.e., like the i386 -> amd64
cross-upgrade nobody really worries about any more.)
Ansgar
[1]: https://lists.debian.org/debian-devel/2018/11/msg00354.html
[2]: cf. OpenSuSE or suggestions to never do that and instead wait
until nobody uses /bi
On Sat, 2020-11-21 at 11:07 +, Paul Wise wrote:
> On Sat, Nov 21, 2020 at 10:33 AM Ansgar wrote:
>
> > The goal is to have /bin and /usr/bin to have identical contents.
> > So one would need a new /bin/python3 -> /usr/bin/python3 symlinks
>
> Those seem unnecessary
equested Release.gpg/InRelease files
would be needed. The service could run independent from snapshot.d.o
and redirect most requests there.
Maybe the same could be done for archive.d.o?
I might be interested to experiment with this as it seems reasonably
small project to implement. :-)
Ansgar
On Fri, 2020-12-18 at 01:15 +, Paul Wise wrote:
> On Thu, Dec 17, 2020 at 10:03 AM Ansgar wrote:
> > (Bonus points if this keeps the original signature if
> > possible.)
>
> Two separate signatures is possible for Release+Release.gpg, just
> rename the latter to .
h for legacy installations for a move to merged-usr-only
to be implemented. This also isn't relevant for Debian 11 (bullseye),
but I would like to have enough time in the Debian 12 (bookworm)
cycle.
Ansgar
[1]: https://lists.debian.org/debian-devel/2020/11/#00232
continued in Decem
sions in addition
to systemd and usrmerge nor for spending much time on implementing
more support for (mostly?) non-free stuff I left things as they are.
(Nor would I be too motivated to then read "but it's wrong" for many
years later as with the other topics...)
Ansgar
[1]:
https
"We encourage CD manufacturers to read
the licenses of the packages in these areas [non-free & contrib] and
determine if they can distribute the packages on their CDs." Maybe we
should do that for the CD images we manufacture? :)
Ansgar
oller: Intel Corporation Wireless 8265 / 8275
>> - https://packages.debian.org/bullseye/firmware-iwlwifi
iwlwifi does work fine with just free software just like hard disks and
similar?
Ansgar
service manager, i.e. the user's instance of
| user@.service.
+---[ man:systemd.exec(5) ]
So changing this limit for user sessions is currently out-of-scope for
systemd and handled by pam_limits on Debian (or whatever else).
Ansgar
what pam_limits does: even when an admin
*explicitly* configures lower limits for user session, these limits
*shouldn't* be applied to system services that just happen to be
(re)started in a user session.
Ansgar
mits from pid 1 in the absence of
> explicit configuration is hacky but good enough for the other init
> systems.
And neither this as then we wouldn't have gotten this thread at all
which is about those defaults being too low for some applications.
Ansgar
sly) and single-user systems where suddenly even the
"nobody" user has access to lots of interesting files...
Ansgar
On Wed, 2021-02-10 at 13:38 +0100, Adam Borowski wrote:
> Define "proper Unix"...
A system including Emacs. So we would need emacs at Priority: standard
or even important or required :]
Ansgar
uldn't be used to make new signatures.
How would you know that the signature was made before the key expired?
Other systems (e.g. signed executables on Windows) have a trusted third
party sign the timestamp for that, but OpenPGP doesn't do so.
Ansgar
Hi Steve,
On Tue, 2021-04-06 at 11:15 -0700, Steve Langasek wrote:
> the rules of civilized discourse do not apply when dealing with
> individuals who are external to your civilization.
Please take your imperialist ideology elsewhere.
Thanks,
Ansgar
list?
Either it's acceptable or it's not acceptable, both as a private and
public reply.
Ansgar
on the decision is
| made or whether the implementation of the original decision will be
| delayed until then.
+---[ Debian Constitution, 4.2.2.4 ]
Which leaves open quite a bit, e.g, how long would the voting period for
the immediate vote be? The regular voting period is two weeks after
all...
Ansgar
1 - 100 of 556 matches
Mail list logo
