Re: The future of mipsel port

[Mathieu Malaterre]

On Tue, Jul 18, 2023 at 6:46 AM YunQiang Su  wrote:
[...]
> Known supported hardwares:
> MIPS P5600
> Ingenic X2000
> Loongson 3A4000

Could you confirm that MIPS Creator CI20 (Ingenic JZ4780) would not be
supported anymore ?

Thanks

Re: Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Mathieu Malaterre]

On Fri, Dec 9, 2022 at 10:29 AM Andreas Tille  wrote:
>
> Hi Mathieu,
>
> Am Tue, Dec 06, 2022 at 08:38:43AM +0100 schrieb Mathieu Malaterre:
> > I do not have a clean answer to this, but in my experience it is
> > getting more and more difficult to compile anything on mipsel with
> > g++-12. The default option `-g -O2` seems to imply `take as much
> > memory as you want to get things to compile` so this end up crossing
> > the 2GB hard-limit.
> >
> > For example here is what webkit is doing to work around the symptoms:
> >
> > * 
> > https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71
>
> Thanks for the hint.  I tried this but this does not work since the R
> build system does not respect external set variables.  Since chances
> are really low that this package will be used on mipsel I asked for
> removal on this architecture.

Totally agree! Let's start the cabal against mipsel as a release arch.

Playing the giveback lotery

[Mathieu Malaterre]

[cc me please]

Dear mipsel porter(s),

Could someone please confirm that all mipsel buildds are pretty much
identical ? I am looking for a beefier machine to compile a multimedia
specific package that used to be available on that arch ?

For reference:

* 
https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=10.0.0-11=1670380412=0

Thanks

Re: Bug#1025203: r-cran-glmmtmb: FTBFS on mipsel

[Mathieu Malaterre]

I do not have a clean answer to this, but in my experience it is
getting more and more difficult to compile anything on mipsel with
g++-12. The default option `-g -O2` seems to imply `take as much
memory as you want to get things to compile` so this end up crossing
the 2GB hard-limit.

For example here is what webkit is doing to work around the symptoms:

* 
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.39.1-1/debian/rules#L66-71

Previous reports on this issue:

* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882490
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78971

On Tue, Dec 6, 2022 at 8:10 AM Andreas Tille  wrote:
>
> Ping?  If this can't be clarified I'd probably ask ftpmaster for removal
> of the package for mipsel.
> Kind regards, Andreas.
>
> Am Thu, Dec 01, 2022 at 07:15:27AM +0100 schrieb Andreas Tille:
> > Hi,
> >
> > Am Wed, Nov 30, 2022 at 10:08:14PM +0100 schrieb Paul Gevers:
> > > Source: r-cran-glmmtmb
> > > Version: 1.1.4+dfsg-3
> > > Severity: serious
> > > Tags: ftbfs
> > > Justification: ftbfs
> > >
> > > Dear maintainer(s),
> > >
> > > Your package failed to build from source on mipsel, where it built
> > > successfully in the past.
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=r-cran-glmmtmb=mipsel=1.1.5%2Bdfsg-1=1669057119=0
> > > ...
> > > cc1plus: out of memory allocating 1058400 bytes after a total of 59473920 
> > > bytes
> >
> > Isn't this just a matter of the autobuilders hardware?
> >
> > If not I do not see any other clue but removing the package for mipsel.
> >
> > Kind regards
> >
> >  Andreas.
> >
> > --
> > http://fam-tille.de
>
> --
> http://fam-tille.de
>

Re: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM

[Mathieu Malaterre]

On Thu, Sep 29, 2022 at 9:14 AM Mathieu Malaterre  wrote:
>
> On Wed, Sep 28, 2022 at 10:06 PM Andreas Tille  wrote:
> >
> > Hi mips porters,
> >
> > in bug #1017752 a
> >
> >FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory
> >
> > is reported.  This remains for the new upstream version I've just
> > uploaded to experimental[1].  Do you see any chance to fix the memory
> > constraint for the autobuilder VM?  If not I'll remove mipsel from the
> > list of supported architectures to enable testing migration.
>
> Here is the trick I used on those arches for openvdb:
>
> [...]
> # Disable optimization on mipsel because the compiler is running out of memory
> # see #847752 / #879636
> ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
> riscv64 sh4 x32))
>   CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
> endif
> [...]
>
> https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-7/debian/rules#L22-26

Here is another simpler one:

* 
https://salsa.debian.org/webkit-team/webkit/-/blob/debian/2.38.0-1/debian/rules#L66

Re: Do you see any chance to fix the "virtual memory exhausted" for nheko on mipsel VM

[Mathieu Malaterre]

On Wed, Sep 28, 2022 at 10:06 PM Andreas Tille  wrote:
>
> Hi mips porters,
>
> in bug #1017752 a
>
>FTBFS on mipsel: virtual memory exhausted: Cannot allocate memory
>
> is reported.  This remains for the new upstream version I've just
> uploaded to experimental[1].  Do you see any chance to fix the memory
> constraint for the autobuilder VM?  If not I'll remove mipsel from the
> list of supported architectures to enable testing migration.

Here is the trick I used on those arches for openvdb:

[...]
# Disable optimization on mipsel because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH), armel armhf i386 mipsel hppa
riscv64 sh4 x32))
  CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif
[...]

https://salsa.debian.org/multimedia-team/openvdb/-/blob/debian/9.1.0-7/debian/rules#L22-26

mips: executable-stack-in-shared-library

[Mathieu Malaterre]

[cc me please]

Dear mips porter,

Upstream of one of my package is trying to provide a fix for the
lintian report:executable-stack-in-shared-library (*)

Basically the patch is as follow (**):

[...]
if (HWY_ARCH MATCHES "mips")
  target_link_options(hwy PUBLIC "LINKER:-z,noexecstack")
endif (HWY_ARCH MATCHES "mips")
[...]

Could someone please confirm this is the "right" patch. I fail to
understand why each and every source package would need to change the
default LDFLAGS value...

Thanks for suggestion/help

-M

(*) https://udd.debian.org/lintian/?packages=highway
(**) https://github.com/google/highway/issues/988

Re: mipsel out-of-memory building dolfinx 0.4.0

[Mathieu Malaterre]

On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons  wrote:
>
> On 2022-06-13 10:01, Mathieu Malaterre wrote:
> > On Sun, Jun 12, 2022 at 11:38 PM Drew Parsons 
> > wrote:
> >>
> >> Hi MIPS porters, I need helping with the build of fenics-dolfinx on
> >> mipsel from experimental,
> >> https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental
> >>
> >> It previously built fine, but the latest version 1:0.4.1 has evidently
> >> grown large enough to break on mipsel.
> >
> > Here is what I used in openvdb:
> >
> > https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L28-32
> >
> > # Disable optimization on mips* because the compiler is running out of
> > memory
> > # see #847752 / #879636
> > ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips mipsel sh4))
> > CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
> > endif
>
> Thanks Mathieu, I'll try that and see if gc-min-expand helps.
>
> But I'm starting to suspect I have two separate problems.  First I need
> to compile the object files, and running out of memory is the problem
> there. Fixed by reducing -O (ggc-min-expand might help also).
>
> But after that, there's the problem linking, with "relocation
> truncated".  Am I right to think that's not an issue of available RAM as
> such, but rather it means the address space required by object files has
> started to exceed 32-bits?
>
> I'll upload a fenics-dolfinx 1:0.4.1-1exp3 to get the "relocation
> truncated" error on the buildlog record.
>
> How would we usually manage "relocation truncated" linking errors?

I've never used it myself. But it appears to be the option "-mxgot":

* https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

Re: mipsel out-of-memory building dolfinx 0.4.0

[Mathieu Malaterre]

On Sun, Jun 12, 2022 at 11:38 PM Drew Parsons  wrote:
>
> Hi MIPS porters, I need helping with the build of fenics-dolfinx on
> mipsel from experimental,
> https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental
>
> It previously built fine, but the latest version 1:0.4.1 has evidently
> grown large enough to break on mipsel.

Here is what I used in openvdb:

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L28-32

# Disable optimization on mips* because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips mipsel sh4))
CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif

Re: Explicitly linking -latomic

[Mathieu Malaterre]

Hi Joachim

On Sun, Feb 20, 2022 at 7:24 PM Joachim Reichel
 wrote:
>
> Dear mips porters,
>
> I would like to get your input on bug #1005696. Is every C++ program using
>  supposed to add architecture-specific code to its build system to 
> link
> with -latomic on mipsel?

Yes !

 (Which apparently is not necessary on other
> architectures.)

