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

2013-10-06 Thread Sven Luther
Hi Niels,

I don't know upto what point you are familiar with my history and its link to 
the powerpc
port, but it pains me to see that the powerpc port is left with so few porters, 
and that it 
may mean the port being dropped. I also have not really followed the mailing 
lists since 
a long time, and don't know who is actually managing the powerpc port, but 
giving the (1) and 
0.5 remark, i guess there is not a full porter.

So given that, and provided debian may not see a problem again in me becoming 
active, i may
be interested in becoming active again as powerpc maintainer. Not sure what 
category you 
can include me in though, and what the formalities would be should i become 
active (and welcome)
in debian again.

Also, i am not really sure of the amount of time i will be able to devote to 
debian, and i will
have to take my powerpc hardware out of the storage area i put it in, but i 
guess it should be enough
to do powerpc porting work, provided other folk help me out. That said, i am 
also interested in the
powerpcspe port, as i am (slowly) working on a open-hardware Freescale P1010 
based board.

Anyway, please let me know if there is anything i can do.

Friendly,

Sven Luther

On Wed, Oct 02, 2013 at 09:45:35AM +0200, 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.
 

 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

Re: Fixed RC bug in frozen parted : #392767: [mac] parted is unable to reread partition tables created by d-i/partman.

2006-11-07 Thread Sven Luther
On Tue, Nov 07, 2006 at 08:08:26PM +0100, Robert Millan wrote:
 
 I'm sorry.  Please feel free to disable the patch; I'm thinking it was not a
 good idea to apply it in the package before it was merged upstream (as it was
 about to, last time I visited this).
 
 Apologises for the hassle.

No problem, i am happy we found it before the release though.

Will you be able to work out a better/cleaner patch ? And work with us to
merge it upstream ?

Friendly,

Sven Luther


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



Re: [D-I] mass kernel udeb update and preparations for RC1

2006-09-19 Thread Sven Luther
On Sun, Sep 17, 2006 at 02:28:06PM +0200, Frans Pop wrote:
 * powerpc: oldworld boot problems with recent kernels

Both will be fixed in 2.6.18, and are already in the 2.6.18-rc7 snapshots
since today.

We don't have 2.6.18 based d-i to confirm this, but i will do a custom build
over the week to confirm this.

I don't particularly feel like backporting those fixes to 2.6.17, especially
as the etch kernel target is 2.6.18, but others may volunteer to do it, or i
may do it if i find some time.

Friendlly,

Sven Luther


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



Re: Changes in formal naming for NetBSD porting effort(s)

2003-12-18 Thread Sven Luther
On Wed, Dec 17, 2003 at 06:37:56PM -0600, Kevin Kreamer wrote:
 [I am not subscribed to debian-bsd.]
 
 On Dec 17, 2003, at 10:20, Branden Robinson wrote:
 Given that we're going to be saddled with with a comprehension problem
 anyway, I say we abandon the effort to be descriptive in the product
 name.  I proposed having a correlation between the first letter of the
 product name and the underlying BSD variant simply as a mnemonic
 convenience for people who already know what the products are supposed
 to be.
 
 We don't have to *completely* give up the effort to be descriptive.  
 How about just calling it:
 
 Debian GNU/NBSD
 Debian GNU/FBSD
 Debian GNU/OBSD (if there's ever an OpenBSD port)
 
 It would have the advantage of being recognizable to most people, 
 without actually using 'NetBSD' or so anywhere in the name.
 
 [ The following suggestion is possibly flameworthy.  Please consider 
 the above separate from the below. ]
 
 In the case of a NetBSD libc, you could use
 
 Debian NBSD/NBSD
 
 basically having the first half signify which libc is used.  However, 
 if Debian is always going to use the GNU/ prefix, then perhaps make it 
 something like
 
 Debian GNU/NBSD/NBSD
 
 with the third part signifying the libc used.

I would better say that the second part be the libc, and that it can be
omitted if it is the same as most userland.

That said, we don't have only GNU stuff as userland.

Friendly,

Sven Luther




Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)

2003-12-18 Thread Sven Luther
On Wed, Dec 17, 2003 at 11:26:10AM -0600, Chad Walstrom wrote:
 On Wed, Dec 17, 2003 at 04:42:28PM +0100, Sven Luther wrote:
  Well, just for the record, i personnally would prefer we don't use
  demon name for keyword if possible.
 
 Forgive me for the gratuitous Harry Potter reference, but fear of a
 name increases fear for the thing itself. ;-p

It is not about fear, just some uneasiness inside. 

 IOW, lighten up, people.  Otherwise, we'll be referring to Debian
 GNU/That Which Shall Not Be Named...

That would be a funny naming scheme. That said, how would we then
differentiate the three BSD ports ? GNU/First one that shall not be
named and so one ?

Friendly,

Sven Luther