Re: Fedora Lifecycles: imagine longer-term possibilities

[Kalev Lember]

On 11/19/2018 10:04 PM, Stephen John Smoogen wrote:

Centos also ships a lot of non-Red Hat kernels and modules which
meet various itches that people feel (xen, upstream lts, various
gluster/ceph/arm32/etc)


I wonder if something like this could make sense for Fedora as well, to
ship two kernel streams. "kernel" that has latest kernel, and
"kernel-lts" that has the LTS kernel that was latest when this Fedora
version was first released. "kernel" would get continuously rebased to
latest version, and "kernel-lts" would just stay on the same version the
whole life cycle.

If some classes of users (hardware vendors) prefer LTS kernel, and some
classes of users (people installing their computers themselves and
wanting latest hardware support) prefer latest kernel, we should be able
to make both happy.

--
Kalev
___
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-20181119.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test did not fail in Rawhide-20181118.n.0):

ID: 310311  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/310311
ID: 310314  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/310314
ID: 310457  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/310457

Old failures (same test failed in Rawhide-20181118.n.0):

ID: 310296  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/310296
ID: 310310  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/310310
ID: 310337  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/310337
ID: 310338  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/310338
ID: 310341  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/310341
ID: 310357  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/310357
ID: 310362  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310362
ID: 310378  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/310378
ID: 310379  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/310379
ID: 310430  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/310430

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

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

ID: 310326  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310326
ID: 310409  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/310409

Old soft failures (same test soft failed in Rawhide-20181118.n.0):

ID: 310319  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/310319
ID: 310320  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/310320
ID: 310340  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/310340
ID: 310344  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/310344
ID: 310392  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/310392
ID: 310395  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/310395
ID: 310417  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/310417
ID: 310458  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/310458

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

New passes (same test did not pass in Rawhide-20181118.n.0):

ID: 310309  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/310309
ID: 310318  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/310318
ID: 310327  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/310327
ID: 310328  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/310328
ID: 310331  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/310331
ID: 310334  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/310334
ID: 310343  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/310343
ID: 310346  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/310346
ID: 310347  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/310347
ID: 310348  Test: x86_64 KDE-live-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/310348
ID: 310349  Test: x86_64 KDE-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/310349
ID: 310351  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/310351
ID: 310352  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/310352
ID: 310353  Test: x86_64 KDE-live-iso desktop_terminal
URL: https://openqa.fedoraproject.org/tests/310353
ID: 310354  Test: x86_64 

Fedora rawhide compose report: 20181119.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181118.n.0
NEW: Fedora-Rawhide-20181119.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  28
Dropped packages:0
Upgraded packages:   186
Downgraded packages: 0

Size of added packages:  179.58 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.77 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20181118.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20181118.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20181118.n.0.iso

= ADDED PACKAGES =
Package: octave-6:4.4.1-1.module_2492+fd098c93
Summary: A high-level language for numerical computations
RPMs:octave octave-devel octave-doc
Size:98.30 MiB

Package: octave-control-3.1.0-3.module_2492+fd098c93
Summary: Computer-Aided Control System Design (CACSD) Tools for Octave
RPMs:octave-control
Size:4.70 MiB

Package: octave-dicom-0.2.1-2.module_2492+fd098c93
Summary: Dicom processing for Octave
RPMs:octave-dicom
Size:1.09 MiB

Package: octave-doctest-0.6.1-4.module_2492+fd098c93
Summary: Documentation tests for Octave
RPMs:octave-doctest
Size:27.60 KiB

Package: octave-general-2.1.0-1.module_2492+fd098c93
Summary: General tools for Octave, string dictionary, parallel computing
RPMs:octave-general
Size:370.50 KiB

Package: octave-gsl-2.0.0-7.module_2492+fd098c93
Summary: Octave bindings to the GNU Scientific Library
RPMs:octave-gsl
Size:685.46 KiB

Package: octave-image-2.8.0-1.module_2492+fd098c93
Summary: Image processing for Octave
RPMs:octave-image
Size:3.60 MiB

Package: octave-interval-3.2.0-3.module_2492+fd098c93
Summary: Interval arithmetic for Octave
RPMs:octave-interval
Size:11.22 MiB

Package: octave-io-2.4.11-3.module_2492+fd098c93
Summary: Input/Output in external formats
RPMs:octave-io
Size:1.47 MiB

Package: octave-jsonlab-1.8-2.module_2492+fd098c93
Summary: JSON/UBJSON encoder and a decoder in the native matlab/octave language
RPMs:octave-jsonlab
Size:44.92 KiB

Package: octave-metch-0.5.0-7.module_2492+fd098c93
Summary: Mesh/volume registration toolbox
RPMs:octave-metch
Size:22.83 KiB

Package: octave-miscellaneous-1.2.1-13.module_2492+fd098c93
Summary: Miscellaneous functions for Octave
RPMs:octave-miscellaneous
Size:599.34 KiB

Package: octave-ncarray-1.0.4-6.module_2492+fd098c93
Summary: Access NetCDF files as a multi-dimensional array
RPMs:octave-ncarray
Size:38.15 KiB

Package: octave-netcdf-1.0.12-3.module_2492+fd098c93
Summary: A MATLAB compatible NetCDF interface for Octave
RPMs:octave-netcdf
Size:537.33 KiB

Package: octave-nnet-0.1.13-15.module_2492+fd098c93
Summary: A feed forward multi-layer neural network
RPMs:octave-nnet
Size:367.25 KiB

Package: octave-odepkg-0.9.1-0.6.20170102hg609.module_2492+fd098c93
Summary: A package for solving ordinary differential equations and more
RPMs:octave-odepkg
Size:1.97 MiB

Package: octave-parallel-3.1.3-2.module_2492+fd098c93
Summary: Parallel execution package for cluster computers for Octave
RPMs:octave-parallel
Size:1.35 MiB

Package: octave-quaternion-2.4.0-9.module_2492+fd098c93
Summary: Quaternion package for Octave
RPMs:octave-quaternion
Size:1.47 MiB

Package: octave-signal-1.4.0-5.module_2492+fd098c93
Summary: Signal processing tools for Octave
RPMs:octave-signal
Size:1.26 MiB

Package: octave-specfun-1.1.0-20.module_2492+fd098c93
Summary: Special functions for Octave, including ellipitic functions
RPMs:octave-specfun
Size:327.01 KiB

Package: octave-statistics-1.4.0-2.module_2492+fd098c93
Summary: Additional statistics functions for Octave
RPMs:octave-statistics
Size:1.40 MiB

Package: octave-struct-1.0.15-3.module_2492+fd098c93
Summary: Structure handling for Octave
RPMs:octave-struct
Size:371.34 KiB

Package: octave-symbolic-2.7.1-3.module_2492+fd098c93
Summary: Symbolic computations for Octave
RPMs:octave-symbolic
Size:267.00 KiB

Package: pam_2fa-1.0-1.fc30
Summary: Second factor authentication for PAM
RPMs:pam_2fa pam_ssh_user_auth
Size:215.65 KiB

Package: perl-URI-db-0.19-1.fc30
Summary: Perl support for database URIs
RPMs:perl-URI-db
Size:35.14 KiB

Package: python-dipy-0.15.0-0.2.git756b519.fc30
Summary: Diffusion MRI utilities in python
RPMs:python-dipy-doc python3-dipy
Size:34.12 MiB

Package: python-pygiftiio-1.0.4-2.fc30
Summary: Python bindings for Gifti
RPMs:python3-pygiftiio
Size:25.04 KiB

Package: swig-3.0.12-22.module_2495+ac095b5b
Summary: Connects C/C++/Objective C to some high-level programming languages
RPMs:ccache-swig swig swig-doc swig-gdb
Size

[389-devel] 389 DS nightly 2018-11-20 - 90% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/20/report-389-ds-base-1.4.0.16-1.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Luya Tshimbalanga]

On 2018-11-13 3:36 p.m., Matthew Miller wrote:
> > Hi everyone! Let's talk about something new and exciting. Since its >
first release fifteen years ago, Fedora has had a 13-month lifecycle >
(give or take). That works awesomely for many cases (like, hey, we're >
all here), but not for everyone. Let's talk about how we might address >
some of the users and use cases we're missing out on. > > When I talk to
people about this, I often get "hey, you should do LTS > or go to
rolling releases.” As I've said before, on the surface that's > a weird
thing to say, since the actual user impact of those two > different
things is mostly _opposite_. So, digging in, it often really > means "I
don't want the pain and fear of big OS upgrades". > > We've addressed
that in several ways: first, making upgrades better. > (Thanks everyone
who has worked on that.) A Fedora release-to-release > update is
normally not much more trouble than you might get some random > Tuesday
with a rolling release. Second, we have some things like Fedora > Atomic
Host and upcoming Fedora CoreOS and IoT which both implement a > rolling
stream on top of the Fedora release base. And finally, there's > the
coming-someday plans for gating Rawhide, making that a better >
proposition for people who really want to live on the edge. > > But
there are some good cases for a longer lifecycle. For one thing, > this
has been a really big blocker for getting Fedora shipped on > hardware.
Second, there are people who really could be happily running > Fedora
but since we don't check the tickbox, they don't even look at us >
seriously. I'd love to change these things. To do that, we need >
something that lasts for 36-48 months. > > So, what would this look
like? I have some ideas, but, really, there > are many possibilities.
That's what this thread is for. Let's figure it > out. How would we
structure repositories? How would we make sure we're > not overworked?
How would we balance this with getting people new stuff > fast as well?
> > > > The biggest issues are proper documentations and manpower.
Before planning a long term release, improving the existing
infrastructure accepting new contributors and active maintenance of
packages  (say adding a co-maintainer)with a guideline easy to read and
understand should be the main priority. Case in the point with the
current wiki hard to navigate when it comes to look at the information
leading to an outdated version.

Additionally, have more polishing on the entire Fedora operating system
is a bonus i.e. presentation (looking at the marketing department, one
of the strong point from Ubuntu) and solid foundation.

Luya




0x5E528174D8A2609A.asc
Description: application/pgp-keys
___
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 Rawhide 20181119.n.0 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 30 Rawhide 20181119.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20181112.n.0: anaconda-30.10-2.fc30.src, 20181119.n.0: 
anaconda-30.11-1.fc30.src

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_30_Rawhide_20181119.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
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

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[sixy]

> Sent: Friday, November 16, 2018 at 10:07 PM
> From: "Jonathan Dieter" 
> To: "Development discussions related to Fedora" 
> 
> Subject: Proposal: Faster composes by eliminating deltarpms and using 
> zchunked rpms instead
>
> For reference, this is in reply to Paul's email about lifecycle
> objectives, specifically focusing on problem statement #1[1].
> 
> 
> Have rpm use zchunk as its compression format, removing the need for
> deltarpms, and thus reducing compose time.  This will require changes
> to both the rpm format and new features in the zchunk format.
> 
> 
> *deltarpm background*
> As part of the compose process, deltarpms are generated between each
> new rpm and both the GA version of the rpm and the previous version. 
> This process is very CPU and memory intensive, especially for large
> rpms.
> 
> This also means that deltarpms are only useful for an end user if they
> are either updating from GA or have been diligent about keeping their
> system up-to-date.  If a user is updating a package from N-2 to N,
> there will be no deltarpm and the full rpm will be downloaded.
> 
> *zchunk background*
> As some are aware, I've been working on zchunk[2], a compression format
> that's designed for highly efficient deltas, and using it minimize
> metadata downloads[3].
> 
> The core idea behind zchunk is that a file is split into independently
> compressed chunks and the checksum of each compressed chunk is stored
> in the zchunk header.  When downloading a new version of the file, you
> download the zchunk header first, check which chunks you already have,
> and then download the rest.
> 
> *Proposal*
> My proposal would be to make zchunk the rpm compression format for
> Fedora.  This would involve a few additions to the zchunk format[4]
> (something the format has been designed to accommodate), and would
> require some changes to the rpm file format.
> 
> *Benefit*
> The benefit of zchunked rpms is that, when downloading an updated rpm,
> you would only need to download the chunks that have changed from
> what's on your system.
> 
> The uncompressed local chunks would be combined with the downloaded
> compressed chunks to create a local rpm that will pass signature
> verification without needing to recompress the uncompressed local
> chunks, making this computationally much faster than rebuilding a
> deltarpm, a win for users.
> 
> The savings wouldn't be as good as what deltarpm can achieve, but
> deltarpms would be redundant and could be removed, completely
> eliminating a large step from the compose process.
> 
> *Drawbacks*
>1. Downloading a new release of a zchunked rpm would be larger than
>   downloading the equivalent deltarpm.  This is offset by the fact
>   that the client is able to work out which chunks it needs no matter
>   what the original rpm is, rather than needing a specific original
>   rpm as deltarpm does.
>2. The rebuilt rpm may not be byte-for-byte identical to the original,
>   but will be able to be validated without decompression, as explained
>   in the next section
> 
> *Changes*
> The zchunk format would need to be extended to allow for a zchunked rpm
> to contain both the uncompressed chunks that were already on the local
> system and the newly downloaded compressed chunks while still passing
> signature verification.  This would also require moving signature
> verification to zchunk.
>  
> The rpm file format has to be changed because the zchunk header needs
> to be at the beginning of the file in order for the zchunk library
> figure out which chunks it needs to download.  My suggestions for
> changes to the rpm file format are as follows:
> 
>1. Signing should be moved to the zchunk format as described at the
>   beginning of this section
>2. The rpm header should be stored in one stream inside the zchunk
>   file.  This allows it to be easily extracted separately from the
>   data
>3. The rpm cpio should be stored in a second stream inside the zchunk
>   file.
>4. At minimum, an optional zchunk element should be set to identify
>   zchunk rpms as rpms rather than regular zchunk files.  If desired,
>   optional elements could also be set containing %{name}, %[version},
>   %{release}, %{arch} and %{epoch}.  This would allow this information
>   to be read easily without needing to extract the rpm header stream.
> 
> *Final notes*
> I realize this is a massive proposal, zchunk is still very young, and
> we're still working on getting the dnf zchunk pull requests reviewed. 
> I do think it's feasible and provides an opportunity to eliminate a
> pain point from our compose process while still reducing the download
> size for our users.
> 
> [1]: 
> https://fedoraproject.org/wiki/Objectives/Lifecycle/Problem_statements#Challenge_.231:_Faster.2C_more_scalable_composes
> [2]: https://github.com/zchunk/zchunk
> [3]: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
> [4]: 

