Re: [atomic-announce] Fedora Atomic Host Two Week Release Announcement: 29.20190708.0

[Sinny Kumari]

On Tue, Jul 9, 2019 at 1:59 AM  wrote:

>
> A new Fedora Atomic Host update is available via an OSTree update:
>
> Version: 29.20190708.0
> Commit(x86_64):
> e4c5affdeff6cbe5c494cbad48419d9746c017f17b46e97ae83639f6328989ce
> Commit(aarch64):
> 58d13ffe3fff2cba3736dfc6a1158991e5d8845fa16b8b501b6b03c7fead3af3
> Commit(ppc64le):
> ea961b706191a4fd6bab4e5b6dda2f5250497a0d1b7fc1831a11796b5af6f57e
>
>
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
>
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
>
> Corresponding image media for new installations can be downloaded from:
>
> https://getfedora.org/en/atomic/download/
>
> Alternatively, image artifacts can be found at the following links:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190708.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190708.0.iso
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.qcow2
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.raw.xz
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-libvirt.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-virtualbox.box
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190708.0.iso
>
> Respective signed CHECKSUM files can be found here:
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
>
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
>
> For direct download, the "latest" targets are always available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest
> https://getfedora.org/atomic_raw_x86_64_latest
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest
> https://getfedora.org/atomic_raw_aarch64_latest
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest
>
> ppc64le:
> https://getfedora.org/atomic_qcow2_ppc64le_latest
> https://getfedora.org/atomic_raw_ppc64le_latest
> https://getfedora.org/atomic_dvd_ostree_ppc64le_latest
>
> Filename fetching URLs are available here:
> x86_64:
> https://getfedora.org/atomic_qcow2_x86_64_latest_filename
> https://getfedora.org/atomic_raw_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename
>
> aarch64:
> https://getfedora.org/atomic_qcow2_aarch64_latest_filename
> https://getfedora.org/atomic_raw_aarch64_latest_filename
> https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

[Bug 1726163] fusioninventory-agent-2.5.1 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
fusioninventory-agent-2.5.1-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-3ff27ac119

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-07-09 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

___
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

[389-devel] 389 DS nightly 2019-07-09 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/07/09/report-389-ds-base-1.4.1.5-20190708git7483341.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/389-devel@lists.fedoraproject.org

[Bug 1727480] perl-DBD-Pg-3.8.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-DBD-Pg-3.8.1-1.fc30 has been pushed to the Fedora 30 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-944097f498

-- 
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 1726163] fusioninventory-agent-2.5.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
fusioninventory-agent-2.5.1-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9faea39bf7

-- 
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 1725350] perl-Finance-Quote-1.48 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Finance-Quote-1.48-1.f |perl-Finance-Quote-1.48-1.f
   |c31 |c31
   ||perl-Finance-Quote-1.48-1.f
   ||c30
 Resolution|--- |ERRATA
Last Closed||2019-07-09 00:56:18



--- Comment #5 from Fedora Update System  ---
perl-Finance-Quote-1.48-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, 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: Contents of devel Digest, Vol 185, Issue 29... rpmlint: shared-lib-without-dependency-information

[Steven Munroe]

I have a similar problem with the proposed package pveclib. I my case I
have a data only libraries. I can eliminate the rpmlint error by forcing a
link to -lc But I am not sure the the appropriate solution.

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


>
> -- Forwarded message --
> From: Florian Weimer 
> To: "Miro Hrončok" 
> Cc: devel@lists.fedoraproject.org, Marcel Plch 
> Bcc:
> Date: Mon, 08 Jul 2019 15:25:27 +0200
> Subject: Re: rpmlint: shared-lib-without-dependency-information (parts of
> Python stdlib)
> * Miro Hrončok:
>
> > On 05. 02. 19 19:04, Miro Hrončok wrote:
> >> I've just spotted these when working on Python 3.8.0a1. This happens
> >> on 3.7 as well since GCC 9:
> >>
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37dm-x86_64-linux-gnu.so
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
> >>
> >> python3-libs.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37m-x86_64-linux-gnu.so
> >> python3-test.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37m-x86_64-linux-gnu.so
> >>
> >>
> >> (Note that there are plenty of other extension modules that do not
> >> raise this error.)
> >>
> >> This doesn't happen with latest python3 built prior to the gcc update
> to 9.
> >>
> >> $ rpmlint -I library-not-linked-against-libc
> >> library-not-linked-against-libc:
> >>
> >> That isn't helpful either.
> >>
> >> I found a similar Debian thing [1] that says:
> >>
> >>  > It is theoretically possible to have a library which doesn't use any
> symbols
> >>  > from libc...
> >>
> >> Do I care? Should I fix something? I honestly have no idea.
> >>
> >> [1]
> https://lintian.debian.org/tags/library-not-linked-against-libc.html
> >
> >
> > We have new errors on F30+:
> >
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> contextvars.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testimportmultiple.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testinternalcapi.cpython-38-x86_64-linux-gnu.so
> >
> > rpmlint doesn't give much info:
> > $ rpmlint -I shared-lib-without-dependency-information
> > shared-lib-without-dependency-information:
> >
> >
> > But lintian again explains the issue:
> >
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
> >
> > The listed shared library doesn't include information about which
> > other libraries the library was linked against. (When running "ldd
> > foo.so" ldd should report about these other libraries. In your case,
> > ldd just reports "statically linked".)
> >
> > I again think this is OK for Python extension modules.
> > Thoughts?
>
> It depends on the extension module.  For _contextvars, it's okay because
> it does not link against anything (glibc or otherwise).  Global C++
> destructors will not work because of unfulfilled weak reference to
> __cxa_finalize, but you probably do not care about that.
>
> rpmlint really should have a list of symbols from system libraries that
> need linking, otherwise there's always going to be false positives for
> such plugins.  (Although extension modules could link against libpython
> on Fedora because Fedora doesn't use the fat Python interpreter, unlike
> some other distributions.)
>
> Thanks,
> Florian
>
>
>
___
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

[389-devel] please review: PR 50487 - Update jemalloc to 5.2.0

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/50487

--

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

[Bug 1728040] New: perl-Test-Compile-2.2.1 is available

[bugzilla]

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

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



Latest upstream release: 2.2.1
Current version/release in rawhide: 2.2.0-1.fc31
URL: http://search.cpan.org/dist/Test-Compile/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/3388/

-- 
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: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Nicolas Chauvet]

Le lun. 8 juil. 2019 à 21:29, Ty Young  a écrit :
>
> Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307
>
> The driver itself seems perfectly fine in that the system boots and OpenGL 
> works perfectly fine. Games are playable.
>
> How do I output strace to a file directly? It spits out way too much info.
>
> The bug is reproducible by doing a fresh install on a new downloaded ISO but 
> really the likelihood that this is a bug caused by Nvidia is slim to none. 
> Arch Linux(what I primarily use) has the same driver version and everything 
> works perfectly fine.
>
> Regardless of whether or not this specific bug was by a packaging issue or 
> Nvidia, the way Fedora packages the Nvidia drivers is bad:
>
> -nvidia-smi isn't specific to CUDA and is a core Nvidia library interface 
> that should come with the base driver as it does in Windows.
That's moot, but the comparison with nvidia on Windows is not
relevant. if you want nvidia-smi, please install
xorg-x11-drv-nvidia-cuda
Previously nvidia-smi relied on any cuda lib, so it was moved on the
cuda side, but we can re-evaluate this, I take take a RFE.

