Nabble - debian-ocaml-maint

Processing of lablgtk2_2.14.0+dfsg-2_amd64.changes

2009-11-29T10:44:41Z

lablgtk2_2.14.0+dfsg-2_amd64.changes uploaded successfully to localhost
along with the files:
lablgtk2_2.14.0+dfsg-2.dsc
lablgtk2_2.14.0+dfsg-2.diff.gz
liblablgtk2-ocaml_2.14.0+dfsg-2_amd64.deb
liblablgtk2-gl-ocaml_2.14.0+dfsg-2_amd64.deb
liblablgtk2-gnome-ocaml_2.14.0+dfsg-2_amd64.deb
liblablgtksourceview2-ocaml_2.14.0+dfsg-2_amd64.deb
liblablgtk2-ocaml-dev_2.14.0+dfsg-2_amd64.deb
liblablgtk2-gl-ocaml-dev_2.14.0+dfsg-2_amd64.deb
liblablgtk2-gnome-ocaml-dev_2.14.0+dfsg-2_amd64.deb
liblablgtksourceview2-ocaml-dev_2.14.0+dfsg-2_amd64.deb
liblablgtk2-ocaml-doc_2.14.0+dfsg-2_all.deb

Greetings,

Your Debian queue daemon (running on host ries.debian.org)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: lablgtk2 transition

2009-11-29T09:47:24Z

Stéphane Glondu wrote:

> Hello,
>
> I'd like to upload lablgtk2 (OCaml bindings to GTK/Gnome stuff) v2.14 to
> unstable soon. It has been in experimental for a while.
>
> The main change is the drop of gtksourceview bindings (in favour of
> gtksourceview2). All reverse-dependencies have been adapted AFAIK
> (except frama-c, maybe, but Mehdi says it's ok).
>
> As usual, it breaks ABI compatibility, so some binNMU will be needed.
> This transition should be limited to a few OCaml packages, though.
>
> Any objection/approval?

Please upload and let us know which binNMUs (and dep-waits) are needed.

Cheers

Luk

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

fieldslib 0.1.0-1 MIGRATED to testing

2009-11-29T08:39:26Z

FYI: The status of the fieldslib source package
in Debian's testing distribution has changed.

Previous version: (not in testing)
Current version: 0.1.0-1

--
This email is automatically generated once a day. As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Future Icon Records] You've been added to our mailing list.

2009-11-28T19:59:03Z

Hi I represent KONVICT MUSIC recording artist COLBY O'DONIS (Just Dance Ft Colby O'Donis. Beautiful Ft Colby O'Donis) and we want to share with you His first Original Christmas song I made a radio edit of so happy here it is if you like it Radio Edit Of - So Happy https://rcpt.yousendit.com/782608652/9a8972b464bfc006aa5139a89722060d Instrumental Radio Edit - So Happy https://rcpt.yousendit.com/782608822/4c2efde9129f9900fe9782387ef48410 

--------
Get your free download from Future Icon Records here: http://fburls.com/26-Niov8PPF
--------

You have been added to the Future Icon Records fan list!

If you would like to verify your info or add more to your fan profile, you can do so by clicking on the following link:

http://www.FanBridge.com/signup/fansignup.php?userid=129853&email=debian-ocaml-maint@...&confCode=2hFa1P1ah5h3rhUhakh56hh5YP

--
This list is powered by FanBridge, the world's leading provider of fan relationship management services for artists.

With FanBridge your information is always secure.

For more information about FanBridge please visit http://www.FanBridge.com/learn/
--

***Important: Please be sure to add the email address (futureiconrecords@...) to your safe senders list.***

Here's how:

Gmail
1. Click Contacts along the left side of any Gmail page.
2. Click Add Contact.
3. In the primary email address box, type futureiconrecords@....
4. Click Save.

AOL (version 9.0 or higher)
1. Click the Mail menu and select Address Book.
2. In the pop up box, click the Add button.
3. In the "Other E-Mail" field, type futureiconrecords@....
4. Make our From address the "Primary E-Mail" address by checking the associated check box.
5. Click the Save button.

AOL 8.0
1. Open this confirmation email.
2. Click Add Address.
3. Verify the sender's contact information (futureiconrecords@...).
4. Click Save.

Yahoo!
1. Click the "addresses" button
2. Select "Add Contact"
3. Save the futureiconrecords@... to your contacts list.

Hotmail
1. Click Options.
2. On the left side of the page, click Mail, and then click Junk E-Mail Protection.
3. Click Safe List.
4. Type futureiconrecords@..., and then click Add.

Outlook
1. Right-click on a message from futureiconrecords@....
2. Point to Junk E-mail, and click Add Sender to Safe Senders List.

----------------------------------------
Future Icon Records sent this email to debian-ocaml-maint@...
Questions? Contact futureiconrecords@... or Future Icon Records, c/o FanBridge, Inc. - 14525 SW Millikan Way, #16910, Beaverton, Oregon 97005, United States

Update Your Information - http://fburls.com/44-0j54kbOH
Forward to a friend - http://fburls.com/75-I1pGL8oZ
Unsubscribe - http://fburls.com/58-u2zZZ2H8
Privacy Policy - http://www.FanBridge.com/learn/privacy.php