[Fedocal] Reminder meeting : Modularity Office Hours

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-11-20 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


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

___
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

[rpms/perl-Glib-Object-Introspection] New Commits To "rpms/perl-Glib-Object-Introspection" (master)

[pagure]

The following commits were pushed to the repo 
rpms/perl-Glib-Object-Introspection on branch
master, which you are following:
e70307e0ee4ab57055f6790feb9aa66cc02593c1Zbigniew Jędrzejewski-SzmekUse 
C.UTF-8 locale



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Glib-Object-Introspection/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 16:29 -0500, Simo Sorce wrote:
> On Mon, 2018-11-19 at 21:02 +, Jonathan Dieter wrote:
> > On Mon, 2018-11-19 at 15:18 -0500, Simo Sorce wrote:

> > > I do not think you can just trust random metadata somewhere, one of the
> > > points of a rpm reinstall is to fix damaged files for example. It does
> > > no good if you skip those because some file somewhere says they are
> > > "OK". (If I understood your comment about "just downloading changed
> > > chunks).
> > 
> > Yes, this is the crux of the problem.  As I see it, dnf should verify
> > the checksums on the local files before downloading the missing chunks,
> > but that doesn't guarantee that the data won't be changed between the
> > download step and the install step.  RPM would also need to verify the
> > checksums before starting the install phase, and would need to bail out
> > if the checksums had changed.
> > 
> > My biggest concern, though, is what happens if package A needs a
> > specific chunk in /usr/bin/foo and package B changes /usr/bin/foo while
> > being installed.  The chunk was there when the install phase started,
> > but disappeared before package A was actually installed.
> 
> Is this different in a normal install ?
> What if package A installs /usr/bin/foo and then package B overwrites
> it ?
> 
> Or are you concerned about the case where there may be an identical
> chunk in different files ? Are chunks "global" to the host ?

This.  If we stored the checksums in the rpm database, then, yes they
would be global to the host.

> This problem could be addressed by copying all uncompressed chunks in a
> staging area before installing the rpm, failing in a clean way (ie not
> half way through a package install). The penalty is the need for enough
> space to copy the uncompressed files though. more clever things could
> be done with proper filesystem support and snapshotting and copy-on-
> write, but not sure it is worth optimizing for what is normally a
> relatively small scratch area (if you do it one package at a time
> only).

What about just copying any uncompressed chunks required for the
current package or any packages still in the install queue?  That might
reduce the scratch area even further.

> > > 2) what are the chunks sizes ?
> > 
> > The chunk sizes vary because you don't want inserting or removing a few
> > bytes to completely change all the following chunks.  The current
> > default average size is 32KB, but that can be adjusted.
> 
> Is this a compromise between compression performance and granularity ?
> Anything else went into the decision to settle around 32k ?
> Some filesystems seem to gravitate around 64k extents so I am
> wondering.

Yes, this is just a compromise.  The larger the chunk size, the larger
the delta you need to download, but the better the compression.  We
could experiment with this to see if 64k would give us significantly
better compression.

I would also chunk on file borders in the rpm payload, so we don't end
up having a chunk span multiple files.  That would get messy fast when
trying to rebuild from local files.

> > > Finally what signature scheme where you planning to use ? And how do
> > > you deal with the data you want to "exclude" from signing, omit it or
> > > feed in blank "sectors" ?
> > 
> > I was planning to use GPG signatures, and was planning to just omit the
> > data I want excluded.  Having said that, while the format supports
> > signatures, the code hasn't been written and if either of those answers
> > are bad/dangerous, we can change that.
> 
> We use GPG signatures right now, can't be any more dangerous than that
> :-)
> 
> The omission vs blanking has no ill effect, but was not explicitly
> mentioned, it should. Esp around places where the missing data is in
> the middle of a "structure" in your diagrams, or it may be ambiguous
> and lead to incompatible implementations if someone is ever going to
> build another (and if zchunk is going to be adopted in rpm I bet there
> will be some other implementation to do some crazy thing :-)

Yep.  Let me clarify that in the format definition (and add the new
checksum types, I noticed they're missing).

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Simo Sorce]

On Mon, 2018-11-19 at 22:18 +0100, Nicolas Mailhot wrote:
> Le lundi 19 novembre 2018 à 20:30 +, Jonathan Dieter a écrit :
> > 
> > The zchunk advantage over deltarpms is much less CPU usage, while its
> > disadvantages are slightly larger network usage and increased disk
> > usage.
> 
> Unfortunately, that's a bad compromise for most limited clients. A
> limited client can trade time for CPU or network performance, swap for
> memory. What it can absolutely not make more of is storage, both install
> and staging storage. Install storage requirements do not depend on rpm
> tech level, but will generally go up over a system lifetime, adding
> pressure on staging storage.
> 
> So you absolutely need to keep staging storage on par or less than
> existing rpm/dnf if you do not want to obsolete classes of Fedora
> hardware.
> 
> And Google released a huge quantity of cheap storage-deficient hardware
> with its chromebooks. People do install Fedora on those.

To be honest, I run low on normal HW as well, and often have to "make
space" for Version upgrades.

It would be much nicer if we could handle this problem by installing
smaller sets of rpms, and downloading the next set of rpms only when
the first got installed and deleted to make space.

But then there is the risk to end up with a frankensetup if you lose
network before the full upgrade is done...

On some systems I would even prefer to download as you go, as I have
more b/w than storage, but I do not want to experiment with putting
/var/cache on nfs ...

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 22:18 +0100, Nicolas Mailhot wrote:
> Le lundi 19 novembre 2018 à 20:30 +, Jonathan Dieter a écrit :
> > The zchunk advantage over deltarpms is much less CPU usage, while its
> > disadvantages are slightly larger network usage and increased disk
> > usage.
> 
> Unfortunately, that's a bad compromise for most limited clients. A
> limited client can trade time for CPU or network performance, swap for
> memory. What it can absolutely not make more of is storage, both install
> and staging storage. Install storage requirements do not depend on rpm
> tech level, but will generally go up over a system lifetime, adding
> pressure on staging storage.
> 
> So you absolutely need to keep staging storage on par or less than
> existing rpm/dnf if you do not want to obsolete classes of Fedora
> hardware.
> 
> And Google released a huge quantity of cheap storage-deficient hardware
> with its chromebooks. People do install Fedora on those.

The only way we can keep staging storage down (and it would actually be
less than deltarpm/normal rpm) is to use the local chunks at install
time rather than download time.  This comes with its own risks though,
see the other emails in this thread, specifically the ones following
Jan Pokorný's message.

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 21:14 +, Tom Hughes wrote:
> On 19/11/2018 20:30, Jonathan Dieter wrote:
> 
> > On the client:
> > The zchunk advantage over regular rpm is decreased network usage, while
> > its disadvantage is increased disk usage (since the local chunks will
> > be uncompressed).
> > 
> > The zchunk advantage over deltarpms is much less CPU usage, while its
> > disadvantages are slightly larger network usage and increased disk
> > usage.
> > 
> > Note that for most users the increased disk usage is temporary, since
> > rpms are deleted after install.
> 
> If they're deleted after install then surely next time there is an
> update there won't be any local chunks and everything will have to
> be downloaded?
> 
> That's what has been confusing me about this whole thing - as I
> understand it the idea is to only download new chunks and to reuse
> chunks that are unchanged from earlier revisions, but it seems
> that doing that would require keeping a local copy of every
> installed rpm which would be a big change that nobody seems to
> have mentioned.

The idea is to use the locally installed files as the local chunks, the
same way that deltarpm does.

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Simo Sorce]

On Mon, 2018-11-19 at 21:02 +, Jonathan Dieter wrote:
> On Mon, 2018-11-19 at 15:18 -0500, Simo Sorce wrote:
> > On Mon, 2018-11-19 at 19:58 +, Jonathan Dieter wrote:
> 
> 
> > > That's an interesting thought.  I was picturing using the zchunk
> > > library in the dnf download stage to build a local rpm from the
> > > verified locally installed files and the downloaded changed chunks,
> > > but, if I understand your suggestions correctly, you're saying we
> > > could
> > > just download the changed chunks and have RPM automatically get the
> > > rpm-integrity verified chunks during the *install* stage.
> > 
> > How do you know which chunks to download w/o having a stored (or
> > recomputed) list of existing chunks ?
> 
> I thought we should store the chunk checksums of installed files in the
> rpm database.  Something like file, offset, length, checksum type,
> checksum?
> 
> > > The advantage of this method is that you don't need to store the local
> > > data twice, but the danger is that the local files get changed
> > > elsewhere during the install process.
> > > 
> > > It's an interesting thought, though, and I wonder if there's a way we
> > > could work around that danger?
> > 
> > I do not think you can just trust random metadata somewhere, one of the
> > points of a rpm reinstall is to fix damaged files for example. It does
> > no good if you skip those because some file somewhere says they are
> > "OK". (If I understood your comment about "just downloading changed
> > chunks).
> 
> Yes, this is the crux of the problem.  As I see it, dnf should verify
> the checksums on the local files before downloading the missing chunks,
> but that doesn't guarantee that the data won't be changed between the
> download step and the install step.  RPM would also need to verify the
> checksums before starting the install phase, and would need to bail out
> if the checksums had changed.
> 
> My biggest concern, though, is what happens if package A needs a
> specific chunk in /usr/bin/foo and package B changes /usr/bin/foo while
> being installed.  The chunk was there when the install phase started,
> but disappeared before package A was actually installed.

Is this different in a normal install ?
What if package A installs /usr/bin/foo and then package B overwrites
it ?

Or are you concerned about the case where there may be an identical
chunk in different files ? Are chunks "global" to the host ?

This problem could be addressed by copying all uncompressed chunks in a
staging area before installing the rpm, failing in a clean way (ie not
half way through a package install). The penalty is the need for enough
space to copy the uncompressed files though. more clever things could
be done with proper filesystem support and snapshotting and copy-on-
write, but not sure it is worth optimizing for what is normally a
relatively small scratch area (if you do it one package at a time
only).

> > A couple more questions.
> > I skimmed quickly at the format and I have two questions I did not
> > immediately see an answer for.
> > 1) why are you still supporting SHA-1 in a new format ?
> 
> Zchunk cares about two types of checksums, the chunk checksums, used to
> determine if two chunks are the same, and the full data checksum (which
> currently defaults to SHA-25), used to actually validate the data.
> 
> Originally, SHA-1 was supposed to be used *only* for the chunk
> checksums, but, somewhere along the way, it was pointed out that using
> the first 128 bits of a SHA-512 hash would be faster and more secure,
> so the default for the chunk checksums is now SHA-512/128.
> 
> The only reason SHA-1 support is still in zchunk is because I don't
> want to break backwards compatibility for the (probably five) zchunk
> files created before this change.
> 
> Having said that, zchunked rpms won't be able to depend on the full
> data checksum (because the local chunks will be uncompressed), so we'd
> need to use SHA-256 at minimum for the chunk checksums.
> 
> > 2) what are the chunks sizes ?
> 
> The chunk sizes vary because you don't want inserting or removing a few
> bytes to completely change all the following chunks.  The current
> default average size is 32KB, but that can be adjusted.

