Re: Archiving the attic folders from d-i for ports

2018-04-27 Thread Bastian Blank
On Fri, Apr 27, 2018 at 05:37:25AM +0200, John Paul Adrian Glaubitz wrote:
> Since there are still some repositories that we need for debian-ports
> in the attic, I was wondering whether we should take care of the
> attic stuff and move it over to salsa or github.

Could you show a list?  Just migrate them the same way.

>Still, I think we should
> archive everything.

The complete content of alioth is going to be archived, so this is
covered.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5



Re: Sparc netboot image is too large to boot (again)

2012-02-18 Thread Bastian Blank
On Fri, Feb 17, 2012 at 08:00:24PM +, Jurij Smakov wrote:
 Attached patch implements the switch. It's not particularly elegant, 
 but minimally intrusive, only affecting the building ot sparc's 
 netboot image. I would like to commit it some time next week, unless 
 anyone objects.

I would do that for all architectures. There is no reason to use gzip on
any of them.

Bastian

-- 
We have the right to survive!
Not by killing others.
-- Deela and Kirk, Wink of An Eye, stardate 5710.5


-- 
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/20120218205825.ga25...@wavehammer.waldi.eu.org



Re: Sparc netboot image is too large to boot (again)

2012-02-05 Thread Bastian Blank
On Sun, Feb 05, 2012 at 02:09:11PM +0100, Samuel Thibault wrote:
 AIUI, linux can now have support for uncompressing bzip2, lzma and lzo.

CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y

The amd64 image have support for gzip, bzip2, lzma and the xz variant.

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, The Omega Glory, stardate unknown


-- 
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/20120205135549.ga2...@wavehammer.waldi.eu.org



Re: Sparc release requalification

2009-08-20 Thread Bastian Blank
On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote:
 On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote:
  If I understand this correctly, this would need the modification off all
  library packages to implement biarch semantic.
 ... which will be needed anyways. So your choice is actually between
 doing it and doing it plus some extra intermediate work.

No, we don't need to do that. Thats what is multiarch for.

Bastian

-- 
Captain's Log, star date 21:34.5...


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



Re: Sparc release requalification

2009-08-20 Thread Bastian Blank
On Thu, Aug 20, 2009 at 10:53:08AM +0200, Philipp Kern wrote:
 It's not intended that multiarch supports switching architectures.

It's also just an upgrade. Or did I miss something that would make it
impossible to replace perl/i386 with perl/amd64?

Bastian

-- 
Many Myths are based on truth
-- Spock, The Way to Eden,  stardate 5832.3


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



Re: Sparc release requalification

2009-08-19 Thread Bastian Blank
On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
 I did speak with Martin Zobel at Debconf on how to get there, having two 
 proposals:
  - define a new sparc64 port, and bootstrap this one using the 32bit port.

This is rather easy. I already did a s390x bootstrap using this method.

  - have an inplace-transition building required library packages for an
upgrade as biarch packages and continue to use the current sparc name.

This would mean that many packages needs to be modified. Is it really
worth the work needed if we consider the availability of multiarch in
the next time?

Bastian

-- 
He's dead, Jim.
-- McCoy, The Devil in the Dark, stardate 3196.1


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



Re: Sparc release requalification

2009-08-19 Thread Bastian Blank
On Wed, Aug 19, 2009 at 01:55:24PM +0200, Matthias Klose wrote:
 On 19.08.2009 13:42, Bastian Blank wrote:
 On Wed, Aug 19, 2009 at 01:16:36PM +0200, Matthias Klose wrote:
 I did speak with Martin Zobel at Debconf on how to get there, having two 
 proposals:
   - have an inplace-transition building required library packages for an
 upgrade as biarch packages and continue to use the current sparc name.
 This would mean that many packages needs to be modified. Is it really
 worth the work needed if we consider the availability of multiarch in
 the next time?
 you'll end up modifying a different set of packages for the new 
 architecture name in control and rules files. I don't know if this is 
 less or more work.

If I understand this correctly, this would need the modification off all
library packages to implement biarch semantic.

Bastian

-- 
Star Trek Lives!


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



Re: [FIX]: ultra45 boot failing...

2009-02-07 Thread Bastian Blank
Package: linux-2.6
Version: 2.6.26-13
Severity: grave

I consider this RC. We'll break X.org either for r0 or r1.

debian-sparc: Please provide someone who wants to take over sparc
architecture maintenance of the Linux packages.

