Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Panu Matilainen]

On 3/22/19 12:23 AM, Richard W.M. Jones wrote:

On Thu, Mar 21, 2019 at 10:05:55PM +, Tomasz Kłoczko wrote:

Just FTR:

[tkloczko@domek SPECS.fedora]$ egrep -w "popd|pushd" * -l| wc -l
2843

Looks like many Fedora packagers forgot that ..

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh


So what?  On Fedora /bin/sh is bash, and bash is a fine shell.

All this nonsense of using dash for /bin/sh on Debian is IMO a
pointless bunch of make-work.


Truly.

It's also actually documented,
https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_default_shell 
says:



In Fedora, all scriptlets can safely assume they are running under the bash 
shell unless a different language has been specified.


It talks about scriptlets, but both scriptlets and build scripts invoke 
the very same /bin/sh so the guarantee holds for both.


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

Re: two Ceph updates for f28, f29, stuck in pending testing for six days

[Kaleb Keithley]

On Tue, Feb 19, 2019 at 3:18 AM Kevin Fenzi  wrote:

> On 2/18/19 12:56 PM, Kaleb Keithley wrote:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-1c53f1a6c8
> > https://bodhi.fedoraproject.org/updates/FEDORA-2019-6a2e72916a
> >
> > Would someone please give them a kick?
>
> For some reason autosign likes to not process these correctly.
>
> I've retagged them to get it to do another pass...
>
> Sorry for not fixing them sooner.
>

Looks like another Ceph build is stuck.

 https://bodhi.fedoraproject.org/updates/FEDORA-2019-16c36506c1

Would someone kick it please? Thanks

--

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

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Richard W.M. Jones]

