Open Seats on the Fedora Packaging Committee

[James Antill]

 The Fedora Packaging Committee has some open seats and is accepting
submissions from interested candidates to serve on the FPC.

 The FPC would like to thank Orion Poplawski, and Jonathan Wakely for
their service.

 This position involves not only reviewing Packaging Guideline drafts
submitted to the FPC for consideration, but also helping rewrite drafts
to resolve issues in a more acceptable fashion. Additionally, the FPC
reviews UID/GID soft static assignment.

 Currently the FPC meets on IRC weekly, on Thursdays based around 12:00
east coast US time, for approximately an hour.
 That can change slightly, but any new time would need to be good for
all the members (East Coast US and German TZs, at least).

 FPC members serve for as long as they are willing, there are currently
no term limits. All decisions are voted on using a +1 (for), 0
(abstain), and -1 (against) mechanism, and all decisions must be
approved by a majority (+5). FPC Meetings do not happen if a quorum (5
members) is not present. Candidates who are interested should provide
the following details to the FPC for consideration, by emailing it
directly to me (james(a)fedoraproject.org).

 The FPC will consider all candidates, but strongly prefers candidates
who have extensive experience packaging in Fedora. Due to the current
environment we will be accepting applications for the next _five_ weeks
(deadline Wednesday, 2018-06-24).

 Name:
 FAS Account:
 Provenpackager? (Yes/No):
 Main area of packaging interest/expertise:
 Reason(s) for wanting to join the FPC:


 Thanks in advance,
  ~James

___
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

Schedule for Thursday's FPC Meeting (2020-05-21 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2020-05-21 16:00 UTC in #fedora-meeting-1 on 
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2020-05-21 09:00 PDT  US/Pacific
2020-05-21 12:00 EDT  --> US/Eastern <--
2020-05-21 16:00 UTC  UTC   
2020-05-21 17:00 BST  Europe/London 
2020-05-21 18:00 CEST Europe/Berlin 
2020-05-21 18:00 CEST Europe/Paris  
2020-05-21 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2020-05-22 00:00 HKT  Asia/Hong_Kong
2020-05-22 00:00 +08  Asia/Singapore
2020-05-22 01:00 JST  Asia/Tokyo
2020-05-22 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

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

= Followup Issues =

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #909 Suggest that linting/measuring-coverage is not for %check
.fpc 909
https://pagure.io/packaging-committee/issue/909

#topic #963 Blanket Bootstrap Exception for building Mono 
.fpc 963
https://pagure.io/packaging-committee/issue/963

= New Issues =

#topic #982 Font packaging stopped working in rawhide/F33 
.fpc 963
https://pagure.io/packaging-committee/issue/963

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines 
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-938 Add Package Review Process page 
https://pagure.io/packaging-committee/pull-request/938

= New Pull Requests =

#topic #pr-#942 Recommend storing changelog entries in separate file. 
https://pagure.io/packaging-committee/pull-request/942

#topic #pr-#947 Deprecate Old Style Dependency Generators 
https://pagure.io/packaging-committee/pull-request/947

#topic #pr-#954 Prohibit use of `rpm` command from specfile. 
https://pagure.io/packaging-committee/pull-request/954