On Sat, Feb 07, 2009 at 10:45:31AM +, Jurij Smakov wrote:
 On Fri, Feb 06, 2009 at 11:11:44PM -0800, David Miller wrote:
  
  The patch:
  
  debian/patches/bugfix/sparc/arch_pci_hostcontroller_workaround.patch
  
  causes ultra45 (and other PCI-Express based workstations) to
  hard reset when the PCI bus is initially scanned by the kernel.
  
  Please revert this patch from the debian kernel in Lenny and
  anywhere else it appears.
  
  The code in that patch creating dummy PCI root host controller nodes
  is wrong and does nothing other than cause trouble.  If it fixes some
  problem with the X server for PCI devices on sparc64 that problem
  needs to be fixed some other way.
  
  Thank you.
 
 I believe that we are just a few days from Lenny release, so uploading 
 a new kernel and rebuilding debian-installer might not be an option 
 at this point, unfortunately. The best we can probably do is include 
 the fixed kernel in the point release, but that's up to kernel team 
 to decide. 

Bastian

-- 
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, Shore Leave, stardate 3025.3


signature.asc
Description: Digital signature


Re: Bug#500358: Fix found

2008-11-27 Thread Bastian Blank
reassign 500358 xserver-xorg-core
thanks

On Tue, Nov 11, 2008 at 11:07:06PM +0100, Julien Cristau wrote:
 On Tue, Nov 11, 2008 at 22:10:03 +0100, Bastian Blank wrote:
  I fail to see the _kernel_ bug it fixes. I now know that this change
  triggers a bug in the old (considered broken by design[1]) PCI code in
  _X.org_.
 The revert doesn't fix a kernel bug.  It works around an X bug.  I
 thought that was clear all along, sorry if it wasn't.

So as it is now worked around, lets get the bug to the right package.

Bastian

-- 
Captain's Log, star date 21:34.5...


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



Re: Bug#500358: Fix found

2008-11-11 Thread Bastian Blank
On Mon, Nov 10, 2008 at 11:46:24AM +0300, Max Dmitrichenko wrote:
  It is the decision of the maintainer if nothing else matches.
 Ok. Who is the maintainer?

debian-kernel, represented by whom doing the work.

 Go on and read the discussion of this bug if you really interested why
 these patches differ.

You want something from us. Also the bugreport reads itself as two
different bugs, which does not make it easier to understand.

   In short, the last patch is the first patch
 merged with Gaudenz's patch which revert changes of SPARC PCI in
 2.6.26 which breaks xserver-xorg-video-ati package.

The first patch is fine. The revert is not.

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, The Conscience of the King, stardate 2818.9


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



Re: Bug#500358: Fix found

2008-11-11 Thread Bastian Blank
On Tue, Nov 11, 2008 at 08:20:01PM +0100, Julien Cristau wrote:
 On Tue, Nov 11, 2008 at 18:22:57 +0100, Bastian Blank wrote:
  The first patch is fine. The revert is not.
 Even if the revert is the only way to get X to work on those machines in
 lenny?

I fail to see the _kernel_ bug it fixes. I now know that this change
triggers a bug in the old (considered broken by design[1]) PCI code in
_X.org_.

So this bug actually contains three:
- The missalignment in the PCI code in the kernel.
- The broken PCI access code in X.org.
- A request to readd the workaround to the kernel to make X.org work
  again (and possibly break other things).

Bastian

[1]: [EMAIL PROTECTED]
-- 
Warp 7 -- It's a law we can live with.


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



Re: Bug#500358: Fix found

2008-11-09 Thread Bastian Blank
On Sun, Nov 09, 2008 at 09:37:11PM +0300, Max Dmitrichenko wrote:
 2008/11/9 Bastian Blank [EMAIL PROTECTED]:
  OK, since there was no opposition and there is still no explaination on
  why this bug was donwgraded in the first place I'm upgrading it back to the
  initial severity.
 
  There is only a small fraction of machines affected, so this is not RC.
 
 This is not a PC case where one can assemble some unique set of components 
 which
 will not work together well.

Hmm, my Sparc got PCI-X and PCIe. Okay, I never tried to put a random
card in it, but why should it not work?

  SPARC is a traditionally brand
 architecture. This case
 affects Ultra 5 and may be several other workstation. So if something
 doesn't function
 on one box it doesn't function on a whole generation of boxes. I think this is
 quite a big part of all Debian SPARC users.

This still does not qualify for the severity grave:

| makes the package in question unusable or mostly so,

It still runs. And the Sparc machines I use don't show such problems.

 And if SPARC is qualified
 for release
 then this is definitely RC.

