Re: O: silo -- Sparc Improved LOader

2013-10-02 Thread Jurij Smakov
On Wed, Oct 2, 2013 at 3:27 AM, Axel Beckert a...@debian.org wrote:

 Control: retitle -1 ITA: silo -- Sparc Improved LOader
 Control: owner -1 !

 Hi Jurij,

 Jurij Smakov wrote:
  There are currently no serious bugs that I know of, so it's mostly about
  keeping it reasonably up to date.

 Ok, I'll try my luck. I managed to revamp the package in a way that my
 UltraSparc still boots. ;-)

 I though couldn't yet play around with silo on sparc64, see my other
 recent mail to debian-sparc@lists.debian.org.

  Prospective maintainers should have access to sparc hardware to be
  able to do at least minimal testing,

 Given.

  joining the 'debootloaders' project on Alioth (within which silo was
  previously maintained) is a good idea as well.

 Request sent. I'm also already subscribed to the debootloaders-silo
 mailing list.

 I though don't intent to continue maintaining the package in svn, but
 rather switch to git, with the git repository based on the previous
 svn repository.

 I'll create the git repository on Alioth and push my changes as soon
 as I've got write permissions to /git/debootloaders/.


I approved your membership request, so you should be good to go now.

Thanks for picking it up.



 Further co-maintainers of course still welcome! :-)

 Regards, Axel
 --
  ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
 : :' :  |  Debian Developer, ftp.ch.debian.org Admin
 `. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
   `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5




-- 
Jurij Smakov | ju...@wooyd.org | Key IDs: 43C30A7D/C99E03CC


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

2013-10-02 Thread 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: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

