Re: Ditch RPM in favor of DPKG

[Anthony F McInerney]

On Sat, 18 Jul 2020 at 06:29, John M. Harris Jr 
wrote:

> On Friday, July 17, 2020 10:20:54 PM MST Anthony F McInerney wrote:
> > On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr 
> >
> > wrote:
> > > On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
> > > > there was no reason not to replac it with regular apt
> > >
> > > Nico touched on these already, but that's simply not possible. Rather,
> > > it's
> > > possible, but would immediately break your system upon installing
> software
> > > using apt.
> >
> > I  believe you and Nico haven't actually touched onto what's actually
> going
> > on.
> > https://bugzilla.redhat.com/show_bug.cgi?id=apt
> >
> >
> https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac
> > kend
>
> Well aware, but that doesn't solve the problem listed above:
> As soon as you try to install DPKG software with this, such as from
> Debian,
> you will break your system. The two CANNOT be installed to the same
> rootfs.
> It's just not going to work. There are too many conflicts.
>
>
this was about building packages..
https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend#User_Experience
___
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: Ditch RPM in favor of DPKG

[John M. Harris Jr]

On Friday, July 17, 2020 10:20:54 PM MST Anthony F McInerney wrote:
> On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr 
> 
> wrote:
> > On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
> > > there was no reason not to replac it with regular apt
> > 
> > Nico touched on these already, but that's simply not possible. Rather,
> > it's
> > possible, but would immediately break your system upon installing software
> > using apt.
> 
> I  believe you and Nico haven't actually touched onto what's actually going
> on.
> https://bugzilla.redhat.com/show_bug.cgi?id=apt
> 
> https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_bac
> kend

Well aware, but that doesn't solve the problem listed above:
As soon as you try to install DPKG software with this, such as from Debian, 
you will break your system. The two CANNOT be installed to the same rootfs. 
It's just not going to work. There are too many conflicts.

-- 
John M. Harris, Jr.

___
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: Ditch RPM in favor of DPKG

[Anthony F McInerney]

On Sat, 18 Jul 2020 at 04:19, John M. Harris Jr 
wrote:

> On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
> > there was no reason not to replac it with regular apt
>
> Nico touched on these already, but that's simply not possible. Rather,
> it's
> possible, but would immediately break your system upon installing software
> using apt.
>
>
I  believe you and Nico haven't actually touched onto what's actually going
on.
https://bugzilla.redhat.com/show_bug.cgi?id=apt

https://fedoraproject.org/wiki/Changes/Move_apt_package_from_RPM_to_DPKG_backend
___
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 2020-07-18 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/07/18/report-389-ds-base-1.4.4.4-20200717git654d0ff.fc32.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

Re: Orphaning a number of Lua-related packages

[John M. Harris Jr]

On Tuesday, July 14, 2020 1:05:33 PM MST Tim Niemueller wrote:
> Dear Fedora Community.
> 
> Things have changed and I can no longer perform all maintainer duties. I 
> have just orphaned several packages. I have given packages which had a 
> co-maintainer to them (Thank you! Many already acted as primary 
> maintainers for a while). If there is a package you care about or use 
> please consider taking over maintainership.
> 
> The packages are:
> https://src.fedoraproject.org/rpms/emacs-lua

If somebody could sponsor me to maintain emacs-lua, I'd like to ensure the 
package remains alive and kicking for years to come. I've gone through the 
review process with another package previously, and I can cite the bugzilla 
ticket, if it's a requirement that I demonstrate an understanding of that 
process.

-- 
John M. Harris, Jr.

___
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: Ditch RPM in favor of DPKG

[John M. Harris Jr]

On Thursday, July 16, 2020 3:11:19 AM MST Dridi Boukelmoune wrote:
> there was no reason not to replac it with regular apt

Nico touched on these already, but that's simply not possible. Rather, it's 
possible, but would immediately break your system upon installing software 
using apt.

-- 
John M. Harris, Jr.

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

Re: Btrfs in Silverblue

[John M. Harris Jr]

On Tuesday, July 14, 2020 12:39:01 AM MST Lennart Poettering wrote:
> > Why at boot time? Well if your default subvolume contains a recent
> > update that for some reason renders it unbootable, it might be nice to
> > be able to pick a prior snapshot. That's how they do this. It isn't
> > how we have to do it, but that's the example that we know works
> > because it's actually designed, planned, implemented and maintained.
> 
> 
> Nah, this kind of selection you do in the initrd, not in the boot loader.

That's done in the bootloader, not the initrd. If you'd like to see this 
behavior to day, you need only reboot and wait for GRUB2 to show up.

> That all said, it might make sense to define a new partition type uuid
> for "btrfs-all-in-one" file systems, because for that it might make
> sense to even allow multiple OS archs in the same btrfs file system,
> e.g. have a subvol /_root.fedora32.x86_64 for the x86_64 version of
> the OS, but /_root.fedora32.arm64 for the ARM version and then have a
> single fs that can be booted on either arch.

How would that make any sense? What's wrong with parsing fstab, as with 
literally every other system?

> > And that's a fine idea. But all of this directly involves a design and
> > plan for a snapshot and rollback regime. That's not happening for
> > Fedora 33. There's enough on our plate right now.
> 
> 
> All I am asking for is to make this simple and robust and forward
> looking enough so that we can later add something like the generator I
> proposed without having to rerrange anything. i.e. make the most basic
> stuff self-describing now, even if the automatic discovering/mounting
> of other subvols doesn't happen today, or even automatic snapshotting.

Using a "generator" for this is probably the least discoverable way to go 
about it, in this case. Again, fstab solves this problem. We don't need to 
replace our wheels with square ones.

-- 
John M. Harris, Jr.

___
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: F33 Change proposal: Replace Linux kernel with BSD kernel

[John M. Harris Jr]

On Thursday, July 16, 2020 2:37:55 PM MST Ben Cotton wrote:
> > F33 Change proposal: Replace Linux kernel with BSD kernel - System-Wide

Well, which BSD kernel? ;)


This email just serves as a neat example of that potential new format for 
Change proposals.

-- 
John M. Harris, Jr.

___
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[John M. Harris Jr]

On Friday, July 17, 2020 10:06:53 AM MST Benjamin Berg wrote:
> On Fri, 2020-07-17 at 09:12 -0700, John M. Harris Jr wrote:
> > On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote:
> > > So, we don't want to get the kernel into the situation where it must
> > > remove executables/libraries from main memory. If that happens, you can
> > > end up hitting the disk for *every* function call.
> > 
> > If this is true, then we shouldn't enable EarlyOOM, as it will kill
> > processes from in main memory.
> 
> I am not sure what you are saying, and I fear there is some sort of
> misunderstanding here or at least a different way of thinking about the
> problem.

As described below, this Change is enabling a daemon that purposefully kills 
users processes. That's not a good thing.

> What we achieve by killing a process is that we give the kernel more
> flexibility in how it manages the available memory. It really doesn't
> matter what you kill, all that matters is that some memory is free'ed
> up again.

It does matter what you kill, because you're wiping out users' data and 
stopping software the user intended to have run. The kernel is already more 
than capable of freeing memory for itself, that's not what this Change is for 
either. This Change is to abuse the OOM killer to run in non-OOM scenarios 
using a userspace daemon.

-- 
John M. Harris, Jr.

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