With that said, the appropriate doc is here:
https://rpmfusion.org/Howto/NVIDIA
It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
that's the interface we rely on. (Everything else should be
auto-detected on purpose).
Also to wait a few for the module to build and install and reboot
(it's explicitly required).

> -nvidia-settings is the Linux alternative to Window's control panel and if 
> not included by default, *should* be included via a "meta" package for 
> desktop users.
It's a separate package, but it is required by the drivers as it's
mandatory indeed. So I don't understand the metapackage thing, it's a
solution for others distros, the Fedora ways is different. (virtual
provides , booleans dependencies, etc).

> -OpenGL not packaged with the driver(or again, install-able via a meta 
> package)? Who wants a graphics driver without OpenGL/Vulkan support?
Well, some people want to have selectables sub-packages as
appropriate, and the split made by RPM Fusion is carefully minded. But
we still welcome improvements.

> -it isn't clear if the command I posted(above) installs the 32-bit libraries 
> or not. Really, meta packages would go a long way in simplifying GPU driver 
> installs!
In regular Fedora, it will install the 32bit libraries on purpose with
the nvidia driver if you have at least a package that requires 32bit
libGL. (same for cuda-libs).

> Neither Windows nor even other Linux distros fragment the driver this much. 
> You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit 
> libraries to equal Fedora's fragmented driver packaging in some distros. Why?
Well, It could be worst. You could have sub-packages depending on the
need to run headless or without Xorg or without wayland dependencies
etc.
That's constraints you might not have, but a good packaging should
works everywhere.

With that said the rpm-ostree line you have used is silly with respect
to the need to llst all sub-packages. Can you point me to the
documentation you have used ?
Thx

-- 
-

Nicolas (kwizart)
___
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: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome

[Vitaly Zaitsev via devel]

Hello, John Florian.

Mon, 8 Jul 2019 15:45:38 -0400 you wrote:

> Along these lines, what's the status of Plasma on Wayland?

Too unstable. Crashes a lot, especially on NVIDIA.

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.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

Fedora Atomic Host Two Week Release Announcement: 29.20190708.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190708.0
Commit(x86_64): e4c5affdeff6cbe5c494cbad48419d9746c017f17b46e97ae83639f6328989ce
Commit(aarch64): 
58d13ffe3fff2cba3736dfc6a1158991e5d8845fa16b8b501b6b03c7fead3af3
Commit(ppc64le): 
ea961b706191a4fd6bab4e5b6dda2f5250497a0d1b7fc1831a11796b5af6f57e


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190708.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190708.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190708.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190708.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190708.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190708.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190708.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190708.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename

[EPEL-devel] Current EPEL-8 Production Layout

[Stephen John Smoogen]

# EPEL-8 Production Layout

## TL; DR:
1. EPEL-8 will have a multi-phase rollout into production.
2. EPEL-8.0 will build using existing grobisplitter in order to use a
'flattened' build system without modules.
3. EPEL-8.1 will start in staging without grobisplitter and using default
modules via mock.
4. The staging work will allow for continual development changes in koji,
'ursa-prime', and MBS functionality to work without breaking Fedora 31 or
initial EPEL-8.0 builds.
5. EPEL-8.1 is tentatively to be ready by November 2019 after Fedora 31
around the time that RHEL-8.1 may release (if it uses a 6 month cadence.)

## Multi-phase rollout

[As documented elsewhere](
https://smoogespace.blogspot.com/2019/06/epel-8.html), EPEL-8 has been
slowly rolling out due to the many changes in RHEL and in the Fedora build
system since EPEL-7 was initiated in 2014. Trying to roll out an EPEL-8
which was 'final' and thus the way it always will be was too prone to
failure as we find we have to constantly change plans to match reality.

We will be rolling out EPEL-8 in a multi-phase release cycle. Each cycle
will allow for hopefully greater functionality for developers and
consumers. On the flip side, we will find that we have to change
expectations of what can and can not be delivered inside of EPEL over that
time.

Phases:
1. 8.0 will be a 'minimal viability'. Due to unshipped development
libraries and the lack of building replacement modules, not all packages
will be able to build. Instead only non-modular RPMs which can rely on only
'default' modules will work. Packages must also only rely on what is
shipped in RHEL-8.0 BaseOS/AppStream/CodeReadyBuilder channels versus any
'unshipped -devel' packages.
2. 8.1 will add on 'minimal modularity'. Instead of using a flattened build
system, we will look at updating koji to have basic knowledge of
modularity, use a tool to tag in packages from modules as needed, and
possibly add in the Module Build System (MBS) in order to ship modules.
3. 8.2 will finish adding in the Module Build System and will enable gating
and CI into the workflow so that packages can tested faster.

Due to the fact that the phases will change how EPEL is produced, there may
be need to be mass rebuilds between each one. There will also be changes in
policies about what packages are allowed to be in EPEL and how they would
be allowed.


## Problems with koji, modules and mock

If you are wanting to build packages in mock, you can set up a lot of
controls in ``/etc/mock/foo.cfg`` which will turn on and off modules as
needed so that you can enable the ``javapackages-tools`` or ``virt-devel``
module so that packages like ``libssh2-devel`` or ``javapackages-local``
are available. However koji does not allow this control per channel because
it is meant to completely control what packages are brought into a
buildroot. Every build records what packages were used to build an artifact
and koji will create a special mock config file to pull in those items.
This allows for a high level of auditability and confirmation that the
package stored is the package built, and that what was built used certain
things.

For building an operating system like Fedora or Red Hat Enterprise Linux
(RHEL), this works great because you can show how things were done 2-3
years later when trying to debug something else. However when koji does not
'own' the lifecycle of packages this becomes problematic. In building EPEL,
the RHEL packages are given to the buildroot via external repositories.
This means that koji does not fully know the lifecycle of the packages it
'pulls' in to the buildroot. In a basic mode it will choose packages it has
built/knows about first, then packages from the buildroot, and if there is
a conflict from external packages will try to choose the one with the
highest ``epoch-version-release-timestamp`` so that only the newest version
is in. (If the timestamp is the same, it tends to refuse to use both
packages).

An improvement to this was adding code to ``mergerepo`` which allows for
dnf to make a choice on which packages to use between repositories. This
allows for mock's dnf to pull in modules without the repositories having
been mangled or 'flattened' as with grobisplitter. However, it is not a
complete story. For DNF to know which modules to pull in it needs to set an
environment variable for the platform (for fedora releases it is something
like f30 and for RHEL it is el8). Koji doesn't know how to do this so the
solution would be to set it in the build systems
``/etc/mock/site-defaults.cfg`` but that would affect all builds and would
cause problems for building Fedora on the same build system.

## Grobisplitter

A second initiative to deal with building with modules was to try and take
modules out of the equation completely. Since a module is a virtual
repository embedded in a real one, you should be able to pull them apart
and make new ones. [Grobisplitter](
https://pagure.io/puiterwijk/grobisplitter) was 

Re: Fedora 31 Self-Contained Change proposal: Qt Wayland By Default on Gnome

[John Florian]

On 2019-06-28 18:28, Kevin Kofler wrote:

Quoting from the proposal:

Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols

Actually, the primary selection protocol (middle-click paste) is only
supported in Qt ≥ 5.14 (not released yet). (It also requires a compositor
implementing the final specification. I'm not sure whether GNOME Shell
already moved from the GNOME private version to the upstreamed version of
the protocol.)



Along these lines, what's the status of Plasma on Wayland?  Any idea 
when this might become the default way of running Plasma on 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

Plan: Update virtualenv to 16.6 and drop Python 2.6 and Jython support

[Miro Hrončok]

Just a heads up that I plan to do $subject in upcoming week in rawhide.

Let me know if I should not.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org

Plan: Update virtualenv to 16.6 and drop Python 2.6 and Jython support

[Miro Hrončok]

Just a heads up that I plan to do $subject in upcoming week in rawhide.

Let me know if I should not.

--
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: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/8/19 11:00 AM, Neal Gompa wrote:
> On Mon, Jul 8, 2019 at 10:39 AM Daniel Walsh  wrote:
>> Their has not been much progress on runc development for this, which
>> might be a blocker.
>>
>> In the Podman/Buildah world, we have support for crun, an alternate OCI
>> Runtime replacement for runc.  crun supports cgroupsv2.
>>
>> There has been little movement in Kubernetes and OpenShift for adding
>> this support, but there has also been little incentive, since no OS Has
>> moved to it.
>>
>> Can systemd turn on the cgroupsv2 by default in Rawhide, to see what
>> complaints happen.
> I would be shocked if Fedora having it switched on would matter. We
> don't have a recent version of OpenShift or Kubernetes in our
> repositories...
>
It will also break Moby-Engine and Docker-ce.
> --
> 真実はいつも一つ！/ 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

___
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: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Ty Young]

Bug filed: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5307

The driver itself seems perfectly fine in that the system boots and OpenGL
works perfectly fine. Games are playable.

How do I output strace to a file directly? It spits out way too much info.

The bug is reproducible by doing a fresh install on a new downloaded ISO
but really the likelihood that this is a bug caused by Nvidia is slim to
none. Arch Linux(what I primarily use) has the same driver version and
everything works perfectly fine.

Regardless of whether or not this specific bug was by a packaging issue or
Nvidia, the way Fedora packages the Nvidia drivers is bad:

-nvidia-smi isn't specific to CUDA and is a core Nvidia library interface
that should come with the base driver as it does in Windows.
-nvidia-settings is the Linux alternative to Window's control panel and if
not included by default, *should* be included via a "meta" package for
desktop users.
-OpenGL not packaged with the driver(or again, installable via a meta
package)? Who wants a graphics driver without OpenGL/Vulkan support?
-it isn't clear if the command I posted(above) installs the 32-bit
libraries or not. Really, meta packages would go a long way in simplifying
GPU driver installs!

Neither Windows nor even other Linux distros fragment the driver this much.
You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit
libraries to equal Fedora's fragmented driver packaging in some distros.
Why?


On Mon, Jul 8, 2019 at 10:37 AM Nicolas Chauvet  wrote:

> Le lun. 8 juil. 2019 à 16:30, Ty Young  a écrit :
> >
> > Hi,
> >
> >
> > To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
> > overclocking support is currently broken. Not even nvidia-settings is
> > able to set a GPU core offset value via GUI despite a correct coolbits
> > value being set. This use to work some updates ago. Wayland is not being
> > used.
> >
> >
> > Command used to install the driver and related utils:
> >
> >
> > rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> > xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
> > xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
> >
> >
> > Attempting to set an overclocking value via command line just results in
> > an "unknown error" message. nvidia-settings doesn't even know what's
> > going on in Fedora Silverblue 30.
> >
> >
> > Can this please be looked into & fixed?
>
> Not yet, you need to provide more useful info as stated in the RPM Fusion
> wiki
> https://rpmfusion.org/Howto/NVIDIA#Bug_Report
>
> Once we can determine the driver is in good state, a strace log of
> nvidia-settings would be useful.
> Please report to bugzilla.rpmfusion.org for now, but if it's
> reproducible and not related to packaging, you will have to forward to
> nvidia directly.
>
> Thx
>
> --
> -
>
> Nicolas (kwizart)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[Daniel Walsh]

On 7/3/19 6:50 PM, Stephen John Smoogen wrote:
>
>
> On Wed, 3 Jul 2019 at 17:15, Robert-André Mauchin  > wrote:
>
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as
> part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-"
> prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as
> the new
> > maintainer.
> >
> > Thanks.
> >
> > David
>
>
> Wasn't there a « Container team » taking care of those packages?
>
>
> And there was a "Cloud team" and a "Server team" and a... there is no
> promise that said teams will last for any longer than the last
> interested person on it. 

Correct the Container Engine team is concentrating on Podman, Skopeo,
Buildah and CRI-O, as replacements of Docker.  We originally helped get
Moby Engine into Fedora, but need volunteers for ongoing maintenance.

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


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

Re: Orphaned packages need new maintainers

[Fabio Valentini]

On Mon, Jul 8, 2019 at 5:35 PM Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via https://pagure.io/releng/issues
>
> Find the full report at
> https://churchyard.fedorapeople.org/orphans-2019-07-08.txt
> (grep for your FAS username and follow the dependencies)
>
>
>   Package  (co)maintainers Status
> Change
>
> ===
> aeshgil, lef, orphan  4 weeks
> ago
> bean-validation-api gil, lef, orphan  4 weeks
> ago
> cdi-api1gil, orphan   4 weeks
> ago
> cmdtest orphan6 weeks
> ago
> concurrent  orphan4 weeks
> ago
> containers  orphan1 weeks
> ago
> cookcc  gil, lef, orphan  4 weeks
> ago
> cookxml orphan4 weeks
> ago
> crypto-utilsjorton, orphan5 weeks
> ago
> csvcat  orphan3 weeks
> ago
> cxf-build-utils gil, lef, orphan  4 weeks
> ago
> cxf-xjc-utils   gil, lef, orphan  4 weeks
> ago
> derby   orphan1 weeks
> ago
> derelictcicku, kalev, orphan  1 weeks
> ago
> dreampiecicku, orphan 3 weeks
> ago
> dsymbol orphan1 weeks
> ago
> dustmitecicku, kalev, orphan  1 weeks
> ago
> dvb-appsorphan, pbrobinson0 weeks
> ago
> earth-and-moon-backgrounds  orphan1 weeks
> ago
> faience-icon-theme  orphan3 weeks
> ago
> fedocal infra-sig, orphan 4 weeks
> ago
> felix-configadmin   orphan4 weeks
> ago
> flr orphan6 weeks
> ago
> gcomprisjwrdegoede, limb, orphan  1 weeks
> ago
> genbackupdata   orphan6 weeks
> ago
> gl3ncicku, kalev, orphan  1 weeks
> ago
> gnome-shell-extension-simple-dock   orphan3 weeks
> ago
> gnumed-server   orphan6 weeks
> ago
> gscribble   orphan6 weeks
> ago
> hibernate-commons-annotations   gil, lef, orphan  4 weeks
> ago
> hibernate-hql   gil, lef, orphan  4 weeks
> ago
> hibernate-searchgil, lef, orphan  4 weeks
> ago
> hibernate-validator gil, lef, orphan  4 weeks
> ago
> jacorb  gil, lef, orphan  4 weeks
> ago
> jandex  gil, orphan   4 weeks
> ago
> jaxws-jboss-httpserver-httpspi  lef, orphan   4 weeks
> ago
> jaxws-undertow-httpspi  gil, lef, orphan  4 weeks
> ago
> jberet  gil, lef, orphan  4 weeks
> ago
> jboss-annotations-1.1-api   orphan4 weeks
> ago
> jboss-classfilewriter   gil, lef, orphan  4 weeks
> ago
> jboss-common-core   gil, lef, orphan  4 weeks
> ago
> jboss-dmr   gil, lef, orphan  4 weeks
> ago
> jboss-ejb-3.1-api   orphan4 weeks
> ago
> jboss-el-3.0-apigil, lef, orphan  4 weeks
> ago
> jboss-httpserverorphan4 weeks
> ago
> jboss-iiop-client   lef, orphan   4 weeks
> ago
> jboss-integration   lef, orphan   4 weeks
> ago
> jboss-interceptors-1.1-api  orphan4 weeks
> ago
> 

Orphaned packages need new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via https://pagure.io/releng/issues

Find the full report at
https://churchyard.fedorapeople.org/orphans-2019-07-08.txt
(grep for your FAS username and follow the dependencies)


 Package  (co)maintainers Status Change
===
aeshgil, lef, orphan  4 weeks ago
bean-validation-api gil, lef, orphan  4 weeks ago
cdi-api1gil, orphan   4 weeks ago
cmdtest orphan6 weeks ago
concurrent  orphan4 weeks ago
containers  orphan1 weeks ago
cookcc  gil, lef, orphan  4 weeks ago
cookxml orphan4 weeks ago
crypto-utilsjorton, orphan5 weeks ago
csvcat  orphan3 weeks ago
cxf-build-utils gil, lef, orphan  4 weeks ago
cxf-xjc-utils   gil, lef, orphan  4 weeks ago
derby   orphan1 weeks ago
derelictcicku, kalev, orphan  1 weeks ago
dreampiecicku, orphan 3 weeks ago
dsymbol orphan1 weeks ago
dustmitecicku, kalev, orphan  1 weeks ago
dvb-appsorphan, pbrobinson0 weeks ago
earth-and-moon-backgrounds  orphan1 weeks ago
faience-icon-theme  orphan3 weeks ago
fedocal infra-sig, orphan 4 weeks ago
felix-configadmin   orphan4 weeks ago
flr orphan6 weeks ago
gcomprisjwrdegoede, limb, orphan  1 weeks ago
genbackupdata   orphan6 weeks ago
gl3ncicku, kalev, orphan  1 weeks ago
gnome-shell-extension-simple-dock   orphan3 weeks ago
gnumed-server   orphan6 weeks ago
gscribble   orphan6 weeks ago
hibernate-commons-annotations   gil, lef, orphan  4 weeks ago
hibernate-hql   gil, lef, orphan  4 weeks ago
hibernate-searchgil, lef, orphan  4 weeks ago
hibernate-validator gil, lef, orphan  4 weeks ago
jacorb  gil, lef, orphan  4 weeks ago
jandex  gil, orphan   4 weeks ago
jaxws-jboss-httpserver-httpspi  lef, orphan   4 weeks ago
jaxws-undertow-httpspi  gil, lef, orphan  4 weeks ago
jberet  gil, lef, orphan  4 weeks ago
jboss-annotations-1.1-api   orphan4 weeks ago
jboss-classfilewriter   gil, lef, orphan  4 weeks ago
jboss-common-core   gil, lef, orphan  4 weeks ago
jboss-dmr   gil, lef, orphan  4 weeks ago
jboss-ejb-3.1-api   orphan4 weeks ago
jboss-el-3.0-apigil, lef, orphan  4 weeks ago
jboss-httpserverorphan4 weeks ago
jboss-iiop-client   lef, orphan   4 weeks ago
jboss-integration   lef, orphan   4 weeks ago
jboss-interceptors-1.1-api  orphan4 weeks ago
jboss-invocationgil, lef, orphan  4 weeks ago
jboss-jacc-1.5-api  lef, orphan   4 weeks ago
jboss-jaxb-intros   lef, orphan   4 weeks ago
jboss-jaxrpc-1.1-apigil, orphan   4 

Orphaned packages need new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via https://pagure.io/releng/issues

Find the full report at
https://churchyard.fedorapeople.org/orphans-2019-07-08.txt
(grep for your FAS username and follow the dependencies)


 Package  (co)maintainers Status Change
===
aeshgil, lef, orphan  4 weeks ago
bean-validation-api gil, lef, orphan  4 weeks ago
cdi-api1gil, orphan   4 weeks ago
cmdtest orphan6 weeks ago
concurrent  orphan4 weeks ago
containers  orphan1 weeks ago
cookcc  gil, lef, orphan  4 weeks ago
cookxml orphan4 weeks ago
crypto-utilsjorton, orphan5 weeks ago
csvcat  orphan3 weeks ago
cxf-build-utils gil, lef, orphan  4 weeks ago
cxf-xjc-utils   gil, lef, orphan  4 weeks ago
derby   orphan1 weeks ago
derelictcicku, kalev, orphan  1 weeks ago
dreampiecicku, orphan 3 weeks ago
dsymbol orphan1 weeks ago
dustmitecicku, kalev, orphan  1 weeks ago
dvb-appsorphan, pbrobinson0 weeks ago
earth-and-moon-backgrounds  orphan1 weeks ago
faience-icon-theme  orphan3 weeks ago
fedocal infra-sig, orphan 4 weeks ago
felix-configadmin   orphan4 weeks ago
flr orphan6 weeks ago
gcomprisjwrdegoede, limb, orphan  1 weeks ago
genbackupdata   orphan6 weeks ago
gl3ncicku, kalev, orphan  1 weeks ago
gnome-shell-extension-simple-dock   orphan3 weeks ago
gnumed-server   orphan6 weeks ago
gscribble   orphan6 weeks ago
hibernate-commons-annotations   gil, lef, orphan  4 weeks ago
hibernate-hql   gil, lef, orphan  4 weeks ago
hibernate-searchgil, lef, orphan  4 weeks ago
hibernate-validator gil, lef, orphan  4 weeks ago
jacorb  gil, lef, orphan  4 weeks ago
jandex  gil, orphan   4 weeks ago
jaxws-jboss-httpserver-httpspi  lef, orphan   4 weeks ago
jaxws-undertow-httpspi  gil, lef, orphan  4 weeks ago
jberet  gil, lef, orphan  4 weeks ago
jboss-annotations-1.1-api   orphan4 weeks ago
jboss-classfilewriter   gil, lef, orphan  4 weeks ago
jboss-common-core   gil, lef, orphan  4 weeks ago
jboss-dmr   gil, lef, orphan  4 weeks ago
jboss-ejb-3.1-api   orphan4 weeks ago
jboss-el-3.0-apigil, lef, orphan  4 weeks ago
jboss-httpserverorphan4 weeks ago
jboss-iiop-client   lef, orphan   4 weeks ago
jboss-integration   lef, orphan   4 weeks ago
jboss-interceptors-1.1-api  orphan4 weeks ago
jboss-invocationgil, lef, orphan  4 weeks ago
jboss-jacc-1.5-api  lef, orphan   4 weeks ago
jboss-jaxb-intros   lef, orphan   4 weeks ago
jboss-jaxrpc-1.1-apigil, orphan   4 

Re: Fedora Data Engineering SIG: interested in a Fedora SIG to work on this?

[Gerald Henriksen]

On Fri, 5 Jul 2019 11:23:06 +0800, you wrote:

>I think documentation alone is not enough to make things easy, as to make
>the software better integrate with Fedora would require some more
>additional work (eg: systemd integration, quick painless installation,
>prebuilt binaries) ..
>
>What about docker images, or vendor-rpm, or automated install scripts
>approach?. Would that work?.

Not if it goes against what the users expect, as it doesn't matter if
your solution is superior if it is too different than what the
community expects / is used to.

Speaking generalities.

My position has evolved, and I have now taken the position that if a
language (like Python) has a built in infrastructure for package
installation I no longer install any Fedora packages beyond the basics
(ie the compiler/interpreter).

Whether it is good or bad, it is no longer worth fighting those
communities and instead I follow their "best practices" and use their
package systems.

You obviously can decide otherwise.

But based on the above, my advice is to see how the communities
operate and find out how best to make Fedora work for those
communities.  

For example, anything that uses the JVM it is likely the only thing
that will install from Fedora is OpenJDK - the communities built
around Java will not use distribution packaged versions of the
software, preferring to install via direct downloads or Maven.

Similiarly with Python, every blog post, video, or book states to do
"pip install ..." and it doesn't matter if an RPM is better integrated
into Fedora as few will go against the community.

Obviously there are exceptions, like anything written in C where they
don't (yet) have their own packaging system and so that stuff likely
should be packaged.

Which comes back to my original post suggesting documentation, as it
isn't so much about making things easy as just making the vast
majority of potential users aware that there are other Linux
alternatives other than say Ubuntu, which seems to dominate that
existing mindset of blog posts and other documentation.
___
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: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Neal Gompa]

On Mon, Jul 8, 2019 at 10:39 AM Daniel Walsh  wrote:
>
> Their has not been much progress on runc development for this, which
> might be a blocker.
>
> In the Podman/Buildah world, we have support for crun, an alternate OCI
> Runtime replacement for runc.  crun supports cgroupsv2.
>
> There has been little movement in Kubernetes and OpenShift for adding
> this support, but there has also been little incentive, since no OS Has
> moved to it.
>
> Can systemd turn on the cgroupsv2 by default in Rawhide, to see what
> complaints happen.

I would be shocked if Fedora having it switched on would matter. We
don't have a recent version of OpenShift or Kubernetes in our
repositories...


--
真実はいつも一つ！/ 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: Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Nicolas Chauvet]

