Re: Remove old GPG keys?

[Panu Matilainen]

On 11/01/2017 10:37 PM, Kevin Fenzi wrote:

On 11/01/2017 01:07 PM, Christopher wrote:

On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi  wrote:


On 10/31/2017 01:08 PM, Christopher wrote:

[...]

I personally don't see much advantage in expiring old keys or the like.
The only attack vector I can see is tricking someone into installing a
package from an EOL release with a known vulnerablity, but if you can do
that you likely can get them to just download it and install it or
download your resigned package and have them accept the key or any
number of things.



Yeah, that's the attack vector I was thinking. It's also the case that
somebody could be tricked into installing an older version of a patched
package from the current release, which is signed by the same GPG key. So,
maybe it's not much of a mitigation of anything. Still, I think adding a
reasonable expiration date is good practice... and warning during
verification (or making a verification policy configurable in yum/dnf)
might be a good idea.


Well, feel free to file RFE's on yum/rpm/dnf, but I suspect they have
lots of more important things to implement.


I actually mostly implemented OpenPGP expiry for rpm last spring, but 
never never pushed it upstream because in the end it seemed so ... meh.


Yeah it could be made to warn at install-time, to what benefit really?
It's better to have rpm verify the expired signature than have people 
use --nosignature to shut up annoying warnings.


- Panu -
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Final release Go/No-Go Meeting

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Final release Go/No-Go Meeting on 2017-11-02 from 17:00:00 to 19:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:



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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Fedocal] Reminder meeting : Fedora Modular Server 27 Beta Release Go/No-Go - 4th round

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Fedora Modular Server 27 Beta Release Go/No-Go - 4th round on 2017-11-02 
from 17:00:00 to 19:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:



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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular 27 compose report: 20171102.n.0 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171101.n.2
NEW: Fedora-Modular-27-20171102.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] unannounced libfastjson ABI change breaks rsyslog

[Troy Curtis Jr]

On Wed, Nov 1, 2017 at 5:49 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> Dear Fedora,
>
>
..snip..


> This breaks, for example, rsyslog-8.30.0-3, which was compiled against
> libfastjson-0.99.7, but didn't go out together with it, so when I ran
> dnf update, the set contained only new rsyslog, which, when run with
> libfastjson-0.99.6 (same SONAME!) simply dies:
> # rsyslogd -n
> rsyslogd: symbol lookup error: rsyslogd: undefined symbol:
> fjson_global_do_case_sensitive_comparison
>
> Dear maintainers, please use abipkgdiff when doing library updates.
> Upstreams do break ABI without bumping SONAME sometimes.
>
>
I'm not sure if it is a real issue or not.  A user in #fedora got bit by
this where his rsyslog was upgraded but not his libfastjson.  Updating to
libfastjson-0.99.7 allowed rsyslog to startup and begin logging.  But it
appeared to die quickly.  This happened at least twice.

There could be other things going on with his setup, but I thought I'd
point out a potential issue to be on the lookout for even if the missing
symbol has been resolved.

Troy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

please help us test the f27 cloud images in RC1.2

[Dusty Mabe]

You can grab the image download links and fill out the results here:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Cloud


Unfortunately only half the AMIs uploaded: 

Fedora-Cloud-Base-27-1.2.x86_64   EC2 (us-east-1)  ami-acaa02d6 
   paravirtual   gp2
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (us-east-1)  ami-00ac047a 
   paravirtual   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (us-west-2)  ami-38b07b40 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (us-west-1)  ami-69586709 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (sa-east-1)  ami-68cfb704 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (eu-west-1)  ami-f564c58c 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (eu-central-1)   ami-a067e2cf 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (ap-southeast-2) ami-6df41a0f 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (ap-southeast-1) ami-04612c67 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (ap-northeast-1) ami-da963abc 
   hvm   standard   
Fedora-Cloud-Base-27-1.2.x86_64   EC2 (us-east-1)  ami-a9a800d3 
   hvm   standard

I've opened a ticket to get this resolved: https://pagure.io/releng/issue/7126
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 27 Candidate RC-1.2 Available Now!

[Adam Williamson]

On Thu, 2017-11-02 at 11:46 +1100, Steven Haigh wrote:
> 
> I'm not sure if this has been evaluated as a blocker...

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

No, because it hasn't been proposed as one.

> If I understand the test cases, seems it belongs here:
> https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot

I can't really tell, because the bug doesn't have enough information
about exactly how you tried to install.

> Happy if its evaluated and found to not match the criteria, but just 
> don't want stuff to fall through the cracks...

It's hard to tell without more information about the scenario, and some
follow-up testing. Does the same happen without the involvement of Xen?
Did it work with F26? Stuff like that.
-- 
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

Re: Remove old GPG keys?

[Sam Varshavchik]

Jonny Heggheim writes:


On 11/01/2017 11:51 PM, Sam Varshavchik wrote:

> I don't think much of expiring either. But keys for prior releases
> should simply be removed, as part of the upgrade process, or on the
> first boot after a successfull upgrade.
>
> Now, if we go this way, we have to make sure we don't turn a bad
> situation into worse one. It's possible that a botched upgrade might
> end up with a system that's still bootable, so prior releases pgp keys
> should be left alone until it's known that fedup did its job
> successfully.
>
> But once an upgrade is complete, prior release's pgp keys have
> absolutely no value in them, whatsoever, except as an additional
> potential compromise vector.

Packages that was built for older releases are still distributed and
used in newer versions.


So? They're simply signed by the newer release's PGP key. Big deal.



Example:
A package built for Fedora 24, signed with the Fedora 25 key, running on
my Fedora 26 setup.

$ gpg2 < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2016-03-31 [SCE]
  C437DCCD558A66A37D6F43724089D8F2FDB19C98
uid   Fedora 25 Primary (25) 

$ rpm -qi maven-shared-io
Name    : maven-shared-io
Epoch   : 1
Version : 3.0.0
Release : 2.fc24
Architecture: noarch
Install Date: Sat 29 Oct 2016 12:26:04 AM CEST

 ==

Fedora 26 did not exist in October 2016. As such, it would be logically  
impossible for this package to have been installed from the Fedora 26  
repository. You installed this package when you were running Fedora 25.


And removing Fedora 24/25th PGP key should have no effect, whatsoever, on  
currently-installed packages. PGP keys are checked only when a package gets  
installed. Once installed, nothing really cares about PGP signatures, and it  
wouldn't always be possible to verify it anyway, since config files  
installed by the package could obviously be changed, filestamps could be  
changed, etc…


I do see that maven-shared-io-3.0.0-2.fc24.src.rpm is, apparently, in the  
Fedora 26 repository:


[mrsam@thinkpad tmp]$ dnf download maven-shared-io
Last metadata expiration check: 0:00:00 ago on Wed 01 Nov 2017 08:33:50 PM EDT.
maven-shared-io-3.0.0-2.fc24.noarch.rpm 143 kB/s |  50 kB 00:00
[mrsam@thinkpad tmp]$ rpm --checksig maven-shared-io-3.0.0-2.fc24.noarch.rpm
maven-shared-io-3.0.0-2.fc24.noarch.rpm: rsa sha1 (md5) pgp md5 OK

I have only Fedora 26 PGP keys installed:

[mrsam@thinkpad tmp]$ rpm -qa gpg-pubkey
gpg-pubkey-3276f4b3-582f2526
gpg-pubkey-64dab85d-57d33e22
gpg-pubkey-9690e4af-582f231f

You can confirm, yourself, that these are Fedora and RPM fusion 26 keys.

I would not be able to verify the pgp signature on this package, unless it's  
signed by one of the keys I have installed.


Therefore, the Fedora 26 repo must be carrying this package signed by the  
Fedora 26 PGP key. Otherwise I could not possibly install it, obviously.


For final proof, you can download this package from the Fedora 24, 25, and  
26 repos, separately, and verify that they're not binary identical, because  
each package carries a different PGP signature inside it. But this can be  
someone else's homework assignment. IIRC, the PGP signature is at the tail  
end of the rpm file, so I expect the actual binary files to be binary- 
identical until the last dozen, or so bytes. I don't know if rpm file format  
supports multiple signatures, and whether a new signature replaces the rpm  
file's existig one, or adds to it, and I'm too lazy to check right now. If  
the file sizes are different, it must mean that the F25/F26 sigs were tacked  
onto this package. If the file sizes are identical, it means that a new  
signature replaces the existing one.