On Thu, Mar 21, 2019 at 10:05:55PM +, Tomasz Kłoczko wrote:
> Just FTR:
> 
> [tkloczko@domek SPECS.fedora]$ egrep -w "popd|pushd" * -l| wc -l
> 2843
> 
> Looks like many Fedora packagers forgot that ..
> 
> [tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
> /bin/sh

So what?  On Fedora /bin/sh is bash, and bash is a fine shell.

All this nonsense of using dash for /bin/sh on Debian is IMO a
pointless bunch of make-work.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

More than 10% of all Fedora spec files are not POSIX sh compliant

[Tomasz Kłoczko]

Just FTR:

[tkloczko@domek SPECS.fedora]$ egrep -w "popd|pushd" * -l| wc -l
2843

Looks like many Fedora packagers forgot that ..

[tkloczko@domek SPECS.fedora]$ rpm -E %_buildshell
/bin/sh

I'm not sure is it would be good to post full list of all spec files here ..

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

soname update - libqalculate

[Mukundan Ragavan]

libqalculate soname bump is happening with v3.0 (libqalculate.so.21).
The following packages are affected -

plasma-workspace
step
cantor
qalculate-kde

I will rebuild these packages and file bug reports if needed. I did not
build v2.9.x despite my earlier email.

Are there objections if I do this for F30 as well or is it too late?

Mukundan.





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

Fedora testing-20190321.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/2 (x86_64)

New failures (same test not failed in updates-20190320.0):

ID: 369602  Test: x86_64 AtomicHost-dvd_ostree-iso install_default
URL: https://openqa.fedoraproject.org/tests/369602

Passed openQA tests: 1/2 (x86_64)

Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso 
install_default@uefi: 
1 services(s) added since previous compose: systemd-modules-load.service
Previous test data: https://openqa.fedoraproject.org/tests/368450#downloads
Current test data: https://openqa.fedoraproject.org/tests/369601#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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30-20190321.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Failed openQA tests: 4/142 (x86_64), 1/2 (arm), 1/24 (i386)

ID: 369386  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/369386
ID: 369407  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/369407
ID: 369410  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/369410
ID: 369423  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/369423
ID: 369445  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/369445
ID: 369499  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/369499

Soft failed openQA tests: 15/142 (x86_64), 5/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 369343  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/369343
ID: 369344  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/369344
ID: 369345  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/369345
ID: 369346  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/369346
ID: 369356  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/369356
ID: 369370  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/369370
ID: 369371  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/369371
ID: 369382  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/369382
ID: 369389  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/369389
ID: 369390  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/369390
ID: 369394  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/369394
ID: 369422  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/369422
ID: 369471  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/369471
ID: 369472  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/369472
ID: 369473  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/369473
ID: 369474  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/369474
ID: 369483  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/369483
ID: 369484  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/369484
ID: 369494  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/369494
ID: 369495  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/369495

Passed openQA tests: 123/142 (x86_64), 18/24 (i386)

Skipped non-gating openQA tests: 1 of 168
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging Question - Open Liberty

[Michael Zhang]

Thanks for the clarification for my first question. 

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.com
 

 
 
 
- Original message -From: Peter Robinson To: Development discussions related to Fedora Cc:Subject: Re: Packaging Question - Open LibertyDate: Thu, Mar 21, 2019 3:05 PM 
 
On Thu, 21 Mar 2019, 18:50 Adam Williamson,  wrote:
On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote:> Hi>> From the previous email, it was stated that it's mandatory to include> the building of the Open Liberty binaries into the rpmbuild. We are> planning on doing that and making it publicly available through> Github. So does that mean that you guys at Fedora are going to> rebuild from source to publish, or do they just want to be sure that> would be possible?All binaries in Fedora packages must be compiled from source at packagebuild time. No pre-built binaries can be shipped.This is right in the guidelines:https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/"No inclusion of pre-built binaries or librariesAll program binaries and program libraries included in Fedora packagesmust be built from the source code that is included in the sourcepackage."
 
To clarify, that means built from source using Fedora build infrastructure, not built from the source somewhere else and then put in the rpm.
 
Please make sure the project as published is set up to be rebuilteasily, ideally using standard tools and conventions. Thanks.--Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___devel mailing list -- devel@lists.fedoraproject.orgTo unsubscribe send an email to devel-le...@lists.fedoraproject.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
 

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

Re: Packaging Question - Open Liberty

[Peter Robinson]

On Thu, 21 Mar 2019, 18:50 Adam Williamson, 
wrote:

> On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote:
> > Hi
> >
> > From the previous email, it was stated that it's mandatory to include
> > the building of the Open Liberty binaries into the rpmbuild. We are
> > planning on doing that and making it publicly available through
> > Github. So does that mean that you guys at Fedora are going to
> > rebuild from source to publish, or do they just want to be sure that
> > would be possible?
>
> All binaries in Fedora packages must be compiled from source at package
> build time. No pre-built binaries can be shipped.
>
> This is right in the guidelines:
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/
>
> "No inclusion of pre-built binaries or libraries
>
> All program binaries and program libraries included in Fedora packages
> must be built from the source code that is included in the source
> package."
>

To clarify, that means built from source using Fedora build infrastructure,
not built from the source somewhere else and then put in the rpm.

Please make sure the project as published is set up to be rebuilt
> easily, ideally using standard tools and conventions. Thanks.
> --
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 30 compose report: 20190321.n.0 changes

[Fedora Branched Report]

OLD: Fedora-30-20190316.n.1
NEW: Fedora-30-20190321.n.0

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

Size of added packages:  0 B
Size of dropped packages:6.00 MiB
Size of upgraded packages:   191.32 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -9.24 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-30-20190321.n.0-sda.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-30-20190321.n.0-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: eclipse-recommenders-2.5.4-3.fc30
Summary: Eclipse Code Recommenders
RPMs:eclipse-recommenders
Size:1.55 MiB

Package: latexila-3.26.1-6.fc30
Summary: Integrated LaTeX Environment for the GNOME desktop
RPMs:latexila latexila-doc
Size:4.45 MiB


= UPGRADED PACKAGES =
Package:  anaconda-30.25.3-4.fc30
Old package:  anaconda-30.25.3-3.fc30
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel
Size: 20.01 MiB
Size change:  8.99 KiB
Changelog:
  * Tue Mar 12 2019 Martin Kolman  - 30.25.3-4
  - Add a new type of the installation system for the initial setup (#1685992) 
(vponcova)


Package:  createrepo_c-0.12.2-1.fc30
Old package:  createrepo_c-0.12.1-1.fc30
Summary:  Creates a common metadata repository
RPMs: createrepo_c createrepo_c-devel createrepo_c-libs 
python3-createrepo_c
Size: 2.72 MiB
Size change:  7.42 KiB
Changelog:
  * Mon Mar 11 2019 Pavla Kratochvilova  - 0.12.2-1
  - Update to 0.12.2
  - mergerepo_c: check if nevra is NULL and warn user about src.rpm naming
  - Consistently produce valid URLs by prepending protocol. (RhBug:1632121)


Package:  dnf-4.2.1-1.fc30
Old package:  dnf-4.1.0-1.fc30
Summary:  Package manager
RPMs: dnf dnf-automatic dnf-data dnf-yum python3-dnf
Size: 978.27 KiB
Size change:  -1.81 KiB
Changelog:
  * Mon Mar 11 2019 Pavla Kratochvilova  - 4.2.1-1
  - Do not allow direct module switch (RhBug:1669491)
  - Use improved config parser that preserves order of data
  - Fix alias list command (RhBug:1666325)
  - Postpone yum conflict to F31
  - Update documentation: implemented plugins; options; deprecated commands 
(RhBug:1670835,1673278)
  - Support zchunk (".zck") compression
  - Fix behavior  of ``--bz`` option when specifying more values
  - Follow RPM security policy for package verification
  - Update modules regardless of installed profiles
  - Add protection of yum package (RhBug:1639363)
  - Fix ``list --showduplicates`` (RhBug:1655605)


Package:  dnf-plugins-core-4.0.6-1.fc30
Old package:  dnf-plugins-core-4.0.4-1.fc30
Summary:  Core Plugins for DNF
RPMs: dnf-plugins-core dnf-utils python3-dnf-plugin-leaves 
python3-dnf-plugin-local python3-dnf-plugin-show-leaves 
python3-dnf-plugin-versionlock python3-dnf-plugins-core
Size: 308.02 KiB
Size change:  7.13 KiB
Changelog:
  * Sat Feb 23 2019 Igor Gnatenko  - 4.0.4-2
  - Raise yum-utils conflict version

  * Mon Mar 11 2019 Pavla Kratochvilova  - 4.0.6-1
  - Update to 4.0.6
  - Use improved config parser that preserves order of data
  - [leaves] Show multiply satisfied dependencies as leaves
  - [download] Fix downloading an rpm from a URL (RhBug:1678582)
  - [download] Fix problem with downloading src pkgs (RhBug:1649627)


Package:  dnf-plugins-extras-4.0.4-1.fc30
Old package:  dnf-plugins-extras-4.0.2-1.fc30
Summary:  Extras Plugins for DNF
RPMs: python3-dnf-plugin-kickstart python3-dnf-plugin-rpmconf 
python3-dnf-plugin-snapper python3-dnf-plugin-system-upgrade 
python3-dnf-plugin-torproxy python3-dnf-plugin-tracer 
python3-dnf-plugins-extras-common
Size: 161.59 KiB
Size change:  3.05 KiB
Changelog:
  * Mon Mar 11 2019 Pavla Kratochvilova  - 4.0.4-1
  - Update to 4.0.4
  - Use improved config parser that preserves order of data
  - [system-upgrade] Save module_platform_id option through system upgrade 
(RhBug:1656509)
  - [system-upgrade] On modular systems, system upgrade requires the next 
module_platform_id


Package:  f30-backgrounds-30.0.0-2.fc30
Old package:  f30-backgrounds-30.0.0-1.fc30
Summary:  Fedora 30 default desktop background
RPMs: f30-backgrounds f30-backgrounds-base f30-backgrounds-extras-base 
f30-backgrounds-extras-gnome f30-backgrounds-extras-kde 
f30-backgrounds-extras-mate f30-backgrounds-extras-xfce f30-backgrounds-gnome 
f30-backgrounds-kde f30-backgrounds-mate f30-backgrounds-xfce
Size: 121.21 MiB
Size change:  1.25 KiB
Changelog:
  * Mon Mar 18 2019 Adam Williamson  - 30.0.0-2
  - Fix f30-backgrounds-kde to set the correct default the

Re: Packaging Question - Open Liberty

[Adam Williamson]

On Thu, 2019-03-21 at 17:25 +, Michael Zhang wrote:
> Hi
> 
> From the previous email, it was stated that it's mandatory to include
> the building of the Open Liberty binaries into the rpmbuild. We are
> planning on doing that and making it publicly available through
> Github. So does that mean that you guys at Fedora are going to
> rebuild from source to publish, or do they just want to be sure that
> would be possible?

All binaries in Fedora packages must be compiled from source at package
build time. No pre-built binaries can be shipped.

This is right in the guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/

"No inclusion of pre-built binaries or libraries

All program binaries and program libraries included in Fedora packages
must be built from the source code that is included in the source
package."

Please make sure the project as published is set up to be rebuilt
easily, ideally using standard tools and conventions. Thanks.
-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 30 Beta Go/No-Go decision is delayed 1 day

[Ben Cotton]

In the Fedora 30 Beta Go/No-Go meeting we decided to delay the
decision by 1 day. This will allow the creation of a new compose (in
progress) that fixes the one outstanding blocker bug. We determined
that the nature of this fix would not require the full test suite and
that delaying the decision by one day in anticipation of success was
preferable to a full week delay.

Please join us at 1700 UTC on Friday, 22 March in #fedora-meeting-1
for another Go/No-Go meeting:
https://apps.fedoraproject.org/calendar/Fedora%20release/2019/3/22/#m9493

As a reminder, we will be holding the Release Readiness meeting
shortly. It will be at 1900 UTC today in #fedora-meeting-1:
https://apps.fedoraproject.org/calendar/meeting/9492/?from_date=2019-03-18

-- 
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Packaging Question - Open Liberty

[Michael Zhang]

HiFrom the previous email, it was stated that it's mandatory to include the building of the Open Liberty binaries into the rpmbuild. We are planning on doing that and making it publicly available through Github. So does that mean that you guys at Fedora are going to rebuild from source to publish, or do they just want to be sure that would be possible?
 
We read in the guidelines that all jars and class files should go under %{_javadir}. We were initially thinking of symlinking all the jars and class files but due to our installation dir structure, it will be incredibly messy. Could we put the whole OpenLiberty install under /usr/share/java/openliberty? I ask because we have jars in locations other than lib and I think moving everything is going to be problematic to manage.
 

 
  Michael Zhang
   Software Developer Test (WAS Install Team)
 Phone: 1-9054133415
 E-mail: michael.zh...@ibm.com
 

 

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

Fedora rawhide compose report: 20190321.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190320.n.0
NEW: Fedora-Rawhide-20190321.n.0

= SUMMARY =
Added images:2
Dropped images:  1
Added packages:  4
Dropped packages:0
Upgraded packages:   113
Downgraded packages: 0

Size of added packages:  9.86 MiB
Size of dropped packages:0 B
Size of upgraded packages:   13.11 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -279.71 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20190321.n.0.s390x.tar.xz
Image: Workstation raw-xz aarch64
Path: 
Workstation/aarch64/images/Fedora-Workstation-Rawhide-20190321.n.0.aarch64.raw.xz

= DROPPED IMAGES =
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20190320.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: python-ipmi-0.4.1-2.fc31
Summary: Pure python IPMI library
RPMs:python3-ipmi
Size:196.71 KiB

Package: spausedd-20190320-1.fc31
Summary: Utility to detect and log scheduler pause
RPMs:spausedd
Size:110.44 KiB

Package: trellis-1.0-0.1.20190320git26d6667.fc31
Summary: Lattice ECP5 FPGA bitstream creation/analysis/programming tools
RPMs:trellis trellis-data trellis-devel
Size:9.48 MiB

Package: ursa-major-0.2.1-1.fc31
Summary: A utility for working with module's koji tags in koji's tag 
inheritance.
RPMs:ursa-major ursa-major-stage
Size:74.44 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CGAL-4.14-0.1beta2.fc31
Old package:  CGAL-4.13-3.fc30
Summary:  Computational Geometry Algorithms Library
RPMs: CGAL CGAL-demos-source CGAL-devel
Size: 131.49 MiB
Size change:  1.72 MiB

Package:  R-cli-1.1.0-1.fc31
Old package:  R-cli-1.0.1-1.fc31
Summary:  Helpers for Developing Command Line Interfaces
RPMs: R-cli
Size: 178.54 KiB
Size change:  -151.25 KiB
Changelog:
  * Wed Mar 20 2019 Elliott Sales de Andrade  - 
1.1.0-1
  - Update to latest version


Package:  R-gamlss.dist-5.1.3-1.fc31
Old package:  R-gamlss.dist-5.1.1-1.fc30
Summary:  Distributions for Generalized Additive Models for Location Scale 
and Shape
RPMs: R-gamlss.dist
Size: 19.26 MiB
Size change:  6.36 MiB
Changelog:
  * Wed Mar 20 2019 Elliott Sales de Andrade  - 
5.1.3-1
  - Update to latest version


Package:  R-git2r-0.25.2-1.fc31
Old package:  R-git2r-0.25.1-1.fc31
Summary:  Provides Access to Git Repositories
RPMs: R-git2r
Size: 2.56 MiB
Size change:  1.30 KiB
Changelog:
  * Wed Mar 20 2019 Elliott Sales de Andrade  - 
0.25.2-1
  - Update to latest version


Package:  R-highr-0.8-1.fc31
Old package:  R-highr-0.7-3.fc30
Summary:  Syntax Highlighting for R Source Code
RPMs: R-highr
Size: 51.06 KiB
Size change:  64 B
Changelog:
  * Wed Mar 20 2019 Elliott Sales de Andrade  - 0.8-1
  - Update to latest version
  - Enable documentation


Package:  R-pkgbuild-1.0.3-1.fc31
Old package:  R-pkgbuild-1.0.2-2.fc31
Summary:  Find Tools Needed to Build R Packages
RPMs: R-pkgbuild
Size: 131.79 KiB
Size change:  3.04 KiB
Changelog:
  * Wed Mar 20 2019 Elliott Sales de Andrade  - 
1.0.3-1
  - Update to latest version


Package:  arm-trusted-firmware-2.1-0.1.rc0.fc31
Old package:  arm-trusted-firmware-2.0-4.20190209.fc30
Summary:  ARM Trusted Firmware
RPMs: arm-trusted-firmware-armv8
Size: 124.89 KiB
Size change:  1.74 KiB
Changelog:
  * Sat Mar 16 2019 Pablo Greco   2.0-5.20190209
  - Support building in el7 with devtoolset-7

  * Wed Mar 20 2019 Peter Robinson  2.1-0.1-rc0
  - New 2.1 rc0 release


Package:  barman-2.7-1.fc31
Old package:  barman-2.5-3.fc30
Summary:  Backup and Recovery Manager for PostgreSQL
RPMs: barman
Size: 314.93 KiB
Size change:  21.35 KiB
Changelog:
  * Wed Mar 20 2019 Francisco Javier Tsao Sant??n  - 2.7-1
  - Update to 2.7 version


Package:  buildah-1.8-17.dev.git9d6da3a.fc31
Old package:  buildah-1.8-16.dev.git1ba9201.fc31
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 27.98 MiB
Size change:  536 B
Changelog:
  * Wed Mar 20 2019 Lokesh Mandvekar (Bot)  - 
1.8-17.dev.git9d6da3a
  - autobuilt 9d6da3a


Package:  clang-8.0.0-1.fc31
Old package:  clang-8.0.0-0.6.rc4.fc31
Summary:  A C language family front-end for LLVM
RPMs: clang clang-analyzer clang-devel clang-libs clang-tools-extra 
git-clang-format python3-clang
Size: 114.32 MiB
Size change:  -127.41 KiB
Changelog:
  * Wed Mar 20 2019 sguel...@redhat.com - 8.0.0-1
  - 8.0.0 final


Package:  compiler-rt-8.0.0-1.fc31
Old package:  compiler-rt-8.0.0-0.4.rc4.fc31
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 14.09 MiB
Size change:  1.50 KiB
Changelog:
  * Wed Mar 20 2019 sguel...@redhat.com - 8.0.0-1
  - 8

Re: sway SIG

[Fabio Alessandro Locati]

Thanks a lot for starting this proposal.

I'm interested in joining this SIG!

Cheers,
Fale
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Rawhide-20190321.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Atomichost qcow2 x86_64
Atomichost raw-xz x86_64

Compose FAILS proposed Rawhide gating check!
5 of 47 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 17/142 (x86_64), 3/24 (i386), 1/2 (arm)

ID: 369139  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/369139
ID: 369147  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/369147
ID: 369148  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/369148
ID: 369167  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/369167
ID: 369168  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/369168
ID: 369169  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/369169
ID: 369181  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/369181
ID: 369182  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/369182
ID: 369195  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/369195
ID: 369217  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/369217
ID: 369230  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/369230
ID: 369247  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/369247
ID: 369248  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/369248
ID: 369249  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/369249
ID: 369250  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/369250
ID: 369251  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/369251
ID: 369253  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/369253
ID: 369254  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/369254
ID: 369256  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/369256
ID: 369267  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/369267
ID: 369282  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/369282

Soft failed openQA tests: 13/142 (x86_64), 4/24 (i386)
(Tests completed, but using a workaround for a known bug)

ID: 369115  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/369115
ID: 369116  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/369116
ID: 369117  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/369117
ID: 369118  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/369118
ID: 369128  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/369128
ID: 369142  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/369142
ID: 369143  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/369143
ID: 369161  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/369161
ID: 369162  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/369162
ID: 369166  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/369166
ID: 369194  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/369194
ID: 369243  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/369243
ID: 369244  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/369244
ID: 369245  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/369245
ID: 369246  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/369246
ID: 369255  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/369255
ID: 369266  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/369266

Passed openQA tests: 92/142 (x86_64), 17/24 (i386)

Skipped gating openQA tests: 8/142 (x86_64)

ID: 369152  Test: x86_64 Workstation-live-iso base_update_c

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Tomasz Kłoczko]

On Thu, 21 Mar 2019 at 12:07, Jakub Jelinek  wrote:
[..]
> Like what exactly?  E.g. all the -Wformat-security warnings are about cases
> where the format strings are constructed shortly before they are passed to
> the format attribute functions, either unmodified or through gettext.

KISS principle ..
Maybe it is time to remove gettext support from gcc/binutils it is
really so hard to maintain?
Who needs this?
I'm not trying to give any answers on those questions but people like
you who are directly maintaining gcc should be able to balance between
some priorities like what is most important and what is only
decoration on the Christmas Tree.

People are writing the code with i18n support which compiles without
single warning. This is not a rocket science.
I can understand that it may be difficult for some people but not
everything needs to be done by single person. Isn't it?

Just try to execute "update-po" target in gcc/ and you will see that
only by this single command is possible to reduce gcc/po/ directory
content by ~2MB (which is about 5% and that is only in one directory
with translations) which says that for quite long time no one cares
that most of the translations are not up-to-date.
Maybe telling other people that if all compile time warnings related
to gettex will be not sorted out before final gcc 9 i18n support will
be dropped? Let's see how many people cares about that support (?).
Chess players sometimes says that in this game more dangerous than
chess mat is knowing that in next move you will be under pressure of
that state.

Every source code maintainer doesn't need to do everything and I'm not
asking you why all those problems are or sort out every even minor
issue.
At least such person needs take care of some problem management by
identify the problem and making aware of them people around, and
assigning priority to each point of the list problems.
It is really good to resent some statistics on each release.
Statistics about up-to-date i18n or number of stats about warnings are
only two I'm sure that you
Am I could be right or not?


Going back to main subject about default compile options. I have
question for you Jakub :)
Quote from redhat-rpm-config package buildflags.md:

* `-fexceptions`: Provide exception unwinding support for C programs.
  See the [`-fexceptions` option in the GCC
  
manual](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fexceptions)
  and the [`cleanup` variable
  
attribute](https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-cleanup-variable-attribute).
  This also hardens cancellation handling in C programs because
  it is not required to use an on-stack jump buffer to install
  a cancellation handler with `pthread_cleanup_push`.  It also makes
  it possible to unwind the stack (using C++ `throw` or Rust panics)
  from C callback functions if a C library supports non-local exits
  from them (e.g., via `longjmp`).

Is it still correct? If it is why that kind of issues are solved that
way? Someone maybe remember in which one project this caused some
issue?
Building all code with exceptions when many people spent many hours to
have code which does not uses exceptions is kind waste .. and still
compile many programs with exceptions only causes that executable code
is puffier. As you know even gcc is not compliant with above :)

What about use -fno-rtti if it is possible to use it?

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packit is released: Packaging as a Service

[Dusty Mabe]

On 3/21/19 9:40 AM, Tomas Tomecek wrote:
> We are pleased to announce the initial version of Packit.
> 
> Packit makes it easy to bring and integrate your upstream projects
> into Fedora, right now we are focused to bring upstream
> releases into Fedora rawhide. You can use packit now as a command-line
> tool, soon Packit will run as a hosted service (much like Travis CI)
> and run these tools automatically.
> 
> The project is hosted on Github and available in Fedora as "packit":
> * https://github.com/packit-service/packit
> 
> For more info please read two blog posts covering the upstream
> releases of packit:
> * 0.1.0 - https://github.com/packit-service/packit/blob/master/docs/01.md
> * 0.2.0 - https://github.com/packit-service/packit/blob/master/docs/02.md
> 
> There is also detailed documentation for workflows which packit covers:
> * https://github.com/packit-service/packit#workflows-covered-by-packit
> 
> This is just a beginning for the project and we are excited to receive
> your feedback.
> 
> Tomas, on behalf of the whole Packit team.

