Re: Bug#1073983: transition: ocaml
On 13/08/2024 08:03, Stéphane Glondu wrote: Dear Emilio, Le 12/08/2024 à 10:31, Emilio Pozuelo Monfort a écrit : As expected, removal hints will be needed, which I've put in 3 categories: # Independent broken packages hol-light (#1073882) ocaml-ffmpeg (#1072440) ocaml-lo (#1075329) pa-ounit (#1073907) ppx-tools (#1078383) sks (#1073911) What about those? # libguestfs related packages (#1078470) guestfs-tools libguestfs virt-v2v guestfs-tools ceilometer-instance-poller ironic-python-agent nbdkit virt-p2v qemu-web-desktop oz kworkflow virtnbdbackup I see the bug has a patch. I'd rather it gets fixed rather than removing all of that, if possible. Done. # coq related packages (#1078252) aac-tactics coq coq-bignums coq-corn coq-deriving coq-doc coq-dpdgraph coqeal coq-elpi coq-equations coq-ext-lib coq-extructures coq-gappa coq-hammer coq-hierarchy-builder coq-hott coq-interval coq-iris coq-libhyps coq-math-classes coq-menhirlib coq-mtac2 coqprime coq-quickchick coq-record-update coq-reduction-effects coq-reglang coq-relation-algebra coq-serapi coq-simple-io coq-stdpp coquelicot coq-unicoq coq-unimath elpi flocq mathcomp-algebra-tactics mathcomp-analysis mathcomp-bigenough mathcomp-finmap mathcomp-multinomials mathcomp-real-closed mathcomp-zify ott paramcoq ssreflect Those should be removed in unstable by ftp-masters, then the removal will be propagated to testing once the transition migrates. My idea was to remove them now to ease the transition, and let them migrate back to testing later, automatically. Despite the big number of packages, this is a self-contained cluster. See also #1078578. I applied the hints and ocaml is now in testing. Cheers, Emilio
Re: Bug#1073983: transition: ocaml
On 12/08/2024 07:37, Stéphane Glondu wrote: Le 07/08/2024 à 10:18, Emilio Pozuelo Monfort a écrit : Let's go ahead with this one. The needed recompilations are mostly done. As expected, removal hints will be needed, which I've put in 3 categories: # Independent broken packages hol-light (#1073882) ocaml-ffmpeg (#1072440) ocaml-lo (#1075329) pa-ounit (#1073907) ppx-tools (#1078383) sks (#1073911) # libguestfs related packages (#1078470) guestfs-tools libguestfs virt-v2v guestfs-tools ceilometer-instance-poller ironic-python-agent nbdkit virt-p2v qemu-web-desktop oz kworkflow virtnbdbackup I see the bug has a patch. I'd rather it gets fixed rather than removing all of that, if possible. # coq related packages (#1078252) aac-tactics coq coq-bignums coq-corn coq-deriving coq-doc coq-dpdgraph coqeal coq-elpi coq-equations coq-ext-lib coq-extructures coq-gappa coq-hammer coq-hierarchy-builder coq-hott coq-interval coq-iris coq-libhyps coq-math-classes coq-menhirlib coq-mtac2 coqprime coq-quickchick coq-record-update coq-reduction-effects coq-reglang coq-relation-algebra coq-serapi coq-simple-io coq-stdpp coquelicot coq-unicoq coq-unimath elpi flocq mathcomp-algebra-tactics mathcomp-analysis mathcomp-bigenough mathcomp-finmap mathcomp-multinomials mathcomp-real-closed mathcomp-zify ott paramcoq ssreflect Those should be removed in unstable by ftp-masters, then the removal will be propagated to testing once the transition migrates. Cheers, Emilio
Bug#1073289: Bug#1073983: transition: ocaml
Control: tags -1 confirmed
On 25/07/2024 10:54, Emilio Pozuelo Monfort wrote:
On 17/07/2024 21:56, Adrian Bunk wrote:
On Wed, Jul 17, 2024 at 11:28:04AM +0200, Emilio Pozuelo Monfort wrote:
On 16/07/2024 13:16, Adrian Bunk wrote:
On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:
Hi,
Hi Stéphane,
Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :
The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]
I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.
[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).
I still think this is the best course of action.
looking at [1] this might be the only reasonable course of action for LLVM <
17.
Disabling them sounds fine (specially for 14 which is no longer in testing
and 15 which we're trying to get rid of), but ideally it can be done ahead
of the start in order to prevent delays with the transition.
Other than that, I'm happy with the current state and we could go ahead. So
if you can get those bindings disabled, then I think we can go ahead.
I tried looking at that, but this "ideally" is in level 15 of the ocaml
transition.
The bindings are already enabled only on some architectures, uploads to
disable them everywhere are trivial while it's a pain to test any changes
without the first 14 levels of the transition.
It would really be much easier to have the binNMUs scheduled and then
fix LLVM.
If by fixing you mean disabling the ocaml bindings, then I'm not sure why it
needs to happen after the binNMUs. If you mean actually fixing the bindings so
they work with the new ocaml, then sure, that's fine.
I see that autopkgtests are being run and some issues are being spotted. I'm
starting the gsl transition first, let's do this one after gsl (hopefully it
will be straightforward).
That one is done. Let's go ahead with this one.
Cheers,
Emilio
Bug#1073289: Bug#1073983: transition: ocaml
On 17/07/2024 21:56, Adrian Bunk wrote:
On Wed, Jul 17, 2024 at 11:28:04AM +0200, Emilio Pozuelo Monfort wrote:
On 16/07/2024 13:16, Adrian Bunk wrote:
On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:
Hi,
Hi Stéphane,
Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :
The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]
I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.
[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).
I still think this is the best course of action.
looking at [1] this might be the only reasonable course of action for LLVM < 17.
Disabling them sounds fine (specially for 14 which is no longer in testing
and 15 which we're trying to get rid of), but ideally it can be done ahead
of the start in order to prevent delays with the transition.
Other than that, I'm happy with the current state and we could go ahead. So
if you can get those bindings disabled, then I think we can go ahead.
I tried looking at that, but this "ideally" is in level 15 of the ocaml
transition.
The bindings are already enabled only on some architectures, uploads to
disable them everywhere are trivial while it's a pain to test any changes
without the first 14 levels of the transition.
It would really be much easier to have the binNMUs scheduled and then
fix LLVM.
If by fixing you mean disabling the ocaml bindings, then I'm not sure why it
needs to happen after the binNMUs. If you mean actually fixing the bindings so
they work with the new ocaml, then sure, that's fine.
I see that autopkgtests are being run and some issues are being spotted. I'm
starting the gsl transition first, let's do this one after gsl (hopefully it
will be straightforward).
Cheers,
Emilio
Bug#1073289: Bug#1073983: transition: ocaml
On 16/07/2024 13:16, Adrian Bunk wrote:
On Tue, Jul 16, 2024 at 10:25:43AM +0200, Stéphane Glondu wrote:
Hi,
Hi Stéphane,
Le 27/06/2024 à 11:38, Stéphane Glondu a écrit :
The remaining unknowns are llvm-toolchain-{14,15,16,17,18}... [...]
I've done a rebuild of the OCaml universe with yesterday's unstable
(mostly). The "missing" packages are the same, but the llvm-toolchain-16
build got far enough to FTBFS because of OCaml 5.2.0. This is likely to
affect llvm-toolchain-{14,15} as well, but might be fixed in newer versions.
I've reported bugs accordingly.
[...] Worst case scenario: the OCaml bindings can be disabled (they
don't have reverse dependencies in Debian).
I still think this is the best course of action.
looking at [1] this might be the only reasonable course of action for LLVM < 17.
Disabling them sounds fine (specially for 14 which is no longer in testing and
15 which we're trying to get rid of), but ideally it can be done ahead of the
start in order to prevent delays with the transition.
Other than that, I'm happy with the current state and we could go ahead. So if
you can get those bindings disabled, then I think we can go ahead.
Cheers,
Emilio
Bug#1030785: -ffile-prefix-map option and reproducibility
On 07/02/2023 20:00, Sven Joachim wrote: On 2023-02-07 17:50 +0100, Guillem Jover wrote: On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, and then switched to enabled by default in dpkg 1.20.6 (see #974087). I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. AFAIR this was considered at the time, yes. If the flag is effectively not fixing anything for the set of packages involved, and is in fact actually making them unreproducible when they would not then, you can disable the fixfilepath feature in the reproducible build flags area, via DEB_BUILD_MAINT_OPTIONS. This does not help for packages which capture all build flags and store them in some file in the package (as is the case here). What is the purpose of having the build flags in a file in the .deb? Cheers, Emilio
Re: Haskell binnmus is there a problem?
On 29/08/2019 12:08, Philipp Kern wrote: > On 2019-08-29 11:46, Emilio Pozuelo Monfort wrote: >> On 29/08/2019 11:17, Philipp Kern wrote: >>> On 2019-08-29 11:14, Emilio Pozuelo Monfort wrote: >>>> Why don't you let the interested teams run the scripts and generate the >>>> required >>>> binNMUs (like they do now), and then you pull that from a cronjob in wuiet >>>> and >>>> schedule the binNMUs? You would just need to define the format and do some >>>> sanity checks. >>> >>> What would those sanity checks be? >> >> You fetch the list from a known debian host (like several other services >> already >> do, including ftp-master or release). If you define the format to be e.g. >> yaml >> or json, with an array of binNMUs to schedule, each one with >> - a source package >> - a version >> - a list of architectures >> - a reason >> >> You can just then call 'wb nmu' with the right arguments and the right >> quoting. >> The sanity checks would be to make sure the arguments have the right format. > > So that together with the other mail of not making it automatic: Would we just > want to have an endpoint you can call as a member of an approved team(?) that > ingests a list of work items, processes it and archives it? Assuming that > Release Team has no block in place? Can we require a manual action by a team > member rather than it being run continuously? So that we could then track down > who initiated it? > > The reason why I asked the Release Team specifically was if we need to > constrain > the set of packages to act upon (e.g. golang-%). If you do not see a reason, > assuming that we can always tell the team in question to fix their automation, > that's fine with me too. On the one hand, adding such a constraint would ensure that the teams don't schedule binNMUs outside their realms. OTOH it would reduce the effectiveness of this solution when they need to schedule them on packages that don't fit whichever criteria we chose (e.g. for apps rather than modules). So I'd start with no constrain and we can add it later if we find out it's preferred. Emilio
Re: Fixing Gringo in testing
On 22/05/18 09:33, Mehdi Dogguy wrote: > Hi, > > Gringo has an RC bug which causes an FTBFS. While the package is fixed in > Unstable, its migration to testing is blocked by python3.6 at the moment. > > I'd like to fix Gringo in testing to avoid removal of many OCaml packages > from testing. The fix is pretty straightfotward as you can see here: > > https://salsa.debian.org/science-team/gringo/commit/1d04ff7026aa95cbd963cdd4e5fdd0d1606c08f0 > > May I proceed with the upload? python3.6 should migrate tomorrow night, and gringo is only set to be autoremoved on June 7th. I'd suggest to wait a bit more, the situation should resolve itself soon. Emilio
Re: Bug#871469: transition: ocaml
On 23/09/17 15:52, Emilio Pozuelo Monfort wrote: > On 14/09/17 15:44, Ximin Luo wrote: >> Stéphane Glondu: >>> On 15/08/2017 22:16, Emilio Pozuelo Monfort wrote: >>>> Control: tags -1 confirmed >>>> [...] >>>>> ocaml 4.05.0 and a few selected packages have been uploaded to >>>>> experimental and build fine on all architectures [3]. >>>> >>>>> So, basically, this transition is ready to be started from my point of >>>>> view. >>>>> >>>>> I will take care of the necessary binNMUs. >>>> >>>> Go ahead. >>> >>> The transition in Fedora revealed an issue with native dynlink on arm64 >>> [1]. The issue is being sorted out upstream [2]. Let's wait a bit. If >>> this is not fixed in one week, we'll upload ocaml with native dynlink >>> disabled on arm64. >>> >>> [1] https://pagure.io/releng/issue/6906 >>> [2] https://github.com/ocaml/ocaml/pull/1268 >>> >> Upstream fixed this "properly" so I've included that patch and done a new >> upload to experimental. Everything seems OK so far, just waiting for slower >> architectures to build. >> >> Soon, I will upload to unstable and begin the transition. Let me know if you >> need me to delay it further. > > That's alright. I see this is already started and binNMUs are needed. Is > someone > from the ocaml team handling these, or should I? This took forever, but it finally migrated: ocaml | 4.05.0-10 | testing| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x I had to remove approx and its only rdep openstack-meta-packages, which were scheduled for autoremoval anyway. Cheers, Emilio
Re: Bug#871469: transition: ocaml
On 14/09/17 15:44, Ximin Luo wrote: > Stéphane Glondu: >> On 15/08/2017 22:16, Emilio Pozuelo Monfort wrote: >>> Control: tags -1 confirmed >>> [...] >>>> ocaml 4.05.0 and a few selected packages have been uploaded to >>>> experimental and build fine on all architectures [3]. >>> >>>> So, basically, this transition is ready to be started from my point of >>>> view. >>>> >>>> I will take care of the necessary binNMUs. >>> >>> Go ahead. >> >> The transition in Fedora revealed an issue with native dynlink on arm64 >> [1]. The issue is being sorted out upstream [2]. Let's wait a bit. If >> this is not fixed in one week, we'll upload ocaml with native dynlink >> disabled on arm64. >> >> [1] https://pagure.io/releng/issue/6906 >> [2] https://github.com/ocaml/ocaml/pull/1268 >> > Upstream fixed this "properly" so I've included that patch and done a new > upload to experimental. Everything seems OK so far, just waiting for slower > architectures to build. > > Soon, I will upload to unstable and begin the transition. Let me know if you > need me to delay it further. That's alright. I see this is already started and binNMUs are needed. Is someone from the ocaml team handling these, or should I? Cheers, Emilio
Bug#840492: sexplib310: no longer builds libsexplib-camlp4-dev
Source: sexplib310 Version: 113.33.03-3 Severity: serious Hi, Your package no longer builds libsexplib-camlp4-dev, and the new libsexplib-ocaml-dev doesn't provide it. This would be fine if it weren't for the number of reverse dependencies that build-depend on it: * source package sexplib310 version 113.33.03-3 no longer builds binary package(s): libsexplib-camlp4-dev on amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x - suggested command: dak rm -m "[auto-cruft] NBS (no longer built by sexplib310)" -s unstable -a amd64,arm64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mips,mips64el,mipsel,powerpc,ppc64el,s390x -p -R -b libsexplib-camlp4-dev - broken Depends: janest-core: libcore-ocaml-dev [amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 powerpc] - broken Build-Depends: custom-printf: libsexplib-camlp4-dev janest-core: libsexplib-camlp4-dev janest-core-extended: libsexplib-camlp4-dev janest-core-kernel: libsexplib-camlp4-dev ocaml-re2: libsexplib-camlp4-dev ocaml-textutils: libsexplib-camlp4-dev otags: libsexplib-camlp4-dev pa-structural-sexp: libsexplib-camlp4-dev pa-test: libsexplib-camlp4-dev typerep: libsexplib-camlp4-dev Please file bugs against those (or fix them directly if you maintain them) or make libsexplib-ocaml-dev provide libsexplib-camlp4-dev. Cheers, Emilio -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#820937: ocaml-re2: FTBFS against new re2
Source: ocaml-re2 Version: 113.00.00+dfsg-2 Severity: serious Your package failed to build against the new re2: g++ -O2 -DPIC -fPIC -g -pipe -DCAML_NAME_SPACE -Wall -I. -I../../../include \ -I/usr/lib/ocaml -c stubs.cpp In file included from /usr/include/c++/5/mutex:35:0, from /usr/include/re2/re2.h:184, from stubs.cpp:2: /usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options. Full logs at https://buildd.debian.org/status/package.php?p=ocaml-re2 Looks like the new version of re2 requires you to build with c++11 support. re2 (20160401+dfsg-2) unstable; urgency=medium . * Bump soname to libre2.so.2. 20160401 changed the ABI of the RE2 class. (Closes: #820178). * Use --std=c++11 in the smoketest, too. Consumers of libre2 now need to do this. Cheers, Emilio
Re: Bug#789133: transition: ocaml 4.02.3
ocaml just went in after llvm got fixed and removing a few packages remove nurpawiki/1.2.3-8 eliom/4.0.0-2 cduce/0.6.0-1 otags/4.01.1-1 botch/0.16-2 matita/0.99.1-3 liquidsoap/1.1.1-7 age-days 1 hivex/1.3.13-1 age-days 3 coccinelle/1.0.3.deb-2 age-days 0 llvm-toolchain-3.4/1:3.4.2-16 Cheers, Emilio
Re: Bug#789133: transition: ocaml 4.02.3
Control: tags -1 confirmed On 05/10/15 10:39, Stéphane Glondu wrote: > 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. Well it looks like #789354 (dose3) has been fixed. Is ocaml-gettext still buggy? I just checked and there's a new version in the archive, 0.3.5-2, with a CHANGELOG entry that seems to suggest this is fixed: v 0.3.5 (Mon, 04 Aug 2014 23:31:41 +0200): * Always use format_of_string to not segfault with OCaml 4.02. If that's the case, then libguestfs (which has rdeps) and virt-top wouldn't need to be removed. monotone-viz also seems fixed. Looks like zeroinstall-injector is the only package not maintained by the ocaml team which is still buggy. It'd have been easier if you had told me all that :) Things look fine, so let's go ahead with this. BTW please avoid binNMU'ing scilab until it migrates. Cheers, Emilio
Re: Bug#789133: transition: ocaml 4.02.3
On 07/09/15 17:45, Stéphane Glondu wrote: > 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? Cheers, Emilio
Re: Bug#789133: transition: ocaml 4.02.2
On 22/06/15 19:15, Stéphane Glondu wrote: > 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. Tbh I'm not thrilled about removing that many packages, but given most of them are maintained by the ocaml team, I may be alright with it. It'd be good to reduce the number as much as possible though. Cheers, Emilio -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558bcaee.6060...@debian.org
Re: Bug#789133: transition: ocaml 4.02.2
On 20/06/15 18:02, Stéphane Glondu wrote: > 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. Sure, I'm fine with removing a few packages if necessary if those don't have rdeps, and are not very important (e.g. they have low popcon). The usual stuff. I'm just asking because I'd like to make sure the transition doesn't block for too long because there are a bunch of FTBFS that we knew about before the transition started. So I want to make sure the impact that those will have. So, I'd like to know what the plan is for those packages that are "missing". E.g. if those maintained by the ocaml team will be fixed promptly, and what will happen to the others. I'd like to see them analyzed and bugs filed (ideally with patches) before we start this. 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. Thanks for bearing with me with my first ocaml transition. Cheers, Emilio >> > 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 > > > missing.txt > > > 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) > -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558814de.1030...@debian.org
Bug#532905: lablgtk2: pygtksourceview1 is deprecated
Package: lablgtk2 Severity: normal Hi, pygtksourceview1 is deprecated and dead upstream. Your package provides bindings for it though, and 4 packages build depend on it. We want to remove it from the archive, so it would be nice if you could look at what possibilities we have to remove it. Maybe it would be possible to provide pygtksourceview2 bindings and migrate those packages. Cheers, Emilio -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-2-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
