Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Reini Urban
>
>
> $ repoquery --repo=rawhide{,-source} --whatrequires perl-Cpanel-JSON-XS
> inxi-0:3.0.37-2.fc32.noarch
> openqa-0:4.6-43.20200205git4861e34.fc33.noarch
>


Oh, interesting. Didn't know it were so many.
I'm upstream on this and I'm planning to rename it to perl-JSON-Safe soon.
https://github.com/rurban/Cpanel-JSON-XS/issues/142
With a backcompat Cpanel::JSON::XS package included of course, but the
repos would need to change.
Looks like quite some work ahead.

-- 
Reini Urban
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Miro Hrončok
> Please help me understand why I am marked?
> vascom: perl-Compress-LZF
> 
> I can't find any package requires perl-Compress-LZF. This always empty:
> dnf repoquery --whatrequires perl-Compress-LZF --alldeps
> dnf repoquery --whatrequires "perl(Compress::LZF)" --alldeps

(The package was adapted since, so no need to panic.)

The source repo was probably missing from your queries:

$ repoquery --repo=rawhide{,-source} --whatrequires perl-Compress-LZF
perl-Cpanel-JSON-XS-0:4.19-1.fc32.src

$ repoquery --repo=rawhide{,-source} --whatrequires perl-Cpanel-JSON-XS
inxi-0:3.0.37-2.fc32.noarch
openqa-0:4.6-43.20200205git4861e34.fc33.noarch
openqa-0:4.6-43.20200205git4861e34.fc33.src
openqa-client-0:4.6-43.20200205git4861e34.fc33.noarch
openqa-common-0:4.6-43.20200205git4861e34.fc33.noarch
openqa-devel-0:4.6-43.20200205git4861e34.fc33.noarch
os-autoinst-0:4.6-8.20190205git63af2f4.fc33.src
os-autoinst-0:4.6-8.20190205git63af2f4.fc33.x86_64
os-autoinst-devel-0:4.6-8.20190205git63af2f4.fc33.i686
os-autoinst-devel-0:4.6-8.20190205git63af2f4.fc33.x86_64
perl-Catalyst-Action-REST-0:1.21-8.fc32.src
perl-Config-Any-0:0.32-11.fc32.noarch
perl-Config-Any-0:0.32-11.fc32.src
perl-Cpanel-JSON-XS-0:4.19-1.fc32.x86_64
perl-CryptX-0:0.053-13.fc32.src
perl-DBIx-Class-0:0.082841-10.fc32.src
perl-JSON-Any-0:1.39-15.fc32.src
perl-JSON-MaybeXS-0:1.004000-7.fc32.noarch
perl-JSON-MaybeXS-0:1.004000-7.fc32.src
perl-MongoDB-0:2.2.1-2.fc32.src
perl-Search-Elasticsearch-0:6.00-8.fc32.noarch
perl-Search-Elasticsearch-0:6.00-8.fc32.src

(And so on...)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Miro Hrončok
> Hm, I'm not seeing these orphaned and I pretty sure I have never maintained 
> them:
> https://src.fedoraproject.org/rpms/perl-IO-Socket-Timeout
> https://src.fedoraproject.org/rpms/perl-PerlIO-via-Timeout
> 
> bug in the script?

They have been since adapted by @pghmcfc.

You have never maintained them, but your package depends on them:

  perl-Redis requires perl(IO::Socket::Timeout)
  gitolite3 requires perl(Redis)
  pagure requires gitolite3

(Also perl-IO-Socket-Timeout requires perl(PerlIO::via::Timeout).)

No bug in the script.  Although not the first "I have never maintained those" 
reaction at all. How to make it easier to understand by affected maintainers?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Another take on RStudio (review swaps?)

2020-02-17 Thread Iñaki Ucar
On Tue, 18 Feb 2020 at 01:11, Jerry James  wrote:
>
> On Sun, Feb 16, 2020 at 10:06 AM Iñaki Ucar  wrote:
> > If anyone is interested in pushing this forward, I can review
> > something in exchange. Note that the koji scratch build fails on s390x
> > due to a Java stack overflow. Does anyone know what's the default in
> > that arch and how to increase it?
>
> You can find the default like this:
>
> java -XX:+PrintFlagsFinal
>
> Then look for ThreadStackSize in the output.  It is 1024 on my x86_64
> machine with Java 8, and 1536 on an s390x machine where I have an
> account.  Pass -Xss to java or -J-Xss to javac to increase it.

Thanks, Jerry. Is there an environment variable to do that? In this
package there is an "ant" invocation buried in the cmake-based build
system, so I tried

%ifarch s390 s390x
export _JAVA_OPTIONS="-Xss16M"
%endif

with no luck. The compilation still fails with a Java stack overflow,
so I suppose that this env variable is not being used.

Iñaki
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Specio license corrected

2020-02-17 Thread Petr Pisar
I corrected a perl-Specio license tag from "Artistic 2.0" to
"Artistic 2.0 and (GPL+ or Artistic)" in all Fedoras.

-- Petr


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Vascom
Please help me understand why I am marked?
vascom: perl-Compress-LZF

I can't find any package requires perl-Compress-LZF. This always empty:
dnf repoquery --whatrequires perl-Compress-LZF --alldeps
dnf repoquery --whatrequires "perl(Compress::LZF)" --alldeps

вт, 18 февр. 2020 г. в 02:50, Jerry James :
>
> On Mon, Feb 17, 2020 at 8:27 AM Miro Hrončok  wrote:
> [snip]
> > pcpa: apache-commons-jexl, jmol, perl-Math-Int64, naga, jspecview
> [snip]
> > sagitter: apache-commons-jexl
>
> Hey pcpa and sagitter, don't worry about apache-commons-jexl.  I've
> just been working on updates for jacop and mp that fix multiple issues
> I've stumbled over with those two packages.  The updates will involve
> dropping the dependency on apache-commons-jexl.  They will also fix
> the jacop integration into mp, by the way, which doesn't actually work
> with the current mp package, as well as restore gecode integration
> into mp.
>
> The jmol orphaning is a bit more concerning.  I'm just about to get
> sagemath building again after it has been broken for a couple of
> months (just waiting for a fix for
> https://bugzilla.redhat.com/show_bug.cgi?id=1789099 at this point),
> and if jmol disappears from Fedora then it will be broken again.
> Argh.  Paulo, since you are the maintainer of record for sagemath, do
> you want to pick up jmol and its dependencies?
>
> If not, is there a charitable soul in the audience who would take
> jmol?  If somebody out there is not a packager, but would like to
> maintain jmol, please contact me.  I'll help you get started.
>
> Regards,
> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1804044] New: perl-Log-ger-0.029 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804044

Bug ID: 1804044
   Summary: perl-Log-ger-0.029 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Log-ger
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.029
Current version/release in rawhide: 0.028-4.fc32
URL: http://search.cpan.org/dist/Log-ger/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/15741/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1804031] perl-Package-New-0.09 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804031



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Package-New-0.09-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=41577644

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1804031] New: perl-Package-New-0.09 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804031

Bug ID: 1804031
   Summary: perl-Package-New-0.09 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Package-New
  Keywords: FutureFeature, Triaged
  Assignee: tcall...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.09
Current version/release in rawhide: 0.08-2.fc32
URL: http://search.cpan.org/dist/Package-New/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/13013/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1804031] perl-Package-New-0.09 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804031



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1663652
  --> https://bugzilla.redhat.com/attachment.cgi?id=1663652=edit
[patch] Update to 0.09 (#1804031)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[389-devel] 389 DS nightly 2020-02-18 - 96% PASS

2020-02-17 Thread vashirov
https://fedorapeople.org/groups/389ds/ci/nightly/2020/02/18/report-389-ds-base-1.4.3.3-20200218git2f8fbe2.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org


[Fedocal] Reminder meeting : Modularity Team (weekly)

2020-02-17 Thread nils
Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2020-02-18 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



Source: https://apps.fedoraproject.org/calendar/meeting/9480/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: perl-Digest-SHA3, perl-Gtk3-WebKit (was: Re: Orphaned packages looking for new maintainers)

2020-02-17 Thread Sérgio Basto
On Mon, 2020-02-17 at 17:34 +, Richard W.M. Jones wrote:
> On Mon, Feb 17, 2020 at 05:32:03PM +, Richard W.M. Jones wrote:
> > On Mon, Feb 17, 2020 at 04:24:22PM +0100, Miro Hrončok wrote:
> > > rjones: perl-Digest-SHA3, perl-Gtk3-WebKit
> > 
> > I took perl-Gtk3-WebKit, at least temporarily.  techtalk-pse
> > depends
> > on it, and there are no open bugs (or even recent bugs at all).
> > Upstream version is still the same as the current package.
> > 
> > I'm confused why I'm listed next to perl-Digest-SHA3 however.  Does
> > some package I own depend on it?
> 
> Oh I see in the longer report, it's virt-dib -> debootstrap ->
> perl-Digest-SHA3.

I removed "Requires:perl-Digest-SHA3" from dpkg, it may fix this
dependency chain .

> Rich.
> 
> -- 
> Richard Jones, Virtualization Group, Red Hat 
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: 
> http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1804004] perl-PerlIO-Layers-0.012 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804004



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-PerlIO-Layers-0.012-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=41569152

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1804004] perl-PerlIO-Layers-0.012 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804004



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1663637
  --> https://bugzilla.redhat.com/attachment.cgi?id=1663637=edit