[EPEL-devel] Re: clusterssh for EPEL 8

[Chris Schanzle]

Certainly!  Done.  Thanks for the polite pointer.

On 7/17/20 9:01 AM, Patrick Riehecky wrote:
> Can you open a bugzilla requesting this be added to EPEL8?
>
> Pat
>
> On Thu, 2020-07-16 at 22:01 -0400, Chris Schanzle wrote:
>> Hi,
>>
>> Clusterssh is a nice tool to send input to multiple ssh sessions
>> simultaneously -- handy for managing a cluster of systems.  I don't
>> know if there is much other interest for clusterssh, but I wanted to
>> share my experience on building it and it seems like it would be
>> fairly low effort to add these to EPEL 8.
>>
>> Using mock, I was able to rebuild to my local repo:
>>
>> clusterssh-4.14-2.fc32.src.rpm
>>
>> after building two dependencies:
>>
>> perl-X11-Protocol-0.56-33.fc32.src.rpm
>> perl-X11-Protocol-Other-31-3.fc32.src.rpm
>>
>> No changes to src.rpm's were needed to build the packages.
>>
>> Thanks for your amazing work!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: How do Fedora developers get access to devtoolset for testing.

[Orion Poplawski]

On 7/17/20 3:03 PM, Steven Munroe wrote:
So my project (pveclib) was requested for el7/8 which means building 
with devtoolset-9.


With a spec file enabled for el7, the local rpmbuild's fail if you don't 
have devtoolset installed. The error message was less than helpful.


So if you can use fedpkg scratch-build devtoolset is preinstalled.

But if you have bugs in your spec file (and as a newbie, I often do) 
then you also get failures with less than helpful status.


FAILED: BuildError: error building package (arch ppc64le), mock exited with 
status 1; see build.log or root.log for more information

In my case I had to remove all the el7 bits from my spec file and test 
with rpmbuild to find the problem.


So having devtoolset installed locally would be helpful.

Thanks in advance


Do builds in mock, e.g.:

fedpkg --release epel7 mockbuild --no-cleanup-after


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

[Test-Announce] 2020-07-20 @ 16:00 UTC - Fedora 33 Blocker Review Meeting

[Adam Williamson]

# F33 Blocker Review meeting
# Date: 2020-07-20
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hi folks! We have 5 proposed Beta blockers, 1 proposed Beta freeze
exception and 2 proposed Final blockers to review, so let's have a
Fedora 33 blocker review meeting on Monday!

If you have time this weekend, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

We'll be evaluating these bugs to see if they violate any of the 
Release Criteria and warrant the blocking of a release if they're not 
fixed. Information on the release criteria for F33 can be found on the 
wiki [0].

For more information about the Blocker and Freeze exception process, 
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting 
works - or how it's supposed to go and you want to run one - check out 
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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

[Test-Announce] 2020-07-20 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2020-07-20
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We didn't meet for a couple of weeks and some Big Changes (tm) are
landing in Fedora 33 right now, so let's get together and check in on
where we're at and what we have planned.

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 33 status and Changes
3. Test Day / community event status
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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 1857787] perl-LWP-Protocol-https-6.09 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-13c6cbc484   
python-gnupg-0.4.6-1.el8
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2f1d845c76   
python-rsa-3.4.2-15.el8
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-9239b6fa50   
botan2-2.12.1-2.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ff58160b15   
libslirp-4.3.1-1.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-672e6676c7   
seamonkey-2.53.3-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-12d0e14fab   
cacti-1.2.13-1.el8 cacti-spine-1.2.13-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-1c906e59bb   
mbedtls-2.16.7-1.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-442e619b4a   
singularity-3.6.0-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-31b5963358   
tor-0.4.3.6-1.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a0f28fffcf   
bashtop-0.9.24-1.el8


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

clamav-0.102.4-1.el8
hxtools-20150304-10.el8
libHX-3.22-12.el8
pam_mount-2.16-10.el8
python-pytest-arraydiff-0.3-6.el8
python-pytest-astropy-0.5.0-4.el8
python-pytest-doctestplus-0.5.0-1.el8
python-pytest-openfiles-0.4.0-1.el8
python-pytest-remotedata-0.3.2-1.el8

Details about builds:



 clamav-0.102.4-1.el8 (FEDORA-EPEL-2020-cf34e230c7)
 End-user tools for the Clam Antivirus scanner

Update Information:

ClamAV 0.102.4 is a bug patch release to address the following issues:
CVE-2020-3350 
Fixed a vulnerability a malicious user could exploit to replace a scan target's
directory with a symlink to another path to trick clamscan, clamdscan, or
clamonacc into removing or moving a different file (such as a critical system
file). The issue would affect users that use the --move or --remove options for
clamscan, clamdscan and clamonacc.  For more information about AV quarantine
attacks using links, see RACK911 Lab's report
.  CVE-2020-3327  Fixed a vulnerability in the ARJ archive-
parsing module in ClamAV 0.102.3 that could cause a denial-of-service (DoS)
condition. Improper bounds checking resulted in an out-of-bounds read that could
cause a crash. The previous fix for this CVE in version 0.102.3 was incomplete.
This fix correctly resolves the issue.  CVE-2020-3481
 Fixed a
vulnerability in the EGG archive module in ClamAV 0.102.0 - 0.102.3 that could
cause a denial-of-service (DoS) condition. Improper error handling could cause a
crash due to a NULL pointer dereference. This vulnerability is mitigated for
those using the official ClamAV signature databases because the file type
signatures in daily.cvd will not enable the EGG archive parser in affected
versions.

ChangeLog:

