Qt-interest Archive, December 2006
4.2.2 Build Failure
Pages: Prev | 1 | 2 | Next
Message 1 in thread
Attempt to build qt 4.2.2 on AMD 64-bit OpenBSD 3.9 failed with the following errors:
cd src && gmake -f Makefile
gmake[1]: Entering directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src'
cd tools/moc && gmake -f Makefile
gmake[2]: Entering directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/moc'
gmake[2]: Nothing to be done for `first'.
gmake[2]: Leaving directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/moc'
cd tools/rcc && gmake -f Makefile
gmake[2]: Entering directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/rcc'
gmake[2]: Nothing to be done for `first'.
gmake[2]: Leaving directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/rcc'
cd tools/uic && gmake -f Makefile
gmake[2]: Entering directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/uic'
gmake[2]: Nothing to be done for `first'.
gmake[2]: Leaving directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/tools/uic'
cd corelib && gmake -f Makefile
gmake[2]: Entering directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/corelib'
g++ -c -pipe -g -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -Wall -W -pthread -fPIC -DQT_SHARED -DQT_BUILD_CORE_LIB -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DGNU_LIBICONV -DQT_NO_DEBUG -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/openbsd-g++ -I. -I../../include -I../../include/QtCore -Iglobal -I.moc/release-shared -I.uic/release-shared -I/usr/local/include -o .obj/release-shared/qfsfileengine_unix.o io/qfsfileengine_unix.cpp
io/qfsfileengine_unix.cpp: In member function `virtual QString
QFSFileEngine::owner(QAbstractFileEngine::FileOwner) const':
io/qfsfileengine_unix.cpp:584: error: `_SC_GETPW_R_SIZE_MAX' undeclared (first
use this function)
io/qfsfileengine_unix.cpp:584: error: (Each undeclared identifier is reported
only once for each function it appears in.)
io/qfsfileengine_unix.cpp:591: error: `getpwuid_r' undeclared (first use this
function)
io/qfsfileengine_unix.cpp:600: error: `_SC_GETGR_R_SIZE_MAX' undeclared (first
use this function)
gmake[2]: *** [.obj/release-shared/qfsfileengine_unix.o] Error 1
gmake[2]: Target `first' not remade because of errors.
gmake[2]: Leaving directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src/corelib'
gmake[1]: *** [sub-corelib-make_default] Error 2
gmake[1]: Target `first' not remade because of errors.
gmake[1]: Leaving directory `/home/daf/QT/qt-x11-opensource-src-4.2.2/src'
gmake: *** [sub-src-make_default-ordered] Error 2
gmake: Target `first' not remade because of errors.
Dave Feustel
--
[ signature omitted ]
Message 2 in thread
Hi,
> Attempt to build qt 4.2.2 on AMD 64-bit OpenBSD 3.9 failed with the following errors:
This looks like a bug in OpenBSD. Have a look at this thread about Qt
4.1.4 for example:
http://lists.trolltech.com/qt-interest/2006-08/thread00717-0.html
Did you contact Trolltech as suggested in this thread? If you don't bugs
can't get fixed.
--
[ signature omitted ]
Message 3 in thread
> Hi,
>
> > Attempt to build qt 4.2.2 on AMD 64-bit OpenBSD 3.9 failed with the following errors:
>
> This looks like a bug in OpenBSD. Have a look at this thread about Qt
> 4.1.4 for example:
> http://lists.trolltech.com/qt-interest/2006-08/thread00717-0.html
>
> Did you contact Trolltech as suggested in this thread?
I tried but did not succeed in getting a bug report filed.
> If you don't bugs can't get fixed.
> --
> Dimitri
--
[ signature omitted ]
Message 4 in thread
Hi,
> I tried but did not succeed in getting a bug report filed.
What did you try? This page?
http://www.trolltech.com/bugreport-form
--
[ signature omitted ]
Message 5 in thread
> Hi,
>
> > I tried but did not succeed in getting a bug report filed.
>
> What did you try? This page?
>
> --
> Dimitri
I tried to file a bug report at bugs.kde.org.
It didn't work. I gave up. This because it is clear to me from
previous battles to get KDE/Qt bugs relating to OpenBSD platform
fixed, that neither kde, qt nor OpenBSD developers really want to
hear about these bugs. I really should stop posting about bugs
I find since I am now officially retired and no longer have
energy or desire to follow through with official bug reports
of OpenBSD/KDE/Qt problems. Finding bug work-arounds is soo much
simpler for me.
--
[ signature omitted ]
Message 6 in thread
Hi,
> I tried to file a bug report at bugs.kde.org.
This is for KDE bugs, not Qt bugs. The KDE team do not write the Qt
software so they can't fix Qt bugs.
> It didn't work. I gave up. This because it is clear to me from
> previous battles to get KDE/Qt bugs relating to OpenBSD platform
This is a misunderstanding. There is no such Qt/KDE entity. There are
programmers writing KDE, and progammers writing Qt. You have to contact
the right people.
> fixed, that neither kde, qt nor OpenBSD developers really want to
> hear about these bugs. I really should stop posting about bugs
> I find since I am now officially retired and no longer have
> energy or desire to follow through with official bug reports
> of OpenBSD/KDE/Qt problems. Finding bug work-arounds is soo much
> simpler for me.
I don't understand. I've always answered your postings, Qt bugs have
been fixed, and OpenBSD bugs have been worked around.
It looks like you expect bugs to be fixed auto-magically. In case you
haven't noticed, software is still written by humans, not robots nor
gods. They have limited time and possibly different priorities. You need
to talk to them and explain to them. In short, you do have to spend some
minimal time filing bug reports if you want them fixed. Just like you
have to spend some time talking to a mechanic to get your car fixed.
--
[ signature omitted ]
Message 7 in thread
On 04.12.06 01:03:22, dfeustel@xxxxxxxxxxxxxx wrote:
> > Hi,
> >
> > > I tried but did not succeed in getting a bug report filed.
> >
> > What did you try? This page?
> >
> > --
> > Dimitri
>
> I tried to file a bug report at bugs.kde.org.
>
> It didn't work.
Thats really weird. It has worked for since ages and it never didn't
work, except when the server was unavailable.
> This because it is clear to me from
> previous battles to get KDE
I remember those mails on kde-devel, and I think you give the wrong
picture here. The kde developers always kindly asked you to give more
precise information or to exactly explain why this or that is a secuirty
hazard (which is what most of your messages where about). At some point
it was clear that you weren't talking about things you really know in
depth, so they gave up. You were also told that some of the things, are
not fixable in KDE and thus you talked to the wrong people.
> Qt bugs relating to OpenBSD platform
Qt is totally unrelated to KDE, except that KDE builds on it and gives
input to TT (partly by filing bugreports) on what they'd like to have
(because KDE is one of the biggest projects building on top of Qt). So
if you have problems with Qt talk to Trolltech.
> fixed, that neither kde, qt nor OpenBSD developers really want to
> hear about these bugs.
As I explained above, from an outside point of view quite some of your
mails were totally unrelated to KDE, some security hazards were just
misunderstandings of the functionality by you.
> I really should stop posting about bugs
> I find since I am now officially retired and no longer have
> energy or desire
If you decide to not write any bugs anymore, thats no problem. But
please stop blaming other people for not caring about bugs you don't
report.
Andreas
--
[ signature omitted ]
Message 8 in thread
> On 04.12.06 01:03:22, dfeustel@xxxxxxxxxxxxxx wrote:
> > > Hi,
> > >
> > > > I tried but did not succeed in getting a bug report filed.
> > >
> > > What did you try? This page?
> > >
> > > --
> > > Dimitri
> >
> > I tried to file a bug report at bugs.kde.org.
> >
> > It didn't work.
>
> Thats really weird. It has worked for since ages and it never didn't
> work, except when the server was unavailable.
>
> > This because it is clear to me from
> > previous battles to get KDE
>
> I remember those mails on kde-devel, and I think you give the wrong
> picture here. The kde developers always kindly asked you to give more
> precise information or to exactly explain why this or that is a secuirty
> hazard (which is what most of your messages where about). At some point
> it was clear that you weren't talking about things you really know in
> depth, so they gave up. You were also told that some of the things, are
> not fixable in KDE and thus you talked to the wrong people.
I disagree with your characterisation here. The bug I am referring
to was the failure of KDE in the OpenBSD port to properly set
permissions for pttys allocated to processes running in KDE. This
problem was obvious when one examined the permissions of the allocated
ptty devices. I became aware of this problem as a result of reading
error messages in the KDE error log output.
This security flaw turned out to be the result of changes made to
the KDE software by the person doing the port to OpenBSD. This bug
was only partially fixed the last time I checked. I agree that I
did not then and still don't understand exactly how pttys work. In
fact, my knowledge of unix security beyond file permissions is still
poor, although I have spent considerable time studying it. It is
my strong impression that some OpenBSD people are very touchy about
allegations of any kind that expose problems with their system. I
ran into this problem many, many times during my 30 years as an
active software developer. That's human nature at work. If you
want to see an example of this, read in the OpenBSD archives the
exchange between me and others about disk passwords. I believe that
that exchange lead to a security fix in which it became impossible
in OpenBSD to set the disk password on ata disks. I really was
surprised at the apparent inability of the OpenBSD people with whom
I was corresponding to grasp the very simple concept of a disk
password stored on the disk in stead of in the bios and the security
implications of that arrangement. Obviously the developers understood
the problem, although they did not post on that subject. They just
fixed the problem in the next release.
> > Qt bugs relating to OpenBSD platform > > Qt is totally unrelated
to KDE, except that KDE builds on it and gives
> input to TT (partly by filing bugreports) on what they'd like to have
> (because KDE is one of the biggest projects building on top of Qt). So
> if you have problems with Qt talk to Trolltech.
> > > fixed, that neither kde, qt nor OpenBSD developers really want to
> > hear about these bugs.
> > As I explained above, from an outside point of view quite some of your
> mails were totally unrelated to KDE, some security hazards were just
> misunderstandings of the functionality by you.
I got into all of that stuff because of all the problems I was having when
I ran X and KDE. The trouble I was having dropped drastically after I
started setting the permissions of all X/KDE sockets to -rw------- and
stopped using kmail and koffice and giving myself permanent ownership
of all the /dev/tty devices that I was using.
> > > I really should stop posting about bugs I find since I
> > > am now officially retired and no longer have energy or desire
> > If you decide to not write any bugs anymore, thats no problem. But
> please stop blaming other people for not caring about bugs you don't
> report.
As far as I'm concerned, mentioning the bug in this user group is reporting
it, but I can understand your disagreeing with that idea.
No blame was attributed by me to anyone. This is a situational problem as
far as I'm concerned.
> > Andreas
--
[ signature omitted ]
Message 9 in thread
On 04.12.06 11:31:53, Andreas Pakulat wrote:
> > On 04.12.06 01:03:22, dfeustel@xxxxxxxxxxxxxx wrote:
> > > This because it is clear to me from
> > > previous battles to get KDE
> >
> > I remember those mails on kde-devel, and I think you give the wrong
> > picture here. The kde developers always kindly asked you to give more
> > precise information or to exactly explain why this or that is a secuirty
> > hazard (which is what most of your messages where about). At some point
> > it was clear that you weren't talking about things you really know in
> > depth, so they gave up. You were also told that some of the things, are
> > not fixable in KDE and thus you talked to the wrong people.
>
> I disagree with your characterisation here.
I didn't remember all the details and I don't have the time to read up
on all the threads. So I'm not going to comment this any further...
> > > > I really should stop posting about bugs I find since I
> > > > am now officially retired and no longer have energy or desire
>
> > > If you decide to not write any bugs anymore, thats no problem. But
> > please stop blaming other people for not caring about bugs you don't
> > report.
>
> As far as I'm concerned, mentioning the bug in this user group is reporting
> it,
Mentioning an OpenBSD bug or a KDE bug in this group is useless and
doesn't make any sense at all. Even mentioning a Qt bug here doesn't
make much sense. There are official channels where Bugreports are
accepted and read by the right people. TT developers do not read all
threads of this list and certainly this list is not the proper place to
keep track of bugs and their current state.
People have developed dozens of systems to keep track of bugs, use them
and you'll find out that bugs will get attention and maybe even a fix.
> but I can understand your disagreeing with that idea.
This is a list for users of Qt, mentioning a bug here merely states: Hey
this bug exists, be aware of it. The same is true for the kde-devel
mailing list, bugs.kde.org is the proper place to report bugs.
Unless you talk to the right people using the right system there's only
a really small chance that software gets fixed.
Andreas
--
[ signature omitted ]
Message 10 in thread
> Hi,
>
> > I tried to file a bug report at bugs.kde.org.
>
> This is for KDE bugs, not Qt bugs. The KDE team do not write the Qt
> software so they can't fix Qt bugs.
Sorry, I was confusing the Qt build failure with a KDE bug I recently discovered.
> > It didn't work. I gave up. This because it is clear to me from
> > previous battles to get KDE/Qt bugs relating to OpenBSD platform
>
> This is a misunderstanding. There is no such Qt/KDE entity. There are
> programmers writing KDE, and progammers writing Qt. You have to contact
> the right people.
>
> > fixed, that neither kde, qt nor OpenBSD developers really want to
> > hear about these bugs. I really should stop posting about bugs
> > I find since I am now officially retired and no longer have
> > energy or desire to follow through with official bug reports
> > of OpenBSD/KDE/Qt problems. Finding bug work-arounds is soo much
> > simpler for me.
>
> I don't understand. I've always answered your postings, Qt bugs have
> been fixed, and OpenBSD bugs have been worked around.
This is true. You do an exæmplary job handling all the email to this group.
> It looks like you expect bugs to be fixed auto-magically. In case you
> haven't noticed, software is still written by humans, not robots nor
> gods. They have limited time and possibly different priorities. You need
> to talk to them and explain to them. In short, you do have to spend some
> minimal time filing bug reports if you want them fixed. Just like you
> have to spend some time talking to a mechanic to get your car fixed.
> --
> Dimitri
I don't have to talk to mechanics; I no longer have a vehicle. :-)
Seriously, When I have identified an OpenBSD-specific problem with Qt or KDE,
the OpenBSD developers said "this is a KDE/Qt problem. Talk to the KDE/Qt developers."
KDE/Qt developers said "this is an OpenBSD problem. Talk to the OpenBSD developers."
I no longer have any interest in being the middle man in such dialogs.
I recommend that the Qt developers create a work-around for the system calls used by
Qt that are not yet implemented in OpenBSD and make sure that each build of Qt works
on the current version of OpenBSD. Otherwise just state that Qt is a Linux-only SDK.
I recommend the same for KDE, although that is irrelevant here and is not likely to
happen in any case. It is simpler and easier to use whatever downlevel version of Qt
is customised for OpenBSD and provided as a package with each new release of OpenBSD.
In other words, up-to-date releases of Qt will never be used with current OpenBSD
as long as the current Qt build doesn't work with that current release.
(BTW, there is NO chance that I will switch from OpenBSD to any version of Linus :-) ).
--
[ signature omitted ]
Message 11 in thread
I think your missing the point... There is no KDE involved with the qt build system...
When a release of QT is put out, then KDE may or may not move to it. At that point, (and I am overly simplyfing the process on purpose.) KDE may port/code to/upgrade/resolve issues for that version...
There may be KDE bugs that get flushed out, or new QT bugs that get flushed out... They may be platform specific. Like it or not.. the more esoteric your platform is.. the more likely a platform specific bug will be flushed out.
File this with the Trolls, Im sure it will get fixed...
Scott
> -----Original Message-----
> From: dfeustel@xxxxxxxxxxxxxx [mailto:dfeustel@xxxxxxxxxxxxxx]
> Sent: Monday, December 04, 2006 4:29 AM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: 4.2.2 Build Failure
>
> > Hi,
> >
> > > I tried to file a bug report at bugs.kde.org.
> >
> > This is for KDE bugs, not Qt bugs. The KDE team do not write the Qt
> > software so they can't fix Qt bugs.
>
> Sorry, I was confusing the Qt build failure with a KDE bug I recently
> discovered.
>
> > > It didn't work. I gave up. This because it is clear to me from
> > > previous battles to get KDE/Qt bugs relating to OpenBSD platform
> >
> > This is a misunderstanding. There is no such Qt/KDE entity. There are
> > programmers writing KDE, and progammers writing Qt. You have to contact
> > the right people.
> >
> > > fixed, that neither kde, qt nor OpenBSD developers really want to
> > > hear about these bugs. I really should stop posting about bugs
> > > I find since I am now officially retired and no longer have
> > > energy or desire to follow through with official bug reports
> > > of OpenBSD/KDE/Qt problems. Finding bug work-arounds is soo much
> > > simpler for me.
> >
> > I don't understand. I've always answered your postings, Qt bugs have
> > been fixed, and OpenBSD bugs have been worked around.
>
> This is true. You do an exæmplary job handling all the email to this
> group.
>
> > It looks like you expect bugs to be fixed auto-magically. In case you
> > haven't noticed, software is still written by humans, not robots nor
> > gods. They have limited time and possibly different priorities. You need
> > to talk to them and explain to them. In short, you do have to spend some
> > minimal time filing bug reports if you want them fixed. Just like you
> > have to spend some time talking to a mechanic to get your car fixed.
> > --
> > Dimitri
>
> I don't have to talk to mechanics; I no longer have a vehicle. :-)
> Seriously, When I have identified an OpenBSD-specific problem with Qt or
> KDE,
> the OpenBSD developers said "this is a KDE/Qt problem. Talk to the KDE/Qt
> developers."
> KDE/Qt developers said "this is an OpenBSD problem. Talk to the OpenBSD
> developers."
> I no longer have any interest in being the middle man in such dialogs.
> I recommend that the Qt developers create a work-around for the system
> calls used by
> Qt that are not yet implemented in OpenBSD and make sure that each build
> of Qt works
> on the current version of OpenBSD. Otherwise just state that Qt is a
> Linux-only SDK.
> I recommend the same for KDE, although that is irrelevant here and is not
> likely to
> happen in any case. It is simpler and easier to use whatever downlevel
> version of Qt
> is customised for OpenBSD and provided as a package with each new release
> of OpenBSD.
> In other words, up-to-date releases of Qt will never be used with current
> OpenBSD
> as long as the current Qt build doesn't work with that current release.
> (BTW, there is NO chance that I will switch from OpenBSD to any version of
> Linus :-) ).
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 12 in thread
This thread concerning the failure of Qt SDK to build on OpenBSD
is getting confused, so here is a position statement regarding
that build failure:
The build of Qt 4.2.2 fails on the AMD 64-bit version of OpenBSD 3.9,
The build fails because Qt configure does not test for the presence in
OpenBSD of a couple of Linux-specific password-related system calls
and, when those system calls are not implemented, generate OpenBSD-
specific Define symbols which cause work-around code for those system
calls to be generated (and the build to succeed) when the build is on
an OpenBSD system.
The result of the build failure on OpenBSD of this version of Qt is that
I will not spend any more time working with the Qt 4.2.2 SDK on either the
32-bit or the 64-bit versions of OpenBSD.
In the event that this or a future version of the Qt SDK is modified so
that the Trollteck build works on OpenBSD 'out of the box' after running
configure, then I will spend some time testing the Qt SDK on OpenBSD.
I would like to once again be able to build and then try out new versions
of the Qt SDKs on my system, but if I can't, there is lots of other
interesting software I *can* build 'out of the box' on OpenBSD.
Dave Feustel
--
[ signature omitted ]
Message 13 in thread
On 04.12.06 14:49:41, dfeustel@xxxxxxxxxxxxxx wrote:
> This thread concerning the failure of Qt SDK to build on OpenBSD
> is getting confused, so here is a position statement regarding
> that build failure:
>
> The build of Qt 4.2.2 fails on the AMD 64-bit version of OpenBSD 3.9,
> The build fails because Qt configure does not test for the presence in
> OpenBSD of a couple of Linux-specific password-related system calls
> and, when those system calls are not implemented, generate OpenBSD-
> specific Define symbols which cause work-around code for those system
> calls to be generated (and the build to succeed) when the build is on
> an OpenBSD system.
<stupid question>
And why are you unable to send this text to qt-bugs at trolltech com?
</stupid question>
> In the event that this or a future version of the Qt SDK is modified so
> that the Trollteck build works on OpenBSD 'out of the box' after running
> configure, then I will spend some time testing the Qt SDK on OpenBSD.
Which will only happen if you send TT a bugreport, posting in this list
will not resolve the problem.
Andreas
--
[ signature omitted ]
Message 14 in thread
Hi,
> The build of Qt 4.2.2 fails on the AMD 64-bit version of OpenBSD 3.9,
> The build fails because Qt configure does not test for the presence in
> OpenBSD of a couple of Linux-specific password-related system calls
> and, when those system calls are not implemented, [...]
There's nothing Linux-specific in _SC_GETGR_R_SIZE_MAX as far as I know.
It's part of Unix standards:
http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html
http://www.opengroup.org/onlinepubs/007908799/xsh/sysconf.html
Where did you get that information from?
That said I do agree that it may be missing from OpenBSD 3.9 and that Qt
should work around that. Debating whether this is an OpenBSD bug or not
won't help with building Qt on OpenBSD 3.9. However the problem may have
been fixed in OpenBSD 4.0. Have you tried OpenBSD 4.0?
> In the event that this or a future version of the Qt SDK is modified so
> that the Trollteck build works on OpenBSD 'out of the box' after running
> configure, then I will spend some time testing the Qt SDK on OpenBSD.
Dave, this may happen if you do report the bug. As I said the place to
report Qt bugs is:
http://www.trolltech.com/bugreport-form
That's what had been already suggested last August:
http://lists.trolltech.com/qt-interest/2006-08/thread00717-0.html
You need to talk to the people who can fix the problem. You're not
necessarily doing that right now. And you may also need to spend some
time explaining the problem and why it's important and should be fixed.
This not specific to Qt, KDE, or OpenBSD. As I said it's the same when
talking to a car mechanic or a doctor of medicine.
--
[ signature omitted ]
Message 15 in thread
> Hi,
>
> > The build of Qt 4.2.2 fails on the AMD 64-bit version of OpenBSD 3.9,
> > The build fails because Qt configure does not test for the presence in
> > OpenBSD of a couple of Linux-specific password-related system calls
> > and, when those system calls are not implemented, [...]
>
> There's nothing Linux-specific in _SC_GETGR_R_SIZE_MAX as far as I know.
> It's part of Unix standards:
> http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html
> http://www.opengroup.org/onlinepubs/007908799/xsh/sysconf.html
> Where did you get that information from?
I was surmising because I didn't have the links you posted above.
Thanks for posting them.
> That said I do agree that it may be missing from OpenBSD 3.9 and that Qt
> should work around that. Debating whether this is an OpenBSD bug or not
> won't help with building Qt on OpenBSD 3.9. However the problem may have
> been fixed in OpenBSD 4.0. Have you tried OpenBSD 4.0?
Just checked the man page at openbsd.org for the function you mention
above, and the function is not documented. I assume from that that the
function is not implemented in 4.0.
> > In the event that this or a future version of the Qt SDK is modified so
> > that the Trollteck build works on OpenBSD 'out of the box' after running
> > configure, then I will spend some time testing the Qt SDK on OpenBSD.
>
> Dave, this may happen if you do report the bug. As I said the place to
> report Qt bugs is:
> http://www.trolltech.com/bugreport-form
OK, I have filed a bug report. Thanks for the link.
> That's what had been already suggested last August:
> http://lists.trolltech.com/qt-interest/2006-08/thread00717-0.html
>
> You need to talk to the people who can fix the problem. You're not
> necessarily doing that right now. And you may also need to spend some
> time explaining the problem and why it's important and should be fixed.
> This not specific to Qt, KDE, or OpenBSD. As I said it's the same when
> talking to a car mechanic or a doctor of medicine.
>
> --
> Dimitri
Dimitri, Thanks for the info in your followup,
Dave
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