If you are unlucky, you'll need to tweak armel, mispel, powerpc and riscv64.

> Or is this some implementation detail that the compiler/linker
> should take care of automatically?

The issue will not be fixed at cmake level, and fixing it at the spec
level of gcc has proved to be difficult:

* https://gitlab.kitware.com/cmake/cmake/-/issues/23021

Basically you'll need to maintain your own libatomic patch...

> Best regards,
>Joachim
>

Re: Testsuite failure on mips64el, solved with '-fno-inline'

[Mathieu Malaterre]

Dear Håvard,

On Mon, Dec 6, 2021 at 1:33 PM Håvard Flaget Aasen
 wrote:
>
> Hello,
>
> I've had some issues with the package c-blosc. The testsuite started
> to fail on mips64el. I found a solution, adding  '-fno-inline' in
> CFLAGS in d/rules.
>
> Does this seem to be a valid solution or, does it only hide a problem
> with the source code?
> There are a couple of things I find strange, the testsuite only failed
> on mips64el and only after GCC-11 was the default compiler, (several
> other packages have also been updated), though it doesn't need to be
> related.

I suspect that `-fno-inline` is simply not the right solution. Of
course, the right solution would be for gcc-11 to properly compile the
code, but I would suggest a slightly more specific solution in the
meantime. I would suggest:

ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips64el))
CFLAGS+=-O1
endif

^ -O1 will be added at the end of the compilation flags, and will
override the current -02.

If that works, we should forward the issue back to gcc people.

Thanks for your work on c-blosc.

-M

Re: MIPS-specific porting issue

[Mathieu Malaterre]

Salut Stéphane,

On Fri, Dec 3, 2021 at 10:19 AM Stéphane Glondu  wrote:
>
> Dear MIPS porters,
>
> I am debugging ocaml-mirage-crypto build on mipsel.
>
> It uses the following code:
>
> > #if defined (__i386__) || defined (__x86_64__)
> >   return Val_long (__rdtsc ());
> > #elif defined (__arm__) || defined (__aarch64__)
> >   return Val_long (read_virtual_count ());
> > #elif defined(__powerpc64__)
> >   return Val_long (read_cycle_counter ());
> > #elif defined(__riscv) && (64 == __riscv_xlen)
> >   return Val_long (rdcycle64 ());
> > #elif defined (__s390x__)
> >   return Val_long (getticks ());
> > #else
> > #error ("No known cycle-counting instruction.")
> > #endif
>
> I have trouble finding a suitable implementation for this on mipsel.
> Would you have a hint?

All I could find is this code (untested):

https://salsa.debian.org/science-team/nfft/-/blob/debian/master/include/cycle.h#L485-507

openvdb / mips64el

[Mathieu Malaterre]

Hi there,

For some reason openvdb keep on FTBFS on mips64el (mipsel-osuosl-01):

* https://buildd.debian.org/status/logs.php?pkg=openvdb=mips64el

The odd thing is that I did change a think in between the experimental
and the unstable upload, the experimental package did build fine :
7.0.0-1 (experimental) / mipsel-sil-01

Is there something specific about mipsel-osuosl-01 ?

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Mathieu Malaterre]

Aurélien,

Thanks for caring about 32bits arches !

On Thu, Aug 8, 2019 at 10:39 PM Aurelien Jarno  wrote:
[...]
> mips and mipsel are more affected by the issue as the virtual address
> space is limited to 2GB. Therefore on those architectures, this issue
> recently started to also affect core packages like ghc and rustc, and
> the usual tricks are not working anymore.
[...]

(maybe a bit naive) Another way to look at the issue is that ghc and
rustc are core packages on 32bits system. Would it make sense to start
having a separate core32 & core64 instead of a single one ?

Re: Dropping mips architecture for bullseye and sid

[Mathieu Malaterre]

Salut Aurélien !

On Sat, Jul 20, 2019 at 12:47 PM Aurelien Jarno  wrote:
>
> Dear all,
>
> The mips architecture, supporting 32-bit big-endian MIPS CPUs, has
> been supported in Debian for more than 15 years. Due to the limited 2GB
> virtual address space and due to the fact this architecture is one of
> the last big-endian architecture Debian supports, the porting effort
> is increasingly difficult. On the other hand the interest for this
> architecture is going down, and with it the human resources available
> for porting is going down.

Thanks for your dedication these last years.

> Now that buster has been released, it is probably time to drop this
> architecture from bullseye and sid. Unless there is a sudden interest
> for this architecture, that is commitment from some new porters and new
> hardware for the build daemons, the plan is to ask for the ftpmasters
> to drop this architecture in about 4 weeks.

In other words, mips is not going to debian-ports ?

> Note that many recent
> MIPS hardware support endian switching at runtime and can therefore be
> supported by the mipsel or mips64el ports. This is the case for example
> of the Octeon CPUs.
>
> Note that this *only concerns bullseye and sid*. The mips architecture
> will still be available for stretch for roughly 1 more year, and for
> buster for roughly 3 more years.
>
> Aurelien, on behalf of the MIPS porters
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net



-- 
Mathieu

Re: as: out of memory allocating 4072 bytes after a total of 546328576 bytes

[Mathieu Malaterre]

On Thu, Nov 15, 2018 at 8:07 AM Mathieu Malaterre  wrote:
>
> On Wed, Nov 14, 2018 at 3:35 PM YunQiang Su  wrote:
> >
> > YunQiang Su  于2018年11月14日周三 下午10:29写道：
> > >
> > > With read as(1), I see
> > >
> > > --reduce-memory-overheads
> > > This option reduces GAS 's memory requirements, at the expense of
> > > making the assembly processes slower. Currently this switch is a
> > > synonym for --hash-size=4051, but in the future it may have other
> > > effects as well.
> > >
> > > I guess you can have a try.
> >
> > If you need pass this option from gcc, you can use
> >-Wa,option
> >
> > https://gcc.gnu.org/onlinedocs/gcc/Assembler-Options.html#Assembler-Options
>
> Thanks for the suggestion ! That looked promising, however this did
> not turn out well:
>
> https://buildd.debian.org/status/fetch.php?pkg=openvdb=mips=5.2.0-2=1542229604=0
>
> As a side note, the message went from:
>
> as: out of memory allocating 4072 bytes after a total of 546328576 bytes
>
> to
>
> as: out of memory allocating 4072 bytes after a total of 557305856 bytes
>
> So I would even be tempted to report a bug to gcc/gas...

So it turns out that simply using -g1 seems to fix all the symptoms on
mips/mipsel (virtual memory exhausted: Cannot allocate memory
). Found it reference in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890237

OpenVDB is now building fine on mips/el.


>
>
> > > Mathieu Malaterre  于2018年11月9日周五 下午5:14写道：
> > > >
> > > > Hi mips guru,
> > > >
> > > > Could someone please comment on:
> > > >
> > > > https://buildd.debian.org/status/fetch.php?pkg=openvdb=mips=5.2.0-1=1541130852=0
> > > >
> > > > Is there a set of flags to use to reduce memory usage on 32bits system
> > > > ? For reference I am using : --param ggc-min-expand=10 -O1
> > > >
> > > > Thanks much
> > > >
> > >
> > >
> > > --
> > > YunQiang Su
> >
> >
> >
> > --
> > YunQiang Su

Re: as: out of memory allocating 4072 bytes after a total of 546328576 bytes

[Mathieu Malaterre]

On Wed, Nov 14, 2018 at 3:35 PM YunQiang Su  wrote:
>
> YunQiang Su  于2018年11月14日周三 下午10:29写道：
> >
> > With read as(1), I see
> >
> > --reduce-memory-overheads
> > This option reduces GAS 's memory requirements, at the expense of
> > making the assembly processes slower. Currently this switch is a
> > synonym for --hash-size=4051, but in the future it may have other
> > effects as well.
> >
> > I guess you can have a try.
>
> If you need pass this option from gcc, you can use
>-Wa,option
>
> https://gcc.gnu.org/onlinedocs/gcc/Assembler-Options.html#Assembler-Options

Thanks for the suggestion ! That looked promising, however this did
not turn out well:

https://buildd.debian.org/status/fetch.php?pkg=openvdb=mips=5.2.0-2=1542229604=0

As a side note, the message went from:

as: out of memory allocating 4072 bytes after a total of 546328576 bytes

to

as: out of memory allocating 4072 bytes after a total of 557305856 bytes

So I would even be tempted to report a bug to gcc/gas...