Le lun. 8 juil. 2019 à 16:30, Ty Young  a écrit :
>
> Hi,
>
>
> To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion,
> overclocking support is currently broken. Not even nvidia-settings is
> able to set a GPU core offset value via GUI despite a correct coolbits
> value being set. This use to work some updates ago. Wayland is not being
> used.
>
>
> Command used to install the driver and related utils:
>
>
> rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia
> xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig
> xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs
>
>
> Attempting to set an overclocking value via command line just results in
> an "unknown error" message. nvidia-settings doesn't even know what's
> going on in Fedora Silverblue 30.
>
>
> Can this please be looked into & fixed?

Not yet, you need to provide more useful info as stated in the RPM Fusion wiki
https://rpmfusion.org/Howto/NVIDIA#Bug_Report

Once we can determine the driver is in good state, a strace log of
nvidia-settings would be useful.
Please report to bugzilla.rpmfusion.org for now, but if it's
reproducible and not related to packaging, you will have to forward to
nvidia directly.

Thx

-- 
-

Nicolas (kwizart)
___
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: Interest in doing Fedora CI with test subpackages

[Neil Horman]

On Mon, Jul 08, 2019 at 02:17:44PM +0200, Vít Ondruch wrote:
> I am skeptical about this proposal. While this might work for your
> package, I am afraid it won't work generally and trying to do something
> like this is wasted energy. Let me explain.
> 
well, that may be fair, but when you way it "won't work generally", I could
paraphrase that to say "it may not be sufficient for all packages".  I would
make the argument that the implication is that, for some subset of packages,
this approach works quite well.  That is in fact, the case for all the packages
I maintain.

