Re: Texmaker fails to build on arm

[Riku Voipio]

On Tue, Jul 18, 2006 at 12:22:44PM -0400, Lennart Sorensen wrote:
 Well the log to me looks like a g++ bug, or possibly something in libqt,
 but probably the compiler.  Too bad you can't tell which g++ version was
 installed at the time of the compile on each architecture's buildd.

Looking at the texmaker buildd log[1], It seems g++-4.1 is not
installed, and thus the version of g++ in the buildd is one
of the g++-4.0 versions. 

Should g++ be atleast the same major version as gcc ? from the logs
seems grieg has g++-4.1 but the others have something older.

--snip--
Automatic build of texmaker_1.3-2 on europa by sbuild/arm 85
Build started at 20060706-0507
--snip--
Checking correctness of source dependencies...
Toolchain package versions: libc6-dev_2.3.6-13 
linux-kernel-headers_2.6.13+0rc3-2.1 gcc-4.1_4.1.1-5 g++-4.1_ binutils_2.17-1 
libstdc++6-4.1-dev_ libstdc++6_4.1.1-5 
--snip--

[1] 
http://buildd.debian.org/fetch.php?pkg=texmakerver=1.3-2arch=armstamp=1152181247file=logas=raw


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [martinw...@yahoo.it: Bug#497165: amiga-fdisk-cross is not being built on any architecture other than i386]

[Riku Voipio]

On Wed, Oct 08, 2008 at 08:52:31PM +0200, Christian T. Steigies wrote:
 could the buildd admins please enable building for amiga-fdisk and upload
 the resulting packages (powerpc has been built, but it seems it was never
 uploaded).

It's not upto buildd admins, it's upto packages-arch-specific[1]
maintainers (cc:'d).

Please change the atari-fdisk p-a-s entry to match what's on the
package sources:

amiga-fdisk-cross: !m68k !poweprc # 
Everything but m68k/ppc
amiga-fdisk: m68k powerpc # 
m68k/ppc specific

[1] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dakrev=HEAD


signature.asc
Description: Digital signature

Re: Architecture usertags

[Riku Voipio]

On Tue, Mar 03, 2009 at 08:52:03PM +0100, Wouter Verhelst wrote:
 so that maintainers could apply them to architecture-specific bugs when
 necessary. The format, suggested by Steve Langasek, was to use the
 porters mailinglist as the user, and the architecture name as the
 usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
 tag).

Armel has already been using something similar:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.orgtag=eabi

usertags would certainly be used a much more if there were a easy
way to set/search them on BTS web interface.

-- 
rm -rf only sounds scary if you don't have backups


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

Re: Roll call for porters of architectures in sid and testing

[Riku Voipio]

On Sun, Sep 01, 2013 at 09:33:51AM +0200, Niels Thykier wrote:
 If you are (or intend to become) an active porter for the lifetime of
 jessie, then please send a signed email explaining your involvement in
 the port to the Release Team debian-rele...@lists.debian.org before
 1st of October 2013. Please explain the level of your involvement in
 the port.

Sorry I missed the deadline, but I guess the information is still
valuable. 

Hi,

I am active porter for armel and also help on armhf and arm64.
I intend to continue helping for the lifetime for jessie.

For armel, I
 - maintain the buildd's, file bugs on failed builds
 - provide packagers bugfixes in case they are unable to fix armel bugs
   in their package themself

For armel, armhf and possibly in future for arm64:
 - test packages on the architectures
 - fix arch-related bugs

I am a DD,

Riku Voipio


-- 
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007101951.ga16...@afflict.kos.to

Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

[Riku Voipio]

On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote:
 +++ Niels Thykier [2013-10-02 09:45 +0200]:
  armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
  McIntyre (DD)
  armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
  Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD)
 
 I am surprised not to see Riku Voipio and Hector Oron on this list as
 I know they help manage the buildds and Riku signs uploads. I don't
 know if they are trying to escape, or just being too slack to send
 mail :-)

Sorry, I missed the fact that this request had a deadline. Anyways,
I am available for arm related issues - just try not to use debian-devel
to reach me, as I tend to just skim subjects here...

Riku


-- 
To UNSUBSCRIBE, email to debian-alpha-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131007102229.gb16...@afflict.kos.to

Re: Porter roll call for Debian Stretch

[Riku Voipio]

On Tue, Sep 20, 2016 at 09:16:00PM +, Niels Thykier wrote:
> Over all, most people (who answered it) was positive towards the switch.
>  Based on this, I suspect that if we make PIE default in Stretch, then
> we will do it for all architectures.  That said, you will be notified if
> that default changes for Stretch.

Is this just for ASLR, or is ther another motivating factor for PIE?

AFAIK Address space randomizing is not really helpful on 32 bit 
architectures - there is just not that many places to randomize to[1].
At least previously, PIE added ~10% to binary size, which can have a major
performance impact on the 32-bit arm core's that don't have much cache to
begin with.

Riku
[1] https://cseweb.ucsd.edu/~hovav/dist/asrandom.pdf

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Riku Voipio]

On Thu, Jun 28, 2018 at 08:11:14PM +0200, Florian Weimer wrote:
> * Niels Thykier:
> 
> > armel/armhf:
> > 
> >
> >  * Undesirable to keep the hardware running beyond 2020.  armhf VM
> >support uncertain. (DSA)
> >- Source: [DSA Sprint report]
> 
> Fedora is facing an issue running armhf under virtualization on arm64:
> 
>   

I think you mean:

https://bugzilla.redhat.com/show_bug.cgi?id=1576593

>   
> 
> Unless the discussion has moved somewhere where I can't follow it, no
> one seems to have solid idea what is going on. 

True. Looking at comment #22, the suggestion seems to be that the guest is
doing something wrong, and kvm is being terrible at pinpointing the source.

> It's also not clear that this configuration has substantial vendor or
> community support. This makes me concerned that virtualization is a viable
> path forward here.

I understand your concern. It would be surprising if this specific bug doesn't
get found and fixed. It's probably stuck because everyone thinks it's 
probably someone elses bug ;)

I still think the armhf vm on arm64 is the only reasonable path forward medium
term. The existing arm64 hw that suport arm32 vm's is still around and
infinitely better than native aarch32 builder hw, and should still be viable
for some time. 

Riku