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
(language, domain) and consider
following whatever they do" to make it easier to interact with these
people when asking for advice or so.
Ansgar
nged to use
`Source: ...` instead of `Package: ...`; more places could follow later.
Ansgar
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
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 sou
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 follo
ss possible as
everything shipping any systemd service will 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
t; then this question
>doesn't arise. But it's entirely 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
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
even marginally 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
difficult 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
could
> 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
an we provide security 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
It shouldn't matter
if you can sign the kernel or any module run in the same context as the
kernel.
Ansgar
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
perimental 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
t; pretty consistent 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
Thomas Goirand writes:
> Do you already have a list of affected package?
A list of affected packages was attached to the mail.
Ansgar
e reason there is /bin/bash and /usr/bin/bash probably?
Ansgar
.)
Alternatively 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
hould Debian 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
nd effort on this.
Ansgar
ckage may cause 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
ontexts 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
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
>> embedde
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
-linux-i386, 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:/
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
> f
n I already have to install other 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
d expect significantly 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
age (install, remove, update)
packages, then I believe PackageKit[1] tries to offer this.
Ansgar
[1]: https://www.freedesktop.org/software/PackageKit/
ransitions should be coordinated).
Upload processing on the security archive will also be ⏸d tomorrow
morning.
Ansgar
ld suggest [1]. But be
careful as [1] itself is non-free (licensed as CC-ND).
Ansgar
[1]: https://www.gnu.org/distros/free-distros.html
APT is not the only way to download packages: often enough users (and
developers) will ignore apt, download packages manually for various
reasons, *not* do the integrity checks apt does and install them.
Using https:// URLs for mirrors wherever possible makes this a bit less
bad.
Ansgar
should not support.
Ansgar
rs is insignificant and can be totally ignored feels rather far
fetched just to support an outcome you want to see true. We would have
much, much larger problems for the future of Debian and Debian-based
distributions than merged-/usr if this was true. So if you have any
support for this claim, I'm interested in seeing it.
Ansgar
Hi,
On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote:
> * Ansgar [210822 05:08]:
> > To get a filesystem layout equivalent to merged-/usr via symlinks
> > farming *every* package shipping files in at least /usr/bin,
> > /usr/sbin
> > and possibly some of /us
maken your point. It clutters the discussion with needless
> debunking.
I think you misunderstand how the partially-symlink-farmed-root
proposal is different from the merged-/usr proposal. Exactly to avoid
such misunderstandings the partially-symlink-farmed-root proposal
should not be named merged-/usr.
Ansgar
nstable:
lib/systemd/system/ifup@.service: root=admin/ifupdown2 usr=admin/ifupdown
lib/systemd/system/networking.service: root=admin/ifupdown2 usr=admin/ifupdown
Ansgar
> Caching packages and transport level encryption are fundamentally
> incompatible.
No. You can explicitly configure apt to use a local caching mirror or
use a trusted TLS certificate for the mirror the proxy impersonates.
Ansgar
acing deb.d.o by a non-CDN feasible? If no, what does use of
https change?
As far as I know there is also at least https://cdn-aws.deb.debian.org/
if you don't like Fastly.
Ansgar
, but not other packages, that
> mechanism doesn't exist yet.
If a CA is untrustworthy, I don't think we would only want to detrust
it for apt's https method. So I see no problem.
>
> It's not about what I like, but on what external services we want to
> depend.
So your concern is about Debian providing the deb.debian.org service at
all? That seems unrelated to the https or not question.
Ansgar
that one size
> does not fit everyone. Either way makes some people unhappy.
Maybe we should just find out who is responsible for this decision and
reassign the bug to them. The installer team maintaining d-i and
debootstrap or the mirror team seem reasonable choices?
Ansgar
On Wed, 2021-09-08 at 13:53 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 01:37:37PM +0200, Ansgar wrote:
> > Maybe we should just find out who is responsible for this decision
> > and
> > reassign the bug to them. The installer team maintaining d-i and
> > deb
ey in the Certificate suffered a Key
| Compromise
+---[ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.0.pdf ]
So that would not be helpful.
Ansgar
On Wed, 2021-09-08 at 15:41 +0200, Helmut Grohne wrote:
> On Wed, Sep 08, 2021 at 02:01:03PM +0200, Ansgar wrote:
> > So what do you suggest then? Tech-ctte as with merged-/usr? Or a
> > GR? Or
> > something else?
>
> I propose that the proponents pay the cost. In this
ckages. (And I'm not sure debootstrap even checks
Valid-Until.)
Ansgar
uld *not* edit .changes files manually as it is too
easy to refer to the wrong files, e.g., a different .orig tarball than
was used to build the package. I suspect someone did manually edit the
file here.
Ansgar
em to keep
adding TLS support to more and more libraries, so such a dependency can
just silently appear later.
Python programs using OpenSSL also usually don't have such an exception.
🐾,
Ansgar
behavior
of contributors. Please see https://www.debian.org/code_of_conduct
Ansgar
place to one where it has.
Why do you claim that?
Given packages already did such moves in the last years and you claim
this happens in a non-negligible number of cases, could you please
point to some examples where this already happens in practice?
Ansgar
ettings in /etc/dpkg/origins/debian, the version in
/etc/debian_version and so on.)
Ansgar
| source, amd64,
arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x
+---
So this would just be "Depends: valgrind" on all architetures?
Ansgar
thout
fallback (which as far as I understand some software already does on
i386 or would like to do) or dropping support for AMD Geode processors.
Ansgar
[1]:
https://salsa.debian.org/release-team/release.debian.org/-/blob/bb0660c80401eeacbe7063044a9a1b711dcc2303/www/bookworm/arch_spec.yaml#L108
1 - 100 of 541 matches
Mail list logo