* Fri Jul 17 2020 Orion Poplawski  - 0.102.4-1
- Update to 0.102.4 (bz#1857867,1858262,1858263,1858265,1858266)
- Security fixes CVE-2020-3327 CVE-2020-3350 CVE-2020-3481
* Thu May 28 2020 Orion Poplawski  - 0.102.3-2
- Update clamd README file (bz#1798369)

References:

  [ 1 ] Bug #1858261 - CVE-2020-3350 clamav: malicious user exploit to replace 
scan target's directory with symlink
https://bugzilla.redhat.com/show_bug.cgi?id=1858261
  [ 2 ] Bug #1858264 - CVE-2020-3481 clamav: improper error handling causing 
crash due to NULL pointer dereference
https://bugzilla.redhat.com/show_bug.cgi?id=1858264




 hxtools-20150304-10.el8 (FEDORA-EPEL-2020-3a77a398c3)
 A collection of several tools

Update Information:

Add pam_mount and its dependencies hxtools and libHX to EPEL 8

ChangeLog:


References:

  [ 1 ] Bug #1831692 - Please build pam_mount for epel 8
https://bugzilla.redhat.com/show_bug.cgi?id=1831692




 

Re: Koji oops

[Kevin Fenzi]

On Fri, Jul 17, 2020 at 02:25:32PM +0200, Dan Horák wrote:
> On Fri, 17 Jul 2020 15:15:00 +0300
> Евгений Пивнев  wrote:
> 
> > What’s wrong with koji?
> > Yet another maintenance jobs that I missed?
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=47345974
> > 
> 
> this is a packaging bug, from build.log:
> cp: cannot stat 'ImageLounge/Readme/README': No such file or directory
> 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=47346270
> > 
> 
> yes, this one looks as an unplanned outage

Yeah. Our two main proxies decided to hit OOM and kill varnish and/or
haproxy, which made things anoying. ;( 

I have doubled their memory for now and we are watching them. 

Sorry for the outage. ;( 

kevin


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

Re: Removing packages from module

[Aleksei Bavshin]

On 7/17/20 1:50 PM, Daniel Mach wrote:
> 
> 
> Dne 17. 07. 20 v 14:15 Aleksei Bavshin napsal(a):
>> On 7/17/20 3:27 AM, Daniel Mach wrote:
>>> Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):
 If the package was part of the module during the release of Fedora 32,
 dnf will see 2 versions/builds of the module-stream:

    - the one that existed during the release (containing the package)
    - the one from updates (no longer containing the package)

 The "original" version will still filter out the non-modular version
 of the package from any transaction.

 And given the way modular filtering works, a package cannot
 technically be "demodularized" this was during one release, unless you
 force a module reset from another package's scriptlet.
>>
>> Thanks for clarifying this, Miro. So the filter is built based on the
>> module metadata instead of the installed packages. I guess I
>> misunderstood that part.
>>
>> That's just sad. I woke up with the bright idea about removing the
>> packages from modulemd and then adding `sway-module-obsoletes` which
>> Obsoletes everything in the module that's behind f32-updates. We have
>> several packages like this since the last module rebuild.
>>
>> If there's a cached non-updateable module metadata from fedora-modular
>> which is always considered by dnf together with the updated version from
>> fedora-updates-modular, that had no chance of working.
> That's exactly how it works.
> Unlike RPMs where usually the latest version is the result of a
> transaction, module metadata are additive.
> Sum of all versions make a stream and it's content (incl. the old RPM
> versions) so you can eventually downgrade your package if you need to.
> We know about the issue and we want to introduce some de-modularization
> feature, but we need to fix more serious issues first.
> 
>>
 During the update to Fedora 33 a modular reset should happen anyway.
 But even if it doesn't I believe that the packages would be upgraded
 to non-modular, assuming their EVR is higher. I might be wrong thou,
 because the concept of removing packages from modules and making them
 non-modular is full of booby traps.
>>>
>>> The module reset is essential, because otherwise DNF will keep using
>>> fail-safe module data on disk and that would still keep the package
>>> filtered.
>>>
>>> I suggest making the change in F33 / Rawhide.
>>> Rawhide shouldn't break, because there's only one (the latest) version
>>> of each module in the repodata and if you release a new modulemd without
>>> the package, everything should work as expected.
>> Your suggestion implies that there's a way to build different set of
>> packages for different releases within the same module stream, right?
>>
>> Because with what Miro said, we are stuck with the requirement to update
>> every package we have in the module until f32 is EOL. I can't just drop
>> package x from modulemd and say "x won't be ever updated in f32 because
>> modularity" :(
>>
> The F33 change I suggested doesn't retrospectively apply on F32.
> You're really stuck maintaining the package until F32 EOL.

Yes, that's something I already accepted.
The real question is how to do the change in f33 considering that f32
and f33 modules must be built from the same modulemd file. I only see
the ability to disable module stream build for f33.

And now I'm curious what would happen if I specify `platform: [-f33]`
and publish new module build. Would that remove previously published
metadata from rawhide?
I guess the right answer is somewhere around servicelevels and `eol`
specification.

-- 
With best regards,
Aleksei Bavshin
___
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

How do Fedora developers get access to devtoolset for testing.

[Steven Munroe]

So my project (pveclib) was requested for el7/8 which means building with
devtoolset-9.

With a spec file enabled for el7, the local rpmbuild's fail if you don't
have devtoolset installed. The error message was less than helpful.

So if you can use fedpkg scratch-build devtoolset is preinstalled.

But if you have bugs in your spec file (and as a newbie, I often do) then
you also get failures with less than helpful status.

FAILED: BuildError: error building package (arch ppc64le), mock exited
with status 1; see build.log or root.log for more information

In my case I had to remove all the el7 bits from my spec file and test with
rpmbuild to find the problem.

So having devtoolset installed locally would be helpful.

Thanks in advance
___
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: Removing packages from module

[Daniel Mach]

Dne 17. 07. 20 v 14:15 Aleksei Bavshin napsal(a):

On 7/17/20 3:27 AM, Daniel Mach wrote:

Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):

If the package was part of the module during the release of Fedora 32,
dnf will see 2 versions/builds of the module-stream:

   - the one that existed during the release (containing the package)
   - the one from updates (no longer containing the package)

The "original" version will still filter out the non-modular version
of the package from any transaction.

And given the way modular filtering works, a package cannot
technically be "demodularized" this was during one release, unless you
force a module reset from another package's scriptlet.


Thanks for clarifying this, Miro. So the filter is built based on the
module metadata instead of the installed packages. I guess I
misunderstood that part.

That's just sad. I woke up with the bright idea about removing the
packages from modulemd and then adding `sway-module-obsoletes` which
Obsoletes everything in the module that's behind f32-updates. We have
several packages like this since the last module rebuild.

If there's a cached non-updateable module metadata from fedora-modular
which is always considered by dnf together with the updated version from
fedora-updates-modular, that had no chance of working.

That's exactly how it works.
Unlike RPMs where usually the latest version is the result of a 
transaction, module metadata are additive.
Sum of all versions make a stream and it's content (incl. the old RPM 
versions) so you can eventually downgrade your package if you need to.
We know about the issue and we want to introduce some de-modularization 
feature, but we need to fix more serious issues first.





During the update to Fedora 33 a modular reset should happen anyway.
But even if it doesn't I believe that the packages would be upgraded
to non-modular, assuming their EVR is higher. I might be wrong thou,
because the concept of removing packages from modules and making them
non-modular is full of booby traps.


The module reset is essential, because otherwise DNF will keep using
fail-safe module data on disk and that would still keep the package
filtered.

I suggest making the change in F33 / Rawhide.
Rawhide shouldn't break, because there's only one (the latest) version
of each module in the repodata and if you release a new modulemd without
the package, everything should work as expected.

Your suggestion implies that there's a way to build different set of
packages for different releases within the same module stream, right?

Because with what Miro said, we are stuck with the requirement to update
every package we have in the module until f32 is EOL. I can't just drop
package x from modulemd and say "x won't be ever updated in f32 because
modularity" :(


The F33 change I suggested doesn't retrospectively apply on F32.
You're really stuck maintaining the package until F32 EOL.
___
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 1858361] perl-App-Cme-1.032 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-App-Cme-1.032-1.fc33
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-07-17 20:35:21




-- 
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 1857787] perl-LWP-Protocol-https-6.09 is available

[bugzilla]

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



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


-- 
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Alexey A.]

> And this will turn bad quickly, as it will eventually
> include the executables/libraries that must be loaded as they are doing
> work!

> So, we don't want to get the kernel into the situation where it must
> remove executables/libraries from main memory. If that happens, you can
> end up hitting the disk for *every* function call.

BTW, with prelockd[1] executables/libraries will not be removed from
memory. This daemon can mlock executables/libraries in memory.

Effects:
- OOM killer comes faster.
- Fast system reclaiming after OOM.

This daemon was written recently, published today.

1. https://github.com/hakavlad/prelockd

вт, 14 июл. 2020 г. в 17:19, Benjamin Berg :

