A non-important question

[fargodwe]

Hello. I have a question that is not something I need before doing something, so please feel free to help others who need help now.

Background: I have a program, GedStarPro, which converts my genealogy database so it can be used by a corresponding program on my Android devices. When ever I have a need to install or reinstall wine such as a change of computers, etc., I always have to use the staging instructions. Member Bob Wya thankfully got this all working for me since I don't understand the technical side of things. Without using staging each time the program errors out when it is apparently opening a jet database. Using staging always solves this. I recently installed linux Mint 20 so I followed the focal instructions but again the program aborts until I install staging.

So, I know there is a terribly HUGE amount of things that go in to a wine release. So I also know that finding the root of this is probably like looking for a needle in a haystack, but is there anyway I can do anything - some kind of testing or tracing or something that could help track this? I'm afraid someday whatever it is that works in staging but not in the "normal release" might disappear and then my program would never run again.

I know this is not important in the overall world of wine and all the effort it takes just to give us a wonderful tool. If it is something someone may want to look at sometime I would be more than happy to do what ever I can. I'm a simple guy so it would step-by-step instructions but I'm more the willing to help.

Thank you for your time.

[spoon0042]

It's possible to do a modified regression test to find which staging patch allows your program to work. If you've never done a regression test before though that may be a tall order. I forget if there was a page on the wiki explaining it; some info on regression testing staging is here though: https://wiki.winehq.org/Wine-Staging#Re ... st_Staging
and more on regression testing generally: https://wiki.winehq.org/Regression_Testing

I could try to walk you through it if you wanted but it is a bit much. Regression testing is kind of like looking for a needle in a haystack now that I think about it, it just speeds things up by repeatedly cutting the pile in half.

[fargodwe]

So, I would start with the source for the latest stable branch, then add staging patches one at a time and testing each until I find the one that makes my program work. That does sound a "bit" over my skills. Coming from a programming and systems programming background I understand what would need to happen but I really just don't even know where to start. Perhaps I should start with downloading whatever is needed and "just" try to build the stable version of wine? From there I could try to get staging patches one at a time and would have to rebuild wine each time?

I guess I can look into building wine and until i understand that. I'll probably have a LOT of questions!

Thank you!

[fargodwe]

Is there any kind of description for each patch so I could at least isolate some of them? No need for them yet obviously!

[spoon0042]

The second link there goes over the process of regression testing, you can read over it to get an idea of what all is involved. Git has functionality that makes the process... uh, not quite "easy" but not too difficult. Step zero would be to get the wine source and build a working version, more on that here: https://wiki.winehq.org/Git_Wine_Tutorial

Guessing which patch could work too. The wine-staging git is here: https://github.com/wine-staging/wine-staging
The patches are, appropriately, in the patches directory. The names are... somewhat descriptive? The individual patches more so than the directories which are named by the dll they modify. You could pull a local copy of wine-staging and use find or grep on some keywords.

[fargodwe]

I'm really completely inexperienced when it comes to linux. My only very basic knowledge of Git is a revision control package but there is obviously a lot more an a lot involved. I will get the wine-staging and try to get it built which I imagine is going to take me a long time. Once I've done that hopefully I will be able understand enough from the wiki's to start trying the regression testing. I am sure I'll have a million questions along the way.

Thank you!

[fargodwe]

Well, you can tell how stupid I am. I tried the configure after using the git statement on the git page you linked to. After only a few lines I already got this error. I have searched the net and have found nothing that says where to get those and install them. I have checked with the package manager in Mint and can't find anything. So right off the bat I'm already messed up. I'd really like to be able to at least build wine-staging then follow the other instructions you linked to.

Code: Select all

configure: error: Cannot build a 32-bit program, you need to install 32-bit development libraries

[spoon0042]

Oh. Yeah. You're going to need a whole mess of 32-bit *-dev packages. Also some info on building wine is here, just the first two sections: https://wiki.winehq.org/Building_Wine