This email message is powered by FanBridge:
http://www.FanBridge.com/b.php?id=129853
Powering Valuable Fan Relationships

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: lablgtk2 transition

2009-11-28T09:35:48Z

On Sat, Nov 28, 2009 at 01:55:49PM +0100, Stéphane Glondu wrote:
> Any objection/approval?

Fine by me.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

signature.asc (197 bytes) Download Attachment

apron 0.9.10-3 MIGRATED to testing

2009-11-28T08:39:24Z

FYI: The status of the apron source package
in Debian's testing distribution has changed.

Previous version: (not in testing)
Current version: 0.9.10-3

--
This email is automatically generated once a day. As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See http://release.debian.org/testing-watch/ for more information.

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Processed: tagging 532289

2009-11-28T08:03:07Z

Processing commands for control@...:

> # 4 months is not pending
> tags 532289 - pending
Bug #532289 [matita] matita fails to build in a non-networking environment.
Removed tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: lablgtk2 transition

2009-11-28T05:42:02Z

Hello,

On 28-11-2009, Stéphane Glondu <steph@...> wrote:
>
> Any objection/approval?
>

Fine with me.

Regards,
Sylvain Le Gall

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

lablgtk2 transition

2009-11-28T04:55:49Z

Hello,

I'd like to upload lablgtk2 (OCaml bindings to GTK/Gnome stuff) v2.14 to
unstable soon. It has been in experimental for a while.

The main change is the drop of gtksourceview bindings (in favour of
gtksourceview2). All reverse-dependencies have been adapted AFAIK
(except frama-c, maybe, but Mehdi says it's ok).

As usual, it breaks ABI compatibility, so some binNMU will be needed.
This transition should be limited to a few OCaml packages, though.

Any objection/approval?

Cheers,

--
Stéphane

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-27T02:32:20Z

Hi,

Am Freitag, den 27.11.2009, 09:05 +0100 schrieb Stefano Zacchiroli:

> On Thu, Nov 26, 2009 at 07:31:08PM +0100, Luk Claes wrote:
> > Ignoring older packages is also not correct. If an Arch: any package
> > with an older version has a strict dependency on an Arch: all package
> > which is still available, apt will happily install them if you try to
> > install the Arch:any package and will refuse to install the newer
> > Arch:all package if you would try that AFAIK.
>
> That's clear, but I though that was _intended_, for what concerns the
> build. A rationale for that is that the older package will vanish soon,
> it is there only temporarily, so it is pointless to build other packages
> against it: it will just postpone (potential) build problems.
>
> Wasn't that the rationale of the patch in the first place?

I think I didn’t give it too much thought back than. I just noticed that
edos-debcheck would mark a package as bd-installable when the buildd’s
were not able to install the dependencies. I can’t recall the exact
circumstances.

Why don’t you just remove the patch and see what breaks, then we’ll have
examples to discuss :-)

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
nomeata@... | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@... | http://people.debian.org/~nomeata

signature.asc (205 bytes) Download Attachment

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-27T00:05:11Z

On Thu, Nov 26, 2009 at 07:31:08PM +0100, Luk Claes wrote:
> Ignoring older packages is also not correct. If an Arch: any package
> with an older version has a strict dependency on an Arch: all package
> which is still available, apt will happily install them if you try to
> install the Arch:any package and will refuse to install the newer
> Arch:all package if you would try that AFAIK.

That's clear, but I though that was _intended_, for what concerns the
build. A rationale for that is that the older package will vanish soon,
it is there only temporarily, so it is pointless to build other packages
against it: it will just postpone (potential) build problems.

Wasn't that the rationale of the patch in the first place?

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T11:38:48Z

On Thu, Nov 26, 2009 at 11:56:15AM +0100, Joachim Breitner wrote:

> >
> > I'm wondering if we can't be smarter about merging those 2 files.
> > It currently only keeps the newest version of all packages, and I
> > wonder if it's a problem if we just concatenate them.
> >
> > The commit log shows:
> > commit 9f9abf7546c8e4a5b4af7daa58b2bbc72964e90c
> > Author: Joachim Breitner <nomeata@...>
> > Date: Wed Jul 29 16:06:57 2009 +0200
> >
> > Use keep-latest in trigger.often
> >
> > This makes sure the Packages and Sources as passed to wanna-build do not
> > contain old entries, so that they are not passed to edos-debcheck. They
> > would not be considered by apt on the buildds for installation anyways.
> >
> > And I'm not so sure about that anymore.
>
> neither am I, since I didn't really do anything about this since
> DebConf. So the following might be bogus:
>
> I don't think that this patch was related only to arch-all package: I
> think what can happen is that source package S build-depends on P, P has
> different versions in the two packages files. The newer version has an
> unsatisfiable dependency, but the older version does not. Apt would not
> install P, as it only considers the newer version, but edos-depcheck
> would assume that S is bd-installable, as it does consider the old
> version of P.

I think that for the source packages we only want to keep the
latest version. It might be that the previous version's build
dependencies can't be installed, and that it was actually the
reason why it got uploaded in the first place. But we don't
care about that, we just want to know it for the current source
version we're going to try to build.