> On Mon, 2020-07-13 at 19:25 -0600, Chris Murphy wrote:
> > On Mon, Jul 13, 2020 at 12:00 PM Benjamin Berg  wrote:
> > > If MemAvailable drops below 250MiB (roughly 6GiB * 4%), then this means
> > > that we have less than 500MiB left for file caches. If we can't swap
> > > (remember, swap is already pretty full too), then a big chunk of these
> > > caches need to be dropped to make the memory available to applications.
> >
> > I regularly see impressively low MemAvailable before earlyoom does
> > SIGTERM, it's almost always swap available (amount of total that's not
> > used) that's the defining factor. Well below 100MiB. This doesn't tend
> > to last very long. Once memory is under this kind of pressure, so is
> > swap, and as swap on zram is so fast, it gets to threshold fast as
> > well.
>
> Yep, EarlyOOM doesn't apply the limit if there is swap available. That
> makes a lot of sense. When swap page is available, the kernel has the
> choice which memory to reclaim (anonymous pages, i.e. swap, or file
> backed pages, i.e. drop caches). So MemAvailable may drop much lower
> temporarily and depending on the workload.
>
> You could say that when swap is available you assume the kernel has the
> ability to keep the system running reasonably well. Once swap runs out,
> the kernel stops having a choice. It can only make room by reclaiming
> important caches. And this will turn bad quickly, as it will eventually
> include the executables/libraries that must be loaded as they are doing
> work!
>
> So, we don't want to get the kernel into the situation where it must
> remove executables/libraries from main memory. If that happens, you can
> end up hitting the disk for *every* function call.
>
> Benjamin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1858048] rt-5.0.0 is available

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Depends On|1858360 |1858381





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1858360
[Bug 1858360] Review Request: perl-HTTP-Headers-ActionPack -  HTTP Action,
Adventure and Excitement
https://bugzilla.redhat.com/show_bug.cgi?id=1858381
[Bug 1858381] Review Request: perl-Web-Machine - Perl port of Webmachine
-- 
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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Benjamin Berg]

On Fri, 2020-07-17 at 09:12 -0700, John M. Harris Jr wrote:
> On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote:
> > So, we don't want to get the kernel into the situation where it must
> > remove executables/libraries from main memory. If that happens, you can
> > end up hitting the disk for *every* function call.
> 
> If this is true, then we shouldn't enable EarlyOOM, as it will kill processes 
> from in main memory.

I am not sure what you are saying, and I fear there is some sort of
misunderstanding here or at least a different way of thinking about the
problem.

What we achieve by killing a process is that we give the kernel more
flexibility in how it manages the available memory. It really doesn't
matter what you kill, all that matters is that some memory is free'ed
up again.

Benjamin


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

[bugzilla]

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

Ralf Corsepius  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Depends On||1858360
   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Ralf Corsepius  ---
Working on it.

As usual with major rt upgrades, this will require further perl dists, reviews,
testing and thus is likely to take quite a larger amount of time.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1858360
[Bug 1858360] Review Request: perl-HTTP-Headers-ActionPack -  HTTP Action,
Adventure and Excitement
-- 
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 1858361] New: perl-App-Cme-1.032 is available

[bugzilla]

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

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



Latest upstream release: 1.032
Current version/release in rawhide: 1.031-2.fc32
URL: http://search.cpan.org/dist/App-Cme/

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


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


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


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


-- 
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: Self Introduction Ludovic Hirlimann

[Nasir Hussain]

Welcome here Ludovic :)

On Fri, Jul 17, 2020 at 7:14 PM Ludovic Hirlimann via devel <
devel@lists.fedoraproject.org> wrote:

> Hi,
>
>
> I'm ludo. I've been involved with opensource for a long time now (using
> my first linux in 1996). I have been a mozilla employee for 10 years (as
> the Thunderbird QA lead and then as an IT staffer). I'm back to linux
> since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my
> distribution of choice and been running it since version 21. I like
> opendata and have particpated in musicbrainz and still participate to
> openstreetmap. I've always like maps and thus I'd like to join de Fedora
> packaging community to maintain, or help maintain two packages that are
> Map related : josm and qgis.
>
> I don't have much experience in maintaining packages but I'm more than
> willing to learn.
>
> Have a nice day.
>
> Ludovic
>
> --
> https://www.hirlimann.net/Ludovic/carnet/
>
>
> ___
> 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: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[John M. Harris Jr]

On Tuesday, July 14, 2020 1:18:08 AM MST Benjamin Berg wrote:
> So, we don't want to get the kernel into the situation where it must
> remove executables/libraries from main memory. If that happens, you can
> end up hitting the disk for *every* function call.

If this is true, then we shouldn't enable EarlyOOM, as it will kill processes 
from in main memory.

-- 
John M. Harris, Jr.

___
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: Upcoming Fedora 33 Change proposal deadlines

[Jeremy Linton]

Hi,


On 7/17/20 9:07 AM, Ben Cotton wrote:

This is the final reminder of the Fedora 33 Change proposal deadlines:

  * 2020-07-21: Proposal deadline for Self-Contained Changes

The mass rebuild is scheduled to begin next week as well.

For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html




So, the PAC proposal should have this defect 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94891 integrated before its 
enabled.


That defect is in 10.2 and has been backported to 10.1/9, but I don't 
see it in the version currently in rawhide. Is there a plan to roll gcc 
forward before or as part of the mass rebuild?



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

Re: Self Introduction Ludovic Hirlimann

[Matthew Miller]

On Fri, Jul 17, 2020 at 04:14:19PM +0200, Ludovic Hirlimann via devel wrote:
> I'm ludo. I've been involved with opensource for a long time now (using
> my first linux in 1996). I have been a mozilla employee for 10 years (as
> the Thunderbird QA lead and then as an IT staffer). I'm back to linux
> since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my

Hi Ludo! Welcome!


-- 
Matthew Miller

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

fedbot spamming in #fedora

[Germano Massullo]

Is it necessary to have in #fedora IRC channel, fedbot spamming 48 times
per day about Fedora respins update?

[16:51]  *** F32-20200715 updated lives available:
https://tinyurl.com/Live-respins2 Built by the Fedora Respin Sig more
info #fedora-respins ***
___
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

Self Introduction Ludovic Hirlimann

[Ludovic Hirlimann via devel]

Hi,


I'm ludo. I've been involved with opensource for a long time now (using
my first linux in 1996). I have been a mozilla employee for 10 years (as
the Thunderbird QA lead and then as an IT staffer). I'm back to linux
since 2015 (used FreeBSD and MacOSX since 2000). I choose Fedora as my
distribution of choice and been running it since version 21. I like
opendata and have particpated in musicbrainz and still participate to
openstreetmap. I've always like maps and thus I'd like to join de Fedora
packaging community to maintain, or help maintain two packages that are
Map related : josm and qgis.

I don't have much experience in maintaining packages but I'm more than
willing to learn.

Have a nice day.

Ludovic

-- 
https://www.hirlimann.net/Ludovic/carnet/




signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Upcoming Fedora 33 Change proposal deadlines

[Ben Cotton]

This is the final reminder of the Fedora 33 Change proposal deadlines:

 * 2020-07-21: Proposal deadline for Self-Contained Changes

The mass rebuild is scheduled to begin next week as well.

