hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
On 04/26/2014 10:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
When will those of us interested in helping get proper access to a build system where we could push mock configs, for test purposes, without manual intervention ?
Manuel
On 04/27/2014 10:46 PM, Manuel Wolfshant wrote:
When will those of us interested in helping get proper access to a build system where we could push mock configs, for test purposes, without manual intervention ?
direct access to the core buildsysten isnt going to happen, there are no plans for that at this point.
at this point ( and the only plan moving forward ) is to expose the reports from the buildsystem and have a process via git that allows external contribution to influence builds.
On 04/28/2014 01:53 PM, Karanbir Singh wrote:
On 04/27/2014 10:46 PM, Manuel Wolfshant wrote:
When will those of us interested in helping get proper access to a build system where we could push mock configs, for test purposes, without manual intervention ?
direct access to the core buildsysten isnt going to happen, there are no plans for that at this point.
and it's just fine. this is not what I meant in any of the talks we had 3 months ago when we repeatedly discussed about this.
at this point ( and the only plan moving forward ) is to expose the reports from the buildsystem and have a process via git that allows external contribution to influence builds.
the last option is the one i was referring to. but without the need or manual intervention to transfer the modified config files from git to the buildsystem.
On 04/28/2014 12:14 PM, Manuel Wolfshant wrote:
at this point ( and the only plan moving forward ) is to expose the reports from the buildsystem and have a process via git that allows external contribution to influence builds.
the last option is the one i was referring to. but without the need or manual intervention to transfer the modified config files from git to the buildsystem.
There is no way to have that without a manual step or direct access really.
There are some things we can do within the limited qa team, for example, being able to resubmit jobs ( specially for unreleased content ) might be easily done. being able to push a patch that influences the environ would be a lot harder, and thats really best done via a git commit process.
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
I can tell you for sure the following RPMs have i686 packages in the release, but cannot be built as the official kernel source rpm doesn't produce the required RPMs for the buildroot:
bluedevil-1.3-4.el7 bluedevil.i686 bluedevil-devel.i686 control-center-3.8.6-15.el7 control-center.i686 evolution-3.8.5-21.el7 evolution.i686 evolution-devel.i686 gnome-settings-daemon-3.8.6.1-8.el7 gnome-settings-daemon.i686 gnome-settings-daemon-devel.i686 metacity-2.34.13-7.el7 metacity.i686 metacity-devel.i686 network-manager-applet-0.9.9.0-15.git20140307.el7 libnm-gtk.i686 libnm-gtk-devel.i686 qemu-kvm-1.5.3-60.el7 libcacard.i686 libcacard-devel.i686 rhythmbox-2.99.1-3.el7 rhythmbox-devel.i686 tracker-0.16.2-8.el7 tracker.i686 tracker-devel.i686
I've opened an upstream bug 1092114
Pat
On 28 April 2014 20:10, Pat Riehecky riehecky@fnal.gov wrote:
I can tell you for sure the following RPMs have i686 packages in the release, but cannot be built as the official kernel source rpm doesn't produce the required RPMs for the buildroot:
bluedevil-1.3-4.el7 bluedevil.i686 bluedevil-devel.i686 control-center-3.8.6-15.el7 control-center.i686 evolution-3.8.5-21.el7 evolution.i686 evolution-devel.i686 gnome-settings-daemon-3.8.6.1-8.el7 gnome-settings-daemon.i686 gnome-settings-daemon-devel.i686 metacity-2.34.13-7.el7 metacity.i686 metacity-devel.i686 network-manager-applet-0.9.9.0-15.git20140307.el7 libnm-gtk.i686 libnm-gtk-devel.i686 qemu-kvm-1.5.3-60.el7 libcacard.i686 libcacard-devel.i686 rhythmbox-2.99.1-3.el7 rhythmbox-devel.i686 tracker-0.16.2-8.el7 tracker.i686 tracker-devel.i686
I've opened an upstream bug 1092114
Pat
-- Pat Riehecky
Scientific Linux developer http://www.scientificlinux.org/
Upstream bug 1092114 has been set private.
Alan.
On 04/28/2014 02:52 PM, Alan Bartlett wrote:
On 28 April 2014 20:10, Pat Riehecky riehecky@fnal.gov wrote:
I can tell you for sure the following RPMs have i686 packages in the release, but cannot be built as the official kernel source rpm doesn't produce the required RPMs for the buildroot:
bluedevil-1.3-4.el7 bluedevil.i686 bluedevil-devel.i686 control-center-3.8.6-15.el7 control-center.i686 evolution-3.8.5-21.el7 evolution.i686 evolution-devel.i686 gnome-settings-daemon-3.8.6.1-8.el7 gnome-settings-daemon.i686 gnome-settings-daemon-devel.i686 metacity-2.34.13-7.el7 metacity.i686 metacity-devel.i686 network-manager-applet-0.9.9.0-15.git20140307.el7 libnm-gtk.i686 libnm-gtk-devel.i686 qemu-kvm-1.5.3-60.el7 libcacard.i686 libcacard-devel.i686 rhythmbox-2.99.1-3.el7 rhythmbox-devel.i686 tracker-0.16.2-8.el7 tracker.i686 tracker-devel.i686
I've opened an upstream bug 1092114
Pat
-- Pat Riehecky
Scientific Linux developer http://www.scientificlinux.org/
Upstream bug 1092114 has been set private.
Alan.
I've asked for upstream to change it to public, but they've only had it a little while....
Pat
On 28 April 2014 20:57, Pat Riehecky riehecky@fnal.gov wrote:
I've asked for upstream to change it to public, but they've only had it a little while....
Pat
-- Pat Riehecky
Scientific Linux developer http://www.scientificlinux.org/
Thank you Pat.
Alan.
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
Looks like changes in strigi between the Beta and the RC prevent kdelibs from building correctly.
BZ 1092693
Pat
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
An odd discrepancy showed up in PyQt4's use of %{python_sitelib} instead of %{python_sitearch}
BZ 1093185
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
pacemaker-1.1.10-29.el7 wont build against publican-3.2.0-3.el7 (from RC). Builds fine against publican-3.1.5-4.el7 (from the BETA)
BZ 1093113
Pat
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
looks like someone else beat me to : maven-dependency-tree missing build requires maven-shared
BZ 1074927
Pat
On 05/01/2014 03:04 PM, Pat Riehecky wrote:
On 04/26/2014 02:56 AM, Karanbir Singh wrote:
hi
for those of you who are tracking the build-reports, the c7.00.00 build running at the moment is just a scratch-build, to try and scope up the issues we are likely to hit in the i386/x86_64 build splits and to quantify exactly what part of i386 we need to owl as a bare minimal.
its running on a single builder node, and were not running the powerpc / arm builds in parallel ( yet ).
Early next week, we should be in a position to start a proper buildrun off the rhel7rc codebase.
- KB
looks like someone else beat me to : maven-dependency-tree missing build requires maven-shared
BZ 1074927
Pat
Also related:
maven-doxia-tools - #1074928 maven-reorting-exec - #1074929 maven-script-interpreter - #1074930 maven-shared-jar - #1074931 maven-verifier - #1074932
Same problem
On 05/01/2014 09:16 PM, Pat Riehecky wrote:
looks like someone else beat me to : maven-dependency-tree missing build requires maven-shared
BZ 1074927
Just as a followup - thanks Pat for these notes, I believe Johnny used this in the process of getting the builds completed.
As someone who has clearly been tracking the build reports, is that something helpful ?
-
Alan Bartlett -
Karanbir Singh -
Manuel Wolfshant -
Pat Riehecky