* Florian Weimer:
>> * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
>>in GCC
>>(Raised by the GCC maintainer; carried over from stretch)
>
> I'm surprised to read this. ppc64el features prominently in the
> toolchain work I do (though I personally do not work on
Paul Gevers wrote:
> As part of the interim architecture qualification for bullseye, we
> request that DSA, the security team, Wanna build, and the toolchain
> maintainers review and update their list of known concerns for bullseye
> release architectures.
There's nothing really of concern from
I don't know if this should be a blocker, but the MIPS builders are
still extremely slow for kernel builds. In the worst case (mipsel:
mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
than the next slowest group of builders (armhf: hasse, henze, holby).
This can be a problem
On 7/8/20 9:21 PM, Paul Gevers wrote:
> Hi,
>
> [Note, this e-mail may look familiar as it is mostly copied over from
> the buster call, not much has changed, AFAICT].
>
> As part of the interim architecture qualification for bullseye, we
> request that DSA, the security team, Wanna build, and
* Paul Gevers:
> * Concern for armel and armhf: only secondary upstream support in GCC
>(Raised by the GCC maintainer; carried over from stretch and buster)
glibc upstream lately has trouble finding qualified persons to
implement security fixes for the 32-bit Arm architecture.
> * Concern
Hi,
[Note, this e-mail may look familiar as it is mostly copied over from
the buster call, not much has changed, AFAICT].
As part of the interim architecture qualification for bullseye, we
request that DSA, the security team, Wanna build, and the toolchain
maintainers review and update their
This thread went OT talking about ports, but oh well…
On Wed, Dec 12, 2018 at 04:03:25AM +0100, Adam Borowski wrote:
> On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> > The build and package delivery infrastructure should offer the same features
> > for both first and second class
[Oy vey, crosspost list from hell -- not sure how to trim...]
On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> I do think this just reinforces the point that second-class architectures
> should have better, more robust support from the Debian project.
> For example, arch-specific
Hi Adrian
I do think this just reinforces the point that second-class architectures
should have better, more robust support from the Debian project.
For example, arch-specific packages most decidedly have a place in Debian
(although they should not be the norm). There will always be such
Hello!
On 12/9/18 3:18 PM, Matthias Klose wrote:
> To me it looks sometimes that Debian is used for testing by upstream, and for
> that the mips architectures don't need to be release architectures.
A note on this: If you decide to move MIPS to Debian Ports, you will make the
port unusable to
On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier 于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent
Niels Thykier 于2018年6月28日周四 上午4:06写道：
>
> Hi,
>
>
> As part of the interim architecture qualification for buster, we request
> that DSA, the security team and the toolchain maintainers review and
> update their list of known concerns for buster release architectures.
>
> Summary of the current
spoke again to TL and asked if pine64 would be willing to look at
sponsorship witn rockpro64 boards (the ones that take 4x PCIe): if
someone from debian were to contact him direct he would happily
consider it.
i then asked him if i could cc him into this discussion and he said he
was way *way*
On Fri, Jun 29, 2018 at 8:13 PM, Luke Kenneth Casson Leighton
wrote:
> On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote:
>
>>> also worth noting, they're working on a 2U rackmount server which
>>> will have i think something insane like 48 Rock64Pro boards in one
>>> full-length case.
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jun 29, 2018 at 8:31 PM, Florian Weimer wrote:
> * Luke Kenneth Casson Leighton:
>
>> that is not a surprise to hear: the massive thrashing caused by the
>> linker phase not being possible to be RAM-resident
* Luke Kenneth Casson Leighton:
> that is not a surprise to hear: the massive thrashing caused by the
> linker phase not being possible to be RAM-resident will be absolutely
> hammering the drives beyond reasonable wear-and-tear limits. which is
> why i'm recommending people try
On Fri, Jun 29, 2018 at 6:59 PM, Jonathan Wiltshire wrote:
>> also worth noting, they're working on a 2U rackmount server which
>> will have i think something insane like 48 Rock64Pro boards in one
>> full-length case.
> None of this addresses the basic DSA requirement of remote management.
>
On Fri, Jun 29, 2018 at 06:29:48PM +0200, Geert Uytterhoeven wrote:
> Are you sure you're not interchanging A8 and A9, cfr. Linux kernel commit
> e388b80288aade31 ("ARM: spectre-v2: add Cortex A8 and A15 validation of the
> IBE bit")?
Yes. That is the main reason the A9 is faster than the A8 at
On Fri, Jun 29, 2018 at 06:05:55PM +0100, Luke Kenneth Casson Leighton wrote:
> apologies for repeating it again: this is why i'm recommending people
> try "-Wl,--no-keep-memory" on the linker phase as if it works as
> intended it will almost certainly drastically reduce memory usage to
> the
On Fri, Jun 29, 2018 at 5:21 PM, Steve McIntyre wrote:
>>2G is also way too little memory these days for a new buildd.
>
> Nod - lots of packages are just too big for that now.
apologies for repeating it again: this is why i'm recommending people
try "-Wl,--no-keep-memory" on the linker phase
Hi Lennart,
debian-ports -> debian-arm
On Fri, Jun 29, 2018 at 5:00 PM Lennart Sorensen
wrote:
> On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
> > in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> > being a notable exception) which means it's
On Fri, Jun 29, 2018 at 11:23:25AM +0200, Julien Cristau wrote:
>On 06/29/2018 09:16 AM, Uwe Kleine-König wrote:
>>>
>>> [DSA Sprint report]:
>>> https://lists.debian.org/debian-project/2018/02/msg4.html
>>
>> In this report Julien Cristau wrote:
>>
>>> In short, the hardware (development
On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote:
> in addition, arm64 is usually speculative OoO (Cavium ThunderX V1
> being a notable exception) which means it's vulnerable to spectre and
> meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you
> want
On Fri, Jun 29, 2018 at 12:50 PM, Julien Cristau wrote:
> Everyone, please avoid followups to debian-po...@lists.debian.org.
> Unless something is relevant to *all* architectures (hint: discussion of
> riscv or arm issues don't qualify), keep replies to the appropriate
> port-specific mailing
On 06/27/2018 10:03 PM, Niels Thykier wrote:
> Hi,
>
>
> As part of the interim architecture qualification for buster, we request
> that DSA, the security team and the toolchain maintainers review and
> update their list of known concerns for buster release architectures.
>
Everyone, please
On Fri, Jun 29, 2018 at 12:23 PM, Adam D. Barratt
wrote:
>> i don't know: i'm an outsider who doesn't have the information in
>> short-term memory, which is why i cc'd the debian-riscv team as they
>> have current facts and knowledge foremost in their minds. which is
>> why i included them.
>
On Fri, 2018-06-29 at 11:44 +0100, Luke Kenneth Casson Leighton wrote:
[...]
> On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt
> wrote:
>
> > > what is the reason why that package is not moving forward?
> >
> > I assume you're referring to the dpkg upload that's in proposed-
> > updates
> >
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jun 29, 2018 at 10:35 AM, Adam D. Barratt
wrote:
>> what is the reason why that package is not moving forward?
>
> I assume you're referring to the dpkg upload that's in proposed-updates
> waiting for the
On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton wrote:
[...]
> debian-riscv has been repeatedly asking for a single zero-impact
> line
> to be included in *one* file in *one* dpkg-related package which
> would
> allow riscv to stop being a NMU architecture and become part of
>
On Wed, Jun 27, 2018 at 9:03 PM, Niels Thykier wrote:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
[other affected 32-bit architectures removed but still relevant]
... i'm
* Niels Thykier:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
Fedora is facing an issue running armhf under virtualization on arm64:
Breno Leitao:
> Hi Niels,
>
> On 06/27/2018 05:03 PM, Niels Thykier wrote:
>
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent
Hi Niels,
On 06/27/2018 05:03 PM, Niels Thykier wrote:
> List of concerns for architectures
> ==
>
> The following is a summary from the current architecture qualification
> table.
>
> * Concern for ppc64el and s390x: we are dependent on sponsors for
>
Hi,
As part of the interim architecture qualification for buster, we request
that DSA, the security team and the toolchain maintainers review and
update their list of known concerns for buster release architectures.
Summary of the current concerns and issues:
* DSA have announced a blocking
34 matches
Mail list logo
