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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-3c9eacae67   
python-rfc3986-1.3.0-1.el6 python3-requests-2.14.2-2.el6_10 
python3-urllib3-1.25.1-1.el6_10
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-81b7c3ebd7   
heimdal-7.7.0-2.el6_10
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-360263f378   
libetpan-1.0-3.el6_10


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

pspg-2.6.4-1.el6

Details about builds:



 pspg-2.6.4-1.el6 (FEDORA-EPEL-2020-9bfd29db70)
 A unix pager optimized for psql

Update Information:

new upstream release, per release notes,
https://github.com/okbob/pspg/releases/tag/2.6.2
https://github.com/okbob/pspg/releases/tag/2.6.3
https://github.com/okbob/pspg/releases/tag/2.6.4

ChangeLog:

* Sun Jan  5 2020 Pavel Raiskup  - 2.6.4-1
- new upstream release, per release notes:
  https://github.com/okbob/pspg/releases/tag/2.6.2
  https://github.com/okbob/pspg/releases/tag/2.6.3
  https://github.com/okbob/pspg/releases/tag/2.6.4
* Sun Dec 15 2019 Pavel Raiskup  - 2.6.1-1
- new upstream release, per release notes:
  https://github.com/okbob/pspg/releases/tag/2.6.1

References:

  [ 1 ] Bug #1784220 - pspg-2.6.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1784220


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

[Bug 1787937] URLs in documentation are incorrect

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Term-ReadLine-Gnu-1.36-6.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-08e92852fa

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

Intent to unretire non-ntk

[Guido Aulisi]

Ciao,

I'm going to unretire non-ntk in rawhide and f31 releases,
because it's a dependency for lv2-sorcer and maybe other audio
packages.

I will file a review request ASAP, I have already made a scratch
build in rawhide [0]

FAS account: tartina

Ciao
Guido

[0]: https://koji.fedoraproject.org/koji/taskinfo?taskID=40167944


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 1787958] New: perl-DB_File-1.853 is available

[bugzilla]

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

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



Latest upstream release: 1.853
Current version/release in rawhide: 1.852-4.fc31
URL: http://search.cpan.org/dist/DB_File/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

-- 
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: lv2-sorcer is not installable

[Code Zombie]

I hope the package gets unretired, because the way things are now, even
dnf groupinstall "Audio Production" fails to work.

- Mehdi

On Sun, Jan 5, 2020, 15:11 Guido Aulisi  wrote:

> Il giorno dom, 05/01/2020 alle 12.21 +0100, Miro Hrončok ha scritto:
> > On 03. 01. 20 19:24, Kevin Kofler wrote:
> > > Zbigniew Jędrzejewski-Szmek wrote:
> > > > The dep was provided by non-ntk, which got retired about half a
> > > > year
> > > > ago [1] after FTBFSing since F29 [2].
> > >
> > > Isn't it great when the policy designed to
> > > remove
> > > breakage from the distribution actually CREATES breakage? Retiring
> > > packages
> > > with no regards to their reverse dependencies is just broken. It
> > > had never
> > > been done that way in the past, before Miro's recent crackdown,
> > > because it
> > > simply defeats all common sense.
> >
> > As a matter of fact, the policy was changed recently, so depending
> > package
> > maintainers MUST get notifications. The Fedora 31 round was
> > unfortunate, mostly
> > because nobody got properly notified. I have devoted a great amount
> > of energy
> > and time to make it better for next rounds. I hope it worked. Only
> > couple of
> > packages are to be retired, where the maintainers simply don't care
> > anymore with
> > only one dependent package:
> >
> >
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/YRLNHZSV4U47A3MDWIU6MUANVMPEFKD2/
> >
> > For the F31 crackdown - it's not like a retired package cannot ever
> > be
> > unretired. It has been more than 8 weeks now, but I gladly re-review
> > a package
> > that got retired, if new maintainers pop up. Unlike you, I actually
> > believe
> > packages must be maintained in order to be kept.
>
> I'm working for unretiring non-ntk, I think I can file a new review
> request in one week, as soon as I come back home; I'm already working
> on it.
>
> > The solution is not to stop orphaning/retiring FTBFS packages, the
> > solution is
> > to get "broken deps" notifications working again:
> >
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBV3UTSPIGW3TOZJSYTXCZMRV4QBR7X5/
>
> Ciao
> Guido
>
> FAS: tartina
> ___
> 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 1787937] URLs in documentation are incorrect

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



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

-- 
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 1787937] URLs in documentation are incorrect

[bugzilla]

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

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Link ID||CPAN 131362
   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

Re: koji / bodhi issues status update

[Kevin Fenzi]