> When RubyGems were designed in 2004, TDD, BDD and testing in general was
> becoming good practice. Therefore they decided that it is good idea to
> ship code together with its test suite and also execute the tests during
> installation. So you were supposed to be able to run something like "gem
> install -t foo". But it proven to be problematic. Generally this "-t"
> option never worked and could be used just for the most naive test
> suites. So the option was removed [1]. Nowadays, more and more gem
> packages does not ship their tests suites and even the support for
> shipping the test suites is deprecated [2].
> 
Ok, that seems like a fair conclusion to draw from your experience, but it is by
no means the only experience.  I currently maintain:
cscope
irqbalance
rng-tools
dropwatch
rstp

and a few others, all of which have very mature test suites embedded into their
soruce code.  For these pacakages, being able to run their test code in the CI
environment would be very helpful to me (and I think, by extension), others who
have simmilarly constructed packages.
 
> If you want to understand how complex it might be to run the test suite
> of some packages, I welcome you to explore the %check sections of
> rubygem- packages. Some are simple, but most are not that simple,
> starting with small differences as load path, ending with test suites
> which needs to run various servers or check against cloud services. Not
> mentioning test matrices.
> 
I do run make check and part of an rpm %check script on most of these, and if
the consensus is that that approach is sufficient for CI purposes, so be it
(that would in fact be much easier for me).  But its my understanding that there
is a desire to move all our testing to a CI pipeline (or perhaps it would be
beter to say that we wish to add CI to all our packages), and running the
included self tests with an upstream source tree within the CI pipeline is
dificult at best (owing to the lack of source availability in the CI
environment), nor is running a %check script during a build an available trigger
to clear gating during CI, hence my desire to find a way to make my included
selftests from the source tree available in CI via -test rpm subpackages.

