firebird-devel — List for general discussion among IB developers

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Alex P. <pes...@ma...>]

On 9/5/22 12:59, Mark Rotteveel wrote:
> On 05-09-2022 11:50, Alex Peshkoff via Firebird-devel wrote:
>> On 9/5/22 12:31, Mark Rotteveel wrote:
>>> On 05-09-2022 11:23, Alex Peshkoff via Firebird-devel wrote:
>>>> This is solved by install script - it creates symlink to 
>>>> /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory 
>>>> (provided it's missing).
>>>> That's done this way in order to make it possible to use system 
>>>> tommath when present.
>>>
>>> That is inconsistent compared to what is done for 
>>> --with-builtin-tomcrypt. I explicitly requested 
>>> --with-builtin-tommath, so I expect it to end up directly in the lib 
>>> directory like tomcrypt.
>>
>> This switch works another way.
>
> It seems to me it does the same thing, but for a different library, so 
> why does it do so in an entirely different way?

I do not know what library do you talk about.
There are many of them - and rules for them vary slightly.

>
>>> If I understand you correctly, I will need to massage what I have in 
>>> buildroot even further to get a usable build. I won't be using the 
>>> install script, because I don't want to install it, I want to 
>>> package it for an embedded deployment.
>>
>> Yes, you need to change something not suitable for embedded, I even 
>> expect you to add configure switch for it - we never deployed FB for 
>> linux w/o install script.
>
> We'll see, if I can find the motivation and energy to figure this out.
>

If you just shell scripts and send me changes I can do the rest myself...

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Mark R. <ma...@la...>]