[patch] Update to 0.012 (#1804004)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1804004] New: perl-PerlIO-Layers-0.012 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1804004

Bug ID: 1804004
   Summary: perl-PerlIO-Layers-0.012 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PerlIO-Layers
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.012
Current version/release in rawhide: 0.011-20.fc32
URL: http://search.cpan.org/dist/PerlIO-Layers/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3229/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Another take on RStudio (review swaps?)

2020-02-17 Thread Jerry James
On Sun, Feb 16, 2020 at 10:06 AM Iñaki Ucar  wrote:
> If anyone is interested in pushing this forward, I can review
> something in exchange. Note that the koji scratch build fails on s390x
> due to a Java stack overflow. Does anyone know what's the default in
> that arch and how to increase it?

You can find the default like this:

java -XX:+PrintFlagsFinal

Then look for ThreadStackSize in the output.  It is 1024 on my x86_64
machine with Java 8, and 1536 on an s390x machine where I have an
account.  Pass -Xss to java or -J-Xss to javac to increase it.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Jerry James
On Mon, Feb 17, 2020 at 8:27 AM Miro Hrončok  wrote:
[snip]
> pcpa: apache-commons-jexl, jmol, perl-Math-Int64, naga, jspecview
[snip]
> sagitter: apache-commons-jexl

Hey pcpa and sagitter, don't worry about apache-commons-jexl.  I've
just been working on updates for jacop and mp that fix multiple issues
I've stumbled over with those two packages.  The updates will involve
dropping the dependency on apache-commons-jexl.  They will also fix
the jacop integration into mp, by the way, which doesn't actually work
with the current mp package, as well as restore gecode integration
into mp.

The jmol orphaning is a bit more concerning.  I'm just about to get
sagemath building again after it has been broken for a couple of
months (just waiting for a fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1789099 at this point),
and if jmol disappears from Fedora then it will be broken again.
Argh.  Paulo, since you are the maintainer of record for sagemath, do
you want to pick up jmol and its dependencies?

If not, is there a charitable soul in the audience who would take
jmol?  If somebody out there is not a packager, but would like to
maintain jmol, please contact me.  I'll help you get started.

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

2020-02-17 Thread Jerry James
On Mon, Feb 17, 2020 at 2:59 PM Bruno Wolff III  wrote:
> For greyhounds, I didn't make an exception in the include file, but rather
> added definitions to the main unit to reserve the space (and changed the
> include file to add extern to the definitions). This didn't result in a
> conflict, so I'm guessing it was a correct way to do this. If it wasn't,
> I'd like to know?

That sounds right.  I've fixed quite a few of these already.  They
tend to fall into just a few cases.

Case 1. Like the example above: there are non-extern variable
declarations in header files, and no non-extern definition in any
C/C++ file.  Solution: do what Bruno did.  Add "extern" to the header
file declarations, and add a non-extern definition to some C/C++ file;
it doesn't really matter which one, although it should be one that
actually accesses the variable in question.

Case 2. There are non-extern variable declarations in header files and
C/C++ files both.  Solution: add "extern" to the header file
declarations and make sure there is only one non-extern definition in
a C/C++ file.  If there is more than one, try removing the others
(hopefully they #include the necessary header file).  If that doesn't
work, either add the necessary #include or add extern to the duplicate
definitions.

Case 3. A variable is not mentioned in any header file, but there are
multiple non-extern definitions of it in C/C++ files.  Solution: check
the code to see if the variable is supposed to be shared.  I have
found a few cases where it is not, and the correct solution was to add
"static" to each of the definitions.  Otherwise, either add an extern
declaration to some header file and remove all but one of the
non-extern definitions, or add extern to all but one of the
definitions.

Case 4. Your package is a code generator that spews forth thousands of
duplicate variable definitions, trusting in -fcommon to merge them
all.  Solution: sit on the floor and cry for awhile, then play "First
World Problems" by Weird Al, and then contact upstream and inform them
that their code generator has a defect, and would they please fix it?
(I have 1 package in this category.)

Richard, if you will provide a list of your packages that have this
issue, some of us may be able to help you put together patches to send
upstream.  Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Qt, GNOME, and fonts

2020-02-17 Thread Jerry James
I am trying to track down a font problem with MuseScore:

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

The problem is that everything is displayed in Cantarell, no matter
which font the user actually selects.  In the style menu, one can pop
up a list of fonts to choose from, and even though every font on the
system is displayed by name, the text samples are all displayed in
Cantarell.

I spent several hours with GDB trying to figure this out (which is how
I was able to determine that Cantarell is the font we're always
looking at), but I still don't understand what is happening.  It
finally dawned on me that I'm running a GNOME desktop, but MuseScore
is a Qt application.  So I logged out, logged into a KDE Plasma
session, and (drum roll please) all of the fonts displayed correctly.

The bug submitter pointed out that if one downloads the AppImage
created by MuseScore upstream, that displays all of the fonts
correctly. Even on my GNOME desktop, that is true.  The fonts are all
correct.  I can see that all of the Qt and X libraries are baked into
the AppImage, but why does that matter?

Does anybody have experience with this sort of thing?  It would be
nice if we could display the fonts correctly when running on a GNOME
desktop.  Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Intent to retire clalsadrv

2020-02-17 Thread Guido Aulisi
I'm going to retire clalsadrv, it's been deprecated upstream [0] for a
long time and it has been replaced by zita-alsa-pcmi.
Nothing depends on it in rawhide according to this query:

dnf --disablerepo='*' --enablerepo='rawhide' repoquery --whatrequires clalsadrv 
--alldep

Ciao
Guido

FAS: tartina

[0]: https://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

2020-02-17 Thread Bruno Wolff III

On Mon, Feb 17, 2020 at 21:32:30 +,
 Ronaldo Mercado  wrote:


I would like to see an example package where you experience this problem.


In my case, greyhounds was the normal case. raidem was the enum should have 
been a typedef case.


For greyhounds, I didn't make an exception in the include file, but rather 
added definitions to the main unit to reserve the space (and changed the 
include file to add extern to the definitions). This didn't result in a 
conflict, so I'm guessing it was a correct way to do this. If it wasn't, 
I'd like to know?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

2020-02-17 Thread Ronaldo Mercado
Hello,

> The most common fix I used was, using "extern" in all but one place.
> Well I guess what I was looking for was for us non-C/C++ programmers. :)
> I can grep the source and arbitrarily choose which one not to use extern 
> with, but is there a right way?

I would like to see an example package where you experience this problem.

One way I have seen this solved is to have a #define, say '#define MAIN'

On the header file "header.h" you would have a declaration and a definition 
only if MAIN is defined, e.g.

extern int y;  /* declaration */
#ifdef MAIN
int y;  /* definition */
#endif

Most c files would include "header.h" and main.c would do this instead

#define MAIN
#include "header.h"

Thanks,

Ronaldo



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1803973] New: CGI::Session is missing in epel8

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803973

Bug ID: 1803973
   Summary: CGI::Session is missing in epel8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-CGI-Session
  Assignee: andr...@bawue.net
  Reporter: net...@crc.id.au
QA Contact: extras...@fedoraproject.org
CC: andr...@bawue.net, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



The perl-CGI-Session package is not available for EPEL8.

Please import & build for EPEL8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

2020-02-17 Thread Richard Shaw
On Mon, Feb 17, 2020 at 12:20 PM Bruno Wolff III  wrote:

> On Sun, Feb 16, 2020 at 07:24:10 -0600,
>   Richard Shaw  wrote:
> >So I have several FTBFS bugs most likely from the new gcc being more
> >pedantic. I understand the bug at a high level but I think it would be
> nice
> >if someone who really understood it could perhaps document strategies for
> >figuring out how to find the right file that needs to be updated and how.
>
> The most common fix I used was, using "extern" in all but one place.
>

Well I guess what I was looking for was for us non-C/C++ programmers. :)

I can grep the source and arbitrarily choose which one not to use extern
with, but is there a right way?

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Signal 4 (ILL) caught by ps in mock

