Bug 211625

$QTDIR won't be defined at build-time unless you source /etc/profile.d/qt.sh
at the beginning of the %build section.

* Only tideEditor is GPL, the two db utils are PD.

(In reply to comment #1)
> $QTDIR won't be defined at build-time unless you source /etc/profile.d/qt.sh
> at the beginning of the %build section.

This is actually not correct. $QTDIR is actually set because
mock surely source files under /etc/profile.d and the environment exported
are actually stored (also, normal rpmbuild stores the environment 
correctly).
You can just expect that $QTDIR is defined as well as $PATH is defined 
correctly.

Negative. And doesn't make sense. In the chroot, you don't want the
build server's host environment, but the build server's guest environment.

Further, for normal rpmbuild builds, $QTDIR is not set unless qt-devel
is available already at log-in time. In active sessions, nothing sources
qt.sh automatically when a package is installed. Your src.rpm would fail
miserably.

All packages (Red Hat and Fedora) do something with the same effect
than:

%build
unset QTDIR || : ; . /etc/profile.d/qt.sh

(In reply to comment #3)
> Negative. And doesn't make sense. In the chroot, you don't want the
> build server's host environment, but the build server's guest environment.
Actually the environment of "build server's guest" is correctly used.
> 
> Further, for normal rpmbuild builds, $QTDIR is not set unless qt-devel
> is available already at log-in time. 
qt-devel is needed anyway (as seen in BuildRequires)

> In active sessions, nothing sources
> qt.sh automatically when a package is installed. 
This is not correct. qt-devel is installed IN ADVANCE.

> Your src.rpm would fail miserably.
You've checked this? You've really run mock? I always check rebuilding
by mock and nothing problem happens.


> All packages (Red Hat and Fedora) do something with the same effect
> than:
> %build
> unset QTDIR || : ; . /etc/profile.d/qt.sh

You can see that many packages using qt-devel doesn't have
the line you mentioned in 
http://buildsys.fedoraproject.org/logs/fedora-development-extras/
and I have already reviewed some packages which use Qt environment.

Some months ago sourcing qt.sh was needed, seems like it is
not needed now. 

Created attachment 139051 [details]
build failure log

> You can see that many packages using qt-devel doesn't have
> the line you mentioned in 
> and I have already reviewed some packages which use Qt environment.

Then you've not done your homework, unfortunately, since all these
packages will fail to build with ordinary rpmbuild.

Patrice,

> Some months ago sourcing qt.sh was needed, seems like it is
> not needed now. 

qt.sh is not sourced. Neither when entering mock chroot, nor when
running something like:

  yum install qt-devel
  rpmbuild --rebuild foo.src.rpm

(In reply to comment #7)
> Patrice,
> 
> > Some months ago sourcing qt.sh was needed, seems like it is
> > not needed now. 
> 
> qt.sh is not sourced. Neither when entering mock chroot, nor when
> running something like:
> 
>   yum install qt-devel
>   rpmbuild --rebuild foo.src.rpm

Ah, ok. In fact I never tested nor investigated but I was reporting
something I remembered somebody else said, so you can disregard my 
comment...

(In reply to comment #7)
> Patrice,
> 
>   yum install qt-devel
>   rpmbuild --rebuild foo.src.rpm

Your situation occurs not only for qt.
You have not noticed it, however, this problem also happen for

glib2
openssh-askpass
kdelibs
mc
cvs
.........

because all of these have the files under /etc/profile.d 
For all these cases we must do the same thing you mentioned?
It is nonsense.

No, you must ensure that all the environment varie must correctly
set IN ADVANCE. All you have to do is
* install all deps needed
* RELOGIN
* then rebuild.

Note: RELOGIN is surely done by mock to ensure the environment.

Again NOTE: 
there are already many FE packages which use qt-devel
for compilation but do not have the line you have mentioned.

Ensuring and correcting your environment by relogin or
"su - <yourself>" is always recommended.

> You have not noticed 

Uh, come on, that's sort of a presumptuous comment. You name applications
and not build requirements. As soon as sourcing special files would be
needed _at build-time_ for a reproducible build, it would add a requirement
at the spec file level.

> relogin

You are not serious about such a requirement, are you?

That would be a step backwards. It would mean that any user, who uses
a package tool to add or update packages, needs to do a non-obvious
preventive re-login. It would also lead to non-reproducible builds,
because the system's QTDIR is not used when a different one is set.

I've been doing package reviews for a very long time. But the ticket for
this tiny package has reached a point already where it becomes too tiresome.
Even if it may be a tiny detail, I won't approve a package like that.

(In reply to comment #12)
> > You have not noticed 
> 
> Uh, come on, that's sort of a presumptuous comment. 
Sorry for this comment.

> As soon as sourcing special files would be
> needed _at build-time_ for a reproducible build, it would add a requirement
> at the spec file level.
> 
> > relogin
> 
> You are not serious about such a requirement, are you?

I am _SERIOUS_ . There can be a case that user sets various environment
during many other works.

Relogin is truly NEEDED because it flushes all other settings (such as
environment) a user (who are trying to rebuild) has done and
sets the inital environment needed.

This is especially true for mockbuild. At first, mockbuild "user" has
set no environment. Then to ensure build environment, mockbuild "user"
really has to relogin.

> That would be a step backwards. It would mean that any user, who uses
> a package tool to add or update packages, needs to do a non-obvious
> preventive re-login. It would also lead to non-reproducible builds,
> because the system's QTDIR is not used when a different one is set.

? Relogin is needed to ensure reproducible builds to ensure system
environment is correctly set. If user has set a different environment
(such as QTDIR) and rebuild srpm without login, this surely leads to
unpleasant result.

Surely rebuild should be done under the same environment, not under
different environment set by user. The only thing to do this is relogin.

> 
> I've been doing package reviews for a very long time. But the ticket for
> this tiny package has reached a point already where it becomes too tiresome.
> Even if it may be a tiny detail, I won't approve a package like that.

Sorry to hear that, however I think this is not a tiny thing.

Well, unifying to xtide.

*** This bug has been marked as a duplicate of 211626 ***