> > Mathieu Malaterre  于2018年11月9日周五 下午5:14写道：
> > >
> > > Hi mips guru,
> > >
> > > Could someone please comment on:
> > >
> > > https://buildd.debian.org/status/fetch.php?pkg=openvdb=mips=5.2.0-1=1541130852=0
> > >
> > > Is there a set of flags to use to reduce memory usage on 32bits system
> > > ? For reference I am using : --param ggc-min-expand=10 -O1
> > >
> > > Thanks much
> > >
> >
> >
> > --
> > YunQiang Su
>
>
>
> --
> YunQiang Su

as: out of memory allocating 4072 bytes after a total of 546328576 bytes

[Mathieu Malaterre]

Hi mips guru,

Could someone please comment on:

https://buildd.debian.org/status/fetch.php?pkg=openvdb=mips=5.2.0-1=1541130852=0

Is there a set of flags to use to reduce memory usage on 32bits system
? For reference I am using : --param ggc-min-expand=10 -O1

Thanks much

Re: Debian/MIPSeb: proposal to drop mipseb port?

[Mathieu Malaterre]

On Mon, Jul 9, 2018 at 12:47 PM YunQiang Su  wrote:
>
> Mathieu Malaterre  于2018年7月9日周一 下午6:31写道：
> >
> > On Mon, Jul 9, 2018 at 12:12 PM YunQiang Su  wrote:
> > >
> > > Adi Kriegisch  于2018年7月9日周一 下午4:34写道：
> > > >
> > > > Hi!
> > > >
> > > > > due to lack of enough man power and build machines for 3 mips* port at
> > > > > the same time, I think that now it is time for us to have a talk about
> > > > > dropping mips32eb support now.
> > > > [...]
> > > > > In fact I don't know anybody is using Debian's mips32eb port.
> > > > > If you are using it, please tell us.
> > > > I am using mips32eb a lot on wifi routers (self-compiled kernel with
> > > > rootfs on a usb stick). There are some people here at a community
> > > > wireless network that do use such setups on their rooftops as well.
> > > >
> > >
> > > What is the advantage of eb than el? better performance?
> > > I guess most of CPUs support both eb and el.
> > >
> > > > Please let me know if there is anything I could do to help avoiding the
> > > > drop.
> > > >
> > >
> > > We need some more build machines, current we use some ER8s,
> > > which use NFS as rootfs and they have no FPU.
> > > So the performance and stability are bad.
> >
> > Just for reference why is mips (mips32eb) not build from an mips64el
> > machine (with FPU) ? All i386 (AFAIK) packages are build from amd64
> > these days (same is true for ppc32 on ppc64).
>
> mipsel packages do build on mips64el machines,
> while mips aka mips32eb cannot.

Sorry to insist, but I thought mips & mipsel in Debian were both
MIPS32r2. So what makes mips32eb so special for MIPS64r6 ?

> >
> > > We also need some more manpower to fix the FTBFS in future.
> >
> > Is this the correct page to look at the FTBFS+mips(32eb):
> >
> > https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=mips=debian-mips%40lists.debian.org
> >
>
> Yes. It is.
>
> >
> >
> > > > best regards,
> > > > Adi Kriegisch
> > > >
> > >
> > >
> > > --
> > > YunQiang Su
> > >
>
>
>
> --
> YunQiang Su

MIPS: PT_GNU_STACK (gcc/binutils)

[Mathieu Malaterre]

