Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 3 June 2018 at 00:29, Andreas Tille wrote: > On Sat, Jun 02, 2018 at 11:22:07PM +0200, Emilio Pozuelo Monfort wrote: >> > I found this while rebuilding r-cran-cummerbund (level 13) in Ubuntu, >> > so anything else missing is a leaf package (or set of leaf packages, I >> > guess). >> >> Do you need a binNMU for r-cran-fastcluster, or do you need to patch it? >> Please >> be clear if you need actions from me, otherwise I may not always realise it. > > I just manually uploaded. Thanks for your work anyway Thanks Andreas. I see the 1.1.24-2 upload, but I don't see the r-api-3.5 dependency in the r-cran-fastcluster binary package, so whatever caused it to not appear on the tracker is still not fixed.
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 02/06/18 15:48, Graham Inggs wrote: > On 1 June 2018 at 21:45, Graham Inggs wrote: >> On 1 June 2018 at 21:43, Graham Inggs wrote: >>> r-cran-fastica also seems to be missing r-api-3.4 so doesn't appear on >>> the tracker, but needs a rebuild. >> >> Sorry, my mistake, please ignore. > > OK, this time I'm pretty sure r-cran-fastcluster is not showing up on > the tracker, and needs a rebuild. > > I found this while rebuilding r-cran-cummerbund (level 13) in Ubuntu, > so anything else missing is a leaf package (or set of leaf packages, I > guess). Do you need a binNMU for r-cran-fastcluster, or do you need to patch it? Please be clear if you need actions from me, otherwise I may not always realise it. Cheers, Emilio
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 21:45, Graham Inggs wrote: > On 1 June 2018 at 21:43, Graham Inggs wrote: >> r-cran-fastica also seems to be missing r-api-3.4 so doesn't appear on >> the tracker, but needs a rebuild. > > Sorry, my mistake, please ignore. OK, this time I'm pretty sure r-cran-fastcluster is not showing up on the tracker, and needs a rebuild. I found this while rebuilding r-cran-cummerbund (level 13) in Ubuntu, so anything else missing is a leaf package (or set of leaf packages, I guess).
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 18:35, Graham Inggs wrote: | On 01/06/2018 17:19, Dirk Eddelbuettel wrote: | > This is now taken care of: dbi_1.0.0-2 was just uploaded | | Thanks Dirk! | | Another weirdness I have come across in Ubuntu today is rebuilds of | r-cran-expm and r-cran-mlmrev fail with the following: | | dh_auto_install: warning: can't parse dependency @builddeps@ | Can't call method "get_deps" on an undefined value at | /usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm line 49. | | Both packages have the following in debian/tests/control: | Depends: @, @builddeps@, ... | | Removing either @ or @builddeps@ fixes the build, it seems to choke on | having both. Any ideas? I have seen that too working on the PPA side for some (inofficial) packages I needed for Travis. I think it may be an old debhelper but I don't really know. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 21:43, Graham Inggs wrote: > r-cran-fastica also seems to be missing r-api-3.4 so doesn't appear on > the tracker, but needs a rebuild. Sorry, my mistake, please ignore.
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
r-cran-fastica also seems to be missing r-api-3.4 so doesn't appear on the tracker, but needs a rebuild.
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 01/06/2018 17:19, Dirk Eddelbuettel wrote: This is now taken care of: dbi_1.0.0-2 was just uploaded Thanks Dirk! Another weirdness I have come across in Ubuntu today is rebuilds of r-cran-expm and r-cran-mlmrev fail with the following: dh_auto_install: warning: can't parse dependency @builddeps@ Can't call method "get_deps" on an undefined value at /usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm line 49. Both packages have the following in debian/tests/control: Depends: @, @builddeps@, ... Removing either @ or @builddeps@ fixes the build, it seems to choke on having both. Any ideas?
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 06:32, Dirk Eddelbuettel wrote: | | On 1 June 2018 at 12:41, Graham Inggs wrote: | | A warning: src:dbi has a hard-coded dependency on r-api-3.4 in | | debian/control, and src:wkward has the same in debian/rules. | | That was from when dh-r was borked and could not cope with srcname != pkgname. | | I can look into fixing it this morning but as I said -- conference today and | tomorrow and I am giving a tutorial in 90 minutes. This is now taken care of: dbi_1.0.0-2 was just uploaded Dirk | Dirk | | | I was unable to find any more [1][2] like these codesearch.d.o. | | | | | | [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+r-api-3.4 | | [2] https://codesearch.debian.net/search?q=path%3Adebian%2Frules+r-api-3.4 | | | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 13:37, Emilio Pozuelo Monfort wrote: | On 01/06/18 13:32, Dirk Eddelbuettel wrote: | > | > On 1 June 2018 at 11:54, Emilio Pozuelo Monfort wrote: | > | Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 | > | tseries. | > | > Why is that needed? Aren't ALL binary packages auto-rebuilt? | | Depending on your definition of auto-rebuilt... I was the one who scheduled the | rebuilds, and I picked all arch:any packages from the transition page, except | for that set. The reason is that they didn't depend on r-base-3.4 (except on | kbsd, probably because of old builds), so it seemed unnecessary to rebuild them. Strange. A lot of these are "mine" and both old and fairly central. Let's follow-up when I have a moment. Ping me if forget / get distracted. But as a "technical issue" this should have a technical solution. Dirk | Turns out they need a rebuild as you guys have pointed out, so that's why I have | scheduled the rebuilds for them now. | | Hope that is clear, let me know if it is not. | | Cheers, | Emilio -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On Fri, Jun 01, 2018 at 11:54:35AM +0200, Emilio Pozuelo Monfort wrote: > > I don't see anything wrong with these source packages, as simply rebuilding > > them > > is enough for the r-api-3.5 dependency to appear. > > > > Was there a bug in dh-r at the time these were uploaded? It smells like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897262#10 (specifically the explanation I gave there - the bug title is misleading). > > Anyway, I believe they do need to be rebuilt. > > Emilio, would you schedule these for binNMU as well please? > > Can you pick them up from the tracker, or would you prefer me to provide a > > list? > > Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival > lme4 > tseries. Thanks a lot. Kind regards Andreas. -- http://fam-tille.de
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 01/06/18 13:32, Dirk Eddelbuettel wrote: > > On 1 June 2018 at 11:54, Emilio Pozuelo Monfort wrote: > | Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival > lme4 > | tseries. > > Why is that needed? Aren't ALL binary packages auto-rebuilt? Depending on your definition of auto-rebuilt... I was the one who scheduled the rebuilds, and I picked all arch:any packages from the transition page, except for that set. The reason is that they didn't depend on r-base-3.4 (except on kbsd, probably because of old builds), so it seemed unnecessary to rebuild them. Turns out they need a rebuild as you guys have pointed out, so that's why I have scheduled the rebuilds for them now. Hope that is clear, let me know if it is not. Cheers, Emilio
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 11:54, Emilio Pozuelo Monfort wrote: | Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 | tseries. Why is that needed? Aren't ALL binary packages auto-rebuilt? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 12:41, Graham Inggs wrote: | A warning: src:dbi has a hard-coded dependency on r-api-3.4 in | debian/control, and src:wkward has the same in debian/rules. That was from when dh-r was borked and could not cope with srcname != pkgname. I can look into fixing it this morning but as I said -- conference today and tomorrow and I am giving a tutorial in 90 minutes. Dirk | I was unable to find any more [1][2] like these codesearch.d.o. | | | [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+r-api-3.4 | [2] https://codesearch.debian.net/search?q=path%3Adebian%2Frules+r-api-3.4 | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
A warning: src:dbi has a hard-coded dependency on r-api-3.4 in debian/control, and src:wkward has the same in debian/rules. I was unable to find any more [1][2] like these codesearch.d.o. [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+r-api-3.4 [2] https://codesearch.debian.net/search?q=path%3Adebian%2Frules+r-api-3.4
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 01/06/2018 11:54, Emilio Pozuelo Monfort wrote: Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 tseries. Thanks!
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 01/06/18 11:44, Graham Inggs wrote: > On 01/06/2018 10:09, Graham Inggs wrote: >> On 1 June 2018 at 09:24, Graham Inggs wrote: >>> Does anyone know why some packages, e.g. cluster, foreign, nlme and >>> rmatrix appear different on the tracker [1]? >>> >>> Did they lose their dependency on r-api-3.4 somewhere along the line? >>> Was this intentional? >>> Do they also need to be rebuilt? >>> >>> >>> [1] https://release.debian.org/transitions/html/r-base-3.5.html >> >> I believe this is the cause of the build failures like this one in >> r-cran-irlba [2]. >> >> >> Error: package or namespace load failed for 'Matrix': >> package 'Matrix' was installed by an R version with different >> internals; it needs to be reinstalled for use with this R version >> Error : package 'Matrix' could not be loaded >> ERROR: lazy loading failed for package 'irlba' >> >> >> [2] https://buildd.debian.org/status/package.php?p=r-cran-irlba >> > > I don't see anything wrong with these source packages, as simply rebuilding > them > is enough for the r-api-3.5 dependency to appear. > > Was there a bug in dh-r at the time these were uploaded? > > Anyway, I believe they do need to be rebuilt. > Emilio, would you schedule these for binNMU as well please? > Can you pick them up from the tracker, or would you prefer me to provide a > list? Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 tseries. Cheers, Emilio
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 01/06/2018 10:09, Graham Inggs wrote: On 1 June 2018 at 09:24, Graham Inggs wrote: Does anyone know why some packages, e.g. cluster, foreign, nlme and rmatrix appear different on the tracker [1]? Did they lose their dependency on r-api-3.4 somewhere along the line? Was this intentional? Do they also need to be rebuilt? [1] https://release.debian.org/transitions/html/r-base-3.5.html I believe this is the cause of the build failures like this one in r-cran-irlba [2]. Error: package or namespace load failed for 'Matrix': package 'Matrix' was installed by an R version with different internals; it needs to be reinstalled for use with this R version Error : package 'Matrix' could not be loaded ERROR: lazy loading failed for package 'irlba' [2] https://buildd.debian.org/status/package.php?p=r-cran-irlba I don't see anything wrong with these source packages, as simply rebuilding them is enough for the r-api-3.5 dependency to appear. Was there a bug in dh-r at the time these were uploaded? Anyway, I believe they do need to be rebuilt. Emilio, would you schedule these for binNMU as well please? Can you pick them up from the tracker, or would you prefer me to provide a list?
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 09:24, Graham Inggs wrote: > Does anyone know why some packages, e.g. cluster, foreign, nlme and > rmatrix appear different on the tracker [1]? > > Did they lose their dependency on r-api-3.4 somewhere along the line? > Was this intentional? > Do they also need to be rebuilt? > > > [1] https://release.debian.org/transitions/html/r-base-3.5.html I believe this is the cause of the build failures like this one in r-cran-irlba [2]. Error: package or namespace load failed for 'Matrix': package 'Matrix' was installed by an R version with different internals; it needs to be reinstalled for use with this R version Error : package 'Matrix' could not be loaded ERROR: lazy loading failed for package 'irlba' [2] https://buildd.debian.org/status/package.php?p=r-cran-irlba
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
Does anyone know why some packages, e.g. cluster, foreign, nlme and rmatrix appear different on the tracker [1]? Did they lose their dependency on r-api-3.4 somewhere along the line? Was this intentional? Do they also need to be rebuilt? [1] https://release.debian.org/transitions/html/r-base-3.5.html
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
Hi Sébastien, On Fri, Jun 01, 2018 at 08:57:48AM +0200, Sébastien Villemot wrote: > On Fri, Jun 01, 2018 at 08:20:48AM +0200, Andreas Tille wrote: > > > I have uploaded r-cran-pkgconfig at Thu May 31 20:37:04 BST 2018 [1] and it > > was accepted to unstable at Thu May 31 20:53:21 BST 2018 [2]. However, > > packages.d.o states it has r-api-3.4! :-( > > It's because r-cran-pkgconfig 2.0.1-3 has not yet been built (right now it is > marked as "Needs-Build") Ahhh, you are right, the page I linked to[1] was pointing to 2.0.1-2. It is strange that if you click on the changelog linked to at this page[2] you get r-cran-pkgconfig (2.0.1-3) unstable; urgency=medium * Rebuild for R 3.5 transition * debhelper 11 * Maintainer: Debian R Packages Maintainers * Point Vcs fields to salsa.debian.org * dh-update-R to update Build-Depends -- Andreas Tille Thu, 31 May 2018 21:21:50 +0200 So may be its a matter of waiting (I guess my binary uploads of r-cran-pkgconfig and r-cran-pwt will not harm - I'll stop this now and will simply wait ...) > > PS: Another random pick is r-cran-pwt with the same issue. :-( > > Re r-cran-pwt, it was accepted at Thu, 31 May 2018 21:39:48 +0200, but it has > been marked as “Installed” (in the build logs page) only since 2h ago. And it > is therefore not yet available on mirrors. > > So it looks like it's just a matter of waiting. I was just astonished when I was trying to build r-cran-hms and it was telling me that it can't build since r-cran-pkgconfig would require r-api-3.4. Obviously I failed to remember "Don't panic". ;-) At least I can now build r-cran-hms with the binary upload which is now installed and when I stumble upon the next similar issue I know what to do - just wait. Kind regards Andreas. [1] https://packages.debian.org/unstable/r-cran-pkgconfig [2] http://metadata.ftp-master.debian.org/changelogs/main/r/r-cran-pkgconfig/r-cran-pkgconfig_2.0.1-3_changelog -- http://fam-tille.de
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On Fri, Jun 01, 2018 at 08:20:48AM +0200, Andreas Tille wrote: > I have uploaded r-cran-pkgconfig at Thu May 31 20:37:04 BST 2018 [1] and it > was accepted to unstable at Thu May 31 20:53:21 BST 2018 [2]. However, > packages.d.o states it has r-api-3.4! :-( It's because r-cran-pkgconfig 2.0.1-3 has not yet been built (right now it is marked as "Needs-Build") > PS: Another random pick is r-cran-pwt with the same issue. :-( Re r-cran-pwt, it was accepted at Thu, 31 May 2018 21:39:48 +0200, but it has been marked as “Installed” (in the build logs page) only since 2h ago. And it is therefore not yet available on mirrors. So it looks like it's just a matter of waiting. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
Hi Andreas On 1 June 2018 at 08:20, Andreas Tille wrote: > I have uploaded r-cran-pkgconfig at Thu May 31 20:37:04 BST 2018 [1] and it > was accepted to unstable at Thu May 31 20:53:21 BST 2018 [2]. However, > packages.d.o states it has r-api-3.4! :-( Check the build logs [1], it seems it hasn't built yet. > PS: Another random pick is r-cran-pwt with the same issue. :-( This one only built 2 hours ago, but if you check the logs [2] you will see it built against r-base-core/3.5.0-5, so I think it is fine. Regards Graham [1] https://buildd.debian.org/status/package.php?p=r-cran-pkgconfig=unstable [2] https://buildd.debian.org/status/package.php?p=r-cran-pwt=unstable
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
Hi Emilio, On Thu, May 31, 2018 at 09:25:50AM +0200, Emilio Pozuelo Monfort wrote: > > Cool, it's almost built everywhere now. I have uploaded r-cran-pkgconfig at Thu May 31 20:37:04 BST 2018 [1] and it was accepted to unstable at Thu May 31 20:53:21 BST 2018 [2]. However, packages.d.o states it has r-api-3.4! :-( It is safe to do source only updates at this time??? My local build had r-api-3.5. I wonder whether we should issue a warning that binary uploads are the safer way to get the work we did not bloated by potentially not yet upgraded autobuilders. I think I will rebuild r-cran-pkgconfig, do a binary upload and hope that this will not be needed for all packages I uploaded yesterday. Kind regards Andreas. PS: Another random pick is r-cran-pwt with the same issue. :-( [1] https://alioth-lists.debian.net/pipermail/r-pkg-team/Week-of-Mon-20180528/000792.html [2] https://alioth-lists.debian.net/pipermail/r-pkg-team/Week-of-Mon-20180528/000802.html [3] https://packages.debian.org/unstable/r-cran-pkgconfig -- http://fam-tille.de