Is this a compromise between compression performance and granularity ?
Anything else went into the decision to settle around 32k ?
Some filesystems seem to gravitate around 64k extents so I am
wondering.

> > Sorry if this is already answered somewhere.
> > 
> > Finally what signature scheme where you planning to use ? And how do
> > you deal with the data you want to "exclude" from signing, omit it or
> > feed in blank "sectors" ?
> 
> I was planning to use GPG signatures, and was planning to just omit the
> data I want excluded.  Having said that, while the format supports
> signatures, the code hasn't been written and if either of those answers
> are bad/dangerous, we can change that.

We use GPG signatures right now, can't be any more 

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Nicolas Mailhot]

Le lundi 19 novembre 2018 à 20:30 +, Jonathan Dieter a écrit :
> 
> The zchunk advantage over deltarpms is much less CPU usage, while its
> disadvantages are slightly larger network usage and increased disk
> usage.

Unfortunately, that's a bad compromise for most limited clients. A
limited client can trade time for CPU or network performance, swap for
memory. What it can absolutely not make more of is storage, both install
and staging storage. Install storage requirements do not depend on rpm
tech level, but will generally go up over a system lifetime, adding
pressure on staging storage.

So you absolutely need to keep staging storage on par or less than
existing rpm/dnf if you do not want to obsolete classes of Fedora
hardware.

And Google released a huge quantity of cheap storage-deficient hardware
with its chromebooks. People do install Fedora on those.

-- 
Nicolas Mailhot
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Tom Hughes]

On 19/11/2018 20:30, Jonathan Dieter wrote:


On the client:
The zchunk advantage over regular rpm is decreased network usage, while
its disadvantage is increased disk usage (since the local chunks will
be uncompressed).

The zchunk advantage over deltarpms is much less CPU usage, while its
disadvantages are slightly larger network usage and increased disk
usage.

Note that for most users the increased disk usage is temporary, since
rpms are deleted after install.


If they're deleted after install then surely next time there is an
update there won't be any local chunks and everything will have to
be downloaded?

That's what has been confusing me about this whole thing - as I
understand it the idea is to only download new chunks and to reuse
chunks that are unchanged from earlier revisions, but it seems
that doing that would require keeping a local copy of every
installed rpm which would be a big change that nobody seems to
have mentioned.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
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: Fedora Lifecycles: imagine longer-term possibilities

[Nicolas Mailhot]

Le lundi 19 novembre 2018 à 11:27 -0800, Japheth Cleaver a écrit :
> On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:
> > 
> > Really, if there is one distro component we should backport to el
> > and
> > all release streams, that's rpm + all Fedora macro packages, not the
> > kernel.
> 
> Well, that's kind of my point. Packaging changes (not at the core
> level, like with the other thread) should not be Fedora-based, they
> should be in coordination *using macro packages* across the entire
> ecosystem. 

I'm not talking about using macros to ease changes I'm talking about
macros used directly in rpm specs because they save packager time and
effort. You don't get more core than that, if the macros are not there
the specs do not build. And spec ifdefs just create more packager work
than if the macro had not been written in the first place (that's one
reason the number of epel packagers is far smaller than the number of
Fedora packagers).

> (Again, Group tag removal seems an obvious example.)

That would take a specific organisation, to track macro changes, and
organise their backport whenever possible. FPC as it is organised today
does not have the required manpower.

Some macros are just lua and shell code easily backported, others
require an explicit rebuild of the tip rpm to old stable (should not be
a problem because rpm is backwards-compatible but we forbid ourselves
that right now), others backports are plain impossible because they
depend on a specific (other than rpm) component update. EPEL backports
would almost certainly collide with old macro versions in the RH EL part
and on lack of capabilities of ancient shell/rpm.

> And coming from an EL6 perspective, what "old rpm deficiencies" are
> you 
> referring to? Optional Recommends might be nifty new features, but 
> somehow we're getting along without them still fine.

What you call getting along fine is mostly slowing down Fedora
progression so the mismatch with EL does not get completely awful (as
your first message clearly stated).

>  (And, judging from 
> reports, the semantics and kinks haven't been entirely worked out of 
> those yet regardless.) If a core rpm forklift can be done safely onto
> an 
> old release, then that's an option to be kept on the table (even in a 
> stable release), but I'm hard pressed to think of any "deficiency"
> per se. 

Just a stupid thing like Fedora rpm adding end of lines by default to
echo warn and err has cost me hours patching the end of lines back in my
el backport. And I don't blame Fedora rpm for fixing this, I blame
whoever though EL-side that it would be ok to differ from the Fedora rpm
behaviour for years.

> 
> If you're discussing things like 3K-character-long java arguments,
> then 
> I agree with you that that's painful. But I fail to see how the core 
> needs of any build system (or install system) can be any more complex 
> than arbitrary shell, and these sections already *are* arbitrary
> shell. 

Before you get to the arbitrary shell part you need to pass the rpm
macro argument parser. It does not understand long options (even if you
have enough letters available for single-character flags "nice" letters
will collide when composing macros). It does not understand repeated
flags (only one flag value possible per call). Realistically for any
semi-complex macro you'll end up defining a magic rpm variable where you
put the arguments you need, and have the macro read this variable
instead of using macro arguments, because any other argument passing
attempt will flounder on the rpm argument processor.

And that's not exotic argument passing invented by awful java devs, even
dnf uses all of those.
 
> I'd like to never have to tweak CFLAGS= in a %build, but it
> occasionally does happen. That doesn't mean it's a design flaw --
> that's why code is allowed to be there. 

Yes, classical rpm works ok for C/C++ programs. That's pretty much the
only class of content that does not need long lines of shoehorning in
spec files. Want to bare any non C/C++ package from the distro so rpm
does not need to change?

> In a worst-case-scenario, one can always 
> standardize on an external helper to adjust or modify things during 
> execution (which has the added benefit of bench-testability and code 
> re-use) and use a macro to call that.
> 
> I feel like this mirrors the debate between imperative initscripts
> and  declarative unit files. Macros are great, and macros calling 
> distro-defined helpers work, but a religious purge of shell does not 
> really seem to be a win.

Then you volunteer to review and audit all those wonderful shell lines
in the tens of thousands of Fedora specs? I though not. Writing
thousands of lines of shell code in specs is trivial. Reviewing and
maintaining the result is not.

> > Most notably, all the dead-stupid %setup/%sources/Tag
> > processing, that you know any rpm novice will misunderstand and get
> > wrong, even before you attempt explanations. Those warts were merely
> > 

Re: Fedora Lifecycles: imagine longer-term possibilities

[Stephen John Smoogen]

On Sun, 18 Nov 2018 at 17:20, Neal Gompa  wrote:
>
> On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski  wrote:
> >
> > On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
> > > I'm not for or against a longer Fedora lifecycle, but I think we need
> > > a stronger statement of what the problem is we're trying to address.
> > >
> > >  From your email:
> > >
> > > On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> > >> But there are some good cases for a longer lifecycle. For one thing,
> > >> this has been a really big blocker for getting Fedora shipped on
> > >> hardware. Second, there are people who really could be happily running
> > >> Fedora but since we don't check the tickbox, they don't even look at us
> > >> seriously. I'd love to change these things. To do that, we need
> > >> something that lasts for 36-48 months.
> > >
> > > this sounds like a very valid problem.
> > >
> > > But if this was fixed, what number of manufacturers would adopt Fedora
> > > and how many installations do they ship (eg per year)?  Could it be
> > > fixed in another way, like a special OEM Fedora release?
> >
> > And why haven't these manufacturers already adopted CentOS which is
> > definitely around longer than 36-48 months?
> >
>
> I think it's quite obvious why. No one can really influence what's in
> CentOS. Red Hat Enterprise Linux itself is developed mostly behind

Those manufacturers can't really influence Windows any either. They
instead know that they will sell enough laptops with Windows on them
that they won't take a bath. There is also complicated financial
methods where Microsoft seems to supplement laptop sales so that it is
cheaper for them to ship with windows than to ship a system with no
OS. Centos also ships a lot of non-Red Hat kernels and modules which
meet various itches that people feel (xen, upstream lts, various
gluster/ceph/arm32/etc)

These are usually the bigger reasons why most larger OEM's haven't
been interested in putting CentOS or even Ubuntu on a large set of
systems. They know that the number of systems they will sell are at
most 1% of all sales.. and there isn't a large enough incentive to do
the various work they need to do that. So you end up needing a vendor
who is going to go all in (the System76's) or you get someone who is
going to offer a specific model set they know they can do
cost-effectively but aren't going to put too much into it. [AKA if the
engineers working on it love MCC Linux.. then its going to be MCC
Linux.]

In the end, for Fedora to be on a laptop by default someone is going
to have to say 'we are betting the farm to do this and will do the
work to make that happen'. I also think that we are focusing on one
part of the original proposal... It wasn't the entire reason for doing
some sort of LTS somewhere. It is just the one we can probably pick
holes in the easiest :).


-- 
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 15:18 -0500, Simo Sorce wrote:
> On Mon, 2018-11-19 at 19:58 +, Jonathan Dieter wrote:

> > That's an interesting thought.  I was picturing using the zchunk
> > library in the dnf download stage to build a local rpm from the
> > verified locally installed files and the downloaded changed chunks,
> > but, if I understand your suggestions correctly, you're saying we
> > could
> > just download the changed chunks and have RPM automatically get the
> > rpm-integrity verified chunks during the *install* stage.
> 
> How do you know which chunks to download w/o having a stored (or
> recomputed) list of existing chunks ?

I thought we should store the chunk checksums of installed files in the
rpm database.  Something like file, offset, length, checksum type,
checksum?

> > The advantage of this method is that you don't need to store the local
> > data twice, but the danger is that the local files get changed
> > elsewhere during the install process.
> > 
> > It's an interesting thought, though, and I wonder if there's a way we
> > could work around that danger?
> 
> I do not think you can just trust random metadata somewhere, one of the
> points of a rpm reinstall is to fix damaged files for example. It does
> no good if you skip those because some file somewhere says they are
> "OK". (If I understood your comment about "just downloading changed
> chunks).

Yes, this is the crux of the problem.  As I see it, dnf should verify
the checksums on the local files before downloading the missing chunks,
but that doesn't guarantee that the data won't be changed between the
download step and the install step.  RPM would also need to verify the
checksums before starting the install phase, and would need to bail out
if the checksums had changed.

My biggest concern, though, is what happens if package A needs a
specific chunk in /usr/bin/foo and package B changes /usr/bin/foo while
being installed.  The chunk was there when the install phase started,
but disappeared before package A was actually installed.

> A couple more questions.
> I skimmed quickly at the format and I have two questions I did not
> immediately see an answer for.
> 1) why are you still supporting SHA-1 in a new format ?

Zchunk cares about two types of checksums, the chunk checksums, used to
determine if two chunks are the same, and the full data checksum (which
currently defaults to SHA-25), used to actually validate the data.

Originally, SHA-1 was supposed to be used *only* for the chunk
checksums, but, somewhere along the way, it was pointed out that using
the first 128 bits of a SHA-512 hash would be faster and more secure,
so the default for the chunk checksums is now SHA-512/128.

The only reason SHA-1 support is still in zchunk is because I don't
want to break backwards compatibility for the (probably five) zchunk
files created before this change.

Having said that, zchunked rpms won't be able to depend on the full
data checksum (because the local chunks will be uncompressed), so we'd
need to use SHA-256 at minimum for the chunk checksums.

> 2) what are the chunks sizes ?

The chunk sizes vary because you don't want inserting or removing a few
bytes to completely change all the following chunks.  The current
default average size is 32KB, but that can be adjusted.

> Sorry if this is already answered somewhere.
> 
> Finally what signature scheme where you planning to use ? And how do
> you deal with the data you want to "exclude" from signing, omit it or
> feed in blank "sectors" ?

I was planning to use GPG signatures, and was planning to just omit the
data I want excluded.  Having said that, while the format supports
signatures, the code hasn't been written and if either of those answers
are bad/dangerous, we can change that.

> Thanks for any answer.
> Simo.

