Bug#1052239: transition: ocaml

[Stéphane Glondu]

Le 23/09/2023 à 06:54, Stéphane Glondu a écrit :

The following packages should be removed from testing for now:

   gmetadom otags xmlrpc-light mlpost ulex0.8 ocamlviz


I think Britney needs a little more help: the following packages should 
also be removed from testing:


  ocaml-http ocaml-lastfm ocamldap pcre-ocaml

(They are already flagged for autoremoval but that would complete in 3 
weeks while everything else is ready.)


And also, allow llvm-toolchain-13 (in particular, libllvm-13-ocaml-dev) 
to break.



Cheers,

--
Stéphane

Bug#1052239: transition: ocaml

[Stéphane Glondu]

Hi all,

Le 20/09/2023 à 09:44, Sebastian Ramacher a écrit :

Good. Please go ahead


I've uploaded ocaml 4.14.1-1 3 days ago, then uploaded camlp4, ocamlnet, 
a few other arch:all packages that could not be binNMUed, and binNMUed 
all the rest.


All packages, except the ones I had already spotted during my test 
rebuild, built fine on all release architectures:


  https://release.debian.org/transitions/html/ocaml.html

scilab's status is unrelated to this transition; there are open RC bugs 
for the other "bad" packages:



https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.14.1-transition;users=debian-ocaml-ma...@lists.debian.org

The following packages should be removed from testing for now:

  gmetadom otags xmlrpc-light mlpost ulex0.8 ocamlviz


There is also another issue I didn't foresee: the binary package 
libllvm-13-ocaml-dev would be broken in testing by the migration of 
ocaml 4.14.1. Its source package, llvm-toolchain-13, has been removed 
from unstable and cannot be removed from testing because of... Haskell!


libllvm-13-ocaml-dev has no reverse dependencies, though... Is it 
possible to remove just this one from testing as well? Or to explicitly 
allow its breakage?



The transition is also looking good on riscv64. For the convenience of 
riscv porters, I've set up a transition tracker for OCaml packages on 
this architecture:


  https://people.debian.org/~glondu/ben/ocaml.html


Cheers,

--
Stéphane

Bug#1052239: transition: ocaml

[Stéphane Glondu]

Le 20/09/2023 à 09:27, Sebastian Ramacher a écrit :

Based on https://release.debian.org/transitions/html/ocaml.html,
diffoscope is involved in both the ocaml and the uncoordinated haskell
transitions. Do we need rebuilds of diffoscope for ocaml?


Why does it matter?


If we would need them, diffoscope would entangle both transitions. As
haskell is currently showing no progress, both transitions would be
stuck in unstable indefinitely.


diffoscope doesn't seem really affected by the haskell transition 
either... Maybe it is related in the same way as ocaml? It does appear 
in the permanent transition trackers because the "affected" criteria is 
very broad there, but my guess is that it wouldn't appear in more 
targeted trackers.


As far as progress is concerned, I guess haskell and/or ocaml support 
can be (temporarily) removed from diffoscope, if a "stuck" condition 
arises, de-entangling everything.



Cheers,

--
Stéphane

Bug#1052239: transition: ocaml

[Stéphane Glondu]

Dear Sebastian,

Le 20/09/2023 à 08:48, Sebastian Ramacher a écrit :

I recompiled the OCaml world with it:

   http://ocaml.debian.net/transitions/ocaml-4.14.1/


Based on https://release.debian.org/transitions/html/ocaml.html,
diffoscope is involved in both the ocaml and the uncoordinated haskell
transitions. Do we need rebuilds of diffoscope for ocaml?


Why does it matter?

diffoscope uses ocaml tools to look into ocaml objects, it doesn't 
depend on ocaml ABI AFAIK. Although there indeed was #1002678 last time, 
I test-compiled diffoscope with the new ocaml version and it built fine.


Therefore, I don't think we need rebuilds of diffoscope.


Cheers,

--
Stéphane

Bug#1052239: transition: ocaml

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: oc...@packages.debian.org
Control: affects -1 + src:ocaml

Dear Release Team,

I uploaded ocaml 4.14.1 to experimental, and it built successfully on
all release architectures.

I recompiled the OCaml world with it:

  http://ocaml.debian.net/transitions/ocaml-4.14.1/

Note that I excluded scilab, llvm-toolchain-{14,15,16}, coq-unimath
and guestfs-tools, because they take too much time (and I don't expect
particular breakage there).

Not counting those, only 8 packages in testing FTBFS and one more has
a missing dependency. All of them could be removed from testing. Bugs
have been filed:

  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.14.1-transition;users=debian-ocaml-ma...@lists.debian.org

I hereby request a transition slot.


Ben file:

title = "ocaml";
is_affected = .depends ~ /ocaml(-base)?-4\.13\.1/ | .depends ~ 
/ocaml(-base)?-4\.14\.1/;
is_good = .depends ~ /ocaml(-base)?-4\.14\.1/;
is_bad = .depends ~ /ocaml(-base)?-4\.13\.1/;


Cheers,

-- 
Stéphane

Re: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild

[Stéphane Glondu]

Le 11/08/2023 à 20:53, Paul Gevers a écrit :
One current blocker is xmlrpc-light, which I mistakenly uploaded with 
urgency low 2 days ago, which therefore should not migrate before 8 
days from now.


It seems the connection is hidden. It would be nice if you could show 
how that works.


Look for "(not considered)" implicit dependencies with grep-excuses:

utop -> ocaml-logs/ppc64el -> ocaml-x509/ppc64el -> ocaml-zarith -> 
ocsigenserver/s390x -> xml-light -> xmlrpc-light


AFAIU, these 7 items (at least) need to migrate to testing together.

I am wondering: Couldn't the required age for xmlrpc-light be lowered? 
Or should I upload a new package with a higher urgency?


I have added an age hint and dropped required age to 5.


Thank you.


Cheers,

--
Stéphane

Re: src:utop: fails to migrate to testing for too long: blocked by ocaml-logs rebuild

[Stéphane Glondu]

Dear Paul,

On Thu, 10 Aug 2023 21:44:23 +0200 Paul Gevers  wrote:
[...]¨ Your package src:utop has been trying to migrate for 37 
days [2]. [...] > If you believe your package is unable to migrate to testing due to

issues beyond your control, don't hesitate to contact the Release Team.


One current blocker is xmlrpc-light, which I mistakenly uploaded with 
urgency low 2 days ago, which therefore should not migrate before 8 days 
from now.


I am wondering: Couldn't the required age for xmlrpc-light be lowered? 
Or should I upload a new package with a higher urgency?



Cheers,

--
Stéphane

Bug#1035728: unblock: ocsigenserver/5.0.1-1+b12

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ocsigenser...@packages.debian.org, 
debian-ocaml-ma...@lists.debian.org
Control: affects -1 + src:ocsigenserver

Dear Release Team,

Please unblock package ocsigenserver

The change is the addition of a missing Breaks+Replaces and should be
trivial.

unblock ocsigenserver/5.0.1-1+b12

Cheers,