= Open Floor = 

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

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

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

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-53b85179ad has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-53b85179ad`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-53b85179ad

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-aa8ce752c3   
pure-ftpd-1.0.49-4.el8
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-03d5f14bbe   
chromium-81.0.4044.138-1.el8
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0d41abf072   
perl-Mojolicious-8.42-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-765ceaa306   
clamav-0.102.3-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-30aba92944   
log4net-2.0.8-10.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2056b1c4a9   
exim-4.93-3.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5660594875   
python-markdown2-2.3.9-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c3fca161ee   
netdata-1.22.1-3.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-38309f9f6f   
transmission-2.94-9.el8
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-06e970da9c   
knot-resolver-5.1.1-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

colm-0.13.0.7-1.el8
laszip-3.4.3-2.el8
libmpdclient-2.18-1.el8
nagios-plugins-2.3.3-2.el8
percolator-3.05-1.el8
purple-discord-0-28.20200512git1174458.el8
purple-hangouts-0-67.20200423hg789eaca.el8
python-certbot-dns-digitalocean-1.4.0-1.el8
python-digitalocean-1.15.0-1.el8
resalloc-3.0-1.el8
testcloud-0.3.3-1.el8

Details about builds:



 colm-0.13.0.7-1.el8 (FEDORA-EPEL-2020-bcc14d4cfa)
 Programming language designed for the analysis of computer languages

Update Information:

Initial release for epel8

ChangeLog:





 laszip-3.4.3-2.el8 (FEDORA-EPEL-2020-77f828872d)
 Quickly turns bulky LAS files into compant LAZ files

Update Information:

Sync to libLAS 3.4.3

ChangeLog:





 libmpdclient-2.18-1.el8 (FEDORA-EPEL-2020-4e5149a6db)
 Library for interfacing Music Player Daemon

Update Information:

Update to 2.18.

ChangeLog:

* Tue May 19 2020 Vasiliy Glazov  - 2.18-1
- Update to 2.18
* Wed Jan 29 2020 Fedora Release Engineering  - 2.16-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 nagios-plugins-2.3.3-2.el8 (FEDORA-EPEL-2020-053f143928)
 Host/service/network monitoring program plugins for Nagios

Update Information:

Remove ssl_validity as perl-Convert-ASN1 has been retired.  BZ#1837397

ChangeLog:

* Wed Oct  8 2003 Martin Jackson  - 2.3.3-2
- Remove ssl_validity as perl-Convert-ASN1 has been retired.  BZ#1837397

References:

  [ 1 ] Bug #1837397 - Can't install "nagios-plugins-all" because 
"perl-Convert-ASN1" is missing for RHEL 8 / CentOS 8
https://bugzilla.redhat.com/show_bug.cgi?id=1837397




 percolator-3.05-1.el8 (FEDORA-EPEL-2020-dcaee7dc3d)
 Software for postprocessing of shotgun proteomics data

Update Information:

- Release 3.05

ChangeLog:





 purple-discord-0-28.20200512git1174458.el8 (FEDORA-EPEL-2020-a79e152fcb)
 Discord plugin for libpurple

Update Information:

Updated some purple plugins to latest snapshots.

[Bug 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-b4a3fbecea has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-b4a3fbecea`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b4a3fbecea

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-c0d616ed91 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-c0d616ed91`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c0d616ed91

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
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-05-21 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/05/21/report-389-ds-base-1.4.4.2-20200520gitc350ddc.fc32.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

[Bug 1834480] perl-FFI-CheckLib-0.27 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-FFI-CheckLib-0.27-1.fc |perl-FFI-CheckLib-0.27-1.fc
   |33  |33
   ||perl-FFI-CheckLib-0.27-1.fc
   ||32
 Resolution|--- |ERRATA
Last Closed||2020-05-21 02:52:17



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-12cd8fc8b8 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
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: Koji build failure misattribution - root.log instead of build.log?

[Adam Williamson]

On Wed, 2020-05-20 at 16:15 -0700, Adam Williamson wrote:
> On Thu, 2020-05-21 at 00:26 +0200, Pavel Raiskup wrote:
> > On Wednesday, May 20, 2020 11:43:10 PM CEST Michel Alexandre Salim wrote:
> > > Hi,
> > > 
> > > I often notice that my scratch build right after updating some packages 
> > > (or packaging them for the first time) would fail -- e.g. due to some 
> > > strict GCC checks -- but Koji would direct me to inspect root.log, even 
> > > though there's no error there and the failure is logged in build.log
> > > 
> > > One recent example: 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=44743799
> > > 
> > > Known issue, and if not, where do I report it?
> > 
> > Probably worth reporting.  Koji decides based on mock's exit status;  so 
> > unless
> > Koji misinterprets the exit status from mock (would be koji issue), this 
> > should
> > be returned against mock.
> 
> It's koji that broke, I think. It's been this way for several months,
> but I never bothered reporting it as I just got used to ignoring what
> Koji said.
> 
> It should say root.log if the exit code is 30 and build.log if it's 1 -
> those are the two most common cases, at least - but it seems to always
> say root.log even if the exit code is 1, now.

Aha, these look relevant:

https://pagure.io/koji/c/3f64a48
https://pagure.io/koji/c/c7d35e9

I *suspect* we have only the first deployed right now, and the second
is intended to fix the problem we currently have. If we update our prod
koji to the second, we should get "see build.log or root.log" when the
exit code is 1.

The issue where this is being discussed is
https://pagure.io/koji/issue/1679 .
-- 
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: Koji build failure misattribution - root.log instead of build.log?

[Adam Williamson]

On Thu, 2020-05-21 at 00:26 +0200, Pavel Raiskup wrote:
> On Wednesday, May 20, 2020 11:43:10 PM CEST Michel Alexandre Salim wrote:
> > Hi,
> > 
> > I often notice that my scratch build right after updating some packages 
> > (or packaging them for the first time) would fail -- e.g. due to some 
> > strict GCC checks -- but Koji would direct me to inspect root.log, even 
> > though there's no error there and the failure is logged in build.log
> > 
> > One recent example: 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=44743799
> > 
> > Known issue, and if not, where do I report it?
> 
> Probably worth reporting.  Koji decides based on mock's exit status;  so 
> unless
> Koji misinterprets the exit status from mock (would be koji issue), this 
> should
> be returned against mock.

It's koji that broke, I think. It's been this way for several months,
but I never bothered reporting it as I just got used to ignoring what
Koji said.

It should say root.log if the exit code is 30 and build.log if it's 1 -
those are the two most common cases, at least - but it seems to always
say root.log even if the exit code is 1, now.
-- 
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

Heads up: gdal-3.1.0 coming to rawhide

[Sandro Mani]

Hi

I'm building gdal-3.1.0 in a f33 side-tag, and I'll also rebuild all 
dependencies:


bes
cloudcompare
dans-gdal-scripts
gazebo
GMT
grass
gtatool
liblas
mapnik
mapserver
merkaartor
ncl
nodejs-gdal
opencv
OpenSceneGraph
osgearth
postgis
python-fiona
python-rasterio
qgis
qlandkartegt
qmapshack
R-rgdal
saga
vfrnav


Sandro

___
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: Koji build failure misattribution - root.log instead of build.log?

[Pavel Raiskup]

On Wednesday, May 20, 2020 11:43:10 PM CEST Michel Alexandre Salim wrote:
> Hi,
> 
> I often notice that my scratch build right after updating some packages 
> (or packaging them for the first time) would fail -- e.g. due to some 
> strict GCC checks -- but Koji would direct me to inspect root.log, even 
> though there's no error there and the failure is logged in build.log
> 
> One recent example: 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44743799
> 
> Known issue, and if not, where do I report it?

Probably worth reporting.  Koji decides based on mock's exit status;  so unless
Koji misinterprets the exit status from mock (would be koji issue), this should
be returned against mock.

Pavel


>
> Thanks,
> 
> -- 
> Michel Alexandre Salim
> profile: https://keybase.io/michel_slm
> chat via email: https://delta.chat/
> GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
> ___
> 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

Koji build failure misattribution - root.log instead of build.log?

[Michel Alexandre Salim]

Hi,

I often notice that my scratch build right after updating some packages 
(or packaging them for the first time) would fail -- e.g. due to some 
strict GCC checks -- but Koji would direct me to inspect root.log, even 
though there's no error there and the failure is logged in build.log


One recent example: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=44743799


Known issue, and if not, where do I report it?

Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: Fedora 33 System-Wide Change proposal: Aarch64 Pointer Authentication & Branch Target Enablement

[Jeremy Linton]

Hi,

On 5/19/20 2:21 PM, Igor Raits wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, 2020-05-18 at 15:36 -0400, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication

== Summary ==
Arm Pointer Authentication (PAC) is a method of hardening code from
Return Oriented Programming (ROP) attacks. It uses a tag in a pointer
to sign and verify pointers. Branch Target Identification (BTI) is
another code hardening method, where the branch/jump target is
identified with a special landing pad instruction. Outside of some
system support in glibc+kernel, packages gain the additional
hardening
by compiling with the -mbranch-protection= flag available in recent
versions of GCC. In particular -mbranch-protection=standard enables
both BTI and PAC, with backwards compatible to armv8.0 code sequences
that activate on v8.3 (PAC) & v8.5 (BTI) enabled Arm machines.


Is there some noticeable performance drop or anything like that?


Potentially, please see my longer response in the other email.





== Owner ==
* Name: [[User:jlinton| Jeremy Linton]] & ARM SIG
* Email: jeremy.lin...@arm.com


== Benefit to Fedora ==

PAC & BTI are code hardening features, they should serve to make
fedora more resistant to a couple further classes of runtime attacks.
By enabling this early, fedora is once again proven to be at the
leading edge of security and linux development. If everything works
as
planned, this change will be invisible to the end user, except in
cases where the applications will trap behaviour that appears to be
caused by exploit attempts.

== Scope ==
* Proposal owners:
Work with individual package maintainers in the case of build
failures
or runtime exceptions. In the latter case there are two
possibilities.
First on v8.0 hardware, which is currently the most common, the
additional instruction sequences are treated as NOP's and should be
completely ignored by the hardware. It may be possible on v8.3/8.5
hardware that PAC or BTI may need additional tweaks for hand written
assembly which interacts with PAC/BTI enabled code.


It would be nice if you would specify which exact flags and where you
will add them, so that it would be easy to see which people we need to
get on board for this change.


Its the gcc flag "-mbranch-protection=standard" I mentioned in the 
summary above. The assumption is that we place it in the arch specific 
opt stanza in /usr/lib/rpm/redhat/rpmrc, or we extend 
/usr/lib/rpm/redhat/macros hardening section to allow an arch specific 
hardening.


I've rebuilt a minimal install by creating a custom mock template, but I 
don't think that is the right official answer.



Thanks,
___
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: Fedora 33 System-Wide Change proposal: Aarch64 Pointer Authentication & Branch Target Enablement

[Jeremy Linton]

Hi,

On 5/19/20 1:38 PM, Przemek Klosowski via devel wrote:

On 5/18/20 3:36 PM, Ben Cotton wrote:

Arm Pointer Authentication (PAC) is a method of hardening code from
Return Oriented Programming (ROP) attacks. It uses a tag in a pointer
to sign and verify pointers. Branch Target Identification (BTI) is
another code hardening method, where the branch/jump target is
identified with a special landing pad instruction.


Is there a performance impact? do those landing pad instructions take an 
execution pipeline slots?


Potentially, depends on the microarch. In general on existing machines 
they decode as HIT/NOPs and get tossed, and since most of the ARM cores 
aren't decode limited it won't have an effect. On cores where its 
actually active its a lot harder to generalize and compare performance 
at the moment. In theory if a particular machine has a bad 
implementation we can just disable it for that given machine to return 
the behavior to just HIT/NOP.




We're planning to use AUTIASP+RET, not RETAA, right?
I believe that is the case, retaa requires a 8.3 machine and we need 
compatibility with 8.0 so we need to stick to the pac portion which is 
in the HINT space and translates to NOPs on < v8.3 hardware.


Note:

https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aarch64/aarch64.c#L8208


Thanks,
___
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: Aggressive updating (Python 3.9): Are we trying to hard?

[Miro Hrončok]

On 20. 05. 20 21:38, Miroslav Suchý wrote:

Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):

Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But instead of 
asking ourselves, "should we push
in the VERY latest Python and hope it's ok?", we just patch the build system to 
accept it anyway and hope for the best.

Qt (et all) is a pretty organized upstream, so when asked about Python 3.8 support 
in 5.13.x, they said, "Nope. Wait for
5.14.x."



BTW this is scholar example of use-case for Modularity.


I disagree: This is a scholar misconception about Modularity.

Modularity doesn't have parallel installability, hence (as Smooge says in this 
thread) you have a big problem:


- you either end up in an impossible "choose the stack" situation
- or you need to rebuild every Python package in every Python stream
  - that has the maintenance issue
  - you have the same problem for PySide in the 3.8 stream as you had before
- or you can workaround Modularity design by packaging each Python stack as a 
different module with namespaced PRM packages (and components) -- hence you get 
all the usability problems and maintainability problems of Modularity with no 
added value


We could have parallel installable multiple Python version stacks w/out 
Modularity just fine. The "only little problem" is we hardly have the enough 
maintainers to maintain the 3k+ existing Python packages.


--
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

Fedora Data Centre Move - What This Means For You

[Aoife Moloney]

# Fedora Data Centre Move - What it means for you?

to: devel-annou...@lists.fedoraproject.org
subject: Fedora Data Centre Move - What it means for you?

Good Morning,

As you may have heard in the past few months, most of the Fedora Infrastructure 
which is currently hosted in a data-center in Phoenix Arizona (USA) will be 
moving to a new datacenter in Virgina (USA) in just a few weeks now.

While we are doing our best to ensure a continuity of service to the project, 
there will be some consequences of this move.

The main issues will be that for several weeks:
- *Fedora's build capacity will be significantly reduced*.
- A few applications, not directly related to building Fedora, running in the 
Fedora Infrastructure will be offline (see link below)

Practically, this means that your build will wait longer to find a builder 
available and as a result the whole build process will feel slower. The builds 
per say should not be impacted though.

As a result, if you know today that you have some important packaging work to 
do, we invite you to try to prioritize it now if possible. Otherwise, if you 
have the opportunity to plan this work for after the move is done, it would 
save some resources for builds that cannot/should not wait (CVEs and alike).

In addition, during the move there will be no staging environment. This will 
directly impact very few people, but from an infrastructure point of view it 
also means that we try to avoid as much as possible updating applications (for 
example deploying a new account system or new releases) during that time.

To give you some insight on dates*:
- The week of June 8th we will be moving services from one data-center to the 
other, so there will be ongoing outages as resources are moved from one data 
center to one with diminished capacity.
- We are hoping to continue rebuilding the infrastructure in Virgnia the week 
of June 22nd as shipped hardware arrives at the new facility.
- The target deadline to complete the entire move and return to normal capacity 
in Fedora Infrastructure is July 28th

A couple of final notes:
- right after the end of the move, there is a mass-rebuild scheduled, so you 
could use this as an opportunity to let releng do the builds for you if you 
prepare everything in dist-git.
- Please try to avoid pinging nirik or smooge in the coming weeks so they can 
focus on this delicate exercise, but if you run into them, I'm sure they will 
appreciate your support or/and some cookies on irc (nirik++ smooge++)!
- Please bare with us while we're working on the move as responses to 
tickets/requests will likely be slower than usual.

A list of the applications that will be impacted by the colo move is available 
at: 
https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA

Thanks in advance for your understanding and help,

Aoife



* All the dates are subject to changes, going from networking issues, to 
servers dying because of the move, to a world-wide pandemic changing the 
working conditions in the data-center, but these are current estimates.
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@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

Fedora Data Centre Move - What This Means For You

[Aoife Moloney]

# Fedora Data Centre Move - What it means for you?

to: devel-announce@lists.fedoraproject.org
subject: Fedora Data Centre Move - What it means for you?

Good Morning,

As you may have heard in the past few months, most of the Fedora Infrastructure 
which is currently hosted in a data-center in Phoenix Arizona (USA) will be 
moving to a new datacenter in Virgina (USA) in just a few weeks now.

While we are doing our best to ensure a continuity of service to the project, 
there will be some consequences of this move.

The main issues will be that for several weeks:
- *Fedora's build capacity will be significantly reduced*.
- A few applications, not directly related to building Fedora, running in the 
Fedora Infrastructure will be offline (see link below)

Practically, this means that your build will wait longer to find a builder 
available and as a result the whole build process will feel slower. The builds 
per say should not be impacted though.

As a result, if you know today that you have some important packaging work to 
do, we invite you to try to prioritize it now if possible. Otherwise, if you 
have the opportunity to plan this work for after the move is done, it would 
save some resources for builds that cannot/should not wait (CVEs and alike).

In addition, during the move there will be no staging environment. This will 
directly impact very few people, but from an infrastructure point of view it 
also means that we try to avoid as much as possible updating applications (for 
example deploying a new account system or new releases) during that time.

To give you some insight on dates*:
- The week of June 8th we will be moving services from one data-center to the 
other, so there will be ongoing outages as resources are moved from one data 
center to one with diminished capacity.
- We are hoping to continue rebuilding the infrastructure in Virgnia the week 
of June 22nd as shipped hardware arrives at the new facility.
- The target deadline to complete the entire move and return to normal capacity 
in Fedora Infrastructure is July 28th

A couple of final notes:
- right after the end of the move, there is a mass-rebuild scheduled, so you 
could use this as an opportunity to let releng do the builds for you if you 
prepare everything in dist-git.
- Please try to avoid pinging nirik or smooge in the coming weeks so they can 
focus on this delicate exercise, but if you run into them, I'm sure they will 
appreciate your support or/and some cookies on irc (nirik++ smooge++)!
- Please bare with us while we're working on the move as responses to 
tickets/requests will likely be slower than usual.

A list of the applications that will be impacted by the colo move is available 
at: 
https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA

Thanks in advance for your understanding and help,

Aoife



* All the dates are subject to changes, going from networking issues, to 
servers dying because of the move, to a world-wide pandemic changing the 
working conditions in the data-center, but these are current estimates.
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, 2020-05-20 at 21:38 +0200, Miroslav Suchý wrote:
> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python
> > 3.8. But instead of asking ourselves, "should we push
> > in the VERY latest Python and hope it's ok?", we just patch the
> > build system to accept it anyway and hope for the best. 
> > 
> > Qt (et all) is a pretty organized upstream, so when asked about
> > Python 3.8 support in 5.13.x, they said, "Nope. Wait for
> > 5.14.x." 
> > 
> 
> BTW this is scholar example of use-case for Modularity.

Not sure if this is bad or good :)

But anyway, with modularity in this case you would either have python
which is used for all applications or the one which is compatible with
PySide2 because of lack of parallel installability.

> -- 
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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
- -- 
Igor Raits 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7Fi38ACgkQEV1auJxc
Hh7A/A/8DJSuoUEpOqT6EB9nhHNPQ+d+HelBxQTyg0jaLDSt2tzC+MWV7NrUBwO4
0vl7YworVmO9y26FmDSA3QPHzUy/R0jSzXHPJ4+CN1IvpNYVT3vQRukfqYpBAsQr
zUJlfQeETzBebR+KoQVAhJ4XFEF3pFGDZeXcXIcNKStezcyPCfBVYrl0zizkUbJi
T5IopFau1DBgRySGMkUj+qiiB8V8KrOufl3HI9Qbo+g7DRw7+3f5qblpuBP4Eamt
cxjclW5brfUv/96PeX/V/cqkj0P6A+tGPksvSeoAKvEhhVwYMp4yrX8jErnl45aP
GO2fPcRgNa61Ss6uVQ4SUX+PA67GoN2fiZ12ZKWT/P7/QH6AAyFOWTQXL8LTT8sE
TAtPtNn4xAG1P/zvjq9oW8iKhYDk6fG7R9serVNVldNLluNKcF4Dl97T+nkFofD/
GbofiVmf9Lix/jb55n3qEPyK+o8hbY2sp1E0S+zx4DoeBEV9xihS7nR9gOaQ0uxE
jqBehmFGuWU/xJ4MlbJtfQiXJwssFbIBHrClJvnxpLYkDMUANcw83OBsRUMPPf6/
Yf4gzhraKR0ZHh/oFtOlczT/mmvKH70/0GO/QVEiFkv5FNBXrs1uZOONnyKJTj4G
G4n8MU7yXL3qtFGlhbrC1rBw/kUWUwpMqyMeM7g6S/subp5BHZI=
=8tUT
-END 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: Aggressive updating (Python 3.9): Are we trying to hard?

[Stephen John Smoogen]

On Wed, 20 May 2020 at 15:39, Miroslav Suchý  wrote:

> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8.
> But instead of asking ourselves, "should we push
> > in the VERY latest Python and hope it's ok?", we just patch the build
> system to accept it anyway and hope for the best.
> >
> > Qt (et all) is a pretty organized upstream, so when asked about Python
> 3.8 support in 5.13.x, they said, "Nope. Wait for
> > 5.14.x."
> >
>
> BTW this is scholar example of use-case for Modularity.
>
>
Maybe if each python module is made parallel installable AND each app which
uses python is tied to using that exact version of python versus python3.
Otherwise you could end up with QT apps needing python3.6, XYZ (let us say
TeX) apps needing python3.8 and dnf needing python3.9 and ONLY ONE OF THESE
CAN BE INSTALLED. And since dnf needs to be there.. I guess you would have
no QT or whatever.

If each of them have been patched to be parallel installable and the apps
have been patched to call python3.8 versus python3.. the only thing
modularity is helping is with giving a list of builds orders to make ti
work correctly. It also adds to each of those groups the maintenance of
those python modules because the python team has just enough people to
maintain 1 module. Not 2, not 3, not one for every old version of python3.






> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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
>


-- 
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: Non-responsive maintainer: glances

[Richard Shaw]

On Tue, May 19, 2020 at 2:53 PM Carl George  wrote:

> Howdy y'all,
>
> The glances package prints out a warning that the user should upgrade
> it via pip.  This is wrong for obvious reasons.  This issue was first
> reported in bugzilla on 2019-11-18 [0].  I opened a pull request to
> fix it 2019-12-22 [1].  The maintainer has not responded to the
> bugzilla or the pull request.  I filed the required non-responsive
> maintainer check bug on 2020-05-11 [2].  Does anyone know of another
> way to contact Edouard (madko)?
>

Nothing I can do to help you here, but wanted to +1 for the update.

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: Aggressive updating (Python 3.9): Are we trying to hard?

[Richard Shaw]

On Wed, May 20, 2020 at 2:39 PM Miroslav Suchý  wrote:

> Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> > Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8.
> But instead of asking ourselves, "should we push
> > in the VERY latest Python and hope it's ok?", we just patch the build
> system to accept it anyway and hope for the best.
> >
> > Qt (et all) is a pretty organized upstream, so when asked about Python
> 3.8 support in 5.13.x, they said, "Nope. Wait for
> > 5.14.x."
> >
>
> BTW this is scholar example of use-case for Modularity.
>

Perhaps, but they are still too cumbersome for the average packager. So I
would have to create a module for Python 3.7, python-pyside2, and freecad,
correct?

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: Aggressive updating (Python 3.9): Are we trying to hard?

[Miroslav Suchý]

Dne 19. 05. 20 v 14:03 Richard Shaw napsal(a):
> Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But 
> instead of asking ourselves, "should we push
> in the VERY latest Python and hope it's ok?", we just patch the build system 
> to accept it anyway and hope for the best. 
> 
> Qt (et all) is a pretty organized upstream, so when asked about Python 3.8 
> support in 5.13.x, they said, "Nope. Wait for
> 5.14.x." 
> 

BTW this is scholar example of use-case for Modularity.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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: TeXLive 2020 landing in rawhide

[Tom Callaway]

I think the issue here is that the most recent texlive package fixes landed
this morning, and the "rawhide" compose that mock would pull in doesn't
have all the fixes yet.

Tom

On Wed, May 20, 2020 at 3:12 PM Richard Shaw  wrote:

> On Wed, May 20, 2020 at 2:08 PM Tom Callaway  wrote:
>
>> I'm not sure what your failure looked like (maybe the rawhide packages
>> used are older than the ones currently in the koji buildroot), but a koji
>> scratch build from master succeeded without issue:
>>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=44738672
>>
>
> Interesting, I know sometimes mock produces different results from Koji
> but I wouldn't expect it in this case. I did both with and without
> --enablerepo=local and tried again after a --scrub=all, with the same
> result.
>
> 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
>
___
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: TeXLive 2020 landing in rawhide

[Richard Shaw]

On Wed, May 20, 2020 at 2:08 PM Tom Callaway  wrote:

> I'm not sure what your failure looked like (maybe the rawhide packages
> used are older than the ones currently in the koji buildroot), but a koji
> scratch build from master succeeded without issue:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=44738672
>

Interesting, I know sometimes mock produces different results from Koji but
I wouldn't expect it in this case. I did both with and without
--enablerepo=local and tried again after a --scrub=all, with the same
result.

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: TeXLive 2020 landing in rawhide

[Tom Callaway]

I'm not sure what your failure looked like (maybe the rawhide packages used
are older than the ones currently in the koji buildroot), but a koji
scratch build from master succeeded without issue:

https://koji.fedoraproject.org/koji/taskinfo?taskID=44738672

Tom

On Wed, May 20, 2020 at 2:21 PM Tom Callaway  wrote:

> It's probably not the same bug, that error is a fairly generic error
> meaning "something has made texlive unhappy". I'm investigating.
>
> Tom
>
> On Wed, May 20, 2020 at 1:29 PM Richard Shaw  wrote:
>
>> Thanks for the PR but it looks like I'm being bitten by:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=578426
>>
>> In the mock build, so how do I generate pdflatex.fmt within a mock chroot?
>>
>> 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
>>
>
___
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: TeXLive 2020 landing in rawhide

[Tom Callaway]

It's probably not the same bug, that error is a fairly generic error
meaning "something has made texlive unhappy". I'm investigating.

Tom

On Wed, May 20, 2020 at 1:29 PM Richard Shaw  wrote:

> Thanks for the PR but it looks like I'm being bitten by:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=578426
>
> In the mock build, so how do I generate pdflatex.fmt within a mock chroot?
>
> 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
>
___
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 vala - asking for new owner

[Michel Alexandre Salim]

Package gifted to feborges.

Thanks Felipe!

--
Michel

On 5/18/20 1:33 AM, Felipe Borges wrote:

Hi,

I maintain GNOME Boxes (which is part of the default workstation
installation) and GNOME Connections. Both written in Vala. Therefore
the maintenance of Vala in Fedora is important to me.

I can take ownership of it, and I will be happy to collaborate with
others that might be also interested.

Regards,
Felipe Borges.

On Sat, May 16, 2020 at 9:53 PM Michel Alexandre Salim
 wrote:


Hi all,

I'm still the primary maintainer for Vala, but de facto have not been
doing much with it -- it mostly gets auto-upgraded together with the
rest of the GNOME stack.

As such I'm not really the best person to have issues assigned to, and
if anyone else wants to take over the reign, I'll transfer ownership
directly rather than causing a mad scramble by directly orphaning.

Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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



--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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

fwupd / LVFS RFE: classifying updates?

[Michel Alexandre Salim]

Hi all,

We manage a fleet of Fedora end-user devices at work (laptops and 
desktops), and currently don't automate firmware update deployment yet 
(given the potential issue if, say, the user suspends their laptop halfway).


Sometimes there are updates that are critical (e.g. a security issue, or 
potential hardware failure on older firmwares) that we do want to 
force-push this, though.


For normal packages, we just set up dnf-automatic to automatically apply 
security updates. Would it be possible to flag critical/security 
firmware updates so that we can just create a process that automatically 
apply these, say on a daily basis, without us having to chase every 
single firmware GUIDs?


Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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: TeXLive 2020 landing in rawhide

[Richard Shaw]

Thanks for the PR but it looks like I'm being bitten by:

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

In the mock build, so how do I generate pdflatex.fmt within a mock chroot?

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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB – fedora-review

[Bruno Wolff III]

On Wed, May 20, 2020 at 11:31:37 -0400,
 Neal Gompa  wrote:

On Wed, May 20, 2020 at 11:06 AM Zbigniew Jędrzejewski-Szmek
 wrote:


I'm seeing this when running fedora-review:

$ fedora-review -b 1838033
INFO: Processing bugzilla bug: 1838033
...
INFO: Installing built package(s)
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.


I got this on a machine I can't reboot right now and I ran rpm --rebuilddb 
which appears to have switched the database over. At least I stopped 
getting the messages when running dnf.

___
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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB – fedora-review

[Igor Raits]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I think you might have cache of buildroot which was populated using BDB
backend, so I guess if you clean mock caches, the problem should go
away.

On Wed, 2020-05-20 at 15:04 +, Zbigniew Jędrzejewski-Szmek wrote:
> I'm seeing this when running fedora-review:
> 
> $ fedora-review -b 1838033
> INFO: Processing bugzilla bug: 1838033
> ...
> INFO: Installing built package(s)
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> INFO: Active plugins: Generic, Shell-api, Java
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:10 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:42 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:46 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:50 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:53 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:00:57 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:01:01 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:01:05 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> Last metadata expiration check: 0:01:09 ago on Wed May 20 15:08:57
> 2020.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend:
> using bdb backend.
> warning: Found 

[Bug 1838194] New: perl-Test-Smoke-1.78 is available

[bugzilla]

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

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



Latest upstream release: 1.78
Current version/release in rawhide: 1.77-1.fc33
URL: http://search.cpan.org/dist/Test-Smoke/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/3418/


-- 
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 1838154] perl-PPIx-Regexp-0.072 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PPIx-Regexp-0.072-1.fc
   ||33
 Resolution|--- |RAWHIDE
Last Closed||2020-05-20 15:52:56



--- Comment #1 from Petr Pisar  ---
An enhancement release that refactors a code. Safer for Rawhide only.


-- 
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: Lots of systemctl segfaults in Koji Rawhide

[Adam Williamson]

On Wed, 2020-05-20 at 09:03 +0200, Petr Pisar wrote:
> On Tue, May 19, 2020 at 08:24:34PM -0700, Adam Williamson wrote:
> > On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > > The most suspicious change between the two build envs that I can see is
> > > openssl. GOOD has openssl-1.1.1g-1.fc33.x86_64 , and BAD has
> > > openssl-1.1.1g-2.fc33.x86_64 . I'm gonna try doing an openssl build
> > > with the patch from -2 reverted and see where that gets us.
> > 
> > OK, I think that did the trick. nbdkit's x86_64 build succeeded this
> > time, and the log shows no systemctl crashes:
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/7666/44717666/root.log
> > 
> > I'll file a bug on openssl to let tmraz know about the problem.
> > Hopefully between the two fixes, the next Rawhide may also be fixed...
> 
> Nice detective work. You could have save your work with Koschei.
> 
>  nbdkit history,
>  first failure with this test
> failure on x86_64:
> 
> supermin: exception: 
> Sys_error("/lib/modules/5.7.0-0.rc5.20200515git1ae7efb38854.1.fc33.x86_64/modules.dep:
>  No such file or directory")
> 
> with only 5 source packages changed and openssl going from 1:1.1.1g-1.fc33 to
> 1:1.1.1g-2.fc33 being one of them.

Good point! Somehow Koschei just didn't come to mind as something that
would be helpful here, but it would indeed have saved me a bit of time.
I did look for packages with frequent 'official' builds to try and find
one which would show a narrow window where the bug appeared, but of
course Koschei would've been the ideal place to look :)
-- 
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

[Bug 1838154] perl-PPIx-Regexp-0.072 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   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

Re: TeXLive 2020 landing in rawhide

[Tom Callaway]

Richard,

I've got a PR for you that adds your explicit tex BuildRequires so that
this works again:
https://src.fedoraproject.org/rpms/OpenColorIO/pull-request/1

Upstream TeXLive sometimes moves .sty files around, so in most cases, it is
easier to specify BuildRequires using the "tex(requirement.sty)" Provides.
If your package has a .tex file, look for the \usepackage{foo} lines, those
are your tex dependencies. And in some cases, those dependencies may be met
by local .sty files, so if you can't find a package in Fedora texlive that
Provides: tex(foo.sty), look for foo.sty in your package source. (It also
could be legitimately missing in Fedora, I'm clearly not perfect!)

Thanks,
Tom

On Wed, May 20, 2020 at 8:41 AM Richard Shaw  wrote:

> On Wed, May 20, 2020 at 7:39 AM Richard Shaw  wrote:
>
>> Not sure if this problem is related, but the last time I build
>> OpenImageIO it worked, I was performing a local mock build (with the local
>> repo enabled) and ran into this:
>>
>
> Correction, OpenColorIO. My fingers always want to type OpenImageIO :)
>
> 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
>
___
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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB – fedora-review

[Neal Gompa]

On Wed, May 20, 2020 at 11:06 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> I'm seeing this when running fedora-review:
>
> $ fedora-review -b 1838033
> INFO: Processing bugzilla bug: 1838033
> ...
> INFO: Installing built package(s)
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> INFO: Active plugins: Generic, Shell-api, Java
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:10 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:42 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:46 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:50 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:53 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:00:57 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:01:01 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:01:05 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> Last metadata expiration check: 0:01:09 ago on Wed May 20 15:08:57 2020.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> warning: Found bdb Packages database while attempting sqlite backend: using 
> bdb backend.
> 

Re: web-assets

[Zbigniew Jędrzejewski-Szmek]

On Wed, May 20, 2020 at 12:22:06PM +0200, Petr Pisar wrote:
> I took web-assets to prevent from braking many packages. If there is somebody
> interested in web applications (not my case), I can give the package to him.

Or her!

Zbyszek
___
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: Fedora 33 System-Wide Change proposal: Sqlite RpmDB – fedora-review

[Zbigniew Jędrzejewski-Szmek]

I'm seeing this when running fedora-review:

$ fedora-review -b 1838033
INFO: Processing bugzilla bug: 1838033
...
INFO: Installing built package(s)
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
INFO: Active plugins: Generic, Shell-api, Java
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:10 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:42 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:46 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:50 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:53 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:00:57 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:01:01 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:01:05 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:01:09 ago on Wed May 20 15:08:57 2020.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
warning: Found bdb Packages database while attempting sqlite backend: using bdb 
backend.
Last metadata expiration check: 0:01:44 ago on Wed May 20 15:08:57 2020.
warning: Found bdb 

[Bug 1838041] perl-Test-TrailingSpace-0.0400 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-TrailingSpace-0.0
   ||400-1.fc33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-05-20 14:51:32



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


-- 
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 1838154] New: perl-PPIx-Regexp-0.072 is available

[bugzilla]

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

Bug ID: 1838154
   Summary: perl-PPIx-Regexp-0.072 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PPIx-Regexp
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.072
Current version/release in rawhide: 0.071-1.fc33
URL: http://search.cpan.org/dist/PPIx-Regexp/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/3288/


-- 
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: An Apology

[Matthew Miller]

On Wed, May 20, 2020 at 05:22:42AM -0500, Ty Young wrote:
> I think I owe some in the Fedora project an apology.

Hi Ty. Thank you for this. When we're passionate about something, it's easy
to get frustrated and upset, and easy for that to get out of hand. It's much
harder to step back and consider, and I appreciate you doing so!

Thanks for your passion, and let's continue to figure out how to solve these
often frustrating challenges together.

-- 
Matthew Miller

Fedora Project Leader
___
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: Modularity survey - results

[John M. Harris Jr]

On Tuesday, May 19, 2020 7:56:35 AM MST Miro Hrončok wrote:
> On 19. 05. 20 16:46, Christopher wrote:
> 
> > Interesting that the survey shows that the most common response was that
> > people  use it "not at all" and the overall response was negative, but
> > the reaction to that is, "improve the docs" and "works as intended". Am I
> > the only one who thinks that the people pushing modularity aren't
> > listening to the larger community?
> FWIW I understand the action point for this survey as a way to improve the 
> situation for environments where we are "stuck with modularity" (such as
> RHEL and EPEL 8) rather than a call for action that says "if we fix this,
> we'll proceed with Fedora modularization".
> 
> -- 
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok

Based on the conclusions section, where it talks only of Fedora releases as 
goal dates, I can't see that as being the case.


-- 
John M. Harris, Jr.


___
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: bodhi: stuck updates

[Gordon Messmer]

On 4/28/20 11:31 AM, Clement Verna wrote:
On Tue, 28 Apr 2020 at 18:41, Alexander Ploumistos 
mailto:alex.ploumis...@gmail.com>> wrote:


Almost a week ago, I built cmpfit and fityk in side tags on F31, F32
and F33. While the builds for F33 moved directly to stable - as
expected - the other two got stuck for 4 days.


It looks like Bodhi thinks that the builds were not signed so the 
update is not going to be pushed. It looks that there is a bug there 
since the builds are correctly tagged in koji.


I will manually fix these update and file a bug upstream so we can 
look a fixing this.



Is this an ongoing issue?  If so, is there a ticket somewhere tracking 
status?

___
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: Need help with side-tag

[Miro Hrončok]

On 20. 05. 20 15:35, Christine Caulfield wrote:

Hi,

I thought I was doing the right thing - because of the libqb soname bump
I built it on a side-tag and got the maintainers of dependent packages
to rebuild their packages on that side-tag.

Now all the builds are in I go to Bodhi to make the update - but it
tells me I can't do it because I don't have commit access to the other
projects.

errr, what do I do now please?


You ask a provenpackager to do it. I can help. Can you please provide the update 
details? Summary, type, karma limits, bugzillas it should fix...



The tag is f33-build-side-23348 if that helps.


That will help yes.

--
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

Need help with side-tag

[Christine Caulfield]

Hi,

I thought I was doing the right thing - because of the libqb soname bump
I built it on a side-tag and got the maintainers of dependent packages
to rebuild their packages on that side-tag.

Now all the builds are in I go to Bodhi to make the update - but it
tells me I can't do it because I don't have commit access to the other
projects.

errr, what do I do now please?

The tag is f33-build-side-23348 if that helps.

Thanks,
Chrissie
___
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 maintainers (a.k.a. JavaScript is the new Java)

[Gwyn Ciesla via devel]

‐‐‐ Original Message ‐‐‐
On Wednesday, May 20, 2020 3:49 AM, Miro Hrončok  wrote:

> pangox-compat orphan, rathann 2 weeks ago

I've removed a dependency on this from a package I maintain; there are many 
others that rely on this somewhere, and it's really old. Is anyone working on 
moving away from it and/or planning to take this?

signature.asc
Description: OpenPGP digital 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: Requires: libgtest.so, libgmock.so, libgmock_main.so question

[Neal Gompa]

On Wed, May 20, 2020 at 9:08 AM Kaleb Keithley  wrote:
>
>
>
> On Wed, May 20, 2020 at 8:52 AM Neal Gompa  wrote:
>>
>> On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley  wrote:
>> >
>> > In rawhide the ceph ceph-test subpackage is deriving a Requires: for 
>> > $subject, and even with gmock and gtest installed the requires is not 
>> > satisfied.
>> >
>> > And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug 
>> > in the gtest and gmock rpms?)
>> >
>> > (They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and 
>> > libgmock_main.so.1.10.0 though.)
>> >
>> > Is there some magic that if I were to add BuildRequires: gtest gmock the 
>> > magic that derives the Requires might come up with 
>> > libg{test,mock,mock_main}.so.1.10.0 instead?
>> >
>> > Otherwise I'm tempted to just disable the build of ceph-test for Fedora 
>> > RPM builds.
>> >
>> > I'm stumped.
>> >
>>
>> The gtest-devel and gmock-devel packages provide the unversioned
>> sonames.
>
>
> It doesn't look that way to me, e.g.
>
> $ rpm -q --provides gtest-devel
> cmake(GTest) = 1.10.0
> cmake(gtest) = 1.10.0
> gtest-devel = 1.10.0-1.fc33
> gtest-devel(x86-64) = 1.10.0-1.fc33
> pkgconfig(gtest) = 1.10.0
> pkgconfig(gtest_main) = 1.10.0
>
> $ rpm -q --provides gmock-devel
> gmock-devel = 1.10.0-1.fc33
> gmock-devel(x86-64) = 1.10.0-1.fc33
> pkgconfig(gmock) = 1.10.0
> pkgconfig(gmock_main) = 1.10.0
>

They are only symlinks to the real files (just like how any other
library package works). So you won't see unversioned Provides there.
You'll see Requires for the libraries in those packages, though.



-- 
真実はいつも一つ！/ 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: Requires: libgtest.so, libgmock.so, libgmock_main.so question

[Fabio Valentini]

On Wed, May 20, 2020 at 2:51 PM Neal Gompa  wrote:
>
> On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley  wrote:
> >
> > In rawhide the ceph ceph-test subpackage is deriving a Requires: for 
> > $subject, and even with gmock and gtest installed the requires is not 
> > satisfied.
> >
> > And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug 
> > in the gtest and gmock rpms?)
> >
> > (They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and 
> > libgmock_main.so.1.10.0 though.)
> >
> > Is there some magic that if I were to add BuildRequires: gtest gmock the 
> > magic that derives the Requires might come up with 
> > libg{test,mock,mock_main}.so.1.10.0 instead?
> >
> > Otherwise I'm tempted to just disable the build of ceph-test for Fedora RPM 
> > builds.
> >
> > I'm stumped.
> >
>
> The gtest-devel and gmock-devel packages provide the unversioned
> sonames. BR those and things should work properly. Is it properly
> linking to the libraries or doing something funky? With the Mir and
> wlcs test suites, it seems to do the right thing...

I assume that's not going to work. Those dependencies aren't satisfied
by anything in the fedora repos. fedora-health-check shows the
following unsatisfiable dependencies for ceph-test:

ceph-test ceph 2:15.2.1-1.fc33 aarch64 rawhide :
aarch64 kkeithle libgmock.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 aarch64 rawhide :
aarch64 kkeithle libgmock_main.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 aarch64 rawhide :
aarch64 kkeithle libgtest.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 ppc64le rawhide :
ppc64le kkeithle libgmock.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 ppc64le rawhide :
ppc64le kkeithle libgmock_main.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 ppc64le rawhide :
ppc64le kkeithle libgtest.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 s390x rawhide : s390x
  kkeithle libgmock.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 s390x rawhide : s390x
  kkeithle libgmock_main.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 s390x rawhide : s390x
  kkeithle libgtest.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 x86_64 rawhide : x86_64
kkeithle libgmock.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 x86_64 rawhide : x86_64
kkeithle libgmock_main.so()(64bit)
ceph-test ceph 2:15.2.1-1.fc33 x86_64 rawhide : x86_64
kkeithle libgtest.so()(64bit)

See: 
https://pagure.io/fedora-health-check/blob/master/f/reports/report-rawhide.md

Fabio

> --
> 真実はいつも一つ！/ 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
___
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: Requires: libgtest.so, libgmock.so, libgmock_main.so question

[Kaleb Keithley]

On Wed, May 20, 2020 at 8:52 AM Neal Gompa  wrote:

> On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley 
> wrote:
> >
> > In rawhide the ceph ceph-test subpackage is deriving a Requires: for
> $subject, and even with gmock and gtest installed the requires is not
> satisfied.
> >
> > And the gtest and gmock rpms (somehow) do not provide them. (Is this a
> bug in the gtest and gmock rpms?)
> >
> > (They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and
> libgmock_main.so.1.10.0 though.)
> >
> > Is there some magic that if I were to add BuildRequires: gtest gmock the
> magic that derives the Requires might come up with
> libg{test,mock,mock_main}.so.1.10.0 instead?
> >
> > Otherwise I'm tempted to just disable the build of ceph-test for Fedora
> RPM builds.
> >
> > I'm stumped.
> >
>
> The gtest-devel and gmock-devel packages provide the unversioned
> sonames.
>

It doesn't look that way to me, e.g.

$ rpm -q --provides gtest-devel
cmake(GTest) = 1.10.0
cmake(gtest) = 1.10.0
gtest-devel = 1.10.0-1.fc33
gtest-devel(x86-64) = 1.10.0-1.fc33
pkgconfig(gtest) = 1.10.0
pkgconfig(gtest_main) = 1.10.0

$ rpm -q --provides gmock-devel
gmock-devel = 1.10.0-1.fc33
gmock-devel(x86-64) = 1.10.0-1.fc33
pkgconfig(gmock) = 1.10.0
pkgconfig(gmock_main) = 1.10.0

--

Kaleb
___
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 maintainers (a.k.a. JavaScript is the new Java)

[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-05-20.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CutyCapt  orphan   1 weeks ago
apache-commons-vfsmizdebsk, orphan 0 weeks ago
bmake orphan   3 weeks ago
cinnamon-applet-globalappmenu orphan   3 weeks ago
cinnamon-themes   jcpunk, orphan   3 weeks ago
dateformatorphan   1 weeks ago
drawtkorphan   0 weeks ago
driftnet  orphan, pwouters 4 weeks ago
felix-framework   mizdebsk, msimacek, orphan   1 weeks ago
felix-osgi-obr-resolver   orphan   1 weeks ago
gmpc  orphan   3 weeks ago
gnome-themes  alexl, caillon, caolanm, 0 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
istatdorphan   4 weeks ago
jasmine   nodejs-sig, orphan, patches  0 weeks ago
jasmine-node  nodejs-sig, orphan, patches  1 weeks ago
js-json   nodejs-sig, orphan   1 weeks ago
js-php-date-formatter orphan   4 weeks ago
js-zlib   nodejs-sig, orphan, patches, 1 weeks ago
  zbyszek
kitsune   orphan   0 weeks ago
markednodejs-sig, orphan, patches  1 weeks ago
maven-release jcapik, orphan   2 weeks ago
mocha nodejs-sig, orphan, patches  1 weeks ago
nodejs-abbrev nodejs-sig, orphan, patches  1 weeks ago
nodejs-ain2   nodejs-sig, orphan, patches  1 weeks ago
nodejs-ansi   nodejs-sig, orphan, patches  1 weeks ago
nodejs-ansi-stylesnodejs-sig, orphan, patches  1 weeks ago
nodejs-archy  nodejs-sig, orphan, patches  1 weeks ago
nodejs-asap   nodejs-sig, orphan, patches  1 weeks ago
nodejs-asn1   nodejs-sig, orphan, patches  1 weeks ago
nodejs-assert-plusnodejs-sig, orphan, patches  1 weeks ago
nodejs-async  nodejs-sig, orphan, patches  1 weeks ago
nodejs-aws-sign   nodejs-sig, orphan, patches  1 weeks ago
nodejs-basic-auth-connect nodejs-sig, orphan, patches  1 weeks ago
nodejs-batch  nodejs-sig, orphan, patches  1 weeks ago
nodejs-better-assert  nodejs-sig, orphan, patches  1 weeks ago
nodejs-bindings   nodejs-sig, orphan, patches  1 weeks ago
nodejs-block-stream   nodejs-sig, orphan, patches  1 weeks ago
nodejs-boom   nodejs-sig, orphan, patches  1 weeks ago
nodejs-buffer-crc32   nodejs-sig, orphan, patches  1 weeks ago
nodejs-buffer-equal   nodejs-sig, orphan, patches  1 weeks ago
nodejs-bunker nodejs-sig, orphan, patches  1 weeks ago
nodejs-burritonodejs-sig, orphan, patches  1 weeks ago
nodejs-bytes  nodejs-sig, orphan, patches  1 weeks ago
nodejs-callsite   nodejs-sig, orphan, patches  1 weeks ago
nodejs-chalk  nodejs-sig, orphan, patches  1 weeks ago
nodejs-character-parser   nodejs-sig, orphan, patches  1 weeks ago
nodejs-charm  nodejs-sig, orphan, patches  1 weeks ago
nodejs-child-process-closenodejs-sig, orphan, patches  1 weeks ago
nodejs-chmodr 

Re: Requires: libgtest.so, libgmock.so, libgmock_main.so question

[Neal Gompa]

On Wed, May 20, 2020 at 8:39 AM Kaleb Keithley  wrote:
>
> In rawhide the ceph ceph-test subpackage is deriving a Requires: for 
> $subject, and even with gmock and gtest installed the requires is not 
> satisfied.
>
> And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug in 
> the gtest and gmock rpms?)
>
> (They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and 
> libgmock_main.so.1.10.0 though.)
>
> Is there some magic that if I were to add BuildRequires: gtest gmock the 
> magic that derives the Requires might come up with 
> libg{test,mock,mock_main}.so.1.10.0 instead?
>
> Otherwise I'm tempted to just disable the build of ceph-test for Fedora RPM 
> builds.
>
> I'm stumped.
>

The gtest-devel and gmock-devel packages provide the unversioned
sonames. BR those and things should work properly. Is it properly
linking to the libraries or doing something funky? With the Mir and
wlcs test suites, it seems to do the right thing...



-- 
真実はいつも一つ！/ 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: TeXLive 2020 landing in rawhide

[Richard Shaw]

On Wed, May 20, 2020 at 7:39 AM Richard Shaw  wrote:

> Not sure if this problem is related, but the last time I build OpenImageIO
> it worked, I was performing a local mock build (with the local repo
> enabled) and ran into this:
>

Correction, OpenColorIO. My fingers always want to type OpenImageIO :)

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

Requires: libgtest.so, libgmock.so, libgmock_main.so question

[Kaleb Keithley]

In rawhide the ceph ceph-test subpackage is deriving a Requires: for
$subject, and even with gmock and gtest installed the requires is not
satisfied.

And the gtest and gmock rpms (somehow) do not provide them. (Is this a bug
in the gtest and gmock rpms?)

(They do provide libgtest.so.1.10.0 libgmock.so.1.10.0 and
libgmock_main.so.1.10.0 though.)

Is there some magic that if I were to add BuildRequires: gtest gmock the
magic that derives the Requires might come up with
libg{test,mock,mock_main}.so.1.10.0 instead?

Otherwise I'm tempted to just disable the build of ceph-test for Fedora RPM
builds.

I'm stumped.

--

Kaleb
___
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: TeXLive 2020 landing in rawhide

[Richard Shaw]

Not sure if this problem is related, but the last time I build OpenImageIO
it worked, I was performing a local mock build (with the local repo
enabled) and ran into this:

cd /builddir/build/BUILD/OpenColorIO-1.1.1/build/docs/build-latex &&
/usr/bin/pdflatex OpenColorIO.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) (preloaded
format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./OpenColorIO.tex
LaTeX2e <2018-12-01>
(./sphinxmanual.cls
Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty)
(/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/t1enc.def)<>)

! LaTeX Error: File `babel.sty' not found.

