Re: Proposal: Abandon v8 package

[Elliott Sales de Andrade]

Let's try this again, but CC'ing the package owners.

On 2019-02-17 9:12 p.m., Elliott Sales de Andrade wrote:
> Hi,
> 
> Sorry for resurrecting a long-dead thread, but a few things happened recently:
> 1. v8 was just retired last week or so,
> 2. R-V8 just ported itself from v8-314 to v8 LTS 6/7.
> 
> Currently, R-V8 supports both v8-314 and v8, but as the latter fixes several 
> downstream package issues, it is the recommended build target. I expect that 
> eventually they will stop supporting 314 as well. This leaves me in a bit of 
> a pickle as it does not bundle v8 and neither I nor upstream have any plans 
> to build it ourselves.
> 
>> For all of these same reasons, the Node.js SIG opted to carry a bundled
>> copy of v8 in that package as well. I think we should move to have v8
>> considered to be a copylib for all reasonable purposes within Fedora.
> 
> In Debian, the nodejs package provides a stable *shared* v8 library, and the 
> recommended install is against libnode-dev. Unfortunately, in Fedora, while 
> nodejs-devel provides v8.h, it does *not* provide any shared library.
> 
> Is this something we can also do in Fedora, i.e., split out a nodejs-libs 
> subpackage, or similar?
> 

--
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Schedule for Thursday's FPC Meeting (2019-02-28 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2019-02-28 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2019-02-28 09:00 PST  US/Pacific
2019-02-28 12:00 EST  --> US/Eastern <--
2019-02-28 17:00 GMT  Europe/London 
2019-02-28 17:00 UTC  UTC   
2019-02-28 18:00 CET  Europe/Berlin 
2019-02-28 18:00 CET  Europe/Paris  
2019-02-28 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2019-03-01 01:00 HKT  Asia/Hong_Kong
2019-03-01 01:00 +08  Asia/Singapore
2019-03-01 02:00 JST  Asia/Tokyo
2019-03-01 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followups =

#topic #719 Simplify packaging of forge-hosted projects  
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #845 Wiki deprecation status  
.fpc 845
https://pagure.io/packaging-committee/issue/845

= New business =

#topic #859 Scriptlet to replace a directory: try delete first?  
.fpc 859
https://pagure.io/packaging-committee/issue/859

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken packages in Fedora 28: Need admin/rel-eng help

[Randy Barlow]

On Wed, 2019-02-27 at 15:35 -0500, Irina Boverman wrote:
> I have a number of qpid packages promoted to "stable" that depend on
> qpid-proton-0.26.0-1.f28. However, someone blocked this package from
> being promoted, and as a result, updated qpid packages cannot be
> installed. We need to either:
> - Push qpid-proton-0.26.0-1.f28 to "stable" ASAP, or
> - Remove updated qpid packages from Fedora 28
> I am not able to do either action, so I need rel eng
> advise/assistance on how to resolve this issue. Also see 
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b8b896b65 for
> reasons why this package was blocked.

The builds that depended on qpid-proton-0.26.0-1.f28 should have been
included in the same update as it so they could move through the
lifecycle together, atomically. If this update had included them, they
would not have been pushed stable without this build. In the future, I
recommend putting builds that depend on each other in the same update
to avoid this problem.

As for dealing with the problem now that they are pushed, it sounds
like there are backwards incompatible changes in the proposed update.
Is that correct? If so, the Fedora Updates Policy does say that we
shouldn't push backwards incompatible changes to stable releases[0]. If
not, it seems that three testers did think there were issues with the
update, and Bodhi unpushed it automatically because it reached the
negative karma threshold (-3).

If you think you have a case for why you should push a backwards
incompatible update to a stable release, you can ask for an exception
from FESCo to the policy[1]. If you decide to do that, please explain
the situation so that FESCo understands the motivation behind the
request.

If you decide to remove the other builds from Fedora 28, you might need
to raise the epoch on those packages and make a new update to roll them
back. Otherwise any users who may have updated to those packages will
not get the rollback. Or perhaps someone else has a better solution
than that…