Nice work Tomas, team! I'm really excited to give this a spin. 

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

Packit is released: Packaging as a Service

[Tomas Tomecek]

We are pleased to announce the initial version of Packit.

Packit makes it easy to bring and integrate your upstream projects
into Fedora, right now we are focused to bring upstream
releases into Fedora rawhide. You can use packit now as a command-line
tool, soon Packit will run as a hosted service (much like Travis CI)
and run these tools automatically.

The project is hosted on Github and available in Fedora as "packit":
* https://github.com/packit-service/packit

For more info please read two blog posts covering the upstream
releases of packit:
* 0.1.0 - https://github.com/packit-service/packit/blob/master/docs/01.md
* 0.2.0 - https://github.com/packit-service/packit/blob/master/docs/02.md

There is also detailed documentation for workflows which packit covers:
* https://github.com/packit-service/packit#workflows-covered-by-packit

This is just a beginning for the project and we are excited to receive
your feedback.

Tomas, on behalf of the whole Packit team.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Jakub Jelinek]

On Thu, Mar 21, 2019 at 11:43:49AM +, Tomasz Kłoczko wrote:
> On Thu, 21 Mar 2019 at 11:37, Stephen John Smoogen  wrote:
> [..]
> > > Even gcc themselves "is not written with recent gcc in mind".
> > >
> > > $ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
> > > $1}'|sort | uniq -c | sort -nr| head -n 20
> > > 485 -Wmissing-profile
> > > 106 -Wformat-security
> > >  81 -Wmaybe-uninitialized
> > >  44 -Wimplicit-fallthrough=
> > >  24 -Wunused-function
> > >  20 -Wpointer-sign
> > >  20 -Wimplicit-function-declaration
> > >  19 -Wstringop-truncation
> > >   8 -Wformat-truncation=
> > >   8 -Wcast-qual
> > >   7 -Wcast-function-type
> > >   4 -Wcpp
> > >   4 -Wbuiltin-declaration-mismatch
> > >   3 -Wparentheses
> > >   2 -Wunused-value
> > >   2 -Wunused-parameter
> > >   2 -Wmissing-prototypes
> > >   2 -Wmisleading-indentation
> > >   2 -Wint-to-pointer-cast
> > >   2 -Wdiscarded-qualifiers
> > >
> > > BTW: each Fedora package build should have as part of the build report
> > > something like above.
> > >
> >
> > Could you explain why it should? I am not sure what those flags
> > actually mean and why it would tell me anything about a package build.
> > If upstream decides that libX needs to be compiled with
> > -Wmissing-prototypes but nothing else.. what is it to me?
> 
> That list is not in order of importance but how often some warning
> happened, and I think that you are fully aware that on that list are
> things far more important than missing prototype.