Type X to quit or  to proceed,
or enter new name. (Default extension: sty)

Enter file name:
! Emergency stop.


l.9 \usepackage
   {times}^^M
!  ==> Fatal error occurred, no output PDF file produced!

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: Problems with packages compiled with gcc 10.0

[Fabio Valentini]

On Tue, May 19, 2020 at 8:08 PM Richard W.M. Jones  wrote:
>
> On Tue, May 19, 2020 at 11:40:50AM +0200, Fabio Valentini wrote:
> > On Tue, May 19, 2020 at 11:28 AM Vitaly Zaitsev via devel
> >  wrote:
> > > Next time FESCo should forbid gcc updates to unreleased versions in
> > > branched Fedora releases.
> > >
> > > Now we need a new mass rebuild in Fedora 32 with fixed gcc 10.1.1 version.
> >
> > As I wrote in my direct response to Guido, doing a mass rebuild for
> > fedora just isn't possible in released branches. So, the best we can
> > do is to deal with issues as people become aware of them and report
> > them, and then rebuild those few broken packages with the "fixed" GCC
> > version, instead of "just rebuild everything because".
> >
> > We also briefly talked about not including pre-release GCC versions in
> > rawhide, but since new GCC versions get almost all their testing only
> > in rawhide, this would inevitably only lead to lower-quality final GCC
> > releases that would then end up in released fedora versions anyway. We
> > (FESCo) were not able to think of a better way to do this.
>
> Well that's one way to look at it.  Another is that I spent half a day
> chasing a bug for one of our users in Fedora 32, and it turned out to
> be caused by GCC.  I *would* have spotted this in Rawhide if it had
> been there for any length of time first.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1835649
>
> You just cannot allow random preproduction GCC into released Fedora.

