Le 2013-05-05 03:50, Adam Borowski a écrit :
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of
the
build process (i.e. ocaml doesn't build-depend
On Sat, 2013-05-04 at 06:36:31 +0200, Matthias Klose wrote:
Am 19.04.2013 00:33, schrieb Guillem Jover:
I think the full-multiarch support for python in
experimental should really be reverted.
No. This is backward, and the wrong way to go forward.
Sorry, but the way to go forward is not
Le 18/04/2013 16:41, Matthias Klose a écrit :
So what is the status for some runtimes/interpreters (would like to see some
follow-up/corrections from package maintainers)?
[...]
- Lua, Ocaml, Haskell, Guile, ... ?
First, let me explain a few notions that will be useful to grasp the
situation
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of the
build process (i.e. ocaml doesn't build-depend on itself). So no need
for cross-compilation
Le 05/05/2013 03:50, Adam Borowski a écrit :
On Sun, May 05, 2013 at 12:08:06AM +0200, Stéphane Glondu wrote:
As far as bootstrapping is concerned, the OCaml sources include
precompiled (bytecode) executables that are used in a first stage of the
build process (i.e. ocaml doesn't build-depend
Am 19.04.2013 00:33, schrieb Guillem Jover:
I think the full-multiarch support for python in
experimental should really be reverted.
No. This is backward, and the wrong way to go forward. I do acknowledge that
there are issues with the current state of dpkg, but I'm not seeing how you are
On Sun, Apr 21, 2013 at 02:42:32AM +0300, Uoti Urpala wrote:
Should that set of running architectures be just architecture?
No. Some packages can have multiple runing architecturs. The most
obvious case is M-A:same packages where you can install the same package
for multiple architectures.
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing package relationships lack information
that is necessary to do the right thing in all cases. Consider different
kinds of
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs to work for the arch matching installed version of X.
P (all)
On Sat, Apr 20, 2013 at 05:42:52PM +0300, Uoti Urpala wrote:
Helmut Grohne wrote:
On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
3) P runs a script using system interpreter X, and depends on the
interpreter environment supporting functionality provided by Q.
Q needs
Helmut Grohne wrote:
You point out a limitation that I'd consider to be a feature. My
proposal requires that every package has a single set of running
architectures that has to apply to all code contained.
Should that set of running architectures be just architecture?
I think that after
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
- Third party modules for interpreters should be cross-buildable.
Many build systems for interpreter languages are written in the
interpreter language itself. So you do require the interpreter
for the build, and the
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
So what is the status for some runtimes/interpreters (would like to see some
follow-up/corrections from package maintainers)?
- Perl: Afaik, Neil did prepare the interpreter to cross-build, and
to co-install the runtime and
On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
I don't see a need to have the perl:i386 interpreter installed on amd64
in order to build third party i386 perl modules, the amd64 interpreter
should be fine, just
On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
On Thu, Apr 18, 2013 at 11:01:17PM -0700, Steve Langasek wrote:
On Thu, Apr 18, 2013 at 04:18:38PM +0100, Neil Williams wrote:
I don't see a need to have the perl:i386 interpreter installed on amd64
in order to build third party
On Fri, Apr 19, 2013 at 08:01:40AM -0700, Steve Langasek wrote:
On Fri, Apr 19, 2013 at 05:26:41PM +0300, Niko Tyni wrote:
The modules aren't linked against libperl, it's
the other way around: libperl loads them at run time with dlopen(3).
They are effectively plugins in a private
On Fri, Apr 19, 2013 at 12:33:07AM +0200, Guillem Jover wrote:
As I pointed out on the debian-perl mailing list, after having
discussed about multiarch support for perl, I don't think a fully
multiarchified perl (nor at least python) should be uploaded to sid,
as going full multiarch on the
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
- Ruby: Afaik, not yet started on multiarch.
Ruby 2.0 has multiarch support upstream. The Debian packaging is not
finished yet, but it will have multiarch.
I do not plan to multiarch 1.9.
--
Antonio Terceiro terce...@debian.org
Helmut Grohne wrote:
Barring any mistakes this appears like a possible solution to the
problem. Did you spot anything obviously wrong? Any example where you
don't see how to work it out?
It seems correct at first glance, but not enough to solve all the issues
mentioned. Currently existing
There are maybe not many use cases where you do want to install an interpreter
like python or perl for a foreign architecture, but there are some use case
where such a setup makes sense. For now I see this limited for architecture
pairs like amd64/i386, armel/armhf, ia64/i386, i.e. for
Hello,
On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote:
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries are split out into separate packages,
and are co-installable. Not yet tested if
On Thu, Apr 18, 2013 at 04:41:35PM +0200, Matthias Klose wrote:
There are maybe not many use cases where you do want to install an interpreter
like python or perl for a foreign architecture, but there are some use case
where such a setup makes sense. For now I see this limited for architecture
On 18 April 2013 15:55, Andrew Shadura bugzi...@tut.by wrote:
Hello,
On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote:
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries are split out into
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support for the python based pretty printer.
Installing gdb:amd64 on i386
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support for the python based pretty printer.
Installing gdb:amd64 on i386
Le jeudi 18 avril 2013 à 16:41 +0200, Matthias Klose a écrit :
- Python: co-installable runtime and development files, cross-buildability
upstreamed for 2.7.4 and 3.3.1. There is a way to cross-build third
party modules using distutils/setuptools. Packages are available in
Goswin von Brederlow writes (Re: multiarch and interpreters/runtimes):
Co-installability of interpreters is generally not planed and would
have to be made as custom solutions, i.e. place the interpreter in
/usr/lib/x86_64-linux-gnu/perl/ and provide /usr/bin/perl as
alternative.
I think it's
Hello,
On Thu, 18 Apr 2013 16:07:44 +0100
Dmitrijs Ledkovs x...@debian.org wrote:
On 18 April 2013 16:41, Matthias Klose d...@debian.org wrote:
- Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches
are available in Debian bug reports.
Currently the shared libraries
Hi!
On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura bugzi...@tut.by wrote:
Hello,
By the way, have you contacted Sergei on this?
I saw the bugreports and I'm planning to start working on them after
wheezy release.
Personally, I'm not yet convinced about this interpreter
Hello,
On Thu, 18 Apr 2013 22:13:04 +0400
Sergei Golovan sgolo...@debian.org wrote:
To Sergei (added to Cc): I'd like to join the effort in packaging
Tcl/Tk and stuff, as I said before; but as you've been the most
active person on the team for quite some time I'm a bit hesitant
about
On Thu, Apr 18, 2013 at 06:15:26PM +0100, Ian Jackson wrote:
Goswin von Brederlow writes (Re: multiarch and interpreters/runtimes):
Co-installability of interpreters is generally not planed and would
have to be made as custom solutions, i.e. place the interpreter in
/usr/lib/x86_64-linux
Matthias Klose d...@debian.org writes:
There are maybe not many use cases where you do want to install an
interpreter like python or perl for a foreign architecture, but there
are some use case where such a setup makes sense.
One additional use case: I want to be able to do this in order to
Hi!
[ I had pending warning about this on debian-devel before the release,
so this is a good way to do that. :) ]
On Thu, 2013-04-18 at 16:41:35 +0200, Matthias Klose wrote:
There are maybe not many use cases where you do want to install an interpreter
like python or perl for a foreign
On 18 April 2013 19:13, Sergei Golovan sgolo...@debian.org wrote:
Hi!
On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura bugzi...@tut.by wrote:
Hello,
By the way, have you contacted Sergei on this?
I saw the bugreports and I'm planning to start working on them after
wheezy release.
Yeah
On Thu, Apr 18, 2013 at 04:18:20PM +0100, Neil Williams wrote:
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose d...@debian.org wrote:
- running a gdb:amd64 on i386 to debug 64bit binaries. This is the
reason for our current gdb64 package on i386, but it is missing the
support
35 matches
Mail list logo