On Fri, Mar 23, 2018 at 3:19 PM James Cowgill  wrote:
>
> Control: notforwarded -1
>
> Hi,
>
> On 22/03/18 14:28, Michael Biebl wrote:
> > Am 22.03.2018 um 12:31 schrieb James Cowgill:
> >> I sent a patch upstream (see above).
> >
> > Thanks!
>
> Unfortunately I've had to ask for this to be reverted:
> https://github.com/systemd/systemd/pull/8563
>
> It turns out that enabling MemoryDenyWriteExecute on MIPS causes any
> applications which use threads to fail because the MIPS toolchain
> (still) does not implement PT_GNU_STACK. So this bug is going to require
> some extra toolchain support (at least glibc and one of gcc/binutils but
> I can't remember which) to fix.

Anyone could confirm the full list of impacted tools (glibc/binutils...) ?

Re: Debian/MIPSeb: proposal to drop mipseb port?

[Mathieu Malaterre]

On Mon, Jul 9, 2018 at 12:12 PM YunQiang Su  wrote:
>
> Adi Kriegisch  于2018年7月9日周一 下午4:34写道：
> >
> > Hi!
> >
> > > due to lack of enough man power and build machines for 3 mips* port at
> > > the same time, I think that now it is time for us to have a talk about
> > > dropping mips32eb support now.
> > [...]
> > > In fact I don't know anybody is using Debian's mips32eb port.
> > > If you are using it, please tell us.
> > I am using mips32eb a lot on wifi routers (self-compiled kernel with
> > rootfs on a usb stick). There are some people here at a community
> > wireless network that do use such setups on their rooftops as well.
> >
>
> What is the advantage of eb than el? better performance?
> I guess most of CPUs support both eb and el.
>
> > Please let me know if there is anything I could do to help avoiding the
> > drop.
> >
>
> We need some more build machines, current we use some ER8s,
> which use NFS as rootfs and they have no FPU.
> So the performance and stability are bad.

Just for reference why is mips (mips32eb) not build from an mips64el
machine (with FPU) ? All i386 (AFAIK) packages are build from amd64
these days (same is true for ppc32 on ppc64).

> We also need some more manpower to fix the FTBFS in future.

Is this the correct page to look at the FTBFS+mips(32eb):

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=mips=debian-mips%40lists.debian.org



> > best regards,
> > Adi Kriegisch
> >
>
>
> --
> YunQiang Su
>

warning: #warning "Consider adding the right mmap() syscall definitions here!" [-Wcpp]

[Mathieu Malaterre]

Source: systemd
Version: 238-2
Severity: important
User: debian-mips@lists.debian.org
Usertags: mips mipsel mipsel64

There seems to be a missing code block to handle mmap/mmap2 on
mips/mipsel & mipsel64:

 % ninja
[263/1470] Compiling C object
'src/shared/systemd-shared-238@sta/seccomp-util.c.o'.
../src/shared/seccomp-util.c: In function 'seccomp_memory_deny_write_execute':
../src/shared/seccomp-util.c:1478:2: warning: #warning "Consider
adding the right mmap() syscall definitions here!" [-Wcpp]
 #warning "Consider adding the right mmap() syscall definitions here!"
  ^~~


I am not comfortable providing a patch (not clear about mmap2 + o32
for instance), hopefully someone from debian-mips@l.d.o could provide
one. Thanks.

Re: mips/mipsel: enforce --param ggc-min-expand=10 always

[Mathieu Malaterre]

Hi James,

On Thu, Nov 23, 2017 at 1:14 PM, James Cowgill <jcowg...@debian.org> wrote:
> On 23/11/17 11:42, Mathieu Malaterre wrote:
>> YunQiang,
>>
>> Do you know of any drawbacks ?
>
> This has been raised before:
> https://lists.debian.org/debian-mips/2016/10/msg00049.html
>
> I think it's generally a good idea. You wouldn't want to "enforce" this
> - you would set it as an overridable default setting.
>
> I think the disadvantages are: compilation speed, I think there is no
> official way to do this so you would have to hack the gcc source a bit,
> and deviation from upstream / other distros.

OK, in that case I'll report as bug against dpkg-buildflags instead of
gcc itself.

Thanks for the update

-M

mips/mipsel: enforce --param ggc-min-expand=10 always (was: virtual memory exhausted: Cannot allocate memory)

[Mathieu Malaterre]

YunQiang,

Do you know of any drawbacks ?

On Thu, Nov 23, 2017 at 11:29 AM, YunQiang Su <wzss...@gmail.com> wrote:
> I guess we should set this param for mips/mipsel by default?
>
> On Thu, Nov 23, 2017 at 5:20 AM, Mathieu Malaterre <ma...@debian.org> wrote:
>> On Wed, Nov 22, 2017 at 2:24 PM, Mathieu Malaterre <ma...@debian.org> wrote:
>>> Dear mips gurus,
>>>
>>> Could someone please suggest a fix for the following FTBFS issue for
>>> OpenVDB package:
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=4.0.2-1=1508213166=0
>>>
>>> Thanks much
>>
>> Turns out that --param ggc-min-expand=10 worked just fine on eller.d.o.
>>
>> Sorry for the noise,
>>
>
>
>
> --
> YunQiang Su

Re: #879636: virtual memory exhausted: Cannot allocate memory

[Mathieu Malaterre]

On Wed, Nov 22, 2017 at 2:24 PM, Mathieu Malaterre <ma...@debian.org> wrote:
> Dear mips gurus,
>
> Could someone please suggest a fix for the following FTBFS issue for
> OpenVDB package:
>
> https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=4.0.2-1=1508213166=0
>
> Thanks much

Turns out that --param ggc-min-expand=10 worked just fine on eller.d.o.

Sorry for the noise,

#849657: virtual memory exhausted: Cannot allocate memory

[Mathieu Malaterre]

Dear mips gurus,

Could someone please suggest a fix for the following FTBFS issue for
OpenVDB package:

https://buildd.debian.org/status/fetch.php?pkg=openvdb=mipsel=4.0.2-1=1508213166=0

Thanks much

Ingenic X1000 SoC or halley2 development kit?

[Mathieu Malaterre]

Hi all,

  Does anyone have access to  Ingenic X1000 SoC or halley2 development
kit ? Please contact me.

Thanks.

Fwd: Free MIPS hardware....you pay shipping.

[Mathieu Malaterre]

FYI


-- Forwarded message --
From: Steven J. Hill 
Date: Thu, Jun 15, 2017 at 7:02 PM
Subject: Free MIPS hardwareyou pay shipping.
To: linux-m...@linux-mips.org, port-sgim...@netbsd.org,
port-m...@netbsd.org, port-hpcm...@netbsd.org,
sibyte-us...@bitmover.com, sibyte-us...@mcvoy.com


Hello.

It is time to get rid of more hardware. If you pay shipping, you
can have it. Here is the first batch:

  (1) SiByte SWARM board in ATX case
  (1) R8000 SGI Indigo2
  (4) Philips Nino (Windows CE) handheld PCs. Three of them are
  the monochrome units and one of them is color.

I have a ton, in the literal sense, of more SGI hardware that I
need to go through in the next couple of months. Email me if
interested.

Steve


signature.asc
Description: PGP signature

Re: Bug#841645: golang-go: There is no mips64el support

[Mathieu Malaterre]

Hi Tianon,

> The main issue with getting it in essentially boils down to gccgo and
> upstream Go disagreeing on the GOARCH for mips64el (gccgo uses
> "mipsn64"[0]), which makes bootstrapping difficult.
>
> [0]: https://groups.google.com/d/topic/golang-nuts/waTy56I_KWQ/discussion


Are you saying that the patch is more complex than just
s/mipsn64/mips64el/ ? Or are you saying you do not want to maintain
such patch until upstream add an alias for mips64el ?

Thanks

CI20: jz4780-rng

[Mathieu Malaterre]

Hi there,

If anyone owns a CI20 (or X1000 SoC) I'd be interested in feedback
from the attached patch.

Thanks much !


jz4780_rng_cgu_v3.patch
Description: Binary data

Re: Bug#861171: #warning "Consider adding the right clone() syscall definitions here!"

[Mathieu Malaterre]

Control: tags -1 patch

On Wed, May 3, 2017 at 11:10 AM, James Cowgill <jcowg...@debian.org> wrote:
> Control: forwarded -1 https://github.com/systemd/systemd/pull/5880
>
> Hi,
>
> On 25/04/17 12:55, Michael Biebl wrote:
>> Am 25.04.2017 um 12:56 schrieb Mathieu Malaterre:
>>> Package: systemd
>>> Version: 232-22
>>> User: debian-mips@lists.debian.org
>>> Usertags: mipsel mips64el mips
>>>
>>> There are warning(s) generated during systemd building on mipsel* :
>>>
>>> I am starring at the clone warning (mmap seems to trigger something
>>> equivalent apparently):
>>>
>>> https://buildd.debian.org/status/fetch.php?pkg=systemd=mips64el=232-22=1490743348=0
>>>
>>> See:
>>> http://sources.debian.net/src/systemd/232-22/src/shared/seccomp-util.c/#L726
>>>
>>>
>>> $ man 2 clone
>>> [...]
>>>On x86-32, and several other common architectures (including
>>> score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa, and MIPS), the
>>> order of the last two arguments is reversed:
>>>
>>>long clone(unsigned long flags, void *child_stack,
>>>  int *ptid, unsigned long newtls,
>>>  int *ctid);
>>> [...]
>>>
>>> I believe it would make sense to fix those warnings (missing case in
>>> the switch) for mips/arm & powerpc* family since those are release
>>> archs.
>>
>> Would be great if you can send us a tested patch. I don't have any mips*
>> hardware where I could test if the patch works as expected.
>
> I've tested and submitted an upstream PR for the MIPS support.

Nice ! Thanks for doing it.

#warning "Consider adding the right clone() syscall definitions here!"

[Mathieu Malaterre]

Hi there,

Did anyone review the warning(s) generated during systemd building on mipsel* ?

I am starring at the clone warning (mmap seems to trigger something
equivalent apparently):

https://buildd.debian.org/status/fetch.php?pkg=systemd=mips64el=232-22=1490743348=0

See:
http://sources.debian.net/src/systemd/232-22/src/shared/seccomp-util.c/#L726


$ man 2 clone
[...]
   On x86-32, and several other common architectures (including
score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa, and MIPS), the
order of the last two arguments is reversed:

   long clone(unsigned long flags, void *child_stack,
 int *ptid, unsigned long newtls,
 int *ctid);
[...]

Is this worth reporting a bug for this ?

thx
-M

Bug#613610: xburst-tools: contains precompiled binaries in debian/

[Mathieu Malaterre]

Hi there,

> It should be works just fine. I have done this before:(just FYI)
>  http://downloads.openmobilefree.net/NanoNote/xburst-tools/mipsel/

So the link has disappeared. What is the status of xburst-tools in
Debian ? Do we really want that package in Debian ?

Thanks for comments

Re: kodi on ci20 creator

[Mathieu Malaterre]

On Tue, Apr 4, 2017 at 11:11 AM, James Cowgill <jcowg...@debian.org> wrote:
> Hi,
>
> On 04/04/17 09:47, Mathieu Malaterre wrote:
>> On Mon, Apr 3, 2017 at 6:11 PM, James Cowgill <james...@cowgill.org.uk> 
>> wrote:
>>> Hi,
>>>
>>> On 02/04/17 18:06, James Cowgill wrote:
>>>> [+CC multimedia team]
>>>>
>>>> On 02/04/17 17:38, Mathieu Malaterre wrote:
>>>>> On Sun, Apr 2, 2017 at 6:03 PM, Mathieu Malaterre <ma...@debian.org> 
>>>>> wrote:
>>>>>> Hi there,
>>>>>>
>>>>>> Does anyone knows what is going on with kodi dependencies on mipel ?
>>>>>
>>>>> OK I think I see the build dependencies loop:
>>>>>
>>>>> https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports
>>>>
>>>> With these binaries:
>>>> libchromaprint-dev | 1.2-1| stable   | mipsel
>>>> ffmpeg | 7:3.0.2-4~bpo8+1 | jessie-backports | mipsel
>>>> x265   | 2.0-4~bpo8+1 | jessie-backports | mipsel
>>>>
>>>> And these sources:
>>>> chromaprint | 1.3.2-2~bpo8+1   | jessie-backports | source
>>>> ffmpeg  | 7:3.2.4-1~bpo8+1 | jessie-backports | source
>>>> x265| 2.0-4~bpo8+1 | jessie-backports | source
>>>>
>>>> To build ffmpeg, we need chromapaint from jessie-backports. To build
>>>> chromapaint we need a working ffmpeg from jessie-backports, but ffmpeg
>>>> is broken due to the missing old x265.
>>>>
>>>> I don't see a way to resolve this without either a binary upload or some
>>>> new bpo uploads (by eg temporarily disabling chromaprint in ffmpeg bpo).
>>>>
>>>> I propose:
>>>> - Binary uploading chromaprint by manually installing the old x265
>>>> binaries from snapshot.d.o.
>>>> - Wait for ffmpeg to build on the buildds.
>>>> - binNMU chromaprint
>>>>
>>>> Opinions? I probably won't get around to doing this until tomorrow.
>>>
>>> I've uploaded this now, but it looks like it's stuck in backports-policy
>>> at the moment.
>>>
>>> I had to build ffmpeg manually as well, because I overlooked that ffmpeg
>>> build-depends on a working ffmpeg through chromaprint.
>>
>> Great I see it now:
>>
>> https://buildd.debian.org/status/package.php?p=ffmpeg=jessie-backports
>>
>> Are you sure you should not also upload chromaprint:
>>
>> https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports
>
> jcowgill@coccia:~$ dak ls -a mipsel -S -s jessie-backports chromaprint
> libchromaprint-dev   | 1.3.2-2~bpo8+1 | jessie-backports | mipsel
> libchromaprint-tools | 1.3.2-2~bpo8+1 | jessie-backports | mipsel
> libchromaprint1  | 1.3.2-2~bpo8+1 | jessie-backports | mipsel
>
> The buildd pages are probably just slow.
>
>> Are is this simply a binNMU missing ?
>
> Yes

Thank you !

https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports

Re: kodi on ci20 creator

[Mathieu Malaterre]

On Mon, Apr 3, 2017 at 6:11 PM, James Cowgill <james...@cowgill.org.uk> wrote:
> Hi,
>
> On 02/04/17 18:06, James Cowgill wrote:
>> [+CC multimedia team]
>>
>> On 02/04/17 17:38, Mathieu Malaterre wrote:
>>> On Sun, Apr 2, 2017 at 6:03 PM, Mathieu Malaterre <ma...@debian.org> wrote:
>>>> Hi there,
>>>>
>>>> Does anyone knows what is going on with kodi dependencies on mipel ?
>>>
>>> OK I think I see the build dependencies loop:
>>>
>>> https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports
>>
>> With these binaries:
>> libchromaprint-dev | 1.2-1| stable   | mipsel
>> ffmpeg | 7:3.0.2-4~bpo8+1 | jessie-backports | mipsel
>> x265   | 2.0-4~bpo8+1 | jessie-backports | mipsel
>>
>> And these sources:
>> chromaprint | 1.3.2-2~bpo8+1   | jessie-backports | source
>> ffmpeg  | 7:3.2.4-1~bpo8+1 | jessie-backports | source
>> x265| 2.0-4~bpo8+1 | jessie-backports | source
>>
>> To build ffmpeg, we need chromapaint from jessie-backports. To build
>> chromapaint we need a working ffmpeg from jessie-backports, but ffmpeg
>> is broken due to the missing old x265.
>>
>> I don't see a way to resolve this without either a binary upload or some
>> new bpo uploads (by eg temporarily disabling chromaprint in ffmpeg bpo).
>>
>> I propose:
>> - Binary uploading chromaprint by manually installing the old x265
>> binaries from snapshot.d.o.
>> - Wait for ffmpeg to build on the buildds.
>> - binNMU chromaprint
>>
>> Opinions? I probably won't get around to doing this until tomorrow.
>
> I've uploaded this now, but it looks like it's stuck in backports-policy
> at the moment.
>
> I had to build ffmpeg manually as well, because I overlooked that ffmpeg
> build-depends on a working ffmpeg through chromaprint.

Great I see it now:

https://buildd.debian.org/status/package.php?p=ffmpeg=jessie-backports

Are you sure you should not also upload chromaprint:

https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports

Are is this simply a binNMU missing ?

Thanks again

CI20 Creator as media center (kodi)

[Mathieu Malaterre]

Hi there,

So right now what prevent the Creator CI20 from being a good
replacement of a RPI2B+ (for example) is the video hardware decoding
capabilities, right ? Is anyone working on it ?

I do not see much activities in:

https://groups.google.com/forum/#!forum/mips-creator-ci20-dev

Also, does anyone knows the status of the official kernel ? Are CI20
patches integrated upstream yet ?

Thanks

Re: kodi on ci20 creator

[Mathieu Malaterre]

On Sun, Apr 2, 2017 at 6:03 PM, Mathieu Malaterre <ma...@debian.org> wrote:
> Hi there,
>
> Does anyone knows what is going on with kodi dependencies on mipel ?

OK I think I see the build dependencies loop:

https://buildd.debian.org/status/package.php?p=chromaprint=jessie-backports

kodi on ci20 creator

[Mathieu Malaterre]

Hi there,

Does anyone knows what is going on with kodi dependencies on mipel ?

root@ci20:~# apt-cache policy libavcodec57
libavcodec57:
  Installed: (none)
  Candidate: 7:3.0.2-4~bpo8+1
  Version table:
 7:3.0.2-4~bpo8+1 0
100 http://ftp.fr.debian.org/debian/ jessie-backports/main
mipsel Packages

root@ci20:~# apt-get install  -t jessie-backports libavcodec57
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libavcodec57 : Depends: libx265-79 (>= 1.9) but it is not installable
E: Unable to correct problems, you have held broken packages.

However all I can find is:

root@ci20:~# apt-cache policy  libx265-87
libx265-87:
  Installed: 2.0-4~bpo8+1
  Candidate: 2.0-4~bpo8+1
  Version table:
 *** 2.0-4~bpo8+1 0
100 http://ftp.fr.debian.org/debian/ jessie-backports/main
mipsel Packages
100 /var/lib/dpkg/status

Do I need to request a rebuild of libavcodec ?

Re: Bug#858405: xmlto: intermittent Segmentation fault when building manpages for libreswan on mips64el

[Mathieu Malaterre]

Seems like debian-mips@l.d.o was missing (I added mips64el tag)

On Wed, Mar 22, 2017 at 2:29 AM, Daniel Kahn Gillmor
 wrote:
> Package: xmlto
> Version: 0.0.28-1
> Severity: normal
>
> https://buildd.debian.org/status/fetch.php?pkg=libreswan=mips64el=3.20-6=1490132010=0
>
> shows xmlto having a segfault during the build of libreswan's manpages.
>
> make[5]: Leaving directory '/«PKGBUILDDIR»/OBJ.linux.mips64/programs/proc'
> sed -e "s:@IPSECVERSION@:3.20:g" -e "/@linux_START@/,/@linux_END@/d" -e 
> "s:@EXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALBINDIR@:/usr/lib/ipsec:g" -e "s:@FINALCONFDDIR@:/etc/ipsec.d:g" -e 
> "s:@FINALCONFDIR@:/etc:g" -e "s:@FINALCONFFILE@:/etc/ipsec.conf:g" -e 
> "s:@FINALDOCDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALEXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALLIBEXECDIR@:/usr/lib/ipsec:g" -e "s:@FINALRCDIR@:/etc/init.d:g" -e 
> "s:@FINALSBINDIR@:/usr/sbin:g" -e "s:@FINALSYSCONFDIR@:/etc:g" -e 
> "s:@FINALVARDIR@:/var:g" -e "s:@IPSEC_CONF@:/etc/ipsec.conf:g" -e 
> "s:@IPSEC_CONFDDIR@:/etc/ipsec.d:g" -e 
> "s:@IPSEC_NSSDIR@:/var/lib/ipsec/nss:g" -e "s:@IPSEC_DIR@:/usr/lib/ipsec:g" 
> -e "s:@IPSEC_EXECDIR@:/usr/lib/ipsec:g" -e "s:@IPSEC_VARDIR@:/var:g" -e 
> "s:@IPSEC_SBINDIR@:/usr/sbin:g" -e 
> "s:@IPSEC_SECRETS_FILE@:/etc/ipsec.secrets:g" -e "s:@MODPROBEBIN@:modprobe:g" 
> -e "s:@MODPROBEARGS@:--quiet --use-blacklist:g" -e "s:@USE_DEFAULT_CONNS@::g" 
> -e "s:@SD_TYPE@:notify:g" -e "s:@SD_RESTART_TYPE@:"always":g" -e 
> "s:@SD_PLUTO_OPTIONS@:"--leak-detective":g" -e "s:@SD_WATCHDOGSEC@:200:g"  < 
> ipsec_version.5.xml > 
> ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp
> mv ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp 
> ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp
> : ignoring seemingly bogus xmlto exit status
> xmlto man ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp -o 
> ../../OBJ.linux.mips64/programs/proc || true
> /usr/bin/xmlto: line 613:  5007 Segmentation fault  "/usr/bin/xsltproc" 
> --nonet --xinclude --param passivetex.extensions '1' -o 
> "/tmp/xmlto.vUw7Aq/ipsec_version.5.proc" "/tmp/xmlto-xsl.XOSOth" 
> "/«PKGBUILDDIR»/programs/proc/../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp"
> test -z ""  -a -r ../../OBJ.linux.mips64/programs/proc/ipsec_version.5
> ../../mk/manpages.mk:79: recipe for target 
> '../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man' failed
> make[4]: *** [../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man] Error 
> 1
> make[4]: Leaving directory '/«PKGBUILDDIR»/programs/proc'
>
> The build of the previous version, 3.20-5, which is very similar code, did 
> not have the segfault:
>
> https://buildd.debian.org/status/fetch.php?pkg=libreswan=mips64el=3.20-5=1490115466=0
>
> make[5]: Leaving directory '/«PKGBUILDDIR»/OBJ.linux.mips64/programs/proc'
> sed -e "s:@IPSECVERSION@:3.20:g" -e "/@linux_START@/,/@linux_END@/d" -e 
> "s:@EXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALBINDIR@:/usr/lib/ipsec:g" -e "s:@FINALCONFDDIR@:/etc/ipsec.d:g" -e 
> "s:@FINALCONFDIR@:/etc:g" -e "s:@FINALCONFFILE@:/etc/ipsec.conf:g" -e 
> "s:@FINALDOCDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALEXAMPLECONFDIR@:/usr/share/doc/libreswan:g" -e 
> "s:@FINALLIBEXECDIR@:/usr/lib/ipsec:g" -e "s:@FINALRCDIR@:/etc/init.d:g" -e 
> "s:@FINALSBINDIR@:/usr/sbin:g" -e "s:@FINALSYSCONFDIR@:/etc:g" -e 
> "s:@FINALVARDIR@:/var:g" -e "s:@IPSEC_CONF@:/etc/ipsec.conf:g" -e 
> "s:@IPSEC_CONFDDIR@:/etc/ipsec.d:g" -e 
> "s:@IPSEC_NSSDIR@:/var/lib/ipsec/nss:g" -e "s:@IPSEC_DIR@:/usr/lib/ipsec:g" 
> -e "s:@IPSEC_EXECDIR@:/usr/lib/ipsec:g" -e "s:@IPSEC_VARDIR@:/var:g" -e 
> "s:@IPSEC_SBINDIR@:/usr/sbin:g" -e 
> "s:@IPSEC_SECRETS_FILE@:/etc/ipsec.secrets:g" -e "s:@MODPROBEBIN@:modprobe:g" 
> -e "s:@MODPROBEARGS@:--quiet --use-blacklist:g" -e "s:@USE_DEFAULT_CONNS@::g" 
> -e "s:@SD_TYPE@:notify:g" -e "s:@SD_RESTART_TYPE@:"always":g" -e 
> "s:@SD_PLUTO_OPTIONS@:"--leak-detective":g" -e "s:@SD_WATCHDOGSEC@:200:g"  < 
> ipsec_version.5.xml > 
> ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp
> mv ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp.tmp 
> ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp
> : ignoring seemingly bogus xmlto exit status
> xmlto man ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.tmp -o 
> ../../OBJ.linux.mips64/programs/proc || true
> Note: Writing ipsec_version.5
> test -z ""  -a -r ../../OBJ.linux.mips64/programs/proc/ipsec_version.5
> touch ../../OBJ.linux.mips64/programs/proc/ipsec_version.5.man
>
> So xmlto seems to fail intermittently on mips64el, even though it
> behaves reliably on all the other debian architectures.
>
> Sorry that i haven't been able to debug it further.
>
> Perhaps someone who knows mips64el can debug it better than i can.
>
> For debian revisions of 3.20, failures happened on:
>
>   mipsel-manda-02
>   eberlin
>
> Also for revisions of 3.20, successes happened on:
>
>   

Re: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

[Mathieu Malaterre]

On Fri, Dec 30, 2016 at 10:06 AM, Emilio Pozuelo Monfort
 wrote:
> On 29/12/16 20:56, Gaudenz Steinlin wrote:
>>
>> Hi Emilio
>>
>> Emilio Pozuelo Monfort  writes:
>>
>>> Source: ceph
>>> Version: 10.2.5-2
>>> Severity: serious
>>>
>>> Your package failed to build on mips/el:
>>>
>>> g++ -DHAVE_CONFIG_H -I.  -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE 
>>> -D__STDC_FORMAT_MACROS -D_GNU_SOURCE 
>>> -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" 
>>> -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" 
>>> -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT-Wdate-time -D_FORTIFY_SOURCE=2 
>>> -I/usr/include/nss -I/usr/include/nspr  -Wall -Wtype-limits 
>>> -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
>>> -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
>>> -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall 
>>> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
>>> --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong  
>>> -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
>>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>>> tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
>>> virtual memory exhausted: Cannot allocate memory
>>> Makefile:24792: recipe for target
>>> 'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
>>
>> I already noticed this and tried to contact m...@buildd.debian.org and
>> mip...@buildd.debian.org. Unfortunately nobody responded yet, so I don't
>> know if the message was even received or not. AFAIK these are the
>> correct contact points for buildd issues.
>
> This is not a buildd issue but a porting issue. debian-mips@ldo is better for
> this. Added to Cc.
>
>> I don't think there is much I can do about this bug and I'm not
>> convinced this is a issue in ceph. If the buildds are unable to build
>> the package we can either completely remove ceph for mips/mipsel or try
>> to only build the client part and have a reduced set of packages on
>> these architectures.
>
> IIRC there are some flags you can pass to reduce memory usage. Most notably
> ggc-min-expand (which is going to be changed in GCC itself, but afaik it 
> hasn't
> happened yet). So you could try adding
>
> --param ggc-min-expand=10
>
> to CFLAGS/CXXFLAGS.
>
> I'd try that before thinking about removing the package from mips.

Reducing -O2 to -O1 did solve the issue for openvdb on mips* (kudos Jochen)

https://packages.qa.debian.org/o/openvdb/news/20161224T090717Z.html

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

On Sat, Oct 1, 2016 at 2:28 AM, Adam Borowski <kilob...@angband.pl> wrote:
> On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote:
>> On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
>> <glaub...@physik.fu-berlin.de> wrote:
>> [...]
>> > On the other hand, some packages dropped support for PowerPC32 like Mono
>> > but this isn't a concern for most users, I would say.
>> [...]
>>
>> However I need to mention that the specific ppc/mono issue is in fact
>> pretty interesting. The long thread is on debian-powerpc@l.d.o but the
>> short version is that this issue only happen because we build the
>> ppc32 mono version on a ppc64 kernel, I know that since I did debug
>> this issue.
>
> Which, if I read the bug correctly, is a yet another case of a bogus
> build system looking at characteristics of the machine it's compiled on
> rather than baseline of the arch.

Well the bug is really upstream: one cannot assume page size at
compilation time. But that is a different story.

> And, per your own work, it's +patch +fixed-upstream.

Wow ! In fact I just realize my patch was against git/master at the
time, and was never backported. Need to get this fixed ASAP.

>> I have not heard from the ppc64el porters, but I suspect ppc64 will
>> not be a release arch. So you need to take into consideration that for
>> powerpc to remain a release arch, one need minimal working ppc64 port.
>> Could we solve the situation of ppc64 for Stretch, could it be moved
>> to official release arch ?
>
> What would you need ppc64 for?  Unlike i386, powerpc includes 64-bit
> kernels so users don't need multiarch:
>
> powerpc has:
> linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC 
> (signed)
> linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed)
> i386 has:
> linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs
> linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs
> linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity 
> protection
> linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed)
> linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed)
>
> Note the joke: "for modern PCs".  Unless you do embedded it takes some
> serious dumpster diving to find a machine not better served by an -amd64
> kernel (and thus multiarch).  The i386 architecture is not self-contained,
> powerpc is.
>
> Thus, there is no need for ppc64 (userland), as long as powerpc has the
> toolchain to build 64-bit kernels.  And that's a primary target for gcc
> upstream.

