Bug#527224: Please binNMU ocsigen/1.1.0-2
+ Stéphane Glondu (Wed, 06 May 2009 13:08:08 +0200): Hello, nmu ocsigen_1.1.0-2 . ALL . -m 'Recompile with ocaml-sqlite3 1.4.0' This would close #527224. Scheduled. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OCaml transition ready (?)...
* Stéphane Glondu [Sat, 04 Apr 2009 14:01:35 +0200]: Adeodato Simó a écrit : Please schedule the attached requests for the OCaml 3.11.0 transition. Scheduled, with the glitches noted below. Please get back to us with the needed wanna-build actions. All packages that needed recompilation or sourceful uploads for the OCaml 3.11.0 transition are now compiled and available in unstable. I guess migrating ocaml to testing can now be considered... This is now done: ocaml | 3.11.0-5 | testing ocaml | 3.11.0-5 | unstable Congratulations for making of this transition one of the less painful I’ve ever had to deal with, though I guess being a quite self-contained set of packages and not having ties to other ongoing transitions really helped. ;-) Thanks!, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OCaml transition ready (?)...
* Stéphane Glondu [Sat, 04 Apr 2009 14:01:35 +0200]:
Adeodato Simó a écrit :
Please schedule the attached requests for the OCaml 3.11.0 transition.
Scheduled, with the glitches noted below. Please get back to us with the
needed wanna-build actions.
All packages that needed recompilation or sourceful uploads for the
OCaml 3.11.0 transition are now compiled and available in unstable.
I guess migrating ocaml to testing can now be considered...
We’re missing camlpdf/{armel,s390}. I gave those packages back, should
become available shortly.
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
--
To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please schedule binNMU of lablgtk2/2.12.0-2 on i386
* Stéphane Glondu [Fri, 27 Feb 2009 14:20:40 +0100]: Hi, The uploaded version of lablgtk2, compiled on i386, has been mistakenly compiled against the gtk2 version of experimental, making it uninstallable on i386. Would someone be kind enough to schedule a binNMU for it? lablgtk2_2.12.0-2, Rebuild against gtk2 in sid, 1, i386 Scheduled. BTW, I fail to understand the FTBFSes of lablgtk2 on powerpc and s390... isn't there something wrong with the build daemons? Transiently uninstallable packages. I've set lablgtk2 to get rebuilt once the problem has gone away. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Man is certainly stark mad; he cannot make a flea, yet he makes gods by the dozens. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: how to push the fix for #503616
* Stefano Zacchiroli [Thu, 30 Oct 2008 09:40:58 +0100]: On Thu, Oct 30, 2008 at 12:18:14AM +0100, Luk Claes wrote: If not please let me know if I'd go for t-p-u with ocamlnet 2.2.9-4. Please upload it with a lower version to tpu, TIA. Done: ocamlnet/2.2.9-3+lenny1, uploaded to t-p-u, urgency: low. Override as needed. Approved. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ocaml-ssl/0.4.2-4 and binNMU ocsigen/1.1.0-1
* Adeodato Simó [Thu, 23 Oct 2008 17:24:00 +0200]: * Stéphane Glondu [Thu, 23 Oct 2008 16:56:18 +0200]: Adeodato Simó a écrit : The ocsigen package was affected by this bug. Please schedule a binNMU for it on all architectures: ocsigen_1.1.0-1, Rebuild against ocaml-ssl/0.4.2-4, 1, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ocsigen dep-wait ocaml-ssl (= 0.4.2-4) Scheduled. The new version of pcre3 available in unstable prevents the new (fixed) version of ocsigen from migrating to testing: http://release.debian.org/migration/testing.pl?package=ocsigen Now that ocaml-ssl/0.4.2-4 has migrated to testing, is it possible to schedule a binNMU of ocsigen directly in testing? Yes, it's on my TODO list, so I'll get something done about it. binNMUs in testing scheduled, let's hope dak will react properly to them (since we'll be uploading to t-p-u something with ver unstable; the expected thing to do is to get them migrated to unstable as well). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: The Wallflowers - Angel on my bike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ocaml-ssl/0.4.2-4 and binNMU ocsigen/1.1.0-1
* Stéphane Glondu [Thu, 23 Oct 2008 16:56:18 +0200]: Adeodato Simó a écrit : The ocsigen package was affected by this bug. Please schedule a binNMU for it on all architectures: ocsigen_1.1.0-1, Rebuild against ocaml-ssl/0.4.2-4, 1, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ocsigen dep-wait ocaml-ssl (= 0.4.2-4) Scheduled. The new version of pcre3 available in unstable prevents the new (fixed) version of ocsigen from migrating to testing: http://release.debian.org/migration/testing.pl?package=ocsigen Now that ocaml-ssl/0.4.2-4 has migrated to testing, is it possible to schedule a binNMU of ocsigen directly in testing? Yes, it's on my TODO list, so I'll get something done about it. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «¡Pero si es tan español que debe de tener el cerebro en forma de botijo, con pitorro y todo!» -- Javier Cercas, “La velocidad de la luz” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please unblock ocaml-ssl/0.4.2-4 and binNMU ocsigen/1.1.0-1
* Stéphane Glondu [Tue, 07 Oct 2008 10:15:53 +0200]: Hi, Please unblock ocaml-ssl/0.4.2-4. It closes a serious bug. Relevant changelog entry: * Fix GC-unsafe operations in C stubs (Closes: #500591) Unblocked. The ocsigen package was affected by this bug. Please schedule a binNMU for it on all architectures: ocsigen_1.1.0-1, Rebuild against ocaml-ssl/0.4.2-4, 1, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ocsigen dep-wait ocaml-ssl (= 0.4.2-4) Scheduled. * Julien Cristau [Tue, 07 Oct 2008 14:50:21 +0200]: the dep-wait needs to be set on libssl-ocaml-dev (ocaml-ssl is the source package). Thanks. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Chavela Vargas - Luz de luna -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU for ocsigen
* Stéphane Glondu [Mon, 30 Jun 2008 13:24:49 +0200]: Stéphane Glondu a écrit : The new release of ocaml-sqlite3 (1.2.0) invalidates some interfaces that are used by ocsigen. Therefore, ocsigen must be rebuilt against this new version. ocsigen_1.0.0-1, Rebuild with ocaml-sqlite3 1.2.0, 2, alpha amd64 arm armel hppa i386 ia64 m68k mips mipsel powerpc s390 sparc ocsigen dep-wait libsqlite3-ocaml-dev (= 1.2.0-1) This request is still on topic... it's been for 16 days, now. Meh, sorry about that. Sometimes that happens, non-trivial emails tend to get delayed... too much. Thanks for the poke, and for waiting. Is there any change this binNMU is scheduled soon? So, uhm, the concerns that partial upgrades from Lenny to Lenny+1 would break if ocaml-sqlite3 changes stuff again is still unresolved. However, as per Stefano's message seems some solution will be in place for Lenny+1. I guess, then, that we can get away with the binNMU this time, but if ocaml-sqlite3 changes again, a Conflicts against ocsigen would be appropriate, could you take care of that, if the day arrives? binNMU scheduled, anyway. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alanis Morissette - Utopia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU for ocsigen
* Stéphane Glondu [Sat, 14 Jun 2008 11:39:50 +0200]: The new release of ocaml-sqlite3 (1.2.0) invalidates some interfaces that are used by ocsigen. Therefore, ocsigen must be rebuilt against this new version. Hm, how does one ensure that partial upgrades work, then? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Elton John - Crocodile rock -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378934: mldonkey-server: postinst breaks (dpkg failure) when mlnet fails to start
* Eduard Bloch [Thu, 20 Jul 2006 01:19:56 +0200]: (btw, packages.d.o still says it is there) (JFTR, you're confusing 2.7.3-2 with 2.7.7-2.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A hacker does for love what other would not do for money.
Bug#346608: advi: FTBFS: build-depends on removed xlibs-dev
Package: advi Version: 1.6.0-6 Severity: serious Hello, This is a serious bug filed against your package because it build-depends on xlibs-dev, which as announced in [1] a while ago, is no longer available in sid. This makes your package fail to build from source. [1] http://lists.debian.org/debian-devel-announce/2005/11/msg00022.html To fix this bug, you need to update your build-dependencies and substitute xlibs-dev for the list of individual X development libraries that your package needs to be built. You can find detailed information about how to do that in the DependsXlibsDev wiki page [2]. [2] http://wiki.debian.org/DependsXlibsDev As indicated by the Release Team [3], the full transition from XFree86 to Xorg is a release blocker for Etch, which means that Etch will not be released until this bug is fixed (or your package removed from testing). So, please, try to fix in a timely manner. [3] http://lists.debian.org/debian-devel-announce/2005/10/msg4.html The number of affected packages by the xlibs-dev transition is huge, so if you feel like helping with patches or uploads, feel free to follow the instructions contained in the wiki page above. A list of affected packages can be found here [4]. [4] http://people.debian.org/~adeodato/release-usertag/transition-xlibs-dev Finally, if there's a strong reason for which your package should not be NMUed, please note so in this bug report. Prospective NMUers will read your reasoning, and will decide if it's strong enough to delay their upload. Thanks for your collaboration! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
[People from debian-ocaml-mail, please keep -mentors CC'ed.] * John Skaller [Sun, 12 Jun 2005 16:27:21 +1000]: I could use a 'build-recommends' dependency, but I understand 'recommends' is only available for the binary package, not the source. Is this correct? The situation: the packaging machine requires 'ocaml' to make binaries from my source package, but if 'ocaml-native-compilers' is also installed it will do so faster, however that package is not available on all architectures. This isn't an essential feature, but here is a case, possibly isolated, where it could be useful. Normally, one resolves this and similar situations like this: Build-Depends: ocaml-native-compilers [!m68k !mips !mipsel !s390], ocaml [m68k mips mipsel s390] Where m68k, mips, mipsel and s390 are the architectures that don't have ocaml-native-compilers (I not 100% that the list is correct or complete). This, as you can imagine, instructs the buildds to install one package or the other depending on the architecture the package is being built for. *BUT*, checking build-dependencies of ocaml packages I don't really see that being used, which makes me suspect there's perhaps another mechanism in place to solve this in the Ocaml world in Debian. :) I'm CC'ing debian-ocaml-maint so that somebody there can clear up the issue for us. John, you may want to post there in the future for ocaml-related questions (or search the archives), since there'll be more ocaml-specific knowledge there than in debian-mentors. [There is a related problem, see next email please] See you there. :) Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The first step on the road to wisdom is the admission of ignorance. The second step is realizing that you don't have to blab it to the world. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with bad package
[debian-ocaml-maint CC'ed again, quoting at full for the benefit of its subscribers.] * John Skaller [Sun, 12 Jun 2005 20:40:09 +1000]: On Sun, 2005-06-12 at 10:30 +0200, Pierre Habouzit wrote: Le Dim 12 Juin 2005 08:51, John Skaller a écrit : How should a package build script cope with a fault in a package used in a build? The situation: there is a fatal bug in the 'ocaml' binary package for the amd64 architecture. This package would contain the native code ocaml compiler for amd64, which has a bug. Native code compilers for x86 works. The debian/rules can detect amd64, and there is a way to force the upstream source to not use the native code compiler. However, the problem will probably be fixed, but I cannot predict in which release of Ocaml. I propose to 'hack' debian/rules to cope. Would that be the proper way? could you bemore specific on the bugs you encounter ? because your explanation lost me a bit. 1. The program 'flxg' is an Ocaml program in the Felix system, and is the primary executable of the Felix package. The ITP registration is here: Bug#312734: Acknowledgement (ITP: felix -- a high performance statically typed scripting language) 2. When the source code for 'flxg' is compiled by the Ocaml native code compiler 'ocamlopt' on the amd64 the resulting executable segfaults. 3. When the bytecode compiler 'ocamlc' is used to build 'flxg' the resulting program executes. When the native code compiler is used on the x86, 'flxg' works. 4. The choice between 'ocamlopt' and 'ocamlc' is made by by the upstream build system. 5. There is an override in the configuration script to force the use of the bytecode compiler. 6. I propose to check for 'amd64' in the debian/rules makefile, and call configure like this: ./configure --set-int-NATIVE_CODE_COMPILER=0 if architecture 'amd64' is detected: this will stop the build process using the faulty native code compiler even if it is detected. Unfortunately the condition is not correct: it will exclude all versions of the Ocaml native code compiler for the amd64, even versions in which the bug is fixed (which I'm sure it will be). However (a) I don't know in which version it will be fixed (b) I don't know how to specify a condition on a particular range of versions of a package, particularly when the upper limit of the range is unknown at this time. Well, why don't you just put the ./configure option there for amd64 without checking for versions, and when a version of ocaml-native-compilers that fixes the issue gets uploaded, you re-upload your package with a versioned build-dependency on it. There should be a bug about this breakage on amd64, so you should be able to find out when the issue gets closed. Also, you could submit a bug against your own package (ocaml-native-compilers not being used for amd64 because of Bug#XXX), so that the need of removing that ./configure option is not forgotten. There'd be also the option of a build-conflicts, but if the configure option works fine, it seems best. And yet a third option would be to remove the amd64 ocaml-native-compilers binaries from the archive, if this breakage is known, affects all packages, and will take a while to solve. The maintainer would know more about this. (c) I cannot simplify the conditions under which the fault occurs, and so can't provide an 'autoconf' style executable test for it: at best I could 'try' the default build and rebuild the whole binary package from scratch using the bytecode compiler if build failed using the native code compiler .. this solution is quite general but extremely ugly .. this is my first attempt to make a Debian package and I suspect people would frown on this technique .. :) Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. -- Alan Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
* Roberto C. Sanchez [Sun, 12 Jun 2005 09:28:24 -0400]: Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? Good idea, but it won't work (at least with the version of sbuild in unstable, if buildds are using something more recent and smarter, that's another story). That would look first for ocaml-native-compilers and then if that is not available, for ocaml. Plus, if the ocaml-native-compilers package becomes available for other architectures, it does not require a modification to the Build-Depends to take advantage of it. As Ian Lynagh pointed me out on IRC, and I later checked on my system, sbuild blindly tries to install the first alternative, and completely fails if it's not available. So you necessarily need to specify arches, modulo my remarks above. Example output from sbuild follows: $ sbuild -d u -v foo_1.dsc ** Using build dependencies supplied by package: Build-Depends: sll | sl, debhelper Checking for already installed source dependencies... sll: missing sl: missing debhelper: already installed Checking for source dependency conflicts... /usr/bin/sudo /usr/bin/apt-get --purge $CHROOT_OPTIONS -q -y install sll Reading Package Lists... Building Dependency Tree... E: Couldn't find package sll Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Under capitalism, man exploits man. Under communism, it's just the opposite. -- J.K. Galbraith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Build-Recommends
* Adeodato Simó [Sun, 12 Jun 2005 16:14:00 +0200]: * Roberto C. Sanchez [Sun, 12 Jun 2005 09:28:24 -0400]: Couldn't you also Build-Depend on 'ocaml-native-compilers | ocaml'? Good idea, but it won't work (at least with the version of sbuild in unstable, if buildds are using something more recent and smarter, that's another story). Uhm, I stand corrected: 16:34 dato Yoe: do you know if the (new?) sbuild used by buildds copes with the situation above? 16:34 Yoe dato: yes, it should handle it 16:35 Yoe dato: it will install the preferred package, but either fall back if that doesn't exist on the given architecture, 16:35 Yoe or not touch whatever is already installed if one is 16:35 dato ok, sweet 16:35 dato I will mail -mentors again, sbuild in sid couldn't cope 16:35 Yoe for instance, many buildd chroots already have ssmtp installed, so an alternative like 'exim4 | mail-transport-agent' will not do anything 16:35 Yoe then sbuild in sid is broken 16:36 Yoe but no official autobuilder uses that one anyway; it's been modified so that it's useful to normal users as a generic build tool 16:37 dato Yoe: ok. has this been a recent change in the sbuild used by buildds, or has it been behaving like that for a long time already? 16:37 Yoe the latter 16:37 Yoe I don't recall it ever behaving differently, in fact Sorry for the false alarm. ;-) -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