Either way, removing old Fedora PGP keys should have absolutely zero impact.



pgpU0vrvWnb57.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 27 Candidate RC-1.2 Available Now!

[Steven Haigh]

On 2017-11-02 11:33, Adam Williamson wrote:

On Wed, 2017-11-01 at 23:19 +, rawh...@fedoraproject.org wrote:

According to the schedule [1], Fedora 27 Candidate RC-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/27

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].


Hi folks! Just a heads up: this is a genuine Final release candidate,
there's a chance we'll decide to ship this tomorrow if there are no
release blocking bugs in it. So please, if you can, help run as many
validation tests on it as possible - we really need as close to 100%
coverage as we can get over the next ~18 hours or so. Thanks very much!


I'm not sure if this has been evaluated as a blocker...

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

If I understand the test cases, seems it belongs here:
https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_Pxeboot

Happy if its evaluated and found to not match the criteria, but just 
don't want stuff to fall through the cracks...


--
Steven Haigh

? net...@crc.id.au ? http://www.crc.id.au
? +61 (3) 9001 6090? 0412 935 897
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Fedora 27 Candidate RC-1.2 Available Now!

[Adam Williamson]

On Wed, 2017-11-01 at 23:19 +, rawh...@fedoraproject.org wrote:
> According to the schedule [1], Fedora 27 Candidate RC-1.2 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan
> 
> Test coverage information for the current release can be seen at:
> https://www.happyassassin.net/testcase_stats/27
> 
> You can see all results, find testing instructions and image download
> locations, and enter results on the Summary page:
> 
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Summary
> 
> The individual test result pages are:
> 
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Server
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Cloud
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Desktop
> https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Security_Lab
> 
> All RC priority test cases for each of these test pages [2] must
> pass in order to meet the RC Release Criteria [3].
> 
> Help is available on #fedora-qa on irc.freenode.net [4], or on the
> test list [5].

Hi folks! Just a heads up: this is a genuine Final release candidate,
there's a chance we'll decide to ship this tomorrow if there are no
release blocking bugs in it. So please, if you can, help run as many
validation tests on it as possible - we really need as close to 100%
coverage as we can get over the next ~18 hours or so. Thanks very much!
-- 
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

Re: Remove old GPG keys?

[Jonny Heggheim]

On 11/01/2017 11:51 PM, Sam Varshavchik wrote:

> I don't think much of expiring either. But keys for prior releases
> should simply be removed, as part of the upgrade process, or on the
> first boot after a successfull upgrade.
>
> Now, if we go this way, we have to make sure we don't turn a bad
> situation into worse one. It's possible that a botched upgrade might
> end up with a system that's still bootable, so prior releases pgp keys
> should be left alone until it's known that fedup did its job
> successfully.
>
> But once an upgrade is complete, prior release's pgp keys have
> absolutely no value in them, whatsoever, except as an additional
> potential compromise vector.

Packages that was built for older releases are still distributed and
used in newer versions.

Example:
A package built for Fedora 24, signed with the Fedora 25 key, running on
my Fedora 26 setup.

$ gpg2 < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2016-03-31 [SCE]
  C437DCCD558A66A37D6F43724089D8F2FDB19C98
uid   Fedora 25 Primary (25) 

$ rpm -qi maven-shared-io
Name    : maven-shared-io
Epoch   : 1
Version : 3.0.0
Release : 2.fc24
Architecture: noarch
Install Date: Sat 29 Oct 2016 12:26:04 AM CEST
Group   : Unspecified
Size    : 64077
License : ASL 2.0
Signature   : RSA/SHA256, Sat 02 Apr 2016 12:12:02 AM CEST, Key ID
4089d8f2fdb19c98
Source RPM  : maven-shared-io-3.0.0-2.fc24.src.rpm
Build Date  : Thu 04 Feb 2016 10:36:28 AM CET
Build Host  : arm01-builder21.arm.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor  : Fedora Project
URL : http://maven.apache.org/shared/maven-shared-io
Summary : API for I/O support like logging, download or file scanning
Description :
API for I/O support like logging, download or file scanning.

$ cat /etc/fedora-release
Fedora release 26 (Twenty Six)




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 Modular 27 compose report: 20171101.n.2 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171101.n.1
NEW: Fedora-Modular-27-20171101.n.2

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  10
Dropped packages:6
Upgraded packages:   32
Downgraded packages: 7

Size of added packages:  172.94 MiB
Size of dropped packages:65.18 MiB
Size of upgraded packages:   200.51 MiB
Size of downgraded packages: 17.35 MiB

Size change of upgraded packages:   3.18 MiB
Size change of downgraded packages: -684.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: postgresql-9.5.9-1.module_2d603185
Summary: PostgreSQL client programs
RPMs:postgresql postgresql-contrib postgresql-devel postgresql-docs 
postgresql-libs postgresql-plperl postgresql-plpython postgresql-plpython3 
postgresql-pltcl postgresql-server postgresql-static postgresql-test 
postgresql-upgrade
Size:169613036 bytes

Package: python-augeas-0.5.0-9.module_68954bcb
Summary: Python bindings to augeas
RPMs:python3-augeas
Size:30108 bytes

Package: python-crypto-2.6.1-19.module_68954bcb
Summary: Cryptography library for Python
RPMs:python3-crypto
Size:3575668 bytes

Package: python-gssapi-1.2.0-8.module_68954bcb
Summary: Python Bindings for GSSAPI (RFC 2743/2744 and extensions)
RPMs:python3-gssapi
Size:2911128 bytes

Package: python-kdcproxy-0.3.2-9.module_68954bcb
Summary: MS-KKDCP (kerberos proxy) WSGI module
RPMs:python3-kdcproxy
Size:33268 bytes

Package: python-netaddr-0.7.19-5.module_68954bcb
Summary: A pure Python network address representation and manipulation library
RPMs:python3-netaddr
Size:1603348 bytes

Package: python-netifaces-0.10.6-1.module_68954bcb
Summary: Python library to retrieve information about network interfaces
RPMs:python3-netifaces
Size:167220 bytes

Package: python-pyasn1-0.3.4-2.module_4ff49ed9
Summary: ASN.1 tools for Python
RPMs:python-pyasn1-doc python2-pyasn1 python2-pyasn1-modules python3-pyasn1 
python3-pyasn1-modules
Size:1711484 bytes

Package: python-qrcode-5.1-8.module_68954bcb
Summary: Python QR Code image generator
RPMs:python3-qrcode-core
Size:44988 bytes

Package: uuid-1.6.2-34.module_2d603185
Summary: Universally Unique Identifier library
RPMs:uuid uuid-c++ uuid-c++-devel uuid-dce uuid-dce-devel uuid-devel 
uuid-perl
Size:1654212 bytes


= DROPPED PACKAGES =
Package: python-pip-9.0.1-12.module_34c36fd9
Summary: A tool for installing and managing Python packages
RPMs:python3-pip
Size:1850168 bytes

Package: python-rpm-generators-4.14.0-0.rc1.1.module_34c36fd9
Summary: Requires and Provides generators for Python RPMs
RPMs:python3-rpm-generators
Size:25152 bytes

Package: python-rpm-macros-3-22.module_34c36fd9
Summary: The unversioned Python RPM macros
RPMs:platform-python-rpm-macros python-rpm-macros python-srpm-macros 
python3-rpm-macros
Size:39648 bytes

Package: python-setuptools-36.2.0-7.module_34c36fd9
Summary: Easily build and distribute Python packages
RPMs:python3-setuptools
Size:610744 bytes

Package: python-wheel-0.30.0a0-8.module_34c36fd9
Summary: A built-package format for Python
RPMs:python3-wheel
Size:88368 bytes

Package: python3-3.6.2-19.module_34c36fd9
Summary: Interpreter of the Python programming language
RPMs:python3 python3-devel python3-libs
Size:65731596 bytes


= UPGRADED PACKAGES =
Package:  authconfig-7.0.1-4.module_cd335104
Old package:  authconfig-7.0.1-4.module_b3027fc2
Summary:  Command line tool for setting up authentication from network 
services
RPMs: authconfig
Size: 1626544 bytes
Size change:  60 bytes

