date:20200915

No missing expected images.

Failed openQA tests: 5/181 (x86_64)

New failures (same test not failed in Fedora-33-20200914.n.0):

ID: 667299  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/667299
ID: 667302  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/667302
ID: 667399  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/667399
ID: 667402  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/667402

Old failures (same test failed in Fedora-33-20200914.n.0):

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

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

Old soft failures (same test soft failed in Fedora-33-20200914.n.0):

ID: 667220  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/667220
ID: 667239  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/667239
ID: 667266  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/667266
ID: 667279  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/667279
ID: 667316  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/667316
ID: 667329  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/667329
ID: 667350  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/667350

Passed openQA tests: 160/181 (x86_64)

Skipped non-gating openQA tests: 9 of 181

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.14 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/664423#downloads
Current test data: https://openqa.fedoraproject.org/tests/667228#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
System load changed from 0.17 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/664456#downloads
Current test data: https://openqa.fedoraproject.org/tests/667261#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 29 MiB to 32 MiB
System load changed from 1.26 to 0.85
Previous test data: https://openqa.fedoraproject.org/tests/664458#downloads
Current test data: https://openqa.fedoraproject.org/tests/667263#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.74 to 0.89
Previous test data: https://openqa.fedoraproject.org/tests/664460#downloads
Current test data: https://openqa.fedoraproject.org/tests/667265#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used swap changed from 11 MiB to 12 MiB
Previous test data: https://openqa.fedoraproject.org/tests/664477#downloads
Current test data: https://openqa.fedoraproject.org/tests/667282#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used swap changed from 14 MiB to 12 MiB
System load changed from 1.04 to 0.88
Previous test data: https://openqa.fedoraproject.org/tests/664478#downloads
Current test data: https://openqa.fedoraproject.org/tests/667283#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used swap changed from 3 MiB to 5 MiB
Previous test data: https://openqa.fedoraproject.org/tests/664538#downloads
Current test data: https://openqa.fedoraproject.org/tests/667343#downloads

Installed system changes in test x86_64 universal install_package_set_minimal: 
System load changed from 0.19 to 0.07
Previous test data: https://openqa.fedoraproject.org/tests/664585#downloads
Current test data: https://openqa.fedoraproject.org/tests/667390#downloads


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

Fedora 33 compose report: 20200915.n.0 changes

2020-09-15 Thread Fedora Rawhide Report

OLD: Fedora-33-20200914.n.0
NEW: Fedora-33-20200915.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  53
Dropped packages:1
Upgraded packages:   12
Downgraded packages: 0

Size of added packages:  864.67 MiB
Size of dropped packages:670.30 KiB
Size of upgraded packages:   103.79 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   22.90 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-33-20200915.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: OpenEXR-2.3.0-6.module_f33+10160+805b0fb5
Summary: A high dynamic-range (HDR) image file format
RPMs:OpenEXR OpenEXR-devel OpenEXR-doc OpenEXR-libs
Size:15.87 MiB

Package: SDL-1.2.15-45.module_f33+10160+805b0fb5
Summary: A cross-platform multimedia library
RPMs:SDL SDL-devel SDL-static
Size:3.57 MiB

Package: SDL_image-1.2.12-25.module_f33+10160+805b0fb5
Summary: Image loading library for SDL
RPMs:SDL_image SDL_image-devel
Size:274.37 KiB

Package: adobe-mappings-cmap-20171205-9.module_f33+10160+805b0fb5
Summary: CMap resources for Adobe's character collections
RPMs:adobe-mappings-cmap adobe-mappings-cmap-deprecated 
adobe-mappings-cmap-devel
Size:2.01 MiB

Package: adobe-mappings-pdf-20180407-7.module_f33+10160+805b0fb5
Summary: PDF mapping resources from Adobe
RPMs:adobe-mappings-pdf adobe-mappings-pdf-devel
Size:675.69 KiB

Package: atkmm-2.24.3-6.module_f33+10160+805b0fb5
Summary: C++ interface for the ATK library
RPMs:atkmm atkmm-devel atkmm-doc
Size:1.20 MiB

Package: boost-1.73.0-7.module_f33+10160+805b0fb5
Summary: The free peer-reviewed portable C++ source libraries
RPMs:boost boost-atomic boost-b2 boost-build boost-chrono boost-container 
boost-context boost-contract boost-coroutine boost-date-time boost-devel 
boost-doc boost-doctools boost-examples boost-fiber boost-filesystem 
boost-graph boost-iostreams boost-locale boost-log boost-math boost-nowide 
boost-numpy3 boost-program-options boost-python3 boost-random boost-regex 
boost-serialization boost-stacktrace boost-static boost-system boost-test 
boost-thread boost-timer boost-type_erasure boost-wave
Size:300.20 MiB

Package: cairomm-1.12.0-13.module_f33+10160+805b0fb5
Summary: C++ API for the cairo graphics library
RPMs:cairomm cairomm-devel cairomm-doc
Size:1.17 MiB

Package: dbus-glib-0.110-10.module_f33+10160+805b0fb5
Summary: GLib bindings for D-Bus
RPMs:dbus-glib dbus-glib-devel
Size:959.45 KiB

Package: evolution-data-server-3.38.0-1.module_f33+10160+805b0fb5
Summary: Backend data server for Evolution
RPMs:evolution-data-server evolution-data-server-devel 
evolution-data-server-langpacks evolution-data-server-perl 
evolution-data-server-tests
Size:18.54 MiB

Package: exiv2-0.27.3-4.module_f33+10160+805b0fb5
Summary: Exif and Iptc metadata manipulation library
RPMs:exiv2 exiv2-devel exiv2-doc exiv2-libs
Size:12.80 MiB

Package: flatpak-rpm-macros-33-1.module_f33+10159+5494a6e5
Summary: Macros for building RPMS for flatpaks
RPMs:flatpak-rpm-macros
Size:53.29 KiB

Package: flatpak-runtime-config-33-1.module_f33+10159+5494a6e5
Summary: Configuration files that live inside the flatpak runtime
RPMs:flatpak-runtime-config
Size:57.67 KiB

Package: gd-2.3.0-3.module_f33+10160+805b0fb5
Summary: A graphics library for quick creation of PNG or JPEG images
RPMs:gd gd-devel gd-progs
Size:1.03 MiB

Package: geocode-glib-3.26.2-2.module_f33+10160+805b0fb5
Summary: Geocoding helper library
RPMs:geocode-glib geocode-glib-devel
Size:649.20 KiB

Package: ghostscript-9.52-8.module_f33+10160+805b0fb5
Summary: Interpreter for PostScript language & PDF
RPMs:ghostscript ghostscript-core ghostscript-doc ghostscript-gtk 
ghostscript-tools-dvipdf ghostscript-tools-fonts ghostscript-tools-printing 
ghostscript-x11 libgs libgs-devel
Size:23.92 MiB

Package: glew-2.1.0-8.module_f33+10160+805b0fb5
Summary: The OpenGL Extension Wrangler Library
RPMs:glew glew-devel libGLEW
Size:2.32 MiB

Package: glibmm24-2.64.2-4.module_f33+10160+805b0fb5
Summary: C++ interface for the GLib library
RPMs:glibmm24 glibmm24-devel glibmm24-doc
Size:11.36 MiB

Package: gnome-desktop3-3.38.0-1.module_f33+10160+805b0fb5
Summary: Library with common API for various GNOME modules
RPMs:gnome-desktop3 gnome-desktop3-devel gnome-desktop3-tests
Size:3.23 MiB

Package: gnome-online-accounts-3.37.90-1.module_f33+10160+805b0fb5
Summary: Single sign-on framework for GNOME
RPMs:gnome-online-accounts gnome-online-accounts-devel
Size:3.13 MiB

Package: google-droid-fonts-20200215-8.module_f33+10160+805b0fb5
Summary: A set of general-purpose font families released by Google as part of 
Android
RPMs:google-droid-fonts-all google-droid-sans-fonts 
google-droid-sans-mono-fonts google-droid-serif-f

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Gary Buhrmaster

On Tue, Sep 15, 2020 at 11:47 PM Kevin Kofler  wrote:

> There still exist connections as slow as 33 kbps.

And no doubt you can find people still using 300 baud
TI Silent 700 terminals.  However, the global internet
speed tests show that the numbers are much higher
on average, and we should consider the most common
numbers when making decisions, while realizing that
we will, in fact, be impacting those still in the the Silent
700 group, and will need to encourage them to share
physical media in those locations.

> Most end users will not notice their one-time installation being a couple
> minutes slower.

Some people download once, and install once.  For
those, it is pay me now, or pay me later, and it may
be a wash, time wise, depending on your download
speeds, but it is also just a one time thing in any
case.  Some people download once, and install lots
of times (in which case the install time may dominate).
There is no one size fits all.

FD: I am in the later group (download once, install on
many VMs/systems during the lifetime of a release),
so would likely prefer to see something like zstd gain
traction at some point, but that is a different discussion.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: btrfs and default page sizes (4k vs 64k)

On Tue, Sep 15, 2020 at 7:57 PM Kevin Kofler  wrote:
>
> Daniel Pocock wrote:
> > One issue I've come across is that a btrfs filesystem can only be used
> > on hosts with the same page size as the host that created the filesystem
>
> Ewww! That alone should disqualify btrfs as a default file system!
>
> Why does a file system depend on the kernel page size? The kernel page size
> is an internal implementation detail of the kernel, whereas a file system
> ought to be a stable interchange format that is compatible across all
> machines.
>
> It is unfortunate that this showstopper was not mentioned when the switch to
> btrfs by default was proposed.
>

I hate to break it to you, but this problem is not just in
filesystems, it's in basically everything in the kernel. And we've had
variations of problems like this for years (endianness, page size,
pointer size, single bit vs multi-bit booleans, etc.). I've personally
been bitten by all of these issues in some way. This comes from the
fact that there's no such thing as "internal implementation detail of
the kernel" by design. This is the "joy" of the monorepo "design"
where everything leaks into everything else.

This didn't become a serious problem until Red Hat made the
unfortunate (though not realized at the time) mistake of switching to
64k pages for ARM and POWER. We got that change in Fedora for POWER
but not ARM. It has led to all kinds of unfortunate problems that are
gradually being worked on and fixed upstream.