It is the decision of the maintainer if nothing else matches.

 And do not hesitate to use common sense. Refusal of fixing the bug
 should be made
 only if you are afraid of breaking something else. This patch targets
 only SPARC. It has
 absolutely no influence on other archs, so it won't break anything
 else even in the worst case.

NMUing a properly maintained package without action from the CTTE is
also a no-go.

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5769907ade8dda7002b304c03ef9e4ee5c1e0821

This is a different patch then
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=102;filename=sparc_fix_for_debian.patch;att=1;bug=500358

Bastian

-- 
History tends to exaggerate.
-- Col. Green, The Savage Curtain, stardate 5906.4


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



Re: Bug#500358: Fix found

2008-11-08 Thread Bastian Blank
severity 500358 important
thanks

On Sat, Nov 08, 2008 at 11:54:38PM +0100, Gaudenz Steinlin wrote:
 On Thu, Nov 06, 2008 at 06:24:57PM +0100, Gaudenz Steinlin wrote:
  As this affects a major part of all SPARC machines, I really think this is 
  release
  critical and the bug severity should be upgraded again. If you don't 
  disagree strongly
  I will upgrade it in the next days.
 OK, since there was no opposition and there is still no explaination on
 why this bug was donwgraded in the first place I'm upgrading it back to the 
 initial severity. 

There is only a small fraction of machines affected, so this is not RC.

 What's the best way forward on this issue? I'm a bit hesitant on just 
 preparing
 an NMU for the kernel, for obvious reasons. It would much prefer it, if a 
 member
 of the kernel team would take care of appling the patch.

I fail to find anything near this patch in upstream (Linus' tree), which
would be the first target. So please provide commit IDs along with
patches. If you want to force us to apply patches which does not follow
our guidelines, you have to ask CTTE.

Bastian

-- 
Beam me up, Scotty!


signature.asc
Description: Digital signature


Kernel sparc maintainer wanted

2007-09-03 Thread Bastian Blank
Hi folks

The kernel team currently lacks a maintainer of the sparc port. There
are now 2 RC bugs open which needs attention if sparc don't want to be
dropped in the near future.

Bastian

-- 
But Captain -- the engines can't take this much longer!


signature.asc
Description: Digital signature


Bug#433187: linux-2.6 - [sparc64-smp] produces unkillable processes

2007-07-15 Thread Bastian Blank
Package: linux-2.6
Version: 2.6.18-5
Severity: grave
Forwarded: [EMAIL PROTECTED]

sparc64 kernels produces unkillable dpkg-query processes (only seen in a
buildd environment yet). Each process sucks one cpu and 3GiB of memory.
Even the OOM killer is not able to kill them.

This problem exists up to 2.6.21 (and most likely also .22) and makes it
mostly impossible to run a reliable buildd.

The problem was forwarded to upstream[1] but no response yet.

Bastian

[1]: http://article.gmane.org/gmane.linux.ports.sparc/7867

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.


signature.asc
Description: Digital signature


Re: Dropping sparc32 for Lenny (was: Scheduling linux-2.6 2.6.21-[23])

2007-05-18 Thread Bastian Blank
On Fri, May 18, 2007 at 01:10:15PM +0200, Frans Pop wrote:
  - sparc32 deprecation? No fix yet for the cmpxchg problem.

For now I only want to disable it.

 In that thread there was some opposition to the idea, but I've not seen 
 anybody making the commitment to maintain sparc32, so dropping it for 
 Lenny does seem logical.

I have to acknowledge the message from Dave[1]. Until there is a new
kernel upstream it may be possible to compile it but it is impossible to
fix real problems.

 However, I do not think this is a decision that should be made solely on 
 the debian-kernel list. I also feel that the decision (when it has been 
 made) should be announced to our users.

-kernel can produce facts. I have no problems building it, but someone
else needs to do the support.

Bastian

[1] http://permalink.gmane.org/gmane.linux.ports.sparc/7531

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, Day of the Dove, stardate unknown


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



Re: Scheduling linux-2.6 2.6.21-[23]

2007-05-18 Thread Bastian Blank
On Fri, May 18, 2007 at 12:18:57PM +0200, Bastian Blank wrote:
 I'd like to schedule the linux-2.6 2.6.21-[23] upload for today.

I'll disable sparc32 and all hppa images.
- sparc32: see the other discussion.
- hppa: broken toolchain which makes it impossible to build them and we
  need linux-libc-dev.

Bastian

-- 
Murder is contrary to the laws of man and God.
-- M-5 Computer, The Ultimate Computer, stardate 4731.3


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