On Sun, Jan 05, 2020 at 05:27:19PM +0100, Clement Verna wrote:
> On Fri, 3 Jan 2020 at 22:41, Kevin Fenzi  wrote:
> 
> > As some of you may know, we have been having issues with koji and bodhi
> > over the holidays. :( koji would sometimes not tag builds or error them
> > with odd error messages and bodhi wasn't pushing updates.
> >
> > I'm happy to report that the underlying issue seems to be fixed now.
> > We hopefully will have a more detailed root cause next week.
> >
> > However, due to the koji issues builds were in a state where bodhi
> > ejected many of them from updates pushes. We are working on cleaning
> > up the state of those updates and there's no need for maintainers to do
> > anything with those updates at this time.
> >
> > Once we get the ejected builds cleaned up we should be able to resume
> > normal bodhi updates pushes.
> >
> 
> Hi all,
> 
> I think that we now have dealt with most of the ejected updates. It seems
> that there are still a few rawhide updates stuck in pending so I ll be
> looking at unblocking these.
> 
> Please let us know if you believed that we have missed something.

Additionally there were a number of builds in koji in "BUILDING" state,
even though they had failed/had no active tasks building them. 

I went ahead and canceled them all, so now maintainers should be able to
resubmit or just do a new build. List of those by maintainer is: 

cabal-rpm-1.0.3-1.fc32   petersen  
BUILDING
cobbler-2.8.5-1.el7  orion 
BUILDING
desktopfolder-1.1.2-1.fc31   atim  
BUILDING
efl-1.23.1-1.fc32spot  
BUILDING
fleet-commander-admin-0.15.0-1.fc30  ogutierrez
BUILDING
gstreamer1-plugins-bad-free-1.16.2-1.fc32wtaymans  
BUILDING
gstreamer1-plugins-base-1.16.2-2.fc31wtaymans  
BUILDING
heimdal-7.7.0-2.epel8.playground abo   
BUILDING
im-chooser-1.7.3-1.epel8.playground  tagoh 
BUILDING
imsettings-1.8.2-1.fc32  tagoh 
BUILDING
js8call-2.1.1-1.fc32 hobbes1069
BUILDING
libbpf-0.0.6-1.fc32  jolsa 
BUILDING
libwacom-1.2-2.fc32  whot  
BUILDING
mellowplayer-3.5.8-1.20191227git9fd6cee.fc32 martinkg  
BUILDING
module-build-macros-0.1-1.module_f32+7264+508b1e07   
mbs/mbs.fedoraproject.org  BUILDING
module-build-macros-0.1-1.module_f32+7272+cab9d0cd   
mbs/mbs.fedoraproject.org  BUILDING
musique-1.7-1.fc32   lbazan
BUILDING
mypaint-2.0.0-0.4.beta.0.fc32avsej 
BUILDING
osc-source_validator-0.19-2.fc31 ngompa
BUILDING
pdf-stapler-1.0.0-1.fc32 aarem 
BUILDING
perl-Config-Model-2.138-1.fc32   eseyman   
BUILDING
python-avocado-74.0-1.module_f31+7253+5196ffdf   
mbs/mbs.fedoraproject.org  BUILDING
python-chaospy-3.0.17-1.fc30 lbazan
BUILDING
python-django-threadedcomments-1.2-8.fc30lbazan
BUILDING
python-lz4-3.0.2-1.fc30  jgu   
BUILDING
python-lz4-3.0.2-1.fc31  jgu   
BUILDING
python-lz4-3.0.2-1.fc32  jgu   
BUILDING
python-mypy_extensions-0.4.1-5.fc32  ignatenkobrain
BUILDING
python-paho-mqtt-1.5.0-2.fc31fab   
BUILDING
python-pycares-3.1.0-fix3.1.fc31 fantom
BUILDING
python-pyelectro-0.1.10-1.fc32   major 
BUILDING
python-versioneer-0.18-2.fc32nonamedotc
BUILDING
rubygem-pg-1.2.0-1.fc32  jaruga
BUILDING
ucblogo-6.1-1.fc31   jrincayc  
BUILDING
vertica-python-0.10.1-1.el7  kubo  
BUILDING

I don't want to blindly resubmit in case folks already bumped release
and make newer builds. If thats the case, you have nothing to do here. 

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: 

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Sun, Jan 5, 2020 at 4:43 AM Aleksandra Fedorova  wrote:
>
> I wonder, how I as a user going to be informed about the
> earlyoom-event?

Same as a kernel oom-killer event. Primary source is the journal.

But well before either earlyoom sends SIGTERM or kernel oom-killer
kills something, the user will know something is wrong, because system
responsivity will be stuttering or even already intermittently
hanging. Earlyoom is not aggressively clobbering things, except for
system configuration that have no swap device. That configuration
needs some earlyoom tweaking, probably, and we're looking at that, but
then those folks also aren't experiencing much reduced system
responsiveness in these cases because their system can't heavily swap.

>I assume abrt will recognize the crash? Will it be
> easily visible from the abrt report that it was the OOM?

No. It's not a crash. Earlyoom sends SIGTERM first, and only sends
SIGKILL if the process isn't responding in time to SIGTERM. And the
kernel oom-killer also doesn't result in an abrt report.

> The concern is: if we enable such a service, will we get large amount
> of vague bug reports from users who don't understand what has
> happened. Can we make it somehow easier to debug?

Unless further real world testing uncovers something very new and
different from my testing (entirely possible, but I can't estimate
that probability), there won't be a measurable increase in bug reports
related to this.

Based on my limited testing (I've done around 200+ tests of
oom-killer, earlyoom SIGTERM (never have seen a SIGKILL), and nohang;
and perhaps 80 of those tests involved forced power off during heavy
swap, compile and system use) there really isn't anything that
requires the user to get involved.

Also, there isn't a per se bug here. It's a series of intentional
designs that are colliding together in a deeply problematic user
experience for the desktop: that the "operating system", i.e. Fedora
Workstation providing kernel, systemd, a bunch of services, libraries,
policies - permits an unprivileged process to ask for essentially
unlimited resources and overcommit the system *and* then heavy swap
use results in compromised system responsiveness and control.

Earlyoom doesn't change any of that, it just selects a process for
SIGTERM much sooner than the kernel oom-killer. And that only stops
the bad experience, by stopping the resource hogging process. It isn't
actually fixing anything. It is in some sense an act of desperation,
that's been a long time coming. Arguably, earlyoom isn't aggressive
enough, doesn't stop the badness soon enough.


-- 
Chris Murphy
___
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-01-06 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

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

Greetings testers!

It's a new year, and we haven't met for a while, so sorry for the short
notice, but let's get together tomorrow!

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. Outstanding proposals
3. Sponsorship process (#603)
4. F32 status
5. Test Day / community event status
6. 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

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Chris Murphy]

On Sun, Jan 5, 2020 at 2:18 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > My understanding of systemd OOMPolicy= behavior, is it looks for the
> > kernel's oom-killer messages and acts upon those. Whereas earlyoom
> > uses the same metric (oom_score) as the oom-killer, it does not invoke
> > the oom-killer. Therefore systemd probably does not get the proper
> > hint to implement OOMPolicy=
>
> Yes. The kernel reports oom events in the cgroup file memory.events,
> and systemd waits for an inotify event on that file; OOMPolicy=stop is
> implemented that way. And the OOMPolicy=kill option is "implemented"
> by setting memory.oom.group=1 in the kernel [1] and having the kernel
> kill all the processes. So systemd is providing a thin wrapper around
> the kernel functionality.
>
> If processes are not killed by the kernel but through a signal from
> userspace, all of this will not work.

The gotcha on the desktop with kernel oom-killer, is that if it's
needed, it's way past too late. And it may never trigger.

The central problem to be solved isn't even what does OOM killing or
when: the ridiculously bad system responsiveness during heavy swap
usage.

My top criticism of the feature proposal is that it doesn't address
the responsivity problem head on. It just reduces the duration of
badness. And the reduction isn't near enough.

One thing that helps the heavy swap problem, today? A much smaller
swap partition. In fact, no swap partition alleviates the problem
entirely, but of course that has other consequences (that the working
group is discussing in #120).

-- 
Chris Murphy
___
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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

[John M. Harris Jr]

On Sunday, January 5, 2020 5:23:12 AM MST Bohdan Khomutskyi wrote:
>  Summary
> 
> Improve compression ratio of SquashFS filesystem on the installation media.
> Owner
> 
> Name: Bohdan Khomutskyi
> 
> Email: bkhom...@redhat.com
> Current status
> 
> Targeted release: I propose this change for Fedora 32
> 
> Last updated: Jan 5 2020
> 
> Pagure.io issue: https://pagure.io/releng/issue/9127
> 
> I was unable to create an article in Fedora wiki system.
> Detailed Description
> 
> As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is
> compressed with default settings of mksquashfs. The standard configuration
> is set to XZ algorithm with block size of 128k and BCJ filter enabled.
> Those parameters can be adjusted which will lead to a better compression
> ratio and/or reduction of the CPU usage at build time.
> 
> This is simple to achieve. Recently, Lorax has gotten support[1] for
> adjusting the compression options for mksquashfs via the configuration
> file. The file should be altered as following:
> 
> [compression]
> bcj = yes
> args = -b 1M -Xdict-size 1M -no-recovery
> 
> Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively.
> Could be adjusted.
> Benefit to Fedora
> 
>-
> 
>Reduction of the installation media size and the cost of storing and
>distributing Fedora.
>-
> 
>Reduction of the CPU usage at build time. Depending on which compression
>parameters chosen.
>-
> 
>See a graphical detail at https://pagure.io/releng/issue/9127.
> 
> Scope
> 
>-
> 
>Proposal owners:
> 
> The build environment should have support for adjusting the Lorax
> configuration file.. Lorax is a program that produces the
> LiveOS/squashfs.img file on the installation media.
> 
> One of the way to allow for such customization, is to add a feature in
> Pungi, to allow for passing -c option to Lorax.
> 
>-
> 
>Release engineering: #9127 
>-
> 
>Policies and guidelines: N/A
>-
> 
>Trademark approval: N/A
> 
> Upgrade/compatibility impact
> 
>-
> 
>This change comes at a cost of higher memory usage during the
>installation. Based on my personal estimations, this should not be the
>issue. Since the decompression should require up to 1MiB per thread.
> 
> User Experience
> 
>-
> 
>Increasing the block size on the current configuration with EXT4 file
>system, should increase latency while accessing the EXT4 filesystem. The
>exact impact is to be evaluated.
>-
> 
>The impact of latency will be reduced, if the plain SquashFS option is
>be choosen.
> 
> Dependencies
> 
>-
> 
>N/A
> 
> Contingency Plan
> 
>-
> 
>N/A
> 
> Documentation
> https://pagure.io/releng/issue/9127.
> 
> mksquashfs(1)
> Release notes See also
> 
> https://pagure.io/releng/issue/8646
> 
> --
> 
> Bohdan Khomutskyi
> 
> Release Configuration Management engineer
> Red Hat

This looks like an excellent Change, especially as these images grow.

-- 
John M. Harris, Jr.
Splentity

___
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 1787937] New: URLs in documentation are incorrect

[bugzilla]

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

Bug ID: 1787937
   Summary: URLs in documentation are incorrect
   Product: Fedora
   Version: 31
  Hardware: x86_64
OS: Linux
Status: NEW
 Component: perl-Term-ReadLine-Gnu
  Severity: low
  Assignee: emman...@seyman.fr
  Reporter: nchan...@alumni.uwaterloo.ca
QA Contact: extras...@fedoraproject.org
CC: c...@wpi.edu, emman...@seyman.fr, lkund...@v3.sk,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:
URLs in documentation are incorrect

Version-Release number of selected component (if applicable):
rpm -q perl-Term-ReadLine-Gnu
perl-Term-ReadLine-Gnu-1.36-5.fc31.x86_64

How reproducible:
always

Steps to Reproduce:
1. run:  perldoc Term::ReadLine::Gnu
2.
3.

Actual results:
References http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html,
http://cnswww.cns.cwru.edu/php/chet/readline/history.html and
http://cnswww.cns.cwru.edu/php/chet/readline/readline.html, which no longer
connect.

Expected results:
Should reference https://tiswww.case.edu/php/chet/readline/rltop.html,
https://tiswww.case.edu/php/chet/readline/history.html,
https://tiswww.cwru.edu/php/chet/readline/readline.html

Additional info:
-

-- 
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 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

[Chris Murphy]

On Sun, Jan 5, 2020 at 5:24 AM Bohdan Khomutskyi  wrote:
>
> Summary
>
> Improve compression ratio of SquashFS filesystem on the installation media.

On the issues of Fedora ISOs using excessive CPU, related to lzma decompression:
https://bugzilla.redhat.com/show_bug.cgi?id=1717728
https://pagure.io/releng/issue/8581

Create images using plain squashfs (without nested ext4)
https://pagure.io/releng/issue/8646

And koji issue to enhance it so it can accept configurable rootfs
types (plain squashfs and configurable compression)
https://pagure.io/koji/issue/1622

I'm wondering if you can relate this feature proposal to those issues
and feature requests?

In my testing, xz does provide better compression ratios, well suited
for seldom used images like archives. But it really makes the
installation experience worse by soaking the CPU, times thousands of
installations (openQA tests on every single nightly, every human QA
tester for nightlies, betas, and then the final released product used
by Fedora end users).

Has zstandard been evaluated? In my testing of images compressed with
zstd, the CPU hit is cut by more than 50%, and is no longer a
bottleneck during installations. Image size does increase, although I
haven't tested mksquashfs block size higher than 256K. Using zstd with
Fedora images also builds on prior evaluation, testing, and effort
moving RPM from xz to zstd.

My testing with mksquashfs block size suggests compression ratio
improves but latency gets worse, and becomes somewhat pathological
with a nested ext4 in it: my best guess is the random access nature of
ext4, many 4KiB seeks turn into larger 128KiB seeks; and also squashfs
and ext4 probably have different localities (where data is placed in
relation to their metadata, in attempt to optimize). Dropping the
nested ext4 image also improved performance quite a bit, independent
of compression algorithm. I forget how much exactly but it may be
~30%.

I've pretty much concluded Fedora is best off dropping the nested ext4
in favor of plain squashfs, and using zstd. It's not required to do
both, but the benefit is additive and significant. The work in dracut
and lorax to support plain squashfs, assembling it using overlayfs
instead of device-mapper is already done, and tested.

-- 
Chris Murphy
___
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 / bodhi issues status update

[Clement Verna]

On Fri, 3 Jan 2020 at 22:41, Kevin Fenzi  wrote:

> As some of you may know, we have been having issues with koji and bodhi
> over the holidays. :( koji would sometimes not tag builds or error them
> with odd error messages and bodhi wasn't pushing updates.
>
> I'm happy to report that the underlying issue seems to be fixed now.
> We hopefully will have a more detailed root cause next week.
>
> However, due to the koji issues builds were in a state where bodhi
> ejected many of them from updates pushes. We are working on cleaning
> up the state of those updates and there's no need for maintainers to do
> anything with those updates at this time.
>
> Once we get the ejected builds cleaned up we should be able to resume
> normal bodhi updates pushes.
>

Hi all,

I think that we now have dealt with most of the ejected updates. It seems
that there are still a few rawhide updates stuck in pending so I ll be
looking at unblocking these.

Please let us know if you believed that we have missed something.

Thanks


>
> Thanks everyone for your patience on this issue!
>
> kevin
> ___
> 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: Orphaning pykka

[Raphael Groner]

pykka is orphaned again. Please feel free to take it.

Reasons:
https://bugzilla.redhat.com/show_bug.cgi?id=1785943
https://bugzilla.redhat.com/show_bug.cgi?id=1787429
https://src.fedoraproject.org/rpms/pykka/pull-request/2
___
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: 20200105.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200104.n.1
NEW: Fedora-Rawhide-20200105.n.0

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

Size of added packages:  12.91 KiB
Size of dropped packages:879.62 KiB
Size of upgraded packages:   286.18 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   673.83 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-apply-defaults-0.1.4-2.fc32
Summary: Helps pull configuration into a project
RPMs:python3-apply-defaults
Size:12.91 KiB


= DROPPED PACKAGES =
Package: avalon-logkit-2.1-33.fc31
Summary: Java logging toolkit
RPMs:avalon-logkit avalon-logkit-javadoc
Size:185.28 KiB

Package: libee-0.4.1-16.fc31
Summary: Event expression library inspired by CEE
RPMs:libee libee-devel libee-utils
Size:462.27 KiB

Package: maven-deploy-plugin-2.8.2-11.fc31
Summary: Maven Deploy Plugin
RPMs:maven-deploy-plugin maven-deploy-plugin-javadoc
Size:72.04 KiB

Package: maven-war-plugin-3.2.2-5.fc31
Summary: Maven WAR Plugin
RPMs:maven-war-plugin maven-war-plugin-javadoc
Size:160.02 KiB


= UPGRADED PACKAGES =
Package:  debhelper-12.7.3-1.fc32
Old package:  debhelper-12.6.1-1.fc32
Summary:  Helper programs for debian/rules
RPMs: debhelper
Size: 972.21 KiB
Size change:  25.62 KiB
Changelog:
  * Wed Dec 11 2019 Fedora Release Monitoring 
 - 12.7.2-1
  - Update to 12.7.2 (#1763530)

  * Sun Jan 05 2020 S??rgio Basto  - 12.7.3-1
  - Update to 12.7.3 (#1763530)


Package:  gnome-online-accounts-3.35.3-1.fc32
Old package:  gnome-online-accounts-3.35.1-1.fc32
Summary:  Single sign-on framework for GNOME
RPMs: gnome-online-accounts gnome-online-accounts-devel
Size: 3.76 MiB
Size change:  -25.23 KiB
Changelog:
  * Sat Jan 04 2020 Debarshi Ray  - 3.35.3-1
  - Update to 3.35.3


Package:  gtk-gnutella-1.1.15-2.fc32
Old package:  gtk-gnutella-1.1.15-1.fc32
Summary:  GUI based Gnutella Client
RPMs: gtk-gnutella
Size: 78.36 MiB
Size change:  67.43 KiB
Changelog:
  * Fri Jan 03 2020 Dmitry Butskoy  - 1.1.15-2
  - fix startup crash (#1787421)


Package:  icecat-68.4.0-0.2.rc1.rh1.fc32
Old package:  icecat-68.4.0-0.1.rc1.gnu1.fc32
Summary:  GNU version of Firefox browser
RPMs: icecat icecat-x11
Size: 147.89 MiB
Size change:  73.36 KiB
Changelog:
  * Fri Jan 03 2020 Antonio Trande  - 
68.4.0-0.2.rc1.rh1
  - New rebuild of source archive (extensions updated)
  - Use rh prefix instead of gnu


Package:  libgnome-games-support-1.5.90-1.fc32
Old package:  libgnome-games-support-1.4.4-1.fc32
Summary:  Support library for GNOME games
RPMs: libgnome-games-support libgnome-games-support-devel
Size: 457.75 KiB
Size change:  -664 B
Changelog:
  * Sat Jan 04 2020 Yanko Kaneti  - 1.5.90-1
  - Update to 1.5.90. Switch to meson


Package:  librealsense-2.31.0-1.module_f32+7277+8b9b7c96
Old package:  librealsense-2.30.0-1.module_f32+7001+82ff9fe6
Summary:  Cross-platform camera capture for Intel RealSense
RPMs: librealsense librealsense-devel librealsense-doc
Size: 26.68 MiB
Size change:  590.92 KiB
Changelog:
  * Wed Dec 11 2019 Till Hofmann  - 2.31.0-1
  - Update to 2.31.0


Package:  mellowplayer-3.5.8-2.20191227git9fd6cee.fc32
Old package:  mellowplayer-3.5.6-1.20191124git433f80b.fc32
Summary:  Cloud music integration for your desktop
RPMs: mellowplayer mellowplayer-doc
Size: 20.80 MiB
Size change:  3.71 KiB
Changelog:
  * Fri Jan 03 2020 Martin Gansser  - 
3.5.8-1.20191227git9fd6cee
  - Update to 3.5.8-1.20191227git9fd6cee

  * Sat Jan 04 2020 Martin Gansser  - 
3.5.8-2.20191227git9fd6cee
  - Bump version due #8482 Koji build fails with "GenericError: Build already 
in progress"


Package:  perl-Config-AutoConf-0.318-1.fc32
Old package:  perl-Config-AutoConf-0.317-6.fc31
Summary:  A module to implement some of AutoConf macros in pure Perl
RPMs: perl-Config-AutoConf
Size: 49.40 KiB
Size change:  75 B
Changelog:
  * Sun Jan 05 2020 Emmanuel Seyman  - 0.318-1
  - Update to 0.318
  - Add perl(File::Slurper) as a dependency
  - Use /usr/bin/perl instead of perl
  - Use %{make_install} instead of make pure_install
  - Use %{make_build} instead of make


Package:  perl-DBIx-Class-Helpers-2.034002-1.fc32
Old package:  perl-DBIx-Class-Helpers-2.034001-1.fc32
Summary:  A collection of various components for DBIx::Class
RPMs: perl-DBIx-Class-Helpers
Size: 205.88 KiB
Size change:  263 B
Changelog:
  * Sun Jan 05 2020 Emmanuel Seyman  - 2.034002-1
  - Update to 2.034002


Package:  pspg-2.6.4-1.fc32
Old package:  pspg-2.6.1-1.fc32
Summary:  A unix pager optimized for psql
RPMs: pspg
Size: 458.65 KiB
Size change:

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

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/155 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20200104.n.1):

ID: 507040  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/507040
ID: 507043  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/507043
ID: 507097  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/507097
ID: 507175  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/507175

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

ID: 507057  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/507057
ID: 507059  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/507059
ID: 507112  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/507112
ID: 507120  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/507120
ID: 507190  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/507190

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

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

ID: 507038  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/507038
ID: 507039  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/507039
ID: 507044  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/507044
ID: 507045  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/507045
ID: 507046  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/507046
ID: 507047  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/507047
ID: 507048  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/507048
ID: 507049  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/507049
ID: 507051  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/507051
ID: 507052  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/507052
ID: 507063  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/507063
ID: 507068  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/507068
ID: 507071  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/507071
ID: 507077  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/507077
ID: 507078  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/507078
ID: 507086  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/507086
ID: 507091  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/507091
ID: 507114  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/507114
ID: 507115  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/507115
ID: 507116  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/507116
ID: 507117  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/507117
ID: 507118  Test: x86_64 universal install_shrink_ext4
URL: https://openqa.fedoraproject.org/tests/507118
ID: 507121  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/507121
ID: 507122  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/507122
ID: 507123  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/507123
ID: 507124  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/507124
ID: 507125  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/507125
ID: 507127  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/507127
ID: 507128  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/507128
ID: 507129  Test: x86_64 universal install_delete_partial@uefi
URL: https://openqa.fedoraproject.org/tests/507129
ID: 507131  Test: x86_64 universal 

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 05, 2020 at 12:29:40PM +0100, Aleksandra Fedorova wrote:
> On Sun, Jan 5, 2020 at 10:18 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova  
> > > wrote:
> > >
> > > > Since in the Change we are not introducing just the earlyoom tool but 
> > > > enable it with a specific profile I would add those details here. Smth 
> > > > like:
> > > >
> > > > "earlyoom service will choose the offending process based on the same 
> > > > oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM 
> > > > left, and SIGKILL on 5%"
> > >
> > > I add this information to the summary. Also, I think these numbers may
> > > need to change to avoid prematurely sending SIGTERM when the system
> > > has no swap device.
> > >
> > > > As I understand in the current setup we are looking more for a 
> > > > controlled failure scenario rather than for a solution.
> > >
> > > Yes, it's fair to say this proposal is to make things "less bad". It
> > > doesn't improve system responsiveness. Once heavy swap starts, the
> > > system is sluggish, stutters, and briefly stalls. This proposal
> > > doesn't fix that. There is a lot of room for improvement.
> > >
> > >
> > > > Can we get a specific manual, what users supposed to do, once they 
> > > > trigger the earlyoom? Does earlyoom help in reporting? Which logs we 
> > > > need to look at?
> > > >
> > > > Maybe add a section in UX part of the change, or setup a dedicated wiki 
> > > > page?
> > >
> > > The user shouldn't need to do anything differently than if the kernel
> > > oom-killer had triggered. The system journal will contain messages
> > > showing what was killed and why:
> > >
> > > Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below
> > > SIGTERM limits: mem 10 %, swap 10 %
> > > Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process
> > > 27421 "chrome": badness 305, VmRSS 42 MiB
> > >
> > >
> > > > Additionally, there was a question during the chat discussion: how the 
> > > > earlyoom setup will work together with OOMPolicy and any other related 
> > > > options of systemd units? Will systemd recognize the OOM event?
> > >
> > > My understanding of systemd OOMPolicy= behavior, is it looks for the
> > > kernel's oom-killer messages and acts upon those. Whereas earlyoom
> > > uses the same metric (oom_score) as the oom-killer, it does not invoke
> > > the oom-killer. Therefore systemd probably does not get the proper
> > > hint to implement OOMPolicy=
> >
> > Yes. The kernel reports oom events in the cgroup file memory.events,
> > and systemd waits for an inotify event on that file; OOMPolicy=stop is
> > implemented that way. And the OOMPolicy=kill option is "implemented"
> > by setting memory.oom.group=1 in the kernel [1] and having the kernel
> > kill all the processes. So systemd is providing a thin wrapper around
> > the kernel functionality.
> >
> > If processes are not killed by the kernel but through a signal from
> > userspace, all of this will not work.
> 
> I grepped /usr/lib/systemd and /etc/systemd for "OOM" on my
> workstation and it seems that we have only OOMScoreAdjust option used
> in the installed systemd units. And this option will be respected by
> earlyoom.
> 
> Since on workstation we don't use tweaking of the OOMPolicy on the
> unit level, I'd say we can leave the tweaking to the system
> administrators: when there is need to adjust OOMPolicy of a service,
> administrators would need to tweak or disable earlyoom service as
> well.

Having "conflicts" between things, in the sense that using one feature
means that another feature needs to be disabled, is always an option.
But it's never a very good option. I think that it isn't too important
to keep OOMPolicy= working, since its a new and relatively unused thing.
Nevertheless, it would be nice to find a way to avoid this and
support both features at the same time. This thread 'til now is mostly
about establishing whether there really is a conflict (it seems yes)
and whether there is some easy way to avoid it (not sure yet...). I
think we should explore that before settling on the easy but suboptimal
answer.

> But I'd like to understand better the difference between _default_
> OOM-event and _default_ earlyoom-event:
> 
> Afaik DefaultOOMPolicy is set to "stop", which means if one of the
> processes in the service is killed by OOM, other processes from the
> same service are gracefully stopped by systemd.
> 
> What is the default behavior of the systemd service on external
> SIGTERM/SIGKILL signal sent to the process by earlyoom?

It depends on which of the processes is killed. If the main process
is killed with SIGTERM, systemd kill consider this a normal successful 
termination.
If the main process is killed with SIGKILL, systemd will consider this a 
failure.
(Both of those cases modified by SuccessExitStatus=.)
If some random subprocess 

Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

[Bohdan Khomutskyi]

 Summary

Improve compression ratio of SquashFS filesystem on the installation media.
Owner

Name: Bohdan Khomutskyi

Email: bkhom...@redhat.com
Current status

Targeted release: I propose this change for Fedora 32

Last updated: Jan 5 2020

Pagure.io issue: https://pagure.io/releng/issue/9127

I was unable to create an article in Fedora wiki system.
Detailed Description

As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is
compressed with default settings of mksquashfs. The standard configuration
is set to XZ algorithm with block size of 128k and BCJ filter enabled.
Those parameters can be adjusted which will lead to a better compression
ratio and/or reduction of the CPU usage at build time.

This is simple to achieve. Recently, Lorax has gotten support[1] for
adjusting the compression options for mksquashfs via the configuration
file. The file should be altered as following:

[compression]
bcj = yes
args = -b 1M -Xdict-size 1M -no-recovery

Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively.
Could be adjusted.
Benefit to Fedora

   -

   Reduction of the installation media size and the cost of storing and
   distributing Fedora.
   -

   Reduction of the CPU usage at build time. Depending on which compression
   parameters chosen.
   -

   See a graphical detail at https://pagure.io/releng/issue/9127.

Scope

   -

   Proposal owners:

The build environment should have support for adjusting the Lorax
configuration file.. Lorax is a program that produces the
LiveOS/squashfs.img file on the installation media.

One of the way to allow for such customization, is to add a feature in
Pungi, to allow for passing -c option to Lorax.

   -

   Release engineering: #9127 
   -

   Policies and guidelines: N/A
   -

   Trademark approval: N/A

Upgrade/compatibility impact

   -

   This change comes at a cost of higher memory usage during the
   installation. Based on my personal estimations, this should not be the
   issue. Since the decompression should require up to 1MiB per thread.

User Experience

   -

   Increasing the block size on the current configuration with EXT4 file
   system, should increase latency while accessing the EXT4 filesystem. The
   exact impact is to be evaluated.
   -

   The impact of latency will be reduced, if the plain SquashFS option is
   be choosen.

Dependencies

   -

   N/A

Contingency Plan

   -

   N/A

Documentation
https://pagure.io/releng/issue/9127.

mksquashfs(1)
Release notes See also

https://pagure.io/releng/issue/8646

--

Bohdan Khomutskyi

Release Configuration Management engineer
Red Hat


Proposed change -- Improve the compression ration of squashfs.img.pdf
Description: Adobe PDF document
___
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 32 System-Wide Change proposal (late): Enable EarlyOOM

[Aleksandra Fedorova]

On Sun, Jan 5, 2020 at 12:39 AM Chris Murphy  wrote:
>
> On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova  wrote:
>
> > Since in the Change we are not introducing just the earlyoom tool but 
> > enable it with a specific profile I would add those details here. Smth like:
> >
> > "earlyoom service will choose the offending process based on the same 
> > oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM left, 
> > and SIGKILL on 5%"
>
> I add this information to the summary. Also, I think these numbers may
> need to change to avoid prematurely sending SIGTERM when the system
> has no swap device.
>
> > As I understand in the current setup we are looking more for a controlled 
> > failure scenario rather than for a solution.
>
> Yes, it's fair to say this proposal is to make things "less bad". It
> doesn't improve system responsiveness. Once heavy swap starts, the
> system is sluggish, stutters, and briefly stalls. This proposal
> doesn't fix that. There is a lot of room for improvement.
>
>
> > Can we get a specific manual, what users supposed to do, once they trigger 
> > the earlyoom? Does earlyoom help in reporting? Which logs we need to look 
> > at?
> >
> > Maybe add a section in UX part of the change, or setup a dedicated wiki 
> > page?
>
> The user shouldn't need to do anything differently than if the kernel
> oom-killer had triggered. The system journal will contain messages
> showing what was killed and why:
>
> Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below
> SIGTERM limits: mem 10 %, swap 10 %
> Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process
> 27421 "chrome": badness 305, VmRSS 42 MiB
>

I wonder, how I as a user going to be informed about the
earlyoom-event? I assume abrt will recognize the crash? Will it be
easily visible from the abrt report that it was the OOM?

The concern is: if we enable such a service, will we get large amount
of vague bug reports from users who don't understand what has
happened. Can we make it somehow easier to debug?

> > Additionally, there was a question during the chat discussion: how the 
> > earlyoom setup will work together with OOMPolicy and any other related 
> > options of systemd units? Will systemd recognize the OOM event?
>
> My understanding of systemd OOMPolicy= behavior, is it looks for the
> kernel's oom-killer messages and acts upon those. Whereas earlyoom
> uses the same metric (oom_score) as the oom-killer, it does not invoke
> the oom-killer. Therefore systemd probably does not get the proper
> hint to implement OOMPolicy=
>
> Fedora need to discuss how big of a problem that is, if there's anyway
> to mitigate it, or tolerate it, weighing the pros of earlyoom for a
> short period, versus the cons of punting this problem for another
> release. This proposal does not intend to step on other superseding
> work in this area, but if it does, it'll be withdrawn.
>
>
> --
> Chris Murphy
> ___
> 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

-- 
Aleksandra Fedorova
bookwar
___
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: lv2-sorcer is not installable

[Guido Aulisi]

Il giorno dom, 05/01/2020 alle 12.21 +0100, Miro Hrončok ha scritto:
> On 03. 01. 20 19:24, Kevin Kofler wrote:
> > Zbigniew Jędrzejewski-Szmek wrote:
> > > The dep was provided by non-ntk, which got retired about half a
> > > year
> > > ago [1] after FTBFSing since F29 [2].
> > 
> > Isn't it great when the policy designed to
> > remove
> > breakage from the distribution actually CREATES breakage? Retiring
> > packages
> > with no regards to their reverse dependencies is just broken. It
> > had never
> > been done that way in the past, before Miro's recent crackdown,
> > because it
> > simply defeats all common sense.
> 
> As a matter of fact, the policy was changed recently, so depending
> package 
> maintainers MUST get notifications. The Fedora 31 round was
> unfortunate, mostly 
> because nobody got properly notified. I have devoted a great amount
> of energy 
> and time to make it better for next rounds. I hope it worked. Only
> couple of 
> packages are to be retired, where the maintainers simply don't care
> anymore with 
> only one dependent package:
> 
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/YRLNHZSV4U47A3MDWIU6MUANVMPEFKD2/
> 
> For the F31 crackdown - it's not like a retired package cannot ever
> be 
> unretired. It has been more than 8 weeks now, but I gladly re-review
> a package 
> that got retired, if new maintainers pop up. Unlike you, I actually
> believe 
> packages must be maintained in order to be kept.

I'm working for unretiring non-ntk, I think I can file a new review
request in one week, as soon as I come back home; I'm already working
on it.

> The solution is not to stop orphaning/retiring FTBFS packages, the
> solution is 
> to get "broken deps" notifications working again:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBV3UTSPIGW3TOZJSYTXCZMRV4QBR7X5/

Ciao
Guido

FAS: tartina


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

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Aleksandra Fedorova]

On Sun, Jan 5, 2020 at 10:18 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> > On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova  
> > wrote:
> >
> > > Since in the Change we are not introducing just the earlyoom tool but 
> > > enable it with a specific profile I would add those details here. Smth 
> > > like:
> > >
> > > "earlyoom service will choose the offending process based on the same 
> > > oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM 
> > > left, and SIGKILL on 5%"
> >
> > I add this information to the summary. Also, I think these numbers may
> > need to change to avoid prematurely sending SIGTERM when the system
> > has no swap device.
> >
> > > As I understand in the current setup we are looking more for a controlled 
> > > failure scenario rather than for a solution.
> >
> > Yes, it's fair to say this proposal is to make things "less bad". It
> > doesn't improve system responsiveness. Once heavy swap starts, the
> > system is sluggish, stutters, and briefly stalls. This proposal
> > doesn't fix that. There is a lot of room for improvement.
> >
> >
> > > Can we get a specific manual, what users supposed to do, once they 
> > > trigger the earlyoom? Does earlyoom help in reporting? Which logs we need 
> > > to look at?
> > >
> > > Maybe add a section in UX part of the change, or setup a dedicated wiki 
> > > page?
> >
> > The user shouldn't need to do anything differently than if the kernel
> > oom-killer had triggered. The system journal will contain messages
> > showing what was killed and why:
> >
> > Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below
> > SIGTERM limits: mem 10 %, swap 10 %
> > Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process
> > 27421 "chrome": badness 305, VmRSS 42 MiB
> >
> >
> > > Additionally, there was a question during the chat discussion: how the 
> > > earlyoom setup will work together with OOMPolicy and any other related 
> > > options of systemd units? Will systemd recognize the OOM event?
> >
> > My understanding of systemd OOMPolicy= behavior, is it looks for the
> > kernel's oom-killer messages and acts upon those. Whereas earlyoom
> > uses the same metric (oom_score) as the oom-killer, it does not invoke
> > the oom-killer. Therefore systemd probably does not get the proper
> > hint to implement OOMPolicy=
>
> Yes. The kernel reports oom events in the cgroup file memory.events,
> and systemd waits for an inotify event on that file; OOMPolicy=stop is
> implemented that way. And the OOMPolicy=kill option is "implemented"
> by setting memory.oom.group=1 in the kernel [1] and having the kernel
> kill all the processes. So systemd is providing a thin wrapper around
> the kernel functionality.
>
> If processes are not killed by the kernel but through a signal from
> userspace, all of this will not work.

I grepped /usr/lib/systemd and /etc/systemd for "OOM" on my
workstation and it seems that we have only OOMScoreAdjust option used
in the installed systemd units. And this option will be respected by
earlyoom.

Since on workstation we don't use tweaking of the OOMPolicy on the
unit level, I'd say we can leave the tweaking to the system
administrators: when there is need to adjust OOMPolicy of a service,
administrators would need to tweak or disable earlyoom service as
well.

But I'd like to understand better the difference between _default_
OOM-event and _default_ earlyoom-event:

Afaik DefaultOOMPolicy is set to "stop", which means if one of the
processes in the service is killed by OOM, other processes from the
same service are gracefully stopped by systemd.

What is the default behavior of the systemd service on external
SIGTERM/SIGKILL signal sent to the process by earlyoom?

> [1] 
> https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files
>
> Zbyszek
>

-- 
Aleksandra Fedorova
bookwar
___
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: lv2-sorcer is not installable

[Miro Hrončok]

On 03. 01. 20 19:24, Kevin Kofler wrote:

Zbigniew Jędrzejewski-Szmek wrote:

The dep was provided by non-ntk, which got retired about half a year
ago [1] after FTBFSing since F29 [2].


Isn't it great when the policy designed to remove
breakage from the distribution actually CREATES breakage? Retiring packages
with no regards to their reverse dependencies is just broken. It had never
been done that way in the past, before Miro's recent crackdown, because it
simply defeats all common sense.


As a matter of fact, the policy was changed recently, so depending package 
maintainers MUST get notifications. The Fedora 31 round was unfortunate, mostly 
because nobody got properly notified. I have devoted a great amount of energy 
and time to make it better for next rounds. I hope it worked. Only couple of 
packages are to be retired, where the maintainers simply don't care anymore with 
only one dependent package:


https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/YRLNHZSV4U47A3MDWIU6MUANVMPEFKD2/

For the F31 crackdown - it's not like a retired package cannot ever be 
unretired. It has been more than 8 weeks now, but I gladly re-review a package 
that got retired, if new maintainers pop up. Unlike you, I actually believe 
packages must be maintained in order to be kept.


The solution is not to stop orphaning/retiring FTBFS packages, the solution is 
to get "broken deps" notifications working again:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBV3UTSPIGW3TOZJSYTXCZMRV4QBR7X5/

--
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: koji / bodhi issues status update

[Mattia Verga via devel]

Il 05/01/20 10:54, Pierre-Yves Chibon ha scritto:
>
> You may also want to print/check when these updates were created, I suspect a
> number of them may be older than this outage.
>
> Also, this has been problematic in the past but since bodhi now simply ignores
> these updates when doing the compose. Thus today while it's not pretty it 
> should
> do no harm (famous last word ;-)).
>
>
Yes, nearly a half of those are really old and already unpushed / 
obsoleted. Maybe, just to get things clean, those that are still in 
pending state should be manually obsoleted in a bodhi-shell (unpushing 
them is not possible).


2015-08-20 08:37:19.495922   FEDORA-2015-13799 obsolete    jgrulich
2015-09-25 20:35:34.512748   FEDORA-2015-f7d2f6b77c obsolete    
plfiorini
2015-09-25 21:02:48.955655   FEDORA-2015-fde9b8aa65 obsolete    
plfiorini
2015-11-13 18:43:20.013465   FEDORA-2015-084442a526 obsolete    spot
2015-11-13 18:43:22.064515   FEDORA-2015-3933d6e71b obsolete    spot
2015-11-22 20:06:43.820739   FEDORA-EPEL-2015-56f1789544 
unpushed    raveit65
2015-11-27 17:22:03.244153   FEDORA-2015-8312a1422c obsolete    
sergiomb
2015-12-10 15:50:59.944428   FEDORA-EPEL-2015-2d0e7de56f 
pending orion
2016-01-15 22:11:41.776291   FEDORA-2016-52e09c8358 obsolete    
raphgro
2016-01-21 21:58:28.957802   FEDORA-EPEL-2016-0bc504f81d 
pending nb
2016-02-06 20:53:49.323746   FEDORA-2016-3745a3404a obsolete    
mrnuke
2016-02-06 20:57:03.050273   FEDORA-2016-9683e48c38 obsolete    
mrnuke
2016-02-12 14:14:52.259339   FEDORA-2016-19d7f3d798 obsolete    
mrnuke
2016-02-13 18:40:20.292308   FEDORA-2016-2f3052d543 obsolete    
mrnuke
2016-03-02 10:30:03.998425   FEDORA-2016-796de36de3 obsolete    
raphgro
2016-03-15 18:20:12.670818   FEDORA-2016-3122ec6414 unpushed    
adelton
2017-12-11 11:41:11.371385   FEDORA-2017-37b618a185 unpushed    
wtaymans
2019-08-14 00:10:47.551091   FEDORA-2019-48c30c6663 pending jhli
2019-08-14 00:10:49.918659   FEDORA-2019-1cfe355806 obsolete    jhli
2019-08-31 07:33:41.603000   FEDORA-2019-2268266d31 pending 
ellert
2019-08-31 07:33:43.431370   FEDORA-EPEL-2019-d119182890 
pending ellert
2019-08-31 07:33:47.607875   FEDORA-2019-bef5c0c3c8 pending 
ellert
2019-08-31 07:33:49.760607   FEDORA-EPEL-2019-0a394e5d23 
pending ellert
2019-08-31 07:33:54.051686   FEDORA-EPEL-2019-e6890f4861 
pending ellert
2019-08-31 07:33:59.602901   FEDORA-2019-1a9f460ddf obsolete    
ellert
2019-09-05 18:24:25.204057   FEDORA-2019-0afb6633c8 obsolete    atim
2019-09-30 13:12:02.178732   FEDORA-2019-39027b3336 pending remi
2019-10-01 13:42:52.471356   FEDORA-2019-240ae9127c pending 
jgrulich
2019-10-01 13:42:59.209092   FEDORA-2019-521db81bfa pending 
jgrulich
2019-10-01 13:43:40.458556   FEDORA-2019-3b596e447b pending 
jgrulich
2019-10-01 13:43:42.808549   FEDORA-2019-e89227ba40 pending 
jgrulich
2019-10-17 07:01:46.878390   FEDORA-2019-12ed3b8473 pending remi
2019-10-30 02:26:41.170270   FEDORA-2019-98ef2a04fc pending 
jjames
2019-10-30 02:26:41.859672   FEDORA-2019-f57b34f7a0 pending 
jjames
2019-11-01 16:29:48.978780   FEDORA-2019-110533d946 pending 
panovotn

2019-12-28 21:39:38.811084   FEDORA-2019-3875c36a14 pending 
eclipseo


___
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 / bodhi issues status update

[Pierre-Yves Chibon]

On Sat, Jan 04, 2020 at 09:37:04AM -, Mattia Verga via devel wrote:
> > On Fri, Jan 03, 2020 at 11:55:27PM +0100, Kevin Kofler wrote:
> > 
> > Yes, they are all because bodhi started composing them, moved their tags
> > and then failed (because koji wasn't tagging things in a timely manner). 
> > 
> > So, they need to be retagged back and resubmitted, or bodhi tweaked to
> > see that it's already moved tags and continue processing them. 
> > 
> > In any case, we plan to do this, so if maintainers could please avoid
> > editing/pushing/unpushing/tweaking or moving these around while we try
> > and fix it that would be great. 
> > 
> > kevin
> 
> There are also a bunch of broken updates in Bodhi which were created without 
> any build. Here it is a list of aliases:
> >>> updates = m.Update.query.filter(m.Update.builds==None).all()
> >>> len(updates)
> 36
> >>> for update in updates:
> ... print(f'{update.alias} created by {update.user.name}')

You may also want to print/check when these updates were created, I suspect a
number of them may be older than this outage.

Also, this has been problematic in the past but since bodhi now simply ignores
these updates when doing the compose. Thus today while it's not pretty it should
do no harm (famous last word ;-)).


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

[Bug 1787839] perl-Filesys-Notify-Simple-0.14 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Filesys-Notify-Simple-0.14-1.fc29.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=40137429

-- 
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 1787883] New: perl-podlators-4.14 is available

[bugzilla]

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

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



Latest upstream release: 4.14
Current version/release in rawhide: 4.13-1.fc32
URL: http://search.cpan.org/dist/podlators/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

-- 
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 1655461] w3c-markup-validator-20.1.2 is available