The buildd has both Packages files, and apt will try to install
the latest version from there. I think sbuild call apt-get with
all packages that should be installed, including all the
dependencies. So I guess it's always going to try and install the
latest arch all package too. So I guess how it's setup now
actually makes edos behave the same as the buildds.

So it's my understanding now that only keeping the latest
version of the source and binary packages and give that
to edos does the right thing.

The options I currently see:
- sbuild should just install the build-dependencies itself, not
things they depend on.
- make apt-get smarter to try different versions
- ftp-master provides a Packages for per arch for the buildds.

In the first case we could make a packages file for edos that
keeps the latest arch any and all arch all packages. This
assumes two things:
- apt will actually try the older version if it's not on the
command line
- You don't build-depend on the arch all package. edos might
think the old version is installable while apt tries the new.

Kurt

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T10:52:16Z

On Thu, Nov 26, 2009 at 07:31:08PM +0100, Luk Claes wrote:

> Stefano Zacchiroli wrote:
> > On Thu, Nov 26, 2009 at 01:34:29PM +0100, Philipp Kern wrote:
> >> IIRC if you say, for instance, "apt-get install foo", then apt only considers
> >> the newest version (well, subjected to pinning, but let's consider that
> >> pinning is not present) and then tries to satisfy its dependencies. It does
> >> not notice that it's not installable *and then* retry with older versions.
> >
> > You're absolutely right: having played with more powerful dependency
> > solvers in the last months made me forget for a minute one of the most
> > annoying limitations of apt :-)
> >
> > So yes, given the specificities of the issue here, I thing we should add
> > a flag to edos-builddebcheck that made it ignore, directly during
> > parsing, the non-most-recent version of any package. I believe it should
> > not be the default, since edos-builddebcheck really answers the question
> > "are build-dep satisfiable?" and not "are build-dep satisfiable by
> > apt?". Of course wanna-build will pass that flag to edos-builddebcheck.
>
> Ignoring older packages is also not correct. If an Arch: any package
> with an older version has a strict dependency on an Arch: all package
> which is still available, apt will happily install them if you try to
> install the Arch:any package and will refuse to install the newer
> Arch:all package if you would try that AFAIK.

Indeed, edos-(build)debcheck would happily propose to install an
older version of a package to make an installation succeed. Anyway,
we will have to live with the fact that an analysis using
edos-builddebcheck will be an approximation of apt's behaviour since
apt has a build-in strategy that is, from a logical point of view,
incomplete. We can accept false positives (indicating buildability),
but must attempt to avoid false negatives. After Luk's argument that
means that edos-builddebbcheck should see the full list of packages.

-Ralf.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T10:31:08Z

Stefano Zacchiroli wrote:

> On Thu, Nov 26, 2009 at 01:34:29PM +0100, Philipp Kern wrote:
>> IIRC if you say, for instance, "apt-get install foo", then apt only considers
>> the newest version (well, subjected to pinning, but let's consider that
>> pinning is not present) and then tries to satisfy its dependencies. It does
>> not notice that it's not installable *and then* retry with older versions.
>
> You're absolutely right: having played with more powerful dependency
> solvers in the last months made me forget for a minute one of the most
> annoying limitations of apt :-)
>
> So yes, given the specificities of the issue here, I thing we should add
> a flag to edos-builddebcheck that made it ignore, directly during
> parsing, the non-most-recent version of any package. I believe it should
> not be the default, since edos-builddebcheck really answers the question
> "are build-dep satisfiable?" and not "are build-dep satisfiable by
> apt?". Of course wanna-build will pass that flag to edos-builddebcheck.

Ignoring older packages is also not correct. If an Arch: any package
with an older version has a strict dependency on an Arch: all package
which is still available, apt will happily install them if you try to
install the Arch:any package and will refuse to install the newer
Arch:all package if you would try that AFAIK.

Cheers

Luk

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T05:09:36Z

On Thu, Nov 26, 2009 at 01:34:29PM +0100, Philipp Kern wrote:
> IIRC if you say, for instance, "apt-get install foo", then apt only considers
> the newest version (well, subjected to pinning, but let's consider that
> pinning is not present) and then tries to satisfy its dependencies. It does
> not notice that it's not installable *and then* retry with older versions.

You're absolutely right: having played with more powerful dependency
solvers in the last months made me forget for a minute one of the most
annoying limitations of apt :-)

So yes, given the specificities of the issue here, I thing we should add
a flag to edos-builddebcheck that made it ignore, directly during
parsing, the non-most-recent version of any package. I believe it should
not be the default, since edos-builddebcheck really answers the question
"are build-dep satisfiable?" and not "are build-dep satisfiable by
apt?". Of course wanna-build will pass that flag to edos-builddebcheck.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T04:34:29Z

On Thu, Nov 26, 2009 at 12:50:05PM +0100, Stefano Zacchiroli wrote:
> I confess I don't understand this hack/problem. apt-get by default
> considers all versions of any package he finds in a Packages as valid
> candidates to satisfy a dependency (up to pinning of course).

IIRC if you say, for instance, "apt-get install foo", then apt only considers
the newest version (well, subjected to pinning, but let's consider that
pinning is not present) and then tries to satisfy its dependencies. It does
not notice that it's not installable *and then* retry with older versions.

At least that's how I understand it.

