Re: allowed uses of non-baseline CPU extensions

2017-10-24 03:31 Yao Wei: Hi, I believe that we haven't talked about another problem is that what if one installing Debian in the portable drive and use it in another computer. Another scenario which has not been considered I think (apologies, I skimmed quickly over part of the thread)... I

Re: allowed uses of non-baseline CPU extensions

Quoting Josh Triplett (2017-10-24 04:29:32) > Philipp Kern wrote: > > I think that's a very important observation. I don't think you can > > necessarily conclude that the system where the package is initially > > installed is the system were the code is executed. > > > > In many kinds of

Re: allowed uses of non-baseline CPU extensions

Philipp Kern wrote: > I think that's a very important observation. I don't think you can > necessarily conclude that the system where the package is initially > installed is the system were the code is executed. > > In many kinds of image-based environments the machines the image is > shipped to

Re: allowed uses of non-baseline CPU extensions

Hi, I believe that we haven't talked about another problem is that what if one installing Debian in the portable drive and use it in another computer. I think we could use debconf to warn user that the CPU of the computer you are installing does not support instructions the package is requiring,

Re: allowed uses of non-baseline CPU extensions

On Tue, Oct 24, 2017 at 4:25 AM, Philipp Kern wrote: > I think that's a very important observation. I don't think you can > necessarily conclude that the system where the package is initially > installed is the system were the code is executed. Indeed. > You argued in #873733[1] that you'd

Re: allowed uses of non-baseline CPU extensions

On 10/05/2017 05:01 AM, Paul Wise wrote: > A better place to put isa-support might be in an apt plugin that > detects packages being installed that declare for example CPU-Flags: > SSE4.1 and prevents installing them unless in a chroot (for d-i or > debootstraps) and has an option to disable that

Re: allowed uses of non-baseline CPU extensions

On Mon, 2017-10-23 at 16:47 +0200, Adam Borowski wrote: > On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > > sse2-support and other packages that fail to install can massively > > screw up systems, potentially leaving dpkg in a state that people > > cannot easily recover from

Re: allowed uses of non-baseline CPU extensions

On Mon, Oct 23, 2017 at 04:47:52PM +0200, Adam Borowski wrote: > It cleanly aborts installation in preinst. that's a violation of the release teams requirement for a stable release, where all packages *must* install cleanly… -- cheers, Holger signature.asc Description: PGP signature

Re: allowed uses of non-baseline CPU extensions

On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > sse2-support and other packages that fail to install can massively > screw up systems, potentially leaving dpkg in a state that people > cannot easily recover from - that is, apt-get install -f might not > be working at that

Re: allowed uses of non-baseline CPU extensions

On Mon, Oct 23, 2017 at 04:36:11PM +0200, Julian Andres Klode wrote: > sse2-support and other packages that fail to install can massively > screw up systems, potentially leaving dpkg in a state that people > cannot easily recover from - that is, apt-get install -f might not > be working at that

Re: allowed uses of non-baseline CPU extensions

On Sun, Oct 22, 2017 at 12:33:02PM +0300, Adrian Bunk wrote: > On Thu, Oct 05, 2017 at 03:52:56AM +0200, Adam Borowski wrote: > >... > > But, Adrian Bunk warned that this makes violating the baseline too easy. > > And indeed, I just noticed an attempt to use an extension in a way I don't > >

Re: allowed uses of non-baseline CPU extensions