Like what exactly?  E.g. all the -Wformat-security warnings are about cases
where the format strings are constructed shortly before they are passed to
the format attribute functions, either unmodified or through gettext.
In no case any of that is from user provided strings.
I've tried several times to change that but it turned to be too ugly for no
real benefit.
-Wmissing-profile is just a matter of not 100% code coverage during
bootstrap when using FDO, not a bug.  What else?

GCC carefully uses -Werror with some -Wno- options in some parts of the
bootstrap on some parts of the codebases and not others for various reasons.

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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Stephan Bergmann]

On 21/03/2019 09:59, Zbigniew Jędrzejewski-Szmek wrote:

"-fstack-protector-strong" is the only one that has a clearly
beneficial effect.

But then there's the overall counterargument from Jakub that we start
deviating from upstream defaults and some users will need to add counter-options
to go back to the compiler defaults. I feel like the possible benefits
from enabling "-fstack-protector-strong" are not big enough to justify
the change. For serious hardening, one would enable way more flags,
and just turning on one or two is enough for the downsides to kick in, but
not enough to have serious benefits.


...and if any of the suggested changes to default options are deemed to 
be of value to users of Fedora, wouldn't they also be of value to users 
of upstream GCC, and should be implemented there?


(I share the sentiment that deviating defaults in distros are a pain for 
users.  It already bites me often enough when a distro unhelpfully 
sneaks in ccache behind my back, let alone something like adding -O.)

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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Stephen John Smoogen]