[bugzilla]

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



--- Comment #7 from Upstream Release Monitoring 
 ---
The following Sources of the specfile are not valid URLs so we cannot
automatically build the new version for you.  Please use URLs in your Source
declarations if possible.

- w3c-markup-validator-20.1.2.tar.xz
- w3c-markup-validator-prepare-tarball.sh

-- 
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 1655461] w3c-markup-validator-20.1.2 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|w3c-markup-validator-19.5.0 |w3c-markup-validator-20.1.2
   |is available|is available



--- Comment #6 from Upstream Release Monitoring 
 ---
Latest upstream release: 20.1.2
Current version/release in rawhide: 1.3-17.fc31
URL: https://validator.github.io/validator/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

-- 
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 32 System-Wide Change proposal (late): Enable EarlyOOM

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 04, 2020 at 04:38:19PM -0700, Chris Murphy wrote:
> On Sat, Jan 4, 2020 at 2:51 AM Aleksandra Fedorova  wrote:
> 
> > Since in the Change we are not introducing just the earlyoom tool but 
> > enable it with a specific profile I would add those details here. Smth like:
> >
> > "earlyoom service will choose the offending process based on the same 
> > oom_score as kernel uses. It will send a SIGTERM signal on 10% of RAM left, 
> > and SIGKILL on 5%"
> 
> I add this information to the summary. Also, I think these numbers may
> need to change to avoid prematurely sending SIGTERM when the system
> has no swap device.
> 
> > As I understand in the current setup we are looking more for a controlled 
> > failure scenario rather than for a solution.
> 
> Yes, it's fair to say this proposal is to make things "less bad". It
> doesn't improve system responsiveness. Once heavy swap starts, the
> system is sluggish, stutters, and briefly stalls. This proposal
> doesn't fix that. There is a lot of room for improvement.
> 
> 
> > Can we get a specific manual, what users supposed to do, once they trigger 
> > the earlyoom? Does earlyoom help in reporting? Which logs we need to look 
> > at?
> >
> > Maybe add a section in UX part of the change, or setup a dedicated wiki 
> > page?
> 
> The user shouldn't need to do anything differently than if the kernel
> oom-killer had triggered. The system journal will contain messages
> showing what was killed and why:
> 
> Jan 04 16:05:42 fmac.local earlyoom[4896]: low memory! at or below
> SIGTERM limits: mem 10 %, swap 10 %
> Jan 04 16:05:42 fmac.local earlyoom[4896]: sending SIGTERM to process
> 27421 "chrome": badness 305, VmRSS 42 MiB
> 
> 
> > Additionally, there was a question during the chat discussion: how the 
> > earlyoom setup will work together with OOMPolicy and any other related 
> > options of systemd units? Will systemd recognize the OOM event?
> 
> My understanding of systemd OOMPolicy= behavior, is it looks for the
> kernel's oom-killer messages and acts upon those. Whereas earlyoom
> uses the same metric (oom_score) as the oom-killer, it does not invoke
> the oom-killer. Therefore systemd probably does not get the proper
> hint to implement OOMPolicy=