2020-02-17 Thread Christoph Junghans
On Mon, Feb 17, 2020 at 3:45 AM Dan Horák  wrote:
>
> On Mon, 17 Feb 2020 11:26:30 +0100
> Petr Pisar  wrote:
>
> > On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > > >
> > > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > > Christoph Junghans  wrote:
> > > >
> > > > > >>
> > > > > >> In your case procps-ng package seems to be miscompiled (or
> > > > > >> run on an incopatible hardware). I recommend getting a shell
> > > > > >> in the mock enviroment (mock --shell) and investigeting
> > > > > >> whether the ps program works there).
> > > > > >
> > > > > > Ok, I will try that and report back.
> > > > > It is indeed broken in shell as well:
> > > > >  sh-5.0# ps
> > > > >
> > > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > > Segmentation fault (core dumped)
> > > >
> > > > works (no crash) on my Power9 system, but it could be a P9
> > > > instruction sneaked into the binary and crashing on Power8
> > > > systems. I'll take a look, but if you could file a bug (with me
> > > > in CC), it would be helpful.
> > > just to make sure, I am running this in mock on the following
> > > system: $ cat /proc/cpuinfo
> > > processor : 0
> > > vendor_id : GenuineIntel
> > > cpu family : 6
> > > model : 142
> > > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
> >
> > Then you actually run the PowerPC ps binary in QEMU emulator. Could
> > you show the /proc/cpuinfo from inside of the mock environment?
>
> first I suggest to use the latest qemu from the virt-preview repo [1]
> and if it still SIGILLs, then report a bugu against qemu. I don't see
> any problem with "ps" on (real) Power8 or Power9 hw, so most likely it's
> an emulation bug.
Updating qemu-common to 2:4.2.0-4 fixed the issue.

Christoph
>
> [1]
> https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/
>
>
>
> Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Signal 4 (ILL) caught by ps in mock

2020-02-17 Thread Christoph Junghans
On Mon, Feb 17, 2020 at 3:27 AM Petr Pisar  wrote:
>
> On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > >
> > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > Christoph Junghans  wrote:
> > >
> > > > >>
> > > > >> In your case procps-ng package seems to be miscompiled (or run on
> > > > >> an incopatible hardware). I recommend getting a shell in the mock
> > > > >> enviroment (mock --shell) and investigeting whether the ps program
> > > > >> works there).
> > > > >
> > > > > Ok, I will try that and report back.
> > > > It is indeed broken in shell as well:
> > > >  sh-5.0# ps
> > > >
> > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > Segmentation fault (core dumped)
> > >
> > > works (no crash) on my Power9 system, but it could be a P9 instruction
> > > sneaked into the binary and crashing on Power8 systems. I'll take a
> > > look, but if you could file a bug (with me in CC), it would be helpful.
> > just to make sure, I am running this in mock on the following system:
> > $ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 142
> > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
>
> Then you actually run the PowerPC ps binary in QEMU emulator. Could you show
> the /proc/cpuinfo from inside of the mock environment?
It is the same inside mock!
>
> -- Petr
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Paul Howarth
On Mon, 17 Feb 2020 16:48:05 +0100
Pierre-Yves Chibon  wrote:

> > pingou: perl-PerlIO-via-Timeout, perl-IO-Socket-Timeout  
> 
> Hm, I'm not seeing these orphaned and I pretty sure I have never
> maintained them:
> https://src.fedoraproject.org/rpms/perl-IO-Socket-Timeout
> https://src.fedoraproject.org/rpms/perl-PerlIO-via-Timeout
> 
> bug in the script?

They're no longer orphaned because I took them. You probably have a
package that depends on them somehow.

Paul.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaning tinymce

2020-02-17 Thread Kevin Fenzi
On Mon, Feb 17, 2020 at 04:27:50PM +0100, Miro Hrončok wrote:
> On 17. 02. 20 7:28, Matthias Runge wrote:
> > On 15/02/2020 21:12, Kevin Fenzi wrote:
> > > Greetings.
> > > 
> > > I was (probibly poorly) maintaining tinymce for a while because we used
> > > it for askbot. We no longer do need it so I am going to orphan it and
> > > hope someone out there has more time and energy to give it the love it
> > > needs.
> > > 
> > > There's currently some CVE's filed against it.
> > > 
> > > It's on versuon 4.5.1 and 5.0 is current.
> > > 
> > 
> > Thank you for keeping it alive for so long. I don't have any use for
> > tinymce (anymore), and from my perspective, it can get removed.
> 
> Please, don't forget to also orphan python-django-tinymce (or to retire it
> once tinymce is retired).

Good catch. I have orphaned this one as well. 

kevin


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to deal with large number of bugs related to the, "multiple definition of..." issue

2020-02-17 Thread Bruno Wolff III

On Sun, Feb 16, 2020 at 07:24:10 -0600,
 Richard Shaw  wrote:

So I have several FTBFS bugs most likely from the new gcc being more
pedantic. I understand the bug at a high level but I think it would be nice
if someone who really understood it could perhaps document strategies for
figuring out how to find the right file that needs to be updated and how.


The most common fix I used was, using "extern" in all but one place.

The was also an odd case where the original developers used an enum 
to define constants and it needed to be a typedef, not an instance of the 
enum. (I don't know why they didn't use "define" to define the constants.)

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: URGENT: users prompted to upgrade to F32

2020-02-17 Thread Adam Williamson
On Mon, 2020-02-17 at 09:51 -0800, Adam Williamson wrote:
> 
> However! It seems that there *may* be an alternative candidate for the
> role. Bodhi has a 'releases' API endpoint, here:
> 
> https://bodhi.fedoraproject.org/releases/

I updated a gnome-software issue:
https://gitlab.gnome.org/GNOME/gnome-software/issues/214

and filed a fedfind issue:
https://pagure.io/fedora-qa/fedfind/issue/17

if anyone's aware of any other systems using the collections data,
please flag them up so we can consider those too.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: URGENT: users prompted to upgrade to F32

2020-02-17 Thread Adam Williamson
On Sun, 2020-02-16 at 22:17 +0100, drago01 wrote:
> On Saturday, February 15, 2020, Kevin Fenzi  wrote:
> 
> > On Fri, Feb 14, 2020 at 05:14:57PM -0800, Adam Williamson wrote:
> > > On Fri, 2020-02-14 at 18:37 -0600, Michael Catanzaro wrote:
> > > > Hi,
> > > > 
> > > > Users are being prompted to upgrade to F32. Anyone who knows how to
> > fix
> > > > this, please help with
> > > > https://pagure.io/fedora-infrastructure/issue/8652 ASAP.
> > > 
> > > We fixed it several hours ago, but people are likely hitting copies of
> > > the bad data cached somewhere along the line :/
> > > 
> > > https://pagure.io/fedora-infrastructure/issue/8652#comment-626587
> > 
> > Yeah, it was live for about 45min this morning, but we fixed it as soon
> > as it was noted. ;(
> > 
> > Not sure that there is too much more we can do at this point...
> > 
> > 
> What can we do to ensure it does not happen again?

Well, ideally, finally come up with an actually sane system / set of
processes for handling release events and storing/providing information
about them.

Unfortunately, as Kevin puts it, we could do a great job of that if
someone would give us four people who could work on it for six months.
As long as that doesn't happen, releng will keep putting duct tape on
duct tape, and when resource constraints force people to do that, this
kind of accident will happen.

In practice, though, there might be something concrete we can do in the
short term.

The problem here is that GNOME Software (and fedfind, as it happens)
are using this thing as a Source of Truth about Fedora releases:

https://admin.fedoraproject.org/pkgdb/api/collections/

when pkgdb existed, that was one of its API endpoints. It could be
relied upon to be a reliable source of information about Fedora
releases that existed and their status (stable, development, EOL)
because it *had* to be updated accurately at each 'lifecycle event'
(Branching, EOL, stable release) or else various other things wouldn't
work right.

But pkgdb was retired in 2017. Since then this URL has not been a
reliable API endpoint, but a weird orphan: it's literally a JSON format
text file which a web server is configured to serve out at that URL. At
each 'lifecycle event', someone has to update the text file by hand,
and do it right. What happened in this case is someone made a mistake
while doing that - I'm not going to say who, because of course it could
happen to anyone as long as this fundamentally silly process is in
place.

We keep this silly process in place because there hasn't really been a
viable alternative to it. PDC was *supposed* to be the replacement for
pkgdb so far as 'Official Source of Truth for release information'
went, but for a variety of reasons - significantly
https://github.com/product-definition-center/product-definition-center/issues/294
 -
it never really has been. Now RH has lost interest in PDC, Fedora is in
an awkward spot where we're sort of still using it, but don't have the
resources to really complete all the plans for its adoption.

However! It seems that there *may* be an alternative candidate for the
role. Bodhi has a 'releases' API endpoint, here:

https://bodhi.fedoraproject.org/releases/

(it renders as HTML in a browser, but you get JSON when accessing it in
API-y ways). I think it actually provides the information that at least
GNOME Software and fedfind need - 'these are the releases that exist,
and their lifecycle status is X'. One key question is exactly when
Fedora 32 becomes 'current' for Bodhi's purposes - it needs to be at
the time we actually decide Fedora 32 is stable, not at the Bodhi
activation point or the point when we cut the final fedora-release
package or anything like that. Another possible issue is distinguishing
Branched from Rawhide. But if the 'stable release' event happens at the
right time, and we can distinguish Branched and Rawhide somehow, I
think we may have a good candidate.

Since this is an API endpoint of a real system which needs to be
updated correctly when the release events actually happen, it should
have the benefits pkgdb used to be (the information should be reliable
and timely), and it shouldn't be as vulnerable to PEBKAC events as...a
hand-edited JSON text file. So if we update GNOME Software and fedfind,
and anything else using collections as a source of truth, to use this
Bodhi API instead, potentially that could help.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: perl-Digest-SHA3, perl-Gtk3-WebKit (was: Re: Orphaned packages looking for new maintainers)

2020-02-17 Thread Richard W.M. Jones
On Mon, Feb 17, 2020 at 05:32:03PM +, Richard W.M. Jones wrote:
> On Mon, Feb 17, 2020 at 04:24:22PM +0100, Miro Hrončok wrote:
> > rjones: perl-Digest-SHA3, perl-Gtk3-WebKit
> 
> I took perl-Gtk3-WebKit, at least temporarily.  techtalk-pse depends
> on it, and there are no open bugs (or even recent bugs at all).
> Upstream version is still the same as the current package.
> 
> I'm confused why I'm listed next to perl-Digest-SHA3 however.  Does
> some package I own depend on it?

Oh I see in the longer report, it's virt-dib -> debootstrap ->
perl-Digest-SHA3.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


perl-Digest-SHA3, perl-Gtk3-WebKit (was: Re: Orphaned packages looking for new maintainers)

2020-02-17 Thread Richard W.M. Jones
On Mon, Feb 17, 2020 at 04:24:22PM +0100, Miro Hrončok wrote:
> rjones: perl-Digest-SHA3, perl-Gtk3-WebKit

I took perl-Gtk3-WebKit, at least temporarily.  techtalk-pse depends
on it, and there are no open bugs (or even recent bugs at all).
Upstream version is still the same as the current package.

I'm confused why I'm listed next to perl-Digest-SHA3 however.  Does
some package I own depend on it?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Packaging of github cli?

2020-02-17 Thread Joe Doss
On 2/17/20 10:40 AM, Richard Shaw wrote:
> I might when I have some time but it looks like a lot of dependent
> package reviews! :)