[0] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#philosophy
[1] https://pagure.io/fesco/new_issue


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: qt4 rebuild

[Richard Shaw]

On Wed, Feb 27, 2019 at 10:18 AM Rex Dieter  wrote:

> Richard Shaw wrote:
>
> > So I'm pretty much out of my league at this point. I can commit the
> > Q_FOREACH patch if needed.
>
> please do commit (or at least submit pull request).
>

Pull request submitted, but it looks like pagure is having issues:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.

Please contact the server administrator at webmas...@fedoraproject.org to
inform them of the time this error occurred, and the actions you performed
just before this error.

More information about this error may be available in the server error log.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Broken packages in Fedora 28: Need admin/rel-eng help

[Irina Boverman]

I have a number of qpid packages promoted to "stable" that depend on
qpid-proton-0.26.0-1.f28. However, someone blocked this package from being
promoted, and as a result, updated qpid packages cannot be installed. We
need to either:
- Push qpid-proton-0.26.0-1.f28 to "stable" ASAP, or
- Remove updated qpid packages from Fedora 28
I am not able to do either action, so I need rel eng advise/assistance on
how to resolve this issue. Also see
https://bodhi.fedoraproject.org/updates/FEDORA-2019-6b8b896b65 for reasons
why this package was blocked.
--
Regards, Irina.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned packages that will be retired

[Miro Hrončok]

On 27. 02. 19 15:34, Robert-André Mauchin wrote:

On lundi 25 février 2019 21:49:32 CET you wrote:

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the
affected packages or a package that depends on one. Please adopt the
affected package or retire your depending package to avoid broken
dependencies, otherwise your package will be retired when the affected
package gets retired.

Full dependencies breakdown at
https://churchyard.fedorapeople.org/orphans-2019-02-25.txt
Grep it for your FAS name.

eclipseo: google-gson


That's not mine, I was never ever involved with google-gson. Is it a bug in
the script?


The script analyzes transitive dependencies (you will get hit by those as well).

Depending on: google-gson (47), status change: 2019-02-05 (2 weeks ago)

protobuf (maintained by: abbot, ignatenkobrain, mizdebsk, peter)
protobuf-java-util-3.6.1-2.fc30.noarch requires mvn(com.google.code.gson:gson) = 
2.8.2


clementine (maintained by: eclipseo)
clementine-1.3.1-34.20181130gitd260c8b.fc30.i686 requires libprotobuf.so.17

strawberry (maintained by: eclipseo)
strawberry-0.4.2-2.fc30.i686 requires libprotobuf.so.17



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Neal Gompa]

On Wed, Feb 27, 2019 at 2:20 PM Miroslav Suchý  wrote:
>
> Dne 27. 02. 19 v 12:30 Lukas Ruzicka napsal(a):
> >
> > However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular 
> > repositories allowed. It fails with an error
> > similar to what Mirek has reported. Disabling modular repositories fixed 
> > the problem and an upgrade was possible, but I
> > see this as quite a serious issue and if it is not fixed, I will definitely 
> > report this as a blocker.
> >
>
> The solution can be
>   dnf --setopt=module_platform_id=platform:f30 system-upgrade download 
> --releasever=30
> which I can put in fedora-upgrade(8) script, but will be PITA for official 
> upgrades.
>

Supposedly this will be fixed in this PR[1], but I don't know how it
will be... Nothing indicates to me how this is getting populated. :/

[1]: https://github.com/rpm-software-management/dnf-plugins-extras/pull/143



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Miroslav Suchý]

Dne 27. 02. 19 v 12:30 Lukas Ruzicka napsal(a):
> 
> However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular 
> repositories allowed. It fails with an error
> similar to what Mirek has reported. Disabling modular repositories fixed the 
> problem and an upgrade was possible, but I
> see this as quite a serious issue and if it is not fixed, I will definitely 
> report this as a blocker.
> 

The solution can be
  dnf --setopt=module_platform_id=platform:f30 system-upgrade download 
--releasever=30
which I can put in fedora-upgrade(8) script, but will be PITA for official 
upgrades.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Promoting qpid-proton to stable

[Irina Boverman]

