Linguistic Translation Solutions
Respected Sir/Ma’am, I would like to introduce a translation. *The company has* specialized in providing t*ranslation and interpretation* (on a contract or permanent basis) for the last 21 years. The company is a pioneer in the fields of translation and interpretation across the globe. It has on board a number of specialized translators and interpreters who are specialized in different languages and areas. Some reputed clients: *TCS, Global Sign, BHEL, Interglobe Technologies, Schneider Electric, and NISC Export Services* *I would be highly grateful if you considered us for any of the above services.* Kind Regards, Preety Ahuja Dept (Tr& In)
Re: Enabling some -Werror=format* by default?
On Fri, Jun 07, 2024 at 12:19:28AM +0500, Andrey Rakhmatullin wrote: > We recently increased the time_t size on certain architectures and some > packages started failing to build because they were using a format > specifier too narrow for the wider time_t, e.g. #1067829. > But the only reason those package FTBFS is they enable either -Werror or > some more specific non-default switch like -Werror=format=2, so I suspect > much more packages contain similar code but gained only a warning. Isn't > this a bad thing? Should we enable at least some combination of -Wformat* > switches by default? Should we at least add a new flag to dpkg-buildflags > and do some test rebuilds with it enabled? It wasn't quite clear to me what -Werror=format=2 actually means. According to the gcc documentation[1], -Wformat=2 currently means: -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k. Of these, we already enable -Werror=format-security, but not the other ones. It is not clear to me, which of these actually catches the the type mismatches. Would you do more research here? It also is unclear how this impacts the archive and yes, I'd recommend a rebuild. Note though that we likely need this rebuild both on a 64bit architecture and a 32bit architecture that is not i386 (due to how t64 works). A partial archive rebuild may work to gauge the size of the problem. I note that this kind of change affects cross builds, so performing cross builds for armhf on amd64 will likely show many of these failures (in addition to all the regular cross build failures). I recommend doing more research before moving forward with this. In particular a MBF about introduced problems would be prudent before doing the switch and even if we don't switch, such a MBF bears value on its own. Helmut [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
MBF: Move remaining files into /usr
As many were so happy with the upload of the debootstrap set, we want to direct your attention to the long tail of the /usr-move transition that we want to see fixed in trixie: Moving aliased files in all remaining packages to /usr. More precisely, the transition should be fully completed in trixie before we enter the transition freeze likely in January 2025. Dragging it, including the restrictions on package splits and moving files, into forky would cause a lot of extra effort. At this time, packages needing work mostly fall into three minimally overlapping classes. Two of them already have bugs filed. This MBF is about filing bugs for the biggest one. * "dh-sequence-movetousr": adding dh-sequence-movetousr to Build-Depends moves all files. We want to file bugs for these now. 191 packages. * "ftbfs#NNN": package currently FTBFS. Automatic analysis was not possible. Most of the packages have been failing to build for quite a while. We'll also look into removing these packages from unstable. 28 packages. * "dep17#NNN": package already has a bug report on how to move. Often with a patch. 78 packages. We intend to use the following bug template: == Source: $SOURCEPKG Version: $SOURCEVERSION Severity: important Tags: patch trixie sid User: helm...@debian.org Usertags: dep17m2 dep17dhmovetousr This package is part of the /usr-move (DEP17) transition, because it contains files in aliased locations and should have those files moved to the corresponding /usr location. The goal of this move is eliminating bugs arising from aliasing, such as file loss during package upgrades. The following files in the following binary packages are affected. ... You may add dh-sequence-movetousr to Build-Depends to perform the move. This is an easy and readily applicable measure that has been verified for this package using a test build. The main advantage of this method is the low effort and it just works when backporting to bookworm. However, it is more of a stop-gap measure as eventually the installation procedure should refer to the files that are actually used for installation. This often means updating debian/*.install files but also changing flags passed to a configure script or similar measures. In case you do not anticipate your package being uploaded to bookworm-backports, please prefer a manual move, but generally prefer moving over delaying any further. After having done this move, please keep in mind that the relevant changes need to be reverted for bookworm-backports, with these exceptions: * dh-sequence-movetousr and dh_movetousr cancel themselves. * dh_installsystemd and dh_installudev revert to the aliased location. * The pkg-config variables systemdsystemunitdir in systemd.pc and udevdir in udev.pc reverts to aliased. Please keep in mind that restructuring changes may introduce problems after moving. A change is considered restructuring if formerly aliased files formerly owned by one package are later to be owned by a package with a different name. Such uploads should be done to experimental and quarantine for three days before moving to unstable. This way, automatic analysis (https://salsa.debian.org/helmutg/dumat) can detect problems and file bugs. Such bugs shall include support for resolving the problems. The severity of this bug shall be raised to RC on August 6th. For additional information about refer to https://wiki.debian.org/UsrMerge and https://subdivi.de/~helmut/dep17.html. == Additionally, we intend to upgrade all existing dep17* usertagged bugs to important severity at the time of the MBF. We intend to upgrade these bugs to RC severity on August 6th, too. Please find the dd-list attached. An irregularly updated version can be found at: https://subdivi.de/~helmut/usrmove.ddlist You may opt for not receiving a bug report by performing the requested change before the bugs are filed. Does anyone object to this MBF or wants an aspect about it changed? Kind regards Chris and Helmut Please fix your packages for the /usr-move aka DEP17. Legend: * "upload" means that a source-ful upload fixes all relevant /usr-move issues (in Arch:all packages) * "dh-sequence-movetousr" means that adding dh-sequence-movetousr to Build-Depends moves all files. You may move them manually if you prefer. * "ftbfs#NNN" identifies a FTBFS bug that prevents automatic analysis. * "dep17#NNN" identifies a relevant bug report. Please consult this bug and fix it if possible. Most of them have a patch. A. Maitland Bottoms libiio dh-sequence-movetousr Adam Borowski btrfs-progs ftbfs#1071297 ndctl dh-sequence-movetousr powermgmt-base dh-sequence-movetousr Adrian Alves grokmirror dh-sequence-movetousr Adrian Vondendriesch booth dh-sequence-movetousr corosync dh-sequence-movetousr fence-agents dh-sequence-movetousr sbd dh-sequence-movetousr Alastair McKinstry csh dh-sequence-movetousr Alberto Bertogli dnss dh-seque
Re: Enabling some -Werror=format* by default?
On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote:
> > We recently increased the time_t size on certain architectures and some
> > packages started failing to build because they were using a format
> > specifier too narrow for the wider time_t, e.g. #1067829.
> > But the only reason those package FTBFS is they enable either -Werror or
> > some more specific non-default switch like -Werror=format=2, so I suspect
> > much more packages contain similar code but gained only a warning. Isn't
> > this a bad thing? Should we enable at least some combination of -Wformat*
> > switches by default? Should we at least add a new flag to dpkg-buildflags
> > and do some test rebuilds with it enabled?
>
> It wasn't quite clear to me what -Werror=format=2 actually means.
> According to the gcc documentation[1], -Wformat=2 currently means:
>
> -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k.
>
> Of these, we already enable -Werror=format-security, but not the other
> ones. It is not clear to me, which of these actually catches the the
> type mismatches. Would you do more research here?
#include
void foo()
{
printf("%d", 0L);
}
This produces a warning with just -Wformat ("format ‘%d’ expects argument
of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]"). It
doesn't look like any more narrow options for this exist (-Wno-* ones
listed in the -Wformat description don't silence this one, and they don't
look like they should anyway).
But I don't know if even -Werror=format is too much to enable by default
globally (I assume it's a good thing to enable it, though).
> It also is unclear how this impacts the archive and yes, I'd recommend a
> rebuild. Note though that we likely need this rebuild both on a 64bit
> architecture and a 32bit architecture that is not i386 (due to how t64
> works). A partial archive rebuild may work to gauge the size of the
> problem.
>
> I note that this kind of change affects cross builds, so performing
> cross builds for armhf on amd64 will likely show many of these failures
> (in addition to all the regular cross build failures).
>
> I recommend doing more research before moving forward with this. In
> particular a MBF about introduced problems would be prudent before doing
> the switch and even if we don't switch, such a MBF bears value on its
> own.
Do you think it makes sense to add this a flag that enables -Werror=format
to dpkg-buildflags(1), before, or after a test rebuild, before, or after
the MBF if we do one?
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Suggestions about i386 support
> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin wrote: > > On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote: It's not just a matter of "buy something better." That's easy. >> >>> Indeed, that is easier and cheaper. >> >> Of course, continuing to use a system I already have is cheaper still. >> >>> What's not easy is that a) that adds another machine to the waste >>> stream, instead of continuing to get use from it, and b) someone has >>> to take the time to set up the new machine, test things, migrate >>> services, etc. to functionally replace the old one. That takes time >>> and effort, too, multiplied by the number of such systems out there. >> >>> (a) is false as newer hardware can already be taken from electronic waste, >>> so it does not add new waste. >> >> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair >> amount of material still goes to waste, and there are all kinds of costs >> associated with those processes. >> >> Reuse is better than recycle for complex things like electronics. > You were suggested to resuse an old amd64 machine. Again, that assumes that I have such a thing. I don't. Unless you want to provide one? Also, that still doesn't explain how that means the existing 32-bit machine stays out of the waste stream. In your solution, it doesn't. In my solution, it does. --J
Re: Suggestions about i386 support
On 2024-06-10 at 08:09, rhys wrote: > On Jun 10, 2024, at 01:44, Andrey Rakhmatullin > wrote: > >> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org >> wrote: >>> Reuse is better than recycle for complex things like electronics. >>> >> You were suggested to resuse an old amd64 machine. > > Again, that assumes that I have such a thing. I don't. Unless you > want to provide one? > > Also, that still doesn't explain how that means the existing 32-bit > machine stays out of the waste stream. In your solution, it doesn't. > In my solution, it does. I think the suggestion was to take an old amd64 machine out of the waste stream, and put the existing 32-bit machine into the waste stream, so that the total amount in the waste stream remains the same but you no longer need software support for the 32-bit machine. How to get access to the right parts of the waste stream to be able to pull out some working 64-bit hardware is another question, and one where I don't have an answer that wouldn't involve spending money (which would presumably make the proposed alternative insufficiently comparable, since presumably you wouldn't have to spend money to keep the existing 32-bit machine in service). If Andrey does, I'd be interested to learn it. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Suggestions about i386 support
Hi The (2024.06.10_12:22:14_+) > How to get access to the right parts of the waste stream to be able to > pull out some working 64-bit hardware is another question, and one where > I don't have an answer that wouldn't involve spending money (which would > presumably make the proposed alternative insufficiently comparable, > since presumably you wouldn't have to spend money to keep the existing > 32-bit machine in service). If Andrey does, I'd be interested to learn > it. The point here is that the Debian project is not intending to support new hardware on the i386 architecture. The architecture is being kept around primarily to support running old i386 binaries. We didn't bring 64bit time_t to the architecture, because of this goal. There isn't a team working on a modern 32 bit x86 port. We're just trying to keep the old one going for as long as we can. You're welcome to try to form such a team, of course :) The cost of supporting a port of Debian is far more than the cost of the machines needed to build it. Never mind the cost of 1 user's machine. Stefano -- Stefano Rivera http://tumbleweed.org.za/
Re: Enabling some -Werror=format* by default?
Hi! On Mon, 2024-06-10 at 16:06:13 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 07:48:59AM +0200, Helmut Grohne wrote: > > > We recently increased the time_t size on certain architectures and some > > > packages started failing to build because they were using a format > > > specifier too narrow for the wider time_t, e.g. #1067829. > > > But the only reason those package FTBFS is they enable either -Werror or > > > some more specific non-default switch like -Werror=format=2, so I suspect > > > much more packages contain similar code but gained only a warning. Isn't > > > this a bad thing? Should we enable at least some combination of -Wformat* > > > switches by default? Should we at least add a new flag to dpkg-buildflags > > > and do some test rebuilds with it enabled? > > > > It wasn't quite clear to me what -Werror=format=2 actually means. > > According to the gcc documentation[1], -Wformat=2 currently means: > > > > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k. Those are in addition to the ones enabled by -Wformat=1, which are: -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args -Wno-format-zero-length So all the above would supposedly turn into -Werror too. > But I don't know if even -Werror=format is too much to enable by default > globally (I assume it's a good thing to enable it, though). Hard to say w/o a rebuild I guess. (And take into account this can also affect configure-style checks, which might become silent errors but end up disabling features or enabling unexpected code paths or similar.) In general I think it's good (in principle) to enable -Werror flags that detect actual bugs in code, the problem is always going to be the amount of fallout and work that creates, and whether there's consensus about that work commitment being acceptable to maintainers in Debian, or whether that can interfere with transitions going on, etc. > > It also is unclear how this impacts the archive and yes, I'd recommend a > > rebuild. Note though that we likely need this rebuild both on a 64bit > > architecture and a 32bit architecture that is not i386 (due to how t64 > > works). A partial archive rebuild may work to gauge the size of the > > problem. > > > > I note that this kind of change affects cross builds, so performing > > cross builds for armhf on amd64 will likely show many of these failures > > (in addition to all the regular cross build failures). > > > > I recommend doing more research before moving forward with this. In > > particular a MBF about introduced problems would be prudent before doing > > the switch and even if we don't switch, such a MBF bears value on its > > own. > Do you think it makes sense to add this a flag that enables -Werror=format > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > the MBF if we do one? If by adding you mean adding a new feature flag that is disabled by default, then depending on the feature area, that might unfortunately be equivalent to enable it by default (due to the «all» keyword). (I started a design to version the build flags interface, but I got stuck, so I let it brew as a background process, have pending to finish that up and propose it on d-dpkg.) Thanks, Guillem
Re: Enabling some -Werror=format* by default?
On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > > > We recently increased the time_t size on certain architectures and some > > > > packages started failing to build because they were using a format > > > > specifier too narrow for the wider time_t, e.g. #1067829. > > > > But the only reason those package FTBFS is they enable either -Werror or > > > > some more specific non-default switch like -Werror=format=2, so I > > > > suspect > > > > much more packages contain similar code but gained only a warning. Isn't > > > > this a bad thing? Should we enable at least some combination of > > > > -Wformat* > > > > switches by default? Should we at least add a new flag to > > > > dpkg-buildflags > > > > and do some test rebuilds with it enabled? > > > > > > It wasn't quite clear to me what -Werror=format=2 actually means. > > > According to the gcc documentation[1], -Wformat=2 currently means: > > > > > > -Wformat -Wformat-nonliteral -Wformat-security -Wformat-y2k. > > Those are in addition to the ones enabled by -Wformat=1, which are: (note that -Wformat is already included in that list) > -Wnonnull -Wno-format-contains-nul -Wno-format-extra-args > -Wno-format-zero-length (note that -Wformat is not equal to these flags, it just implies -Wnonnull and those three -Wno-* can be used to turn off some parts of it) > In general I think it's good (in principle) to enable -Werror flags > that detect actual bugs in code, the problem is always going to be > the amount of fallout and work that creates, and whether there's > consensus about that work commitment being acceptable to maintainers > in Debian, or whether that can interfere with transitions going on, > etc. Yeah. > > > It also is unclear how this impacts the archive and yes, I'd recommend a > > > rebuild. Note though that we likely need this rebuild both on a 64bit > > > architecture and a 32bit architecture that is not i386 (due to how t64 > > > works). A partial archive rebuild may work to gauge the size of the > > > problem. > > > > > > I note that this kind of change affects cross builds, so performing > > > cross builds for armhf on amd64 will likely show many of these failures > > > (in addition to all the regular cross build failures). > > > > > > I recommend doing more research before moving forward with this. In > > > particular a MBF about introduced problems would be prudent before doing > > > the switch and even if we don't switch, such a MBF bears value on its > > > own. > > > Do you think it makes sense to add this a flag that enables -Werror=format > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > > the MBF if we do one? > > If by adding you mean adding a new feature flag that is disabled by > default, then depending on the feature area, that might unfortunately > be equivalent to enable it by default (due to the «all» keyword). That's a good point, though hopefully people who use "all" understand the implication... -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestions about i386 support
On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > The point here is that the Debian project is not intending to support > new hardware on the i386 architecture. The architecture is being kept > around primarily to support running old i386 binaries. ... and the most appropriate answers to some technical questions are not going to be the same for "i386 to run legacy 32-bit binaries on 64-bit CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support both equally. > We didn't bring 64bit time_t to the architecture, because of this goal. This is a good example of a decision that goes differently for those two purposes. If we want to run legacy i386 binaries, 64-bit time_t would be counterproductive, because it will break some of those binaries *now* (not just in 2038). Raising the baseline (to i686 or beyond) is another decision that would go differently for those two purposes. For legacy i386 binaries on an x86_64 CPU, the baseline could raise as far as i686 + SSE + SSE2 without losing any 64-bit CPU support, because SSE and SSE2 are part of the x86_64 baseline; but for genuinely 32-bit CPUs, as discussed in this thread and elsewhere, even i686 is sometimes too high. > There isn't a team working on a modern 32 bit x86 port. We're just > trying to keep the old one going for as long as we can. You're welcome > to try to form such a team, of course :) The "i386" name is widely hard-coded in third-party software (e.g. Steam) as being the appropriate architecture to use to run legacy 32-bit binaries on a 64-bit CPU, so if we were to fork i386 into two separate ports (one for legacy binaries on 64-bit CPUs, and one for 32-bit CPUs), the route that would avoid breaking backwards-compatibility would be for the i386 name to stay with the port that is intended for legacy binaries, introducing a new name for the port that is intended for 32-bit CPUs. (This is because by definition legacy binaries are legacy, and are not going to change to accommodate new decisions, whereas a new port can produce new binaries with code changes if enough effort is put into doing so.) If people want a distribution to run on 32-bit x86 CPUs badly enough, one possible route would be to start a new port (perhaps called ia32, i386t64 or something similar) for that use-case; it would have a baseline that is as low as its maintainers want it to be (i586?), and a 64-bit time_t for post-2038 future-proofing. As far as I'm aware, nobody is yet putting effort into doing this. Also, several important upstreams no longer consider i386 to be useful (and especially i386-without-SSE2), so so the burden of supporting 32-bit CPUs in modern software will fall on the downstream developers who have chosen that their aim is to support 32-bit CPUs. And, for several larger packages it is becoming a serious problem to compile and link the software natively on any 32-bit architecture, because the working set for the compiler or linker is larger than 4 GiB, but a 32-bit architecture can't possibly address more than 4 GiB of virtual memory at a time. Those are problems that any would-be port maintainer for a "modern" 32-bit x86 port would have to deal with somehow, and telling the wider Debian project "this is important to me, therefore it should be important to you" is unlikely to result in those problems going away. Alternatively... > The cost of supporting a port of Debian is far more than the cost of the > machines needed to build it. Never mind the cost of 1 user's machine. As a point of comparison, a used 64-bit laptop of a well-respected design from 12-13 years ago (Lenovo X220) seems to be readily available for around £60 on eBay UK, and that price is enough to pay a software consultant in the UK for somewhere around 1 hour. Of course, volunteer effort is not directly interchangeable with consultant effort and not every country is the UK, but the time-cost of maintaining a 32-bit port of Debian is going to be lots of hours. I suspect that many of the used 64-bit laptops of that age on eBay go unsold and will instead be discarded, entering the e-waste stream, in which case buying one as a replacement for a 32-bit machine is not a net increase in e-waste. (No endorsement of eBay intended, other sources of refurbished computers are available.) smcv
Re: Enabling some -Werror=format* by default?
On Mon, 10 Jun 2024 at 16:24:54 +0200, Guillem Jover wrote: > In general I think it's good (in principle) to enable -Werror flags > that detect actual bugs in code, the problem is always going to be > the amount of fallout and work that creates Yes. The difficult thing here is balancing "detect actual (important) bugs in code" against "detect non-bugs or unimportant bugs, and make them be treated as if they were important". Unfortunately, because compiler warnings are mostly heuristics involving a reasonable guess about what the developer had intended to happen, most compiler warnings do a mixture of both. smcv
Re: Enabling some -Werror=format* by default?
On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > Do you think it makes sense to add this a flag that enables -Werror=format > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > > the MBF if we do one? > > If by adding you mean adding a new feature flag that is disabled by > default, then depending on the feature area, that might unfortunately > be equivalent to enable it by default (due to the «all» keyword). Another related question: if not via dpkg-buildflags, how do we do rebuilds with changed default flags? -- WBR, wRAR signature.asc Description: PGP signature
Re: Suggestions about i386 support
On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote: > > The point here is that the Debian project is not intending to support > > new hardware on the i386 architecture. The architecture is being kept > > around primarily to support running old i386 binaries. > > ... and the most appropriate answers to some technical questions are not > going to be the same for "i386 to run legacy 32-bit binaries on 64-bit > CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support > both equally. Yeah, it should be made clear that if some people want to bring back proper support for i386 hardware, they will need to make a new port. Which is of course more complicated than fixing an existing one (but at least bootstrapping it should be easier than bootstrapping some non-x86 port). > If people want a distribution to run on 32-bit x86 CPUs badly enough, > one possible route would be to start a new port (perhaps called ia32, > i386t64 or something similar) for that use-case; it would have a baseline > that is as low as its maintainers want it to be (i586?), and a 64-bit > time_t for post-2038 future-proofing. > > As far as I'm aware, nobody is yet putting effort into doing this. Also, > several important upstreams no longer consider i386 to be useful (and > especially i386-without-SSE2), so so the burden of supporting 32-bit > CPUs in modern software will fall on the downstream developers who have > chosen that their aim is to support 32-bit CPUs. I assume such software already has this status on Debian i386 (and so is either not built there or supported only by the maintainer, or maybe built with a raised baseline) so there should be no regression here, though additional packages will get the same status in the future. Similarly, we already don't build a noticeable number of packages on armel (and some of them also on armhf) when we build them on arm64. -- WBR, wRAR signature.asc Description: PGP signature
Re: Mandatory LC_ALL=C.UTF-8 during package building
On Sat, 08 Jun 2024 at 02:14:36 +0900, Simon Richter wrote: > Reproducibility outside of sterile environments is however a problem for us > as a distribution, because it affects how well people are able to contribute > to packages they are not directly maintaining If our package-building entry point sets up aspects of its desired normalized (or "sterile") environment itself, surely it's equally easy for those contributors to build every package in that way, whether they maintain this particular package or not? > if my package is not required to work outside > of a very controlled environment, that is also an impediment to > co-maintenance I'm not sure that follows. If the only thing we require is that it works in a controlled environment, and the controlled environment is documented and easy to achieve, then surely every prospective co-maintainer is in an equally good position to be contributing? That seems better, to me, than having unwritten rules about what environment is "close enough" and what environment doesn't actually work. If I want to contribute to (let's say) both GNOME and KDE, but the GNOME team expects me to be building in one controlled environment, and the KDE team expects me to be building in a *different* controlled environment, then sure, that would be a barrier to contribution: I'd have to do that setup once per team, and maybe they'd be mutually incompatible. But that isn't going to be the case if we're setting a policy for the whole distro, which only needs to happen once? We already do expect maintainers to be building in a specified environment: Debian unstable (not stable, and not Ubuntu, for example). I can see that if our policy was something like "must build in a schroot", then that would be making us vulnerable to a lock-in where we can't move to Podman or systemd-nspawn or Incus or whatever is the flavour of the month because our policy says we use schroot, and then we end up shackled to schroot's particular properties and limitations. (Indeed, to an extent, we already have that problem by using schroot on official buildds, and as a result being unable to gain much benefit from work done on container technologies outside the Debian bubble.) But that's not what was proposed by this thread: this thread is about locales. Now that glibc has C.UTF-8 built-in and non-optional, you can set a normalized or sterile locale regardless of whether you're building on bare metal, in a VM, in a schroot, in Docker, or whatever, and it's very easy to do that in a tool (or even an interactive shell) and have it inherit down through the build? So I'm not sure I see the problem? If you're making a wider point about use of containers etc. that is orthogonal to setting the locale, then that would be a valid objection to someone saying "we should standardize on building in Docker" (and I would make a similar objection myself), but that's not this thread. (I also do agree that it is an anti-pattern if we have a specified environment where tests or QA will be run, and serious consequences for failures in that environment, without it being reasonably straightforward for contributors to repeat the testing in a sufficiently similar controlled environment that they have a decent chance at being able to reproduce the failure. But, again, that isn't this thread.) > a lot of the debates we've had in the past years is who gets to > decide what is in scope Yes, that's always going to be the case for a community that doesn't have an authority figure telling us "the scope is what I say it is". We have debates when we don't all agree, and the scope of our collective project is one of the foundations for all the other decisions we make, so it's certainly something that we can't expect to be unanimous. (Insert wise words from Russ Allbery about the difference between unanimity and consensus here...) I hope we can come close enough to a consensus that we're all generally willing to accept it, though, even if that means sometimes accepting a narrower or wider scope than I would personally prefer. > > What Giole proposed at the beginning of this thread can be rephrased as > > declaring that "FTBFS when locale is not C.UTF-8" and "non-reproducible > > when locale is varied" are non-bugs, and therefore they are not only > > wontfix, but they should be closed altogether as being out-of-scope. > > Indeed -- however this class of bugs has already been solved because > reproducible-builds.org have filed bugs wherever this happened, and > maintainers have added workarounds where it was impossible to fix. Someone (actually, quite a lot of someones) had to do that testing, and those fixes or workarounds. Who did it benefit, and would they have received the same benefit if we had said "building in a locale other than C.UTF-8 is unsupported", or in some cases "building in a non-UTF-8 locale is unsupported", and made it straightforward to build in the supported locales? I think there is a danger that we sink time
Re: Suggestions about i386 support
On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote: > > several important upstreams no longer consider i386 to be useful (and > > especially i386-without-SSE2), so so the burden of supporting 32-bit > > CPUs in modern software will fall on the downstream developers who have > > chosen that their aim is to support 32-bit CPUs. > > I assume such software already has this status on Debian i386 (and so is > either not built there or supported only by the maintainer, or maybe built > with a raised baseline) so there should be no regression here Some concrete examples: * Packages built with -fcf-protection (Intel CET) require CPU support for "long NOP" opcodes which are, or used to be, non-baseline. This is a security hardening measure, so if we disable it in order to respect the documented baseline, the result is that our binaries are less secure than they could be (fewer mitigations for exploits) on CPUs where those opcodes actually *are* supported. (That's what started this thread: sudo enables this hardening.) * nodeJS, Qt5WebEngine and others have a known baseline violation by using and requiring SSE2 internally, which they document by depending on sse2-support. I thought Chromium did this too, but maybe it either doesn't do that any more, or still has the baseline violation but doesn't document it. * Packages built with rustc (notably Firefox and librsvg) had a known baseline violation in the past (they would crash with an illegal instruction on i586) which was made officially not-a-bug by raising the baseline to i686. * In packages with test suites that compare the results of floating-point calculations at a high precision (such as librsvg), the fact that we target the legacy i387 FPU (which has 80-bit excess precision) rather than SSE2 (which has 64-bit IEEE precision) has caused a lot of extra work for maintainers in the past, due to tests getting a result on i386 that differs from the result on every other platform we support. * Some third-party software like Steam does not follow our baselines, and unconditionally requires newer CPU features. (Not a concern for Steam on i386 any more, because Steam now requires a 64-bit CPU, so bookworm's steam-installer is intentionally not installable on purely 32-bit systems - but Steam will not actually work on a baseline *64-bit* CPU any more.) smcv
Re: Enabling some -Werror=format* by default?
Hi! On Mon, 2024-06-10 at 20:09:21 +0500, Andrey Rakhmatullin wrote: > On Mon, Jun 10, 2024 at 04:24:54PM +0200, Guillem Jover wrote: > > > Do you think it makes sense to add this a flag that enables -Werror=format > > > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > > > the MBF if we do one? > > > > If by adding you mean adding a new feature flag that is disabled by > > default, then depending on the feature area, that might unfortunately > > be equivalent to enable it by default (due to the «all» keyword). > > Another related question: if not via dpkg-buildflags, how do we do > rebuilds with changed default flags? Ah, you can still use its mechanism (just not its policy) where a rebuild should be able to use DEB__APPEND for that, or set them in one of its config files. If having a modified dpkg-dev emitting those by default would be less cumbersome for the rebuilder, I'm happy to provide an out of archive package for that for example, which I think we have done for some rebuilds. Thanks, Guillem
Re: Enabling some -Werror=format* by default?
On Mon, Jun 10, 2024 at 04:06:13PM +0500, Andrey Rakhmatullin wrote: > Do you think it makes sense to add this a flag that enables -Werror=format > to dpkg-buildflags(1), before, or after a test rebuild, before, or after > the MBF if we do one? I think that a test rebuild and the MBF are reasonable preconditions to extend the default build flags (and with default I mean changing hardening=+all). As multiple people pointed out, the effects of the flags are hard to predict and they can even cause misbuilds (via failing configure checks), so these flags do have a non-trivial cost (and benefits). Ideally, we'd not just do a rebuild with the flags, but also do a rebuild without and then compare the binary .debs. In the event that we misguide configure, we expect the .debs to differ and otherwise to equal due to the work of the reproducible builds folks. That equality has a really annoying difference in practice though: Build ids are dependent on the compiler flags, so the comparison would have to magically ignore changes in build id and this is where things become quite difficult. > Another related question: if not via dpkg-buildflags, how do we do > rebuilds with changed default flags? If you export DEB_CFLAGS_APPEND=-Werror=format=2 and DEB_CXXFLAGS_APPEND=-Werror=format=2 (not to be confused with DEB_*_MAINT_APPEND which is often set in d/rules), you should get most packages to pick up these flags. Possibly debusine.debian.net can be used to perform such a rebuild rather than using your own resources. Steering it to do this is a non-trivial task at present, but I my impression is that you will receive support in doing so and it can do native armhf builds (eliminating the need for cross builds). Your mileage will vary. In any case, my impression is that the first step towards changing hardening flags is actually performing test builds in whatever form. Helmut
Seeking consensus on file conflict between python3-proto-plus and nanopb
Hello, There is a file conflict between python3-proto-plus and nanopb. The conflict arises due to both packages has a file at /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining python3-proto-plus, and I am seeking guidance. The module name "proto" is an integral part of the python3-proto-plus package. Renaming the "proto" module in python3-proto-plus would significantly impact future dependent packages. It appears that nanopb's use of the module name "proto" does not align with the conventional identification of a Python module. Given this, it might be plausible to make this module private within the nanopb package. This adjustment could potentially resolve the conflict without affecting the dependent packages. I have attempted to reach out to the nanopb maintainer to discuss this issue, but I have not yet received a response. In case the maintainer is MIA, should I proceed with renaming the "proto" module in nanopb to "nanopb-proto"? As one of the team members, I am willing to implement this change if it is deemed the best solution. I am looking forward to your input and suggestions on how we can resolve this issue in a way that maintains the integrity and functionality of both packages. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072073 Best regards, Yogeswaran. signature.asc Description: PGP signature
Re: Enabling some -Werror=format* by default?
* Helmut Grohne [2024-06-10 18:01]: > Ideally, we'd not just do a rebuild with the flags, but also do a > rebuild without and then compare the binary .debs. In the event that we > misguide configure, we expect the .debs to differ and otherwise to equal > due to the work of the reproducible builds folks. That equality has a > really annoying difference in practice though: Build ids are dependent > on the compiler flags, so the comparison would have to magically ignore > changes in build id and this is where things become quite difficult. Indeed build IDs can be a very annoying source of unreproducible builds (though I mostly encounter those working with Android toolchains, not Debian packages). But build IDs can be disabled via appropriate linker flags (e.g. -Wl,--build-id=none). Is there some reason simply doing that for both rebuilds is not an option? - Fay
Re: Seeking consensus on file conflict between python3-proto-plus and nanopb
On Mon, Jun 10, 2024 at 06:40:02PM -0400, Yogeswaran Umasankar wrote: > There is a file conflict between python3-proto-plus and nanopb. The > conflict arises due to both packages has a file at > /usr/lib/python3/dist-packages/proto/__init__.py [0]. I am maintaining > python3-proto-plus, and I am seeking guidance. > > The module name "proto" is an integral part of the python3-proto-plus > package. Renaming the "proto" module in python3-proto-plus would > significantly impact future dependent packages. > > It appears that nanopb's use of the module name "proto" does not align > with the conventional identification of a Python module. What do you mean? It does look like a Python module to me. It's very likely that it should be a private one though, but I see you already asked the maintainer about that. > I have attempted to reach out to the nanopb maintainer to discuss this > issue, but I have not yet received a response. In case the maintainer is > MIA, should I proceed with renaming the "proto" module in nanopb to > "nanopb-proto"? No, it will make it useless. I don't see a good way forward that doesn't involve NMUing nanopb. -- WBR, wRAR signature.asc Description: PGP signature