Great ! That's all I wanted to check. I was worried we would need
buildd(s) running on ppc64el.

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.

I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?

-M

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Hi all,

On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
>> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>>- powerpc: No porter (RM blocker)
>>
>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>> maintaining powerpcspe which is very similar to powerpc.
>
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

[Let's assume that we can't find a powerpc porter in time for Stretch.]

1. Will `powperpc` automatically be downgraded to simple port ? Or is
this also not automated and the port may simply be removed (eg. sparc)
?
2. Apart from loosing the automatic debian-installer stuff, what else
are we going to loose in that scenario ?

Thanks much for pointers !

-M

Re: Bug#815998: golang: add mips64/mips64el support

[Mathieu Malaterre]

On Tue, Aug 30, 2016 at 8:31 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> On Sun, Aug 28, 2016 at 5:12 PM, Tianon Gravi <tia...@debian.org> wrote:
>> Given that upstream officially supports bootstrapping via gccgo, I'd
>> rather keep the discussion of "fix cross build" to a separate issue if
>> we can.  I am interested in updating the packaging to properly support
>> cross-building, but consider it a secondary concern to adding more
>> architectures.
>>
>> That being said, I attempted to build src:golang-1.7 on mips64el and
>> ran into the following build failure:
>>
>> (sid_mips64el-dchroot)tianon@eller:~/golang-1.7-1.7$ dpkg-buildpackage -uc 
>> -us
>> dpkg-buildpackage: info: source package golang-1.7
>> dpkg-buildpackage: info: source version 1.7-3
>> dpkg-buildpackage: info: source distribution unstable
>> dpkg-buildpackage: info: source changed by Tianon Gravi <tia...@debian.org>
>> dpkg-buildpackage: info: host architecture mips64el
>>  dpkg-source --before-build golang-1.7-1.7
>>  fakeroot debian/rules clean
> [...]
>
>> export GOROOT_BOOTSTRAP=$(env -i go env GOROOT) \
>> && cd src \
>> && /home/tianon/golang-1.7-1.7/debian/helpers/goenv.sh \
>
> Well you need to update that file I guess:
>
> $ head -20 debian/helpers/goenv.sh
> #!/bin/sh
> set -e
>
> __goos__deb_arch_os() {
> case "$1" in
> kfreebsd) echo freebsd ;;
> linux) echo "$1" ;;
> *) echo >&2 "error: unrecongized DEB_*_ARCH_OS: $1"; exit 1 ;;
> esac
> }
>
> __goarch__deb_arch_cpu() {
> case "$1" in
> amd64|arm|arm64|ppc64|s390x) echo "$1" ;;
> i386) echo 386 ;;
> ppc64el) echo ppc64le ;;
> mips64el) echo mips64le ;;
> *) echo >&2 "error: unrecongized DEB_*_ARCH_CPU: $1"; exit 1 ;;
> esac
> }
>
> Good luck!