Kind regards,
Philipp Kern
--
.''`. Philipp Kern Debian Developer
: :' : http://philkern.de Stable Release Manager
`. `' xmpp:phil@... Wanna-Build Admin
`- finger pkern/key@...

signature.asc (204 bytes) Download Attachment

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T03:50:05Z

On Thu, Nov 26, 2009 at 11:56:15AM +0100, Joachim Breitner wrote:

> I don’t think that this patch was related only to arch-all package: I
> think what can happen is that source package S build-depends on P, P has
> different versions in the two packages files. The newer version has an
> unsatisfiable dependency, but the older version does not. Apt would not
> install P, as it only considers the newer version, but edos-depcheck
> would assume that S is bd-installable, as it does consider the old
> version of P.
>
> Maybe it would be convenient to tell be able to tell edos-debcheck to
> only consider the newest version found for a package, instead of all
> versions, so this merger can be removed.

I confess I don't understand this hack/problem. apt-get by default
considers all versions of any package he finds in a Packages as valid
candidates to satisfy a dependency (up to pinning of course).

So, AFAICT, the only way to fulfill your commit log which stated that
the older package would not be considered anyhow by apt during build, is
actually to have patch apt (or pinned it in some way) to have that
behavior. Is this is the case?

If this is not the case (i.e. apt will consider both arch:all versions
as valid candidates to satisfy a dependency), then no extra feature is
needed on the side of edos-debcheck: it would be enough to pass to it
the exact Packages file which is known to apt at build time.

If this is still the case, then we can either:

a) ignore the problem (at worst edos-builddebcheck will return a false
positive, the build will be attempted and will fail); this is
probably the best approach if the statical impact of this corner case
is low

b) have edos-debcheck implements the same dependency ignore logics
implemented by buildds

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

signature.asc (197 bytes) Download Attachment

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-26T02:56:15Z

Hi,

Am Mittwoch, den 25.11.2009, 23:29 +0100 schrieb Kurt Roeckx:

> There has also been a change on ftp-master's side that it keeps
> the arch all package around of old versions until the arch any
> package of the arch is uploaded. I think this also fixes our
> problem, or atleast a big part of it. There is just one small
> problem with that, and that is the the special Packages file
> for the buildds is one with all arches in it. We merge it with
> the Packages file for the arch.
>
> I'm wondering if we can't be smarter about merging those 2 files.
> It currently only keeps the newest version of all packages, and I
> wonder if it's a problem if we just concatenate them.
>
> The commit log shows:
> commit 9f9abf7546c8e4a5b4af7daa58b2bbc72964e90c
> Author: Joachim Breitner <nomeata@...>
> Date: Wed Jul 29 16:06:57 2009 +0200
>
> Use keep-latest in trigger.often
>
> This makes sure the Packages and Sources as passed to wanna-build do not
> contain old entries, so that they are not passed to edos-debcheck. They
> would not be considered by apt on the buildds for installation anyways.
>
> And I'm not so sure about that anymore.

neither am I, since I didn’t really do anything about this since
DebConf. So the following might be bogus:

I don’t think that this patch was related only to arch-all package: I
think what can happen is that source package S build-depends on P, P has
different versions in the two packages files. The newer version has an
unsatisfiable dependency, but the older version does not. Apt would not
install P, as it only considers the newer version, but edos-depcheck
would assume that S is bd-installable, as it does consider the old
version of P.

Maybe it would be convenient to tell be able to tell edos-debcheck to
only consider the newest version found for a package, instead of all
versions, so this merger can be removed.

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
nomeata@... | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata@... | http://people.debian.org/~nomeata

signature.asc (205 bytes) Download Attachment

Bug#558090: ITP: camljava -- interface between OCaml and Java via Caml/C interface and JNI

2009-11-26T02:44:48Z

Package: wnpp
Severity: wishlist
Owner: Stefano Zacchiroli <zack@...>

* Package name : camljava
Version : 0.3
Upstream Author : Xavier Leroy
* URL : http://pauillac.inria.fr/~xleroy/software.html#camljava
* License : LGPL
Programming Lang: OCaml, C, Java
Description : interface between OCaml and Java via Caml/C interface and JNI

CamlJava is an interface between OCaml and Java allowing programs written in
one of the two languages to call code written in the other.
.
Interaction among the two languages happen via the respective C interfaces:
Caml/C interface for OCaml and JNI (Java Native Interface) for Java.
.
Currently, CamlJava provides a low-level, weakly-typed OCaml interface very
similar to the JNI. Java object references are mapped to an abstract type,
and various JNI-like operations are provided to allow Java method
invocation, field access, and more.
.
A basic callback facility (allowing Java code to invoke methods on OCaml
objects) is also provided, although some stub Java code must be written by
hand.

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-25T14:29:18Z

On Wed, Nov 25, 2009 at 11:06:17PM +0100, Ralf Treinen wrote:

