Bug#905889: transition: gdbm
[2018-10-02 09:38] Emilio Pozuelo Monfort
> part text/plain 567
> On 11/08/2018 09:40, Dmitry Bogatov wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Hello. According to [1] I request approval of upload gdbm-1.17 into
> > unstable. It will affect 28 packages, 26 of which build cleanly
> > (no-changes source upload will be required) and I am ready to NMU
> > patches for two others (perl and qsf).
> Is perl still unfixed? With the upcoming perl transition, that's
> something th at I wouldn't like to see fixed through an NMU at this
> point.
No, according to #904005, Perl maintainer fixed this issue himself.
Only qsf left {no response from maintainer, will NMU}.
Bug#909288: transition: kdepim 18.08
Hello, On Wed, Oct 03, 2018 at 10:01:23PM +0200, Sandro Knauß wrote: > Hey, > > after the first archs have compiled complete kde pim 18.08. Now several > packages needs to get recompiled against > the new kdepim, they needs to get rebuilt on any architecture: [...] > > nmu kio-gdrive . ANY . -m 'Rebuild against kdepim 18.08.1' > dw kio-gdrive . ANY . -m 'libkpimgapi-dev (>= 18.08.0~)' > I've added some nice-to-have appstream updates to kio-gdrive to add some additional value to the upload, and I've contacted Maximilian, who usually sponsors uploads for this package. If it comes down to it, would you please sponsor the -2 revision from one of the follow rather than uploading a binnmu?: git clone g...@salsa.debian.org:qt-kde-team/extras/kio-gdrive.git # use uscan to get the orig tarball, or download the one already in # the archive # or dget https://mentors.debian.net/debian/pool/main/k/kio-gdrive/kio-gdrive_1.2.4-2.dsc Thanks! Nicholas signature.asc Description: PGP signature
Re: MPICH as default MPI; WAS: MPI debugging workflows
On 2018-10-03 21:02, Alastair McKinstry wrote: Hi, See thread below. I've just uploaded 3.1.2-5 which I believe fixes the hangs due to OpenMPI ( non-atomic handling of sending a 64-bit tag, occuring mostly on archs with 32-bit atomics). Awkward observation: openmpi 3.1.2-5 now causes dolfin tests to timeout (on amd64) https://ci.debian.net/packages/d/dolfin/unstable/amd64/ Tracker page pings lammps and liggghts as well. Drew
Bug#884635: transition: libupnp
Hi, Niels Thykier wrote: > Before this transition can start, we will need a solution for amule, > djmount, gmrender-resurrect and linphone (which is either RM or upload > with a fix). > > Removing all of them leads to the following collateral damage[1]: > > """ > Checking reverse dependencies... > # Broken Depends: > kopete: kopete > libosmo-abis: libosmotrau2 > > # Broken Build-Depends: > kopete: libmediastreamer-dev (>= 3.6) > libortp-dev (>= 0.13) > libosmo-abis: libortp-dev > libosmo-netif: libortp-dev > osmo-bts: libortp-dev > > Dependency problem found. > """ > (I have not researched exactly which package causes what to break; that > is an exercise left for the reader) All of these are caused by linphone. We have a really really old linphone in testing/unstable that has been out-of-date since several Debian releases. The current version is staged in experimental, the transition (Bug#891620) is blocked by Kopete which does not build against a current libmediastreamer (Bug#890606). There is an upstream bug with patches attached. The first one was just NULLing additional arguments. Felix Lechner recently created a better one that still fails compilation. The upstream bug has been open for two years now, without any significant progress. We've suggested to the kopete maintainers to drop Jingle support and allow us to proceed, but no response. The linphone stack in experimental does not use libupnp anymore as far as I can see. If it helps please RM src:linphone from testing, we will rather have Buster without linphone than with this version. Bernhard
Bug#884635: transition: libupnp
Hi Uwe, I have make a pull request for your gmrender-resurrect github repo with my changes. I also have the aMule port ready. Does anyone knows if they accept patches in github? In the case of djmount has an internal frozen libupnp that is compiled static by default, at least in the repo I cloned in Github, so it should not be a problem. Finally, linphone, I did not understand how it uses libupnp since it does not seem to call libupnp functions. Or I cloned the wrong repo :) Regards, Marcelo. On Tue, Oct 2, 2018 at 9:29 AM Uwe Kleine-König wrote: > Hello Marcelo, > > On 10/01/2018 11:33 PM, Marcelo Roberto Jimenez wrote: > > If I can help further, please do contact me. > > I started to port gmrender-resurrect to 1.8, but I think there are a few > code parts that won't work with 1.8, but that might also be me not > understanding the data model completely. > > If you'd take a look at > > https://github.com/ukleinek/gmrender-resurrect/commit/ad3c91b9a63e8bf443e56747fc43ff29e92c5414 > that would be great. > > Thanks > Uwe > >
Bug#909412: transition: libpodofo
Ah and please remember to also binNMU scribus-ng in experimental :) On Tue, 2 Oct 2018, 5:00 p.m. Mattia Rizzolo, wrote: > On Tue, Oct 02, 2018 at 04:46:11PM +0200, Emilio Pozuelo Monfort wrote: > > Yes. That (openssl) is going to block other larger transitions from > starting as > > well, so I'd rather have this one, which is small and doesn't conflict > with > > anything, ready to go in while openssl gets fixed. Thanks for checking > in any case. > > Alright, uploaded! > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- >
Processed: kmymoney: KMyMoney needs to be recompiled against KDE PIM 18.08.
Processing control commands: > block 909288 by -1 Bug #909288 [release.debian.org] transition: kdepim 18.08 909288 was blocked by: 908869 909288 was not blocking any bugs. Added blocking bug(s) of 909288: 910248 -- 909288: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909288 910248: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910248 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#909288: transition: kdepim 18.08
Hey, after the first archs have compiled complete kde pim 18.08. Now several packages needs to get recompiled against the new kdepim, they needs to get rebuilt on any architecture: nmu ktorrent . ANY . -m 'Rebuild against kdepim 18.08.1' dw ktorrent . ANY . -m 'libkf5syndication-dev (>= 18.08.0~)' nmu kio-gdrive . ANY . -m 'Rebuild against kdepim 18.08.1' dw kio-gdrive . ANY . -m 'libkpimgapi-dev (>= 18.08.0~)' nmu kjots . ANY . -m 'Rebuild against kdepim 18.08.1' dw kjots . ANY . -m 'libkf5akonadi-dev (>= 4:18.08.0~), libkf5akonadinotes-dev (>= 18.08.0~), libkf5pimtextedit-dev (>= 18.08.0~)' nmu zanshin . ANY . -m 'Rebuild against kdepim 18.08.1' dw zanshin . ANY . -m 'libkf5akonadicalendar-dev (>= 4:18.08.0~), libkf5akonadicontact-dev (>= 4:18.08.0~), libkf5akonadinotes-dev (>= 4:18.08.0~), libkf5akonadisearch-dev (>= 4:18.08.0~), libkf5identitymanagement-dev (>= 18.08.0~), libkf5kontactinterface-dev (>= 18.08.0~), libkf5ldap-dev (>= 18.08.0~)' nmu digikam . ANY . -m 'Rebuild against kdepim 18.08.1' dw digikam . ANY . -m 'libkf5calendarcore-dev (>= 4:18.08.0~)' nmu kraft . ANY . -m 'Rebuild against kdepim 18.08.1' dw kraft . ANY . -m 'libkf5akonadi-dev (>= 4:18.08.0~), libkf5akonadicontact-dev (>= 4:18.08.0~)' hefee signature.asc Description: This is a digitally signed message part.
Re: MPICH as default MPI; WAS: MPI debugging workflows
Hi,
Em qua, 3 de out de 2018 às 16:24, Mattia Rizzolo escreveu:
>
> On Wed, Oct 03, 2018 at 02:02:25PM +0100, Alastair McKinstry wrote:
> > Any ideas on how to write the ben tracker script? I think it would work by
> > looking for packages with binaries linked to openmpi rather than mpich, but
> > there are a number of packages that would be false positives (HDF5,
> > open-coarrays, etc. ) that build against both.
>
> The bug report I linked in mpi-defaults' README.source contains an
> example.
>
> the false positives could be just handled manually (i.e. listed in the
> transition bug), I don't think there are many that links to both.
>
> Also, please note that mpich never built on riscv64, and is not up2date
> on hppa and ppc64. I think at least the riscv64 should be handlded
> first, so to avoid being in the same situation again when a single weird
> architecture uses a different MPI implementation.
> I'm CCing debian-ri...@lists.debian.org for this, in case you need help.
>From the riscv64 camp, I built the current version in hardware and
uploaded to "unreleased" in debian-ports:
mpich_3.3~b3-2_riscv64.changes
I suspect that the reason why it doesn't build is timeout in the
tests, due to the buildds being qemu-system. The timeout can be
increased with environment variables:
test/mpi/runtests.in:if (defined($ENV{"MPITEST_TIMEOUT"})) {
test/mpi/runtests.in:$defaultTimeLimit = $ENV{"MPITEST_TIMEOUT"};
test/mpi/runtests.in:if (defined($ENV{"MPITEST_TIMEOUT_MULTIPLIER"})) {
test/mpi/runtests.in:$defaultTimeLimitMultiplier =
$ENV{"MPITEST_TIMEOUT_MULTIPLIER"};
We can try to send a patch if it helps.
Cheers.
--
Manuel A. Fernandez Montecelo
Bug#910232: transition: postgresql-11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition PostgreSQL 11 RC1 will be released next week, and 11.0 will follow one week later if everything goes well. I plan to target unstable with RC1. PG 11 is the version that will be released with buster; PG 10 will be removed once all packages have been migrated. As usual, there should be little release team coordination needed, the PostgreSQL team will be doing the necessary sourceful uploads for the PostgreSQL module packages. Ben file attached. Thanks, Christoph >From db8cff538aed040c2da313b208ba343ddf1a1541 Mon Sep 17 00:00:00 2001 From: Christoph Berg Date: Wed, 3 Oct 2018 19:19:02 +0200 Subject: [PATCH] Add postgresql-11 tracker --- config/ongoing/postgresql-11.ben | 5 + 1 file changed, 5 insertions(+) create mode 100644 config/ongoing/postgresql-11.ben diff --git a/config/ongoing/postgresql-11.ben b/config/ongoing/postgresql-11.ben new file mode 100644 index 000..aabd6d5 --- /dev/null +++ b/config/ongoing/postgresql-11.ben @@ -0,0 +1,5 @@ +title = "postgresql-11"; +is_affected = .depends ~ /postgresql.*-[19].*/ | .build-depends ~ /postgresql.*-[19].*/ | .recommends ~ /postgresql.*-[19].*/ | .suggests ~ /postgresql.*-[19].*/; +is_good = .depends ~ /postgresql.*-11.*/ | .build-depends ~ /postgresql.*-11.*/ | .recommends ~ /postgresql.*-11.*/ | .suggests ~ /postgresql.*-11.*/; +is_bad = .depends ~ /postgresql.*-(9|10).*/ | .build-depends ~ /postgresql.*-(9|10).*/ | .recommends ~ /postgresql.*-(9|10).*/ | .suggests ~ /postgresql.*-(9|10).*/; +export = false; -- 2.19.0.329.g76f2f5c1e3
Re: How does the transition tracker for python3.7 progress?
Hi! On Wed, Oct 03, 2018 at 05:20:59PM +0100, Neil Williams wrote: > https://release.debian.org/transitions/html/python3.7.html > > At what point does a package listed as unknown get processed to > determine if it is good or bad? python3 transitions are annoyingly hard to track due to many case corners. Yesterday I failed at least 6 bugs against packages that were marked as unknown due to the wrong build-depends line (IIRC you were amongst the maintainers of those packages). > What is the trigger for that process? that's enterely manual, and the sad bit is that there aren't "notes" nor anybody is going to manually exclude packages from the tracker. Except people fixing their wrong build-depends (but that still leaves cases of packages correctly build-depending on e.g. python3-all-)bg for tests but still being arch:all and so creating a package with a depends on only a possibly unversioned python3). > How do arch:all packages affect the tracker? like all other packages... I don't understand your question. > https://tracker.debian.org/pkg/nuitka is marked as good but all of > the other arch:all packages are unknown. most of arch:all packages shouldn't appear in the tracker at all (and indeed they don't). > Equally, packages are listed as unknown with a highlight denoting > "Dependencies" on another package. If that package is marked as good, > why is the unknown package not checked? What highlighting are you talking about? > The package I care about most is at Dependency level 7 and has a > highlight Dependencies: pyyaml which is in the good list. How do I > identify what (if anything) I can do about this being listed as > unknown? As far as I can tell, the package doesn't depend on any of the > packages currently listed as bad (most of which are sid-only). I assume you are talking about src:lava. It's weird, I thought I had sent a bug to that, I wonder why I didn't... At any rate, the issue is like this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910094 I must have messed up my list while running mass-bug > One of my packages is at Dependency level 1 and unknown but I can't > tell if I have done anything wrong or how the package affects the > transition. I assume you are talking about src:black. And indeed I did open a bug for that one yesterday: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910094 (incidentally, the same bug I reported a few lines above :P) At any rate, those false positives only cause noise in the tracker, they aren't actually hindering the transition if not for people like you now and me yesterday that wested their time looking at them. Currently proper overview of the transition is blocked by src:python3.7 not migrating due to src:openssl blocking the world. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
How does the transition tracker for python3.7 progress?
https://release.debian.org/transitions/html/python3.7.html At what point does a package listed as unknown get processed to determine if it is good or bad? What is the trigger for that process? How do arch:all packages affect the tracker? https://tracker.debian.org/pkg/nuitka is marked as good but all of the other arch:all packages are unknown. Equally, packages are listed as unknown with a highlight denoting "Dependencies" on another package. If that package is marked as good, why is the unknown package not checked? There are links to RC bugs but not all of those RC bugs relate to the transition (e.g. boost and a few others are RC due to an invalid maintainer address). The package I care about most is at Dependency level 7 and has a highlight Dependencies: pyyaml which is in the good list. How do I identify what (if anything) I can do about this being listed as unknown? As far as I can tell, the package doesn't depend on any of the packages currently listed as bad (most of which are sid-only). One of my packages is at Dependency level 1 and unknown but I can't tell if I have done anything wrong or how the package affects the transition. Help? -- Neil Williams h...@codehelp.co.uk pgp8G21EaDHxE.pgp Description: OpenPGP digital signature
Re: Re-evaluating architecture inclusion in unstable/experimental
Hi Philipp! On 10/3/18 4:29 PM, Philipp Kern wrote: > Please excuse my ignorance, but which architecture do we still have with > 2 GiB address space? The main point of removing s390 was that this was > unsustainable. The 32-bit MIPS architectures have this limitation which causes various build issues up to the point that maintainers have to reduce optimization levels for the C/C++ compiler to be able to build a package. Another issue is that the Rust compiler, despite being fully supported on 32-bit MIPS, cannot be built natively there because the build process runs out of memory at some point. >> I have seen IBM people on multiple occasions in various upstream >> projects trying to remove code for older POWER targets because >> they insisted anything below POWER8 is not supported anymore. In >> some cases like Golang with success [1]. > > Yeah, IBM behavior has been incredibly frustrating here on the System z > side, too. Essentially they end up actively removing support for > anything they don't support anymore. Somewhat relieves me to hear that I'm not the only one running into this problem. I find it frustrating though since it leaves a bad impression on what attitude IBM has towards open source and the community. > To some degree I understand this behavior: It's a real relieve to not > need to support something old and crufty when you're the engineer on the > other side having to do that. Even when such support is contributed, > someone needs to keep it working and they won't keep old hardware around > for that. Sure, I understand that. But in the case of Golang, the necessary extra code paths are really manageable. In fact, have my own tree of Golang where I reverted the changes which dropped POWER5 support and I keep rebasing this tree from time to time and it still works fine. It does work without problems on the x86 side with the kernel and the toolchain still supporting rather old hardware. POWER5 isn't that old. > But it has very awkward implications on the people that still have that > hardware for one reason or another and don't actually rely on a support > contract. My main argument is that if there are still a reasonable amount of users and there are still enough people to help maintain a port, it should not removed just because it's old. In the end, software is written to be useful to users and not for the sake of the people writing it. > For s390x I can say that the port was driven without any commercial > interest on both Aurelien's and my side The question is though: Is there quantifiable amount of users that is running Debian on such big iron instead of one of the Linux enterprise distributions on the market? If the argument is about maintenance burden, then does it justify to support Debian on s390x when the number of users is small? And, if yes, why does that not apply to ppc64, for example? (I would mention sparc64 here as well, but there is actually a valid blocker which is the lack of supply of new hardware for DSA). Thanks for the insight! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: MPICH as default MPI; WAS: MPI debugging workflows
On 2018-10-03 22:12, Mattia Rizzolo wrote: the false positives could be just handled manually (i.e. listed in the transition bug), I don't think there are many that links to both. Also, please note that mpich never built on riscv64, and is not up2date on hppa and ppc64. I think at least the riscv64 should be handlded first, so to avoid being in the same situation again when a single weird architecture uses a different MPI implementation. I'm CCing debian-ri...@lists.debian.org for this, in case you need help. Another thing to be mindful of are the debci tests, which are growing in number. Tests that pass with openmpi won't necessarily pass mpich, notwithstanding the assertion we're working with that mpich is more stable. An example is the build-time tests for scalapack (which builds both openmpi and mpich versions). Build logs at https://buildd.debian.org/status/package.php?p=scalapack . Tests are set to run against both openmpi and mpich. On amd64 the openmpi tests pass (apart from a couple of timeouts), while against mpich 16 tests failed out of 96 (so currently mpich test failures are being ignored). I don't know if that means the scalapack tests are making assumptions that aren't valid under the general MPI specification, but I can guess it won't be the only package with this challenge. As far as the ben script goes, it could look at dependencies on mpi-default-dev as well as libopenmpi3. Drew
Re: Re-evaluating architecture inclusion in unstable/experimental
On Sat, Sep 29, 2018 at 05:05:17PM +0200, John Paul Adrian Glaubitz wrote: Well, I have had people from IBM fix 32-bit PowerPC code. There is naturally more involvement behind the 64-bit stuff because that's where the commercial interests are. The kernel itself dropped 32bit powerpc support years ago, IIRC. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Re-evaluating architecture inclusion in unstable/experimental
ср, 3 окт. 2018 г. в 17:48, Jonathan Dowland : > > On Sat, Sep 29, 2018 at 05:05:17PM +0200, John Paul Adrian Glaubitz > wrote: > >Well, I have had people from IBM fix 32-bit PowerPC code. There is > >naturally more involvement behind the 64-bit stuff because that's where > >the commercial interests are. > > The kernel itself dropped 32bit powerpc support years ago, IIRC. Hmm, no. ls -l /arch/powerpc/platforms/ shows all of them. -- With best wishes Dmitry
Re: Re-evaluating architecture inclusion in unstable/experimental
On 29.09.2018 00:30, John Paul Adrian Glaubitz wrote: > On 9/28/18 11:26 PM, Adam D. Barratt wrote: >> On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: >>> So, it's not always a purely technical decision whether a port >>> remains a release architecture. It's also often highly political and >>> somehow also influenced by commercial entities. >> Please don't make implications like that unless you can back them up. > Well, I cannot prove it. But when I see that we have ports as release > architectures with hardware where atomics in hardware don't even work > correctly and the virtual address space is limited to 2 GiB per process > while on the other hand perfectly healthy and maintained ports like > powerpc and ppc64 which have actually a measurable userbase and interest > in the community are axed or barred from being a release architecture, > then I have my doubts that those decisions aren't also driven by > commercial interests or politics. Please excuse my ignorance, but which architecture do we still have with 2 GiB address space? The main point of removing s390 was that this was unsustainable. > I have seen IBM people on multiple occasions in various upstream > projects trying to remove code for older POWER targets because > they insisted anything below POWER8 is not supported anymore. In > some cases like Golang with success [1]. Yeah, IBM behavior has been incredibly frustrating here on the System z side, too. Essentially they end up actively removing support for anything they don't support anymore. To some degree I understand this behavior: It's a real relieve to not need to support something old and crufty when you're the engineer on the other side having to do that. Even when such support is contributed, someone needs to keep it working and they won't keep old hardware around for that. But it has very awkward implications on the people that still have that hardware for one reason or another and don't actually rely on a support contract. For s390x I can say that the port was driven without any commercial interest on both Aurelien's and my side. Kind regards Philipp Kern
Re: MPICH as default MPI; WAS: MPI debugging workflows
On Wed, Oct 03, 2018 at 02:02:25PM +0100, Alastair McKinstry wrote: > Any ideas on how to write the ben tracker script? I think it would work by > looking for packages with binaries linked to openmpi rather than mpich, but > there are a number of packages that would be false positives (HDF5, > open-coarrays, etc. ) that build against both. The bug report I linked in mpi-defaults' README.source contains an example. the false positives could be just handled manually (i.e. listed in the transition bug), I don't think there are many that links to both. Also, please note that mpich never built on riscv64, and is not up2date on hppa and ppc64. I think at least the riscv64 should be handlded first, so to avoid being in the same situation again when a single weird architecture uses a different MPI implementation. I'm CCing debian-ri...@lists.debian.org for this, in case you need help. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: MPICH as default MPI; WAS: MPI debugging workflows
Hi, See thread below. I've just uploaded 3.1.2-5 which I believe fixes the hangs due to OpenMPI ( non-atomic handling of sending a 64-bit tag, occuring mostly on archs with 32-bit atomics). With this, I think it is appropriate to start the ball rolling on making mpich the default MPI for buster. Any objections? Any ideas on how to write the ben tracker script? I think it would work by looking for packages with binaries linked to openmpi rather than mpich, but there are a number of packages that would be false positives (HDF5, open-coarrays, etc. ) that build against both. regards Alastair On 31/08/2018 11:17, Alastair McKinstry wrote: On 31/08/2018 11:04, Drew Parsons wrote: On 2018-08-30 14:18, Alastair McKinstry wrote: On 30/08/2018 09:39, Drew Parsons wrote: If you want a break from the openmpi angst then go ahead and drop mpich 3.3b3 into unstable. It won't make the overall MPI situation any worse... :) Drew Ok, I've pushed 3.3b3 to unstable. Great! For me there are two concerns: (1) The current setup (openmpi default) shakes out issues in openmpi3 that should be fixed. It would be good to get that done. That's fair. If we're going to "drop" openmpi, it's a good policy to leave it in as stable a state as possible. At this stage it appears there is a remaining "hang" / threading issue thats affecting 32-bit platforms (See #907267). Once thats fixed, I'm favouring no further updates before Buster - ie ship openmpi 3.1.2 with pmix 3.0.1 (openmpi now has a dependency on libpmix, the Process Management Interface for exascale, that handles the launching of processes (up to millions, hierarchically). the openmpi /pmix interface has been flaky, I suspect, and not well tested on non-traditional HPC architectures (eg. I suspect its the source of the 32-bit issue). mpich _can_ be built with pmix but I'm recommending not doing so for Buster. (2) moving to mpich as default is a transition and should be pushed before the deadline - say setting 30 Sept? This is probably a good point to confer with the Release Team, so I'm cc:ing them. Release Team: we have nearly completed the openmpi3 transition. But there is a broader question of switching mpi-defaults to mpich instead of openmpi. mpich is reported to be more stable than openmpi and is recommended by several upstream authors of the HPC software libraries. We have some consensus that switching to mpich is probably a good idea, it's just a question of timing at this point. Does an MPI / mpich transition overlap with other transitions planned for Buster - say hwloc, hdf5 ? hdf5 already builds against both openmpi and mpich, so it should not be a particular problem. It has had more build failures on the minor arches (with the new hdf5 version in experimental), but there's no reason to blame mpich for that. I don't know about hwloc, but the builds in experimental look clean. Drew -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Processed: Re: Bug#908869: blogilo: FTBFS with pimtextedit 18.08.1
Processing control commands: > block 909288 by -1 Bug #909288 [release.debian.org] transition: kdepim 18.08 909288 was not blocked by any bugs. 909288 was not blocking any bugs. Added blocking bug(s) of 909288: 908869 > severity -1 serious Bug #908869 [blogilo] blogilo: FTBFS with pimtextedit 18.08.1 Severity set to 'serious' from 'important' -- 908869: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908869 909288: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909288 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#910136: marked as done (nmu: php-ast_0.1.6-2)
Your message dated Wed, 3 Oct 2018 09:23:06 +0200 with message-id <464f1a10-86bb-3b2c-03f2-ef0f5f8eb...@debian.org> and subject line Re: Bug#910136: nmu: php-ast_0.1.6-2 has caused the Debian Bug report #910136, regarding nmu: php-ast_0.1.6-2 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 910136: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910136 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 nmu php-ast_0.1.6-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-geoip_1.1.1-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-gmagick_2.0.5~rc1+1.1.7~rc3-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-gnupg_1.4.0-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-msgpack_2.0.2+0.5.7-5 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-propro_2.1.0+1.0.2-1 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-radius_1.4.0~b1-8 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-raphf_2.0.0+1.1.2-3 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-rrd_2.0.1+1.1.3-5 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-uuid_1.0.4-6 . ANY . unstable . -m "Rebuild for PHP 7.3" Hi, this is a first round of PHP 7.3 related binNMUs for PHP extensions that I directly maintain, the other batch is waiting for PHP 7.3.0~rc2 to hit unstable that added Depends on libpcre2-dev to php7.3-dev. And the rest either needs new upstream version, or a patch, so it will be handled as separate upload. Thanks, Ondrej - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlu0bG9fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcL58xAAlt74VOGlzPN41LKjwpzYuOxnho7DqY/5HREFTwkSQC/YSH2ueGkVYnWe ogazwX5Omffk2Ti7Q9e+3vomzsILJH8b1utDeUGiOslUAA6TUazKhxGqv15FggTz tj+/tQecJ+Iwz9Ig0gbGLQdtIR+XsP3LrvDZ6Ca3Unxmd9TYEAPLFRBaxU7YVVsg khhCV2dPYpNntALYkM81Eq3bV2uHeOGeco8qfBjBa1dB/AuvIYn6d/xe1VwGsFhD 80xnQFTvLuu+68SWBJF6iBJyYpmsLDoWpmTzre0UxRfjFFDvRWrksY2StYELgNhM 07nMGvysyXLPyHnqYENsBez7UPg6RwHS3q2PuJKDoyBCUMdcO6LavvhArr5wCWN3 5+IOyIIoRCWduQHC+0TY+x3anBoAOXHkFURLESZWD7T88c32Kp/jbMdxoYnEHH5O UBBXqlSYsEfEvtiXSbrjfSggcrsZjvZgRZ3DriC8aUtbpw585vDCCSUUq8tXpXc7 CDMtSdCc3mYYinaS1jVPO8NB5ZeFkK5OB8H759fE2G9EU/xIjHzl7dNUbeeJ5WDq hJw6vX7V70pjQNhqgpJKbXrYcBgppnqrjdeQhi0vEt9l2gaJ/R5DrwZdZibEMbL6 OkF/fUomSUxBXAF9GGWYnvutwe+ZFebDC7KoL9XNiU6n6BKLjIc= =MDjY -END PGP SIGNATURE- --- End Message --- --- Begin Message --- On 03/10/2018 09:14, Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu php-ast_0.1.6-2 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-geoip_1.1.1-2 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-gmagick_2.0.5~rc1+1.1.7~rc3-2 . ANY . unstable . -m "Rebuild for PHP > 7.3" > nmu php-gnupg_1.4.0-2 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-msgpack_2.0.2+0.5.7-5 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-propro_2.1.0+1.0.2-1 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-radius_1.4.0~b1-8 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-raphf_2.0.0+1.1.2-3 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-rrd_2.0.1+1.1.3-5 . ANY . unstable . -m "Rebuild for PHP 7.3" > nmu php-uuid_1.0.4-6 . ANY . unstable . -m "Rebuild for PHP 7.3" > > Hi, > > this is a first round of PHP 7.3 related binNMUs for PHP extensions > that I directly maintain, the other batch is waiting for PHP 7.3.0~rc2 > to hit unstable that added Depends on libpcre2-dev to php7.3-dev. > > And the rest either needs new upstream version, or a patch, so it will > be handled as separate upload. Done. FWIW you can use the php7.3 transition bug for these requests, no need to open separate bugs. Cheers, Emilio--- End Message ---
Bug#910136: nmu: php-ast_0.1.6-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 nmu php-ast_0.1.6-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-geoip_1.1.1-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-gmagick_2.0.5~rc1+1.1.7~rc3-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-gnupg_1.4.0-2 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-msgpack_2.0.2+0.5.7-5 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-propro_2.1.0+1.0.2-1 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-radius_1.4.0~b1-8 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-raphf_2.0.0+1.1.2-3 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-rrd_2.0.1+1.1.3-5 . ANY . unstable . -m "Rebuild for PHP 7.3" nmu php-uuid_1.0.4-6 . ANY . unstable . -m "Rebuild for PHP 7.3" Hi, this is a first round of PHP 7.3 related binNMUs for PHP extensions that I directly maintain, the other batch is waiting for PHP 7.3.0~rc2 to hit unstable that added Depends on libpcre2-dev to php7.3-dev. And the rest either needs new upstream version, or a patch, so it will be handled as separate upload. Thanks, Ondrej - -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_DK.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAlu0bG9fFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u WcL58xAAlt74VOGlzPN41LKjwpzYuOxnho7DqY/5HREFTwkSQC/YSH2ueGkVYnWe ogazwX5Omffk2Ti7Q9e+3vomzsILJH8b1utDeUGiOslUAA6TUazKhxGqv15FggTz tj+/tQecJ+Iwz9Ig0gbGLQdtIR+XsP3LrvDZ6Ca3Unxmd9TYEAPLFRBaxU7YVVsg khhCV2dPYpNntALYkM81Eq3bV2uHeOGeco8qfBjBa1dB/AuvIYn6d/xe1VwGsFhD 80xnQFTvLuu+68SWBJF6iBJyYpmsLDoWpmTzre0UxRfjFFDvRWrksY2StYELgNhM 07nMGvysyXLPyHnqYENsBez7UPg6RwHS3q2PuJKDoyBCUMdcO6LavvhArr5wCWN3 5+IOyIIoRCWduQHC+0TY+x3anBoAOXHkFURLESZWD7T88c32Kp/jbMdxoYnEHH5O UBBXqlSYsEfEvtiXSbrjfSggcrsZjvZgRZ3DriC8aUtbpw585vDCCSUUq8tXpXc7 CDMtSdCc3mYYinaS1jVPO8NB5ZeFkK5OB8H759fE2G9EU/xIjHzl7dNUbeeJ5WDq hJw6vX7V70pjQNhqgpJKbXrYcBgppnqrjdeQhi0vEt9l2gaJ/R5DrwZdZibEMbL6 OkF/fUomSUxBXAF9GGWYnvutwe+ZFebDC7KoL9XNiU6n6BKLjIc= =MDjY -END PGP SIGNATURE-
Bug#907342: transition: octave
Le mardi 02 octobre 2018 à 09:43 +0200, Emilio Pozuelo Monfort a écrit : > On 26/08/2018 21:05, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-octave.html > > > > Dear Release Team, > > > > Please schedule a transition for octave. The latest minor release (4.4.1) > > bumped the SOVERSION of liboctave. > > > > Since this ABI change, though not backward compatible, is minimal, the > > transition should be straightforward. In any case, we stand ready to fix > > issues > > and NMU if needed. > > > > The new version of octave is already in experimental. > > Please go ahead. Thanks. Octave 4.4.1 has been uploaded to unstable and is now compiled on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