> Also, for all these tests we usually try to simulate the environment as
> similar as possible to upstream repository, because this is how these
> test suites are designed. It would be even harder to execute the test
> suites against installed packages.
> 
Unless you were able to extract the test suite into a separate package, install
it in the environment, and run it, while pointing to the installed binaries that
you are trying to test :)

Neil

> 
> Vít
> 
> 
> [1]
> https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c
> 
> [2] https://github.com/rubygems/rubygems/issues/735
> 
> 
> Dne 05. 07. 19 v 19:49 Neil Horman napsal(a):
> > Hey all-
> > I was starting to setup CI for one of my packages in Fedora (cscope),
> > which requires that I have access to the sources to run my test (cscope 
> > uses its
> > own source tree to search for various symbols to confirm that its working
> > properly).  Getting the sources in the CI environment is a bit of a pain, 
> > so I
> > started working on trying to do this by creating a test subpackage 
> > (specifically
> > named -citest) to package up the sources solely for the purpose of getting 
> > them
> > installed and available during CI runs.  It occured to me that this offers
> > several advantages, among them:
> > 1) the ability to codify dependencies within the ame spec file, rather than
> > having to copy them to the test.yml file, and keep them in sync
> >
> > 2) The ability to use a file format (rpm spec files) that I'm more familiar 
> > with
> >
> > 3) Easy access to tests that are embedded in the source tree
> >
> > 4) minimizing the test harness setup in test.yml
> >
> > For anyone interested, I've got a pull request started here:
> > https://src.fedoraproject.org/rpms/cscope/pull-request/2
> >
> > If anyone wants to take a look at the changes I had to make to do this (fair
> > warning, its still very rough).
> >
> > That all said, I was wondering if perhaps there was general interest in 
> > making
> > this kind of test model somewhat more formal (i.e. creating an rpm macro 
> > library
> > to make test package generation a bit easier, creating a standard entry 

[Bug 1716159] perl-TeX-Encode-2.006 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-TeX-Encode-2.006-1.fc3
   ||1
 Resolution|--- |RAWHIDE
   Assignee|tcall...@redhat.com |jples...@redhat.com
Last Closed||2019-07-08 14:14:41



-- 
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: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

[Daniel Walsh]

On 7/4/19 5:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 03, 2019 at 04:23:24PM -0400, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/CGroupsV2
>>
>> == Summary ==
>> The kernel has had some support for CgroupsV2 for some time, and yet
>> no one has used it because it is not on by default.  There are lots of
>> new features and fixes over CgroupsV1 that it is time to reveal to the
>> user community.
>>
>> == Owner ==
>> * Name: [[User:dwalsh| Daniel J Walsh]]
>> * Email: 
>>
>>
>> == Detailed Description ==
>> Enablement of the CgroupsV2 by default will allow tools like systemd,
>> container tools and libvirt to take advantage of the new features and
>> many fixes in Cgroups V1.  A lot of the functionality in VGroups V1
>> has been rewritten to fix fundamental flaws in its design.
>>
>> The reason CGroupsV2 by default has been blocked is that the Container
>> tools and someone the Virtualization tools did not have support.  We
>> believe that the time is right to try to move these tools along to
>> take advantage of this kernel feature. In order to begin testing these
>> features more widely we believe we need to have a platform like
>> Rawhide to test on and get others to test as well.
>>
>> The main features of CgroupsV2 we would like to take advantage of in
>> the container world is delegation of cgroup hierarchies.   Allowing
>> tools like podman to be able to use CGroups in rootless mode, would be
>> a large advance.
>>
>>
>> == Benefit to Fedora ==
>> Fedora is known for being a leading platform for the enablement of new
>> kernel functions, and this would continue its legacy.  The world will
>> eventually move to CGroupsV2 and Fedora should lead the way.
>>
>> == Scope ==
>> * Proposal owners:
>> The largest changes required to make this Change is to get containers
>> runtimes like RUNC to work with the change.  After RUNC has support
>> for CgroupsV2 we need to move container engines like Podman, CRI-o,
>> Buildah and Moby into support CgroupsV2.
>>
>> * Other developers:
>> We need to find other tools that have built the CGroupsV1 API into
>> themselves and get them to support CGroupsV2.
>>
>> Known packages:
>>
>> - libvirt: The team is already working on this.
>>
>> -  JVM:  Uses Cgroups file system to check for allocated memory for
>> the JVM, will have to use and understand the CgroupV2 mechanism to
>> discover these sessings.
>>
>> - Snap package does not run with CGroupV2:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438079
>>
>> - Systemd will need to be modified to set the new default to cgroupv2
>>
>> * Release engineering: [https://pagure.io/releng/issue/8509 #8509]
>> * Policies and guidelines:
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> Any tools or scripts that an administrator used to manually configure
>> the CGroupsV1 will have to be modified to CGroupsV2.  Luckily if these
>> tools took advantage of systemd interfaces they should not require
>> changes.
>>
>> == How To Test ==
>> Make sure different tools that use cgroups continue to work when
>> booted into the new system.  Make sure containers, virtual machines
>> and the Jave Virtual Machine still work properly.  Convert the VM's of
>> the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
>> make sure their test suites completely pass.  Will request that the
>> libvirt team and JVM teams similarly change their test platforms.
> Actually it's enough to set 'systemd.unified-cgroup-hierarchy' on the
> kernel command line to test. I think this should be mentioned, so
> people can test already in F29 or F30 or rawhide before the default is
> changed.
>
>> == User Experience ==
>> We believe that at this point their will be no or very little user
>> experience change, unless he is an administrator looking to modify the
>> system Cgroups using the cgroupsfs.
>>
>> One potential problem will be container images that expect to be
>> running in a CgroupV1 environment.  Some container engines leak the
>> Cgroup Hierarchy into containers so that tools within the container
>> can look at how much memory the cgroup gives them for example.  These
>> tools might break with the change, but they should be adjusted quickly
>> over time, and I don't really see a way to avoid this.
>>
>> == Dependencies ==
>> Currently there are no known changes to the package requirements for
>> this change.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: If the container tools and virtualization
>> tools do not work at beta and do not look like they will be ready for
>> beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
>> * Contingency deadline: Beta Freeze
>> * Blocks release? Yes
> We know that cgroupv2 already (and for a long time...) works better
> than v1, so I'd rather make the switch unconditional, using the usual
> phrasing of "In the unlikely case catastrophic problems are discovered
> with v2, the default will be reverted 

Nvidia GPU overclocking in Fedora Silverblue 30 is currently broken

[Ty Young]

Hi,


To whoever is packaging the Nvidia GPU driver in Fedora / RPM Fusion, 
overclocking support is currently broken. Not even nvidia-settings is 
able to set a GPU core offset value via GUI despite a correct coolbits 
value being set. This use to work some updates ago. Wayland is not being 
used.



Command used to install the driver and related utils:


rpm-ostree install kmod-nvidia xorg-x11-drv-nvidia 
xorg-x11-drv-nvidia-libs nvidia-settings nvidia-xconfig 
xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs



Attempting to set an overclocking value via command line just results in 
an "unknown error" message. nvidia-settings doesn't even know what's 
going on in Fedora Silverblue 30.



Can this please be looked into & fixed?
___
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: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

[Florian Weimer]

* Pavel Valena:

> - Original Message -
>> From: "Florian Weimer" 
>> To: "Pavel Valena" 
>> Cc: devel@lists.fedoraproject.org
>> Sent: Tuesday, May 14, 2019 10:47:41 AM
>> Subject: Re: rpmlint: library-not-linked-against-libc (parts of Python 
>> stdlib, after gcc 9)
>> 
>> * Pavel Valena:
>> 
>> > The same occurs with Ruby:
>> > https://src.fedoraproject.org/rpms/ruby/pull-request/44
>> 
>> I'm not sure if this is a false positive.  I checked fcntl.so, and it
>> references __cxa_finalize, as a weak symbol, so it needs to be linked
>> against libc.so.6, for ABI stability.
>> 
>> Can you figure out the linker command line?  It could be a binutils bug
>> in the implementation of --as-needed.
>
> From Ruby build(rawhide):
> https://da.gd/jBhE6
> https://copr.fedorainfracloud.org/coprs/pvalena/ruby/build/887856/
>
> ```
>* LDFLAGS: -L. -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \
>   -fstack-protector-strong -rdynamic \
>   -Wl,-export-dynamic
>* DLDFLAGS:-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> ```
>
> The full command is:
> ```
> gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. 
> -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -fstack-protector-strong 
> -rdynamic -Wl,-export-dynamic -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -m64  -lruby  -lm   -lc
> ```
> 
>
>
> Wich is different from F29(same SRPM; result linked correctly):
> ```
>* LDFLAGS: -L. -Wl,-z,relro   -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld \
>   -fstack-protector-strong -rdynamic \
>   -Wl,-export-dynamic
>* DLDFLAGS:-Wl,-z,relro   -Wl,-z,now \
>   -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> ```
> ```
> gcc -shared -o ../../.ext/x86_64-linux/fcntl.so fcntl.o -L. -L../.. -L. 
> -Wl,-z,relro   -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-z,relro   
> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -m64  -lruby  -lm   
> -lc
> ```

Yes, it's due to the --as-needed change.  Problems like this one are
expected.  The ELF tooling certainly needs to be updated for this change.

Thanks,
Florian
___
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: rpmlint: shared-lib-without-dependency-information (parts of Python stdlib)

[Florian Weimer]

* Miro Hrončok:

> On 05. 02. 19 19:04, Miro Hrončok wrote:
>> I've just spotted these when working on Python 3.8.0a1. This happens
>> on 3.7 as well since GCC 9:
>>
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
>> python3-debug.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
>>  
>>
>> python3-libs.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
>> python3-test.x86_64: E: library-not-linked-against-libc
>> /usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
>>  
>>
>>
>> (Note that there are plenty of other extension modules that do not
>> raise this error.)
>>
>> This doesn't happen with latest python3 built prior to the gcc update to 9.
>>
>> $ rpmlint -I library-not-linked-against-libc
>> library-not-linked-against-libc:
>>
>> That isn't helpful either.
>>
>> I found a similar Debian thing [1] that says:
>>
>>  > It is theoretically possible to have a library which doesn't use any 
>> symbols
>>  > from libc...
>>
>> Do I care? Should I fix something? I honestly have no idea.
>>
>> [1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
>
>
> We have new errors on F30+:
>
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_contextvars.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testimportmultiple.cpython-38-x86_64-linux-gnu.so
> python38.x86_64: E: shared-lib-without-dependency-information
> /usr/lib64/python3.8/lib-dynload/_testinternalcapi.cpython-38-x86_64-linux-gnu.so
>
> rpmlint doesn't give much info:
> $ rpmlint -I shared-lib-without-dependency-information
> shared-lib-without-dependency-information:
>
>
> But lintian again explains the issue:
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.html
>
> The listed shared library doesn't include information about which
> other libraries the library was linked against. (When running "ldd
> foo.so" ldd should report about these other libraries. In your case,
> ldd just reports "statically linked".)
>
> I again think this is OK for Python extension modules.
> Thoughts?

It depends on the extension module.  For _contextvars, it's okay because
it does not link against anything (glibc or otherwise).  Global C++
destructors will not work because of unfulfilled weak reference to
__cxa_finalize, but you probably do not care about that.

rpmlint really should have a list of symbols from system libraries that
need linking, otherwise there's always going to be false positives for
such plugins.  (Although extension modules could link against libpython
on Fedora because Fedora doesn't use the fat Python interpreter, unlike
some other distributions.)

Thanks,
Florian
___
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 1727899] New: perl-Scope-Upper-0.32 is available

[bugzilla]

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

Bug ID: 1727899
   Summary: perl-Scope-Upper-0.32 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Scope-Upper
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.32
Current version/release in rawhide: 0.31-3.fc31
URL: http://search.cpan.org/dist/Scope-Upper/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/5999/

-- 
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: Character limit for spec file summary?

[Brian (bex) Exelbierd]

I created a PR https://pagure.io/packaging-committee/pull-request/912
to try and make these things clearer when the text is read.  Feedback
desired and welcome.

regards,

bex

On Mon, Jul 8, 2019 at 2:15 PM Petr Pisar  wrote:
>
> On 2019-07-06, Richard Shaw  wrote:
> > Is there an actual limit or guideline on the character length of the
> > summary tag?
> >
> > I can't seem to find anything one way or the other.
> >
> rpmlint reports an error on a summary longer than 80 characters.
>
> -- Petr
> ___
> 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



-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.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

[Bug 1726163] fusioninventory-agent-2.5.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2019-9faea39bf7 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9faea39bf7

-- 
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: Interest in doing Fedora CI with test subpackages

[Vít Ondruch]

I am skeptical about this proposal. While this might work for your
package, I am afraid it won't work generally and trying to do something
like this is wasted energy. Let me explain.

When RubyGems were designed in 2004, TDD, BDD and testing in general was
becoming good practice. Therefore they decided that it is good idea to
ship code together with its test suite and also execute the tests during
installation. So you were supposed to be able to run something like "gem
install -t foo". But it proven to be problematic. Generally this "-t"
option never worked and could be used just for the most naive test
suites. So the option was removed [1]. Nowadays, more and more gem
packages does not ship their tests suites and even the support for
shipping the test suites is deprecated [2].

If you want to understand how complex it might be to run the test suite
of some packages, I welcome you to explore the %check sections of
rubygem- packages. Some are simple, but most are not that simple,
starting with small differences as load path, ending with test suites
which needs to run various servers or check against cloud services. Not
mentioning test matrices.

Also, for all these tests we usually try to simulate the environment as
similar as possible to upstream repository, because this is how these
test suites are designed. It would be even harder to execute the test
suites against installed packages.


Vít


[1]
https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c

[2] https://github.com/rubygems/rubygems/issues/735


Dne 05. 07. 19 v 19:49 Neil Horman napsal(a):
> Hey all-
>   I was starting to setup CI for one of my packages in Fedora (cscope),
> which requires that I have access to the sources to run my test (cscope uses 
> its
> own source tree to search for various symbols to confirm that its working
> properly).  Getting the sources in the CI environment is a bit of a pain, so I
> started working on trying to do this by creating a test subpackage 
> (specifically
> named -citest) to package up the sources solely for the purpose of getting 
> them
> installed and available during CI runs.  It occured to me that this offers
> several advantages, among them:
> 1) the ability to codify dependencies within the ame spec file, rather than
> having to copy them to the test.yml file, and keep them in sync
>
> 2) The ability to use a file format (rpm spec files) that I'm more familiar 
> with
>
> 3) Easy access to tests that are embedded in the source tree
>
> 4) minimizing the test harness setup in test.yml
>
> For anyone interested, I've got a pull request started here:
> https://src.fedoraproject.org/rpms/cscope/pull-request/2
>
> If anyone wants to take a look at the changes I had to make to do this (fair
> warning, its still very rough).
>
> That all said, I was wondering if perhaps there was general interest in making
> this kind of test model somewhat more formal (i.e. creating an rpm macro 
> library
> to make test package generation a bit easier, creating a standard entry point 
> to
> run tests, etc).  
>
> Thoughts welcome
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Character limit for spec file summary?

