Re: [Stretch] Status for architecture qualification

2016-06-27 Thread Wouter Verhelst
(sorry for jumping in late here)

On Wed, Jun 15, 2016 at 07:51:55AM +0800, Paul Wise wrote:
> On Wed, 2016-06-15 at 01:37 +0300, Dimitri John Ledkov wrote:
> 
> > At the openmainframeproject EU meetup, it was indicated that SUSE
> > joined with indication that Open Build Service might be able to use
> > resources hosted by Marist.
> > 
> > I wonder if it makes sense to reach out, and see if there are
> > resources available to use as porter boxes & build boxes. That way
> > Debian might be able to get such donated resource available on ongoing
> > basis and hopefully with some hw support.
> 
> Marist already support Debian with an s390x buildd:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(sponsor=*marist*)"
> https://db.debian.org/machines.cgi?host=zani
> 
> Our other sponsors for s390 are www.iic.kit.edu and www.zivit.de:
> 
> ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org  
> "(architecture=s390*)" sponsor

Given that we already seem to have three hardware sponsors for the s390x
port, is this really a concern?

If we were to lose one sponsor, we'd still have two (and it would be
reasonable to try to ensure that we get a new sponsor to replace the one
lost).

How about making it a requirement that there is some level of redundancy
in sponsors for ports where hardware cannot be easily bought with Debian
money? That would cover the s390x port as well as any potential other
insanely-expensive-hardware port[1] that we might support now or in the
future.

If push comes to shove, we could also talk to IBM. Pretty much all POWER
hardware we have was sponsored by IBM; it's not unreasonable to assume
they might be willing to also sponsor s390x time or hardware.

[1] not that I know of any, but hey, you never know.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12



Re: Time to change the debian-ports list?

2015-07-22 Thread Wouter Verhelst
Hi,

(haven't seen the original mail, so replying to this one)

On Fri, Jul 17, 2015 at 01:40:20PM +0100, Steve McIntyre wrote:
 On Thu, Sep 11, 2014 at 12:51:29PM +0100, Steve McIntyre wrote:
 On Wed, Sep 10, 2014 at 07:01:00PM +, Thorsten Glaser wrote:
 Alexander Wirt dixit:
 
 Could you please (technically) summarize what needs to be done from
 listmaster side? 
 
 1. Remove whatever debian-po...@lists.debian.org is right now
 
 2. Create a new debian-po...@lists.debian.org mailing list which
works just like the other regular lists
 
 3. Announce the new debian-po...@lists.debian.org so that people
can subscribe to it; document that there is no longer
an address to reach *all* ports but that people should
eMail the individual ports’ lists (and cross-post if
needed, but only to the amount needed), and that the
new debian-po...@lists.debian.org instead is a mailing list for
discussion about
a) debian-ports.org infrastructure
b) porting Debian in general
c) questions related to setting up a Debian port,
   including wanna-build, buildd, etc.

That seems like a bad idea to me, tbh. There will be people who won't
notice that the meaning of debian-ports@ has changed, and who will try
to use it with its old meaning.

If there are problems with the current meaning of debian-ports, can't we
just retire the old alias and create a list under a different name?

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26


-- 
To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150722153817.gb9...@grep.be



Re: Current and upcoming toolchain changes for jessie

2013-06-19 Thread Wouter Verhelst
On 14-06-13 21:11, Thorsten Glaser wrote:
 Wouter, Mikael: input on switching C/C++ to 4.8?

We don't have much data either way, do we?

I suppose it shouldn't be too much of a problem, but I can't be sure. In
the past we've usually taken the plunge, and filed bugs if things go
really bad.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51c171d9.50...@debian.org



Re: Architecture usertags

2009-03-05 Thread Wouter Verhelst
On Thu, Mar 05, 2009 at 11:22:19AM +0100, Peter Palfrader wrote:
 On Tue, 03 Mar 2009, Wouter Verhelst wrote:
 
 The format, suggested by Steve Langasek, was to use the
  porters mailinglist as the user, and the architecture name as the
  usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
  tag).
 
 Or debian-po...@lists.debian.org as user.

I did not think that would be a good idea, since the AFAIK the bts will
send out a mail to the mail address listed as user when a usertag is
set; it is okay if adding a 'powerpc' tag causes a mail to be sent to
the powerpc mailinglist; I do not think it is okay if that would cause a
mail to be sent to _all_ porter mailinglists.

-- 
Lo-lan-do Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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



Architecture usertags

2009-03-03 Thread Wouter Verhelst
Hi,

I've often thought that it would be useful to have tags in the BTS so
that users or maintainers could mark a bug as specific to a particular
architecture. This way, when I have some spare time, I could go to the
BTS, fetch a list of bugs that are specific to an architecture I care
about, and see what I can do about them, or give some feedback if that
would help.

Using a set of usertags under my own email address on the BTS wouldn't
really work for that, since it kindof defeats the whole purpose; I want
to use these tags to find bugs that I care about in the first place, but
in order for me to be able to add a usertag, I would have to know about
the bug before I could find it. Kind of a chicken-and-egg problem.

So I suggested to Don Armstrong that he add a set of
architecture-specific regular tags; but he seemed averse to this, as the
current informal policy of the debbugs maintainers is to require that a
usertag is used for a particular purpose before they add a new regular
tag; this is so that no tags get created which won't be used. I guess
this is a worty goal.

After a short discussion on IRC, we came up with another option: a set
of publically documented usertags, the definition of which would be
announced on debian-devel-announce and linked to from the BTS homepage,
so that maintainers could apply them to architecture-specific bugs when
necessary. The format, suggested by Steve Langasek, was to use the
porters mailinglist as the user, and the architecture name as the
usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as
tag).

Before I'll fire off an email to d-d-a announcing that, does anyone have
any comments, objections, or suggestions to improve this proposal?

Thanks,

-- 
Lo-lan-do Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


signature.asc
Description: Digital signature


Re: buildd depend on gcc-3.3

2004-01-22 Thread Wouter Verhelst
Op di 20-01-2004, om 23:46 schreef Geert Stappers:
 Hello mipsel people,
 
 From http://m68k.bluespice.org/buildd/mipsel_Dep-Wait.html
 I got this information:
 
 gcc-3.3 ( 1:3.3.3ds0-0pre0)  [gcc-3.3_1:3.3.3ds2-0pre2 [Installed 
 rmurray-repeat]]
   amule_1.2.4-1  [rmurray-repeat]
   conglomerate_0.7.8-1  [rmurray-repeat]
   devhelp_0.7-7  [rmurray-repeat]
   encompass_0.5.99.3-3  [rmurray-repeat]
   epiphany-browser_1.0.6-1  [rmurray-repeat]
 
 
 How should I read that information?

The five mentioned packages need gcc-3.3 ( 1:3.3.3ds0-0pre0) before
they can be compiled, which is provided by gcc-3.3_1:3.3.3ds2-0pre2
which has been installed (but only very recently, otherwise the five
other packages would've been set to needs-build already)

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
Most people have two reasons for doing anything -- a good reason, and
the real reason