Hi,
2018-06-29 11:35 GMT+02:00 Adam D. Barratt :
> On Fri, 2018-06-29 at 10:20 +0100, Luke Kenneth Casson Leighton 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 point
Processing changes file: dpkg_1.18.25_amd64+1.changes
ACCEPT
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, 2018-06-29 at 22:33 +0100, Ben Hutchings wrote:
> On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier wrote:
> > > If the issues and concerns from you or your team are not up to date,
> > > then please follow up to this email (keeping debian-release@l.d.o and
> >
Processing changes file: dpkg_1.18.25_amd64.changes
REJECT
On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> Niels Thykier wrote:
> > If the issues and concerns from you or your team are not up to date,
> > then please follow up to this email (keeping debian-release@l.d.o and
> > debian-ports@l.d.o in CC to ensure both parties are notified).
>
Processing changes file: dpkg_1.18.25_amd64.changes
REJECT
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.
Niels Thykier wrote:
> If the issues and concerns from you or your team are not up to date,
> then please follow up to this email (keeping debian-release@l.d.o and
> debian-ports@l.d.o in CC to ensure both parties are notified).
Two issues that we discussed at the recent Security Team sprint wrt
---
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
Control: forwarded -1 https://release.debian.org/transitions/html/python3.7.html
On Thu, Jun 28, 2018 at 08:48:39AM +0200, Matthias Klose wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Please setup a tracker to
Processing control commands:
> forwarded -1 https://release.debian.org/transitions/html/python3.7.html
Bug #902582 [release.debian.org] (some kind of) transition: add python3.7 as a
supported python3 version
Set Bug forwarded-to-address to
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
Processing control commands:
> block 902582 by -1
Bug #902582 [release.debian.org] (some kind of) transition: add python3.7 as a
supported python3 version
902582 was not blocked by any bugs.
902582 was not blocking any bugs.
Added blocking bug(s) of 902582: 902702
--
902582:
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
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
The OpenStack image, as released in Stretch at this URL:
http://cdimage.debian.org/cdimage/openstack/current-9/
suffers from a very annoying "feature": it has
> On Jun 29, 2018, at 9:50 AM, Jonathan Wiltshire wrote:
>
>> On Fri, Jun 29, 2018 at 11:04:26PM +0900, Roger Shimizu wrote:
>> I see armel is already not a candidate for buster [0].
>> So it seems we can discuss armhf, but no armel at all.
>> I don't agree with this idea.
>> And I think we
On Fri, Jun 29, 2018 at 11:04:26PM +0900, Roger Shimizu wrote:
> I see armel is already not a candidate for buster [0].
> So it seems we can discuss armhf, but no armel at all.
> I don't agree with this idea.
> And I think we should treat armel and armhf equally.
Please review the mail which
On Friday 29 June 2018 10:28:33 Samuel Thibault wrote:
> Roger Shimizu, le ven. 29 juin 2018 23:04:26 +0900, a ecrit:
> > On Fri, Jun 29, 2018 at 10:04 PM, Uwe Kleine-König
> >
> > wrote:
> > > On 06/29/2018 11:23 AM, Julien Cristau wrote:
> > >> 2G is also way too little memory these days for a
On Fri, Jun 29, 2018 at 3:28 PM, Samuel Thibault wrote:
> Roger Shimizu, le ven. 29 juin 2018 23:04:26 +0900, a ecrit:
>> On Fri, Jun 29, 2018 at 10:04 PM, Uwe Kleine-König
>> wrote:
>> > On 06/29/2018 11:23 AM, Julien Cristau wrote:
>> >> 2G is also way too little memory these days for a new
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
Open Network Linux developed for the Open Compute Project has a vested
interest in maintaining support for armel at least. I would be interested
in sponsoring or donating rack mountable switches using armel processors.
On Fri, Jun 29, 2018 at 3:04 AM, W. Martin Borgert
wrote:
> Quoting Uwe
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I've prepared an update to python-proliantutils which fixes FTBFS when
there is internet connectivity in the build host. Please find the diff
attached to this
Roger Shimizu, le ven. 29 juin 2018 23:04:26 +0900, a ecrit:
> On Fri, Jun 29, 2018 at 10:04 PM, Uwe Kleine-König
> wrote:
> > On 06/29/2018 11:23 AM, Julien Cristau wrote:
> >> 2G is also way too little memory these days for a new buildd.
> >
> > Then the machine is out, the amount of RAM isn't
On Fri, Jun 29, 2018 at 10:04 PM, Uwe Kleine-König
wrote:
> Hello Julien,
>
> On 06/29/2018 11:23 AM, Julien Cristau wrote:
>>> If the concerns are mostly about the hardware not being rackable, there
>>> is a rackable NAS by Netgear:
>>>
>>>
>>>
Hello Julien,
On 06/29/2018 11:23 AM, Julien Cristau wrote:
>> If the concerns are mostly about the hardware not being rackable, there
>> is a rackable NAS by Netgear:
>>
>>
>> https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs
>>
>> with an armhf cpu. Not
Processing control commands:
> clone -1 -2
Bug #901085 [src:libur-perl] libur-perl: FTBFS with Perl 5.28: test failures
Bug 901085 cloned as bug 902674
902557 was blocked by: 901082 900232 900832 899021 862678 902556 887687 901080
629405 901085
902557 was not blocking any bugs.
Added blocking
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:06 PM, John Paul Adrian Glaubitz
wrote:
> On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:
>> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König
>> wrote:
>>
In short, the hardware (development boards) we're currently using to
build armel and armhf
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
> >
On 06/29/2018 10:41 AM, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König
> wrote:
>
>>> In short, the hardware (development boards) we're currently using to
>>> build armel and armhf packages aren't up to our standards, and we
>>> really, really want them
---
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
Quoting Uwe Kleine-König :
If the concerns are mostly about the hardware not being rackable, there
is a rackable NAS by Netgear:
https://www.netgear.com/business/products/storage/readynas/RN2120.aspx#tab-techspecs
This seems to be out of stock and discontinued, unfortunately.
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
>
[s/debian-ports/debian-arm/]
On 06/29/2018 09:16 AM, Uwe Kleine-König wrote:
> Hello,
>
> On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
>> armel/armhf:
>>
>>
>> * Undesirable to keep the hardware running beyond 2020. armhf VM
>>support uncertain. (DSA)
>>-
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 Fri, Jun 29, 2018 at 8:16 AM, Uwe Kleine-König
wrote:
> Hello,
>
> On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
>> armel/armhf:
>>
>>
>> * Undesirable to keep the hardware running beyond 2020. armhf VM
>>support uncertain. (DSA)
>>- Source: [DSA
Processing control commands:
> severity -1 serious
Bug #629405 [src:debconf] libqtgui4-perl based frontend might need to be removed
Severity set to 'serious' from 'wishlist'
> block 902557 with -1
Bug #902557 [release.debian.org] transition: Perl 5.28
902557 was blocked by: 862678 901085 901082
Hello,
On Wed, Jun 27, 2018 at 08:03:00PM +, Niels Thykier wrote:
> armel/armhf:
>
>
> * Undesirable to keep the hardware running beyond 2020. armhf VM
>support uncertain. (DSA)
>- Source: [DSA Sprint report]
>
> [DSA Sprint report]:
>
46 matches
Mail list logo