Package:  autofs-1:5.1.3-4.module_cd335104
Old package:  autofs-1:5.1.3-4.module_b3027fc2
Summary:  A tool for automatically mounting and unmounting filesystems
RPMs: autofs
Size: 5494112 bytes
Size change:  -224 bytes

Package:  autogen-5.18.12-5.module_cd335104
Old package:  autogen-5.18.12-5.module_b3027fc2
Summary:  Automated text file generator
RPMs: autogen autogen-libopts autogen-libopts-devel
Size: 5243768 bytes
Size change:  468 bytes

Package:  babel-2.3.4-6.module_cd335104
Old package:  babel-2.3.4-6.module_b3027fc2
Summary:  Tools for internationalizing Python applications
RPMs: babel babel-doc python2-babel python3-babel
Size: 10518396 bytes
Size change:  12 bytes

Package:  bind-dyndb-ldap-11.1-6.module_cd335104
Old package:  bind-dyndb-ldap-11.1-6.module_b3027fc2
Summary:  LDAP back-end plug-in for BIND
RPMs: bind-dyndb-ldap
Size: 913176 bytes
Size change:  -56 bytes

Package:  certmonger-0.79.5-2.module_cd335104
Old package:  certmonger-0.79.5-2.module_b3027fc2
Summary:  Certificate status monitor and PKI enrollment client
RPMs: certmonger
Size: 4649156 bytes
Size change:  -28 bytes

Package:  fontawesome-fonts-4.7.0-3.module_cd335104
Old package:  fontawesome

[Test-Announce] Fedora 27 Candidate RC-1.2 Available Now!

[rawhide]

According to the schedule [1], Fedora 27 Candidate RC-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/27

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_27_RC_1.2_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-27/f-27-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_27_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building of OkHttp 3.9.0 fails

[Jonny Heggheim]

On 11/01/2017 09:46 PM, Jonny Heggheim wrote:

> It looks like your patch is corrupting AndroidPlatform.java, how/why did
> you create it? Or did you port it from okhttp2?

I think this patch would work better
https://jonny.fedorapeople.org/okhttp-3.9.0-rm-android-stuff.patch

Another issue; is seems like the dependency okio need to be updated.


Jonny



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Sam Varshavchik]

Kevin Fenzi writes:


I personally don't see much advantage in expiring old keys or the like.
The only attack vector I can see is tricking someone into installing a
package from an EOL release with a known vulnerablity, but if you can do
that you likely can get them to just download it and install it or
download your resigned package and have them accept the key or any
number of things.


I don't think much of expiring either. But keys for prior releases should  
simply be removed, as part of the upgrade process, or on the first boot  
after a successfull upgrade.


Now, if we go this way, we have to make sure we don't turn a bad situation  
into worse one. It's possible that a botched upgrade might end up with a  
system that's still bootable, so prior releases pgp keys should be left  
alone until it's known that fedup did its job successfully.


But once an upgrade is complete, prior release's pgp keys have absolutely no  
value in them, whatsoever, except as an additional potential compromise  
vector.




pgpYk1hNk4uB3.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS-UP] unannounced libfastjson ABI change breaks rsyslog

[Dominik 'Rathann' Mierzejewski]

Dear Fedora,
it looks like the libfastjson-0.99.7 update that was submitted as an
update for all branches contained an unannounced ABI break:
$ abipkgdiff --d1 libfastjson-debuginfo-0.99.6-1.fc26.x86_64.rpm --d2 
libfastjson-debuginfo-0.99.7-1.fc26.x86_64.rpm --devel1 
libfastjson-devel-0.99.6-1.fc26.x86_64.rpm --devel2 
libfastjson-devel-0.99.7-1.fc26.x86_64.rpm libfastjson-0.99.6-1.fc26.x86_64.rpm 
libfastjson-0.99.7-1.fc26.x86_64.rpm
 changes of 'libfastjson.so.4.1.0'===
  Functions changes summary: 3 Removed, 1 Changed (57 filtered out), 4 Added 
functions
  Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

  3 Removed functions:

'function void fjson_object_free_userdata(fjson_object*, void*)'
{fjson_object_free_userdata}
'function void fjson_object_set_serializer(fjson_object*, void*)'
{fjson_object_set_serializer}
'function int fjson_object_userdata_to_json_string(fjson_object*, int, 
int)'{fjson_object_userdata_to_json_string}

  4 Added functions:

'function void fjson_global_do_case_sensitive_comparison(const int)'
{fjson_global_do_case_sensitive_comparison}
'function size_t fjson_object_dump_buffered(fjson_object*, int, char*, 
size_t, void*)'{fjson_object_dump_buffered}
'function size_t fjson_object_size(fjson_object*)'{fjson_object_size}
'function size_t fjson_object_size_ext(fjson_object*, int)'
{fjson_object_size_ext}

  1 function with some indirect sub-type change:

[C]'function int fjson_object_array_add(fjson_object*, fjson_object*)' at 
json_object.c:1001:1 has some indirect sub-type changes:
  parameter 1 of type 'fjson_object*' has sub-type changes:
in pointed to type 'struct fjson_object' at json_object_private.h:51:1:
  type size changed from 2176 to 2048 bits
  1 data member deletion:
'void* fjson_object::_userdata', at offset 2112 (in bits) at 
json_object_private.h:74:1

  1 data member change:
   type of 'data fjson_object::o' changed:
 1 data member changes (1 filtered):
  type of 'double data::c_double' changed:
entity changed from 'double' to 'struct __anonymous_struct__' 
at json_object_private.h:60:1
type size changed from 64 to 128 bits

 end of changes of 'libfastjson.so.4.1.0'===

This breaks, for example, rsyslog-8.30.0-3, which was compiled against
libfastjson-0.99.7, but didn't go out together with it, so when I ran
dnf update, the set contained only new rsyslog, which, when run with
libfastjson-0.99.6 (same SONAME!) simply dies:
# rsyslogd -n
rsyslogd: symbol lookup error: rsyslogd: undefined symbol: 
fjson_global_do_case_sensitive_comparison

Dear maintainers, please use abipkgdiff when doing library updates.
Upstreams do break ABI without bumping SONAME sometimes.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building of OkHttp 3.9.0 fails

[Jonny Heggheim]

Hi Martin!


On 11/01/2017 07:22 PM, Martin Gansser wrote:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile 
> (default-compile) on project okhttp: Compilation failure: Compilation failure:
> [ERROR] 
> /home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[41,19]
>  error: class, interface, or enum expected
> [ERROR] 
> /home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[43,2]
>  error: class, interface, or enum expected
> [ERROR] 
> /home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[45,19]
>  error: class, interface, or enum expected
> ___
>
It looks like your patch is corrupting AndroidPlatform.java, how/why did
you create it? Or did you port it from okhttp2?

Jonny



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Kevin Fenzi]

On 11/01/2017 01:19 PM, Przemek Klosowski wrote:
> On 11/01/2017 03:14 PM, Kevin Fenzi wrote:
>> The only attack vector I can see is tricking someone into installing a
>> package from an EOL release with a known vulnerablity, but if you can do
>> that you likely can get them to just download it and install it or
> 
> Is it possible to compromise an old key, and use it to sign new malware
> that looks like it is from a recent distribution? 

Well, rpm doesn't care what a file is named... you can make a
foobar-1.0.fc30.x86_64.rpm signed by any key you want. That said, you
would have to trick someone into downloading and installing it.

>I understand that it's
> unlikely because private keys are protected equally well regardless
> whether they are old or new, but maybe there's some way that makes older
> keys more vulnerable?

Sure, older keys are likely less bits (I don't recall). So it's more
likely someone could brute force them somehow or the like. As far as I
know even 1024 bit gpg keys are not brute forceable currently.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Kevin Fenzi]

On 11/01/2017 01:07 PM, Christopher wrote:
> On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi  wrote:
> 
>> On 10/31/2017 01:08 PM, Christopher wrote:
>>>
>>> Why wouldn't the keys have expiration dates, following best practices? An
>>> expired key is a bit friendlier of a nudge off of using outdated and
>>> unsupported RPMs than a revoked key, which indicates a potential
>>> compromise. I would expect any GPG keys for Fedora versions older than
>>> EOL+5 or EOL+10 years to have already expired. Is that not the case?
>>
>> nope. It's not the case and it also largely doesn't matter.
>>
>> So, a few facts to toss on the thread:
>>
>> * All our keys that have been generated by sigul (which I think is all
>> of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both
>> retired now) don't set expiration dates.
>>
>>
> Is it possible to change that behavior?

