9:03 p.m.
Hi,
I occasionally get this strange failure in koji. Sometimes this happens
with a good package build, and I can just re-submit it without changing
anything, and it works fine. Is this a known issue?
For example, from
https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:
sh: /usr/bin/python: No such file or directory
warning: Could not canonicalize hostname: buildvm-14.phx2.fedoraproject.org
--
Christopher
9:13 p.m.
On Thu, 22 Dec 2016 03:03:56 +0000
Christopher <ctubbsii(a)fedoraproject.org> wrote:
Hi,
I occasionally get this strange failure in koji. Sometimes this
happens with a good package build, and I can just re-submit it
without changing anything, and it works fine. Is this a known issue?
For example, from
https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:
sh: /usr/bin/python: No such file or directory
warning: Could not canonicalize hostname:
buildvm-14.phx2.fedoraproject.org
Please when posting koji links, post a link to the top level task.
If you post directly to build.log or the like it takes some work to
find the actual task and the other logs (where often the problem is).
The above is just a warning and doesn't matter, the true failure is in
the root.log:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17021330
https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/root.log
DEBUG util.py:426: Error: No Package found for checkstyle
DEBUG util.py:426: Error: No Package found for ivy-local
DEBUG util.py:426: Error: No Package found for jdiff
DEBUG util.py:426: Error: No Package found for jtoaster
DEBUG util.py:426: Error: No Package found for netty
DEBUG util.py:564: Child return code was: 1
epel7 doesn't have those BuildRequires, so the package build fails.
kevin
10:06 p.m.
On Wed, Dec 21, 2016 at 10:14 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On Thu, 22 Dec 2016 03:03:56 +0000
Christopher <ctubbsii(a)fedoraproject.org> wrote:
> Hi,
>
> I occasionally get this strange failure in koji. Sometimes this
> happens with a good package build, and I can just re-submit it
> without changing anything, and it works fine. Is this a known issue?
>
> For example, from
> https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/build.log:
>
> sh: /usr/bin/python: No such file or directory
>
> warning: Could not canonicalize hostname:
> buildvm-14.phx2.fedoraproject.org
Please when posting koji links, post a link to the top level task.
If you post directly to build.log or the like it takes some work to
find the actual task and the other logs (where often the problem is).
Sorry about that. Will try to do better next time.
The above is just a warning and doesn't matter, the true failure
is in
the root.log:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17021330
https://kojipkgs.fedoraproject.org//work/tasks/1330/17021330/root.log
Forgot to check that. Usually the failures I see are in build.log (because
it's my fault).
DEBUG util.py:426: Error: No Package found for checkstyle
DEBUG util.py:426: Error: No Package found for ivy-local
DEBUG util.py:426: Error: No Package found for jdiff
DEBUG util.py:426: Error: No Package found for jtoaster
DEBUG util.py:426: Error: No Package found for netty
DEBUG util.py:564: Child return code was: 1
epel7 doesn't have those BuildRequires, so the package build fails.
kevin
Well, crap, this was a bad example. Sorry about that. I saw a problem
yesterday with one of the jquery builds I ran, and thought that this was a
similar error. I should have asked about the earlier failure when it was
easier to find.
The failure yesterday that I was thinking of was:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
Re-submitting it 4 minutes later passed just fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
I shouldn't have jumped to conclusions thinking today's failure was
related. :)
--
Christopher
2:27 a.m.
On 12/22/2016 05:06 AM, Christopher wrote:
The failure yesterday that I was thinking of was:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
Re-submitting it 4 minutes later passed just fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
These builds were ran on different architectures - the first one on
aarch64 and the second one - x86_64. nodejs package is available only on
x86_64, so failure on aarch64 was expected.
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
2:50 a.m.
Dne 22.12.2016 v 09:27 Mikolaj Izdebski napsal(a):
On 12/22/2016 05:06 AM, Christopher wrote:
> The failure yesterday that I was thinking of was:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
>
> Re-submitting it 4 minutes later passed just fine:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
These builds were ran on different architectures - the first one on
aarch64 and the second one - x86_64. nodejs package is available only on
x86_64, so failure on aarch64 was expected.
Honestly this is annoying misbehavior. How we can tell Koji to avoid
certain builders for certain noarch packages? Wouldn't be possible to
build noarch packages just on primary arch builders for example?
Vít
3:12 a.m.
On Thursday, December 22, 2016 9:50:12 AM CET Vít Ondruch wrote:
Dne 22.12.2016 v 09:27 Mikolaj Izdebski napsal(a):
> On 12/22/2016 05:06 AM, Christopher wrote:
>> The failure yesterday that I was thinking of was:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
>>
>> Re-submitting it 4 minutes later passed just fine:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
> These builds were ran on different architectures - the first one on
> aarch64 and the second one - x86_64. nodejs package is available only on
> x86_64, so failure on aarch64 was expected.
>
Honestly this is annoying misbehavior. How we can tell Koji to avoid
certain builders for certain noarch packages?
There used to be a koji target for documentation, using that caused that
'x86_64' or 'i686' builders were chosen. But it seems those are not
there
anymore.
Wouldn't be possible to build noarch packages just on primary
arch builders
for example?
Those arches are all primary .. but ExclusiveArch could help.
Pavel
4:16 a.m.
Dne 22.12.2016 v 10:12 Pavel Raiskup napsal(a):
On Thursday, December 22, 2016 9:50:12 AM CET Vít Ondruch wrote:
> Wouldn't be possible to build noarch packages just on primary arch builders
> for example?
Those arches are all primary .. but ExclusiveArch could help.
No, not all arches build in Koji are primary arches ...
https://fedoraproject.org/wiki/Architectures#Secondary_Architectures
Vít
4:37 a.m.
On Thu, Dec 22, 2016 at 10:16 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 22.12.2016 v 10:12 Pavel Raiskup napsal(a):
> On Thursday, December 22, 2016 9:50:12 AM CET Vít Ondruch wrote:
>
>> Wouldn't be possible to build noarch packages just on primary arch builders
>> for example?
> Those arches are all primary .. but ExclusiveArch could help.
No, not all arches build in Koji are primary arches ...
https://fedoraproject.org/wiki/Architectures#Secondary_Architectures
The term is generally Alternate Architectures, then we have the
hipster ones like mips/risc-v which are generally referred to as
Experimental Architectures. We now have primary and secondary release
artifacts.
Peter
10:12 a.m.
On Thu, Dec 22, 2016 at 5:16 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 22.12.2016 v 10:12 Pavel Raiskup napsal(a):
> On Thursday, December 22, 2016 9:50:12 AM CET Vít Ondruch wrote:
>
>> Wouldn't be possible to build noarch packages just on primary arch builders
>> for example?
> Those arches are all primary .. but ExclusiveArch could help.
No, not all arches build in Koji are primary arches ...
https://fedoraproject.org/wiki/Architectures#Secondary_Architectures
Starting with F26, they almost all are:
https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitect...
s390x and the Experimental Architectures Peter mentioned are the only
ones that are not driven and built from the primary hub.
josh
3:33 a.m.
On 2016-12-22, Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Thursday, December 22, 2016 9:50:12 AM CET Vít Ondruch wrote:
>
> Dne 22.12.2016 v 09:27 Mikolaj Izdebski napsal(a):
> > On 12/22/2016 05:06 AM, Christopher wrote:
> >> The failure yesterday that I was thinking of was:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
> >>
> >> Re-submitting it 4 minutes later passed just fine:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
> > These builds were ran on different architectures - the first one on
> > aarch64 and the second one - x86_64. nodejs package is available only on
> > x86_64, so failure on aarch64 was expected.
> >
>
> Honestly this is annoying misbehavior. How we can tell Koji to avoid
> certain builders for certain noarch packages?
There used to be a koji target for documentation, using that caused that
'x86_64' or 'i686' builders were chosen. But it seems those are not
there
anymore.
> Wouldn't be possible to build noarch packages just on primary arch builders
> for example?
Those arches are all primary .. but ExclusiveArch could help.
No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch and
I still receive reports about broken compose and Koschei reports build
failures when koji picks up unlisted archictecture.
-- Petr
3:42 a.m.
On Friday, December 23, 2016 9:33:31 AM CET Petr Pisar wrote:
>> Wouldn't be possible to build noarch packages just on
primary arch builders
>> for example?
>
> Those arches are all primary .. but ExclusiveArch could help.
>
No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch and
I still receive reports about broken compose
Is this the bug?
https://pagure.io/pungi-fedora/issue/87
and Koschei reports build failures when koji picks up unlisted
archictecture.
Is this problem of Koschei or somewhere else? Have you tried to report?
Thanks,
Pavel
3:46 a.m.
On Friday, December 23, 2016 10:42:33 AM CET Pavel Raiskup wrote:
On Friday, December 23, 2016 9:33:31 AM CET Petr Pisar wrote:
> >> Wouldn't be possible to build noarch packages just on primary arch
builders
> >> for example?
> >
> > Those arches are all primary .. but ExclusiveArch could help.
> >
> No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch and
> I still receive reports about broken compose
Is this the bug?
https://pagure.io/pungi-fedora/issue/87
Sorry, this one:
https://bugzilla.redhat.com/show_bug.cgi?id=1298668
(the first is the "subpackage" issue)
> and Koschei reports build failures when koji picks up unlisted
archictecture.
Is this problem of Koschei or somewhere else? Have you tried to report?
Thanks,
Pavel
4:30 a.m.
On 2016-12-23, Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Friday, December 23, 2016 10:42:33 AM CET Pavel Raiskup wrote:
> On Friday, December 23, 2016 9:33:31 AM CET Petr Pisar wrote:
> > >> Wouldn't be possible to build noarch packages just on primary
> > >> arch builders for example?
> > >
> > > Those arches are all primary .. but ExclusiveArch could help.
> > >
> > No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch
> > and I still receive reports about broken compose
>
> Is this the bug? https://pagure.io/pungi-fedora/issue/87
Sorry, this one: https://bugzilla.redhat.com/show_bug.cgi?id=1298668
No. This is a generic problem that the ExclusiveArch hack as documents in
packaging guidelines (i.e. noarch package with ExclusiveArch including
noarch) is not honored by infrastructure.
It started happen half year ago when infrastruture migrated to the new
compose database, I reported it into Fedora Hosted Track where nobody
respodned and then few months later infrastructure shutted down the
Track and moved to Pagure without migrating existing bug reports.
> > and Koschei reports build failures when koji picks up
unlisted
> > archictecture.
>
> Is this problem of Koschei or somewhere else? Have you tried to
> report?
Koschei is only a symptom because it uses koji. There is nothing wrong
with Koschei.
-- Petr
11:01 a.m.
On Fri, 23 Dec 2016 10:30:12 +0000 (UTC)
Petr Pisar <ppisar(a)redhat.com> wrote:
On 2016-12-23, Pavel Raiskup <praiskup(a)redhat.com> wrote:
> On Friday, December 23, 2016 10:42:33 AM CET Pavel Raiskup wrote:
>> On Friday, December 23, 2016 9:33:31 AM CET Petr Pisar wrote:
>> > >> Wouldn't be possible to build noarch packages just on primary
>> > >> arch builders for example?
>> > >
>> > > Those arches are all primary .. but ExclusiveArch could help.
>> > >
>> > No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch
>> > and I still receive reports about broken compose
>>
>> Is this the bug? https://pagure.io/pungi-fedora/issue/87
>
> Sorry, this one: https://bugzilla.redhat.com/show_bug.cgi?id=1298668
>
No. This is a generic problem that the ExclusiveArch hack as
documents in packaging guidelines (i.e. noarch package with
ExclusiveArch including noarch) is not honored by infrastructure.
Sure, if by Infrastructure you mean koji. :)
It started happen half year ago when infrastruture migrated to the
new
compose database, I reported it into Fedora Hosted Track where nobody
respodned and then few months later infrastructure shutted down the
Track and moved to Pagure without migrating existing bug reports.
I don't see how the compose db has anything to do with this at all.
Do you have any links to the tickets? Also I don't know of any
infrastructure repo that was moved from trac -> pagure without also
moving old tickets. Which exact trac was this?
>> > and Koschei reports build failures when koji picks up
unlisted
>> > archictecture.
>>
>> Is this problem of Koschei or somewhere else? Have you tried to
>> report?
Koschei is only a symptom because it uses koji. There is nothing wrong
with Koschei.
Right.
kevin
7:59 a.m.
On 2016-12-24, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 23 Dec 2016 10:30:12 +0000 (UTC)
Petr Pisar <ppisar(a)redhat.com> wrote:
> No. This is a generic problem that the ExclusiveArch hack as
> documents in packaging guidelines (i.e. noarch package with
> ExclusiveArch including noarch) is not honored by infrastructure.
Sure, if by Infrastructure you mean koji. :)
Yes. Koji. They had the same Track instance, didn't?
> It started happen half year ago when infrastruture migrated to
the new
> compose database, I reported it into Fedora Hosted Track where nobody
> respodned and then few months later infrastructure shutted down the
> Track and moved to Pagure without migrating existing bug reports.
I don't see how the compose db has anything to do with this at all.
I think the email reports about broken dependencies are generarated from
compose database. I noticed the issue with failing builds much later.
Maybe it's a different issue, maybe I only was lucky not to hit the
affected builders sooner.
Do you have any links to the tickets?
No. I delete old e-mails. There was nothing spectacular in the ticket.
Just a complain that the document procedure is not honored anymore.
Also I don't know of any
infrastructure repo that was moved from trac -> pagure without also
moving old tickets. Which exact trac was this?
I think it was <https://fedorahosted.org/fedora-infrastructure/ticket/>;.
-- Petr
11:05 a.m.
On Mon, 2 Jan 2017 13:59:25 +0000 (UTC)
Petr Pisar <ppisar(a)redhat.com> wrote:
On 2016-12-24, Kevin Fenzi <kevin(a)scrye.com> wrote:
> On Fri, 23 Dec 2016 10:30:12 +0000 (UTC)
> Petr Pisar <ppisar(a)redhat.com> wrote:
>> No. This is a generic problem that the ExclusiveArch hack as
>> documents in packaging guidelines (i.e. noarch package with
>> ExclusiveArch including noarch) is not honored by infrastructure.
>
> Sure, if by Infrastructure you mean koji. :)
>
Yes. Koji. They had the same Track instance, didn't?
No. Infrastructure controls configuration and deployment of Fedora's
koji instance(s). If it's not something we can fix in configuration or
deployment, it should be filed upstream with the upstream koji
developers.
>> It started happen half year ago when infrastruture migrated to the
>> new compose database, I reported it into Fedora Hosted Track where
>> nobody respodned and then few months later infrastructure shutted
>> down the Track and moved to Pagure without migrating existing bug
>> reports.
>
> I don't see how the compose db has anything to do with this at
> all.
I think the email reports about broken dependencies are generarated
from compose database. I noticed the issue with failing builds much
later. Maybe it's a different issue, maybe I only was lucky not to
hit the affected builders sooner.
The broken dependency reports for rawhide are generated by
the /usr/share/mash/spam-o-matic script that is in the 'mash' package.
(as it always has been).
> Do you have any links to the tickets?
No. I delete old e-mails. There was nothing spectacular in the ticket.
Just a complain that the document procedure is not honored anymore.
> Also I don't know of any
> infrastructure repo that was moved from trac -> pagure without also
> moving old tickets. Which exact trac was this?
>
I think it was
<https://fedorahosted.org/fedora-infrastructure/ticket/>;.
All old tickets were migrated from that instance to the new pagure one.
They even have the same ticket numbers. They even have a redirect from
the old trac link to the new pagure tickets. ;)
Anyhow, enough of the past... I think this is something for koji
upstream to solve in the end.
kevin
3:56 a.m.
On 12/23/2016 10:42 AM, Pavel Raiskup wrote:
On Friday, December 23, 2016 9:33:31 AM CET Petr Pisar wrote:
>>> Wouldn't be possible to build noarch packages just on primary arch
builders
>>> for example?
>>
>> Those arches are all primary .. but ExclusiveArch could help.
>>
> No, it does not. I have noarch perl-Alien-ROOT with ExclusiveArch and
> I still receive reports about broken compose
Is this the bug?
https://pagure.io/pungi-fedora/issue/87
> and Koschei reports build failures when koji picks up unlisted archictecture.
Is this problem of Koschei or somewhere else? Have you tried to report?
Koschei merely calls Koji to rebuild SRPM. It does not parse them or
spec files. It's up to Koji to decide on which architectures to build
the SRPM.
There is a way in Koschei to override architectures on which builds are
ran. See https://fedoraproject.org/wiki/Koschei#Setting_arch_override
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
3:15 a.m.
On 12/22/2016 09:50 AM, Vít Ondruch wrote:
Dne 22.12.2016 v 09:27 Mikolaj Izdebski napsal(a):
> On 12/22/2016 05:06 AM, Christopher wrote:
>> The failure yesterday that I was thinking of was:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
>>
>> Re-submitting it 4 minutes later passed just fine:
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
> These builds were ran on different architectures - the first one on
> aarch64 and the second one - x86_64. nodejs package is available only on
> x86_64, so failure on aarch64 was expected.
>
Honestly this is annoying misbehavior. How we can tell Koji to avoid
certain builders for certain noarch packages? Wouldn't be possible to
build noarch packages just on primary arch builders for example?
It is doable by using Koji channels.
Koji has a policy which could be used to select channel automatically
depending on various things, like package name. For example, eclipse
packages are built in their own eclipse channel. See [1].
Packager can override channel manually when needed. When submitting
build, you can choose which channel to use. For example, when you want
the build to be ran on x86_64 you can select "livecd" channel [2], which
contains only x86_64 hosts. In this case the build [3] will be ran on
one of x86_64 builders.
[1]
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/koji...
[2] https://koji.fedoraproject.org/koji/channelinfo?channelID=6
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=13711755
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
11:03 a.m.
On Thu, 22 Dec 2016 10:15:57 +0100
Mikolaj Izdebski <mizdebsk(a)redhat.com> wrote:
On 12/22/2016 09:50 AM, Vít Ondruch wrote:
>
>
> Dne 22.12.2016 v 09:27 Mikolaj Izdebski napsal(a):
>> On 12/22/2016 05:06 AM, Christopher wrote:
>>> The failure yesterday that I was thinking of was:
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
>>>
>>> Re-submitting it 4 minutes later passed just fine:
>>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
>> These builds were ran on different architectures - the first one on
>> aarch64 and the second one - x86_64. nodejs package is available
>> only on x86_64, so failure on aarch64 was expected.
>>
>
> Honestly this is annoying misbehavior. How we can tell Koji to avoid
> certain builders for certain noarch packages? Wouldn't be possible
> to build noarch packages just on primary arch builders for
> example?
It is doable by using Koji channels.
Koji has a policy which could be used to select channel automatically
depending on various things, like package name. For example, eclipse
packages are built in their own eclipse channel. See [1].
I really would hate to try and update this conf for every single noarch
package that doesn't build on all arches. It would be a lot of work and
error prone. ;(
Packager can override channel manually when needed. When submitting
build, you can choose which channel to use. For example, when you want
the build to be ran on x86_64 you can select "livecd" channel [2],
which contains only x86_64 hosts. In this case the build [3] will be
ran on one of x86_64 builders.
I don't think there's any way to do this from the koji command line is
there?
kevin
--
11:28 p.m.
> >>> The failure yesterday that I was thinking of was:
> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004112
> >>>
> >>> Re-submitting it 4 minutes later passed just fine:
> >>> https://koji.fedoraproject.org/koji/taskinfo?taskID=17004125
> >> These builds were ran on different architectures - the first one on
> >> aarch64 and the second one - x86_64. nodejs package is available
> >> only on x86_64, so failure on aarch64 was expected.
It is planned to have nodejs for EPEL on all architectures supported
by EPEL. The only reason it's not currently is due to a bug with a
package shipped with RHEL which means we either need to overrde the
defined macro or get it fix (or IMO dropoed) from the RHEL package.
> > Honestly this is annoying misbehavior. How we can tell Koji
to avoid
> > certain builders for certain noarch packages? Wouldn't be possible
> > to build noarch packages just on primary arch builders for
> > example?
Define "primary arch builders" as we have primary/secondary
deliverables but architectures are x86_64 and Alternate architectures
now.
> It is doable by using Koji channels.
>
> Koji has a policy which could be used to select channel automatically
> depending on various things, like package name. For example, eclipse
> packages are built in their own eclipse channel. See [1].
I really would hate to try and update this conf for every single noarch
package that doesn't build on all arches. It would be a lot of work and
error prone. ;(
> Packager can override channel manually when needed. When submitting
> build, you can choose which channel to use. For example, when you want
> the build to be ran on x86_64 you can select "livecd" channel [2],
> which contains only x86_64 hosts. In this case the build [3] will be
> ran on one of x86_64 builders.
I don't think there's any way to do this from the koji command line is
there?
No there's not and there's no reason to say that those channel will
remain as x86 only either.
10:14 a.m.
On 12/24/2016 06:03 PM, Kevin Fenzi wrote:
> Packager can override channel manually when needed. When
submitting
> build, you can choose which channel to use. For example, when you want
> the build to be ran on x86_64 you can select "livecd" channel [2],
> which contains only x86_64 hosts. In this case the build [3] will be
> ran on one of x86_64 builders.
I don't think there's any way to do this from the koji command line is
there?
It is possible from CLI for admin users (using "koji make-task").
For non-admin users it is still possible with XML-RPC API:
$ koji list-api | grep -A7 'build('
Or with Python API:
#!/usr/bin/python
import koji
s = koji.ClientSession('http://koji.fedoraproject.org/kojihub')
s.gssapi_login()
print('Task created:
http://koji.fedoraproject.org/koji/taskinfo?taskID=%d' %
s.build('git://pkgs.fedoraproject.org/rpms/geronimo-jta?#430498207b8f...;,
'f26', {}, 0, 'livecd'))
--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
3:26 a.m.
Hi Vít Ondruch:
Honestly this is annoying misbehavior. How we can tell Koji to avoid
certain builders for certain noarch packages? Wouldn't be possible to
build noarch packages just on primary arch builders for example?
Will ExclusiveArch: %{nodejs_arches} noarch help?
https://fedoraproject.org/wiki/Packaging:Node.js#ExclusiveArch
Jonny
1:06 a.m.
I understand this was not the cause to FTBFS, but FTR:
On Thursday, December 22, 2016 3:03:56 AM CET Christopher wrote:
sh: /usr/bin/python: No such file or directory
https://bugzilla.redhat.com/1243292
warning: Could not canonicalize hostname:
buildvm-14.phx2.fedoraproject.org
https://github.com/rpm-software-management/rpm/blob/ff43d03d1f9686c9ffa92...
Pavel
3:19 a.m.
Honestly this is annoying misbehavior. How we can tell Koji to avoid
certain builders for certain noarch packages? Wouldn't be possible to
build noarch packages just on primary arch builders for example?
You can. (make it arch specific)
It doesn't make any sense to me - you want noarch package, but only on
specific architectures ??
Even if you solve it your way, what would it be good for? (I'm kinda
curious)
https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Support
--
Michal Schorm
Core Services - Databases Team
mail: mschorm(a)redhat.com
Brno-IRC: mschorm
3:23 a.m.
On 22/12/16 09:19, Michal Schorm wrote:
> Honestly this is annoying misbehavior. How we can tell Koji to
avoid
> certain builders for certain noarch packages? Wouldn't be possible to
> build noarch packages just on primary arch builders for example?
You can. (make it arch specific)
It doesn't make any sense to me - you want noarch package, but only on
specific architectures ??
The problem is things which have a runtime engine that is arch specific
and not available on all arches.
So in the case here the package is noarch because it's pure javascript
but the javascript engine (nodejs itself) is compiled code that is arch
specific and not available everywhere, at least for the version in EPEL.
Similar problems exist with some other interpreted languages I believe
where the interpreter itself is not universally available.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
3:59 a.m.
Dne 22.12.2016 v 10:23 Tom Hughes napsal(a):
On 22/12/16 09:19, Michal Schorm wrote:
>> Honestly this is annoying misbehavior. How we can tell Koji to avoid
>> certain builders for certain noarch packages? Wouldn't be possible to
>> build noarch packages just on primary arch builders for example?
>
> You can. (make it arch specific)
> It doesn't make any sense to me - you want noarch package, but only on
> specific architectures ??
The problem is things which have a runtime engine that is arch
specific and not available on all arches.
So in the case here the package is noarch because it's pure javascript
but the javascript engine (nodejs itself) is compiled code that is
arch specific and not available everywhere, at least for the version
in EPEL.
Similar problems exist with some other interpreted languages I believe
where the interpreter itself is not universally available.
Tom
In my specific case, rubygem-mongo is MongoDB client and it needs
MondoDB server (which does not support BE architectures) to execute its
test suite. But otherwise it can run on all platforms and connect to
remote server just fine.
Vít
5:20 a.m.
On 12/22/2016 10:59 AM, Vít Ondruch wrote:
In my specific case, rubygem-mongo is MongoDB client and it needs
MondoDB server (which does not support BE architectures) to execute its
test suite. But otherwise it can run on all platforms and connect to
remote server just fine.
Hasn't this mongodb issue been fixed upstream?
<https://jira.mongodb.org/browse/SERVER-21252>
Thanks,
Florian
5:24 a.m.
New subject: MongoDB on Big Endian
Dne 22.12.2016 v 12:20 Florian Weimer napsal(a):
On 12/22/2016 10:59 AM, Vít Ondruch wrote:
> In my specific case, rubygem-mongo is MongoDB client and it needs
> MondoDB server (which does not support BE architectures) to execute its
> test suite. But otherwise it can run on all platforms and connect to
> remote server just fine.
Hasn't this mongodb issue been fixed upstream?
<https://jira.mongodb.org/browse/SERVER-21252>
Good question. Lets see what mongodb maintainers thinks about that ....
Vít
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
8:03 a.m.
New subject: MongoDB on Big Endian
Hi,
MongoDB upstream does not support ppc64 BE.
But there is support for s390x, so code is ported/ready for Big Endian. I've managed
to make MongoDB building and passing basic tests on ppc64.
So in rawhide in latest build, all fedora primary architectures are functional. Testing is
very welcomed.
Marek
8:09 a.m.
New subject: MongoDB on Big Endian
Cool \ó/
Thx
V.
Dne 10.1.2017 v 15:03 Marek Skalický napsal(a):
Hi,
MongoDB upstream does not support ppc64 BE.
But there is support for s390x, so code is ported/ready for Big Endian. I've managed
to make MongoDB building and passing basic tests on ppc64.
So in rawhide in latest build, all fedora primary architectures are functional. Testing
is very welcomed.
Marek
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
2657
days inactive
2676
days old
29 comments
13 participants
participants (13)
-
Christopher -
Florian Weimer -
Jonny Heggheim -
Josh Boyer -
Kevin Fenzi -
Marek Skalický -
Michal Schorm -
Mikolaj Izdebski -
Pavel Raiskup -
Peter Robinson -
Petr Pisar -
Tom Hughes -
Vít Ondruch