Thank you for looking at this!

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Sun, 2018-11-18 at 13:19 -0500, Stephen John Smoogen wrote:
> On Sun, 18 Nov 2018 at 12:49, Neal Gompa  wrote:
> > On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter  > > wrote:
> > > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > > > Jonathan Dieter wrote:
> > > > > My proposal would be to make zchunk the rpm compression
> > > > > format for
> > > > > Fedora.
> > > > 
> > > > Given that:
> > > > 1. zchunk is based on zstd, which is typically less efficient
> > > > in terms of
> > > >compression ratio than xz, depending on settings
> > > >(see, e.g., https://github.com/inikep/lzbench), and
> > > > 2. zchunk can by design only compress chunks individually and
> > > > not benefit
> > > >from the space savings of a solid archive with a global
> > > > dictionary,
> > > > I fear that this is going to significantly increase the size of
> > > > the RPMs,
> > > > which matters:
> > > > * for the initial downloads,
> > > > * for storage (e.g., keepcache=1, local mirrors, etc.), and
> > > > * for the people not using deltas for whatever reason.
> > > > 
> > > > I think zchunk makes a lot of sense for the metadata, but I am
> > > > not convinced
> > > > that it is the right choice for the RPMs themselves.
> > > 
> > > I suspect the first is true, but zchunk does actually allow for a
> > > global (per-file) dictionary that can be used to compress each
> > > chunk.
> > > The difficulty is that the dictionary has to stay the same
> > > between file
> > > versions, or the chunk checksums won't match.  There would have
> > > to be
> > > some thought put into how to generate and store the dictionaries.
> > > 
> > > As for how much bigger a zchunked rpm will be compared to an xz
> > > rpm, at
> > > the moment it's a bit hand-wavy.  Based on zchunked repodata work
> > > I've
> > > done, I think we might be looking at a size that's slightly
> > > smaller
> > > than a gzipped rpm.  I won't know for sure until I put together a
> > > proof-of-concept, but I want to make sure that there aren't any
> > > gaping
> > > holes in the proposal before I do that.
> > > 
> > 
> > I did some work several months ago to evaluate zstd compression for
> > RPMs for Fedora, because of the lower memory and CPU usage for
> > (de)compression. However, the average size increase from xz was
> > pretty
> > large (~20% or more on average, and nothing ever was either the
> > same
> > or smaller), even with heavier compression settings. That might
> > have
> > changed a bit with newer zstd releases that offer some more
> > tunables,
> > but I think it'll remain a tough sell on disk space.
> 
> So there are at least 4 legs here:
> CPU usage (in both uncompression install and deltarpm)
> Memory usage per transaction
> Network amount
> Disk amount
> 
> I expect that the best we are going to get in any 'improvement' is
> going to be 3 out of the 4. The xz compression and delta-rpm has a
> cpu/memory tradeoff for disk and network in comparison to gzip but it
> is mostly acceptable if you have fairly modern desktops. However for
> older hardware or lower power systems that tradeoff may not be good.

Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't
require extra CPU usage on the client side as they don't go through the
decompress-recompress cycle that deltarpms do.  Re-assembling a zchunk
file requires no compression or decompression.

On the client:
The zchunk advantage over regular rpm is decreased network usage, while
its disadvantage is increased disk usage (since the local chunks will
be uncompressed).

The zchunk advantage over deltarpms is much less CPU usage, while its
disadvantages are slightly larger network usage and increased disk
usage.

Note that for most users the increased disk usage is temporary, since
rpms are deleted after install.

In our infrastructure:
The zchunk advantage over deltarpms is that they are created in the
build stage and shouldn't take any longer than building a normal rpm,
while deltarpms take quite a while to build.

The disadvantage is that our current rpms use xz compression which is
more efficient at compressing a whole file than zchunk is, so zchunked
rpms will require more disk space.

Hope that helps clarify things.

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Simo Sorce]

On Mon, 2018-11-19 at 19:58 +, Jonathan Dieter wrote:
> On Mon, 2018-11-19 at 20:16 +0100, Jan Pokorný wrote:
> > On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> > > Le 2018-11-19 12:28, Martin Kolman a écrit :
> > > 
> > > > Many people might think RAM would not be an issue in 2018, but in
> > > > practice there are
> > > > and likely always will be memory constrained installation targets,
> > > > such as massive deployments
> > > > of "small" VMs or the IoT use cases mentioned above.
> > > 
> > > Sure, that’s the artificial small vm case
> > > 
> > > The average old/limited hardware is limited in memory, cpu and storage.
> > > Therefore if you have one factor to sacrifice it's cpu time because you 
> > > can
> > > always let the CPU run a little longer, but a limited system won't 
> > > magically
> > > grow more memory or more storage.
> > > 
> > > Storage would not be such a problem is dnf was smart enough to auto
> > > partition big upgrades in lots of small partial upgrades, before 
> > > downloading
> > > gigs of data that do not fit on disk.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1609824
> > 
> > Also, not familiar with zchunk way of doing things, but couldn't
> > rpm-integrity-verified installed files be mapped back to "chunks"
> > to further aleviate space concerns for the machine receiving
> > updates in some cases?
> 
> That's an interesting thought.  I was picturing using the zchunk
> library in the dnf download stage to build a local rpm from the
> verified locally installed files and the downloaded changed chunks,
> but, if I understand your suggestions correctly, you're saying we could
> just download the changed chunks and have RPM automatically get the
> rpm-integrity verified chunks during the *install* stage.

How do you know which chunks to download w/o having a stored (or
recomputed) list of existing chunks ?

> The advantage of this method is that you don't need to store the local
> data twice, but the danger is that the local files get changed
> elsewhere during the install process.
> 
> It's an interesting thought, though, and I wonder if there's a way we
> could work around that danger?

I do not think you can just trust random metadata somewhere, one of the
points of a rpm reinstall is to fix damaged files for example. It does
no good if you skip those because some file somewhere says they are
"OK". (If I understood your comment about "just downloading changed
chunks).

A couple more questions.
I skimmed quickly at the format and I have two questions I did not
immediately see an answer for.
1) why are you still supporting SHA-1 in a new format ?
2) what are the chunks sizes ?

Sorry if this is already answered somewhere.

Finally what signature scheme where you planning to use ? And how do
you deal with the data you want to "exclude" from signing, omit it or
feed in blank "sectors" ?

Thanks for any answer.
Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 20:16 +0100, Jan Pokorný wrote:
> On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> > Le 2018-11-19 12:28, Martin Kolman a écrit :
> > 
> > > Many people might think RAM would not be an issue in 2018, but in
> > > practice there are
> > > and likely always will be memory constrained installation targets,
> > > such as massive deployments
> > > of "small" VMs or the IoT use cases mentioned above.
> > 
> > Sure, that’s the artificial small vm case
> > 
> > The average old/limited hardware is limited in memory, cpu and storage.
> > Therefore if you have one factor to sacrifice it's cpu time because you can
> > always let the CPU run a little longer, but a limited system won't magically
> > grow more memory or more storage.
> > 
> > Storage would not be such a problem is dnf was smart enough to auto
> > partition big upgrades in lots of small partial upgrades, before downloading
> > gigs of data that do not fit on disk.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1609824
> 
> Also, not familiar with zchunk way of doing things, but couldn't
> rpm-integrity-verified installed files be mapped back to "chunks"
> to further aleviate space concerns for the machine receiving
> updates in some cases?

That's an interesting thought.  I was picturing using the zchunk
library in the dnf download stage to build a local rpm from the
verified locally installed files and the downloaded changed chunks,
but, if I understand your suggestions correctly, you're saying we could
just download the changed chunks and have RPM automatically get the
rpm-integrity verified chunks during the *install* stage.

The advantage of this method is that you don't need to store the local
data twice, but the danger is that the local files get changed
elsewhere during the install process.

It's an interesting thought, though, and I wonder if there's a way we
could work around that danger?

Jonathan


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Sun, 2018-11-18 at 07:02 +, Leigh Scott wrote:
> +1 to anything to rid me of deltarpms, I currently have to disable
> this lame default.

The irony is that getting deltarpms into Fedora was largely my
fault.  ;)  Sorry, Leigh.

Jonathan
___
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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jonathan Dieter]

On Mon, 2018-11-19 at 14:57 +0100, Miroslav Suchý wrote:
> Dne 16. 11. 18 v 23:07 Jonathan Dieter napsal(a):
> >1. Downloading a new release of a zchunked rpm would be larger than
> >   downloading the equivalent deltarpm.  This is offset by the fact
> >   that the client is able to work out which chunks it needs no matter
> >   what the original rpm is, rather than needing a specific original
> >   rpm as deltarpm does.
> 
> Does this means bigger requirements for copies of RPMs too? I mean
> for all our repos mirros, for RH Satellites, Spacewalk, Koji, Copr,
> Retrace...

Yes, and that should actually be item 3 in drawbacks.  Zchunked rpms
will be larger than the current xz-compressed rpms, but the actual size
increase is still unknown.  I think we can shoot for roughly the same
size as a gzip-compressed rpm, but I'm not sure.

Mirror storage *might* actually go down, since we no longer need to
store deltarpms, but anything that only stores rpms will definitely
require more space.

Jonathan

___
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: Fedora Lifecycles: imagine longer-term possibilities

[Japheth Cleaver]

On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:

Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit :

I'm not sure why punting like this is a good thing. RPM is a
standard,
moving along at what one might expect a core component to do, but to
the
extent that "evolving our packaging" means doing things at odds with
or
in an incompatible way other distros (whether downstream,
"downstream",  or not) this is not a feature, or very nice.

I think you do not realise how much old rpm is holding us back, and how
much we limit ourselves in Fedora, and make ourselves more work, just to
cater to those old rpm limitations. A small number of people, that
include Jason Tibbitts, perform unappreciated heroic wonders all year
round to limit the damage old rpm deficiencies inflict on Fedora and
EPEL, and if you think the situation is imperfect, well it would be
terrible without them.

Really, if there is one distro component we should backport to el and
all release streams, that's rpm + all Fedora macro packages, not the
kernel.


Well, that's kind of my point. Packaging changes (not at the core level, 
like with the other thread) should not be Fedora-based, they should be 
in coordination *using macro packages* across the entire ecosystem. 
(Again, Group tag removal seems an obvious example.)


And coming from an EL6 perspective, what "old rpm deficiencies" are you 
referring to? Optional Recommends might be nifty new features, but 
somehow we're getting along without them still fine. (And, judging from 
reports, the semantics and kinks haven't been entirely worked out of 
those yet regardless.) If a core rpm forklift can be done safely onto an 
old release, then that's an option to be kept on the table (even in a 
stable release), but I'm hard pressed to think of any "deficiency" per 
se. (%trans processing and %build conditionals strike me as things it 
would've be important to backport.)



Classical rpm targets and works well for C/C++ projects that use
autotools, a static small list of dependencies, and release as an
archive. A growing part of the distribution does not fit this model any
more. git and the internet blew away any limit on the number and cadence
of dependencies for every language, including C/C++. Non C/C++ languages
do not fit in the C/C++ macro model. Those new parts needs the same
level of rpm support as previous projects, which means writing new
macros, that build on other new macros, and it all falls appart if you
can not rely on some of those other macros existing because of a time-
jump in el land.

Classical rpm macro argument processing is severely deficient, not even
on par with shell getopts-level of argument processing, let alone the
argparse-level many languages now sport. That creates a huge impedance
mismatch with modern commands that expect more elaborate argument
syntax. You can not drive them from rpm macros, you end up putting lists
of arguments in variables to pass them to commands behind the macro
argument parser. That should be fixed.


If you're discussing things like 3K-character-long java arguments, then 
I agree with you that that's painful. But I fail to see how the core 
needs of any build system (or install system) can be any more complex 
than arbitrary shell, and these sections already *are* arbitrary shell. 
I'd like to never have to tweak CFLAGS= in a %build, but it occasionally 
does happen. That doesn't mean it's a design flaw -- that's why code is 
allowed to be there. In a worst-case-scenario, one can always 
standardize on an external helper to adjust or modify things during 
execution (which has the added benefit of bench-testability and code 
re-use) and use a macro to call that.


I feel like this mirrors the debate between imperative initscripts and 
declarative unit files. Macros are great, and macros calling 
distro-defined helpers work, but a religious purge of shell does not 
really seem to be a win.




Most notably, all the dead-stupid %setup/%sources/Tag
processing, that you know any rpm novice will misunderstand and get
wrong, even before you attempt explanations. Those warts were merely
annoying when dealing with a few thousands of distro packages, they have
a real cost now the distro has grown.
How is this processing "dead-stupid"? I'm seriously asking here. It's 
not difficult, and it shouldn't be too much to ask that someone be able 
to figure out the syntax of a simple recipe file like this. I agree we 
were in an RPM-documentation deadzone for a while there, but I feel like 
there are plenty of examples and guides now for novice RPM users. 
Certainly seems easier to make an .rpm than a .deb.


-jc
___
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: 

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jan Pokorný]