[Petr Pisar]

On 2019-07-06, Richard Shaw  wrote:
> Is there an actual limit or guideline on the character length of the
> summary tag?
>
> I can't seem to find anything one way or the other.
>
rpmlint reports an error on a summary longer than 80 characters.

-- Petr
___
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 1727848] New: perl-Mojolicious-8.19 is available

[bugzilla]

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

Bug ID: 1727848
   Summary: perl-Mojolicious-8.19 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mojolicious
  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,
robinlee.s...@gmail.com, yan...@declera.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 8.19
Current version/release in rawhide: 8.18-1.fc31
URL: https://metacpan.org/release/Mojolicious

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/5966/

-- 
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 1727732] perl-MCE-1.841 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-MCE-1.841-1.fc31
 Resolution|--- |RAWHIDE
Last Closed||2019-07-08 10:07:21



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

-- 
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: MPFR 4

[James Paul Turner]

On Sat, 2019-07-06 at 17:58 -0600, Jerry James wrote:
> On Sat, Jul 6, 2019 at 1:55 PM Jakub Jelinek 
> wrote:
> > There is no way around having some compatibility version, either in
> > the same
> > or other rpm, at least for a short period of time, because gcc
> > needs libmpfr
> > and libmpfr needs to be built with gcc, so if you upgrade
> > incompatibly
> > libmpfr, you will build that package, but once it is in the
> > buildroots, gcc
> > will not install anymore and so nothing that needs gcc to build
> > will
> > succeed building.
> 
> Right.  I think James's question was about submitting a package for
> review that is a different version of a package owned by somebody
> else.  The maintainer of record for mpfr is Pavel Cahyna.  I see he
> has an mpfr COPR:
> 
> https://copr.fedorainfracloud.org/coprs/pcahyna/mpfr4/
> 
> but it looks like it hasn't been touched in a long time.  This is
> what
> fedora-active-user has to say about him:
> 
> Last login in FAS:
>pcahyna 2019-05-16
> Last action on koji:
>Fri, 11 Aug 2017 package list entry revoked: zisofs-tools in f25
> by pkgdb
> Last package update on bodhi:
>2018-02-25 21:51:52 on package mpfr-3.1.6-1.fc27
> Last actions performed according to fedmsg:
>   - joerg.schill...@fokus.fraunhofer.de updated nothing on
> RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on
> 2019-07-04 08:29:55 ()
>   - ekan...@rcn.com updated nothing on RHBZ#1648742 'wodim should not
> pretend to handle DL-DV...' on 2019-07-04 08:06:42 ()
>   - r...@htt-consult.com updated nothing on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-27 10:22:24 ()
>   - joerg.schill...@fokus.fraunhofer.de updated nothing on
> RHBZ#1648742 'wodim should not pretend to handle DL-DV...' on
> 2019-06-26 06:21:01 ()
>   - ekan...@rcn.com updated 'cc' on RHBZ#1648742 'wodim should not
> pretend to handle DL-DV...' on 2019-06-26 06:02:22 ()
>   - pdu...@gmx.com updated 'cc' on RHBZ#1457252 'gnuplot-5.2.7 is
> available' on 2019-06-09 12:07:09 ()
>   - ke...@tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-05 14:27:05 ()
>   - ke...@tigcc.ticalc.org updated 'cc' on RHBZ#1583845 'Cannot write
> to CDrom at all' on 2019-06-05 14:19:32 ()
>   - ke...@tigcc.ticalc.org updated 'cc', 'dup_id', and 'resolution'
> on
> RHBZ#1580021 'wodim missing u+s will prevent usage at ...' on
> 2019-06-05 14:19:32 ()
>   - upstream-release-monitoring updated 'short_desc' on RHBZ#1457252
> 'gnuplot-5.2.7 is available' on 2019-05-29 01:05:26 ()
> Last email on mailing list:
> ERROR:active-user:[Errno socket error] [Errno -2] Name or service not
> known
> 
> Hmmm, what happened with the email on mailing list check?
> 
> The current mpfr library (3.1.6) has soname "libmpfr.so.4".  The new
> mpfr library (4.0.2) has soname "libmpfr.so.6".  We want to keep both
> sonames available until all consumers can be switched to mpfr4, which
> may take awhile.
> 
> We are not changing versions of libmpc, so the soname of
> "libmpc.so.3"
> is fixed.  Therefore, we have to have the following packages, and
> their -devel subpackages, and it has to be possible to have them all
> installed in the same buildroot:
> - mpfr 3.1.6
> - mpfr 4.0.2
> - libmpc 1.1.0 linked with mpfr 3.1.6
> - libmpc 1.1.0 linked with mpfr 4.0.2
> 
> I think it would be nice to have the "mpfr" package mean the latest
> version (i.e., 4.0.2), and introduce an mpfr3 package to hold 3.1.6.
> Likewise, it would be nice to have the "libmpc" package mean the
> version linked with mpfr 4.0.2, and introduce something, say
> "libmpc-mpfr3", to hold the version linked with mpfr 3.1.6.  I can be
> swayed otherwise, but that would let us preserve package history, and
> we can hopefully drop the mpfr3 and libmpc-mpfr3 packages from the
> distribution someday.
> 
> The tricky part, of course, is not breaking gcc while updating.  Here
> is one way that could be accomplished.  Caveat: I haven't actually
> tried doing this.  If this seems reasonable, I would like to create a
> COPR and start doing these builds to make sure nothing breaks.
> - Alter the mpfr package to produce mpfr3, mpfr3-devel, mpfr, and
> mpfr-devel
>   packages.  The mpfr3 library has the old soname, the mpfr library
> has the new
>   soname.  The -devel packages must be installable in parallel, so
> the mpfr3
>   packages have libmpfr3.so*, /usr/include/mpfr3.h, and
>   /usr/include/mpf2mpfr3.h.
> - Alter the libmpc package to produce libmpc and libmpc-mpfr3
> packages.  The
>   libmpc package keeps the current soname.  The libmpc-mpfr3 package
> gets the
>   soname “libmpc-mpfr3.so.3”.  Both are linked against mpfr3!  That’s
> important!
>   The -devel packages must be installable in parallel, so the libmpc-
> mpfr3
>   packages have libmpc-mpfr3.so* and /usr/include/mpc-mpfr3.h.
> - Build gcc with mpfr3 and libmpc-mpfr3.  This means that gcc no
> longer depends
>   on the mpfr and libmpc packages, so we can change them without
> breaking 

