-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The main Node.js package supports only x86[_64] and ARM architectures, due to these being the only supported architectures of v8. This is causing issues with the downstream packages such as nodejs-less which are built for EPEL6.
Is there any way to add ExclusiveArch to the %{?nodejs_find_provides_and_requires} macro in the main node package so that we won't try to build the modules on unsupported architectures? It would be a lot less effort to fix that macro than it would be to fix every node module.
On 20/05/13 13:30, Stephen Gallagher wrote:
Is there any way to add ExclusiveArch to the %{?nodejs_find_provides_and_requires} macro in the main node package so that we won't try to build the modules on unsupported architectures? It would be a lot less effort to fix that macro than it would be to fix every node module.
No - a version of was tried for the binary modules. The plan was to do:
ExclusiveArch: %{nodejs_arches}
so that %{nodejs_arches} could be updated easily if v8 adds support for more architectures.
It didn't work though because nodejs-devel is not installed on the builders at the point when they are working out what arches to build on, so you just get:
BuildError: No matching arches were found
The only way to make it work (actually you pointed this out at the time I think) would be to get the macros into the minimal build root, perhaps by moving them from nodejs-devel to redhat-rpm-config.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/20/2013 08:41 AM, Tom Hughes wrote:
On 20/05/13 13:30, Stephen Gallagher wrote:
Is there any way to add ExclusiveArch to the %{?nodejs_find_provides_and_requires} macro in the main node package so that we won't try to build the modules on unsupported architectures? It would be a lot less effort to fix that macro than it would be to fix every node module.
No - a version of was tried for the binary modules. The plan was to do:
ExclusiveArch: %{nodejs_arches}
so that %{nodejs_arches} could be updated easily if v8 adds support for more architectures.
It didn't work though because nodejs-devel is not installed on the builders at the point when they are working out what arches to build on, so you just get:
BuildError: No matching arches were found
The only way to make it work (actually you pointed this out at the time I think) would be to get the macros into the minimal build root, perhaps by moving them from nodejs-devel to redhat-rpm-config.
Ahh, right. I forgot we already had this discussion. Ok, do we have a bug files with redhat-rpm-config? I'm reasonably sure that this would be accepted by them (since it's in the spirit of conformance with the accepted packaging guidelines).
If not, can someone who knows RPM macros better than I do prepare a patch and submit it (CCing the folks on this list so we can keep track), please?
On Mon, May 20, 2013 at 5:49 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 05/20/2013 08:41 AM, Tom Hughes wrote:
On 20/05/13 13:30, Stephen Gallagher wrote:
Is there any way to add ExclusiveArch to the %{?nodejs_find_provides_and_requires} macro in the main node package so that we won't try to build the modules on unsupported architectures? It would be a lot less effort to fix that macro than it would be to fix every node module.
No - a version of was tried for the binary modules. The plan was to do:
ExclusiveArch: %{nodejs_arches}
so that %{nodejs_arches} could be updated easily if v8 adds support for more architectures.
It didn't work though because nodejs-devel is not installed on the builders at the point when they are working out what arches to build on, so you just get:
BuildError: No matching arches were found
The only way to make it work (actually you pointed this out at the time I think) would be to get the macros into the minimal build root, perhaps by moving them from nodejs-devel to redhat-rpm-config.
Ahh, right. I forgot we already had this discussion. Ok, do we have a bug files with redhat-rpm-config? I'm reasonably sure that this would be accepted by them (since it's in the spirit of conformance with the accepted packaging guidelines).
Yeah, I filed a bug after the last thread regarding this: https://bugzilla.redhat.com/show_bug.cgi?id=921291
If not, can someone who knows RPM macros better than I do prepare a patch and submit it (CCing the folks on this list so we can keep track), please?
I'm not sure where my head was when I originally filed the bug, because the answer to my question in the first comment is plainly obvious when you actually look at the package (or even the package's name!) ;-) I've added a patch to the bug now.
-T.C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/20/2013 10:32 PM, T.C. Hollingsworth wrote:
On Mon, May 20, 2013 at 5:49 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On 05/20/2013 08:41 AM, Tom Hughes wrote:
On 20/05/13 13:30, Stephen Gallagher wrote:
Is there any way to add ExclusiveArch to the %{?nodejs_find_provides_and_requires} macro in the main node package so that we won't try to build the modules on unsupported architectures? It would be a lot less effort to fix that macro than it would be to fix every node module.
No - a version of was tried for the binary modules. The plan was to do:
ExclusiveArch: %{nodejs_arches}
so that %{nodejs_arches} could be updated easily if v8 adds support for more architectures.
It didn't work though because nodejs-devel is not installed on the builders at the point when they are working out what arches to build on, so you just get:
BuildError: No matching arches were found
The only way to make it work (actually you pointed this out at the time I think) would be to get the macros into the minimal build root, perhaps by moving them from nodejs-devel to redhat-rpm-config.
Ahh, right. I forgot we already had this discussion. Ok, do we have a bug files with redhat-rpm-config? I'm reasonably sure that this would be accepted by them (since it's in the spirit of conformance with the accepted packaging guidelines).
Yeah, I filed a bug after the last thread regarding this: https://bugzilla.redhat.com/show_bug.cgi?id=921291
If not, can someone who knows RPM macros better than I do prepare a patch and submit it (CCing the folks on this list so we can keep track), please?
I'm not sure where my head was when I originally filed the bug, because the answer to my question in the first comment is plainly obvious when you actually look at the package (or even the package's name!) ;-) I've added a patch to the bug now.
FYI, Panu has added the patch to redhat-rpm-config and pushed a Bodhi update to testing: https://admin.fedoraproject.org/updates/redhat-rpm-config-9.1.0-45.fc19
Please add the %nodejs_arches to the ExclusiveArch line in your nodejs-* packages and rebuild against them locally with this package and give karma. I can also tag it into a buildroot override if we want to start rebuilding all of the official nodejs packages.
On Wed, May 29, 2013 at 5:19 AM, Stephen Gallagher sgallagh@redhat.com wrote:
FYI, Panu has added the patch to redhat-rpm-config and pushed a Bodhi update to testing: https://admin.fedoraproject.org/updates/redhat-rpm-config-9.1.0-45.fc19
Please add the %nodejs_arches to the ExclusiveArch line in your nodejs-* packages and rebuild against them locally with this package and give karma. I can also tag it into a buildroot override if we want to start rebuilding all of the official nodejs packages.
Okay, so this doesn't seem to work with noarch packages:
[tc@zathras]~/fedpkg/npm/nodejs-ini% grep -e ExclusiveArch -e BuildArch nodejs-ini.spec BuildArch: noarch ExclusiveArch: %{nodejs_arches} [tc@zathras]~/fedpkg/npm/nodejs-ini% fedpkg local error: Architecture is not included: noarch
Could not execute local: Non zero exit
This kind of sucks, since part of the motivation for doing this was shutting up dependency warning e-mails from ppc64. If we can't use this with noarch packages, it doesn't really help us at all. In fact, I would have noticed the npm(ansi) provides issue I just wrote the list about a lot sooner if it hadn't got lost in a bunch of useless broken dependencies on ppc64 spam, so this actually is causing serious problems for us. :-(
Any ideas about what we could do here? Or should I elevate this to devel@lists.fpo for wider input?
The good news is this works great for binary modules, both locally here on F19 and on Rawhide in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=5440548
-T.C.
On Wed, May 29, 2013 at 6:55 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
Any ideas about what we could do here? Or should I elevate this to devel@lists.fpo for wider input?
I went ahead and did just that: https://lists.fedoraproject.org/pipermail/epel-devel/2013-May/008482.html
The good news is this works great for binary modules, both locally here on F19 and on Rawhide in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=5440548
As an addendum to this, this also works as expected on architectures where packages *shouldn't* build: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1136458
-T.C.
On May 29, 2013, at 10:40 PM, "T.C. Hollingsworth" tchollingsworth@gmail.com wrote:
On Wed, May 29, 2013 at 6:55 PM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
Any ideas about what we could do here? Or should I elevate this to devel@lists.fpo for wider input?
I went ahead and did just that: https://lists.fedoraproject.org/pipermail/epel-devel/2013-May/008482.html
This should probably go to FPC, rather than devel.
I can immediately think of two solutions to this, but I do not like either of them:
1) Ask rel-eng to simply block the inclusion on any package starting with nodejs- from being shipped in repos for the unsupported arches.
2) On EPEL6, build all nodejs- packages as archful instead of noarch.
Question: how does PERL handle this in EPEL? I know there are PERL packages that can only be shipped for certain arches because they exist in core RHEL for a subset of the supported arches.
The good news is this works great for binary modules, both locally here on F19 and on Rawhide in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=5440548
As an addendum to this, this also works as expected on architectures where packages *shouldn't* build: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1136458
-T.C. _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/nodejs
On Thu, May 30, 2013 at 2:52 AM, Stephen Gallagher sgallagh@redhat.com wrote:
This should probably go to FPC, rather than devel.
I intended that as a slightly more polite way of asking dgilmore and/or nirik for their input, since this is kind of a rel-eng issue.
I can immediately think of two solutions to this, but I do not like either of them:
- Ask rel-eng to simply block the inclusion on any package starting with nodejs- from being shipped in repos for the unsupported arches.
I have a feeling that blocking nodejs-* in koji sounds simple enough to us but would be a nightmare for our already overworked rel-eng folks. It doesn't look like koji's blocking mechanism [1] supports wildcards.
- On EPEL6, build all nodejs- packages as archful instead of noarch.
What about 3.) Just hack something into the script that sends out dependency warning e-mails to ignore nodejs-* (or much more preferably the output of `repoquery --whatrequires nodejs`).
That wouldn't fix the issue of metadata bloat on PPC (or having a bunch of useless RPMs in the PPC repo, but we hardlink everything so that shouldn't matter), but it would at least make dependency warnings in EPEL useful again. Option 2 is slightly more clean, but if we go that route instead of slightly larger metadata on PPC we just double the number of RPMs on the mirrors.
So it seems the question we're asking is—whose lives do we want to make more miserable: Kevin and Dennis', mirror admins', or PPC users' waiting for yum to download metadata. :-P
(Speaking of making lives miserable, I might add that my option 3 only requires me to write one patch, while option 2 involves scripting patches for ~200 packages, which makes it appeal even more to me. ;-)
Question: how does PERL handle this in EPEL? I know there are PERL packages that can only be shipped for certain arches because they exist in core RHEL for a subset of the supported arches.
<wild guess> Wouldn't those would be archful anyway, and not affected by this? (Even if they weren't archful to begin with, I suspect making them archful would be the answer to this question?) </wild guess>
-T.C.
On 30/05/13 02:55, T.C. Hollingsworth wrote:
The good news is this works great for binary modules, both locally here on F19 and on Rawhide in koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=5440548
Doesn't seem to work for me on rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5501008
That is with "ExclusiveArch: %{nodejs_arches}".
Going back to listing the architectures manually works.
Tom
On Thu, Jun 13, 2013 at 2:41 PM, Tom Hughes tom@compton.nu wrote:
Doesn't seem to work for me on rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=5501008
That is with "ExclusiveArch: %{nodejs_arches}".
Going back to listing the architectures manually works.
Try: %{?nodejs_arches: ExclusiveArch: %{nodejs_arches}}%{!nodejs_arches: ExclusiveArch: %{ix86} x86_64 %{arm}}
I believe the other %{*_arches} macros use a similar construction in their spec. Mock probably uses the RHEL 6 rpm at some stage in the build process that gets tripped up without this.
Also, I don't believe Panu backported this to F18 (and this probably can't get into RHEL6), so that'll allow you to use the same spec in all branches.
-T.C.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/29/2013 09:55 PM, T.C. Hollingsworth wrote:
On Wed, May 29, 2013 at 5:19 AM, Stephen Gallagher sgallagh@redhat.com wrote:
FYI, Panu has added the patch to redhat-rpm-config and pushed a Bodhi update to testing: https://admin.fedoraproject.org/updates/redhat-rpm-config-9.1.0-45.fc19
Please add the %nodejs_arches to the ExclusiveArch line in your
nodejs-* packages and rebuild against them locally with this package and give karma. I can also tag it into a buildroot override if we want to start rebuilding all of the official nodejs packages.
Okay, so this doesn't seem to work with noarch packages:
[tc@zathras]~/fedpkg/npm/nodejs-ini% grep -e ExclusiveArch -e BuildArch nodejs-ini.spec BuildArch: noarch ExclusiveArch: %{nodejs_arches} [tc@zathras]~/fedpkg/npm/nodejs-ini% fedpkg local error: Architecture is not included: noarch
Could not execute local: Non zero exit
Sorry for the long turnaround on this, but I had a long conversation with Dennis Gilmore, Toshio Kuratomi, Kevin Fenzi and Bill Nottingham about this today and we figured out the correct approach.
So with noarch packages, we will want to do:
BuildArch: noarch ExclusiveArch: %{nodejs_arches} noarch
This will yield the correct result (building it noarch and only putting it in the %{nodejs_arches} repositories. (Confirmed by Dennis Gilmore; this is how the Intel WiFi firmware does things too).
For archful builds we can leave off BuildArch and just use: ExclusiveArch: %{nodejs_arches}
Obviously, this will only work on F19 and later. For Fedora 18 and EPEL 6, we need to do:
BuildArch: noarch ExclusiveArch: %{ix86} %{arm} x86_64 noarch
and
ExclusiveArch: %{ix86} %{arm} x86_64
respectively.
This can also work: %{?nodejs_arches: ExclusiveArch: %{nodejs_arches}}%{!nodejs_arches: ExclusiveArch: %{ix86} x86_64 %{arm}}
But it's ugly, and I'd recommend just splitting the package RPMs between branches to keep each branch simpler to understand.
On Tue, Jun 18, 2013 at 11:28 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Sorry for the long turnaround on this, but I had a long conversation with Dennis Gilmore, Toshio Kuratomi, Kevin Fenzi and Bill Nottingham about this today and we figured out the correct approach.
Thanks a lot, Stephen!
So with noarch packages, we will want to do:
BuildArch: noarch ExclusiveArch: %{nodejs_arches} noarch
This will yield the correct result (building it noarch and only putting it in the %{nodejs_arches} repositories. (Confirmed by Dennis Gilmore; this is how the Intel WiFi firmware does things too).
<snip>
But it's ugly, and I'd recommend just splitting the package RPMs between branches to keep each branch simpler to understand.
This is getting done on the npm stack as part of the big update, which should eliminate a big chunk of the mail even for other maintainers, since that includes a lot of widely depended on modules.
BTW, here's the shell fragment I used to fix this, in case it saves someone time: https://gist.github.com/tchollingsworth/5854722
-T.C.
nodejs@lists.fedoraproject.org
-
Stephen Gallagher -
T.C. Hollingsworth -
Tom Hughes