* 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
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
* Riku Voipio:
> On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
>> * Niels Thykier:
>>
>> > armel/armhf:
>> >
>> >
>> > * Undesirable to keep the hardware running beyond 2020. armhf VM
>> >support uncertain. (DSA)
>> >- Source: [DSA Sprint report]
>>
>>
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 08:27:09AM +, Riku Voipio wrote:
>On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
>> * Niels Thykier:
>>
>> > armel/armhf:
>> >
>> >
>> > * Undesirable to keep the hardware running beyond 2020. armhf VM
>> >support uncertain. (DSA)
>>
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
On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
> * 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
* 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:
29 matches
Mail list logo