I guess I was not clear, I meant specifically this line:

export GO386=387

There should a sentinel around this.
2cts

Re: Bug#815998: golang: add mips64/mips64el support

[Mathieu Malaterre]

On Sun, Aug 28, 2016 at 5:12 PM, Tianon Gravi  wrote:
> Given that upstream officially supports bootstrapping via gccgo, I'd
> rather keep the discussion of "fix cross build" to a separate issue if
> we can.  I am interested in updating the packaging to properly support
> cross-building, but consider it a secondary concern to adding more
> architectures.
>
> That being said, I attempted to build src:golang-1.7 on mips64el and
> ran into the following build failure:
>
> (sid_mips64el-dchroot)tianon@eller:~/golang-1.7-1.7$ dpkg-buildpackage -uc -us
> dpkg-buildpackage: info: source package golang-1.7
> dpkg-buildpackage: info: source version 1.7-3
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Tianon Gravi 
> dpkg-buildpackage: info: host architecture mips64el
>  dpkg-source --before-build golang-1.7-1.7
>  fakeroot debian/rules clean
[...]

> export GOROOT_BOOTSTRAP=$(env -i go env GOROOT) \
> && cd src \
> && /home/tianon/golang-1.7-1.7/debian/helpers/goenv.sh \

Well you need to update that file I guess:

