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

2013-10-02 Thread Bastien ROUCARIES
Add me for armel.

Bastien
Le 2 oct. 2013 09:46, "Niels Thykier"  a écrit :

> Hi,
>
> The final results are in:
>
> Summary table:
> Arch   || DDs || NMs/DMs || Other || Total
> ---++-++-++---++--
> armel  ||  3  ||   0 || 1 ||4
> armhf  ||  3  ||   1 || 2 ||6
> hurd-i386  ||  5  ||   0 || 3 ||8
> ia64   || *0* ||   0 || 3 ||3
> kfreebsd-amd64 ||  4  ||   0 || 2 ||6
> kfreebsd-i386  ||  4  ||   0 || 2 ||6
> mips   ||  1  ||   0 || 1 ||2
> mipsel ||  1  ||   0 || 1 ||2
> powerpc[1] || (1) ||   0 || 2 ||   2.5?
> s390x  || *0* ||   0 || 0 ||   *0*
> sparc[2]   ||  1  ||   0 || 0 ||1
>
> [1] The (1) and .5 is from a "I am not primarily a porter [...]"-remark,
> so I wasn't sure how to count it.
>
> [2] By the looks of it, if sparc was replaced by sparc64, we could be
> looking at 3 in the "Other"-column rather than 0.
>
> NMs/DMs include DMs and people currently in NM process.  The "Other"
> column may include people who said they would like to become porters
> (but would need to be introduced to the job) and thus may imply some
> active recruiting from the current porters.  This is at least true for
> hurd-i386.
>
>
>
> The current policy says that we require "5 developers" (i.e. DDs) for
> release architectures[AP], so based on that only amd64, i386 and
> hurd-i386 would pass this requirement.  It is quite possible we need to
> revise that requirement, but most of the architectures would (still) do
> well to attract a few more (DD) porters.
>   I have attached a file with my notes of who are behind those numbers.
>  If your name is missing or you believe I have miscounted something[CD]
> for an architecture listed in the table above, please reply to this
> email *promptly* (CC'ing me explicitly is fine) with your concerns or
> corrections.
>
> At this time, I have *not* updated the arch qualification table yet.  I
> will do that in a couple of days.  We will also follow up on this in the
> next bits from the release team.
>
> ~Niels
>
> [AP] http://release.debian.org/jessie/arch_policy.html
>
> [CD] I may (or may not) have been caffeine-deprived when I did the
> counting.  You are free to make assumptions about whether that has
> affected my ability to do addic^Htion or parsing your email(s) properly.
>
>


Re: Please try rebuilding imagemagick on sparc (2nd try)

2012-11-22 Thread Bastien ROUCARIES
On Thu, Nov 22, 2012 at 10:55 AM, Philipp Kern  wrote:
> On Thu, Nov 22, 2012 at 07:05:26AM +0100, Bastien ROUCARIES wrote:
>> And under other arch we do not found anything. I do not have an access to a
>> porter box (dm), i will ask but i néed more information in order to
>> reproduce
>
> http://dsa.debian.org/doc/guest-account/

Yes but I plan first to adopt duma in order to build something that
could debug the memory leak.

I will attempt the debian paris mini conf this week end but before I
have no time to do this
>
> Kind regards
> Philipp Kern


--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAE2SPAZxjG=+deUsL6n+8KGqvhXkgVy=cJEcYOUs�luz6...@mail.gmail.com



Re: Please try rebuilding imagemagick on sparc (2nd try)

2012-11-21 Thread Bastien ROUCARIES
Le 21 nov. 2012 23:59, "Philipp Kern"  a écrit :
>
> Vincent,
>
> am Wed, Nov 21, 2012 at 11:43:06AM +0100 hast du folgendes geschrieben:
> >   gb imagemagick_8:6.7.7.10-5 . sparc
> >
> >   This FTBS has been hitting imagemagick sporadically without any
> > pattern, and never in a way related to code changes. I suspect it may
> > be a subtle toolchain bug, but as it is not very reproducible, there's
> > no simple way to dig into that. So far, rebuilding has always
> > succeeded, suggesting a small probability to trigger the bug.
>
> I'd guess some valgrind might be in order?

Valgrind does not work on sparc
And under other arch we do not found anything. I do not have an access to a
porter box (dm), i will ask but i néed more information in order to
reproduce

.moreover the ftbde is due to convert from graphicksmagica in this case
used for converting icons. If we change for convert from imagemagick it
also fail sporadically.

Likely the bug is under librsvg or in libc

Bastion

> Anyway done.
>
> Kind regards
> Philipp Kern