Sure. Would require an RFE against sigul and code/work to implement, but
it should be possible.

...snip...

> I think setting EOL+10 year expiration date would probably annoy nobody if
> the verification simply produced a warning about age and didn't actually
> cause anything to fail.

I think going to all the work of implementing that would waste a lot of
peoples time and cause EOL using people to change nothing.

> 
> 
>> I personally don't see much advantage in expiring old keys or the like.
>> The only attack vector I can see is tricking someone into installing a
>> package from an EOL release with a known vulnerablity, but if you can do
>> that you likely can get them to just download it and install it or
>> download your resigned package and have them accept the key or any
>> number of things.
>>
>>
> Yeah, that's the attack vector I was thinking. It's also the case that
> somebody could be tricked into installing an older version of a patched
> package from the current release, which is signed by the same GPG key. So,
> maybe it's not much of a mitigation of anything. Still, I think adding a
> reasonable expiration date is good practice... and warning during
> verification (or making a verification policy configurable in yum/dnf)
> might be a good idea.

Well, feel free to file RFE's on yum/rpm/dnf, but I suspect they have
lots of more important things to implement.

kevin




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Przemek Klosowski]

On 11/01/2017 03:14 PM, Kevin Fenzi wrote:

The only attack vector I can see is tricking someone into installing a
package from an EOL release with a known vulnerablity, but if you can do
that you likely can get them to just download it and install it or


Is it possible to compromise an old key, and use it to sign new malware 
that looks like it is from a recent distribution? I understand that it's 
unlikely because private keys are protected equally well regardless 
whether they are old or new, but maybe there's some way that makes older 
keys more vulnerable?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Christopher]

On Wed, Nov 1, 2017 at 3:26 PM Kevin Fenzi  wrote:

> On 10/31/2017 01:08 PM, Christopher wrote:
> >
> > Why wouldn't the keys have expiration dates, following best practices? An
> > expired key is a bit friendlier of a nudge off of using outdated and
> > unsupported RPMs than a revoked key, which indicates a potential
> > compromise. I would expect any GPG keys for Fedora versions older than
> > EOL+5 or EOL+10 years to have already expired. Is that not the case?
>
> nope. It's not the case and it also largely doesn't matter.
>
> So, a few facts to toss on the thread:
>
> * All our keys that have been generated by sigul (which I think is all
> of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both
> retired now) don't set expiration dates.
>
>
Is it possible to change that behavior?


> * EPEL-5's key did have a 10 year expiration, and did expire early this
> year before it went end of life. Turns out the only thing that cared
> about that was sigul. yum doesn't check, rpm doesn't check, they happily
> keep using the expired key.
>
>
I think that's what's being proposed to be fixed. rpm and/or yum should
check.
I'm actually not sure I'm on board with that idea, though, because as you
point out further down, the old releases are still served in mirrors, and
could still be in use. I'm more concerned about following best practices to
set expiration dates, so that a key cannot be used past a certain date to
continue to sign new artifacts, unintentionally. Extremely long-lived keys
increase the liklihood that they are using older generation algorithms
which could be broken, weak algorithms, or simply due to their age they're
old enough to have been brute-forced. I don't know that we should do
anything on the verification or cleanup end of things, but setting an
expiration date seems reasonable to me.


> * I've tried to sign the Fedora gpg keys in the past, but I'm really not
> sure it's worth it. IMHO gpg is kind of a dead end. It's hopelessly
> complex, no one bothers to use the web of trust as it was intended, it
> integrates very poorly with everything and only geeks use it.
>
>
One might argue that only geeks use Fedora or Linux in general, so I'm not
sure that's much of a relevant point. The fact is GPG is used to sign RPMs,
which are used by Fedora, so using GPG well is still relevant.


> * Currently we don't do anything to make things difficult for EOL users.
> When a release goes EOL we archive it, but we continue to serve it in
> mirrormanager (now pointing to the archives) and we don't do anything
> with the keys. If we wish to do something like this, it should likely be
> a decision for FESCo and/or the Council. Changing this may annoy a large
> number of people. :)
>
>
I think setting EOL+10 year expiration date would probably annoy nobody if
the verification simply produced a warning about age and didn't actually
cause anything to fail.


> I personally don't see much advantage in expiring old keys or the like.
> The only attack vector I can see is tricking someone into installing a
> package from an EOL release with a known vulnerablity, but if you can do
> that you likely can get them to just download it and install it or
> download your resigned package and have them accept the key or any
> number of things.
>
>
Yeah, that's the attack vector I was thinking. It's also the case that
somebody could be tricked into installing an older version of a patched
package from the current release, which is signed by the same GPG key. So,
maybe it's not much of a mitigation of anything. Still, I think adding a
reasonable expiration date is good practice... and warning during
verification (or making a verification policy configurable in yum/dnf)
might be a good idea.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Kevin Fenzi]

On 10/31/2017 01:08 PM, Christopher wrote:
> 
> Why wouldn't the keys have expiration dates, following best practices? An
> expired key is a bit friendlier of a nudge off of using outdated and
> unsupported RPMs than a revoked key, which indicates a potential
> compromise. I would expect any GPG keys for Fedora versions older than
> EOL+5 or EOL+10 years to have already expired. Is that not the case?

nope. It's not the case and it also largely doesn't matter.

So, a few facts to toss on the thread:

* All our keys that have been generated by sigul (which I think is all
of them, the only exceptions used to be EPEL-4 and EPEL-5 which are both
retired now) don't set expiration dates.

* EPEL-5's key did have a 10 year expiration, and did expire early this
year before it went end of life. Turns out the only thing that cared
about that was sigul. yum doesn't check, rpm doesn't check, they happily
keep using the expired key.

* I've tried to sign the Fedora gpg keys in the past, but I'm really not
sure it's worth it. IMHO gpg is kind of a dead end. It's hopelessly
complex, no one bothers to use the web of trust as it was intended, it
integrates very poorly with everything and only geeks use it.

* Currently we don't do anything to make things difficult for EOL users.
When a release goes EOL we archive it, but we continue to serve it in
mirrormanager (now pointing to the archives) and we don't do anything
with the keys. If we wish to do something like this, it should likely be
a decision for FESCo and/or the Council. Changing this may annoy a large
number of people. :)

I personally don't see much advantage in expiring old keys or the like.
The only attack vector I can see is tricking someone into installing a
package from an EOL release with a known vulnerablity, but if you can do
that you likely can get them to just download it and install it or
download your resigned package and have them accept the key or any
number of things.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Building of OkHttp 3.9.0 fails

[Martin Gansser]

thanks for your explanation, i added the two line as you mentioned.

%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]//pom:compilerId'
%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]//pom:dependencies'

have the next bugs to do with the fact that the Android part must be deleted 
from the sources? What do you think ?
...
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 2.004 s
[INFO] Finished at: 2017-11-01T19:15:50+01:00
[INFO] Final Memory: 13M/144M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) 
on project okhttp: Compilation failure: Compilation failure:
[ERROR] 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[41,19]
 error: class, interface, or enum expected
[ERROR] 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[43,2]
 error: class, interface, or enum expected
[ERROR] 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/okhttp/src/main/java/okhttp3/internal/platform/AndroidPlatform.java:[45,19]
 error: class, interface, or enum expected
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular bikeshed compose report: 20171026.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Modular-Bikeshed-20171026.n.0
NEW: Fedora-Modular-Bikeshed-20171026.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0.00 B
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 27-20171101.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Workstation live i386
Kde live i386

Failed openQA tests: 11/137 (x86_64), 2/22 (i386), 1/2 (arm)

New failures (same test did not fail in 27-20171031.n.0):

ID: 163763  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/163763
ID: 163820  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/163820
ID: 163833  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/163833
ID: 163843  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/163843
ID: 163853  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/163853
ID: 163871  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/163871
ID: 163894  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/163894

Old failures (same test failed in 27-20171031.n.0):

ID: 163742  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/163742
ID: 163768  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/163768
ID: 163787  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/163787
ID: 163795  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/163795
ID: 163797  Test: arm Minimal-raw_xz-raw.xz base_services_start_arm
URL: https://openqa.fedoraproject.org/tests/163797
ID: 163804  Test: x86_64 Workstation Ostree-dvd_ostree-iso 
base_services_start
URL: https://openqa.fedoraproject.org/tests/163804
ID: 163851  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/163851

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