There is an issue with  qpid-proton-0.26.0-1.fc28. It should be in
"stable", but it was blocked. This is creating a problem with qpid packages
in F28. Can someone advise or assist in moving this package to "stable"
ASAP?
--
Regards, Irina.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Orphaning: rubygem-riot and rubygem-rabl

[Pavel Valena]

I have orphaned rubygem-riot and rubygem-rabl as I have no use for them.

Regards,

-- 
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: qt4 rebuild

[Rex Dieter]

Richard Shaw wrote:

> So I'm pretty much out of my league at this point. I can commit the
> Q_FOREACH patch if needed.

please do commit (or at least submit pull request).

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Orphaned packages that will be retired

[Robert-André Mauchin]

On lundi 25 février 2019 21:49:32 CET you wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected packages or a package that depends on one. Please adopt the
> affected package or retire your depending package to avoid broken
> dependencies, otherwise your package will be retired when the affected
> package gets retired.
> 
> Full dependencies breakdown at
> https://churchyard.fedorapeople.org/orphans-2019-02-25.txt
> Grep it for your FAS name.
> 
> eclipseo: google-gson

That's not mine, I was never ever involved with google-gson. Is it a bug in 
the script?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Miroslav Suchý]

Dne 27. 02. 19 v 10:57 Miro Hrončok napsal(a):
> If not, why do we have them in mock, that is certainly not OK.

Mock has them because fedora-repos has them.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Miro Hrončok]

On 27. 02. 19 12:30, Lukas Ruzicka wrote:

Why people disable the repo, I do not know. I might have a slight notion.

However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular 
repositories allowed. It fails with an error similar to what Mirek has reported. 
Disabling modular repositories fixed the problem and an upgrade was possible, 
but I see this as quite a serious issue and if it is not fixed, I will 
definitely report this as a blocker.


I do not know, where the problem lies, whether the modules have not been built 
yet or something, but I would definitely expect that in time of Branching, 
things like that would have been solved. Otherwise, people will not want to get 
into problems like this and they might think twice about modular content.


I tend to agree. People like to disable stuff that causes them trouble. 
Modularity clearly does. Otherwise they wouldn't need to disable it.



Anyway, I've reported the problem as dnf bug, as dnf spits an exception:

https://bugzilla.redhat.com/show_bug.cgi?id=1683618

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Lukas Ruzicka]

Why people disable the repo, I do not know. I might have a slight notion.

However, you cannot upgrade from Fedora 29 to Fedora 30 with Modular
repositories allowed. It fails with an error similar to what Mirek has
reported. Disabling modular repositories fixed the problem and an upgrade
was possible, but I see this as quite a serious issue and if it is not
fixed, I will definitely report this as a blocker.

I do not know, where the problem lies, whether the modules have not been
built yet or something, but I would definitely expect that in time of
Branching, things like that would have been solved. Otherwise, people will
not want to get into problems like this and they might think twice about
modular content.



On Wed, Feb 27, 2019 at 11:37 AM Miro Hrončok  wrote:

> On 27. 02. 19 11:09, Igor Gnatenko wrote:
> > I think those messages are just informational, because nothing uses
> those
> > modules to build packages..  or am I wrong?
>
> It aborts the build.
>
> ---
>
> Modular dependency problems with Defaults:
>
>   Problem 1: conflicting requests
>- nothing provides module(platform:f30) needed by module
> avocado:stable:3020190213205848:a5b0195c-0.x86_64
>   Problem 2: conflicting requests
>- nothing provides module(platform:f30) needed by module
> bat:latest:3020190214090936:e50d0d19-0.x86_64
> ...
>   Problem 12: conflicting requests
>- nothing provides module(platform:f30) needed by module
> stratis:1:20181215204600:a5b0195c-0.x86_64
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "/usr/bin/dnf", line 58, in 
>  main.user_main(sys.argv[1:], exit_code=True)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 193, in
> user_main
>  errcode = main(args)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in
> main
>  return _main(base, args, cli_class, option_parser_class)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in
> _main
>  return cli_run(cli, base)
>File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in
> cli_run
>  cli.run()
>File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1108, in
> run
>  return self.command.run()
>File "/usr/lib/python3.7/site-packages/dnf/cli/commands/install.py",
> line 97,
> in run
>  module_debsolv_errors))
>File "/usr/lib/python3.7/site-packages/dnf/module/module_base.py", line
> 604,
> in format_modular_solver_errors
>  msg = dnf.util._format_resolve_problems(errors)
>File "/usr/lib/python3.7/site-packages/dnf/util.py", line 384, in
> _format_resolve_problems
>  msg += "\n  - ".join(rs)
> TypeError: sequence item 0: expected str instance, list found
>
> Could not execute mockbuild: Failed to execute command.
>
> ---
>
> Is this a dnf bug?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: /usr/bin/ld is broken in rawhide

