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

[Niels Thykier]

Hi,


As part of the interim architecture qualification for buster, we request
that DSA, the security team and the toolchain maintainers review and
update their list of known concerns for buster release architectures.

Summary of the current concerns and issues:
 * DSA have announced a blocking issue for armel and armhf (see below)
 * Concerns from DSA about ppc64el and s390x have been carried over from
   stretch.
 * Concerns from the GCC maintainers about armel, armhf, mips, mips64el
   and mipsel have been carried over from stretch.

If the issues and concerns from you or your team are not up to date,
then please follow up to this email (keeping debian-release@l.d.o and
debian-ports@l.d.o in CC to ensure both parties are notified).

Whilst porters remain ultimately responsible for ensuring the
architectures are ready for release, we do expect that you / your team
are willing to assist with clarifications of the concerns and to apply
patches/changes in a timely manner to resolve the concerns.


List of blocking issues by architecture
===

The following is a summary from the current architecture qualification
table.

armel/armhf:


 * Undesirable to keep the hardware running beyond 2020.  armhf VM
   support uncertain. (DSA)
   - Source: [DSA Sprint report]


[DSA Sprint report]:
https://lists.debian.org/debian-project/2018/02/msg4.html


List of concerns for architectures
==

The following is a summary from the current architecture qualification
table.

 * Concern for ppc64el and s390x: we are dependent on sponsors for
   hardware.
   (Raised by DSA; carried over from stretch)

 * Concern for armel and armhf: only secondary upstream support in GCC
   (Raised by the GCC maintainer; carried over from stretch)

 * Concern for mips, mips64el, mipsel and ppc64el: no upstream support
   in GCC
   (Raised by the GCC maintainer; carried over from stretch)


Architecture status
===

These are the architectures currently being built for buster:

 * Intel/AMD-based: amd64, i386
 * ARM-based: arm64, armel, armhf
 * MIPS-based: mips, mipsel, mips64el
 * Other: ppc64el, s390x

If the blocking issues cannot be resolved, affected architectures are at
risk of removal from testing before buster is frozen.

We are currently unaware of any new architectures likely to be ready in
time for inclusion in buster.

On behalf of the release team,
Niels Thykier



signature.asc
Description: OpenPGP digital signature

Re: Stable update request: kernel changes to fix PIE with large stack

[Niels Thykier]

Ben Hutchings:
> On Sat, 2017-04-22 at 20:07 +0000, Niels Thykier wrote:
> [...]
>> Hi Ben,
>>
>> Could you please file a pu bug for this?  I fear that otherwise, it
>> might be overlooked for the next time the SRMs review the outstanding
>> stable update requests.
> 
> I already stopped waiting and went ahead and made these changes.  I
> verified that they build on all release architectures except
> mips/mipsel (porterboxes were down) and was able to test the result on
> amd64, armhf, i386, powerpc, ppc64 (standing in for ppc64el) and s390x.
> 
> Ben.
> 

Excellent, thanks. :)

~Niels

Re: Stable update request: kernel changes to fix PIE with large stack

[Niels Thykier]

Ben Hutchings:
> On Thu, 2017-03-23 at 17:06 +, James Cowgill wrote:
> [...]
>> The reason the program and the heap are at these very high addresses is
>> that xsltproc is built with PIE and the kernel is treating the
>> executable like a mmap and grouping it with all the other libraries. In
>> d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR") the behavior
>> changed and now the program and it's heap will be mapped at a lower
>> address so the bug does not affect newer kernels. Using "setarch -L" or
>> "setarch -R" is another workaround for this bug because that moves the
>> program so that there is a much larger gap between the heap and the stack.
>>
>> This might affect other applications as well. Effectively it means that
>> PIE executables which use lots of stack space might not work properly
>> with jessie's kernel. The chances the bug will be hit seems to vary
>> between arches however (depending on what each arch does in
>> arch_pick_mmap_layout and arch_randomize_brk) - mips64el seems to be hit
>> pretty frequently. In xsltproc's case, PIE was enabled some time ago
>> which is why this bug is quite old.
>>
>> I believe any of the following will fix this (but have not all been tested):
>> - Reduce the stack usage in xsltproc (the upstream bug)
>> - Upgrade the relevant buildds to Linux >= 4.1
>> - Apply d1fd836dcf00 to jessie's kernel
> 
> That's part of a series of 10 commits covering multiple architectures. 
> I already picked one of them as a dependency for fixing CVE-2016-3672,
> which leaves 9 to do.  I think it is worth doing this in stable to
> support chroots and partial upgrades, but I would like to hear the
> release team ack/nak this in principle before I start preparing the
> change for Debian stable.
> 
> Kees Cook quotes the list of commits here:
> http://lists.openwall.net/linux-kernel/2015/07/27/964
> (I can't find the original message).
> 
> Ben.
> 
>> - Disable PIE in xsltproc.
>> - Run xsltproc inside setarch -L / setarch -R
> [...]
> 

Hi Ben,

Could you please file a pu bug for this?  I fear that otherwise, it
might be overlooked for the next time the SRMs review the outstanding
stable update requests.

Thanks,
~Niels

Re: Enabling PIE by default for Stretch

[Niels Thykier]

Niels Thykier:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> [...]
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> [...]
> 
> Thanks,
> ~Niels
> 
> [...]

It appears that there were no major concerns.  I will follow up #835148
and request PIE by default for the following architectures.

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

Should you be a porter for an architecture not listed above and want PIE
by default on your architecture, please follow up on #835148 as well (or
a file a new wishlist bug if #835148 is closed when you do it)

NB: The omission of powerpc was intentional as there were no porters
supporting it during the roll-call.

Thanks,
~Niels

Re: Architecture qualification meeting, scheduling

[Niels Thykier]

Adrian Bunk:
> [ fullquote adding -ports, for people not following -release or -devel ]
> 
> [...]
> 
> Is https://release.debian.org/stretch/arch_qualify.html the up-to-date 
> information available to you, and the "candidate" line how a decision
> would look like based on the current information?
> 
> cu
> Adrian
> 

It reflects all the issues we are aware of at the present time (except
for archive-{coverage,uptodate}, which can be seen from
https://buildd.debian.org/stats/).

If you believe we have overlooked an issue or an update, please do not
hesitate to let us know. :)

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Niels Thykier]