Well, that's not exactly what happened.
The branch for what would eventually become fedora 32 just inherited a
pre-release GCC version, because that's what was on the master branch
/ in rawhide at the time.

I think we just jad a bit of "bad luck" this time round - the exact
build that was used a period of time (including the mass rebuild, I
think) seems to have produced buggy code in some circumstances. If
those issues had been compile time errors instead of runtime errors,
they would've been caught pretty quickly, but alas ...

Fabio

> 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
___
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 1838041] perl-Test-TrailingSpace-0.0400 is available

[bugzilla]

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



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


-- 
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 1838041] New: perl-Test-TrailingSpace-0.0400 is available

[bugzilla]

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

Bug ID: 1838041
   Summary: perl-Test-TrailingSpace-0.0400 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-TrailingSpace
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: i...@cicku.me, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.0400
Current version/release in rawhide: 0.0302-3.fc33
URL: http://search.cpan.org/dist/Test-TrailingSpace/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/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/3420/


-- 
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 1838041] perl-Test-TrailingSpace-0.0400 is available

[bugzilla]

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



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


-- 
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: Strange rpm trigger behavior in koji rawhide

[Panu Matilainen]

On 5/19/20 6:01 AM, Orion Poplawski wrote:
   We're trying to track down a problem that only appears in koji and 
