Content-Type: text/plain
debian-devel-digest Digest Volume 2023 : Issue 271
Today's Topics:
Re: Proposed MBF: Removal of libfree [ Hugh McMaster <hugh.mcmaster@outloo ]
Bug#1041318: ITP: rust-json-event-pa [ Jonas Smedegaard <dr@jones.dk> ]
Re: Proposed MBF: Removal of libfree [ Hugh McMaster <hugh.mcmaster@outloo ]
Re: usertagging file conflicts [Was: [ Ralf Treinen <treinen@debian.org> ]
Re: usertagging file conflicts [Was: [ Paul Wise <pabs@debian.org> ]
The future of mipsel port [ YunQiang Su <syq@debian.org> ]
Re: systemd-analyze security as a re [ "Trent W. Buck" <trentbuck@gmail.co ]
Re: The future of mipsel port [ Matthew Garrett <mjg59@srcf.ucam.or ]
Bug#1041417: ITP: rust-regalloc2 -- [ Jonas Smedegaard <dr@jones.dk> ]
Date: Mon, 17 Jul 2023 21:45:13 +1000
From: Hugh McMaster <hugh.mcmaster@outlook.com>
To: Simon McVittie <smcv@debian.org>
Cc: debian-devel@lists.debian.org
Subject: Re: Proposed MBF: Removal of libfreetype6-dev
Message-ID:
<[🔎] SY6P282MB3236A4620329B1388FA28A6FF23BA@SY6P282MB3236.AUSP282.PROD.OUTLOOK.COM" target="_blank">[🔎] SY6P282MB3236A4620329B1388FA28A6FF23BA@SY6P282MB3236.AUSP282.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"
Hi Simon,
On Mon, 17 Jul 2023 at 00:07, Simon McVittie wrote:
>
> On Sun, 16 Jul 2023 at 22:38:20 +1000, Hugh McMaster wrote:
> > Currently, there are 219 build-dependencies and 29 (direct)
> > dependencies on libfreetype6-dev, which has been released with
> > bullseye and bookworm.
>
> Lintian diagnoses this as "[build-]depends-on-obsolete-package" since
> 2.116.0 (MR at [1], instances of the relevant tags listed at [2] and
> [3]) which will hopefully help progress towards dropping the transitional
> package.
Thanks for pointing this out. I wasn't aware Lintian had started
flagging dependencies on obsolete packages some 10 months ago.
Having Lintian issue a warning or error instead of bug filing is preferable.
> [1] https://salsa.debian.org/lintian/lintian/-/merge_requests/417
> (partially reverted in
> https://salsa.debian.org/lintian/lintian/-/merge_requests/452 but the
> freetype part remains)
> [2] https://udd.debian.org/lintian-tag.cgi?tag=build-depends-on-obsolete-package
> [3] https://udd.debian.org/lintian-tag.cgi?tag=depends-on-obsolete-package
>
> Unfortunately lintian.debian.org is not currently updating, so please
> don't use that as a source.
Date: Mon, 17 Jul 2023 14:06:35 +0200
From: Jonas Smedegaard <dr@jones.dk>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#1041318: ITP: rust-json-event-parser -- JSON event parser and serializer
Message-ID: <[🔎] 168959559567.3829237.16286019313710125242.reportbug@auryn.jones.dk" target="_blank">[🔎] 168959559567.3829237.16286019313710125242.reportbug@auryn.jones.dk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard <dr@jones.dk>
X-Debbugs-Cc: debian-devel@lists.debian.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
* Package name : rust-json-event-parser
Version : 0.1.1
Upstream Contact: Tpt <thomas@pellissier-tanon.fr>
* URL : https://github.com/oxigraph/json-event-parser
* License : Apache-2.0 or Expat
Programming Lang: Rust
Description : JSON event parser and serializer
JSON event parser
is a simple streaming JSON parser and serializer implementation in Rust.
.
It does not aim
to be the fastest or the more versatile JSON parser possible
but to be an as simple as possible implementation.
This package is needed for oxigraph (bug#996504).
It will be maintained in the collaborative debian section of salsa, at
https://salsa.debian.org/debian/rust-json-event-parser
- Jonas
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS1LsgACgkQLHwxRsGg
ASGuZxAAnGaRse4xNrc1A8yia/ZGZPbilR93QiVzblYfKtAvPp7sMUkpvjPhkdP6
EEXdvcHUP72p/yQj6wmRzptLtDxNd6/K4V0DQpZj1wA11i3BJHiiX4udVqqBQlvQ
FpCgMw28c4VzYW84JGAYEb7Dqsd85U8rZLdpSmaZ+eAIzeRAjfoldLKn7wfoxZKk
iB/veI19T/oAHyRYnG1ptukLBexUvjxQxZczhr1/6e5Njk0glY1/oNLQ7ewv7NGS
1Pcislx9jEsxPmtxGEzBifoV/H+2lYvir3HqNEx6pWF4BqiUEFDTfaRPUiQ/PsTQ
azbJNcZzSiRLKFw6dZzXqnAZgQCgicO4a8GEoBNDaRWlbe7PL9BidfshcOnKXX/i
4x943xCCOhXSGCTrbIW2nwM8etz9QRXn7zmqHjCAH2arFPjRCv3E4dABhO1J/lP/
sNnMwKNtljuAG++ucBkXaN0JYV4JSQGRoCocegDbjYQBOsDG7ARgEJyJBdPbBoIH
PF6HVgWCCvhJ9V8sEFy2/aY26ycfUzwKst7Qz80V35A3wyZMTrHQHs0A+dAVRhU1
foxNCFRhUdO/4HDB7opVfyZ7hOuagRiv0ccxa/jKzMtduh6JMYQf291NyN08valq
yMTE83L5588OnZv/Z+AcRZQbtPOQZqyrqEEBtFTyo9qCUjtbUrk=
=oDlV
-----END PGP SIGNATURE-----
Date: Mon, 17 Jul 2023 21:55:33 +1000
From: Hugh McMaster <hugh.mcmaster@outlook.com>
To: Sven Joachim <svenjoac@gmx.de>
Cc: debian-devel@lists.debian.org
Subject: Re: Proposed MBF: Removal of libfreetype6-dev
Message-ID:
<[🔎] SY6P282MB3236611881C1FEC58F7F47B4F23BA@SY6P282MB3236.AUSP282.PROD.OUTLOOK.COM" target="_blank">[🔎] SY6P282MB3236611881C1FEC58F7F47B4F23BA@SY6P282MB3236.AUSP282.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="UTF-8"
Hi Sven,
On Mon, 17 Jul 2023 at 01:13, Sven Joachim wrote:
>
> On 2023-07-16 22:38 +1000, Hugh McMaster wrote:
>
> > I will be removing the transitional package libfreetype6-dev (from the
> > source package freetype) later this year.
> >
> > [snip]
>
> My suggestion is to drop the libfreetype6-dev package immediately and
> not waste your and other people's time with mass-bug filing, because
> libfreetype-dev already has a versioned Provides on libfreetype6-dev.
> This is what I did with three transitional -dev packages in ncurses, and
> although I had initially been skeptical it worked like a charm. See the
> discussion in #1032708.
This is helpful and offer an immediate way forward.
I'll be uploading FreeType 2.13.1 in a few weeks, so I'll drop
libfreetype6-dev at that time.
I'm curious: do you plan to drop Provides: libncurses5-dev (=
${binary:Version}), ... from your control file at some point?
Hugh
Date: Mon, 17 Jul 2023 16:08:48 +0200
From: Ralf Treinen <treinen@debian.org>
To: debian-devel@lists.debian.org, debian-qa@lists.debian.org
Subject: Re: usertagging file conflicts [Was: Re: /usr-merge: continuous
archive analysis]
Message-ID: <[🔎] ZLVLcALRLAjPlqNk@debian.home.org" target="_blank">[🔎] ZLVLcALRLAjPlqNk@debian.home.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hello,
On Mon, Jul 17, 2023 at 10:35:24AM +0200, Andreas Beckmann wrote:
> On 17/07/2023 07.16, Helmut Grohne wrote:
> > Then I found treinen@debian.org using edos-file-overwrite. That latter
> > one seems like what I need here. Should we move it to the qa space and
> > drop the edos part? I suggest debian-qa@lists.debian.org usertags
> > file-overwrite. Otherwise, Ralf are you ok with me reusing your tag?
>
> Moving the usertag to the qa namespace sounds like a good idea.
I agree
> And dropping the ancient edos prefix ...
Yes. At the origin, the edos prefix was useful for us as the tool used
to detect these bugs came from the edos project, but that project is
over since a long time. And the tag has been used since then by others for
tagging these kind of bugs discovered independently. So yes, time
to simplify.
> edos-file-overwrite has been used primarily for file-vs-file conflicts (as
> these are the only ones detectable by analyzing .contents files)
That was it's original target, and more specifically between packages
in the same distro, but as Andreas explained that was extended by others
to upgrading bugs:
> We also didn't distinguish between file overwrites happening within a distro
> (two packages in sid shipping the same file) and on upgrades (the file in
> question moved between packages with insufficient Breaks+Replaces). Maybe we
> should.
Sounds like a good idea. However, I do not think that usertags support
a hierarchy of tags. So maybe different specific usertags with a common
prefix, like
fileconflict-installation (error occurs when one tries to install two
packages togther)
fileconflict-upgrade (error occurs when upgrading, due to missing
breaks/replaces)
fileconflict-directory (error occuring due to /usr merge)
Or something in this direction. -Ralf.
Date: Tue, 18 Jul 2023 12:33:37 +0800
From: Paul Wise <pabs@debian.org>
To: debian-devel@lists.debian.org
Subject: Re: usertagging file conflicts [Was: Re: /usr-merge: continuous
archive analysis]
Message-ID: <[🔎] 7c35873f7d94f2f690b56293a81342fac881a753.camel@debian.org" target="_blank">[🔎] 7c35873f7d94f2f690b56293a81342fac881a753.camel@debian.org>
Content-Type: multipart/signed; micalg="pgp-sha512";
protocol="application/pgp-signature"; boundary="=-v7hxGELMNZ4VK7oQ9YVR"
--=-v7hxGELMNZ4VK7oQ9YVR
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, 2023-07-17 at 07:16 +0200, Helmut Grohne wrote:
> Then I found treinen@debian.org=C2=A0using edos-file-overwrite. That latt=
er
> one seems like what I need here. Should we move it to the qa space and
> drop the edos part? I suggest debian-qa@lists.debian.org=C2=A0usertags
> file-overwrite.=C2=A0 Otherwise, Ralf are you ok with me reusing your tag=
?
I have scripts to automate usertags changes and watch weekly diffs.
The QA copy runs from cron fixing some typos and my fork is modified
and run when I notice any weird changes. The script can be used to
easily perform moving and or renaming of usertags as needed here.
https://salsa.debian.org/qa/qa/blob/master/data/cronjobs/usertags-fixes
https://salsa.debian.org/pabs/qa/blob/master/data/cronjobs/usertags-fixes
editor data/cronjobs/usertags-fixes
mkdir tmp
rsync --timeout=3D60 --recursive --delete rsync://bugs-mirror.debian.org/bt=
s-spool-index/user/ tmp/all/
./data/cronjobs/usertags-fixes --debug tmp
--=20
bye,
pabs
https://wiki.debian.org/PaulWise
--=-v7hxGELMNZ4VK7oQ9YVR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmS2Fh0ACgkQMRa6Xp/6
aaNZcg/9FUQocouUSj7ND89NAX220KG9TMn3LKEb8gQMfCbynFGA0Pn9URKJVPbs
rRAj2nan/hVJE9wwghSFVYEDSDyaXDJmSGuHJ60HcHu0XYAOciWfoBJbt1B3Ztmr
8ORr3JHYTC6V89OQ9c4/OIMEvUfcs2Yx2o4kMkYDq0DOwB/f9j69MgyHHJ1q4KCz
WWBUNVtVHbqHyAJMSf/P0j5CE0hkxCJU4Dtwznw5iKUEu2Je7F+nNVbXCE8RfDIA
YyajVa8uFDoxXH8M3Ehq3tPog2mKIrGANKAFc96/nqd0cI3aXcCXwGBzdl6/C0Ns
KYRGRyHng6dnhYU5bwnwZl84N4wbZofdHIhUZsSr0t60KMess2tfyCOAQfOhJbEq
j1oY92jxFlnOfJo8Ct4djSZJBU/PlYu2Anhrjjs31Mgg7VTJxvSoVgYIugmV0MI0
Bl4c+TaZeo1tMONSOEK+QPULBALJUwP7SeSn5ZKlUqNZim2idxys2jyp8kpRaS2/
aj2z17sq1W/meMIU4RwSOcnS4oA59KjeeJX12lx5GQMfdDGuyvrqOSEj6ILiX1tZ
tqOwMv25S2ql/4BMiedhj8bk7Sji5gl6LTrMzbKEkkPXvuijXUh/0hrkDCuw7u0+
WXZJehy+oKab4SlQrts7Y0B0FSizj8OadWhnf2EtiAPOzCYDEsY=
=ZguY
-----END PGP SIGNATURE-----
--=-v7hxGELMNZ4VK7oQ9YVR--
Date: Tue, 18 Jul 2023 12:45:51 +0800
From: YunQiang Su <syq@debian.org>
To: debian-mips <debian-mips@lists.debian.org>
Cc: "debian-devel@lists.debian.org" <debian-devel@lists.debian.org>
Subject: The future of mipsel port
Message-ID: <CAKcpw6X1uBc7ZvKD=AGfwV6_ogW8fxKeUjYn_Rb4AkG7-0n6RA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Hi, folks,
Welcome to era of Trixie, and let's talk about the future of mipsel.
mipsel port has some problems as somebody may know:
1. 2G user RAM space make some packages FTBFS, especially with LTO enabled.
2. Y2038 problem, which requires almost rebootstrap.
3. The current hardwares, include MIPS P5600, Ingenic X2000, Loongson 3A4000,
are NAN2008 hardwares, and some new software supposed that NAN2008 is
always true.
[1] https://sourceware.org/binutils/docs-2.25/as/MIPS-NaN-Encodings.html
4. the maintenance status of big projects, like Firefox, Libreoffice
etc are not so good.
So I consider to suggest drop mipsel support from the list of official ports.
(And let's keep mips64el port).
As CIP United, we do maintain an unofficial port of mipsel.
So I wish that Debian can still accept our patch to support mipsel
port (source only).
https://repo.oss.cipunited.com/debian/
Debian mips32r2el port with:
* -mnan=2008
* -mfp64
* -mmsa (not yet, will have another port)
* -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
* -D_TIME_BITS=64
Known supported hardwares:
MIPS P5600
Ingenic X2000
Loongson 3A4000
Date: Tue, 18 Jul 2023 14:49:19 +1000
From: "Trent W. Buck" <trentbuck@gmail.com>
To: debian-devel@lists.debian.org
Subject: Re: systemd-analyze security as a release goal
Message-ID: <[🔎] 87h6q16cz4.fsf_-_@gmail.com" target="_blank">[🔎] 87h6q16cz4.fsf_-_@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Matthew Garrett <mjg59@srcf.ucam.org> writes:
> On Thu, Jul 13, 2023 at 08:03:39PM +0200, Timo Röhling wrote:
>
>> qemu is basically an interpreter for foreign machine code. If your
>> threat model allows access to qemu-user-static for an attacker, they
>> can run pretty much any binary is if it were native, and the whole
>> SystemCallArchitectures hardening becomes meaningless.
>
> My understanding of the threat is that compatibility syscalls (eg, x32
> on amd64) are less well-tested than the local architecture syscalls, and
> so allowing apps to call them increases the risk - a compromised app
> that can make compatibility syscalls stands a higher probability of
> being able to elevate privileges, either in userland or to the kernel
> itself. Allowing qemu to translate syscalls from other architectures to
> the local syscall ABI doesn't increase that risk, so isn't a concern.
> The goal isn't to prevent code form other architectures from running,
> it's to reduce the attack surface by preventing calls to the
> compatbility syscalls.
Thanks, your user story is much better than mine:
SystemCallArchitectures=native slightly inconveniences attackers by
forcing them to make multiple payloads, instead of "meh, I'll just
build for IA32; that works on regular AND embedded/old systems".
Date: Tue, 18 Jul 2023 10:41:21 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: debian-mips <debian-mips@lists.debian.org>,
"debian-devel@lists.debian.org" <debian-devel@lists.debian.org>
Subject: Re: The future of mipsel port
Message-ID: <[🔎] 20230718094121.GA7780@srcf.ucam.org" target="_blank">[🔎] 20230718094121.GA7780@srcf.ucam.org>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote:
> Known supported hardwares:
> MIPS P5600
> Ingenic X2000
> Loongson 3A4000
This sounds reasonable, but do you have a list of hardware currently
supported by the mipsel port that would be left unsupported by this?
Date: Tue, 18 Jul 2023 19:31:38 +0200
From: Jonas Smedegaard <dr@jones.dk>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#1041417: ITP: rust-regalloc2 -- backtracking register allocator
Message-ID: <[🔎] 168970149888.4147386.17155979977866940931.reportbug@auryn.jones.dk" target="_blank">[🔎] 168970149888.4147386.17155979977866940931.reportbug@auryn.jones.dk>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard <dr@jones.dk>
X-Debbugs-Cc: debian-devel@lists.debian.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
* Package name : rust-regalloc2
Version : 0.9.1
Upstream Contact: Chris Fallin <chris@cfallin.org>
* URL : https://github.com/bytecodealliance/regalloc2
* License : Apache-2.0 with LLVM exception
Programming Lang: Rust
Description : backtracking register allocator
regalloc2 is a register allocator
that started life as, and is about 50% still,
a port of IonMonkey's backtracking register allocator to Rust.
In many regards, it has been generalized, optimized, and improved
since the initial port.
.
In addition,
it contains substantial amounts of testing infrastructure
(fuzzing harnesses and checkers)
that does not exist in the original IonMonkey allocator.
This package is needed by swc (bug#991761).
It will be maintained in the collaborative debian section of salsan at
https://salsa.debian.org/debian/rust-regalloc2
- Jonas
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS2zHcACgkQLHwxRsGg
ASFRAA/7B0A4+Zm3LFQoPFLfv/uaqfkELXs1Fuf2eKgK/IwzR99U+ne2dNB4S1aF
V0ZhF33WbidD63Em/WwNwENGYmeqUa/WUnxFrvEq45E/VyYUd0a3V+jYaGAsxEOA
dZ/N7oLrdFcWaG4eF+K2+Xm5nQe7S7vNafVR2+WT69So9dLlht6gkvDYdM2QWS1u
QxQ08vGgPD9qYWW3IVcvG/mTzL7MnU2PkN4CD17Lowz3pVqxqioEZoHNjxjsJdXC
dhGfTE4a7B9CY8sq/8mBkaJqtOSL6VFKa26rCheMYfwg85XZQ0xS9G5ZiumFU7w9
yM1FPMR9s9YRrGm350wnWzhnKbjGbiyPqMZL79In9vVXak0AXkmUe/07Eii9budI
vzaq8oPMDOfFV3R809q7I8qh3Riy27LrjPxXzB30/r2L0fGs7l6csqGuPll5NZ6O
N0087VphdJoGUJw9Sro+4Dvs+vqqsmNKQ26H+5d8BWeQsfmu1MTD/iyBu4w+3GG1
3nbrMFpBR16eQ6gV4rYxBjTcocqGBPJU+BwgGs5wcQtwplIN25T0pGwoIz2ZhPUQ
pl+5EQw4dMCPMWJlmS9HWcbz5bD2s/t1cHDGpw87Nh66JjV1n6sAMkqNkFtxirCD
WTBN6RMFscwLD/7wrgS0Q/bSwNWe9IzbuuJZDUu1+INW7w+fPrk=
=nXER
-----END PGP SIGNATURE-----