>
> We are currently preparing a new release of the underlying library
> and the tools that are using them (this will be the dose3 library).
> This will happen in the next weeks, and that new version will have
> a native edos-builddebcheck (without need of a python wrapper). The
> new library will allow us to realise much more easily manipulations
> on the package universe.
>
> Anyway, we will have to decide what exactly we will implement. The
> current proposal (after discussion with zack) is the following:
>
> - we construct a set BE as follows: at the start it only contains the
> package "build-essential". Then we extend the set by any package from
> the Packages file that build-essential directly or indirectly depends on.
> For calculating BE we would also follow through alternatives, that is if
> a build-essential package depends on a|b we would both include a and b in
> that set.
> - For each package in the set BE we set its list of conflicts to the
> empty list.
>
> This would mean that all build-essential packages and all their (in)direct
> dependencies *that are present in the Packages file* would be assumed to
> be always installable. This would probably give some false positives
> (indicating packages as buildable when in reality they are not) but that
> seems acceptable.
>
> However, if for instance a build-essential package does depend on a package
> p that does not exist in the Packages file than we wouldn't assume p to
> be installable. Is that OK?

I don't see a problem with it.

There has also been a change on ftp-master's side that it keeps
the arch all package around of old versions until the arch any
package of the arch is uploaded. I think this also fixes our
problem, or atleast a big part of it. There is just one small
problem with that, and that is the the special Packages file
for the buildds is one with all arches in it. We merge it with
the Packages file for the arch.

I'm wondering if we can't be smarter about merging those 2 files.
It currently only keeps the newest version of all packages, and I
wonder if it's a problem if we just concatenate them.

The commit log shows:
commit 9f9abf7546c8e4a5b4af7daa58b2bbc72964e90c
Author: Joachim Breitner <nomeata@...>
Date: Wed Jul 29 16:06:57 2009 +0200

Use keep-latest in trigger.often

This makes sure the Packages and Sources as passed to wanna-build do not
contain old entries, so that they are not passed to edos-debcheck. They
would not be considered by apt on the buildds for installation anyways.

And I'm not so sure about that anymore.

Kurt

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#545381: edos-builddebcheck: Always consider built-essential packages installable

2009-11-25T14:06:17Z

On Fri, Nov 20, 2009 at 05:46:58PM +0100, Kurt Roeckx wrote:

> On Tue, Sep 29, 2009 at 11:16:31PM +0200, Kurt Roeckx wrote:
> > On Sun, Sep 27, 2009 at 10:07:50PM +0200, Kurt Roeckx wrote:
> > > I'm now running your version, but with the deb822.py merged into
> > > it again.
> > [...]
> > > I've just added hurd-i386 to buildd.debian.org, and they have
> > > the following problem:
> > > debhelper (= 7.4.2) depends on perl {perl (= 5.10.0-19)}
> > > perl (= 5.10.0-19) depends on hurd {hurd (= 20090404-1)}
> > > hurd (= 20090404-1) depends on sysv-rc {sysv-rc (= 2.87dsf-6)}
> > > sysv-rc (= 2.87dsf-6) depends on insserv (>> 1.12.0-10) {NOT AVAILABLE}
> > >
> > > Since perl is one of the packages that's build-essential,
> > > they shouldn't get that error.
> >
> > So looking at what is happening, it seems you remove
> > the dependencies for build-essential packages from
> > the source packages. But those don't build-depend
> > on it in the first place. You need to change
> > the Depends on the Packages themself, so
> > that the files going to edos-debcheck
> > does not have Depends: perl for debhelper.
> >
> > I've tried adding a package that provides all the build-essential
> > packages in 1 package, but that seems to cause problems too.
> >
> > This has atleast 2 problems:
> > - Versioned depedencies don't work. We have things like
> > - libtext-format-perl (= 0.52-21) depends on perl (>= 5.6.0-16)
> > - autoconf (= 2.64-4) depends on perl (>> 5.005)
> > (I've only seen it with perl so far)
> > - You need to add provides for all the provides the packages
> > you try to replace have. And perl has alot of them.
> >
> > It might also need to be arch specific, I think hurd has conflicts
> > with packages that are essential on other arches.
> >
> > This atleast seems to be giving reasonable results, it might
> > not be perfect, but would atleast not get us completly stuck.
>
> So does someone have a better suggestion on how to get this fixed?
> I would like to see the options about dropping Depends.

We are currently preparing a new release of the underlying library
and the tools that are using them (this will be the dose3 library).
This will happen in the next weeks, and that new version will have
a native edos-builddebcheck (without need of a python wrapper). The
new library will allow us to realise much more easily manipulations
on the package universe.

Anyway, we will have to decide what exactly we will implement. The
current proposal (after discussion with zack) is the following:

- we construct a set BE as follows: at the start it only contains the
package "build-essential". Then we extend the set by any package from
the Packages file that build-essential directly or indirectly depends on.
For calculating BE we would also follow through alternatives, that is if
a build-essential package depends on a|b we would both include a and b in
that set.
- For each package in the set BE we set its list of conflicts to the
empty list.

This would mean that all build-essential packages and all their (in)direct
dependencies *that are present in the Packages file* would be assumed to
be always installable. This would probably give some false positives
(indicating packages as buildable when in reality they are not) but that
seems acceptable.

However, if for instance a build-essential package does depend on a package
p that does not exist in the Packages file than we wouldn't assume p to
be installable. Is that OK?

-Ralf.

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#554389: fixed

2009-11-25T11:25:56Z

We believe that the bug you reported is now fixed; the following
changes were made to the overrides...

Concerning package liblwt-ocaml...
Operating on the unstable suite
Changed priority from extra to optional

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 554389@....

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@....

Debian distribution maintenance software
pp.
Barry deFreese (the ftpmaster behind the curtain)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#557538: marked as done (libbatteries-ocaml-dev: Can't compile : ocamlfind: Package `bin_prot.syntax' not found)

2009-11-25T05:27:22Z

Your message dated Wed, 25 Nov 2009 13:21:56 +0000
with message-id <E1NDHoi-00015Q-T7@...>
and subject line Bug#557538: fixed in ocaml-batteries 0.20090405+beta1-5
has caused the Debian Bug report #557538,
regarding libbatteries-ocaml-dev: Can't compile : ocamlfind: Package `bin_prot.syntax' not found
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@...
immediately.)

