Bug#929011: unblock: singularity-container/3.1.1+ds-1
On June 28, 2019 5:00:00 AM EDT, Ivo De Decker wrote: >Hi, > >On Thu, Jun 27, 2019 at 09:30:09AM -0400, Afif Elghraoui wrote: >> On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui >wrote: >> > >> > >> >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker >> >wrote: >> >>Hi, >> >>> >> >>> So I think the two options we have is (in order of preference): >1. >> >>> unblock singularity-container and let the 3.1 based version in to >> >>> buster, or 2. remove singularity-container from buster. >> >> >> >>It's really too late for option 1. Sorry. >> >> >> >>I added a removal hint. >> >> >> > >> >This request was not just filed recently. I don't understand why I'm >> >being penalized for this being late--the version requested for >> >unblocking as been in unstable for 43 days with no new bugs. And >it's >> >also a leaf package. >> > >> >Please reconsider. >> > >> >> I at least want to know what I could have done because, from my >perspective, >> I did everything in my power to do this as quickly as possible. At >the time >> I made the request, the buster release date had not yet even been >set. > >Please look at the freeze policy: > >https://release.debian.org/buster/freeze_policy.html I have seen it. I hoped we would be trying to make the best possible release rather than just following the freeze policy for its own sake. My understanding of its strictness is to keep packages with reverse-dependencies from breaking them with large changes. This was a very low/no-risk request because it is a leaf package. firefox-esr updates to new versions all the time for security support and actually does break reverse-dependency packages in Stable much of the time as a result. > >The upload of 3.1.1+ds-1 was done on 2019-05-15, the full freeze >started on >2019-03-12. > >During the full freeze, we only accept targeted fixes. Your upload >didn't come >close to that, as you admitted yourself in your original mail to the >unblock >request. The chances of such a request being granted were extremely >small, >even at the point the request was made. > >The unblock won't be granted. Sorry. > Removal of the existing version in buster, on the other hand, I thought was too extreme. I would have tried to support 3.0.3 in buster if any CVEs in it came up and, if that proved too difficult, asked for the exemption to bump to this 3.1 lts version again at that point. regards Afif
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: reopen -1 On June 27, 2019 9:06:41 AM EDT, Afif Elghraoui wrote: > > >On June 27, 2019 5:47:28 AM EDT, Ivo De Decker >wrote: >>Hi, >>> >>> So I think the two options we have is (in order of preference): 1. >>> unblock singularity-container and let the 3.1 based version in to >>> buster, or 2. remove singularity-container from buster. >> >>It's really too late for option 1. Sorry. >> >>I added a removal hint. >> > >This request was not just filed recently. I don't understand why I'm >being penalized for this being late--the version requested for >unblocking as been in unstable for 43 days with no new bugs. And it's >also a leaf package. > >Please reconsider. > I at least want to know what I could have done because, from my perspective, I did everything in my power to do this as quickly as possible. At the time I made the request, the buster release date had not yet even been set. I followed up on the docker bugs and offered to help and was told by the maintainer it was under control. The singularity community was really looking forward to having the package in Debian Stable this time around. regards Afif
Bug#929011: unblock: singularity-container/3.1.1+ds-1
Control: tag -1 - moreinfo On June 25, 2019 4:16:17 PM EDT, Salvatore Bonaccorso wrote: >Hi Paul, hi Afif, > [...] >> >> Your proposed changes very much do not align with the freeze policy, >so >> you're asking for an exception for a new upstream release. This >package >> is currently listed to be auto-removed due to docker.io, so I am not >> going to review it now. docker.io is a major concern for the >> security-team so that needs to be resolved first. If that gets >resolved >> in a timely manner, i.e. before it is auto-removed, please ping this >bug >> (e.g. by removing the moreinfo bug). > >I do agree that the changes are not really reviewable given the size >of the diff. But with Afifs argument and now the package not beeing >marked as autoremoved: if we want to support singularity-container >security wise in buster we would need to bite into the apple and >accept this late new version bump for buster as the 3.1 version. > >So I think the two options we have is (in order of preference): 1. >unblock singularity-container and let the 3.1 based version in to >buster, or 2. remove singularity-container from buster. > >Cc'in team@s.d.o for further comments. > Thanks, Salvatore. I'm removing the moreinfo tag as Paul said to do since the autoremoval warning has been lifted. regards Afif
Bug#926556: unblock: yubikey-personalization/1.19.3-3 - now accepted to Unstable
Control: tag -1 - moreinfo Hello, The package just passed NEW today, so should be ready to go. thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي https://afif.ghraoui.name
Bug#926556: unblock: yubikey-personalization/1.19.3-3
Control: tag -1 - moreinfo Hello, On Sat, 25 May 2019 13:06:36 -0400 Bill Blough wrote: > It appears that the needed changes are located in Salsa [1], and that the > release was prepared but not uploaded (since it's nowhere to be found). > Indeed. It also looks like he prepared the package and debdiff before pushing to salsa, because he merged in a pre-existing commit by a co-maintainer removing his name from the Uploaders list. I've uploaded the state of salsa as is, so I hope that extra change of dropping an Uploader isn't an issue. > This package is team maintained, and since it's not clear to me if the > rest of the team is aware of this issue, I'm CC'ing the team address in > this message. > > If there's no response from nicoo or the rest of the team, I would like to go > ahead with an NMU, assuming that's permissible under these circumstances. > Thanks for following up. regards Afif -- Afif Elghraoui | عفيف الغراوي https://afif.ghraoui.name
Bug#929011: unblock singularity-container - unstable vs testing-proposed-updates
Hello, To add on to this bug report--- singularity-container is a Go package, so its dependencies are statically linked (similar concerns as what happened with docker.io in #927189 [1]). Should I upload to buster? thanks and regards Afif 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927189 -- Afif Elghraoui | عفيف الغراوي https://afif.ghraoui.name
Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4
On July 9, 2018 12:18:06 PM EDT, "Adam D. Barratt" wrote: >On 2018-07-09 04:16, Afif Elghraoui wrote: >> على الأحد 8 تـمـوز 2018 14:38، كتب Adam D. Barratt: >>> > >I've filed #903406 with a small patch that at least builds successfully > >on abel.d.o. > >If you could upload a +deb9u2 including that patch shortly (ideally >today) then we should still be able to get the update into this >weekend's point release. (Alternatively I can upload it, but I'd prefer > >having maintainer buy-in, as I don't really want to have to support it >afterwards. ;-) ) > Thanks. I haven't looked at the patch yet, but I should get to this hopefully tonight. regards Afif
Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4
على الأحد 8 تـمـوز 2018 14:38، كتب Adam D. Barratt: > > Unfortunately, the build failed on armhf: > > > [java] [exec] /usr/bin/ld: cannot find -ljvm > [java] [exec] collect2: error: ld returned 1 exit status > [java] [exec] make[2]: *** [jgdi_test] Error 1 > > BUILD FAILED > /<>/gridengine-8.1.9+dfsg/source/build.xml:85: The following error > occurred while executing this line: > /<>/gridengine-8.1.9+dfsg/source/build.xml:30: Java returned: 1 > > > Looking at buildd.d.o, this seems to have been happening in unstable > for a few months now as well, but I can't find a related bug report. > Any idea what's going on here? > I asked the java team about this in December [1] and never heard back. It seemed to me that the path to the openjdk libraries on armhf changed so that the gridengine build system wasn't looking in the right place anymore and thought the java team would know more about it. I didn't pursue it further, though. regards Afif 1. https://lists.debian.org/debian-java/2017/12/msg00050.html -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4
على السبت 7 تـمـوز 2018 07:35، كتب Adam D. Barratt: > With the above change, please feel free to upload. Uploaded. I hope source-only is fine. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4 - complete diff
Here is the complete diff for the proposed upload, including the changelog: --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +gridengine (8.1.9+dfsg-4+deb9u1) stretch-proposed-updates; urgency=medium + + * gridengine-qmon: + - Use correct paths to qmon pixmaps (Closes: #892296) + + -- Afif Elghraoui Thu, 05 Jul 2018 00:38:58 -0400 + gridengine (8.1.9+dfsg-4) unstable; urgency=low * Patch upstream source to declare prerequisites for pdc (Closes: #846770) diff --git a/debian/gridengine-qmon.install b/debian/gridengine-qmon.install index 99b6cf17d..59ddc17f0 100644 --- a/debian/gridengine-qmon.install +++ b/debian/gridengine-qmon.install @@ -1,2 +1,2 @@ debian/tmp/usr/bin/*/qmon usr/lib/gridengine -debian/tmp/usr/qmon/PIXMAPS/* usr/share/gridengine/pixmaps +debian/tmp/usr/qmon/PIXMAPSusr/share/gridengine/qmon/ diff --git a/debian/gridengine-qmon.links b/debian/gridengine-qmon.links index cefcd72ed..ecaf1fda2 100644 --- a/debian/gridengine-qmon.links +++ b/debian/gridengine-qmon.links @@ -1 +1,2 @@ usr/share/gridengine/gridengine-wrapper usr/bin/qmon +usr/share/gridengine/qmon/PIXMAPS var/lib/gridengine/qmon/PIXMAPS -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#903015: stretch-pu: package gridengine/8.1.9+dfsg-4
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu A user requested that the bug #892296 be fixed in Stable [1]. The necessary patch to fix this is at the end of this message. Thanks and regards Afif 1. https://lists.debian.org/debian-hpc/2018/06/msg00021.html >From c416d2f88fa6ee1518d95e37a65856c571994bc0 Mon Sep 17 00:00:00 2001 From: Afif Elghraoui Date: Sun, 11 Mar 2018 17:07:27 -0400 Subject: [PATCH] Use correct paths to qmon pixmaps Closes: #892296 --- debian/gridengine-qmon.install | 2 +- debian/gridengine-qmon.links | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/gridengine-qmon.install b/debian/gridengine-qmon.install index 99b6cf17d..59ddc17f0 100644 --- a/debian/gridengine-qmon.install +++ b/debian/gridengine-qmon.install @@ -1,2 +1,2 @@ debian/tmp/usr/bin/*/qmon usr/lib/gridengine -debian/tmp/usr/qmon/PIXMAPS/* usr/share/gridengine/pixmaps +debian/tmp/usr/qmon/PIXMAPSusr/share/gridengine/qmon/ diff --git a/debian/gridengine-qmon.links b/debian/gridengine-qmon.links index cefcd72ed..ecaf1fda2 100644 --- a/debian/gridengine-qmon.links +++ b/debian/gridengine-qmon.links @@ -1 +1,2 @@ usr/share/gridengine/gridengine-wrapper usr/bin/qmon +usr/share/gridengine/qmon/PIXMAPS var/lib/gridengine/qmon/PIXMAPS -- 2.18.0
Please allow smalr to migrate to testing
Hello, We have one more case of an arch:all package held up in testing because of installability issues on i386 due to a dependency on bwa. Can smalr be allowed to migrate to Testing? https://qa.debian.org/excuses.php?package=smalr Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: canu - not migrating to testing despite several weeks of no excuses
On October 13, 2017 2:39:40 AM EDT, Afif Elghraoui <a...@debian.org> wrote: > > or >add mhap to build-depends to prevent canu from building on >architectures where mhap isn't available. > I mean libssw (mhap being arch:all) regards Afif
Re: canu - not migrating to testing despite several weeks of no excuses
On October 13, 2017 1:37:30 AM EDT, "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote: >On Fri, 2017-10-13 at 00:39 -0400, Afif Elghraoui wrote: >> >> على الخميس 12 تشرين الأول 2017 01:48، كتب Adam D. Barratt: >> Is it not possible to depend on it without incurring an RC >> bug? > >Yes, trivially - by depending on it only on architectures where it >actually exists. Your problem is that e.g. your armel packages end up >depending on a package that only exists on amd64. > >Your realistic options depend on how strongly canu requires mhap (can >it work without it on non-amd64 architectures?), and how strongly mhap >requires libssw (again, can it work without it on other architctures?). > Canu strongly requires mhap and I believe mhap strongly requires libssw. It looks like I either need to hardcode canu's arch list to exclude the other platforms despite its ability to build on them, or add mhap to build-depends to prevent canu from building on architectures where mhap isn't available. Thanks and regards Afif
Re: canu - not migrating to testing despite several weeks of no excuses
على الخميس 12 تشرين الأول 2017 01:48، كتب Adam D. Barratt: > The britney log says: > > trying: canu > skipped: canu (0, 2975, 79) > got: 43+0: a-4:i-26:a-2:a-1:a-1:m-1:m-4:m-1:p-1:s-2 > * arm64: canu > > Which indicates that the binary package "canu" would be uninstallable > on (at least) arm64 were the package to migrate. A little investigation > leads to this being due to the dependency on "mhap", which in turns > depends on "libssw-java", and: > > libssw-java | 1.1-1+b1 | testing | amd64 > libssw-java | 1.1-1+b1 | unstable | amd64, kfreebsd-amd64 > > This also means that your package has an unreported RC bug in unstable > right now, as it cannot possibly be installable on any architectures > other than amd64 and kfreebsd-amd64. Thanks for the explanation. libssw uses some x86-specific processor features if I remember correctly. Is it not possible to depend on it without incurring an RC bug? Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
canu - not migrating to testing despite several weeks of no excuses
Hi, release team, Do you know what the problem is here with canu? : https://qa.debian.org/excuses.php?package=canu ~~~ Migration status: OK: Will attempt migration (Any information below is purely informational) 39 days old (needed 5 days) Piuparts tested OK - https://piuparts.debian.org/sid/source/c/canu.html Valid candidate ~~~ It's been stuck like this for a while. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#852970: RM: pbcopper/0.0.1+20161202-2
على السبت 28 كانون الثاني 2017 07:45، كتب Simon McVittie: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > X-Debbugs-Cc: Afif Elghraoui <a...@debian.org> > > Afif Elghraoui wrote: >> There is nothing actually wrong with pbcopper, but there is no sense in >> releasing this package for stretch since it basically only exists to >> support unanimity, which did not make the cutoff. > I think the hint for this would be: > > # RoM, #852654 > remove pbcopper/0.0.1+20161202-2 Sure. Just as long as it's removed from Testing and not from Unstable. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: pbseqlib testing migration
I'd like to follow-up on this. I will try for an executive summary in case my original message was too long: * pbseqlib builds three arch:any libraries as well as the arch:all libpbseq-dev that depends on all of their -dev packages * pbseqlib has a new build dependency that does not build on 32-bit architectures (all old pbseqlib binaries have already been removed) * the un-installability of libpbseq-dev on i386 is preventing testing migration. I believe this needs a force-hint. This is also somewhat urgent because some rdeps with fixed RC bugs cannot migrate without this one going first. Thanks and regards Afif على السبت 31 كانون الأول 2016 22:59، كتب Afif Elghraoui: > Hello, > > pbseqlib includes a metapackage (arch:all) to install its component > sub-libraries and development files (arch:any). Since its new dependency > pbbam is not available on 32-bit architectures, this metapackage is not > installable on i386 anymore. Testing migration appears to be blocked > because of this, even though the metapackage would not be new to Stretch: > > ~~~ https://qa.debian.org/excuses.php?package=pbseqlib > 11 days old (needed 10 days) > libpbseq/i386 unsatisfiable Depends: libpbdata (>= 0~20161219-1) > libpbseq/i386 unsatisfiable Depends: libpbihdf (>= 0~20161219-1) > libpbseq/i386 unsatisfiable Depends: libblasr (>= 0~20161219-1) > libpbseq-dev/i386 unsatisfiable Depends: libpbdata-dev (>= 0~20161219-1) > libpbseq-dev/i386 unsatisfiable Depends: libpbihdf-dev (>= 0~20161219-1) > libpbseq-dev/i386 unsatisfiable Depends: libblasr-dev (>= 0~20161219-1) > Piuparts tested OK - https://piuparts.debian.org/sid/source/p/pbseqlib.html > Valid candidate > ~~~ > > Does this situation need a force hint? We need this to migrate in order > to prevent autoremoval of several other packages. > > Thanks and regards > Afif > -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
pbseqlib testing migration
Hello, pbseqlib includes a metapackage (arch:all) to install its component sub-libraries and development files (arch:any). Since its new dependency pbbam is not available on 32-bit architectures, this metapackage is not installable on i386 anymore. Testing migration appears to be blocked because of this, even though the metapackage would not be new to Stretch: ~~~ https://qa.debian.org/excuses.php?package=pbseqlib 11 days old (needed 10 days) libpbseq/i386 unsatisfiable Depends: libpbdata (>= 0~20161219-1) libpbseq/i386 unsatisfiable Depends: libpbihdf (>= 0~20161219-1) libpbseq/i386 unsatisfiable Depends: libblasr (>= 0~20161219-1) libpbseq-dev/i386 unsatisfiable Depends: libpbdata-dev (>= 0~20161219-1) libpbseq-dev/i386 unsatisfiable Depends: libpbihdf-dev (>= 0~20161219-1) libpbseq-dev/i386 unsatisfiable Depends: libblasr-dev (>= 0~20161219-1) Piuparts tested OK - https://piuparts.debian.org/sid/source/p/pbseqlib.html Valid candidate ~~~ Does this situation need a force hint? We need this to migrate in order to prevent autoremoval of several other packages. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?
على الأحد 20 تشرين الثاني 2016 23:05، كتب Niels Thykier: > Which source packages are we talking about? gridengine and ori. In the case of gridengine, we have a contributed patch, but it has not been applied upstream or seen more than compile-testing. In the case of ori, upstream's plan is to drop the dependency on openssl, but I don't know when this will happen. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?
Hi, I'm maintaining two packages affected by this transition. So far, I've just been monitoring the situation, as I share many of the concerns that have been raised on -devel. Is it an acceptable solution to instead build-depend on libbsl1.0-dev, downgrade the severity of the FTBFS with 1.1.0 bug to important, and unblock the transition by it? Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: migration exception for mhap
Hello, I'm sorry that I've been away from my email for a while. I was also hoping for some discussion of Emilio's point. على الإثنين 25 تـمـوز 2016 09:19، كتب Emilio Pozuelo Monfort: > Hi, > > On 25/07/16 11:13, Jonathan Wiltshire wrote: >> On 2016-07-24 23:11, Afif Elghraoui wrote: >> >>>> For performance reasons britney only tests installability on amd64 and >>>> i386 (hence the message), otherwise the list would be much longer. >>>> >>>> A package cannot migrate if it is not installable on the test >>>> architectures. >>>> >>> >>> For the purposes of mhap, it is a package for scientific research and >>> would probably not be usable on i386 even if it could be installed >>> there. It requires more powerful processors than anything that is i386 >>> that I am aware of (besides am64 CPUs posing as such, but the package >>> works on x32 anyway). >> >> Maybe you want "arch:any-amd64 x32" then? > > I'm not sure about that. mhap is arch:all. It just happens to be uninstallable > on some architectures because one of its dependencies isn't available > everywhere. Whenever that dependency gets support for those architectures, > then > mhap will be installable. > > This isn't different to sspace, circlator, pbalign, console-setup-freebsd, > python-pbcore, python-pbgenomicconsensus... to name a few. > > Maybe we should change our policy here or fix some stuff (including how > britney > handles arch:all packages), but we should carefully think about it and then be > consistent about it. > For the people who hold the view that, if a package of architecture-independent files is not installable on i386, it should be duplicated for each of the architectures on which it will be installable, has this opinion taken the approval of the ftpmasters? I don't think they would be in favor of the idea of wasting space on the archive for this reason. I completely agree with Emilio, as well as Ansgar who made this point before[1]. Thanks and regards Afif 1. https://lists.debian.org/debian-devel/2016/03/msg00415.html -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: migration exception for mhap
على الأحد 24 تـمـوز 2016 05:32، كتب Jonathan Wiltshire: > On 2016-07-23 23:14, Afif Elghraoui wrote: >> >> mhap is arch:all. libssw-java contains Java bindings for its C library >> and is not supported on i386. The dependencies are not broken. I hope >> this is a clear enough explanation. > > Yes, I know all that, but your dependencies are still broken. Your > package is uninstallable on any architecture other than amd64. > I thought arch:all meant that the package doesn't have architecture-dependent files, not that it's supposed to be usable on every single one. Barring porting libssw to i386 or reducing functionality of the package to remove dependency on libssw, would you prefer that I declare mhap as arch:any so that it only builds for architectures where it will be installable? Then we'll have multiple copies of the exact same package for amd64, kfreebsd-amd64, and x32. > For performance reasons britney only tests installability on amd64 and > i386 (hence the message), otherwise the list would be much longer. > > A package cannot migrate if it is not installable on the test > architectures. > For the purposes of mhap, it is a package for scientific research and would probably not be usable on i386 even if it could be installed there. It requires more powerful processors than anything that is i386 that I am aware of (besides am64 CPUs posing as such, but the package works on x32 anyway). If you really want me to jump through this hoop, I will be disabling some functionality of the mhap package. I'm hoping it won't come to this. Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: [Debian-med-packaging] migration exception for mhap
على السبت 23 تـمـوز 2016 06:56، كتب Jonathan Wiltshire: > On 2016-07-23 09:22, Afif Elghraoui wrote: >> The latest upstream release of the mhap package adds a new dependency >> on >> libssw-java, which is not available for i386. The testing excuses page >> for mhap currently says: >> >> 8 days old (needed 5 days) >> mhap/i386 unsatisfiable Depends: libssw-java >> >> May we have this package unblocked for migration? > > No; you can't have a package in testing with unsatisfiable dependencies. > Either make libssw-java available on i386 or fix your dependencies. > mhap is arch:all. libssw-java contains Java bindings for its C library and is not supported on i386. The dependencies are not broken. I hope this is a clear enough explanation. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
migration exception for mhap
Hello, The latest upstream release of the mhap package adds a new dependency on libssw-java, which is not available for i386. The testing excuses page for mhap currently says: 8 days old (needed 5 days) mhap/i386 unsatisfiable Depends: libssw-java May we have this package unblocked for migration? Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Confusing migration excuse regarding mips64el
على السبت 16 تـمـوز 2016 14:26، كتب Adam D. Barratt: > There are other reasons why the migration might not have occurred. The > excuse in question finishes with "valid candidate", indicating that this > is /not/ a blocker. Ok, I guess I expected the excuses page to have all the relevant information. > >> So what does the "nevermind" part mean? > > It means exactly what it says, that mips64el is not a blocker for > migration. If you check the logs, you will find the actual issue: > > trying: python-pysam > skipped: python-pysam (0, 16, 15) > got: 70+1071: a-3:i-20:a-0:a-0:a-0:m-0:m-3:p-43:p-0:s-1:m-1071 > * mipsel: pbbarcode, python-kineticstools, python-pbh5tools > > This is due to the fact that each of those packages depends on > python-pbcore, which in turn depends on python-pysam. As you've removed > the mipsel binaries for python-pysam, migrating the new version would > therefore render those packages uninstallable in testing, so britney > refuses. > > As the dependent packages appear to have the same version numbers in > testing and unstable, this also means that they will currently be > uninstallable (and therefore RC-buggy) in unstable. If python-pysam is > not intended to be reintroduced on mipsel, the binaries of the other > packages will also need removing on that architecture. > Thanks for clearing this up. I've requested removal of those rdeps on mipsel and armel. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Confusing migration excuse regarding mips64el
[please keep me in Cc] Hello, I had previously requested removal of outdated binaries for python-pysam to enable testing migration, but I did not do so for mips64el because the migration excuse[1] says: ~~~ missing build on mips64el: python-pysam, python-pysam-tests, python3-pysam (from 0.9.0+ds-1) (but mips64el isn't keeping up, so nevermind) ~~~ It seems that this actually does matter, since migration has not happened despite the other outdated binary packages having been removed for several days. So what does the "nevermind" part mean? Thanks and regards Afif 1. https://qa.debian.org/excuses.php?package=python-pysam -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Testing migration exception for smrtanalysis and pbh5tools (arch: all)
Hello, Two new source packages, smrtanalysis and pbh5tools, with arch:all binary packages have indirect dependencies on bcftools, which cannot currently build on i386 (#819617). These two packages cannot make their first testing migration because they're not installable on i386. May I have an exception made for them? Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: arch: all packages and uninstallability on i386
على الإثنين 11 نيسـان 2016 14:00، كتب Emilio Pozuelo Monfort: > On 09/04/16 21:24, Afif Elghraoui wrote: >>> The other option is to fix python-pysam on i386 (i.e. fix >>> bcftools). Obviously the latter would be preferable... >>> >> >> The main problem is #819617, which has been under investigation upstream >> for some time and I doubt that a resolution will appear soon. bcftools >> is a new build-dependency of pysam, so there is no regression on >> python-pysam's part. > > Can you ping the upstream bug again? It seems like upstream was working on it, > and some time has passed, so maybe will see a fix soon. In that case, having > it > build on i386 to solve this uninstallability problem would be good. > Done. I don't inspire as much urgency for this kind of report since I don't speak as an affected user, but I pinged anyway. > Otherwise, removing the i386 binaries for the rdeps is the way to go. > Okay. I'll see what they say. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: arch: all packages and uninstallability on i386
على السبت 9 نيسـان 2016 03:43، كتب Emilio Pozuelo Monfort: > Both packages went in. > Many thanks. Now I can upload to jessie-backports! > However python-pysam is a problem because the arch:all rdeps have arch:any > rdeps, and those are now broken on i386. > > force breaks: > * i386: falconkit, kineticstools, pbalign, pbbarcode, pbgenomicconsensus, > pbh5tools, pbhoney, pbjelly, pbsuite, python-kineticstools, python-pbalign, > python-pbbanana, python-pbcore, python-pbgenomicconsensus, python-pbh5tools, > python-pbsuite-utils > > One solution would be to remove the i386 binaries for those as well (which is > what would have normally happened when you requested the removal of the pysam > i386 binaries). I can do this, but will there still be a problem for the arch: all reverse-dependencies? I'm worried that they might not stay in testing for not being installable on i386. > The other option is to fix python-pysam on i386 (i.e. fix > bcftools). Obviously the latter would be preferable... > The main problem is #819617, which has been under investigation upstream for some time and I doubt that a resolution will appear soon. bcftools is a new build-dependency of pysam, so there is no regression on python-pysam's part. > Can you look at that? > For the record, bcftools was also failing to build on three other release archs (#812268). That was fixed upstream after I forwarded the report. I backported the necessary patch to resolve it in Debian, but there are still issues on i386. It looks like the required changes to fix it would be more extensive. Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: arch: all packages and uninstallability on i386
على الجمعـة 8 نيسـان 2016 00:17، كتب Emilio Pozuelo Monfort: > On 08/04/16 07:16, Afif Elghraoui wrote: >> [Please Cc me; I'm not subscribed] >> I am trying to prevent python-pysam and its reverse-dependencies from >> being removed from testing. The latest release of python-pysam can not >> yet build on i386, and it cannot migrate to testing because it would >> make it's arch: all reverse-dependencies uninstallable. The previous >> upstream release has an RC bug and I don't want any of these packages to >> be removed from testing because of this. > > So this used to build on i386 but those binaries have been removed. Right. > I suppose we > could force this in. > Please and thank you! >> Another package is circlator, which is arch: all and has some >> dependencies that cannot currently build on i386. Its testing migration >> has been stalled for over two weeks because it's not installable on i386. > > That sounds like it's a regression, i.e. the version in testing is currently > installable on i386 whereas the version in sid isn't. That's why it doesn't > migrate. This one's actually a new package and has never been in testing before. > We could force it as well, making this package uninstallable on i386 > (just as if it was arch:any and you had removed the i386 binaries). > > Is that what you want? Yes, that's right. > Is it not possible to fix that rdep? > The dependencies? I just checked--- one of them (bwa) is specifically limited to (kfree-bsd-)amd64. According to an older changelog entry (0.7.5a-2), this is because of a requirement for SSE2. That is from an older release and I suppose the situation could have changed, but is it necessary to hold back the package because of this? Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
arch: all packages and uninstallability on i386
[Please Cc me; I'm not subscribed] Hi, I have a similar problem with two packages. I am trying to prevent python-pysam and its reverse-dependencies from being removed from testing. The latest release of python-pysam can not yet build on i386, and it cannot migrate to testing because it would make it's arch: all reverse-dependencies uninstallable. The previous upstream release has an RC bug and I don't want any of these packages to be removed from testing because of this. Another package is circlator, which is arch: all and has some dependencies that cannot currently build on i386. Its testing migration has been stalled for over two weeks because it's not installable on i386. I'm hoping these two issues can be resolved soon. The testing autoremoval for python-pysam and its reverse-dependencies is coming up very soon. Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: arch all package's missing dependency on i386 prevents testing migration
على الأربعاء 30 آذار 2016 01:42، كتب Ansgar Burchardt: > As far as I remember, the testing migration script checks installability > of arch:all packages on amd64 and i386, and there are manual workarounds > for arch:all packages that are not installable on these architectures. > Cc'ed the release team to take a look too. Thanks! I'd like to upload this package to jessie-backports, so I'm hoping this won't be too much of a delay because it also has to wait in backports-NEW afterwards. Many thanks and regards Afif