New soft failures (same test did not soft fail in 27-20171031.n.0):

ID: 163785  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/163785

Old soft failures (same test soft failed in 27-20171031.n.0):

ID: 163813  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/163813
ID: 163838  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/163838
ID: 163846  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/163846
ID: 163854  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/163854
ID: 163856  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/163856

Passed openQA tests: 119/137 (x86_64), 20/22 (i386), 1/2 (arm)

New passes (same test did not pass in 27-20171031.n.0):

ID: 163766  Test: x86_64 Workstation-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/163766
ID: 163784  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/163784
ID: 163802  Test: x86_64 Workstation Ostree-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/163802
ID: 163824  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/163824
ID: 163849  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/163849

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
1 packages(s) removed since previous compose: fedora-release-notes
Previous test data: https://openqa.fedoraproject.org/tests/163434#downloads
Current test data: https://openqa.fedoraproject.org/tests/163739#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
1 packages(s) removed since previous compose: fedora-release-notes
Previous test data: https://openqa.fedoraproject.org/tests/163435#downloads
Current test data: https://openqa.fedoraproject.org/tests/163740#downloads

Installed system changes in test i386 Server-dvd-iso install_default: 
1 packages(s) added since previous compose: alef-fonts
3 packages(s) removed since previous compose: dejavu-fonts-common, 
dejavu-sans-fonts, fedora-release-notes
System load changed from 0.27 to 0.12
Previous test data: https://openqa.fedoraproject.org/tests/163455#downloads
Current test data: https://openqa.fedoraproject.org/tests/163760#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 0.76 to 1.16
Previous test data: https://openqa.fedoraproject.org/tests/163459#downloads
Current test data: https://openqa.fedoraproject.org/tests/163764#downloads

Installed system changes in test x86_64 Workstation-boot-iso install_default: 
System load changed from 0.59 to 0.95
Average CPU usage changed from 17.43809524 to 3

Re: Building of OkHttp 3.9.0 fails

[Michael Šimáček]

On 2017-11-01 15:45, Martin Gansser wrote:

Hi,

when trying to compile okhttp with the okhttp.spec file from [1] i get this 
error messages:

...
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:guide:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:simple-client:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:slack:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:sample-parent:pom:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
...
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) on 
project okhttp: Execution default-compile of goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile failed: Plugin 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1 or one of its dependencies 
could not be resolved: The following artifacts could not be resolved: 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1, 
com.google.errorprone:error_prone_core:jar:2.0.16: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1 has not been 
downloaded from it before. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :okhttp

Is there any help to get okhttp compiling again



It is missing additional dependencies for the compiler plugin. You have 
two options: a) package them b) remove them. The dependencies are there 
for static analysis, which is useful for upstream, but redundant for 
Fedora packaging, so I'd just remove them. For that you need to remove 
the dependency declaration, and the part of configuration that 
references them. You can do that with:
%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]//pom:compilerId'
%pom_xpath_remove 
'pom:plugin[pom:artifactId="maven-compiler-plugin"]/pom:dependencies'



Regards,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: 'configure' error on x86_64/ppc64 only

[Dan Horák]

On Wed, 1 Nov 2017 17:29:37 +0100
Antonio Trande  wrote:

> Hi all.
> 
> 'configure' command of 'mld2p4' package is failing on Rawhide
> x86_64/ppc64 only with:
> 
> > checking for working installation of PSBLAS... yes.
> > checking for version of PSBLAS... Done
> > configure: error: PSBLAS version major "unknown".
> 
> It happens on koji, not with 'rpmbuild' and 'mock'.
> 
> Can anyone get 'config.log' from build
> https://koji.fedoraproject.org/koji/taskinfo?taskID=22829601 ?

or you could do something like

diff --git a/mld2p4.spec b/mld2p4.spec
index 204f352..ffc75ac 100644
--- a/mld2p4.spec
+++ b/mld2p4.spec
@@ -221,7 +221,9 @@ export INCBLAS=-I%{_includedir}
   --with-mumps="-ldmumps -lmumps_common -lpord" 
--with-mumpsincdir=%{_includedir}/MUMPS \
   --with-superlu=-lsuperlu --with-superluincdir=%{_includedir}/SuperLU \
   --with-umfpack=-lumfpack --with-umfpackincdir=%{_includedir}/suitesparse
-%make_build
+%make_build || :
+cat path/to/config.log
+exit 1
 
 # Make shared libraries
 pushd lib



Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Rawhide] gawk API changes heads up

[David Kaspar [Dee'Kej]]

Thanks for the info. In that case there's nothing holding me from doing the
rebase (I'm already in contact with gawk extensions developer). My guess is
that the new gawk version will land in Rawhide tomorrow then.

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular 27 compose report: 20171101.n.1 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171101.n.0
NEW: Fedora-Modular-27-20171101.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  2
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  1.91 MiB
Size of dropped packages:0.00 B
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

Size change of upgraded packages:   0.00 B
Size change of downgraded packages: 0.00 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: logrotate-3.12.3-3.module_6e76caf9
Summary: Rotates, compresses, removes and mails system log files
RPMs:logrotate
Size:564324 bytes

Package: words-3.0-27.module_6e76caf9
Summary: A dictionary of English words for the /usr/share/dict directory
RPMs:words
Size:1441492 bytes


= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

'configure' error on x86_64/ppc64 only

[Antonio Trande]

Hi all.

'configure' command of 'mld2p4' package is failing on Rawhide
x86_64/ppc64 only with:

> checking for working installation of PSBLAS... yes.
> checking for version of PSBLAS... Done
> configure: error: PSBLAS version major "unknown".

It happens on koji, not with 'rpmbuild' and 'mock'.

Can anyone get 'config.log' from build
https://koji.fedoraproject.org/koji/taskinfo?taskID=22829601 ?


--
Antonio Trande
sagitter AT fedoraproject dot org
See my vCard.
<>

signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libical 3.0.0 changes license to LGPLv2.1 or MPLv2.0

[Milan Crha]

Hi,

On Wed, 2017-11-01 at 14:56 +0100, Igor Gnatenko wrote:
> Do you know that LGPLv2.1 is wrong license tag in Fedora[0]?

Nope, I do not. Thanks for the pointer.

> You should use LGPLv2+ or MPLv2.0

They do not say "and later", thus the current LGPLv2 is more accurate.
I'm going to correct the .spec file.
Thanks again and bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

long waiting times for COPR jobs

[Michal Novotny]

Hello,

lately, COPR pending job queues are holding jobs for pretty long time (even
hours). This is a buggy behaviour and we will be doing our best to fix this
issue in the following days.

Thank your for your patience
COPR team
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Guidelines change] Changes to the packaging guidelines

[Jason L Tibbitts III]

Here are the recent changes to the packaging guidelines.

-

Following releng approval, the restrictions on the use of rich/Boolean
dependencies have been lifted.

* 
https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_dependencies
* https://pagure.io/packaging-committee/issue/559

-

Packaging guidelines for Rust have been added.

* https://fedoraproject.org/wiki/Packaging:Rust
* https://pagure.io/packaging-committee/issue/705

-

A new section was added to the packaging guidelines regarding shebang
lines. It forbids the use of 'env' and codifies the longstanding rpmlint
rule that non-executable files should not have shebang lines.

* https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines
* https://pagure.io/packaging-committee/issue/700

-

Appstream metadata guidelines were updated to reflect the new location
into which appdata files should be placed.

* https://fedoraproject.org/wiki/Packaging:AppData
* https://pagure.io/packaging-committee/issue/704

-

The python guidelines were modified to forbid the use of /usr/bin/python
in shebang lines or as a dependency of a package.

* https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes
* https://pagure.io/packaging-committee/issue/698

-

The SourceURL guideliens were altered to Use a simplified form for
github URLs.

* https://fedoraproject.org/wiki/Packaging:SourceURL#Git_Hosting_Services
* https://pagure.io/packaging-committee/issue/697

-

The section on bundled libraries was expanded with more explicit
instructions on constructing the Provides: line which indicates the
bundling.

* 
https://fedoraproject.org/wiki/Packaging:Guidelines#Bundling_and_Duplication_of_system_libraries
* https://pagure.io/packaging-committee/issue/696

-

The section on statically linking executables has been completely
revamped to remove the need for committee intervention and to make it
more obvious that there is no prohibition on statically linking to build
artifacts within a single package.

* 
https://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables
* https://pagure.io/packaging-committee/issue/692
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review Swaps

[Richard Shaw]

I have a few simple C++ based review requests that I'm willing to perform
review swaps for:

flnet - Amateur Radio Net Control Station
https://bugzilla.redhat.com/show_bug.cgi?id=1060852

flwkey - Modem program for the K1EL Winkeyer series
https://bugzilla.redhat.com/show_bug.cgi?id=1321081

linsim - Tool for Amateur Radio Digital Mode evaluation
https://bugzilla.redhat.com/show_bug.cgi?id=1508478

flcluster - A management tool for accessing dxcluster nodes
https://bugzilla.redhat.com/show_bug.cgi?id=1508492

Thanks,
Richard
FAS: hobbes1069
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] droping file_contexts.bin from selinux-policy-targeted package

[Petr Lautrbach]

On Wed, Nov 01, 2017 at 09:59:29AM +0100, Igor Gnatenko wrote:
> On Wed, 2017-11-01 at 09:46 +0100, Petr Lautrbach wrote:
> > Hi,
> > 
> > we are going to drop file_contexts.bin from selinux-policy-targeted
> > package.
> > 
> > file_contexts.bin file is regenerated by sefcontext_compile utility
> > every time
> > policy is rebuilt, e.g. during update, after semodule -B, ... and
> > this file
> > contains pre compiled pcre regexes from file_contexts.
> > 
> > We added this file to selinux-policy-targeted in order to prevent
> > problems such
> > were [1] [2] but it causes another problems like [3]
> > 
> > Since systemd should be already fixed, it seems to be safe to drop it
> > again and
> > let it create during post install phase.  So we are going to drop it
> > from
> > Rawhide and I think it could be dropped from Fedora 27 as well.
> Am I right that this file will be created on installation? Then you
> should use %ghost to mark it belonging to some package.

Yes, this is the plan.

https://src.fedoraproject.org/fork/plautrba/rpms/selinux-policy/c/dba350c6e03d8747a5524e59ff80cd6277ffa755

If you want to see the changes see

https://src.fedoraproject.org/rpms/selinux-policy/pull-request/3

Thanks,

Petr

> > 
> > I've prepared COPR selinux-policy build [4] without this file. It
> > would be
> > great if someone could test it in some Live image.
> > 
> > With few simple step you can also test how userspace works without
> > *.bin files
> > on a local system:
> > 
> > 1. remove .bin files from /etc/selinux/targeted/contexts/files/
> > 
> > # rm /etc/selinux/targeted/contexts/files/*bin
> > 
> > 2. add/change /etc/selinux/semanage.conf so it contains:
> > 
> > [sefcontext_compile]
> > path = /bin/true
> > [end]
> > 
> > 3. update selinux-policy{,-targeted} from [4]
> > 
> > 4. test it - reboot, relabel, run a desktop session, ...
> > 
> > 
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314372
> > [2] https://github.com/systemd/systemd/pull/2508#issuecomment-1882354
> > 77
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1502009
> > 
> > [4] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-policy/b
> > uild/656330/
> > 
> > Thanks,
> > 
> > Petr
> > 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> -- 
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Michal Novotny]

