On 03/05/14 21:00, map...@users.sourceforge.net wrote:
> ---
> make init script writeable by the root user
>
> Modified Paths:
> --
> firebird/trunk/builds/install/arch-specific/linux/linuxLibrary.sh.in
>
> Modified: firebird/trunk/builds/install/arch-specific/linux/linuxLi
root can change everything but file is read only for root
all the other init scripts are rwx for root
-rwxr-xr-x
On Thu, Mar 6, 2014 at 11:09 AM, Alex Peshkoff wrote:
> On 03/05/14 21:00, map...@users.sourceforge.net wrote:
>> ---
>> make init script writeable by the root user
>>
>> Mod
On 03/06/14 13:21, marius adrian popa wrote:
> root can change everything but file is read only for root
As long as root can change everything it does not matter that file is RO.
> all the other init scripts are rwx for root
>
> -rwxr-xr-x
Well, from this POV I can agree...
---
I had to do quick changes to it and i was annoyed to chmod on each
time i did an make install
Anyway we will have more changes to init scripts : next
Ubuntu/Debian versions will switch to system.d as default
On Thu, Mar 6, 2014 at 11:28 AM, Alex Peshkoff wrote:
> On 03/06/14 13:21, marius adri
On 03/06/14 13:49, marius adrian popa wrote:
> I had to do quick changes to it and i was annoyed to chmod on each
> time i did an make install
I do not know what editor are you using, with mcedit I have no problems
changing RO files as root.
> Anyway we will have more changes to init scripts :
Le 06/03/14 10:59, Alex Peshkoff a écrit :
> On 03/06/14 13:49, marius adrian popa wrote:
>> Anyway we will have more changes to init scripts : next
>> Ubuntu/Debian versions will switch to system.d as default
>>
>
> We are ready in trunk.
also for 2.5 in Fedora and Mageia
> BTW, did they really
2014-03-06 13:59 GMT+04:00 Alex Peshkoff :
> BTW, did they really make a solution? I remember there was very active
> discussion re switch to systemd.
AFAIK They decided to use systemd especially for Linux based systems.
--
Roman Simakov
-
Hello, All.
I think that detailed error diagnostics is useful in release build too.
Actually, it is
even more useful there because release build is used by bigger number of
application
developers. So, I suggest to remove ifdefs there.
Opinions?
--
WBR, SD.
--
On 03/06/14 18:27, Dimitry Sibiryakov wrote:
> Hello, All.
>
> I think that detailed error diagnostics is useful in release build too.
> Actually, it is
> even more useful there because release build is used by bigger number of
> application
> developers. So, I suggest to remove ifdefs th
06.03.2014 16:21, Alex Peshkoff wrote:
> BTW, when using new interface message about bad SQLDA looks silly.
> Who has an idea what to do with it?
Replace them with complaints about BLR. I'll prepare another version of path
which
should solve the rest.
--
WBR, SD.
---
On 03/06/14 19:30, Dimitry Sibiryakov wrote:
> 06.03.2014 16:21, Alex Peshkoff wrote:
>> BTW, when using new interface message about bad SQLDA looks silly.
>> Who has an idea what to do with it?
> Replace them with complaints about BLR.
Also far from ideal. Average user may does not know what
06.03.2014 16:39, Alex Peshkoff wrote:
> Also far from ideal. Average user may does not know what is BLR.
That's why average user should forward error messages to application
developers who
used messages API and know what BLR is.
> Something like invalid format of requested from server data
On 03/06/14 19:45, Dimitry Sibiryakov wrote:
> 06.03.2014 16:39, Alex Peshkoff wrote:
>> Also far from ideal. Average user may does not know what is BLR.
> That's why average user should forward error messages to application
> developers who
> used messages API and know what BLR is.
Sorry, un
06.03.2014 16:53, Alex Peshkoff wrote:
> Sorry, under average user I've meant average developer...
MetadataFromBlr is used in old message API only. Is developer don't use this
API, he
won't get these error messages.
--
WBR, SD.
---
On 3/6/2014 10:39 AM, Alex Peshkoff wrote:
> On 03/06/14 19:30, Dimitry Sibiryakov wrote:
>> 06.03.2014 16:21, Alex Peshkoff wrote:
>>> BTW, when using new interface message about bad SQLDA looks silly.
>>> Who has an idea what to do with it?
>> Replace them with complaints about BLR.
> Also f
On 03/06/14 20:00, Dimitry Sibiryakov wrote:
> 06.03.2014 16:53, Alex Peshkoff wrote:
>> Sorry, under average user I've meant average developer...
> MetadataFromBlr is used in old message API only. Is developer don't use
> this API, he
> won't get these error messages.
>
It's also used when c
06.03.2014 17:25, Alex Peshkoff wrote:
> I must say that with correctly working Sqlda->BLR converter
Actually, this is exactly thing that I'm going to kill.
--
WBR, SD.
--
Subversion Kills Productivity. Get off Su
On 03/06/14 20:31, Dimitry Sibiryakov wrote:
> 06.03.2014 17:25, Alex Peshkoff wrote:
>> I must say that with correctly working Sqlda->BLR converter
> Actually, this is exactly thing that I'm going to kill.
>
Yes, as soon as we stop to call BLR-oriented functions to implement
SQLDA-oriented A
Many error messages are not enough descriptive for the application's
developer.
By example, when trying to save a row: "data truncated" is not enough. We
have no idea which is the field problematic and the table can have 20, 30,
40 or more fields. So, we need to look each field, one for one, until
Title: Re: [Firebird-devel] MetadataFromBlr diagnostics
Btw, I would like to have the ability of customizing the error message of check constraints and foreign keys violations.
There is a ticket open for this yet.
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
06.03.2014 17:39, Alex Peshkoff wrote:
> Yes, as soon as we stop to call BLR-oriented functions to implement
> SQLDA-oriented API calls converting Sqlda->BLR->IMessageMetadata instead
> Sqlda->IMessageMetadata directly makes absolutely no sense.
Funny things I see in current sources: sqlda is c
21 matches
Mail list logo