$ head -20 debian/helpers/goenv.sh
#!/bin/sh
set -e

__goos__deb_arch_os() {
case "$1" in
kfreebsd) echo freebsd ;;
linux) echo "$1" ;;
*) echo >&2 "error: unrecongized DEB_*_ARCH_OS: $1"; exit 1 ;;
esac
}

__goarch__deb_arch_cpu() {
case "$1" in
amd64|arm|arm64|ppc64|s390x) echo "$1" ;;
i386) echo 386 ;;
ppc64el) echo ppc64le ;;
mips64el) echo mips64le ;;
*) echo >&2 "error: unrecongized DEB_*_ARCH_CPU: $1"; exit 1 ;;
esac
}

Good luck!

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

On Thu, Jun 16, 2016 at 2:12 AM, Hector Oron  wrote:
[...]
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
[...]

The debian-powerpc@l.d.o mailing list is active so I would say it
still has some users. I have been using partch.d.o for doing some work
on PowerPC. I posted a summary of work people have been doing on this
port lately:

https://lists.debian.org/debian-powerpc/2016/06/msg00046.html

However I do agree that true PowerPC hardware is actually
disappearing, and it is alive mostly thanks to being an ABI using
32bits integer for PPC64 CPU(s).

-M

Re: SGI O2 Jessie kernel issue

[Mathieu Malaterre]

On Sun, Feb 21, 2016 at 10:49 PM, Florian Lohoff  wrote:
> On Wed, Feb 17, 2016 at 09:01:10AM -0500, Stefan Monnier wrote:
>> > I own a SGI O2 which is running as a shell-, mail- and webserver since
>> > 2006.  The machine has 1 GB of RAM and two 72 GB hard disks configured as
>> > RAID-1 (md). CPU is R5000SC @ 180Mhz.
>>
>> Hmm... I love using my old Thinkpad X30 to give presentations, but
>> I can't help thinking that a cubieboard/Pi would be a great
>> replacement for that machine:
>
> You cant test SGI Kernels on an cubieboard so its not a replacement.
> Somebody has to test the state of the platform.

cubieboard are armhf based ? Do you mean creator ci20 (mipsel based) ?

src:tbb on mips

[Mathieu Malaterre]

Hi there,