Coming back to Btrfs specifically, there is work underway upstream to
resolve this issue. My (semi-blind) estimate is that we'll see a fix
in Linux 5.11, but Josef (cc'd to this email) may know more about it.

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl11 vs openssl1.1

On Tue, Sep 15, 2020 at 6:35 PM Michel Alexandre Salim
 wrote:
>
> On Tue, 2020-09-15 at 14:10 -0400, Simo Sorce wrote:
> > On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> > >
> > > The compat- prefix is no longer allowed. Instead we should be using
> > > versioned package names.
> >
> > Why?
> > The "compat-" prefix clearly indicated the .so was provided
> > exclusively
> > for backward binary compatibility and shouldn't be relied upon in
> > other
> > packages.
> >
> Provided ${libname}-devel pulls the latest, main version instead of one
> of the older versions, hopefully there is no confusion which version is
> meant to be used?
>
> (That being said, when using other virtual provides such as
> 'pkgconfig(pcname)' it doesn't matter whether the package is versioned
> or prefixed with compat- anyway, as that won't make a difference from
> the call site).
>
> > A bare name conveys nothing and risk introducing dependencies later
> > instead of slowly draining out dependencies until it can be removed
> > again.
> >
> > > So if we're changing the old one, it'll become openssl1.0 to comply
> > > with current guidelines.
> >
> > I think having a package named openssl1.0 or openssl1.1 would lead to
> > more confusion, not less.
> >
> > Simo.
> >
> >
> Anyone familiar with how this works in practice for Debian (and
> derivatives) and, IIRC, Mageia? They've been using versioned packages
> for years so if there are potential confusions they ought to have
> encountered them before.
>

Mageia, openSUSE, and Debian all require versioned packaging for
libraries in all cases. It works perfectly fine. There's no confusion
or anything the package manager or whatever. In the Fedora case, it
looks odd to see it, but since it's only for legacy libraries, it's
fine.

Something that Mageia and openSUSE do sometimes is just not ship a
-devel package if the library is only there for runtime backwards
compatibility. That's something we could do for openssl1.0 and
eventually openssl1.1.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Samuel Sieb


On 9/15/20 4:46 PM, Kevin Kofler wrote:

There still exist connections as slow as 33 kbps. At that speed, 142 MB take
at least 10 hours to download (probably more because 1 data byte takes more
than 8 raw bits to transfer and because the theoretical speed cannot always
be sustained). Depending on when you started the download (which takes a few
days overall), that can mean you lose an entire day (if you are not lucky
enough that those 10+ extra hours are overnight).


I'm curious who would be trying to download a 4GB iso at that speed, 
considering that would involve tying up their internet connection for at 
least two weeks.

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

Re: btrfs and default page sizes (4k vs 64k)

2020-09-15 Thread Kevin Kofler

Daniel Pocock wrote:
> One issue I've come across is that a btrfs filesystem can only be used
> on hosts with the same page size as the host that created the filesystem

Ewww! That alone should disqualify btrfs as a default file system!

Why does a file system depend on the kernel page size? The kernel page size 
is an internal implementation detail of the kernel, whereas a file system 
ought to be a stable interchange format that is compatible across all 
machines.

It is unfortunate that this showstopper was not mentioned when the switch to 
btrfs by default was proposed.

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

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Kevin Kofler

Frantisek Zatloukal wrote:
> Saving 142 MBs isn't going to make a huge difference in download times
> (disclaimer: I don't know how is the internet connection
> speed in other areas, I have not that fast connection of 200mbps down
> (slowest possible in my area), so 142 MB saving would make roughly 6
> seconds difference myself).

There still exist connections as slow as 33 kbps. At that speed, 142 MB take 
at least 10 hours to download (probably more because 1 data byte takes more 
than 8 raw bits to transfer and because the theoretical speed cannot always 
be sustained). Depending on when you started the download (which takes a few 
days overall), that can mean you lose an entire day (if you are not lucky 
enough that those 10+ extra hours are overnight).

> On the other hand, saving minutes in the installation process (as seen
> with zstd if I am reading the numbers correctly) is not only going to help
> users with installation times, but also us, Fedora QA, with faster
> testing, both manual and automated (OpenQA).

Most end users will not notice their one-time installation being a couple 
minutes slower.

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

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Kevin Kofler

Kamil Paral wrote:
> Each image is downloaded just once, but installed 1+ times.

Most end users install the image exactly once.

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

Re: compat-openssl11 vs openssl1.1

2020-09-15 Thread Michel Alexandre Salim

On Tue, 2020-09-15 at 14:10 -0400, Simo Sorce wrote:
> On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> > 
> > The compat- prefix is no longer allowed. Instead we should be using
> > versioned package names.
> 
> Why?
> The "compat-" prefix clearly indicated the .so was provided
> exclusively
> for backward binary compatibility and shouldn't be relied upon in
> other
> packages.
> 
Provided ${libname}-devel pulls the latest, main version instead of one
of the older versions, hopefully there is no confusion which version is
meant to be used?

(That being said, when using other virtual provides such as
'pkgconfig(pcname)' it doesn't matter whether the package is versioned
or prefixed with compat- anyway, as that won't make a difference from
the call site).

> A bare name conveys nothing and risk introducing dependencies later
> instead of slowly draining out dependencies until it can be removed
> again.
> 
> > So if we're changing the old one, it'll become openssl1.0 to comply
> > with current guidelines.
> 
> I think having a package named openssl1.0 or openssl1.1 would lead to
> more confusion, not less.
> 
> Simo.
> 
> 
Anyone familiar with how this works in practice for Debian (and
derivatives) and, IIRC, Mageia? They've been using versioned packages
for years so if there are potential confusions they ought to have
encountered them before.

Regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Rawhide-20200915.n.1 compose check report

No missing expected images.

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 20/181 (x86_64)

New failures (same test not failed in Fedora-Rawhide-20200913.n.0):

ID: 667010  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/667010
ID: 667013  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/667013
ID: 667014  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/667014

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

ID: 666860  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/666860
ID: 666861  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/666861
ID: 666864  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/666864
ID: 666865  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/666865
ID: 666866  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/666866
ID: 666867  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/666867
ID: 666868  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/666868
ID: 666895  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/666895
ID: 666906  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/666906
ID: 666940  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/666940
ID: 666950  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/666950
ID: 666961  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/666961
ID: 666983  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/666983
ID: 667002  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/667002
ID: 667018  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/667018
ID: 667051  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/667051
ID: 667057  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/667057

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

New soft failures (same test not soft failed in Fedora-Rawhide-20200913.n.0):

ID: 667055  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/667055

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

ID: 666831  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/666831
ID: 666850  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/666850
ID: 666913  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/666913
ID: 666927  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/666927
ID: 667015  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/667015
ID: 667068  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/667068

Passed openQA tests: 154/181 (x86_64)

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
3 packages(s) added since previous compose: libibverbs-core, 
python3-pexpect, python3-ptyprocess
2 packages(s) removed since previous compose: libibverbs, rdma-core
Previous test data: https://openqa.fedoraproject.org/tests/663965#downloads
Current test data: https://openqa.fedoraproject.org/tests/666839#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
3 packages(s) added since previous compose: libibverbs-core, 
python3-pexpect, python3-ptyprocess
2 packages(s) removed since previous compose: libibverbs, rdma-core
System load changed from 0.09 to 0.34
Previous test data: https://openqa.fedoraproject.org/tests/663967#downloads
Current test data: https://openqa.fedoraproject.org/tests/666841#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 21 MiB to 3 MiB
4 packages(s) added since previous compose: libibverbs-core, 
python3-pexpect,

[Bug 1879289] New: perl-ExtUtils-Install-2.18 is available

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

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



Latest upstream release: 2.18
Current version/release in rawhide: 2.16-3.fc33
URL: http://search.cpan.org/dist/ExtUtils-Install/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/15262/


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

Re: Giving away two of my package

2020-09-15 Thread Andy Mender

On Tue, 15 Sep 2020 at 12:04, Charalampos Stratakis 
wrote:

> Hello,
>
> I've got some packages that I do not have any use for anymore and I'd like
> to give them away. If noone wants them I'll retire and orphan them in ~ a
> week.
>
> python-bna: https://src.fedoraproject.org/rpms/python-bna
>
> This is a Python library of Battle.net Authenticator routines, which
> contains a command-line Battle.net authentication.
>
> Upstream https://github.com/jleclanche/python-bna seems somewhat active
> with last commit on the 23rd of May. Latest version on rawhide is 4.1.0 and
> upstream latest version is 5.0.0
>
> Nothing depends on the package on rawhide.
>

Could I take that package?

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

Re: Changing the desktop background image of a GNOME based lab to match Fedora

2020-09-15 Thread Adam Williamson

On Tue, 2020-09-15 at 21:45 +0200, Miro Hrončok wrote:
> On 15. 09. 20 20:47, Neal Gompa wrote:
> > On Tue, Sep 15, 2020 at 2:41 PM Miro Hrončok  wrote:
> > > 
> > > Hello,
> > > 
> > > There is a Fedora Python Classroom Lab:
> > > 
> > > https://labs.fedoraproject.org/python-classroom/
> > > 
> > > It has a GNOME based live / installable option. It has the default GNOME 
> > > desktop
> > > background.
> > > 
> > > What are the necessary steps to use the Fedora's default background?
> > > (Both on the live system and on the installed one.)
> > > 
> > 
> > Add back the fedora-workstation-backgrounds package to
> > fedora-python-classroom-gnome-common.ks. It's currently excluded since
> > you remove the entirety of the workstation product group.
> 
> Thanks, Neal.

fedora-workstation-backgrounds isn't actually very important. The key
package is desktop-backgrounds-gnome . That contains the gschema
overrides that make the official Fedora background the default, and it
depends on f33-backgrounds-gnome which contains the background metadata
and depends on f33-backgrounds-base which contains the actual *images*.

Top Men are currently working on making this setup even more
complicated, but it's a tough job. :P
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Changing the desktop background image of a GNOME based lab to match Fedora


On 15. 09. 20 20:47, Neal Gompa wrote:

On Tue, Sep 15, 2020 at 2:41 PM Miro Hrončok  wrote:


Hello,

There is a Fedora Python Classroom Lab:

https://labs.fedoraproject.org/python-classroom/

It has a GNOME based live / installable option. It has the default GNOME desktop
background.

What are the necessary steps to use the Fedora's default background?
(Both on the live system and on the installed one.)



Add back the fedora-workstation-backgrounds package to
fedora-python-classroom-gnome-common.ks. It's currently excluded since
you remove the entirety of the workstation product group.


Thanks, Neal.

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

Re: Changing the desktop background image of a GNOME based lab to match Fedora

On Tue, Sep 15, 2020 at 2:41 PM Miro Hrončok  wrote:
>
> Hello,
>
> There is a Fedora Python Classroom Lab:
>
> https://labs.fedoraproject.org/python-classroom/
>
> It has a GNOME based live / installable option. It has the default GNOME 
> desktop
> background.
>
> What are the necessary steps to use the Fedora's default background?
> (Both on the live system and on the installed one.)
>

Add back the fedora-workstation-backgrounds package to
fedora-python-classroom-gnome-common.ks. It's currently excluded since
you remove the entirety of the workstation product group.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200915.n.1 changes

2020-09-15 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20200913.n.0
NEW: Fedora-Rawhide-20200915.n.1

= SUMMARY =
Added images:0
Dropped images:  10
Added packages:  42
Dropped packages:5
Upgraded packages:   179
Downgraded packages: 0

Size of added packages:  50.36 MiB
Size of dropped packages:1.15 MiB
Size of upgraded packages:   10.05 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20200913.n.0.iso
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20200913.n.0.iso
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20200913.n.0.iso
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-Rawhide-20200913.n.0-sda.raw.xz
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20200913.n.0.iso
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200913.n.0.ppc64le.vmdk
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200913.n.0.ppc64le.tar.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200913.n.0.ppc64le.qcow2
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200913.n.0.ppc64le.tar.xz
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200913.n.0.ppc64le.raw.xz

= ADDED PACKAGES =
Package: antimicrox-3.1-1.20200911git9b383.fc34
Summary: Graphical program used to map keyboard buttons and mouse controls to a 
gamepad
RPMs:antimicrox antimicrox-libantilib antimicrox-libantilib-devel
Size:6.02 MiB

Package: flang-11.0.0-0.1.rc2.fc34
Summary: a Fortran language front-end designed for integration with LLVM
RPMs:flang flang-devel flang-doc
Size:24.66 MiB

Package: icon-9.5.20i-1.fc34
Summary: Icon programming language
RPMs:icon icon-utils
Size:5.81 MiB

Package: ocaml-csexp-1.3.1-1.fc34
Summary: Parsing and printing of S-expressions in canonical form
RPMs:ocaml-csexp ocaml-csexp-devel
Size:770.30 KiB

Package: perl-App-cpanminus-1.7044-10.module_f34+10171+51c6e2a6
Summary: Get, unpack, build and install CPAN modules
RPMs:perl-App-cpanminus
Size:175.11 KiB

Package: perl-CPAN-Meta-Check-0.014-13.module_f34+10171+51c6e2a6
Summary: Verify requirements in a CPAN::Meta object
RPMs:perl-CPAN-Meta-Check
Size:39.86 KiB

Package: perl-File-pushd-1.016-9.module_f34+10171+9b2ab924
Summary: Change directory temporarily for a limited scope
RPMs:perl-File-pushd
Size:47.40 KiB

Package: perl-Module-CPANfile-1.1004-9.module_f34+10171+51c6e2a6
Summary: Parse cpanfile
RPMs:perl-Module-CPANfile
Size:81.28 KiB

Package: perl-Parse-PMFile-0.42-4.module_f34+10171+51c6e2a6
Summary: Parses .pm file as PAUSE does
RPMs:perl-Parse-PMFile
Size:44.94 KiB

Package: perl-Spiffy-0.46-18.module_f34+10156+42edc7d2
Summary: Framework for doing object oriented (OO) programming in Perl
RPMs:perl-Spiffy
Size:78.80 KiB

Package: perl-String-ShellQuote-1.04-31.module_f34+10171+51c6e2a6
Summary: Perl module for quoting strings for passing through the shell
RPMs:perl-String-ShellQuote
Size:37.83 KiB

Package: perl-String-TtyLength-0.02-1.fc34
Summary: Length or width of string excluding ANSI tty codes
RPMs:perl-String-TtyLength
Size:19.12 KiB

Package: perl-Test-Base-0.89-9.module_f34+10156+2c558071
Summary: Data Driven Testing Framework
RPMs:perl-Test-Base
Size:99.92 KiB

Package: perl-Test-Deep-1.130-3.module_f34+10156+42edc7d2
Summary: Extremely flexible deep comparison
RPMs:perl-Test-Deep
Size:122.55 KiB

Package: perl-Test-YAML-1.07-9.module_f34+10156+2c558071
Summary: Testing Module for YAML Implementations
RPMs:perl-Test-YAML
Size:39.71 KiB

Package: perl-YAML-1.30-5.module_f34+10156+2c558071
Summary: YAML Ain't Markup Language (tm)
RPMs:perl-YAML
Size:331.75 KiB

Package: pyserial-asyncio-0.4-1.fc34
Summary: Asynchronous Python Serial Port Extension
RPMs:python-pyserial-asyncio-doc python3-pyserial-asyncio
Size:178.44 KiB

Package: python-afsapi-0.0.4-1.fc34
Summary: Python wrapper for the Frontier Silicon API
RPMs:python3-afsapi
Size:20.01 KiB

Package: python-aioflo-0.4.1-2.fc34
Summary: Python library for Flo by Moen Smart Water Detectors
RPMs:python3-aioflo
Size:25.49 KiB

Package: python-aionotion-2.0.3-2.fc34
Summary: Python library for Notion Home Monitoring
RPMs:python3-aionotion
Size:20.88 KiB

Package: python-aioopenssl-0.5.1-1.fc34
Summary: TLS-capable transport using OpenSSL for asyncio
RPMs:python3-aioopenssl
Size:25.42 KiB

Package: python-aiosasl-0.4.1-2.fc34

Changing the desktop background image of a GNOME based lab to match Fedora


Hello,

There is a Fedora Python Classroom Lab:

https://labs.fedoraproject.org/python-classroom/

It has a GNOME based live / installable option. It has the default GNOME desktop 
background.


What are the necessary steps to use the Fedora's default background?
(Both on the live system and on the installed one.)

Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl11 vs openssl1.1

On Tue, Sep 15, 2020 at 2:29 PM Michael Catanzaro  wrote:
>
> On Tue, Sep 15, 2020 at 1:46 pm, Neal Gompa  wrote:
> > openssl1.0
>
> It reached EOL in December 2019. Probably time to remove it from Fedora?
>

Ideally, yes, but I think some things still use it, and I think it
tracks the RHEL 7 openssl package now.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl11 vs openssl1.1

2020-09-15 Thread Michael Catanzaro


On Tue, Sep 15, 2020 at 1:46 pm, Neal Gompa  wrote:

openssl1.0


It reached EOL in December 2019. Probably time to remove it from Fedora?

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

[Bug 1876156] perl-Module-Starter-1.77 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-Starter-1.77-1. |perl-Module-Starter-1.77-1.
   |fc34|fc34
   |perl-Module-Starter-1.77-1. |perl-Module-Starter-1.77-1.
   |fc32|fc32
   ||perl-Module-Starter-1.77-1.
   ||fc31



--- Comment #11 from Fedora Update System  ---
FEDORA-2020-84ea84a57f has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.


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

Re: compat-openssl11 vs openssl1.1

2020-09-15 Thread Simo Sorce

On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet  wrote:
> > On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> > > I've submitted a new compat-openssl11 package for review but it was
> > > pointed out to me that according to the new format of the naming for
> > > compat packages it should be named openssl1.1. However there already
> > > is
> > > a compat-openssl10 package.
> > > 
> > > What is more important? Consistency between those two compat packages
> > > or strictly following the naming rules for the new package?
> > > 
> > 
> > My 2 cents would be consistency. If others disagree, perhaps compat-
> > openssl10 should be renamed to compat-openssl1.0 and obsolete the old
> > compat-openssl10? Its annoying to try to find the magic name something
> > has based on something else... python-foo vs Foo-python etc.
> 
> The compat- prefix is no longer allowed. Instead we should be using
> versioned package names.

Why?
The "compat-" prefix clearly indicated the .so was provided exclusively
for backward binary compatibility and shouldn't be relied upon in other
packages.

A bare name conveys nothing and risk introducing dependencies later
instead of slowly draining out dependencies until it can be removed
again.

> So if we're changing the old one, it'll become openssl1.0 to comply
> with current guidelines.

I think having a package named openssl1.0 or openssl1.1 would lead to
more confusion, not less.

Simo.

> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Simo Sorce
RHEL Crypto Team
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl11 vs openssl1.1

2020-09-15 Thread Nathanael D. Noblet

On Tue, 2020-09-15 at 13:46 -0400, Neal Gompa wrote:
> On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet 
> > My 2 cents would be consistency. If others disagree, perhaps
> > compat-
> > openssl10 should be renamed to compat-openssl1.0 and obsolete the
> > old
> > compat-openssl10? Its annoying to try to find the magic name
> > something
> > has based on something else... python-foo vs Foo-python etc.
> 
> The compat- prefix is no longer allowed. Instead we should be using
> versioned package names.
> 
> So if we're changing the old one, it'll become openssl1.0 to comply
> with current guidelines.

Yeah, either way I'd 100% say consistency is important. So to clean up
and be consistent I'd suggest the other one is renamed as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: New segfault with flexiblas/openblaso

2020-09-15 Thread Iñaki Ucar

FYI, we've managed to narrow down the issue to this:
https://github.com/xianyi/OpenBLAS/issues/2839

On Tue, 15 Sep 2020 at 12:22, Iñaki Ucar  wrote:
>
> I found that this may be a packaging issue in openblas. What I did was
> to download the source distribution, then
>
> $ tar xf openblas-0.3.10.tar.gz
> $ cd OpenBLAS-0.3.10
> $ make USE_THREAD=1 USE_OPENMP=1
> $ CMD='octave -H -q --no-window-system --no-site-file --eval
> pkg("load","statistics");test("/usr/share/octave/pac
> kages/statistics-1.4.1/canoncorr.m");'
> $ FLEXIBLAS=$PWD/libopenblas.so $CMD
> PASSES 7 out of 7 tests
>
> My guess is that the spec requires a "make clean" between builds with
> different flags. Makes sense?
>
> Iñaki
>
> On Fri, 4 Sep 2020 at 11:22, Iñaki Ucar  wrote:
> >
> > On Fri, 4 Sep 2020 at 11:16, Susi Lehtola
> >  wrote:
> > >
> > > On Fri, 4 Sep 2020 10:57:13 +0200
> > > Iñaki Ucar  wrote:
> > > > Hi,
> > > >
> > > > Strange... Let me bring this upstream to see whether this is
> > > > flexiblas' or openblas' fault. In the meanwhile, exporting
> > > > FLEXIBLAS=netlib before the tests makes use of the reference
> > > > implementation, so everything should be slower but safer. And if this
> > > > starts happening in the wild, we can change to openblas-serial with a
> > > > quick update of FlexiBLAS.
> > >
> > > ... which would lead to a horrendous regression in performance, utterly
> > > ruining parallellization.
> > >
> > > If this happens, there is no alternative but to resort to the
> > > contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
> > > changes and rebuild all packages so that they work again as intended.
> >
> > If this is a bug in FlexiBLAS, by experience I'm sure it will be fixed
> > soon. If not, then it's a bug in openblaso, which should be also
> > tracked down and fixed; otherwise, would you link packages back to
> > openblaso knowing it's faulty?
> >
> > --
> > Iñaki Úcar
>
>
>
> --
> Iñaki Úcar



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

Re: compat-openssl11 vs openssl1.1

On Tue, Sep 15, 2020 at 1:36 PM Nathanael D. Noblet  wrote:
>
> On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> > I've submitted a new compat-openssl11 package for review but it was
> > pointed out to me that according to the new format of the naming for
> > compat packages it should be named openssl1.1. However there already
> > is
> > a compat-openssl10 package.
> >
> > What is more important? Consistency between those two compat packages
> > or strictly following the naming rules for the new package?
> >
>
> My 2 cents would be consistency. If others disagree, perhaps compat-
> openssl10 should be renamed to compat-openssl1.0 and obsolete the old
> compat-openssl10? Its annoying to try to find the magic name something
> has based on something else... python-foo vs Foo-python etc.

The compat- prefix is no longer allowed. Instead we should be using
versioned package names.

So if we're changing the old one, it'll become openssl1.0 to comply
with current guidelines.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: compat-openssl11 vs openssl1.1

2020-09-15 Thread Nathanael D. Noblet

On Tue, 2020-09-15 at 19:26 +0200, Tomas Mraz wrote:
> I've submitted a new compat-openssl11 package for review but it was
> pointed out to me that according to the new format of the naming for
> compat packages it should be named openssl1.1. However there already
> is
> a compat-openssl10 package.
> 
> What is more important? Consistency between those two compat packages
> or strictly following the naming rules for the new package?
> 

My 2 cents would be consistency. If others disagree, perhaps compat-
openssl10 should be renamed to compat-openssl1.0 and obsolete the old
compat-openssl10? Its annoying to try to find the magic name something
has based on something else... python-foo vs Foo-python etc.

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

Re: compat-openssl11 vs openssl1.1


On 15. 09. 20 19:26, Tomas Mraz wrote:

What is more important? Consistency between those two compat packages
or strictly following the naming rules for the new package?


Why not both? I.e. renaming compat-openssl10 to openssl1.0 while packaging 
openssl1.1?


Note that I've always considered the compat-openssl10 name quite confusing, so I 
would prefer the new one to be openssl1.1 (even if you don't rnemae the old one).


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

Re: compat-openssl11 vs openssl1.1

On Tue, Sep 15, 2020 at 1:27 PM Tomas Mraz  wrote:
>
> Hi Fedora developers,
>
> we need to introduce temporarily a compat package for OpenSSL as it is
> going to be rebased to the 3.0 version in Rawhide once the 3.0 release
> is stable.
>
> The 3.0 version should not break API from the 1.1.1, it just breaks the
> ABI, so rebuilds should be quite easy. Of course there might be minor
> breakage and adjustments needed especially for the language bindings.
> But anyway to help with the transition there should temporarily be a
> compat package with the openssl-1.1.1.
>
> I've submitted a new compat-openssl11 package for review but it was
> pointed out to me that according to the new format of the naming for
> compat packages it should be named openssl1.1. However there already is
> a compat-openssl10 package.
>
> What is more important? Consistency between those two compat packages
> or strictly following the naming rules for the new package?
>

Please name it the new way. Otherwise we'll never finish switching over.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1876160] perl-List-AllUtils-0.18 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-List-AllUtils-0.18-1.f |perl-List-AllUtils-0.18-1.f
   |c34 |c34
   |perl-List-AllUtils-0.18-1.f |perl-List-AllUtils-0.18-1.f
   |c32 |c32
   ||perl-List-AllUtils-0.18-1.f
   ||c31



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


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

compat-openssl11 vs openssl1.1

2020-09-15 Thread Tomas Mraz

Hi Fedora developers,

we need to introduce temporarily a compat package for OpenSSL as it is
going to be rebased to the 3.0 version in Rawhide once the 3.0 release
is stable.

The 3.0 version should not break API from the 1.1.1, it just breaks the
ABI, so rebuilds should be quite easy. Of course there might be minor
breakage and adjustments needed especially for the language bindings.
But anyway to help with the transition there should temporarily be a
compat package with the openssl-1.1.1.

I've submitted a new compat-openssl11 package for review but it was
pointed out to me that according to the new format of the naming for
compat packages it should be named openssl1.1. However there already is
a compat-openssl10 package.

What is more important? Consistency between those two compat packages
or strictly following the naming rules for the new package?

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

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

Re: Self Introduction: Tom Yates

2020-09-15 Thread Michel Alexandre Salim

Hi Tom,

On Tuesday, September 15, 2020 4:49:48 AM PDT Tom Yates wrote:
> Hello.  I'm Tom Yates, I've been using free software since the late '80s,
> and Red Hat since RHL 4.2 (ie, the late '90s).  Because I'm really that
> ancient, I fairly extensively use RCS (a very old revision control system)
> and am posting with a view to becoming co-maintainer for an RCS package in
> EPEL for RHEL8 (and later).
> 

Welcome! You might be interested in joining epel-devel@ as well.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

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

[Bug 1876156] perl-Module-Starter-1.77 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Module-Starter-1.77-1. |perl-Module-Starter-1.77-1.
   |fc34|fc34
   ||perl-Module-Starter-1.77-1.
   ||fc32
 Resolution|--- |ERRATA
Last Closed||2020-09-15 16:16:32



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


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

[Bug 1879217] New: perl-IO-Socket-IP-0.41 is available

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

Bug ID: 1879217
   Summary: perl-IO-Socket-IP-0.41 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-IO-Socket-IP
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, n...@fedoraproject.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.41
Current version/release in rawhide: 0.39-458.fc33
URL: http://search.cpan.org/dist/IO-Socket-IP/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/2999/


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

[EPEL-devel] Re: EPEL playground && mock builds against released repos

2020-09-15 Thread Kevin Fenzi

On Tue, Sep 15, 2020 at 10:53:10AM +0200, Pavel Raiskup wrote:
> Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can
> reproduce builds locally with mock.  Initially the configuration worked, but 
> it
> has been failing for quite some time now.  Dnf isn't able to --installroot:
> 
> No matches found for the following disable plugin patterns: local, 
> spacewalk
> CentOS-8 - Base  12 MB/s | 2.2 MB 
> 00:00
> CentOS-8 - AppStream 21 MB/s | 5.8 MB 
> 00:00
> CentOS-8 - PowerTools11 MB/s | 1.9 MB 
> 00:00
> CentOS-8 - Extras33 kB/s | 7.3 kB 
> 00:00
> Extra Packages for Enterprise Linux 8 - Playgro  15 MB/s | 6.1 MB 
> 00:00
> Error:
>  Problem: conflicting requests
>   - nothing provides fpc-srpm-macros needed by 
> epel-rpm-macros-8-16.playground.noarch
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
> to use not only best candidate packages)
> 
> I'm not sure we miss something there, but it looks like the shipped chroot is
> broken.  The mock bug report [1], and fpc-srpm-macros report [2].

Yeah, looks like the fpc-srpm-macros build for epel8-playground failed. 

I fired off a build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=51522174

but also there's no epel8-playground branch for the package. 

> Local mock builds are done against CentOS repositories, so I'm not sure where 
> to
> report this problem, if here or to CentOS (but starting here as I believe that
> fpc-srpm-macros should go to the playground repo).
> 
> Also another question is whether we can fix the chroot, or not (dropping the
> config file from mock-core-configs is an option, too).

We should be able to fix it. Once the above lands in the buildroot it
should be working again.

kevin


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

[Bug 1870746] EPEL8 Branch Request: perl-Test-TempDir

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-97732a2b90 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-97732a2b90

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


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

[Bug 1870754] EPEL8 Branch Request: perl-Data-Dumper-Concise

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2020-97732a2b90 has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-97732a2b90

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


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

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

2020-09-15 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2390c71f9c   
chromium-85.0.4183.83-1.el8
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-0214580ca4   
mbedtls-2.16.8-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c5ced83bcc   
seamonkey-2.53.4-1.el8


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

aha-0.5.1-1.el8
amavisd-milter-1.7.1-1.el8
perl-Data-Dumper-Concise-2.023-12.el8
perl-Test-TempDir-0.11-1.el8
pyserial-asyncio-0.4-1.el8
python-blessed-1.17.10-1.el8
python-enlighten-1.6.2-1.el8
python-sseclient-py-1.7-1.el8
xsecurelock-1.7.0-3.el8

Details about builds:



 aha-0.5.1-1.el8 (FEDORA-EPEL-2020-c0c043c53f)
 Convert terminal output to HTML

Update Information:

Update to latest upstream release (v0.5.1)

ChangeLog:

* Mon Sep 14 2020 Artur Frenszek-Iwicki  - 0.5.1-1
- Update to latest upstream release




 amavisd-milter-1.7.1-1.el8 (FEDORA-EPEL-2020-5c9f9db204)
 Sendmail milter for amavisd-new using the AM.PDP protocol

Update Information:

# amavisd-milter  ## Bug and compatibility fixes   - An empty sender must always
be enclosed in angle brackets

ChangeLog:

* Mon Sep 14 2020 Robert Scheck  1.7.1-1
- Upgrade to 1.7.1 (#1878910)
* Mon Jul 27 2020 Fedora Release Engineering  - 
1.7.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

References:

  [ 1 ] Bug #1878910 - amavisd-milter-1.7.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1878910




 perl-Data-Dumper-Concise-2.023-12.el8 (FEDORA-EPEL-2020-97732a2b90)
 A convenient way to reproduce a set of Dumper options

Update Information:

EPEL8 branches of perl modules, per user request.

ChangeLog:


References:

  [ 1 ] Bug #1870746 - EPEL8 Branch Request: perl-Test-TempDir
https://bugzilla.redhat.com/show_bug.cgi?id=1870746
  [ 2 ] Bug #1870754 - EPEL8 Branch Request: perl-Data-Dumper-Concise
https://bugzilla.redhat.com/show_bug.cgi?id=1870754




 perl-Test-TempDir-0.11-1.el8 (FEDORA-EPEL-2020-97732a2b90)
 Temporary files support for testing

Update Information:

EPEL8 branches of perl modules, per user request.

ChangeLog:


References:

  [ 1 ] Bug #1870746 - EPEL8 Branch Request: perl-Test-TempDir
https://bugzilla.redhat.com/show_bug.cgi?id=1870746
  [ 2 ] Bug #1870754 - EPEL8 Branch Request: perl-Data-Dumper-Concise
https://bugzilla.redhat.com/show_bug.cgi?id=1870754




 pyserial-asyncio-0.4-1.el8 (FEDORA-EPEL-2020-9295c78a8d)
 Asynchronous Python Serial Port Extension

Update Information:

Initial package for Fedora

ChangeLog:





 python-blessed-1.17.10-1.el8 (FEDORA-EPEL-2020-6aa0435ca8)
 A thin, practical wrapper around terminal capabilities in Python

Update Information:

Updated to 1.17.10

ChangeLog:

* Mon Sep 14 2020 Avram Lubkin  -

[EPEL-devel] Re: Proposing an EPEL packaging SIG

2020-09-15 Thread Kevin Fenzi

On Mon, Sep 14, 2020 at 09:42:36AM -0700, Michel Alexandre Salim wrote:

> I wonder if these are two separate concerns though? I agree that being
> able to indicate a package should always be branched would be great,
> but... epel-sig / epel-wranglers might not find a package relevant in a
> new EL release (e.g. say we care about neovim, and want to carry it by
> default in new releases, and thus we also care about some of its
> dependencies that are not in (RH)EL core -- but the set of dependencies
> we care about in EPEL7 != the set in EPEL8 etc.
> 
> ^ if that seems explicit that's because it, uh, is from personal
> experience.

Yeah, I agree, not everything will want to auto branch... and in fact
this will change from time to time as new versions come out, things are
retired, etc. 

> Maybe package.cfg might be where such a metadata live? e.g. if the
> epel8 branch of the package has a package.cfg that says "branch for
> next release" it gets branched for epel9 -- and inherits that
> package.cfg by default. If a package gets opted in once and at some
> point is no longer needed in the next epel, just delete that.

I don't like that idea... I've heard many many complaints from people
about package.cfg files and them messing up merges. 

I would think at the pagure/src.fp.o level might be better... or if not,
then just a simple 'alwaysepelbranch' file or something thats ignored
except for this use. 

> This might also suggest we want to have a delay before automatically
> branching so EPEL SIG / Wranglers have time to adjust that package.cfg
> after testing the next EL beta.

Sure, should be a deliberate process.

snip

> Hmm. So right now (correct me if I'm wrong), it seems that only the
> main admin for a package can override the bugzilla assignee?

yeah, I think thats indeed the case. 

> I'm not sure about how this part would work yet. If at the beginning we
> try this out with manual infra ticket, I could imagine the EPEL SIG
> member that requests EPEL-SIG comaintainership for a package should ask
> the main admin to make them the EPEL assignee, or if it goes through an
> infra ticket, ask for infra to make that change?

I suppose. I am not keen on adding more infrastructure tickets. 
If we can do a workflow that consolidates requests/can be automated that
would be much better IMHO. 

> > > One deviation we might want to have from how Python SIG works is...
> > > we
> > > probably don't want to encourage packagers to add this EPEL SIG as
> > > a
> > > comaintainer preemptively, but only as needed.
> > 
> > That would defeat the purpose of using epel-sig packages as 'always
> > branch' wouldn't it?
> > 
> Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG
> has commit access requesting a new branch is not a significant delay
> anyway). So 'branch for next' in package.cfg might be a better solution
> all around.
> 
> How much tooling change would we need to get collaborators the ability
> to request branches if the branch name matches their whitelist,
> incidentally?

Not sure. Thats a question for Pingou. :) 

> > The other hazard if that different maintainers have different
> > workflows
> > and epel-sig folks would need to adjust to those. ie, some people
> > want
> > master to have epel conditionals and merge back to epel branches,
> > some
> > don't want that at all. I wonder if it wouldn't make sense to have
> > some
> > way to indicate to people what workflow is in effect for the package
> > (I
> > guess spec file comments?)
> > 
> Maybe spec file comments as well as only granting collaborator
> (whitelisting epel* branches) instead of commit / admin access if they
> don't want EPEL conditionals?

yeah. 

kevin


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

[EPEL-devel] Re: Proposed EPEL Playground Documentation

2020-09-15 Thread Troy Dawson

This is the second draft.  It has added a section in the developer
section saying to clean your packages up when you are done playing and
testing them.
Edit's are still welcome, but I think it covers everything that has
been discussed and approved.
This will be published about the same time that
 - fedpkg doesn't require you to build playground when building epel
-- https://pagure.io/fedpkg/issue/414
- package.cfg isn't automatically added to epel8 branches when they are created
-- https://pagure.io/fedora-infrastructure/issue/9322

==

# EPEL PLAYGROUND

We have added an additional set of channels for EPEL-8 called
playground. It is meant to be sort of like Fedora Rawhide so that
packagers can work on versions of software which are too fast moving
or will have large API changes from what they are putting in the
regular channel.

Packages in epel8-playground are primarily to be used in the following manner:
 * To test out some new version of the package that might not be stable yet.
 * To test out some new packaging of the package
 * To test a major version change of the package that they want to
land at the next epel8 minor release.
 * To build a package that will never be stable enough for epel8, but
still could be useful to some.

## Consumers / End Users
Consumers should be aware that packages in EPEL8-playground are there
without any Service Level Expectations. You may want to only cherry
pick packages from there as needed.

EPEL8-playground is not a full EPEL release.  It only has those
packages that developers and maintainers are "playing" around with.
Because of this, you should not expect to enable only epel-playground
and get everything you need.  It is expected that you have regular
epel enabled whenever you enable epel-playground.

## Developers / Maintainers
epel8-playground builds are NOT automatically built when you build in
epel8.  This is a change from the original vision. #(Remove this
sentence after a few years)
You must use the epel8-playground branch and build from there, just
like you would any other Fedora / EPEL build area.

Packages in epel-playground will never be automatically put into
regular epel.  That is the responsibility of the package maintainer.

It is recommended that if a maintainer plans to bring a package that
has a large change from epel-playground to regular epel, they do it at
minor RHEL releases (ie, 8.3, 8.4).   Since end users will be
upgrading and paying more attention than usual at those times, it’s a
great chance to make larger changes.  Be sure to announce those major
changes well in advance on epel-devel and epel-announce.

When a maintainer is done with their package in playground, they must
untag all builds of it out of epel-playground.  We do not want
epel-playground cluttered with old test packages.  Done means either
the package has been moved to regular EPEL, and / or the maintainer no
longer wants to play and test in epel-playground.  Untagging all
builds of a package is currently done via a release engineering
ticket.

EPEL Playground has traits similar to Fedora Rawhide.
 * Built packages do not need to be tagged with override to get into
the epel8-playground build repository.  They will be put in the next
time the build repository is refreshed.  This is usually within 15 to
60 minutes.
  * The main epel8-playground repository is built once a day, just
like Fedora Rawhide.  Thus built packages are usually available in
epel8-playground the day after they are built.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: [EPEL-devel] Re: Proposing an EPEL packaging SIG

2020-09-15 Thread Kevin Fenzi

On Mon, Sep 14, 2020 at 09:42:36AM -0700, Michel Alexandre Salim wrote:

> I wonder if these are two separate concerns though? I agree that being
> able to indicate a package should always be branched would be great,
> but... epel-sig / epel-wranglers might not find a package relevant in a
> new EL release (e.g. say we care about neovim, and want to carry it by
> default in new releases, and thus we also care about some of its
> dependencies that are not in (RH)EL core -- but the set of dependencies
> we care about in EPEL7 != the set in EPEL8 etc.
> 
> ^ if that seems explicit that's because it, uh, is from personal
> experience.

Yeah, I agree, not everything will want to auto branch... and in fact
this will change from time to time as new versions come out, things are
retired, etc. 

> Maybe package.cfg might be where such a metadata live? e.g. if the
> epel8 branch of the package has a package.cfg that says "branch for
> next release" it gets branched for epel9 -- and inherits that
> package.cfg by default. If a package gets opted in once and at some
> point is no longer needed in the next epel, just delete that.

I don't like that idea... I've heard many many complaints from people
about package.cfg files and them messing up merges. 

I would think at the pagure/src.fp.o level might be better... or if not,
then just a simple 'alwaysepelbranch' file or something thats ignored
except for this use. 

> This might also suggest we want to have a delay before automatically
> branching so EPEL SIG / Wranglers have time to adjust that package.cfg
> after testing the next EL beta.

Sure, should be a deliberate process.

snip

> Hmm. So right now (correct me if I'm wrong), it seems that only the
> main admin for a package can override the bugzilla assignee?

yeah, I think thats indeed the case. 

> I'm not sure about how this part would work yet. If at the beginning we
> try this out with manual infra ticket, I could imagine the EPEL SIG
> member that requests EPEL-SIG comaintainership for a package should ask
> the main admin to make them the EPEL assignee, or if it goes through an
> infra ticket, ask for infra to make that change?

I suppose. I am not keen on adding more infrastructure tickets. 
If we can do a workflow that consolidates requests/can be automated that
would be much better IMHO. 

> > > One deviation we might want to have from how Python SIG works is...
> > > we
> > > probably don't want to encourage packagers to add this EPEL SIG as
> > > a
> > > comaintainer preemptively, but only as needed.
> > 
> > That would defeat the purpose of using epel-sig packages as 'always
> > branch' wouldn't it?
> > 
> Right - I wasn't thinking of the 'always branch' case (once EPEL-SIG
> has commit access requesting a new branch is not a significant delay
> anyway). So 'branch for next' in package.cfg might be a better solution
> all around.
> 
> How much tooling change would we need to get collaborators the ability
> to request branches if the branch name matches their whitelist,
> incidentally?

Not sure. Thats a question for Pingou. :) 

> > The other hazard if that different maintainers have different
> > workflows
> > and epel-sig folks would need to adjust to those. ie, some people
> > want
> > master to have epel conditionals and merge back to epel branches,
> > some
> > don't want that at all. I wonder if it wouldn't make sense to have
> > some
> > way to indicate to people what workflow is in effect for the package
> > (I
> > guess spec file comments?)
> > 
> Maybe spec file comments as well as only granting collaborator
> (whitelisting epel* branches) instead of commit / admin access if they
> don't want EPEL conditionals?

yeah. 

kevin


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

[Bug 1876273] perltidy-20200907 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perltidy-20200907-1.fc34|perltidy-20200907-1.fc34
   ||perltidy-20200907-1.fc32
 Resolution|--- |ERRATA
Last Closed||2020-09-15 16:16:29



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


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

[Bug 1876124] perl-Log-Log4perl-1.52 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Log-Log4perl-1.52-1.fc |perl-Log-Log4perl-1.52-1.fc
   |34  |34
   ||perl-Log-Log4perl-1.52-1.fc
   ||32
 Resolution|--- |ERRATA
Last Closed||2020-09-15 16:16:35



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


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

[Bug 1876160] perl-List-AllUtils-0.18 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-List-AllUtils-0.18-1.f |perl-List-AllUtils-0.18-1.f
   |c34 |c34
   ||perl-List-AllUtils-0.18-1.f
   ||c32
 Resolution|--- |ERRATA
Last Closed||2020-09-15 16:16:33



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


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

[Bug 1879188] New: perl-Search-Elasticsearch-7.30 is available

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

Bug ID: 1879188
   Summary: perl-Search-Elasticsearch-7.30 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Search-Elasticsearch
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 7.30
Current version/release in rawhide: 6.81-3.fc33
URL: http://search.cpan.org/dist/Search-Elasticsearch/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/10543/


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

Re: Kubernetes Development SIG

2020-09-15 Thread Ankur Sinha

On Tue, Sep 15, 2020 20:25:18 +0530, Sumantro Mukherjee wrote:
> 
> 
> On Tue, Sep 15, 2020 at 7:15 PM Leonardo Rossetti  wrote:
> 
> Hello all,
> 
> I would like to present a Kubernetes Development SIG.
> 
> 
> I would love to be a part of the group!

+1, mostly as a user :)

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: Kubernetes Development SIG

2020-09-15 Thread Sumantro Mukherjee

On Tue, Sep 15, 2020 at 7:15 PM Leonardo Rossetti 
wrote:

> Hello all,
>
> I would like to present a Kubernetes Development SIG.
>
> I initially thought of an "operator SIG" but I think a wider SIG about
> programming components and services with Kubernetes APIs and internal
> components made more sense (inspired by the "Programming Kubernetes" book).
>
> I am using some of the fields/titles described in this document [1] as the
> proposal template.
>
> Proposal Name
> 
>
> SIG: Kubernetes Development
>
> Summary
> ===
>
> A SIG for people interested in using, developing, extending kubernetes for
> Fedora components and services.
>
> Owner
> =
>
> Name: Leonardo Rossetti (lrossett)
> Email: lross...@redhat.com
>
> Benefit to Fedora
> =
>
> Development Experience and Learning
> 
>
> A place to exchange and discuss kubernetes development design and patterns.
>
> Extending kubernetes is not that straightforward so this SIG would be a
> good place to learn more about it.
>
> Kubernetes can be extended in the following areas:
>
> * Kubectl Plugins
> * Custom API Servers
> * Custom Controllers / Operators
>
> Operator Development
> ---
>
> The Operator SDK [3] is the shining new framework when developing custom
> kubernetes controllers nas has become a popular tool for packaging and
> deploying applications in kubernetes.
>
> Some Fedora services and components could leverage the usage of an
> operator (as we are doing with MBBOX [2]) but other services could be
> deployed via operators as well and even the mbbox operator could be split
> into smaller operators.
>
> Kubernetes DevOps
> ---
>
> The SIG could also be a place for sysadmins and ops engineers to discuss
> the challenges, practices and tooling of monitoring, deploying and running
> operators, api servers and other related kubernetes components in
> production.
>
> [1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
> [2] - https://github.com/fedora-infra/mbbox
> [3] - https://github.com/operator-framework/operator-sdk
>
> --
>
> Leonardo Rossetti
>
> Senior Software Engineer,
>
> Red Hat 
>
> lross...@redhat.com
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>

I would love to be a part of the group!
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

[Bug 1878992] Upgrade perl-Test-MockModule to 0.174.0

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

[Bug 1878775] perl-SQL-Translator-1.62 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

Re: [HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide

2020-09-15 Thread Petr Menšík

I just rebuilt unbound into that tag.

Tried build of getdns and fstrm packages, but they are blocked by
missing libavahi rebuild [1]. It is dragged in by doxygen used during
the build. Feel free to send copy to me once avahi is rebuilt.

Petr

1. https://bugzilla.redhat.com/show_bug.cgi?id=1713942#c9

On 9/15/20 11:17 AM, Ondřej Lysoněk wrote:
> (maintainers of dependent packages in BCC)
> 
> Hi,
> 
> libevent will be rebased to 2.1.12 in Rawhide. The new version
> includes a soname bump. Rebuilds of libevent and dependent packages
> will happen in side tag 'f34-build-side-30069'.
> 
> Due to the nature of the dependency tree, we can't simply build all
> dependent packages at the same time. We'll have to build in
> batches. See my plan at the bottom of the email.
> 
> I'll reach out to individual maintainers when it's time to rebuild
> their package. However, the new libevent is already built in the tag,
> so if you own a package from the "Initial set", you don't have to wait
> for me and you can start the rebuild right away using the following
> command.
> 
> fedpkg build --target=f34-build-side-30069
> 
> I've performed test rebuilds of the dependent packages in COPR and it
> went mostly well, so I don't expect any big issues. Some notable
> things I found during the test rebuilds:
> - some of the packages (libreswan, perl-Event-Lib, sems) fail to build
>   for unrelated reasons. Unless these are fixed, they'll become
>   uninstallable. I've notified their owners.
>   - libreswan should hopefully get fixed soon by its own rebase
>   - perl-Event-Lib will likely get orphaned
>   - no response about sems
> - I wasn't able to rebuild community-mysql, because for some reason,
>   it fails to build in COPR (but builds fine in Koji). I guess we'll
>   have to build this one with our fingers crossed.
> - the new libevent breaks transmission slightly. Hopefully this will
>   get fixed soon. Worst-case scenario, we'll temporarily revert the
>   problematic libevent change, or come up with some temporary quick
>   fix for transmission. Reported upstream:
>   https://github.com/transmission/transmission/issues/1437
> - due to a build dep loop, avahi will need to be bootstrapped
> - I'm not sure if chromium really utilizes the system libevent - it
>   seems to bundle it's own version. Nevertheless, it has BuildRequires
>   for libevent-devel, so it's included in my list.
>   
> List of dependent packages:
> - 389-ds-base
> - addrwatch
> - avahi
> - ccnet
> - chromium
> - community-mysql
> - coturn
> - fragments
> - fstrm
> - gearmand
> - getdns
> - groonga
> - icecat
> - Io-language
> - ladvd
> - libasr
> - libcouchbase
> - libmemcached
> - libreswan
> - libverto
> - links
> - lldpd
> - lua-event
> - mediaconch
> - memcached
> - mpris-scrobbler
> - nbd-runner
> - netatalk
> - nfs-utils
> - nsd
> - ntp
> - ocproxy
> - openmpi
> - opensmtpd
> - perl-Event-Lib
> - pgbouncer
> - php-pecl-event
> - php-pecl-http
> - php-pecl-memcached
> - pmix
> - qt5-qtwebengine
> - remctl
> - scanssh
> - seafile
> - sems
> - sslsplit
> - sstp-client
> - suricata
> - thrift
> - tmate
> - tmux
> - tor
> - transmission
> - trickle
> - unbound
> - uwsgi
> - zabbix
> 
> Here is my plan for the rebuild process. Note that the "After ... is
> rebuilt" paragraphs can be executed in any order - just their
> respective dependencies must be met.
> 
> Initial set:
> - avahi - needs to be bootstrapped
> - packages that I haven't been able to rebuild:
>   - community-mysql, libreswan, perl-Event-Lib, sems
> - other: addrwatch, ccnet, coturn, groonga, ladvd, libasr,
>   libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner,
>   nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event,
>   php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit,
>   sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix
> 
> After avahi is rebuilt, we can rebuild:
> 389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event,
> netatalk, qt5-qtwebengine, thrift, tor, transmission
> 
> After unbound and avahi is rebuilt, we can rebuild:
> chromium, getdns
> 
> After memcached is rebuilt, we can rebuild:
> libmemcached
> 
> After memcached and libmemcached is rebuilt, we can rebuild:
> gearmand, Io-language, php-pecl-memcached
> 
> After qt5-qtwebengine is rebuilt, we can rebuild:
> mediaconch
> 
> After pmix and avahi is rebuilt, we can rebuild:
> openmpi
> 
> Best regards
> Ondřej Lysoněk
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP:

Re: Release criteria proposal: first boot experience

2020-09-15 Thread Kamil Paral

On Tue, Sep 1, 2020 at 10:24 PM Michael Catanzaro 
wrote:

> Hi,
>
> We currently have a bug where the Online Accounts page in initial setup
> is nonfunctional. [1] This doesn't violate any current release
> criterion, but surely we don't want to release with a broken initial
> setup experience. So let's add a new requirement for that. How about
> something like:
>
> "If an initial setup utility is run or intended to be run after the
> first boot of the installed system, then it must start successfully and
> each page or panel of the initial setup utility should withstand a
> basic functionality test."
>
> OK that's pretty basic, but it gets the point across. I think this can
> be a final requirement, not necessarily important enough to be a beta
> requirement. Bikeshed away!
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1870476


This criterion is now live:
https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#First_boot_experience
https://fedoraproject.org/w/index.php?title=QA%3ATestcase_base_initial_setup=revision=588239=491757
https://fedoraproject.org/w/index.php?title=Template%3ABase_test_matrix=revision=588240=581773

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

Re: Can't push update to stable

2020-09-15 Thread Richard W.M. Jones


https://pagure.io/fedora-infrastructure/issue/9320

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

Re: Kubernetes Development SIG

On Tue, Sep 15, 2020 at 9:44 AM Leonardo Rossetti  wrote:
>
> Hello all,
>
> I would like to present a Kubernetes Development SIG.
>
> I initially thought of an "operator SIG" but I think a wider SIG about 
> programming components and services with Kubernetes APIs and internal 
> components made more sense (inspired by the "Programming Kubernetes" book).
>
> I am using some of the fields/titles described in this document [1] as the 
> proposal template.
>
> Proposal Name
> 
>
> SIG: Kubernetes Development
>
> Summary
> ===
>
> A SIG for people interested in using, developing, extending kubernetes for 
> Fedora components and services.
>

This sounds interesting. I'd be interested in participating in this.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can't push update to stable (was: Re: What is the status of this F33 update?)

2020-09-15 Thread Richard W.M. Jones

On Tue, Sep 15, 2020 at 02:52:14PM +0100, Richard W.M. Jones wrote:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 again ...
> 
> I cannot push this to stable, at least, not through the web UI.
> The button does nothing.

Meanwhile the command line hangs for a long time and then fails with
some kind of timeout:

$ bodhi updates request FEDORA-2020-3f6760cc65 stable
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/fedora/client/openidbaseclient.py", 
line 249, in send_request
data = output.json()
  File "/usr/lib/python3.9/site-packages/requests/models.py", line 898, in json
return complexjson.loads(self.text, **kwargs)
  File "/usr/lib64/python3.9/site-packages/simplejson/__init__.py", line 525, 
in loads
return _default_decoder.decode(s)
  File "/usr/lib64/python3.9/site-packages/simplejson/decoder.py", line 370, in 
decode
obj, end = self.raw_decode(s)
  File "/usr/lib64/python3.9/site-packages/simplejson/decoder.py", line 400, in 
raw_decode
return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/bodhi", line 11, in 
load_entry_point('bodhi-client==5.2.2', 'console_scripts', 'bodhi')()
  File "/usr/lib/python3.9/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.9/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3.9/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/bodhi/client/__init__.py", line 263, 
in wrapper
method(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/bodhi/client/__init__.py", line 690, 
in request
resp = client.request(update, state)
  File "/usr/lib/python3.9/site-packages/bodhi/client/bindings.py", line 117, 
in wrapper
result = method(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/bodhi/client/bindings.py", line 297, 
in request
return self.send_request(f'updates/{update}/request',
  File "/usr/lib/python3.9/site-packages/fedora/client/openidbaseclient.py", 
line 252, in send_request
raise ServerError(
fedora.client.ServerError: 
ServerError(https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65/request,
 504, Error returned from json module while processing 
b'https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65/request': 
b'Expecting value: line 1 column 1 (char 0)'
b"504 Gateway Time-out\nThe server didn't respond in 
time.\n\n")

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can't push update to stable


On 15. 09. 20 15:52, Richard W.M. Jones wrote:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 again ...

I cannot push this to stable, at least, not through the web UI.
The button does nothing.


$ bodhi updates request FEDORA-2020-3f6760cc65 stable
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/fedora/client/openidbaseclient.py", 
line 249, in send_request

data = output.json()
  File "/usr/lib/python3.8/site-packages/requests/models.py", line 897, in json
return complexjson.loads(self.text, **kwargs)
  File "/usr/lib64/python3.8/site-packages/simplejson/__init__.py", line 525, 
in loads

return _default_decoder.decode(s)
  File "/usr/lib64/python3.8/site-packages/simplejson/decoder.py", line 370, in 
decode

obj, end = self.raw_decode(s)
  File "/usr/lib64/python3.8/site-packages/simplejson/decoder.py", line 400, in 
raw_decode

return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/bodhi", line 11, in 
load_entry_point('bodhi-client==5.1.1', 'console_scripts', 'bodhi')()
  File "/usr/lib/python3.8/site-packages/click/core.py", line 829, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 782, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.8/site-packages/click/core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3.8/site-packages/click/core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3.8/site-packages/click/core.py", line 610, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/bodhi/client/__init__.py", line 263, 
in wrapper

method(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/bodhi/client/__init__.py", line 683, 
in request

resp = client.request(update, state)
  File "/usr/lib/python3.8/site-packages/bodhi/client/bindings.py", line 117, 
in wrapper

result = method(*args, **kwargs)
  File "/usr/lib/python3.8/site-packages/bodhi/client/bindings.py", line 297, 
in request

return self.send_request(f'updates/{update}/request',
  File "/usr/lib/python3.8/site-packages/fedora/client/openidbaseclient.py", 
line 252, in send_request

raise ServerError(
fedora.client.ServerError: 
ServerError(https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65/request, 
504, Error returned from json module while processing 
b'https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65/request': 
b'Expecting value: line 1 column 1 (char 0)'
b"504 Gateway Time-out\nThe server didn't respond in 
time.\n\n")



I suggest you open an infra ticket.

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

Can't push update to stable (was: Re: What is the status of this F33 update?)

2020-09-15 Thread Richard W.M. Jones

https://bodhi.fedoraproject.org/updates/FEDORA-2020-3f6760cc65 again ...

I cannot push this to stable, at least, not through the web UI.
The button does nothing.

Rich.

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

Kubernetes Development SIG

2020-09-15 Thread Leonardo Rossetti

Hello all,

I would like to present a Kubernetes Development SIG.

I initially thought of an "operator SIG" but I think a wider SIG about
programming components and services with Kubernetes APIs and internal
components made more sense (inspired by the "Programming Kubernetes" book).

I am using some of the fields/titles described in this document [1] as the
proposal template.

Proposal Name


SIG: Kubernetes Development

Summary
===

A SIG for people interested in using, developing, extending kubernetes for
Fedora components and services.

Owner
=

Name: Leonardo Rossetti (lrossett)
Email: lross...@redhat.com

Benefit to Fedora
=

Development Experience and Learning


A place to exchange and discuss kubernetes development design and patterns.

Extending kubernetes is not that straightforward so this SIG would be a
good place to learn more about it.

Kubernetes can be extended in the following areas:

* Kubectl Plugins
* Custom API Servers
* Custom Controllers / Operators

Operator Development
---

The Operator SDK [3] is the shining new framework when developing custom
kubernetes controllers nas has become a popular tool for packaging and
deploying applications in kubernetes.

Some Fedora services and components could leverage the usage of an operator
(as we are doing with MBBOX [2]) but other services could be deployed via
operators as well and even the mbbox operator could be split into smaller
operators.

Kubernetes DevOps
---

The SIG could also be a place for sysadmins and ops engineers to discuss
the challenges, practices and tooling of monitoring, deploying and running
operators, api servers and other related kubernetes components in
production.

[1] - https://fedoraproject.org/wiki/Changes/EmptyTemplate
[2] - https://github.com/fedora-infra/mbbox
[3] - https://github.com/operator-framework/operator-sdk

-- 

Leonardo Rossetti

Senior Software Engineer,

Red Hat 

lross...@redhat.com

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

[EPEL-devel] Re: EPEL playground && mock builds against released repos

2020-09-15 Thread Troy Dawson

On Tue, Sep 15, 2020 at 1:53 AM Pavel Raiskup  wrote:
>
> Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can
> reproduce builds locally with mock.  Initially the configuration worked, but 
> it
> has been failing for quite some time now.  Dnf isn't able to --installroot:
>
> No matches found for the following disable plugin patterns: local, 
> spacewalk
> CentOS-8 - Base  12 MB/s | 2.2 MB 
> 00:00
> CentOS-8 - AppStream 21 MB/s | 5.8 MB 
> 00:00
> CentOS-8 - PowerTools11 MB/s | 1.9 MB 
> 00:00
> CentOS-8 - Extras33 kB/s | 7.3 kB 
> 00:00
> Extra Packages for Enterprise Linux 8 - Playgro  15 MB/s | 6.1 MB 
> 00:00
> Error:
>  Problem: conflicting requests
>   - nothing provides fpc-srpm-macros needed by 
> epel-rpm-macros-8-16.playground.noarch
> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' 
> to use not only best candidate packages)
>
> I'm not sure we miss something there, but it looks like the shipped chroot is
> broken.  The mock bug report [1], and fpc-srpm-macros report [2].
>
> Local mock builds are done against CentOS repositories, so I'm not sure where 
> to
> report this problem, if here or to CentOS (but starting here as I believe that
> fpc-srpm-macros should go to the playground repo).
>
> Also another question is whether we can fix the chroot, or not (dropping the
> config file from mock-core-configs is an option, too).
>
> [1] https://github.com/rpm-software-management/mock/issues/620
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1875057
>
> Pavel
>

I guess here is probably going to be the best place to start.
EPEL Playground is in the middle of changing.
It will no longer be a "stand alone" repository.  It will be for only
those packages that people are using to "play with" large changes to
their packages.  There will be no more automatic builds of all
packages.
Because of this, you will need to have the regular EPEL repository
enabled in order to use the EPEL-Playground repository.

We're right in the middle of this change, but fixing mock now is the
best time to do it.  It won't hurt anything to add the regular EPEL
repository now, when doing the EPEL-Playground mock.

Troy
p.s. I'll put this in the bugzilla and the issue.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-15 Thread Hans de Goede


Hi,

On 9/14/20 5:05 PM, Fabio Valentini wrote:

On Fri, Sep 11, 2020 at 10:04 PM Hans de Goede  wrote:


Hi,

On 9/11/20 6:08 PM, Fabio Valentini wrote:

I can try to come up with a list of often-used-but-simple-to-maintain
Java packages?


Yes that sounds great. I would be happy to pick up a few of
those to help and if a bunch of us do that hopefully we can
lighten the load a bit.


I looked through the list of packages currently associated with the
Java SIG, and I've put together a list of things that are usually easy
to maintain:
https://pagure.io/java-maint-sig/blob/master/f/EASYFIX.md

The easy-to-maintain packages are almost 100% up-to-date in fedora
right now, but as we all well know, that state isn't usually lasting
for long :-)


Thank you for making this list. I'm afraid that I don't really
see anything which really appeals to me to pick-up there, sorry.

Still hopefully some others will find this list helpful.

Regards,

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

[Bug 1879100] New: Please build an EPEL8 build for perl-File-Find-Rule-Age

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

Bug ID: 1879100
   Summary: Please build an EPEL8 build for
perl-File-Find-Rule-Age
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-File-Find-Rule-Age
  Assignee: ticot...@gmail.com
  Reporter: t.h.amund...@usit.uio.no
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ticot...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please build an EPEL8 build for perl-File-Find-Rule-Age.


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

Re: Giving away two of my package

2020-09-15 Thread Martin Jackson




pipsi: https://src.fedoraproject.org/rpms/pipsi

A wrapper around virtualenv and pip which installs scripts provided by python 
packages into separate virtualenvs to shield them from your system and each 
other.

The project https://github.com/mitsuhiko/pipsi/ is not maintained anymore 
upstream and a replacement is developed instead:  
https://github.com/pipxproject/pipx

Nothing depends on it as well

FYI, we have pipx in Fedora - I've been maintaining it since f32 was in 
development.


Thanks,

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

Schedule for Wednesday's FESCo Meeting (2020-09-16)

2020-09-15 Thread Clement Verna

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

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

or run:
  date -d '2020-09-16 14: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 =
#2469 F34 Self-Contained Change: Python Upstream Architecture Names
https://pagure.io/fesco/issue/2469
APPROVED (+5, 0, 0)

#2466 Nonresponsive maintainer: Jon Disnard parasense
https://pagure.io/fesco/issue/2466
APPROVED (+4, 0, 0)

= Followups =

= New business =

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

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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



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


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

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Event-Lib-1.03-46.fc34




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

Self Introduction: Tom Yates

2020-09-15 Thread Tom Yates

Hello.  I'm Tom Yates, I've been using free software since the late '80s, 
and Red Hat since RHL 4.2 (ie, the late '90s).  Because I'm really that 
ancient, I fairly extensively use RCS (a very old revision control system) 
and am posting with a view to becoming co-maintainer for an RCS package in 
EPEL for RHEL8 (and later).


During work times I'm principally a consultant free software sysadmin, 
with a sideline in writing, mostly for LWN.



--

  Tom Yates  -  https://www.teaparty.net-BEGIN PGP PUBLIC KEY BLOCK-

mQINBFlzC68BEACmGh1BQ7ReCK9rG5vFpeFC7boTJQjfWISMQK/9t4VMqRWsoW3B
/VSp6mIl+LpA2WlgBtgKSUyDURNOLIYlZS4TjvP+jRxRD1khlhkY0Y48HzFz/RLZ
RW/3laDne2nX5nDkAbgp/asiwfAqjwZp3Q86gw35O938j5Im4q3QShyYWTMcisqp
1lqmmilQWoQWwSw+BW+AkYZLQZi5AXCyCdSpTgSIfcYFtpvMHZJYHX+BhDkO7cmb
rVKRHY0pCO+KIJPWd4J7h4Eil4yU1VlrE0XBXELrhO+rsJBtqLHxw3fEIhYeub2n
e3K1NxywN+Ui8iv1ZmErD9Pp6UNNRuc0LTaB+EfpSOdjB5zCEla3Hn4q+6LkkjUS
LMmawdfPE7U5PB++/XDwHrU53UtlQL6XGNBpuGilRLlYwvQmiFILrm7E3xCS9R7v
tULWzNYqDsmxzl6IkJq1AQvhGTP84UO93AvYKeI4okpfEKD51aOAzM3l89Dz/m1L
PNMwYWTXFXTAFnvbe9ADtHTjzzypAHhyrV8U0tiuhSA6y9V47034xLnLqc4+no5R
dR0Fuzb5yridWlk4jB1v7k80iFxO8Pb8inxkWmOxIKKp+zA9hfsoR0j16AktMBRx
2rK+CeLdqr4nMiYSzjOKN/7GNrjDEs8ppvE1dbjqZN7OuoS4RGygqa18QwARAQAB
tCJUb20gWWF0ZXMgPG1hZGhhdHRlckB0ZWFwYXJ0eS5uZXQ+iQJXBBMBCABBAhsD
BQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAhkBFiEE1XksTIxvjeg3eUnR9IOAsuyP
lEkFAlnptHEFCQlnVMIACgkQ9IOAsuyPlEmJQQ//QnmioNRsdxMs1Xg1yrXYX8a4
GuXB4+6bv2gjSQz4kO6PKS7pY7ASWYg+Fm+FUbuYZ3COmac7iYCqLWsU9kTTJgQw
g1RU7OCwFdPeHZUcNIyUioEYQGTPYwMW9VBytbolyCD+tUNXGlW/X0zg9X1CjJyc
JMCPpEezO4KsVIMztX96ezAQtNvQrbO8pYAxcNtsgNN84y5JXeQyJGTJYn+4i80C
FA969x+yj0YZ7zJbgTVvWxdmHpu3muX/UOibCjGtFklxnFORSf1WJZbYBX9yFf27
YyJu0Cs1S6v4l4AJzmGB8jE5rBpqIFXsgt5s/GBPDE7QlEgWZL8XMq2LJs2QVhum
Gp8dS1A5Khv5zo4QqKIF2pTYfqggpO6vXM/Eul2fUc+MRt8eUdIY3k2Ql9pqxAv2
4o39wMhFb6b+4OB5HmqC34f/KRHfciTLq5uLQ8DMdersYU7XBlN+oa7EVt1x3KJr
/0hMvuOcF3o92uSJSY3zHdUNaQqZRJcIQEhw4ZQ05SH4GlUCkC92RKwH50R/pRIh
EYxwgTt+NZS0nOkhgbZfjAXccXeCRkwPWT/zLvfAo1fdJGKKjn/0jVafrSXr2wZ9
blgp1DbFcx6Do7h80PuNm1/jTcKYcrbf2jeX9I5oLqJywPxn2W1EOxZC3hzGADkz
WXBtjB3ZB8kqcJr/oOKIXQQQEQIAHRYhBCt94ojPFYF4xLOHXU9SCJtPMOLiBQJZ
cw0LAAoJEE9SCJtPMOLiAbEAn17w/cYoCLpWVpQ5+kNYLSQVwLVOAJ42xwECNs2l
AzXnFjTXVzpiDhjhGokCVAQTAQgAPhYhBNV5LEyMb43oN3lJ0fSDgLLsj5RJBQJZ
cwuvAhsDBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEPSDgLLsj5RJ
L2wP/0Ma4lIur86iR7nE+kSOb0uFLbgGBN1GY8isxLO5uTR4DOb3CplYNMyNEUac
ypXWT35GfRUfbPbIx9Jy3MPpwk628Zmp2sa5AKLjsNXHPp98Pq/L2DL/yt4aBgYb
iUYqNZI3E1X22N/TSFRs4AzCySFTiWXXUT1LvEgUVnT1HNFXATkduduFxliZB91B
4/cG6Bit6MCLxCosBaf976x/vRPxMiqRo1jue5nn/0VFhsogCjbC+OdroLBq+Wi4
6aVZhgZLhacavlQBfT1X5bECCJQNsAgBYf9t5ouaQ9LGWEsB7tqSUicceLOf9XVm
BM0XXH658pX7lV+26lGJPwxGf8Bfs4OBWCLafhdXOGBZ0kyjr0D8wwYtYGjki5Pd
9jAuIk7krxvAyLboFLhsHFjh5H2DOKGDD5tcG5yv9znhEKRaqKVk4V0a6s9lqyn4
gfZDNEaoP/LE2vZCYufQQXLXFsXg7hs6CJe2sZ9Q7UuKTgAv9RnqG7yd2R1ODxLx
tUHqBOmVXI8ZWuhmbgEvO1VUtkZeNbSScA442Uc3mhOwfTZLmZf7DbuSlYVqdp2h
BBTS7kA8CxuQTTHM4zZIVcXNRhEmtOtnnqvVXQqKev5j5QHN4+7oRZTwuVOBHzFe
wSued97+QO1sQADMloT7FJ/+9KybxDRXzXn3Y2EQYsI5/EKitCRUb20gWWF0ZXMg
PHR5YXRlc0BnYXRla2VlcGVyLmx0ZC51az6JAlQEEwEIAD4CGwMFCwkIBwIGFQgJ
CgsCBBYCAwECHgECF4AWIQTVeSxMjG+N6Dd5SdH0g4Cy7I+USQUCWem0iwUJCWdU
wgAKCRD0g4Cy7I+USUqGEACaRuqCOk2lNoW0eCyZ4Nqqw3gbf+XiWCDXI33XLgoK
oJ/euhwNCFe6drxs+jF9EdreBjGaUkcnkAklZhz/30lFT8hzDv/wmp5Gy258RKQi
7KtpG0cy9FFAhUKiDEv39DFTJVshNKg89vnbL/NnP5gEIuBcu1eryhzWgZ3P+Vrw
BB13riQlzQL0W4QPOyV69i3L1RozxAfuQcfGOJjGS/i48rexJVuBjc0O4Z7wsW4a
HKT5Gjjg075rKphXGDeTJwutqJpRDctdiVEXN6DUny62Yk2GPek1xSkdY+UbtkoN
H6sCW2gUAXPUQyCg0Y8goOTZw+PDDiP3brR0QbiIi8xGOSgQcdd1SNXPSChJkJ0c
MTiGc4QvgVr3wxc8m5HKMP54Fq7BZ5Y1pBh+EStkXTajC8xXe4rc266rNJSNLvKt
1NlzhTjOl2o7VffyUpPVjdQA9B2g5ldZFyyMPHRHHL781PllcaXRMip6x8XcWqq1
y4KEthVv+k1QcfJGfk1+tCG6Cl52x3JfPxIWAIsRdSZ3gTE4sdaeHHRoPlxlRXuZ
ZchgURYsnHFg3On+Er46Hrx8szIA2KbcIIwvofLe/2Ajxli6UlkPgWQKs3RNMQ5s
JHrAekI2ILq7k8cS5KZnrWTRdsIWL32ZB6PhVNT+NRWys7Ca+GCtrIwsX4ODk+NP
GIhdBBARAgAdFiEEK33iiM8VgXjEs4ddT1IIm08w4uIFAllzDRMACgkQT1IIm08w
4uKNiwCeIK17/EpzkPl1BXA4SZEqYE7hDA4AnA2X2ka1oWwSOtt6lp9mwz6eYLlV
iQJUBBMBCAA+FiEE1XksTIxvjeg3eUnR9IOAsuyPlEkFAllzDJgCGwMFCQlmAYAF
CwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQ9IOAsuyPlEnxBg//eEbo4DyPjv+U
C7WQMiriePR8RFVnlHPFd08xKSL/njJzUY6u+XeOGCJd1n9XWjb3no/cyRDKZdT0
jhW5aqXZ7uV7HTLPWC3xFZafZaDwbIHx4r5TgBrP1MbjVLRmUtAB8qatXuNYXvDg
AkFGywT6q+Cdhx/KIFYIpWsR8rR/nYpfTK6itFzmn6QnDnmiqWGCHAB3P1fIz+FJ
4tGA3tFNvFnKGHEYUNQ3X729BXCliqtY4Da8OHtDRa96WETrBAJNKX692WHl1mXW
qMfm3I9+GS6Aqzfq7qg/hQRu2GMHxCfFtlbr28fC0KkyqsM3h0Hy4b+uXEZy+hxN
hcYBWzufyPCEm8oglLWEP7jv5fp3HSm1T6gtY2hgPCij73P1v0sJtma/WXs5W03M
ahSmrsIdL1R4elg3Qop9NjszBOnsAIbKXLO/x9TrtXim46X95Xn3woplMg+iYPOX
V7mdXknW5p3r+qj6KNAlPm7oTbAjCoPjTJGhyvOjMSXVv0SvygBjozzvAN8PPRKy
pCkYPx3ewr138lewYFaKOCVkM3rg+WdI4iNPur+6k2Wk6wlkMn+83EsCkVMG7c5n
+FFcITG2Mnd2nqe728DTVjzWGJABD1QXAjjaruQnCr5m+eq4dBQ9EZYi+jTZXn/M
EhlHGMLUCNKnbK8INp9QJm5nYgf+XqrRxe3F6wEQAAEB/9j/
4AAQSkZJRgABAQEAXwBfAAD//gBYQ1JFQVRPUjogWFYgVmVyc2lvbiAzLjEwYSAg

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||CPAN 133340
   Assignee|kwiz...@gmail.com   |ppi...@redhat.com




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

Fedora-Cloud-31-20200915.0 compose check report

No missing expected images.

Passed openQA tests: 7/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide

2020-09-15 Thread Tomas Korbar

Hey all,
Just wanted to inform you that memcached and libmemcached
are rebuilt in the side tag. So maintainers of dependent packages
(gearmand, Io-language, php-pecl-memcached) can proceed with
their build.
Regards.

On Tue, Sep 15, 2020 at 11:17 AM Ondřej Lysoněk  wrote:

> (maintainers of dependent packages in BCC)
>
> Hi,
>
> libevent will be rebased to 2.1.12 in Rawhide. The new version
> includes a soname bump. Rebuilds of libevent and dependent packages
> will happen in side tag 'f34-build-side-30069'.
>
> Due to the nature of the dependency tree, we can't simply build all
> dependent packages at the same time. We'll have to build in
> batches. See my plan at the bottom of the email.
>
> I'll reach out to individual maintainers when it's time to rebuild
> their package. However, the new libevent is already built in the tag,
> so if you own a package from the "Initial set", you don't have to wait
> for me and you can start the rebuild right away using the following
> command.
>
> fedpkg build --target=f34-build-side-30069
>
> I've performed test rebuilds of the dependent packages in COPR and it
> went mostly well, so I don't expect any big issues. Some notable
> things I found during the test rebuilds:
> - some of the packages (libreswan, perl-Event-Lib, sems) fail to build
>   for unrelated reasons. Unless these are fixed, they'll become
>   uninstallable. I've notified their owners.
>   - libreswan should hopefully get fixed soon by its own rebase
>   - perl-Event-Lib will likely get orphaned
>   - no response about sems
> - I wasn't able to rebuild community-mysql, because for some reason,
>   it fails to build in COPR (but builds fine in Koji). I guess we'll
>   have to build this one with our fingers crossed.
> - the new libevent breaks transmission slightly. Hopefully this will
>   get fixed soon. Worst-case scenario, we'll temporarily revert the
>   problematic libevent change, or come up with some temporary quick
>   fix for transmission. Reported upstream:
>   https://github.com/transmission/transmission/issues/1437
> - due to a build dep loop, avahi will need to be bootstrapped
> - I'm not sure if chromium really utilizes the system libevent - it
>   seems to bundle it's own version. Nevertheless, it has BuildRequires
>   for libevent-devel, so it's included in my list.
>
> List of dependent packages:
> - 389-ds-base
> - addrwatch
> - avahi
> - ccnet
> - chromium
> - community-mysql
> - coturn
> - fragments
> - fstrm
> - gearmand
> - getdns
> - groonga
> - icecat
> - Io-language
> - ladvd
> - libasr
> - libcouchbase
> - libmemcached
> - libreswan
> - libverto
> - links
> - lldpd
> - lua-event
> - mediaconch
> - memcached
> - mpris-scrobbler
> - nbd-runner
> - netatalk
> - nfs-utils
> - nsd
> - ntp
> - ocproxy
> - openmpi
> - opensmtpd
> - perl-Event-Lib
> - pgbouncer
> - php-pecl-event
> - php-pecl-http
> - php-pecl-memcached
> - pmix
> - qt5-qtwebengine
> - remctl
> - scanssh
> - seafile
> - sems
> - sslsplit
> - sstp-client
> - suricata
> - thrift
> - tmate
> - tmux
> - tor
> - transmission
> - trickle
> - unbound
> - uwsgi
> - zabbix
>
> Here is my plan for the rebuild process. Note that the "After ... is
> rebuilt" paragraphs can be executed in any order - just their
> respective dependencies must be met.
>
> Initial set:
> - avahi - needs to be bootstrapped
> - packages that I haven't been able to rebuild:
>   - community-mysql, libreswan, perl-Event-Lib, sems
> - other: addrwatch, ccnet, coturn, groonga, ladvd, libasr,
>   libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner,
>   nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event,
>   php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit,
>   sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix
>
> After avahi is rebuilt, we can rebuild:
> 389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event,
> netatalk, qt5-qtwebengine, thrift, tor, transmission
>
> After unbound and avahi is rebuilt, we can rebuild:
> chromium, getdns
>
> After memcached is rebuilt, we can rebuild:
> libmemcached
>
> After memcached and libmemcached is rebuilt, we can rebuild:
> gearmand, Io-language, php-pecl-memcached
>
> After qt5-qtwebengine is rebuilt, we can rebuild:
> mediaconch
>
> After pmix and avahi is rebuilt, we can rebuild:
> openmpi
>
> Best regards
> Ondřej Lysoněk
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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

Petr Pisar  changed:

   What|Removed |Added

 CC||ppi...@redhat.com



--- Comment #5 from Petr Pisar  ---
I corrected reading to the expected sizes (6 and 2 bytes), added some debugging
and it's like I said. (CLIENT debugging is not serialized to SERVER debugging):

$ perl -Iblib/{lib,arch} t/64_pending_events_destroyed.t
1..6
# Running under perl version 5.032000 for linux
# Current time local: Tue Sep 15 13:09:52 2020
# Current time GMT:   Tue Sep 15 11:09:52 2020
# Using Test.pm version 1.31
CLIENT 1:1 wrote 6 B at t/64_pending_events_destroyed.t line 39.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 1:1 read  B at t/64_pending_events_destroyed.t line 41.
CLIENT 1:2 wrote 6 B at t/64_pending_events_destroyed.t line 39.
SERVER accepted. at t/64_pending_events_destroyed.t line 74.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 1:2 read  B at t/64_pending_events_destroyed.t line 41.
CLIENT 1:3 wrote 6 B at t/64_pending_events_destroyed.t line 39.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 1:3 read  B at t/64_pending_events_destroyed.t line 41.
Use of uninitialized value $ok in concatenation (.) or string at
t/64_pending_events_destroyed.t line 88.
SERVER  read 6 B at t/64_pending_events_destroyed.t line 88.
CLIENT 1 closed at t/64_pending_events_destroyed.t line 44.
ok 1
SERVER 1 wrote an error: Broken pipe at t/64_pending_events_destroyed.t line
109.
CLIENT 2:1 wrote 6 B at t/64_pending_events_destroyed.t line 39.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 2:1 read  B at t/64_pending_events_destroyed.t line 41.
CLIENT 2:2 wrote 6 B at t/64_pending_events_destroyed.t line 39.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 2:2 read  B at t/64_pending_events_destroyed.t line 41.
SERVER accepted. at t/64_pending_events_destroyed.t line 74.
CLIENT 2:3 wrote 6 B at t/64_pending_events_destroyed.t line 39.
Use of uninitialized value $read in concatenation (.) or string at
t/64_pending_events_destroyed.t line 41.
CLIENT 2:3 read  B at t/64_pending_events_destroyed.t line 41.
CLIENT 2 closed at t/64_pending_events_destroyed.t line 44.
SERVER 1 read 6 B at t/64_pending_events_destroyed.t line 88.
ok 2
SERVER 2 wrote an error: Broken pipe at t/64_pending_events_destroyed.t line
109.
^C

The client sends all data, reads nothing (because of non-blocking), and closes
the connection. Then server reads a response, attempts to write, but that fails
and the server in case of write failure does simply resets and waits for a new
connection. But client is programmed to perform two connections, while the
server expects 6 cycles.

I will try to patch the test to work under a condition of a smooth timing.


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

Re: New segfault with flexiblas/openblaso

2020-09-15 Thread Iñaki Ucar

I found that this may be a packaging issue in openblas. What I did was
to download the source distribution, then

$ tar xf openblas-0.3.10.tar.gz
$ cd OpenBLAS-0.3.10
$ make USE_THREAD=1 USE_OPENMP=1
$ CMD='octave -H -q --no-window-system --no-site-file --eval
pkg("load","statistics");test("/usr/share/octave/pac
kages/statistics-1.4.1/canoncorr.m");'
$ FLEXIBLAS=$PWD/libopenblas.so $CMD
PASSES 7 out of 7 tests

My guess is that the spec requires a "make clean" between builds with
different flags. Makes sense?

Iñaki

On Fri, 4 Sep 2020 at 11:22, Iñaki Ucar  wrote:
>
> On Fri, 4 Sep 2020 at 11:16, Susi Lehtola
>  wrote:
> >
> > On Fri, 4 Sep 2020 10:57:13 +0200
> > Iñaki Ucar  wrote:
> > > Hi,
> > >
> > > Strange... Let me bring this upstream to see whether this is
> > > flexiblas' or openblas' fault. In the meanwhile, exporting
> > > FLEXIBLAS=netlib before the tests makes use of the reference
> > > implementation, so everything should be slower but safer. And if this
> > > starts happening in the wild, we can change to openblas-serial with a
> > > quick update of FlexiBLAS.
> >
> > ... which would lead to a horrendous regression in performance, utterly
> > ruining parallellization.
> >
> > If this happens, there is no alternative but to resort to the
> > contingency plan of the FlexiBLAS as BLAS/LAPACK manager: undo all
> > changes and rebuild all packages so that they work again as intended.
>
> If this is a bug in FlexiBLAS, by experience I'm sure it will be fixed
> soon. If not, then it's a bug in openblaso, which should be also
> tracked down and fixed; otherwise, would you link packages back to
> openblaso knowing it's faulty?
>
> --
> Iñaki Úcar



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

[Bug 1879033] perl-XML-LibXML-2.0206 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-XML-LibXML-2.0206-1.fc
   ||34
 Resolution|--- |RAWHIDE
Last Closed||2020-09-15 10:11:36




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

Giving away two of my package

2020-09-15 Thread Charalampos Stratakis

Hello,

I've got some packages that I do not have any use for anymore and I'd like to 
give them away. If noone wants them I'll retire and orphan them in ~ a week.

python-bna: https://src.fedoraproject.org/rpms/python-bna

This is a Python library of Battle.net Authenticator routines, which contains a 
command-line Battle.net authentication.

Upstream https://github.com/jleclanche/python-bna seems somewhat active with 
last commit on the 23rd of May. Latest version on rawhide is 4.1.0 and upstream 
latest version is 5.0.0

Nothing depends on the package on rawhide.


pipsi: https://src.fedoraproject.org/rpms/pipsi

A wrapper around virtualenv and pip which installs scripts provided by python 
packages into separate virtualenvs to shield them from your system and each 
other.

The project https://github.com/mitsuhiko/pipsi/ is not maintained anymore 
upstream and a replacement is developed instead:  
https://github.com/pipxproject/pipx

Nothing depends on it as well

-- 
Regards, 

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Sep 15, 2020 at 11:18:04AM +0200, Bohdan Khomutskyi wrote:
> Hello everyone,
> 
> Thanks for sharing your ideas and comments about this change.
> 
> Thanks to Mohan Boddu, I got RawHide DVD and netinstall images of
> RawHide with the optimization features enabled. Those test composes
> are available at the following locations:
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/
> (Plain SquashFS)
> 
> https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200908.n.1/compose/Server/x86_64/iso/
> (Plain SquashFS and different xz compression options)
> 
> To select images from the test composes, I applied a patch from
> https://github.com/rhinstaller/anaconda/pull/2829, so you can
> download and run those images yourself to test the change:
> 
> https://drive.google.com/drive/folders/1tGsoqFMg2A6dQZHfuQNb9uDqYu9XEiPI
> 
> The result of benchmark will supplement already available data I
> previously posted for Fedora Live images at
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> 
> As a reminder, there are 2 levels for this optimization:
> 
> 1. Making the SquashFS filesystem on the DVD plain (i.e. without
> embedded EXT4 inside it) -- has the suffix plain-xz-128k.iso

This sounds excellent. We should get both better time and space efficiency.

> 2. In addition to #1, using a different compression parameters for
> the SquashFS filesystem on the installation medium -- has the suffix
> plain-xz-1M.iso

And this ones trades times for space. Considering that the space
difference is only ~50 MB, I don't think it's worth it, for all the
reasons outlined before.

You haven't really answered the "why" part: why is it so important to
save 50MB? And why is the effect on QA less important?

Zbyszek


> I propose to apply both of optimizations, using the highest possible
> compression ratio supported by SquashFS. The highest compression
> ratio in SquashFS corresponds to xz level 1 (out of 9 available
> presets).
> 
> Making the first change will reduce both x86-64 Boot and the x86-64
> DVD ISO by approximately 24 MiB. With both changes combined, the
> reduction of size will be 70 MiB.
> 
> Because the SquashFS filesystem on the Live installation medium is
> of bigger size, storage savings on the Live images are even higher
> (I documented it in
> https://fedoraproject.org/wiki/Changes/OptimizeSquashFS)
> 
> On 05/09/2020 12:43, Zbigniew Jędrzejewski-Szmek wrote:
> >On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:
> >>https://fedoraproject.org/wiki/Changes/OptimizeSquashFS
> >...
> >>Based on the results above, I'd suggest selecting the following
> >>''optimal configuration'': XZ algorithm, with block size of 1MiB and
> >>without BCJ filter (plain xz -b 1M, without -Xbcj x86).
> >>On the right, you can see the impact of the compression algorithms on
> >>installation time.
> >>
> >>As can be seen from the picture on the right hand side, selecting
> >>'plain xz -b 1M configuration' has minimal impact on the installation
> >>time and CPU usage during the installation. The compression will
> >>result in +6.51% or, in real terms, +24.94s additional installation
> >>time, compared to the savings of 142 MiB on the installation media,
> >>== Benefit to Fedora ==
> >>* Reduction of the installation media size and the cost of storing and
> >>distributing Fedora.
> >>* Reduction of the CPU usage at build time. Depending on which
> >>compression parameters chosen.
> >Hi Bohdan,
> >
> >I think there's a misalignment of priorities.
> >
> >My evaluation is the following: users won't care. The image size difference
> >is not big enough for people to notice. OTOH, slower installation will
> >impact QA and VM installations. We're doing more and more automated
> >installations and tests, and this change impacts those tests negatively.
> >
> >>This increase in installation time will be compensated by the change
> >>in the installer:https://github.com/rhinstaller/anaconda/pull/2292
> >This PR is very interesting. But it seems that the more we optimize
> >things, the more slow decompression will be noticable. I.e. in some
> >way, right now, the slow decompression is obscured by the slow IO
> >speed, multiple levels of block device, or slow processing of the
> >uncompressed data. Any time the input or output speed is improved,
> >slow compression will be more of a bottleneck. So the approach of
> >increasing XZ compression levels has bad perspectives.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1879033] perl-XML-LibXML-2.0206 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|caillon+fedoraproject@gmail |
   |.com, ka...@ucw.cz, |
   |rhug...@redhat.com, |
   |rstr...@redhat.com, |
   |sandm...@redhat.com |
   Doc Type|--- |If docs needed, set a value




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

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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



--- Comment #4 from Petr Pisar  ---
This could be triggered by a "Fix setting a non-blocking mode in
IO::Socket::UNIX" patch I applied from upstream to perl in Fedora ≥ 33.
Previously, setting a blocking mode for UNIX sockets in Perl was ignored. Now
it is respected.

The t/64_pending_events_destroyed.t test creates a UNIX stream server and
spawns a UNIX stream client. Both of them in a non-blocking mode. Then it
connects the client to the server, and then it lets the client to write
"foobar", and read any response three times, then it connects for the second
time and again does the write and read three times. The server checks that it
received "foobar", then sends some data and it repeats it 6 times. The clients
uses a plain Perl, the server uses the Event library. The client interleaves
few sleeps, the server performs everything as fast as possible.

I can see the test does not perform any other synchronization. Especially it
blindly reads and writes without checking for the success and without verifying
it read and wrote everything to be written or to be expected to read. I believe
that the non-blocking mode coalesces the adjacent messages and that triggers
two failures: The server reads all three "foobar" in one read, and reports the
unexpected value "foobarfoobarfoobar". Then the server blocks indefinitely,
because it waits for another 5 messages that will never arrive, because the
client finished.


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

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

2020-09-15 Thread Bohdan Khomutskyi

Hello everyone,

Thanks for sharing your ideas and comments about this change.

Thanks to Mohan Boddu, I got RawHide DVD and netinstall images of
RawHide with the optimization features enabled. Those test composes are
available at the following locations:
https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200828.n.0/
(Plain SquashFS)

https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200908.n.1/compose/Server/x86_64/iso/
(Plain SquashFS and different xz compression options)

To select images from the test composes, I applied a patch from
https://github.com/rhinstaller/anaconda/pull/2829, so you can download
and run those images yourself to test the change:

https://drive.google.com/drive/folders/1tGsoqFMg2A6dQZHfuQNb9uDqYu9XEiPI

The result of benchmark will supplement already available data I
previously posted for Fedora Live images at
https://fedoraproject.org/wiki/Changes/OptimizeSquashFS

As a reminder, there are 2 levels for this optimization:

1. Making the SquashFS filesystem on the DVD plain (i.e. without
embedded EXT4 inside it) -- has the suffix plain-xz-128k.iso
2. In addition to #1, using a different compression parameters for the
SquashFS filesystem on the installation medium -- has the suffix
plain-xz-1M.iso

I propose to apply both of optimizations, using the highest possible
compression ratio supported by SquashFS. The highest compression ratio
in SquashFS corresponds to xz level 1 (out of 9 available presets).

Making the first change will reduce both x86-64 Boot and the x86-64 DVD
ISO by approximately 24 MiB. With both changes combined, the reduction
of size will be 70 MiB.

Because the SquashFS filesystem on the Live installation medium is of
bigger size, storage savings on the Live images are even higher (I
documented it in https://fedoraproject.org/wiki/Changes/OptimizeSquashFS)

On 05/09/2020 12:43, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Aug 27, 2020 at 11:13:26AM -0400, Ben Cotton wrote:

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

...

Based on the results above, I'd suggest selecting the following
''optimal configuration'': XZ algorithm, with block size of 1MiB and
without BCJ filter (plain xz -b 1M, without -Xbcj x86).
On the right, you can see the impact of the compression algorithms on
installation time.

As can be seen from the picture on the right hand side, selecting
'plain xz -b 1M configuration' has minimal impact on the installation
time and CPU usage during the installation. The compression will
result in +6.51% or, in real terms, +24.94s additional installation
time, compared to the savings of 142 MiB on the installation media,
== Benefit to Fedora ==
* Reduction of the installation media size and the cost of storing and
distributing Fedora.
* Reduction of the CPU usage at build time. Depending on which
compression parameters chosen.

Hi Bohdan,

I think there's a misalignment of priorities.

My evaluation is the following: users won't care. The image size difference
is not big enough for people to notice. OTOH, slower installation will
impact QA and VM installations. We're doing more and more automated
installations and tests, and this change impacts those tests negatively.

This increase in installation time will be compensated by the change
in the installer:https://github.com/rhinstaller/anaconda/pull/2292

This PR is very interesting. But it seems that the more we optimize
things, the more slow decompression will be noticable. I.e. in some
way, right now, the slow decompression is obscured by the slow IO
speed, multiple levels of block device, or slow processing of the
uncompressed data. Any time the input or output speed is improved,
slow compression will be more of a bottleneck. So the approach of
increasing XZ compression levels has bad perspectives.

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

--
Bohdan Khomutskyi
RHEL Compose release engineer
EXD Software production
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide

2020-09-15 Thread Ondřej Lysoněk

(maintainers of dependent packages in BCC)

Hi,

libevent will be rebased to 2.1.12 in Rawhide. The new version
includes a soname bump. Rebuilds of libevent and dependent packages
will happen in side tag 'f34-build-side-30069'.

Due to the nature of the dependency tree, we can't simply build all
dependent packages at the same time. We'll have to build in
batches. See my plan at the bottom of the email.

I'll reach out to individual maintainers when it's time to rebuild
their package. However, the new libevent is already built in the tag,
so if you own a package from the "Initial set", you don't have to wait
for me and you can start the rebuild right away using the following
command.

fedpkg build --target=f34-build-side-30069

I've performed test rebuilds of the dependent packages in COPR and it
went mostly well, so I don't expect any big issues. Some notable
things I found during the test rebuilds:
- some of the packages (libreswan, perl-Event-Lib, sems) fail to build
  for unrelated reasons. Unless these are fixed, they'll become
  uninstallable. I've notified their owners.
  - libreswan should hopefully get fixed soon by its own rebase
  - perl-Event-Lib will likely get orphaned
  - no response about sems
- I wasn't able to rebuild community-mysql, because for some reason,
  it fails to build in COPR (but builds fine in Koji). I guess we'll
  have to build this one with our fingers crossed.
- the new libevent breaks transmission slightly. Hopefully this will
  get fixed soon. Worst-case scenario, we'll temporarily revert the
  problematic libevent change, or come up with some temporary quick
  fix for transmission. Reported upstream:
  https://github.com/transmission/transmission/issues/1437
- due to a build dep loop, avahi will need to be bootstrapped
- I'm not sure if chromium really utilizes the system libevent - it
  seems to bundle it's own version. Nevertheless, it has BuildRequires
  for libevent-devel, so it's included in my list.
  
List of dependent packages:
- 389-ds-base
- addrwatch
- avahi
- ccnet
- chromium
- community-mysql
- coturn
- fragments
- fstrm
- gearmand
- getdns
- groonga
- icecat
- Io-language
- ladvd
- libasr
- libcouchbase
- libmemcached
- libreswan
- libverto
- links
- lldpd
- lua-event
- mediaconch
- memcached
- mpris-scrobbler
- nbd-runner
- netatalk
- nfs-utils
- nsd
- ntp
- ocproxy
- openmpi
- opensmtpd
- perl-Event-Lib
- pgbouncer
- php-pecl-event
- php-pecl-http
- php-pecl-memcached
- pmix
- qt5-qtwebengine
- remctl
- scanssh
- seafile
- sems
- sslsplit
- sstp-client
- suricata
- thrift
- tmate
- tmux
- tor
- transmission
- trickle
- unbound
- uwsgi
- zabbix

Here is my plan for the rebuild process. Note that the "After ... is
rebuilt" paragraphs can be executed in any order - just their
respective dependencies must be met.

Initial set:
- avahi - needs to be bootstrapped
- packages that I haven't been able to rebuild:
  - community-mysql, libreswan, perl-Event-Lib, sems
- other: addrwatch, ccnet, coturn, groonga, ladvd, libasr,
  libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner,
  nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event,
  php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit,
  sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix

After avahi is rebuilt, we can rebuild:
389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event,
netatalk, qt5-qtwebengine, thrift, tor, transmission

After unbound and avahi is rebuilt, we can rebuild:
chromium, getdns

After memcached is rebuilt, we can rebuild:
libmemcached

After memcached and libmemcached is rebuilt, we can rebuild:
gearmand, Io-language, php-pecl-memcached

After qt5-qtwebengine is rebuilt, we can rebuild:
mediaconch

After pmix and avahi is rebuilt, we can rebuild:
openmpi

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

[Bug 1878992] Upgrade perl-Test-MockModule to 0.174.0

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-669342571e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-669342571e


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

Fedora-Cloud-32-20200915.0 compose check report

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20200914.0):

ID: 665791  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/665791

Passed openQA tests: 6/7 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1879033] New: perl-XML-LibXML-2.0206 is available

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

Bug ID: 1879033
   Summary: perl-XML-LibXML-2.0206 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-XML-LibXML
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.0206
Current version/release in rawhide: 2.0205-3.fc33
URL: https://metacpan.org/release/XML-LibXML

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from anitya:
https://release-monitoring.org/project/3527/


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

[Bug 1878992] Upgrade perl-Test-MockModule to 0.174.0

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||p...@city-fan.org
   Fixed In Version||perl-Test-MockModule-0.174.
   ||0-1.fc34
   Assignee|spo...@gmail.com|p...@city-fan.org




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

[EPEL-devel] EPEL playground && mock builds against released repos

2020-09-15 Thread Pavel Raiskup

Hi, we ship epelplayground-8-x86_64.cfg file in mock-core-configs so users can
reproduce builds locally with mock.  Initially the configuration worked, but it
has been failing for quite some time now.  Dnf isn't able to --installroot:

No matches found for the following disable plugin patterns: local, spacewalk
CentOS-8 - Base  12 MB/s | 2.2 MB 00:00
CentOS-8 - AppStream 21 MB/s | 5.8 MB 00:00
CentOS-8 - PowerTools11 MB/s | 1.9 MB 00:00
CentOS-8 - Extras33 kB/s | 7.3 kB 00:00
Extra Packages for Enterprise Linux 8 - Playgro  15 MB/s | 6.1 MB 00:00
Error:
 Problem: conflicting requests
  - nothing provides fpc-srpm-macros needed by 
epel-rpm-macros-8-16.playground.noarch
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to 
use not only best candidate packages)

I'm not sure we miss something there, but it looks like the shipped chroot is
broken.  The mock bug report [1], and fpc-srpm-macros report [2].

Local mock builds are done against CentOS repositories, so I'm not sure where to
report this problem, if here or to CentOS (but starting here as I believe that
fpc-srpm-macros should go to the playground repo).

Also another question is whether we can fix the chroot, or not (dropping the
config file from mock-core-configs is an option, too).

[1] https://github.com/rpm-software-management/mock/issues/620
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1875057

Pavel


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

[Bug 1876460] perl-Event-Lib FTBFS in F33 and Rawhide

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



--- Comment #3 from Ondřej Lysoněk  ---
(In reply to Nicolas Chauvet (kwizart) from comment #2)
> Well, It seems like I'm assignee by miss-take on this package, 
> 
> Free free to maintain, rebuild anything, specially take-over the package.

Ok, thanks for the info!

You seem to be listed as the maintainer in Pagure, so if you're not interested
in maintaining the package, I believe you should orphan it.
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Orphaning_Procedure


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

Re: [EPEL-devel] Proposing an EPEL packaging SIG

2020-09-15 Thread Pierre-Yves Chibon

On Mon, Sep 14, 2020 at 08:54:57AM -0700, Kevin Fenzi wrote:
> On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote:

> > There are several changes we can make to both streamline the process,
> > and not increase the maintenance burden on the (other) maintainers of
> > these packages:
> > 
> > * Have an EPEL SIG modeled after the SIGs centered around programming
> > language stacks (e.g. Python, Haskell, Java)
> > * Have an expedited flow where this SIG can request EPEL branches and
> > admin access to packages if there are no response from package
> > maintainers for a set period (3 days? 1 week?)
> 
> Both of those are really short... I guess a week or two might be ok. 

The old pkgdb had one week for this (if after a week of the branch request being
opened the current admins had not rejected the branching (with a reason), the
branch request was processed).


Pierre


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

[Bug 1874449] Upgrade perl-Type-Tiny to 1.010006

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade perl-Type-Tiny to   |Upgrade perl-Type-Tiny to
   |1.010005|1.010006



--- Comment #1 from Jitka Plesnikova  ---
Latest Fedora delivers 1.010004 version. Upstream released 1.010006. 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-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1878992] New: Upgrade perl-Test-MockModule to 0.174.0

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

Bug ID: 1878992
   Summary: Upgrade perl-Test-MockModule to 0.174.0
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-MockModule
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.173.0 version. Upstream released 0.174.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-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1878987] New: Upgrade perl-Crypt-SMIME to 0.27