[Bug 1727480] perl-DBD-Pg-3.8.1 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-DBD-Pg-3.8.1-1.fc31



-- 
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 1727775] perl-Test-Compile-2.2.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Compile-2.2.0-1.f
   ||c31
 Resolution|--- |RAWHIDE
Last Closed||2019-07-08 09:04:52



-- 
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 1727480] perl-DBD-Pg-3.8.1 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2019-944097f498 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-944097f498

-- 
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: Review swaps

[Jakub Jelen]

On Sat, 2019-07-06 at 21:01 -0600, Jerry James wrote:
> I'm working on getting some optional dependencies of sagemath into
> Fedora.  All of these should be fairly simple reviews.  Let me know
> what I can review for you in exchange.
> 
> gap-pkg-happrime: https://bugzilla.redhat.com/show_bug.cgi?id=1723997
> coxeter: https://bugzilla.redhat.com/show_bug.cgi?id=1727498
> gap-pkg-forms: https://bugzilla.redhat.com/show_bug.cgi?id=1727499
> gap-pkg-hecke: https://bugzilla.redhat.com/show_bug.cgi?id=1727500
> gap-pkg-profiling: 
> https://bugzilla.redhat.com/show_bug.cgi?id=1727501
> mcqd: https://bugzilla.redhat.com/show_bug.cgi?id=1727502