On 05-09-2022 11:50, Alex Peshkoff via Firebird-devel wrote:
> On 9/5/22 12:31, Mark Rotteveel wrote:
>> On 05-09-2022 11:23, Alex Peshkoff via Firebird-devel wrote:
>>> This is solved by install script - it creates symlink to 
>>> /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory 
>>> (provided it's missing).
>>> That's done this way in order to make it possible to use system 
>>> tommath when present.
>>
>> That is inconsistent compared to what is done for 
>> --with-builtin-tomcrypt. I explicitly requested 
>> --with-builtin-tommath, so I expect it to end up directly in the lib 
>> directory like tomcrypt.
> 
> This switch works another way.

It seems to me it does the same thing, but for a different library, so 
why does it do so in an entirely different way?

>> If I understand you correctly, I will need to massage what I have in 
>> buildroot even further to get a usable build. I won't be using the 
>> install script, because I don't want to install it, I want to package 
>> it for an embedded deployment.
> 
> Yes, you need to change something not suitable for embedded, I even 
> expect you to add configure switch for it - we never deployed FB for 
> linux w/o install script.

We'll see, if I can find the motivation and energy to figure this out.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Alex P. <pes...@ma...>]

On 9/5/22 12:31, Mark Rotteveel wrote:
> On 05-09-2022 11:23, Alex Peshkoff via Firebird-devel wrote:
>> This is solved by install script - it creates symlink to 
>> /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory 
>> (provided it's missing).
>> That's done this way in order to make it possible to use system 
>> tommath when present.
>
> That is inconsistent compared to what is done for 
> --with-builtin-tomcrypt. I explicitly requested 
> --with-builtin-tommath, so I expect it to end up directly in the lib 
> directory like tomcrypt.

This switch works another way.

>
> If I understand you correctly, I will need to massage what I have in 
> buildroot even further to get a usable build. I won't be using the 
> install script, because I don't want to install it, I want to package 
> it for an embedded deployment.
>

Yes, you need to change something not suitable for embedded, I even 
expect you to add configure switch for it - we never deployed FB for 
linux w/o install script.

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Mark R. <ma...@la...>]

On 05-09-2022 11:23, Alex Peshkoff via Firebird-devel wrote:
> This is solved by install script - it creates symlink to 
> /inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory 
> (provided it's missing).
> That's done this way in order to make it possible to use system tommath 
> when present.

That is inconsistent compared to what is done for 
--with-builtin-tomcrypt. I explicitly requested --with-builtin-tommath, 
so I expect it to end up directly in the lib directory like tomcrypt.

If I understand you correctly, I will need to massage what I have in 
buildroot even further to get a usable build. I won't be using the 
install script, because I don't want to install it, I want to package it 
for an embedded deployment.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Alex P. <pes...@ma...>]

On 9/3/22 16:12, Mark Rotteveel wrote:
> I'm investigating ways of packaging Firebird Embedded for Java, so it 
> can be used as drop-in Java library (which is then unpacked to a 
> temporary directory automatically).
>
> Given Firebird complains about missing libtommath when I use the 
> normal build, and I don't want to impose on users to install 
> additional libraries, I tried a custom build (from current state of 
> v4.0-release branch) with:
>
> ./autogen.sh --with-builtin-tommath --with-builtin-tomcrypt 
> --enable-binreloc
> make
> make dist
>
> I have a problem with libtommath in this build:
>
> gen/buildroot/usr/local/firebird/lib contains libtomcrypt.so.1.0.1 
> (and symlinks libtomcrypt.so and libtomcrypt.so.1), but no libtommath 
> files, these are in a .tm subdirectory of lib, so
>
> gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so.0
> gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so.0.0.41
> gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so
>
> I would have expected these files directly in 
> gen/buildroot/usr/local/firebird/lib/, not in 
> gen/buildroot/usr/local/firebird/lib/.tm/. Trying to load embedded 
> this way complains about missing libtommath.
>

This is solved by install script - it creates symlink to 
/inst/path/firebird/lib/.tm/libtommath.so.0 in system lib directory 
(provided it's missing).
That's done this way in order to make it possible to use system tommath 
when present.

Re: [Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Norbert S. G. <ns...@te...>]

> What is wrong here? Did I miss a configuration option somewhere? Is this a 
> bug in the build?
>
> Mark

Hi,
Personally, I compile git sources on centos/rocky by installing the 
lib's below otherwise it generates errors.


dnf config-manager --set-enabled crb

dnf upgrade -y
cd /
mkdir git
cd git
dnf install wget git -y
git clone https://github.com/FirebirdSQL/firebird.git

dnf install unzip m4 autoconf automake libtool libtool-ltdl icu libicu 
libicu-devel sed libtommath libtommath-devel libtomcrypt 
libtomcrypt-devel ncurses ncurses-devel gcc-c++ libstdc++ 
libstdc++-devel libtommath libtommath-devel glibc-static 
libstdc++-static libtool-ltdl-devel zlib zlib-devel -y

cd firebird

bla bla

-- 
Norbert Saint Georges
http://tetrasys.fi

[Firebird-devel] Building Firebird Linux with --with-builtin-tommath

[Mark R. <ma...@la...>]

I'm investigating ways of packaging Firebird Embedded for Java, so it 
can be used as drop-in Java library (which is then unpacked to a 
temporary directory automatically).

Given Firebird complains about missing libtommath when I use the normal 
build, and I don't want to impose on users to install additional 
libraries, I tried a custom build (from current state of v4.0-release 
branch) with:

./autogen.sh --with-builtin-tommath --with-builtin-tomcrypt 
--enable-binreloc
make
make dist

I have a problem with libtommath in this build:

gen/buildroot/usr/local/firebird/lib contains libtomcrypt.so.1.0.1 (and 
symlinks libtomcrypt.so and libtomcrypt.so.1), but no libtommath files, 
these are in a .tm subdirectory of lib, so

gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so.0
gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so.0.0.41
gen/buildroot/usr/local/firebird/lib/.tm/libtommath.so

I would have expected these files directly in 
gen/buildroot/usr/local/firebird/lib/, not in 
gen/buildroot/usr/local/firebird/lib/.tm/. Trying to load embedded this 
way complains about missing libtommath.

Copying those files/symlinks from .tm to the parent directory allows 
embedded to be loaded.

What is wrong here? Did I miss a configuration option somewhere? Is this 
a bug in the build?

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Service errors returned by API

[Alex P. <pes...@ma...>]

On 8/25/22 21:52, Dimitry Sibiryakov wrote:

> Perhaps warnings should be returned both ways: the binary form in 
> status and duplicate text in output. In this case applications will 
> get them as usual and advanced ones may be interested in parsing status.
>

I will look at what can be done here. Putting warnings (if any) into 
status vector is definitely not a problem, duplicating them into text 
output too, what may be not trivial is messages currently printed by 
burp-like services to stdX.

>
>> Certainly we may require analyzing warnings from clients who want to 
>> receive verbose messages in machine-readable form. Is it what you want?
>
>   Rather no. As written above - messages belong to (one of) output 
> streams (I believe services API should be able to deliver multiple 
> streams in parallel: messages and binary stream for backup as an 
> example).
>

I was thinking about it. Suppose adding N buffers for stream data 
instead current one should not be too hard to do. But what about API for 
that, format of data sent to user, etc. - that should be well though 
before starting with this.

Re: [Firebird-devel] Version info item filling on the way

[James S. <ji...@ji...>]

Yes

On Sat, Aug 27, 2022 at 10:45 AM Dimitry Sibiryakov <sd...@ib...>
wrote:

>    Hello All,
>
>    currently isc_info_firebird_version is formed from engine version,
> server
> version and remote provider version.
>    I wonder if there should be also the Y-valve version in addition to all
> that
> in the case if third-party network provider is used.
>    An example:
>
> ISQL Version: WI-T5.0.0.550 Firebird 5.0 Initial
> Server version:
> WI-V4.0.1.2631 Firebird 4.0
> FireSwarm server 0.3-Devel
> FireSwarm client 0.3-Devel
> ===> here fbclient's version is missed <===
>
> --
>    WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
-- 
Jim Starkey

Re: [Firebird-devel] Version info item filling on the way

[Dimitry S. <sd...@ib...>]

Dimitry Sibiryakov wrote 27.08.2022 16:45:
> ISQL Version: WI-T5.0.0.550 Firebird 5.0 Initial Server version: WI-V4.0.1.2631 
> Firebird 4.0 FireSwarm server 0.3-Devel FireSwarm client 0.3-Devel
> ===> here fbclient's version is missed <===
> 

   Oops, formatting has been screwed. It should be like this:

ISQL Version: WI-T5.0.0.550 Firebird 5.0 Initial
Server version: WI-V4.0.1.2631 Firebird 4.0
FireSwarm server 0.3-Devel
FireSwarm client 0.3-Devel
=== here fbclient's version is missed ===

-- 
   WBR, SD.

[Firebird-devel] Version info item filling on the way

[Dimitry S. <sd...@ib...>]

   Hello All,

   currently isc_info_firebird_version is formed from engine version, server 
version and remote provider version.
   I wonder if there should be also the Y-valve version in addition to all that 
in the case if third-party network provider is used.
   An example:

ISQL Version: WI-T5.0.0.550 Firebird 5.0 Initial 
Server version: 
WI-V4.0.1.2631 Firebird 4.0 
FireSwarm server 0.3-Devel 
FireSwarm client 0.3-Devel
===> here fbclient's version is missed <===

-- 
   WBR, SD.

Re: [Firebird-devel] Service errors returned by API

[Dimitry S. <sd...@ib...>]

Alex Peshkoff via Firebird-devel wrote 25.08.2022 10:27:
> But here are some problems:
> - An error when querying service is treated by 99% of callers (starting with 
> fbsvcmgr) as fatal one. Other errors will not be displayed.

   And it is the right way to handle them, IMHO.

> - What about warnings - yes, they probably may be used at the first glance. But 
> once again big problems with old clients. What should return isc_service_query - 
> success or failure? On failure one prints status and detachs from service, on 
> success - ignores SV.

   Wasn't it always the way warnings were working: success in function result 
and requirement to parse vector to get them?..
   Perhaps warnings should be returned both ways: the binary form in status and 
duplicate text in output. In this case applications will get them as usual and 
advanced ones may be interested in parsing status.

> - Verbose messages are already passed through isc_svc_query().

   That's what they belongs to.

> Certainly we may require analyzing warnings from clients who want to receive 
> verbose messages in machine-readable form. Is it what you want?

   Rather no. As written above - messages belong to (one of) output streams (I 
believe services API should be able to deliver multiple streams in parallel: 
messages and binary stream for backup as an example).

-- 
   WBR, SD.

Re: [Firebird-devel] Improve release filenames

[Jiří Č. <ji...@ci...>]

> As the Intel platforms will be the *huge* majority, what about this:
>
> win32 | win64 |win64-arm
>
> or this:
>
> win32-x86 | win64-x86 | win64-arm
>
> or just:
>
> win32 | win64-x86 | win64-arm

That seems pretty inconsistent (in regards to other filenames).

-- 
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

Re: [Firebird-devel] Improve release filenames

[Mark R. <ma...@la...>]

On 25-08-2022 15:13, Stefan Heymann wrote:
>> I propose this name convention starting with Firebird 5:
> 
>> Firebird-5.0.0.2816-0-windows-x86-pdb.exe
>> Firebird-5.0.0.2816-0-windows-x86-pdb.zip
>> Firebird-5.0.0.2816-0-windows-x86.exe
>> Firebird-5.0.0.2816-0-windows-x86.zip
>> Firebird-5.0.0.2816-0-windows-x64-pdb.exe
>> Firebird-5.0.0.2816-0-windows-x64-pdb.zip
>> Firebird-5.0.0.2816-0-windows-x64.exe
>> Firebird-5.0.0.2816-0-windows-x64.zip
>> [...]
> 
> I'd like to suggest you use win32 and win64 instead of x86 and x64. Or, it you want to keep the "windows" prefix, use window-32 and windows-64.
> 
> For me as a Windows user this would be much more logical (the 86 comes from the 80*86 processor, the 64 comes from 64 bits, so it's not consistent from the beginning).

The proposed naming has the benefit it is consistent across platforms. 
That is:
Firebird-<version>-<os-family>-<target-cpu>[-qualifier].

I don't see the need, nor the point to deviate from this for Windows.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Improve release filenames

[Stefan H. <li...@st...>]

>> > I'd like to suggest you use win32 and win64 instead of x86 and x64. Or, it you want to keep the "windows" prefix, use window-32 and windows-64.
>> > For me as a Windows user this would be much more logical (the 86 comes from the 80*86 processor, the 64 comes from 64 bits, so it's not consistent from the beginning).


> In the past win32 and win64 was good but now Windows exists for ARM64.
> x86, x(86-)64, arm64, etc. are more clear. But I am not a core developer just a user. :-)

As the Intel platforms will be the *huge* majority, what about this:

win32 | win64 |win64-arm

or this:

win32-x86 | win64-x86 | win64-arm

or just:

win32 | win64-x86 | win64-arm


Regards

Stefan

Re: [Firebird-devel] Improve release filenames

[Jiří Č. <ji...@ci...>]

> In the past win32 and win64 was good but now Windows exists for ARM64.
> x86, x(86-)64, arm64, etc. are more clear. But I am not a core developer 
> just a user. :-)

Same for me.

-- 
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/

Re: [Firebird-devel] Improve release filenames

[Gabor B. <mln...@bg...>]

2022.08.25. 15:13 keltezéssel, Stefan Heymann írta:
> 
> I'd like to suggest you use win32 and win64 instead of x86 and x64. Or, it you want to keep the "windows" prefix, use window-32 and windows-64.
> 
> For me as a Windows user this would be much more logical (the 86 comes from the 80*86 processor, the 64 comes from 64 bits, so it's not consistent from the beginning).


In the past win32 and win64 was good but now Windows exists for ARM64.
x86, x(86-)64, arm64, etc. are more clear. But I am not a core developer 
just a user. :-)

Gabor

Re: [Firebird-devel] Improve release filenames

[Stefan H. <li...@st...>]

> I propose this name convention starting with Firebird 5:

> Firebird-5.0.0.2816-0-windows-x86-pdb.exe
> Firebird-5.0.0.2816-0-windows-x86-pdb.zip
> Firebird-5.0.0.2816-0-windows-x86.exe
> Firebird-5.0.0.2816-0-windows-x86.zip
> Firebird-5.0.0.2816-0-windows-x64-pdb.exe
> Firebird-5.0.0.2816-0-windows-x64-pdb.zip
> Firebird-5.0.0.2816-0-windows-x64.exe
> Firebird-5.0.0.2816-0-windows-x64.zip
> [...]

I'd like to suggest you use win32 and win64 instead of x86 and x64. Or, it you want to keep the "windows" prefix, use window-32 and windows-64.

For me as a Windows user this would be much more logical (the 86 comes from the 80*86 processor, the 64 comes from 64 bits, so it's not consistent from the beginning).


Best Regards

Stefan



-- 
Stefan Heymann, Tübingen, Germany

Re: [Firebird-devel] Improve release filenames

[Mark R. <ma...@la...>]

On 25-08-2022 12:38, Dimitry Sibiryakov wrote:
> Dmitry Yemanov wrote 25.08.2022 12:34:
>>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe
>>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip
>>> Firebird-5.0.0.2816-0-windows-x86.exe
>>> Firebird-5.0.0.2816-0-windows-x86.zip
>>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.exe
>>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.zip
>>> Firebird-5.0.0.2816-0-windows-x64.exe
>>> Firebird-5.0.0.2816-0-windows-x64.zip
>>> Firebird-5.0.0.2816-0-linux-x64.tar.gz
>>> Firebird-5.0.0.2816-0-linux-x64-debugSymbols.tar.gz
>>> Firebird-5.0.0.2816-0-android-arm.tar.gz (armv7, other?)
>>> Firebird-5.0.0.2816-0-android-arm-withDebugSymbols.tar.gz
>>> Firebird-5.0.0.2816-0-android-arm64.tar.gz
>>> Firebird-5.0.0.2816-0-android-arm64-withDebugSymbols.tar.gz
>>> Firebird-5.0.0.2816-0-linux-x86.tar.gz
>>> Firebird-5.0.0.2816-0-linux-x86-debugSymbols.tar.gz
>>> Firebird-5.0.0.2816-0-source.tar.xz
>>> Firebird-5.0.0.2816-0-macos-x64.pkg
>>
>> Looks good to me.
> 
>    Is this zero after build number necessary?

We have had -1 releases, e.g. 
https://firebirdsql.org/en/firebird-4-0-0/#Win32 
(Firebird-4.0.0.2496-1-Win32.exe), so for consistency, either it should 
always be included, or we should ditch this package revision (or 
whatever we should call it) entirely.

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Improve release filenames

[Adriano d. S. F. <adr...@gm...>]

On 25/08/2022 07:38, Dimitry Sibiryakov wrote:
> 
>   Is this zero after build number necessary?
> 

It's packaging number.

We had this type of problem in Windows build in the past, where retag
was not necessary and the package number was increased.


Adriano

Re: [Firebird-devel] Improve release filenames

[Dimitry S. <sd...@ib...>]

Dmitry Yemanov wrote 25.08.2022 12:34:
>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe
>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip
>> Firebird-5.0.0.2816-0-windows-x86.exe
>> Firebird-5.0.0.2816-0-windows-x86.zip
>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.exe
>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.zip
>> Firebird-5.0.0.2816-0-windows-x64.exe
>> Firebird-5.0.0.2816-0-windows-x64.zip
>> Firebird-5.0.0.2816-0-linux-x64.tar.gz
>> Firebird-5.0.0.2816-0-linux-x64-debugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-android-arm.tar.gz (armv7, other?)
>> Firebird-5.0.0.2816-0-android-arm-withDebugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-android-arm64.tar.gz
>> Firebird-5.0.0.2816-0-android-arm64-withDebugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-linux-x86.tar.gz
>> Firebird-5.0.0.2816-0-linux-x86-debugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-source.tar.xz
>> Firebird-5.0.0.2816-0-macos-x64.pkg
> 
> Looks good to me.

   Is this zero after build number necessary?

-- 
   WBR, SD.

Re: [Firebird-devel] Improve release filenames

[Adriano d. S. F. <adr...@gm...>]

On 25/08/2022 07:19, Mark Rotteveel wrote:
> On 25-08-2022 03:15, Adriano dos Santos Fernandes wrote:
>> On 24/08/2022 08:45, Adriano dos Santos Fernandes wrote:
>>>
>>> I propose this name convention starting with Firebird 5:
>>>
>>
>> Here is my updated proposal based on the discussion so far:
>>
>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe
>> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip
>> Firebird-5.0.0.2816-0-windows-x86.exe
>> Firebird-5.0.0.2816-0-windows-x86.zip
>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.exe
>> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.zip
>> Firebird-5.0.0.2816-0-windows-x64.exe
>> Firebird-5.0.0.2816-0-windows-x64.zip
>> Firebird-5.0.0.2816-0-linux-x64.tar.gz
>> Firebird-5.0.0.2816-0-linux-x64-debugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-android-arm.tar.gz (armv7, other?)
>> Firebird-5.0.0.2816-0-android-arm-withDebugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-android-arm64.tar.gz
>> Firebird-5.0.0.2816-0-android-arm64-withDebugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-linux-x86.tar.gz
>> Firebird-5.0.0.2816-0-linux-x86-debugSymbols.tar.gz
>> Firebird-5.0.0.2816-0-source.tar.xz
>> Firebird-5.0.0.2816-0-macos-x64.pkg
> 
> Sounds OK. On suggestion: use "with-debug-symbols" and "debug-symbols",
> but that is just because I'm a bit allergic to capitals in filenames ;)
> 

Me too, but I want to use dashes to separate components in this case,
and then it would be inconsistent have a single information spread into
multiple parts.


Adriano

Re: [Firebird-devel] Improve release filenames

[Dmitry Y. <fir...@ya...>]

25.08.2022 04:15, Adriano dos Santos Fernandes wrote:

> Here is my updated proposal based on the discussion so far:
> 
> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe
> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip
> Firebird-5.0.0.2816-0-windows-x86.exe
> Firebird-5.0.0.2816-0-windows-x86.zip
> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.exe
> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.zip
> Firebird-5.0.0.2816-0-windows-x64.exe
> Firebird-5.0.0.2816-0-windows-x64.zip
> Firebird-5.0.0.2816-0-linux-x64.tar.gz
> Firebird-5.0.0.2816-0-linux-x64-debugSymbols.tar.gz
> Firebird-5.0.0.2816-0-android-arm.tar.gz (armv7, other?)
> Firebird-5.0.0.2816-0-android-arm-withDebugSymbols.tar.gz
> Firebird-5.0.0.2816-0-android-arm64.tar.gz
> Firebird-5.0.0.2816-0-android-arm64-withDebugSymbols.tar.gz
> Firebird-5.0.0.2816-0-linux-x86.tar.gz
> Firebird-5.0.0.2816-0-linux-x86-debugSymbols.tar.gz
> Firebird-5.0.0.2816-0-source.tar.xz
> Firebird-5.0.0.2816-0-macos-x64.pkg

Looks good to me.


Dmitry

Re: [Firebird-devel] Improve release filenames

[Mark R. <ma...@la...>]

On 25-08-2022 03:15, Adriano dos Santos Fernandes wrote:
> On 24/08/2022 08:45, Adriano dos Santos Fernandes wrote:
>>
>> I propose this name convention starting with Firebird 5:
>>
> 
> Here is my updated proposal based on the discussion so far:
> 
> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.exe
> Firebird-5.0.0.2816-0-windows-x86-withDebugSymbols.zip
> Firebird-5.0.0.2816-0-windows-x86.exe
> Firebird-5.0.0.2816-0-windows-x86.zip
> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.exe
> Firebird-5.0.0.2816-0-windows-x64-withDebugSymbols.zip
> Firebird-5.0.0.2816-0-windows-x64.exe
> Firebird-5.0.0.2816-0-windows-x64.zip
> Firebird-5.0.0.2816-0-linux-x64.tar.gz
> Firebird-5.0.0.2816-0-linux-x64-debugSymbols.tar.gz
> Firebird-5.0.0.2816-0-android-arm.tar.gz (armv7, other?)
> Firebird-5.0.0.2816-0-android-arm-withDebugSymbols.tar.gz
> Firebird-5.0.0.2816-0-android-arm64.tar.gz
> Firebird-5.0.0.2816-0-android-arm64-withDebugSymbols.tar.gz
> Firebird-5.0.0.2816-0-linux-x86.tar.gz
> Firebird-5.0.0.2816-0-linux-x86-debugSymbols.tar.gz
> Firebird-5.0.0.2816-0-source.tar.xz
> Firebird-5.0.0.2816-0-macos-x64.pkg

Sounds OK. On suggestion: use "with-debug-symbols" and "debug-symbols", 
but that is just because I'm a bit allergic to capitals in filenames ;)

Mark
-- 
Mark Rotteveel

Re: [Firebird-devel] Service errors returned by API (was: [FirebirdSQL/firebird] [FR] Database restore must make every effort on activating deferred indexes (Issue #7269))

[Alex P. <pes...@ma...>]

On 8/24/22 20:59, Dimitry Sibiryakov wrote:
> Alexander Peshkov wrote 24.08.2022 19:06:
>> On 8/24/22 14:31, Dimitry Sibiryakov wrote:
>>  > Without it services seem to be pretty useless.
>>
>> I think this to be suggested in devel and if nobody sees problems - feel
>> free to add a ticket, I will implement it.
>
>   Ok. But I don't think that a simple hack returning only thread exit 
> code is a right way to go.

If I was thinking that way that feature could be present since 2. 5 :-)

>
>> Notice - in status vector it will be a notice that service thread failed
>> with exit code NNN, original message with a reason for is unknown at the
>> final point.
>
>   It is not quite try.
>   In the old dark days when the service thread just run an external 
> utility and mindlessly redirect whole output to the client it was so. 
> But nowadays the thread is doing whole work itself 

Just small notice - an ability to return errors in SV does not directly 
depend upon does service run as a process or as a thread. It's possible 
to pass SV cross-process but nobody cared about. With service threads 
pre-2.5 it was a mix - some errors were returned as SV, some - as text 
lines.

> so it can return a proper errors, warnings and verbose messages 
> through isc_svc_query() as soon as they happen.

But here are some problems:
- An error when querying service is treated by 99% of callers (starting 
with fbsvcmgr) as fatal one. Other errors will not be displayed.
- What about warnings - yes, they probably may be used at the first 
glance. But once again big problems with old clients. What should return 
isc_service_query - success or failure? On failure one prints status and 
detachs from service, on success - ignores SV.
- Verbose messages are already passed through isc_svc_query().

Certainly we may require analyzing warnings from clients who want to 
receive verbose messages in machine-readable form. Is it what you want?