Bug#871469: transition: ocaml

2017-11-14 Thread Andreas Beckmann
Please also binNMU libaio-ocaml in experimental.


Thanks

Andreas



Bug#871469: transition: ocaml

2017-10-10 Thread Stéphane Glondu

On 09/10/2017 21:45, Ximin Luo wrote:

That's alright. I see this is already started and binNMUs are needed. Is someone
from the ocaml team handling these, or should I?


I am handling these.


Would it be possible to prioritize the rebuilds of lwt and ocaml-ctypes?
They seem to be in the critical path to make llvm-toolchain-5.0 buildable
again, which is breaking cross-architecture installability of Mesa, a
relatively common configuration for i386 packages on amd64.

Unfortunately lwt currently fails to build from source (#877548). I notice
that the test rebuild at 
has a newer upstream release of lwt which hopefully addresses that?



I'd support this too, since one of my other packages (rustc) is blocked on LLVM 
as well.

Is a new source upload of LWT all that's needed? I'd be happy to take care of 
that.


I was waiting for the rebuilding of everything on armel and armhf to 
catch up. This is done now, and I've just uploaded lwt.


Cheers,

--
Stéphane



Bug#871469: transition: ocaml

2017-10-09 Thread Ximin Luo
Simon McVittie:
> Control: block 871469 by 877548
> 
> On Mon, 25 Sep 2017 at 10:05:02 +0200, Stéphane Glondu wrote:
>> On 23/09/2017 15:52, Emilio Pozuelo Monfort wrote:
>>> That's alright. I see this is already started and binNMUs are needed. Is 
>>> someone
>>> from the ocaml team handling these, or should I?
>>
>> I am handling these.
> 
> Hi,
> Would it be possible to prioritize the rebuilds of lwt and ocaml-ctypes?
> They seem to be in the critical path to make llvm-toolchain-5.0 buildable
> again, which is breaking cross-architecture installability of Mesa, a
> relatively common configuration for i386 packages on amd64.
> 
> Unfortunately lwt currently fails to build from source (#877548). I notice
> that the test rebuild at 
> has a newer upstream release of lwt which hopefully addresses that?
> 

I'd support this too, since one of my other packages (rustc) is blocked on LLVM 
as well.

Is a new source upload of LWT all that's needed? I'd be happy to take care of 
that.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Bug#871469: transition: ocaml

2017-10-06 Thread Simon McVittie
Control: block 871469 by 877548

On Mon, 25 Sep 2017 at 10:05:02 +0200, Stéphane Glondu wrote:
> On 23/09/2017 15:52, Emilio Pozuelo Monfort wrote:
> > That's alright. I see this is already started and binNMUs are needed. Is 
> > someone
> > from the ocaml team handling these, or should I?
> 
> I am handling these.

Hi,
Would it be possible to prioritize the rebuilds of lwt and ocaml-ctypes?
They seem to be in the critical path to make llvm-toolchain-5.0 buildable
again, which is breaking cross-architecture installability of Mesa, a
relatively common configuration for i386 packages on amd64.

Unfortunately lwt currently fails to build from source (#877548). I notice
that the test rebuild at 
has a newer upstream release of lwt which hopefully addresses that?

Thanks,
smcv



Bug#871469: transition: ocaml

2017-09-25 Thread Stéphane Glondu

On 23/09/2017 15:52, Emilio Pozuelo Monfort wrote:

That's alright. I see this is already started and binNMUs are needed. Is someone
from the ocaml team handling these, or should I?


I am handling these.

Cheers,

--
Stéphane



Bug#871469: transition: ocaml

2017-09-23 Thread Emilio Pozuelo Monfort
On 14/09/17 15:44, Ximin Luo wrote:
> Stéphane Glondu:
>> On 15/08/2017 22:16, Emilio Pozuelo Monfort wrote:
>>> Control: tags -1 confirmed
>>> [...]
 ocaml 4.05.0 and a few selected packages have been uploaded to
 experimental and build fine on all architectures [3].
>>>
 So, basically, this transition is ready to be started from my point of
 view.

 I will take care of the necessary binNMUs.
>>>
>>> Go ahead.
>>
>> The transition in Fedora revealed an issue with native dynlink on arm64
>> [1]. The issue is being sorted out upstream [2]. Let's wait a bit. If
>> this is not fixed in one week, we'll upload ocaml with native dynlink
>> disabled on arm64.
>>
>> [1] https://pagure.io/releng/issue/6906
>> [2] https://github.com/ocaml/ocaml/pull/1268
>>
> Upstream fixed this "properly" so I've included that patch and done a new 
> upload to experimental. Everything seems OK so far, just waiting for slower 
> architectures to build.
> 
> Soon, I will upload to unstable and begin the transition. Let me know if you 
> need me to delay it further.

That's alright. I see this is already started and binNMUs are needed. Is someone
from the ocaml team handling these, or should I?

Cheers,
Emilio



Bug#871469: transition: ocaml

2017-09-19 Thread Katsuhiko Nishimra
Hi.

While Build-Depends-Arch is supported since Standards-Version 4.0.0, the
transition seems to be running without build-depends-arch in the
"Affected:" pattern.

Is that OK?

If it's OK, sorry for the noise.


signature.asc
Description: PGP signature


Bug#871469: transition: ocaml

2017-09-14 Thread Ximin Luo
Stéphane Glondu:
> On 15/08/2017 22:16, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 confirmed
>> [...]
>>> ocaml 4.05.0 and a few selected packages have been uploaded to
>>> experimental and build fine on all architectures [3].
>>
>>> So, basically, this transition is ready to be started from my point of
>>> view.
>>>
>>> I will take care of the necessary binNMUs.
>>
>> Go ahead.
> 
> The transition in Fedora revealed an issue with native dynlink on arm64
> [1]. The issue is being sorted out upstream [2]. Let's wait a bit. If
> this is not fixed in one week, we'll upload ocaml with native dynlink
> disabled on arm64.
> 
> [1] https://pagure.io/releng/issue/6906
> [2] https://github.com/ocaml/ocaml/pull/1268
> 
Upstream fixed this "properly" so I've included that patch and done a new 
upload to experimental. Everything seems OK so far, just waiting for slower 
architectures to build.

Soon, I will upload to unstable and begin the transition. Let me know if you 
need me to delay it further.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



Bug#871469: transition: ocaml

2017-08-16 Thread Stéphane Glondu
On 15/08/2017 22:16, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> [...]
>> ocaml 4.05.0 and a few selected packages have been uploaded to
>> experimental and build fine on all architectures [3].
> 
>> So, basically, this transition is ready to be started from my point of
>> view.
>>
>> I will take care of the necessary binNMUs.
> 
> Go ahead.

The transition in Fedora revealed an issue with native dynlink on arm64
[1]. The issue is being sorted out upstream [2]. Let's wait a bit. If
this is not fixed in one week, we'll upload ocaml with native dynlink
disabled on arm64.

[1] https://pagure.io/releng/issue/6906
[2] https://github.com/ocaml/ocaml/pull/1268


Cheers,

-- 
Stéphane



Bug#871469: transition: ocaml

2017-08-15 Thread Emilio Pozuelo Monfort
Control: tags -1 confirmed

On 08/08/17 10:32, Stéphane Glondu wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> We would like to update ocaml from 4.02.3 to 4.05.0. This is 3 major
> releases (and 2 years) ahead.
> 
> With current unstable, on amd64:
> - 9 source uploads (at least) are needed
> - 222 packages rebuild fine with no changes
> - 22 packages FTBFS with the new version
> - 18 packages cannot be rebuilt because one of their b-deps FTBFS
> 
> Among the latter 40 packages, 32 are in testing. Bug reports have been
> submitted for some of them [1] and patches are available. The
> remaining ones are pretty self-contained (no external reverse
> dependencies) and can be removed from testing if they get in the
> way. I've put details at [2].

Please file bugs for all of them.

> ocaml 4.05.0 and a few selected packages have been uploaded to
> experimental and build fine on all architectures [3].

> So, basically, this transition is ready to be started from my point of
> view.
> 
> I will take care of the necessary binNMUs.

Go ahead.

Cheers,
Emilio



Bug#871469: transition: ocaml

2017-08-08 Thread Stéphane Glondu
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

We would like to update ocaml from 4.02.3 to 4.05.0. This is 3 major
releases (and 2 years) ahead.

With current unstable, on amd64:
- 9 source uploads (at least) are needed
- 222 packages rebuild fine with no changes
- 22 packages FTBFS with the new version
- 18 packages cannot be rebuilt because one of their b-deps FTBFS

Among the latter 40 packages, 32 are in testing. Bug reports have been
submitted for some of them [1] and patches are available. The
remaining ones are pretty self-contained (no external reverse
dependencies) and can be removed from testing if they get in the
way. I've put details at [2].

ocaml 4.05.0 and a few selected packages have been uploaded to
experimental and build fine on all architectures [3].

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.05.0-transition;users=debian-ocaml-ma...@lists.debian.org
[2] http://ocaml.debian.net/debian/ocaml-4.05.0%2Brc1/
[3] 
https://buildd.debian.org/status/package.php?p=ocaml%2Ccamlp4%2Cfindlib%2Cocamlbuild=experimental=compact

So, basically, this transition is ready to be started from my point of
view.

I will take care of the necessary binNMUs.

Ben file:

title = "ocaml";
is_affected = .depends ~ /ocaml(-base)?(-nox)?-4.02.3/ | .depends ~ 
/ocaml(-base)?(-nox)?-4.05.0/;
is_good = .depends ~ /ocaml(-base)?(-nox)?-4.05.0/;
is_bad = .depends ~ /ocaml(-base)?(-nox)?-4.02.3/;


Cheers,

-- 
Stéphane

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)