We have finished the SCM source type implementation. You can read more in
this blog post: https://clime.github.io/2017/10/24/COPR-SCM.html

Thank you for the feedback!
clime

On Wed, Sep 27, 2017 at 10:28 PM, Michal Novotny  wrote:

> Hello,
>
> On Tue, Sep 5, 2017 at 5:50 PM, Petr Stodulka  wrote:
>
>>
>>
>> On 4.9.2017 19:27, Michal Novotny wrote:
>> > I might contact you for more information, but alright, if you feel the
>> custom script is more convenient,
>> > then I am all for it. But first, I would like to make a proposal of
>> each option (with screenshots and
>> > just complete feature request description) so that users can clearly
>> see  the options and pick what
>> > they like the best. We can work with Pavel on it.
>> >
>> > If you agree, I would post the two proposals here before actual
>> implementation.
>> >
>>
>> Yes, it would be fine see concrete proposals to discuss it before
>> implementation. Thanks.
>>
>
> in the end, we decided, we will probably try out both ways. I will likely
> implement the 'make srpm'
> command in addition to 'tito', 'tito --test', 'rpkg' options in the SCM
> tab and Pavel will make new
> source type called 'Custom' (or something similar) where user can script
> out the way how sources
> for a subsequent srpm build are going to be fetched. This script will be
> stored in DB and will
> launched in a chroot initialized by a set of predefined buildroot packages
> (i.e. fedpkg, wget,). Both
> solutions will be fairly equivalent, except in the first case the script
> will be stored in a Git repository,
> whereas in the second, it will be stored in the COPR database. The latter
> will likely offer more
> more freedom in where to fetch sources from (i.e. launchpad.net or CPAN)
> whereas the former
> will be focused mainly on Git and SVN (likely) sources.
>
> Consider this still to be in a proposal state. We will see how well the
> actual implementation goes.
>
>
>>
>> P.
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libical 3.0.0 changes license to LGPLv2.1 or MPLv2.0

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2017-11-01 at 12:58 +0100, Milan Crha wrote:
>   Hello,
> with the update to libical 3.0.0 the sources changed the license from
> LGPLv2 or MPLv1.1 to LGPLv2.1 or MPLv2.0, as mentioned in the
> upstream
> list here:
> http://lists.infradead.org/pipermail/libical-devel/2017-
> May/000764.html

Do you know that LGPLv2.1 is wrong license tag in Fedora[0]? You should
use LGPLv2+ or MPLv2.0

[0] https://fedoraproject.org/wiki/Licensing:Main
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAln50oQACgkQaVcUvRu8
X0yuMw//YV3wiH2+VOKmojLw/BUrBXsgAHhVTINRmcOJMGNEkOpk0Uzyksf+VkSG
LPhWFnNkcIDGEN/zEeB7LiinkyJwNYG/9D+z3aoKYdgKOG7BhTL4xjScnMak4M2F
iwch+Fv1V4zJReYj36IORf0b1XE5ZpmMW5Uy9g92DzJBz67yN9QJTNmsWMLuTmTu
jxPph5WIEn4CVxf95I1at20+SBwP0xjVohUct2wCPWc752/GGfqeR23XKxSt8XCz
LcXY68eOMREulXhzssFbprPKNu0TQRfP2iB0A+QISuV8LU5l1NcVdpGdH7rHmUSu
QV1Pj+Gs45j5Vybxf0AOrb/0jqDtzN0jw+fHwW0xNMOuUwBrwwDguMIO5Jo65yLn
F5WbapCyk9d1K557lAp2n7nE0jOLWbAg1SGR5qYhqmyCP4r5iPdRnRMrcv3cPrtF
9S17FlcX1EQQJtMtxA4Js9IJb7ULay4aTp3w0fPw894TbTB3ubqIpvNB0GbrAk4e
LiFldMklGiaAvp4+KszSoJXq5zxYVK7E/j3hl2L9CZwUYyarsag5usHuBzWxfhsU
zaA0Bu7Lsv2y8VfsARa2O5LvbvzrASyRwKLPXZNAABOwxZUo6CROhwu9ULQKCNJk
AOxs1XrBUw2xatXV+Oai7QOFGc4FpcBjWXb67Luw6TQRsoetT88=
=mCnV
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Building of OkHttp 3.9.0 fails

[Martin Gansser]

Hi,

when trying to compile okhttp with the okhttp.spec file from [1] i get this 
error messages:

...
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:guide:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:simple-client:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:slack:jar:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
com.squareup.okhttp3.sample:sample-parent:pom:3.9.0
[WARNING] 'build.plugins.plugin.version' for 
org.codehaus.mojo:animal-sniffer-maven-plugin is missing. @ 
com.squareup.okhttp3.sample:sample-parent:[unknown-version], 
/home/martin/rpmbuild/BUILD/okhttp-parent-3.9.0/samples/pom.xml, line 24, 
column 15
...
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) 
on project okhttp: Execution default-compile of goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile failed: Plugin 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1 or one of its dependencies 
could not be resolved: The following artifacts could not be resolved: 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1, 
com.google.errorprone:error_prone_core:jar:2.0.16: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.codehaus.plexus:plexus-compiler-javac-errorprone:jar:2.8.1 has not been 
downloaded from it before. -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :okhttp