(I assume your program is 32-bit. If it's 64 things get... not fun.)

The easiest way to get a 32-bit build environment is to add a deb-src line to match whatever you added for wine in /etc/apt/sources.list or under sources.list.d. Assuming it's focal it should look like this:

Code: Select all

deb https://dl.winehq.org/wine-builds/ubuntu/ focal main
deb-src https://dl.winehq.org/wine-builds/ubuntu/ focal main

Then 'apt update' and... I'm not 100% on this but try 'apt-get build-dep wine' and see what happens. If I haven't scared you off.

[fargodwe]

The "deb" line was in /etc/apt/sources.list.d/additional-sources.list so I added the "deb-src" line there, did the update, did the upgrade, got the following indicating broken packages. I went through this once building ubuntu a few years ago and seemed to go through dependency hell getting that straighten out, but I've never had the broken packages come up. An "apt check wine" came back clean. An "apt recommends wine" came back clean.

Code: Select all

dave@dave-Aleena:~$ sudo apt build-dep wine
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 builddeps:wine : Depends: libosmesa6-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
dave@dave-Aleena:~$ 

I hope somewhere along the line it gets a little less frustrating but I suspect not. I know squat about wine except for running 3 windows apts. I also don't know squat about the OS anymore. Maybe I should just let this die, but I have to go on because i want this problem solved once and for all. I had some admins REALLY mad at me when i posted a message about this happens in ubuntu but not another linux. All they wanted to do was tell me i was using staging and all over me for not knowing terminologies like stable, develop and staging. It made me mad and I finally just said FINE and dropped it - it was as if they didn't understand my problem and/or didn't care. This problem has occurred each new release and forces me to use staging. I'm tired of that and I'm tired of something not working fine in every dang stable release since 3.x and I want to FIND and INFORM about where the problem initiates and get it fixed. So I'm mad at myself for not understanding any of the "stuff".

[spoon0042]

Don't beat yourself up over it; I consider it a minor miracle that any of this works at all.

The standard advice for dependency problems is to try to install the problem package and see what happens, and repeat as necessary. Or it might try to uninstall half your system. Other third party repos can complicate things here.

It's also possible there's some quirk with Mint 20 that the winehq guys didn't anticipate. I may be able to look into this when I have some free time.

As for the "mad admins" was that on this site, did you file a bug here, or what? Note that your program may need some patch from staging and some patches have been in staging for years. If things worked on some other distro though that would be an interesting problem.

[fargodwe]

I wanted to file a bug report, but when I opened a thread on doing so and for what reason I was told it was staging and then everything went to heck. I believe Bob Wya, who was the one who was able to make this all work for me, had said he had it running with the release branch but was running a different linux distribution so I said it must be something included with standard wine release for linux "xx" but getting continually dropped from Ubuntu. To say I was made to feel like the worst piece of trash on the planet would be an understatement and started me looking to native applications to use instead so I could just quit having any need for wine, but none like these are available without a huge conversions of data, documents, pictures, etc., and nothing like GedStar Since I therefore have to use GedStar, and it's the program with this problem, I decided to try to find some way to get to the bottom of it myself. It would appear that isn't going to be the case now either with Mint 20. So now I don't know what I should do - perhaps get away from Ubuntu/Mint/et al and try the distribution Bob Wya was running. To me it seems like a lot of screwing around to get something that is "fixed" in staging to finally be "fixed" in the standard release. Why there doesn't appear to be a description of what all a patch is doing I suppose is the way things are kept too difficult for the rest of us to learn so it remains in the hands of the elite. They do a great job, but this situation should not be that hard. Take the source for the general release, try applying 1 patch in the patch set for staging. If it doesn't solve the problem, move on to the next patch.

Guess I'm stuck with no solution again.

[spoon0042]

That's all... yeah, a pain. I'd like to help; I found your other threads here and am trying to get it working but can't seem to. To be clear, you do have it working on some current wine, version and branch? And should it work just by pointing it to the sample.fdb from Legacy, or is there some configuration to do in either program?

[fargodwe]

There's just a touch more - thanks to Bob Wya for finding this all out for fixing this. First it needs to be a 32-bit prefix and every "release" of wine I have had to use the staging branch to get it to work - never has worked in the "regular" branch. I think it's all in the previous threads. You have to install mdac28 with winetricks FIRST, then go back with winetricks again and install jet40. That's the order Bob Wya got things working for me and I have always followed that when I've had reinstall.

[fargodwe]

I just tried something - and *IF* I did things correctly - it looks like it now works in wine stable 5.0.1. I did the following:

Code: Select all

sudo apt-get purge winehq-staging

After doing so when I tried

Code: Select all

wine --version

it said that wine wasn't known.

I then

Code: Select all

sudo apt install --install-recommends winehq-stable

After doing so when I tried

Code: Select all

wine --version

and it showed

Code: Select all

wine-5.0.1

At this point I *assume* all I have is wine-stable.

Just in case I recreated the 32-bit prefix, used winetricks to install mdac28 and then again to install jet40.

I reran GedStar and it runs - so if I understand things correctly it means it *IS* finally running in wine-stable. If so, can I safely assume that what ever was causing it to fail will now be there in future versions of wine-stable?

So, *if* this is all correct, you now don't need to do anything. When I created the 32- bit prefix I had also installed mdac28 and then installed jet40 as I know these were still needed. I must have really screwed up my testing when I installed Mint 20. So I apologize for wasting your time and I apologize to any admin or maintainer who thought they had now fixed the problem.

[spoon0042]

It's fine, this stuff is actually interesting to me for whatever reason.

If it's working for you in stable, great. I don't remember if I tried stable or not but I can check. In theory any future wine-stable version should work but regressions happen. Though it seems like -devel should work too, I'll try that again.

[spoon0042]

Oh good, I got it to work. It seems there may be an issue with winetricks where I'm not clear on which dlls should have an override set. Don't worry about that though unless in the future you have a problem again that would be useful information.

odbccp32 native,builtin
msado15 not set