Re: Really enable -fstack-clash-protection on armhf/armel?

2023-11-27 Thread Moritz Muehlenhoff
On Fri, Nov 24, 2023 at 01:34:21AM +0100, Guillem Jover wrote: > > Is that a feature that the Debian ARM32 porters and the security team really > > want to support actively, despite the missing upstream support? > > According to https://bugs.debian.org/918914#73 there were no pending > toolchain

Re: Supporting armel/armhf in wheezy-lts

2016-04-24 Thread Moritz Muehlenhoff
On Sun, Apr 24, 2016 at 09:55:10AM +0200, Raphael Hertzog wrote: > > https://wiki.debian.org/LTS/ makes it appear that LTS is an official Debian > > effort. > > And it is. There are multiple Debian developers who have initiated this > project, have been organizing it on

Re: gcc-5: guile-2.0 fails to build with offset problem on armel

2015-08-31 Thread Moritz Muehlenhoff
On Mon, Aug 24, 2015 at 06:54:49PM -0500, Rob Browning wrote: > > Feel free to downgrade this if you think appropriate, but given that 4.8 > is scheduled to be removed from stretch at some point, this will > eventually become grave for guile-2.0. (The problem appears to affect > gcc-4.9 as

Re: Bug#722610: yorick-av: FTBFS on armhf: ERROR (*main*) Segmentation violation interrupt (SIGSEGV)

2013-10-08 Thread Moritz Muehlenhoff
On Thu, Sep 12, 2013 at 08:53:07PM +0200, Sebastian Ramacher wrote: Source: yorick-av Version: 0.0.1-3 Severity: serious Justification: FTBFS but built successfully in the past Tags: sid jessie Control: block 706798 by -1 yorick-av currently fails to build on armhf: |dh_auto_test |

Re: armel boxes for Debian

2008-02-24 Thread Moritz Muehlenhoff
On Wed, Feb 20, 2008 at 07:44:30PM -0500, Joey Hess wrote: Moritz Muehlenhoff wrote: We could just declare arm a second-class architecture for security updates, i.e. DSAs being released once all archs are available except arm and arm updates being released once available. For small

Re: armel boxes for Debian

2008-02-20 Thread Moritz Muehlenhoff
On Wed, Feb 20, 2008 at 06:12:10PM -0500, Joey Hess wrote: Riku Voipio wrote: The security buildd is a different story. Parallell buildd's compiling several packages at time don't help[1], they want single builds completed fast, so they can release security advisories with minimal delay.

Re: Security buildd for armel

2008-02-08 Thread Moritz Muehlenhoff
On Fri, Feb 08, 2008 at 07:39:50PM +, Martin Guy wrote: 2008/2/8, Daniel Jacobowitz [EMAIL PROTECTED]: On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote: So, these Intel boards are _badly_ needed. Or maybe the buildd can be run in qemu on a fast amd64 machine, I don't

Re: Security buildd for armel

2008-02-08 Thread Moritz Muehlenhoff
On Fri, Feb 08, 2008 at 12:17:23PM -0600, Bill Gatliff wrote: Moritz Muehlenhoff wrote: Also there are four updates for iceweasel, xulrunner, icedove and iceape coming very soon, which take 12-15 hours each, while the second slowest arch requires ca. 4-5 hours, imposing another delay

Re: Security buildd for armel

2008-02-08 Thread Moritz Muehlenhoff
On Mon, Feb 04, 2008 at 01:05:29PM +0200, Riku Voipio wrote: On Sun, Feb 03, 2008 at 11:01:01PM +0100, Moritz Muehlenhoff wrote: I have a question wrt armel qualification for Lenny: What type of machine is planned to be used as the security buildd? Generally buildd's are handled

Re: Some thoughts on the ARM build daemons

2007-05-08 Thread Moritz Muehlenhoff
Aurelien Jarno wrote: - tofee: up, building packages, sometimes stable-security. I think it is time to changes things. Our faster build daemons have a 233MHz CPU with 256MB of RAM, while there are way faster ARM CPU today. How much faster is the fastest available ARM CPU compared to toffee?