Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Sent from my MetroPCS 4G LTE Android device
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, 2013-04-05 at 13:09:51 +0100, Ian Jackson wrote: Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)): Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). I agree entirely with what Guillem says. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. I wonder if this should be explicitly stated in the dev ref. Yeah, I guess, I'll try to come up with a patch in the next weeks (added to my TODO list). Thanks. Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130504143535.gb11...@gaara.hadrons.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 12:16:11PM +0300, Niko Tyni wrote: On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote: On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@debian.org writes: FWIW, I've done ABI-incompatible uploads of perl to experimental in the past without changing the perlapi-* virtual package name or the libperl SONAME. The aim was to experiment with different configuration options, particularly 64-bit integers and 128-bit long doubles. I certainly didn't support upgrades from those versions to the same extent as I'd have done for unstable. OTOH, the packages were pretty close to uninstallable on any non-minimal systems anyway, as we didn't offer corresponding rebuilt XS modules in experimental. Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Well, it wasn't installable with perl packages in sid at the time due to a major version upgrade, which is why I was experimenting with incompatible ABI changes in the first place. (This was around perl/5.12.0-1 or so.) That was OK then. Just in general one should think about such things. Note: This isn't an attack of you or that upload. You/perl just have the horrible luck of being used as an example. You should have set the perlapi-* to include -experimental or something to make it differ from sid. Having the perlapi-* provides and depends makes this simple. First, this was against the policy at the time (since fixed with #579457.) Second, the ABI changes would also have required an extra libperl SONAME change with the implied NEW processing. That's too much overhead IMO. Yeah, NEW queue processing can be bad. But if it realy is just experimenting and the dependencies prevent mixed setups then I wouldn't take the SONAME so serious. The SONAME change is there so old and new stuff can coexist and migrate over time. That isn't applicable to such an experimental situation. Imho experimental packages should be made with the hope that they could enter sid in the future. Sure they are for experimenting. But say the experiment is successfull shouldn't the package go to sid? If you have to redesign them at that point you will just introduce new bugs at that point and restart the testing process again. The experiment in this case was seeing if the test suite passes on all architectures or not. It did not because long doubles are weird on powerpc, so I reverted the change. I then uploaded the next try (again, to experimental of course) without changing the perlapi-* or the SONAME. I still think that expecting full-blown ABI change handling for iterations like this in experimental is too much. Totaly. Not for every iteration anyway. As long as mixing/breaking sid is prevented with an SONAME change or dependencies that is fine. I think ftp-master would kill you if every experimental upload had to go through NEW. As a side note: What you did probably shouldn't have been using experimental at all. This should have gone to the long proposed build me this package buildd extension. All you wanted (it sounds like) was to compile the package and see the results of the built time test suite. It would be nice if someone would work on implementing this idea. That way maintainers could upload sources for test builds on selective archs. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423122218.GA26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune I sure hope you mean breakages between different experimental versions. Not breakages compared to stable/testing/unstable versions. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423122357.GB26534@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-23 14:23:57 +0200, Goswin von Brederlow wrote: On Fri, Apr 19, 2013 at 09:53:05AM +, Sune Vuorela wrote: On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune I sure hope you mean breakages between different experimental versions. Not breakages compared to stable/testing/unstable versions. You should also consider breakage between an experimental version and a future unstable version. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130423125918.gb1...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Thu, Apr 18, 2013 at 10:56:34AM +0200, Goswin von Brederlow wrote: On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@debian.org writes: FWIW, I've done ABI-incompatible uploads of perl to experimental in the past without changing the perlapi-* virtual package name or the libperl SONAME. The aim was to experiment with different configuration options, particularly 64-bit integers and 128-bit long doubles. I certainly didn't support upgrades from those versions to the same extent as I'd have done for unstable. OTOH, the packages were pretty close to uninstallable on any non-minimal systems anyway, as we didn't offer corresponding rebuilt XS modules in experimental. Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Well, it wasn't installable with perl packages in sid at the time due to a major version upgrade, which is why I was experimenting with incompatible ABI changes in the first place. (This was around perl/5.12.0-1 or so.) You should have set the perlapi-* to include -experimental or something to make it differ from sid. Having the perlapi-* provides and depends makes this simple. First, this was against the policy at the time (since fixed with #579457.) Second, the ABI changes would also have required an extra libperl SONAME change with the implied NEW processing. That's too much overhead IMO. Imho experimental packages should be made with the hope that they could enter sid in the future. Sure they are for experimenting. But say the experiment is successfull shouldn't the package go to sid? If you have to redesign them at that point you will just introduce new bugs at that point and restart the testing process again. The experiment in this case was seeing if the test suite passes on all architectures or not. It did not because long doubles are weird on powerpc, so I reverted the change. I then uploaded the next try (again, to experimental of course) without changing the perlapi-* or the SONAME. I still think that expecting full-blown ABI change handling for iterations like this in experimental is too much. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130419091611.GA4918@madeleine.local.invalid
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-18, Goswin von Brederlow goswin-...@web.de wrote: Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. Welcome to experimental. Stuff might break, stuff might be deliberately broken, ... I might also not properly manage abi changes in libraries in experimental, especially when it is me packaging snapshots. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkn2505.fhs.nos...@sshway.ssh.pusling.com
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas Why wait? Well, ok, better not add changes to dpkg right now. :) Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418084850.GB24658@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 02:28:23PM -0700, Russ Allbery wrote: Niko Tyni nt...@debian.org writes: FWIW, I've done ABI-incompatible uploads of perl to experimental in the past without changing the perlapi-* virtual package name or the libperl SONAME. The aim was to experiment with different configuration options, particularly 64-bit integers and 128-bit long doubles. I certainly didn't support upgrades from those versions to the same extent as I'd have done for unstable. OTOH, the packages were pretty close to uninstallable on any non-minimal systems anyway, as we didn't offer corresponding rebuilt XS modules in experimental. Oh, that's a good point. Yes, I hadn't thought about that specific case for testing ABI breakage in experimental. But then that simply is a broken upload. It will break horribly if you install the experimental perl but keep other perl packages from sid. You should have set the perlapi-* to include -experimental or something to make it differ from sid. Having the perlapi-* provides and depends makes this simple. Imho experimental packages should be made with the hope that they could enter sid in the future. Sure they are for experimenting. But say the experiment is successfull shouldn't the package go to sid? If you have to redesign them at that point you will just introduce new bugs at that point and restart the testing process again. But that might just be me. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418085634.GC24658@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-18 10:48 +0200, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas Why wait? Well, ok, better not add changes to dpkg right now. :) Has anyone tried patching dpkg to keep the epoch in the deb filename? Yes, Guillem did so one year ago but reverted it. Anything break? Quite a few things, see the thread on http://lists.debian.org/debian-dpkg/2012/04/threads.html#00024. Cheers, Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738uoxlad@turtle.gmx.de
epoch in filenames for packages (was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/18/2013 10:48, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. It handles it by rejecting the later upload. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? [...] Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? [1] and [2] include at least dpkg-genchanges and dpkg-source breaking. [1] http://bugs.debian.org/551323 [2] http://bugs.debian.org/645895 Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516fb70b.3010...@debian.org
Re: epoch in filenames for packages (was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Thu, Apr 18, 2013 at 11:04:11AM +0200, Ansgar Burchardt wrote: On 04/18/2013 10:48, Goswin von Brederlow wrote: On Sun, Apr 07, 2013 at 09:29:19PM +0800, Thomas Goirand wrote: On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. It handles it by rejecting the later upload. I wonder what would happen if one uploaded a foo_1.2.3-1_amd64.deb with a new epoch but same hash. :) The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? [...] Has anyone tried patching dpkg to keep the epoch in the deb filename? Anything break? [1] and [2] include at least dpkg-genchanges and dpkg-source breaking. [1] http://bugs.debian.org/551323 [2] http://bugs.debian.org/645895 Ansgar Both of those are part of dpkg so they should have been patched too. I ment does anything outside of dpkg break. But that is probably covered in the thread mentioned in the last mail. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130418144535.GD21076@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote: Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit : Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4) or you could have an API virtual package: r-base-api-3.0 Hi Dirk and everybody, since we already have a substitution variable in most of the R packages (R:Depends), I think that we can use it to address the problem. First, let's define the problem: R broke backwards compatibility a couple of times since it has been packaged. Rebuilding packages is usually done swiftly, but there remains the problem of transitions to Testing and updates on the users computers. There is usually a gap of some years between breakages, so we do not want an over-engeneered solution. I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. (The exception being that partial upgrades from Wheezy to Jessie will not be supported, but this is also the case in the current situation). In short: That is not an exception but THE intention. It's the whole point of having an api virtual package. In long: The R package breaks compatibility in such a way that a partial upgrade simply won't be functional. You either update them all or none. Till now installing any package compiles against a newer R API would pull in the newer r-base-core package to fullfill its version requirement but would not force old R packages already installed to also be updated. This leads to procken packages on partial update. Introducing the api virtual package will enforce that all R packages will be compiled against the same R API, against a compatible r-base-core. Installing one package compiled against the new R will force apt/aptitude to also update all the already installed R packages, which is what is required. - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. It might be enough to only depend on the api or you might need both, the api virtual package and a versioned depends for a minimum version. But that depends on the circumstances. Design it so that it is easy to have both and so that you don't miss updating the minimum version when required. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. It might make sense to have a single file r-api-virtual-version (or so) in the source and generate the Provides: field and /usr/share/R/debian/r-cran.mk from that single source. Let's discuss the details on #704805 Have a nice week-end, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130416131604.GC21076@frosties
Re: Further Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sat, Apr 13, 2013 at 09:48:05PM +0200, Anton Gladky wrote:
On 04/13/2013 04:18 PM, Dirk Eddelbuettel wrote:
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p | grep Maintainer | \
sed -e 's/.*//' -e 's/$//'; done | \
awk -F, '/^r-/ {print $2,$1}' | sort
debian-med-packag...@lists.alioth.debian.org r-bioc-cummerbund
...
debichem-de...@lists.alioth.debian.org r-cran-readbrukerflexdata
i...@maintz.de r-cran-gtable
lawre...@debian.org r-cran-pscl
root@max:/#
Cool, considering the deep freeze...
+1
As previous discussion has shown the R change is at least questionable.
I personally will not upgrade any R related package in Debian Med or
Debian Science before Wheezy is released - I'm fine if anybody else
wants to spend time into this, provided the relevant team VCS will be
updated.
Kind regards
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130415080652.gb19...@an3as.eu
Re: Further Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sat, Apr 13, 2013 at 09:18:05AM -0500, Dirk Eddelbuettel wrote: Charles, failing that, shall we coordinate off-list? Re-building in chroot takes about a minute or two each but sadly some of these package appear effectively orphaned (eg gpplot2, single upload 15 months ago -- is that really work done to Debian standards?) Perhaps I misread this, but it seemed you are criticising folks for not working on things which don't impact wheezy? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415090947.GA5777@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-04 21:08:45 +0200, Philipp Kern wrote: On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote: I wonder whether there are packaged extensions […] So you didn't actually look. EOT from me, it's wasting my time. Sorry, I meant why instead of whether. As I've said in my message, packaged extensions are useless IMHO, because Firefox can handle upgrades gracefully. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. Our current freeze rules that apply to unstable prevent that in a social, not technical way. So, transitions could be avoided in a social way. No need for a freeze. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415142214.ga18...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote: So, transitions could be avoided in a social way. No need for a freeze. Let's see how well that works - look at the very first message in this thread. Neil -- signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-15 15:31:38 +0100, Neil McGovern wrote: On Mon, Apr 15, 2013 at 04:22:14PM +0200, Vincent Lefevre wrote: So, transitions could be avoided in a social way. No need for a freeze. Let's see how well that works - look at the very first message in this thread. My point is that: whether there is a freeze or not, it doesn't work well. On the other hand, one could argue that without the freeze system, it could have worked better: here the maintainer may have thought that because of the freeze, uploading the package wouldn't have hurt the next release. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130415143903.gb18...@xvii.vinc17.org
Re: Further Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
Le Sat, Apr 13, 2013 at 09:18:05AM -0500, Dirk Eddelbuettel a écrit : I would be really terrific if the the debian-med, debian-science, debichem teams could update some of these packages. Charles, failing that, shall we coordinate off-list? Re-building in chroot takes about a minute or two each but sadly some of these package appear effectively orphaned (eg gpplot2, single upload 15 months ago -- is that really work done to Debian standards?) Hi Dirk and everybody, my pace is aproximately one package per day, partly because instead of rebuilding I take the opportunity to upgrade when new upstream releases are available (and as you noted, a lot accumulated during the Freeze). Everybody's help is welcome, especially for the trivial rebuilds. We have our packages managed in Subversion and Git repository, but if this is bothering, I think that we can cut corners with a simple NMU with no changes, that will be a branch in the version tree. Also, for the architecture-dependant packages, we can request binary NMUs, although I have been reluctant to do so in order to not disturb the Release team. For ggplot2, we are working on the update (#700862), but it needs the introduction of new packages (r-cran-gtable, accepted this week, and r-cran-scales, to be uploaded). For the short term, I just uploaded a NMU to rebuild the package. Have a nice Sunday, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130414083639.gc13...@falafel.plessy.net
Further Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p | grep Maintainer | \
sed -e 's/.*//' -e 's/$//'; done | \
awk -F, '/^r-/ {print $2,$1}' | sort
debian-med-packag...@lists.alioth.debian.org r-bioc-cummerbund
debian-med-packag...@lists.alioth.debian.org r-bioc-edger
debian-med-packag...@lists.alioth.debian.org r-bioc-hilbertvis
debian-med-packag...@lists.alioth.debian.org r-bioc-limma
debian-med-packag...@lists.alioth.debian.org r-bioc-qvalue
debian-med-packag...@lists.alioth.debian.org r-cran-combinat
debian-med-packag...@lists.alioth.debian.org r-cran-deal
debian-med-packag...@lists.alioth.debian.org r-cran-diagnosismed
debian-med-packag...@lists.alioth.debian.org r-cran-dichromat
debian-med-packag...@lists.alioth.debian.org r-cran-epi
debian-med-packag...@lists.alioth.debian.org r-cran-epibasix
debian-med-packag...@lists.alioth.debian.org r-cran-epicalc
debian-med-packag...@lists.alioth.debian.org r-cran-epir
debian-med-packag...@lists.alioth.debian.org r-cran-epitools
debian-med-packag...@lists.alioth.debian.org r-cran-evd
debian-med-packag...@lists.alioth.debian.org r-cran-genabel
debian-med-packag...@lists.alioth.debian.org r-cran-genetics
debian-med-packag...@lists.alioth.debian.org r-cran-ggplot2
debian-med-packag...@lists.alioth.debian.org r-cran-haplo.stats
debian-med-packag...@lists.alioth.debian.org r-cran-labeling
debian-med-packag...@lists.alioth.debian.org r-cran-psy
debian-med-packag...@lists.alioth.debian.org r-cran-pvclust
debian-med-packag...@lists.alioth.debian.org r-cran-randomforest
debian-med-packag...@lists.alioth.debian.org r-cran-reshape2
debian-med-packag...@lists.alioth.debian.org r-cran-rocr
debian-med-packag...@lists.alioth.debian.org r-cran-stringr
debian-med-packag...@lists.alioth.debian.org r-other-mott-happy
debian-science-maintain...@lists.alioth.debian.org r-cran-amore
debian-science-maintain...@lists.alioth.debian.org r-cran-msm
debian-science-maintain...@lists.alioth.debian.org r-cran-plotrix
debian-science-maintain...@lists.alioth.debian.org r-cran-sp
debian-science-maintain...@lists.alioth.debian.org r-cran-spc
debian-science-maintain...@lists.alioth.debian.org r-cran-teachingdemos
debian-science-maintain...@lists.alioth.debian.org r-cran-vcd
debian-science-maintain...@lists.alioth.debian.org r-cran-xtable
debichem-de...@lists.alioth.debian.org r-cran-maldiquant
debichem-de...@lists.alioth.debian.org r-cran-readbrukerflexdata
i...@maintz.de r-cran-gtable
lawre...@debian.org r-cran-pscl
root@max:/#
I would be really terrific if the the debian-med, debian-science, debichem
teams could update some of these packages.
Charles, failing that, shall we coordinate off-list? Re-building in chroot
takes about a minute or two each but sadly some of these package appear
effectively orphaned (eg gpplot2, single upload 15 months ago -- is that
really work done to Debian standards?)
Dirk
[1] I filtered out things like littler (works fine with R 3.0.0),
python-nwsserver (uses pipes, is fine too) and postgresql-9.1-plr which I
suspect is fine just like littler is.
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20841.26909.357993.896...@max.nulle.part
Re: Further Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/13/2013 04:18 PM, Dirk Eddelbuettel wrote:
So here is where we stand, with little improvement from last week: [1]
root@max:/# for p in `apt-cache showpkg r-base-core | \
grep r-base-core 2 | sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p | grep Maintainer | \
sed -e 's/.*//' -e 's/$//'; done | \
awk -F, '/^r-/ {print $2,$1}' | sort
debian-med-packag...@lists.alioth.debian.org r-bioc-cummerbund
debian-med-packag...@lists.alioth.debian.org r-bioc-edger
debian-med-packag...@lists.alioth.debian.org r-bioc-hilbertvis
debian-med-packag...@lists.alioth.debian.org r-bioc-limma
debian-med-packag...@lists.alioth.debian.org r-bioc-qvalue
debian-med-packag...@lists.alioth.debian.org r-cran-combinat
debian-med-packag...@lists.alioth.debian.org r-cran-deal
debian-med-packag...@lists.alioth.debian.org r-cran-diagnosismed
debian-med-packag...@lists.alioth.debian.org r-cran-dichromat
debian-med-packag...@lists.alioth.debian.org r-cran-epi
debian-med-packag...@lists.alioth.debian.org r-cran-epibasix
debian-med-packag...@lists.alioth.debian.org r-cran-epicalc
debian-med-packag...@lists.alioth.debian.org r-cran-epir
debian-med-packag...@lists.alioth.debian.org r-cran-epitools
debian-med-packag...@lists.alioth.debian.org r-cran-evd
debian-med-packag...@lists.alioth.debian.org r-cran-genabel
debian-med-packag...@lists.alioth.debian.org r-cran-genetics
debian-med-packag...@lists.alioth.debian.org r-cran-ggplot2
debian-med-packag...@lists.alioth.debian.org r-cran-haplo.stats
debian-med-packag...@lists.alioth.debian.org r-cran-labeling
debian-med-packag...@lists.alioth.debian.org r-cran-psy
debian-med-packag...@lists.alioth.debian.org r-cran-pvclust
debian-med-packag...@lists.alioth.debian.org r-cran-randomforest
debian-med-packag...@lists.alioth.debian.org r-cran-reshape2
debian-med-packag...@lists.alioth.debian.org r-cran-rocr
debian-med-packag...@lists.alioth.debian.org r-cran-stringr
debian-med-packag...@lists.alioth.debian.org r-other-mott-happy
debian-science-maintain...@lists.alioth.debian.org r-cran-amore
debian-science-maintain...@lists.alioth.debian.org r-cran-msm
debian-science-maintain...@lists.alioth.debian.org r-cran-plotrix
debian-science-maintain...@lists.alioth.debian.org r-cran-sp
debian-science-maintain...@lists.alioth.debian.org r-cran-spc
debian-science-maintain...@lists.alioth.debian.org r-cran-teachingdemos
debian-science-maintain...@lists.alioth.debian.org r-cran-vcd
debian-science-maintain...@lists.alioth.debian.org r-cran-xtable
debichem-de...@lists.alioth.debian.org r-cran-maldiquant
debichem-de...@lists.alioth.debian.org r-cran-readbrukerflexdata
i...@maintz.de r-cran-gtable
lawre...@debian.org r-cran-pscl
root@max:/#
Cool, considering the deep freeze...
Anton
signature.asc
Description: OpenPGP digital signature
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
2013/4/9 Thomas Goirand z...@debian.org: If I upload new packages A and B, that A depends and B, and that A gets approved, but B doesn't, then we end up with package A being in Debian, but never installable. That is unlikely to happen: dak has a colour scheme to identify missing packages. It's also nice to identify packages who belong in main, contrib, and non-free, just to avoid component mismatches. Now, if what you are suggesting that I should wait for B to be approved before uploading A, I think you aren't being realistic when the NEW queue has a 3 months waiting time. This might work with small projects, but if you have to maintain a complex set of packages, with lots of dependencies, it just doesn't work. Been there, tried that ... Uploading packages in NEW which depend on other packages in NEW is fine, as explained above. Dependencies will be reviewed first, and when accepted, the other packages will be processed as well. The major difficulty happens when the dependency chain is very complex (e.g. A - B - C - D - E - A), in that case it would help if maintainers suggested the order in which to review packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadk7b0of088feo66cypo-8crkrrsyd5bma49oe-twf8tx71...@mail.gmail.com
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Wed, Apr 10, 2013 at 02:52:20AM +0800, Thomas Goirand wrote: If I upload new packages A and B, that A depends and B, and that A gets approved, but B doesn't, then we end up with package A being in Debian, but never installable. Has this ever happened? I believe the FTP masters do look at dependencies of packages in NEW to prevent this situation. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130410084319.GA3103@debian
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/03/2013 04:34 AM, Thomas Goirand wrote: On 04/01/2013 11:06 PM, Luca Falavigna wrote: On the other hand, FTP Team is willing to fast-track NEW packages anytime, if needed. That's simply not truth. I can't let you say that and not reply. Hi, I would like to publicly thanks Luca for all the FTP Master assistant work that he did on the Openstack packages recently. Nearly all of the Openstack packages have been approved, and now I'm down to python-pecan and websockify, which have been rejected, for very valid reasons, with 2 or 3 files that are sourceless. I'll work on them, and create a DFSG version, hoping that I can finish the work before the next week Openstack summit. Saying well, all is done but it's waiting FTP masters approval is really not the same as saying well, yeah, everything is now in Debian !!! This was a very frustrating situation a week ago, and what just happened fills me with a lot of satisfaction. I am really convince that your work will really make a difference next week, when we will discuss with Ubuntu guys, and try to convince everyone that Debian is also a good platform for Openstack. So again, thanks so much Luca! Thomas P.S: I'm unsure if I'll upload all of Grizzly this week to Experimental or what, if I can fix python-pecan and websockify... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51641476.3050...@debian.org
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Tue, Apr 9, 2013 at 3:15 PM, Thomas Goirand z...@debian.org wrote: On 04/03/2013 04:34 AM, Thomas Goirand wrote: On 04/01/2013 11:06 PM, Luca Falavigna wrote: On the other hand, FTP Team is willing to fast-track NEW packages anytime, if needed. That's simply not truth. I can't let you say that and not reply. So again, thanks so much Luca! +1 Thanks Luca for your careful review, you manage to still catch glitch in packages while under pressure ! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUsz2gqwY2sa2=823cn6eqc5c052ruxsdbhb0x1rsx+o...@mail.gmail.com
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 02.04.2013 22:48, Thomas Goirand wrote: On 04/02/2013 12:16 AM, Luca Falavigna wrote: In a perfect world there wouldn't be any need for a NEW queue at all. But we have to face with the reality. We try to do our best to improve things where we can. From the FTP Team side, we always try to be quick and helpful with our fellow developers, and are happy to hear about suggestions how to improve further. I got a bunch of suggestions... Suggestion #1: if a package stays more than a month in the NEW queue, then it gets automatically approved, and may be reviewed later on. My reasoning is that more than a month, it can become really problematic and blocks development. No. Go back to start and learn why there is a NEW queue. Suggestion #2: get rid of the new binary queue (not new source package, that's different). There's no reason why the licensing of a package changes just because the maintainer decides to add a new binary, so it makes no sense. This would save a lot of time for the FTP team. No. Go back to start and learn why there is a NEW queue. Suggestion #3: have a system where any other DD can review a package in the NEW queue, not only the FTP masters or the FTP assistants. That would include publishing the contents of the NEW queue, at least to all Debian Developers - so we might violate licenses already. Suggestion #4: recognized that the FTP team needs to work faster, and get more people in the FTP team. When did you read the last announce mail from the FTP team? They always look for people to join. But it is a lot of work, so rarely people like to join. Or they don't get into the team because they fail to understand what they have to take care of. So when did you offer yourself to join the FTP team? Suggestion #5: make it so that a bunch of packages can be reviewed together, as they might depend on each other, and we would like to avoid cases where some packages are accepted, but can't be installed because their dependencies are in NEW. And that breaks exactly what? Such a package will never migrate to testing. No harm done. Also you might want to avoid to depend on packages not yet in Debian as they might never end up in Debian at all. Suggestion #6: get rid of the NEW queue completely. I'm not the only one that thinks it should be like that, and that the licensing review process could happen after packages are accepted. Maybe though, I'll be the only one saying it out loud (but I'm getting used to it...). No. Go back to start and learn why there is a NEW queue. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3f9836d48fe7ac1b5f0d254d3266c...@mail.recluse.de
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/09/2013 11:54 PM, Bernd Zeimetz wrote: So when did you offer yourself to join the FTP team? I didn't offer to completely join forever, but I offered my help, few months ago. Though considering the mistakes I did in the past (and still do from time to time, despite my (probably wrong) feeling to do double-checks), I do understand why they didn't feel comfortable with me checking for licenses. On 04/09/2013 11:54 PM, Bernd Zeimetz wrote: Suggestion #2: get rid of the new binary queue (not new source package, that's different). There's no reason why the licensing of a package changes just because the maintainer decides to add a new binary, so it makes no sense. This would save a lot of time for the FTP team. No. Go back to start and learn why there is a NEW queue. No what? To which part of the above? Would you care to explain, since I'm so dumb and I should learn? In what way adding lines in debian/control changes the licensing of upstream source? Suggestion #5: make it so that a bunch of packages can be reviewed together, as they might depend on each other, and we would like to avoid cases where some packages are accepted, but can't be installed because their dependencies are in NEW. And that breaks exactly what? Such a package will never migrate to testing. No harm done. Also you might want to avoid to depend on packages not yet in Debian as they might never end up in Debian at all. If I upload new packages A and B, that A depends and B, and that A gets approved, but B doesn't, then we end up with package A being in Debian, but never installable. Now, if what you are suggesting that I should wait for B to be approved before uploading A, I think you aren't being realistic when the NEW queue has a 3 months waiting time. This might work with small projects, but if you have to maintain a complex set of packages, with lots of dependencies, it just doesn't work. Been there, tried that ... Also, thinking only about testing, when we have a 10 months period of freeze, is quite crazy. So yes, harm done, even in Experimental (during the freeze)! No. Go back to start and learn why there is a NEW queue. You didn't need to repeat this sentence 3 times. I believe I know why we have it, never the less, I feel like there would be better ways to handle the problem. I'm only the vocal person here, I know I'm not the only one thinking this way. Others probably fear the reaction of the FTP masters, I personally think (and hope) they are smarter than this and accept constructive critics. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51646364.9040...@debian.org
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 09/04/13 17:54, Bernd Zeimetz wrote: On 02.04.2013 22:48, Thomas Goirand wrote: On 04/02/2013 12:16 AM, Luca Falavigna wrote: In a perfect world there wouldn't be any need for a NEW queue at all. But we have to face with the reality. We try to do our best to improve things where we can. From the FTP Team side, we always try to be quick and helpful with our fellow developers, and are happy to hear about suggestions how to improve further. I got a bunch of suggestions... Suggestion #1: if a package stays more than a month in the NEW queue, then it gets automatically approved, and may be reviewed later on. My reasoning is that more than a month, it can become really problematic and blocks development. No. Go back to start and learn why there is a NEW queue. Suggestion #2: get rid of the new binary queue (not new source package, that's different). There's no reason why the licensing of a package changes just because the maintainer decides to add a new binary, so it makes no sense. This would save a lot of time for the FTP team. No. Go back to start and learn why there is a NEW queue. That answer is not so clear Plenty of packages have evolved with new upstream releases over many years without any ongoing review by the FTP masters. I'm sure I could find one that has subsequently and inadvertently become non-free if I really looked hard enough. Why should review only take place on those packages that the maintainer chooses to modularise? Isn't it the content of the source package that needs review? Maybe the review should be triggered by some other factor? For example, every time a new upstream major release number increment occurs, the upload goes into NEW? Suggestion #3: have a system where any other DD can review a package in the NEW queue, not only the FTP masters or the FTP assistants. That would include publishing the contents of the NEW queue, at least to all Debian Developers - so we might violate licenses already. That is not a watertight argument either - it would be quite feasible to publicize the source package without making the upstream tarball public. Just make sure that other DDs can see a link to the upstream tarball on the upstream web site, and the hash from the changes file This would actually be a very good way of helping to distribute the workload of FTP masters as all DDs could presumably practice rejecting things, while the decision to accept something would remain with the FTP master. I also value the work of the FTP masters and everybody who scrutinizes packages to make sure they really are free and open. Just look at the Android market for an example of what would evolve without such efforts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516465b6.4050...@pocock.com.au
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 07.04.2013 03:07, Julian Gilbey wrote:
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
as the source package is *not* dependent upon the R version, only the
binary package resulting from it; this will aid any backporters, for
example.
No, you have to Build-Depend on the minimal R version your package needs.
A (probably bad) example: sactterelot3d needs R = 2.7.0 so my Build-Depends is:
Build-Depends: debhelper (= 9), cdbs, r-base-dev (= 2.7.0)
Philip
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/516139ab.9030...@gmx.net
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sun, Apr 07, 2013 at 11:17:31AM +0200, Philip Rinn wrote:
On 07.04.2013 03:07, Julian Gilbey wrote:
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
as the source package is *not* dependent upon the R version, only the
binary package resulting from it; this will aid any backporters, for
example.
No, you have to Build-Depend on the minimal R version your package needs.
A (probably bad) example: sactterelot3d needs R = 2.7.0 so my Build-Depends
is:
Build-Depends: debhelper (= 9), cdbs, r-base-dev (= 2.7.0)
Yes, indeed. My bad. But it does *not* need to depend on r-base-dev
(= 3.0.0) unless the package actually requires 3.0.0 functionality.
Uploading erm 0.14-0-6 with the correct build-time dependencies;
raschsampler has no specified R version dependency, so leaving that
one unspecified.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130407120102.gb25...@d-and-j.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 04/02/2013 09:18 PM, Goswin von Brederlow wrote: Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. The fact that the epoch doesn't appear in the file name is the most annoying part of it. Perhaps at some point, we could change that fact, and solve the problem, maybe for Jessie? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/516174af.4060...@debian.org
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 7 April 2013 at 13:01, Julian Gilbey wrote:
| On Sun, Apr 07, 2013 at 11:17:31AM +0200, Philip Rinn wrote:
| On 07.04.2013 03:07, Julian Gilbey wrote:
| Ah, thanks Chris, I wasn't aware of that! But then it seems to me
| that the correct lines should be:
|
| Build-Depends: ..., r-base-dev, ...
| [...]
| Depends: ..., ${R:Depends}, ...
|
| as the source package is *not* dependent upon the R version, only the
| binary package resulting from it; this will aid any backporters, for
| example.
| No, you have to Build-Depend on the minimal R version your package needs.
| A (probably bad) example: sactterelot3d needs R = 2.7.0 so my
Build-Depends is:
|
| Build-Depends: debhelper (= 9), cdbs, r-base-dev (= 2.7.0)
|
| Yes, indeed. My bad. But it does *not* need to depend on r-base-dev
| (= 3.0.0) unless the package actually requires 3.0.0 functionality.
And we really do sometimes have the superset as R also imposes. Right now
the only reason we are rebuilding is ... so that R (at run-time, when loading
the package) sees it as being produced by R (= 3.0.0).
| Uploading erm 0.14-0-6 with the correct build-time dependencies;
| raschsampler has no specified R version dependency, so leaving that
| one unspecified.
I still think that is wrong but you ipso-facto get the right thing to
happen. But for my packages, I do make this explicit.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20833.31680.984007.402...@max.nulle.part
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Holger Levsen wrote: On Montag, 1. April 2013, Steve M. Robbins wrote: Rather than accept the harm, surely the release team could simply roll back the upload in some manner? As I understand it, only by introducing an epoch in the package version. Or by using the 9.0.0+really0.99-1 version convention, which IMHO for is way better for cases of temporary backtracking like this. But in this particular case, leaving it alone in unstable would be better still. The release is not that far away, and it is not impossible to maintain packages in testing even when the package in sid has moved on. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130408053404.GA28322@elie.Belkin
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote: I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. I do not only like this but IMHO it is perfectly needed (as for any other language system we are packaging. - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. As I said previously in bug #659163 when R:Depends was introduced to regard some R api based on the expression R --version | head -n1 | perl -ne 'print / +([0-9]\.[0-9]+\.[0-9])/' which is independant from a certain package. I do regard the currently implemented solution as an unneeded restriction. Compared to the current implementation and the original suggestion in #659163 the r-api suggestion above is certainly the cleanest and best possible solution and I'm really in favour of this. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. +1 (or even +2) Let's discuss the details on #704805 In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#10 Dirk Eddelbuettel wrote: I am not (yet?) sold: -- there is only one provider or r-api-* I can not parse whether this should be a question or a problem. -- we actually do have a greater than relation This is the current implementation and this is not really helpful. -- the version numbers already solve this No, they do not. An API level is something else than a version number. -- this was needed three times in ten years There is no point in properly solving a problem only because it does not happen very frequently. It can perfectly happen that it occures in a bad timing and a clean solution is always the goal we should approach inside Debian. I think we are overengineering this. I'm in great favour of the suggestion of Charles and IMHO it is far from overengineering - just following the usual standard procedure as it is implemented in all comparable situations in Debian. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406152615.ga2...@an3as.eu
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, Apr 05, 2013 at 09:04:41PM -0500, Dirk Eddelbuettel wrote:
First off, let me apologize. I clearly did this the wrong way and should have
contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
this created for the release managers and maintainer, particularly at this
time.
R 3.0.0 was released on April 3 as scheduled. As usual, I built a package the
morning of, and all build daemons are current. (There was also an unrelated
bug which is why were at 3.0.0-2.) The release team kindly put a block on
it, so it will make it into testing. Good.
[...]
So 127 packages are already taken care of. On the other hand, we still have
~50 packages needing work:
[...]
R print(todo[ order(todo[,2]), ], row.names=FALSE)
pkg maint
r-cran-erm j...@debian.org
r-cran-raschsampler j...@debian.org
I uploaded these to unstable on Friday lunchtime, and they were
accepted into unstable on Friday afternoon; I'm unclear why they are
still in your list? Did I do something wrong?
Oh yes, I clearly did. Even though I built it in a chroot with
r-base-dev 3.0.0-2 installed, I forgot to update the Depends lines in
the control files.
So something doesn't make sense somewhere: if my package doesn't care
which version of R it's building against, but R itself cares, then
surely there should be some way of querying r-base-dev during the
build process to enquire which version is required? It is almost
certainly too late to do anything about this for wheezy, but it would
be good to think about doing something for wheezy+1. Ideally, this
would be by creating a misc substvar so that instead of having to
specify the version of r-base-core in the Depends: field, it could be
specified just as ${misc:Depends} and then filled in automatically.
Anyway, I'm rebuilding them now with the dependencies updated to
3.0.0-2.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130406205527.gb32...@d-and-j.net
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey j...@debian.org wrote:
So something doesn't make sense somewhere: if my package doesn't care
which version of R it's building against, but R itself cares, then
surely there should be some way of querying r-base-dev during the
build process to enquire which version is required? It is almost
certainly too late to do anything about this for wheezy, but it would
be good to think about doing something for wheezy+1. Ideally, this
would be by creating a misc substvar so that instead of having to
specify the version of r-base-core in the Depends: field, it could be
specified just as ${misc:Depends} and then filled in automatically.
If you're using cdbs and r-cran.mk in debian/rules, you can add
Depends: ${R:Depends} to debian/control to pick up the current binary
dependency. I've migrated almost all of my packages over and it makes
life easier.
Probably down the road it'd be good to create some lintian checks for
things like this dependency. (The holy grail would be to verify build
dependencies and binary dependencies against the upstream
DESCRIPTION.)
Chris
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/canjczgjhpisu3aznvcgopavjqftofp12hn+4pqyc2m4thds...@mail.gmail.com
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 6 April 2013 at 19:30, Chris Lawrence wrote:
| On Sat, Apr 6, 2013 at 4:55 PM, Julian Gilbey j...@debian.org wrote:
| So something doesn't make sense somewhere: if my package doesn't care
| which version of R it's building against, but R itself cares, then
| surely there should be some way of querying r-base-dev during the
| build process to enquire which version is required? It is almost
| certainly too late to do anything about this for wheezy, but it would
| be good to think about doing something for wheezy+1. Ideally, this
| would be by creating a misc substvar so that instead of having to
| specify the version of r-base-core in the Depends: field, it could be
| specified just as ${misc:Depends} and then filled in automatically.
|
| If you're using cdbs and r-cran.mk in debian/rules, you can add
| Depends: ${R:Depends} to debian/control to pick up the current binary
| dependency. I've migrated almost all of my packages over and it makes
| life easier.
Right. What Chris said. This is something Andreas and Charles have pushed
for and which most of the 150+ r-cran-packages now use. One example from one
of my 100-ish r-cran-* packages:
Build-Depends: debhelper (= 7), r-base-dev (= 3.0.0), cdbs
[...]
Depends: ${shlibs:Depends}, ${R:Depends}
The Build-Depends: edit is manual.
The one in Depends: no longer is. That is useful.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20832.49748.764779.43...@max.nulle.part
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 6 April 2013 at 21:55, Julian Gilbey wrote:
| R print(todo[ order(todo[,2]), ], row.names=FALSE)
| pkg
maint
| r-cran-erm
j...@debian.org
| r-cran-raschsampler
j...@debian.org
|
| I uploaded these to unstable on Friday lunchtime, and they were
| accepted into unstable on Friday afternoon; I'm unclear why they are
| still in your list? Did I do something wrong?
|
| Oh yes, I clearly did. Even though I built it in a chroot with
| r-base-dev 3.0.0-2 installed, I forgot to update the Depends lines in
| the control files.
|
| So something doesn't make sense somewhere: if my package doesn't care
| which version of R it's building against, but R itself cares, then
| surely there should be some way of querying r-base-dev during the
Dunno -- we only have one r-base-core / r-base-dev. I think if you had
updated you pbuilder chroot, you would have gotten the new R -- satisfying
both the Depends you had, and the Depends you should have had.
| build process to enquire which version is required? It is almost
| certainly too late to do anything about this for wheezy, but it would
| be good to think about doing something for wheezy+1. Ideally, this
| would be by creating a misc substvar so that instead of having to
| specify the version of r-base-core in the Depends: field, it could be
| specified just as ${misc:Depends} and then filled in automatically.
If someone could contribute this...
| Anyway, I'm rebuilding them now with the dependencies updated to
| 3.0.0-2.
Thanks.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20832.49579.180499.982...@max.nulle.part
Re: Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Sat, Apr 06, 2013 at 07:48:20PM -0500, Dirk Eddelbuettel wrote:
| If you're using cdbs and r-cran.mk in debian/rules, you can add
| Depends: ${R:Depends} to debian/control to pick up the current binary
| dependency. I've migrated almost all of my packages over and it makes
| life easier.
Right. What Chris said. This is something Andreas and Charles have pushed
for and which most of the 150+ r-cran-packages now use. One example from one
of my 100-ish r-cran-* packages:
Ah, cool!
Build-Depends: debhelper (= 7), r-base-dev (= 3.0.0), cdbs
[...]
Depends: ${shlibs:Depends}, ${R:Depends}
The Build-Depends: edit is manual.
The one in Depends: no longer is. That is useful.
Ah, thanks Chris, I wasn't aware of that! But then it seems to me
that the correct lines should be:
Build-Depends: ..., r-base-dev, ...
[...]
Depends: ..., ${R:Depends}, ...
as the source package is *not* dependent upon the R version, only the
binary package resulting from it; this will aid any backporters, for
example.
Julian
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130407010724.ga24...@d-and-j.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote: A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual according the the release plan and announcements [1]. It contains major internal changes [2] and requires rebuilds of all R packages. As I usually do, I started packaging pre-releases and rc candidates [3] based on March 24, 27 and 30 snapshots. Michael Rutter, who tirelessly backports (most of) my Debian R packages to Ubuntu, has also made builds of these R packages [4]. As for unstable, we have an issue as essentially all reverse-dependencies that are R packages will need to be rebuilt [5]. On testing, I get for 158 packages from `apt-cache rdepends r-base-core | grep -c r-cran-`. I am a little unclear what is required; is a binary rebuild sufficient, or is some change in the source code necessary? If the former, would it not be better just to ask the buildd administrators for a binary rebuild as opposed to having a new source version just for this? Julian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405075352.gc6...@d-and-j.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le Fri, Apr 05, 2013 at 08:53:52AM +0100, Julian Gilbey a écrit : On Sun, Mar 31, 2013 at 11:45:15AM -0500, Dirk Eddelbuettel wrote: I am a little unclear what is required; is a binary rebuild sufficient, or is some change in the source code necessary? If the former, would it not be better just to ask the buildd administrators for a binary rebuild as opposed to having a new source version just for this? Hi Julian, for architecture-dependant packages, a binary rebuild is sufficient. For arch-independant packages, this facility is not available. In addition, with the Freeze, many of us had refrained from updating their packages, so this need for rebuilds is a good opportunity for update now that the relase is getting near. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130405081019.ga32...@falafel.plessy.net
Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
Guillem Jover writes (Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)): Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). I agree entirely with what Guillem says. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. I wonder if this should be explicitly stated in the dev ref. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20830.48911.568030.146...@chiark.greenend.org.uk
Update on R 3.0.0 migration (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
First off, let me apologize. I clearly did this the wrong way and should have
contacted -release and -devel beforehand. My bad -- I'm sorry for extra work
this created for the release managers and maintainer, particularly at this
time.
R 3.0.0 was released on April 3 as scheduled. As usual, I built a package the
morning of, and all build daemons are current. (There was also an unrelated
bug which is why were at 3.0.0-2.) The release team kindly put a block on
it, so it will make it into testing. Good.
Preceding the release and following it, we have rebuilt the vast number of
r-cran-* packages used my R, and which do need a rebuild, plus a few
building against R such as python-rpy. Currently, in my unstable pbuilder
chroot (and thanks to Chris for the showpkg trick)
root@max:/# apt-cache showpkg r-base-core | grep r-base-core 3 | wc -l
127
So 127 packages are already taken care of. On the other hand, we still have
~50 packages needing work:
root@max:/# apt-cache showpkg r-base-core | grep r-base-core 2 | wc -l
52
A few of these are false positives though. Looking more closely via
root@max:/# for p in `apt-cache showpkg r-base-core | grep r-base-core 2 |
sort | awk -F, '{print $1}'`; \
do echo -n $p,; apt-cache show $p | grep Maintainer | sed -e
's/.*//' -e 's/$//'; done
gets us a nice little csv data set we can print in R:
R print(todo[ order(todo[,2]), ], row.names=FALSE)
pkg maint
r-bioc-biobase debian-med-packag...@lists.alioth.debian.org
r-bioc-biocgenerics debian-med-packag...@lists.alioth.debian.org
r-bioc-cummerbund debian-med-packag...@lists.alioth.debian.org
r-bioc-edger debian-med-packag...@lists.alioth.debian.org
r-bioc-hilbertvis debian-med-packag...@lists.alioth.debian.org
r-bioc-limma debian-med-packag...@lists.alioth.debian.org
r-bioc-qvalue debian-med-packag...@lists.alioth.debian.org
r-cran-combinat debian-med-packag...@lists.alioth.debian.org
r-cran-deal debian-med-packag...@lists.alioth.debian.org
r-cran-diagnosismed debian-med-packag...@lists.alioth.debian.org
r-cran-epi debian-med-packag...@lists.alioth.debian.org
r-cran-epibasix debian-med-packag...@lists.alioth.debian.org
r-cran-epicalc debian-med-packag...@lists.alioth.debian.org
r-cran-epir debian-med-packag...@lists.alioth.debian.org
r-cran-epitools debian-med-packag...@lists.alioth.debian.org
r-cran-evd debian-med-packag...@lists.alioth.debian.org
r-cran-genabel debian-med-packag...@lists.alioth.debian.org
r-cran-genetics debian-med-packag...@lists.alioth.debian.org
r-cran-ggplot2 debian-med-packag...@lists.alioth.debian.org
r-cran-haplo.stats debian-med-packag...@lists.alioth.debian.org
r-cran-psy debian-med-packag...@lists.alioth.debian.org
r-cran-pvclust debian-med-packag...@lists.alioth.debian.org
r-cran-randomforest debian-med-packag...@lists.alioth.debian.org
r-cran-reshape debian-med-packag...@lists.alioth.debian.org
r-cran-reshape2 debian-med-packag...@lists.alioth.debian.org
r-cran-rocr debian-med-packag...@lists.alioth.debian.org
r-cran-rsqlite debian-med-packag...@lists.alioth.debian.org
r-cran-stringr debian-med-packag...@lists.alioth.debian.org
r-cran-vegan debian-med-packag...@lists.alioth.debian.org
r-other-bio3d debian-med-packag...@lists.alioth.debian.org
r-other-mott-happy debian-med-packag...@lists.alioth.debian.org
r-cran-amore debian-science-maintain...@lists.alioth.debian.org
r-cran-msm debian-science-maintain...@lists.alioth.debian.org
r-cran-plotrix debian-science-maintain...@lists.alioth.debian.org
r-cran-sp debian-science-maintain...@lists.alioth.debian.org
r-cran-spc debian-science-maintain...@lists.alioth.debian.org
r-cran-teachingdemos debian-science-maintain...@lists.alioth.debian.org
r-cran-vcd debian-science-maintain...@lists.alioth.debian.org
r-cran-xtable debian-science-maintain...@lists.alioth.debian.org
r-cran-maldiquant debichem-de...@lists.alioth.debian.org
r-cran-readbrukerflexdata debichem-de...@lists.alioth.debian.org
littler e...@debian.org
python-nwsserver e...@debian.org
r-cran-gregmisc
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit : Depends: r-base-core (= 3.0.0~20130327) , r-base-core ( 4) or you could have an API virtual package: r-base-api-3.0 Hi Dirk and everybody, since we already have a substitution variable in most of the R packages (R:Depends), I think that we can use it to address the problem. First, let's define the problem: R broke backwards compatibility a couple of times since it has been packaged. Rebuilding packages is usually done swiftly, but there remains the problem of transitions to Testing and updates on the users computers. There is usually a gap of some years between breakages, so we do not want an over-engeneered solution. I like the idea of an api virtual package, as it requires little work from the parties involved and solves most of the problem. (The exception being that partial upgrades from Wheezy to Jessie will not be supported, but this is also the case in the current situation). - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces the R:Depends substitution variable, would make packages depend on the r-api virtual package instead of requiring a version equal or superior to the version of r-base-core used at build time. - Next time R breaks backwards compatibility, Dirk would need to modify the Provides: line in debian/control and voilà, the new R core package can not be installed on a system without removing or upgrading the R library packages that were built with the old API. Let's discuss the details on #704805 Have a nice week-end, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130406040849.gd22...@falafel.plessy.net
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
]] Vincent Lefevre On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Sometimes, they do, and except during this last stage of the freeze, it's not been particularly hard to get bug fixes into wheezy. As I have written elsewhere, I've had unblock requests go through less than five minutes after I filed the request. It's a little bit of extra book-keeping, sure, but it's not very onerous. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ip42vlay@qurzaw.varnish-software.com
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote: It seems that most reverse dependencies for iceweasel are l10n packages and extensions, so that one can consider them as part of the upgrade. The remaining dependencies seem to have a form like iceweasel | www-browser. So, what would be wrong? That the extensions also need to be updated, for the very least. Not also that in practice, many (most?) users will use a backport. So, if some real reverse dependency would be affected by a change in the iceweasel version, it rather needs to be fixed now. I presume most users of a backport don't use packaged extensions at all. I mean the update of the package in testing. A RC bug is a way to block transitions from happening there; a freeze is not needed. Multiple transitions then get entangled. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-04 16:23:33 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 10:29:26PM +0200, Vincent Lefevre wrote: It seems that most reverse dependencies for iceweasel are l10n packages and extensions, so that one can consider them as part of the upgrade. The remaining dependencies seem to have a form like iceweasel | www-browser. So, what would be wrong? That the extensions also need to be updated, for the very least. If they are really maintained, they should probably have been updated already (that's one way to make sure that security fixes are applied). Otherwise it would be better to drop them. Not also that in practice, many (most?) users will use a backport. So, if some real reverse dependency would be affected by a change in the iceweasel version, it rather needs to be fixed now. I presume most users of a backport don't use packaged extensions at all. I wonder whether there are packaged extensions (and whether they could conflict with extensions installed by the user). Automatic handling by Firefox/Iceweasel works well. I mean the update of the package in testing. A RC bug is a way to block transitions from happening there; a freeze is not needed. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404151454.gn31...@xvii.vinc17.org
Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Wed, 2013-04-03 at 20:18:44 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote: On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. Which is a new custom that comes from Ubuntu who cannot reasonably use epochs. We can. Well, I strongly disagree that in general using epochs for packaging mistakes is a good practice (and I've thought so even before Ubuntu existed). The main purpose of epochs is to be able to handle mistakes or changes in the version numbering itself. Say upstream resets their versioning from v450 to 0.0.0, or from date based 20130404 to 0.0.0 (although the packager could have avoided that by prefixing with 0.), or if they used something like 1.210 and they meant 1.2.10 (svgalib), or a package takes over another's name (git). Epochs are a necessary evil, but they are distracting and clutter the version string, and if they can be avoided (by way of a 2really1 scheme) then IMO that should be prefered, beucase that's just temporary, usually until next Debian release. Also as it can be seen on the archive, once a version has been tainted (!?), uploaders tend to lower their resistance to increase the epoch even further. Also, introducing an epoch where there was none in an NMU should be frowned upon, unfortunately I've seen multiple instances of these in the recent past, something I'd be very upset if it happened to any of the packages I maintain. Something else I disagree is good practice is bumping an epoch to win the automatic upgradability against a downstream distribution version or 3rd-party package repository, because that makes us dependant on their practices. Some recentish examples of what _seems_ like gratuituous epoch introduction (there's probably many others): audit (NMU upload revert) clang (NMU upload revert, although with maintainer approval, because supposedly the package will get merged into llvm, but that only holds as long as the clang package disappears) file (NMU upload revert) fonts-ipafont-nonfree-jisx0208 (just for a tarball repack) ppl (no clear reason from the changelog?) usbutils (simply switching from 0.87 to 001 would have been fine) Not to mention things like fonts-sil-gentium with its date-base epoch. Something people seem to forget or be unware of, is that binary packages can contain a different version than the source they come from, so if you really need to bump the epoch for (say) a shared library package, you could do it just for that one, which would disappear when changing package name on the next SOVERSION bump. Or that when renaming the source and package names the epoch can be reset. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404180927.ga31...@gaara.hadrons.org
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Thu, Apr 04, 2013 at 08:09:27PM +0200, Guillem Jover wrote: Also as it can be seen on the archive, once a version has been tainted (!?), uploaders tend to lower their resistance to increase the epoch even further. But once an epoch has been added, there is (arguably?) no problems with increasing it further. -- WBR, wRAR signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Thu, Apr 04, 2013 at 05:14:54PM +0200, Vincent Lefevre wrote: I wonder whether there are packaged extensions […] So you didn't actually look. EOT from me, it's wasting my time. Multiple transitions then get entangled. I don't understand what you mean here. The freeze doesn't prevent that from happening in unstable. Our current freeze rules that apply to unstable prevent that in a social, not technical way. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Epoch usage conventions (was Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Fri, Apr 05, 2013 at 01:00:52AM +0600, Andrey Rahmatullin wrote: But once an epoch has been added, there is (arguably?) no problems with increasing it further. You're not really increasing ugliness in that case, but you are still screwing with any extant versioned relationships. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404210243.ga2...@scru.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 13:37:59 -0500, Peter Samuelson wrote: [Vincent Lefevre] I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. Agreed: in July 2012, many - too many - RC bugs were already open. So when, in your estimation, would have been a better time to freeze? It depends on the rate these RC bugs are fixed. Only RC bugs affecting testing should be considered here. The question is then: were there many bugs affecting testing? If yes, why? Isn't the goal of unstable to detect RC bugs (in particular) before packages enter testing? If this fails too often, then something is wrong here. Moreover, perhaps there should be different steps in the freeze. Packages with a good history w.r.t. RC bugs (e.g. no RC bugs, or RC bugs quickly fixed) should not be concerned by an initial freeze. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403091430.gi31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. -- WBR, wRAR signature.asc Description: Digital signature
CUT and stable releases Was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2013-04-02 at 17:24 +0100, Adam D. Barratt wrote: On 02.04.2013 16:35, Svante Signell wrote: The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: That's a contentious definition of best. You also appear to have somewhat missed the point of my response to that original message, i.e. URL:http://lists.debian.org/debian-devel/2013/01/msg00274.html As I replied to you in http://lists.debian.org/debian-devel/2013/01/msg00275.html I did _not_ propose to remove testing! i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. I'm still struggling to see how this is fundamentally different from the frozen suite which testing was introduced to replace, more than a dozen years ago. As per my earlier message referenced above, see URL:http://lists.debian.org/debian-devel/2000/08/msg00906.html for some detail of why frozen didn't work. It's not fundamentally different, but still different. And we can easily achieve CUT too, see below :) As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. FSVO new. I think it is new in the sense it adds a new dimension to the problem. I'm repeating the proposal again here, a little differently compared to before: t is current time. dt is the delay for packages to go from unstable to testing. T0 is the time for a freeze leading to next release. dT is the time from freeze to next stable release. T1 is the time the last stable release was made. RC0, RC1, ... are release candidates for next stable. - experimental: as before: experimental(t) - unstable: never frozen = unstable(t): Here we have the CUT :) And packahing of new upstream releases are not hindered by the freeze period. - testing: Case 1) No release: testing(t) = unstable(t-dt) Case 2) Release: testing(T0) = new archive called e.g. next_release_RC0, then RC1, ... until the last RC bug has been squeezed out leading to next stable. - stable: Case 1: No release: stable(t) = previous_release(T1) (of course with security updates, etc.) Case 2: Release: stable(t) = testing(T0+dT) (see above). Of course a lot of details have to be squeezed out but the above covers the main idea. What do you think? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364984364.4439.24.ca...@amd64.my.own.domain
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 09:50:23 -0700, Russ Allbery wrote: Vincent Lefevre vinc...@vinc17.net writes: There are various problems with experimental, in particular dependencies are not necessarily listed, Huh? I have no clue what you could possibly be talking about, unless you're just saying that some packages in experimental are critically buggy. This was said in some Debian mailing-list. Not sure whether this is done on purpose or this was meant to be a bug. and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). This is a bizarre statement to me. Why would you not take that into account as a maintainer? I always have for everything I've uploaded to experimental. IIRC, this was about a package that took care of an upgrade in its postinst script (something like that), but the maintainer didn't consider upgrade from experimental versions. There was also this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544480 which was closed immediately (and has never been fixed), just because some package from experimental was installed. The user is required to correct the installation manually. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403110705.gj31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 21:53:08 +0200, Philipp Kern wrote: Vincent, am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben: I don't think that the status even of a big package like iceweasel is satisfactory. I pretty much agree. But what's the problem here? That xulrunner and iceweasel have rdeps in the archive that aren't necessarily compatible with a new version of iceweasel and hence introducing yet another transition whenever the targeted release changes. I suppose that iceweasel could be built against the libraries from testing. Then AFAIK, there remains a few rdeps problems, concerning libmozjs and xulrunner (which must match the iceweasel version), but this can be resolved by having both versions installed (this is possible). Having different versions of some libs installed at the same time may not really be satisfactory, but a very old version of iceweasel is worse, IMHO. And concerning transitions, you don't need a freeze to block them. As if it would be that easy. c.f. R, which this thread is about and which didn't change any package name. You can see that concerning R, the freeze was pretty useless to avoid some problems. Now, the freeze only concerns testing. And it is easy to prevent packages from migrating to testing. A spurious RC bug is a solution. There is no need to freeze *all* the packages. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403112858.gk31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 09:48:34 -0700, Russ Allbery wrote: Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). I don't see how that makes the graph meaningless. One of the points of a freeze is that we stop doing new transitions; in fact, that's one of the painful parts that everyone complaints about. How do you plan on keeping transitions from introducing new RC bugs without freezing? Transitions can occur in unstable. But their migration to testing would be blocked. This doesn't need a freeze. This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Of course. And the only thing that we've ever managed to do to get that behavior change is to freeze. If you could get everyone to work on RC bugs outside of a freeze so that the RC bug count doesn't spike and then grow continuously every time we unfreeze, then indeed we would have a much nicer release process. Past experience tells us that's Hard; people work on RC bugs during the freeze and not to the same degree outside of the freeze. Perhaps some kind of freeze should occur earlier, i.e. when RC bugs start to become high, and unfreeze when the number of RC bugs is low enough. But I think one needs to differentiate: * RC bugs in testing and RC bugs in unstable only; * RC bugs from upstream (which shouldn't require much work from Debian if upstream is active) and Debian-specific RC bugs. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages Which collectively amount to probably 75% of the archive, since among other things that includes pretty much any package that uses a shared library. I don't understand what you mean here. If you mean that a shared library is breaking many packages, then such a bug should be fixed ASAP or the version should be reverted until the bug is fixed. The package wouldn't probably have the time to migrate to testing anyway. and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) New transitions should be rejected in some other way, not by freezing all the packages. and because more people actually work on RC bugs during a freeze. Then perhaps call it a RC big fix period, where people should work on RC bugs, but blocking new packages that fix bugs to experimental or unstable is not a solution in particular if the freeze lasts a long time. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403120812.gl31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403121222.gm31...@xvii.vinc17.org
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
The NEW queue is not just for double-checking licenses. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013040318.GB11273@debian
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On Wed, Apr 03, 2013 at 03:44:48PM +0100, Jonathan Dowland wrote: The NEW queue is not just for double-checking licenses. But it should be. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403144646.ga20...@scru.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote: On 2013-04-02 21:06:30 +0200, Tollef Fog Heen wrote: Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Case in point: http://www.h-online.com/open/news/item/Security-updates-break-ownCloud-installations-1834507.html We know from some projects that they have regression testing we deem sufficient to trust that assertion. But I'm not sure it's generally true. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote: I pretty much agree. But what's the problem here? That xulrunner and iceweasel have rdeps in the archive that aren't necessarily compatible with a new version of iceweasel and hence introducing yet another transition whenever the targeted release changes. I suppose that iceweasel could be built against the libraries from testing. Then AFAIK, there remains a few rdeps problems, concerning libmozjs and xulrunner (which must match the iceweasel version), but this can be resolved by having both versions installed (this is possible). I said rdeps. Packages that depend on iceweasel and xulrunner. While the latter is coinstallable, the former is not. And concerning transitions, you don't need a freeze to block them. As if it would be that easy. c.f. R, which this thread is about and which didn't change any package name. You can see that concerning R, the freeze was pretty useless to avoid some problems. Now, the freeze only concerns testing. And it is easy to prevent packages from migrating to testing. A spurious RC bug is a solution. I interpreted your argument as being different: They should normally be detected when the package is uploaded in unstable. And concerning transitions, you don't need a freeze to block them. Hence yes, we could block packages in unstable from being updated. Transitions also happen for unstable which cause temporary uninstallability, so I'm not sure what block you're talking about then. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Wed, Apr 03, 2013 at 03:33:30PM +0600, Andrey Rahmatullin wrote: On Tue, Apr 02, 2013 at 09:55:09PM +0200, Philipp Kern wrote: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. It seems we usually upload a 2really1 package to fix that particular mistake without introducing an epoch. Which is a new custom that comes from Ubuntu who cannot reasonably use epochs. We can. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-03 20:14:32 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 02:12:22PM +0200, Vincent Lefevre wrote: In general, bug-fix releases (which are also blocked by the freeze) don't introduce new bugs. Case in point: http://www.h-online.com/open/news/item/Security-updates-break-ownCloud-installations-1834507.html Of course, there are exceptions. But you can see that the problem has been fixed very quickly (in less than 24 hours). If such a thing happens in Debian, the intermediate broken versions wouldn't even have the time to reach testing. One may also wonder whether the broken versions have sufficiently been tested. Perhaps not, to quickly fix a security problem. But even in this case, this may be the right thing to do. We know from some projects that they have regression testing we deem sufficient to trust that assertion. But I'm not sure it's generally true. Couldn't Debian packages have some field about the quality of regression testing? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403200748.ga6...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-03 20:17:47 +0200, Philipp Kern wrote: On Wed, Apr 03, 2013 at 01:28:58PM +0200, Vincent Lefevre wrote: I pretty much agree. But what's the problem here? That xulrunner and iceweasel have rdeps in the archive that aren't necessarily compatible with a new version of iceweasel and hence introducing yet another transition whenever the targeted release changes. I suppose that iceweasel could be built against the libraries from testing. Then AFAIK, there remains a few rdeps problems, concerning libmozjs and xulrunner (which must match the iceweasel version), but this can be resolved by having both versions installed (this is possible). I said rdeps. I know. Packages that depend on iceweasel and xulrunner. While the latter is coinstallable, the former is not. It seems that most reverse dependencies for iceweasel are l10n packages and extensions, so that one can consider them as part of the upgrade. The remaining dependencies seem to have a form like iceweasel | www-browser. So, what would be wrong? Not also that in practice, many (most?) users will use a backport. So, if some real reverse dependency would be affected by a change in the iceweasel version, it rather needs to be fixed now. And concerning transitions, you don't need a freeze to block them. As if it would be that easy. c.f. R, which this thread is about and which didn't change any package name. You can see that concerning R, the freeze was pretty useless to avoid some problems. Now, the freeze only concerns testing. And it is easy to prevent packages from migrating to testing. A spurious RC bug is a solution. I interpreted your argument as being different: They should normally be detected when the package is uploaded in unstable. And concerning transitions, you don't need a freeze to block them. Hence yes, we could block packages in unstable from being updated. Transitions also happen for unstable which cause temporary uninstallability, so I'm not sure what block you're talking about then. I mean the update of the package in testing. A RC bug is a way to block transitions from happening there; a freeze is not needed. Concerning unstable, freeze or not, you can't really block updates there (as this can be seen with R). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130403202926.gb6...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. - Jukka. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402064022.GA26379@marx.bitnet
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le 02/04/2013 08:40, Jukka Ruohonen a écrit : On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. As for perl, python, ruby, ... modules: only one software to install/upgrade/ fix security bug, ... : apt When R packages exist in Debian, I always install them from Debian. So that, I do not have to re-install them at each change of R version. I do not have to check if new upstream versions are available neither. apt does it for me. Now, as for perl (and probably other software with lots of modules), the creation of a R Debian package from a R CRAN package should be as automatic as possible (I did not check at all where we are on this point). Regards, Vincent - Jukka. -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515a85dc.2080...@free.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote: IMO it's important to remember that it's fundamentally the release team that is at fault for problems here, not the R maintainer. Can you please remind me what you do for Debian? Aside from flame debian-devel. I've forgotten. Unstable has already been frozen for much longer than is in any way reasonable for either development of Debian, users of Debian unstable, or upstreams whose current software is either not being packaged at all or is only in experimental. I agree with this, but the release team are not the people who are on the critical path for getting us to release-ready, as per our current release process. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402081317.GA3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 12:15:17AM +0200, Arno Töll wrote: So help speeding up the release process. The universal rebuttal to all complaints about the release process. Sadly it misses the point at the heart of most complaints: far too much work is needed to become release-ready, and there is not enough resource to do it. People who feel the release process is broken and care about Debian have a duty to discuss it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402081536.GB3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote: I don't think the time for this discussion is now, so I'll restrain myself from saying more. The release is near, and there's going to be plenty of time until the next freeze :) When the pain of the freeze will be a fast-fading memory, and we'll not bother trying to reform the release process until we're in the thick of it again, and if anyone dares suggest that the process is flawed at that point they'll be labelled a pariah and shunned from the village. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402082011.GC3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. If, you are suggesting here, that the release process in Debian is utterly set in stone and nobody may raise objections about it or try to work to address the problems that people have with it, then I guess *I'm* in the wrong project. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402082602.GD3371@debian
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Le mardi 02 avril 2013 à 09:15 +0100, Jonathan Dowland a écrit : The universal rebuttal to all complaints about the release process. Sadly it misses the point at the heart of most complaints: far too much work is needed to become release-ready, and there is not enough resource to do it. People who feel the release process is broken and care about Debian have a duty to discuss it. This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364893776.3634.849.camel@pi0307572
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402125235.gb31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote: This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. If neither upstream nor the Debian maintainer of some package is active and the package is rather buggy (e.g. with RC bugs not easy to fix), I don't think that the package should be in stable. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402130933.gc31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402130943.gj6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 02.04.2013 13:52, Vincent Lefevre wrote: I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. If so, there was a good reason for that (i.e. pre-announced time-based freeze). As others have said (although ymmv) I don't think this is the appropriate time to get in to the pros / cons of that decision. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2b0f08e74fe8a44e3d83f679a0d93...@mail.adsl.funky-badger.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 14:52:35 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-03-31 23:20:23 +0100, Neil Williams wrote: The length of the freeze is not the fault of the release team. The length of the freeze is down to all of the contributors to Debian not fixing enough RC bugs - I count myself in that, I've managed to get massively less done for this release than for previous ones. There are reasons, it doesn't change the reality that the freeze is still ongoing. I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. The release happens when (almost) all RC bugs are fixed, the freeze is to allow the existing bugs to be fixed whilst *protecting* the other packages from breakage caused by new software being uploaded. The RC bug count only ever comes down once a freeze is in place. New software causes new bugs, that's inescapable. To reduce the bug count, existing software must be fixed without allowing new software to continue breaking things and whilst making the absolute minimal changes to the software which is still working. *That* is the freeze. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpag6fmtZ2H6.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Or RC bugs also apply to old versions of the package. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402131538.gd31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Mon, Apr 01, 2013 at 01:13:29PM +0100, Neil Williams wrote: On Mon, 1 Apr 2013 17:42:29 +0600 Andrey Rahmatullin w...@wrar.name wrote: On Mon, Apr 01, 2013 at 12:33:15AM -0500, Steve M. Robbins wrote: Thanks for trading the R release cycle with Debian's and for delaying the release. The harm has already been done, so somebody should probably go and create a transition tracker for it? Rather than accept the harm, surely the release team could simply roll back the upload in some manner? Only by uploading older versions with bumped version numbers, and that still will cause testing and unstable to have different binaries. That is why we have epochs - an epoch is ignored for the purposes of the binary packages, see zlib1g and other packages using epochs. The existing tools have sane support for epochs, exactly to avoid these problems. http://packages.debian.org/sid/zlib1g 1:1.2.7.dfsg-13 http://ftp.uk.debian.org/debian/pool/main/z/zlib/zlib1g_1.2.7.dfsg-13_amd64.deb dpkg -l | grep ':' The version currently in wheezy could be re-uploaded with a single change to the changelog to start using an epoch and using the version string currently in wheezy for the post-epoch string of the new version. If wheezy had foo 1.2.3-1 and unstable 2.0.0-1, the epoch version of 1.2.3 would be 1:1.2.3-1 which is newer than 2.0.0-1 but be compatible with 1.2.3-1 already in wheezy. Actually that hits another problem. Namely that the epoch does not appear in the binary package filename. While wheezy would have 1.2.3-1 and unstable would have 1:1.2.3-1 they both produce the same foo_1.2.3-1_amd64.deb. But for certain the file contents will differ, the files won't be bit identical and checksums will differ. The archive can not handle that case. You would have to upload foo 1:1.2.3-2 to avoid the name clash. And not, we do not have epochs to temporarily downgrade a package after a botched upload. Esspecially when the package doesn't yet have a epoch. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402131824.GA10316@frosties
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 15:09:33 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-04-02 11:09:35 +0200, Josselin Mouette wrote: This is indeed Debian’s problem and needs discussion, but the roots lie in upstreams. It mostly comes down to the fact that upstreams of a growing number of projects are not able to synchronize their releases so that a single set of versions can all work together. Personally I think the best way to alleviate that problem would be to reduce the set of packages that are included in a stable release (and that also means in testing). But that is a high price to pay for the sole benefit of making releases easier. If neither upstream nor the Debian maintainer of some package is active and the package is rather buggy (e.g. with RC bugs not easy to fix), I don't think that the package should be in stable. Whilst there are packages which are in that state and some of those can be removed, it isn't possible to remove such packages when there are multiple reverse dependencies. We cannot remove every package where both the maintainer and the upstream are inactive without also removing a lot of packages which have active teams. Equally, active teams don't have the bandwidth to take on the workload of all of their inactive dependencies. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpXV0CvcopJa.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit : On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Yes, many. See some other reply: the RC bug count only really goes down during freezes. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. RC bugs are not only about upstream, it's also about packaging, transitions, etc. It can easily become an intractable mess if things keep getting changed. That's what the freeze it meant to avoid. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402132318.gl6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2 Apr 2013 15:15:38 +0200 Vincent Lefevre vinc...@vinc17.net wrote: On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Or RC bugs also apply to old versions of the package. That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. Even during a freeze, there are many many RC bugs opened for the first time and a lot of those are not in packages which have changed since the freeze began. No package is an island. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJOMreCwOaH.pgp Description: PGP signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit : Having latest upstream versions easily available to users is important for the development of many projects, That's what experimental is for. There are various problems with experimental, in particular dependencies are not necessarily listed, and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). In short, experimental is not for the end user. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402142918.ge31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 14:17:17 +0100, Neil Williams wrote: The release happens when (almost) all RC bugs are fixed, the freeze is to allow the existing bugs to be fixed whilst *protecting* the other packages from breakage caused by new software being uploaded. You can still fix bugs while new software is uploaded, and more generally RC bugs should be fixed ASAP. The RC bug count only ever comes down once a freeze is in place. Developers should not wait for the freeze to fix RC bugs. New software causes new bugs, that's inescapable. But new software also causes existing bugs to be fixed. The number of bugs tend to decrease, in particular in bug-fix releases (note that such releases are also blocked by the freeze). To reduce the bug count, existing software must be fixed without allowing new software to continue breaking things and whilst making the absolute minimal changes to the software which is still working. *That* is the freeze. No, buggy new software that breaks things should not enter testing in the first place. That's what unstable/testing is for. New buggy packages should remain in unstable while new versions of good packages could still enter testing for the next release. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402145212.gf31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 15:23:18 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 15:15:38 +0200, a écrit : On 2013-04-02 15:09:43 +0200, Samuel Thibault wrote: Vincent Lefevre, le Tue 02 Apr 2013 14:52:35 +0200, a écrit : I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, Problem is: until you freeze, new RC bugs keep getting introduced. But I would say, not many. Yes, many. See some other reply: the RC bug count only really goes down during freezes. But many packages don't have new RC bugs. They are still blocked by the freeze. I don't think that the status even of a big package like iceweasel is satisfactory. Moreover really new RC bugs are introduced on packages where upstream is active (since the version is new), so that they have a better chance to be fixed quickly. RC bugs are not only about upstream, it's also about packaging, transitions, etc. It can easily become an intractable mess if things keep getting changed. That's what the freeze it meant to avoid. They should normally be detected when the package is uploaded in unstable. And concerning transitions, you don't need a freeze to block them. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402150727.gg31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages and this doesn't prevent developers from fixing RC bugs. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402152052.gh31...@xvii.vinc17.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre, le Tue 02 Apr 2013 17:20:52 +0200, a écrit : This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Which is one of the goals of freezing. I'm just tired of argumenting over something that was already discussed. Let's just work on the actual release at stake... Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402152433.gx6...@type.bordeaux.inria.fr
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2013-04-02 at 16:29 +0200, Vincent Lefevre wrote: On 2013-04-01 02:34:41 +0200, Samuel Thibault wrote: Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit : Having latest upstream versions easily available to users is important for the development of many projects, That's what experimental is for. There are various problems with experimental, in particular dependencies are not necessarily listed, and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). In short, experimental is not for the end user. The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. The details can be discussed later on, when Wheezy is released. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364916902.2302.136.ca...@s1499.it.kth.se
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 02.04.2013 16:35, Svante Signell wrote: The best solution would be having unstable _never_ frozen, at the cost of another repository during the freeze period. This was proposed some time ago, see http://lists.debian.org/debian-devel/2013/01/msg00273.html repeated here for convenience: That's a contentious definition of best. You also appear to have somewhat missed the point of my response to that original message, i.e. URL:http://lists.debian.org/debian-devel/2013/01/msg00274.html i) experimental being really for new stuff ii) unstable unfrozen always: - stable+1: if no freeze - testing after xx days as before - stable+1=unstable frozen at freeze time: if during freeze - testing - stable - stable+2: if in freeze - unstable And the frozen unstable/testing repository could cover a subset of the packages in unstable: The good ones. That would effectively reduce the freeze period. I'm still struggling to see how this is fundamentally different from the frozen suite which testing was introduced to replace, more than a dozen years ago. As per my earlier message referenced above, see URL:http://lists.debian.org/debian-devel/2000/08/msg00906.html for some detail of why frozen didn't work. As proposed in the thread the idea should be written down at http://wiki.debian.org/ReleaseProposals Since this idea is new as far as I could see it's time do do that. FSVO new. Regards, Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/613c903831a5003cf7f8d2254668f...@mail.adsl.funky-badger.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 02 Apr 2013, Jukka Ruohonen wrote: On Sun, Mar 31, 2013 at 05:39:05PM -0500, Dirk Eddelbuettel wrote: When I said peripheral I meant in the sense that none of the Depends are used by anything else beyond R. I know it is not small -- there are now 4400 R packages on CRAN, and we have about 150 of those in Debian. I think it must be asked: what is the rationale of trying to re-package those for Debian? CRAN works. CRAN works, but it's not optimal. There's a reason why those packages are packaged, and why http://debian-r.debian.net exists. Don Armstrong -- Sometimes I wish I could take back all my mistakes but then I think what if my mother could take back hers? -- a softer world #498 http://www.asofterworld.com/index.php?id=498 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402164039.gk4...@rzlab.ucr.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Jonathan Dowland j...@debian.org writes: On Mon, Apr 01, 2013 at 07:57:50AM +0300, Faidon Liambotis wrote: I don't think the time for this discussion is now, so I'll restrain myself from saying more. The release is near, and there's going to be plenty of time until the next freeze :) When the pain of the freeze will be a fast-fading memory, and we'll not bother trying to reform the release process until we're in the thick of it again, and if anyone dares suggest that the process is flawed at that point they'll be labelled a pariah and shunned from the village. I really don't think this is true. If someone tries to do that in a later discussion, I at least promise to point out that the freeze is long and uncomfortable and that, if we can come up with a better solution, we would definitely benefit. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v50rikk@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre vinc...@vinc17.net writes: On 2013-04-02 14:29:46 +0100, Neil Williams wrote: That is not how it actually works out. Policy changes are made which require old packages to build with new flags, compilers and toolchain packages get upgraded and introduce new failure modes, QA tools improve and catch more corner cases. Those things no longer happen during a freeze, so the bug count has a chance to go down. Look at the graphs on bugs.debian.org - the RC count rises steadily outside of a freeze. The graph is meaningless. Many RC bugs can be due to transitions, which are specific (the freeze applies to *all* packagse). I don't see how that makes the graph meaningless. One of the points of a freeze is that we stop doing new transitions; in fact, that's one of the painful parts that everyone complaints about. How do you plan on keeping transitions from introducing new RC bugs without freezing? This is also due to the fact that more people are working on fixing RC bugs *now* instead of doing that before. Of course. And the only thing that we've ever managed to do to get that behavior change is to freeze. If you could get everyone to work on RC bugs outside of a freeze so that the RC bug count doesn't spike and then grow continuously every time we unfreeze, then indeed we would have a much nicer release process. Past experience tells us that's Hard; people work on RC bugs during the freeze and not to the same degree outside of the freeze. Again, you're missing the whole inter-dependency issue. A new piece of software can introduce / reveal bugs in previously working software. Or a previously working piece of software can start to fail because hardware has moved on and is able to push more data through the software than previously envisaged leading to complex threading / timing issues. But my point is that this is true only for some particular packages Which collectively amount to probably 75% of the archive, since among other things that includes pretty much any package that uses a shared library. and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) and because more people actually work on RC bugs during a freeze. That's the fundamental constraint that any new release process needs to work with. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nfori8t@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent Lefevre vinc...@vinc17.net writes: There are various problems with experimental, in particular dependencies are not necessarily listed, Huh? I have no clue what you could possibly be talking about, unless you're just saying that some packages in experimental are critically buggy. and upgrade from an experimental package is not supported (it generally works, but the maintainer doesn't have to take that into account). This is a bizarre statement to me. Why would you not take that into account as a maintainer? I always have for everything I've uploaded to experimental. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjxgq3lc@windlord.stanford.edu
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Jonathan Dowland] On Mon, Apr 01, 2013 at 04:45:19PM +0100, Neil McGovern wrote: You seem to believe that unstable is more important than stable releases. I do not. One of us is in the wrong project. If, you are suggesting here, that the release process in Debian is utterly set in stone and nobody may raise objections about it or try to work to address the problems that people have with it ECHAN? Did you quote the wrong text, or reply to the wrong message or even the wrong sender? Because your paraphrase seems to have nothing to do with the text you quoted. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183124.gu4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
[Vincent Lefevre] I disagree. If the freeze occurred only once (almost) all RC bugs were fixed, there would be (almost) no delay. I suspect that the length of the freeze is due to the fact that the freeze occurred while too many RC bugs were already open. Agreed: in July 2012, many - too many - RC bugs were already open. So when, in your estimation, would have been a better time to freeze? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130402183759.gv4...@p12n.org
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
]] Russ Allbery and this doesn't prevent developers from fixing RC bugs. Nothing prevents developers from fixing RC bugs at any time. They just don't in sufficient numbers to keep ahead of the incoming rate except during a freeze, both because the freeze drops the incoming rate (by, among other things, rejecting new transitions) and because more people actually work on RC bugs during a freeze. Just to expand slightly on this, the problem you're both poking at is that during a freeze, our incentives are directed towards fixing RC bugs (because then we can release, which means we can then do what we prefer to, which (as you can see in the unconstrained periods), is to package new software, new upstream versions and so on). New code tends to be buggier than older, debugged code, so it's no surprise that we get more RC bugs in the non-freeze periods.. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738v83g7d@xoog.err.no
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Vincent, am Tue, Apr 02, 2013 at 05:07:27PM +0200 hast du folgendes geschrieben: I don't think that the status even of a big package like iceweasel is satisfactory. I pretty much agree. But what's the problem here? That xulrunner and iceweasel have rdeps in the archive that aren't necessarily compatible with a new version of iceweasel and hence introducing yet another transition whenever the targeted release changes. And concerning transitions, you don't need a freeze to block them. As if it would be that easy. c.f. R, which this thread is about and which didn't change any package name. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Goswin, am Tue, Apr 02, 2013 at 03:18:24PM +0200 hast du folgendes geschrieben: And not, we do not have epochs to temporarily downgrade a package after a botched upload. c.f. imagemagick I'm pretty sure we do. SCNR Philipp Kern signature.asc Description: Digital signature
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/01/2013 11:06 PM, Luca Falavigna wrote: On the other hand, FTP Team is willing to fast-track NEW packages anytime, if needed. That's simply not truth. I can't let you say that and not reply. And I'm happy we come to this topic. I've sent a mail to the FTP masters last January (IIRC) about it, because I'm working on Openstack, which has release cycles of 6 months. I've been working on these packages days and nights, hoping that I would make it for the next release of Openstack. As it stand, I still have some python packages in the NEW queue, from the *last* version of Openstack, released nearly 6 months ago. I did the upload nearly 3 months ago for Cinder. I'm still waiting. And I'm not even talking about the python dependencies that I need for the next release of Openstack, due in 3 days. Absolutely all of them were uploaded for Experimental. There is absolutely no transition problem with my packages. The result is a real disaster for my development. There was talks about doing the packaging of Openstack together, with Ubuntu and Debian. But as it stands, I don't think I'm in a good position to ask for that, since it can take a random time for my packages to get reviewed and finally accepted. Now, if anyone tells me that Debian isn't adapted for such a fast development as Openstack, I will be forced to agree. My only option (which I am already doing) is using a private non-official repository, which is really not a satisfying solution. I even proposed my help for the review process (of other packages, not mine, of course...). This was a no-go refusal. I haven't seen either that the FTP team asked for help and new members, if I am seen as not qualified and the team is understaffed! I by the way agree with Joachim that the unpredictability of the processing time is the most irritating part of it all. I really don't understand why all development has to be completely stalled during the freeze. The only answer I had from the FTP-masters was we are frozen, have you noticed?... ... Thomas Goirand (zigo) BTW: http://ftp-master.debian.org/stat.html shows that everything started to get stuck around mid-december. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515b40d0.6090...@debian.org
Re: NEW processing during freezes (Was: R 3.0.0 and required rebuilds of all reverse Depends: of R)
On 04/02/2013 12:16 AM, Luca Falavigna wrote: In a perfect world there wouldn't be any need for a NEW queue at all. But we have to face with the reality. We try to do our best to improve things where we can. From the FTP Team side, we always try to be quick and helpful with our fellow developers, and are happy to hear about suggestions how to improve further. I got a bunch of suggestions... Suggestion #1: if a package stays more than a month in the NEW queue, then it gets automatically approved, and may be reviewed later on. My reasoning is that more than a month, it can become really problematic and blocks development. Suggestion #2: get rid of the new binary queue (not new source package, that's different). There's no reason why the licensing of a package changes just because the maintainer decides to add a new binary, so it makes no sense. This would save a lot of time for the FTP team. Suggestion #3: have a system where any other DD can review a package in the NEW queue, not only the FTP masters or the FTP assistants. Suggestion #4: recognized that the FTP team needs to work faster, and get more people in the FTP team. Suggestion #5: make it so that a bunch of packages can be reviewed together, as they might depend on each other, and we would like to avoid cases where some packages are accepted, but can't be installed because their dependencies are in NEW. Suggestion #6: get rid of the NEW queue completely. I'm not the only one that thinks it should be like that, and that the licensing review process could happen after packages are accepted. Maybe though, I'll be the only one saying it out loud (but I'm getting used to it...). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/515b4418.2020...@debian.org
