Spec URL: ftp://ftp.licr.org/pub/xview.spec SRPM URL: ftp://ftp.licr.org/pub/xview-3.2-0.1.p4.src.rpm Description: XView (X Window-System-based Visual/Integrated Environment for Workstations) is a user-interface toolkit to support interactive, graphics-based applications running under the X Window System. XView provides a set of pre-built, user-interface objects such as canvases, scrollbars, menus, and control panels. The appearance and functionality of these objects follow the OPEN LOOK Graphical User Interface (GUI) specification. XView features an object-oriented style Application Programmer's Interface (API) that is straightforward and easy to learn. This is pretty much vintage stuff :-) There are a few useful pieces of scientific software that depend on the xview package. I intend to submit some of them over time, starting with treetool. This review request is to get the ball rolling. Some discussion already occured on f-e-l: https://www.redhat.com/archives/fedora-extras-list/2006-October/msg00643.html It looks like we will have to exclude 64-bit architectures for now, and use the 32-bit packages on x86_64. Hans, please add your patches to this ticket... tia :-)
Maybe it would be interesting to submit treetool before the review is completed such that we can test that xview works correctly on treetools, otherwise there is no test case. I'll follow the review, but I'd like to avoid formally reviewing the package for obvious reasons...
(In reply to comment #1) > Maybe it would be interesting to submit treetool before the > review is completed such that we can test that xview works > correctly on treetools, otherwise there is no test case. Will do ASAP. I'm currently waiting for the OA to clarify the license terms (he already said in PM he has no problem to put this in FE, but hasn't decided yet which exact license to use)... In the meantime, there are a few clients (cmdtool, shelltool, clock) already included in the xview package. > I'll follow the review, but I'd like to avoid formally reviewing > the package for obvious reasons... Sure, np. Thanks for putting it together in the first place.
Created attachment 140809 [details] Patch with some interesting fixes from Suse I've spend some hours taking a look and I've come to the same conclusion as the Debian maintainer, this is very hard to fix for 64 bit. More then that fixing probably will also include fixing / changing all xview using clients! Luckily all 64 bit platforms we support also have a 32 bit compatibility option, so I think we should just not build xview (and apps using it) for x86_64 / ppc64. It would be a good idea IMHO in cases like this to add xview + deps + packages using it to a list of packages to copy over to the x86_64 repo from the i386 repo, so that it will be readily available for those who want it. My taking a look started with suse since they had x86_64 packages of xview in their repo, but appearantly these have had the famous suse QA done do them (iow none). I did find some other interesting patches in there, which I have bundled in a smaller one with possible real fixes and a larger one which fixes a load of warnings (but no where near all warnings). I also have a patch which fixes some 64 bit related warnings by adding the necessary prototypes, which isn't enough to get this running but IMHO still should be applied / send upstream (Debian claims to be upstream these days) as it is an improvement.
Created attachment 140810 [details] Patch fixing a bunch of warnings
Created attachment 140811 [details] Patch: add some missing prototypes fixing a few 64 bit related warnings (but 64 bit is still nogo)
Christian ping ?
yea, I'm still here... but haven't had any time to work on this. But there's hope... Are you interested in helping ?
Ok, I made some progress. New SRPM and spec here: ftp://ftp.licr.org/pub/xview.spec ftp://ftp.licr.org/pub/xview-3.2p1.4-0.fc7.src.rpm I still haven't heard back from the treetool maintainer (and poked him again, we'll see). In the meantime: any idea which xview-using package would be suitable as guinea pig? I thought about workman, but I don't think anyone would actually use it :-) This thing compiles and runs on i386 (and probably ppc) in 32 bit. There are still quite a few worrisome compiler warnings. And much more work to get it to run on 64-bit machines. I didn't see any progress in Debian on this front. rpmlint seems mostly happy I'd still like to clean it up further, but this is where I got so far and it might already be useful to other folks as-is... Thanks to Hans for all the work he put into this already. Of course, if anyone is interested in co-maintaining, I'd be delighted
[in reply to comment #7] >> Are you interested in helping ? yes. ;-) okay, i'll check this out on x86_64.
This ticket is now over a year old; is it dead yet? Or is there still interest in moving it forward?
(In reply to comment #10) > This ticket is now over a year old; is it dead yet? Not, dead... just in deep slumber :) > Or is there still interest in moving it forward? I'm still interested to see this in, somehow.
So what needs to happen? I mean, you could use ExclusiveArch: i386 (and maybe ppc too) but that seems somewhat pointless. There are a few other things that would need to be fixed: "Distributable" is never OK for a License: and you'd need to remove or split off the static libraries.
(In reply to comment #12) > So what needs to happen? I mean, you could use ExclusiveArch: i386 (and maybe > ppc too) but that seems somewhat pointless. > > There are a few other things that would need to be fixed: "Distributable" is > never OK for a License: and you'd need to remove or split off the static libraries. That sort of went under the radar for a while now. But I'll try to find some time and clean up the mess a bit. I wanted to take a second hard look to see if it would be feasible to make this 64-bit clean... but I could start with a bunch of ExcludeArch. The thing is that if I distribute a 32-bit only package first, things will probably break when the code is cleaned for 64-bits. So I'm a bit hesitant...
I guess it's time to ping on this old ticket. Has there been any progress?
No progress: -ENOTIME... I still intend to get back to it when time permits. If you'd rather see this one closed, I can always reopen a new one when I'm ready.
All I can say is that as long as this ticket is open, I'll keep pinging it. So if you'd like a reminder ever couple of months then sure, leave it open.
(In reply to comment #16) > So if you'd like a reminder ever couple of months then sure, leave it open. Fine with me :-)
Well, I promised I'd ping every couple of months, and I'm about a week late. Any progress?
No progress... (gee, time flies...)
Still no progress...
ping :)
Still here and still haven't lost interest, and doing my best not to lose hope...
spec url doesn't work.
(In reply to comment #23) > spec url doesn't work. Strange. Works for me... From where are you trying to access it, and what exactly happens ?
(In reply to comment #24) > (In reply to comment #23) > > spec url doesn't work. > > Strange. Works for me... > From where are you trying to access it, and what exactly happens ? Okay, that was a problem with Chromium. With Firefox it works fine. (I'm still waiting for ftp servers to vanish from the face of the earth, as well as any other protocols that aren't firewall safe.)
(In reply to comment #25) > (I'm still waiting for ftp servers to vanish from the face of the earth, as > well as any other protocols that aren't firewall safe.) eh ... :-)
Ping? I would suggest to close this ticket.
(In reply to comment #27) > Ping? I would suggest to close this ticket. Ok. Still haven't found enough time to work on this unfortunately.