copr, but I can't reproduce locally in mock on my rawhide VM.  It's 
related to file triggers and we're trying to debug with something this:


%transfiletriggerin -n texlive-kpathsea -- /usr/share/texlive
# %{_bindir}/texhash 2> /dev/null || :
# DEBUG, lets see what it does
/usr/bin/sh -x %{_bindir}/texhash || :
export TEXMF=/usr/share/texlive/texmf-dist
export TEXMFCNF=/usr/share/texlive/texmf-dist/web2c
export TEXMFCACHE=/var/lib/texmf
# %{_bindir}/mtxrun --generate &> /dev/null || :
# %{_bindir}/fmtutil-sys --all &> /dev/null || :
# DEBUG, lets see what it does
%{_bindir}/mtxrun --generate || :
%{_bindir}/fmtutil-sys --all || :

hoping to see the output in the mock root.log, but I get nothing.

One basic question - if texlive-kpathsea is part of the transaction, 
does the above trigger still fire at the end of the transaction?


IIRC yes.


I see that mock locally and in copr has output like:

   Running scriptlet: texlive-base-7:20200327-4.fc33~bootstrap.1.x86_6 
357/357


But I don't see any "Running triggers" or similar.  Are we correct to 
expect output from triggers?


Dnf output regarding scriptlets is not really useful beyond "its doing 
something" indication, at least here it seems to be merging multiple 
triggers into one line of output accounted for the installing/removing 
package rather than the trigger owner etc. If you can reproduce this 
directly with dnf, using '--rpmverbosity debug' should shed more light 
on what's going on, including actual scriptlet names and their owner 
packages.


This is causing build failures after the recent texlive update.  Any 
help would be greatly appreciated.




It's entirely possible there its just another file trigger bug, it 
wouldn't be the first one uncovered by texlive. Please file a bug on rpm 
with reproducer info and lets work from there.


- Panu -
___
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-IoT-32-20200520.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 8/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Mount /run contents changed to 67.97498045% of previous size
Previous test data: https://openqa.fedoraproject.org/tests/596113#downloads
Current test data: https://openqa.fedoraproject.org/tests/601108#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.06 to 0.25
Previous test data: https://openqa.fedoraproject.org/tests/596114#downloads
Current test data: https://openqa.fedoraproject.org/tests/601109#downloads
-- 
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

Fedora-Cloud-32-20200520.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 601107  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/601107
-- 
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

Fedora-Cloud-31-20200520.0 compose check report