[Mamoru TASAKA]

Todd Zullinger wrote on 2019/02/27 14:00:

Orion Poplawski wrote:

With current koji buildroot I end up with:

+ ls -l /usr/bin/ld /usr/bin/ld.bfd /usr/bin/ld.gold /usr/bin/ldd
--w---. 1 root root 3814880 Feb 27 04:00 /usr/bin/ld
-rwxr-xr-x. 1 root root 1841608 Feb 26 15:02 /usr/bin/ld.bfd
-rwxr-xr-x. 1 root root 3814880 Feb 26 15:02 /usr/bin/ld.gold
-rwxr-xr-x. 1 root root5441 Feb 19 07:39 /usr/bin/ldd

and thus:

BUILDSTDERR: collect2: fatal error: cannot find 'ld'


https://bugzilla.redhat.com/show_bug.cgi?id=1683408

It might be worth untagging the binutils update until a fixed
build is ready, which it looks like Mamoru has done:

https://pagure.io/releng/issue/8172



Kevin untagged binutils-2.32-7.fc31, so I guess ld issue is
fixed now.

Regards,
Mamoru


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Miro Hrončok]

On 27. 02. 19 11:09, Igor Gnatenko wrote:
I think those messages are just informational, because nothing uses those 
modules to build packages..  or am I wrong?


It aborts the build.

---

Modular dependency problems with Defaults:

 Problem 1: conflicting requests
  - nothing provides module(platform:f30) needed by module 
avocado:stable:3020190213205848:a5b0195c-0.x86_64

 Problem 2: conflicting requests
  - nothing provides module(platform:f30) needed by module 
bat:latest:3020190214090936:e50d0d19-0.x86_64

...
 Problem 12: conflicting requests
  - nothing provides module(platform:f30) needed by module 
stratis:1:20181215204600:a5b0195c-0.x86_64


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in 
main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 193, in 
user_main
errcode = main(args)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
  File "/usr/lib/python3.7/site-packages/dnf/cli/main.py", line 115, in cli_run
cli.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/cli.py", line 1108, in run
return self.command.run()
  File "/usr/lib/python3.7/site-packages/dnf/cli/commands/install.py", line 97, 
in run

module_debsolv_errors))
  File "/usr/lib/python3.7/site-packages/dnf/module/module_base.py", line 604, 
in format_modular_solver_errors

msg = dnf.util._format_resolve_problems(errors)
  File "/usr/lib/python3.7/site-packages/dnf/util.py", line 384, in 
_format_resolve_problems

msg += "\n  - ".join(rs)
TypeError: sequence item 0: expected str instance, list found

Could not execute mockbuild: Failed to execute command.

---

Is this a dnf bug?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Igor Gnatenko]

I think those messages are just informational, because nothing uses those
modules to build packages..  or am I wrong?

On Tue, Feb 26, 2019, 14:32 Miroslav Suchý  wrote:

> From:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
>
> When you try to run:
>   mock -r fedora-rawhide-x86_64 shell
>
> You will get:
>  Problem 1: conflicting requests
>   - nothing provides module(platform:f30) needed by module
> stratis:1:20181215204600:a5b0195c-0.x86_64
>  Problem 2: conflicting requests
>   - nothing provides module(platform:f30) needed by module
> standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64
> 
>
> rawhide has module_id=platform:f31.
>
> When will be all rawhide modules rebuild? Or what is the solution for
> this? Because right now all rawhide modules are
> basically broken. And because Mock started using modular fedora repos,
> then all Mock attempts for rawhides builds are
> broken too.
>
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: GCC9 bug on ppc64le ? or why just fail in ppc64le rawhide?

