Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, Nov 05, 2013 at 08:53:05AM +0100, Niels Thykier wrote: [1] I certainly wouldn't have space for something like this: http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg (and much less the money. Yeah I know that is technically not an s390, but as I understand it, an s390 should be around that size) That is in fact a s390, and pretty much the smallest of the zSeries you can find. You wouldn't be able to do anything with it even if you got it, though - it doesn't have internal storage at all (no Mainframe has, except the previous-generation Multiprise 3000 series), and requires external FICON/ESCON SAN storage to boot/operate. So you'd have to take a big clunky enterprise array of disks as well - just another full rack, if you're lucky. I was offered one of these z800 at some point, and had to pass on it too. Oh, and then there's the licensing stuff... chances of getting the required IBM assistance to get it (re)installed are about on par with Justin Bieber's chances of getting elected as President. There's an emulator (hercules) which can run zSeries operating systems on top of Linux, if you can get your hands on those. Anyway, sorry for going offtopic. :-) Lennert signature.asc Description: Digital signature
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier writes (Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))): On 2013-11-03 16:03, Steven Chamberlain wrote: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 Actually, I meant a real BTS page (e.g. like [1]) rather than just a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. I think this would be a good idea. If the psuedo-package had a predictable name which depended only on the architecture, even better. Ian. -- 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/21113.13532.963985.569...@chiark.greenend.org.uk
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I'm OK with assisting with either, but I need to know which solution porters would prefer. -- Don Armstrong http://www.donarmstrong.com For those who understand, no explanation is necessary. For those who do not, none is possible. -- 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/20131105183439.gy9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Don Armstrong wrote: On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I would also be OK with creating a pseudopackage as well as Ian suggested. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. -- Don Armstrong http://www.donarmstrong.com America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 -- 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/20131105185031.gz9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Hi, On 05/11/13 18:50, Don Armstrong wrote: On Tue, 05 Nov 2013, Don Armstrong wrote: This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] Either of those sounds good. Fully-fledged tags would be the easiest for most reporters to remember to use, but I wonder if this pollutes the tag namespace. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. Would that be only for generic issues with a port, not specific to a package? I doubt this would be used much. These bugs might typically be reassigned to kernel packages or eglibc anyway. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527949c5.8040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Wouter Verhelst wrote: Well, I did ask for the creation of port-specific tags back at debconf8 (if I'm not mistaken), but you told me to go for usertags instead ;-) Sounds familiar. Usertags have the advantage of not requiring me to do any work. But presumably at the time I hadn't thought of the difficulties of coordinating all of the different usertags between porters. Yes, I think that's a good idea; it would avoid issues where maintainers are waiting on porters and vice versa, since the reassigning of a bug to a port pseudopackage would make it clear who's waiting for whom. Additionally, it would allow porters to have a todo list of things that need to be done for their port but aren't specific to any one package (or of which the root cause hasn't been found yet, e.g., recently compiled binaries segfault, but we don't know why yet) If you're going down this road, I would appreciate it if ports listed on debian-ports.org would also be getting pseudopackages. Since they would all be under the same ports.debian.org (or similar) namespace, I wouldn't have a problem with it. [My main concern about pseudopackages is polluting the package namespace; since I can't imagine anyone ever wanting to create a package called someport.ports.debian.org for a sane reason, that shouldn't be a big deal.] It would also be possible (in the meantime) for bugs to be assigned to both the port-specific pseudopackage, and the original package which spawned the bug. In any event, if a few active porters wouldn't mind creating a wishlist bug against bugs.debian.org for this with a suggested course of action, I'd appreciate it. Assuming there is no significant disagreement about that course of action, I'd like to implement it within a week or so. -- Don Armstrong http://www.donarmstrong.com PowerPoint is symptomatic of a certain type of bureaucratic environment: one typified by interminable presentations with lots of fussy little bullet-points and flashy dissolves and soundtracks masked into the background, to try to convince the audience that the goon behind the computer has something significant to say. -- Charles Stross _The Jennifer Morgue_ p33 -- 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/20131105201345.ga9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 03/11/13 10:54, Niels Thykier wrote: Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often FTBFS on kfreebsd bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, -- Steven Chamberlain ste...@pyro.eu.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/527665af.2040...@pyro.eu.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 16:03, Steven Chamberlain wrote: On 03/11/13 10:54, Niels Thykier wrote: Come to think of it; maybe we should have a BTS page for each of the ports (e.g. a pseudo package in the BTS). We've had this on kfreebsd, due it to having been a release goal: http://udd.debian.org/bugs.cgi?release=jessie_or_sidmerged=ignfnewerval=7kfreebsd=1sortby=severitysorto=desccseverity=1ctags=1 Actually, I meant a real BTS page (e.g. like [1]) rather than just a list of tagged bugs. The list of tagged bugs definitely have it uses, but it does not give me an overview of which bugs should be fixed by the maintainer of the given package and which the porters should fix. It uses usertags, but someone has to set those. Porters usually set them on bugs they file; but quite often FTBFS on kfreebsd bugs are filed without being tagged or Cc'd to our list, so someone has to periodically look for and tag things. Regards, In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. Do we have a tool you can give a source package, a version plus a list of architectures and it will generate a bug with the right tags? I think that would help a lot for me. ~Niels [1] http://bugs.debian.org/release.debian.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/52789fdb.2000...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On 2013-11-03 23:04, Steve Langasek wrote: On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: [...] I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. I will not rule out that it was a poor choice of example on my part for ia64 (and maybe powerpc), which is(/are) the concrete port(s) we would be talking in this case. That said, it is my understanding that one does not simply own an s390(x)[1]. Nor would I be concerned to have arm porters that worked on all 3 arm ports while possessing hardware only for a (non-empty) subset of those architectures. ~Niels [1] I certainly wouldn't have space for something like this: http://en.wikipedia.org/wiki/File:Z800_2066_JKU.jpeg (and much less the money. Yeah I know that is technically not an s390, but as I understand it, an s390 should be around that size) -- 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/5278a3e1.30...@thykier.net
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
Niels Thykier dixit: Then there are more concrete things like ruby's test suite seg. faulting on ia64 (#593141), ld seg. faulting with --as-needed on ia64 And only statically linked klibc-compiled executables work on IA64, not dynamically linked ones. I’ve looked into it, but Itanic is so massively foreign I didn’t manage to find out anything except that the problem appears to happen before main. Until we have a clear definition of actively maintained ports, I would recommend porters to err on the side of being verbose over being silent. I’ve held off on the m68k side because I think the role call was only for architectures in the main archive, right? [1] Nothing official yet, but gcc-4.6 (and earlier) /might/ not be acceptable as a default for Jessie. Didn't Doko say he’d want 4.8? We (on the m68k side) are putting effort into that one, since 4.7 appears to only be used by eglibc right now. And 4.6 for GNAT, but gnat-4.8 is new, and the ICE may be fixed as there’s active upstream on the GCC/m68k side. bye, //mirabilos -- diogenese Beware of ritual lest you forget the meaning behind it. igli yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place. -- 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/pine.bsm.4.64l.1311031444380.31...@herc.mirbsd.org
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Sun, Nov 03, 2013 at 11:54:34AM +0100, Niels Thykier wrote: On 2013-10-29 17:48, Ian Jackson wrote: Niels Thykier writes (Re: Bits from the Release Team (Jessie freeze info)): [...] As mentioned we are debating whether the 5 DDs requirement still makes sense. Would you say that we should abolish the requirement for DD porters completely? I.e. Even if there are no (soon to be) DDs, we should consider the porter requirements fulfilled as long as they are enough active porters behind the port[0]? I don't have a good feel for the answer to that question. It's just that if it is the case that a problem with ports is the lack of specifically DDs, rather than porter effort in general, then sponsorship is an obvious way to solve that problem. If you feel that that's not really the main problem then a criterion which counts porters of any status would be better. I suppose a sponsor-only DD could be sufficient, provided that the sponsor knows the porters well enough to be willing to sign off on e.g. access to porter boxes. I guess the sponsor would also need to dedicate time to mentor (new?) porters on workflows and on quicks like when is a FTBFS RC and when it isn't etc. Why would the sponsor need to be involved in getting the porters access to porter boxes? Porter boxes exist so that DDs *not* involved in a port have access to a machine of the architecture and can keep their packages working. I've never heard of a porter who didn't have access to their own box for porting work. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
