Unsubscribe On Tue, Jul 18, 2023 at 1:33 PM < debian-devel-digest-requ...@lists.debian.org> wrote:
> 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 <d...@jones.dk> ] > Re: Proposed MBF: Removal of libfree [ Hugh McMaster > <hugh.mcmaster@outloo ] > Re: usertagging file conflicts [Was: [ Ralf Treinen <trei...@debian.org> > ] > Re: usertagging file conflicts [Was: [ Paul Wise <p...@debian.org> ] > The future of mipsel port [ YunQiang Su <s...@debian.org> ] > Re: systemd-analyze security as a re [ "Trent W. Buck" < > trentb...@gmail.co ] > Re: The future of mipsel port [ Matthew Garrett > <mj...@srcf.ucam.or ] > Bug#1041417: ITP: rust-regalloc2 -- [ Jonas Smedegaard <d...@jones.dk> ] > Date: Mon, 17 Jul 2023 21:45:13 +1000 > From: Hugh McMaster <hugh.mcmas...@outlook.com> > To: Simon McVittie <s...@debian.org> > Cc: debian-devel@lists.debian.org > Subject: Re: Proposed MBF: Removal of libfreetype6-dev > Message-ID: > < > sy6p282mb3236a4620329b1388fa28a6ff2...@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 <d...@jones.dk> > To: Debian Bug Tracking System <sub...@bugs.debian.org> > Subject: Bug#1041318: ITP: rust-json-event-parser -- JSON event parser and > serializer > Message-ID: < > 168959559567.3829237.16286019313710125242.report...@auryn.jones.dk> > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard <d...@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 <tho...@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.mcmas...@outlook.com> > To: Sven Joachim <svenj...@gmx.de> > Cc: debian-devel@lists.debian.org > Subject: Re: Proposed MBF: Removal of libfreetype6-dev > Message-ID: > < > sy6p282mb3236611881c1fec58f7f47b4f2...@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 <trei...@debian.org> > To: debian-devel@lists.debian.org, debian...@lists.debian.org > Subject: Re: usertagging file conflicts [Was: Re: /usr-merge: continuous > archive analysis] > Message-ID: <zlvlcalrlajpl...@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 trei...@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...@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 <p...@debian.org> > To: debian-devel@lists.debian.org > Subject: Re: usertagging file conflicts [Was: Re: /usr-merge: continuous > archive analysis] > Message-ID: <7c35873f7d94f2f690b56293a81342fac881a753.ca...@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 trei...@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...@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/ <http://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 <s...@debian.org> > To: debian-mips <debian-m...@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-0n...@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" <trentb...@gmail.com> > To: debian-devel@lists.debian.org > Subject: Re: systemd-analyze security as a release goal > Message-ID: <87h6q16cz4.fsf...@gmail.com> > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > Matthew Garrett <mj...@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 <mj...@srcf.ucam.org> > To: debian-mips <debian-m...@lists.debian.org>, > "debian-devel@lists.debian.org" <debian-devel@lists.debian.org> > Subject: Re: The future of mipsel port > Message-ID: <20230718094121.ga7...@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 <d...@jones.dk> > To: Debian Bug Tracking System <sub...@bugs.debian.org> > Subject: Bug#1041417: ITP: rust-regalloc2 -- backtracking register > allocator > Message-ID: < > 168970149888.4147386.17155979977866940931.report...@auryn.jones.dk> > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard <d...@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 <ch...@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----- >