I will take some of them. So far, I took the last one.

Can you do me a review of the following one:

pcsc-lite-acsccid: https://bugzilla.redhat.com/show_bug.cgi?id=1725840

Thank you,
-- 
Jakub Jelen
Senior Software Engineer
Security Technologies
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: New Go Packaging Guidelines landed in rawhide (koji) today

[Nicolas Mailhot via devel]

Le 2019-07-08 09:06, Jakub Cajka a écrit :

- Original Message -

From: "Nicolas Mailhot via devel" 
To: "Christophe de Dinechin" , "Development 
discussions related to Fedora"


Cc: "Robin Lee" , "nicolas mailhot" 


Sent: Saturday, July 6, 2019 8:39:12 AM
Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) 
today


Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
écrit :
>
> Also, would anybody mind if I add a note on the guideline page
> stating
> that this is from F31 on, since the go-rpm-macros package does not
> exist before. Unless there is a plan to create branches for earlier
> releases?

It could be done for previous releases, if someone was motivated
enough. The macro code itself works, with trivial adjustments, on
ancient releases like EL7. But, it depends on things in redhat-rpm-
config, so backporting would demand to convince redhat-rpm-config
maintainers to backport too.

Anyway this is pretty academic right now, I doubt anyone would accept 
a

backport without synchronized backport of the whole Go packageset, and
that can not happen before eclipso finishes to update the stack in
devel.



You have omitted that the new macros stack is not fully backwards
compatible, so it would require more work on fixing the packages that
are affected by the breakage(AFAIK a bit under ~100). IMHO it is not a
good idea to back-port this to any stable Fedora release.


That’s why I wrote that a macro backport, without the mass spec cleanup 
& fixing eclipseo is doing in devel right now, would not be a good idea. 
(fixing a clean spec to use the new macro stack takes a couple of 
minutes; fixing the warts that accumulated in Fedora for years because 
the tooling was not there is something else entirely)


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

libgweather soname bump

[Kalev Lember]

A quick heads up that I'm building libgweather 3.33.0 update for rawhide
that bumps the library soname with minor ABI changes.  I'll kick off
rebuilds for all dependent packages.

Kalev
___
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 1727775] New: perl-Test-Compile-2.2.0 is available

[bugzilla]

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

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



Latest upstream release: 2.2.0
Current version/release in rawhide: 2.1.2-1.fc31
URL: http://search.cpan.org/dist/Test-Compile/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/3388/

-- 
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 Go Packaging Guidelines landed in rawhide (koji) today

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot via devel" 
> To: "Christophe de Dinechin" , "Development discussions 
> related to Fedora"
> 
> Cc: "Robin Lee" , "nicolas mailhot" 
> 
> Sent: Saturday, July 6, 2019 8:39:12 AM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji) today
> 
> Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
> écrit :
> > 
> > Also, would anybody mind if I add a note on the guideline page
> > stating
> > that this is from F31 on, since the go-rpm-macros package does not
> > exist before. Unless there is a plan to create branches for earlier
> > releases?
> 
> It could be done for previous releases, if someone was motivated
> enough. The macro code itself works, with trivial adjustments, on
> ancient releases like EL7. But, it depends on things in redhat-rpm-
> config, so backporting would demand to convince redhat-rpm-config
> maintainers to backport too.
> 
> Anyway this is pretty academic right now, I doubt anyone would accept a
> backport without synchronized backport of the whole Go packageset, and
> that can not happen before eclipso finishes to update the stack in
> devel.
> 
> Regards,
> 
> --
> Nicolas Mailhot

You have omitted that the new macros stack is not fully backwards compatible, 
so it would require more work on fixing the packages that are affected by the 
breakage(AFAIK a bit under ~100). IMHO it is not a good idea to back-port this 
to any stable Fedora release.

JC

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