I think we are good on reviews now. It did have a lot of dependencies. Ooof!

Joe



-- 
Joe Doss
j...@solidadmin.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Packaging of github cli?

2020-02-17 Thread Richard Shaw
On Fri, Feb 14, 2020 at 11:51 PM Joe Doss  wrote:

> On 2/14/20 12:36 PM, Joe Doss wrote:
> > I will see what it takes to get this submitted for review this weekend.
>
> Here we go https://bugzilla.redhat.com/show_bug.cgi?id=1803302
>
> If anyone has any some time to give these package a review that would be
> great.
>

I might when I have some time but it looks like a lot of dependent package
reviews! :)

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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Anybody want js-jquery-noty?

2020-02-17 Thread Randy Barlow
I plan to orphan js-jquery-noty unless someone wants to maintain it.


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to get proper nsswitch.conf?

2020-02-17 Thread Michael Catanzaro
On Mon, Feb 17, 2020 at 11:24 am, Pavel Březina  
wrote:

This is systemd module, right? There was some discussion about it in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P/#PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P

I don't really have all the information but apparently there are some 
collisions with LDAP/FreeIPA and is not supposed to be enabled by 
default.


Thanks, this is good to know.


Next question, I have:

passwd: sss files systemd
shadow: files sss
group: sss files systemd

The difference is that authselect doesn't write the shadow line [1], 
that one is coming from our glibc [2]. (glibc is already patched to 
enable sssd.) That inconsistency seems odd; shouldn't authselect be 
modifying the shadow line as well?


SSSD does not support shadow therefore it is not added by authselect. 
IMHO it should be removed from glibc nsswitch.conf as well.


OK: https://src.fedoraproject.org/rpms/glibc/pull-request/17

Then it also doesn't make sense that we put files before sss in half 
the lines, and sss before files in the other half.


Basically only passwd and group needs to have sss consulted first 
because SSSD now handles local users as well and this way will glibc 
first consults SSSD in-memory cache before reading from disk.


It does not matter with the other maps. It makes sense to me to have 
SSSD first because nowadays if you are joined to a remote domain you 
have these maps served by SSSD from LDAP then having the 
configuration in files, at least in enterprise scenarios.


sudoers have files first because there is always /etc/sudoers with at 
least %wheel so it makes sense to read it first.


Thanks for the info,

Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Summary/Minutes from today's FESCo Meeting (2020-02-17)

2020-02-17 Thread David Cantrell

=
#fedora-meeting-1: FESCO (2020-02-17)
=


Meeting started by dcantrell at 15:00:16 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-17/fesco.2020-02-17-15.00.log.html
.



Meeting summary
---
* init process  (dcantrell, 15:00:16)

* #2333 mingw CVEs aren't getting fixed  (dcantrell, 15:04:06)

* #2333 mingw CVEs aren't getting fixed  (dcantrell, 15:09:39)
  * AGREED: APPROVED (+6, 0, -0)  (dcantrell, 15:22:52)

* #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE
  (32bit), Add Workstation(64bit) - https://fedoraproject.org/wiki/\
  (dcantrell, 15:23:05)

* #2339 Proposal to change ARM Release Blocking Criteria - Drop XFCE
  (32bit), Add Workstation(64bit) -
  https://fedoraproject.org/wiki/Changes/ARM_Release_Criteria_Changes
  (dcantrell, 15:23:34)
  * AGREED: APPROVED (+7, 0, -0)  (dcantrell, 15:35:33)

* Next week's chair  (dcantrell, 15:35:52)
  * ACTION: contyk will chair next meeting  (dcantrell, 15:37:41)

* Open Floor  (dcantrell, 15:38:04)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1801882
(bookwar, 15:47:40)

Meeting ended at 15:55:01 UTC.




Action Items

* contyk will chair next meeting




Action Items, by person
---
* contyk
  * contyk will chair next meeting
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dcantrell (105)
* zbyszek (25)
* nirik (20)
* zodbot (19)
* bookwar (14)
* contyk (13)
* decathorpe (10)
* pbrobinson (7)
* pwhalen (5)
* bcotton (5)
* cipherboy (4)
* ignatenkobrain (3)
* kalev (1)
* dcantrel (0)
* mhroncok (0)
* sgallagh (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot


--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers

2020-02-17 Thread Pierre-Yves Chibon
> pingou: perl-PerlIO-via-Timeout, perl-IO-Socket-Timeout

Hm, I'm not seeing these orphaned and I pretty sure I have never maintained 
them:
https://src.fedoraproject.org/rpms/perl-IO-Socket-Timeout
https://src.fedoraproject.org/rpms/perl-PerlIO-via-Timeout

bug in the script?


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned packages looking for new maintainers

2020-02-17 Thread Miro Hrončok

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.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-02-17.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

adns  orphan, rvokal   0 weeks ago
apache-commons-jexl   mizdebsk, orphan 0 weeks ago
appframework  orphan   0 weeks ago
argyllcms orphan, rhughes  3 weeks ago
bean-validation-api   orphan   0 weeks ago
bindexorphan   0 weeks ago
clang7.0  orphan, sergesanspaille, 1 weeks ago
  tstellar
clang8.0  orphan, sergesanspaille, 0 weeks ago
  tstellar
cuneiform orphan   0 weeks ago
dump  jridky, orphan, vdolezal 0 weeks ago
exciting  marcindulak, orphan  4 weeks ago
felix-scr-maven-pluginjerboaa, jkang, orphan   1 weeks ago
freemarkerorphan   0 weeks ago
geronimo-jta  mizdebsk, orphan 0 weeks ago
gnome-shell-extension-orphan   0 weeks ago
taskwarrior
hibernate lef, odubaj, orphan  2 weeks ago
htmlcleaner   besser82, marcindulak, orphan4 weeks ago
ini4j orphan   2 weeks ago
java-augeas   bkearney, orphan 3 weeks ago
jboss-transaction-1.2-api orphan   5 weeks ago
jettison  mizdebsk, orphan 5 weeks ago
jetty-artifact-remote-resources   mizdebsk, orphan 5 weeks ago
jetty-assembly-descriptorsmizdebsk, orphan 5 weeks ago
jetty-test-policy mizdebsk, orphan 5 weeks ago
jmol  jussilehtola, orphan 0 weeks ago
jspecview jussilehtola, orphan 0 weeks ago
jsr-311   mizdebsk, orphan 0 weeks ago
llvm7.0   jistone, orphan, 1 weeks ago
  sergesanspaille, tstellar
llvm8.0   orphan, sergesanspaille, 0 weeks ago
  tstellar
maven-jarsigner-pluginjcapik, mizdebsk, orphan 3 weeks ago
maven-shared-jarsignermizdebsk, orphan 3 weeks ago
naga  jussilehtola, orphan 0 weeks ago
nodejs-typeahead.js   dcallagh, orphan, vjancik0 weeks ago
perl-Business-Stripe  orphan   1 weeks ago
perl-Bytes-Random-Secure  orphan   1 weeks ago
perl-CPAN-Reporterorphan   1 weeks ago
perl-Clone-PP orphan   1 weeks ago
perl-Compress-LZ4 orphan   1 weeks ago
perl-Compress-LZF orphan   1 weeks ago
perl-Compress-Snappy  orphan   1 weeks ago
perl-Crypt-ECBorphan   1 weeks ago
perl-Crypt-PBKDF2 orphan   1 weeks ago
perl-Crypt-PWSafe3orphan   1 weeks ago
perl-Crypt-Random-Seedorphan   1 weeks ago
perl-Crypt-Random-TESHA2  orphan   1 weeks ago
perl-Crypt-SaltedHash orphan   1 weeks ago
perl-Date-Easter  orphan   1 weeks ago
perl-Date-Handler orphan   1 weeks ago

Re: Orphaning tinymce

2020-02-17 Thread Miro Hrončok

On 17. 02. 20 7:28, Matthias Runge wrote:

On 15/02/2020 21:12, Kevin Fenzi wrote:

Greetings.

I was (probibly poorly) maintaining tinymce for a while because we used
it for askbot. We no longer do need it so I am going to orphan it and
hope someone out there has more time and energy to give it the love it
needs.

There's currently some CVE's filed against it.

It's on versuon 4.5.1 and 5.0 is current.



Thank you for keeping it alive for so long. I don't have any use for
tinymce (anymore), and from my perspective, it can get removed.


Please, don't forget to also orphan python-django-tinymce (or to retire it once 
tinymce is retired).