-- 
Stéphane
diff -Nru ocsigenserver-5.0.1/debian/changelog 
ocsigenserver-5.0.1/debian/changelog
--- ocsigenserver-5.0.1/debian/changelog2022-01-23 12:54:32.0 
+0100
+++ ocsigenserver-5.0.1/debian/changelog2023-05-05 13:38:30.0 
+0200
@@ -1,3 +1,10 @@
+ocsigenserver (5.0.1-2) unstable; urgency=medium
+
+  * Add missing Breaks+Replaces for libocsigenserver-ocaml-dev
+(Closes: #1034938)
+
+ -- Stéphane Glondu   Fri, 05 May 2023 13:38:30 +0200
+
 ocsigenserver (5.0.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru ocsigenserver-5.0.1/debian/control ocsigenserver-5.0.1/debian/control
--- ocsigenserver-5.0.1/debian/control  2022-01-23 12:54:32.0 +0100
+++ ocsigenserver-5.0.1/debian/control  2023-05-05 13:38:30.0 +0200
@@ -53,6 +53,8 @@
  ${ocaml:Depends},
  ${shlibs:Depends},
  ${misc:Depends}
+Breaks: libocsigenserver-ocaml-dev (<< 5)
+Replaces: libocsigenserver-ocaml-dev (<< 5)
 Provides: ${ocaml:Provides}
 Suggests: ocaml-findlib
 Description: web server of the Ocsigen project (runtime libraries)

Bug#1034691: nmu: why3_1.5.1-1+b1 frama-c_20220511-manganese-3-10

[Stéphane Glondu]

Dear Sebastian,

Le 23/04/2023 à 11:36, Sebastian Ramacher a écrit :

ocaml 4.13.1-4 causes the ABI to change for at least why3. Do you expect
that the ABI of ther ocaml packages also changes? If so, we should
rebuild the ocaml world before the release to not get any surprises if a
ocaml package gets a stable update.


See also:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030785

The ABI of ocaml-compiler-libs changed (only on native architectures), 
with no visible changes in virtual packages, so anything using that is 
potentially broken. I (thought I) binNMUed all affected packages (there 
were a lot of them), but missed why3 for some reason.


IMHO, the cleanest way to fix the issue for sure is to change the OCaml 
ABI advertised in the virtual package name. But that means an amount of 
work similar to an OCaml transition. Do we really work this kind of move 
at this stage of the freeze? I don't think so.


A pretty good approximation to checking that everything is fine is to 
mass-rebuild everything (as Lucas Nussbaum does regularly), identify the 
(few, I expect) packages that FTBFS, and binNMU them (+ maybe some of 
their dependencies). I suspect why3 is special because it embeds modules 
provided by ocaml in a plugin (dh_ocaml's --nodefined-map is suspicious 
in this context) but this situation should be rare.



Cheers,

--
Stéphane

Re: xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED [and 1 more messages]

[Stéphane Glondu]

Dear Ian,

Le 06/02/2023 à 11:41, Ian Jackson a écrit :

ftpmaster REJECTed it:

there is an ocaml stack rebuild[1] at them moment, where xen is a part of.
So please upload to experimental.


I am as surprised as you by this rejection reason...


[1] https://release.debian.org/transitions/html/ocaml.html


I am responsible for this one :-)

OCaml stack rebuilds happen routinely. They rarely pose problems (as far 
as I can tell). When I initiate one, I actively monitor it.



Could you please advise is what the proper way is for us to interact
with ocaml transitions ?  When, if at all, should we wait with
uploading to unstable ?
[...]
Please let us know by this time tomorrow if there's any reason not to
do that.


As far as xen is concerned, it depends only on ocaml and findlib, and 
has no reverse-dependencies (in OCaml land). It should not pose any 
problems in general, and does not (as far as I can tell) in the current 
case.



Cheers,

--
Stéphane

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Le 25/01/2022 à 05:39, Stéphane Glondu a écrit :
>>> - ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
>>> deprecated, should be removed from testing
>>
>> That would also require removal of:
>>
>> coq-elpi
>> coq-hierarchy-builder
>> elpi
>> haxe
>> liquidsoap
>> mercurial-buildpackage
>> morbig
>> morsmall
>> node-carto
>> node-hsluv
>> ocaml-sedlex
>> ocaml-visitors
>> pgocaml
>> ppx-deriving
>> ppx-deriving-yojson
> 
> Packages that used to depend on ppx-tools-versioned and/or ppxfind (in
> testing) do no longer in their 4.13.1-compatible version (in
> unstable)... That's why I said they seem deprecated.
> 
> In current unstable, the only reverse-dependencies that remain are eliom
> and nurpawiki:
> 
>> glondu@coccia:~$ dak rm -Rn -s unstable ppx-tools-versioned ppxfind eliom 
>> nurpawiki
>> Will remove the following packages from unstable:
>> [...]
>> Checking reverse dependencies...
>> No dependency problem found.

Now, I can simulate a successful migration of ocaml (and 273 other
packages (including binNMUs)) if ppx-tools-versioned is removed at the
same time...


Cheers,

-- 
Stéphane

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Le 24/01/2022 à 23:31, Sebastian Ramacher a écrit :
>> - ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
>> deprecated, should be removed from testing
> 
> That would also require removal of:
> 
> coq-elpi
> coq-hierarchy-builder
> elpi
> haxe
> liquidsoap
> mercurial-buildpackage
> morbig
> morsmall
> node-carto
> node-hsluv
> ocaml-sedlex
> ocaml-visitors
> pgocaml
> ppx-deriving
> ppx-deriving-yojson

Packages that used to depend on ppx-tools-versioned and/or ppxfind (in
testing) do no longer in their 4.13.1-compatible version (in
unstable)... That's why I said they seem deprecated.

In current unstable, the only reverse-dependencies that remain are eliom
and nurpawiki:

> glondu@coccia:~$ dak rm -Rn -s unstable ppx-tools-versioned ppxfind eliom 
> nurpawiki
> Will remove the following packages from unstable:
> [...]
> Checking reverse dependencies...
> No dependency problem found.


Cheers,

-- 
Stéphane

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Le 19/01/2022 à 09:34, Sebastian Ramacher a écrit :
> The libguestfs build for the php8.1 transition migrated, so this
> transition can proceed. Please go ahead.

5 days later, most of packages have been rebuilt with the new OCaml. The
remaining outliers are:

- hol-light (#1002983): the fix is not trivial and upstream doesn't seem
interested in supporting a modern toolchain, should be removed from
testing for the time being
- otags (#1002940): seems dead upstream, should be removed from testing
for the time being
- ppx-tools-versioned (#1002941), ppxfind (#1002942): they seem
deprecated, should be removed from testing
- sks (#1002657): a patch is available
- llvm-toolchain-11 (#1002607), llvm-toolchain-12 (#1002608): the fix is
trivial
- eliom: a new upstream release is available, but it needs ocsipersist
which is sitting in NEW... can be removed temporarily from testing if needed
- nurpawiki: depends on eliom, can be removed temporarily from testing
if needed
- llvm-toolchain-9: not in testing... as far as I understand, should be
removed from Debian altogether
- why3, frama-c: not in testing... FTBFS at the moment, but should be
fixed in the future


Cheers,

-- 
Stéphane

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Control: tags -1 - moreinfo

Le 09/01/2022 à 17:49, Sebastian Ramacher a écrit :
> Please remove the moreinfo tag once ocaml-odoc-parser has been accepted.

It has been yesterday.

I think this transition is ready to be started.

As usual, I will take care of binNMUs.


Cheers,

-- 
Stéphane

Bug#1002681: transition: ocaml

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear Release Team,

I've updated ocaml to 4.13.1 (released on 2021-10-01) and uploaded to
experimental. It builds on all release architectures, and most of
ports as well.

Version currently in unstable is 4.11.1 (released on 2020-09-01).

I've tried to rebuild all related packages with the new version, and
the breakage is minimal:

  https://ocaml.debian.net/transitions/ocaml-4.13.1/

A new version of ocaml-odoc is required, and it depends on a package
(ocaml-odoc-parser) which is in the NEW queue. When it is accepted, I
think we can proceed to updating OCaml in unstable.


Ben file:

title = "ocaml";
is_affected = .depends ~ "ocaml.*4\.11\.1" | .depends ~ "ocaml.*4\.13\.1";
is_good = .depends ~ "ocaml.*4\.13\.1";
is_bad = .depends ~ "ocaml.*4\.11\.1";


Cheers,

-- 
Stéphane

Bug#1001441: Please override urgency of lwt and ocplib-endian

[Stéphane Glondu]

Package: release.debian.org
Severity: normal

Dear Release Team,

I've just realized that I've uploaded lwt and ocplib-endian with
urgency=low instead of medium, setting their testing migration delay
to 10 days.

Now, 5 days have past, and these two packages seem to block the
migration of 50 other packages (including binNMUs [1]), which are
otherwise ready. This puts the Debian OCaml world in a delicate
situation similar to a never-ending transition.

Could you reduce the testing migration delay of lwt and ocplib-endian
to 5 days, please?

[1] ben bin-prot dochelp dose3 eliom fieldslib janest-base
janest-ocaml-compiler-libs js-of-ocaml lambda-term lwt lwt-log lwt-ssl
morbig morsmall nproc nurpawiki obus ocaml-cstruct ocaml-domain-name
ocaml-hex ocaml-inotify ocaml-ipaddr ocaml-odoc ocaml-parsexp ocaml-re
ocaml-stdio ocaml-usb ocaml-visitors ocplib-endian ocsigenserver ocurl
parmap pgocaml ppx-bin-prot ppx-compare ppx-custom-printf ppx-deriving
ppx-deriving-yojson ppx-fields-conv ppx-here ppx-optcomp ppx-sexp-conv
ppx-variants-conv ppxlib sexplib310 typerep tyxml utop variantslib


Cheers,

-- 
Stéphane

Bug#1000632: RM: coq/8.12.0-3+b3 and others

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear Release Managers,

#1000573 prevents a bunch of packages [1] from migrating to
testing. It would makes things better if coq and some related packages
[2] could be removed from testing.

[1] 17 packages (including binNMUs): alt-ergo ben botch camlimages
coinst cryptokit cudf dose3 eliom extlib js-of-ocaml nurpawiki
ocaml-base64 ocaml-graphics ocaml-mccs ocaml-zarith ocsigenserver

[2] Easy hint: -coq -frama-c -prooftree -ssreflect -why3


Cheers,

-- 
Stéphane

Bug#971415: transition: ocaml

[Stéphane Glondu]

Le 16/10/2020 à 11:31, Stéphane Glondu a écrit :
> I have scheduled all binNMUs and uploaded the necessary packages, and
> most of packages have been built now.
> 
> IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
> ppc64el. The other issues concern packages that are not in testing, or
> can be removed from testing.

llvm has been fixed. Everything seems in place to complete this
transition, except for this autopkgtest failure (according to
tracker.debian.org):

> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference ♻), 
> arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: 
> Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)

However, I don't understand why it complains about
ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does
something need to be done?


Cheers,

-- 
Stéphane

Bug#971415: transition: ocaml

[Stéphane Glondu]

Le 12/10/2020 à 09:57, Sebastian Ramacher a écrit :
 I tried to install all corresponding opam packages in a 4.11.1 switch,
 and the breakage is minimal.
>>>
>>> Have bugs been filed for the these issues or are you taking care of
>>> that?
>>
>> I will take care of filing bugs and/or fixing issues. And as usual, I
>> will also take care of binNMUs.
> 
> Great, please go ahead.

I have scheduled all binNMUs and uploaded the necessary packages, and
most of packages have been built now.

IMHO, the major blocker for now are llvm-toolchain-{9,10} which FTBFS on
ppc64el. The other issues concern packages that are not in testing, or
can be removed from testing.

I've gathered relevant bug reports there:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.11.1-transition;users=debian-oc...@lists.debian.org


Cheers,

-- 
Stéphane

Bug#971415: transition: ocaml

[Stéphane Glondu]

Le 10/10/2020 à 17:58, Sebastian Ramacher a écrit :
>> I tried to install all corresponding opam packages in a 4.11.1 switch,
>> and the breakage is minimal.
> 
> Have bugs been filed for the these issues or are you taking care of
> that?

I will take care of filing bugs and/or fixing issues. And as usual, I
will also take care of binNMUs.


Cheers,

-- 
Stéphane

Bug#971415: transition: ocaml

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear Release Team,

I've updated ocaml to 4.11.1 and uploaded to experimental. It builds on
all release architectures, and most of ports as well (fixes for
hurd-i386 are pending, and it's still not built on kfreebsd-*).

The main change as far as Debian is concerned is the split of the
graphics library, which I packaged (as ocaml-graphics) and has been
accepted.

I tried to install all corresponding opam packages in a 4.11.1 switch,
and the breakage is minimal.

Therefore, I think we can proceed to updating OCaml in unstable.


Cheers,

-- 
Stéphane

Ben file:

title = "ocaml";
is_affected = .depends ~ "ocaml.*4\.08\.1" | .depends ~ "ocaml.*4\.11\.1";
is_good = .depends ~ "ocaml.*4\.11\.1";
is_bad = .depends ~ "ocaml.*4\.08\.1";


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#951761: buster-pu: package opam/2.0.3-1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Dear Release Managers,

It has been brought to my attention that opam doesn't work in buster
out of the box. This has been tracked in [1] (fixed in testing) and
[2]. See in particular comments starting at [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908203
[2] https://github.com/ocaml/opam/issues/3827
[3] https://github.com/ocaml/opam/issues/3827#issuecomment-586265289

Martin Lucina (@mato on GitHub) proposed some changes to improve the
situation.

I've attached the proposed changes. I would like to apply them in a
buster update.


Cheers,

-- 
Stéphane


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

Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru opam-2.0.3/debian/changelog opam-2.0.3/debian/changelog
--- opam-2.0.3/debian/changelog 2019-02-01 12:05:09.0 +0100
+++ opam-2.0.3/debian/changelog 2020-02-18 07:42:31.0 +0100
@@ -1,3 +1,10 @@
+opam (2.0.3-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Prefer mccs over aspcud (Closes: #908203)
+
+ -- Stéphane Glondu   Tue, 18 Feb 2020 07:42:31 +0100
+
 opam (2.0.3-1) unstable; urgency=medium
 
   * New (bugfix) upstream release
diff -Nru opam-2.0.3/debian/control opam-2.0.3/debian/control
--- opam-2.0.3/debian/control   2019-02-01 10:13:14.0 +0100
+++ opam-2.0.3/debian/control   2020-02-18 07:37:20.0 +0100
@@ -22,7 +22,7 @@
  libopam-file-format-ocaml-dev,
  libjsonm-ocaml-dev,
  libopam-file-format-ocaml-dev,
- aspcud,
+ mccs,
  rsync,
  unzip,
  openssl,
@@ -50,7 +50,7 @@
  ${misc:Depends},
  opam-doc (= ${source:Version}),
  build-essential,
- aspcud | mccs | packup,
+ mccs,
  opam-installer,
  bubblewrap [linux-any],
  unzip,
diff -Nru opam-2.0.3/debian/gbp.conf opam-2.0.3/debian/gbp.conf
--- opam-2.0.3/debian/gbp.conf  2018-12-02 12:53:29.0 +0100
+++ opam-2.0.3/debian/gbp.conf  2020-02-18 07:33:43.0 +0100
@@ -8,3 +8,5 @@
 "src_ext",
 "ocp-build"
 ]
+debian-branch = buster/master
+upstream-branch = buster/upstream
diff -Nru opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch 
opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch
--- opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch
1970-01-01 01:00:00.0 +0100
+++ opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch
2020-02-18 07:40:53.0 +0100
@@ -0,0 +1,25 @@
+From: Martin Lucina 
+Date: Tue, 18 Feb 2020 07:37:04 +0100
+Subject: Prefer mccs over aspcud
+
+Bug-Debian: https://bugs.debian.org/908203
+Bug: https://github.com/ocaml/opam/issues/3827
+Origin: https://github.com/ocaml/opam/issues/3827#issuecomment-586945810
+---
+ src/solver/opamCudfSolver.ml | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/solver/opamCudfSolver.ml b/src/solver/opamCudfSolver.ml
+index 03486f1..b3b8aa6 100644
+--- a/src/solver/opamCudfSolver.ml
 b/src/solver/opamCudfSolver.ml
+@@ -215,8 +215,8 @@ let make_custom_solver name args criteria =
+ 
+ let default_solver_selection =
+   OpamBuiltinMccs.all_backends @ [
+-(module Aspcud: S);
+ (module Mccs: S);
++(module Aspcud: S);
+ (module Aspcud_old: S);
+ (module Packup: S);
+   ]
diff -Nru opam-2.0.3/debian/patches/series opam-2.0.3/debian/patches/series
--- opam-2.0.3/debian/patches/series2019-02-01 12:04:22.0 +0100
+++ opam-2.0.3/debian/patches/series2020-02-18 07:40:53.0 +0100
@@ -1,2 +1,3 @@
 0002-Add-a-test-target.patch
 0002-Fix-spelling-error-in-manpage.patch
+0003-Prefer-mccs-over-aspcud.patch

Re: Autopkgtest preventing ocaml-dune from migrating to testing

[Stéphane Glondu]

Hello,

Le 03/02/2020 à 21:05, Paul Gevers a écrit :
>> Currently, ocaml-dune/2.1.3-1 is blocked in unstable because of
>> autopkgtest failure of ocaml-sedlex/2.1-3. However, this test failure
>> has been fixed in ocaml-sedlex/2.1-4. Likewise, ocaml-sedlex/2.1-4 is
>> bloked in unstable because of autopkgtest failure of itself, but this
>> test has been done with ocaml-dune/1.11.0-2 (i.e. the testing version)
>> instead of the unstable version.
>>
>> What can be done to unblock the situation?
> 
> If the issue is only with the autopkgtest, than from our point of view,
> ideally one (or both) gains a breaks on the version of the other package
> in testing. If that happens, our migration software is able to schedule
> the right combination of tests. However, we realize that sometime
> maintainers consider such a breaks too strong. Then the only way
> currently is that we manually help the package.
> 
> Are you willing to add such a breaks to either package?

Yes, I added some breaks, and the packages migrated.

Thanks for the hint!

-- 
Stéphane

Autopkgtest preventing ocaml-dune from migrating to testing

[Stéphane Glondu]

Dear Release Managers,

Currently, ocaml-dune/2.1.3-1 is blocked in unstable because of
autopkgtest failure of ocaml-sedlex/2.1-3. However, this test failure
has been fixed in ocaml-sedlex/2.1-4. Likewise, ocaml-sedlex/2.1-4 is
bloked in unstable because of autopkgtest failure of itself, but this
test has been done with ocaml-dune/1.11.0-2 (i.e. the testing version)
instead of the unstable version.

What can be done to unblock the situation?


Cheers,

-- 
Stéphane

Bug#941907: transition: ocaml

[Stéphane Glondu]

Le 16/11/2019 à 21:28, Paul Gevers a écrit :
>> Let's see where we are when all ages are fine.
> 
> I'm failing to (quickly) see why ocaml doesn't want to migrate. Does
> anybody already have some foo laying around to see what the problem is?
> I'm only seeing ocaml in the autohinter section, while I expected in the
> regular section.

Now, I see the following reasons:
- hivex is too young
- lwt is blocked because arch:all packages are not built... but there
are no longer arch:all packages (I don't know what can be done here, I
assumed cruft packages were automatically removed at some point)
- llvm-toolchain-8 FTBFS on mips* (I've reported #944844)
- llvm-toolchain-9 is waiting for piuparts


Cheers,

-- 
Stéphane

Bug#941907: transition: ocaml

[Stéphane Glondu]

Hi,

Le 12/11/2019 à 20:24, Paul Gevers a écrit :
>> Here is a status update after 8 days.
>>
>> Most of the packages have been updated or rebuilt. For the few
>> exceptions, bugs have been filed and all of the concerned packages
>> (except llvm-toolchain-8) can be removed from testing.
> 
> I am not too familiar with the ocaml way of working, but does everything
> needs to be rebuild before it can migrate? If so we can remove those
> packages once the llvm-toolchain-8 issue is fixed.

Yes. You can remove all red packages in [1] + meta-ocaml (which depends
on pxp). Note that lwt, which is orange (because of cruft liblwt-ssl-*),
should not be removed.

[1] https://release.debian.org/transitions/html/ocaml-4.08.1.html

>> So the main blocker now is llvm-toolchain-8 with #943920.
> 
> Thanks for the update. Are you aware of the other migration blockers?
> See https://qa.debian.org/excuses.php?package=ocaml

Yes. I've fixed some of those and I've reported #944709.


Cheers,

-- 
Stéphane

Bug#941907: transition: ocaml

[Stéphane Glondu]

block 941907 by 943920
thanks

Le 04/11/2019 à 13:50, Stéphane Glondu a écrit :
>> Please go ahead.
> 
> Started.

Here is a status update after 8 days.

Most of the packages have been updated or rebuilt. For the few
exceptions, bugs have been filed and all of the concerned packages
(except llvm-toolchain-8) can be removed from testing.

So the main blocker now is llvm-toolchain-8 with #943920.


Cheers,

-- 
Stéphane

Bug#941907: transition: ocaml

[Stéphane Glondu]

Le 03/11/2019 à 21:06, Paul Gevers a écrit :
> On 07-10-2019 15:50, Stéphane Glondu wrote:
>> I think it's time to upgrade OCaml to 4.08.1.
>>
>> It has been uploaded to experimental, and builds fine on all release
>> architectures. [1]
>>
>> Most of reverse-dependencies recompile fine with no changes (on
>> amd64). [2]
>>
>> Bug reports have been (or will be) reported for the few packages that
>> need action. [3]
>>
>> [1] https://buildd.debian.org/status/package.php?p=ocaml=experimental
>> [2] https://ocaml.debian.net/transitions/ocaml-4.08.0/
> 
> This link never works for me.

Maybe it is because it is reachable via IPv6 only?

>> [3] 
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.08-transition;users=debian-ocaml-ma...@lists.debian.org
>>
>> I will take care of the necessary binNMUs.
> 
> Please go ahead.

Started.


Cheers,

-- 
Stéphane

Bug#941907: transition: ocaml

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

I think it's time to upgrade OCaml to 4.08.1.

It has been uploaded to experimental, and builds fine on all release
architectures. [1]

Most of reverse-dependencies recompile fine with no changes (on
amd64). [2]

Bug reports have been (or will be) reported for the few packages that
need action. [3]

[1] https://buildd.debian.org/status/package.php?p=ocaml=experimental
[2] https://ocaml.debian.net/transitions/ocaml-4.08.0/
[3] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ocaml-4.08-transition;users=debian-ocaml-ma...@lists.debian.org

I will take care of the necessary binNMUs.

Ben file:

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


Cheers,

-- 
Stéphane

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#934872: RM: ocaml-usb/1.3.0-4 ocaml-sqlexpr/0.5.5-3 zeroinstall-injector/2.12.3-2 obus/1.1.5-6

[Stéphane Glondu]

Le 21/08/2019 à 20:07, Thomas Leonard a écrit :
>> Again, this removal from testing is not a definitive removal from Debian
>> and may be just temporary. I didn't mean to be hostile.
> 
> Do you have an idea of when this will be? I should be able to look at
> a workaround this weekend if it's not back by then.

I expect it will take a few months before obus is in testing again. Note
that I've also dropped liblwt-glib-ocaml-dev (as it is separate in newer
upstream version of lwt which also needs to be updated), so you'll have
to workaround that as well.


Cheers,

-- 
Stéphane

Bug#934872: RM: ocaml-usb/1.3.0-4 ocaml-sqlexpr/0.5.5-3 zeroinstall-injector/2.12.3-2 obus/1.1.5-6

[Stéphane Glondu]

Le 21/08/2019 à 18:26, Thomas Leonard a écrit :
>> Please remove the following packages from testing:
>>
>>  * ocaml-usb, affected by #933993
>>  * ocaml-sqlexpr, affected by #933994
>>  * zeroinstall-injector, affected by #934340
>>  * obus, affected by #933992
> 
> Hi,
> 
> I'm the maintainer of zeroinstall-injector and I just got notified
> that it was removed and found this issue. I believe that this removal
> was done in error.
> 
> As I explained in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934340, there is no
> need to remove obus, which has made a new release without a camlp4
> dependency (and also, camlp4 itself is now compatible with the new
> OCaml and therefore does not need to be removed).

It might be compatible, but is still deprecated upstream. Its future is
unclear. Nobody volunteered to maintain it. We are still strongly
encouraged by upstream to get rid of it (and Fedora already did it).
Once OCaml 4.08.x hits testing, my plan is to be more aggressive about
removing it. For now, I just get rid of what gets in the way of updating
other packages.

> The message there says "The new version depends on (at least) two NEW
> packages (lwt_log and ppxlib), and the NEW queue backlog is pretty big
> now." but I don't believe the length of the NEW queue is a good reason
> to remove working packages.

It's removed from testing only. I don't believe the length of the NEW
queue is a good reason to stop working at all if it is possible to
progress otherwise.

> It is possible to get the zeroinstall package (at least the binaries)
> restored to testing while this issue is fixed?

I don't believe so, but I don't have authority here. Anyway, I won't
reinstate the camlp4 dependency in lwt, I'd rather update lwt which is
pretty old now but that is not possible at the moment.

>> They prevent 62 other packages from migrating to testing. They are
>> already marked for autoremoval, but too far in the future.
> 
> It was only marked for autoremoval due to this exact issue. Surely the
> purpose of the time delay is to let these things be fixed properly?

So your suggestion was to freeze activity until the packages were
automatically removed from testing? I firmly believe that accelerating
the removal from testing was legitimate here. Your package can migrate
back to testing later.

> https://wiki.debian.org/ftpmaster_Removals seems to indicate that a
> maintainer should be given several weeks notice before their package
> is removed.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934340#17 was posted 8
days before the removal and got not reply, so I thought you were OK with
this.

Again, this removal from testing is not a definitive removal from Debian
and may be just temporary. I didn't mean to be hostile.


Cheers,

-- 
Stéphane

Re: Haskell binnmus is there a problem?

[Stéphane Glondu]

Le 21/08/2019 à 10:14, Mattia Rizzolo a écrit :
>> I used to schedule these, but for many months it seems it wasn't
>> necessary, not sure if someone else scheduled them
> 
> At the very least, quite some times pochu did them the last year, fwiw.
> 
>> Going forward, it is not sustainable for this to depend on manual
>> interaction by me. We at least need to allow a more active member of
>> the Haskell team do these, or finally automate this tedious task.
> 
> It's the problem all statically liked languages have, be that haskell,
> ocaml, or the "new" golang (that came to the spotlight due to a somewhat
> worse implementation than the other two).  Please do try to coordinate
> and decide on a sane method to process auto-binNMUs or something like
> that.

As far as ocaml is concerned, it is not due to the language being
"statically linked", but to the strict and automatic ABI checking (and
no notion of backward compatibility at the ABI level). We would have the
same problem (maybe even worse) if the language was dynamically linked.


Cheers,

-- 
Stéphane

Bug#934872: RM: ocaml-usb/1.3.0-4 ocaml-sqlexpr/0.5.5-3 zeroinstall-injector/2.12.3-2 obus/1.1.5-6

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Dear Release Managers,

Please remove the following packages from testing:

 * ocaml-usb, affected by #933993
 * ocaml-sqlexpr, affected by #933994
 * zeroinstall-injector, affected by #934340
 * obus, affected by #933992

They prevent 62 other packages from migrating to testing. They are
already marked for autoremoval, but too far in the future.


Cheers,

-- 
Stéphane

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

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

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Stéphane Glondu]

Le 07/07/2019 à 03:47, Jonathan Wiltshire a écrit :
> No binary maintainer uploads for bullseye
> =
> 
> The release of buster also means the bullseye release cycle is about to begin.
> From now on, we will no longer allow binaries uploaded by maintainers to
> migrate to testing. This means that you will need to do source-only uploads if
> you want them to reach bullseye.
> 
> 
>   Q: I already did a binary upload, do I need to do a new (source-only) 
> upload?
>   A: Yes (preferably with other changes, not just a version bump).
> 
>   Q: I needed to do a binary upload because my upload went to the NEW queue,
>  do I need to do a new (source-only) upload for it to reach bullseye?
>   A: Yes. We also suggest going through NEW in experimental instead of 
> unstable
>  where possible, to avoid disruption in unstable.
> 
>   Q: Does this also apply to contrib and non-free?
>   A: No. Not all packages in contrib and non-free can be built on the buildds,
>  so maintainer uploads will still be allowed to migrate for packages
>  outside main.

Q: BinNMUs of packages uploaded before this new policy that have
   arch:all binaries can no longer migrate to testing. Is that
   intentional?

See for example ocaml-migrate-parsetree/amd64 (there are others).

This will make transitions that involve lots of binNMUs (such as
OCaml-related ones) much harder. For example, there is one such ongoing
(mini-)transition involving ocaml-migrate-parsetree, 26 other binNMUed
packages, and 7 updated packages. It will be delayed by the time to
upload all these binNMUed package and their aging. Meanwhile, this
transition may become bigger and longer as people unaware of this update
their OCaml-related packages.

Is there a public API to query the built-on-buildd flag for a given
binary package?


Cheers,

-- 
Stéphane

Please CC: me or debian-ocaml-maint on reply

Bug#899189: nmu: unison_2.48.3-1

[Stéphane Glondu]

On 06/07/2018 03:15, Cyril Brulebois wrote:
>> For the sake of completeness, here's an extra data point. If someone
>> ends up with two peers with versions 2.48.3-1 vs. 2.48.3-1+b1 (hosts
>> with s-p-u enabled, but not dist-upgraded at the same time), one can
>> get this very issue:
>> | Uncaught exception Failure("input_value: bad bigarray kind")

This is expected.

>> with extra unfriendly debug messages (hey, look at those in the github
>> bug tracker, the ones we wanted to get rid of).
>>
>> I thought I'd mention the possibly surprising outcome for people not
>> following debian-release@ closely.
> 
> Also, that seems to completely invalidate the on-disk cache, which is
> likely the reason why the first run with an upgraded version (on either
> side, by the way) can take several (dozens of) minutes instead of a
> couple of seconds.

Indeed. Care must be taken at each upgrade of Unison, I think Unison
users are aware of that. This is not specific to Debian. What was
specific to Debian was the situation of Unison compiled with a version
of OCaml different from the one that is being distributed alongside,
which this binNMU is meant to fix.

> It might have been a good idea to mention that in the binNMU request. It
> might also be a good idea to document those consequences in some way.

Sorry. Where would be a good place to document this, now?


Cheers,

-- 
Stéphane

Bug#899189: nmu: unison_2.48.3-1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

Currently, Unison in Stretch is compiled with OCaml 4.01.0 (at least
on i386), while OCaml in Stretch is 4.02.3. This triggers a subtle
interoperability bug more often than it should, and led to too much
lost time in my opinion (e.g. see [1] and [2]).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802919
[2] https://github.com/bcpierce00/unison/issues/94

I don't know if it is acceptable to do binNMUs in stable (I probably
can do it myself), so I'm asking here :-)

nmu unison_2.48.3-1 . ANY . stretch . -m "Recompile with ocaml version in 
stretch"

Cheers,

-- 
Stéphane

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

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

Bug#871469: Status of llvm-toolchain-3.8?

[Stéphane Glondu]

On 30/10/2017 10:39, Stéphane Glondu wrote:

Is there any plans to fix llvm-toolchain-3.8?


I wish we could removed it but it is far from ready (we were blocked by
the ocaml transition but I dropped the ocaml support to mitigate that)
I will try to fix that in the next few days.
Sorry about that


I saw that you removed the OCaml bindings (libllvm-3.8-ocaml-dev) from 
llvm-toolchain-3.8, but there is still libllvm-ocaml-dev (from 
llvm-defaults) that depends on libllvm-3.8-ocaml-dev.


I think you need to remove libllvm-ocaml-dev from llvm-defaults to 
disentangle LLVM and OCaml.


llvm-toolchain-3.8 FTBFS on armel and armhf, so it cannot migrate to 
testing. This situation blocks ocaml.


My attempts to find a solution to this were not very satisfactory... I 
think that changing llvm-defaults meta-packages to llvm > 3.8 (a version 
that does not FTBFS, so >= 4.0) can help.



Cheers,

--
Stéphane

Bug#871469: Status of llvm-toolchain-3.8?

[Stéphane Glondu]

On 20/10/2017 10:27, Sylvestre Ledru wrote:

At the moment, llvm-toolchain-3.8 FTBFS with "gcc-7.2: Command not
found" and this blocks the OCaml transition.

I see there are already bugs open related to gcc-7 (#871011 and
#853523), but these do not have recent activity.

I also see that this package has been requested to be removed
(#873331), but again no recent activity on this bug.

Is there any plans to fix llvm-toolchain-3.8?


I wish we could removed it but it is far from ready (we were blocked by
the ocaml transition but I dropped the ocaml support to mitigate that)
I will try to fix that in the next few days.
Sorry about that


I saw that you removed the OCaml bindings (libllvm-3.8-ocaml-dev) from 
llvm-toolchain-3.8, but there is still libllvm-ocaml-dev (from 
llvm-defaults) that depends on libllvm-3.8-ocaml-dev.


I think you need to remove libllvm-ocaml-dev from llvm-defaults to 
disentangle LLVM and OCaml.


Cheers,

--
Stéphane

Bug#871469: Status of llvm-toolchain-3.8?

[Stéphane Glondu]

Hello,

At the moment, llvm-toolchain-3.8 FTBFS with "gcc-7.2: Command not 
found" and this blocks the OCaml transition.


I see there are already bugs open related to gcc-7 (#871011 and 
#853523), but these do not have recent activity.


I also see that this package has been requested to be removed (#873331), 
but again no recent activity on this bug.


Is there any plans to fix llvm-toolchain-3.8?


Cheers,

--
Stéphane

Bug#871469: transition: ocaml

[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

[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

[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

[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)

Bug#870336: Helping migration of camlp5, lablgtk2, etc.

[Stéphane Glondu]

Package: release.debian.org
Severity: normal

Dear RT,

camlp5, lablgtk2 and other packages have been waiting for migration to
testing for a while. Their migration is essentially blocked by
hol-light and botch which FTBFS at the moment.

Here are hints to make things evolve (courtesy of comigrate):

age-days 4 frama-c/20161101+silicon+dfsg-6
age-days 3 pxp/1.2.9-1
age-days 3 utop/1.19.3-2
easy aac-tactics/amd64/8.6.1-1 aac-tactics/arm64/8.6.1-1 
aac-tactics/armel/8.6.1-1 aac-tactics/armhf/8.6.1-1 aac-tactics/i386/8.6.1-1 
aac-tactics/mips/8.6.1-1 aac-tactics/mips64el/8.6.1-1 
aac-tactics/mipsel/8.6.1-1 aac-tactics/ppc64el/8.6.1-1 
aac-tactics/s390x/8.6.1-1 advi/mips/1.10.2-3 advi/mips64el/1.10.2-3 
advi/mipsel/1.10.2-3 advi/ppc64el/1.10.2-3 advi/s390x/1.10.2-3 
alt-ergo/mips/1.30-1 alt-ergo/mips64el/1.30-1 alt-ergo/mipsel/1.30-1 
alt-ergo/ppc64el/1.30-1 alt-ergo/s390x/1.30-1 ara/1.0.33 belenios/1.4+dfsg-2 
ben/0.7.7 -botch/0.21-3 cairo-ocaml/amd64/1:1.2.0-6 cairo-ocaml/arm64/1:1.2.0-6 
cairo-ocaml/armel/1:1.2.0-6 cairo-ocaml/armhf/1:1.2.0-6 
cairo-ocaml/i386/1:1.2.0-6 cairo-ocaml/mips/1:1.2.0-6 
cairo-ocaml/mips64el/1:1.2.0-6 cairo-ocaml/mipsel/1:1.2.0-6 
cairo-ocaml/ppc64el/1:1.2.0-6 cairo-ocaml/s390x/1:1.2.0-6 
camlimages/amd64/1:4.2.0-1.1 camlimages/arm64/1:4.2.0-1.1 
camlimages/armel/1:4.2.0-1.1 camlimages/armhf/1:4.2.0-1.1 
camlimages/i386/1:4.2.0-1.1 camlimages/mips/1:4.2.0-1.1 
camlimages/mips64el/1:4.2.0-1.1 camlimages/mipsel/1:4.2.0-1.1 
camlimages/ppc64el/1:4.2.0-1.1 camlimages/s390x/1:4.2.0-1.1 camlp5/7.01-1 
camomile/0.8.5-1 cduce/amd64/0.6.0-5 cduce/arm64/0.6.0-5 cduce/armel/0.6.0-5 
cduce/armhf/0.6.0-5 cduce/i386/0.6.0-5 coinst/mips/1.9.3-1 
coinst/mips64el/1.9.3-1 coinst/mipsel/1.9.3-1 coinst/ppc64el/1.9.3-1 
coinst/s390x/1.9.3-1 coq/amd64/8.6-4 coq/arm64/8.6-4 coq/armel/8.6-4 
coq/armhf/8.6-4 coq/i386/8.6-4 coq/mips/8.6-4 coq/mips64el/8.6-4 
coq/mipsel/8.6-4 coq/ppc64el/8.6-4 coq/s390x/8.6-4 cryptokit/1.11-1 
dose3/5.0.1-9 eliom/amd64/4.2-3 eliom/arm64/4.2-3 eliom/armel/4.2-3 
eliom/armhf/4.2-3 eliom/i386/4.2-3 eliom/mips/4.2-3 eliom/mips64el/4.2-3 
eliom/mipsel/4.2-3 eliom/ppc64el/4.2-3 eliom/s390x/4.2-3 
frama-c/20161101+silicon+dfsg-6 freetennis/mips/0.4.8-10 
freetennis/mips64el/0.4.8-10 freetennis/mipsel/0.4.8-10 
freetennis/ppc64el/0.4.8-10 freetennis/s390x/0.4.8-10 galax/amd64/1.1-15 
galax/arm64/1.1-15 galax/armel/1.1-15 galax/armhf/1.1-15 galax/i386/1.1-15 
galax/mips/1.1-15 galax/mips64el/1.1-15 galax/mipsel/1.1-15 
galax/ppc64el/1.1-15 galax/s390x/1.1-15 -hol-light/20170109-1 
lablgtk-extras/amd64/1.5-1 lablgtk-extras/arm64/1.5-1 
lablgtk-extras/armel/1.5-1 lablgtk-extras/armhf/1.5-1 lablgtk-extras/i386/1.5-1 
lablgtk-extras/mips/1.5-1 lablgtk-extras/mips64el/1.5-1 
lablgtk-extras/mipsel/1.5-1 lablgtk-extras/ppc64el/1.5-1 
lablgtk-extras/s390x/1.5-1 lablgtk2/2.18.5+dfsg-1 lablgtkmathview/amd64/0.7.8-6 
lablgtkmathview/arm64/0.7.8-6 lablgtkmathview/armel/0.7.8-6 
lablgtkmathview/armhf/0.7.8-6 lablgtkmathview/i386/0.7.8-6 
lablgtkmathview/mips/0.7.8-6 lablgtkmathview/mips64el/0.7.8-6 
lablgtkmathview/mipsel/0.7.8-6 lablgtkmathview/ppc64el/0.7.8-6 
lablgtkmathview/s390x/0.7.8-6 laby/0.6.4-2 lambda-term/1.10.1-2 
ledit/amd64/2.03-5 ledit/arm64/2.03-5 ledit/armel/2.03-5 ledit/armhf/2.03-5 
ledit/i386/2.03-5 ledit/mips/2.03-5 ledit/mips64el/2.03-5 ledit/mipsel/2.03-5 
ledit/ppc64el/2.03-5 ledit/s390x/2.03-5 liquidsoap/mips/1.1.1-7.2 
liquidsoap/mips64el/1.1.1-7.2 liquidsoap/mipsel/1.1.1-7.2 
liquidsoap/ppc64el/1.1.1-7.2 liquidsoap/s390x/1.1.1-7.2 lwt/2.5.2-2 
monotone-viz/mips/1.0.2-4 monotone-viz/mips64el/1.0.2-4 
monotone-viz/mipsel/1.0.2-4 monotone-viz/ppc64el/1.0.2-4 
monotone-viz/s390x/1.0.2-4 nurpawiki/amd64/1.2.3-10 nurpawiki/arm64/1.2.3-10 
nurpawiki/armel/1.2.3-10 nurpawiki/armhf/1.2.3-10 nurpawiki/i386/1.2.3-10 
nurpawiki/mips/1.2.3-10 nurpawiki/mips64el/1.2.3-10 nurpawiki/mipsel/1.2.3-10 
nurpawiki/ppc64el/1.2.3-10 nurpawiki/s390x/1.2.3-10 ocaml-fileutils/0.5.2-1 
ocaml-gettext/0.3.7-1 ocaml-http/amd64/0.1.5-1 ocaml-http/arm64/0.1.5-1 
ocaml-http/armel/0.1.5-1 ocaml-http/armhf/0.1.5-1 ocaml-http/i386/0.1.5-1 
ocaml-lastfm/amd64/0.3.0-4 ocaml-lastfm/arm64/0.3.0-4 
ocaml-lastfm/armel/0.3.0-4 ocaml-lastfm/armhf/0.3.0-4 ocaml-lastfm/i386/0.3.0-4 
ocaml-mm/0.3.0-1 ocaml-ssl/0.5.3-1 ocamlbricks/amd64/0.90+bzr400-2 
ocamlbricks/arm64/0.90+bzr400-2 ocamlbricks/armel/0.90+bzr400-2 
ocamlbricks/armhf/0.90+bzr400-2 ocamlbricks/i386/0.90+bzr400-2 
ocamlbricks/mips/0.90+bzr400-2 ocamlbricks/mips64el/0.90+bzr400-2 
ocamlbricks/mipsel/0.90+bzr400-2 ocamlbricks/ppc64el/0.90+bzr400-2 
ocamlbricks/s390x/0.90+bzr400-2 ocamldap/amd64/2.1.8-10 ocamldap/arm64/2.1.8-10 
ocamldap/armel/2.1.8-10 ocamldap/armhf/2.1.8-10 ocamldap/i386/2.1.8-10 
ocamldap/mips/2.1.8-10 ocamldap/mips64el/2.1.8-10 ocamldap/mipsel/2.1.8-10 
ocamldap/ppc64el/2.1.8-10 ocamldap/s390x/2.1.8-10 ocamlgraph/amd64/1.8.6-1 
ocamlgraph/arm64/1.8.6-1 ocamlgraph/armel/1.8.6-1 ocamlgraph/armhf/1.8.6-1 
ocamlgraph/i386/1.8.6-1 

Bug#789133: transition: ocaml 4.02.3

[Stéphane Glondu]

Le 30/09/2015 19:21, Emilio Pozuelo Monfort a écrit :
>> Now that gcc-5 migrated, can anyone give an ETA for the OCaml transition?
> 
> Has the situation improved wrt the last status update? Can you give an update?

plplot has been removed from testing. No other improvements, but I
believe we can proceed with the transition. Blocking packages are few
(only 2 not maintained by Debian OCaml Maintainers, virt-top and
zeroinstall-injector) and I think they can be (temporarily) removed from
testing if needed.

Cheers,

-- 
Stéphane

Bug#789133: transition: ocaml 4.02.3

[Stéphane Glondu]

Now that gcc-5 migrated, can anyone give an ETA for the OCaml transition?


Cheers,

-- 
Stéphane

Bug#789133: transition: ocaml 4.02.2

[Stéphane Glondu]

Le 23/06/2015 23:45, Eric Cooper a écrit :
 I've updated approx to version 5.5-2 to fix the build failure due to
 deprecation of String.create in 4.02.

Thank you.

 So I'd appreciate it if someone could build it from the master branch
 of git.debian.org/git/pkg-ocaml-maint/packages/approx.git and upload
 it.

Done.

 BTW, I still believe -warn-error is good engineering practice, even
 though it's inconvenient during transitions like this.  So rather than
 turn it off completely, I turned off only the warning due to
 deprecated features.

It might be good for development or continuous integration, where
upstream is in charge of fixing things. But for software uploaded to
Debian, I don't think it's the Debian maintainer's job to fix all new
warnings a package may trigger. That's why I think -warn-error
(especially -warn-error A) should not be used in released software.


Cheers,

-- 
Stéphane


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558b98fd.4040...@debian.org

Bug#789133: transition: ocaml 4.02.2

[Stéphane Glondu]

Le 22/06/2015 15:59, Emilio Pozuelo Monfort a écrit :
 Or if you can give a more detailed explanation of what will happen after ocaml
 is uploaded, binNMUs are scheduled, and we have ~30 packages that are holding
 the transition.

I say we remove them from testing. dak rm -Rn -s testing shows that
all missing packages + ceve gnudatalanguage nbdkit psfex scamp can be
removed from testing together.

Cheers,

-- 
Stéphane


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558842a6.3010...@debian.org

Bug#789133: transition: ocaml 4.02.2

[Stéphane Glondu]

Le 19/06/2015 12:56, Emilio Pozuelo Monfort a écrit :
 I see some of the failing packages have in the log:
 
  - Finished parsing the build-deps
 Wrong version of OCaml!
 
 That does that mean the package couldn't be built because of the dependency
 problems you mention?

Indeed.

 My only concern here is that with 41 failing packages, the transition may take
 quite a while to finish, blocking other stuff. That'd be different if most of
 those packages will just build fine after the binNMUs, but I have no idea if
 that's the case...

No, it's not the case. However, having an old version of OCaml in
unstable also blocks other stuff: new versions of OCaml-related stuff
start picking up new features of OCaml so we cannot update them before
OCaml. Moreover, sometimes, fixes for failing packages need the new
version of OCaml. That's why I am in favour of removing packages from
testing in order to update OCaml. IMHO, failing packages can be fixed later.

 I do wonder how many of those are actual failures, of those, how many are
 maintained by the ocaml team and how many are not...

I've recompiled everything with the final ocaml 4.02.2, fixing a few
things on the way. The build logs are available at:

  http://ocaml.debian.net/debian/ocaml-4.02.2/

There are 34 MISSING packages. I have attached a summary.

 BTW if you have filed bugs for the failing packages, please make them block 
 this
 tracking bug.

I will.


Cheers,

-- 
Stéphane

Not in testing:
  llvm-toolchain-3.6
  llvm-toolchain-snapshot
  ocamlduce
  janest-core

Use compiler internals, should be removed from testing if needed:
  jocaml
  mingw-ocaml
  cmigrep
  otags
  cduce
  js-of-ocaml
  eliom (needs js-of-ocaml)
  nurpawiki (needs eliom)

Maintained by the Debian OCaml Team:
  coq-doc (fix in coq)
  ocaml-fdkaac (dep issue, libfdk-aac-dev)
  coccinelle (dep issue, camlp4)
  lablgtk-extras (Some fatal warnings were triggered)
  ocaml-reins (Some fatal warnings were triggered)
  approx (Some fatal warnings were triggered)
  dose3 (issue in RPM bindings, #789354)
  ocaml-gettext (segfault, suspicious double linking of Unix)
  ocamldap
  matita (a class type should be virtual)
  ocsigenserver (dep issue)
  opam
  why
  liquidsoap
  coinst
  nss-passwords (int types, I am upstream)

Maintained by others:
  monotone-viz
  plplot (configure error)
  libguestfs (needs ocaml-gettext)
  virt-top (needs ocaml-gettext)
  zeroinstall-injector (string/bytes discrepancy)
  botch (needs dose3)

Bug#789133: transition: ocaml 4.02.2

[Stéphane Glondu]

Le 18/06/2015 17:06, Eric Cooper a écrit :
 Attached is the list of packages appearing in the tracker, with an
 annotation:
  - unstable if the package can be binNMUed
  - experimental if the package has to be uploaded from experimental
  - UNRELEASED if the package has to be uploaded from git (though I
am not sure I've pushed everything I should have)
  - MISSING if the package has not been built for some reason (FTBFS,
missing dependency, resource exhaustion)
 
 Is any further information (build logs etc.) available about the
 MISSING packages?

Build logs and binary packages are available at:

  http://ocaml.debian.net/debian/ocaml-4.02.2%2Brc1/pool/

Cheers,

-- 
Stéphane


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5583ed33.1090...@debian.org

Bug#789133: transition: ocaml 4.02.2

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Managers and OCaml Maintainers,

I would like to start the transition to OCaml 4.02.2 (released
yesterday) as soon as possible. This version has been preceded by a
release candidate, which I used to test-rebuild all the packages. It
breaks some packages; most of them have been fixed in experimental
and/or in git. As usual, it involves a lot of binNMUs; I will take care
of those.

The bug number in the tracker:

  https://release.debian.org/transitions/html/ocaml.html

should be updated now.

Attached is the list of packages appearing in the tracker, with an
annotation:
 - unstable if the package can be binNMUed
 - experimental if the package has to be uploaded from experimental
 - UNRELEASED if the package has to be uploaded from git (though I
   am not sure I've pushed everything I should have)
 - MISSING if the package has not been built for some reason (FTBFS,
   missing dependency, resource exhaustion)

Out of 256 packages, 41 are MISSING. LLVM packages are probably OK but
take too much disk space for my sandbox. Other notable MISSING packages
include dose3, camlimages and js-of-ocaml but I am confident they are
fixed upstream and just need an update. They also include packages that
are not in testing such as ocamlduce, jocaml or janest-core.

Once the transition has started, and all not-MISSING packages have been
compiled, it should be possible for everyone to fix MISSING ones but for
now, it's delicate because all dependencies have to be recompiled in
order...


Cheers,

-- 
Stéphane
=== Dependency level 1 ===
camlidl-doc: unstable
ceve: unstable
dh-ocaml: unstable
hevea-doc: unstable
meta-ocaml: unstable
meta-unison: unstable
ocaml-doc: unstable
ocamlmakefile: unstable
tuareg-mode: unstable
=== Dependency level 2 ===
ocaml: UNRELEASED
=== Dependency level 3 ===
camlidl: unstable
camlp5: UNRELEASED
camlzip: unstable
confluence: unstable
cothreads: unstable
cuyo: unstable
facile: unstable
findlib: UNRELEASED
hevea: unstable
hlins: unstable
jocaml: MISSING
lablgl: UNRELEASED
llvm-toolchain-3.4: MISSING
llvm-toolchain-3.5: MISSING
llvm-toolchain-3.6: MISSING
llvm-toolchain-snapshot: MISSING
mediawiki: unstable
mediawiki-math: unstable
mingw-ocaml: MISSING
misery: unstable
mlgmp: unstable
ocaml-tools: unstable
ocamlagrep: unstable
ocamldsort: unstable
ocamlduce: MISSING
ocamlpam: unstable
ocamlwc: unstable
ocamlweb: unstable
omake: unstable
perl4caml: unstable
planets: UNRELEASED
polygen: unstable
pycaml: unstable
scilab: unstable
spamoracle: unstable
xml-light: unstable
=== Dependency level 4 ===
apron: unstable
bibtex2html: unstable
calendar: unstable
camlbz2: unstable
camldbm: unstable
camljava: unstable
camlmix: unstable
camltemplate: unstable
cmdliner: unstable
coq-doc: MISSING
cppo: unstable
cryptgps: unstable
cryptokit: unstable
extlib: unstable
gd4o: unstable
gmetadom: unstable
haxe: unstable
hivex: unstable
hol-light: unstable
kalzium: unstable
lablgtk2: UNRELEASED
ledit: unstable
llvm-defaults: MISSING
menhir: unstable
mlpcap: unstable
mysql-ocaml: unstable
ocaml-alsa: unstable
ocaml-ao: unstable
ocaml-bitstring: unstable
ocaml-bjack: unstable
ocaml-config-file: unstable
ocaml-cry: unstable
ocaml-csv: unstable
ocaml-curses: unstable
ocaml-dbus: unstable
ocaml-deriving: unstable
ocaml-expat: unstable
ocaml-faad: unstable
ocaml-fdkaac: MISSING
ocaml-frei0r: unstable
ocaml-gavl: unstable
ocaml-getopt: unstable
ocaml-gnuplot: unstable
ocaml-gstreamer: unstable
ocaml-inotify: unstable
ocaml-ladspa: unstable
ocaml-lame: unstable
ocaml-libvirt: unstable
ocaml-lo: unstable
ocaml-mad: unstable
ocaml-magic: unstable
ocaml-mm: unstable
ocaml-ogg: unstable
ocaml-portaudio: unstable
ocaml-pulseaudio: unstable
ocaml-re: unstable
ocaml-res: unstable
ocaml-samplerate: unstable
ocaml-sha: unstable
ocaml-shine: unstable
ocaml-shout: unstable
ocaml-soundtouch: unstable
ocaml-sqlite3: unstable
ocaml-ssl: unstable
ocaml-taglib: unstable
ocaml-voaacenc: unstable
ocaml-zarith: unstable
ocamlcreal: unstable
ocamlgsl: unstable
ocamlify: unstable
ocamlsdl: unstable
ocurl: unstable
optcomp: unstable
ounit: unstable
pagodacf: unstable
parmap: unstable
pcre-ocaml: unstable
pipebang: unstable
postgresql-ocaml: unstable
react: unstable
syslog-ocaml: unstable
tophide: UNRELEASED
type-conv: unstable
ulex: unstable
ulex0.8: unstable
uuidm: unstable
xmlm: unstable
xstr: unstable
xstrp4: unstable
=== Dependency level 5 ===
ara: unstable
bin-prot: unstable
cairo-ocaml: unstable
camlimages: MISSING
camomile: unstable
cmigrep: MISSING
coccinelle: MISSING
comparelib: unstable
coq: unstable
cudf: experimental
enumerate: unstable
fieldslib: unstable
freetennis: UNRELEASED
geneweb: unstable
headache: unstable
herelib: unstable
lablgtk-extras: MISSING
lablgtkmathview: unstable
laby: unstable
mikmatch: unstable
mldonkey: UNRELEASED
monotone-viz: MISSING
mtasc: unstable
ocaml-benchmark: unstable
ocaml-ctypes: 

Bug#718767: pango1.0 binNMUed

[Stéphane Glondu]

Hi,

lablgtk2 was uninstallable because of pango1.0, which was uninstallable
because of harfbuzz.

I tried to rebuild on my machine pango1.0, and it unlocks the situation
w.r.t lablgtk2. I saw someone binNMUed it on hurd-i386. I binNMUed it on
other architectures as well (with dw on libharfbuzz0b).

A similar situation is happening with coq and texlive-bin.

Cheers,

-- 
Stéphane


-- 
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/52a04bd0.1030...@debian.org

Bug#718767: transition: ocaml 4.01.0

[Stéphane Glondu]

Le 02/12/2013 13:54, Mehdi Dogguy a écrit :
 I would like to start the transition to OCaml 4.00.1 (released last
 November) as soon as possible. It breaks some packages; most of them
 have been fixed in experimental. As usual, it involves a lot of binNMUs;
 I will take care of those.

 Now, I think we should start the transition to OCaml 4.01.0 in unstable.

 
 Let's start now. Could you please upload the updated pacakges from
 experimental
 to sid and schedule needed binNMUs?

OK, I'll do that.

Cheers,

-- 
Stéphane


-- 
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/529c9b25.4060...@debian.org

Bug#730619: [PATCH] Add a transition collision detector.

[Stéphane Glondu]

Package: ben
Version: 0.6.6
Severity: normal

Le 09/02/2012 18:21, Niels Thykier a écrit :
 While this post-processing of generated HTML files is kind of ugly, it
 makes it easy to show which transitions might be entangled due to
 collisions.
 [...]
 
 I am in favor of using this as a temporary solution until Ben gets a
 similar feature.

Submitting a proper bugreport for this...

For reference, original patch is at:

  https://lists.debian.org/debian-release/2012/02/msg00084.html

-- 
Stéphane


-- 
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/5295c5bb.6020...@debian.org

Bug#718767: transition: ocaml 4.01.0

[Stéphane Glondu]

retitle 718767 transition: ocaml 4.01.0
thanks

Le 05/08/2013 10:43, Stéphane Glondu a écrit :
 I would like to start the transition to OCaml 4.00.1 (released last
 November) as soon as possible. It breaks some packages; most of them
 have been fixed in experimental. As usual, it involves a lot of binNMUs;
 I will take care of those.

Now, I think we should start the transition to OCaml 4.01.0 in unstable.


Cheers,

-- 
Stéphane


--
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/5291ceca.3080...@debian.org

Bug#718767: ocaml_4.01.0-1_amd64.changes ACCEPTED into experimental

[Stéphane Glondu]

Le 09/11/2013 10:32, Hendrik Tews a écrit :
 Debian FTP Masters ftpmas...@ftp-master.debian.org writes:
 
Source: ocaml
Version: 4.01.0-1
 
 does this mean we skip the 4.00 transition and transition
 directly to 4.01, when the release team finally approves?

Yes.

 Does this also mean that you would welcome/sponsor package
 uploads to experimental with new versions or 4.01 compatibility?

Yes, although I would prefer to avoid uploads when binNMUs are sufficient.


Cheers,

-- 
Stéphane


--
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/527e0a57.3020...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 02/10/2013 19:43, Julien Cristau a écrit :
 I have uploaded Nova 2013.1.3-2 with removed support for XAPI, as you
 asked. I hope XCP support can come back quickly in Debian.
 [...]
 Hoping that this will help for the Ocaml transition,

 That was one week ago. nova has migrated to testing and xen-api has been
 removed from testing.

 What is blocking now?

 #721999

xen has migrated to testing. What's the new blocker, now?


Cheers,

-- 
Stéphane


--
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/526ce473@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 25/09/2013 04:56, Thomas Goirand a écrit :
 I have uploaded Nova 2013.1.3-2 with removed support for XAPI, as you
 asked. I hope XCP support can come back quickly in Debian.
 [...]
 Hoping that this will help for the Ocaml transition,

That was one week ago. nova has migrated to testing and xen-api has been
removed from testing.

What is blocking now?


Cheers,

-- 
Stéphane


--
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/524bb0c0.7080...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 06/09/2013 10:14, Thomas Goirand a écrit :
 However, as I wrote it, it's going to happen, so please be patient about
 it. IMO, this shouldn't block any transition though. If the release team
 is reading: just let everything transition to testing, and remove the
 old version of XCP 1.3.2 in testing if that helps, plus add some
 blocking bugs so that the rest of Debian isn't affected by the (not
 finished) work on XCP 1.6 for Debian.

More than two weeks later, xen-api is still in testing, and preventing
the start of the OCaml transition.

If I remove all binary packages of xen-api from testing, the following
new packages are broken: xcp-guest-templates, nova-xcp-plugins,
nova-compute-xen.

xcp-guest-templates is built by guest-templates which seems to be a leaf
package and could be removed from testing.

On the other hand, both nova-* packages are built by nova which Julien
wants to keep in testing. The last changelog entry advertises the
removal of nova-xcp-plugins, but it is still there.

Thomas, could you please upload a new nova without nova-xcp-plugins and
nova-compute-xen?


Cheers,

-- 
Stéphane


-- 
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/52419829.2090...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 24/09/2013 15:48, Stéphane Glondu a écrit :
 If I remove all binary packages of xen-api from testing, the following
 new packages are broken: xcp-guest-templates, nova-xcp-plugins,
 nova-compute-xen.
 
 xcp-guest-templates is built by guest-templates which seems to be a leaf
 package and could be removed from testing.
 
 On the other hand, both nova-* packages are built by nova which Julien
 wants to keep in testing. The last changelog entry advertises the
 removal of nova-xcp-plugins, but it is still there.

On the other hand, if removing nova is accepted, it seems that novnc is
the only reverse dependency.

To summarize, at the moment, (at least) the following packages need to
be removed (or fixed) from testing to proceed: xen-api, guest-templates,
nova and novnc.


Cheers,

-- 
Stéphane


-- 
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/52419bf5.3020...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 24/09/2013 19:00, Thomas Goirand a écrit :
 Please don't think this way.
 
 I work daily on 79 packages to maintain OpenStack in Debian:
 
 http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org

If you go that way, I could say that you're blocking my work on 214
packages in Debian:

http://qa.debian.org/developer.php?login=debian-ocaml-ma...@lists.debian.org

 I do not agree to just destroy my work this way.

Removing a package from testing doesn't mean destroying it. On the other
hand, the work done to prepare the OCaml transition is becoming more and
more obsolete, effectively destroying it.

 Also, I don't really understand what the problem is, since xcp-xapi has
 been fixed out to use the new type-conv thing.

xen-api is still failing to build from source in unstable. Excerpt from
the build log:
 + gcc -g -O2 -DCOMPILE_NATIVE -I/usr/lib/ocaml -I/usr/include -I. -c -o 
 xenguest_stubs.o xenguest_stubs.c
 In file included from xenguest_stubs.c:24:0:
 /usr/include/xs.h:1:2: warning: #warning xs.h is deprecated use xenstore.h 
 instead [-Wcpp]
  #warning xs.h is deprecated use xenstore.h instead
   ^
 xenguest_stubs.c: In function 'dispatch_suspend':
 xenguest_stubs.c:197:14: warning: cast from pointer to integer of different 
 size [-Wpointer-to-int-cast]
   int domid = (int) arg;
   ^
 xenguest_stubs.c: In function 'hvm_build_set_params':
 xenguest_stubs.c:360:8: error: 'struct hvm_info_table' has no member named 
 'acpi_enabled'
   va_hvm-acpi_enabled = f.acpi;
 ^
 xenguest_stubs.c: At top level:
 xenguest_stubs.c:470:3: warning: initialization from incompatible pointer 
 type [enabled by default]
.postcopy = switch_qemu_logdirty,
^
 xenguest_stubs.c:470:3: warning: (near initialization for 
 'save_callbacks.postcopy') [enabled by default]
 xenguest_stubs.c: In function 'stub_xc_domain_save':
 xenguest_stubs.c:490:18: warning: assignment makes pointer from integer 
 without a cast [enabled by default]
callbacks.data = c_domid;
   ^
 xenguest_stubs.c:497:21: error: too few arguments to function 'xc_domain_save'
  c_flags, callbacks, Bool_val(hvm));
  ^
 In file included from xenguest_stubs.c:23:0:
 /usr/include/xenguest.h:87:5: note: declared here
  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t 
 max_iters,
  ^
 xenguest_stubs.c: In function 'stub_xc_domain_restore':
 xenguest_stubs.c:552:10: warning: passing argument 7 of 'xc_domain_restore' 
 makes integer from pointer without a cast [enabled by default]
   Bool_val(hvm), f.pae, 0 /*superpages*/);
   ^
 In file included from xenguest_stubs.c:23:0:
 /usr/include/xenguest.h:122:5: note: expected 'unsigned int' but argument is 
 of type 'long unsigned int *'
  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  ^
 xenguest_stubs.c:552:10: warning: passing argument 8 of 'xc_domain_restore' 
 makes pointer from integer without a cast [enabled by default]
   Bool_val(hvm), f.pae, 0 /*superpages*/);
   ^
 In file included from xenguest_stubs.c:23:0:
 /usr/include/xenguest.h:122:5: note: expected 'long unsigned int *' but 
 argument is of type 'int'
  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  ^
 xenguest_stubs.c:552:10: error: too few arguments to function 
 'xc_domain_restore'
   Bool_val(hvm), f.pae, 0 /*superpages*/);
   ^
 In file included from xenguest_stubs.c:23:0:
 /usr/include/xenguest.h:122:5: note: declared here
  int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom,
  ^

As I've said numerous times already, xen-api needs an update. If you
cannot update it, please arrange for its removal from testing.


Cheers,

-- 
Stéphane


--
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/5241e0d3.60...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 06/09/2013 10:14, Thomas Goirand a écrit :
 I wrote it many time to many people. Please don't just read 1.6 as new
 upstream release for XCP. That's unfortunately not the way it works.
 Upstream version for Debian and the one they do for CentOS are
 different, and just using upstream 1.6 doesn't cut it. It needs to be
 ported to Debian, and that's far from a trivial work (as Michael Tokarev
 wrote, it's not just replacing /usr/libexec/ into /usr/lib/ and the like).

That is not the way it should work. Upstream version should not be
specific to either Debian or CentOS. There should be only one version,
and it is the job of each distribution (yours, here) to do the
specialization work. If you can't, then arrange for its removal from
testing.

 However, as I wrote it, it's going to happen, so please be patient about
 it. IMO, this shouldn't block any transition though. If the release team
 is reading: just let everything transition to testing, and remove the
 old version of XCP 1.3.2 in testing if that helps, plus add some
 blocking bugs so that the rest of Debian isn't affected by the (not
 finished) work on XCP 1.6 for Debian.

There are reverse-dependencies so it cannot be easily removed from
testing. And this situation IS blocking other people's work. And has
been for (at least) one month.

 No, the package isn't neglected. It's simply more complicated than it
 seems. I'm currently dealing with upstream about it.

While doing so, please make sure future versions are trivial to port to
Debian. It should have been done during the initial packaging.

 I by the way don't mind if 1.3.2 is removed from testing, as we will
 need to package the next version anyway.

Then, could you give the list of packages that should be removed from
testing? Remember, testing should be self-contained, so it means remove
all reverse dependencies as well.

 There are a few reverse-dependencies, but they all look somehow
 connected: nova, guest-templates, xcp-*... My take would be to remove
 (from testing) all of them.
 
 The problem for Nova is different. It's depending on sqlalchemy-migrate
 (python-migrate in Debian), which is blocked by Alembic, AFAIK. As for
 guest-templates, I don't see why it is affected.

guest-templates build-depends on libxenapi-ocaml-dev, which is built by
xen-api.

 I hope the above helps,

And nothing has changed since...


Cheers,

-- 
Stéphane


--
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/522ec796.7090...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Le 05/09/2013 23:18, Julien Cristau a écrit :
 tracker adjusted.  xen-api is currently broken though, so you'll need to
 get that fixed before starting.

I've just fixed a blocking bug (#713349) which was due to the renaming
of an OCaml library (type-conv - type_conv).

Now, xen-api FTBFS because of what looks like an API change in some (C)
dependency:

 [...]
 + gcc -g -O2 -DCOMPILE_NATIVE -I/usr/lib/ocaml -I/usr/include -I. -c -o 
 xenguest_stubs.o xenguest_stubs.c
 In file included from xenguest_stubs.c:24:0:
 /usr/include/xs.h:1:2: warning: #warning xs.h is deprecated use xenstore.h 
 instead [-Wcpp]
  #warning xs.h is deprecated use xenstore.h instead
   ^
 xenguest_stubs.c: In function 'dispatch_suspend':
 xenguest_stubs.c:197:14: warning: cast from pointer to integer of different 
 size [-Wpointer-to-int-cast]
   int domid = (int) arg;
   ^
 xenguest_stubs.c: In function 'hvm_build_set_params':
 xenguest_stubs.c:360:8: error: 'struct hvm_info_table' has no member named 
 'acpi_enabled'
   va_hvm-acpi_enabled = f.acpi;
 ^
 xenguest_stubs.c: At top level:
 xenguest_stubs.c:470:3: warning: initialization from incompatible pointer 
 type [enabled by default]
.postcopy = switch_qemu_logdirty,
^
 [...]

On the other hand, there is a new upstream release (upstream version is
1.6 and unstable version is 1.3.2). It doesn't make sense to me to
invest time in this without updating the package, which goes beyond the
scope of an NMU. Fixing #713349 was already borderline since there is
also a new upstream release there... but it was easy.

The FTBFS bug has been reported in June. I told some of the maintainers
(in-person, in CC) to update this package during debconf. No activity
since them. IMHO, this package is neglected and should be removed from
testing.

There are a few reverse-dependencies, but they all look somehow
connected: nova, guest-templates, xcp-*... My take would be to remove
(from testing) all of them.


Cheers,

-- 
Stéphane


--
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/52297955.7000...@debian.org

Re: Bug#713073: PTS: show library transition message also on the source package page

[Stéphane Glondu]

Le 16/08/2013 17:29, Giovanni Mascellani a écrit :
 @Release team: Joachim Breitner asked to patch PTS so that it displays
 not only the packages involved in a transition, but also the packages
 that cause the transition (see the example below).
 [...]
 Is Ben aware of this information? If so, could you please export it in a
 machine parsable way? If not, would you consider adding it?

Ben is aware of the packages that match the affected predicate. It
seems that predicates the release team uses exclude the packages that
cause the transition. For example, in libcogl12, the affected
predicate is:

.depends ~ /libcogl(9|12)|libcogl-pango(0|12)/  !(.source ~ cogl)

The last clause explicitly excludes the cogl source package, and
therefore cogl doesn't appear in the transition monitoring page (nor in
its PTS). I don't know why this clause was added.


Cheers,

-- 
Stéphane


--
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/5213199d.9000...@debian.org

Re: Bug#713073: PTS: show library transition message also on the source package page

[Stéphane Glondu]

Le 20/08/2013 09:41, Niels Thykier a écrit :
 I think the reason why we prefer having the introducing source package
 as unaffected, is because it will be taken care of by a source upload
 (i.e. there is usually nothing for us to do about that package). [...]

The tool was meant to track packages that need sourceful uploads too...

 [...] The
 introducing package also tends to create its own dependency level in
 the tracker, so excluding almost always removes a dependency level in
 the tracker.

You could also make it good, so that it is hidden by the javascript foo.

Why does it matter to have an additional dependency level?


Cheers,

-- 
Stéphane


--
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/521325d0.6020...@debian.org

Bug#718767: transition: ocaml 4.00.1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Managers,

I would like to start the transition to OCaml 4.00.1 (released last
November) as soon as possible. It breaks some packages; most of them
have been fixed in experimental. As usual, it involves a lot of binNMUs;
I will take care of those.

The permanent transition tracker for ocaml is enough, but the clause

  .depends ~ /ocaml(-base)?(-nox)?-3\.1(1|2)\../

will become obsolete with the new version, and I think it can be dropped
(it should imply the rest). Additionally, the bug number in the comment
should be updated as well.


Cheers,

-- 
Stéphane


-- 
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/51ff65b8.50...@debian.org

Bug#709618: camlp5 et al need hinting

[Stéphane Glondu]

Package: release.debian.org
Severity: important

Dear Release Managers,

Now that glib has migrated, I think that camlp5 [1] and related
packages need manual hinting. All the packages listed in the Coq
section of [2] need to enter together.

[1] http://release.debian.org/migration/testing.pl?package=camlp5
[2] https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions

By the way, could I acquire easy-hinting capabilities so that I could
directly handle OCaml packages in the same way as I do for binNMUs? I
promise not to mess with other packages :-)


Cheers,

-- 
Stéphane


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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20130524130345.28668.57963.report...@wencory.loria.fr

Re: Bug#709618: camlp5 et al need hinting

[Stéphane Glondu]

Le 24/05/2013 15:15, Adam D. Barratt a écrit :
 Looking at the dependencies, I guess why needs rebuilding against the
 new coq, or removing?

Removing, because of #707585, as said in [1]. With Mehdi's approval (he
is why's maintainer).

[1] https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions


Cheers,

-- 
Stéphane


-- 
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/519f6ea4.6080...@debian.org

Re: Bug#666825: Apache 2.4 upload date scheduled for May 30

[Stéphane Glondu]

Le 23/05/2013 13:13, Arno Töll a écrit :
 we are ready to upload Apache2 2.4 to Debian Sid now. This means the
 transition is effectively starting now, and going to break your modules.

There are currently ~20 source entangled OCaml-related packages waiting
to migrate to testing (see Ocsigen section in [1]) + a number of
binNMUs including ocamlnet. Please wait for this to happen before
uploading apache.

[1] https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions


Cheers,

-- 
Stéphane


-- 
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/519e01aa.4010...@debian.org

Re: Bug#666825: Apache 2.4 upload date scheduled for May 30

[Stéphane Glondu]

Le 23/05/2013 13:57, Arno Töll a écrit :
 please coordinate this in #661958. I got an ACK of the Release Team, so
 I don't know if they had your issue on the radar or not. Either way, I
 know nothing about OCaml and your transition.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666825#47 (you were
also a direct recipient of this mail).


Cheers,

-- 
Stéphane



-- 
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/519e0626.5080...@debian.org

OCaml transition plans

[Stéphane Glondu]

Hello,

During the freeze, a new major version of OCaml has been released. The
current version is 4.00.1 (already in experimental, the one in sid is
3.12.1). It breaks some packages, and many of those have been fixed
upstream meanwhile. It seems that most of the times, fixes are
backward-compatible.

Therefore, I propose that we update all other OCaml-related packages
first (not the compiler itself). At least, those that still compile with
the old version. This means many small transitions.

Once this is done (I expect this will take several months), I hope a
painless transition for OCaml itself. And by done, I mean everything
is reasonnably up-to-date in *testing*.

I am planning to handle myself Coq, Ocsigen, Unison, and many of their
direct and reverse dependencies. I will document the progress in [1].
Feel free to step in for other groups of packages, and document them in [1].

Note that Ocsigen depends on ocamlnet, which interferes with Apache
2.4... but we're not there yet. I am not aware of other interferences,
at least with what is listed on [2].

[1] https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransition
[2] http://release.debian.org/transitions/


Cheers,

-- 
Stéphane


--
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/518a2d51.7010...@debian.org

Bug#693618: unblock: js-of-ocaml/1.2-2

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Le 02/11/2012 22:23, Niels Thykier a écrit :
 It does not seem important, but given it is a doc-only change I am
 willing to accept it if you are still willing to upload it.  If you do
 upload it, please file an unblock bug after it has been in unstable for
 a couple of days.

Done.


Cheers,

-- 
Stéphane
diff -Nru js-of-ocaml-1.2/debian/changelog js-of-ocaml-1.2/debian/changelog
--- js-of-ocaml-1.2/debian/changelog	2012-06-08 07:23:02.0 +0200
+++ js-of-ocaml-1.2/debian/changelog	2012-11-14 12:18:20.0 +0100
@@ -1,3 +1,9 @@
+js-of-ocaml (1.2-2) unstable; urgency=low
+
+  * Update upstream changelog and version (Closes: #691257)
+
+ -- Stéphane Glondu glo...@debian.org  Wed, 14 Nov 2012 12:18:20 +0100
+
 js-of-ocaml (1.2-1) unstable; urgency=low
 
   * New upstream release
diff -Nru js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch
--- js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch	1970-01-01 01:00:00.0 +0100
+++ js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch	2012-10-26 10:20:28.0 +0200
@@ -0,0 +1,40 @@
+From: Stephane Glondu st...@glondu.net
+Date: Fri, 26 Oct 2012 10:14:29 +0200
+Subject: Changelog and version
+
+Origin: upstream, http://ocsigen.org/darcsweb/?r=js_of_ocaml;a=commit;h=20120530130902-4e2d2-a51cd5bebba852be2e409cb076f8b300dea37cf9.gz
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691257
+---
+ CHANGES |   13 +
+ VERSION |2 +-
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/CHANGES b/CHANGES
+index 1608ba0..1701902 100644
+--- a/CHANGES
 b/CHANGES
+@@ -1,3 +1,16 @@
++
++= 1.2 (2012-06-02) =
++
++ * Bugfixes
++ ** Fix #284
++ ** Fix return type of window##open_
++
++ * Features/Changes
++ ** Improvements in the data-flow solver
++ ** Add Dom_html.window##onscroll
++ ** Dom_events.listen: handler should return boolean
++ ** Add DOM drag/drop events
++
+ = 1.1.1 (2012-03-15) =
+ 
+  * Bugfixes:
+diff --git a/VERSION b/VERSION
+index 524cb55..5625e59 100644
+--- a/VERSION
 b/VERSION
+@@ -1 +1 @@
+-1.1.1
++1.2
+-- 
diff -Nru js-of-ocaml-1.2/debian/patches/series js-of-ocaml-1.2/debian/patches/series
--- js-of-ocaml-1.2/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ js-of-ocaml-1.2/debian/patches/series	2012-10-26 10:20:28.0 +0200
@@ -0,0 +1 @@
+0001-Changelog-and-version.patch
diff -Nru js-of-ocaml-1.2/debian/README.Debian js-of-ocaml-1.2/debian/README.Debian
--- js-of-ocaml-1.2/debian/README.Debian	1970-01-01 01:00:00.0 +0100
+++ js-of-ocaml-1.2/debian/README.Debian	2012-11-14 12:18:13.0 +0100
@@ -0,0 +1,12 @@
+js_of_ocaml 1.2 in Debian
+-
+
+The upstream part of this packages matches tag 1.2 [1] from the
+upstream Darcs repository, and not the tarball currently published on
+the upstream site versioned as 1.2, which contains more commits. In
+particular, module Lwt_js_events is not present. See Debian bug
+#691257 for more information.
+
+[1] hash 20120530130911-4e2d2-f31950afc273d98b70ecc9d2dd6cc23947de7204.gz
+
+ -- Stéphane Glondu glo...@debian.org, Wed, 14 Nov 2012 12:18:13 +0100

Freeze exception request for js_of_ocaml 1.2-2

[Stéphane Glondu]

Dear Release Team,

Bug #691257 made me realize that the upstream tarball of the Debian
package is not the same as the one currently available on the upstream
website, and the contents does not match tag 1.2 in the upstream
repository either.

There is one commit missing. It changes only changelog and version, and
I would like to update the Debian package with it. Attached is a debdiff.


Cheers,

-- 
Stéphane
diff -Nru js-of-ocaml-1.2/debian/changelog js-of-ocaml-1.2/debian/changelog
--- js-of-ocaml-1.2/debian/changelog	2012-06-08 07:23:02.0 +0200
+++ js-of-ocaml-1.2/debian/changelog	2012-10-26 10:20:28.0 +0200
@@ -1,3 +1,9 @@
+js-of-ocaml (1.2-2) unstable; urgency=low
+
+  * Update upstream changelog and version (Closes: #691257)
+
+ -- Stéphane Glondu glo...@debian.org  Fri, 26 Oct 2012 10:18:47 +0200
+
 js-of-ocaml (1.2-1) unstable; urgency=low
 
   * New upstream release
diff -Nru js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch
--- js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch	1970-01-01 01:00:00.0 +0100
+++ js-of-ocaml-1.2/debian/patches/0001-Changelog-and-version.patch	2012-10-26 10:20:28.0 +0200
@@ -0,0 +1,40 @@
+From: Stephane Glondu st...@glondu.net
+Date: Fri, 26 Oct 2012 10:14:29 +0200
+Subject: Changelog and version
+
+Origin: upstream, http://ocsigen.org/darcsweb/?r=js_of_ocaml;a=commit;h=20120530130902-4e2d2-a51cd5bebba852be2e409cb076f8b300dea37cf9.gz
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691257
+---
+ CHANGES |   13 +
+ VERSION |2 +-
+ 2 files changed, 14 insertions(+), 1 deletion(-)
+
+diff --git a/CHANGES b/CHANGES
+index 1608ba0..1701902 100644
+--- a/CHANGES
 b/CHANGES
+@@ -1,3 +1,16 @@
++
++= 1.2 (2012-06-02) =
++
++ * Bugfixes
++ ** Fix #284
++ ** Fix return type of window##open_
++
++ * Features/Changes
++ ** Improvements in the data-flow solver
++ ** Add Dom_html.window##onscroll
++ ** Dom_events.listen: handler should return boolean
++ ** Add DOM drag/drop events
++
+ = 1.1.1 (2012-03-15) =
+ 
+  * Bugfixes:
+diff --git a/VERSION b/VERSION
+index 524cb55..5625e59 100644
+--- a/VERSION
 b/VERSION
+@@ -1 +1 @@
+-1.1.1
++1.2
+-- 
diff -Nru js-of-ocaml-1.2/debian/patches/series js-of-ocaml-1.2/debian/patches/series
--- js-of-ocaml-1.2/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ js-of-ocaml-1.2/debian/patches/series	2012-10-26 10:20:28.0 +0200
@@ -0,0 +1 @@
+0001-Changelog-and-version.patch

Re: Bug#666825: Test rebuild of your package ocamlnet

[Stéphane Glondu]

Le 05/05/2012 13:48, a...@debian.org a écrit :
 this is a follow-up message to your Apache 2.4 transition bug for
 package ocamlnet. We are approaching an upload of the web server to
 Debian's Unstable repository as soon as the release team acknowledges
 the upload. Along that upload we are planning to raise the importance of
 this bug to a release-critical severity. 

Please wait at least that react, xmlm, xen-api, openvswitch (and maybe
others), which are related to ocamlnet (via ocsigen), migrate to testing
before breaking ocamlnet. My current estimate is in 2 days.


Cheers,

-- 
Stéphane


--
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/4fa56ac3.2080...@debian.org

Migration issue because of openvswitch...

[Stéphane Glondu]

Hello,

Currently, react (19 days old), xmlm (17 days) and xen-api (11 days) are
stuck in unstable. One reason is the following: xen-api depends on xmlm
and they must go together, and xen-api depends on (a new binary package
of) openvswitch, which FTBFS (and has been for  32 days).

Is there anyone working on fixing openvswitch? Or can the dependency in
xen-api be dropped, and reintroduced later, when openvswitch works and
has migrated to testing?


Cheers,

-- 
Stéphane


-- 
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/4f994b2e.1070...@debian.org

Re: False negative in ben?

[Stéphane Glondu]

Le 06/04/2012 13:00, Joachim Breitner a écrit :
 I regularly check
 http://release.debian.org/transitions/html/haskell.html, it is a great
 tool. But I am confused why it says haskell-sfml-audio, -openal and
 -alut is bad on armel armhf mips mipsel ppc s390 s390x. According to the
 parameters, this means that some of the packages of the source are
 uninstallable, but edos-debcheck or apt-get install in a chroot work
 flawlessly.

Ben considers only the latest version of arch:all packages, whereas dak
waits for the source package to be built on $arch before making the new
versions of its arch:all packages available on $arch.

For example, in the case of -openal, libopenal1 (1:1.13-6) is indeed not
installable on armel (from Ben's point of view): it depends on
libopenal-data (1:1.13-6), which is arch:all and non-existent since only
version 1:1.14-1 is considered.

I'm not sure exactly what the desired behaviour is in this case...


Cheers,

-- 
Stéphane


-- 
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/4f7efab3.8090...@debian.org

Re: Bug#662281: camlimages: Please Build-Depends on libpng-dev, change from libpng12-dev

[Stéphane Glondu]

Le 05/03/2012 04:23, Nobuhiro Iwamatsu a écrit :
 Please change Build-Depends of the package from libpng12-dev to libpng-dev.

PTS says that camlimages is part of libtiff4-symbols transition. Can I
upload it anyway?


Cheers,

-- 
Stéphane


--
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/4f552302.1080...@debian.org

Bug#633304: transition: ocaml

[Stéphane Glondu]

On 09/07/2011 05:51 PM, Stéphane Glondu wrote:
 OCaml 3.12.1 has been recently released. It is mostly bugfixes. I've
 rebuilt all packages that depend on ocaml, and I see no blocker to
 update it in Debian. I've planified the migration at [1] (I am
 planning to update a few other packages on the way). This will involve
 ~30 sourceful uploads and ~150 binNMUs.

 [1] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions

 I am waiting for the approval from the release team to proceed.
 
 It's been 60 days now, and no news. Any ETA?

I understand that the release team is very busy, and OCaml transitions
involve a lot of packages, but history has shown that they are pretty
self-contained and don't interact very much with other stuff.

Actually, in general, I'd rather see (I'm talking about the OCaml stack,
with my maintainer's hat on) problematic packages removed from testing
instead of waiting for months to get a new version of the compiler or a
library. The fact that everything has to be recompiled is unfortunate,
but the infrastructure seems to support it well, and it constrains the
packages to be always buildable, which is nice. Besides, OCaml upstream
is very conservative and break very few (if any) stuff with new releases
(and here, we are talking about a minor release...).


Cheers,

-- 
Stéphane



--
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/4e733d0a.4030...@debian.org

Bug#633304: transition: ocaml

[Stéphane Glondu]

Le 09/07/2011 13:35, Stéphane Glondu a écrit :
 OCaml 3.12.1 has been recently released. It is mostly bugfixes. I've
 rebuilt all packages that depend on ocaml, and I see no blocker to
 update it in Debian. I've planified the migration at [1] (I am
 planning to update a few other packages on the way). This will involve
 ~30 sourceful uploads and ~150 binNMUs.
 
 [1] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions
 
 I am waiting for the approval from the release team to proceed.

It's been 60 days now, and no news. Any ETA?


Cheers,

-- 
Stéphane




--
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/4e67930a.2060...@debian.org

Re: NMU of mdadm for squeeze-proposed-upates

[Stéphane Glondu]

Le 03/05/2011 08:52, Thomas Goirand a écrit :

-echo $PROGNAME: I: selecting $ionice I/O scheduling class for resync
of $array. 2
+[ $quiet -lt 1 ]  echo $PROGNAME: I: selecting $ionice I/O
scheduling class for resync of $array. 2


Out of context, I would prefer something like:

  if [ $quiet -lt 1 ]; then echo ...; fi

(especially in a script that sets -e)


Cheers,

--
Stéphane


--
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/4dece174.6080...@debian.org

Re: Suggested release goal: /run

[Stéphane Glondu]

Le 30/03/2011 17:24, Tollef Fog Heen a écrit :

(Please keep me in Cc, I'm not subscribed)
[...]
- /run should exist as a tmpfs
- /var/run should be a symlink or bind mount of/to /run
- /var/lock should be a symlink/bind mount to /run/lock
- /lib/init/rw should be a symlink/bind mount to /run
- applications are free to use /run as they have previously used
   /var/run.  Applications using /lib/init/rw and /dev/shm are to be
   changed to use /run.


Is there some generic location planned for (non priviledged) users? 
Currently, /tmp is used for that, but since we are talking about making 
clean stuff...



Cheers,

--
Stéphane


--
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/4d95d410.1080...@debian.org

Re: Tracking ghc transition on http://release.debian.org/transitions/

[Stéphane Glondu]

Le 31/03/2011 20:35, Joachim Breitner a écrit :
 I’m surprised by the dependency level calculation – haskell-transformers
 should be on one level with -deepseq. But maybe that calculation is
 confused as the binary package names are changing during the transition.

The code assumes (among other things) that there are no loops in the
dependency graph. I don't know exactly what meaningful information it
could convey when there are loops in the dependency graph.


Cheers,

-- 
Stéphane


--
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/4d94f6b3.8080...@debian.org

Bug#618871: transition: ocaml

[Stéphane Glondu]

Le 29/03/2011 19:52, Julien Cristau a écrit :
 The Debian OCaml team is ready for a transition to OCaml 3.12.0. All
 packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will
 be affected.

 I am waiting for the approval from the release team to proceed.

 Any news on that?

 Clearly not.

Could you give more detail, please? Is there an ongoing transition
somehow conflicting and that could use some help? I heard about gmp, but
gmp/gmp4 (and why, which had been temporarily removed from testing) just
migrated to testing, and I didn't find any open bugs tracking this. I
haven't looked at other transitions... but I ask here because you are
supposed to be more knowledgeable :-)

According to [1], there remains stuff, though, but (on amd64 at least),
most of the packages go green after a binNMU. Obvious issues are
cheesetracker, gclcvs, genius, guile-1.8, lilypond, netrek-client-cow,
strongswan, acl2, hol88, mlgmp [I could probably fix that, but
haven't been notified], linbox [not sure], maxima, open-cobol,
regina-normal, units-filter [not sure]... is there anyone working on
that right now? FTR, we have far less unsolved obvious issues in the
planned ocaml transition, and they are documented at [2].

It would be nice if we used the power of our BTS and set blockers for
this bug (#618871), so that someone outside the release team (such as
me) can see more clearly [than Clearly not.] what is going on.

[1] http://release.debian.org/transitions/gmp5.html
[2] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions


Cheers,

-- 
Stéphane




--
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/4d93b180.9090...@debian.org

Bug#618871: transition: ocaml

[Stéphane Glondu]

Le 19/03/2011 08:40, Stéphane Glondu a écrit :

The Debian OCaml team is ready for a transition to OCaml 3.12.0. All
packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will
be affected.

I am waiting for the approval from the release team to proceed.


Any news on that?


Cheers,

--
Stéphane



--
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/4d91df17.6060...@debian.org

Bug#618871: transition: ocaml

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

The Debian OCaml team is ready for a transition to OCaml 3.12.0. All
packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will
be affected.

I am waiting for the approval from the release team to proceed.


Cheers,

-- 
Stéphane

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
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/20110319074005.5170.23521.report...@korell.up7.fr

Bug#615062: nmu: packages broken by #613848

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hello,

Here is a binNMU request for packages that are broken by the
(mini-)transition tracked with #613848. I've simulated it on amd64,
and everything compiles [1] except ocaml-melt which seems broken by an
external bug [2, not investigated yet] and liquidsoap, which is
BD-uninstallable independently of this transition.

# nothing to do for lablgtk2 (= 2.14.2+dfsg-1)
# camlimages has the following arch:all packages: libcamlimages-ocaml-doc
nmu 4 camlimages_1:3.0.1-5 . ALL . -m 'Rebuild with new lablgtk2'
dw camlimages_1:3.0.1-5 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1)'
# advi has the following arch:all packages: advi-examples
# ocamlgraph has the following arch:all packages: libocamlgraph-ocaml-doc
nmu 1 ocamlgraph_1.5-1 . ALL . -m 'Rebuild with new lablgtk2'
dw ocamlgraph_1.5-1 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1)'
# nothing to do for pcre-ocaml (= 6.2.2-1)
# ocamlnet has the following arch:all packages: libocamlnet-ocaml-doc
nmu 2 ocamlnet_2.2.9-8 . ALL . -m 'Rebuild with new lablgtk2, pcre-ocaml'
dw ocamlnet_2.2.9-8 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1), 
libpcre-ocaml (= 6.2.2-1)'
# nothing to do for ounit (= 1.1.0-3)
# nothing to do for bin-prot (= 1.2.24-1)
nmu 3 cairo-ocaml_20090223-3 . ALL . -m 'Rebuild with new lablgtk2'
dw cairo-ocaml_20090223-3 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1)'
# cameleon has the following arch:all packages: cameleon-doc
nmu 2 cameleon_1.9.19-2 . ALL . -m 'Rebuild with new lablgtk2, pcre-ocaml'
dw cameleon_1.9.19-2 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1), 
libpcre-ocaml (= 6.2.2-1)'
# nothing to do for camlp5 (= 6.02.1-1)
nmu 4 cduce_0.5.3-2 . ALL . -m 'Rebuild with new ocamlnet, pcre-ocaml'
dw cduce_0.5.3-2 . ALL . -m 'libapache2-mod-ocamlnet (= 2.2.9-8+b2), 
libpcre-ocaml (= 6.2.2-1)'
nmu 2 dose2_1.4.2-3 . ALL . -m 'Rebuild with new pcre-ocaml'
dw dose2_1.4.2-3 . ALL . -m 'libpcre-ocaml (= 6.2.2-1)'
# cmigrep has the following arch:all packages: cmigrep
# nothing to do for coq (= 8.2.pl2+dfsg-2)
nmu 1 frama-c_20100401+boron+dfsg-5 . ALL . -m 'Rebuild with new lablgtk2, 
ocamlgraph'
dw frama-c_20100401+boron+dfsg-5 . ALL . -m 'liblablgtk2-gl-ocaml (= 
2.14.2+dfsg-1), libocamlgraph-ocaml-dev (= 1.5-1+b1)'
# freetennis has the following arch:all packages: freetennis-common
nmu 2 pxp_1.2.1-2 . ALL . -m 'Rebuild with new ocamlnet'
dw pxp_1.2.1-2 . ALL . -m 'libapache2-mod-ocamlnet (= 2.2.9-8+b2)'
# galax has the following arch:all packages: galax-doc
nmu 1 galax_1.1-7 . ALL . -m 'Rebuild with new ocamlnet, pcre-ocaml, pxp'
dw galax_1.1-7 . ALL . -m 'libapache2-mod-ocamlnet (= 2.2.9-8+b2), 
libpcre-ocaml (= 6.2.2-1), libpxp-ocaml-dev (= 1.2.1-2+b2)'
# janest-core has the following arch:all packages: libcore-ocaml-doc
nmu 2 json-wheel_1.0.6-2 . ALL . -m 'Rebuild with new ocamlnet'
dw json-wheel_1.0.6-2 . ALL . -m 'libapache2-mod-ocamlnet (= 2.2.9-8+b2)'
nmu 2 json-static_0.9.8-1 . ALL . -m 'Rebuild with new json-wheel'
dw json-static_0.9.8-1 . ALL . -m 'libjson-wheel-ocaml-dev (= 1.0.6-2+b2)'
nmu 4 lablgtkmathview_0.7.8-5 . ALL . -m 'Rebuild with new lablgtk2'
dw lablgtkmathview_0.7.8-5 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1)'
# nothing to do for ledit (= 2.02.1-1)
nmu 2 ocaml-duppy_0.3.1-1 . ALL . -m 'Rebuild with new pcre-ocaml'
dw ocaml-duppy_0.3.1-1 . ALL . -m 'libpcre-ocaml (= 6.2.2-1)'
nmu 3 ocaml-lastfm_0.2.0-1 . ALL . -m 'Rebuild with new pcre-ocaml, ocamlnet'
dw ocaml-lastfm_0.2.0-1 . ALL . -m 'libpcre-ocaml (= 6.2.2-1), 
libapache2-mod-ocamlnet (= 2.2.9-8+b2)'
# liquidsoap has the following arch:all packages: liguidsoap
nmu 2 liquidsoap_0.9.2-3 . ALL . -m 'Rebuild with new ocaml-duppy, 
ocaml-lastfm, pcre-ocaml'
# liquidsoap is otherwise BD-Uninstallable
dw liquidsoap_0.9.2-3 . ALL . -m 'libduppy-ocaml-dev (= 0.3.1-1+b2), 
liblastfm-ocaml-dev (= 0.2.0-1+b3), libpcre-ocaml (= 6.2.2-1)'
# nothing to do for ocaml-text (= 0.4-2)
# lwt has the following arch:all packages: liblwt-ocaml-doc
nmu 1 lwt_2.1.1-1 . ALL . -m 'Rebuild with new lablgtk2, ocaml-text'
dw lwt_2.1.1-1 . ALL . -m 'liblablgtk2-gl-ocaml (= 2.14.2+dfsg-1), 
libtext-ocaml (= 0.4-2)'
# nothing to do for matita (= 0.5.8-3)
nmu 2 mikmatch_1.0.2-1 . ALL . -m 'Rebuild with new pcre-ocaml'
dw mikmatch_1.0.2-1 . ALL . -m 'libpcre-ocaml (= 6.2.2-1)'
# mlpost has the following arch:all packages: libmlpost-ocaml-doc
nmu 1 mlpost_0.8.1-2 . ALL . -m 'Rebuild with new cairo-ocaml'
dw mlpost_0.8.1-2 . ALL . -m 'libcairo-ocaml (= 20090223-3+b3)'
# ocsigen has the following arch:all packages: libocsigen-ocaml-doc, ocsigen-dev
nmu 1 ocsigen_1.3.3-2 . ALL . -m 'Rebuild with new lwt, ocamlnet, pcre-ocaml'
dw ocsigen_1.3.3-2 . ALL . -m 'liblwt-glib-ocaml (= 2.1.1-1+b1), 
libapache2-mod-ocamlnet (= 2.2.9-8+b2), libpcre-ocaml (= 6.2.2-1)'
# nothing to do for postgresql-ocaml (= 1.14.0-1)
nmu 4 nurpawiki_1.2.3-4 . ALL . -m 'Rebuild with new ocsigen, 

Bug#613848: Bug#615140: libsoundtouch-dev: needs to provide libsoundtouch1-dev

[Stéphane Glondu]

Le 26/02/2011 01:38, Julien Cristau a écrit :
 Package: libsoundtouch-dev
 Version: 1.5.0-3
 Severity: serious
 Justification: i said so
 
 Apparently you decided to start a SONAME transition with no coordination
 with the release team.  This will clash with the ongoing transition to
 ffmpeg 0.6, and delay things by that much. [...]

FYI, it also affects the ongoing transition of OCaml libraries
(#613848), because liquidsoap (which must be recompiled) indirectly
depends on soundtouch and is therefore currently BD-Uninstallable.


Cheers,

-- 
Stéphane




--
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/4d68770f.3090...@glondu.net

Bug#614030: pu: package ocsigen/1.3.3-1squeeze1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu

Le 15/02/2011 19:34, Stéphane Glondu a écrit :
 Here it is. There is also currently a pending upload to unstable fixing
 the bug (among other things).

Turning this into a bug report so that it can be more easily tracked.

-- 
Stéphane
diff --git a/debian/changelog b/debian/changelog
index 9b60b57..8aabc15 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ocsigen (1.3.3-1squeeze1) stable; urgency=low
+
+  * Add missing dependencies to ocsigen: libocsigen-xhtml-ocaml-dev and
+liblwt-ssl-ocaml-dev (Closes: #613372)
+
+ -- Stéphane Glondu glo...@debian.org  Tue, 15 Feb 2011 19:27:09 +0100
+
 ocsigen (1.3.3-1) unstable; urgency=low
 
   * New upstream release
diff --git a/debian/control b/debian/control
index ac1ffa2..bf87163 100644
--- a/debian/control
+++ b/debian/control
@@ -30,6 +30,8 @@ Package: ocsigen
 Section: httpd
 Architecture: any
 Depends: adduser, psmisc, procps,
+ libocsigen-xhtml-ocaml-dev,
+ liblwt-ssl-ocaml-dev,
  ${ocaml:Depends},
  ${shlibs:Depends},
  ${misc:Depends}
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 6c7ed3b..f2f78be 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,3 +1,5 @@
 [DEFAULT]
 pristine-tar = True
 cleaner = debuild clean  dh_quilt_unpatch  dh_clean
+upstream-branch = squeeze/upstream
+debian-branch = squeeze/master

Bug#613848: (mini-)transition of OCaml libraries: camlp5, lablgtk2, ...

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
Owner: glo...@debian.org
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I've prepared a small transition of some libs to new upstream
versions, to be completed before the transition to OCaml = 3.12 (not
yet planned). I've documented it at the end of [1]. It will involve
some binNMUs and Britney hints, but won't be as complex as a
full-blown OCaml transition. Unless there is a strong objection, I'm
planning to start it this week-end.

[1] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions


Cheers,

-- 
Stéphane

(please explain about the transition: impacted packages, reason, ...)

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20110217174208.12989.14795.report...@aspirine.inria.fr

Bug#613848: Transition to OCaml 3.12.0...

[Stéphane Glondu]

Le 10/02/2011 10:12, Sylvain Le Gall a écrit :
 I also have a pair of packages to update (sexplib, type-conv, bin-prot,
 ounit). Since some of them will break the distribution and should
 trigger the need to binNMU some other packages, I am not sure how to
 proceed: 1) upload new version during the transition, 2) do it before
 and ask for binNMU or 3) do it before and don't ask for binNMU

