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
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-d
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-compilati
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
situat
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
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
plan
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.
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 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.
> > >
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.
>
>
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 depend
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 pa
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
signature.asc
Des
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 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 di
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 thir
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
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 a
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, an
On Thu, Apr 18, 2013 at 04:18:20PM +0100, Neil Williams wrote:
> On Thu, 18 Apr 2013 16:41:35 +0200
> Matthias Klose 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 p
On 18 April 2013 19:13, Sergei Golovan wrote:
> Hi!
>
> On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura 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 there is no rush r
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 arch
Matthias Klose 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
cross-grade (t
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 interpret
Hello,
On Thu, 18 Apr 2013 22:13:04 +0400
Sergei Golovan 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 interrupting th
Hi!
On Thu, Apr 18, 2013 at 9:56 PM, Andrew Shadura 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
> > multiarchification,
Hello,
On Thu, 18 Apr 2013 16:07:44 +0100
Dmitrijs Ledkovs wrote:
> > On 18 April 2013 16:41, Matthias Klose 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 sep
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
>
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
>experim
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose 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 in wheezy wil
On Thu, 18 Apr 2013 16:41:35 +0200
Matthias Klose 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 in wheezy wil
On 18 April 2013 15:55, Andrew Shadura wrote:
> Hello,
>
> On 18 April 2013 16:41, Matthias Klose 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,
>>
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 architectu
Hello,
On 18 April 2013 16:41, Matthias Klose 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 this enough
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 architectur
35 matches
Mail list logo