[Florian Weimer]

* Sérgio Basto:

> OK , I made another patch [1] not touching ./Source/Common/gdcmString.h
> and instead use definition of EOL, I use the default char of template
> ... 
>
> [1]
>
> https://src.fedoraproject.org/fork/sergiomb/rpms/gdcm/blob/master/f/gdcm-2.8.8-dont_use_EOF.patch

That looks much more reasonable.  Thanks!

Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Miro Hrončok]

On 26. 02. 19 15:08, Petr Šabata wrote:

On Tue, Feb 26, 2019 at 02:41:56PM +0100, Fabio Valentini wrote:

On Tue, Feb 26, 2019, 14:24 Miroslav Suchý  wrote:


From:
   https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2

When you try to run:
   mock -r fedora-rawhide-x86_64 shell

You will get:
  Problem 1: conflicting requests
   - nothing provides module(platform:f30) needed by module
stratis:1:20181215204600:a5b0195c-0.x86_64
  Problem 2: conflicting requests
   - nothing provides module(platform:f30) needed by module
standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64


rawhide has module_id=platform:f31.

When will be all rawhide modules rebuild? Or what is the solution for
this? Because right now all rawhide modules are
basically broken. And because Mock started using modular fedora repos,
then all Mock attempts for rawhides builds are
broken too.



Related: It would be nice if module repositories in mock (and COPR) were an
optional thing (right now, probably default=off, until that stuff is
fixed), like bootstrap chroot and network access.

I know, "just add another option" ... still, I'll manually disable all
modular repos in mock configs on my local system, but that's not an option
for COPR.


I always wonder why people disable the repo -- it's part of
Fedora.  What's your motivation?


Do we have modular repositories in Koji?
If not, why do we have them in mock, that is certainly not OK.
If yes, why are we dealing with ursa major and/or alternatives?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Broken modules on rawhide

[Petr Šabata]

On Tue, Feb 26, 2019 at 03:23:19PM +0100, Miro Hrončok wrote:
> On 26. 02. 19 15:07, Petr Šabata wrote:
> > On Tue, Feb 26, 2019 at 02:23:35PM +0100, Miroslav Suchý wrote:
> > > From:
> > >https://bugzilla.redhat.com/show_bug.cgi?id=1680320#c2
> > > 
> > > When you try to run:
> > >mock -r fedora-rawhide-x86_64 shell
> > > 
> > > You will get:
> > >   Problem 1: conflicting requests
> > >- nothing provides module(platform:f30) needed by module 
> > > stratis:1:20181215204600:a5b0195c-0.x86_64
> > >   Problem 2: conflicting requests
> > >- nothing provides module(platform:f30) needed by module 
> > > standard-test-roles:3.0:3020190214144451:a5b0195c-0.x86_64
> > > 
> > > 
> > > rawhide has module_id=platform:f31.
> > 
> > I think this shouldn't have been updated until after the branch
> > point.
> > 
> > > When will be all rawhide modules rebuild? Or what is the solution for 
> > > this? Because right now all rawhide modules are
> > > basically broken. And because Mock started using modular fedora repos, 
> > > then all Mock attempts for rawhides builds are
> > > broken too.
> > 
> > At branch point, modules that can run on any platform, or are
> > compatible with platform:f31, will simply be tagged.  Modules that
> > could run of f31 if rebuilt will be rebuilt.
> > 
> > I think this is an unfortunate timing issue and needs to be
> > coordinated better in the future.  The branch point happens later
> > this week; perhaps we could revert the change for the time being?
> 
> I don't know what do you exactly mean by "branch point" but "Branch Fedora
> 30 from Rawhide" already happened a week ago.

Uh, you're correct.  I need to refresh my calendar skills.

In that case discard what I wrote before; I'll follow up with
rel-eng today.

P


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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