2013-10-02 Thread Ansgar Burchardt
On 10/02/2013 09:45, Niels Thykier wrote:
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 ---++-++-++---++--
[...]
 sparc[2]   ||  1  ||   0 || 0 ||1
 
 [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.

In addition gcc no longer supports 32bit sparc according to the
architecture qualification notes for Squeeze[1] and Wheezy[2].

  [1] http://release.debian.org/squeeze/arch_qualify.html#sparc-upstream
  [2] http://release.debian.org/wheezy/arch_qualify.html#sparc-upstream

So it might make sense to drop sparc in any case and add sparc64 if
there are enough people interested.

Ansgar


-- 
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/524be06e.2000...@debian.org



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

2013-10-02 Thread Axel Beckert
Hi,

[I've replaced debian-ports with debian-sparc in the recipients list]

Niels Thykier wrote:
 Arch   || DDs || NMs/DMs || Other || Total
 ---++-++-++---++--
[…]
 sparc[2]   ||  1  ||   0 || 0 ||1
[…]
 [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.

Ansgar Burchardt wrote:
 So it might make sense to drop sparc in any case and add sparc64 if
 there are enough people interested.

Well, count me in for sparc64 in general, too. I expect, too, that's
where we're heading to anyway, and I don't expect too many
differences. I though fear that we're not yet there:

Yesterday I tried to setup a sparc64 chroot on a second disc in one of
my Sparcs, but the currently documented way[1] to do so failed[2] due
to outdated packages. On a first glance it looks like missing BinNMUs
for the Perl 5.14 to Perl 5.18 transition.

[1] https://wiki.debian.org/Sparc64#Bootstrapping_sparc64
[2] https://lists.debian.org/debian-sparc/2013/10/msg1.html

OTOH such issues were present in the past[3] of sparc64, too, back
then with the transition from Perl 5.10 to Perl 5.12.

[3] https://lists.debian.org/debian-sparc/2011/05/msg00030.html

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


signature.asc
Description: Digital signature


Re: Bootstrapping Sparc64: Outdated, but required perl module packages? (Perl 5.14 vs 5.18)

2013-10-02 Thread Frans van Berckel
 Hi,

 I was trying to get Sparc64 running as documented on
 https://wiki.debian.org/Sparc64#Bootstrapping_sparc64 but multistrap
 failed due to some required Perl module packages not yet being rebuilt
 against Perl 5.18:

 I: Calculating required packages.
 apt-get -y  -o Apt::Architecture=sparc64 -o
 Dir::Etc::TrustedParts=/mnt/sparc64/etc/apt/trusted.gpg.d -o
 Dir::Etc::Trusted=/mnt/sparc64/etc/apt/trusted.gpg.d/trusted.gpg -o
 Apt::Get::AllowUnauthenticated=true -o Apt::Get::Download-Only=true -o
 Apt::Install-Recommends=false -o Dir=/mnt/sparc64/ -o
 Dir::Etc=/mnt/sparc64/etc/apt/ -o
 Dir::Etc::Parts=/mnt/sparc64/etc/apt/apt.conf.d/ -o
 Dir::Etc::PreferencesParts=/mnt/sparc64/etc/apt/preferences.d/ -o
 APT::Default-Release=* -o Dir::State=/mnt/sparc64/var/lib/apt/ -o
 Dir::State::Status=/mnt/sparc64/var/lib/dpkg/status -o
 Dir::Cache=/mnt/sparc64/var/cache/apt/ install  apt base-files base-passwd
 bash bsdutils coreutils dash debconf debconf-i18n
 debian-ports-archive-keyring debianutils diffutils dpkg dpkg-dev e2fslibs
 e2fsprogs findutils gcc-4.7-base gcc-4.8-base grep gzip hostname
 initscripts libacl1 libattr1 libblkid1 libc-bin libc6 libcomerr2 libgcc1
 liblocale-gettext-perl liblzma5 libmount1 libncurses5 libpam-modules
 libpam-modules-bin libpam-runtime libpam0g libpcre3 libselinux1 libsepol1
 libss2 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl
 libtinfo5 libuuid1 login lsb-base mawk mount multiarch-support
 ncurses-base ncurses-bin passwd perl-base sed sensible-utils sysv-rc
 sysvinit sysvinit-utils tar tzdata util-linux zlib1g
 Reading package lists... Done
 Building dependency tree... 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:
  liblocale-gettext-perl : PreDepends: perlapi-5.14.2 but it is not
 installable
  libtext-charwidth-perl : Depends: perlapi-5.14.2 but it is not
 installable
  libtext-iconv-perl : Depends: perlapi-5.14.2 but it is not installable
 E: Unable to correct problems, you have held broken packages.
 apt download failed. Exit value: 100

Strange, these dependencies got to call 5.18.1-2 as well. Sparc64 does
both. Because 5.18.1-2 is what's in the repo. You can check the sheets.

http://packages.debian.org/sid/liblocale-gettext-perl
http://packages.debian.org/sid/libtext-charwidth-perl
http://packages.debian.org/sid/libtext-iconv-perl
http://ftp.debian-ports.org/debian/pool-sparc64/main/p/perl/

About using stable; Debian-ports repo does unstable, experimental, sid and
unreleased. True it's main only.

http://ftp.debian-ports.org/debian/dists/

Thanks,


Frans van Berckel

Simple, if Media Engineering does!
Website: http://www.fransvanberckel.nl/


-- 
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/9d60109dcd3d00a0c9fcd1e3e0fe6258.squir...@webmail.xs4all.nl



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 ni...@thykier.net 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: Bootstrapping Sparc64: Outdated, but required perl module packages? (Perl 5.14 vs 5.18)

2013-10-02 Thread Axel Beckert
Hi Frans,

thanks for looking into this issue.

Frans van Berckel wrote:
  The following packages have unmet dependencies:
   liblocale-gettext-perl : PreDepends: perlapi-5.14.2 but it is not
  installable
   libtext-charwidth-perl : Depends: perlapi-5.14.2 but it is not
  installable
   libtext-iconv-perl : Depends: perlapi-5.14.2 but it is not installable
  E: Unable to correct problems, you have held broken packages.
  apt download failed. Exit value: 100
 
 Strange, these dependencies got to call 5.18.1-2 as well. Sparc64 does
 both. Because 5.18.1-2 is what's in the repo. You can check the sheets.

Sure, Perl is 5.18 in the repo, but not all necessary packages have
been rebuilt for 5.18:

 http://packages.debian.org/sid/liblocale-gettext-perl

From that page:

dep: perl-base (= 5.14.2-3) [sparc64]
dep: perl-base (= 5.18.1-2) [nicht sparc64, …]

dep: perlapi-5.14.2 [sparc64, …] virtuelles Paket, bereitgestellt durch 
perl-base 
dep: perlapi-5.18.1 [nicht sparc64, …] virtuelles Paket, bereitgestellt durch 
perl-base

So it clearly states that liblocale-gettext-perl on sparc64 is out of
date with regards to the Perl.

 http://packages.debian.org/sid/libtext-charwidth-perl
 http://packages.debian.org/sid/libtext-iconv-perl

Same issue here.

So who can schedule BinNMUs for sparc64? Because that's what would
help.

Or can I cross-compile stuff for sparc64 on sparc?

 About using stable; Debian-ports repo does unstable, experimental, sid and
 unreleased. True it's main only.

That's ok. I just thought it may help to install Stable and then
dist-upgrade to unstable to workaround this issue.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20131002124801.gd3...@sym.noone.org



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

2013-10-02 Thread Wookey
+++ Niels Thykier [2013-10-02 09:45 +0200]:
 Hi,
 
 The final results are in:
 
 Summary table:
 Arch   || DDs || NMs/DMs || Other || Total
 ---++-++-++---++--
 armel  ||  3  ||   0 || 1 ||4
 armhf  ||  3  ||   1 || 2 ||6

 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 :-)

   arm64: Wookey (DD), Steve McInture (DD)

There are other DDs working on this too (Doko and Riku
particularly), but again they are probably trying to avoid getting
any more formal responsibilities. :-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
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/20131002150724.ge32...@stoneboat.aleph1.co.uk



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

2013-10-02 Thread Dave Jones
Hello, all.

I am not currently a porter but I would like to be one for the s390x
architecture.


I am familiar with zSeries system programming and have a lot of
experience in running Linux in virtual environments, mostly z/VM on
large IBM processors..  I use Linux for 11 year, family with cross
compiling tool chain.

I am not a DD/DM. and I am somewhat surprised not to see Philiip Kern
(pk...@debian.org) on the list.

DJ

On 10/02/2013 02:45 AM, Niels Thykier wrote:
 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.
 

-- 
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544


-- 
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/524c3ab0.2020...@vsoft-software.com



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

2013-10-02 Thread Patrick Baggett
I'm interesting in helping on ia64. I'm not fluent in ia64 assembly, but I
can get around pretty well. I'm very experienced in C/C++/Java and
debugging. I've got a fully functional system running Xorg/Mesa3D/sound, so
I can reproduce, test, and fix issues as time permits.

Patrick Baggett


On Wed, Oct 2, 2013 at 2:45 AM, Niels Thykier ni...@thykier.net wrote:

 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: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)

2013-10-02 Thread Julien Cristau
On Wed, Oct  2, 2013 at 11:44:44 +0200, Axel Beckert wrote:

 Yesterday I tried to setup a sparc64 chroot on a second disc in one of
 my Sparcs, but the currently documented way[1] to do so failed[2] due
 to outdated packages. On a first glance it looks like missing BinNMUs
 for the Perl 5.14 to Perl 5.18 transition.
 
Part of the porter's job is to take care of that kind of things.  If
that's not happening for sparc64 because nobody's actually taking care
of the port, I don't see it as a viable candidate for the archive...

Cheers,
Julien


signature.asc
Description: Digital signature


Seems I have bad timing with Debian on SPARC.

2013-10-02 Thread u60 spitfire
Just signed up for this mailing list; had spent a good amount of time
over the last week getting my Ultra 60 up and running again.  It's
mostly OK...heh...execpt the part about having to reprogram the darn
NVRAM every time I turn it on.

I got jessie installed (Didn't get far in the stable release; first
thing I did was try to open iceweasel and it hit a bus error --
unaligned mem access maybe).  Working on getting the framebuffer going
and whatnot now, went to the Debian forums and figured I'd try this
mailing list after no responses there.

After checking the posts for the last few months (only a handful!),
they seem all about Helloanybody out there using/maintaining
this?  or Hey if anyone's using driver X y'all need to maintain it
yourself 'cause you're the only one using it, heh.

So, realistically*, what's the deal?  Any point in trying to get this
to work or should I cut my losses now and move to some other
distribution or OS?  I had thought that maybe there was some interest
in the architecture since OpenSPARC was published/available for some
time.  Anyhow.

Advice appreciated in advance.

thanks



*Yes, I'm not being terribly realistic running anything on this box to
begin with.


-- 
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/CAN-w9fwQ7=FhaE3R=o7Ehx7ckMm=cfxuyiixinjcchmttbc...@mail.gmail.com



Re: Bug#721498: O: silo -- Sparc Improved LOader

2013-10-02 Thread Axel Beckert
Hi Jurij,

Jurij Smakov wrote:
 On Wed, Oct 2, 2013 at 3:27 AM, Axel Beckert a...@debian.org wrote:
  I'll create the git repository on Alioth and push my changes as soon
  as I've got write permissions to /git/debootloaders/.
 
 I approved your membership request, so you should be good to go now.

Done:

http://anonscm.debian.org/gitweb/?p=debootloaders/silo.git;a=shortlog

Upload preferably after I managed to build silo on sparc64, too. If
that seems too far away, I'll probably upload earlier.

 Thanks for picking it up.

Thanks for all your work on silo so far!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20131002225843.gh3...@sym.noone.org



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

2013-10-02 Thread Axel Beckert
Him

Julien Cristau wrote:
 On Wed, Oct  2, 2013 at 11:44:44 +0200, Axel Beckert wrote:
  Yesterday I tried to setup a sparc64 chroot on a second disc in one of
  my Sparcs, but the currently documented way[1] to do so failed[2] due
  to outdated packages. On a first glance it looks like missing BinNMUs
  for the Perl 5.14 to Perl 5.18 transition.
 
 Part of the porter's job is to take care of that kind of things.

Definitely.

 If that's not happening for sparc64 because nobody's actually taking
 care of the port, I don't see it as a viable candidate for the
 archive...

*nod* One of the reasons why I'm trying to improve that...

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20131002230600.gi3...@sym.noone.org



Re: Bootstrapping Sparc64: Outdated, but required perl module packages? (Perl 5.14 vs 5.18)

2013-10-02 Thread Axel Beckert
Hi again,

Axel Beckert wrote:
 Frans van Berckel wrote:
   The following packages have unmet dependencies:
liblocale-gettext-perl : PreDepends: perlapi-5.14.2 but it is not
   installable
libtext-charwidth-perl : Depends: perlapi-5.14.2 but it is not
   installable
libtext-iconv-perl : Depends: perlapi-5.14.2 but it is not installable
   E: Unable to correct problems, you have held broken packages.
   apt download failed. Exit value: 100

Got it working. Took the full apt-get command as multistrap did, but
removed the three perl modules in question as well as debconf-i18n
which needs them, but I never need and which I consider to be
primarily disk space waste.

But this just got stuff downloaded. Next step was to put that reduced
package list into the multistrap.conf's packages= and set
omitrequired=true (needs to be in the [General] section) and
restart. That worked. Yay!

Will likely try to build these three packages locally and see how far
I come.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert a...@debian.org, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
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/20131002234858.gj3...@sym.noone.org



Re: Bootstrapping Sparc64: Outdated, but required perl module packages? (Perl 5.14 vs 5.18)

2013-10-02 Thread Frans van Berckel
Hi Axel,

 Got it working. Took the full apt-get command as multistrap did, but
 removed the three perl modules in question as well as debconf-i18n
 which needs them, but I never need and which I consider to be
 primarily disk space waste.

 But this just got stuff downloaded. Next step was to put that reduced
 package list into the multistrap.conf's packages= and set
 omitrequired=true (needs to be in the [General] section) and
 restart. That worked. Yay!

 Will likely try to build these three packages locally and see how far
 I come.

You did it! If you have a extra partition left, it's smart to copy a
backup on that before install the dev tools. So you can always go
back-forward.

It's good to know from sparc you can easily chroot into a mounted sparc64
partition. Beware, please mount /proc  /sys before if needed.

Thanks,

Frans van Berckel


-- 
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/e952dd49deaab142e163b7adc67750a4.squir...@webmail.xs4all.nl