Processed: Re: Bug#446665: mercury: should this package be removed?
Processing commands for [EMAIL PROTECTED]: > severity 446665 normal Bug#446665: mercury: should this package be removed? Severity set to `normal' from `serious' > reassign 446665 ftp.debian.org Bug#446665: mercury: should this package be removed? Bug reassigned from package `mercury' to `ftp.debian.org'. > retitle 446665 RM: mercury -- RoQA; RC buggy Bug#446665: mercury: should this package be removed? Changed Bug title to `RM: mercury -- RoQA; RC buggy' from `mercury: should this package be removed?'. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
severity 446665 normal reassign 446665 ftp.debian.org retitle 446665 RM: mercury -- RoQA; RC buggy thanks On 14/10/07 at 20:32 +0200, Lucas Nussbaum wrote: > Your package came up as a candidate for removal from Debian, because: > * 4 RC bugs opened for a long time > * not suitable for a stable release according to #281369 > * Low popcon (19 insts) > * Hasn't been in testing for a very long time > * New upstream release available for a long time now Hi, This issue has been open for a long time. I am now removing mercury from Debian. If someone is still interested in fixing all those issues and getting in back in shape, the source package can be fetched from http://snapshot.debian.net/archive/2005/03/13/debian/pool/main/m/mercury/mercury_0.11.0.rotd.20040511-5.dsc -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
On Wed, Feb 20, 2008 at 06:43:27PM +1100, Peter Hawkins wrote: > Hi... > > On Feb 20, 2008 9:50 AM, Paul Bone <[EMAIL PROTECTED]> wrote: > > Mercury also supports 'grades', this makes it different to other > > compliers and more interesting to package. Each grade represents a > > complier backend and some options. There are two C backends, a Java > > backend, and Erlang backend and a MSIL backend. Options can include > > optional garbage collection (as apposed to never reclaiming memory), > > profiling support, debugging support and more. > > > > I'd like to package the library and runtime for each grade. These can > > all be installed concurrently and won't conflict. > > There are at least two issues you may have to deal with here: > * Mercury does not provide any guarantees about a stable library ABI, > so you'll have difficulty packaging grades using shared libraries and > not breaking applications when you update the libraries. Hrm, that's true. I know that at the top of each .m file in the standard library a comment describes the stability of the API exported by the library. I've also never seen any avalible call change, or go away. Some more interesting grades such as deep profiling change and can no-longer be linked with previous version of the same grade, dispite there being no mercury library code changes, only changes in the complier that will generate incompatible C code. (I'm currently working on such a change for the deep profilier). The real solution would be to standardize the API, and version the runtime along with libraries and programs compiled against it, which is a problem for upstream. Other solutions are static linking or placing the stable version number in the package name, (like zlib1g). Then programs may depend on the version they where compiled/developed against. This could get messy but since releases are sledom it may be ok. > * Mercury standard libraries can be very large (tens of megabytes in > some of the debug grades), so packaging every possible grade seems > rather wasteful of archive space. If you ask me, you need to pick a > small set of useful grades which cover most use cases. I'm not sure > how many architectures Debain supports at the moment, but if you > aren't careful you could easily consume hundreds of megabytes of > fileserver space just on Mercury library grades (10+ architectures * > 10s of Mb/grade * many grades). I begun listing the grades I think would be useful to package, I found about 6 grades, so that's not too bad. I'll list them properly when I build the package and check that I havn't forgotten any. We can also reduce space by limiting the architectures that this is avalible for, (If that's cool with Debian). I don't expect there to be much interest in arm, mips, mipsel or m68k. That said, I want mipsel packages for myself for another project :-) Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Hi... On Feb 20, 2008 9:50 AM, Paul Bone <[EMAIL PROTECTED]> wrote: > Mercury also supports 'grades', this makes it different to other > compliers and more interesting to package. Each grade represents a > complier backend and some options. There are two C backends, a Java > backend, and Erlang backend and a MSIL backend. Options can include > optional garbage collection (as apposed to never reclaiming memory), > profiling support, debugging support and more. > > I'd like to package the library and runtime for each grade. These can > all be installed concurrently and won't conflict. There are at least two issues you may have to deal with here: * Mercury does not provide any guarantees about a stable library ABI, so you'll have difficulty packaging grades using shared libraries and not breaking applications when you update the libraries. * Mercury standard libraries can be very large (tens of megabytes in some of the debug grades), so packaging every possible grade seems rather wasteful of archive space. If you ask me, you need to pick a small set of useful grades which cover most use cases. I'm not sure how many architectures Debain supports at the moment, but if you aren't careful you could easily consume hundreds of megabytes of fileserver space just on Mercury library grades (10+ architectures * 10s of Mb/grade * many grades). Peter -- 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?
On Tue, Feb 19, 2008 at 03:27:37PM -0500, Barry deFreese 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. :-) > 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. The Mercury website should be considered correct, this package (in debian) is a very old version of Mercury and I'd like to release a newer package based on the current stable version, and also ensure I can produce .debs for the current CVS HEAD. There are several components to mercury that I'd like to package in seperate binary packages. These are: + Complier + Runtime and Standard Library + Other tools such as debuggers and profilers. Mercury also supports 'grades', this makes it different to other compliers and more interesting to package. Each grade represents a complier backend and some options. There are two C backends, a Java backend, and Erlang backend and a MSIL backend. Options can include optional garbage collection (as apposed to never reclaiming memory), profiling support, debugging support and more. I'd like to package the library and runtime for each grade. These can all be installed concurrently and won't conflict. 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 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. 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. 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. I've also CC'ed the [EMAIL PROTECTED] mailing list. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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?
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?
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?
On 30/11/07 at 17:22 +1300, Roy Ward wrote: > 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. 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? ;) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- 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?
notfixed 446665 0.11.0.rotd.20040511-5 found 446665 0.11.0.rotd.20040511-5 thanks On 15/10/07 at 00:38 +0200, Lucas Nussbaum wrote: > Hi Roy, > > On 15/10/07 at 11:03 +1300, Roy Ward wrote: > >> * 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. > > Ooops, the ITA line on the PTS should be in bold :-) I missed it. > > I'm perfectly fine with keeping the package in Debian for now, if you > are working on packaging the new version. > > Thank you for the very detailed information. Hi Roy, Have you made some progress on this package? 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. Happy Hacking! -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#446665: mercury: should this package be removed?
Processing commands for [EMAIL PROTECTED]: > notfixed 446665 0.11.0.rotd.20040511-5 Bug#446665: mercury: should this package be removed? Bug no longer marked as fixed in version 0.11.0.rotd.20040511-5. > found 446665 0.11.0.rotd.20040511-5 Bug#446665: mercury: should this package be removed? Bug marked as found in version 0.11.0.rotd.20040511-5 and reopened. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446665: mercury: should this package be removed?
Hi Roy, On 15/10/07 at 11:03 +1300, Roy Ward wrote: >> * 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. Ooops, the ITA line on the PTS should be in bold :-) I missed it. I'm perfectly fine with keeping the package in Debian for now, if you are working on packaging the new version. Thank you for the very detailed information. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- 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. 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#446665: mercury: should this package be removed?
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 * not suitable for a stable release according to #281369 * Low popcon (19 insts) * Hasn't been in testing for a very long time * New upstream release available for a long time now If you think that it should be orphaned instead of being removed from Debian, please reply to this bug and tell so. If you agree, sending the following commands to [EMAIL PROTECTED] should do it (after replacing nn with this bug's number): severity nn normal reassign nn ftp.debian.org retitle nn RM: estraier -- RoM; obsoleted, RC buggy thanks For more information, see http://wiki.debian.org/ftpmaster_Removals http://ftp-master.debian.org/removals.txt 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. Thank you, -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