For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Upcoming Fedora 33 Change proposal deadlines

[Ben Cotton]

This is the final reminder of the Fedora 33 Change proposal deadlines:

 * 2020-07-21: Proposal deadline for Self-Contained Changes

The mass rebuild is scheduled to begin next week as well.

For the full schedule, see
https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org

[EPEL-devel] Re: clusterssh for EPEL 8

[Patrick Riehecky]

Can you open a bugzilla requesting this be added to EPEL8?

Pat

On Thu, 2020-07-16 at 22:01 -0400, Chris Schanzle wrote:
> Hi,
> 
> Clusterssh is a nice tool to send input to multiple ssh sessions
> simultaneously -- handy for managing a cluster of systems.  I don't
> know if there is much other interest for clusterssh, but I wanted to
> share my experience on building it and it seems like it would be
> fairly low effort to add these to EPEL 8.
> 
> Using mock, I was able to rebuild to my local repo:
> 
> clusterssh-4.14-2.fc32.src.rpm
> 
> after building two dependencies:
> 
> perl-X11-Protocol-0.56-33.fc32.src.rpm
> perl-X11-Protocol-Other-31-3.fc32.src.rpm
> 
> No changes to src.rpm's were needed to build the packages.
> 
> Thanks for your amazing work!
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to 
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-2Dconduct_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=9XsptSeviKe1gGO1YIceqqQcdS2iWyfGHDBJeFuN-GE=wOFICWkMTJX8sCJ-GBePn3W7AmNihqcw4G2ziLSDZWU=
>  
> List Guidelines: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_Mailing-5Flist-5Fguidelines=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=9XsptSeviKe1gGO1YIceqqQcdS2iWyfGHDBJeFuN-GE=MTnFkzqmFpAAN-UVbeUuZIiPDwmQghJQiVK-wOu2rkE=
>  
> List Archives: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.org_archives_list_epel-2Ddevel-40lists.fedoraproject.org=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=9XsptSeviKe1gGO1YIceqqQcdS2iWyfGHDBJeFuN-GE=cGYZ2g3J01d4NqQHDG0FmOQGNNoPVRF02Q8lYhDVTe4=
>  
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Fedora in 6th gear

[Vít Ondruch]

Thx to everybody who submitted the change proposal. It is nice that
people follow the process instead of just pushing something into Fedora
without sharing with wider audience.


Vít


Dne 16. 07. 20 v 19:52 Zbigniew Jędrzejewski-Szmek napsal(a):
> In the FESCo meeting summary email sent out today there were 10
> changes approved. I had the feeling that this is more than usual,
> so I took a look at the wiki.
>
> Tally (systemd-wide and self-contained):
> F20: 14 + 22
> F21: 28 + 34
> F22: 21 + 15
> F23: 12 +  7
> F24: 20 + 23
> F25:  9 + 11
> F26: 17 + 22
> F27: 20 + 15
> F28: 31 + 19
> F29: 23 + 20
> F30: 25 + 24
> F31: 21 + 21
> F32: 23 + 20
> F33: 40 + 18 (and growing)
>
> Seems that this be a busy release :)
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Koji oops

[Dan Horák]

On Fri, 17 Jul 2020 15:15:00 +0300
Евгений Пивнев  wrote:

> What’s wrong with koji?
> Yet another maintenance jobs that I missed?
> https://koji.fedoraproject.org/koji/taskinfo?taskID=47345974
> 

this is a packaging bug, from build.log:
cp: cannot stat 'ImageLounge/Readme/README': No such file or directory

> https://koji.fedoraproject.org/koji/taskinfo?taskID=47346270
> 

yes, this one looks as an unplanned outage


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

Koji oops

[Евгений Пивнев]

What’s wrong with koji?
Yet another maintenance jobs that I missed?
https://koji.fedoraproject.org/koji/taskinfo?taskID=47345974 

https://koji.fedoraproject.org/koji/taskinfo?taskID=47346270 
___
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: Removing packages from module

[Aleksei Bavshin]

On 7/17/20 3:27 AM, Daniel Mach wrote:
> Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):
>> If the package was part of the module during the release of Fedora 32,
>> dnf will see 2 versions/builds of the module-stream:
>>
>>   - the one that existed during the release (containing the package)
>>   - the one from updates (no longer containing the package)
>>
>> The "original" version will still filter out the non-modular version
>> of the package from any transaction.
>>
>> And given the way modular filtering works, a package cannot
>> technically be "demodularized" this was during one release, unless you
>> force a module reset from another package's scriptlet.

Thanks for clarifying this, Miro. So the filter is built based on the
module metadata instead of the installed packages. I guess I
misunderstood that part.

That's just sad. I woke up with the bright idea about removing the
packages from modulemd and then adding `sway-module-obsoletes` which
Obsoletes everything in the module that's behind f32-updates. We have
several packages like this since the last module rebuild.

If there's a cached non-updateable module metadata from fedora-modular
which is always considered by dnf together with the updated version from
fedora-updates-modular, that had no chance of working.

>> During the update to Fedora 33 a modular reset should happen anyway.
>> But even if it doesn't I believe that the packages would be upgraded
>> to non-modular, assuming their EVR is higher. I might be wrong thou,
>> because the concept of removing packages from modules and making them
>> non-modular is full of booby traps.
> 
> The module reset is essential, because otherwise DNF will keep using
> fail-safe module data on disk and that would still keep the package
> filtered.
> 
> I suggest making the change in F33 / Rawhide.
> Rawhide shouldn't break, because there's only one (the latest) version
> of each module in the repodata and if you release a new modulemd without
> the package, everything should work as expected.
Your suggestion implies that there's a way to build different set of
packages for different releases within the same module stream, right?

Because with what Miro said, we are stuck with the requirement to update
every package we have in the module until f32 is EOL. I can't just drop
package x from modulemd and say "x won't be ever updated in f32 because
modularity" :(


-- 
With best regards,
Aleksei Bavshin



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

matroska stack update (soname bumps)

[Dominik 'Rathann' Mierzejewski]

Hello,
I'm updating the matroska stack to the latest upstream versions,
including stable branches as the libraries are security sensitive.

libebml and libmatroska come with soname bumps but no incompatible
API changes. I tested the rebuilds in copr in advance.

I'm rebuilding all dependent packages in side tags, starting with
rawhide:
gerbera
mkvtoolnix
libebml
libmatroska

Maintainers have been Bcc'd.

vlc from RPM Fusion will be rebuilt separately.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora rawhide compose report: 20200717.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200715.n.2
NEW: Fedora-Rawhide-20200717.n.0

= SUMMARY =
Added images:10
Dropped images:  3
Added packages:  8
Dropped packages:3
Upgraded packages:   95
Downgraded packages: 0

Size of added packages:  6.61 MiB
Size of dropped packages:6.74 MiB
Size of upgraded packages:   3.29 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200717.n.0.s390x.qcow2
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20200717.n.0.s390x.tar.xz
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20200717.n.0.s390x.tar.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20200717.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200717.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20200717.n.0.x86_64.vagrant-libvirt.box
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20200717.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20200717.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200717.n.0.s390x.raw.xz
Image: Cloud_Base vmdk s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20200717.n.0.s390x.vmdk

= DROPPED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200715.n.2.ppc64le.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20200715.n.2.ppc64le.tar.xz
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20200715.n.2.iso

