Re: The future of mipsel port
On Sun, 2023-08-06 at 13:54 +0200, Florian Lohoff wrote: > I am late to the party but as i mentioned a couple times on debian-mips > already i'd like to keep mipsel as a debian-port - and i'd like to > revert away from mips32r2 back to mips2/mips3 - That change (with > stretch) basically dropped all of the supported platforms formerly > supported without a good reason - mips32r2 cpus would have been > able to run mips2 code. The now supported platforms are > basically non existent or available for the normal user. That sounds like a new port would be needed, some docs: https://wiki.debian.org/PortsDocs/New > So with that change we basically killed 90% of the Debian/mipsel > users/community e.g. Siemens RM series, Cobalt Cube/RAQ, Decstation R4k > and the like which are now all stuck with pre-Stretch Debian Releases. The baseline bump of the mips port similarly lost MIPSr1 based routers, some of which could run Debian in a chroot. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Enabling -fstack-clash-protection for trixie
Following the procedure to modify default dpkg-buildflags I propose to enable -fstack-clash-protection on amd64. The bug for dpkg tracking this is #918914. | -fstack-clash-protection | Generate code to prevent stack clash style attacks. When this option | is enabled, the compiler will only allocate one page of stack space | at a time and each page is accessed immediately after allocation. | Thus, it prevents allocations from jumping over any stack guard page | provided by the operating system. This has been enabled on other distros for many years already (e.g. Fedora since 27, RHEL since 8, OpenSUSE since 15.1, Ubuntu since 19.10). I worked with Lucas a while back and he made an archive rebuild on amd64, only a minimal list of packages will need to be adapted: http://qa-logs.debian.net/2023/05/24/ The open question is whether to also enable this for arm64, mips64el, ppc64el, riscv and s390x. I'm adding the respective porter lists, if there's consensus among porters of a given arch other than amd64 to also add the flag, please post a followup to #918914. Cheers, Moritz
Re: /usr-merge: continuous archive analysis
On 2023-08-01 Helmut Grohne wrote: [...] > In moving crontab_setgid from lib to libexec, you effectively evade the > moratorium and are entitled to also move from / to /usr. This is an > action you can do right now. The move from /lib to /usr/libexec prevents > the file loss scenario that spurred the moratorium. [...] Hello, Somehow related: If I introduce a new systemd unit should I work around dh_installsystemd and ship it in /usr/lib/systemd/system/? At first glance it seemed like a good idea (not adding to the problem) but doubt there is real benefit. - Another binary package in the same source already ships a unit that will need to be moved so we will need to use $magic anyway. FWIW I would have used something like this: override_dh_installsystemd: dh_installsystemd mv debian/foo/lib/systemd/system \ debian/foo/usr/lib/systemd/ (I am assuming dh_installsystemd would not start installing stuff into /usr/lib without a dh_compat bump.) cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: The future of mipsel port
Hi, On Tue, Jul 18, 2023 at 12:45:51PM +0800, YunQiang Su wrote: > Hi, folks, > > Welcome to era of Trixie, and let's talk about the future of mipsel. > So I consider to suggest drop mipsel support from the list of official ports. > (And let's keep mips64el port). I am late to the party but as i mentioned a couple times on debian-mips already i'd like to keep mipsel as a debian-port - and i'd like to revert away from mips32r2 back to mips2/mips3 - That change (with stretch) basically dropped all of the supported platforms formerly supported without a good reason - mips32r2 cpus would have been able to run mips2 code. The now supported platforms are basically non existent or available for the normal user. So with that change we basically killed 90% of the Debian/mipsel users/community e.g. Siemens RM series, Cobalt Cube/RAQ, Decstation R4k and the like which are now all stuck with pre-Stretch Debian Releases. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature
Re: Potential MBF: packages failing to build twice in a row
Quoting Timo Röhling (2023-08-05 21:07:34) > * Lucas Nussbaum [2023-08-05 17:06]: > >An example sbuild invocation to reproduce failures is: > [omitted the command line equivalent of Tolstoy's War and Peace] > > If we decide that this issue is important enough that people should > care and mass bugs be filed, sbuild will need a more concise way to test > this; something like pbuilder's --twice option. if somebody feels strongly that a --twice option is needed for sbuild I'd be happy to review and merge a MR against the sbuild packaging git on salsa: https://salsa.debian.org/debian/sbuild/ Thanks! cheers, josch signature.asc Description: signature
Re: Potential MBF: packages failing to build twice in a row
On Sat, 05 Aug 2023 at 21:29:08 +0200, Andrey Rakhmatullin wrote: > I expect all Python packages that ship > $name.egg-info and don't remove it in clean and don't exclude it via > extend-diff-ignore (all of which is unneeded busywork even if recommended) > to behave the same. Python packages that *don't* ship $name.egg-info in their upstream source, don't remove it in clean and don't exclude it via extend-diff-ignore will also fail Lucas' test if they are 3.0 (quilt) format (or presumably will have unintended diff instead if they are format 1.0). That's the only reason bmap-tools_3.6-2 was on Lucas' list, for example. smcv
Bug#1043110: ITP: ocaml-randomconv -- convert from random byte vectors to random native numbers
Package: wnpp Severity: wishlist Owner: Stéphane Glondu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-ocaml-ma...@lists.debian.org * Package name: ocaml-randomconv Version : 0.1.3 Upstream Contact: Hannes Mehnert * URL : https://github.com/hannesm/randomconv * License : ISC Programming Lang: OCaml Description : convert from random byte vectors to random native numbers Given a function which produces random byte vectors, convert it to a number of your choice (int8/int16/int32/int64/int/float). This package is needed to run all ocaml-mirage-crypto tests. It will be maintained in the OCaml team.
Q: How to set DMARC record for .debian.net?
Hi, According to LDAP Gateway [1], It supports to create a SPF txt record and DKIM pub key txt record for dnsZoneEntry. I'm no sure but, it seems that DMARC txt record (v=DMARC1; ...) may be rejected to set. Are there any guide to set DMARC for .debian.net correctly (If I'm wrong) or Can we support it? [1] https://db.debian.org/doc-mail.html -- Kentaro Hayashi
