Re: Dropping -devel subpackage

2019-08-04 Thread Iñaki Ucar 
On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
>
> > So the question is: should I add "Obsoletes: pkg-devel < $new_version"
> > to pkg's SPEC? Is this a proper use of "Obsoletes"?
>
> Yes. Exactly a right thing to do.

Thanks, Miro. Then, I suggest to add this particular case to the
documentation. Not sure where though, but FWIW, my first search was
"drop subpackage" and *not* the "Obsoletes" subsection.

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

Re: Dropping -devel subpackage

2019-08-04 Thread Rex Dieter 
Iñaki Ucar wrote:

> On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
>>
>> > So the question is: should I add "Obsoletes: pkg-devel < $new_version"
>> > to pkg's SPEC? Is this a proper use of "Obsoletes"?
>>
>> Yes. Exactly a right thing to do.
> 
> Thanks, Miro. Then, I suggest to add this particular case to the
> documentation. Not sure where though, but FWIW, my first search was
> "drop subpackage" and *not* the "Obsoletes" subsection.

That case should already be covered by the "replace" part of:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

-- Rex

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

Re: Untag a build?

2019-08-04 Thread Kevin Kofler 
Kevin Fenzi wrote:
> If the build has gone out in a rawhide compose, you need to just push
> out a fixed build. That could be something to fix it, or adding an Epoch
> and downgrading back to a previous version.
> 
> If it's not yet gone out in a compose, you can file a releng ticket to
> have someone untag it, or you can tag the previous version into
> f31-updates-candidate and it will get pushed out instead. ie:
> 
> koji tag-pkg f31-updates-candidate 
> 
> But you should only do that if it's not gone out in a compose.
> In this case it looks like that build has gone out. ;(

Can this policy finally get reconsidered? "dnf distro-sync" (and "yum 
distro-sync" before it) has been available for years now. Is it really worth 
introducing an Epoch that we will then be stuck with forever, also in 
releases, just so that Rawhide users can upgrade with "dnf upgrade" rather 
than "dnf distro-sync"?

I absolutely see the necessity of ensuring upgrade paths from release to 
release, and even from release to Rawhide (because it ensures that the 
upgrade path will work when Rawhide becomes a release), but from Rawhide to 
Rawhide, just WHY?

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

Re: Join the new Minimization Team

2019-08-04 Thread Adam Samalik 
On Sat, Aug 3, 2019 at 11:24 PM Clement Verna 
wrote:

> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > > I've already done some experiments with that. I used multi-stage builds
> > > with podman, but it's the same in principle. And yes, the sizes are
> > > smaller. What was interesting though that some additional packages
> (ones
> > > that wouldn't appear in the images using the Fedora base image) has
> been
> > > dragged in as dependencies. Some of them are even related to hardware.
> (See
> > > the report [1] and the github repo [2].)
> >
> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> > anymore.
> >
> > A lot of the stuff in those images seems completely unnecessary:
> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> > grubby, systemd-bootchart, systemd-udev.
> >
> > > So that might be one area to focus on — to make sure that these "from
> > > scratch" installations don't drag unnecessary stuff.
> >
> > Yep, that sounds like a good start. I suspect that F30 might be already
> > better in this regard.
>
> Yes quite a bit has happened on the base image since F29, we have
> removed quite a few things and trimmed down the latest rawhide to
> 208MB. I am sure that can still be improved and I welcome any help on
> that :-).
>

I've regenerated it for f30 and f31:
https://asamalik.fedorapeople.org/container-randomness/report.html

I see the fedora:f31 image is 195 MB, woot!


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


-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20190804.n.0 compose check report

2019-08-04 Thread Fedora compose checker 
No missing expected images.

Compose FAILS proposed Rawhide gating check!
13 of 45 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 38/147 (x86_64), 1/2 (arm)

Old failures (same test failed in Fedora-Rawhide-20190802.n.1):

ID: 429014  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/429014
ID: 429020  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/429020
ID: 429025  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/429025
ID: 429026  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429026
ID: 429028  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/429028
ID: 429029  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/429029
ID: 429030  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/429030
ID: 429031  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/429031
ID: 429032  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/429032
ID: 429033  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/429033
ID: 429034  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429034
ID: 429035  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/429035
ID: 429036  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/429036
ID: 429037  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/429037
ID: 429039  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/429039
ID: 429044  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429044
ID: 429045  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429045
ID: 429054  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429054
ID: 429057  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/429057
ID: 429060  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/429060
ID: 429061  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/429061
ID: 429062  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/429062
ID: 429063  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/429063
ID: 429072  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/429072
ID: 429075  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/429075
ID: 429077  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/429077
ID: 429078  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/429078
ID: 429139  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429139
ID: 429140  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/429140
ID: 429141  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/429141
ID: 429142  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429142
ID: 429145  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/429145
ID: 429146  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/429146
ID: 429147  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/429147
ID: 429149  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/429149
ID: 429150  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/429150
ID: 429151  Test: x86_64 universal install_cyrillic_language
URL:

Re: How do I remove GLIBCXX_ASSERTIONS?

2019-08-04 Thread Sam Varshavchik 

Georg Sauthoff writes:


> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
>
> std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
>
> But that still tripped the assertion when the foo vector was empty, so I  
had

> wrap this inside an if().

But why don't you use the idiomatic

copy(foo.begin(), foo.end(), back_inserter(bar));

?

No need to wrap it into an extra if statement.


I'm well aware of the alternatives. That's not the point.

The point is that there's nothing wrong with this specific form of existing  
code that now throws exceptions when the hardened build gets turned on.  
There is no buffer overruns, and nothing to exploit.


IIRC, the hardened build did find one real bug in the upstream package that  
was the original subject matter here, but all of the rest were these kinds  
of false positives. Now you have a situation when the existing code is known  
to be working, but needs changing in order to use a hardened build. There's  
some level of risk of regression in any change, and that gets weighed  
against the benefits of having a hardened build.


The above was just a basic example of this. It is not true that exceptions  
from hardened code are always evidence of potentially exploitable problem.  
Sometimes/most of the time, but sometimes they are false positives.





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

Re: Join the new Minimization Team

2019-08-04 Thread Christian Glombek 
Whoop this is great!
But I wonder why the scratch build sizes have gone up this dramatically in
f31?



On Sun, Aug 4, 2019 at 10:59 AM Adam Samalik  wrote:

>
>
> On Sat, Aug 3, 2019 at 11:24 PM Clement Verna 
> wrote:
>
>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage
>> builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages
>> (ones
>> > > that wouldn't appear in the images using the Fedora base image) has
>> been
>> > > dragged in as dependencies. Some of them are even related to
>> hardware. (See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>>
>
> I've regenerated it for f30 and f31:
> https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!
>
>
>>
>> >
>> > Zbyszek
>> >
>> >
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> > Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> > List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

New graphical dependency visualiser prototype

2019-08-04 Thread Adam Samalik 
I wrote a script to visualise dependencies of RPM installations [1]. It
supports file paths and container images as an input.

The script generates a graph of packages and their relations including
sizes of all individual packages and some basic clustering. Clicking on a
package highlights its relations to other packages. [2]

Hopefully this will be useful for the Minimization objective [3].

[1] https://pagure.io/minimization/dependency-visualiser
[2] https://asamalik.fedorapeople.org/showme/fedora-base-image.svg
[3] https://docs.fedoraproject.org/en-US/minimization/

-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20190804.n.0 changes

2019-08-04 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20190802.n.1
NEW: Fedora-Rawhide-20190804.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  9
Dropped packages:3
Upgraded packages:   100
Downgraded packages: 1

Size of added packages:  13.15 MiB
Size of dropped packages:387.70 KiB
Size of upgraded packages:   3.85 GiB
Size of downgraded packages: 622.68 KiB

Size change of upgraded packages:   -8.11 MiB
Size change of downgraded packages: -43.27 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: golang-github-andybalholm-brotli-0-0.1.20190803gited0fd64.fc31
Summary: Pure Go Brotli encoder and decoder
RPMs:golang-github-andybalholm-brotli-devel
Size:326.54 KiB

Package: golang-github-armon-socks5-0-0.1.20190803gite753329.fc31
Summary: SOCKS5 server in Golang
RPMs:golang-github-armon-socks5-devel
Size:17.90 KiB

Package: golang-github-pierrec-cmdflag-0.0.2-1.fc31
Summary: Augment the flag package with commands
RPMs:golang-github-pierrec-cmdflag-devel
Size:18.80 KiB

Package: golang-github-weppos-publicsuffix-0.5.0-1.fc31
Summary: Domain name parser for Go based on the Public Suffix List
RPMs:golang-github-weppos-publicsuffix-devel
Size:58.39 KiB

Package: golang-github-xo-dburl-0-0.1.20190803git98997a0.fc31
Summary: URL style mechanism for parsing and opening SQL database connection 
strings
RPMs:golang-github-xo-dburl-devel
Size:23.15 KiB

Package: golang-x-mod-0.1.0-1.fc31
Summary: Go module mechanics libraries
RPMs:golang-x-mod golang-x-mod-devel
Size:12.14 MiB

Package: ocproxy-1.60-1.20190728gitc98f06d.fc31
Summary: OpenConnect Proxy
RPMs:ocproxy
Size:486.30 KiB

Package: rust-getrandom-0.1.7-1.fc31
Summary: Small cross-platform library for retrieving random data from system 
source
RPMs:rust-getrandom+default-devel rust-getrandom+log-devel 
rust-getrandom+std-devel rust-getrandom-devel
Size:52.72 KiB

Package: rust-ppv-lite86-0.2.5-1.fc31
Summary: Implementation of the crypto-simd API for x86
RPMs:rust-ppv-lite86+default-devel rust-ppv-lite86+simd-devel 
rust-ppv-lite86+std-devel rust-ppv-lite86-devel
Size:47.46 KiB


= DROPPED PACKAGES =
Package: Spawning-0.9.7-8.fc31
Summary: A HTTP server for hosting WSGI python web applications
RPMs:Spawning
Size:67.16 KiB

Package: kredentials-2.0-0.19.pre3.fc30
Summary: KDE system tray kerberos ticket monitor
RPMs:kredentials
Size:305.94 KiB

Package: nodejs-grunt-contrib-copy-1.0.0-4.fc29
Summary: Copy files and folders
RPMs:nodejs-grunt-contrib-copy
Size:14.60 KiB


= UPGRADED PACKAGES =
Package:  R-xtable-1.8.4-1.fc31
Old package:  R-xtable-1.7.1-4.fc21
Summary:  Export tables to LaTeX or HTML
RPMs: R-xtable
Size: 692.97 KiB
Size change:  309.98 KiB
Changelog:
  * Wed Feb 07 2018 Fedora Release Engineering  - 
1.7.3-6
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild

  * Tue Jul 10 2018 Pierre-Yves Chibon  - 1.8.2-1
  - Update to 1.8.2

  * Thu Jul 12 2018 Fedora Release Engineering  - 
1.8.2-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild

  * Thu Jan 31 2019 Fedora Release Engineering  - 
1.8.2-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild

  * Wed Jul 24 2019 Fedora Release Engineering  - 
1.8.2-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sun Aug 04 2019 Filipe Rosset  - 1.8.4-1
  - Update to 1.8.4 fixes rhbz#1603314 rhbz#1674616 rhbz#1734912 and 
rhbz#1735432
  - ChangeLog https://cran.r-project.org/web/packages/xtable/NEWS


Package:  ams-2.1.2-4.fc31
Old package:  ams-2.1.2-3.fc31
Summary:  Alsa Modular Synth, a realtime modular synthesizer
RPMs: ams
Size: 2.60 MiB
Size change:  1.08 KiB
Changelog:
  * Sat Aug 03 2019 Guido Aulisi  - 2.1.2-4
  - Use zita-alsa-pcmi instead of deprecated clalsadrv


Package:  cacti-1.2.5-3.fc31
Old package:  cacti-1.2.5-2.fc31
Summary:  An rrd based graphing tool
RPMs: cacti
Size: 18.76 MiB
Size change:  -1.35 KiB
Changelog:
  * Sat Aug 03 2019 Morten Stevens  - 1.2.5-3
  - Require mariadb instead of mysql


Package:  cacti-spine-1.2.5-3.fc31
Old package:  cacti-spine-1.2.5-2.fc31
Summary:  Threaded poller for Cacti written in C
RPMs: cacti-spine
Size: 474.96 KiB
Size change:  510 B
Changelog:
  * Sat Aug 03 2019 Morten Stevens  - 1.2.5-3
  - Fix building on RHEL8


Package:  cjdns-20.3-5.fc31
Old package:  cjdns-20.3-2.fc31
Summary:  The privacy-friendly network without borders
RPMs: cjdns cjdns-graph cjdns-selinux cjdns-tools python2-cjdns
Size: 3.24 MiB
Size change:  116.91 KiB
Changelog:
  * Thu May 09 2019 Stuart Gathman  - 20.3-3
  - Move running test suite to check

  * Wed Jul 24 2019 Fedora Release Engineering  - 
20.3-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sat Aug 03 2019

Re: Join the new Minimization Team

2019-08-04 Thread Peter Robinson 
>> On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> >
>> > On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
>> > > I've already done some experiments with that. I used multi-stage builds
>> > > with podman, but it's the same in principle. And yes, the sizes are
>> > > smaller. What was interesting though that some additional packages (ones
>> > > that wouldn't appear in the images using the Fedora base image) has been
>> > > dragged in as dependencies. Some of them are even related to hardware. 
>> > > (See
>> > > the report [1] and the github repo [2].)
>> >
>> > It'd be nice to rebase this to F30 or even F31. F29 is not interesting
>> > anymore.
>> >
>> > A lot of the stuff in those images seems completely unnecessary:
>> > device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
>> > grubby, systemd-bootchart, systemd-udev.
>> >
>> > > So that might be one area to focus on — to make sure that these "from
>> > > scratch" installations don't drag unnecessary stuff.
>> >
>> > Yep, that sounds like a good start. I suspect that F30 might be already
>> > better in this regard.
>>
>> Yes quite a bit has happened on the base image since F29, we have
>> removed quite a few things and trimmed down the latest rawhide to
>> 208MB. I am sure that can still be improved and I welcome any help on
>> that :-).
>
>
> I've regenerated it for f30 and f31: 
> https://asamalik.fedorapeople.org/container-randomness/report.html
>
> I see the fedora:f31 image is 195 MB, woot!

Is there a plan to add some form of CI to monitor this? It would make
it easy to monitor ups/downs over time and pick up mistakes that bloat
deps by accident.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Dropping -devel subpackage

2019-08-04 Thread Nico Kadel-Garcia 
On Sun, Aug 4, 2019 at 2:36 PM Iñaki Ucar  wrote:
>
> On Sun, 4 Aug 2019 at 15:01, Rex Dieter  wrote:
> >
> > Iñaki Ucar wrote:
> >
> > > On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
> > >>
> > >> > So the question is: should I add "Obsoletes: pkg-devel < $new_version"
> > >> > to pkg's SPEC? Is this a proper use of "Obsoletes"?
> > >>
> > >> Yes. Exactly a right thing to do.
> > >
> > > Thanks, Miro. Then, I suggest to add this particular case to the
> > > documentation. Not sure where though, but FWIW, my first search was
> > > "drop subpackage" and *not* the "Obsoletes" subsection.
> >
> > That case should already be covered by the "replace" part of:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
>
> That's not clear to me. I read that in the first place, and I didn't
> identify this case either as a rename nor a replacement. A replacement
> is like bar that obsoletes foo. But here we have foo and
> foo-something, and at some point the latter is dropped (and not
> provided in foo).
>
> Iñaki

I'm running into just this sort of issue this with python2 modules and
Samba libraries, such as libldb, libtevent, libtalloc, and libtdb for
Samba 4.11rc1 The necessary modern visions of all of those libraries
are no longer copatible with python2. Compiling them for Fedora 30 and
RHEL 7 means that the old python2 modules are still present for
dependencies in mock, and hilarity ensues, *unless* the python3
modules are configured to "Obsolete" the python2  modules.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Dropping -devel subpackage

2019-08-04 Thread Iñaki Ucar 
On Sun, 4 Aug 2019 at 15:01, Rex Dieter  wrote:
>
> Iñaki Ucar wrote:
>
> > On Sun, 4 Aug 2019 at 01:21, Miro Hrončok  wrote:
> >>
> >> > So the question is: should I add "Obsoletes: pkg-devel < $new_version"
> >> > to pkg's SPEC? Is this a proper use of "Obsoletes"?
> >>
> >> Yes. Exactly a right thing to do.
> >
> > Thanks, Miro. Then, I suggest to add this particular case to the
> > documentation. Not sure where though, but FWIW, my first search was
> > "drop subpackage" and *not* the "Obsoletes" subsection.
>
> That case should already be covered by the "replace" part of:
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages

That's not clear to me. I read that in the first place, and I didn't
identify this case either as a rename nor a replacement. A replacement
is like bar that obsoletes foo. But here we have foo and
foo-something, and at some point the latter is dropped (and not
provided in foo).

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

Re: New graphical dependency visualiser prototype

2019-08-04 Thread Igor Gnatenko 
How does it deal with rich dependencies? Does it take conflicts into the
account? What about multiple provides which satisfy dependency?

On Sun, Aug 4, 2019, 19:41 Adam Samalik  wrote:

> I wrote a script to visualise dependencies of RPM installations [1]. It
> supports file paths and container images as an input.
>
> The script generates a graph of packages and their relations including
> sizes of all individual packages and some basic clustering. Clicking on a
> package highlights its relations to other packages. [2]
>
> Hopefully this will be useful for the Minimization objective [3].
>
> [1] https://pagure.io/minimization/dependency-visualiser
> [2] https://asamalik.fedorapeople.org/showme/fedora-base-image.svg
> [3] https://docs.fedoraproject.org/en-US/minimization/
>
> --
>
> Adam Šamalík
> ---
> Senior Software Engineer
> Red Hat
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning some packages

2019-08-04 Thread Pierre-Yves Chibon 
On Sat, Aug 03, 2019 at 06:52:55PM +, Gwyn Ciesla via devel wrote:
>I'll take the python packagesand igraph.

igraph and python-igraph are yours, thanks! :)

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

Re: How do I remove GLIBCXX_ASSERTIONS?

2019-08-04 Thread Iñaki Ucar 
On Sun, 4 Aug 2019 at 16:21, Sam Varshavchik  wrote:
>
> I'm well aware of the alternatives. That's not the point.
>
> The point is that there's nothing wrong with this specific form of existing
> code that now throws exceptions when the hardened build gets turned on.
> There is no buffer overruns, and nothing to exploit.
>
> IIRC, the hardened build did find one real bug in the upstream package that
> was the original subject matter here, but all of the rest were these kinds
> of false positives. Now you have a situation when the existing code is known
> to be working, but needs changing in order to use a hardened build. There's
> some level of risk of regression in any change, and that gets weighed
> against the benefits of having a hardened build.
>
> The above was just a basic example of this. It is not true that exceptions
> from hardened code are always evidence of potentially exploitable problem.
> Sometimes/most of the time, but sometimes they are false positives.

Georg's point (please, correct me if I'm wrong) is: how many false
positives are there (I'd say, very few) and how many of them leave us
with no reasonable (and even more idiomatic, as in your basic example)
options (I'd say, very very few to none) compared to the protection
these assertions provide with a very small performance cost?

I do think that there's something wrong with unnecessarily complex and
non-idiomatic constructs when there are reasonable, fast, idiomatic
alternatives, even if the code throws no exceptions and is technically
correct. I do think there's something wrong if you need to navigate
various C++ standards to understand the container implementation at a
low level to be sure that memory is contiguous and the code is doing
the correct thing.

But anyway, this turned into an off-topic. This flag is not an issue
for KiCad, and it wasn't a false positive. The issue was a critical
bug uncovered thanks to this flag.

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

Re: Rolling out Phase I of rawhide package gating

2019-08-04 Thread Pierre-Yves Chibon 
On Sat, Aug 03, 2019 at 11:20:35AM -0700, Kevin Fenzi wrote:
> On 8/2/19 11:13 AM, Florian Weimer wrote:
> > * Pierre-Yves Chibon:
> > 
> >> When you run `fedpkg build` on Rawhide, your package will be built in
> >> a new koji tag (which will be the default target for Rawhide). The
> >> package will be picked up from this koji tag, signed and moved onto a
> >> second tag. Bodhi will be notified by koji once this new build is
> >> signed and will automatically create an update for it (you will be
> >> notified about this by email by bodhi directly) with a “Testing”
> >> status. If the package maintainer has not opted in into the CI
> >> workflow, the update will be pushed to “Stable” and the build will be
> >> pushed into the regular Rawhide tag, making it available in the
> >> Rawhide buildroot, just as it is today.
> > 
> > I see both “Status stable” and a “Push to Testing” button in the upper
> > right here:
> > 
> >   
> > 
> > Is this a UI issue?
> 
> It's an issue of some kind definitely... either it should not show that
> or not allow it.

+1

Could you please make a ticket of this at:
https://github.com/fedora-infra/bodhi/issues/ ?


Thanks,
Pierre


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

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

2019-08-04 Thread updates 
The following builds have been pushed to Fedora EPEL 8 updates-testing

pdns-4.1.11-2.el8

Details about builds:



 pdns-4.1.11-2.el8 (FEDORA-EPEL-2019-3280c93462)
 A modern, advanced and high performance authoritative-only nameserver

Update Information:

The PowerDNS Nameserver is a modern, advanced and high performance
authoritative-only nameserver. It is written from scratch and conforms to all
relevant DNS standards documents. Furthermore, PowerDNS interfaces with almost
any database.


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