Yes. The kernel reports oom events in the cgroup file memory.events,
and systemd waits for an inotify event on that file; OOMPolicy=stop is
implemented that way. And the OOMPolicy=kill option is "implemented"
by setting memory.oom.group=1 in the kernel [1] and having the kernel
kill all the processes. So systemd is providing a thin wrapper around
the kernel functionality.

If processes are not killed by the kernel but through a signal from
userspace, all of this will not work.

[1] 
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files

Zbyszek

> Fedora need to discuss how big of a problem that is, if there's anyway
> to mitigate it, or tolerate it, weighing the pros of earlyoom for a
> short period, versus the cons of punting this problem for another
> release. This proposal does not intend to step on other superseding
> work in this area, but if it does, it'll be withdrawn.
___
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 1787839] perl-Filesys-Notify-Simple-0.14 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1649912
  --> https://bugzilla.redhat.com/attachment.cgi?id=1649912=edit
[patch] Update to 0.14 (#1787839)

-- 
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 1787839] New: perl-Filesys-Notify-Simple-0.14 is available

[bugzilla]

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

Bug ID: 1787839
   Summary: perl-Filesys-Notify-Simple-0.14 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Filesys-Notify-Simple
  Keywords: FutureFeature, Triaged
  Assignee: robinlee.s...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org,
