n /dev/shm /tmp)
What will happen on systems where users changed the configuration files
and these changes are not applied automatically?
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% (?)
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
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
essie-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
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
,
> 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
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
ample.
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
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
yesterday. The move should be completed with this.
Ansgar
ng Debian
would probably not like that much...)
Ansgar
reasons.
>
> 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
t;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
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
. 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
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
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 be improved
tual 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
n just seek from
one header to the next and only need to do so few times).
Ansgar
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 variab
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 va
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
ve
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
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
> >
ifying 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
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
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:
> > > > Havi
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
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
n't been for a while); even phones have started
to move to 64bit systems a while ago.
Ansgar
o 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
ng dgit to upload packages is sadly incompatible with best
practices around packaging.)
Ansgar
bly 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 how f
(e.g. merge-request or mail) is expected.
+---[
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
]
Ansgar
ed 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/
ofile.
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
shouldn'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
ake things a bit easier for Hurd/kFreeBSD, but
it's not an absolute requirement for such a port to exist.
Ansgar
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
language, domain) and consider
following whatever they do" to make it easier to interact with these
people when asking for advice or so.
Ansgar
ty updates for
> them, or will we shunt these users onto a "rolling release" track, and if
> yes, who manages that track?
Currently the systemd maintainers also maintain a backport for systemd.
Ansgar
Package: ftp.debian.org
Hideki Yamane writes:
> firefox-esr package doesn't migrate to testing but I cannot
> find the reason at https://qa.debian.org/excuses.php?package=firefox-esr
I believe we should remove firefox-esr/armel to allow the current
version to migrate to testing.
Ansgar
inally preparing.
I'm not sure what that has to do with Debian supporting multiple init
systems? Nobody is suggesting to not package software that doesn't need
tight integration with systemd; most software probably won't.
Ansgar
esides that, from earlier communication from the 2000 active developers
of the Devuan distribution, they were planning to stop importing updates
from Debian anyway.
Ansgar
nt in the archive.
As far as I know Python also byte-compiles modules in postinst, so such
a dependency might be required for that alone. Though that tests if the
`py3compile` program (or similar) is actually installed.
Ansgar
erimental and/or only available via
experimental.
But for packages like firefox, users should really get updates by
default.
Unstable is arguably also easier to use than experimental (no extra
source entries, no pinning, ...). I believe binNMUs are also mostly
only scheduled for packages in unstable.
Ansgar
the new branch to be a descendant by "fake"
merges, but that is not a good idea for various reasons: it creates an
incorrect history and confuses tools that now think commits were
applies when they really were not.)
Ansgar
matter
if you can sign the kernel or any module run in the same context as the
kernel.
Ansgar
Guillem Jover writes:
> On Wed, 2019-10-23 at 08:32:11 +0200, Ansgar wrote:
>> the thread about naming (source) packages reminded me of an other thing:
>> Debian's bug tracking system currently (mostly) tracks bugs against
>> binary packages and (less often) against source p
Sune Vuorela writes:
> On 2019-10-23, Ansgar wrote:
>> So I'm wondering if we should start just filing all bug reports against
>> source packages? Reportbug could probably be easily changed to use
>> `Source: ...` instead of `Package: ...`; more places could follow lat
by their archive management
system.
As far as I understand git-archive is fairly good as reproducing
identical uncompressed tarballs at a later time from the git repository.
Ansgar
urce: ...` instead of `Package: ...`; more places could follow later.
Ansgar
ifficult because it's
> more featureful.
There is already an alternative implementation for tmpfiles.d:
https://github.com/OpenRC/opentmpfiles
I don't know more than that it exists though.
Ansgar
> migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ +
> signed-by. Right now it ships keyrings in both places.
I would recommend against doing this as long as sources.list is a
configuration file: it would need regular updates to change to the new
signing key. That doesn't work out of the box.
Ansgar
start to pull in systemd,
even though one might not use it to start the service.
I think this is not a good idea.
> - apt being able to blacklist packages and hide packages that depend on
>those
Implicitly hiding some packages seems very confusing.
Ansgar
ely possible that the answer to question
>1 is "yes" but the answer to this question is still "no."
I don't really believe writing init systems is Debian's goal, just like
implementing our own X server or other stuff.
That other implementations that use systemd's unit files might be
useful, but so far no other implementation has come into existence for
years.
Ansgar
Thomas Goirand writes:
> Do you already have a list of affected package?
A list of affected packages was attached to the mail.
Ansgar
her packages anyway...
I have no problem installing a different MTA than Debian's default
(exim), my preferred shell, my preferred editor and so on either.
Ansgar
ly more
server installations than desktop ones.
So popcon might overestimate sysvinit usage and it might in reality be
lower over the total installation base.
Ansgar
Russ Allbery writes:
> 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
>> emb
it yet.
I think a `--facility` option should be fairly easy to implement. Just
adapt some code from the existing `--identifier` and `--priority`
options, there is already a method to translate facility names to
numbers (see calls to `log_facility_unshifted_from_string`).
Ansgar
[1]: https://gith
, i386 are distict architectures
after all. So an incompatible newglibc-linux-i386 would be different
from i386 as well?
Ansgar
ment. Just
> > adapt some code from the existing `--identifier` and `--priority`
> > options, there is already a method to translate facility names to
> > numbers (see calls to `log_facility_unshifted_from_string`).
> >
> > Ansgar
> >
> > [1]: https:/
ntexts for a long time and there it might be easier to just
change the ABI, but for a general-purpose distribution we start seeing
more and more problems and I don't really see us supporting them as a
full architecture in 10+ years.
Ansgar
On Wed, 2020-02-05 at 09:55 -0500, Sam Hartman wrote:
> > > > > > "Ansgar" == Ansgar writes:
>
> Ansgar> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
> >> Steve, you're presuming that we would not create a new soname
> for
&g
stop shipping files in `/bin`, then a package
could just ship the `bin -> usr/bin` symlinks.
Ansgar
signature.asc
Description: This is a digitally signed message part
is
also the risk to get stuck in that state. AFAIR this might be the case
with OpenSuSE (not sure, I think that was their state some time ago at
least).
Ansgar
here was consensus that the (singular) approach is the right way.
I would recommend *not* following it given it wasn't successful for
other distributions.
The largest blocker for doing anything is that Debian hasn't agreed on
making merged-/usr mandatory anyway.
Ansgar
default.
I don't understand how this can work unless time_t is *never* exposed by
any library other than libc.
Ansgar
Upgraded systems that have rsyslog installed won't get a persistent
journal this way.
The downside is that magic like this might not be easily discoverable
and confuse people who for some reason want a persistent journal and
syslog.
Ansgar
ing ABI might thus be acceptable there.
i386 seems different. I think option C above would be the only
realistic proposal so far to fix the time_t problem for (parts of) i386,
but if glibc upstream doesn't want to expose two interfaces then i386
will probably just break.
Ansgar
spend effort on this.
Ansgar
your system to become totally
broken and you may not even be able to use dpkg to put things back, so
only do so if you know what you are doing."
"Essential" packages just have additional requirements (in particular
essential packages must work even in the "unpacked" state).
Ansgar
on there is /bin/bash and /usr/bin/bash probably?
Ansgar
ternatively the upstream repository without the Debian packaging bits
can be found at [1] (might be a mirror, not sure).
Ansgar
[1]: https://github.com/OpenRC/opentmpfiles
ebian choose to use tmpfiles for more generic purposes.
> this does not entirely
> obviate my concerns related to needing to have systemd-the-package's
> daemons present in order to gain access to these facilities.
I'm happy to have helped overcome these concerns.
Ansgar
unbreak a minimal system...
A regular user shouldn't have to deal with a minimal system, but should
have a less minimal editor installed or use a rescue system.
Ansgar
wouldn't want to tightly trim all packages. Unlike minbase or
> prio:important, your average 5GB install doesn't care about a few megs
> here and there. Thus: do we want to trim manually or globally?
Special cases for packages are annoying, so I would just apply the same
policy for all packages (by default).
Ansgar
like for
native systemd services.
> B) Can systemctl mask be run on a subdirectory that you are about to
> chroot into, but have not yet done so?
I would expect something like `systemctl --root=/chroot mask
${something}.service` to work. If it doesn't work, that's probably a
bug.
Ansgar
nal features.
Or have debootstrap not install any editor. But if I remember correctly
that idea wasn't popular.
Ansgar
counter-productive to have such a requirement as it only would
mean more people have to use contrib/non-free.
Ansgar
On Wed, 2020-08-19 at 10:15 -0700, Sean Whitton wrote:
> On Fri 14 Aug 2020 at 09:04AM +02, Ansgar wrote:
> > There are also other issues such as the system seeming to accepting
> > uploads from known-compromised keys last I looked at it, though
> > maybe security expe
efore, for example to clear the dmesg buffer:
$ dmesg --clear
works after adding `cap_syslog` to the dmesg binary whereas it did not
work before.
Ansgar
this for shipping source for the program
(firefox_X.orig.tar) and translations (firefox_X-l10n-*.tar).
Ansgar (not having looked into this issue before)
did in fact use a master/slave metaphor [1].
> [1] https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html
You might be interested in [2] as well. Speculation is often wrong.
[2]:
https://mail.gnome.org/archives/desktop-devel-list/2020-June/msg00023.html
Ansgar
n is sound and deploying the system can
> and should go ahead, but we could not overcome the disagreement.
There are also other issues such as the system seeming to accepting
uploads from known-compromised keys last I looked at it, though maybe
security experts disagree how much of an issue this is in practice.
Ansgar
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 December: https
d 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 /bin/sh
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
ted 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 .
): 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->/usr/bi
1 - 100 of 1856 matches
Mail list logo
