Re: Freeze for LLVM packages
Hi, 2010/9/9, Adam D. Barratt a...@adam-barratt.org.uk: The changelog for an earlier version mentions - debian/control.in/source: Build-Depends on ocaml-nox (= 3.11.2), ocaml-best-compilers | ocaml-nox, dh-ocaml (= 0.9.1). which appears to have been lost in this version of the package. Indeed, this is now fixed. http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.dsc Beside the OCaml issue, which I'm working on, do you have any other comment on the package? Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimu+iqjgi0warxrrdgpwemcupu6dqbjctso7...@mail.gmail.com
Re: Freeze for LLVM packages
On Wed, 2010-09-22 at 08:13 +0200, Arthur Loiret wrote: 2010/9/9, Adam D. Barratt a...@adam-barratt.org.uk: The changelog for an earlier version mentions - debian/control.in/source: Build-Depends on ocaml-nox (= 3.11.2), ocaml-best-compilers | ocaml-nox, dh-ocaml (= 0.9.1). which appears to have been lost in this version of the package. Indeed, this is now fixed. http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.dsc Beside the OCaml issue, which I'm working on, do you have any other comment on the package? I assume llvm-2.6-runtime's Replaces and Conflicts on llvm ( 2.6-7) are inherited from llvm-runtime, which was split out of the main llvm binary package in that version; that seems superfluous for the -2.6 package. If we're still hoping to get llvm-defaults and llvm-2.6 in to Squeeze, they really need to make it to unstable soon (and #593188 in llvm-2.7 needs resolving). Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1285185383.4068.14.ca...@hathi.jungle.funky-badger.org
Re: Freeze for LLVM packages
On Sun, August 29, 2010 22:10, Arthur Loiret wrote: 2010/8/24, Arthur Loiret aloi...@debian.org: llvm-2.6 is on its way, and will be quite simple: no source changes from the llvm package, just a few packaging bits. There you go: http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.dsc http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.debdiff Sorry for not getting back to you sooner. Following on from Stéphane's comments on the setup of the OCaml package, there seem to be some other OCaml-related issues. Firstly, there's a missing Build-Depend on dh-ocaml; adding that then gives: fakeroot debian/rules binary make: /usr/bin/ocamlc: Command not found make: /usr/bin/ocamlc: Command not found [...] dh_install -p libllvm-ocaml-2.6-dev cp: cannot stat `./debian/tmp-llvm//llvm-2.6': No such file or directory dh_install: cp -a ./debian/tmp-llvm//llvm-2.6 debian/libllvm-ocaml-2.6-dev/// returned exit code 1 make: *** [/tmp/buildd/llvm-2.6-2.6/debian/stamps/binary-stamp-libllvm-ocaml-dev] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 The changelog for an earlier version mentions - debian/control.in/source: Build-Depends on ocaml-nox (= 3.11.2), ocaml-best-compilers | ocaml-nox, dh-ocaml (= 0.9.1). which appears to have been lost in this version of the package. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/3a769892e76d9bdde6ec5734b83f0f1c.squir...@adsl.funky-badger.org
Re: Freeze for LLVM packages
2010/8/24, Arthur Loiret aloi...@debian.org: llvm-2.6 is on its way, and will be quite simple: no source changes from the llvm package, just a few packaging bits. There you go: http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.dsc http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.debdiff Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=brcgfv=qbujdm2=lkpcvvm6lc4_wzma8n+...@mail.gmail.com
Re: Freeze for LLVM packages
Le 29/08/2010 23:10, Arthur Loiret a écrit : There you go: http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.dsc http://people.debian.org/~aloiret/squeeze/llvm/llvm-2.6_2.6-10.debdiff From the diff: define libllvm-ocaml-dev_extra_binary if test x$* = xlibllvm-ocaml-dev ; then \ - cp $(D)/debian/$*.META $(D)/debian/$*/$(OCAML_STDLIB_DIR)/METAS/META.llvm ; \ + cp $(D)/debian/$(strip $(call pkgname,$*)).META $(D)/debian/$(strip $(call pkgname,$*))/$(OCAML_STDLIB_DIR)/METAS/META.llvm-$(UVERSION) ; \ fi endef This won't work because of . in $(UVERSION). . is reserved for delimiting subpackages. You should replace them with something else (e.g. _), or drop punctuation altogether (as in META.llvm27). And the contents should also reflect the (findlib) package name. Actually, the same applies for llvm-2.7 as well... The META files should be fixed for both, or dropped. They are useless as they are (it was fine when the package name was versionless). Attached is a (tentatively) fixed META.llvm-2_7 file. Beware that the directory variable refers to the actual directory (here, llvm-2.7), and the requires refer to the package name (i.e. the extension of the META file, here llvm-2_7 or whatever you choose). And by the way, libllvm-ocaml-2.7-dev doesn't respect OCaml packaging policy (which is still work in progress...) and is not handled by dh_ocaml (the virtual package with ABI hash is not provided)... something like libllvm-2.7-ocaml-dev would be better. Cheers, -- Stéphane description = Low Level Virtual Machine bindings version = 2.7 directory = +llvm-2.7 archive(byte) = llvm.cma archive(native) = llvm.cmxa linkopts = -cclib -lstdc++ -cclib -lllvm package executionengine ( requires = llvm-2_7 version = 2.7 archive(native) = llvm_executionengine.cmxa archive(byte) = llvm_executionengine.cma linkopts = -cclib -lllvm_executionengine ) package target ( requires = llvm-2_7 version = 2.7 archive(native) = llvm_target.cmxa archive(byte) = llvm_target.cma linkopts = -cclib -lllvm_target ) package scalar_opts ( requires = llvm-2_7 llvm-2_7.target version = 2.7 archive(native) = llvm_scalar_opts.cmxa archive(byte) = llvm_scalar_opts.cma linkopts = -cclib -lllvm_scalar_opts ) package analysis ( requires = llvm-2_7 version = 2.7 archive(native) = llvm_analysis.cmxa archive(byte) = llvm_analysis.cma linkopts = -cclib -lllvm_analysis ) package bitwriter ( requires = llvm-2_7 version = 2.7 archive(native) = llvm_bitwriter.cmxa archive(byte) = llvm_bitwriter.cma linkopts = -cclib -lllvm_bitwriter ) package bitreader ( requires = llvm-2_7 llvm-2_7.bitwriter version = 2.7 archive(native) = llvm_bitreader.cmxa archive(byte) = llvm_bitreader.cma linkopts = -cclib -lllvm_bitreader )
Re: Freeze for LLVM packages
2010/8/23, Adam D. Barratt a...@adam-barratt.org.uk: On Wed, August 18, 2010 11:50, Arthur Loiret wrote: 2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk: This package still needs a bit of work, but not on this side. Ah, I'd assumed everything was basically ready to go and just waiting to be uploaded. How much is a bit of work? One issue I did notice is that llvm-defaults is missing a build-dependency on m4 (having tried building it in a clean(ish) chroot). The source package was given in its current state, so not ready to be uploaded yet. The bit of work remaining is quite small (partly done locally already). I will probably give you the finished version later today. Any news on this? How far off are you from having a final version of llvm-defaults and llvm-2.6 ready? (I'm assuming/hoping that the latter would largely be a copy of the current llvm source package with the necessary symlinks added, rather than also including a new upstream version). Here is llvm-defaults: http://people.debian.org/~aloiret/squeeze/llvm/llvm-defaults_0.1.dsc It should be close to its final state, but note its libllvm-ocaml-dev package is not installable yet because I need to do an llvm-2.7 upload before. llvm-runtime, llvm and llvm-dev are fine. llvm-gcc-4.2 is now fixed. llvm-2.6 is on its way, and will be quite simple: no source changes from the llvm package, just a few packaging bits. Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=ojedus+rj0jpaq=qcdaeu=75q4bkei0mt=...@mail.gmail.com
Re: Freeze for LLVM packages
On Wed, August 18, 2010 11:50, Arthur Loiret wrote: 2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk: This package still needs a bit of work, but not on this side. Ah, I'd assumed everything was basically ready to go and just waiting to be uploaded. How much is a bit of work? One issue I did notice is that llvm-defaults is missing a build-dependency on m4 (having tried building it in a clean(ish) chroot). The source package was given in its current state, so not ready to be uploaded yet. The bit of work remaining is quite small (partly done locally already). I will probably give you the finished version later today. Any news on this? How far off are you from having a final version of llvm-defaults and llvm-2.6 ready? (I'm assuming/hoping that the latter would largely be a copy of the current llvm source package with the necessary symlinks added, rather than also including a new upstream version). Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/88e4fe533bb849157843fac544c8e781.squir...@adsl.funky-badger.org
Re: Freeze for LLVM packages
2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk: As I said, my primary concern from a release point of view is whether there are good reasons for doing the changes now, rather than waiting for squeeze+1. As Matthias said, the reason is to get the good llvm version installed when users type apt-get install llvm, which is 2.7. Version 2.6 is just there for the two packages that still need it for now, and will be removed for squeeze+1. Very most users want to use 2.7 rather that 2.6. It would just make their life easier by just asking them to install llvm-dev and use unversioned binaries. Has the current configuration confused people that you know of or is this more of a of course people want to use the latest version by default? Both. This package still needs a bit of work, but not on this side. Ah, I'd assumed everything was basically ready to go and just waiting to be uploaded. How much is a bit of work? One issue I did notice is that llvm-defaults is missing a build-dependency on m4 (having tried building it in a clean(ish) chroot). The source package was given in its current state, so not ready to be uploaded yet. The bit of work remaining is quite small (partly done locally already). I will probably give you the finished version later today. Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik7tbn7vze4mzhzs9hsbe4cujcb4edehnlaj...@mail.gmail.com
Re: Freeze for LLVM packages
On Wed, August 18, 2010 11:50, Arthur Loiret wrote:
2010/8/18, Adam D. Barratt a...@adam-barratt.org.uk:
As I said, my primary concern from a release point of view is whether
there are good reasons for doing the changes now, rather than waiting
for squeeze+1.
As Matthias said, the reason is to get the good llvm version installed
when users type apt-get install llvm, which is 2.7. Version 2.6 is
just there for the two packages that still need it for now, and will
be removed for squeeze+1.
Matthias also mentioned trying to remove 2.6 for Squeeze, which is rather
less likely.
So far as I can see, the current split of 2.6 vs 2.7 using packages in the
archive is
2.6 - ldc, llvm-py, llvm-gcc-4.2 (i386)
2.7 - clang, haskell-llvm, llvm-gcc-4.2 (amd64), openjdk-6
Which of those packages will not work with 2.7? Of the remainder which,
if any, are you proposing changing the {build-,}dependencies of? Any
depending on llvm (= 2.6) which will also work with 2.7 shouldn't
require changes and there's certainly an argument that for squeeze uploads
which simply changed the llvm-2.7 dependencies to be llvm (= 2.7)
wouldn't qualify for exceptions on their own.
llvm-gcc-4.2 also has a new upstream version in unstable which was
uploaded after the freeze and does not have an exception (and ftbfs on
i386), which doesn't help.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/feb26b55b4d4c2e70d105ec86c47452d.squir...@adsl.funky-badger.org
Re: Freeze for LLVM packages
On Tue, 2010-08-17 at 02:09 +0200, Arthur Loiret wrote:
2010/8/16, Adam D. Barratt a...@adam-barratt.org.uk:
On Sun, 2010-08-15 at 22:21 +0200, Arthur Loiret wrote:
2010/8/15, Adam D. Barratt a...@adam-barratt.org.uk:
On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote:
- Rename the current llvm source package to llvm-2.6 and
replace binaries by versioned binaries. Thus, it is allowed to have
two versions in the archive (the 2.7 version is already versioned),
just like GCC.
My primary question is what does this gain us for Squeeze? I can see
that it could make future maintenance easier when llvm 2.8 hits the
archive, but that's not going to the case for Squeeze.
[...]
So far as I can see, the current packages are already co-installable,
albeit under the names llvm and llvm-2.7; that's not as clean as
might be preferable, but it would work.
[...]
In other words, here is what I want for squeeze:
[snip llvm-defaults explanation]
Thanks, that fits with what I'd expected.
As I said, my primary concern from a release point of view is whether
there are good reasons for doing the changes now, rather than waiting
for squeeze+1.
Very most users want to use 2.7 rather that 2.6. It would just make
their life easier by just asking them to install llvm-dev and use
unversioned binaries.
Has the current configuration confused people that you know of or is
this more of a of course people want to use the latest version by
default?
As I already said, those changes are smooth for the archive.
For unstable, most probably. For testing we're looking at adding two
new source packages and updating the {build-,}dependencies of some
others and rebuilding them; all of that carries some risk, even if it
should be small.
On a related note, the version of at least the llvm binary package would
also need to be greater than the current 2.6-9. apt won't view llvm_0.1
as requiring an upgrade from an already installed package of a higher
version.
The llvm-defaults 0.1 source package builds 2.7-1 binaries, see
debian/rules.
Ah, yes; I should have expected that when you mentioned it was based on
gcc-defaults. :-) (Having the source versioned in a way that allows the
source and binary versions to stay in sync seems more obvious imho,
but...)
This package still needs a bit of work, but not on this
side.
Ah, I'd assumed everything was basically ready to go and just waiting to
be uploaded. How much is a bit of work? One issue I did notice is
that llvm-defaults is missing a build-dependency on m4 (having tried
building it in a clean(ish) chroot).
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1282108396.8293.4930.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Freeze for LLVM packages
On 18.08.2010 07:13, Adam D. Barratt wrote: On Tue, 2010-08-17 at 02:09 +0200, Arthur Loiret wrote: 2010/8/16, Adam D. Barratta...@adam-barratt.org.uk: On Sun, 2010-08-15 at 22:21 +0200, Arthur Loiret wrote: 2010/8/15, Adam D. Barratta...@adam-barratt.org.uk: On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. My primary question is what does this gain us for Squeeze? I can see that it could make future maintenance easier when llvm 2.8 hits the archive, but that's not going to the case for Squeeze. [...] So far as I can see, the current packages are already co-installable, albeit under the names llvm and llvm-2.7; that's not as clean as might be preferable, but it would work. [...] In other words, here is what I want for squeeze: [snip llvm-defaults explanation] Thanks, that fits with what I'd expected. As I said, my primary concern from a release point of view is whether there are good reasons for doing the changes now, rather than waiting for squeeze+1. yes, get the preferred version, when installing llvm. 2.6 is a legacy version, and probably should be removed for squeeze once all packages build with 2.7. making this change now makes a possible removal of a legacy llvm-2.6 package easier. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c6b7522.3020...@debian.org
Re: Freeze for LLVM packages
On Sun, 2010-08-15 at 22:21 +0200, Arthur Loiret wrote: 2010/8/15, Adam D. Barratt a...@adam-barratt.org.uk: On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. My primary question is what does this gain us for Squeeze? I can see that it could make future maintenance easier when llvm 2.8 hits the archive, but that's not going to the case for Squeeze. Starting with 2.7, the new convention is to have versioned source packages, to allow several different versions to co-exist. Apologies if my question wasn't clear. I appreciate why having the versioned names is advantageous - I'm just not sure what the advantage is to doing the renaming for 2.6 in squeeze, rather than in squeeze+1. So far as I can see, the current packages are already co-installable, albeit under the names llvm and llvm-2.7; that's not as clean as might be preferable, but it would work. - Upload a package called llvm-defaults which would provide the binaries for the default (2.7) version. It can be found in its current state here [0]. Also like GCC. The llvm-defaults package begins producing the llvm binary package, but build-depends on llvm (= 2.7). As the latest version of llvm in the archive is 2.6-9 and the version built from llvm-defaults would be 0.1, that would make the package unbuildable. This should be llvm-2.7 (= 2.7-1), indeed. Thanks, fixed. On a related note, the version of at least the llvm binary package would also need to be greater than the current 2.6-9. apt won't view llvm_0.1 as requiring an upgrade from an already installed package of a higher version. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281981812.12140.372.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Freeze for LLVM packages
2010/8/16, Adam D. Barratt a...@adam-barratt.org.uk: On Sun, 2010-08-15 at 22:21 +0200, Arthur Loiret wrote: 2010/8/15, Adam D. Barratt a...@adam-barratt.org.uk: On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. My primary question is what does this gain us for Squeeze? I can see that it could make future maintenance easier when llvm 2.8 hits the archive, but that's not going to the case for Squeeze. Starting with 2.7, the new convention is to have versioned source packages, to allow several different versions to co-exist. Apologies if my question wasn't clear. I appreciate why having the versioned names is advantageous - I'm just not sure what the advantage is to doing the renaming for 2.6 in squeeze, rather than in squeeze+1. So far as I can see, the current packages are already co-installable, albeit under the names llvm and llvm-2.7; that's not as clean as might be preferable, but it would work. The current binaries packages from llvm should be provided by llvm-defaults, which would Depends on the versioned 2.7 binary packages from llvm-2.7. The current binaries packages from llvm have to be renamed to some versioned binaries packages then. In other words, here is what I want for squeeze: * llvm-2.6 provides libllvm-ocaml-2.6-dev, llvm-2.6, llvm-2.6-dev, llvm-2.6-doc, llvm-2.6-examples, llvm-2.6-runtime, llvm-2.6-source. The binaries package have to be renamed, and some files inside them have to be versioned. * llvm-defaults provides llvm, llvm-runtime, llvm-dev, libllvm-ocaml-dev. They would all Depends on the corresponding versioned packages and just provide symlinks. So, when an user installs llvm, it will also install llvm-2.7 and symlink, for example, /usr/bin/llc to /usr/bin/llc-2.7. * llvm-2.7 provides libllvm-ocaml-2.7-dev, libllvm2.7, llvm-2.7, llvm-2.7-dev, llvm-2.7-doc, llvm-2.7-examples, llvm-2.7-priv-dev, llvm-2.7-runtime, llvm-2.7-source. Already the case. Very most users want to use 2.7 rather that 2.6. It would just make their life easier by just asking them to install llvm-dev and use unversioned binaries. As I already said, those changes are smooth for the archive. - Upload a package called llvm-defaults which would provide the binaries for the default (2.7) version. It can be found in its current state here [0]. Also like GCC. The llvm-defaults package begins producing the llvm binary package, but build-depends on llvm (= 2.7). As the latest version of llvm in the archive is 2.6-9 and the version built from llvm-defaults would be 0.1, that would make the package unbuildable. This should be llvm-2.7 (= 2.7-1), indeed. Thanks, fixed. On a related note, the version of at least the llvm binary package would also need to be greater than the current 2.6-9. apt won't view llvm_0.1 as requiring an upgrade from an already installed package of a higher version. The llvm-defaults 0.1 source package builds 2.7-1 binaries, see debian/rules. This package still needs a bit of work, but not on this side. Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinv-l4vzkbxnebeqmsn=apvrjsvazvdyjtvc...@mail.gmail.com
Re: Freeze for LLVM packages
On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: We would like to make llvm 2.7 (which is already used by clang and openjdk) the default version, but some packages (ldc and python-llvm) still need llvm 2.6. [...] The things to do would be: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. My primary question is what does this gain us for Squeeze? I can see that it could make future maintenance easier when llvm 2.8 hits the archive, but that's not going to the case for Squeeze. - Upload a package called llvm-defaults which would provide the binaries for the default (2.7) version. It can be found in its current state here [0]. Also like GCC. The llvm-defaults package begins producing the llvm binary package, but build-depends on llvm (= 2.7). As the latest version of llvm in the archive is 2.6-9 and the version built from llvm-defaults would be 0.1, that would make the package unbuildable. - Do a last upload of llvm-2.7, clang and llvm-gcc-4.2 which fixes the remaining open bugs llvm-gcc-4.2 FTBFS on i386, although there doesn't seem to be an open bug for that. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1281883234.29656.435.ca...@kaa.jungle.aubergine.my-net-space.net
Re: Freeze for LLVM packages
2010/8/15, Adam D. Barratt a...@adam-barratt.org.uk: On Thu, 2010-08-12 at 19:01 +0200, Arthur Loiret wrote: We would like to make llvm 2.7 (which is already used by clang and openjdk) the default version, but some packages (ldc and python-llvm) still need llvm 2.6. [...] The things to do would be: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. My primary question is what does this gain us for Squeeze? I can see that it could make future maintenance easier when llvm 2.8 hits the archive, but that's not going to the case for Squeeze. Starting with 2.7, the new convention is to have versioned source packages, to allow several different versions to co-exist. The binary packages built from the current llvm source package have to be renamed to some versioned binary packages. So, if the package has to go threw NEW anyway, why not make it follow the new convention by the same occasion? - Upload a package called llvm-defaults which would provide the binaries for the default (2.7) version. It can be found in its current state here [0]. Also like GCC. The llvm-defaults package begins producing the llvm binary package, but build-depends on llvm (= 2.7). As the latest version of llvm in the archive is 2.6-9 and the version built from llvm-defaults would be 0.1, that would make the package unbuildable. This should be llvm-2.7 (= 2.7-1), indeed. Thanks, fixed. - Do a last upload of llvm-2.7, clang and llvm-gcc-4.2 which fixes the remaining open bugs llvm-gcc-4.2 FTBFS on i386, although there doesn't seem to be an open bug for that. Yes, I have a debug build running already. Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=ayng9jbpmh1+2bm_o2xxeszpvfw=zqg5e8...@mail.gmail.com
Freeze for LLVM packages
Hi! During the DebConf, Matthias Klose and I discussed about llvm in Squeeze and took a few decisions, but the freeze has been announced before I uploaded the corresponding work. We would like to make llvm 2.7 (which is already used by clang and openjdk) the default version, but some packages (ldc and python-llvm) still need llvm 2.6. The things to do would be: - Rename the current llvm source package to llvm-2.6 and replace binaries by versioned binaries. Thus, it is allowed to have two versions in the archive (the 2.7 version is already versioned), just like GCC. - Upload a package called llvm-defaults which would provide the binaries for the default (2.7) version. It can be found in its current state here [0]. Also like GCC. - Adjust build-dependencies of ldc and python-llvm to the versioned 2.6 packages. - Do a last upload of llvm-2.7, clang and llvm-gcc-4.2 which fixes the remaining open bugs This transition would be very smooth (all the packages using llvm already use the version they need, no need to fix them) and I would take care to fix all the eventual bugs very quickly. [0] http://people.debian.org/~aloiret/llvm-defaults/llvm-defaults_0.1.dsc Thanks, Arthur. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimjebcksjd+gqj4nv5rn7bnnrujo+srw3avk...@mail.gmail.com