= ADDED PACKAGES =
Package: credslayer-0.1.2-1.fc33
Summary: Extract credentials and other details from network captures
RPMs:credslayer python-credslayer-doc python3-credslayer
Size:4.90 MiB

Package: python-flask-wtf-decorators-0.1.2-0.2.20200715.7fa5a26.fc33
Summary: Use decorators to validate forms
RPMs:python3-flask-wtf-decorators
Size:12.92 KiB

Package: python-widgetsnbextension-3.5.1-1.fc33
Summary: Interactive HTML widgets for Jupyter notebooks
RPMs:python3-widgetsnbextension
Size:865.07 KiB

Package: rubygem-ncursesw-1.4.10-1.fc33
Summary: Ruby wrapper for the ncurses library, with wide character support
RPMs:rubygem-ncursesw rubygem-ncursesw-doc
Size:661.97 KiB

Package: rust-enumflags2-0.6.4-1.fc33
Summary: Enum-based bit flags
RPMs:rust-enumflags2+default-devel rust-enumflags2+not_literal-devel 
rust-enumflags2+serde-devel rust-enumflags2+std-devel rust-enumflags2-devel
Size:46.88 KiB

Package: rust-hostname-validator-1.0.0-1.fc33
Summary: Validate hostnames according to IETF RFC 1123
RPMs:rust-hostname-validator+default-devel rust-hostname-validator-devel
Size:17.59 KiB

Package: rust-mbox-0.5.0-1.fc33
Summary: Malloc-based box
RPMs:rust-mbox+default-devel rust-mbox+std-devel rust-mbox-devel
Size:34.10 KiB

Package: rust-tss-esapi-4.0.5~alpha.1-1.fc33
Summary: Wrapper around TSS 2.0 Enhanced System API
RPMs:rust-tss-esapi+default-devel rust-tss-esapi+docs-devel 
rust-tss-esapi-devel
Size:113.56 KiB


= DROPPED PACKAGES =
Package: gtkglextmm-1.2.0-32.fc32
Summary: C++ wrapper for GtkGlExt
RPMs:gtkglextmm gtkglextmm-devel
Size:1.97 MiB

Package: repsnapper-2.5-0.4.a5.fc32
Summary: RepRap control software
RPMs:repsnapper
Size:2.62 MiB

Package: vocal-2.4.1-3.fc32
Summary: Powerful, beautiful, and simple podcast client
RPMs:vocal
Size:2.15 MiB


= UPGRADED PACKAGES =
Package:  FAudio-20.07-1.fc33
Old package:  FAudio-20.06-1.fc33
Summary:  FNA is a reimplementation of the Microsoft XNA Game Studio 4.0 
Refresh libraries
RPMs: libFAudio libFAudio-devel
Size: 797.77 KiB
Size change:  1.22 KiB
Changelog:
  * Wed Jul 15 2020 Michael Cronenworth  - 20.07-1
  - Update to 20.07


Package:  NetworkManager-1:1.26.0-2.fc33
Old package:  NetworkManager-1:1.26.0-1.fc33
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 28.31 MiB
Size change:  6.66 KiB
Changelog:
  * Mon Jul 13 2020 Thomas Haller  - 1

[Bug 1857787] perl-LWP-Protocol-https-6.09 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-LWP-Protocol-https-6.0
   ||9-1.fc33
   Assignee|ppi...@redhat.com   |jples...@redhat.com
   Doc Type|--- |If docs needed, set a value




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

Review swap

[clime]

Hello,

I have a package rpm-git-tag-sort for a review. Can I swap it with somebody?

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

clime
___
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: Claim delve

[Robert-André Mauchin]

On Thursday, 16 July 2020 19:38:22 CEST Alejandro Saez Morollon wrote:
> Hi there, folks.
> 
> Delve[0] (a Golang debugger) was retired due to the impossibility of
> building a new version of delve for dependencies issues. I would like
> to claim the package and fix the situation. I already have one of the
> dependencies[1] in the works.
> 
> I already talked with the original maintainer (he's in cc) and he is OK with
> it.
 
> Thanks.
> 
> [0] https://src.fedoraproject.org/rpms/delve
> [1] https://src.fedoraproject.org/rpms/golang-starlark
> ___
> 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

Ark the Golang SIG (and me) for any help regarding the deps.

___
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

[Test-Announce] Fedora 33 Rawhide 20200717.n.0 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20200713.n.0: anaconda-33.21-1.fc33.src, 20200717.n.0: 
anaconda-33.23-1.fc33.src

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

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

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

The individual test result pages are:

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

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: Removing packages from module

[Daniel Mach]

Dne 17. 07. 20 v 11:04 Miro Hrončok napsal(a):

On 17. 07. 20 6:47, Aleksei Bavshin wrote:

In an optimistic case I'd like to believe that once the package is
removed from the modulemd file and a new module update is published, the
override magic hacked into dnf would stop masking package from
non-modular repository. NEVRA would be the only factor deciding the
update priority and when we push new build of the package into
f32-updates it would update the remaining modular build of the package
with lower EVR.


If the package was part of the module during the release of Fedora 32, 
dnf will see 2 versions/builds of the module-stream:


  - the one that existed during the release (containing the package)
  - the one from updates (no longer containing the package)

The "original" version will still filter out the non-modular version of 
the package from any transaction.


And given the way modular filtering works, a package cannot technically 
be "demodularized" this was during one release, unless you force a 
module reset from another package's scriptlet.


Thanks Miro,
That exactly describes what happens.


In a pessimistic case I expect that the package removed from the module
will never be updated by dnf in the same release cycle since the already
installed version originates from the modular repository. Upgrade to f33
would require module reset.


During the update to Fedora 33 a modular reset should happen anyway. But 
even if it doesn't I believe that the packages would be upgraded to 
non-modular, assuming their EVR is higher. I might be wrong thou, 
because the concept of removing packages from modules and making them 
non-modular is full of booby traps.


The module reset is essential, because otherwise DNF will keep using 
fail-safe module data on disk and that would still keep the package 
filtered.


I suggest making the change in F33 / Rawhide.
Rawhide shouldn't break, because there's only one (the latest) version 
of each module in the repodata and if you release a new modulemd without 
the package, everything should work as expected.

___
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 1858226] New: perl-Mojolicious-8.57 is available

[bugzilla]

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

Bug ID: 1858226
   Summary: perl-Mojolicious-8.57 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.57
Current version/release in rawhide: 8.51-1.fc33
URL: https://metacpan.org/release/Mojolicious

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


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


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


Based on the information from anitya:
https://release-monitoring.org/project/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

Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed

[Iñaki Ucar]

On Fri, 17 Jul 2020 at 11:19, Dan Horák  wrote:
>
> On Fri, 17 Jul 2020 10:42:45 +0200
> Iñaki Ucar  wrote:
>
> > Could someone with superpowers cancel the following task for me?
> > Thanks.
>
> done, it has already failed on i686

Yeah, that's why I wanted to cancel it. The task was launched without
the --fail-fast flag and it takes many hours to complete on s390x and
armv7hl. Thanks!

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

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

[Iñaki Ucar]

