4:43 a.m.
Hello All!
I've noticed that I cannot build Elixir in Rawhide anymore. It got
stuck at tests and all I've got is a cryptic (at least to me) message:
+ RPM_EC=0
BUILDSTDERR: ++ jobs -p
+ exit 0
See this link for full build log:
* https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
For comparison here is how successful build log for F-30 looks like
(the same package)
* https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
Are there any differences between Koji settings for Rawhide and F-30
which we should know about? Selinux, resource constraints etc?
--
With best regards, Peter Lemenkov.
4:54 a.m.
Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
Hello All!
I've noticed that I cannot build Elixir in Rawhide anymore. It got
stuck at tests and all I've got is a cryptic (at least to me) message:
+ RPM_EC=0
BUILDSTDERR: ++ jobs -p
+ exit 0
See this link for full build log:
* https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
For comparison here is how successful build log for F-30 looks like
(the same package)
* https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
* https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
Are there any differences between Koji settings for Rawhide and F-30
which we should know about? Selinux, resource constraints etc?
This is wrong (not sure if the culprit)
%endif %{__with_rebar3}
I would rewrite it to:
%endif # __with_rebar3
And definitely rawhide has new rpm (see the announced change) and therefore rpmbuild.
There should not be any change which can cause this, but regression is always possible.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
5:25 a.m.
On 6/13/19 12:54 PM, Miroslav Suchý wrote:
Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> Hello All!
> I've noticed that I cannot build Elixir in Rawhide anymore. It got
> stuck at tests and all I've got is a cryptic (at least to me) message:
>
>
> + RPM_EC=0
> BUILDSTDERR: ++ jobs -p
> + exit 0
>
>
> See this link for full build log:
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
>
> For comparison here is how successful build log for F-30 looks like
> (the same package)
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
>
> Are there any differences between Koji settings for Rawhide and F-30
> which we should know about? Selinux, resource constraints etc?
>
This is wrong (not sure if the culprit)
%endif %{__with_rebar3}
I would rewrite it to:
%endif # __with_rebar3
Actually both are wrong, and rpm >= 4.15 will complain (unlike old
versions). Rpm only supports comments at beginning of line, and this
only ever worked by accident.
And definitely rawhide has new rpm (see the announced change) and therefore rpmbuild.
There should not be any change which can cause this, but regression is always possible.
If the cause of failure is the same as
https://bugzilla.redhat.com/show_bug.cgi?id=1720143 then it should be
fixed now as of rpm-4.14.90-0.git14653.14.fc31.
If not, feel free to file a new bug to have it investigated. There's
more than two years worth of new code in the new rpm so there's always a
possibility of regressions. Our built-in test-suite cannot even begin to
compete with rawhide in that :)
- Panu -
10:59 a.m.
On Thu, 2019-06-13 at 13:25 +0300, Panu Matilainen wrote:
On 6/13/19 12:54 PM, Miroslav Suchý wrote:
> Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> > Hello All!
> > I've noticed that I cannot build Elixir in Rawhide anymore. It got
> > stuck at tests and all I've got is a cryptic (at least to me) message:
> >
> >
> > + RPM_EC=0
> > BUILDSTDERR: ++ jobs -p
> > + exit 0
> >
> >
> > See this link for full build log:
> >
> > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
> >
> > For comparison here is how successful build log for F-30 looks like
> > (the same package)
> >
> > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
> >
> > Are there any differences between Koji settings for Rawhide and F-30
> > which we should know about? Selinux, resource constraints etc?
> >
>
> This is wrong (not sure if the culprit)
>
> %endif %{__with_rebar3}
>
> I would rewrite it to:
>
> %endif # __with_rebar3
Actually both are wrong, and rpm >= 4.15 will complain (unlike old
versions). Rpm only supports comments at beginning of line, and this
only ever worked by accident.
Oh dear, that's unfortunate. Because of the lack of indentation,
parsing a nested set of %ifs in spec files has always been difficult,
and adding an end-of-line comment after the %endif to help is
definitely a pattern I've seen in multiple spec files.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
11:42 a.m.
On Thu, Jun 13, 2019 at 12:41 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2019-06-13 at 13:25 +0300, Panu Matilainen wrote:
> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
> > Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
> > > Hello All!
> > > I've noticed that I cannot build Elixir in Rawhide anymore. It got
> > > stuck at tests and all I've got is a cryptic (at least to me)
message:
> > >
> > >
> > > + RPM_EC=0
> > > BUILDSTDERR: ++ jobs -p
> > > + exit 0
> > >
> > >
> > > See this link for full build log:
> > >
> > > * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
> > >
> > > For comparison here is how successful build log for F-30 looks like
> > > (the same package)
> > >
> > > * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> > > * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
> > >
> > > Are there any differences between Koji settings for Rawhide and F-30
> > > which we should know about? Selinux, resource constraints etc?
> > >
> >
> > This is wrong (not sure if the culprit)
> >
> > %endif %{__with_rebar3}
> >
> > I would rewrite it to:
> >
> > %endif # __with_rebar3
>
> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> versions). Rpm only supports comments at beginning of line, and this
> only ever worked by accident.
Oh dear, that's unfortunate. Because of the lack of indentation,
parsing a nested set of %ifs in spec files has always been difficult,
and adding an end-of-line comment after the %endif to help is
definitely a pattern I've seen in multiple spec files.
I guess people don't know you can indent conditional blocks? It's the
only indentation rpmbuild allows, but you can do it.
--
真実はいつも一つ！/ Always, there's only one truth!
2:19 p.m.
On Thu, 2019-06-13 at 12:42 -0400, Neal Gompa wrote:
> > > This is wrong (not sure if the culprit)
> > >
> > > %endif %{__with_rebar3}
> > >
> > > I would rewrite it to:
> > >
> > > %endif # __with_rebar3
> >
> > Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> > versions). Rpm only supports comments at beginning of line, and this
> > only ever worked by accident.
>
> Oh dear, that's unfortunate. Because of the lack of indentation,
> parsing a nested set of %ifs in spec files has always been difficult,
> and adding an end-of-line comment after the %endif to help is
> definitely a pattern I've seen in multiple spec files.
I guess people don't know you can indent conditional blocks? It's the
only indentation rpmbuild allows, but you can do it.
Well, I for one sure didn't...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:23 a.m.
On 6/13/19 6:59 PM, Adam Williamson wrote:
On Thu, 2019-06-13 at 13:25 +0300, Panu Matilainen wrote:
> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>> Dne 13. 06. 19 v 11:43 Peter Lemenkov napsal(a):
>>> Hello All!
>>> I've noticed that I cannot build Elixir in Rawhide anymore. It got
>>> stuck at tests and all I've got is a cryptic (at least to me) message:
>>>
>>>
>>> + RPM_EC=0
>>> BUILDSTDERR: ++ jobs -p
>>> + exit 0
>>>
>>>
>>> See this link for full build log:
>>>
>>> * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
>>> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
>>>
>>> For comparison here is how successful build log for F-30 looks like
>>> (the same package)
>>>
>>> * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
>>> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
>>>
>>> Are there any differences between Koji settings for Rawhide and F-30
>>> which we should know about? Selinux, resource constraints etc?
>>>
>>
>> This is wrong (not sure if the culprit)
>>
>> %endif %{__with_rebar3}
>>
>> I would rewrite it to:
>>
>> %endif # __with_rebar3
>
> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> versions). Rpm only supports comments at beginning of line, and this
> only ever worked by accident.
Oh dear, that's unfortunate. Because of the lack of indentation,
parsing a nested set of %ifs in spec files has always been difficult,
and adding an end-of-line comment after the %endif to help is
definitely a pattern I've seen in multiple spec files.
I know. While the new warning catched several severely broken usages
that actually have side-effects, outlawing innocent comments feels a bit
like throwing the baby out with the bathwater in the name of consistency.
It is just a warning though, so there's no need to go mass-removing
those comments. We might want to revisit that issue, one way or the other.
- Panu -
8:45 a.m.
* Panu Matilainen:
On 6/13/19 12:54 PM, Miroslav Suchý wrote:
> This is wrong (not sure if the culprit)
>
> %endif %{__with_rebar3}
>
> I would rewrite it to:
>
> %endif # __with_rebar3
Actually both are wrong, and rpm >= 4.15 will complain (unlike old
versions). Rpm only supports comments at beginning of line, and this
only ever worked by accident.
Would it be possible to bring back the ability to comment on %endif
lines at least? It's nice to have a comment there if the condition is a
screen or two away.
Thanks,
Florian
2:01 a.m.
On 6/17/19 4:45 PM, Florian Weimer wrote:
* Panu Matilainen:
> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>> This is wrong (not sure if the culprit)
>>
>> %endif %{__with_rebar3}
>>
>> I would rewrite it to:
>>
>> %endif # __with_rebar3
>
> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
> versions). Rpm only supports comments at beginning of line, and this
> only ever worked by accident.
Would it be possible to bring back the ability to comment on %endif
lines at least? It's nice to have a comment there if the condition is a
screen or two away.
Nothing prevents you from putting the comment on the line above:
# __with_rebar3
%endif
- Panu -
2:15 a.m.
* Panu Matilainen:
On 6/17/19 4:45 PM, Florian Weimer wrote:
> * Panu Matilainen:
>
>> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>>> This is wrong (not sure if the culprit)
>>>
>>> %endif %{__with_rebar3}
>>>
>>> I would rewrite it to:
>>>
>>> %endif # __with_rebar3
>>
>> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
>> versions). Rpm only supports comments at beginning of line, and this
>> only ever worked by accident.
>
> Would it be possible to bring back the ability to comment on %endif
> lines at least? It's nice to have a comment there if the condition is a
> screen or two away.
Nothing prevents you from putting the comment on the line above:
# __with_rebar3
%endif
This doesn't follow the usual convention for such comments.
Are # lines stripped always, even in scriptlets?
Thanks,
Florian
6:05 a.m.
On 6/18/19 10:15 AM, Florian Weimer wrote:
* Panu Matilainen:
> On 6/17/19 4:45 PM, Florian Weimer wrote:
>> * Panu Matilainen:
>>
>>> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>>>> This is wrong (not sure if the culprit)
>>>>
>>>> %endif %{__with_rebar3}
>>>>
>>>> I would rewrite it to:
>>>>
>>>> %endif # __with_rebar3
>>>
>>> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
>>> versions). Rpm only supports comments at beginning of line, and this
>>> only ever worked by accident.
>>
>> Would it be possible to bring back the ability to comment on %endif
>> lines at least? It's nice to have a comment there if the condition is a
>> screen or two away.
>
> Nothing prevents you from putting the comment on the line above:
>
> # __with_rebar3
> %endif
This doesn't follow the usual convention for such comments.
Yeah, but then rpm never officially supported the "usual convention". It
was just another spec parser quirk that they got through until now (and
again, it's only a warning still)
Are # lines stripped always, even in scriptlets?
No, because whatever is in scriptlets body belongs to the scriptlet
interpreter which certainly is not rpm. Oh, I know...
To that cause, I just submitted
https://github.com/rpm-software-management/rpm/pull/753. Doesn't help
with comments after %endif though.
- Panu -
6:09 a.m.
* Panu Matilainen:
On 6/18/19 10:15 AM, Florian Weimer wrote:
> * Panu Matilainen:
>
>> On 6/17/19 4:45 PM, Florian Weimer wrote:
>>> * Panu Matilainen:
>>>
>>>> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>>>>> This is wrong (not sure if the culprit)
>>>>>
>>>>> %endif %{__with_rebar3}
>>>>>
>>>>> I would rewrite it to:
>>>>>
>>>>> %endif # __with_rebar3
>>>>
>>>> Actually both are wrong, and rpm >= 4.15 will complain (unlike old
>>>> versions). Rpm only supports comments at beginning of line, and this
>>>> only ever worked by accident.
>>>
>>> Would it be possible to bring back the ability to comment on %endif
>>> lines at least? It's nice to have a comment there if the condition is a
>>> screen or two away.
>>
>> Nothing prevents you from putting the comment on the line above:
>>
>> # __with_rebar3
>> %endif
>
> This doesn't follow the usual convention for such comments.
Yeah, but then rpm never officially supported the "usual
convention". It was just another spec parser quirk that they got
through until now (and again, it's only a warning still)
Still it seemed rather useful.
Can you put a macro invocation after %endif, on the same line? If yes,
we could have macro there that expands to nothing.
> Are # lines stripped always, even in scriptlets?
>
No, because whatever is in scriptlets body belongs to the scriptlet
interpreter which certainly is not rpm. Oh, I know...
To that cause, I just submitted
https://github.com/rpm-software-management/rpm/pull/753. Doesn't help
with comments after %endif though.
Thanks. I like the M4 reference.
Florian
6:48 a.m.
On 6/18/19 2:09 PM, Florian Weimer wrote:
* Panu Matilainen:
> On 6/18/19 10:15 AM, Florian Weimer wrote:
>> * Panu Matilainen:
>>
>>> On 6/17/19 4:45 PM, Florian Weimer wrote:
>>>> * Panu Matilainen:
>>>>
>>>>> On 6/13/19 12:54 PM, Miroslav Suchý wrote:
>>>>>> This is wrong (not sure if the culprit)
>>>>>>
>>>>>> %endif %{__with_rebar3}
>>>>>>
>>>>>> I would rewrite it to:
>>>>>>
>>>>>> %endif # __with_rebar3
>>>>>
>>>>> Actually both are wrong, and rpm >= 4.15 will complain (unlike
old
>>>>> versions). Rpm only supports comments at beginning of line, and this
>>>>> only ever worked by accident.
>>>>
>>>> Would it be possible to bring back the ability to comment on %endif
>>>> lines at least? It's nice to have a comment there if the condition
is a
>>>> screen or two away.
>>>
>>> Nothing prevents you from putting the comment on the line above:
>>>
>>> # __with_rebar3
>>> %endif
>>
>> This doesn't follow the usual convention for such comments.
>
> Yeah, but then rpm never officially supported the "usual
> convention". It was just another spec parser quirk that they got
> through until now (and again, it's only a warning still)
Still it seemed rather useful.
Can you put a macro invocation after %endif, on the same line? If yes,
we could have macro there that expands to nothing.
You can, and that's pretty much the reason for this warning because it's
*not* what you'd expect [*]. For example, %define and %global expand to
nothing... and any text following %else or %endif gets treated as part
of the preceeding block, ie text following %else on the same line gets
expanded when the %if-condition is true. Yes, you read that right.
So if you have
%if 1 == 1
echo moo
%else # %define aaa bbb
echo foo
%endif # %define aaa ccc
...the value of aaa macro is actually bbb after parsing this. Those
%define's could also be there without the comment marks and behave the
same deed.
So the new warning has to look at the line *before* expanding it, so a
macro wont help with that. Rpm could of course specifically handle #
-comments there, but for consistency it should allow free # -comments
everywhere then.
[*] For the full horror, see
https://github.com/rpm-software-management/rpm/pull/625. And if you read
that, you'll find that I'm also a bit torn on the issue of losing those
comments after %endif.
- Panu -
7:56 a.m.
* Panu Matilainen:
So if you have
%if 1 == 1
echo moo
%else # %define aaa bbb
echo foo
%endif # %define aaa ccc
...the value of aaa macro is actually bbb after parsing this. Those
%define's could also be there without the comment marks and behave the
same deed.
So the new warning has to look at the line *before* expanding it, so a
macro wont help with that. Rpm could of course specifically handle #
-comments there, but for consistency it should allow free # -comments
everywhere then.
Not sure if I understand. Are you saying that
%endif%{discard:__with_rebar3}
will not work either?
Thanks,
Florian
8:08 a.m.
On 6/18/19 3:56 PM, Florian Weimer wrote:
* Panu Matilainen:
> So if you have
>
> %if 1 == 1
> echo moo
> %else # %define aaa bbb
> echo foo
> %endif # %define aaa ccc
>
> ...the value of aaa macro is actually bbb after parsing this. Those
> %define's could also be there without the comment marks and behave the
> same deed.
>
> So the new warning has to look at the line *before* expanding it, so a
> macro wont help with that. Rpm could of course specifically handle #
> -comments there, but for consistency it should allow free # -comments
> everywhere then.
Not sure if I understand. Are you saying that
%endif%{discard:__with_rebar3}
will not work either?
Yes, that's what I'm saying. Or rather, you'd get the warning with that
too. It all *behaves* exactly the same as before, so it continues to "work".
- Panu -
12:35 p.m.
> Not sure if I understand. Are you saying that
>
> %endif%{discard:__with_rebar3}
>
> will not work either?
Yes, that's what I'm saying. Or rather, you'd get the warning with that
too. It all *behaves* exactly the same as before, so it continues to "work".
Could this ugly hack work?
%{endif __with_rebar3}
Assuming the %endif macro would ignore any parameters.
Dridi
4:21 a.m.
New subject: Spec/macro comments (was: Any new restriction in Koji added recently
in Rawhide?)
On 6/18/19 2:05 PM, Panu Matilainen wrote:
On 6/18/19 10:15 AM, Florian Weimer wrote:
> * Panu Matilainen:
>
> Are # lines stripped always, even in scriptlets?
>
No, because whatever is in scriptlets body belongs to the scriptlet
interpreter which certainly is not rpm. Oh, I know...
To that cause, I just submitted
https://github.com/rpm-software-management/rpm/pull/753. Doesn't help
with comments after %endif though.
Just FWIW, %dnl support is now in rawhide.
What it means in practise is that for the first time there's now a way
to escape macro expansion for the rest of the line (so eg multiline
macros such as %configure can be commented out with it), it's possible
to add comments to macros themselves and comments can appear anywhere in
the spec.
The classical example of this is comments intended for the scriptlet
below ending up in the previous scriptlet body.
---
%post -p /sbin/ldconfig
%dnl postun is needed to handle foo
%postun
%dnl always do bar first
%{_bindir}/do_bar
%{_bindir}/do_foo
---
...results in:
$ rpm -qp --scripts scriptintr-1.0-1.fc30.noarch.rpm
postinstall program: /sbin/ldconfig
postuninstall scriptlet (using /bin/sh):
/usr/bin/do_bar
/usr/bin/do_foo
...wheras #-comments would end up in the package and in case of "postun
is needed to handle foo", in the body of the wrong scriptlet that will
cause ldconfig to complain.
- Panu -
4:56 a.m.
You may consider adding your package to the Koschei service:
https://apps.fedoraproject.org/koschei/package/python-elixir which
will do rebuilds when the buildroot change, and it will show you the
changes in a well readable way.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Thu, Jun 13, 2019 at 11:44 AM Peter Lemenkov <lemenkov(a)gmail.com> wrote:
>
> Hello All!
> I've noticed that I cannot build Elixir in Rawhide anymore. It got
> stuck at tests and all I've got is a cryptic (at least to me) message:
>
>
> + RPM_EC=0
> BUILDSTDERR: ++ jobs -p
> + exit 0
>
>
> See this link for full build log:
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8021/35518021/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35517975
>
> For comparison here is how successful build log for F-30 looks like
> (the same package)
>
> * https://kojipkgs.fedoraproject.org//work/tasks/8987/35518987/build.log
> * https://koji.fedoraproject.org/koji/taskinfo?taskID=35518984
>
> Are there any differences between Koji settings for Rawhide and F-30
> which we should know about? Selinux, resource constraints etc?
> --
> With best regards, Peter Lemenkov.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
4:59 a.m.
On 2019-06-13, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
I've noticed that I cannot build Elixir in Rawhide anymore. It
got
stuck at tests and all I've got is a cryptic (at least to me) message:
+ RPM_EC=0
BUILDSTDERR: ++ jobs -p
+ exit 0
F31 has a new rpm-build with a new features. Your issue seems like
another bug in the same process clean-up code I reported an hour ago.
See bug #1720143.
-- Petr
6:03 a.m.
Hello!
чт, 13 июн. 2019 г. в 12:49, Petr Pisar <ppisar(a)redhat.com>:
On 2019-06-13, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
> I've noticed that I cannot build Elixir in Rawhide anymore. It got
> stuck at tests and all I've got is a cryptic (at least to me) message:
>
>
> + RPM_EC=0
> BUILDSTDERR: ++ jobs -p
> + exit 0
>
F31 has a new rpm-build with a new features. Your issue seems like
another bug in the same process clean-up code I reported an hour ago.
See bug #1720143.
Yes, looks exactly like my case. Thanks for the pointing out!
--
With best regards, Peter Lemenkov.
11:02 a.m.
On Thu, 2019-06-13 at 13:03 +0200, Peter Lemenkov wrote:
Hello!
чт, 13 июн. 2019 г. в 12:49, Petr Pisar <ppisar(a)redhat.com>:
> On 2019-06-13, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
> > I've noticed that I cannot build Elixir in Rawhide anymore. It
> > got
> > stuck at tests and all I've got is a cryptic (at least to me)
> > message:
> >
> >
> > + RPM_EC=0
> > BUILDSTDERR: ++ jobs -p
> > + exit 0
> >
> F31 has a new rpm-build with a new features. Your issue seems like
> another bug in the same process clean-up code I reported an hour
> ago.
> See bug #1720143.
Yes, looks exactly like my case. Thanks for the pointing out!
Is fixed for me
Best regards,
--
Sérgio M. B.
7:09 p.m.
On Thu, 2019-06-13 at 17:02 +0100, Sérgio Basto wrote:
On Thu, 2019-06-13 at 13:03 +0200, Peter Lemenkov wrote:
> Hello!
>
> чт, 13 июн. 2019 г. в 12:49, Petr Pisar <ppisar(a)redhat.com>:
> > On 2019-06-13, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
> > > I've noticed that I cannot build Elixir in Rawhide anymore. It
> > > got
> > > stuck at tests and all I've got is a cryptic (at least to me)
> > > message:
> > >
> > >
> > > + RPM_EC=0
> > > BUILDSTDERR: ++ jobs -p
> > > + exit 0
> > >
> > F31 has a new rpm-build with a new features. Your issue seems
> > like
> > another bug in the same process clean-up code I reported an hour
> > ago.
> > See bug #1720143.
>
> Yes, looks exactly like my case. Thanks for the pointing out!
Is fixed for me
I mixed my builds, I still have issues with libprojectM [1] , but seems
a little different that is reported [2]
[1]
https://koji.fedoraproject.org/koji/taskinfo?taskID=35530649
[2]
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
BUILDSTDERR: xargs: unmatched single quote; by default quotes are special to xargs unless
you use the -0 option
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install)
BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install)
tM-3.1.1-0.6.rc4.fc31.x86_64/usr/lib64/libprojectM.so.3.1.1
Best regards,
--
Sérgio M. B.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Sérgio M. B.
2:16 a.m.
On 6/14/19 3:09 AM, Sérgio Basto wrote:
I mixed my builds, I still have issues with libprojectM [1] , but
seems
a little different that is reported [2]
[1]
https://koji.fedoraproject.org/koji/taskinfo?taskID=35530649
[2]
+ /usr/lib/rpm/brp-strip-static-archive /usr/bin/strip
BUILDSTDERR: xargs: unmatched single quote; by default quotes are special to xargs unless
you use the -0 option
BUILDSTDERR: error: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install)
BUILDSTDERR: Bad exit status from /var/tmp/rpm-tmp.ojGFZw (%install)
tM-3.1.1-0.6.rc4.fc31.x86_64/usr/lib64/libprojectM.so.3.1.1
Please file a new bug, this is an entirely different issue.
- Panu -
1763
days inactive
1777
days old
23 comments
10 participants
participants (10)
-
Adam Williamson -
Dridi Boukelmoune -
Florian Weimer -
Michal Schorm -
Miroslav Suchý -
Neal Gompa -
Panu Matilainen -
Peter Lemenkov -
Petr Pisar -
Sérgio Basto