On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> Le 2018-11-19 12:28, Martin Kolman a écrit :
> 
>> Many people might think RAM would not be an issue in 2018, but in
>> practice there are
>> and likely always will be memory constrained installation targets,
>> such as massive deployments
>> of "small" VMs or the IoT use cases mentioned above.
> 
> Sure, that’s the artificial small vm case
> 
> The average old/limited hardware is limited in memory, cpu and storage.
> Therefore if you have one factor to sacrifice it's cpu time because you can
> always let the CPU run a little longer, but a limited system won't magically
> grow more memory or more storage.
> 
> Storage would not be such a problem is dnf was smart enough to auto
> partition big upgrades in lots of small partial upgrades, before downloading
> gigs of data that do not fit on disk.

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

Also, not familiar with zchunk way of doing things, but couldn't
rpm-integrity-verified installed files be mapped back to "chunks"
to further aleviate space concerns for the machine receiving
updates in some cases?

-- 
Jan (Poki)


pgpYjB_2HuJHu.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://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: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Howard Johnson]

On 16/11/2018 22:07, Jonathan Dieter wrote:

The uncompressed local chunks would be combined with the downloaded
compressed chunks to create a local rpm that will pass signature
verification without needing to recompress the uncompressed local
chunks, making this computationally much faster than rebuilding a
deltarpm, a win for users.


It would be really nice if, while changes are being made to RPM for 
this, we could get rid of the local rpm build step and move support for 
applying deltas into RPM itself.  I know this is likely to be a lot more 
involved than only changing the compression scheme, but I really think 
it's worth it.


In fact, a quick poke through the rpm-maint list finds this open RPM RFE 
https://github.com/rpm-software-management/rpm/issues/433 which shows 
that the RPM dev team are open to the idea.


Currently, enabling deltarpms is a trade-off.  If you have faster local 
storage than download, deltas are a win.  If your download is fast 
enough, deltas add more overhead than they save.  A system whereby 
deltas can be applied with the same or less resources on the end host to 
downloading the full RPM is a win for everyone.  Combining that with a 
system whereby the delta is actually just selective range downloads of 
the payload of a "normal" binary RPM is the icing on the Fedora 
Infrastructure cake ;)


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

Orphaing some packages: hdapsd, pg_journal

[Tomasz Torcz]

Hi,

  I've orphaned two of my packages:

– hdapsd - https://src.fedoraproject.org/rpms/hdapsd
  This is daemon for laptops with accelerometer. It detects computer
  falling down and parks HDD head to reduce damage.
  I haven't used a laptop with spinning drive for years, I'm not sure
  if it still works.

– pg_journal - https://src.fedoraproject.org/rpms/pg_journal
  This isi an extension for PostgreSQL, providing better logging into the
  journal. Years passed and it have not been integrated in PgSQL.
  Petr Kubat had a commit right to this package, but only in order to
  recompile it when PgSQL gets updated.

  Feel free to take over if you see any use with this packages.
  Cheers,

-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
___
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

[EPEL-devel] Re: EPEL-8 plans and needed work

[Troy Dawson]

On Sun, Nov 18, 2018 at 11:00 AM Kevin Fenzi  wrote:
>
> On 11/17/18 4:09 PM, Orion Poplawski wrote:
>
> > I'm afraid I'm still very unfamiliar with modules, but it does seem like
> > this will be very central to how we deliver packages to EPEL-8.  My
> > initial questions are:
>
> Yeah, I don't know them as well as I can, but can take a stab at
> answering based on what I know. ;)
>
> And yes, I agree modules will be key for epel8.
> >
> > - Can we "simply" extend the platform for current modules to cover
> > RHEL-8?  That way one could for example deliver octave 4.4 for both
> > Fedora and EPEL-8 at the same time.  The main issue that I see is
> > preventing packages that already exist in RHEL-8 from making it in.
>
> Yes, we hopefully can do that. However, they might need some adjustment
> for epel8 differences.
>
> The 'existing rhel8 packages' brings up a good point: Do we want to care
> about that in epel8 modules? If we replace something thats in a module,
> perhaps thats expected and ok, and just avoid replacing base packages?
>

*my opinion*
I think as long modules don't directly compete name and stream with
RHEL8's, then it should be ok to build and have as a module in EPEL8.

Example:
perl 5.26 (can't be in epel8)
perl 5.26.FavoriteFlag (can be in epel8)
or maybe
perl-FavoriteFlag 5.26 (can be in epel8)

As far as replacing base packages with modules.  My opinion isn't very
stong, but here is what I think.
I'm against replacing BaseOS packages in modules.
I'm ok with replacing AppStream packages in modules.

> > - How do we build against the RHEL-8 modules?  I see that RHEL-8 has two
> > perl and two php module streams:
> >
> > perl  5.24   minimal, default
> > perl  5.26 [d]   minimal, default [d]
> > php   7.1devel, minimal, default [d]
> > php   7.2 [d]devel, minimal, default [d]
> >
> > presumably if I want to builld say perl-Config-Simple for EPEL-8 we'll
> > need/want to build it for both module streams?  How does one go about
> > attaching that package to the RHEL-8 module?  Or will we need separate
> > EPEL versions of the modules?
>
> If you are building a non modular package, right now you cannot build
> against modular packages at all. This is what the 'ursa-major' app that
> releng/fesco are discussing enabling will allow for. Until thats setup,
> non modular builds can't use any modules.
>
> If you are building a modular package, you specify in the module yaml
> file exactly what modules you are building against and what version.
> > - Do we need to distinguish between EPEL packages that will be treated
> > much like BaseOS packages in RHEL (very long lived and stable), and ones
> > that are like the AppStream (shorter lifetimes)?  Do we just want to
> > treat everything like AppStream packages?
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/using_application_stream/using-appstream_using-appstream
>
> I'd say everything like appstream.
> >
> >
> > Some of what I wrote just might not make sense due to my limited
> > understanding of modules.
>
> I could also be wrong above, so hopefully if so someone will correct me.
>
> kevin
>
>
>
> ___
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Summary/Minutes from today's FESCo Meeting (2018-11-19)

[Randy Barlow]

=
#fedora-meeting-1: FESCO (2018-11-19)
=


Meeting started by bowlofeggs at 15:00:00 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2018-11-19/fesco.2018-11-19-15.00.log.html
.



Meeting summary
---
* init process  (bowlofeggs, 15:00:06)

* #1970 Long orphaned packages are not being retired after 6 weeks
  (bowlofeggs, 15:05:53)
  * ACTION: mhroncok volunteers to retire the packages manually and see
what can be automated  (sgallagh, 15:13:26)
  * AGREED: The policy to retire packages after six weeks of being
orphaned is reaffirmed. At least three warnings with one-week
intervals will be sent out to co-maintainers before retiring. (+7,
0, -0)  (bowlofeggs, 15:42:18)
  * AGREED: mhroncok is added as a release engineer to process
unretirement requests (which are still the same process as now, file
ticket, it gets checked, etc) (+6, 1, -0)  (bowlofeggs, 15:42:40)

* #1973 FTBFS package are not being orphaned, nor retired  (bowlofeggs,
  15:43:10)
  * LINK:
https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py
(ignatenkobrain, 15:49:00)
  * ACTION: nirik will add
https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py
to cron  (bowlofeggs, 15:49:33)
  * LINK: https://pagure.io/releng/pull-request/7881   (mhroncok,
15:50:15)

* #2009 libsolv SONAME bump in stable  (bowlofeggs, 15:52:08)

* #2013 to strict rules for branches deletion alongside with norules for
  theirs creations  (bowlofeggs, 15:53:28)

* #2003 Ursa Major (modules in buildroot) enablement  (zbyszek,
  16:07:49)
  * LINK: https://pagure.io/fesco/issue/2003   (zbyszek, 16:07:52)
  * ACTION: contyk to write up a summary in the ticket  (zbyszek,
16:35:11)
  * we'll discuss this in the ticket again  (zbyszek, 16:38:01)

* Next week's chair  (zbyszek, 16:38:59)

* Open Floor  (zbyszek, 16:39:28)
  * elections happen soon  (bowlofeggs, 16:41:23)
  * nominate your favorite person to FESCo
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
(bowlofeggs, 16:41:38)
  * Nomination period is now open. The period ends on 2018-Nov-28 at
23:59:59 UTC.  (zbyszek, 16:42:34)

Meeting ended at 16:46:18 UTC.




Action Items

* mhroncok volunteers to retire the packages manually and see what can
  be automated
* nirik will add
  https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py
  to cron
* contyk to write up a summary in the ticket




Action Items, by person
---
* contyk
  * contyk to write up a summary in the ticket
* mhroncok
  * mhroncok volunteers to retire the packages manually and see what can
be automated
* nirik
  * nirik will add
https://pagure.io/releng/blob/master/f/scripts/mass-rebuild-close-bugs.py
to cron
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* zbyszek (120)
* bowlofeggs (115)
* mhroncok (70)
* sgallagh (58)
* Son_Goku (47)
* nirik (45)
* tyll (33)
* zodbot (22)
* contyk (21)
* jsmith (13)
* pac23 (9)
* mizdebsk (9)
* Pharaoh_Atem (8)
* maxamillion (6)
* ignatenkobrain (5)
* mboddu (3)
* jcline (1)
* jforbes (0)




Generated by `MeetBot`_ 0.1.4

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


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

[EPEL-devel] Re: EPEL7 Bad-Dependencies Tracking Bug

[Troy Dawson]

My apologies for delaying my work on this.
Priorities got shifted so I'm starting this work today.
On Wed, Nov 14, 2018 at 10:50 AM Stephen John Smoogen  wrote:
>
> On Wed, 14 Nov 2018 at 13:00, Troy Dawson  wrote:
> >
> > Here are the list of packages with bad dependencies, their bug URL,
> > and current status.
> > For those that still have "No Comment" tomorrow, I will start going
> > through and fixing.
> > For those that want to be removed, I'll be doing that tomorrow as well.
> >
>
> Thanks. We 'approved' this at the meeting today so go ahead. Thank you
> very much for the work. And I agree with your assessments on package
> that might need removal if needed.
>
> > airinv https://bugzilla.redhat.com/show_bug.cgi?id=1647583
> > - Rebuilt - On QA
> > anjuta https://bugzilla.redhat.com/show_bug.cgi?id=1648003
> > - Rebuilt - On QA
> > banshee https://bugzilla.redhat.com/show_bug.cgi?id=1647999
> > - No Comment
> > beets https://bugzilla.redhat.com/show_bug.cgi?id=1647995
> > - Wants Removed
> > bionetgen https://bugzilla.redhat.com/show_bug.cgi?id=1647989
> > - Rebuilt - On QA
> > cinnamon https://bugzilla.redhat.com/show_bug.cgi?id=1647181
> > - Want Removed
> > cjdns-graph https://bugzilla.redhat.com/show_bug.cgi?id=1647987
> > - Rebuilt - On QA
> > jabber-roster https://bugzilla.redhat.com/show_bug.cgi?id=1647977
> > - No Comment
> > libpeas-loader-python3 https://bugzilla.redhat.com/show_bug.cgi?id=1647973
> > - No Comment
> > notify-sharp3 https://bugzilla.redhat.com/show_bug.cgi?id=1647623
> > - No Comment
> > opensips https://bugzilla.redhat.com/show_bug.cgi?id=1647622
> > - No Comment
> > perl-GTop https://bugzilla.redhat.com/show_bug.cgi?id=1647620
> > - Rebuilt - On QA
> > python-atomic-reactor https://bugzilla.redhat.com/show_bug.cgi?id=1647613
> > - Wants Removed
> > python-django16 https://bugzilla.redhat.com/show_bug.cgi?id=1647611
> > - Rebuilt - On QA
> > python-proliantutils https://bugzilla.redhat.com/show_bug.cgi?id=1647614
> > - No Comment
> > python-adal https://bugzilla.redhat.com/show_bug.cgi?id=1647605
> > - Assigned
> > python-pyfakefs https://bugzilla.redhat.com/show_bug.cgi?id=1647603
> > - No Comment
> > python-pygithub https://bugzilla.redhat.com/show_bug.cgi?id=1647602
> > - No Comment
> > python-yamlordereddictloader 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1647597
> > - No Comment
> > ruby-qpid https://bugzilla.redhat.com/show_bug.cgi?id=1647592
> > - No Comment (I recommend removal)
> > rubygem-apipie-bindings https://bugzilla.redhat.com/show_bug.cgi?id=1647585
> > - Wants Removed
> > simcrs https://bugzilla.redhat.com/show_bug.cgi?id=1647584
> > - Rebuilt - On QA
> > slim https://bugzilla.redhat.com/show_bug.cgi?id=1647581
> > - No Comment
> > xfce4-vala https://bugzilla.redhat.com/show_bug.cgi?id=1647569
> > - Rebuilt - On QA
> > On Thu, Nov 8, 2018 at 1:35 PM Troy Dawson  wrote:
> > >
> > > On Wed, Nov 7, 2018 at 12:56 PM Troy Dawson  wrote:
> > > >
> > > > Hi,
> > > > I'm going through the lists of EPEL7 packages that are not able to be
> > > > installed on RHEL 7.6, and opening bugzilla's for them.  I am keeping
> > > > track of all those bugs with a tracker bug.[1]
> > > > My apologies to the epel-release maintainers for using their package
> > > > for the tracker.
> > > >
> > > > I've only created 6 bugs thus far, and only 1 of those bugs is because
> > > > of RHEL 7.6.
> > > > Because I'm verifying each failed install, and tracking down the basic
> > > > problem, it's taking me a little longer.  It might take a couple of
> > > > days.
> > > > I'll send an email when I'm done.
> > > >
> > > > Troy
> > > >
> > > > [1] - https://bugzilla.redhat.com/show_bug.cgi?id=1647564
> > >
> > > I'm pretty much done for now.
> > > I didn't do any nodejs or golang bugs because all of their failing
> > > dependencies are in EPEL, not RHEL.  Or perhaps I should say they
> > > *aren't* in EPEL :)
> > >
> > > A few numbers
> > >
> > > bugs created for uninstallable EPEL7 packages - 24
> > > nodejs uninstallable packages - 11
> > > golang uninstallable packages - 18
> > >
> > > Total EPEL7 binary packages[2] - 12,547
> > > ^^ Above installable on RHEL 7.6 - 12,043
> > > ^^ Above not installable on RHEL 7.6 - 504
> > >
> > > Why such a big difference between 504 uninstallable binary packages,
> > > but only 53 potential bugs?
> > > 1 - bugs are against source packages.  The bottom checks are against
> > > binary packages.  My guess is that the 50 bugs cover about 150 binary
> > > packages because each source can have more than one package.  And when
> > > I was looking at the packages, it looked like about an average of
> > > three binaries per source.
> > > 2 - repoquery (used to generate the bug list) went to the heart of the
> > > problems.  So if package A is uninstallable, and package B depends on
> > > A.  We don't file a bug for package B, only A.  For some of those
> > > nodejs packages, I've seen one package A with a bad dependency, cause
> > > 25 to 50 package B's, 

[EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata possibly incorrect

[John Griffin]

Hello Stephen,

Here is RH’s reply on the query as to how RH Satellite parses RPMs for date 
base filters.


Hi John, I got some information for you. Errata filter based on date does not 
scan RPMs, but scan errata (update or create) date and exclude/include all rpms 
which this specific errata contains. Does this help in the process?

Re:
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
jgrif...@samhealth.org



From: John Griffin
Sent: Monday, November 5, 2018 8:34 AM
To: EPEL Development List 
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata 
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR 
OPEN ATTACHMENTS unless you recognize the sender and know the contents are safe.



Hello Stephen,

We mirror the EPEL5 and EPEL7 repositories, but I really don’t know if there 
are other issues with those or EPEL6. The only reason I stumbled upon this one 
was due to the fact that the munin update in Sept 2018 now requires 
conntrack-tools. There may be others, and this also maybe be the only one.

I will request from RH the technical details they use when applying date 
filters in Satellite, maybe with that I can scan the other RPM’s in our mirrors 
for other hits.

Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
jgrif...@samhealth.org



From: Stephen John Smoogen mailto:smo...@gmail.com>>
Sent: Thursday, November 1, 2018 2:04 PM
To: 
epel-devel@lists.fedoraproject.org
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata 
possibly incorrect





WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR 
OPEN ATTACHMENTS unless you recognize the sender and know the contents are safe.




On Thu, 1 Nov 2018 at 16:46, John Griffin 
mailto:jgrif...@samhealth.org>> wrote:

Hello Stephen,



Yes, we have the conntrack-tools in our Red Hat Satellite repository, and we 
can apply it outside of our Satellite process; by manually copying the rpm to 
each server and installing outside of our process.



The issue is the interworking of the metatdata in the conntrack-tools RPM and 
Red Hat Satellite date filters for Content Views. Not sure how familiar you are 
with Red Hat Satellite, but the data filters are the primary method used to 
create a cyclical patching schedule and thus patch sets based on date.



In Red Hat Satellite, if I specify any date inclusion (Like from January 1, 
1970 - October 12, 2018) and point it at the EPEL6 repository the filter does 
not pick up the conntrack-tools. I opened support case with Red Hat, and with 
their assistance we have a work around, where we don't specify any Satellite 
date filters for the EPEL repositories (i.e. Get Everything no matter when 
released) and yes still keep the Satellite date filters on the official Red Hat 
repositories used to create the combined  Satellite content view.



However this work-around does not allow us to recreate a patch content view of 
EPEL product or patches of any date other than 'today'. Without a date filter 
we get all EPEL content and patches. This does not work with our Patching 
paradigm, as we base patch sets on Date. We then use life-cycle management to 
promote a patch set to Production after it has been vetted on Dev then Test.



Red Hat does not support EPEL, and indicated this is not a Satellite issue but 
a RPM metadata issue with EPEL release process.


I will check but I am not sure it is a problem we can solve quickly as I don't 
know how Satellite categorizes dates currently. Do you also mirror anything 
from other non Red Hat Network repositories and do they have the problem also? 
[I am mostly looking to see if we are not setting something up we should or not]



Let me know if you need further clarification.



Best Regards,
[cid:image005.jpg@01D24A1F.439697B0]
John Griffin | Infrastructure Architect
815 NW 9th Street, Ste 221  |  Corvallis, OR 97330
P 541-768-4707
jgrif...@samhealth.org








-Original Message-
From: Stephen John Smoogen mailto:smo...@gmail.com>>
Sent: Wednesday, October 31, 2018 2:14 PM
To: 
epel-devel@lists.fedoraproject.org
Subject: [EPEL-devel] Re: EPEL6 conntrack-tools-0.9.13-3.el6.x86_64 metadata 
possibly incorrect



WARNING: This email originated from outside of SHS.  DO NOT CLICK ANY LINKS OR 
OPEN ATTACHMENTS unless you recognize the sender and know the contents are safe.

On Wed, 31 Oct 2018 at 16:01, John Griffin 
mailto:jgrif...@samhealth.org>> wrote:

>

> We now use Red Hat Satellite 6.3 and have it synchronizing to

> https://dl.fedoraproject.org/pub/epel/6Server/

>

> Recent 

[rpms/perltidy] New Commits To "rpms/perltidy" (master)

[pagure]

The following commits were pushed to the repo rpms/perltidy on branch
master, which you are following:
ead4489b3f8f65e7936e79b592d27548198d675dPaul HowarthUpdate to 20181120 
(see CHANGES.md for details)



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perltidy/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Mátyás Selmeci]

On 11/16/18 5:17 PM, Jason L Tibbitts III wrote:
>> "MM" == Matthew Miller  writes:
> 
> MM> It's the fundamental contradiction that all operating systems face:
> MM> users complain "too fast and too slow!" at the same time.
> 
> Well, then lengthening the Fedora lifecycle does not seem to me to be
> the real solution.  Instead, I think, it's to piggyback onto the already
> long RHEL lifecycle but provide isolated pieces of "instability"
> (i.e. new stuff) to people who want them.
> 
> Or more simply, don't try to slow Fedora down.  Let Fedora be Fedora and
> instead leverage Fedora to speed RHEL up in selected areas where people
> want it.
> 
> MM> As noted elsewhere in this thread, many packagers are already doing
> MM> this: maintaining a slow stream for EPEL or for RHEL as part of
> MM> their day job, and a fast stream in Fedora.
> 
> So let RHEL be the core bits, moving as fast or as slow as Red Hat wants
> to support.  And let someone who wants "the new stuff" layer things over
> that.  Fedora could provide the layers, which move as fast as Fedora
> does.
> 
> Of course, the practicalities of that and the potential combinatorial
> explosion of options and interdependencies might render the whole idea
> pointless.  But that's supposed to be what the whole module system
> solves.  Or is it the flatpak system?  Maybe both.  And I believe those
> are both conveniently supported by RHEL8.
So basically something EPEL-like that doesn't have the "don't mess
with the base OS" restriction?  That would be really nice.  The long
time between RHEL releases (which seems to be getting worse, too)
makes supporting it a real pain for my group.

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
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: NSS package consolidation

[Daiki Ueno]

Robert-André Mauchin  writes:

>> https://copr.fedorainfracloud.org/coprs/ueno/nss-consolidate/

> Could we also remove the old cruft?

Thank you!  I have updated the PR based on the suggestions.

>  - Consider using a URL for Source0:
>
> Source0:  https://hg.mozilla.org/projects/nss/archive/%
> {nss_tag}.tar.gz

That really makes sense, though I'd like to use the URLs from the
upstream release announcements, that are in the form:
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/%{nss_tag}/src/%{name}-%{nss_archive_version}.tar.gz

Regards,
-- 
Daiki Ueno
___
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: [EPEL-devel] rhel 8 beta mock configs and EOLed mock configs

[Miroslav Suchý]

Dne 16. 11. 18 v 23:45 Orion Poplawski napsal(a):
> On 11/15/18 3:05 PM, Miroslav Suchy wrote:
>> Hi,
>> I just released [1] new mock-core-config package which include new
>> rhelbeta-8-* configs.
>> This will allows you to build packages on top of RHEL 8 Beta. This is
>> temporary config. I put them there so you can experiment with your
>> builds and prepare for EPEL 8 once it will be available.
>> This config will be removed when Beta ends.
> 
> I had trouble with using it with a bootstrap configuration because there is no
> distribution-gpg-keys package available, which led to:
> 
> Curl error (37): Couldn't read a file:// file for
> file:///usr/share/distribution-gpg-keys/redhat/RPM-GPG-KEY-redhat8-beta
> [Couldn't open file
> /usr/share/distribution-gpg-keys/redhat/RPM-GPG-KEY-redhat8-beta]
> 
> I ended up adding:
> 
> config_opts['dnf_install_command'] = 'install dnf dnf-plugins-core
> https://kojipkgs.fedoraproject.org//packages/distribution-gpg-keys/1.26/1.el7/noarch/distribution-gpg-keys-1.26-1.el7.noarch.rpm'

I hit this as well. This happened to me as well when you enable bootstrap.
One option is to modify 'dnf_install_command' (until EPEL is available) or to 
disable bootstrap.

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

[rpms/perl-Devel-Cycle] New Commits To "rpms/perl-Devel-Cycle" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Devel-Cycle on branch
master, which you are following:
abe47936b360bf083cef4008c2ecb24bdc6d1b11Paul HowarthSpecify all build 
dependencies



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Devel-Cycle/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651148] Upgrade perl-Event to 1.27

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Event-1.27-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-19 09:09:19



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

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

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Miroslav Suchý]

Dne 16. 11. 18 v 23:07 Jonathan Dieter napsal(a):
>1. Downloading a new release of a zchunked rpm would be larger than
>   downloading the equivalent deltarpm.  This is offset by the fact
>   that the client is able to work out which chunks it needs no matter
>   what the original rpm is, rather than needing a specific original
>   rpm as deltarpm does.

Does this means bigger requirements for copies of RPMs too? I mean for all our 
repos mirros, for RH Satellites,
Spacewalk, Koji, Copr, Retrace...

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

[rpms/perl-Event] New Commits To "rpms/perl-Event" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Event on branch
master, which you are following:
3e169303735fa1fcdb73c6b165f766d37965Paul HowarthUpdate to 1.27



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Event/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Matthew Miller]

On Sun, Nov 18, 2018 at 07:02:24AM -, Leigh Scott wrote:
> +1 to anything to rid me of deltarpms, I currently have to disable this lame 
> default.

Leigh, it may be "lame" to you, but it's important to many people with
bandwidth limitations or slower connections. There's always room for
improvement but let's please not talk about other people's work in this way.
Thank you.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

Schedule for today's FESCo Meeting (2018-11-19)

[Randy Barlow]

Following is the list of topics that will be discussed in the
FESCo meeting Monday (today) at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2018-11-19 15:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =
F30 System-Wide Change: New 128-bit IEEE long double ABI for IBM 64-bit POWER LE
https://pagure.io/fesco/issue/1981
ACCEPTED (+6, 0, -0)

