Bug#446665: mercury: should this package be removed?
I filed the initial ITA, but have then been unable to make much progress because of other commitments (including being overseas for a while). Unfortunately, although I'm back now, unforeseen personal circumstances mean I won't be able to do anything in the immediate future (next 2-3 weeks at least) either, and getting something releasable would be later than that. If someone wants to adopt it, please do, and I'll help as much as I can. Otherwise I _will_ get to it, but it may not be for a while. As for the gcc-3.4 vs. gcc-4.1, I'd had a good look at that, and it depends which version: The Release Of The Day does indeed compile with gcc-4.1 The latest release (0.13.1) which was the one I was looking at packing (to avoid a ROTD ending up in stable) does not - it does require gcc-3.4 (there's only a couple of places where it is broken under gcc-4.1/gcc-4.2, but it would take someone with more knowledge than me to fix that). I use 0.13.1, but the version to package depends on: * when there is going to be another release (I don't know this) * whether most current users use 0.13.1 or ROTD (I don't know but can find this out). Cheers, Roy Ward. Barry Freese wrote: Hi folks, Sorry for all of the CCs but all of you have expressed interest in fixing/adopting this package (with the exception of QA). Do any of you still have an interest and/or a plan to fix this package? According to the Mecury website, it is supposed to build with gcc-4.1 which would be a hell of a lot better than gcc-3.x. Is that not the case? This thing has been orphaned a while and has an RC bug over a year old. If no-one wants to fix it up, I will request removal within the week. If I can help with packaging or fixing this thing, please feel free to contact me and will gladly help if I can. Otherwise it's a goner. :-) Thank you! Barry deFreese -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Paul Bone wrote: Hi Barry. I'm interested in re-packaging this, however it's going to be one of those things that gets a small amount of attention here and there. I'm one of the Mercury developers, so I use and develop on Mercury day-to-day. This will mean that there may be 6-12 mercury-related packages. And since I haven't packaged for Debian before this is rather an ominous task. I intend to read plenty of documentation and seek the help of [EMAIL PROTECTED] as appropriate. I'm in a similar position - not much time, and have never created a Debian package before. I was going to create one big package, but 6-12 makes more sense. I usually use the ROTD releases, however that's mostly because I'm working on Mercury it's self. It is probably useful to package a stable release and a ROTD, since we havn't made a release for a while. One of the reasons that the previous version never made it to stable was that was an ROTD, so I see using a ROTD only as a bit of a trap. Packaging both might be good though, but only have the release version go into Lenny. Unfortunatly I can't make any progress of when this will be done, and I'm not yet sure the best way to do it. Will removing the old package from Debian make it harder for me to get this one in? If so I'd like it left in Debian until I'm able to complete this. But since I want to package the new stable version instead removing it may not affect me. I was involved in discussions on this a while ago (when I put in the ITA) and my thought was to leave it in so the bug history etc. doesn't get removed (some it it is still relevant). Taking it over might also make it easier to get a sponsor if you are not a Debian dev. It would also be nice not to have another package grab the name. However the maintainers have the final say on that. Ray Ward: I'd like to addopt this, may I? If you agree I'll change O to ITA and make myself the owner on bug #379682. Absolutely, particularly as my ITA was quite some time ago, and I've still not managed to get a package ready. It sounds like we are in similar positions time and experience wise, and you have the advantage of being a developer - I've only been a user for a few years. My main interest is to see that a reasonably recent Mercury package gets into Debian. With what limited time I've got, I'm also happy to help in any way I can. Cheers, Roy Ward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Lucas Nussbaum wrote: I don't know anything about mercury, but maybe it would be a better plan to package rotds, and find and fix bugs in them, instead of trying to get an old version in debian, and then switching to a brand new release just before lenny. Note that you could also decide to include a rotd in lenny, if upstream hasn't released anything by then... I think that the answer to that actually is our priority is our users. What's the most useful choice for our users? ;) Well, the most useful thing for users is to have a somewhat recent version of Mercury ;-) As for the release vs. rotd, I'm really in two minds on that - gcc-3.4 is very old (I thought I saw a post somewhere suggesting that gcc-3.4 getting retired from Debian at some point, although I was unable to find the post when I went back to look for it). Also mercury-0.13.1 is a year old, and the rotds are very good. On the other hand, at least one of the reasons that the previous version of Mercury never made it to testing/stable is that it got caught in the rotd versions - the maintainer didn't want a rotd ending up in stable. Also, as a user I use 0.13.1 for all my Mercury development, so it is at least a viable option. If anyone else reads this (and I could check on the Mercury mailing list as well and ask the other users directly), I'm open to suggestions on this. There's also another delay on me spending time on this - I'm shortly going away till end of Jan. Cheers, Roy Ward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Lucas Nussbaum wrote: Have you made some progress on this package? Some, but not enough to submit a package. One bit of news is that gcc-3.3 is going to be the required compiler. I've looking at building Mercury 0.13.1 with several versions of gcc on x86 and amd64, and while projects are fine with a later gcc, Mercury itself won't build under newer versions. The next upstream release (whenever that is) will shift gcc versions to 4.1 or 4.2. If someone reading this can tell me that a version of gcc that old is not acceptable, I'll package a rotd (release of the day), and then gamble that there is a full upstream release before the Lenny release. Also, I'm reopening this bug. Feel free to close it when the other RCs are fixed, but it's easier for us to keep track of this issue with this bug. OK, thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Lucas Nussbaum wrote: Package: mercury Version: 0.11.0.rotd.20040511-5 Severity: serious User: [EMAIL PROTECTED] Usertags: proposed-removal Hi, Your package came up as a candidate for removal from Debian, because: * 4 RC bugs opened for a long time Of the bugs: * #281369: Dummy RC bug against Mercury explained below. * #430313: ldbl128 transition for alpha, powerpc, sparc, s390 I'm reasonably sure that doesn't apply to Mercury as the language doesn't support long doubles, but I want to be certain before closing this bug. * #297217: mercury: FTBFS (amd64/gcc-4.0): invalid lvalue in assignment * #381813: mercury: FTBFS: cannot stat `./debian/tmp/usr/lib/mercury/bin': No such file or directory For both of these, Mercury has _never_ worked with gcc-4.0 - it does work with gcc-3.4 (recommended by upstream), gcc-4.1 or gcc-4.2 (my preferred version, but there's some issues and testing I need to work through). * not suitable for a stable release according to #281369 I've checked with the previous maintainer and upstream on this one. The reason for the bug is that the previous maintainer didn't want a 'release of the day' (Mercury has two available branches - the numbered releases, and the 'release of the day') getting into testing/stable. I intend to package only the numbered releases. Upstream has no objections to this being packaged for Debian. * Low popcon (19 insts) I consider the current package is too old to be useful (I've been telling people to install from source rather than the package). Also, as a logic programming language, it's unlikely to ever have a particularly high popcon. * Hasn't been in testing for a very long time See comments on bug #281369 * New upstream release available for a long time now I'm working on packaging that - it's still going to take some time (in the order of weeks). If you think that it should be orphaned instead of being removed from Debian, please reply to this bug and tell so. This is confusing - I thought it was already orphaned, which is when I filed an ITA. snip If you disagree and want to continue to maintain this package, please just close this bug, preferably in an upload also fixing the other issues. Whether to remove or not in the meantime I'm not certain. What makes the most sense - to leave it in until I get upload a replacement (for which I will need to find a sponsor), or remove it in the meantime and I can apply to get it added to Debian as a fresh package? My preference would be to keep it, as upgrading a package will be easier than adding a new one, and it means the name, bug history, description etc. gets kept, but I'm open to suggestions on that one. I will close this bug in the meantime. It's not an option to quickly release a partial fix, as Mercury is a reasonably large package (and it takes quite a while to build) and I want to have something pretty much right before a sponsor gets to spend any time on it. Cheers, Roy Ward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423298: mercury: should this package be orphaned?
I'd like to adopt the mercury (and mercury-docs) packages, unless someone more qualified wishes to do it. I've been using Mercury on Debian (i386 and amd64) for some years now, and want this easily available to other Debian users. I am not a Mercury developer, but the feedback I've had from the devs is It's fine by us if I adopt the package. I've also had some feedback from the previous maintainer. Some years ago, I contributed to the MacOSX (powerpc) port of Mercury, so I have some knowledge of the build system. I would not be able to make any significant changes to the code, but could pass relevant bug reports back upstream. I am also not a Debian Developer, so I will be seeking a sponsor at some point to do package uploads. My plan would be to package numbered releases of Mercury only (currently 0.13.1) which would deal with bug #281369 and this bug, and to have Mercury depend on an appropriate version of gcc (Mercury is very fussy about gcc version) which would deal with bugs #297217 and #381813. Note that this is very early in the process - I have not yet constructed any packages (there's a learning curve there), but thought I'd get this out early so as to avoid any risk of duplication of effort - if someone else is looking at doing this, please let me know! Cheers, Roy Ward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