--
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Orphaned packages looking for new maintainers

2020-02-17 Thread Miro Hrončok

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.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-02-17.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

adns  orphan, rvokal   0 weeks ago
apache-commons-jexl   mizdebsk, orphan 0 weeks ago
appframework  orphan   0 weeks ago
argyllcms orphan, rhughes  3 weeks ago
bean-validation-api   orphan   0 weeks ago
bindexorphan   0 weeks ago
clang7.0  orphan, sergesanspaille, 1 weeks ago
  tstellar
clang8.0  orphan, sergesanspaille, 0 weeks ago
  tstellar
cuneiform orphan   0 weeks ago
dump  jridky, orphan, vdolezal 0 weeks ago
exciting  marcindulak, orphan  4 weeks ago
felix-scr-maven-pluginjerboaa, jkang, orphan   1 weeks ago
freemarkerorphan   0 weeks ago
geronimo-jta  mizdebsk, orphan 0 weeks ago
gnome-shell-extension-orphan   0 weeks ago
taskwarrior
hibernate lef, odubaj, orphan  2 weeks ago
htmlcleaner   besser82, marcindulak, orphan4 weeks ago
ini4j orphan   2 weeks ago
java-augeas   bkearney, orphan 3 weeks ago
jboss-transaction-1.2-api orphan   5 weeks ago
jettison  mizdebsk, orphan 5 weeks ago
jetty-artifact-remote-resources   mizdebsk, orphan 5 weeks ago
jetty-assembly-descriptorsmizdebsk, orphan 5 weeks ago
jetty-test-policy mizdebsk, orphan 5 weeks ago
jmol  jussilehtola, orphan 0 weeks ago
jspecview jussilehtola, orphan 0 weeks ago
jsr-311   mizdebsk, orphan 0 weeks ago
llvm7.0   jistone, orphan, 1 weeks ago
  sergesanspaille, tstellar
llvm8.0   orphan, sergesanspaille, 0 weeks ago
  tstellar
maven-jarsigner-pluginjcapik, mizdebsk, orphan 3 weeks ago
maven-shared-jarsignermizdebsk, orphan 3 weeks ago
naga  jussilehtola, orphan 0 weeks ago
nodejs-typeahead.js   dcallagh, orphan, vjancik0 weeks ago
perl-Business-Stripe  orphan   1 weeks ago
perl-Bytes-Random-Secure  orphan   1 weeks ago
perl-CPAN-Reporterorphan   1 weeks ago
perl-Clone-PP orphan   1 weeks ago
perl-Compress-LZ4 orphan   1 weeks ago
perl-Compress-LZF orphan   1 weeks ago
perl-Compress-Snappy  orphan   1 weeks ago
perl-Crypt-ECBorphan   1 weeks ago
perl-Crypt-PBKDF2 orphan   1 weeks ago
perl-Crypt-PWSafe3orphan   1 weeks ago
perl-Crypt-Random-Seedorphan   1 weeks ago
perl-Crypt-Random-TESHA2  orphan   1 weeks ago
perl-Crypt-SaltedHash orphan   1 weeks ago
perl-Date-Easter  orphan   1 weeks ago
perl-Date-Handler orphan   1 weeks ago

Orphaned mongo-java-driver

2020-02-17 Thread Omair Majid
Hi,

I have just orphaned the mongo-java-driver package.

I have not been able to give it the time or attention it needs.
Hopefully someone else can take over this package.

Omair
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[EPEL-devel] Re: KDE Plasma Desktop available for EPEL8

2020-02-17 Thread Troy Dawson
On Mon, Feb 10, 2020 at 10:04 AM Troy Dawson  wrote:
>
> Hello,
> The KDE Plasma Desktop is now available for standard EPEL8.
>
> ## How to install
>
> ### First: install epel-release
> rpm -Uvh 
> https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
>
> ### Second: Enable codeready-builder or PowerTools
>   subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms
>  If CentOS 8 do
>   dnf config-manager --enable PowerTools
>
> ### Third: install KDE
> dnf group install "KDE Plasma Workspaces"
> (Optional) dnf group install kde-desktop
> (Optional) dnf group install kde-media
> (Optional) dnf --enablerepo=epel-testing group install kde-apps [1]
> (Optional) dnf --enablerepo=epel-testing group install okular [1]
>

kde-apps and okular are now out of testing and into regular epel8
If you want, you can now do
  dnf group install kde-apps
  dnf  install okular

> ### (Optional) Fourth: Set sddm as desktop manager
> systemctl set-default graphical.target [if in multi-user.target]
> dnf install sddm\*
> systemctl enable sddm -f
> reboot
>
> Note1: There are some packages missing due to RHEL8 not releasing some
> key -devel packages.  Most notable are plasma-nm* and
> kmail/kaddressbook (and everything related to that).
> Note2: Any packages related to telepathy are also missing.  This is
> due to telepathy's current dependency on python2-dbus, which will not
> be in RHEL8.
> Note3: There are no packages that are qt4 based.
> Note4: There were over a hundred more kde/plasma/qt5 related packages,
> and I didn't know which ones people were actually using.  So if you
> have a favorite KDE/Plasma/QT5 application that isn't currently
> available in epel8, and isn't in the list above, let me know and we'll
> see if we can get it in.
>
> Troy
> [1] - Still in epel-testing.  I will send a follow up email when it is out.
> -- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-00865efa86
> -- https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-bda6808b41
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org


erlang-jose license change

2020-02-17 Thread Randy Barlow
erlang-jose has changed licenses from MPLv2.0 to MIT.

https://src.fedoraproject.org/rpms/erlang-jose/c/cb981bf5


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What's up with koschei?

2020-02-17 Thread Kevin Fenzi
On Mon, Feb 17, 2020 at 01:09:00PM +0100, Mikolaj Izdebski wrote:
> On Mon, Feb 17, 2020 at 10:27 AM Fabio Valentini  wrote:
> > I've noticed that koschei doesn't seem to have scheduled any scratch
> > builds since around the fedora 32 mass rebuild, and it also hasn't
> > picked up the f32 branch yet.
> 
> Koschei collections are manipulated manually by Koschei admins
> (members of sysadmin-koschei FAS group). Since all sysadmin-koschei
> members were on vacation during and after Fedora 32 branching,
> corresponding collections have not been created yet. I expect to
> create them this week.
> 
> > Is there a known "outage" or is it just sitting there idle for some
> > reason? I really like to know when my packages start to FTBFS ...
> 
> That was unplanned outage - someone scaled scheduler service down to
> zero replicas, so it was not running. Unfortunately after move to
> OpenShift we don't have decent monitoring for Koschei, so we don't
> have a way of seeing such problems until they are reported by users.
> I've just scaled scheduler up and it seems to be running again.

We scaled it down because it was causing builders to have full disks and
was breaking things for the mass rebuild. 

https://github.com/fedora-infra/koschei/issues/310