John Paul Adrian Glaubitz:
> On 09/30/2016 06:08 PM, Niels Thykier wrote:
>> I strongly /suspect/ that "no porters" for powerpc will imply the
>> removal of powerpc for Stretch.  It may or may not be moved to ports
>> (assuming someone is willing to support it there).
> 
> So, I take this as a "no" for the offer from me and Christoph Biedel to take
> over the powerpc port for Stretch?
> 
> [...]
> 
> Thanks,
> Adrian
> 

My statement above was made based on the assumption stated in the first
line of Mathieu's mail, which was "Assume there are no powerpc porters
for Stretch".

As for "porter qualification"
=

We got burned during the Jessie release, where a person answered the
roll call for sparc and we kept sparc as a release architecture for
Jessie.  However, we ended up with a completely broken and unbootable
sparc kernel.

  That was an embarrassment to the Debian stability and quality
  reputation that I never - ever - want to repeat.

(For avoidance of doubt: I want to ensure that release architectures
"just work(tm)" and I have no desire to blame that volunteer).


If I am to support powerpc as a realease architecture for Stretch, I
need to know that there are *active* porters behind it committed to
keeping it in the working.  People who would definitely catch such
issues long before the release.  People who file bugs / submit patches etc.


If you need inspiration: Have a look at the [automatic testing of
ppc64el images].  Or the [arm64 machines on ci.debian.net] with
comparable results to amd64.  This is the sort of thing that inspires
confidence in the ports for me and I think we should have vastly more of.


Thanks,
~Niels

[automatic testing of ppc64el images]:
 https://lists.debian.org/debian-powerpc/2016/06/msg2.html

[arm64 machines on ci.debian.net]:
 https://ci.debian.net/status/

Re: Porter roll call for Debian Stretch

[Niels Thykier]

ni...@thykier.net:
> Hi,
> 
> Like last release, we are doing a roll call for porters of all release
> architectures.  If you are an active porter behind one of the [release
> architectures] for the entire lifetime of Debian Stretch (est. end of
> 2020), please respond with a signed email containing the following
> before Friday, the 9th of September:
> 
>  [...]
> 

Thanks to all that replied to the roll call.

We got replies from all architectures except amd64 (Waived), i386
(Waived) and powerpc (problematic).  For the ports that replied, all had
at least 2 or more porters.
  We also got a parallel update from Matthias Klose on the toolchain
state[1].  Based on these we have updated the current state of the
architecture qualification for Stretch[2].

 * Please check that your name is listed as a porter on [2] (see [3]
   for how).  If I missed you, please do not hesitate to let me know.

 * For powerpc, mips and mipsel: Please note that we have added a
   (potentially) blocking issues for your architecture.
   - powerpc: No porter (RM blocker)
   - mips+mipsel: #834147 (RM concern, possibly blocker)


As for the piggy backed question about PIE by default:

 * arm64: 2 OK, 1 did not mention it
 * armel: 3 OK, 1 OK if tested first, 1 was neutral and 1 did not
   mention it
 * armhf: 4 OK, 1 OK if tested first, 1 was neutral and 2 did not
   mention it
 * mips+mipsel+mips64el: 3 OK, 1 OK later, 4 did not mention it.
 * ppc64el: 3 OK, 1 recommended further testing/research
 * s390x: 2 OK

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.

Thanks,
~Niels

[1] https://lists.debian.org/debian-release/2016/09/msg00263.html

[2] https://release.debian.org/stretch/arch_qualify.html

[3] Hover your mouse over the number of porters for your architecture
or download the underlying data file from:
  https://release.debian.org/stretch/arch_spec.yaml




signature.asc
Description: OpenPGP digital signature

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Kurt Roeckx:
> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>also apply to this port? [0]
> 
> If -fPIE is the default will -fPIC override it?
> 
> It will also default to tell the linker to use -pie, but then
> don't do it when you want to create a shared library?
> 

I believe so.  At least, Ubuntu made PIE default in their compiler
without having to change all SO packages to still build.

Admittedly, it could also be that GCC uses some built "compiler spec"
files for this case (a la an implicit "-specs=$FILE"), which are similar
to those Redhat uses for this purposes (see [1] for an example of such
files).

Regardless, it seems to "just work(TM)" if you pass the proper flags
when compiling your SOs.

>>From what I understand, depending on what the .o file is going to
> be used for you want different things:
> - shared library: -fPIC
> - executable: -fPIC or -fPIE both work, but prefer -fPIE
> - static library: Same as executables
> 
> For static libraries we now have a policy to not use -fPIC,
> should that then get replaced by using -fPIE?
> 
> 
> 
> Kurt
> 

Honestly, I had not thought about that.  From the looks of it, de facto
we will end up with -fPIE being the default for static libraries as well.
  I would be supporting that change on the assumption that it requires
less work from individual maintainers (and presumably has no notable
downsides in the final result).

Thanks,
~Niels

[1] Example spec files for this case seems to be something like:

pie-compile.specs
"""
*cc1_options:
+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
"""

pie-link.specs:
"""
*self_spec:
+ %{!shared:%{!r:-pie}}
"""

NB: I manually carved them out of a diff without testing them.

Re: Porter roll call for Debian Stretch

[Niels Thykier]

Martin Michlmayr:
> * ni...@thykier.net  [2016-08-17 22:05]:
>> 2020), please respond with a signed email containing the following
>> before Friday, the 9th of September:
> 
> Can you please specify where to respond to?  I don't think dozens of
> emails to -ports and -devel make any sense.
> 

Ah, sorry I had indeed forgotten to set Reply-To. :)

> Maybe debian-release with CC debian- or to you personally and
> you'll collect the info?
> 

Please send the replies to debian-release. :)

Thanks,
~Niels

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Emilio Pozuelo Monfort:
> [...]
> 
> Brilliant. We will start the testing bootstrap soon.
> 
> Cheers,
> Emilio
> 

We have completed our first successful Britney run with mips64el enabled
in testing.

