On Mon, Aug 19, 2019 at 7:29 PM Sam Hartman wrote:
> Your entire argument is built on the premise that it is actually
> desirable for these applications (compilers, linkers, etc) to work in
> 32-bit address spaces.
that's right [and in another message in the thread it was mentioned
that builds h
On Wed, Aug 14, 2019 at 5:13 PM Aurelien Jarno wrote:
> > a proper fix would also have the advantage of keeping linkers for
> > *other* platforms (even 64 bit ones) out of swap-thrashing, saving
> > power consumption for build hardware and costing a lot less on SSD and
> > HDD regular replacement
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Thu, Aug 8, 2019 at 9:39 PM Aurelien Jarno wrote:
> We are at a point were we should probably look for a real solution
> instead of relying on tricks.
*sigh* i _have_ been pointing out for several years now that thi
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Aug 9, 2019 at 1:49 PM Ivo De Decker wrote:
>
> Hi Aurelien,
>
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
>
> > 32-bit processes are able to address at maximum 4GB of memory (2^32),
> > and often less (2 or 3GB)
On Thursday, May 17, 2012, Steve McIntyre wrote:
> On Wed, May 16, 2012 at 09:18:38PM +0200, Mike Hommey wrote:
>
> >> >Would it be worth trying to link with gold for these?
> >>
> >> It might be, yes. I can try that with iceweasel on an imx53 or Panda
> >> with 1GB if you like. Are there any non
On Tue, Jan 8, 2019 at 7:26 AM Luke Kenneth Casson Leighton
wrote:
>
> On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton
> wrote:
> trying this:
>
> $ python evil_linker_torture.py 3000 400 200 50
>
> running with "make -j4" is going to take a few
On Tue, Jan 8, 2019 at 7:01 AM Luke Kenneth Casson Leighton
wrote:
> i'm going to see if i can get above the 4GB mark by modifying the
> Makefile to do 3,000 shared libraries instead of 3,000 static object
> files.
fail. shared libraries link extremely quickly. reverted to
$ python evil_linker_torture.py 3000 100 100 50
ok so that managed to get up to 1.8GB resident memory, paused for a
bit, then doubled it to 3.6GB, and a few seconds later successfully
outputted a binary.
i'm going to see if i can get above the 4GB mark by modifying the
Makefile to do 3,000 sh
On Tue, Jan 8, 2019 at 6:27 AM Luke Kenneth Casson Leighton
wrote:
> i'm just running the above, will hit "send" now in case i can't hit
> ctrl-c in time on the linker phase... goodbye world... :)
$ python evil_linker_torture.py 2000 50 100 200
$ make -j8
oh,
$ python evil_linker_torture.py 2000 50 100 200
ok so it's pretty basic, and arguments of "2000 50 10 100"
resulted in around a 10-15 second linker phase, which top showed to be
getting up to around the 2-3GB resident memory range. "2000 50 100
200" should start to make even a system
On Tuesday, January 8, 2019, Mike Hommey wrote:
> On Mon, Jan 07, 2019 at 11:46:41PM +0000, Luke Kenneth Casson Leighton
> wrote:
>
> > At some point apps are going to become so insanely large that not even
> > disabling debug info will help.
>
> That's less
On Tuesday, January 8, 2019, Mike Hommey wrote:
> .
>
> Note that Firefox is built with --no-keep-memory
> --reduce-memory-overheads, and that was still not enough for 32-bts
> builds. GNU gold instead of BFD ld was also given a shot. That didn't
> work either. Presently, to make things link at a
On Sun, Jan 6, 2019 at 11:46 PM Steve McIntyre wrote:
>
> [ Please note the cross-post and respect the Reply-To... ]
>
> Hi folks,
>
> This has taken a while in coming, for which I apologise. There's a lot
> of work involved in rebuilding the whole Debian archive, and many many
> hours spent analy
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* too
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 board
---
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
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.
> T
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 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 bu
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 lis
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 current
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.
>
>
---
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 point
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 Sprint
On Fri, May 31, 2013 at 3:52 AM, Ben Hutchings wrote:
> The 3.8.y branch is over, so I think we have to move to 3.9, ready or
> not. I merged the work in progress from trunk to sid and am going
> through the config changes at the moment.
>
> I'm rather disappointed that nothing at all has been c
On Wed, Jan 4, 2012 at 12:24 AM, peter green wrote:
> Luke Kenneth Casson Leighton wrote:
>>
>> On Tue, Jan 3, 2012 at 10:54 PM, Adam D. Barratt
>> wrote:
>>
>>
>>>
>>> (fwiw, the not-yet-built list includes webkit and ruby1.9.1, each of
&g
On Tue, Jan 3, 2012 at 11:04 PM, Luke Kenneth Casson Leighton
wrote:
> anything outside of that - even by a marginal amount - will result in
> the build machine absolutely thrashing its nuts off.
[for anything in excess of 24 hours].
--
To UNSUBSCRIBE, email to debian-releas
On Tue, Jan 3, 2012 at 10:54 PM, Adam D. Barratt
wrote:
> (fwiw, the not-yet-built list includes webkit and ruby1.9.1, each of
> which have a number of other packages directly or indirectly stuck
> behind them).
ahh... webkit. do you have a system anywhere that has 2gb of RAM?
if not, i strong
On Mon, Jul 25, 2005 at 05:52:54PM -0700, Steve Langasek wrote:
> On Tue, Jul 26, 2005 at 12:45:48AM +0100, Luke Kenneth Casson Leighton wrote:
> > On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
>
> > for this P120 (whatever) i have *shudder* had to use a
>
On Mon, Jul 25, 2005 at 05:06:49PM -0700, Steve Langasek wrote:
> Incidentally, I have no idea why this bug was filed against
> kernel-image-2.6-686;
... because i believed it to be a... wossisname... dummy package
(2.6.N ... 2.6.NN)
oops.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wit
On Mon, Jul 25, 2005 at 03:51:22PM -0700, Matt Taggart wrote:
> It would probably be a good idea to record what ought to work in any given
> release and maybe have an ongoing idea what it should be. The answer might be
> architecture specific? ISTR either the d-i team or apt/dpkg/aptitude tryin
On Mon, Jul 25, 2005 at 04:17:10PM -0700, Matt Taggart wrote:
> debian-release cc'd due to minimum system requirement stuff mentioned in a
> previous message...
>
> Luke Kenneth Casson Leighton writes...
>
> > my bug report invites you to consider the impact that s
33 matches
Mail list logo