I fear if nothing has changed we will start getting full disks on builds
again. ;( 

kevin


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Pierre-Yves Chibon
On Mon, Feb 17, 2020 at 09:44:21AM -0500, Michael McLean wrote:
>That's the fm-orchestrator rest api. The code maintenance has transferred
>from the Factory 2.0 team to the RHEL Build team (i.e. the "Koji team").
>Historically, the Factory team has handled the Fedora infra deployments.
>However, I think we should move towards having that work more like Koji
>itself, where infra handles the infra parts.

This is a discussion we may want to start sooner rather than later as it
involves resources which are already thin.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Michael McLean
That's the fm-orchestrator rest api. The code maintenance has transferred
from the Factory 2.0 team to the RHEL Build team (i.e. the "Koji team").
Historically, the Factory team has handled the Fedora infra deployments.
However, I think we should move towards having that work more like Koji
itself, where infra handles the infra parts.

On Mon, Feb 17, 2020 at 7:57 AM Neal Gompa  wrote:

> On Mon, Feb 17, 2020 at 7:55 AM Pierre-Yves Chibon 
> wrote:
> >
> > On Mon, Feb 17, 2020 at 12:46:17PM +0100, Mikolaj Izdebski wrote:
> > > mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
> > > can report issues at [2].
> >
> > I don't think that we do, but we may know who does and help you redirect
> your
> > question to them.
> >
> > From the top of my head, I have to admit, I do not know.
> >
> >
>
> The Koji team maintains it now. They've owned it since the beginning
> of the year, I think?
>
>
>
> --
> 真実はいつも一つ!/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Change proposal discussion - Optimize SquashFS Size

2020-02-17 Thread Rex Dieter
John M. Harris Jr wrote:

> On Monday, February 10, 2020 10:53:45 AM MST Jared K. Smith wrote:
>> On Mon, Feb 10, 2020 at 3:30 AM John M. Harris Jr 
>> 
>> wrote:
>> > As for the software available, that's called choice. I know
>> > it's a relative unknown in the GNOME world, as one option is shoved
>> > down everyones' throat, but it's a key part of the KDE ideology, as
>> > well as GNU/Linux itself.

>> John, it's obvious from your posts in this list that you're not a fan of
>> GNOME.  I'd kindly ask you to please refrain from attacking GNOME,
>> especially when the discussion at hand isn't about GNOME itself.  It's
>> not in keeping with the "be excellent to each other" spirit that Fedora
>> likes to keep in its mailing lists.

> An observation is not an attack. What I said about GNOME is simply true,
...

John,
It's the "is shoved down everyone's throat" comment that could be construed 
as hostile and non-constructive in this context.  (I certainly took it that 
way). 

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: copr builds for rawhide 64-bit arches failing

2020-02-17 Thread Pavel Raiskup
Thanks for the report.

On Saturday, February 15, 2020 3:09:49 PM CET Alexander Ploumistos wrote:
> DEBUG util.py:596:  ERROR: not a btrfs filesystem: /var/lib/mock
> DEBUG util.py:596:  ERROR: can't access '/var/lib/mock'
> DEBUG util.py:744:  Child return code was: 1
> DEBUG util.py:1580:  Please ignore the error above above about btrfs.

As the warning says itself, you can ignore this error.  The build failed
because of something else.  Most likely because Rawhide buildroots were
broken in Copr since yesterday (rawhide packages started to be signed by
F33 keys, which were not in mock configuration on builder machines..).

This should be fixed now, can you retry?  Please send us the links to
build failures if you still observe failures.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Stephen John Smoogen
On Mon, 17 Feb 2020 at 06:47, Mikolaj Izdebski  wrote:

> mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
> can report issues at [2].
>
> [1] https://fedoraproject.org/wiki/Infrastructure
> [2] https://pagure.io/fedora-infrastructure/issues



mbs like some other services are 'run' by Infrastructure team. We power it
on and let it do its thing. However we do not maintain the service (we
currently have no one on the team who is familiar with the code or tools
involved in it.) From the filed ticket, we will notify the current
maintainers of mbs to see if they can diagnose the problem.


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Stephan Bergmann

On 17/02/2020 13:54, Pierre-Yves Chibon wrote:

On Mon, Feb 17, 2020 at 12:46:17PM +0100, Mikolaj Izdebski wrote:

mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
can report issues at [2].


I don't think that we do, but we may know who does and help you redirect your
question to them.


thanks; filed  
"`fedpkg module-build` fails with "The modulemd libreoffice.yaml is 
invalid. Please verify the syntax is correct." upon buildopts: arches: 
[x86_64]" now

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Neal Gompa
On Mon, Feb 17, 2020 at 7:55 AM Pierre-Yves Chibon  wrote:
>
> On Mon, Feb 17, 2020 at 12:46:17PM +0100, Mikolaj Izdebski wrote:
> > mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
> > can report issues at [2].
>
> I don't think that we do, but we may know who does and help you redirect your
> question to them.
>
> From the top of my head, I have to admit, I do not know.
>
>

The Koji team maintains it now. They've owned it since the beginning
of the year, I think?



-- 
真実はいつも一つ!/ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Pierre-Yves Chibon
On Mon, Feb 17, 2020 at 12:46:17PM +0100, Mikolaj Izdebski wrote:
> mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
> can report issues at [2].

I don't think that we do, but we may know who does and help you redirect your
question to them.

From the top of my head, I have to admit, I do not know.


Pierre

> [1] https://fedoraproject.org/wiki/Infrastructure
> [2] https://pagure.io/fedora-infrastructure/issues
> 
> --
> Mikolaj Izdebski
> 
> On Mon, Feb 17, 2020 at 12:20 PM Stephan Bergmann  wrote:
> >
> > I am trying to do a build of LibreOffice from Fedora RPMs (à la
> > ), but `fedpkg
> > module-build` keeps failing with
> >
> > > The modulemd libreoffice.yaml is invalid. Please verify the syntax is 
> > > correct.
> >
> > after
> > 
> > "Restrict builds to x86_64".
> >
> > Judging from strace and what little information the --verbose option of
> > fedpkg provides, it looks like that error message is reported back from
> > mbs.fedoraproject.org:443.  Could it be that that installation is
> > missing
> > 
> > "Add support for new ModulemdBuildopts arches attribute"?
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What's up with koschei?

2020-02-17 Thread Fabio Valentini
On Mon, Feb 17, 2020 at 1:12 PM Mikolaj Izdebski  wrote:
>
> On Mon, Feb 17, 2020 at 10:27 AM Fabio Valentini  wrote:
> > I've noticed that koschei doesn't seem to have scheduled any scratch
> > builds since around the fedora 32 mass rebuild, and it also hasn't
> > picked up the f32 branch yet.

(snip)

> Koschei collections are manipulated manually by Koschei admins
> (members of sysadmin-koschei FAS group). Since all sysadmin-koschei
> members were on vacation during and after Fedora 32 branching,
> corresponding collections have not been created yet. I expect to
> create them this week.

I didn't know that adding new releases is a manual process. Thanks for the info.

> > Is there a known "outage" or is it just sitting there idle for some
> > reason? I really like to know when my packages start to FTBFS ...
>
> That was unplanned outage - someone scaled scheduler service down to
> zero replicas, so it was not running. Unfortunately after move to
> OpenShift we don't have decent monitoring for Koschei, so we don't
> have a way of seeing such problems until they are reported by users.
> I've just scaled scheduler up and it seems to be running again.

Awesome, thanks for fixing it!

Fabio

> Thanks for the report.
>
> --
> Mikolaj Izdebski
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: What's up with koschei?

2020-02-17 Thread Mikolaj Izdebski
On Mon, Feb 17, 2020 at 10:27 AM Fabio Valentini  wrote:
> I've noticed that koschei doesn't seem to have scheduled any scratch
> builds since around the fedora 32 mass rebuild, and it also hasn't
> picked up the f32 branch yet.

Koschei collections are manipulated manually by Koschei admins
(members of sysadmin-koschei FAS group). Since all sysadmin-koschei
members were on vacation during and after Fedora 32 branching,
corresponding collections have not been created yet. I expect to
create them this week.

> Is there a known "outage" or is it just sitting there idle for some
> reason? I really like to know when my packages start to FTBFS ...

That was unplanned outage - someone scaled scheduler service down to
zero replicas, so it was not running. Unfortunately after move to
OpenShift we don't have decent monitoring for Koschei, so we don't
have a way of seeing such problems until they are reported by users.
I've just scaled scheduler up and it seems to be running again.

Thanks for the report.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Mikolaj Izdebski
mbs.fedoraproject.org is maintained by Infrastructure Team [1]. You
can report issues at [2].

[1] https://fedoraproject.org/wiki/Infrastructure
[2] https://pagure.io/fedora-infrastructure/issues

--
Mikolaj Izdebski

On Mon, Feb 17, 2020 at 12:20 PM Stephan Bergmann  wrote:
>
> I am trying to do a build of LibreOffice from Fedora RPMs (à la
> ), but `fedpkg
> module-build` keeps failing with
>
> > The modulemd libreoffice.yaml is invalid. Please verify the syntax is 
> > correct.
>
> after
> 
> "Restrict builds to x86_64".
>
> Judging from strace and what little information the --verbose option of
> fedpkg provides, it looks like that error message is reported back from
> mbs.fedoraproject.org:443.  Could it be that that installation is
> missing
> 
> "Add support for new ModulemdBuildopts arches attribute"?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> 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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1803552] perl-Devel-Hide-0.0013 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803552

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-Hide-0.0013-1.fc
   ||32
   ||perl-Devel-Hide-0.0013-1.fc
   ||33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-17 11:23:44



--- Comment #3 from Paul Howarth  ---
F33 Build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41541676

F32 Build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=41541997

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Who maintains the service at mbs.fedoraproject.org:443?