src:tbb was uploaded over the week end. We've included a patch to fix
compilation on mips and powerpc (see #787084 for details). Everything
went -finally- fine on powerpc.

However I was suprised to see test failures on mips:

https://buildd.debian.org/status/fetch.php?pkg=tbb=mips=4.3~20150611-0.1=1441564654

Technically tbb on mips has never worked so this is not a regression,
but I'd be interested in feedback from mips guru on the tests
failures.

Thx

Re: o32 != n32

[Mathieu Malaterre]

On Thu, May 7, 2015 at 11:41 AM, James Cowgill james...@cowgill.org.uk wrote:
 On Thu, 2015-05-07 at 11:25 +0200, Mathieu Malaterre wrote:
 On Thu, May 7, 2015 at 10:57 AM, James Cowgill james...@cowgill.org.uk 
 wrote:
  On Thu, 2015-05-07 at 09:27 +0200, Mathieu Malaterre wrote:
  Hello MIPS gurus,
 
  Could someone please let me know if this is possible to have a
  dual-ABI system (eg: n32  o32) on MIPS. On my x86-64 system I can run
  a multi-arch system (x86  x86-64), thanks to the recent multi-arch
  effort.
 
  Is it possible on MIPS ? Does it make sense ?
 
  If you have a 64-bit kernel then that should completely work (all Debian
  kernels except for 4kc are 64-bit).
 
  If you then install gcc-multilib you should be able to pass -mabi=n32 to
  gcc to get n32 binaries (or -mabi=64 for n64 binaries). I haven't done a
  huge amount of testing with it, but you should also be able to add the
  mips64el debian repo which contains everything recompiled with n64. Then
  you should be able to do proper multiarch.
 
  See: http://mipsdebian.imgtec.com/

 I haven't received my Creator CI20 board yet, but I still fail to
 understand how that's possible. On my x86-64 there is a *single* ABI,
 and thus I can have a single `/usr/lib/x86_64-linux-gnu/libpthread.so`
 installed from libc6-dev:amd64 which wont conflict with
 `/usr/lib/i386-linux-gnu/libpthread.so` installed from libc6-dev:i386.

 The processor in the CI20 is 32-bit only so you won't be able to do any
 of this on that unfortunately.

 If you use mipsel / mips64el multiarch, the setup use on amd64 is
 identical on mips. Multilib places libraries in /lib32 or /lib64 just
 link it does on x86.

 I may sound dumb, but I fail to understand how multi-abi can be
 handled when directories are setup to handle (single) per-arch object
 files.

 The directories *are* setup to handle multiple ABIs. 'i386-linux-gnu' is
 the ABI used on i386 and it is completely different to the
 'x86_64-linux-gnu' ABI (you can't link amd64 and i386 objects together).

My original post was about mixing n32 and o32. So if I try to
summarize your post (little endian ABI only):

- debian `mipsel` refers to ABI `o32`
- debian `mips64el` refers to ABI `o64`
(https://gcc.gnu.org/projects/mipso64-abi.html)

Debian has not been working officially on any of the n32 or n64 ABIs.

Now let me rephrase my original question into:

Since Debian `mipsel` is using the old o32 ABI, would it make sense to
use n32 ABI on Creator CI20 ?

As per your comment, I will not be able to use (=link to) the o32
`libc` provided by the default debian `mipsel` package when building
an n32 application (gcc -mabi=n32). In which case the location
`/usr/lib/mipsel-linux-gnu/` will be reserved for object files with
o32 ABI, while something like `/usr/lib/mipsel-n32-linux-gnu/` may be
used for n32 ABI.

Thanks again for your time and clarification !


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxX0+N==t1HZPGbwK=w7qEKGVdn_Kd=pNRba=eun4s...@mail.gmail.com

Re: o32 != n32

[Mathieu Malaterre]

Hi James,

On Thu, May 7, 2015 at 10:57 AM, James Cowgill james...@cowgill.org.uk wrote:
 On Thu, 2015-05-07 at 09:27 +0200, Mathieu Malaterre wrote:
 Hello MIPS gurus,

 Could someone please let me know if this is possible to have a
 dual-ABI system (eg: n32  o32) on MIPS. On my x86-64 system I can run
 a multi-arch system (x86  x86-64), thanks to the recent multi-arch
 effort.

 Is it possible on MIPS ? Does it make sense ?

 If you have a 64-bit kernel then that should completely work (all Debian
 kernels except for 4kc are 64-bit).

 If you then install gcc-multilib you should be able to pass -mabi=n32 to
 gcc to get n32 binaries (or -mabi=64 for n64 binaries). I haven't done a
 huge amount of testing with it, but you should also be able to add the
 mips64el debian repo which contains everything recompiled with n64. Then
 you should be able to do proper multiarch.

 See: http://mipsdebian.imgtec.com/

I haven't received my Creator CI20 board yet, but I still fail to
understand how that's possible. On my x86-64 there is a *single* ABI,
and thus I can have a single `/usr/lib/x86_64-linux-gnu/libpthread.so`
installed from libc6-dev:amd64 which wont conflict with
`/usr/lib/i386-linux-gnu/libpthread.so` installed from libc6-dev:i386.

I may sound dumb, but I fail to understand how multi-abi can be
handled when directories are setup to handle (single) per-arch object
files.


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusxsf1w7gffdyqadsshl3brdcs9h5eu3mzvzrxmvqu_...@mail.gmail.com

o32 != n32

[Mathieu Malaterre]

Hello MIPS gurus,

Could someone please let me know if this is possible to have a
dual-ABI system (eg: n32  o32) on MIPS. On my x86-64 system I can run
a multi-arch system (x86  x86-64), thanks to the recent multi-arch
effort.

Is it possible on MIPS ? Does it make sense ?

Thanks,


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusxxscyoerky1f6dnwhn_4+bmktegbaaxoz+dda905m...@mail.gmail.com

Re: o32 != n32

[Mathieu Malaterre]

On Thu, May 7, 2015 at 4:24 PM, YunQiang Su wzss...@gmail.com wrote:
 On Thu, May 7, 2015 at 6:01 PM, Mathieu Malaterre ma...@debian.org wrote:
 On Thu, May 7, 2015 at 11:41 AM, James Cowgill james...@cowgill.org.uk 
 wrote:
 On Thu, 2015-05-07 at 11:25 +0200, Mathieu Malaterre wrote:
 On Thu, May 7, 2015 at 10:57 AM, James Cowgill james...@cowgill.org.uk 
 wrote:
  On Thu, 2015-05-07 at 09:27 +0200, Mathieu Malaterre wrote:
  Hello MIPS gurus,
 
  Could someone please let me know if this is possible to have a
  dual-ABI system (eg: n32  o32) on MIPS. On my x86-64 system I can run
  a multi-arch system (x86  x86-64), thanks to the recent multi-arch
  effort.
 
  Is it possible on MIPS ? Does it make sense ?
 
  If you have a 64-bit kernel then that should completely work (all Debian
  kernels except for 4kc are 64-bit).
 
  If you then install gcc-multilib you should be able to pass -mabi=n32 to
  gcc to get n32 binaries (or -mabi=64 for n64 binaries). I haven't done a
  huge amount of testing with it, but you should also be able to add the
  mips64el debian repo which contains everything recompiled with n64. Then
  you should be able to do proper multiarch.
 
  See: http://mipsdebian.imgtec.com/

 I haven't received my Creator CI20 board yet, but I still fail to
 understand how that's possible. On my x86-64 there is a *single* ABI,
 and thus I can have a single `/usr/lib/x86_64-linux-gnu/libpthread.so`
 installed from libc6-dev:amd64 which wont conflict with
 `/usr/lib/i386-linux-gnu/libpthread.so` installed from libc6-dev:i386.

 The processor in the CI20 is 32-bit only so you won't be able to do any
 of this on that unfortunately.

 If you use mipsel / mips64el multiarch, the setup use on amd64 is
 identical on mips. Multilib places libraries in /lib32 or /lib64 just
 link it does on x86.

 I may sound dumb, but I fail to understand how multi-abi can be
 handled when directories are setup to handle (single) per-arch object
 files.

 The directories *are* setup to handle multiple ABIs. 'i386-linux-gnu' is
 the ABI used on i386 and it is completely different to the
 'x86_64-linux-gnu' ABI (you can't link amd64 and i386 objects together).

 My original post was about mixing n32 and o32. So if I try to
 summarize your post (little endian ABI only):

 - debian `mipsel` refers to ABI `o32`
 - debian `mips64el` refers to ABI `o64`
 (https://gcc.gnu.org/projects/mipso64-abi.html)

 Debian has not been working officially on any of the n32 or n64 ABIs.

 Now let me rephrase my original question into:

 Since Debian `mipsel` is using the old o32 ABI, would it make sense to
 use n32 ABI on Creator CI20 ?

 O32 is like i386,
 N32 is like x32
 N64 is like x86-64 aka amd64.

 N32 and N64 ask for 64bit CPU, while CI20 uses a 32bit only CPU,
 so you cannot use N32 and N64 on it.


 As per your comment, I will not be able to use (=link to) the o32
 `libc` provided by the default debian `mipsel` package when building
 an n32 application (gcc -mabi=n32). In which case the location
 `/usr/lib/mipsel-linux-gnu/` will be reserved for object files with
 o32 ABI, while something like `/usr/lib/mipsel-n32-linux-gnu/` may be
 used for n32 ABI.

 `/usr/lib/mipsel-n32-linux-gnu/` - /usr/lib/mips64el-linux-gnuabin32

 We also have
 /usr/lib/mips64el-linux-gnuabi64 for N64.

Crystal clear !


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUswziSRdMDPqKRvMF2SFq+6OiLX_YQGVoEjCf0mPj6=f...@mail.gmail.com

Re: GCC-4.5 as the default for (at least some) architectures

[Mathieu Malaterre]

On Tue, Apr 26, 2011 at 5:31 PM, Konstantinos Margaritis
mar...@genesi-usa.com wrote:
 On 26 April 2011 18:03, Matthias Klose d...@debian.org wrote:
 I'll make GCC 4.6 the default after the release of
 GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
 powerpc.

 Could you include armhf in the list as well?

I am also getting an ICE with g++ 4.5 on mips too on one of my C++ package:

https://buildd.debian.org/status/package.php?p=vxl

but since there is no log I cannot confirm this is the same ICE as on i386/armel

thanks,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktimr8sshy4vvasvzoxk4gyj1pb9...@mail.gmail.com

Re: gdcm: Dep-Wait: mono-runtime

[Mathieu Malaterre]

On Mon, Jul 13, 2009 at 6:39 PM, Luk Claesl...@debian.org wrote:
 Mathieu Malaterre wrote:
 Could someone please let me know what is going on with gdcm buildd ? I
 have taken out mono from mipsel:

 $ cat control
 ...
  mono-devel (= 2.0) [!alpha !armel !mipsel !m68k !hppa]
 ...

   But it still shows up as: Dep-Wait: mono-runtime on

 https://buildd.debian.org/pkg.cgi?pkg=gdcm

 That's perfectly normal as Dep-Waits are sticky, do you want to have it
 cleared so a build is tried on mipsel again?

Yes, please.


-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Please remove sticky Dep-Wait: libvtk5 (= 5.2.1-3) on gdcm

[Mathieu Malaterre]

Please clear  sticky Dep-Wait: libvtk5 (= 5.2.1-3) on gdcm package.

Ref:
https://buildd.debian.org/pkg.cgi?pkg=gdcm

Thank you

-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

gdcm: Dep-Wait: mono-runtime

[Mathieu Malaterre]

Could someone please let me know what is going on with gdcm buildd ? I
have taken out mono from mipsel:

$ cat control
...
 mono-devel (= 2.0) [!alpha !armel !mipsel !m68k !hppa]
...

  But it still shows up as: Dep-Wait: mono-runtime on

https://buildd.debian.org/pkg.cgi?pkg=gdcm

thank you
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org