Re: libc-bin
On Fri, 05 Apr 2013 18:45:15 -0500, carlos wrote: >Is thought to have libc 2.17 on Debian testing soon? Unlikely. Even unstable has only libc 2.13, and at this stage of the release I guess that hell will freeze over before the release team will allow a new libc upstream version into Debian wheezy. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1uopod-qb...@swivel.zugschlus.de
Re: libc-bin
On Fri, Apr 05, 2013 at 06:45:15PM -0500, carlos wrote: > I've trying to use Chromiun latest trunk but its requires libc-bin > > 2.15, even I use Debian Testing I do not have this package. > Is thought to have libc 2.17 on Debian testing soon? As experimental already has 2.17 for some time, I suppose it will go into testing in a relatively short time after the wheezy release. You can always try installing it from experimental, of course (usual considerations apply). -- WBR, wRAR -- 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/20130406102411.ga30...@belkar.wrar.name
Re: fotoxx: new upstream version available
fotoxx version 13.04 is available: http://www.kornelix.com/uploads/1/3/0/3/13035936/fotoxx-13.04.tar.gz The Debian watch file needs to be updated. Is the package maintainer still active? -- 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/20130406130640.UKsuRhT1t@outer-rim
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: libc-bin
On Fri, Apr 5, 2013 at 7:45 PM, carlos wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Thanks for your time and job! > I've trying to use Chromiun latest trunk but its requires libc-bin > 2.15, > even I use Debian Testing I do not have this package. > Is thought to have libc 2.17 on Debian testing soon? Have you considered installing the Debian chromium package rather than the upstream build? Best wishes, Mike -- 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/CANTw=mmnfkw7cur+elplyhzn0lsd+j0yln_t0ho+byowxau...@mail.gmail.com
Re: Generators for debian/* files?
> +++ Jonathan Dowland [2013-04-05 10:09 +0100]: > > On Fri, Apr 05, 2013 at 11:07:31AM +0200, Thomas Koch wrote: > > > This java code should be replaces with something in perl/python/non-JVM. > > > > Why? [Wookey] > Because it's an entirely unnecessary circular build-dependency. java > is not part of build-essential and this doesn't seem like a good > reason for making it so. This sounds like a packaging tool, not a build tool. (At least, I _hope_ nobody is thinking of generating debian/rules during the build process!) I'd say anyone packaging Java stuff probably has a JVM. -- 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/20130406183437.gw4...@p12n.org
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: fotoxx: new upstream version available
Hi, sorry for the delay. Yes, I'm active. I was waiting the new realease to find a sponsor and work with the new version of the package. Thanks for the bug reports. I'm going to check them out. 2013/4/6 > fotoxx version 13.04 is available: > http://www.kornelix.com/uploads/1/3/0/3/13035936/fotoxx-13.04.tar.gz > > The Debian watch file needs to be updated. > > Is the package maintainer still active? > > > -- > 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/20130406130640.UKsuRhT1t@outer-rim > >
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 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 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
