Re: [Stretch] Status for architecture qualification
(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?
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
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
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
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
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