On Fri, 17 Jul 2020 at 11:19, Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Friday, 17 July 2020 at 10:25, Dave Love wrote:
> > There will be hoops to jump through to get packages to configure when
> > they don't know about the library.
>
> From what I understand from the proposal, FlexiBLAS looks like vanilla
> BLAS and LAPACK to the consumers. No hoop jumping required.

Correct.

> >  If I want to use a library that's
> > not included, I'm in the same position.  It's not clear to me a priori
> > what happens if you try to use just BLIS even, given that OpenBLAS'
>
> From what I understand, if you select BLIS, then it'll be used for all
> symbols it implements and netlib reference will be used for the rest.

And correct.

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

Re: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

[Dominik 'Rathann' Mierzejewski]

On Friday, 17 July 2020 at 10:25, Dave Love wrote:
> [I found I hadn't sent this earlier, as I should have.]
> 
> > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
> >
> > == Summary ==
> > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
> > library, which will set OpenBLAS as system-wide default backend, and
> > at the same time will provide a proper switching mechanism that
> > currently Fedora lacks.
> >
> I oppose this (in favour of a different approach) from experience in
> research computing system management, general support, and
> implementation.  It doesn't solve any problem I (have) had, as far as I
> can tell, and looks as if it produces more.  The licence seems to me to
> rule it out a priori.

Licence issues seem to have been cleared according to a message further
down the thread.

> The proposal doesn't justify things, including its dismissal of the
> simple, clean alternative in similar to Debian's, with which I have some
> experience.

What exact alternative are you proposing, then? Carrying downstream
patches to all BLAS/LAPACK implementations like Debian? I don't think
that's sustainable.

> (I don't know what the environment modules alternative is, since
> that's one way of specifying the late binding.)

Environment modules are user-selectable sets of environment variable
values and require affected packages to be built in a specific way.
https://docs.fedoraproject.org/en-US/packaging-guidelines/EnvironmentModules/

> BLAS isn't alone in presenting a substitute interface like that.  It
> works well with a heterogeneous HPC cluster where you want different
> BLAS implementations on different nodes (think KNL, A64FX).

I'm not sure what you mean here. What "substitute interface" are you
talking about?

> There will be hoops to jump through to get packages to configure when
> they don't know about the library.

From what I understand from the proposal, FlexiBLAS looks like vanilla
BLAS and LAPACK to the consumers. No hoop jumping required.

>  If I want to use a library that's
> not included, I'm in the same position.  It's not clear to me a priori
> what happens if you try to use just BLIS even, given that OpenBLAS'

From what I understand, if you select BLIS, then it'll be used for all
symbols it implements and netlib reference will be used for the rest.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
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-java] Re: Mass rebuild for f33-java11 side tag completed

[Dan Horák]

On Fri, 17 Jul 2020 10:42:45 +0200
Iñaki Ucar  wrote:

> Could someone with superpowers cancel the following task for me?
> Thanks.

done, it has already failed on i686


Dan

> https://koji.fedoraproject.org/koji/taskinfo?taskID=47330918
> 
> On Fri, 17 Jul 2020 at 09:44, Fabio Valentini 
> wrote:
> >
> > On Wed, Jul 15, 2020 at 5:55 PM Mat Booth 
> > wrote:
> > > Any update? Any thoughts on when you want to merge the f33-java11
> > > side tag back into rawhide?
> >
> > I second this, please don't wait two weeks [0] for merging the side
> > tag, it's only going to cause merge conflict problems with packages
> > that get rebuilt in rawhide until then.
> > Please just do it now, and we'll fix any Java 11 FTBFS issues in
> > rawhide directly.
> >
> > Fabio
> >
> > [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1858082#c3
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
> 
> 
> -- 
> Iñaki Úcar
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List
> Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Removing packages from module

[Miro Hrončok]

On 17. 07. 20 6:47, Aleksei Bavshin wrote:

In an optimistic case I'd like to believe that once the package is
removed from the modulemd file and a new module update is published, the
override magic hacked into dnf would stop masking package from
non-modular repository. NEVRA would be the only factor deciding the
update priority and when we push new build of the package into
f32-updates it would update the remaining modular build of the package
with lower EVR.


If the package was part of the module during the release of Fedora 32, dnf will 
see 2 versions/builds of the module-stream:


 - the one that existed during the release (containing the package)
 - the one from updates (no longer containing the package)

The "original" version will still filter out the non-modular version of the 
package from any transaction.


And given the way modular filtering works, a package cannot technically be 
"demodularized" this was during one release, unless you force a module reset 
from another package's scriptlet.



In a pessimistic case I expect that the package removed from the module
will never be updated by dnf in the same release cycle since the already
installed version originates from the modular repository. Upgrade to f33
would require module reset.


During the update to Fedora 33 a modular reset should happen anyway. But even if 
it doesn't I believe that the packages would be upgraded to non-modular, 
assuming their EVR is higher. I might be wrong thou, because the concept of 
removing packages from modules and making them non-modular is full of booby traps.


--
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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

[Iñaki Ucar]

On Fri, 17 Jul 2020 at 10:34, Dave Love  wrote:
>
> [I found I hadn't sent this earlier, as I should have.]
>
> > https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
> >
> > == Summary ==
> > BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
> > library, which will set OpenBLAS as system-wide default backend, and
> > at the same time will provide a proper switching mechanism that
> > currently Fedora lacks.
> >
> I oppose this (in favour of a different approach) from experience in
> research computing system management, general support, and
> implementation.  It doesn't solve any problem I (have) had, as far as I
> can tell, and looks as if it produces more.  The licence seems to me to
> rule it out a priori.

The authors are going to add an exception, so the license won't be a
problem. What problems do you think it produces?

> The proposal doesn't justify things, including its dismissal of the
> simple, clean alternative in similar to Debian's, with which I have some

I don't justify that because Debian's alternative has been repeatedly
dismissed as an option for Fedora for a simple reason: one could end
up with libblas pointing to one implementation and liblapack pointing
to another. This problem, that Debian has, is solved with this
library.

> There will be hoops to jump through to get packages to configure when
> they don't know about the library.

I don't think so, but if there are serious issues, rolling back the
change is pretty straightforward.

> If I want to use a library that's
> not included, I'm in the same position.

No, you are not. You just need to point to that library using the
FLEXIBLAS environment variable.

> It's not clear to me a priori
> what happens if you try to use just BLIS even, given that OpenBLAS'
> LAPACK implementation isn't the vanilla one, and depends on OpenBLAS as
> far as I know.

I don't understand this. You can switch to BLIS easily. The default
one doesn't matter.

> The choice of OpenBLAS isn't justified.  It's not even
> obvious that you want the same implementation for serial and
> multi-threaded as OpenBLAS seems to have had continual problems with
> threading which BLIS hasn't as far as I know.  I expect OpenBLAS is the
> best serial option on average, at least, but that needs data for
> different architectures.

This is about having a sane default one. That's it. You can switch
then to whatever implementation you want.

> I realize no-one is going to be running Fedora on HPC systems, where
> this really matters, but presumably it filters down to RHEL, which is
> looking less and less like a good HPC platform to me.

Actually, FlexiBLAS is developed by researchers in HPC.

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

Re: [fedora-java] Re: Mass rebuild for f33-java11 side tag completed

[Iñaki Ucar]

Could someone with superpowers cancel the following task for me? Thanks.

https://koji.fedoraproject.org/koji/taskinfo?taskID=47330918

On Fri, 17 Jul 2020 at 09:44, Fabio Valentini  wrote:
>
> On Wed, Jul 15, 2020 at 5:55 PM Mat Booth  wrote:
> > Any update? Any thoughts on when you want to merge the f33-java11 side tag 
> > back into rawhide?
>
> I second this, please don't wait two weeks [0] for merging the side
> tag, it's only going to cause merge conflict problems with packages
> that get rebuilt in rawhide until then.
> Please just do it now, and we'll fix any Java 11 FTBFS issues in
> rawhide directly.
>
> Fabio
>
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1858082#c3
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



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

Re: Ditch RPM in favor of DPKG

[Nico Kadel-Garcia]

On Fri, Jul 17, 2020 at 3:15 AM Dridi Boukelmoune
 wrote:
>
> > Oddly, the subject of the original post infers getting rid of rpm but
> > the post itself sounds like it's proposing something different and
> > that's why I decided to speak up.
>
> Yes, poor joke of mine, keeps hitting home though :)
>
> Ditching RPM in favor of DPKG was never meant to be a system-wide
> change, but simply switching Fedora's apt package from apt-rpm to
> regular apt. The original post was intentionally misleading because I
> have a particular sense of humor and frankly I didn't think that after
> months of completion this change would still make my day every once in
> a while.

Again, "no". It won't work that easy, for exactly the same reasons I
already mentioned. The components overlap far too much and will
inevitably conflict.
___
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: Mass rebuild for f33-java11 side tag completed

[Christian Heimes]

> Hello!
> 
> toatal packages: 610
> passed: 427
> failed: 176
> 
> From the failures, there is 29 which passed in the copr before, and now are 
> thus failing
> from two
> reasons - unrelated change, or non-intel64-arch failure. I will put this to 
> FTBF bugs for
> those 29
> pacakges,
> 
> 
> In Monday, or as other duties allows I will fill FTBFS bugs for failures  
> with straces and
> reproduce
> steps.
> In default CC will be, me, Severin, decathrope and 
> java-devel(a)lists.fedoraproject.org.
> 
> Note that during non-sidetag rebuild during fedora 33 branching in start of 
> August,  we
> can expect
> some indirect dependencies to fail.
> 
> Thoughts?

Hi Jiri,

how will a merge of the Java 11 side tag into F33 Rawhide affect Dogtag
PKI? Dogtag PKI (aka pki-core package) is mostly written on top of the
Tomcat stack. As far as I know the Dogtag team is still working on Java
11 support.

Dogtag is a core component of FreeIPA, which is a one of three major
features of Fedora Server collection (the other two are modularity and
Cockpit) [0]. FreeIPA is also part of Fedora's OpenQA effort. It's
likely that Java 11 update is going to break a core feature of Fedora
and QA gating for a considerable amount of packages.

Could you please hold of the merge of the side tag and work with the
Dogtag team to solve the issue?

By the way I see a rebuild of Tomcat in the side tag but there is no
pki-core build. Why is pki-core missing from the tag? Is it one of the
FTBFS packages?

$ koji list-tagged f33-java11 | grep tomcat
tomcat-9.0.36-2.fc33  f33-java11jvanek
tomcat-native-1.2.23-2.fc33   f33-java11jvanek
tomcat-taglibs-parent-3-12.fc33   f33-java11jvanek
tomcatjss-7.5.0-0.5.fc33  f33-java11jvanek
$ koji list-tagged f33-java11 | grep pki


Christian

[0] https://getfedora.org/en/server/
___
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: FlexiBLAS as BLAS/LAPACK manager - Fedora 33 System-Wide Change proposal

[Dave Love]

[I found I hadn't sent this earlier, as I should have.]

> https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager
>
> == Summary ==
> BLAS/LAPACK packages will be compiled against the FlexiBLAS wrapper
> library, which will set OpenBLAS as system-wide default backend, and
> at the same time will provide a proper switching mechanism that
> currently Fedora lacks.
>
I oppose this (in favour of a different approach) from experience in
research computing system management, general support, and
implementation.  It doesn't solve any problem I (have) had, as far as I
can tell, and looks as if it produces more.  The licence seems to me to
rule it out a priori.

The proposal doesn't justify things, including its dismissal of the
simple, clean alternative in similar to Debian's, with which I have some
experience.  (I don't know what the environment modules alternative is,
since that's one way of specifying the late binding.)  BLAS isn't alone
in presenting a substitute interface like that.  It works well with a
heterogeneous HPC cluster where you want different BLAS implementations
on different nodes (think KNL, A64FX).

There will be hoops to jump through to get packages to configure when
they don't know about the library.  If I want to use a library that's
not included, I'm in the same position.  It's not clear to me a priori
what happens if you try to use just BLIS even, given that OpenBLAS'
LAPACK implementation isn't the vanilla one, and depends on OpenBLAS as
far as I know.  The choice of OpenBLAS isn't justified.  It's not even
obvious that you want the same implementation for serial and
multi-threaded as OpenBLAS seems to have had continual problems with
threading which BLIS hasn't as far as I know.  I expect OpenBLAS is the
best serial option on average, at least, but that needs data for
different architectures.

Profiling is listed as a feature, but I wouldn't want a LA-specific
profiler rather than a more general one.  (Scorep on el7 currently
doesn't do that for want of a suitable clang (or LLVM?) component to do
the library wrapping, but it could.)

I realize no-one is going to be running Fedora on HPC systems, where
this really matters, but presumably it filters down to RHEL, which is
looking less and less like a good HPC platform to me.
___
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-java] Re: Mass rebuild for f33-java11 side tag completed

[Fabio Valentini]

On Wed, Jul 15, 2020 at 5:55 PM Mat Booth  wrote:
> Any update? Any thoughts on when you want to merge the f33-java11 side tag 
> back into rawhide?

I second this, please don't wait two weeks [0] for merging the side
tag, it's only going to cause merge conflict problems with packages
that get rebuilt in rawhide until then.
Please just do it now, and we'll fix any Java 11 FTBFS issues in
rawhide directly.

Fabio

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1858082#c3
___
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: Ditch RPM in favor of DPKG

[Dridi Boukelmoune]

> Oddly, the subject of the original post infers getting rid of rpm but
> the post itself sounds like it's proposing something different and
> that's why I decided to speak up.

Yes, poor joke of mine, keeps hitting home though :)

Ditching RPM in favor of DPKG was never meant to be a system-wide
change, but simply switching Fedora's apt package from apt-rpm to
regular apt. The original post was intentionally misleading because I
have a particular sense of humor and frankly I didn't think that after
months of completion this change would still make my day every once in
a while.

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

Seriously, nothing to worry about!

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

[EPEL-devel] clusterssh for EPEL 8

[Chris Schanzle]

Hi,

Clusterssh is a nice tool to send input to multiple ssh sessions simultaneously 
-- handy for managing a cluster of systems.  I don't know if there is much 
other interest for clusterssh, but I wanted to share my experience on building 
it and it seems like it would be fairly low effort to add these to EPEL 8.

Using mock, I was able to rebuild to my local repo:

clusterssh-4.14-2.fc32.src.rpm

after building two dependencies:

perl-X11-Protocol-0.56-33.fc32.src.rpm
perl-X11-Protocol-Other-31-3.fc32.src.rpm

No changes to src.rpm's were needed to build the packages.

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