2020-02-17 Thread Stephan Bergmann
I am trying to do a build of LibreOffice from Fedora RPMs (à la 
), but `fedpkg 
module-build` keeps failing with



The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct.


after 
 
"Restrict builds to x86_64".


Judging from strace and what little information the --verbose option of 
fedpkg provides, it looks like that error message is reported back from 
mbs.fedoraproject.org:443.  Could it be that that installation is 
missing 
 
"Add support for new ModulemdBuildopts arches attribute"?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Signal 4 (ILL) caught by ps in mock

2020-02-17 Thread Dan Horák
On Mon, 17 Feb 2020 11:26:30 +0100
Petr Pisar  wrote:

> On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> > On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> > >
> > > On Fri, 14 Feb 2020 10:28:10 -0700
> > > Christoph Junghans  wrote:
> > >
> > > > >>
> > > > >> In your case procps-ng package seems to be miscompiled (or
> > > > >> run on an incopatible hardware). I recommend getting a shell
> > > > >> in the mock enviroment (mock --shell) and investigeting
> > > > >> whether the ps program works there).
> > > > >
> > > > > Ok, I will try that and report back.
> > > > It is indeed broken in shell as well:
> > > >  sh-5.0# ps
> > > >
> > > > Signal 4 (ILL) caught by ps (3.3.15).
> > > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > > Segmentation fault (core dumped)
> > >
> > > works (no crash) on my Power9 system, but it could be a P9
> > > instruction sneaked into the binary and crashing on Power8
> > > systems. I'll take a look, but if you could file a bug (with me
> > > in CC), it would be helpful.
> > just to make sure, I am running this in mock on the following
> > system: $ cat /proc/cpuinfo
> > processor : 0
> > vendor_id : GenuineIntel
> > cpu family : 6
> > model : 142
> > model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
> 
> Then you actually run the PowerPC ps binary in QEMU emulator. Could
> you show the /proc/cpuinfo from inside of the mock environment?

first I suggest to use the latest qemu from the virt-preview repo [1]
and if it still SIGILLs, then report a bugu against qemu. I don't see
any problem with "ps" on (real) Power8 or Power9 hw, so most likely it's
an emulation bug.

[1]
https://copr.fedorainfracloud.org/coprs/g/virtmaint-sig/virt-preview/



Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora-Cloud-31-20200217.0 compose check report

2020-02-17 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Signal 4 (ILL) caught by ps in mock

2020-02-17 Thread Petr Pisar
On Fri, Feb 14, 2020 at 02:33:15PM -0700, Christoph Junghans wrote:
> On Fri, Feb 14, 2020 at 10:37 AM Dan Horák  wrote:
> >
> > On Fri, 14 Feb 2020 10:28:10 -0700
> > Christoph Junghans  wrote:
> >
> > > >>
> > > >> In your case procps-ng package seems to be miscompiled (or run on
> > > >> an incopatible hardware). I recommend getting a shell in the mock
> > > >> enviroment (mock --shell) and investigeting whether the ps program
> > > >> works there).
> > > >
> > > > Ok, I will try that and report back.
> > > It is indeed broken in shell as well:
> > >  sh-5.0# ps
> > >
> > > Signal 4 (ILL) caught by ps (3.3.15).
> > > /usr/bin/ps:ps/display.c:66: please report this bug
> > > Segmentation fault (core dumped)
> >
> > works (no crash) on my Power9 system, but it could be a P9 instruction
> > sneaked into the binary and crashing on Power8 systems. I'll take a
> > look, but if you could file a bug (with me in CC), it would be helpful.
> just to make sure, I am running this in mock on the following system:
> $ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 142
> model name : Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz

Then you actually run the PowerPC ps binary in QEMU emulator. Could you show
the /proc/cpuinfo from inside of the mock environment?

-- Petr


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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to get proper nsswitch.conf?

2020-02-17 Thread Pavel Březina

On 2/14/20 8:19 PM, Michael Catanzaro wrote:
On Thu, Feb 13, 2020 at 7:13 pm, Michael Catanzaro 
 wrote:

Why don't we have mymachines here?


This is systemd module, right? There was some discussion about it in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P/#PNKKVG3K6WAU42CCPVIEV6LZY7PWUG4P

I don't really have all the information but apparently there are some 
collisions with LDAP/FreeIPA and is not supposed to be enabled by default.



Next question, I have:

passwd: sss files systemd
shadow: files sss
group: sss files systemd

The difference is that authselect doesn't write the shadow line [1], 
that one is coming from our glibc [2]. (glibc is already patched to 
enable sssd.) That inconsistency seems odd; shouldn't authselect be 
modifying the shadow line as well?


SSSD does not support shadow therefore it is not added by authselect. 
IMHO it should be removed from glibc nsswitch.conf as well.


Then it also doesn't make sense that we put files before sss in half the 
lines, and sss before files in the other half.


Basically only passwd and group needs to have sss consulted first 
because SSSD now handles local users as well and this way will glibc 
first consults SSSD in-memory cache before reading from disk.


It does not matter with the other maps. It makes sense to me to have 
SSSD first because nowadays if you are joined to a remote domain you 
have these maps served by SSSD from LDAP then having the configuration 
in files, at least in enterprise scenarios.


sudoers have files first because there is always /etc/sudoers with at 
least %wheel so it makes sense to read it first.




[1] 
https://github.com/pbrezina/authselect/blob/master/profiles/sssd/nsswitch.conf 

[2] 
https://src.fedoraproject.org/rpms/glibc/blob/master/f/glibc-fedora-nsswitch.patch 





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803711



--- Comment #1 from Petr Pisar  ---
Those are the rebased packages between last successful build and now:

Removed packages:
annobin-9.01
binutils-2.33.1
binutils-gold-2.33.1
cpio-2.12
fedora-gpg-keys-32
fedora-release-32
fedora-release-common-32
fedora-repos-32
fedora-repos-rawhide-32
freetype-2.10.0
freetype-devel-2.10.0
gdb-minimal-9.0.50.20191119
glib2-2.63.4
glibc-2.30.9000
glibc-common-2.30.9000
glibc-devel-2.30.9000
glibc-headers-2.30.9000
glibc-minimal-langpack-2.30.9000
hwdata-0.331
kernel-headers-5.5.0
krb5-libs-1.17.1
libarchive-3.4.0
libblkid-2.35
liberation-fonts-common-2.00.5
liberation-sans-fonts-2.00.5
libfdisk-2.35
libmount-2.35
libsmartcols-2.35
libtasn1-4.15.0
libuuid-2.35
libxcrypt-4.4.11
libxcrypt-devel-4.4.11
libXt-1.1.5
mesa-libGL-19.3.3
mesa-libglapi-19.3.3
pcre-8.43
perl-Devel-PPPort-3.56
perl-parent-0.237
perl-Scalar-List-Utils-1.53
python3-3.8.1
python3-libs-3.8.1
redhat-rpm-config-149
sed-4.5
sqlite-libs-3.30.1
systemd-libs-244.1
util-linux-2.35
xkeyboard-config-2.28
Added packages:
annobin-9.07
binutils-2.34
binutils-gold-2.34
cpio-2.13
dejavu-fonts-common-2.37
dejavu-sans-fonts-2.37
fedora-gpg-keys-33
fedora-release-33
fedora-release-common-33
fedora-repos-33
fedora-repos-rawhide-33
freetype-2.10.1
freetype-devel-2.10.1
gdb-minimal-9.1
glib2-2.63.5
glibc-2.31
glibc-common-2.31
glibc-devel-2.31
glibc-headers-2.31
glibc-minimal-langpack-2.31
guile-2.0.14
hwdata-0.332
kernel-headers-5.6.0
krb5-libs-1.18
langpacks-core-font-en-3.0
libarchive-3.4.2
libblkid-2.35.1
liberation-fonts-common-2.1.0
liberation-sans-fonts-2.1.0
libfdisk-2.35.1
libmount-2.35.1
libsmartcols-2.35.1
libtasn1-4.16.0
libuuid-2.35.1
libxcrypt-4.4.13
libxcrypt-devel-4.4.13
libXt-1.2.0
mesa-libGL-20.0.0~rc2
mesa-libglapi-20.0.0~rc2
pcre-8.44
perl-Devel-PPPort-3.57
perl-parent-0.238
perl-Scalar-List-Utils-1.54
python3-3.8.2~rc1
python3-libs-3.8.2~rc1
redhat-rpm-config-151
sed-4.8
sqlite-libs-3.31.1
systemd-libs-245~rc1
util-linux-2.35.1
xkeyboard-config-2.29
xxhash-libs-0.7.2

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1800988] perl-Data-Report-1.001 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1800988

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Data-Report-1.001-32.f
   ||c32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-17 09:58:42



--- Comment #3 from Jitka Plesnikova  ---
perl-Data-Report-1.001-32.fc32 built by sciurius

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1803711] perl-Tk-804.034-9.fc33 FTBFS: t/entry.t test fails

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803711

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-Tk-804.034-9.fc33  |perl-Tk-804.034-9.fc33
   |FTBFS:  |FTBFS: t/entry.t test fails



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1803711] New: perl-Tk-804.034-9.fc33 FTBFS:

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803711