Please note that Britney does *not* yet enforce installability of
mips64el.  Nor should you expect mips64el in testing to be useful at the
moment (I would be surprised if "build-essential" as installable at this
point).

As the architecture matures in testing, we will gradually tweak the
configuration for mips64el.

Thanks,
~Niels

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Philipp Kern:
> On 2016-06-05 12:01, Niels Thykier wrote:
>>  * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
>>s390x
>>- *No* blockers at this time from RT, DSA nor security.
>>- s390, ppc64el and all arm ports have DSA concerns.
> 
> What is the current DSA concern about s390x?
> 
> Kind regards and thanks
> Philipp Kern
> 

The concern listed as: "rely on sponsors for hardware (mild concern)"

As I recall the argument went something along the lines of:

"Debian cannot replace the hardware; if any of the machines dies, we
need a sponsor to replace it.  If all of them dies and we cannot get
sponsored replacements, we cannot support the architecture any longer"

(My wording)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: mips64el in testing

[Niels Thykier]

Aurelien Jarno:
> [...]
> 
> Here is the current buildd lists and how there are configured:
> - eberlin (DSAed): mipsel then mips64el
> - mipsel-aql-01 (DSAed): mipsel then mips64el
> - mipsel-aql-02 (DSAed): mipsel then mips64el
> - mipsel-aql-03 (DSAed): mips64el then mipsel
> - mipsel-manda-01 (DSAed): mipsel then mips64el
> - mipsel-manda-01 (DSAed): mipsel then mips64el
> - clash (manually signed): mips64el
> - lm6100 (manually signed): mips64el
> - thor (manually signed): mips64el
> 

Thanks.  I have updated our lists.  For now I am only counting a buildd
on its primary arch.

> In short only one DSAed buildd builds mips64el before mipsel. This is
> clearly not enough for the port.
> 

Indeed, though it looks solvable. :)  Anyway, it has been added as an RM
concern for now.

Let me know if there are updates to their primary architectures.

>> to be shared between mipsel and mips64el.  Are some of these being
>> migrated to/replaced with DSA buildds?
> 
> 2 buildds have arrived at man-da and 2 at sil. They need to be racked
> and installed. They will be split between mips (they have an FPU) and
> mipsel/mips64el, likely 1 mips and 1 mipsel in each location, but it's
> not fully decided yet.
> 
> Aurelien
> 

Sounds great. :)

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: mips64el in testing

[Niels Thykier]

YunQiang Su:
> On Sun, Jun 5, 2016 at 4:41 PM, Niels Thykier <ni...@thykier.net> wrote:
>> [...]
>> AFAICT, we are still missing:
>>
>>  * A rebuild of the last package [mipsel64import]
> 
> This is a bug of gcc, and the gcc team in IMG is working on it.
> It also effects lua.
> 

Thanks for the update. :)

>>  * DSA maintained buildds (admittedly, I did not look for one).
> 
> mips64el shares the same machines with mipsel.
> All machines for mipsel can be configured to build for mips64el at the
> same time.
> 
> [...]

In other words, there is a DSA buildd?

I notice we have the following list of mipsel/mips64el buildds:

 * mips64el: eberlin, mipsel-aql-01, mipsel-aql-02, mipsel-manda-01,
   mipsel-manda-02
   - I presume none of them are DSA given mips64el currently has a note
 of not having a DSA buildd.

 * mipsel: mayer, eysler, rem, phrixos (non-DSA), helle (non-DSA)

Are these lists up to date?  If so, we only seem to have 4 DSA buildds
to be shared between mipsel and mips64el.  Are some of these being
migrated to/replaced with DSA buildds?

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

Steven Chamberlain:
> Hi,
> 

Hi,

> John Paul Adrian Glaubitz wrote:
>> I have invested lots of time and effort to get sparc64 into a usable state 
>> in Debian.
>> We are close to 11.000 installed packages. Missing packages include Firefox,
>> Thunderbird/Icedove, golang and LibreOffice to name the most important ones.
> 
> Is there some way to define 'core'[0] packages as blockers for testing
> migration, and arch release qualification;  but other packages not?
> 

There is no current definition and I doubt it will be trivial to agree
on a definition.  Also, the moment you want to keep the set
self-contained (by including build-depends) it very easily explodes
unless you patch packages to disable "optional" features.

> Many of these ports would be useful if just a base system was released,
> and preferably having stable/security updates for that part (otherwise
> it is difficult for users to try it, developers to work on it, or DSA to
> support buildds for it;  all of which are limitations on ports' further
> growth).
> 

Assuming we use your definition as basis, you probably also want the
packages necessary to support a DSA maintained buildd.  Otherwise it
seems it fail one of your own proposed requirements.

> Trying to have *every* package build and stay built on every port, and
> supported for the lifetime of stable, is a lot of work without much
> purpose sometimes.  And it's unreasonable for any one port to block
> testing migration of a package on all arches, unless it is something
> really essential.
> 
> This might be done either:
>   * in the official archive, with relaxed rules for testing migration
> and more frequently de-crufting of out-of-date packages;

I suspect this will be a lot of work and an uphill battle as the our
current tooling is not really written for this case.  At the very least,
I fear a lot of extra special cases in Britney that I cannot easily deal
with.

>   * creating a mini testing/stable suite based on debian-ports.org?
> where maybe only the core packages are candidates to migrate.
> 

At least short term, this probably a lot more tractable. I am happy to
provide help with setting up a Britney instance for ports.  Though we
would need some way to provide a architecture specific version of the
"core" packages.

> [0]: I'd define core packages as everything needed to install, boot, and
> then build packages on that arch.  The rebootstrap project gives us some
> idea of what those are;  but add to that the kernel and any bootloaders.
> Being able to rebootstrap, should be part of the arch release
> qualification anyway IMHO.
> 
> Regards,
> 

Hmm, the rebootstrap idea is interesting as a new requirement.  I will
look into it.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: [Stretch] Status for architecture qualification

[Niels Thykier]

John Paul Adrian Glaubitz:
> Hi Niels!
> 
> On 06/05/2016 12:01 PM, Niels Thykier wrote:
>> Beyond mips64el, we are not aware of any new architectures for Stretch.
>>
>> I kindly ask you to:
>>
>>  * Porters, please assert if your architecture is targeting Stretch.
> 
> To give some insight what's happening in Debian Ports. We have two candidates 
> which
> I think would qualify for inclusion in a stable release. There is also a third
> potential candidate for future releases of Debian once the hardware has become
> available.
> 