Is there any help to get okhttp compiling again

[1] https://martinkg.fedorapeople.org/Packages/okhttp3/okhttp.spec
[2] https://martinkg.fedorapeople.org/Packages/okhttp3/build-error.txt

Thanks
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[David Cantrell]

On 10/31/2017 04:15 PM, Sam Varshavchik wrote:
> David Cantrell writes:
> 
>> I don't really consider this a thing about saving space or making the
>> output of 'rpm -qa' look nicer or something, but rather being good users
>> of GPG.  If we create and then phase out signing keys, then part of our
>> process should also involve sending revocations for the old keys.  And
>> that process could be automated by a dnf plugin too.  Leaving old keys
>> around on the system for verification purposes presents a risk should
>> the old key become compromised.
> 
> Pretty sure I recall that a signing key was potentially compromised,
> some years ago, and the entire distro had to be re-signed with a new key.

Indeed.  It has happened.  It was very frustrating.

> … Yup. Just checked. Fedora 9 had to be re-signed with a new pgp key.
> 
> How quickly people forget.

It's very easy to forget.

> Personally, every few releases I've manually gone through, and nuked old
> repo keys.

And I think a lot of us tend to do that sort of housekeeping work, which
was sort of the point of my response.  We could make that a little
better in our tools (if it's not already there in some capacity).

Thanks,

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[David Cantrell]

On 10/31/2017 04:08 PM, Christopher wrote:
> On Tue, Oct 31, 2017 at 3:06 PM David Cantrell  > wrote:
> 
> On 10/31/2017 11:32 AM, R P Herrold wrote:
> > On Tue, 31 Oct 2017, David Cantrell wrote:
> >
> >>> # rpm -qa gpg-pubkey --qf "%{version}-%{release} %{summary}\n"|wc -l
> >>> 64
> >>
> >> Do we issue revocations for old keys?  If not, let's do that and
> extend
> >> dnf to honor those and clean up?
> >
> > What is the 'use case' for potentially preventing installation
> > against a already know key of a existing, but older 'noarch'
> > package; or one unpacking an older SRPM and NOT getting the
> > scary NOKEY warning?  The size of the keys is trivial, even
> > though they do tend to accrete in a 'long running' instance
> >
> > heck, I'll wager mostly those keys are never countersigned
> > into a web of trust, and sent to the constellation of GnuPG
> > key-servers in the first place
> >
> > Going even further, and revoking the keys is 'fly-specking'
> > overkill
> >
> > I have no problem with removing keys not _used_ on a given
> > host (such information being able to be compiled out of the
> > RPM database)
> 
> I don't really consider this a thing about saving space or making the
> output of 'rpm -qa' look nicer or something, but rather being good users
> of GPG.  If we create and then phase out signing keys, then part of our
> process should also involve sending revocations for the old keys.  And
> that process could be automated by a dnf plugin too.  Leaving old keys
> around on the system for verification purposes presents a risk should
> the old key become compromised.
> 
> 
> Why wouldn't the keys have expiration dates, following best practices?
> An expired key is a bit friendlier of a nudge off of using outdated and
> unsupported RPMs than a revoked key, which indicates a potential
> compromise. I would expect any GPG keys for Fedora versions older than
> EOL+5 or EOL+10 years to have already expired. Is that not the case?

I don't know if the keys have expiration dates or not, but that would be
effective too.  And our packaging tools could clean things up based on
that information as well.

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg failed to retire package

[Chenxiong Qi]

On Wed, Nov 1, 2017 at 8:46 PM, Zamir SUN  wrote:
> Hi Chenxiong,
>
>> What's the fedpkg version are you using?
>>
>
> I was using fedpkg-1.28-1.fc26.noarch that day.
> I try update and get 1.29-5.fc26 now. While I already executed on all
> branches of portpub. So do I need to run fedpkg retire again with this
> new version?

I don't think you need to run it again.

BTW, retiring package from pkgdb had been removed since fedpkg-1.29.

>
> Thanks.
>
> --
> Ziqian SUN (Zamir)
> GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
> Want to know more about Fedora?
> Visit https://fedoraproject.org/wiki/
> Ready to contribute? See https://whatcanidoforfedora.org/



-- 
Regards,
Chenxiong Qi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Stefan Hajnoczi

[Stefan Hajnoczi]

On Wed, Nov 1, 2017 at 11:31 AM, Richard W.M. Jones  wrote:
> On Wed, Nov 01, 2017 at 11:25:05AM +, Stefan Hajnoczi wrote:
>> Hi Fedora,
>> I have just submitted my first Fedora package, git-publish - Prepare
>> and store patch revisions as git tags:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1508384
>>
>> I've used Copr up until now but it's time to make some of the software
>> I'm involved with more easily available.
>>
>> Most of my open source involvement is with the QEMU and KVM projects.
>> I work in Red Hat's virtualization team.  I also contribute to
>> developer utilities from time to time.
>>
>> My website is https://vmsplice.net/ and has my PGP key, blog, and
>> slides for presentations I've given over the years.
>
> Welcome Stefan.
>
> I've agreed to sponsor Stefan into the packager process, since I've
> known him a long time and he's done a huge amount of work in
> communities such as (but not only) qemu.

Thank you Rich!

My original email didn't go through to the list.  Since you quoted my
full email there is no need to resend.

Stefan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: fedpkg failed to retire package

[Zamir SUN]

Hi Chenxiong,

> What's the fedpkg version are you using?
> 

I was using fedpkg-1.28-1.fc26.noarch that day.
I try update and get 1.29-5.fc26 now. While I already executed on all
branches of portpub. So do I need to run fedpkg retire again with this
new version?

Thanks.

-- 
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

libical 3.0.0 changes license to LGPLv2.1 or MPLv2.0

[Milan Crha]

Hello,
with the update to libical 3.0.0 the sources changed the license from
LGPLv2 or MPLv1.1 to LGPLv2.1 or MPLv2.0, as mentioned in the upstream
list here:
http://lists.infradead.org/pipermail/libical-devel/2017-May/000764.html

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Self Introduction: Stefan Hajnoczi

[Richard W.M. Jones]

On Wed, Nov 01, 2017 at 11:25:05AM +, Stefan Hajnoczi wrote:
> Hi Fedora,
> I have just submitted my first Fedora package, git-publish - Prepare
> and store patch revisions as git tags:
> https://bugzilla.redhat.com/show_bug.cgi?id=1508384
> 
> I've used Copr up until now but it's time to make some of the software
> I'm involved with more easily available.
> 
> Most of my open source involvement is with the QEMU and KVM projects.
> I work in Red Hat's virtualization team.  I also contribute to
> developer utilities from time to time.
> 
> My website is https://vmsplice.net/ and has my PGP key, blog, and
> slides for presentations I've given over the years.

Welcome Stefan.

I've agreed to sponsor Stefan into the packager process, since I've
known him a long time and he's done a huge amount of work in
communities such as (but not only) qemu.

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

[Heads-up] libical 3.0.0 to reach rawhide, replacing libical-glib

[Milan Crha]

Hello,
I'd like to give a heads up about a plan to update libical to its 3.0.0
release in rawhide once I figure out some details about its build. This
release also obsoletes libical-glib package, the project had been added
into libical itself.

I currently plan to push the update on Monday, November 6th.

The list of dependencies according to:
   # dnf repoquery --whatrequires libical-devel --alldeps
follows:
   evolution-data-server-devel
   libical-glib-devel
   kf5-kcalendarcore-devel
   maya-calendar-devel
I have commit rights only for the first two, where the second is to be
obsoleted anyway.

The list of packages using libical is much longer:

   # dnf repoquery --whatrequires libical --alldeps
   akonadi-calendar-tools
   akonadiconsole
   almanah
   asterisk-calendar
   bijiben
   blogilo
   bluez-obexd
   cairo-dock-plug-ins-base
   california
   calligra-plan-libs
   claws-mail-plugins-vcalendar
   cyrus-imapd
   cyrus-imapd-utils
   digikam
   digikam-libs
   evolution
   evolution-bogofilter
   evolution-data-server
   evolution-data-server-tests
   evolution-ews
   evolution-mapi
   evolution-pst
   evolution-spamassassin
   gnokii
   gnome-calendar
   gnome-shell
   gnome-todo
   kalarm
   kdepim-addons
   kdepim-runtime
   kdepim-runtime-libs
   kdepimlibs
   kf5-akonadi-calendar
   kf5-akonadi-search
   kf5-calendarsupport
   kf5-eventviews
   kf5-incidenceeditor
   kf5-kalarmcal
   kf5-kblog
   kf5-kcalendarcore
   kf5-kcalendarutils
   kf5-ktnef
   kf5-messagelib
   kmail
   kmail-libs
   kmymoney
   knotes-libs
   korganizer
   korganizer-libs
   libical-glib
   libkgapi
   libkolab
   libopensync-plugin-evolution2
   maya-calendar
   openchange-client
   orage
   osmo
   python2-kolab
   renku
   syncevolution
   syncevolution-libs
   syncevolution-libs-akonadi
   wingpanel-indicator-datetime
   zanshin

I know they get the dependency mostly due to using one or more of
the packages from the first list, but I guess it will be safer to
rebuild them too. I have commit rights to many of those, but not to
all, thus I'd need help with rebuilds from the respective maintainers,
co-maintainers or proven packager(s), once I push the libical 3.0.0 to
the rawhide.

Bye,
Milan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS-UP] droping file_contexts.bin from selinux-policy-targeted package

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2017-11-01 at 09:46 +0100, Petr Lautrbach wrote:
> Hi,
> 
> we are going to drop file_contexts.bin from selinux-policy-targeted
> package.
> 
> file_contexts.bin file is regenerated by sefcontext_compile utility
> every time
> policy is rebuilt, e.g. during update, after semodule -B, ... and
> this file
> contains pre compiled pcre regexes from file_contexts.
> 
> We added this file to selinux-policy-targeted in order to prevent
> problems such
> were [1] [2] but it causes another problems like [3]
> 
> Since systemd should be already fixed, it seems to be safe to drop it
> again and
> let it create during post install phase.  So we are going to drop it
> from
> Rawhide and I think it could be dropped from Fedora 27 as well.
Am I right that this file will be created on installation? Then you
should use %ghost to mark it belonging to some package.
> 
> I've prepared COPR selinux-policy build [4] without this file. It
> would be
> great if someone could test it in some Live image.
> 
> With few simple step you can also test how userspace works without
> *.bin files
> on a local system:
> 
> 1. remove .bin files from /etc/selinux/targeted/contexts/files/
> 
> # rm /etc/selinux/targeted/contexts/files/*bin
> 
> 2. add/change /etc/selinux/semanage.conf so it contains:
> 
> [sefcontext_compile]
> path = /bin/true
> [end]
> 
> 3. update selinux-policy{,-targeted} from [4]
> 
> 4. test it - reboot, relabel, run a desktop session, ...
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1314372
> [2] https://github.com/systemd/systemd/pull/2508#issuecomment-1882354
> 77
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1502009
> 
> [4] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-policy/b
> uild/656330/
> 
> Thanks,
> 
> Petr
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAln5jPEACgkQaVcUvRu8
X0yy9w//Z8GDqWhQOJoWL7UeP3OO+8s1i5NbUSw0cLsZroccy9A5yTvX+3tSOP1i
oxE0XWQFPF81nefbDAXdpxWqhVtVigQMpvgXKI3yss46Xnk4zts/Avbsti1ctvFB
KUPFl/nrwUTXF/sTkLSiz6RFWURL/fRrfBrsFhfEzDyp8wwEfpDb6Jh0ago0lgfD
2UZsLacRezy5XU38w4C9kJRlm/C4HpuNb/aiE3ciz8hlvtMwUbCCf5cQo7BqugMq
50/e/tbcMzsBh5Ynav0wgEvLhNSR3WO2T8h7T7b4uFbKAph65A0LzHJqXDscDX4q
GdNWjLEcKgMcpkvullVmJN+KbT/Sa3zEZO9ZFedd+0VHgP1ZLLzZPtc+7bTXN0uy
rRFplppfs8NiMyLRHkyl35C6Z8lykWAh8o3zdV4XIeIzMrCt3sqmF6Fq3z6r6YGn
xxz8t5jjJh+uUrcSbw9N2ojnwZkR6oWmTOiCEvUbOBk73xxnV2oNgbvzwoW+1CAI
mLCQQ//WhpuaEiupdk2wR5zXeeIOqZ6VXeYH6UWxn5Q1xa4aUljbI8C5s6Yqsf3a
cSULw83wz9keIXpjzg39mOxTHcLJJFHKI+lnPn4X7M2PjrTDvaNHbs40pYGzCfX1
Fy9VPtZPKSm4Uqp62YyCTH7wvNsfT4dWy1ZXCkxHTgzaNwEOeMs=
=emsS
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS-UP] droping file_contexts.bin from selinux-policy-targeted package