robinlee.s...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.14
Current version/release in rawhide: 0.13-7.fc31
URL: http://search.cpan.org/dist/Filesys-Notify-Simple/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

-- 
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 1787782] perl-DBD-Mock-1.55 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
One or more of the new sources for this package are identical to the old
sources. It's likely this package does not use the version macro in its Source
URLs. If possible, please update the specfile to include the version macro in
the Source URLs

-- 
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 1787782] New: perl-DBD-Mock-1.55 is available

[bugzilla]

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

Bug ID: 1787782
   Summary: perl-DBD-Mock-1.55 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-Mock
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jakub.jedel...@gmail.com, jan.pra...@gmail.com,
lkund...@v3.sk, perl-devel@lists.fedoraproject.org,
ppi...@redhat.com, tjczep...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.55
Current version/release in rawhide: 1.53-1.fc32
URL: http://search.cpan.org/dist/DBD-Mock/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy


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


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


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

-- 
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: lv2-sorcer is not installable

[Zbigniew Jędrzejewski-Szmek]

On Sat, Jan 04, 2020 at 12:48:21AM +0100, Kevin Kofler wrote:
> Fabio Valentini wrote:
> > Don't blame Miro for doing the necessary things, just because you don't
> > like the process.
> 
> The issue is that I do not agree that this process is necessary to begin 
> with.
> 
> > We have asked you multiple times to suggest a policy that works for you
> > too, but you haven't done that,
> 
> I have. The policy that I have suggested is to just do nothing. FTBFS by 
> itself has no impact whatsoever on end users. Only if the package actually 
> does not install and/or run, it is appropriate to file a bug, and if that 
> bug is not acted upon and cannot be easily fixed by a provenpackager due to 
> the FTBFS, to initiate the (existing) non-responsive maintainer policy.

Fine. You have created a proposal now. The idea of doing nothing has
been discussed, and rejected. A bunch of various processes has been
discussed, one of them accepted by FESCo. Despite many different
opinions about the best procedure, one thing that everybody seemed to
agree on was that *something* needs to be done. So yeah, the idea of doing
*nothing* was rejected by the tech governance body of Fedora, duly elected
according to our rules.

You keep saying stuff like "Miro's crackdown", as if it was one
person's whim to do this. It is not. It is the official Fedora policy,
see previous paragraph. And yes, this comes very close to being an
attack on the person. If you don't like the policy, convince enough
community members to vote differently and change the policy.

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