Re: Call to help testing osb for backward compatibility

[gbWilly <gbWilly@xxxxxxxxxxxxxx>]

gbWilly

Gambas3 for Debian

Sent with Proton Mail secure email.

On Saturday, December 21st, 2024 at 05:58, T Lee Davidson <t.lee.davidson@xxxxxxxxx> wrote:

> On 12/20/24 17:02, Benoît Minisini wrote:
> 
> > Le 20/12/2024 à 22:42, Benoît Minisini a écrit :
> > 
> > > Le 20/12/2024 à 22:25, T Lee Davidson a écrit :
> > > 
> > > > I have no idea what this means or how it might be fixed as I have never used a rolling release, nor an Arch, distribution.
> > > > Note: I was given an option to choose the source for qt-webview (gtk, qt5, or qt6). I chose qt6-webview.
> > > 
> > > The 'gb.hash' component must not have its own package, it must be included inside the 'gambas3-runtime' component.
> > > 
> > > I must tell PKGBUILD that now 'gambas3-runtime' replaces 'gambas3-gb- hash'. I think I know how to do that according to the
> > > current PKGBUILD content. I will do that as soon as possible so that you can check if I am right!
> > 
> > I have updated the configuration files, you can try again in about 15 minutes when the new packages are build.
> > 

Ah, Benoit is on it and it seems he's becoming a master chef at recipe making in his 'cuisine'...
 
> Aha, this time it told me it needed to remove gambas3-gb-hash because it conflicts with gambas3-runtime. And, the update
> appeared to proceed just fine. (I did have to manually install gambas3-gb-qt5-ext to get a project with a dial control to open
> and run.) The installation package depending on gb.qt5.ext requested by gbWilly also installed and executed correctly.

Good the gb-hash problem can be that easily solved. That means this can be applied in the debian recipe as well as some of the same is causing trouble on upgrading from official (see my previous reply)

> 
> BTW, when I made the installation package (Project -> Make installation package...) for Arch, I was able to select Arch at step
> 
> "3. Target distribution". But, at "10. Create package", the package build failed because it couldn't find the "fakeroot" binary.
> Shouldn't that be caught at Step 3?

I have no idea on how inner package dependencies for Arch work, but I guess adding fakeroot as dependency should solve this.
On debian it is recommended as part of dpkg-dev that is a dependency of build-essentials that is a dependency of gambas3.
Arch might have inner dependencies different for their disto and maybe build-essentials doesn't provide fakeroot?

gbWilly