F30 Change: Pantheon Desktop
https://pagure.io/fesco/issue/2010
ACCEPTED (+5, 0, -0)


= Followups =

#topic #1970 Action needed: Orphan packages will be retired if they remain 
orphaned for six weeks
https://pagure.io/fesco/issue/1970

#topic #1973 The FTBFS cleanup policy is not happening
https://pagure.io/fesco/issue/1973

#topic #2003 Ursa Major (modules in buildroot) enablement
https://pagure.io/fesco/issue/2003


= New business =

#topic #2009 libsolv SONAME bump in stable
https://pagure.io/fesco/issue/2009

#topic #2013 to strict rules for branches deletion alongside with
norules for theirs creations
https://pagure.io/fesco/issue/2013


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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

[rpms/perl-ExtUtils-Config] New Commits To "rpms/perl-ExtUtils-Config" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-ExtUtils-Config on 
branch
master, which you are following:
78c446fbf43604ec25b25d26195ae4e4267d3553Paul HowarthPackage clean-up



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-ExtUtils-Config/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[rpms/perl-ExtUtils-Helpers] New Commits To "rpms/perl-ExtUtils-Helpers" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-ExtUtils-Helpers on 
branch
master, which you are following:
62927958914f8f2294523380ea446234d4be481cPaul HowarthDrop EL-5 support



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-ExtUtils-Helpers/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Nicolas Mailhot]

Le 2018-11-19 12:28, Martin Kolman a écrit :


Many people might think RAM would not be an issue in 2018, but in
practice there are
and likely always will be memory constrained installation targets,
such as massive deployments
of "small" VMs or the IoT use cases mentioned above.


Sure, that’s the artificial small vm case

The average old/limited hardware is limited in memory, cpu and storage. 
Therefore if you have one factor to sacrifice it's cpu time because you 
can always let the CPU run a little longer, but a limited system won't 
magically grow more memory or more storage.


Storage would not be such a problem is dnf was smart enough to auto 
partition big upgrades in lots of small partial upgrades, before 
downloading gigs of data that do not fit on disk.


Regards,

--
Nicolas Mailhot
___
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

[Bug 1651147] Upgrade perl-DBD-MySQL to 4.049

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-DBD-MySQL-4.049-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-19 06:39:12



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

[rpms/perl-DBD-MySQL] New Commits To "rpms/perl-DBD-MySQL" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-DBD-MySQL on branch
master, which you are following:
5b0dba690e8b5e4d59c78f83f870c35d8d003557Jitka Plesnikova4.049 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-DBD-MySQL/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651167] Upgrade perl-Test-POE-Client-TCP to 1.26

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-POE-Client-TCP-1.
   ||26-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-19 06:34:41



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 30.

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

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Martin Kolman]

On Mon, 2018-11-19 at 11:41 +0100, Sheogorath wrote:
> On 11/18/18 7:19 PM, Stephen John Smoogen wrote:
> > On Sun, 18 Nov 2018 at 12:49, Neal Gompa  wrote:
> > > On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter  
> > > wrote:
> > > > On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
> > > > > Jonathan Dieter wrote:
> > > > > > My proposal would be to make zchunk the rpm compression format for
> > > > > > Fedora.
> > > > > 
> > > > > Given that:
> > > > > 1. zchunk is based on zstd, which is typically less efficient in 
> > > > > terms of
> > > > >compression ratio than xz, depending on settings
> > > > >(see, e.g., https://github.com/inikep/lzbench), and
> > > > > 2. zchunk can by design only compress chunks individually and not 
> > > > > benefit
> > > > >from the space savings of a solid archive with a global dictionary,
> > > > > I fear that this is going to significantly increase the size of the 
> > > > > RPMs,
> > > > > which matters:
> > > > > * for the initial downloads,
> > > > > * for storage (e.g., keepcache=1, local mirrors, etc.), and
> > > > > * for the people not using deltas for whatever reason.
> > > > > 
> > > > > I think zchunk makes a lot of sense for the metadata, but I am not 
> > > > > convinced
> > > > > that it is the right choice for the RPMs themselves.
> > > > 
> > > > I suspect the first is true, but zchunk does actually allow for a
> > > > global (per-file) dictionary that can be used to compress each chunk.
> > > > The difficulty is that the dictionary has to stay the same between file
> > > > versions, or the chunk checksums won't match.  There would have to be
> > > > some thought put into how to generate and store the dictionaries.
> > > > 
> > > > As for how much bigger a zchunked rpm will be compared to an xz rpm, at
> > > > the moment it's a bit hand-wavy.  Based on zchunked repodata work I've
> > > > done, I think we might be looking at a size that's slightly smaller
> > > > than a gzipped rpm.  I won't know for sure until I put together a
> > > > proof-of-concept, but I want to make sure that there aren't any gaping
> > > > holes in the proposal before I do that.
> > > > 
> > > 
> > > I did some work several months ago to evaluate zstd compression for
> > > RPMs for Fedora, because of the lower memory and CPU usage for
> > > (de)compression. However, the average size increase from xz was pretty
> > > large (~20% or more on average, and nothing ever was either the same
> > > or smaller), even with heavier compression settings. That might have
> > > changed a bit with newer zstd releases that offer some more tunables,
> > > but I think it'll remain a tough sell on disk space.
> > 
> > So there are at least 4 legs here:
> > CPU usage (in both uncompression install and deltarpm)
> > Memory usage per transaction
> > Network amount
> > Disk amount
> > 
> > I expect that the best we are going to get in any 'improvement' is
> > going to be 3 out of the 4. The xz compression and delta-rpm has a
> > cpu/memory tradeoff for disk and network in comparison to gzip but it
> > is mostly acceptable if you have fairly modern desktops. However for
> > older hardware or lower power systems that tradeoff may not be good.
> > 
> 
> Good point. Given that we start to have Fedora IoT we have to look at
> those creatures. IoT devices hate heavy RAM usage, hate disk usage are
> half way okay with CPU usage (but keep in mind it may take an hour to
> decompress) and depending on the upstream, either use mobile data for
> networking or when you're lucky some WiFi/Bluetooth/… thing.
> 
> Means:
> CPU usage: Getting worse here, doesn't hurt too much
> Memory usage: Don't! Get! Worse!
> Network amount: Well, people wouldn't be happy when it gets worse, but
> mobile data gets cheaper every day.
> Disk amount: People won't be happy with an increase here, but as long as
> it stays somewhere within 10% it's fine, more than 20% would already
> hurt a lot.
> 
I'd like to add another perspective - network installations.

During a network installation of Fedora, the installer can only use the 
available RAM
to both run and store and data it needs before starting the installation. 
Only after the installation is startedf and storage is partitioned, it can
(if the system has a swap partition) relieve some of the memory pressure to
persistent storage.

Many people might think RAM would not be an issue in 2018, but in practice 
there are
and likely always will be memory constrained installation targets, such as 
massive deployments
of "small" VMs or the IoT use cases mentioned above.

So even though a network installation process is unlikely to actually do
delta package reconstructions against an older version, it would bee good
if memory requirements just for simple non-delta download, verification and
package installation would remain sane.


> So when we want to revisit RPM, we should keep our new fellows in mind.
> Maybe we get some OSTree magic going? There we already see deltas
> 

[rpms/perl-Test-POE-Client-TCP] New Commits To "rpms/perl-Test-POE-Client-TCP" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Test-POE-Client-TCP on 
branch
master, which you are following:
d1c8b1f79f09276cf1ef7a69078441b83cfa7a19Petr PísařCache 1.26 sources



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Test-POE-Client-TCP/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651168] Upgrade perl-TestML to 0.55

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |DUPLICATE
Last Closed||2018-11-19 06:27:51



--- Comment #1 from Petr Pisar  ---


*** This bug has been marked as a duplicate of bug 1650156 ***

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

[Bug 1650156] Upgrade perl-TestML to 0.55

[bugzilla]

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



--- Comment #4 from Petr Pisar  ---
*** Bug 1651168 has been marked as a duplicate of this bug. ***

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

[rpms/perl-Test-POE-Client-TCP] New Commits To "rpms/perl-Test-POE-Client-TCP" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Test-POE-Client-TCP on 
branch
master, which you are following:
d83cf165a3cb5a9bbf65a7752bddc4ec9e12bc84Petr Písař1.26 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Test-POE-Client-TCP/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-FFI-CheckLib-0.23-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-743cb3ece4

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

[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-FFI-CheckLib-0.23-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-d8d7c922cc

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

[rpms/perl-FFI-CheckLib] New Commits To "rpms/perl-FFI-CheckLib" (f28)

[pagure]

The following commits were pushed to the repo rpms/perl-FFI-CheckLib on branch
f28, which you are following:
2e34a50fad737b6e6cefac0339595ca45904f012Petr Písař0.23 bump
aba2725f1cf22de6ba3f09128d60c8eb6b24ec2dJitka Plesnikova0.22 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-FFI-CheckLib/commits/f28
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[rpms/perl-FFI-CheckLib] New Commits To "rpms/perl-FFI-CheckLib" (f29)

[pagure]

The following commits were pushed to the repo rpms/perl-FFI-CheckLib on branch
f29, which you are following:
35a92059c436fb408d77546c83cec236546dca3cPetr Písař0.23 bump
ae072bbac9701f5c63d952b97b067da94ef87b60Jitka Plesnikova0.22 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-FFI-CheckLib/commits/f29
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651151] Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-FFI-CheckLib-0.23-1.fc
   ||30



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 28.

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

[rpms/perl-FFI-CheckLib] New Commits To "rpms/perl-FFI-CheckLib" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-FFI-CheckLib on branch
master, which you are following:
35a92059c436fb408d77546c83cec236546dca3cPetr Písař0.23 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-FFI-CheckLib/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651146] Upgrade perl-CBOR-XS to 1.71

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CBOR-XS-1.71-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-19 06:04:22



--- Comment #1 from Petr Pisar  ---
This seems like a bug-fix release (exception in callbacks causes by perl) but
safer for Rawhide only.

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

[Bug 1651161] Upgrade perl-Graphics-ColorNames to 3.4.0

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Graphics-ColorNames-3.
   ||4.0-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-11-19 06:02:03



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

[rpms/perl-Graphics-ColorNames] New Commits To "rpms/perl-Graphics-ColorNames" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Graphics-ColorNames on 
branch
master, which you are following:
c807905593906b3c84dc56530e2ef2f2ead7a411Jitka Plesnikova3.4.0 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Graphics-ColorNames/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1651168] New: Upgrade perl-TestML to 0.55

[bugzilla]

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

Bug ID: 1651168
   Summary: Upgrade perl-TestML to 0.55
   Product: Fedora
   Version: rawhide
 Component: perl-TestML
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 0.54.05 version. Upstream released 0.55. When you have
free time, please upgrade it.

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

[Bug 1651167] New: Upgrade perl-Test-POE-Client-TCP to 1.26

[bugzilla]

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

Bug ID: 1651167
   Summary: Upgrade perl-Test-POE-Client-TCP to 1.26
   Product: Fedora
   Version: rawhide
 Component: perl-Test-POE-Client-TCP
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: andrea.v...@gmail.com,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 1.24 version. Upstream released 1.26. When you have free
time, please upgrade it.

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

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Sheogorath]

On 11/18/18 7:19 PM, Stephen John Smoogen wrote:
> On Sun, 18 Nov 2018 at 12:49, Neal Gompa  wrote:
>>
>> On Sun, Nov 18, 2018 at 11:54 AM Jonathan Dieter  wrote:
>>>
>>> On Sat, 2018-11-17 at 22:30 +0100, Kevin Kofler wrote:
 Jonathan Dieter wrote:
> My proposal would be to make zchunk the rpm compression format for
> Fedora.

 Given that:
 1. zchunk is based on zstd, which is typically less efficient in terms of