[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: Orphaned packages looking for maintainers (a.k.a. JavaScript is the new Java)

[Neal Gompa]

On Wed, May 20, 2020 at 5:43 AM Fabio Valentini  wrote:
>
> On Wed, May 20, 2020 at 10:50 AM Miro Hrončok  wrote:
> >
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know for sure
> > that the package should be retired, please do so now with a proper reason:
> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> (big snip)
>
> So ... does this mean we can finally admit that antora (the tool that
> generates docs.fedoraproject.org) will never even be packaged for
> fedora?



I wish we wouldn't pick tools that we can't ship to our own users. In
my opinion, doing so violates the principle of Fedora being able to produce
itself...




--
真実はいつも一つ！/ 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: Fedora 31->32 dnf system-update experience

[Miro Hrončok]

On 11. 05. 20 1:56, Miro Hrončok wrote:

On 08. 05. 20 16:24, Richard Shaw wrote:
There were a bunch of python2 packages that needed to be removed which 
necessitated --allowerasing which I've never had to do before.


Do you still have that list? Maybe in `dnf history`? If so, we can make the 
experience nicer, but I cannot help without the list. The idea was that all 
problematic packages are obsoleted, but this data is extremely hard to collect 
without users reporting in with the actual lists.


I got that list and extracted the following from it:

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

--
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

An Apology

[Ty Young]

Hi,


I think I owe some in the Fedora project an apology.


I feel like some good people where caught in the crossfire who were 
never intended to be with my words. I do not believe it to be true nor 
was it intended to be taken as "all Linux distros and their software 
maintainers are evil". I understand that, if nothing else, Fedora and 
others takes the route it does in order to be safe rather than sorry. 
That doesn't mean I agree with it, but it should never be confused with 
malicious intentions either, which I may very well have given off I was 
accusing innocent people of. There are no doubt many in the Fedora 
project that try to make right for everyone whenever and however 
possible, sometimes going above and beyond to do so. Those people 
deserve praise and compliments, not criticism or negativity thrown in 
their direction.



I'm very sorry to all those people.


I should take the time to say that, despite what some may think, I don't 
hate Fedora. I guess for those that don't know how nerdy I am for Fedora 
Silverblue, it would be easy to get the idea that I somehow hate 
everything Fedora does. This isn't remotely the case. I've been poking 
Fedora Silverblue every beta release trying to see if it's ready to take 
Arch Linux's spot when it goes south, and while it and the number of 
Flatpaks have improved and are still improving, they and Fedora aren't 
ready for me personally. If I was to recommend someone else who had less 
strict requirements(nvidia/rolling/software availability) a Linux distro 
though, Fedora Silverblue would probably be it.



I should also be clear here that I'm not, in shape or form anyway, 
apologizing to anyone who actually believes that which amounts to "Open 
Source projects are nothing without Linux distros and their packagers". 
I do not feel like I owe anyone who thinks or claims such anything.



Again, very sorry.


___
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

web-assets

[Petr Pisar]

I took web-assets to prevent from braking many packages. If there is somebody
interested in web applications (not my case), I can give the package to him.

-- 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

[Bug 1837486] perl-Convert-Binary-C-0.79 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Convert-Binary-C-0.79-
   ||1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-05-20 10:16:03




-- 
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 1768303] nagios-plugins-all is missing perl(utf8::all)

[bugzilla]

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



--- Comment #7 from vidbaz  ---
Hi,

sorry for the spam, we were installing on Oracle Linux 7 and this package is
available only on ol7_optional_latest repo. We fixed the issue enabling this
Repo 

[ol7_optional_latest]
name=Oracle Linux $releasever Optional Latest ($basearch)
baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/OL7/optional/latest/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1

After that everything looks good.

thanks.


-- 
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 1768303] nagios-plugins-all is missing perl(utf8::all)

[bugzilla]

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

vidbaz  changed:

   What|Removed |Added

 CC||vidbaz-er...@hotmail.com



--- Comment #6 from vidbaz  ---
Hi,

This bug is still present on epel7

I tried also to install perl-Dist-CheckConflicts (yum install
perl-Dist-CheckConflicts) but this package is not present on the epel repo.


Thanks.

vidbaz@host01 /etc/yum.repos.d $ sudo yum install perl-Dist-CheckConflicts
Loaded plugins: ulninfo
No package perl-Dist-CheckConflicts available.
Error: Nothing to do
vidbaz@host01 /etc/yum.repos.d $ 

Repo URL:
http://ftp.tu-chemnitz.de/pub/linux/fedora-epel/7/x86_64/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: Aggressive updating (Python 3.9): Are we trying to hard?

[Kevin Kofler]

Orion Poplawski wrote:
> I guess my hope here is that perhaps we allow build failures hold up
> finishing the rest of a stack's build a bit longer.  Let that pressure
> build to hopefully get some more eyes on really fixing the underlying
> issues.

I am of that mindset too.

Unfortunately, these days, the "Rawhide must be usable at all times" faction 
has the say (and the tooling is set up that way, too, e.g., any broken 
dependency in any release-blocking deliverable will fail the entire Rawhide 
compose, even if we are not anywhere near a release). So just leaving a 
package broken for a couple weeks until it can be fixed *properly* is not 
currently doable, unfortunately. I still think it is the right thing to do 
though.

"Temporary" workarounds tend to become permanent, either because people 
simply forget to turn them off or because the proper fix is not ready in 
time for the release.

Kevin Kofler
___
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: Modularity survey - results

[Kevin Kofler]

Daniel Mach wrote:
> Our goal (I speak for the people who *currently* work on Modularity
> project at Red Hat) is *not* pushing anyone to use Modularity. It's up
> to Fesco, SIGs, spin maintainers and individual package maintainers to
> make their choices.

But our point is that it should be up to individual *users*. Modularity 
needs to become fully optional, i.e.:

* disable `*modular*.repo` by default,
* keep default streams banned (as they are now provisionally),
* ban module-only packages: modular versions should only be allowed as
  alternatives to existing packages,
* encourage using parallel-installable compatibility packages rather than
  modules wherever reasonable (e.g., libraries, language interpreters, …).

Then you can play with the technology as much as you want, without 
disturbing anybody. (But you will probably find that users will prefer other 
ways to get alternative software versions, i.e., Copr for leaf packages, 
parallel-installable compatibility packages for non-leaf packages.)

Kevin Kofler
___
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 maintainers (a.k.a. JavaScript is the new Java)

[Fabio Valentini]

On Wed, May 20, 2020 at 10:50 AM Miro Hrončok  wrote:
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

(big snip)

So ... does this mean we can finally admit that antora (the tool that
generates docs.fedoraproject.org) will never even be packaged for
fedora?
___
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: Modularity survey - results

[Kevin Kofler]

Christopher wrote:
> Interesting that the survey shows that the most common response was that
> people use it "not at all" and the overall response was negative, but the
> reaction to that is, "improve the docs" and "works as intended". Am I the
> only one who thinks that the people pushing modularity aren't listening to
> the larger community?

Indeed, it looks like the only kind of action justified by the responses is 
"axe the whole thing". (See the remainder of my mail for the rationale.)

And the proposed solutions (under "Conclusions and Plans") for the 
encountered issues are not convincing me at all. E.g.:

| Problems finding modular or non-modular RPMs hidden by an active module
| Stream
| Solution: The problem is fixed in Fedora 32 already by the patch
| [https://github.com/rpm-software-management/dnf/pull/1483] .
|
| Problems with modular RPMs overriding non-modular RPMs
| It works per design. Any change proposals should be discussed first.

I think this is a design flaw that cannot just be filed off as "works per 
design", considering that many people have issues with it. And the solution 
to allow "finding" the hidden RPMs through the obscure "dnf module provides" 
command (see the linked "fix") is not of much use, considering that it is 
not how people normally look for packages (and it is not exposed in any UI).

> I used to love Fedora for being my community distro... but ever since
> modularity, things seem to be far less about the community, and far more
> about doing what a tiny few want. Modularity has some good ideas... it has
> some merit... just like SCL had some good ideas... but good ideas aren't
> enough to override the fact that few people want it, and most people find
> it more problematic than beneficial.

Indeed, the vast majority of packagers that answered do not package modules 
at all, only RPMs. More respondents do not even use modularity at all than 
use it frequently.

And "use it occasionally" is not well-defined, since default streams in some 
existing Fedora releases mean that you end up "using modularity 
occasionally" if you do not go out of your way to avoid it (by disabling the 
modular repositories, which Fedora explicitly recommends against). So we 
might not even have a majority using modularity deliberately. (One needs to 
ask better questions to find that out.)

> The disproportionate size of the effort and disproportionate disruption it
> has caused to the stability of Fedora packaging, just don't seem to be
> justifiable at the current level of maturity.

Agreed.

> For what it's worth, I applaud the efforts of the modularity team for the
> kind of research and development they've put in to the system... I don't
> fault them at all for their work to experiment with a new packaging
> paradigm...

Also keep in mind that the current Modularity team is basically a new team 
that inherited the flawed design from the original Modularity team.

> I just think the degree of experimentation on the packager experience
> while packagers still need to do their packaging, wasn't the right venue
> for that experimentation, and Fedora had suffered immensely as a
> consequence.

I agree here too.

So a big +1 to your message.

Kevin Kofler
___
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

Getting deprecation warning about hawkey.Repo class

[Aleksandra Fedorova]

Hi, all,

I am looking for some background and info on this deprecation warning:

/usr/lib64/python3.8/site-packages/hawkey/__init__.py:348:
DeprecationWarning: The class hawkey.Repo is deprecated. Please use
dnf.repo.Repo instead. The class will be removed on 2019-12-31.

I have found this mail [1] from 18 March 2019. It says in Fedora 32
hawkey subpackages will be removed from libdnf. But we have rpmdeplint
running on Fedora 32, which gets this message, see [2].

Koschei service also seems to have the same issue [3]

What is the latest status of this? Has the deprecation happened? Is it
still planned? Are there any tips for tool maintainers, how to deal
with it?