On Sun, Oct 22, 2017 at 06:53:49PM +0800, Aron Xu wrote: >... > With packages like sse2-support maintainers have the option of > creating different flavors of their packages with modern instructions > enabled/disabled, The opposite is true. The result are not different flavors (which would be

Re: allowed uses of non-baseline CPU extensions

On Sun, Oct 22, 2017 at 5:33 PM, Adrian Bunk wrote: > > There are two options availabe: > 1. RC bug that qtwebengine-opensource-src must not be built on i386 >since it violates the baseline, all code using it has to do whatever >mitigation is already done for the other

Re: allowed uses of non-baseline CPU extensions

On Thu, Oct 05, 2017 at 03:52:56AM +0200, Adam Borowski wrote: >... > But, Adrian Bunk warned that this makes violating the baseline too easy. > And indeed, I just noticed an attempt to use an extension in a way I don't > consider to be valid: #864012. I understand the maintainer's reasoning, >

Re: allowed uses of non-baseline CPU extensions

On Thu, 05 Oct 2017 at 20:10:02 +0200, Sven Joachim wrote: > On 2017-10-05 09:09 +0100, Simon McVittie wrote: > > Unfortunately, dpkg's cputable doesn't seem to > > have a column for "what is a normal uname -m on this architecture?", > > The closest thing to that is DEB_HOST_GNU_CPU which

Re: allowed uses of non-baseline CPU extensions

On Thu, 05 Oct 2017 at 20:10:02 +0200, Sven Joachim wrote: > On 2017-10-05 09:09 +0100, Simon McVittie wrote: > > It's also common > > to identify architecture by uname -m in ad-hoc project-specific build > > systems > > Using uname -m seems to be wrong, since there are many 32-bit >

Re: allowed uses of non-baseline CPU extensions

On 2017-10-05 09:09 +0100, Simon McVittie wrote: > On Thu, 05 Oct 2017 at 11:01:42 +0800, Paul Wise wrote: >> Anything that generates different code depending on the instructions >> supported by the build CPU is going to break reproducible builds. So >> whatever mechanism is used, it needs to be

Re: allowed uses of non-baseline CPU extensions [and 1 more messages]

Simon McVittie writes ("Re: allowed uses of non-baseline CPU extensions"): > I think this is perhaps a reasonable compromise: consider non-baseline > CPU requirements to be a bug, I think this is the right approach. It neatly solves the problem of asking the maintainer t

Re: allowed uses of non-baseline CPU extensions

On Thu, 2017-10-05 at 03:23 +0100, Ben Hutchings wrote: > This should be unnecessary since gcc 6, as you can easily tell the > compiler to generate and select between multiple versions of the > functions. See . Having to identify interesting functions and add

Re: allowed uses of non-baseline CPU extensions

On Thu, Oct 05, 2017 at 09:12:05AM +0100, Simon McVittie wrote: > On Thu, 05 Oct 2017 at 03:52:56 +0200, Adam Borowski wrote: > > So, let's list packages that want non-baseline: > > * multiple variants: package src:x provides x-unoptimized, x-sse3 and > > x-avx1048576. Clearly legitimate and a

Re: allowed uses of non-baseline CPU extensions

On Thu, 05 Oct 2017 at 03:52:56 +0200, Adam Borowski wrote: > The package in question, lepton, is a tool to losslessly recompress JPEG > files. It does so faster if your CPU is equipped with SSE4.1, thus the > upstream build system hard-codes this requirement, even though it seems > that generic

Re: allowed uses of non-baseline CPU extensions

On Thu, 05 Oct 2017 at 11:01:42 +0800, Paul Wise wrote: > Anything that generates different code depending on the instructions > supported by the build CPU is going to break reproducible builds. So > whatever mechanism is used, it needs to be deterministic. [...] > I'd like to see

Re: allowed uses of non-baseline CPU extensions

On Thu, Oct 5, 2017 at 9:52 AM, Adam Borowski wrote: > Any thoughts? A better place to put isa-support might be in an apt plugin that detects packages being installed that declare for example CPU-Flags: SSE4.1 and prevents installing them unless in a chroot (for d-i or debootstraps) and has an

Re: allowed uses of non-baseline CPU extensions

On Thu, 2017-10-05 at 03:52 +0200, Adam Borowski wrote: [..] > The package in question, lepton, is a tool to losslessly recompress JPEG > files. It does so faster if your CPU is equipped with SSE4.1, thus the > upstream build system hard-codes this requirement, even though it seems > that generic

allowed uses of non-baseline CPU extensions

Hi folks! Recently, I've made a package "isa-support" to improve handling of cases where support for extensions not included in an arch's baseline is required. I'm not sure if an install-time check is the best idea, but no one proposed anything better, thus for now it's an improvement over