With recent versions of mock, (ie, mock-0.8 series), I've noticed change in behavior, seemingly the mockbuild user doesn't include stuff from /etc/profile.d/* (my guess is that it's no longer being treated as a login shell).
I mention this because bunch of kde-related packages that once built fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE aren't getting set properly).
Can anyone confirm/deny this?
-- Rex
On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote:
With recent versions of mock, (ie, mock-0.8 series), I've noticed change in behavior, seemingly the mockbuild user doesn't include stuff
from /etc/profile.d/* (my guess is that it's no longer being treated as a
login shell).
I mention this because bunch of kde-related packages that once built fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE aren't getting set properly).
Can anyone confirm/deny this?
It would be a bug if it sourced files from /etc/profile.d/* automatically, because a normal rpmbuild does not do that either -- as often the files get installed only after you have logged in already. We have been doing it manually in %build for a very long time, especially for qt.sh
Michael Schwendt wrote:
On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote:
With recent versions of mock, (ie, mock-0.8 series), I've noticed change in behavior, seemingly the mockbuild user doesn't include stuff
from /etc/profile.d/* (my guess is that it's no longer being treated as a
login shell).
I mention this because bunch of kde-related packages that once built fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE aren't getting set properly).
Can anyone confirm/deny this?
Or more precisely, is this mock's intended behavior? If so, please reconsider. :)
It would be a bug if it sourced files from /etc/profile.d/* automatically, because a normal rpmbuild does not do that either --
The user running rpmbuild logged in, and sourced things. mockbuild used to do the same (with 0.7), but now apparently doesn't.
We have been doing it manually in %build for a very long time, especially for qt.sh
This is a hack to cater to the "I just installed pkg X after logging in, why doesn't my local rpmbuild work?" croud. That's all fine and dandy, but I'd much rather not make manual source'ing of profile.d/ items a requirement to make things "just work" in fedora's buildsys either.
-- Rex
-- Rex
On Mon, 03 Dec 2007 12:32:39 -0600 Rex Dieter rdieter@math.unl.edu wrote:
This is a hack to cater to the "I just installed pkg X after logging in, why doesn't my local rpmbuild work?" croud. That's all fine and dandy, but I'd much rather not make manual source'ing of profile.d/ items a requirement to make things "just work" in fedora's buildsys either.
And I'd rather not rely on some "shell magic" to make things just work too.
Jesse Keating wrote:
On Mon, 03 Dec 2007 12:32:39 -0600 Rex Dieter rdieter@math.unl.edu wrote:
This is a hack to cater to the "I just installed pkg X after logging in, why doesn't my local rpmbuild work?" croud. That's all fine and dandy, but I'd much rather not make manual source'ing of profile.d/ items a requirement to make things "just work" in fedora's buildsys either.
And I'd rather not rely on some "shell magic" to make things just work too.
Sigh, so can someone come up with a better solution to "I want to install pkg foo, where it defines env vars, and pkgs consuming/using pkg foo shouldn't need to know it's implementation details (ie, which file in /etc/profile.d/ needs to source'd)" ?
-- Rex
On Tue, 04 Dec 2007 07:55:41 -0600 Rex Dieter rdieter@math.unl.edu wrote:
Sigh, so can someone come up with a better solution to "I want to install pkg foo, where it defines env vars, and pkgs consuming/using pkg foo shouldn't need to know it's implementation details (ie, which file in /etc/profile.d/ needs to source'd)" ?
How do you plan to solve this when installing on a real system? User installs a bunch of -devel packages, tries to do an rpmbuild, fail. What then?
Jesse Keating wrote:
On Tue, 04 Dec 2007 07:55:41 -0600 Rex Dieter rdieter@math.unl.edu wrote:
Sigh, so can someone come up with a better solution to "I want to install pkg foo, where it defines env vars, and pkgs consuming/using pkg foo shouldn't need to know it's implementation details (ie, which file in /etc/profile.d/ needs to source'd)" ?
How do you plan to solve this when installing on a real system? User installs a bunch of -devel packages, tries to do an rpmbuild, fail. What then?
The easiest (and only) solution I see so far is my initial suggestion: "start a (new) login shell".
If that's not acceptable, then we're stuck with the status-quo.
-- Rex
On Tue, 2007-12-04 at 08:50 -0600, Rex Dieter wrote:
Jesse Keating wrote:
On Tue, 04 Dec 2007 07:55:41 -0600 Rex Dieter rdieter@math.unl.edu wrote:
Sigh, so can someone come up with a better solution to "I want to install pkg foo, where it defines env vars, and pkgs consuming/using pkg foo shouldn't need to know it's implementation details (ie, which file in /etc/profile.d/ needs to source'd)" ?
How do you plan to solve this when installing on a real system? User installs a bunch of -devel packages, tries to do an rpmbuild, fail. What then?
The easiest (and only) solution I see so far is my initial suggestion: "start a (new) login shell".
If that's not acceptable, then we're stuck with the status-quo.
Why not convert qt to use pkg-config like so many other projects do, rather than stuffing build configuration details into my environment, where I don't care about them 99% of the time?
Mike Bonnet wrote:
Why not convert qt to use pkg-config like so many other projects do, rather than stuffing build configuration details into my environment, where I don't care about them 99% of the time?
qt itself *does* use pkg-config, many qt-consuming apps don't use pkg-config (yet).
-- Rex
Rex Dieter wrote:
Mike Bonnet wrote:
Why not convert qt to use pkg-config like so many other projects do, rather than stuffing build configuration details into my environment, where I don't care about them 99% of the time?
qt itself *does* use pkg-config, many qt-consuming apps don't use pkg-config (yet).
fyi, I submitted a patch to upstream kde so all future kde(3)-based apps can/will detect qt properly (with pkg-config support), without the need of any special/custom environment variables. See: http://bugs.kde.org/136377
-- Rex
On Mon, Dec 03, 2007 at 12:32:39PM -0600, Rex Dieter wrote:
Michael Schwendt wrote:
On Mon, 03 Dec 2007 09:28:43 -0600, Rex Dieter wrote:
With recent versions of mock, (ie, mock-0.8 series), I've noticed change in behavior, seemingly the mockbuild user doesn't include stuff
from /etc/profile.d/* (my guess is that it's no longer being treated as a
login shell).
I mention this because bunch of kde-related packages that once built fine, no longer do, because /etc/profile.d/qt.sh apparently isn't getting source'd into the build environment (and env vars QTDIR, QTLIB, QTINCLUDE aren't getting set properly).
Can anyone confirm/deny this?
Or more precisely, is this mock's intended behavior? If so, please reconsider. :)
Yes, this is the intended behaviour.
The behaviour from 0.7 was a bug as it made builds non-reproduce-able, becuase environment variables from the host leaked into the chroot build.
If I run a mock 0.7 build of PKG_X and I have QT installed on my local machine, PKG_X, then the mock build would see QT.
If you run a mock 0.7 build of PKG_X and *dont* have QT installed on your box, then PKG_X build silently doesnt see QT.
This could lead to silently-differing output RPMs from two otherwise identical builds.
The new mock scrubs the environment in the setuid wrapper such that when we exec() rpmbuild it has a clean environment.
When we exec() rpmbuild, we do so with a clean environment. If you wish to include dependencies, the proper way to do that is from the specfile. -- Michael
Michael E Brown wrote:
When we exec() rpmbuild, we do so with a clean environment. If you wish to include dependencies, the proper way to do that is from the specfile.
One could argue though that it should exec rpmbuild within a login shell so that it picks up settings from /etc/profile.d/* within the chroot environment.
On Mon, Dec 03, 2007 at 04:38:10PM -0700, Orion Poplawski wrote:
Michael E Brown wrote:
When we exec() rpmbuild, we do so with a clean environment. If you wish to include dependencies, the proper way to do that is from the specfile.
One could argue though that it should exec rpmbuild within a login shell so that it picks up settings from /etc/profile.d/* within the chroot environment.
Indeed. One could argue that.
At this point, I would defer to Jesse, who has more experience in this specific area.
I was merely trying to point out why the old mock behaviour was a bug (leaking env vars from host=>chroot).
The patch to change the rpmbuild to be a login shell would not be a large one, and I am sort of on the fence about it. (Minor input would be that env. vars from /etc/profile.d/ seem like a poor way to do this, there seem to be lots of better ways.) -- Michael
On Mon, Dec 03, 2007 at 05:55:03PM -0600, Michael E Brown wrote:
On Mon, Dec 03, 2007 at 04:38:10PM -0700, Orion Poplawski wrote:
Michael E Brown wrote:
When we exec() rpmbuild, we do so with a clean environment. If you wish to include dependencies, the proper way to do that is from the specfile.
One could argue though that it should exec rpmbuild within a login shell so that it picks up settings from /etc/profile.d/* within the chroot environment.
Indeed. One could argue that.
At this point, I would defer to Jesse, who has more experience in this specific area.
I was merely trying to point out why the old mock behaviour was a bug (leaking env vars from host=>chroot).
The patch to change the rpmbuild to be a login shell would not be a large one, and I am sort of on the fence about it. (Minor input would be that env. vars from /etc/profile.d/ seem like a poor way to do this, there seem to be lots of better ways.)
What's the benefit to having mock implicitly invoke a login shell, rather than the spec file explicitly including such if it needs it? I much prefer explicit over implicit - so much easier to track down when things don't work as expected when you don't have to "just know" that mock uses a login shell to invoke /etc/profile.d/* because you can see in the spec where /etc/profile.d/qt.sh got sourced.
buildsys@lists.fedoraproject.org