On Thu, 21 Mar 2019 at 07:53, Stephen John Smoogen  wrote:
>

>
> When people see lists like this they are going to assume it is order
> of importance because if X is used N many more times, it must be much
> more important than Y. Most packagers are not because most packages

wow.. I need a better editor (and probably author).

Most packagers are not aware of the importance of flags because most
packages are just things they put up with for the thing they really
want to get done.

[Which is an ugly run-on sentence and probably in the passive voice
and a bunch of other things.]


> are just things they do so they can get what they really want done.
> That may be a sad state to some, but the majority of packages in
> Fedora are the commons on which the cattle (packages people do things
> with) graze on. If I am a perl/python/erlang/nodejs/ghc/R packager and
> I get a report that something down in my stack has 2
> -Wmisleading-indentations and 485 -Wmissing-profiles.. I am going to
> assume that the upstream wanted it that way since all I did was copy
> this spec file from another one and use the defaults. If I get
> something with the tool I actually am familiar with
> (perl/python/erlang/etc) I might be better atuned to knowing that flag
> X or dependency Y is important.. but in the end I might really just
> want emacs-nethack.el to be a package and I won't have a clue if any
> of the above was important. So we need to make sure it is clear when
> we add something to a report why it is important.
>
>
> > kloczek
> > --
> > Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
>
>
> --
> Stephen J Smoogen.



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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Stephen John Smoogen]