Bug ID: 1803711
   Summary: perl-Tk-804.034-9.fc33 FTBFS:
   Product: Fedora
   Version: rawhide
   URL: https://koji.fedoraproject.org/koji/buildinfo?buildID=
1463067
Status: NEW
 Component: perl-Tk
  Assignee: xav...@bachelot.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andreas.bierf...@lowlatency.de,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk, xav...@bachelot.org
  Target Milestone: ---
Classification: Fedora



perl-Tk-804.034-9.fc33 fails to build in Fedora 33 because tests fail like
this:

t/dirtree.t .. ok
#   Failed test at t/entry.t line 682.
#  got: '0'
# expected: '1'
#   Failed test at t/entry.t line 691.
#  got: '0'
# expected: '1'
#   Failed test at t/entry.t line 744.
#  got: '5'
# expected: '6'
#   Failed test at t/entry.t line 1217.
#  got: '4'
# expected: '5'
# Looks like you failed 4 tests of 351.
t/entry.t  
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/351 subtests 
(less 39 skipped subtests: 308 okay)
XS_Tk__Callback_Call error:Intentional error.
XS_Tk__Callback_Call error:Intentional error.
t/errordialog.t .. ok
[...]
Test Summary Report
---
t/canvas.t (Wstat: 0 Tests: 166 Failed: 0)
  TODO passed:   124
t/entry.t  (Wstat: 1024 Tests: 351 Failed: 4)
  Failed tests:  197, 201, 212, 326
  Non-zero exit status: 4
t/listbox.t(Wstat: 0 Tests: 537 Failed: 0)
  TODO passed:   320-322, 328, 502
t/text.t   (Wstat: 0 Tests: 415 Failed: 0)
  TODO passed:   121
t/wm-tcl.t (Wstat: 0 Tests: 315 Failed: 0)
  TODO passed:   86-87, 154-157, 164-165, 175-178, 221-224
237-239, 264-265, 275-276, 280-283
t/zzScrolled.t (Wstat: 0 Tests: 94 Failed: 0)
  TODO passed:   52, 66, 80, 94
Files=76, Tests=4361, 45 wallclock secs ( 0.78 usr  0.14 sys +  8.24 cusr  1.11
csys = 10.27 CPU)
Result: FAIL
Failed 1/76 test programs. 4/4361 subtests failed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1795112] Upgrade perl-Data-Perl to 0.002011

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1795112

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Data-Perl-0.002011-1.f
   ||c32
 Resolution|--- |RAWHIDE
Last Closed||2020-02-17 09:51:35



--- Comment #2 from Jitka Plesnikova  ---
perl-Data-Perl-0.002011-1.fc32 built by corsepiu

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1800471] Upgrade perl-Type-Tiny to 1.008005

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1800471

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Type-Tiny-1.008005-1.f
   ||c33
   ||perl-Type-Tiny-1.008005-1.f
   ||c32
 Resolution|--- |RAWHIDE
Last Closed||2020-02-17 09:50:05



--- Comment #2 from Jitka Plesnikova  ---
perl-Type-Tiny-1.008005-1.fc33 and perl-Type-Tiny-1.008005-1.fc32 built by
corsepiu

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: CPE Weekly: 2020-02-14

2020-02-17 Thread Aoife Moloney
Thanks for the feedback Kamil!

I look forward to bridging that 2.7% discrepancy soon! :)


Kindest regards,
Aoife

On Mon, Feb 17, 2020 at 9:33 AM Kamil Paral  wrote:

> On Fri, Feb 14, 2020 at 6:58 PM Aoife Moloney  wrote:
>
>> # CPE Weekly: 2020-02-14
>>
>
> Hey Aoife,
> thanks a lot for improving report formatting. It is now 97.3% more
> readable! :-) Looks great.
>
> Kamil
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 

Aoife Moloney

Feature Driver

Community Platform Engineering Team

Red Hat EMEA 

Communications House

Cork Road

Waterford

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1794452] perl-ExtUtils-CppGuess-0.21 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1794452

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-ExtUtils-CppGuess-0.21
   ||-1.fc33
   ||perl-ExtUtils-CppGuess-0.21
   ||-1.fc32
 Resolution|--- |RAWHIDE
   Assignee|mhron...@redhat.com |jples...@redhat.com
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-17 09:46:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1799856] perl-Syntax-Highlight-Perl6: FTBFS in Fedora rawhide/f32

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1799856

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com
Link ID||CPAN 131760
   Doc Type|--- |If docs needed, set a value



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


[Bug 1793228] perl-Schedule-Cron-Events-1.96 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1793228

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Schedule-Cron-Events-1
   ||.96-1.fc33
   ||perl-Schedule-Cron-Events-1
   ||.96-1.fc32
 Resolution|--- |RAWHIDE
   Assignee|redhat-bugzilla@linuxnetz.d |jples...@redhat.com
   |e   |
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-17 09:31:53



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: CPE Weekly: 2020-02-14

2020-02-17 Thread Kamil Paral
On Fri, Feb 14, 2020 at 6:58 PM Aoife Moloney  wrote:

> # CPE Weekly: 2020-02-14
>

Hey Aoife,
thanks a lot for improving report formatting. It is now 97.3% more
readable! :-) Looks great.

Kamil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


What's up with koschei?

2020-02-17 Thread Fabio Valentini
Hi everybody,

I've noticed that koschei doesn't seem to have scheduled any scratch
builds since around the fedora 32 mass rebuild, and it also hasn't
picked up the f32 branch yet.

Is there a known "outage" or is it just sitting there idle for some
reason? I really like to know when my packages start to FTBFS ...

Fabio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1802999] Upgrade perl-Pegex to 0.75

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1802999

Gerd Pokorra  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Pegex-0.75-1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-02-17 09:17:23



--- Comment #1 from Gerd Pokorra  ---
perl-Pegex-0.75-1 are built for f32 and rawhide (f33).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Package uses Gradle (retired) to build: what to do?

2020-02-17 Thread Jun Aruga
Hi Mikolaj,

Thanks for your info and recommendation.

> Currently I don't have time to maintain Gradle in Fedora. Several of
my packages are built with Gradle by their upstreams, but currently it
is more feasible to port packages to be built with Maven rather than
maintaining Gradle in Fedora. But this may change in the future - as
more projects start to use Gradle I may decide to take up its
maintenance in upcoming years.

> There are several different ways to handle this problem. In this case
my recommendation is to port packages to be built with Maven instead
of Gradle.

Shall we write something about the Gradle's situation to the wiki
Packaging:Java page?
https://fedoraproject.org/wiki/Packaging:Java

I think that it helps other Java packagers.

-- 
Jun | He - His - Him
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[Bug 1803391] perl-Devel-CheckOS-1.83 is available

2020-02-17 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803391

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Devel-CheckOS-1.83-1.f
   ||c33
   ||perl-Devel-CheckOS-1.83-1.f
   ||c32
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-02-17 09:06:15



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org


Re: Package uses Gradle (retired) to build: what to do?

2020-02-17 Thread Mikolaj Izdebski
On Sat, Feb 8, 2020 at 12:23 PM Ankur Sinha  wrote:
>
> Hello,
>
> netcdf-java[1] uses the Gradle build system, and is required to update
> hdfview[2] to the latest version. Gradle, however, was retired[3] as
> "out of date, broken, fails to build, basically unmaintainable".
>
> Now, I know that following our system, one must package Gradle first but
> given the retirement comment, packaging and then maintaining it does not
> appear a simple task, and for one dependency only, it seems overkill.
>
> Is there perhaps a way of bypassing that somehow? For example, is there
> a way to use good old Maven to build a Gradle based project?

There are several different ways to handle this problem. In this case
my recommendation is to port packages to be built with Maven instead
of Gradle. The exact way to do this varies between projects, but in
general you'd need to obtain Maven POMs for particular project (eg.
from Maven Central), add missing build instructions ( section
of POM files) and model composition/inheritance ( and
 elements of POM). There are several cases of packages that
are built this way in Fedora, which you can use as examples. Let me
know if you need more help.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Fedora-Cloud-30-20200217.0 compose check report

2020-02-17 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Package uses Gradle (retired) to build: what to do?

2020-02-17 Thread Mikolaj Izdebski
On Thu, Feb 13, 2020 at 11:33 AM Jun Aruga  wrote:
>
> > Anyone with the time to (co-)maintain Gradle? :)
>
> I added Mikolaj and Daniel to TO.
> They had maintained gradle before being dead.package, seeing the past
> commits in rpms/gradle.
> Mikolaj and Daniel, do you like to come back as a maintainer of rpms/gradle?

Currently I don't have time to maintain Gradle in Fedora. Several of
my packages are built with Gradle by their upstreams, but currently it
is more feasible to port packages to be built with Maven rather than
maintaining Gradle in Fedora. But this may change in the future - as
more projects start to use Gradle I may decide to take up its
maintenance in upcoming years.

--
Mikolaj Izdebski
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org