[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P2YXWI77MDX6QZ5H35JZ7ZLRTFZBC5EH/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1832171
[3] https://github.com/fedora-infra/koschei/issues/292


-- 
Aleksandra Fedorova
bookwar
___
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: Lots of systemctl segfaults in Koji Rawhide

[Richard W.M. Jones]

On Tue, May 19, 2020 at 08:43:01PM -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 20:24 -0700, Adam Williamson wrote:
> > On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > > The most suspicious change between the two build envs that I can see is
> > > openssl. GOOD has openssl-1.1.1g-1.fc33.x86_64 , and BAD has
> > > openssl-1.1.1g-2.fc33.x86_64 . I'm gonna try doing an openssl build
> > > with the patch from -2 reverted and see where that gets us.
> > 
> > OK, I think that did the trick. nbdkit's x86_64 build succeeded this
> > time, and the log shows no systemctl crashes:
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/7666/44717666/root.log
> > 
> > I'll file a bug on openssl to let tmraz know about the problem.
> > Hopefully between the two fixes, the next Rawhide may also be fixed...
> 
> Bug reports:
> 
> openssl - https://bugzilla.redhat.com/show_bug.cgi?id=1837809
> libpcap - https://bugzilla.redhat.com/show_bug.cgi?id=1837812

Excellent detective work, thanks!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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

Orphaned packages looking for maintainers (a.k.a. JavaScript is the new Java)

[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-05-20.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CutyCapt  orphan   1 weeks ago
apache-commons-vfsmizdebsk, orphan 0 weeks ago
bmake orphan   3 weeks ago
cinnamon-applet-globalappmenu orphan   3 weeks ago
cinnamon-themes   jcpunk, orphan   3 weeks ago
dateformatorphan   1 weeks ago
drawtkorphan   0 weeks ago
driftnet  orphan, pwouters 4 weeks ago
felix-framework   mizdebsk, msimacek, orphan   1 weeks ago
felix-osgi-obr-resolver   orphan   1 weeks ago
gmpc  orphan   3 weeks ago
gnome-themes  alexl, caillon, caolanm, 0 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, rstrode, ssp
istatdorphan   4 weeks ago
jasmine   nodejs-sig, orphan, patches  0 weeks ago
jasmine-node  nodejs-sig, orphan, patches  1 weeks ago
js-json   nodejs-sig, orphan   1 weeks ago
js-php-date-formatter orphan   4 weeks ago
js-zlib   nodejs-sig, orphan, patches, 1 weeks ago
  zbyszek
kitsune   orphan   0 weeks ago
markednodejs-sig, orphan, patches  1 weeks ago
maven-release jcapik, orphan   2 weeks ago
mocha nodejs-sig, orphan, patches  1 weeks ago
nodejs-abbrev nodejs-sig, orphan, patches  1 weeks ago
nodejs-ain2   nodejs-sig, orphan, patches  1 weeks ago
nodejs-ansi   nodejs-sig, orphan, patches  1 weeks ago
nodejs-ansi-stylesnodejs-sig, orphan, patches  1 weeks ago
nodejs-archy  nodejs-sig, orphan, patches  1 weeks ago
nodejs-asap   nodejs-sig, orphan, patches  1 weeks ago
nodejs-asn1   nodejs-sig, orphan, patches  1 weeks ago
nodejs-assert-plusnodejs-sig, orphan, patches  1 weeks ago
nodejs-async  nodejs-sig, orphan, patches  1 weeks ago
nodejs-aws-sign   nodejs-sig, orphan, patches  1 weeks ago
nodejs-basic-auth-connect nodejs-sig, orphan, patches  1 weeks ago
nodejs-batch  nodejs-sig, orphan, patches  1 weeks ago
nodejs-better-assert  nodejs-sig, orphan, patches  1 weeks ago
nodejs-bindings   nodejs-sig, orphan, patches  1 weeks ago
nodejs-block-stream   nodejs-sig, orphan, patches  1 weeks ago
nodejs-boom   nodejs-sig, orphan, patches  1 weeks ago
nodejs-buffer-crc32   nodejs-sig, orphan, patches  1 weeks ago
nodejs-buffer-equal   nodejs-sig, orphan, patches  1 weeks ago
nodejs-bunker nodejs-sig, orphan, patches  1 weeks ago
nodejs-burritonodejs-sig, orphan, patches  1 weeks ago
nodejs-bytes  nodejs-sig, orphan, patches  1 weeks ago
nodejs-callsite   nodejs-sig, orphan, patches  1 weeks ago
nodejs-chalk  nodejs-sig, orphan, patches  1 weeks ago
nodejs-character-parser   nodejs-sig, orphan, patches  1 weeks ago
nodejs-charm  nodejs-sig, orphan, patches  1 weeks ago
nodejs-child-process-closenodejs-sig, orphan, patches  1 weeks ago
nodejs-chmodr 

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Wed, May 20, 2020 at 09:03:39AM +0100, Paul Howarth wrote:
> What host system are you running that on?

x86_64 Fedora 31 with updates-testing enabled.

After mock finishes bootstrapping DNF, it installs buildrooot and just before
it, it enables the modules:

Complete!
Finish(bootstrap): dnf install
Start(bootstrap): creating root cache
Finish(bootstrap): creating root cache
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
Mock Version: 2.2
INFO: Mock Version: 2.2
Start: dnf install
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   499 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.0 MB/s | 7.0 MB 00:06
CentOS-8 - PowerTools   
   516 kB/s | 2.0 MB 00:03
CentOS-8 - Extras   
   6.5 kB/s | 5.9 kB 00:00
epel
   555 kB/s | 6.6 MB 00:12
Dependencies resolved.
===
 Package  ArchitectureVersion   
RepositorySize
===
Enabling module streams:
 mariadb  10.3  
  
 mariadb-devel10.3  
  

Transaction Summary
===

Complete!
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
11 kB/s | 3.9 kB 00:00
CentOS-8 - AppStream
11 kB/s | 4.3 kB 00:00
CentOS-8 - PowerTools   
   9.9 kB/s | 4.3 kB 00:00
CentOS-8 - Extras   
   3.5 kB/s | 1.5 kB 00:00
epel
   4.4 kB/s | 4.7 kB 00:01
epel
   726 kB/s | 6.6 MB 00:09
Dependencies resolved.
===
 Package  ArchitectureVersion   
  Repository  Size
===
Installing:
 bash x86_64  4.4.19-10.el8 
  BaseOS 1.5 M

After installing the buildroot, it installs the Judy-devel package.

I cannot speak much about a mock configuration, because I had my own changes
in the defaults.cfg and site-defaults.cfg, but when mock introduced the
templates I thrown my configuration away. I don't have any changes in
epel-8-x86_64.cfg and the templates.

-- Petr


signature.asc
Description: PGP signature
___
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

Re: TeXLive 2020 landing in rawhide

[Miro Hrončok]

On 20. 05. 20 10:32, Miro Hrončok wrote:

pungi has:

...
Writing index file Pungi.idx
(./Pungi.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ptm.fd)

! LaTeX Error: File `epstopdf-base.sty' not found.



Looking at /usr/share/texlive/texmf-dist/tex/latex/graphics-def/luatex.def and 
pdftex.def


I believe this should be required by texlive-graphics-def. Will open a PR.


https://src.fedoraproject.org/rpms/texlive/pull-request/5 should fix this



--
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

Re: TeXLive 2020 landing in rawhide

[Miro Hrončok]

On 20. 05. 20 9:55, Miro Hrončok wrote:

On 14. 05. 20 23:55, Tom Callaway wrote:
I've just kicked off new builds for texlive and texlive-base for TeXLive 2020 
in rawhide. Hopefully, everything that depends on them will continue to work, 
but if you notice any new issues generating docs (or any missing components or 
broken dependencies), feel free to email me or open Bugzilla tickets.


Now we get:

This is XeTeX, Version 3.14159265-2.6-0.92 (TeX Live 2020) (preloaded 
format=xelatex)

  restricted \write18 enabled.
entering extended mode
(xelatex/sphinxtests.tex
LaTeX2e <2018-12-01>
(./sphinxmanual.cls
Document Class: sphinxmanual 2018/12/23 v2.0 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty

Package cmap Warning: pdftex not detected - exiting.
...
(./sphinxmessages.sty)
Writing index file sphinxtests.idx
(xelatex/sphinxtests.aux)
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd)

! LaTeX Error: Command `\acute' already defined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
  ...

l.71 \begin{document}

No pages of output.
Transcript written on xelatex/sphinxtests.log.

During the tests of python-sphinx. Is this something that Sphinx need to be 
adapted for? For a laymen's eye, this look slike a problem in 
/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd.


https://koschei.fedoraproject.org/package/python-sphinx?collection=f33


pungi has:

...
Writing index file Pungi.idx
(./Pungi.aux) (/usr/share/texlive/texmf-dist/tex/latex/base/ts1cmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/t1ptm.fd)

! LaTeX Error: File `epstopdf-base.sty' not found.



Looking at /usr/share/texlive/texmf-dist/tex/latex/graphics-def/luatex.def and 
pdftex.def


I believe this should be required by texlive-graphics-def. Will open a PR.

--
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

[EPEL-devel] Re: Modules again

[Paul Howarth]

On Wed, 20 May 2020 08:10:42 +0200
Petr Pisar  wrote:

> On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> > On Tue, 19 May 2020 09:07:30 -0400
> > Stephen John Smoogen  wrote:
> >   
> > > On Tue, 19 May 2020 at 06:05, Paul Howarth 
> > > wrote: 
> > > > On Mon, 18 May 2020 22:29:54 -0600
> > > > Orion Poplawski  wrote:
> > > >
> > > > > On 5/17/20 6:34 AM, Paul Howarth wrote:
> > > > > > I'm trying to do a local build of gtkwave for EPEL-8.
> > > > > >
> > > > > > A koji scratch build somehow works:
> > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
> > > > > >
> > > > > > But a local build does not:
> > > > > >
> > > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
> > > > > > ...
> > > > > > Error:
> > > > > >   Problem: conflicting requests
> > > > > >- package
> > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is
> > > > > > excluded
> > > > > >- package
> > > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
> > > > > > excluded
> > > > > >
> > > > > > Adding a repo with a local build of Judy doesn't help; that
> > > > > > gets excluded too.
> > > > > >
> > > > > > Any clues?
> > > > > >
> > > > > > Paul.
> > > > >
> > > > > Judy-devel appears to be part of the mariadb-devel module.
> > > > > Locally I can do:
> > > > >
> > > > > dnf module enable mariadb-devel
> > > > > dnf install Judy-devel
> > > > >
> > > > > This was discovered with:
> > > > >
> > > > > dnf module provides Judy-devel
> > > > >
> > > > > on RHEL 8.2, though that does not appear to work on CentOS
> > > > > 8.1.
> > > > >
> > > > > For mock, this seems to work:
> > > > >
> > > > > mock -r epel-8-x86_64 --config-opts
> > > > > module_enable=mariadb-devel --config-opts module_enable=
> > > > > gtkwave-3.3.104-2.el8.src.rpm
> > > >
> > > > I tried that and it didn't make any difference for me (building
> > > > on F-31). Maybe I need to wait for CentOS 8.2?
> > > >
> > > >
> > > Hmm do you have the Powertools enabled in that Mock? I see
> > > Judy-devel in the CentOS-8.1 tree in Powertools.  
> > 
> > Yes, I'm using vanilla configs straight from mock-core-configs for
> > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> > which has the PowerTools repo defined and not disabled.
> > 
> > (I generally use my own configs and don't touch the original ones,
> > so I know that if I try the original ones from upstream then they
> > should work as intended)
> > 
> > Note that the error message doesn't say it can't find Judy-devel, it
> > says that it (and Judy) is/are excluded. I don't know why that is.
> >   
> The message means that the Judy-devel package exists in a repository,
> but is not available for an installation, because a module it belongs
> to is not active (i.e. not enabled nor default). The correct
> procedure is enable the module it belongs to.
> 
> "dnf module provides Judy-devel" command returns mariadb-devel:10.3
> module. After enabling that module you get another error message that
> Judy package is excluded. That's because Judy package belongs to
> mariadb:10.3 module. You also need to enable that module. Then it
> works. It also works in mock:
> 
> $ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel
> --config-opts module_enable=mariadb install Judy-devel [...]
> INFO: installing package(s): Judy-devel
> No matches found for the following disable plugin patterns: local,
> spacewalk CentOS-8 - Base
>539 kB/s | 2.2 MB
> 00:04 CentOS-8 - AppStream
>1.3 MB/s | 7.0 MB
> 00:05 CentOS-8 - PowerTools
>442 kB/s | 2.0 MB
> 00:04 CentOS-8 - Extras
>5.7 kB/s | 5.9 kB
> 00:01 epel
>5.2 kB/s | 4.7 kB
> 00:00 Dependencies resolved.
> ===
> PackageArchitecture   Version
>Repository  Size
> ===
> Installing: Judy-devel x86_64
> 1.0.5-18.module_el8.1.0+217+4d875839   PowerTools
>  76 k Installing dependencies: Judy
> x86_64 1.0.5-18.module_el8.1.0+217+4d875839
> AppStream  131 k
> 
> Transaction Summary
> ===
> Install  2 Packages
> [...]
> Installed:
>   Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64
> Judy-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 
> 
> Complete!

What host system are you 

Re: TeXLive 2020 landing in rawhide

[Miro Hrončok]

On 14. 05. 20 23:55, Tom Callaway wrote:
I've just kicked off new builds for texlive and texlive-base for TeXLive 2020 in 
rawhide. Hopefully, everything that depends on them will continue to work, but 
if you notice any new issues generating docs (or any missing components or 
broken dependencies), feel free to email me or open Bugzilla tickets.


Now we get:

This is XeTeX, Version 3.14159265-2.6-0.92 (TeX Live 2020) (preloaded 
format=xelatex)

 restricted \write18 enabled.
entering extended mode
(xelatex/sphinxtests.tex
LaTeX2e <2018-12-01>
(./sphinxmanual.cls
Document Class: sphinxmanual 2018/12/23 v2.0 Document class (Sphinx manual)
(/usr/share/texlive/texmf-dist/tex/latex/base/report.cls
Document Class: report 2018/09/03 v1.4i Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)))
(/usr/share/texlive/texmf-dist/tex/latex/cmap/cmap.sty

Package cmap Warning: pdftex not detected - exiting.

) (/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3-code.tex
(/usr/share/texlive/texmf-dist/tex/latex/l3kernel/l3deprecation.def))
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xdvipdfmx.def)))
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/tuenc.def))
(/usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty))
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty))
(/usr/share/texlive/texmf-dist/tex/latex/polyglossia/polyglossia.sty
(/usr/share/texlive/texmf-dist/tex/latex/etoolbox/etoolbox.sty)
(/usr/share/texlive/texmf-dist/tex/latex/makecmds/makecmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/xkeyval/xkeyval.sty
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifluatex.sty
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty))
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty)
(/usr/share/texlive/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty)
(/usr/share/texlive/texmf-dist/tex/latex/filehook/filehook.sty)
(/usr/share/texlive/texmf-dist/tex/latex/polyglossia/gloss-latex.ldf))
(/usr/share/texlive/texmf-dist/tex/latex/polyglossia/gloss-english.ldf)
(/usr/share/texlive/texmf-dist/tex/latex/fncychap/fncychap.sty) (./sphinx.sty
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/xetex.def)))
(/usr/share/texlive/texmf-dist/tex/latex/fancyhdr/fancyhdr.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/textcomp.sty
(/usr/share/texlive/texmf-dist/tex/latex/base/ts1enc.def))
(/usr/share/texlive/texmf-dist/tex/latex/titlesec/titlesec.sty)
(/usr/share/texlive/texmf-dist/tex/latex/tabulary/tabulary.sty
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty))
(/usr/share/texlive/texmf-dist/tex/latex/tools/longtable.sty)
(/usr/share/texlive/texmf-dist/tex/latex/varwidth/varwidth.sty)
(./sphinxmulticell.sty)
(/usr/share/texlive/texmf-dist/tex/latex/base/makeidx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/framed/framed.sty)
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg))
(/usr/share/texlive/texmf-dist/tex/latex/fancyvrb/fancyvrb.sty)
(./footnotehyper-sphinx.sty)
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty)
(/usr/share/texlive/texmf-dist/tex/latex/wrapfig/wrapfig.sty)
(/usr/share/texlive/texmf-dist/tex/latex/parskip/parskip.sty
(/usr/share/texlive/texmf-dist/tex/latex/parskip/parskip-2001-04-09.sty))
(/usr/share/texlive/texmf-dist/tex/latex/base/alltt.sty)
(/usr/share/texlive/texmf-dist/tex/latex/upquote/upquote.sty)
(/usr/share/texlive/texmf-dist/tex/latex/capt-of/capt-of.sty)
(/usr/share/texlive/texmf-dist/tex/latex/needspace/needspace.sty)
(./sphinxhighlight.sty)
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
(/usr/share/texlive/texmf-dist/tex/generic/kvsetkeys/kvsetkeys.sty)))

Re: Lots of systemctl segfaults in Koji Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 19, 2020 at 04:52:55PM -0700, Adam Williamson wrote:
> In fact it seems to be a bit more complex than that, because systemd
> doesn't actually list its dependency on libpcap:
> 
> [adamw@adam libpcap (master)]$ rpm -q --requires systemd | grep pcap
> [adamw@adam libpcap (master)]$
> 
> but it must be encoded indirectly somehow, because if you try and
> remove libpcap, dnf refuses to because it'd remove systemd:
> 
> [adamw@adam libpcap (master)]$ sudo dnf remove libpcap
> [sudo] password for adamw: 
> Error: 
>  Problem: The operation would result in removing the following
> protected packages: systemd

systemd requires libip4tc.so.2()(64bit) provided by iptables-libs,
and iptables-libs requires libpcap.so.1()(64bit) provided by libpcap.

Zbyszek
___
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-c0d616ed91 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c0d616ed91


-- 
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-b4a3fbecea has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b4a3fbecea


-- 
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-53b85179ad has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-53b85179ad


-- 
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: Lots of systemctl segfaults in Koji Rawhide

[Zbigniew Jędrzejewski-Szmek]

On Tue, May 19, 2020 at 08:43:01PM -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 20:24 -0700, Adam Williamson wrote:
> > On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > > The most suspicious change between the two build envs that I can see is
> > > openssl. GOOD has openssl-1.1.1g-1.fc33.x86_64 , and BAD has
> > > openssl-1.1.1g-2.fc33.x86_64 . I'm gonna try doing an openssl build
> > > with the patch from -2 reverted and see where that gets us.
> > 
> > OK, I think that did the trick. nbdkit's x86_64 build succeeded this
> > time, and the log shows no systemctl crashes:
> > 
> > https://kojipkgs.fedoraproject.org//work/tasks/7666/44717666/root.log
> > 
> > I'll file a bug on openssl to let tmraz know about the problem.
> > Hopefully between the two fixes, the next Rawhide may also be fixed...
> 
> Bug reports:
> 
> openssl - https://bugzilla.redhat.com/show_bug.cgi?id=1837809
> libpcap - https://bugzilla.redhat.com/show_bug.cgi?id=1837812

Adam, thanks for tracking this down!

Zbyszek
___
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Mozilla-CA-20200520-1.
   ||fc33



--- Comment #3 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1837829] perl-Mozilla-CA-20200520 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   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

Re: Modularity survey - results

[Daniel Mach]

Dne 19. 05. 20 v 16:56 Miro Hrončok napsal(a):

On 19. 05. 20 16:46, Christopher wrote:
Interesting that the survey shows that the most common response was 
that people use it "not at all" and the overall response was negative, 
but the reaction to that is, "improve the docs" and "works as 
intended". Am I the only one who thinks that the people pushing 
modularity aren't listening to the larger community?
FWIW I understand the action point for this survey as a way to improve 
the situation for environments where we are "stuck with modularity" 
(such as RHEL and EPEL 8) rather than a call for action that says "if we 
fix this, we'll proceed with Fedora modularization".



Exactly.



Our goal is to improve the *existing* implementation of Modularity (RHEL 
8 and EPEL 8 compatibility is important for us) and make it *available* 
to any projects under Fedora Project umbrella, which includes Fedora and 
EPEL 8. That's why we'll focus on the docs in the first place. The 
survey confirmed that people make a lot of assumptions about Modularity 
and interpret it in their own ways and this is source of many 
misunderstandings. When we're all on the same page, we can move on and 
work on individual fixes.


Our goal (I speak for the people who *currently* work on Modularity 
project at Red Hat) is *not* pushing anyone to use Modularity. It's up 
to Fesco, SIGs, spin maintainers and individual package maintainers to 
make their choices.


Please note that we are not the same people who created Modularity, we 
took it over recently and we are expected to maintain it, not to 
redesign it from scratch. Please give us a chance to prove that we 
listen to the community.





I interpret the survey results that some people in Fedora would use 
modules to build and distribute multiple versions of their software 
stacks, but the increased complexity and related issues are not worth it.


I believe that to make Modularity successful and useful for the 
community, we need to simplify it and better integrate it with the rpm 
ecosystem. Make it more straightforward for those who build or 
distribute modules and nearly invisible for those who consume them.


___
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-20200520.0 compose check report

[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: Lots of systemctl segfaults in Koji Rawhide

[Petr Pisar]

On Tue, May 19, 2020 at 08:24:34PM -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:32 -0700, Adam Williamson wrote:
> > 
> > The most suspicious change between the two build envs that I can see is
> > openssl. GOOD has openssl-1.1.1g-1.fc33.x86_64 , and BAD has
> > openssl-1.1.1g-2.fc33.x86_64 . I'm gonna try doing an openssl build
> > with the patch from -2 reverted and see where that gets us.
> 
> OK, I think that did the trick. nbdkit's x86_64 build succeeded this
> time, and the log shows no systemctl crashes:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/7666/44717666/root.log
> 
> I'll file a bug on openssl to let tmraz know about the problem.
> Hopefully between the two fixes, the next Rawhide may also be fixed...

Nice detective work. You could have save your work with Koschei.

 nbdkit history,
 first failure with this test
failure on x86_64:

supermin: exception: 
Sys_error("/lib/modules/5.7.0-0.rc5.20200515git1ae7efb38854.1.fc33.x86_64/modules.dep:
 No such file or directory")

with only 5 source packages changed and openssl going from 1:1.1.1g-1.fc33 to
1:1.1.1g-2.fc33 being one of them.

-- 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: TeXLive 2020 landing in rawhide

[Miro Hrončok]

On 20. 05. 20 6:05, Orion Poplawski wrote:

On 5/19/20 5:16 AM, Miro Hrončok wrote:

On 15. 05. 20 22:36, Tom Callaway wrote:
I'm hoping that when texlive is able to fully install this issue will go 
away. I just got a successful build for -21 that _should_ resolve all the 
broken deps except for biber.


At this point I get:

   nothing provides biber >= 2.14 needed by texlive-biblatex

This will interfere with Python 3.9 rebuilds. We plan to start those in Koji 
this week.


Is there an emergency break to pull?



biber 2.14 has now been built.


Thank You! This really unblocked us.

--
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

[Bug 1837680] perl-TimeDate-2.33 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-TimeDate-2.33-1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-05-20 07:00:17




-- 
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: Aggressive updating (Python 3.9): Are we trying to hard?

[Miro Hrončok]

On 19. 05. 20 14:24, Miro Hrončok wrote:
If we integrate new Python versions later, this "trying hard" will just shift 
from alphas and betas to .1 and .2.


One more important thing to note is that for example with Python 3.9, it was 
input from Fedora that made a couple long-deprecated-now-removed things 
reverted, because the impact in Fedora was to big. I cannot imagine this 
happening if we integrated Python 3.9.2 instead of 3.9.0a2.


--
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

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Wed, May 20, 2020 at 08:10:42AM +0200, Petr Pisar wrote:
> Now you can ask why enabling mariadb-devel:10.3 does not enable mariadb:10.3
> automatically. Especially when mariadb-devel:10.3 run-requires mariadb:10.3
> according to "dnf module info mariadb-devel:10.3" command. The answer is a bug
> in DNF. I think I recall the bugs has already been fixed, but apparantly it's
> still (or again) there.
> 
https://bugzilla.redhat.com/show_bug.cgi?id=1837841

-- Petr


signature.asc
Description: PGP signature
___
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

[EPEL-devel] Re: Modules again

[Petr Pisar]

On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> On Tue, 19 May 2020 09:07:30 -0400
> Stephen John Smoogen  wrote:
> 
> > On Tue, 19 May 2020 at 06:05, Paul Howarth  wrote:
> > 
> > > On Mon, 18 May 2020 22:29:54 -0600
> > > Orion Poplawski  wrote:
> > >  
> > > > On 5/17/20 6:34 AM, Paul Howarth wrote:  
> > > > > I'm trying to do a local build of gtkwave for EPEL-8.
> > > > >
> > > > > A koji scratch build somehow works:
> > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
> > > > >
> > > > > But a local build does not:
> > > > >
> > > > > $ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
> > > > > ...
> > > > > Error:
> > > > >   Problem: conflicting requests
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.i686 is excluded
> > > > >- package
> > > > > Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64 is
> > > > > excluded
> > > > >
> > > > > Adding a repo with a local build of Judy doesn't help; that gets
> > > > > excluded too.
> > > > >
> > > > > Any clues?
> > > > >
> > > > > Paul.  
> > > >
> > > > Judy-devel appears to be part of the mariadb-devel module.
> > > > Locally I can do:
> > > >
> > > > dnf module enable mariadb-devel
> > > > dnf install Judy-devel
> > > >
> > > > This was discovered with:
> > > >
> > > > dnf module provides Judy-devel
> > > >
> > > > on RHEL 8.2, though that does not appear to work on CentOS 8.1.
> > > >
> > > > For mock, this seems to work:
> > > >
> > > > mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel
> > > > --config-opts module_enable= gtkwave-3.3.104-2.el8.src.rpm  
> > >
> > > I tried that and it didn't make any difference for me (building on
> > > F-31). Maybe I need to wait for CentOS 8.2?
> > >
> > >  
> > Hmm do you have the Powertools enabled in that Mock? I see Judy-devel
> > in the CentOS-8.1 tree in Powertools.
> 
> Yes, I'm using vanilla configs straight from mock-core-configs for
> this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> which has the PowerTools repo defined and not disabled.
> 
> (I generally use my own configs and don't touch the original ones, so I
> know that if I try the original ones from upstream then they should
> work as intended)
> 
> Note that the error message doesn't say it can't find Judy-devel, it
> says that it (and Judy) is/are excluded. I don't know why that is.
> 
The message means that the Judy-devel package exists in a repository, but is
not available for an installation, because a module it belongs to is not
active (i.e. not enabled nor default). The correct procedure is enable
the module it belongs to.

"dnf module provides Judy-devel" command returns mariadb-devel:10.3 module.
After enabling that module you get another error message that Judy package is
excluded. That's because Judy package belongs to mariadb:10.3 module. You also
need to enable that module. Then it works. It also works in mock:

$ mock -r epel-8-x86_64 --config-opts module_enable=mariadb-devel --config-opts 
module_enable=mariadb install Judy-devel
[...]
INFO: installing package(s): Judy-devel
No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base 
   539 kB/s | 2.2 MB 00:04
CentOS-8 - AppStream
   1.3 MB/s | 7.0 MB 00:05
CentOS-8 - PowerTools   
   442 kB/s | 2.0 MB 00:04
CentOS-8 - Extras   
   5.7 kB/s | 5.9 kB 00:01
epel
   5.2 kB/s | 4.7 kB 00:00
Dependencies resolved.
===
 PackageArchitecture   Version  
  Repository  Size
===
Installing:
 Judy-devel x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   PowerTools   
   76 k
Installing dependencies:
 Judy   x86_64 
1.0.5-18.module_el8.1.0+217+4d875839   AppStream
  131 k

Transaction Summary
===
Install  2 Packages
[...]
Installed:
  Judy-devel-1.0.5-18.module_el8.1.0+217+4d875839.x86_64  
Judy-1.0.5-18.module_el8.1.0+217+4d875839.x86_64