compression ratio than xz, depending on settings
(see, e.g., https://github.com/inikep/lzbench), and
 2. zchunk can by design only compress chunks individually and not benefit
from the space savings of a solid archive with a global dictionary,
 I fear that this is going to significantly increase the size of the RPMs,
 which matters:
 * for the initial downloads,
 * for storage (e.g., keepcache=1, local mirrors, etc.), and
 * for the people not using deltas for whatever reason.

 I think zchunk makes a lot of sense for the metadata, but I am not 
 convinced
 that it is the right choice for the RPMs themselves.
>>>
>>> I suspect the first is true, but zchunk does actually allow for a
>>> global (per-file) dictionary that can be used to compress each chunk.
>>> The difficulty is that the dictionary has to stay the same between file
>>> versions, or the chunk checksums won't match.  There would have to be
>>> some thought put into how to generate and store the dictionaries.
>>>
>>> As for how much bigger a zchunked rpm will be compared to an xz rpm, at
>>> the moment it's a bit hand-wavy.  Based on zchunked repodata work I've
>>> done, I think we might be looking at a size that's slightly smaller
>>> than a gzipped rpm.  I won't know for sure until I put together a
>>> proof-of-concept, but I want to make sure that there aren't any gaping
>>> holes in the proposal before I do that.
>>>
>>
>> I did some work several months ago to evaluate zstd compression for
>> RPMs for Fedora, because of the lower memory and CPU usage for
>> (de)compression. However, the average size increase from xz was pretty
>> large (~20% or more on average, and nothing ever was either the same
>> or smaller), even with heavier compression settings. That might have
>> changed a bit with newer zstd releases that offer some more tunables,
>> but I think it'll remain a tough sell on disk space.
> 
> So there are at least 4 legs here:
> CPU usage (in both uncompression install and deltarpm)
> Memory usage per transaction
> Network amount
> Disk amount
> 
> I expect that the best we are going to get in any 'improvement' is
> going to be 3 out of the 4. The xz compression and delta-rpm has a
> cpu/memory tradeoff for disk and network in comparison to gzip but it
> is mostly acceptable if you have fairly modern desktops. However for
> older hardware or lower power systems that tradeoff may not be good.
> 

Good point. Given that we start to have Fedora IoT we have to look at
those creatures. IoT devices hate heavy RAM usage, hate disk usage are
half way okay with CPU usage (but keep in mind it may take an hour to
decompress) and depending on the upstream, either use mobile data for
networking or when you're lucky some WiFi/Bluetooth/… thing.

Means:
CPU usage: Getting worse here, doesn't hurt too much
Memory usage: Don't! Get! Worse!
Network amount: Well, people wouldn't be happy when it gets worse, but
mobile data gets cheaper every day.
Disk amount: People won't be happy with an increase here, but as long as
it stays somewhere within 10% it's fine, more than 20% would already
hurt a lot.

So when we want to revisit RPM, we should keep our new fellows in mind.
Maybe we get some OSTree magic going? There we already see deltas
between versions and we get chunks.

-- 
Signed
Sheogorath



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

[EPEL-devel] Re: EPEL 8 beta ?

[Xavier Bachelot]

Le 17/11/2018 à 17:02, Stephen John Smoogen a écrit :

On Fri, 16 Nov 2018 at 06:21, Xavier Bachelot  wrote:


Hi,

Now that RHEL 8 beta is out, is there any plan to have some sort of EPEL
8 beta for people willing to prepare for the real RHEL 8 in advance ?



Thanks Xavier,

I put out an email yesterday on this. I would like to get some ideas
on what people want from EPEL-8 but I think people also have to see
what RHEL-8 has and how it works to see what changes EPEL may need to
make to keep up with it.


Thanks Smooge. I see other more specific mails thread are starting to 
pop up about EPEL8, I'll make sure to follow them.


My primary intend for asking is EPEL is needed by a well known third 
party repository which is providing packages which cannot be provided by 
Fedora and EL for various reasons. On the EL side, this repo is building 
up over EPEL, hence the question.


Regards,
Xavier
___
epel-devel mailing list -- epel-de...@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-de...@lists.fedoraproject.org

[Bug 1651166] New: Upgrade perl-Net-DNS to 1.19

[bugzilla]

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

Bug ID: 1651166
   Summary: Upgrade perl-Net-DNS to 1.19
   Product: Fedora
   Version: rawhide
 Component: perl-Net-DNS
  Assignee: pwout...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
mbar...@fastmail.com,
perl-de...@lists.fedoraproject.org,
pwout...@redhat.com, rhug...@redhat.com,
rstr...@redhat.com, sandm...@redhat.com



Latest Fedora delivers 1.18 version. Upstream released 1.19. When you have free
time, please upgrade it.

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

[Bug 1651164] New: Upgrade perl-Mojolicious to 8.07

[bugzilla]

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

Bug ID: 1651164
   Summary: Upgrade perl-Mojolicious to 8.07
   Product: Fedora
   Version: rawhide
 Component: perl-Mojolicious
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr,
perl-de...@lists.fedoraproject.org,
robinlee.s...@gmail.com, yan...@declera.com



Latest Fedora delivers 8.06 version. Upstream released 8.07. When you have free
time, please upgrade it.

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

[Bug 1651162] New: Upgrade perl-Mail-SPF-Iterator to 1.119

[bugzilla]

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

Bug ID: 1651162
   Summary: Upgrade perl-Mail-SPF-Iterator to 1.119
   Product: Fedora
   Version: rawhide
 Component: perl-Mail-SPF-Iterator
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-de...@lists.fedoraproject.org



Latest Fedora delivers 1.118 version. Upstream released 1.119. When you have
free time, please upgrade it.

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

[Bug 1651161] New: Upgrade perl-Graphics-ColorNames to 3.4.0

[bugzilla]

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

Bug ID: 1651161
   Summary: Upgrade perl-Graphics-ColorNames to 3.4.0
   Product: Fedora
   Version: rawhide
 Component: perl-Graphics-ColorNames
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-de...@lists.fedoraproject.org, st...@silug.org



Latest Fedora delivers 3.3.4 version. Upstream released 3.4.0. When you have
free time, please upgrade it.

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

[rpms/perl-CBOR-XS] New Commits To "rpms/perl-CBOR-XS" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-CBOR-XS on branch
master, which you are following:
bcbf2b8b6f5017e0364fa3ac92383872cdee0723Petr Písař0.71 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-CBOR-XS/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Nicolas Mailhot]

Le 2018-11-19 10:31, Gerd Hoffmann a écrit :


caches:  doesn't look so good.  squid can't store chunks of a file.


For range request caching you probably want apache traffic server (ATS), 
not squid, as cache layer.


The video guys implemented lots if range request magic in the cache tech 
they use.


--
Nicolas Mailhot
___
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

[Bug 1651151] New: Upgrade perl-FFI-CheckLib to 0.23

[bugzilla]

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

Bug ID: 1651151
   Summary: Upgrade perl-FFI-CheckLib to 0.23
   Product: Fedora
   Version: rawhide
 Component: perl-FFI-CheckLib
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 0.22 version. Upstream released 0.23. When you have free
time, please upgrade it.

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

[Bug 1651148] New: Upgrade perl-Event to 1.27

[bugzilla]

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

Bug ID: 1651148
   Summary: Upgrade perl-Event to 1.27
   Product: Fedora
   Version: rawhide
 Component: perl-Event
  Assignee: p...@city-fan.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-de...@lists.fedoraproject.org,
steve.tray...@cern.ch



Latest Fedora delivers 1.26 version. Upstream released 1.27. When you have free
time, please upgrade it.

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

[Bug 1651147] New: Upgrade perl-DBD-MySQL to 4.049

[bugzilla]

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

Bug ID: 1651147
   Summary: Upgrade perl-DBD-MySQL to 4.049
   Product: Fedora
   Version: rawhide
 Component: perl-DBD-MySQL
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com,
john.j5l...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mbar...@fastmail.com,
perl-de...@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com



Latest Fedora delivers 4.048 version. Upstream released 4.049. When you have
free time, please upgrade it.

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

[Bug 1651146] New: Upgrade perl-CBOR-XS to 1.71

[bugzilla]

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

Bug ID: 1651146
   Summary: Upgrade perl-CBOR-XS to 1.71
   Product: Fedora
   Version: rawhide
 Component: perl-CBOR-XS
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, perl-de...@lists.fedoraproject.org,
ppi...@redhat.com



Latest Fedora delivers 1.7 version. Upstream released 1.71. When you have free
time, please upgrade it.

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

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Gerd Hoffmann]

On Sat, Nov 17, 2018 at 02:43:23PM -0600, Chris Adams wrote:
> Once upon a time, Jonathan Dieter  said:
> > The benefit of zchunked rpms is that, when downloading an updated rpm,
> > you would only need to download the chunks that have changed from
> > what's on your system.
> 
> How well do web servers and caches handle range requests?

web servers:  not much of a problem.

caches:  doesn't look so good.  squid can't store chunks of a file.  So
the options you have are:

  (a) configure squid to pass through range requests to the original
  server.  Which kills any caching.
  (b) configure squid to fetch the whole file no matter what.
  Subsequent requests (including range requests) will be served
  from cache then, but zchunked rpms wouldn't save any bandwidth
  then.

cheers,
  Gerd
___
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

[rpms/perl-Pegex] New Commits To "rpms/perl-Pegex" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Pegex on branch
master, which you are following:
a5bb6d3bbb8f0af7eb45c89e5fc59670ea41d558Petr PísařRemove perl_bootstrap 
code because perl-TestML >= 0.54.05 does not require perl-Pegex
1072b01868e89560c09a1ae274ecd27f568c8e98Petr PísařDo not depend on 
bundled TestML



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Pegex/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[Bug 1612860] perl-Net-Pcap-0.18-9.fc29 FTBFS: stubs.inc:357:8: error: redefinition of 'struct pcap_rmtauth'

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Net-Pcap-0.18-7.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-f4fa442797

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

[Bug 1612860] perl-Net-Pcap-0.18-9.fc29 FTBFS: stubs.inc:357:8: error: redefinition of 'struct pcap_rmtauth'

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |MODIFIED



--- Comment #7 from Fedora Update System  ---
perl-Net-Pcap-0.18-8.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-b29814d978

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

[rpms/perl-Net-Pcap] New Commits To "rpms/perl-Net-Pcap" (f27)

[pagure]

The following commits were pushed to the repo rpms/perl-Net-Pcap on branch
f27, which you are following:
904c3be3375e4170005e3a0438f6df4be64a41dcJitka PlesnikovaFix build with 
libpcap-1.9.0 (bug #1612860)



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Net-Pcap/commits/f27
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

Fedora Rawhide-20181118.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

New failures (same test did not fail in Rawhide-20181117.n.0):

ID: 309823  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/309823
ID: 309824  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/309824
ID: 309841  Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/309841
ID: 309842  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/309842
ID: 309845  Test: x86_64 Workstation-live-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/309845
ID: 309857  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/309857
ID: 309923  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/309923
ID: 309933  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/309933
ID: 309948  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/309948

Old failures (same test failed in Rawhide-20181117.n.0):

ID: 309810  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/309810
ID: 309832  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/309832
ID: 309848  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/309848
ID: 309851  Test: x86_64 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/309851
ID: 309852  Test: x86_64 Workstation-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/309852
ID: 309855  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/309855
ID: 309871  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/309871
ID: 309876  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/309876
ID: 309892  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/309892
ID: 309893  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/309893
ID: 309943  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/309943
ID: 309944  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/309944
ID: 309976  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/309976

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

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

ID: 309854  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/309854
ID: 309858  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/309858

Old soft failures (same test soft failed in Rawhide-20181117.n.0):

ID: 309833  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/309833
ID: 309834  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/309834
ID: 309906  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/309906
ID: 309909  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/309909
ID: 309931  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/309931
ID: 309971  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/309971
ID: 309972  Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/309972

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

New passes (same test did not pass in Rawhide-20181117.n.0):

ID: 309825  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/309825
ID: 309839  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/309839
ID: 309904  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/309904
ID: 309938  Test: x86_64 universal install_rescue_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/309938
ID: 309970  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/309970

Skipped openQA tests: 16 of 168

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed 

[rpms/perl-Net-Pcap] New Commits To "rpms/perl-Net-Pcap" (f28)

[pagure]

The following commits were pushed to the repo rpms/perl-Net-Pcap on branch
f28, which you are following:
3d386274b9372b356ebd9f299adc4afcbb8a281dJitka PlesnikovaFix build with 
libpcap-1.9.0 (bug #1612860)



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Net-Pcap/commits/f28
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[rpms/perl-Template-Toolkit-Simple] New Commits To "rpms/perl-Template-Toolkit-Simple" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Template-Toolkit-Simple 
on branch
master, which you are following:
861eb81b822b0494ec21008d7b86aee95ee39570Petr PísařModernize spec file
740ecd7861b7f607c895195b4e8af8e386087243Petr PísařOld TestML API moved 
to TestML1 name space



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Template-Toolkit-Simple/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org

[rpms/perl-Swim] New Commits To "rpms/perl-Swim" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Swim on branch
master, which you are following:
0bfd5a6df0a35bfeb0bb3ca463fc814c676938cbPetr PísařModernize spec file
c1269ffa8203b0df3860920711b7c1ef714fd316Petr PísařOld TestML API moved 
to TestML1 name space



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Swim/commits/master
___
perl-devel mailing list -- perl-de...@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-de...@lists.fedoraproject.org