--
557538: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557538
Debian Bug Tracking System
Contact owner@... with problems

Package: libbatteries-ocaml-dev
Version: 0.20090405+beta1-4
Severity: normal

Hi,
probably since the last version of libbatteries, I obtain an error when I try to use batteries.
The error is a simple :
ocamlfind: Package `bin_prot.syntax' not found - Required by `batteries.bin_prot.syntax'

It works fine with a computer using Debian Testing.

Cheers,

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

Kernel: Linux 2.6.31-trunk-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/bash

Versions of packages libbatteries-ocaml-dev depends on:
ii camlp4 [camlp4-3.11.1] 3.11.1-4 Pre Processor Pretty Printer for O
ii libcamomile-ocaml-dev [li 0.7.2-2 Unicode library for OCaml
ii libfindlib-ocaml-dev [lib 1.2.5+debian-1 library for managing OCaml librari
ii libocamlnet-ocaml-dev [li 2.2.9-7 OCaml application-level Internet l
ii libpcre-ocaml-dev [libpcr 6.0.1-2 OCaml bindings for PCRE (Perl Comp
ii libsexplib-camlp4-dev [li 4.2.16-1 automated conversions between OCam
ii libzip-ocaml-dev [libzip- 1.04-6 OCaml compression libraries (devel
ii ocaml-findlib 1.2.5+debian-1 management tool for OCaml librarie
ii ocaml-nox [ocaml-nox-3.11 3.11.1-4 ML implementation with a class-bas

Versions of packages libbatteries-ocaml-dev recommends:
ii libbatteries-ocaml-do 0.20090405+beta1-4 Batteries included - OCaml develop

Versions of packages libbatteries-ocaml-dev suggests:
pn ledit <none> (no description available)

-- no debconf information

Source: ocaml-batteries
Source-Version: 0.20090405+beta1-5

We believe that the bug you reported is fixed in the latest version of
ocaml-batteries, which is due to be installed in the Debian FTP archive:

libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb
to main/o/ocaml-batteries/libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb
libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
to main/o/ocaml-batteries/libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
ocaml-batteries-included_0.20090405+beta1-5_all.deb
to main/o/ocaml-batteries/ocaml-batteries-included_0.20090405+beta1-5_all.deb
ocaml-batteries_0.20090405+beta1-5.diff.gz
to main/o/ocaml-batteries/ocaml-batteries_0.20090405+beta1-5.diff.gz
ocaml-batteries_0.20090405+beta1-5.dsc
to main/o/ocaml-batteries/ocaml-batteries_0.20090405+beta1-5.dsc

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 557538@...,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Stefano Zacchiroli <zack@...> (supplier of updated ocaml-batteries package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@...)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 25 Nov 2009 13:11:18 +0100
Source: ocaml-batteries
Binary: libbatteries-ocaml-dev libbatteries-ocaml-doc ocaml-batteries-included
Architecture: source all amd64
Version: 0.20090405+beta1-5
Distribution: unstable
Urgency: low
Maintainer: Debian OCaml Maintainers <debian-ocaml-maint@...>
Changed-By: Stefano Zacchiroli <zack@...>
Description:
libbatteries-ocaml-dev - Batteries included: OCaml development platform - development file
libbatteries-ocaml-doc - Batteries included - OCaml development platform - documentation
ocaml-batteries-included - Batteries included: OCaml development platform - metapackage
Closes: 557538
Changes:
ocaml-batteries (0.20090405+beta1-5) unstable; urgency=low
.
* debian/control: add explicit dep on libbin-prot-camlp4-dev, it is a
needed CamlP4 dep, not inferrable by dh_ocaml (Closes: #557538)
Checksums-Sha1:
98a69cfcfd190f920312a813a2e7bfed7c741639 1659 ocaml-batteries_0.20090405+beta1-5.dsc
2f6c3a1f3ac860463bebb6add2db2919fb5544a6 8595 ocaml-batteries_0.20090405+beta1-5.diff.gz
089baf2887f02777e9293cf8650add7bddfbda86 1099118 libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
55854a967d0ebb631d032126815024031d92af94 27730 ocaml-batteries-included_0.20090405+beta1-5_all.deb
d42abc25f30cab92b9c016d466c2be8a8da502a5 10848984 libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb
Checksums-Sha256:
ae190abb2c34e6d5cd56a6a5fdc22741b20dcea64374993922de4a2431f3a25b 1659 ocaml-batteries_0.20090405+beta1-5.dsc
c489cb92fa1e31e94a31da58fbe1d08476e8880851b2e2117040841594972717 8595 ocaml-batteries_0.20090405+beta1-5.diff.gz
166dd55e451caac0ed981e7683eaac8f643c3bfb2b7dd1fd24384862c6955870 1099118 libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
8258399a674878fbd08e52644bd8ffe5b38c1bcd275e7020aeebb3efc968a1e3 27730 ocaml-batteries-included_0.20090405+beta1-5_all.deb
7183fb6b970eddd275946f79aa3f9ed645582a9dfbad2124097bd77162815e85 10848984 libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb
Files:
a3c22954d836bbc08cc1fc6886d60d31 1659 ocaml optional ocaml-batteries_0.20090405+beta1-5.dsc
2bddc041d35388746a02e3e985a42c73 8595 ocaml optional ocaml-batteries_0.20090405+beta1-5.diff.gz
3f84f4e55b4d507a3842c33570e0ed73 1099118 doc optional libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
b3d58c9080ade8c99544ebd43e515b5d 27730 ocaml optional ocaml-batteries-included_0.20090405+beta1-5_all.deb
981ae94074cc6ebdd2fb96b527193e3c 10848984 ocaml optional libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD4DBQFLDShj1cqbBPLEI7wRAkpPAJYoe2eFdBf1o+S7LnXZEpIv7YFiAJ9Vc5Mn
2llQkX0cBZlS+ajQIP3kOw==
=9A2a
-----END PGP SIGNATURE-----

Processing of ocaml-batteries_0.20090405+beta1-5_amd64.changes

2009-11-25T04:57:59Z

ocaml-batteries_0.20090405+beta1-5_amd64.changes uploaded successfully to localhost
along with the files:
ocaml-batteries_0.20090405+beta1-5.dsc
ocaml-batteries_0.20090405+beta1-5.diff.gz
libbatteries-ocaml-doc_0.20090405+beta1-5_all.deb
ocaml-batteries-included_0.20090405+beta1-5_all.deb
libbatteries-ocaml-dev_0.20090405+beta1-5_amd64.deb

Greetings,

Your Debian queue daemon (running on host ries.debian.org)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#557538: libbatteries-ocaml-dev: Can't compile : ocamlfind: Package `bin_prot.syntax' not found

2009-11-25T04:54:52Z

On Sun, Nov 22, 2009 at 06:37:48PM +0100, Florent Fourcot wrote:
> probably since the last version of libbatteries, I obtain an error when I try to use batteries.
> The error is a simple :
> ocamlfind: Package `bin_prot.syntax' not found - Required by `batteries.bin_prot.syntax'

In turned out this was a corner case in dh-ocaml which the package was
not considering. bin_prot is used by batteries only as a (required)
syntax extension and not as a library at all. This in turn means that
there is no reference to any object of bin_prot in any caml object
shipped by batteries and, finally, that the dependency on bin_prot is
not inferrable by dh-ocaml (which currently knows nothing about the
mapping between findlib packages and Debian packages).

I've hence added explicitly the missing dependency on
libbin-prot-camlp4-dev to ocaml batteries. The fixed package has just
been uploaded to unstable.

In the mean time, as a work around, you can install by hand
"libbin-prot-camlp4-dev" to fix your compilation nuisances.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

signature.asc (197 bytes) Download Attachment

Processed: limit source to ocaml-batteries, tagging 557538

2009-11-25T04:33:03Z

Processing commands for control@...:

> #ocaml-batteries (0.20090405+beta1-5) unstable; urgency=low
> #
> # * debian/control: add explicit dep on libbin-prot-camlp4-dev, it is a
> # needed CamlP4 dep, not inferrable by dh_ocaml (Closes: #557538)
> #
> limit source ocaml-batteries
Limiting to bugs with field 'source' containing at least one of 'ocaml-batteries'
Limit currently set to 'source':'ocaml-batteries'

> tags 557538 + pending
Bug #557538 [libbatteries-ocaml-dev] libbatteries-ocaml-dev: Can't compile : ocamlfind: Package `bin_prot.syntax' not found
Added tag(s) pending.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Bug#556838: cameleon: FTBFS: Error: unit XmlParser exported in cameleon but already exported by libxml-light-ocaml-dev v2.2-12

2009-11-25T04:32:30Z

Lucas Nussbaum a écrit :
> Source: cameleon
> Version: 1.9.18.svn20090908+703-1
> [...]
> During a rebuild of all packages in sid, your package failed to build on
> amd64.

FYI, I'm planning to fix this with the upload of cameleon 1.9.19 to
unstable (during lablgtk2 2.14 transition). Note: it might be fixed with
a change in dh-ocaml before this transition.

--
Stéphane

--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Subscription to pkg-ocaml-maint project on Alioth

2009-11-24T17:38:45Z

Le mardi 24 novembre 2009 à 23:59, Sylvain Le Gall a écrit :

> On 24-11-2009, Laurent Léonard <laurent@...> wrote:
> > --nextPart1990447.fUzNMv33EA
> > Content-Type: text/plain;
> > charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > Content-Disposition: inline
> >
> > Hi,
> >=20
> > I'm waiting for my acceptation in the pkg-ocaml-maint project on Alioth
> > sin= ce=20
> > 16 November 2009. I need to be part of the project to take care of
> > virt-top= ,=20
> > I'm currently member of pkg-libvirt.
> >
> > virt-top 1.0.3 is ready to be released (not 1.0.4, see #550377) and I
> > made= =20
> > some enhancement on the package in my local Git repository. Could you
> > pleas= e=20
> > accept me ?
>
> Send me your changes directly, so that I can review it.

I just pushed my changes to Git, so it's easier for you to review it.

--
Laurent Léonard

signature.asc (204 bytes) Download Attachment

Re: Subscription to pkg-ocaml-maint project on Alioth

2009-11-24T17:37:16Z

Le mardi 24 novembre 2009 à 22:39, Stefano Zacchiroli a écrit :

> On Tue, Nov 24, 2009 at 07:30:42PM +0100, Laurent Léonard wrote:
> > I'm waiting for my acceptation in the pkg-ocaml-maint project on Alioth
> > since 16 November 2009. I need to be part of the project to take care of
> > virt-top, I'm currently member of pkg-libvirt.
> >
> > virt-top 1.0.3 is ready to be released (not 1.0.4, see #550377) and I
> > made some enhancement on the package in my local Git repository. Could
> > you please accept me ?
>
> Sorry, I must have missed your request.
> I've just approved your membership.

Thank you.

--
Laurent Léonard

signature.asc (204 bytes) Download Attachment

Re: Subscription to pkg-ocaml-maint project on Alioth

2009-11-24T14:59:53Z

On 24-11-2009, Laurent Léonard <laurent@...> wrote:

> --nextPart1990447.fUzNMv33EA
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> Hi,
>=20
> I'm waiting for my acceptation in the pkg-ocaml-maint project on Alioth sin=
> ce=20
> 16 November 2009. I need to be part of the project to take care of virt-top=
> ,=20
> I'm currently member of pkg-libvirt.
>
> virt-top 1.0.3 is ready to be released (not 1.0.4, see #550377) and I made=
>=20
> some enhancement on the package in my local Git repository. Could you pleas=
> e=20
> accept me ?
>

Send me your changes directly, so that I can review it.

Regards,
Sylvain Le Gall

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

Re: Subscription to pkg-ocaml-maint project on Alioth

2009-11-24T13:39:45Z

On Tue, Nov 24, 2009 at 07:30:42PM +0100, Laurent Léonard wrote:
> I'm waiting for my acceptation in the pkg-ocaml-maint project on Alioth since
> 16 November 2009. I need to be part of the project to take care of virt-top,
> I'm currently member of pkg-libvirt.
>
> virt-top 1.0.3 is ready to be released (not 1.0.4, see #550377) and I made
> some enhancement on the package in my local Git repository. Could you please
> accept me ?

Sorry, I must have missed your request.
I've just approved your membership.

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

signature.asc (197 bytes) Download Attachment

Subscription to pkg-ocaml-maint project on Alioth

2009-11-24T10:30:42Z

Hi,

I'm waiting for my acceptation in the pkg-ocaml-maint project on Alioth since
16 November 2009. I need to be part of the project to take care of virt-top,
I'm currently member of pkg-libvirt.

virt-top 1.0.3 is ready to be released (not 1.0.4, see #550377) and I made
some enhancement on the package in my local Git repository. Could you please
accept me ?

Thank you,
--
Laurent Léonard

signature.asc (204 bytes) Download Attachment

Re: Bug#557553: geneweb: Search and navigaition fails

2009-11-24T09:16:24Z

tags 557553 help
thanks

Quoting Pär-Ola Nilsson (peje@...):

> >Hmm, I just did the exact same sequence after adding your test
> >database to my local tree and.....got no error.
> >
> >Could you send the output of "ls -lR /var/lib/geneweb"?
> >
> >Are you using unstable or testing?
> >
> >
> It's a mishmash but mostly unstable, some testing and some select
> experimental.
>
> Tried the same thing on a i386 box mostly testing with some unstable
> and that works.
> Tried the same on another amd64 box mostly unstable and some testing, failes
> Another i386 box at work mostly unstable and some testing, works
>
> Seems its amd64 boxes that fail.

Oh, nice catch. So, we apparently have something that fails on amd64
but not i386.

I might need some help by the Ocaml team to track this down. It is
more and more likely that this goes far beyond my own skills.

Ocaml folks, would you mind looking at this bug report that apparently
shows up only on amd64, for geneweb?

signature.asc (205 bytes) Download Attachment

Bug#557538: Sorry

2009-11-24T08:58:54Z

Sorry,

I managed to make a typo in the Closes number in the changelog for a
completely unrelated bug (#557558), so I made a mess and closed the
wrong bug. My sincere apologies.

Mattias

signature.asc (204 bytes) Download Attachment

Processed: found 557538 in 0.20090405+beta1-4

2009-11-24T08:27:10Z

Processing commands for control@...:

> found 557538 0.20090405+beta1-4
Bug #557538 [libbatteries-ocaml-dev] libbatteries-ocaml-dev: Can't compile : ocamlfind: Package `bin_prot.syntax' not found
Ignoring request to alter found versions of bug #557538 to the same values previously set
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...