Thanks. :)

> ppc64:
> 
> [...]

AFAICT, it is not in unstable and I have not heard of any attempts to
bootstrap it there yet.  Who is working on it and what is the ETA?

> 
> sparc64:
> 
> [...]
> 

Thanks for the update.  For every one working on this, please keep in
mind that it can take quite a while to be set up and included in testing
(even without missing hardware).

If you are unable to acquire (promise of) the necessary hardware within
a month or two, making it into a Stretch will probably be very hard.

> sh4:
> 
> [...]
> 
> Thanks,
> Adrian
> 
> [...]

While it sounds exciting, I doubt it will be ready for Stretch (I
presume this was the "potential candidate for a future release").

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

[Stretch] Status for architecture qualification

[Niels Thykier]

Hi members of DSA, Security, RT and all porters.

While the freeze still seem far away, I think it is time to start with
the architecture qualifications.

For starters, here are the architectures we are aware of:

 * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el,
   s390x
   - *No* blockers at this time from RT, DSA nor security.
   - s390, ppc64el and all arm ports have DSA concerns.
   - armel has a RT concern about lack of buildds (only 2)

 * mips64el (NEW)
   - No DSA buildd (RT blocker)
   - Rebuild after import not complete (RT Blocker)
   - Not yet in testing (due to the above).

 * kfreebsd-i386, kfreebsd-amd64
   - Not included in Jessie due to lack of sustainable man-power (RT
 blocker)
   - No news of the situation having changed
   - If there is no news on the situation after DebConf16, I will
 assume kfreebsd-* will not target Stretch.

Beyond mips64el, we are not aware of any new architectures for Stretch.

I kindly ask you to:

 * Porters, please assert if your architecture is targeting Stretch.
 * Review the list architectures and the reported blockers/concerns
 * Reply to this mail with updates to these blockers/concerns (if any).
   - DSA/Security/RT: Please use the word "blocker" or "RC" for issues
 that *must* be solved for you to be willing to support the
 architecture.

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Re: mips64el in testing

[Niels Thykier]

Emilio Pozuelo Monfort:
> On 06/03/16 01:21, Aurelien Jarno wrote:
>> [...]
> 
> Please let us know when those issues get sorted out.
> 
> Cheers,
> Emilio
> 

Hi,

Just a friendly reminder that we have not heard from you on this topic.

AFAICT, we are still missing:

 * A rebuild of the last package [mipsel64import]
 * DSA maintained buildds (admittedly, I did not look for one).

Please keep in mind that bootstrapping a new architecture in testing may
take quite a while before it is ready for a release.

Thanks,
~Niels

[mipsel64import]: https://ftp-master.debian.org/users/mhy/mipsel64import.txt





signature.asc
Description: OpenPGP digital signature

Bug#733296: gnupg2: FTBFS on mips* can't disable core dumps: Operation not permitted

[Niels Thykier]

Package: gnupg2
Version: 2.0.22-2
Severity: serious

Hi,

Your package FTBFS on mips* with:



echo ../../g10/gpg2 --homedir . --no-options --no-greeting \
 --no-secmem-warning --batch --dearmor ./gpg_dearmor
