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



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 , 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: 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 , 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: 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  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 , 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: Seems I have bad timing with Debian on SPARC.

2013-10-02 Thread Patrick Baggett
On Wed, Oct 2, 2013 at 4:36 PM, u60 spitfire  wrote:

> 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.
>
>
Linux on SPARC is very niche. Think of yourself as...frontiersmen. Consider
the cases though: you go to Oracle.com and cheap server is $20K. So you can
either use:

a) 100% supported Solaris 11.1, 24x7 phone support, deep virtual machine
support, apps/libraries optimized for the HW, etc.
b) Linux, which may or may not recognize your disk controller and may panic
while booting the kernel on really new machines.


> 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.
>

I think Debian/sparc is probably one of the better distributions for SPARC,
but it can be quite rough, yeah. I run it and I don't have too many
problems. I run it on an Ultra 80, E420R (Ultra 80 but with diff case IIRC)
and a Blade 2500. Neither gives me problems, but running Sun-branded
components is really hard -- Sun was never very forthcoming with HW specs
and even if they had now, there would be little interest in pre-2000 HW to
actually fix the drivers. You can try Solaris 10 if you have a lot of
memory, but you're going to need to customize it, because for playing
around, you probably don't need all of the stuff it installed.

I personally enjoy Linux on SPARC more than Solaris on SPARC because I can
mix cheap PC components in the PCI slots to get some flexibility, so long
as it isn't critical for booting the system [e.g. disk controllers]. I ran
an Ultra 10 with an NV GeForce4 for example and was able to play Quake III.
Not all drivers work that well though, and I've filed a few bugs and other
times just written off the driver as "meh" (for example, some SPARC sound
drivers -- why bother if you can replace with $10 PCI sound card?)

So I guess, I'd say stick with Debian. I think your experience with the
Ultra 60 should be pretty decent overall, though if you need a new NVRAM
battery, yeah, going to suck a bit. :)

If you're having some issues, posted here, and I missed it, I'm sorry. I
try to help when I can. Please let us know what they are and let's see if
we can't work them out.

Patrick


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


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


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  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 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 Steve McIntyre
On Wed, Oct 02, 2013 at 04:07:25PM +0100, Wookey wrote:
>+++ 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. :-)

*grin* I guess so...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...


-- 
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/20131002151044.gk14...@einval.com



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: 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 , 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 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: 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 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 , 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: 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] 
  [2] 

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



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