Re: omake failures (#510919) (and RFS)
Evgeni Golov a écrit : BTW, there are many things that shouldn't be in the .orig.tar.gz (such as CVS directories, for a start)... For future releases, it might be relevant to repackage the upstream tarball. Yupp, but thats a different issue, not relevant here and now :) Sorry for the misinformation... CVS directories were there in the past, but not any more now :) And for really closing 510919: could either ocaml-nox or omake provide a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we (or actually you :P) don't break any user-scripts. This sounds like a dirty visible hack to me, I don't agree with this proposal. Are there so many people hard-coding ocamldep-omake in their scripts? Doesn't it sound reasonable to force people to update their scripts now? Dunno if there are people hardcoding it, I don't do any ocaml stuff. But you should consider adding a debian/NEWS file, saying ocamldep-omake is gone now, so users notice this fact on upgrade and not when their stuff is failing. Done. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919)
George Danchev a écrit : I strongly believe that removing 0.9.8.5-3-3 from both lenny and sid is the way to go, since such a insane package as have been put together should have never been uploaded to the archive in the first place [1]. Then prepare a new and fixed package (sane orig.tar.gz included), upload it to sid and ask release team if they can tolerate such a unblock for lenny at that stage. If they can't, well that is not their fault. There is no excuse for deliberately uploading such a compromised orig.tar.gz to the archive and then insist on it being released with lenny for whatever reasons. I personally see this as a dextrous way to deceive and bypass the established procedures. What you propose might be the most elegant way, but involve troublesome steps. It means removing ocaml-reins and patching upstream omake to deal with the missing file. And maybe the new package will also require a more thorough (and time-consuming) review. -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919)
George Danchev a écrit : 1. apply the above mentioned patch against ocamldep as brought with ocaml-nox package. That would be pretty dangerous, since ocaml-nox rdeps are exposed at risk. Unlikely to be approved by the release team. It seems the patch has already been applied upstream, since version 3.10¹. So the patched version shouldn't be necessary any more (to be verified). 2. prepare a separate source package to carry out that special version of ocamldep (possibly called ocamldep-omake) in order to avoid messing up with ocaml-nox package, and make it build-dependency of omake. Possilbe drawbacks: new package, unlikely to be approved by release team at that point. 3. extend the source package of omake in order to embed the sources of such a special ocamldep-omake and invoke it right along during the omake build. Drawbacks: embeded source copies, security risk. The ocaml source package already provides the ocaml-source binary package. Should a modified ocamldep (or any tool provided by ocaml) be necessary, one could depend on that package and patch ocaml sources and compile them as needed, avoiding duplication of code (and automatic test [and enforced adaptation] of the patch against new version of ocaml). 4. completely remove that broken package from the archive, no build-repends are found, no harm done. This is my favourity one. Has someone any news from Mike Furr? The last mail from him on a Debian mailing-list dates back to Feb. 2008 with a signature suggesting that he was lacking time for Debian². Note that the Maintainer field of omake is set to Mike Furr, and not the mailing-list, so that we don't receive directly any bug report related to it. Moreover, I don't understand why there is an additional -3 in the version number. BTW, there is also a new upstream version (but it is probably not the right time to import it...). I intend to have a deeper look at omake by the end of the week... with at least a migration to git, and switch of Maintainer to d-o-m (unless otherwise instructed). I will then give my opinion on point 4. ¹ http://caml.inria.fr/mantis/view.php?id=4047 ² http://lists.debian.org/debian-ocaml-maint/2008/02/msg00023.html Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919)
On 07-01-2009, Stéphane Glondu st...@glondu.net wrote: 4. completely remove that broken package from the archive, no build-repends are found, no harm done. This is my favourity one. Has someone any news from Mike Furr? The last mail from him on a Debian mailing-list dates back to Feb. 2008 with a signature suggesting that he was lacking time for Debian². Note that the Maintainer field of omake is set to Mike Furr, and not the mailing-list, so that we don't receive directly any bug report related to it. Moreover, I don't understand why there is an additional -3 in the version number. BTW, there is also a new upstream version (but it is probably not the right time to import it...). I intend to have a deeper look at omake by the end of the week... with at least a migration to git, and switch of Maintainer to d-o-m (unless otherwise instructed). I will then give my opinion on point 4. For what is important, I totally agree with hijacking the package to git/d-o-m. I think Mike Furr is MIA for now, just explain that we hijack the package waiting mfurr to come back. I do however disagree with point 4. OMake is used by some people, like Jane Street, so there is at least some user around. Unfortunately, I don't have time/interest to fix the bug. Maybe an intermediate just remove for lenny should be enough. Regards, Sylvain Le Gall -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919)
Sylvain Le Gall gil...@debian.org writes: On 07-01-2009, Stéphane Glondu st...@glondu.net wrote: 4. completely remove that broken package from the archive, no build-repends are found, no harm done. This is my favourity one. Has someone any news from Mike Furr? The last mail from him on a Debian mailing-list dates back to Feb. 2008 with a signature suggesting that he was lacking time for Debian². Note that the Maintainer field of omake is set to Mike Furr, and not the mailing-list, so that we don't receive directly any bug report related to it. Moreover, I don't understand why there is an additional -3 in the version number. BTW, there is also a new upstream version (but it is probably not the right time to import it...). I intend to have a deeper look at omake by the end of the week... with at least a migration to git, and switch of Maintainer to d-o-m (unless otherwise instructed). I will then give my opinion on point 4. For what is important, I totally agree with hijacking the package to git/d-o-m. I think Mike Furr is MIA for now, just explain that we hijack the package waiting mfurr to come back. I do however disagree with point 4. OMake is used by some people, like Jane Street, so there is at least some user around. Unfortunately, I don't have time/interest to fix the bug. Maybe an intermediate just remove for lenny should be enough. Regards, Sylvain Le Gall On that note could we get the current omake into experimental? MfG Goswin -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919)
On Wed, Jan 07, 2009 at 03:35:33PM +, Sylvain Le Gall wrote:
For what is important, I totally agree with hijacking the package to
git/d-o-m. I think Mike Furr is MIA for now, just explain that we hijack
the package waiting mfurr to come back.
While stating that, it would have been more than appropriate to Cc
him. Doing that with this post.
If we get no reply, we loose nothing; if we do get a reply, we gain
something.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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
Description: Digital signature
Re: omake failures (#510919)
On Wed, Jan 07, 2009 at 03:54:52PM +0100, Stéphane Glondu wrote:
I intend to have a deeper look at omake by the end of the
week... with at least a migration to git, and switch of Maintainer
to d-o-m (unless otherwise instructed).
Seconded.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{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
Description: Digital signature
Re: omake failures (#510919)
Hi d-o-m, Stéphane Glondu wrote: Has someone any news from Mike Furr? The last mail from him on a Debian mailing-list dates back to Feb. 2008 with a signature suggesting that he was lacking time for Debian². Note that the Maintainer field of omake is set to Mike Furr, and not the mailing-list, so that we don't receive directly any bug report related to it. Packaging wise, I really haven't done much in quite a while. I usually check d-o-m a couple of times a month to see how things are going, but most of my packages haven't needed an update in quite some time either. Thanks to Stefano for pinging me on this discussion. Moreover, I don't understand why there is an additional -3 in the version number. The upstream release number includes a -N, so the full debian version has a -N-M postfix. BTW, there is also a new upstream version (but it is probably not the right time to import it...). No, the 0.9.9 is only a pre-release, it is not intended to replace 0.9.8.5 at this point. As far as ocamldep-omake is concerned, that version of ocamldep was introduced by the omake developers a long time ago to get around fundamental limitations in the tool. It was meant to be somewhat temporary, but getting patches accepted upstream into OCaml is not always easy (especially for new features), so it persisted for a couple of versions before it was accepted upstream. Since it was included for a significant period of time, I decided to leave it in the package until the next major point release of omake (which, unexpectedly, has yet to happen) even after it was deprecated, as users of omake may have referenced it in their build scripts (I know I had to at one point). Stripping the header line was obviously a dumb idea... I don't recall why I decided to do that. So, at this point I would suggest one of the following fixes: 1) Remove ocamldep-omake from the package since it is not used by omake itself. This may impact users who otherwise invoke it themselves (for historical reasons). 2) Put the header line back and update OCaml.om to call it correctly. If it is in violation of policy to not ship the entire source code of the bytecode (instead of the patch as is done currently), then also add the necessary source files. I haven't looked at policy in a while, nor have I been following the debates about binary blobs in source packages, so I trust the opinions of others on this subject. I would recommend #2 since we are so close to releasing Lenny, and certainly removing the file once it is released. I think removing the entire package from Lenny would be a shame since a lot of people use it (myself included!). As for the general state of this and my other OCaml packages, I think I would like to put my ego aside and ask you guys take them over as group maintained packages. My primary Debian machine died a few months ago, I haven't learned git (yet), and I'm only a few months away from finishing my PhD, so this is not the best time for me to spend a lot of time getting back up to speed in Debian. I do miss it though, and hope to become more active in the future. Cheers, -Mike -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919) (and RFS)
I wrote in 4964c23c.7020...@glondu.net: 1. apply the above mentioned patch against ocamldep as brought with ocaml-nox package. That would be pretty dangerous, since ocaml-nox rdeps are exposed at risk. Unlikely to be approved by the release team. It seems the patch has already been applied upstream, since version 3.10¹. So the patched version shouldn't be necessary any more (to be verified). [...] I intend to have a deeper look at omake by the end of the week... with at least a migration to git, and switch of Maintainer to d-o-m (unless otherwise instructed). I will then give my opinion on point 4. As said in git commit bfd1cebf64a424759df083c1fc15276cc9ea3fff: Do not install ocamldep-omake (Closes: #510919) The build system of omake detects by itself that standard ocamldep supports -modules (starting from OCaml 3.10), and do not need ocamldep-omake in this case. However, it still installs it. FWIW, the only (build-)rdep in our svn, ocaml-reins, builds correctly without ocamldep-omake. Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919) (and RFS)
On Thu, 08 Jan 2009 01:29:49 +0100 Stéphane Glondu wrote: As said in git commit bfd1cebf64a424759df083c1fc15276cc9ea3fff: Do not install ocamldep-omake (Closes: #510919) The build system of omake detects by itself that standard ocamldep supports -modules (starting from OCaml 3.10), and do not need ocamldep-omake in this case. However, it still installs it. Did you also remove the binary from the .orig.tar.gz? We don't have the source for it... And for really closing 510919: could either ocaml-nox or omake provide a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we (or actually you :P) don't break any user-scripts. Regards Evgeni -- Bruce Schneier Fact Number 170: Bruce Schneier's abs are NP-hard. pgpbCVKcverq2.pgp Description: PGP signature
Re: omake failures (#510919)
Mike Furr wrote: [things] Obviously, I didn't see this mail when I wrote my previous one (496548fd.2080...@glondu.net). 1) Remove ocamldep-omake from the package since it is not used by omake itself. This may impact users who otherwise invoke it themselves (for historical reasons). This is what I've done. As far as Debian is concerned, only ocaml-reins depends on omake (please correct me if I'm wrong), and it doesn't explicitly use ocamldep-omake. For users invoking it directly... I think it's not a big deal to make them change (as they are likely to being forced to change some of their configuration files in etch-lenny transition anyway). 2) Put the header line back and update OCaml.om to call it correctly. If it is in violation of policy to not ship the entire source code of the bytecode (instead of the patch as is done currently), then also add the necessary source files. I haven't looked at policy in a while, nor have I been following the debates about binary blobs in source packages, so I trust the opinions of others on this subject. I would recommend #2 since we are so close to releasing Lenny, and certainly removing the file once it is released. I think removing the entire package from Lenny would be a shame since a lot of people use it (myself included!). I agree on the last sentence, but still thinks #1 is the best course of action for other reasons: the OCaml syntax might have evolved since 3.09, and there is no upstream statement that the bytecode is compatible (actually, we have an upstream statement of the opposite). Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919) (and RFS)
Evgeni Golov a écrit : Did you also remove the binary from the .orig.tar.gz? We don't have the source for it... No, I didn't. Even though the source is not technically available (in the archive, today), there is an advertised way to rebuild it with only free tools... IMHO, it is not the same issue as all the recent firmware fuss. Besides, we do not use this binary any more. For Lenny, it didn't seem worth to me to repackage the upstream tarball. BTW, there are many things that shouldn't be in the .orig.tar.gz (such as CVS directories, for a start)... For future releases, it might be relevant to repackage the upstream tarball. And for really closing 510919: could either ocaml-nox or omake provide a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we (or actually you :P) don't break any user-scripts. This sounds like a dirty visible hack to me, I don't agree with this proposal. Are there so many people hard-coding ocamldep-omake in their scripts? Doesn't it sound reasonable to force people to update their scripts now? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-ocaml-maint-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: omake failures (#510919) (and RFS)
On Thu, 08 Jan 2009 02:05:02 +0100 Stéphane Glondu wrote: Evgeni Golov a écrit : Did you also remove the binary from the .orig.tar.gz? We don't have the source for it... No, I didn't. Even though the source is not technically available (in the archive, today), there is an advertised way to rebuild it with only free tools... IMHO, it is not the same issue as all the recent firmware fuss. Besides, we do not use this binary any more. For Lenny, it didn't seem worth to me to repackage the upstream tarball. I'm not a good legal boy, but you're prolly correct that it can be in the source tarball for now. What do the others think? BTW, there are many things that shouldn't be in the .orig.tar.gz (such as CVS directories, for a start)... For future releases, it might be relevant to repackage the upstream tarball. Yupp, but thats a different issue, not relevant here and now :) And for really closing 510919: could either ocaml-nox or omake provide a ocamldep-omake symlink, pointing to ocamldep? Just to make sure we (or actually you :P) don't break any user-scripts. This sounds like a dirty visible hack to me, I don't agree with this proposal. Are there so many people hard-coding ocamldep-omake in their scripts? Doesn't it sound reasonable to force people to update their scripts now? Dunno if there are people hardcoding it, I don't do any ocaml stuff. But you should consider adding a debian/NEWS file, saying ocamldep-omake is gone now, so users notice this fact on upgrade and not when their stuff is failing. Regards Evgeni -- Bruce Schneier Fact Number 893: Schneier has no diseases, but he isn't vaccinated. Injection doesn't work with him. pgp7NO7l8su0I.pgp Description: PGP signature
Re: omake failures (#510919)
Hey, please CC me, I'm not subscribed :) On Tue, 6 Jan 2009 23:21:22 +0200 George Danchev wrote: 1. apply the above mentioned patch against ocamldep as brought with ocaml-nox package. That would be pretty dangerous, since ocaml-nox rdeps are exposed at risk. Unlikely to be approved by the release team. I bet it wont be approved, but building another binary out of the ocaml-nox source with the patch applied should work? So ocaml-nox will have ocamldep (the original) and ocamldep-omake (the patched). Or one could push the latter into a separate package built from the same source, would have to go through NEW then, but sounds more RM compatible than changing ocamldep directly. 2. prepare a separate source package to carry out that special version of ocamldep (possibly called ocamldep-omake) in order to avoid messing up with ocaml-nox package, and make it build-dependency of omake. Possilbe drawbacks: new package, unlikely to be approved by release team at that point. 3. extend the source package of omake in order to embed the sources of such a special ocamldep-omake and invoke it right along during the omake build. Drawbacks: embeded source copies, security risk. The separate source package would also have an embedded copy, same bad IMHO. 4. completely remove that broken package from the archive, no build-repends are found, no harm done. This is my favourity one. Well, omake is in Etch, and I dont like the idea to drop such a package. Additionally people could be using it localy, you newer know. While I believe that 2nd. and 3rd. would have been possible (ugly, but possible) courses of action before the freeze (provided these blatant failures would have not been ignored lightly), I don't believe that release team would approve them at that stage of the release. Obviosuly 1st. is pretty dangerous, thus we will be better served with 4th. Comments ? I'd go for 1.5, ocaml-nox builds a new ocamldep-omake binary. But YMMV as usual :) Regards Evgeni -- Bruce Schneier Fact Number 955: Bruce Schneier does not get kidney stones. He gets Rosetta Stones. pgp3PBA7aHqIy.pgp Description: PGP signature
