Re: Bug#895193: transition: openmpi
Control: tags -1 confirmed On 11/04/18 11:12, Alastair McKinstry wrote: > > > On 11/04/2018 10:07, John Paul Adrian Glaubitz wrote: >> On 04/11/2018 10:53 AM, Alastair McKinstry wrote: >>> As of 3.0.1, openmpi now works on Big-Endian powerpc (which was to be a >>> problem; it had been dropped upstream because of an unknown bug, now >>> fixed). >> >> Oh, really, they fixed that? I already had given up hopes and >> therefore ignored >> the thread on github out of frustration. >> >>From the thread (and related PRs it references) its fixed and works as > long as -O3 is used. > I've implemented and tested this in ./rules. > >>> The other non-release archs were failing due to missing dependencies: in >>> particular java support (not used by any package in stable/testing) and >>> pmix (new; not used in testing/stable; pmix enables scaling to ~100,000+ >>> nodes, which is unlikely to be needed). >> >> I am working on fixing the remaining OpenJDK issues. I'm an upstream >> committer in the OpenJDK project, so I can commit all changes myself. >> > Ok. I've just disabled support as necessary for archs with openjdk issues. > While a riscv64 build has not yet occurred (awaiting in queue to see), > all issues on all other archs should now be resolved, > making the transition possible. Great. Please go ahead. Cheers, Emilio
Re: [Stretch] Status for architecture qualification
On 16/06/16 02:12, Hector Oron wrote: > I have put up the classical wiki page for Stretch at: > https://wiki.debian.org/ArchiveQualification/Stretch > > Please review and comment if required. That page is now outdated wrt mips concerns (see below). Do we need to duplicate the information that we already have on r.d.o/stretch/arch_qualify.html ? >>- s390, ppc64el and all arm ports have DSA concerns. > > I understand s390x and ppc64el DSA concerns have been clarified > in-list and those concerns are due to nature of the architecture. Sure, that's fine. > For the ARM ports, which have also been clarified, let me re-confirm: > * arm64 port has remote power and remote console available, plus > geo-redundancy, hardware is available and there is more hardware > coming in the pipeline. I am unsure why it is listed with multiple DSA > concerns, that surprises me (with DSA and ARM porter hats). The port > currently has 4 machines up, one down waiting to be replaced, in total > 5 and more coming. OK. I have removed the DSA concerns for arm64 from arch_qualify due to this. > * armhf/armel ports share hardware, we currently have 6 machines up > with remote power and remote console (of course that being development > boards is not so nice as server remote management goodies). Some > machines require a button press but local admins are great and always > happy to help. > > If none steps up explaining what are DSA concerns on the ARM > architectures, please update status requalification page dropping > those concerns. [DSA hat on] AIUI armhf/armel needing local admins should still be a concern, even if mild. Ideally that wouldn't be necessary. I have updated arch_qualify to reflect that. > I see armel has one porter listed, if more are needed, please add > myself and Riku Voipio (armel buildd maints). [ARM hat on] > I see arm64/armhf are covered porterwise however there should be more > porters available if needed. I have added you two as armel porters. >> * mips64el (NEW) >>- No DSA buildd (RT blocker) > > As far as I can see mips64el is using shared builds with mipsel port > hardware, those machines are DSA. We now got more hardware. This is no longer a concern. >>- Rebuild after import not complete (RT Blocker) > > Is there a list of packages that should be rebuilt? There's just one package missing, which is being worked on. See Aurelien's mail. >>- Not yet in testing (due to the above). > > Please let's work on getting it in testing ASAP I think the above > blockers can be worked out quite reasonably. Once db5.3 is rebuilt, we can enable mips64el in testing. > While working out ArchitectureQualification/Stretch wiki page I > believe everything is mostly fine for release, however I got a > personal concern on powerpc architecture. Is it well maintained? Does > it have porters? Does it have users? Does it still make sense to carry > along? Not sure about this one... I don't think anybody has stepped up as a porter. > Another concern (DSA) which I have added and explained in the wiki > page is the lack of georedundancy for the 'mips' port. Verbatim copy > from wiki follows: > "mips: It has 5 buildds in the same datacenter, current hardware are > routers or development boards which makes it very difficult to ship to > other places. The host providing redundancy (lucatelli) at UBC-ECE > must be decomissioned ASAP, leaving the port in a situation of not > geographic redundancy. However advanced plans exists to deploy mips > hardware in other data centers RSN." > > I'll keep you posted whenever there is progress on that area. I do not > believe it should be a blocker for release, but we must ensure geo > redundancy first. That's sorted out now. Cheers, Emilio
Re: [Stretch] Status for architecture qualification
On 14/06/16 09:06, Philipp Kern wrote: > On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: >> Philipp Kern: >>> On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. >>> What is the current DSA concern about s390x? >> The concern listed as: "rely on sponsors for hardware (mild concern)" >> >> As I recall the argument went something along the lines of: >> >> "Debian cannot replace the hardware; if any of the machines dies, we >> need a sponsor to replace it. If all of them dies and we cannot get >> sponsored replacements, we cannot support the architecture any longer" >> >> (My wording) > > Yeah, but that's unfortunately one of the universal truths of this port. > I mean in theory sometimes they turn up on eBay and people try to make > them work[1]. > > It also seems true for other ports where we commonly relied on sponsors > to hand us replacements. But maybe it's only ppc64el these days, maybe > there are useful builds available for the others (including arm64 and > mips) on the market now. AFAIK we rely on sponsors for all ports. The difference is that if we eventually have to buy things ourselves, we can get mips*, arm* or x86 buildds (for example), but we can't reasonably get a s390x one. But that's not something we can change, so as long as there no other concerns, this shouldn't be a blocker. Emilio
Re: binNMUs: please exercise some care
On 23/10/15 13:02, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > >> wanna-build does, yes, but at least the Release Team tend to use the "wb" >> wrapper tool which automatically works out the next free number on each >> architecture. > > Ah, cool – so we have only to patch this tool to automatically > use the highest number per batch on all affected architectures > (or even to use the highest number if all architectures would > be touched, but that’s probably an unreasonable amount of code > change). Sorry, aren't you saying the same thing in both cases? If not, can you rephrase or expand that? > Where’s the source code to that tool? https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb Please open a bug report against release.debian.org when submitting a patch. Cheers, Emilio
Re: binNMUs: please exercise some care
On 23/10/15 13:21, Emilio Pozuelo Monfort wrote: > On 23/10/15 13:02, Thorsten Glaser wrote: >> On Fri, 23 Oct 2015, Adam D. Barratt wrote: >> >>> wanna-build does, yes, but at least the Release Team tend to use the "wb" >>> wrapper tool which automatically works out the next free number on each >>> architecture. >> >> Ah, cool – so we have only to patch this tool to automatically >> use the highest number per batch on all affected architectures >> (or even to use the highest number if all architectures would >> be touched, but that’s probably an unreasonable amount of code >> change). > > Sorry, aren't you saying the same thing in both cases? If not, can you > rephrase > or expand that? > >> Where’s the source code to that tool? > > https://anonscm.debian.org/cgit/mirror/release-tools.git/tree/scripts/wb > > Please open a bug report against release.debian.org when submitting a patch. OTOH, I'm not sure this fix is appropriate. It just feels like a workaround for a dpkg bug, which would be better fixed in dpkg itself. This won't help when we have to schedule a binNMU on one or two architectures and not all of them. Emilio
Re: binNMUs: please exercise some care
On 23/10/15 11:20, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Emilio Pozuelo Monfort wrote: > >> I can go back to scheduling binNMUs for release architectures only, or for >> ANY >> -x32. But I don't have the time to look at every architecture and determine >> which one needs a binNMU and which one has already done it. Anyway if your > > OK. In this case, scheduling them is probably better. OK good to know. >> buildds are fast enough that they already rebuilt things, then maybe >> rebuilding >> them again is not such a big deal... > > This is probably true for x32, yes, but I was concerned about > M-A libraries not being coinstallable. For example, the harfbuzz > library currently has one +b more than all others, making trouble > for my desktop system (x32+i386 M-A). In that case, it wasn’t even > because the rebuild was done twice, but, because another rebuild > before the current (shared) one was necessary. > > How about, scheduling them all at once, but using the same version > number across arches when doing it (i.e. the largest)? Again, that involves determining what that number is for each package... Instead of all that manual work for every transition, you could ping #758616 and try to get this solved at its root. >> That wasn't me. But I'll try to spread the word about --extra-depends, as I >> agree it's useful to avoid this. I didn't use it much in the past when I just > > Okay, thanks a lot! Also, thanks for the response. Cheers, Emilio
Re: binNMUs: please exercise some care
On 23/10/15 12:23, Wookey wrote: > +++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]: >> On 23/10/15 11:20, Thorsten Glaser wrote: > >>> How about, scheduling them all at once, but using the same version >>> number across arches when doing it (i.e. the largest)? >> >> Again, that involves determining what that number is for each package... > > That is a single-page lookup, though, so only one lookup, not one for > each arch e.g: https://buildd.debian.org/status/package.php?p=harfbuzz I didn't say once per arch. I said once per package, which is worse. I normally schedule binNMUs for several dozens packages. Multiply that by several transitions... Sorry but I'm not going to do that. >> Instead of all that manual work for every transition, you could ping >> #758616 and try to get this solved at its root. > > It would clearly be better if we either did sourceful rebuilds or > fixed the 'binNMU skew' problem. But we do need to do something > reasonably soon otherwise it's not going to be ready for Stretch > either. Ping the dpkg bug? :) Emilio
Re: binNMUs: please exercise some care
[ Sorry for the cross-post, but I believe the people in -release and -wb-team should see this ] On 23/10/15 09:05, Thorsten Glaser wrote: > Hi, > > whoever is scheduling binNMUs now should do so with a little > bit more care, please. > > Case in point, frameworkintegration – x32 already was rebuilt > against the new Qt API and did not need the additional binNMU. That one was me. This is what I did: wb nmu fcitx-qt5 frameworkintegration gcin hime kwin libqtxdg lxqt-qtplugin qtcurve calibre . ANY . -m "Rebuild against qtbase-abi-5-5-1." --extra-depends "libqt5core5a (>= 5.5.1)" I can go back to scheduling binNMUs for release architectures only, or for ANY -x32. But I don't have the time to look at every architecture and determine which one needs a binNMU and which one has already done it. Anyway if your buildds are fast enough that they already rebuilt things, then maybe rebuilding them again is not such a big deal... Maybe when the transition tracker suggests commands to schedule binNMUs (something I want to implement) it can do so for affected architectures only. > Case in point, some OCaml binNMUs were done recently (within > the last month), to rebuild against the new compiler version, > but that version was not yet built on m68k. (You can set > extra Build-Depends and use that to version them, to make > sure that, while you have the comfort of scheduling them > all at once instead of in several batches, they only happen > after their prerequisite has been done.) That wasn't me. But I'll try to spread the word about --extra-depends, as I agree it's useful to avoid this. I didn't use it much in the past when I just used to wait for all architectures in wanna-build to build. But now that we got all the ports, it's a good way to schedule things just once without having to wait for every port. Cheers, Emilio