[Petr Lautrbach]

Hi,

we are going to drop file_contexts.bin from selinux-policy-targeted package.

file_contexts.bin file is regenerated by sefcontext_compile utility every time
policy is rebuilt, e.g. during update, after semodule -B, ... and this file
contains pre compiled pcre regexes from file_contexts.

We added this file to selinux-policy-targeted in order to prevent problems such
were [1] [2] but it causes another problems like [3]

Since systemd should be already fixed, it seems to be safe to drop it again and
let it create during post install phase.  So we are going to drop it from
Rawhide and I think it could be dropped from Fedora 27 as well.

I've prepared COPR selinux-policy build [4] without this file. It would be
great if someone could test it in some Live image.

With few simple step you can also test how userspace works without *.bin files
on a local system:

1. remove .bin files from /etc/selinux/targeted/contexts/files/

# rm /etc/selinux/targeted/contexts/files/*bin

2. add/change /etc/selinux/semanage.conf so it contains:

[sefcontext_compile]
path = /bin/true
[end]

3. update selinux-policy{,-targeted} from [4]

4. test it - reboot, relabel, run a desktop session, ...


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1314372
[2] https://github.com/systemd/systemd/pull/2508#issuecomment-188235477
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1502009

[4] 
https://copr.fedorainfracloud.org/coprs/plautrba/selinux-policy/build/656330/

Thanks,

Petr

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

SDL2_image changes license from LGPLv2+ to LGPLv2+ and zlib

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since 2.0.2, SVG support is included.. And as usual, in a bad way by
bundling some library with custom changes. Now it is nanosvg where
upstream never had any releases.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAln5gJoACgkQaVcUvRu8
X0xFIhAAiLDkvd4wkewrShM3KHdN+2giTNPDJnOvHS1sj/6SjmCJtMzPpYGpUBIT
/uYL0oId7jThN8pNirL2KF22SoffU0j6NZoJ7YWGntoq9uq0a3sss2lWplovSaVI
/ZfVGfDzuz3UgyGA7cNHkw/pfNUplg6LHH+YOjlswozw6LWCp4NRIPuDfnxMnCZf
M1ZTNndykAQkWkIoyv7e2TFkpWaKaEEhWVQhCmcCYugDSmH0WH7fullfnNytsRiG
En4U2XVBE2MXUZH5qZA6yZHbirDEKPRYZW4NHzoHYussJGZzXtfPwAJFBUTgBRZ9
JumBKVSYpO7sICC032yAcmvnicom8jOICkHDLBhZRKm96V3RWKB5MkLgaebS5dd/
3ENGEIQIHiH3waD5OlM6W99Yw+W93S/djpQvcpQhxNkbr9o3LHzH2+kOcz/+urGR
hS8hCloQXHpS2Wxw5+5clmvqxtXOHvIR1O2Vq9aFJ7d3EwSb+KDLrImpRwQk18pp
pvXroXDYWreFOhcicp9khUC4y0IWAmPoqX6Pd6B8nIi3KJGMZ4MC8s0disalnV3N
rioQM6lK1EkYgB0toVIlhxV7oqIRzwO69Nzibp7dEy7469zXIe4jXthZSJk8P9D9
lXLWQn+D2K+wkg2MJTbg1EG7vcJ8sxx0sEbxZlqinEjL/ynIkpU=
=DfVq
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org