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
---
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.
>
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
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 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 us
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
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
On Fri, Feb 3, 2012 at 5:48 AM, Stephen Kitt st...@sk2.org wrote:
Hi Peter,
On Fri, Feb 03, 2012 at 02:36:17AM +, peter green wrote:
Libreoffice hasn't yet been built on armhf. I consider libreoffice
to be a reasonablly important package and one that we need to get in
before we can claim
On Sat, Feb 25, 2012 at 2:04 PM, Rene Engelhard r...@debian.org wrote:
Hi,
On Sat, Feb 25, 2012 at 01:49:02PM +, Luke Kenneth Casson Leighton wrote:
it's even more hilarious than that: it's actually because java can't
access windows registry functions, so someone wrote a c-based DLL
On Thu, Jan 06, 2005 at 07:31:59PM +0100, Falk Hueffner wrote:
Luke Kenneth Casson Leighton [EMAIL PROTECTED], [EMAIL PROTECTED] schrieb
am 06.01.05 19:10:48:
math ops - and - cannot be performed with constants 32-bit!
I don't see that.
#define TEST 0x1
unsigned long
../../../khtml/ecma/kjs_html.cpp:1237: error: Non-addressable variable
inside an alias set.
.GLOBAL_VAR, UID 3058, is an alias tag, is static, call clobbered,
default def: .GLOBAL_VAR_45
TMT.34829, UID 3040, is an alias tag, is global, call clobbered, default
def: TMT.34829_617, may aliases: {
Package: libstdc++5
Version: 1:3.3.3-8
Severity: normal
i don't know how it happened and i have not been modifying anything
other than by doing regular apt-get installs of packages.
somehow i end up with a link from libstdc++.so to .5.0.0 instead
of .5.0.6 and yet /usr/lib/libstdc++.5.0.0 does
On Wed, May 21, 2003 at 11:49:33AM +0200, Gregor Hoffleit wrote:
* Joel Baker [EMAIL PROTECTED] [030521 09:08]:
If it isn't finding things in /lib by default, someone has a rather serious
bug on their hands. Check the version of ldconfig and kin?
AFAICS, the problem is not that the
On Wed, May 21, 2003 at 11:47:14AM +0200, Gregor Hoffleit wrote:
Indeed, on all machines I checked, /lib was not in /etc/ld.so.conf (nor
was /usr/lib on most machines).
So the real cause for your trouble, Luke, appearently is the presence of
that libgcc1_so file in /usr/lib. AFAICS, adding
On Tue, May 20, 2003 at 11:59:25AM +0200, Gregor Hoffleit wrote:
* Luke Kenneth Casson Leighton [EMAIL PROTECTED] [030519 18:39]:
On Mon, May 19, 2003 at 10:16:50AM -0500, Skip Montanaro wrote:
Luke gcc 3.3 is now the latest for unstable.
Luke gcc 3.3 contains a package
On Tue, May 20, 2003 at 11:05:17PM +0200, Matthias Klose wrote:
- add /lib to /etc/ld.so.conf before /usr/lib
- install the new libgcc1
- then upgrade other packages.
It seems to be a local problem with your installation, else we had
more than one bug report ... I'm downgrading the report
Package: libgcc1
Version: 1:3.2.3-0pre6
Severity: critical
actions taken:
apt-get remove jade
this required, at this time, the installation / upgrade of libgcc1
and the installation / upgrade of tetex.
gcc 3.3 and cpp 3.3 was NOT required as part of that installation / upgrade.
once
21 matches
Mail list logo