chmod 755 ./gpg_dearmor
./gpg_dearmor  ./pubring.gpg  ./pubring.asc
gpg: Fatal: can't disable core dumps: Operation not permitted
make[4]: *** [pubring.gpg] Error 2
make[4]: Leaving directory `/«PKGBUILDDIR»/tests/openpgp'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/tests'
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make[2]: Leaving directory `/«PKGBUILDDIR»'
make[1]: Leaving directory `/«PKGBUILDDIR»'
dh_auto_build: make -j1 returned exit code 2
make: *** [build-arch] Error 2



~Niels


--
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/20131228092915.7151.30548.report...@mangetsu.thykier.net

default-java and openjdk-7 on sparc

[Niels Thykier]

On 2013-11-09 14:35, Niels Thykier wrote:
 Hi,
 
 (With my Java hat on and my Release hat off)
 
 We are getting close to being able to remove openjdk-6 from sid and
 testing.  However, there is major blocker, which is java-common itself
 (and its default-* binaries).  mips and mipsel are the only two
 architectures still using OpenJDK 6 as default java.
 
 At the current time, OpenJDK 7 have not been successfully ported on
 these architectures and it is my understanding that it is unlikely to
 change in the near future.  This leaves gcj-jdk as the only viable
 option for mips and mipsel.
 
 I intend to implement these changes in java-common in about 14 days,
 unless there are alternative solutions (that does not involve keeping
 openjdk-6 around).
 
 ~Niels
 
 

Hi sparc porters,

We are currently debating whether the default java should change from
openjdk-6 to gcj for mips and mipsel.  I now noticed that while sparc
uses openjdk-7 as default java, openjdk-7 no longer builds successfully
on sparc and haven't done so for at least 85 days.

It is my understanding that Matthias Klose (doko) is the only active
maintainer working on OpenJDK-7 and he does not have time to solve this
problem.  While this is not an immediate problem for getting rid of
openjdk-6, it will be a problem that needs to be solved before the
Jessie freeze[0].

If you are interested in fixing the OpenJDK-7 build failure, you may (or
may not) find [1] interesting.

~Niels

[0] Currently available solutions are: use gcj as default java or make
OpenJDK-7 build again.

[1] https://lists.debian.org/debian-java/2013/11/msg00072.html

(the odd patch being a reference to patch attached to #729448)



-- 
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/5284ba47.3080...@thykier.net

Replacing openjdk-6 with gcj-jdk as default java for mips{,el}

[Niels Thykier]

Hi,

(With my Java hat on and my Release hat off)

We are getting close to being able to remove openjdk-6 from sid and
testing.  However, there is major blocker, which is java-common itself
(and its default-* binaries).  mips and mipsel are the only two
architectures still using OpenJDK 6 as default java.

At the current time, OpenJDK 7 have not been successfully ported on
these architectures and it is my understanding that it is unlikely to
change in the near future.  This leaves gcj-jdk as the only viable
option for mips and mipsel.

I intend to implement these changes in java-common in about 14 days,
unless there are alternative solutions (that does not involve keeping
openjdk-6 around).

~Niels


-- 
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/527e3a35.2060...@thykier.net

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-11-03 16:03, Steven Chamberlain wrote:
 On 03/11/13 10:54, Niels Thykier wrote:
 Come to think of it; maybe we should have a BTS page for each of the
 ports (e.g. a pseudo package in the BTS).
 
 We've had this on kfreebsd, due it to having been a release goal:
 
 http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1
 


Actually, I meant a real BTS page (e.g. like [1]) rather than just a
list of tagged bugs.  The list of tagged bugs definitely have it uses,
but it does not give me an overview of which bugs should be fixed by the
maintainer of the given package and which the porters should fix.

 It uses usertags, but someone has to set those.  Porters usually set
 them on bugs they file;  but quite often FTBFS on kfreebsd bugs are
 filed without being tagged or Cc'd to our list, so someone has to
 periodically look for and tag things.
 
 Regards,
 

In this regard; I am guilty of filing some those bugs without tagging
them.  Honestly, adding the tags get a bit in the way right now.  If a
package FTBFS on 4 architectures, I have to dig up 3-4 different
usertags (with different user) and associate it with the bug.
  Do we have a tool you can give a source package, a version plus a list
of architectures and it will generate a bug with the right tags?  I
think that would help a lot for me.

~Niels

[1] http://bugs.debian.org/release.debian.org



-- 
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/52789fdb.2000...@thykier.net

Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-11-03 23:04, Steve Langasek wrote:
 On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote:
 [...]
 
 I suppose a sponsor-only DD could be sufficient, provided that the
 sponsor knows the porters well enough to be willing to sign off on e.g.
 access to porter boxes.  I guess the sponsor would also need to dedicate
 time to mentor (new?) porters on workflows and on quicks like when is a
 FTBFS RC and when it isn't etc.
 
 Why would the sponsor need to be involved in getting the porters access to
 porter boxes?  Porter boxes exist so that DDs *not* involved in a port have
 access to a machine of the architecture and can keep their packages working.
 I've never heard of a porter who didn't have access to their own box for
 porting work.
 

I will not rule out that it was a poor choice of example on my part for
ia64 (and maybe powerpc), which is(/are) the concrete port(s) we would
be talking in this case.
  That said, it is my understanding that one does not simply own an
s390(x)[1].  Nor would I be concerned to have arm porters that worked
on all 3 arm ports while possessing hardware only for a (non-empty)
subset of those architectures.

~Niels

[1] I certainly wouldn't have space for something like this:

 http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg

(and much less the money.  Yeah I know that is technically not an s390,
but as I understand it, an s390 should be around that size)



-- 
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/5278a3e1.30...@thykier.net

Re: Bug#727751: enblend-enfuse: FTBFS on mipsel but built there in the past

[Niels Thykier]

On 2013-10-28 22:27, Andreas Barth wrote:
 * Andreas Metzler (ametz...@bebt.de) [131028 19:24]:
 On 2013-10-26 Niels Thykier ni...@thykier.net wrote:
 
 Your package FTBFS on mipsel but built there in the past.  It looks
 like it is an ICE, so you may have to reassign the bug to the relevant
 compiler/part of the toolchain.
 
 is it possible that the mipsel *buildd* machines are hosed? e.g.
 4.1.2+dfsg-1 in experimental) failed to build on mayer [buildd]
 yesterday but worked on eder [porterbox]. Afaict both were using the
 same up to date toolchain.
 
 I dist-upgraded the chroots this morning. For this reason I just
 rescheduled a build, we will see if it works or not.
 
 
 
 Andi
 

Hi,

It still FTBFS, but it looks like it timed out this time?

~Niels



-- 
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/52760e2e.5040...@thykier.net

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

[Niels Thykier]

Hi,

Added Dejan Latinovic, Dragoslav Sicarov and Jurica Stanojkovic as
non-DD mips + mipsel porters.

Thanks for your interest,
~Niels



-- 
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/527615d9.8020...@thykier.net

Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))

[Niels Thykier]

On 2013-10-29 17:48, Ian Jackson wrote:
 Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)):
 [...]
 As mentioned we are debating whether the 5 DDs requirement still makes
 sense.  Would you say that we should abolish the requirement for DD
 porters completely?  I.e. Even if there are no (soon to be) DDs, we
 should consider the porter requirements fulfilled as long as they are
 enough active porters behind the port[0]?
 
 I don't have a good feel for the answer to that question.  
 
 It's just that if it is the case that a problem with ports is the lack
 of specifically DDs, rather than porter effort in general, then
 sponsorship is an obvious way to solve that problem.
 
 If you feel that that's not really the main problem then a criterion
 which counts porters of any status would be better.
 

I suppose a sponsor-only DD could be sufficient, provided that the
sponsor knows the porters well enough to be willing to sign off on e.g.
access to porter boxes.  I guess the sponsor would also need to dedicate
time to mentor (new?) porters on workflows and on quicks like when is a
FTBFS RC and when it isn't etc.

 (Mind you, I have my doubts about a process which counts people
 promising to do work - it sets up some rather unfortunate incentives.
 I guess it's easier to judge and more prospective than a process which
 attempts to gauge whether the work has been done well enough.)
 
 [...]
 
 Thanks,
 Ian.
 
 

Ah, you are not the first to question this process.  Obviously, we
intend to keep people up on their promise by actively maintaining their
port.  Sadly, we do not have a clear definition of actively maintained
ports and I doubt we will have it any time soon either.
  But porters can start by working on the concerns from DSA (if they
haven't already done so).  Ports having gcc-4.6 as default compiler
might also consider improving in that area[1].

Then there are more concrete things like ruby's test suite seg. faulting
on ia64 (#593141), ld seg. faulting with --as-needed on ia64
(#718047[2]), a lot of ruby packages being stuck on kfreebsd-any due to
ruby2.0 FTBFS (#726095[3]).  Personally, I would also expect that
key-packages work on all ports (on which they are built) in general[4].

All of the (non-mild) DSA concerns are already something we will
officially hold against the ports.  Most of the other issues listed
above are not official concerns.  However, I would not be surprised if
most of them became official issues eventually.


Until we have a clear definition of actively maintained ports, I would
recommend porters to err on the side of being verbose over being silent.
 As an example, lack of visible reply to mails like [5] makes it seem
like nobody is home.
  Mind you, I am not saying porters have the responsibility to fix every
problem forwarded to their port list.  I am also aware that sometimes
issues/mail disappear in the depths of people inbox - heck it happens
to me as well.
  Come to think of it; maybe we should have a BTS page for each of the
ports (e.g. a pseudo package in the BTS).  That way it would at least be
easier for all people to find outstanding issues for the port[6].  It
would also give us the possiblity to trivial declare a problem RC (or
not) for ports.  (Plus, then I won't have to update some random file on
release.d.o for every new issue :P)

Anyhow, I hope to be able to give a more official statement in the
near future.

~Niels

[1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
acceptable as a default for Jessie.

[2] Apparently it is controversial whether that bug should be RC, but it
definitely looks like that kind of thing that will cause issues for ia64
later.

[3] That one got a patch, but it might be worth it to put some pressure
on the maintainer or even doing a NMU.

[4] A rule of thumb could be something like your port should probably
not be listed here in the long run:

http://udd.debian.org/bugs.cgi?release=jessie_and_sidmerged=ignkeypackages=onlyfnewerval=7flastmodval=7rc=1sortby=idsorto=asc


[5] https://lists.debian.org/debian-mips/2013/08/msg5.html

Btw, this is not intended to single out mips.

[6] I know that people have been usertags for issues that affect the
port, but it is not clear to me that all those usertags bugged is
something we expect porters to fix.  Rather it seems more like porters
tagging the FTBFS bugs they file.



-- 
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/52762b6a.5060...@thykier.net

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 15:49, Thorsten Glaser wrote:
 Niels Thykier dixit:
 
 [...]
 Until we have a clear definition of actively maintained ports, I would
 recommend porters to err on the side of being verbose over being silent.
 
 I’ve held off on the m68k side because I think the role call was only
 for architectures in the main archive, right?
 

Yes, we are only talking about architectures in the main architecture.

 [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be
 acceptable as a default for Jessie.
 
 Didn't Doko say he’d want 4.8? We (on the m68k side) are putting
 effort into that one, since 4.7 appears to only be used by eglibc
 right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may
 be fixed as there’s active upstream on the GCC/m68k side.
 
 bye,
 //mirabilos
 

I am not entirely up to speed on what he wants; I am still waiting for
him to get back to me (see [1]).

~Niels

[1] https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/527671af.7050...@thykier.net

Re: Potential issues for most ports

[Niels Thykier]

On 2013-11-03 16:54, Niels Thykier wrote:
 On 2013-11-03 15:49, Thorsten Glaser wrote:
  Niels Thykier dixit:
  
  [...]
  Until we have a clear definition of actively maintained ports, I would
  recommend porters to err on the side of being verbose over being silent.
  
  I’ve held off on the m68k side because I think the role call was only
  for architectures in the main archive, right?
  
 Yes, we are only talking about architectures in the main architecture.
 

s/main arcihtecture/main archive/;

~Niels



-- 
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/527674bd.2070...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-29 16:05, Ian Jackson wrote:
 Niels Thykier writes (Bits from the Release Team (Jessie freeze info)):
 Results of porter roll-call
 ===
 ...
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 - ---++-++-++---++--
 armel  ||  5  ||   0 || 2 ||7
 armhf  ||  6  ||   1 || 2 ||9
 hurd-i386  ||  5  ||   0 || 3 ||8
 ia64   || *0* ||   0 || 3 ||3
 kfreebsd-amd64 ||  5  ||   0 || 2 ||6
 kfreebsd-i386  ||  5  ||   0 || 2 ||6
 mips   ||  2  ||   0 || 1 ||3
 mipsel ||  2  ||   0 || 1 ||3
 powerpc[1] || (1) ||   0 || 2 ||   2.5?
 s390x  ||  1  ||   0 || 1 ||2
 sparc  ||  1  ||   0 || 0 ||1
 ...
 Based on the number of porters, we are considering changing the
 current requirements of 5 DDs to better reflect the reality of the
 situation.  We will follow up in a future bits on the changes.
 
 Thanks.
 

You are welcome. :)

 I think it is disappointing to find that we may be dropping
 architectures where a significant amount of effort is available,
 simply because the volunteers don't have enough status - specifically,
 because of a lack of DDs.
 

As mentioned we are debating whether the 5 DDs requirement still makes
sense.  Would you say that we should abolish the requirement for DD
porters completely?  I.e. Even if there are no (soon to be) DDs, we
should consider the porter requirements fulfilled as long as they are
enough active porters behind the port[0]?

 I'm keen that Debian should continue to support a wide range of
 architectures.  Would it help if I, as a DD, volunteered to sponsor
 porter uploads for any architecture ?  That is I guess I'm
 volunteering to become a new kind of person - a non-port-specific
 porter sponsor.
 

I suppose that could help ports without a DD if we allowed such to be in
testing.  However, it is my understanding that our main issue with ports
often is that they are not actively maintained (or appears to lack
active maintenance).
  As an example I remember having received several complains from e.g.
the GCC maintainers in regards to the state of gcc on various ports[1].
 Here I would suspect a patch would be sufficient without needing to
actually NMU gcc to get the fix in.
  There are also stuff like the port concerns from DSA that attention.

 Obviously I will review the debdiff etc.  I'm an experienced C
 programmer with some background in C language lawyering and
 portability stuff, so I should usually be able to do a decent review
 of a patch even on an unfamiliar architecture.
 
 In fact, regardless of what the release team decide for the policy, I
 would be happy to sponsor porter uploads.  Please just email me.
 
 Ian.
 
 

:)

~Niels

[0] Leaving the definition of active porter vaguely defined for now.

[1] Obviously, I haven't been keeping track of them so I had to ask for
a reminder.

https://lists.debian.org/debian-release/2013/10/msg00710.html



-- 
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/526fdfe3.7060...@thykier.net

Re: Bits from the Release Team (Jessie freeze info)

[Niels Thykier]

On 2013-10-19 16:38, Jeremiah C. Foster wrote:
 Hello,
 
 On Sun, Oct 13, 2013 at 05:01:31PM +0200, Niels Thykier wrote:
 
 [snip freeze policy]
  

Hi,

I s/-arm/-ports/'ed the CC, since I figured the rest of the porters
would find the answer equally interesting.

 Results of porter roll-call
 ===

 [...]

 That said, we would like to encourage porters behind all ports to
 ensure that the toolchain is up to date and working.  We are aware of
 at least gcc on mips having its test suite disabled[GCC].  Other ports
 may suffer from similar issues and we hope to have those resolved
 sooner rather than later.  We are currently waiting for the gcc
 maintainers to compile a list of such issues.
 
 So I can extrapolate from this that ensuring that the toolchain is up
 to date and working is a key activity of a porter.

Yes; build-essential being broken is obviously a problem.  But also
having the same default compiler on all architectures is also desired.

 If my assumption is
 correct, is there a complete definition of the toolchain as we see
 it in Debian that a porter might reasonably be expected to use to do
 thier porting?
 

I do not have an complete list of packages, although it will definitely
include build-essential.  My intuition is that toolchain should
include any compiler used by packages on that architecture[1] (e.g. if
the arch has built haskell packages, it should have a working haskell
compiler as well).  But as said, that is my personally view and not an
official statement.

 In addition, I wonder if there is a way to report the status of the
 toolchain and what sort of expectations are there around up to date?

I would love for us to have an automated system to give us a
weather-report on the toolchain for each architecture.  It would be
nice both for us to see how ports are doing and for porters to spot and
fix problems early.
  As for up-to-date, I don't have a complete answer here.  I seem to
remember the GCC maintainers being frustrated at having to maintain
gcc-4.6 (it is apparently still default for some architectures) despite
gcc-4.8 being the latest stable release.

 Is it expected to build Debian toolchain nightly and run a specific
 test suite? Is the expectation that one uses pbuilder and builds a set
 of packages?

What we got in the policy so far[2]:


Installer: The architecture must have a working,tested installer.
[...]

Archive coverage: The architecture needs to have successfully compiled
the current version of the overwhelming part of the archive [...]


Which implies a set of packages being the current version of the
overwhelming part of the archive plus all of d-i.  However, that is not
something you just build, so having a smaller set as a basic test
would probably be way more useful.  I am not aware of such a basic test
set, so feel free to propose one.

I like the toolchain nightly thing as well. I don't think it is
required, but it sounds like the kind of thing that would help people
spot issues sooner rather than later!

 Perhaps this is outlined on the wiki somewhere and if not
 perhaps it ought to be?
 
 Regards,
 
 Jeremiah
 
 

Having documentation on it would definitely be a good thing.  For actual
requirements, we should add them to the policy[2], but having a
wiki-page of recommended porter practises/tests would probably be a
nice addition too.

~Niels

[1] My rationale for this is that we would like to be able to
rebuild/reproduce builds, which would require a working compiler.

[2] http://release.debian.org/jessie/arch_policy.html



-- 
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/52654b6d.9020...@thykier.net

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

[Niels Thykier]

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.

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  ||  1  ||   0 || 0 ||1

[1] Roger Leigh: I am not primarily a porter [...].

armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve 
McInture (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), 
Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD)
hurd-i386: Samuel Thibault (DD), Barry deFreese (DD), Thomas Schwinge (!DD), 
Pino Toscano (DD), Svante Signell (!DD), Michael Banck (DD), Guillem Jover 
(DD), Zhang Cong (!DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), 
Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD)
mips: Graham Whaley (!DD), Andreas Barth (DD)
mipsel: Graham Whaley (!DD), Andreas Barth (DD)
powerpc: [Roger Leigh (DD)], Geoff Levand (!DD), Lennart Sorensen (!DD)
sparc: Axel Beckert (DD)

Maybes for ia64 (?): Martin Lucina (!DD), Émeric MASCHINO (!DD), Mark Wickens 
(!DD)


(Some inaccuracies can occur in the (xN) below; /me got confused and may have 
lost count for some of them)

Items suggested in the roll call:
* test packages: armel (x3), armhf (x4), hurd-i386 (x4), kfreebsd-amd64 (x6), 
kfreebsd-i386 (x6), mips, mipsel, powerpc (x3), sparc
* fix toolchain issues: armel, armhf (x3), hurd-i386 (x3), mips, mipsel, 
powerpc (x2)
* triage arch-specific bugs: armel (x3), armhf (x4), hurd-i386 (x4), 
kfreebsd-amd64 (x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2), 
sparc
* fix arch-related bugs: armel (x2), armhf (x4), hurd-i386 (x5), kfreebsd-amd64 
(x5), kfreebsd-i386 (x5), mips (x2), mipsel (x2), powerpc (x2)
* maintain buildds: armhf, hurd-i386 (x2), kfreebsd-amd64, kfreebsd-i386, mips, 
mipsel

Items suggested by porters in their mails:
+ test d-i when needed: hurd-i386, powerpc (x3)
+ maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
+ maintain non-DSA porter box: hurd-i386 (x2), kfreebsd-amd64
+ maintain production system of $arch: sparc/Wheezy

Re: Roll call for porters of architectures in sid and testing (Status update)

[Niels Thykier]

On 2013-09-01 09:33, Niels Thykier wrote:
 Hi,
 
 As we announced in [LAST-BITS], we would like to get a better idea of
 that status of the ports, to make an informed decision about which
 port can be released with jessie. One of the steps is to get an
 overview of which of the porters are (still) active for each
 port. Once the results from the role-call are in, we will request
 other information about the status of the ports. In the meantime, feel
 free to update and collect info about the ports in the Debian wiki[WIKI].
 
 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.
 
 Feel free to use the following template as your reply:
 
 [...]
 
 Niels, on behalf of the release team
 
 [LAST-BITS] 
 http://lists.debian.org/debian-devel-announce/2013/08/msg6.html
 
 [WIKI] https://wiki.debian.org/ArchiveQualification/Jessie
 


Hi all,

Here is a little status update on the mails we have received so far.
First off, thanks to all the porters who have already replied!

So far, the *no one* has stepped up to back the following architectures:

   hurd-i386
   ia64
   mips
   mipsel
   s390x

I have pinged some people and #d-hurd, so this will hopefully be amended
soon.  Remember that the *deadline is 1st of October*.

In the list above, I excluded:

  amd64 and i386: requirement for porters is waived
  s390: Being removed from testing during the Jessie cycle
(Agreement made during the Wheezy release cycle)

The following table shows the porters for each architecture in
*unstable* that I have data on so far:

armel: Wookey (DD)
armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD)
kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD),
   Petr Salinger (!DD), Robert Millan (DD)
powerpc: Geoff Levand (!DD), Roger Leigh (DD)
sparc: Axel Beckert (DD), Rainer Herbst (!DD)


If you are missing from this list above, then I have missed your email.
 Please follow up to this mail with a message-ID (or resend it,
whichever you prefer).

We also got a number of people interested in architectures not currently
in unstable.  These are:

  alpha: Bill MacAllister (!DD), Kieron Gillespie (!DD)
  arm64: Wookey (DD)
  parisc/hppa: Helge Deller (!DD)
  ppc64: Steven Gawroriski (!DD)
  sparc64: Steven Gawroriski (!DD), Kieron Gillespie (!DD)

This will hopefully teach me to remember to include the in unstable
restriction to the next roll call.  :)  Anyhow, if you are working on
these architectures on debian-ports and saw a new name in the list
above, this might be an opportunity to recruit new people.


We also received a couple of emails from people who are not or did not
want to be porters at the moment.  However, they expressed an interest
in the architectures:

  David Kuehling: mipsel
- debug arch-related issues
  Meelis Roos: ppc, sparc64 (parisc)
- test and report bugs in upstream kernel
  Peter Green: armhf (possibly any-arm)
- works on raspbian


In the template email included in the roll call, we included some tasks
that people might be doing.  These are the task people have said they
are doing for a given port.

  * test packages: armhf, kfreebsd-amd64 (x4), kfreebsd-i386 (x4),
 powerpc, sparc (x2)
  * fix toolchain issues: armhf, powerpc
  * triage arch-specific bugs: armhf, kfreebsd-amd64 (x3),
 kfreebsd-i386 (x3), powerpc, sparc (x2)
  * fix arch-related bugs: armhf, kfreebsd-amd64 (x3),
  kfreebsd-i386 (x3), powerpc
  * maintain buildds: armhf, kfreebsd-amd64, kfreebsd-i386

NB: I have manually translated some prose-text into the items above, so
something might have been lost (or gained) in that translation.

Some of the porters also added some new items.  I have included some of
these items below:

  + test d-i when needed: powerpc (x2)
  + maintain arch-related pkgs: kfreebsd-amd64, kfreebsd-i386
  + maintain non-DSA porter box: kfreebsd-amd64
  + maintain production system of $arch: sparc/stable
  + can offer hardware access[1]: sparc (Axel Beckert)
  + eglibc issues: kfreebsd-amd64, kfreebsd-i386
  + maintain+test cross-toolchains for $arch: armel, armhf

~Niels

[1] Restrictions may apply.


-- 
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/523ab805.7000...@thykier.net

Roll call for porters of architectures in sid and testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

As we announced in [LAST-BITS], we would like to get a better idea of
that status of the ports, to make an informed decision about which
port can be released with jessie. One of the steps is to get an
overview of which of the porters are (still) active for each
port. Once the results from the role-call are in, we will request
other information about the status of the ports. In the meantime, feel
free to update and collect info about the ports in the Debian wiki[WIKI].

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.

Feel free to use the following template as your reply:


  Hi,
  
  I am an active porter for the following architectures and I intend
  to continue this for the lifetime of the jessie release:

  For ARCH, I
  - test (most|all) packages on this architecture
  - fix toolchain issues
  - triage arch-specific bugs
  - fix arch-related bugs
  - maintain buildds
  - ...
  
  I am a DD|I am a DM|I am not a DD/DM
  
  YOUR NAME


Niels, on behalf of the release team

[LAST-BITS] http://lists.debian.org/debian-devel-announce/2013/08/msg6.html

[WIKI] https://wiki.debian.org/ArchiveQualification/Jessie

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSIu2TAAoJEAVLu599gGRC86EP/j/7FEZ9pxpTEHrBI41GTu6r
nENS5kAZAuxFQHfYLtKexBcgneGd6cgdmr3cIoh1ZL9lJgXq74X8FL5IbWNqUw9S
o9UQWpZJiwIIlH4fqSgFVLIphI0DQr7dXI7xcDIm4kl6Fdruo1tGxX8xqL23jzdP
nQb3jrXv3bj5943MfWeCbODILv2N6qev9VtWeQ6Wmh8PvxRUl7VqgdQaeHtlMsUp
TQT5fz0cw8gc2amlwlOZxaGDV2C8mHboJIKMEsu79BK4SlFSED9rXn4juFPUnAgG
uADsMdBBqEIgSMN42cPHQju+KLfJe/+xScmlzzDS/d7aWWs02TibcQ1ZnPi+bcgp
bd/Wa0lms+Fc2OpcuFle9Lwo+2B+ka1Dd3itm+D0SbmrxoGi6CuMMwydLcQbSJ73
hHw9HJEIQr2x/ZItNPJrSvvj50rwYXcmFbxtVAwv2pFXfQ37iukYgAaaMvnwpNNJ
6dM1coCF9skNkXLO8rkZ+5aupGgjpS9BdKKAEQrPy/aoaW9KNCZrLQeA4C3QySBU
OcCNBv7taSjVAVNszKtRIQpu2gzFGAV0u9Gj41qW1JzDHYrmAvMyGxrndOxTmaFr
p05QWgcMsPhNvdHjd6sWLyzJ5NYUKksCPMRgCc0BEd6moIyrt7UFsp2+guJZPBJ0
pffEJGK2iGtrWmJfElof
=TUeZ
-END PGP SIGNATURE-


-- 
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/20130901073351.a92862...@thykier.net