I've just realized that the last upstream release of type-conv and
sexplib310 don't compile with ocaml 3.11.2. So for these two, we have no
choice, we have to do 1).

I've updated sexplib310 packaging in git, and upstream changes look
pretty invasive (we are several versions behind). Work has to be done to
make sure all rdeps build, and I'd rather stick to the version currently
in unstable if this work is not done before we start the OCaml transition.

The latest upstream of type-conv seems to be already packaged in git.
Sylvain, what are your feeling about updating it during OCaml
transition? If you are unsure, I've got a patch to make the version
currently in unstable compile with OCaml 3.12.

ounit is already in experimental and seems ready to be part of #613848
(but I'd like to have confirmation).

I've updated bin-prot packaging in git, and upstream changes look
innocuous. I'm planning to make it part of #613848.


Cheers,

-- 
Stéphane




--
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/4d5e1917.7010...@debian.org

S-P-U for #613372?

[Stéphane Glondu]

Dear release team,

There are missing dependencies in the ocsigen package of squeeze (cf. 
#613372). Would it be possible to fix that for the next point release?



Cheers,

--
Stéphane


--
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/4d59622b.7090...@debian.org

Bug#612892: RM: matita/0.5.8-2+b1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hello,

With approval of its maintainer, and for the reasons explained in [1],
I request the removal of matita from testing.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612891


Cheers,

-- 
Stéphane

-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/2011023134.2511.87908.report...@aspirine.inria.fr

Bug#603968: unblock: camlbz2/0.6.0-6

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

Please unblock package camlbz2:

camlbz2 (0.6.0-6) unstable; urgency=low

  * Add dependency to libbz2-ocaml-dev (Closes: #603939)
  * Add myself to Uploaders, and remove Stefano

 -- Stéphane Glondu glo...@debian.org  Thu, 18 Nov 2010 23:06:25 +0100

unblock camlbz2/0.6.0-6


Cheers,

-- 
Stéphane

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20101118224510.19730.55584.report...@aspirine.inria.fr

Bug#600334: freeze exception for babeld/1.0.2-1

[Stéphane Glondu]

Le 25/10/2010 20:54, Julien Cristau a écrit :
 There has been a recent new bugfix release of babeld that fixes a
 possible crash on mips architectures. Attached is the diff of what I
 am planning to upload against the current version in unstable (and
 testing).

 Are you sure the bug affected debian in the first place?

No.

-- 
Stéphane




--
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/4cc5d490.7090...@glondu.net

Bug#600334: freeze exception for babeld/1.0.2-1

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Hello,

There has been a recent new bugfix release of babeld that fixes a
possible crash on mips architectures. Attached is the diff of what I
am planning to upload against the current version in unstable (and
testing).

Can it be granted a freeze exception?


Cheers,

-- 
Stéphane

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/CHANGES b/CHANGES
index 8a138da..14fc816 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,7 @@
+1 October 2010: babeld 1.0.2:
+
+  * Worked around a gcc bug that would cause assertion failures on MIPS.
+
 2 May 2010: babeld 1.0.1:
 
   * Fixed a bug that could cause input filters to be ignored.
diff --git a/debian/changelog b/debian/changelog
index 56422c2..ec21adc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+babeld (1.0.2-1) UNRELEASED; urgency=low
+
+  * New upstream release
+
+ -- Stéphane Glondu glo...@debian.org  Sat, 16 Oct 2010 09:01:24 +0200
+
 babeld (1.0.1-1) unstable; urgency=low
 
   * New upstream release
diff --git a/route.c b/route.c
index b1a90db..3997af5 100644
--- a/route.c
+++ b/route.c
@@ -234,7 +234,7 @@ switch_routes(struct route *old, struct route *new)
 local_notify_route(new, LOCAL_CHANGE);
 }
 
-void
+static void
 change_route_metric(struct route *route, unsigned newmetric)
 {
 int old, new;
@@ -262,6 +262,13 @@ change_route_metric(struct route *route, unsigned newmetric)
 local_notify_route(route, LOCAL_CHANGE);
 }
 
+static void
+retract_route(struct route *route)
+{
+route-refmetric = INFINITY;
+change_route_metric(route, INFINITY);
+}
+
 int
 route_feasible(struct route *route)
 {
@@ -326,31 +333,30 @@ find_best_route(const unsigned char *prefix, unsigned char plen, int feasible,
 void
 update_route_metric(struct route *route)
 {
-int oldmetric;
-int newmetric;
+int oldmetric = route_metric(route);
 
-oldmetric = route_metric(route);
 if(route_expired(route)) {
 if(route-refmetric  INFINITY) {
 route-seqno = seqno_plus(route-src-seqno, 1);
-route-refmetric = INFINITY;
+retract_route(route);
+if(oldmetric  INFINITY)
+route_changed(route, route-src, oldmetric);
 }
-newmetric = INFINITY;
 } else {
 struct neighbour *neigh = route-neigh;
 int add_metric = input_filter(route-src-id,
   route-src-prefix, route-src-plen,
   neigh-address,
   neigh-network-ifindex);
-newmetric = MIN(route-refmetric +
-add_metric +
-neighbour_cost(route-neigh),
-INFINITY);
-}
-
-if(newmetric != oldmetric) {
-change_route_metric(route, newmetric);
-route_changed(route, route-src, oldmetric);
+int newmetric = MIN(route-refmetric +
+add_metric +
+neighbour_cost(route-neigh),
+INFINITY);
+
+if(newmetric != oldmetric) {
+change_route_metric(route, newmetric);
+route_changed(route, route-src, oldmetric);
+}
 }
 }
 
@@ -572,10 +578,11 @@ retract_neighbour_routes(struct neighbour *neigh)
 i = 0;
 while(i  numroutes) {
 if(routes[i].neigh == neigh) {
-unsigned short oldmetric = route_metric(routes[i]);
-if(oldmetric != INFINITY) {
-change_route_metric(routes[i], INFINITY);
-route_changed(routes[i], routes[i].src, oldmetric);
+if(routes[i].refmetric != INFINITY) {
+unsigned short oldmetric = route_metric(routes[i]);
+retract_route(routes[i]);
+if(oldmetric != INFINITY)
+route_changed(routes[i], routes[i].src, oldmetric);
 }
 }
 i++;
diff --git a/route.h b/route.h
index 64fa3d2..72a1098 100644
--- a/route.h
+++ b/route.h
@@ -52,7 +52,6 @@ void flush_network_routes(struct network *net, int v4only);
 void install_route(struct route *route);
 void uninstall_route(struct route *route);
 void switch_route(struct route *old, struct route *new);
-void change_route_metric(struct route *route, unsigned newmetric);
 int route_feasible(struct route *route);
 int route_old(struct route *route);
 int route_expired(struct route *route);
diff --git a/util.h b/util.h
index 62abb2b..d142018 100644
--- a/util.h
+++ b/util.h
@@ -20,7 +20,15 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS

Bug#599174: unblock: mldonkey/3.0.3-2

[Stéphane Glondu]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

Please unblock package mldonkey. Last changelog entry:

mldonkey (3.0.3-2) unstable; urgency=low

  * Add myself to Uploaders
  * Add Danish debconf translation (Closes: #599126)

 -- Stéphane Glondu glo...@debian.org  Tue, 05 Oct 2010 10:44:57 +0200


unblock mldonkey/3.0.3-2


Cheers,

-- 
Stéphane

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

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
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/20101005095526.30812.35429.report...@korell.up7.fr

Re: Freeze for LLVM packages

[Stéphane Glondu]

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
)

Freeze exception for llvm/2.6-9.1

[Stéphane Glondu]

Dear Release Team,

I've uploaded a few days ago to DELAYED/5 a NMU of llvm (2.6-9.1) that
should be granted a freeze exception. It fixes three bugs (incl. 2 RC)
and a few Lintian/Piuparts checks. The last changelog entry is:

llvm (2.6-9.1) unstable; urgency=low

  * Non-maintainer upload.
  * llvm-runtime:
- replace Conflicts with previous version by Breaks
- add explicit set -e in maintainer scripts
- properly remove llvm.binfmt in prerm script
  * llvm-dev:
- install vim files in /usr/share/vim/addons, add README.Debian
  (Closes: #593190)
- add dependency to libffi-dev (Closes: #573368)
  * libllvm-ocaml-dev:
- apply Sylvain Le Gall's patch to fix META filename (Closes: #583475)
- add suggestion to ocaml-findlib
  * Add debian/source/format

 -- Stéphane Glondu glo...@debian.org  Thu, 19 Aug 2010 18:53:44 +0200

The full diff is available at:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593624

NB: The package has still 2 days to spend in the DELAYED queue. I'm not
sure when this request should have been sent...


Cheers,

-- 
Stéphane


--
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/4c70abef.6070...@debian.org

Freeze exception for mldonkey

[Stéphane Glondu]

Hi,

mldonkey/3.0.3-1 has been uploaded to unstable before the announce of
the freeze, but it seems blocked nonetheless (according to the PTS).

This is a new upstream release, and has many changes... but most of them
are bugfixes. The diff from the version in testing would be meaningless
(but can be seen easily with the git repository at [1]), but the
upstream changelog is available at [2]. It also fixes at least 3 Debian
(minor) bugs (#544175, #555602, #580087) and is a leaf package.

Can mldonkey be granted a freeze exception?

If yes, one more query: currently, it fails to build from source and
upstream has sent me a patch to fix it (I've tested it on
kfreebsd-amd64). I've attached the patch to this mail.

Would this new version be granted a freeze exception?

[1] http://git.debian.org/?p=pkg-ocaml-maint/packages/mldonkey.git
[2]
http://git.debian.org/?p=pkg-ocaml-maint/packages/mldonkey.git;a=blob;f=distrib/ChangeLog;hb=HEAD


Cheers,

-- 
Stéphane
commit af4be2718b6b81e16d4e72e2f8991385c7ffa564
Author: Stephane Glondu st...@glondu.net
Date:   Sun Aug 8 16:16:31 2010 -0400

Fix build on kfreebsd

diff --git a/debian/changelog b/debian/changelog
index a3f3865..5de7fc2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mldonkey (3.0.3-2) unstable; urgency=low
+
+  * Fix build on kfreebsd
+
+ -- Stéphane Glondu glo...@debian.org  Sun, 08 Aug 2010 16:15:50 -0400
+
 mldonkey (3.0.3-1) unstable; urgency=low
 
   * Team upload.
diff --git a/debian/patches/0004-Fix-build-on-kfreebsd.patch b/debian/patches/0004-Fix-build-on-kfreebsd.patch
new file mode 100644
index 000..9563db9
--- /dev/null
+++ b/debian/patches/0004-Fix-build-on-kfreebsd.patch
@@ -0,0 +1,38 @@
+From: spiralvoice spiralvo...@users.sourceforge.net
+Date: Sun, 8 Aug 2010 16:14:00 -0400
+Subject: [PATCH] Fix build on kfreebsd
+
+Origin: upstream, https://savannah.nongnu.org/patch/?7273
+---
+ config/configure.in |3 +++
+ src/utils/lib/stubs_c.c |2 +-
+ 2 files changed, 4 insertions(+), 1 deletions(-)
+
+diff --git a/config/configure.in b/config/configure.in
+index 0dfcd93..6313ae1 100644
+--- a/config/configure.in
 b/config/configure.in
+@@ -105,6 +105,9 @@ END
+ SYSTEM=cygwin
+ OS_FILES2=cygwin
+ ;;
++  *kfreebsd*)
++SYSTEM=kfreebsd
++;;
+   *freebsd*|*dragonfly*)
+ SYSTEM=freebsd
+ CPPFLAGS=${CPPFLAGS} -I/usr/local/include
+diff --git a/src/utils/lib/stubs_c.c b/src/utils/lib/stubs_c.c
+index 02a4276..c9a0e6d 100644
+--- a/src/utils/lib/stubs_c.c
 b/src/utils/lib/stubs_c.c
+@@ -1108,7 +1108,7 @@ copy_statfs (struct statfs *buf)
+ # endif
+   v = copy_int64 (buf-f_frsize); caml_modify (Field (bufv, 10), v);
+ #else
+-#if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(__APPLE__) || defined(__DragonFly__)
++#if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__NetBSD__) || defined(__APPLE__) || defined(__DragonFly__) || defined(__FreeBSD_kernel__)
+ #  if defined(__OpenBSD__) || defined(__NetBSD__) || (defined(__FreeBSD__)  __FreeBSD_version  502000) || defined(__DragonFly__) || defined(__APPLE__)
+ #include sys/syslimits.h
+  v = copy_int64 (NAME_MAX); caml_modify (Field (bufv, 8), v);
+-- 
diff --git a/debian/patches/series b/debian/patches/series
index efbcb3b..d2f89ca 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 0001-Use-usr-bin-see-as-default-previewer.patch
 0002-Remove-bashisms.patch
 0003-Fix-tiger-tree-corruption.patch
+0004-Fix-build-on-kfreebsd.patch

Re: Freeze exception for mldonkey

[Stéphane Glondu]

Le 08/08/2010 17:13, Stéphane Glondu a écrit :
 If yes, one more query: currently, it fails to build from source [...]

I meant on kfreebsd-*.

-- 
Stéphane


--
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/4c5f2306.4020...@debian.org