On Thu, 21 Mar 2019 at 07:46, Tomasz Kłoczko  wrote:
>
> On Thu, 21 Mar 2019 at 11:37, Stephen John Smoogen  wrote:
> [..]
> > > Even gcc themselves "is not written with recent gcc in mind".
> > >
> > > $ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
> > > $1}'|sort | uniq -c | sort -nr| head -n 20
> > > 485 -Wmissing-profile
> > > 106 -Wformat-security
> > >  81 -Wmaybe-uninitialized
> > >  44 -Wimplicit-fallthrough=
> > >  24 -Wunused-function
> > >  20 -Wpointer-sign
> > >  20 -Wimplicit-function-declaration
> > >  19 -Wstringop-truncation
> > >   8 -Wformat-truncation=
> > >   8 -Wcast-qual
> > >   7 -Wcast-function-type
> > >   4 -Wcpp
> > >   4 -Wbuiltin-declaration-mismatch
> > >   3 -Wparentheses
> > >   2 -Wunused-value
> > >   2 -Wunused-parameter
> > >   2 -Wmissing-prototypes
> > >   2 -Wmisleading-indentation
> > >   2 -Wint-to-pointer-cast
> > >   2 -Wdiscarded-qualifiers
> > >
> > > BTW: each Fedora package build should have as part of the build report
> > > something like above.
> > >
> >
> > Could you explain why it should? I am not sure what those flags
> > actually mean and why it would tell me anything about a package build.
> > If upstream decides that libX needs to be compiled with
> > -Wmissing-prototypes but nothing else.. what is it to me?
>
> That list is not in order of importance but how often some warning
> happened, and I think that you are fully aware that on that list are
> things far more important than missing prototype.
>


When people see lists like this they are going to assume it is order
of importance because if X is used N many more times, it must be much
more important than Y. Most packagers are not because most packages
are just things they do so they can get what they really want done.
That may be a sad state to some, but the majority of packages in
Fedora are the commons on which the cattle (packages people do things
with) graze on. If I am a perl/python/erlang/nodejs/ghc/R packager and
I get a report that something down in my stack has 2
-Wmisleading-indentations and 485 -Wmissing-profiles.. I am going to
assume that the upstream wanted it that way since all I did was copy
this spec file from another one and use the defaults. If I get
something with the tool I actually am familiar with
(perl/python/erlang/etc) I might be better atuned to knowing that flag
X or dependency Y is important.. but in the end I might really just
want emacs-nethack.el to be a package and I won't have a clue if any
of the above was important. So we need to make sure it is clear when
we add something to a report why it is important.


> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Tomasz Kłoczko]

On Thu, 21 Mar 2019 at 11:37, Stephen John Smoogen  wrote:
[..]
> > Even gcc themselves "is not written with recent gcc in mind".
> >
> > $ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
> > $1}'|sort | uniq -c | sort -nr| head -n 20
> > 485 -Wmissing-profile
> > 106 -Wformat-security
> >  81 -Wmaybe-uninitialized
> >  44 -Wimplicit-fallthrough=
> >  24 -Wunused-function
> >  20 -Wpointer-sign
> >  20 -Wimplicit-function-declaration
> >  19 -Wstringop-truncation
> >   8 -Wformat-truncation=
> >   8 -Wcast-qual
> >   7 -Wcast-function-type
> >   4 -Wcpp
> >   4 -Wbuiltin-declaration-mismatch
> >   3 -Wparentheses
> >   2 -Wunused-value
> >   2 -Wunused-parameter
> >   2 -Wmissing-prototypes
> >   2 -Wmisleading-indentation
> >   2 -Wint-to-pointer-cast
> >   2 -Wdiscarded-qualifiers
> >
> > BTW: each Fedora package build should have as part of the build report
> > something like above.
> >
>
> Could you explain why it should? I am not sure what those flags
> actually mean and why it would tell me anything about a package build.
> If upstream decides that libX needs to be compiled with
> -Wmissing-prototypes but nothing else.. what is it to me?

That list is not in order of importance but how often some warning
happened, and I think that you are fully aware that on that list are
things far more important than missing prototype.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Stephen John Smoogen]

On Thu, 21 Mar 2019 at 07:23, Tomasz Kłoczko  wrote:
>
> On Thu, 21 Mar 2019 at 09:07, Zbigniew Jędrzejewski-Szmek
>  wrote:
> [..]
> > The effect of "-Wformat -Wformat-security" without -Werror is only more 
> > warnings.
> > Unfortunately -Wformat will generate spurious warnings if the code is
> > not careful to give additional information to the compiler with
> > __attribute__((__format__(printf))) and friends. And even that sometimes
> > not enough, and explicit #pragma GCC diagnostic ignored 
> > "-Wformat-nonliteral"
> > is needed. So all in all, it is totally expected that code which is not
> > written with recent gcc in mind will generate spurious format warnings, even
> > if the code is completely OK. So turning this on will make builds more
> > noisy, and possibly break projects which use -Werror.
>
> Even gcc themselves "is not written with recent gcc in mind".
>
> $ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
> $1}'|sort | uniq -c | sort -nr| head -n 20
> 485 -Wmissing-profile
> 106 -Wformat-security
>  81 -Wmaybe-uninitialized
>  44 -Wimplicit-fallthrough=
>  24 -Wunused-function
>  20 -Wpointer-sign
>  20 -Wimplicit-function-declaration
>  19 -Wstringop-truncation
>   8 -Wformat-truncation=
>   8 -Wcast-qual
>   7 -Wcast-function-type
>   4 -Wcpp
>   4 -Wbuiltin-declaration-mismatch
>   3 -Wparentheses
>   2 -Wunused-value
>   2 -Wunused-parameter
>   2 -Wmissing-prototypes
>   2 -Wmisleading-indentation
>   2 -Wint-to-pointer-cast
>   2 -Wdiscarded-qualifiers
>
> BTW: each Fedora package build should have as part of the build report
> something like above.
>

Could you explain why it should? I am not sure what those flags
actually mean and why it would tell me anything about a package build.
If upstream decides that libX needs to be compiled with
-Wmissing-prototypes but nothing else.. what is it to me?


> kloczek
> --
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Tomasz Kłoczko]

On Thu, 21 Mar 2019 at 09:07, Zbigniew Jędrzejewski-Szmek
 wrote:
[..]
> The effect of "-Wformat -Wformat-security" without -Werror is only more 
> warnings.
> Unfortunately -Wformat will generate spurious warnings if the code is
> not careful to give additional information to the compiler with
> __attribute__((__format__(printf))) and friends. And even that sometimes
> not enough, and explicit #pragma GCC diagnostic ignored "-Wformat-nonliteral"
> is needed. So all in all, it is totally expected that code which is not
> written with recent gcc in mind will generate spurious format warnings, even
> if the code is completely OK. So turning this on will make builds more
> noisy, and possibly break projects which use -Werror.

Even gcc themselves "is not written with recent gcc in mind".

$ grep '\[\-W' gcc.log| awk -F\[ '{print $2}'|awk -F\] '{print
$1}'|sort | uniq -c | sort -nr| head -n 20
485 -Wmissing-profile
106 -Wformat-security
 81 -Wmaybe-uninitialized
 44 -Wimplicit-fallthrough=
 24 -Wunused-function
 20 -Wpointer-sign
 20 -Wimplicit-function-declaration
 19 -Wstringop-truncation
  8 -Wformat-truncation=
  8 -Wcast-qual
  7 -Wcast-function-type
  4 -Wcpp
  4 -Wbuiltin-declaration-mismatch
  3 -Wparentheses
  2 -Wunused-value
  2 -Wunused-parameter
  2 -Wmissing-prototypes
  2 -Wmisleading-indentation
  2 -Wint-to-pointer-cast
  2 -Wdiscarded-qualifiers

BTW: each Fedora package build should have as part of the build report
something like above.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 20, 2019 at 09:52:02AM +0530, Huzaifa Sidhpurwala wrote:
> On 3/15/19 9:49 PM, Richard W.M. Jones wrote:
> > On Fri, Mar 15, 2019 at 04:15:58PM +, Richard W.M. Jones wrote:
> >> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote:
> >>> https://fedoraproject.org/wiki/Changes/HardenedCompiler
> >>
> >> I'm not opposing this, but is it possible we could do this without
> >> breaking clang at the same time?
> >>
> >> In the past (and currently) the Fedora compiler flags need some hairy
> >> editing so they work with clang, eg:
> >>
> >> https://src.fedoraproject.org/rpms/american-fuzzy-lop/blob/master/f/american-fuzzy-lop.spec#_110
> >>
> >> (Actually this is not the latest iteration - latest clang 7 and gcc 9
> >> and Fedora 30+ needs even more editing, but I didn't push it yet since
> >> there are other issues with this package.)
> >>
> >> It would be nice if there was a way we could avoid this.
> > 
> > So after rereading the proposal more carefully it seems as if the
> > proposal is to change the defaults in GCC so no flags would need to be
> > specified.  Would we consequently remove those flags from the command
> > line (which would solve my problem above)?
> 
> The flags in my proposal will be removed from the command line during
> the Fedora build process, since they are now default. Only people who
> dont want to use these flags due to some reason will need to unset them
> (I am assuming there are not a lot of packages like that)
> 
> Currently based on Jakub's suggestion i am also planning to remove to
> fortify_source flag and keep others.
> 
> The plan is to start some where and each release work with glibc and
> other teams so that we make more such security flags as default and also
> work with packages which break due to inclusion of such flags.


The original proposal had:
-Wformat -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 
-D_FORTIFY_SOURCE=2 -O

IIUC, the proposal now would be:
-Wformat -Wformat-security -fstack-protector-strong -O

As was stated multiple times in this thread, this change does not
apply to *packages* which follow the packaging guidelines, because various
flags are already set in %{optflags}. This change would only affect
mispackaged packages and locally compiled programs.

The effect of "-Wformat -Wformat-security" without -Werror is only more 
warnings.
Unfortunately -Wformat will generate spurious warnings if the code is
not careful to give additional information to the compiler with
__attribute__((__format__(printf))) and friends. And even that sometimes
not enough, and explicit #pragma GCC diagnostic ignored "-Wformat-nonliteral"
is needed. So all in all, it is totally expected that code which is not
written with recent gcc in mind will generate spurious format warnings, even
if the code is completely OK. So turning this on will make builds more
noisy, and possibly break projects which use -Werror.

The effect of "-O" is not nice, because it's often useful to compile without
any optimization whatsoever for debugging, so that the binary code
corresponds as closely as possible to the source. I'm sure people will
not know that '-O' has been made the default and will be confused.

"-fstack-protector-strong" is the only one that has a clearly
beneficial effect.

But then there's the overall counterargument from Jakub that we start
deviating from upstream defaults and some users will need to add counter-options
to go back to the compiler defaults. I feel like the possible benefits
from enabling "-fstack-protector-strong" are not big enough to justify
the change. For serious hardening, one would enable way more flags,
and just turning on one or two is enough for the downsides to kick in, but
not enough to have serious benefits.

I think that instead of playing with compiler defaults like this, it
would be more productive to investigate *packaged* software and to
check if it really follows the packaging guidelines and is hardened
effectively. With annobin enabled, it should be possible to do this
programatically.

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