date:20201118

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20201118.0):

ID: 725030  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/725030
ID: 725037  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/725037

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

[Bug 1899357] perl-Convert-Binary-C-0.81 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC|al...@users.sourceforge.net |
   Fixed In Version||perl-Convert-Binary-C-0.81-
   ||1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-19 06:39:36




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

[Bug 1899180] perl-PAR-Dist-0.50 is available

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



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

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


-- 
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 1899180] perl-PAR-Dist-0.50 is available

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



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


-- 
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 1899180] perl-PAR-Dist-0.50 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PAR-Dist-0.50-1.fc34




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

License change: R-vctrs GPLv3 -> MIT

2020-11-18 Thread Elliott Sales de Andrade

See title. I will only be updating in F33+.

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

f33/f34 amdgpu firmware for 6800/6900

2020-11-18 Thread David Airlie

I've packaged up the firmware for the new AMD GPUs in linux-firmware
in updates-testing. I doubt anyone will have access to one of these
cards for a few weeks anyways, but if somene does end up with one,
please see how it fairs.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-ff2b09cd0a

Dave.
___
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] Fedora EPEL 8 updates-testing report

2020-11-18 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2aa68c5f5e   
tor-0.4.3.7-1.el8
   6  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-317c124dc0   
rpki-client-6.8p1-1.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c93c61069   
pngcheck-2.4.0-2.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3000c1eea   
seamonkey-2.53.5-2.el8
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b5debb24b   
chromium-86.0.4240.198-1.el8


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

psutils-2.04-1.el8
python-curtsies-0.3.4-2.el8
python-managesieve-0.6-4.el8
python-pyemby-1.6-1.el8
python-pynuvo-0.2-1.el8
python-rangeparser-0.1.3-2.el8
python-waqiasync-1.0.0-1.el8
rubberband-1.9.0-1.el8
xpra-4.0.5-2.el8
xrootd-5.0.3-2.el8

Details about builds:



 psutils-2.04-1.el8 (FEDORA-EPEL-2020-0ae0b74db2)
 PostScript utilities

Update Information:

This release fixes handling a paper size when parsing an offset. It also fixes a
warning about an undefined variable.

ChangeLog:

* Wed Nov 18 2020 Petr Pisar  - 2.04-1
- 2.04 bump

References:

  [ 1 ] Bug #1898868 - psutils-2.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1898868




 python-curtsies-0.3.4-2.el8 (FEDORA-EPEL-2020-a095e0e62d)
 Curses-like terminal wrapper, with colored strings

Update Information:

Initial build for EPEL 8

ChangeLog:


References:

  [ 1 ] Bug #1782780 - RFE - please build a python(3)-curtsies package for EPEL 
8
https://bugzilla.redhat.com/show_bug.cgi?id=1782780




 python-managesieve-0.6-4.el8 (FEDORA-EPEL-2020-09d5da6037)
 Accessing a Sieve-Server for managing Sieve scripts

Update Information:

Initial release of package

ChangeLog:


References:

  [ 1 ] Bug #1892756 - Review Request: python-managesieve - Accessing a 
Sieve-Server for managing Sieve scripts
https://bugzilla.redhat.com/show_bug.cgi?id=1892756




 python-pyemby-1.6-1.el8 (FEDORA-EPEL-2020-31bd190097)
 Python module to interact with a Emby media server

Update Information:

Initial package for Fedora

ChangeLog:





 python-pynuvo-0.2-1.el8 (FEDORA-EPEL-2020-eece3260c1)
 Python API for talking to Nuvo multi zone amplifier

Update Information:

Initial package for Fedora

ChangeLog:





 python-rangeparser-0.1.3-2.el8 (FEDORA-EPEL-2020-3c89d630f8)
 Parses a list of ranges or numbers

Update Information:

Update summary (#1888981)

ChangeLog:





 python-waqiasync-1.0.0-1.el8 (FEDORA-EPEL-2020-8b794af0b7)
 Python API for aqicn.org

Update Information:

Initial

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

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



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

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


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

Re: Two questions on updates

2020-11-18 Thread Kevin Kofler via devel

Fabio Valentini wrote:
> You are kinda right, yet you are not.
> The minimum for *autokarma* is +1 for normal updates, +2 for critpath
> updates. But the message "This update can be pushed to stable if the
> maintainer wishes" does not refer to autokarma (update getting pushed
> automatically by bodhi after getting the necessary karma), but to
> maintainers pushing an update *manually* - which is *always* allowed
> for updates that got at least +2 karma, and is independent from
> "autokarma".

Well, for my updates, I normally disable autopush *and* set the stable 
threshold to 1 (why would I want it set any higher? With manual push, I can 
still decide to wait for more feedback if the +1 does not convince me, I do 
not need Bodhi to enforce that for me), and then Bodhi correctly gives me 
that "This update can be pushed to stable if the maintainer wishes" 
notification when the update gets +1 karma (unless this regressed recently).

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

[Bug 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #36 from Fedora Update System  ---
FEDORA-2020-503b26ba4f 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-503b26ba4f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-503b26ba4f

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


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

[Bug 1883530] Add perl-Curses-UI to EPEL8

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-11-19 00:30:18



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


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

[Bug 1890598] EPEL8 Request: perl-Prima

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



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


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

[Bug 1893424] perl-Prima-1.60 is available

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



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


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

Fedora 33 elections voting now open

2020-11-18 Thread Ben Cotton

Voting in the Fedora 33 elections is now open. Go to the Elections app
to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 3
December. Don't forget to claim your "I Voted" badge when you cast
your ballot. Links to candidate interviews are in the Elections app
and on the
Community Blog[2].

[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/fedora-33-elections-voting-now-open/

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

Fedora 33 elections voting now open

2020-11-18 Thread Ben Cotton

Voting in the Fedora 33 elections is now open. Go to the Elections app
to cast[1] your vote. Voting closes at 23:59 UTC on Thursday 3
December. Don't forget to claim your "I Voted" badge when you cast
your ballot. Links to candidate interviews are in the Elections app
and on the
Community Blog[2].

[1] https://elections.fedoraproject.org/
[2] https://communityblog.fedoraproject.org/fedora-33-elections-voting-now-open/

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

[Bug 1899357] New: perl-Convert-Binary-C-0.81 is available

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

Bug ID: 1899357
   Summary: perl-Convert-Binary-C-0.81 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Convert-Binary-C
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@users.sourceforge.net, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.81
Current version/release in rawhide: 0.80-1.fc34
URL: http://search.cpan.org/dist/Convert-Binary-C/

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


-- 
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: Two questions on updates

2020-11-18 Thread Jerry James

On Wed, Nov 18, 2020 at 3:47 PM Kevin Fenzi  wrote:
> HUmf. I also tried without much luck... (and I unpushed it as part of
> that, sorry for that).

No problem.  Thank you for trying.

> Can you file a releng ticket on this and we can at the very least dig
> into the database and fix it that way. ;(

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

Regards,
-- 
Jerry James
http://www.jamezone.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: Two questions on updates

2020-11-18 Thread Kevin Fenzi

On Wed, Nov 18, 2020 at 11:05:04AM -0700, Jerry James wrote:
> On Wed, Nov 18, 2020 at 10:56 AM Mattia Verga via devel
>  wrote:
> > Yeah, that's another Bodhi webUI bug (fixed in devel, but not yet
> > available in prod).
> >
> > To update the builds list of a side-tag update you can use the CLI:
> > `bodhi updates edit --from-tag= `
> >
> > Try that...
> 
> $ bodhi updates edit --from-tag=f33-build-side-33909 FEDORA-2020-f16abf2fb5
> Error: --from-tag option does not take a value
> $ bodhi updates edit --from-tag FEDORA-2020-f16abf2fb5
> ERROR: The release of the update is composed by Bodhi, i.e. follows
> the normal update workflow. Please build packages normally, using
> build root overrides as required, and edit the update accordingly with
> these new builds.
> $ bodhi updates edit --addbuilds sagemath-9.2-2.fc33 --removebuilds
> sagemath-9.2-1.fc33 FEDORA-2020-f16abf2fb5
> Cannot find release associated with build: sagemath-9.2-2.fc33, tags:
> ['f33-build-side-33909']
> 
> 
> /me bangs head against handy brick wall

HUmf. I also tried without much luck... (and I unpushed it as part of
that, sorry for that). 

Can you file a releng ticket on this and we can at the very least dig
into the database and fix it that way. ;( 

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: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Gargoyle

On 18/11/2020 13:28, Luca BRUNO wrote:

A dynamic default is being tackled directly at kernel level.
There is a currently in-progress patch on linux-fsdevel for this, first
revision is at
https://patchwork.kernel.org/project/linux-fsdevel/patch/20201026204418.23197-1-long...@redhat.com/.
For further context, see
https://github.com/coreos/fedora-coreos-tracker/issues/637

Great info, thanks Luca.

It seems like the same issues are identified on that thread as by others
on this one. IDE's and sync'y things being almost universally
problematic with the low default.

I'm not familiar with kernel dev. How long do these kind of things take
to trickle into a distro? Would it still be worth targeting something
for F34? Could a file dropped into
/etc/sysctl.d/10-max_user_watches.conf be a quick win?

So far the only drawbacks mentioned are an increase in RAM usage when a
lot of watches are in use and _maybe_ a filesystem slowdown (which so
far hasn't been raised by anyone on the kernel.org thread).

My biggest offender, netbeans (17k watchers), is currently using 1.6G of
RAM. Another 50MB really would be a drop in the ocean.

G.
___
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: systemd-resolved in a container

2020-11-18 Thread Alexander Bokovoy


On ke, 18 marras 2020, Paul Wouters wrote:

On Wed, 18 Nov 2020, Alexander Bokovoy wrote:


Is there a way to use systemd resolved in a container?


I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.


What is the advantage of running systemd-resolved in a container?

Is that container doing mDNS or LLMNR or a split-dns VPN ?

The whole point of containers is isolation and minimal setups. Pulling
in Base OS components into each container seems a waste of resources?


It is part of systemd packaging and gets pulled in with that if you need
systemd -- like we need for FreeIPA CIs or FreeIPA container
deployments.

# rpm -qf /usr/lib/systemd/systemd-resolved
systemd-246.6-3.fc34.x86_64


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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 1283764] Use of uninitialized value in numeric eq (==) at /usr/share/perl5/vendor_perl/File/Tail.pm line 391

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



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


-- 
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: Summary/Minutes from today's FESCo Meeting (2020-11-11)

2020-11-18 Thread Alexander Scheel

On Tue, Nov 17, 2020 at 1:21 PM Robbie Harwood  wrote:
>
> Matthew Miller  writes:
>
> > On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote:
> >> > I completely agree. This is one of the reasons I switched away from
> >> > ubuntu years ago (with its 4 (?) tiers of support + repos for its
> >> > packages ...).
> >> I agree, Fedora did the Core-Extras Merge back in the day for a reason.
> >
> > That reason was _mainly_ to erase the inside Red Hat,
> > community-around-the-edges distinction. That was a huge success and Fedora
> > wouldn't be interesting without that. But I think the _technical_ choice was
> > in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way.
>
> Respectfully, I don't agree with that.  From a technical perspective,
> the splitting of RHEL into many repos is awful to work with, and there
> was no reason to suppose it would be otherwise.
>
> Suppose I depend on a package.  That package could now come from any of
> the following repositories (assuming I haven't forgotten any):
>
> - AppStream
> - BaseOS
> - CRB
> - BuildRoot
> - EPEL
>
> And that's just for me building things in BaseOS + AppStream, not even
> any layered products.  For me internally, these repos are all nearby,
> but what if I weren't?  Some come from Red Hat, some from CentOS, EPEL
> (and ELN) from Fedora, ...
>
> This is painful to work with; I just need my package to build.  From a
> technical perspective, we need to consider the time lost due to trying
> to configure machines and testing environments with the right repos,
> the impossibility of figuring out what repo a package actually is
> shipped in [1] (if it even is), etc..
>
> And that doesn't even get into modularity - where there's another layer
> of package non-discoverability.
>
> Also RHEL/EPEL policy currently means that "hidden" packages in RHEL
> can't be exposed in EPEL - because that would be repackaging them.
>
> In summary, from a technical perspective, this is an unwieldy mess.
> Nothing is gained from the packager's point of view or the end user's
> point of view.  The gains [2] are in the lifecycle and support realms -
> firmly in business, not technical.
>
> So: no new repo splits please.  The only distinction we should care
> about is "Fedora" and "not Fedora", in my view - keep it simple and
> approachable.

I second what Robbie has said as well.

I am against the thought of this change.

As my team has found out within Red Hat, this repo split has been a
large PITA. Because RHEL also won't self-host and many sub-packages
are missing from released bits that are otherwise available in e.g.,
BUILDROOT, building our bits in COPR for QE to test has been an
impossible battle. After close to a year, this use case still hasn't
been enabled internally.

Consider also what other groups such as COPR have to do to support
repo splits. Yeah, it might be quick to split it in Koji and repo
files, but the impact on other teams and contributors is a huge
negative. If people have to go searching for special repos and
dependencies to build their packages, the developer experience of
Fedora will suffer more. That will push more people to Ubuntu.



My 2c.,

Alex

>
> Thanks,
> --Robbie
>
> 1: This is an issue with RHEL tools, in my view.
> 2: I contend that hiding packages doesn't actually reduce support
>burden, just hides it, but that's orthogonal to the conversation.
> ___
> 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: NEEDINFO nag 2 days after bug creation?

2020-11-18 Thread Andy Mender

On Tue, 17 Nov 2020 at 16:17, Richard Shaw  wrote:

> On Mon, Nov 16, 2020 at 5:10 PM Miro Hrončok  wrote:
>
>> On 11/16/20 11:31 PM, Richard Shaw wrote:
>> > The logic behind the NEEDINFO stuff may need to be updated... The
>> subject says
>> > it all and it's quite annoying.
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1897496
>> > 
>>
>> The script runs every 3 weeks, on a Sunday. Sometimes, this happens to be
>> right
>> after the bug was opened. Sorry about that.
>>
>> Sure, we *should* adapt that script to check the creation date of the
>> bug. The
>> script is here if you are interested to take a look:
>>
>
> Now that I know that, it's not as big of a deal but yeah, it would be good
> to check the BZ creation date, then I would say it should probably run
> every week (assuming it's not run more frequently due to resource usage.)
>
>
> https://pagure.io/releng/blob/master/f/scripts/ftbfs_weekly_reminder.py
>
>
> I may take a look but $DAYJOB is insane right now and my Python
> programming days ended a long time ago :)
>
> Thanks,
> Richard
>
>
Python dev here. I can have a look at it over the weekend :).
___
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: INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Simo Sorce

On Wed, 2020-11-18 at 20:21 +0100, Miro Hrončok wrote:
> On 11/18/20 8:10 PM, Alexander Scheel wrote:
> > Also, JFTR, I believe I only took over internal maintenance of
> > python-nss; I am not a maintainer of Fedora python-nss. There is only
> > one maintainer:
> > 
> > https://src.fedoraproject.org/rpms/python-nss
> 
> My motivation here is to either get this package orphaned/retired or 
> maintained 
> by a new maintainer.

The former is more likely.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: F34, ppc64 and changing from 64k to 4k page size?



On 18/11/2020 19:18, Dan Horák wrote:
> On Wed, 18 Nov 2020 18:54:51 +0100
> Daniel Pocock  wrote:
> 
>>
>>
>> Hi all,
>>
>> Given the problems with the 64k page size, is it feasible to offer the
>> 4k page size as default for ppc64 users in Fedora 34?
> 
> personally I haven't encountered any problems related to 64k pages on
> my Talos II system, that's used as my primary workstation. And I believe

The issues only arise in certain things

For example, the Nouveau driver: I tried it out of curiosity with an old
K2200.  I don't need it though as I'm using a Radeon card.

> if there are still some page size related issue, they should be fixed
> rather than masked. Once COPR has back ppc64le support, anyone is

Personally, I agree that fixing issues that only arise on 64k pages can
help raise code quality.  Simply adding unit tests for such issues can
also have a positive impact.

On the other hand, there are a backlog of issues on the platform and in
free software in general.  We all have to make decisions to work on some
issues ahead of others.

> welcome to offer 4k kernels there, like there are other kernel variants
> for other platforms.
>

Thanks for pointing that out.

Can we create installation media with a 4k page size from COPR and can
it be distributed from a trusted source for any other user?



> 
>   Dan
> 
>> Vikings.net in Germany is about to start selling[1] workstations based
>> on the Talos II and Blackbird.  The people who buy those have a big
>> commitment to free software and I suspect many of them will try Fedora.
>>
>> More comments[2] about the platform on my earlier blog.
>>
>> Regards,
>>
>> Daniel
>>
>> 1. https://store.vikings.net/openpower
>> 2. https://danielpocock.com/talos-II-quickstart/
>> ___
>> 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
> 
___
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: libcap-ng update coming to rawhide

2020-11-18 Thread Steve Grubb

Hello,

The new libcap-ng has been built into rawhide.

Cheers,
-Steve

On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote:
> A new version of libcap-ng is going to be released next week. Normally this
>  isn't newsworthy, nor is this a soname version bump. But it is important
> to let the broader community know something about it. The behaviour of
> capng_apply is changing slightly.
> 
> In the past, capng_apply would silently eat errors when the bounding set 
> could not be changed. In order to change the bounding set, you have to have
> 
> CAP_SETPCAP. A developer reported an issue in github where their project
> needed to know that capng_apply was completely successful changing the
> bounding set. Meaning that they need an error returned. I didn't think too
> much of it and made the change.
> 
> Then one day I noticed that I could not update a package against Fedora's
> git  or push a change. Looking into this, I found gnome-keyring was not
> working. [1]  I dug into the source code and found that it was trying to
> change the bounding set when it had partial capabilities. The fix is to
> simply verify that you have CAP_SETPCAP before attempting this.
> 
> I don't know of any other software that is affected. But I wanted to give 
> everyone a heads up before I push it out. I always dogfood libraries I
> work on, so maybe this is the only issue.
> 
> Eventually libcap-ng needs to get pushed over to F33 because there is a 
> problem with ambient capailities that the new release fixes. And speaking
> of  ambient capabilities, the new version of libcap-ng contains a new
> library libdrop_ambient.so. You can use it with LD_PRELOAD to force an app
> to drop ambient capabilities leaving the other capabilities intact. All
> the work is done in the constructor, so no function calls are needed.
> 
> Best Regards,
> -Steve
> 
> 1 - https://bugzilla.redhat.com/show_bug.cgi?id=1888978
> 
> ___
> 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/de...@lists.fedoraproject.or
> g



___
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: INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Miro Hrončok


On 11/18/20 8:10 PM, Alexander Scheel wrote:

Also, JFTR, I believe I only took over internal maintenance of
python-nss; I am not a maintainer of Fedora python-nss. There is only
one maintainer:

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


My motivation here is to either get this package orphaned/retired or maintained 
by a new maintainer.


--
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: systemd-resolved in a container

2020-11-18 Thread Nikos Mavrogiannopoulos

On Wed, Nov 18, 2020 at 6:37 PM Paul Wouters  wrote:
>
> On Wed, 18 Nov 2020, Alexander Bokovoy wrote:
>
> >> Is there a way to use systemd resolved in a container?
> >
> > I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
> > replaced by dbus-broker which is not active by default.
> >
> > So you need
> >
> > systemctl enable --now dbus-broker
> >
> > Without it even hostnamectl doesn't work, not just systemd-resolve.
>
> What is the advantage of running systemd-resolved in a container?

I do not know, but as I said the fedora container is set up with it
already there. What I am actually trying to do is to test the resolved
support in an application via the gitlab CI.

regards,
Nikos
___
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: INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Alexander Scheel

Also, JFTR, I believe I only took over internal maintenance of
python-nss; I am not a maintainer of Fedora python-nss. There is only
one maintainer:

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


- Alex

On Wed, Nov 18, 2020 at 2:09 PM Alexander Scheel  wrote:
>
> Note that I have no access to upstream python-nss. The entire upstream
> community was John Dennis. The last upstream commit was in 2018 and
> the commit prior was in 2017. With his departure, there's no viable
> path forward for maintaining python-nss upstream; perhaps someone from
> Mozilla will take it over, I do not know.
>
> Dogtag is looking to remove our dependency on python-nss and will
> likely orphan it if we can do so in the f34 release cycle.
>
> I'll let the list know what we decide.
>
>
> - A
>
> On Wed, Nov 18, 2020 at 2:00 PM Rob Crittenden  wrote:
> >
> > Miro Hrončok wrote:
> > > Hello.
> > >
> > > Does anybody has an alternate contact info for jden...@redhat.com / FAS
> > > jdennis?
> > >
> > > Bugzilla says the account is invalid:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1892248
> >
> > Alex Scheel replaced John as the maintainer.
> >
> > rob
> >
___
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: INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Alexander Scheel

Note that I have no access to upstream python-nss. The entire upstream
community was John Dennis. The last upstream commit was in 2018 and
the commit prior was in 2017. With his departure, there's no viable
path forward for maintaining python-nss upstream; perhaps someone from
Mozilla will take it over, I do not know.

Dogtag is looking to remove our dependency on python-nss and will
likely orphan it if we can do so in the f34 release cycle.

I'll let the list know what we decide.

- A

On Wed, Nov 18, 2020 at 2:00 PM Rob Crittenden  wrote:
>
> Miro Hrončok wrote:
> > Hello.
> >
> > Does anybody has an alternate contact info for jden...@redhat.com / FAS
> > jdennis?
> >
> > Bugzilla says the account is invalid:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1892248
>
> Alex Scheel replaced John as the maintainer.
>
> rob
>
___
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: INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Rob Crittenden

Miro Hrončok wrote:
> Hello.
> 
> Does anybody has an alternate contact info for jden...@redhat.com / FAS
> jdennis?
> 
> Bugzilla says the account is invalid:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1892248

Alex Scheel replaced John as the maintainer.

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

Re: F34, ppc64 and changing from 64k to 4k page size?



On 18/11/2020 19:17, David Howells wrote:
> Daniel Pocock  wrote:
> 
>> Given the problems with the 64k page size, is it feasible to offer the
>> 4k page size as default for ppc64 users in Fedora 34?
> 
> It doesn't necessarily help you if you're, say, upgrading from F33 and are
> already using 64K pagesize.  Your formatted filesystems may already depend on
> this - in which case you may find your system is unbootable.
> 

I built my own kernels with 4k page size and used that for creating my
filesystems.  Filesystems are not the only issue though, I found some
applications that don't work on 64k but do work on 4k.

I raised this thread for the convenience of other people who may not be
ready to build a kernel like me.

Regards,

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

Re: F34, ppc64 and changing from 64k to 4k page size?

2020-11-18 Thread Dan Horák

On Wed, 18 Nov 2020 18:54:51 +0100
Daniel Pocock  wrote:

> 
> 
> Hi all,
> 
> Given the problems with the 64k page size, is it feasible to offer the
> 4k page size as default for ppc64 users in Fedora 34?

personally I haven't encountered any problems related to 64k pages on
my Talos II system, that's used as my primary workstation. And I believe
if there are still some page size related issue, they should be fixed
rather than masked. Once COPR has back ppc64le support, anyone is
welcome to offer 4k kernels there, like there are other kernel variants
for other platforms.


Dan

> Vikings.net in Germany is about to start selling[1] workstations based
> on the Talos II and Blackbird.  The people who buy those have a big
> commitment to free software and I suspect many of them will try Fedora.
> 
> More comments[2] about the platform on my earlier blog.
> 
> Regards,
> 
> Daniel
> 
> 1. https://store.vikings.net/openpower
> 2. https://danielpocock.com/talos-II-quickstart/
> ___
> 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: F34, ppc64 and changing from 64k to 4k page size?

2020-11-18 Thread David Howells

Daniel Pocock  wrote:

> Given the problems with the 64k page size, is it feasible to offer the
> 4k page size as default for ppc64 users in Fedora 34?

It doesn't necessarily help you if you're, say, upgrading from F33 and are
already using 64K pagesize.  Your formatted filesystems may already depend on
this - in which case you may find your system is unbootable.

David
___
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: Two questions on updates

2020-11-18 Thread Jerry James

On Wed, Nov 18, 2020 at 10:56 AM Mattia Verga via devel
 wrote:
> Yeah, that's another Bodhi webUI bug (fixed in devel, but not yet
> available in prod).
>
> To update the builds list of a side-tag update you can use the CLI:
> `bodhi updates edit --from-tag= `
>
> Try that...

$ bodhi updates edit --from-tag=f33-build-side-33909 FEDORA-2020-f16abf2fb5
Error: --from-tag option does not take a value
$ bodhi updates edit --from-tag FEDORA-2020-f16abf2fb5
ERROR: The release of the update is composed by Bodhi, i.e. follows
the normal update workflow. Please build packages normally, using
build root overrides as required, and edit the update accordingly with
these new builds.
$ bodhi updates edit --addbuilds sagemath-9.2-2.fc33 --removebuilds
sagemath-9.2-1.fc33 FEDORA-2020-f16abf2fb5
Cannot find release associated with build: sagemath-9.2-2.fc33, tags:
['f33-build-side-33909']

/me bangs head against handy brick wall
-- 
Jerry James
http://www.jamezone.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: Two questions on updates

2020-11-18 Thread Mattia Verga via devel

Il 18/11/20 18:43, Jerry James ha scritto:
> On Mon, Nov 16, 2020 at 9:34 AM Fabio Valentini  wrote:
>> Ah, I'm just sharing my wisdom. It has no use when I keep it to myself :)
> I need a little more wisdom.  This is the update I created from the side tag:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-f16abf2fb5/
>
> A tester found a problem with the sagemath package, so I did a new
> build (also into the side tag), sagemath-9.2-2.fc33.  Now I want to
> edit the update.  I click the edit button ... and the list of builds
> is not editable.  Is that intentional?  If so, how am I supposed to
> update an update?

Yeah, that's another Bodhi webUI bug (fixed in devel, but not yet 
available in prod).

To update the builds list of a side-tag update you can use the CLI:
`bodhi updates edit --from-tag= `

Try that...

Mattia

___
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

F34, ppc64 and changing from 64k to 4k page size?



Hi all,

Given the problems with the 64k page size, is it feasible to offer the
4k page size as default for ppc64 users in Fedora 34?

Vikings.net in Germany is about to start selling[1] workstations based
on the Talos II and Blackbird.  The people who buy those have a big
commitment to free software and I suspect many of them will try Fedora.

More comments[2] about the platform on my earlier blog.

Regards,

Daniel

1. https://store.vikings.net/openpower
2. https://danielpocock.com/talos-II-quickstart/
___
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-IoT-34-20201118.0 compose check report

No missing expected images.

Failed openQA tests: 4/16 (x86_64), 8/15 (aarch64)

New failures (same test not failed in Fedora-IoT-34-20201116.0):

ID: 724941  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/724941
ID: 724948  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/724948
ID: 724952  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/724952

Old failures (same test failed in Fedora-IoT-34-20201116.0):

ID: 724933  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/724933
ID: 724945  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/724945
ID: 724949  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/724949
ID: 724951  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/724951
ID: 724953  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/724953
ID: 724954  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/724954
ID: 724957  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/724957
ID: 724959  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/724959
ID: 724963  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/724963

Passed openQA tests: 12/16 (x86_64), 7/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
1 services(s) added since previous compose: systemd-homed-activate.service
Previous test data: https://openqa.fedoraproject.org/tests/723406#downloads
Current test data: https://openqa.fedoraproject.org/tests/724934#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) added since previous compose: systemd-homed-activate.service
Previous test data: https://openqa.fedoraproject.org/tests/723407#downloads
Current test data: https://openqa.fedoraproject.org/tests/724935#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.57 to 0.44
Previous test data: https://openqa.fedoraproject.org/tests/723422#downloads
Current test data: https://openqa.fedoraproject.org/tests/724950#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Two questions on updates

2020-11-18 Thread Jerry James

On Mon, Nov 16, 2020 at 9:34 AM Fabio Valentini  wrote:
> Ah, I'm just sharing my wisdom. It has no use when I keep it to myself :)

I need a little more wisdom.  This is the update I created from the side tag:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-f16abf2fb5/

A tester found a problem with the sagemath package, so I did a new
build (also into the side tag), sagemath-9.2-2.fc33.  Now I want to
edit the update.  I click the edit button ... and the list of builds
is not editable.  Is that intentional?  If so, how am I supposed to
update an update?
-- 
Jerry James
http://www.jamezone.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

new Radeon RX 6800/6900/Big Navi on Fedora


Hi all,

Does anybody have any comments for those who manage to get one of these
cards?

Phoronix published[1] various comments about it, it appears to need:

Kernel 5.9 or 5.10

Firmware binary code that isn't yet present in linux-firmware.git
- is there any way to extract that binary from another platform?

llvm-11 or greater for Mesa

Mesa 20.2 or later

F33 looks good for llvm and mesa.

They offered 20 of them at my local supplier today, I submitted an order
but it isn't clear if I really got it.  Looking forward to trying the
combination of this PCIe 4 GPU with the Talos II.

Regards,

Daniel


https://www.phoronix.com/scan.php?page=article=amd-rx6800-linux=1
___
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: systemd-resolved in a container

2020-11-18 Thread Paul Wouters


On Wed, 18 Nov 2020, Alexander Bokovoy wrote:


Is there a way to use systemd resolved in a container?


I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.


What is the advantage of running systemd-resolved in a container?

Is that container doing mDNS or LLMNR or a split-dns VPN ?

The whole point of containers is isolation and minimal setups. Pulling
in Base OS components into each container seems a waste of resources?

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

video meeting to discuss Matrix/Element and IRC

2020-11-18 Thread Matthew Miller

[I posted to the Fedora Council list, but reposting here for wider
distribution.]

As mentioned, we're looking at moving the Fedora Council's main chat to
Matrix. And as part of that, we're considering a hosted Element server --
which obviously could go quite beyond just #fedora-council. Neal suggested a
video meeting to talk with interested people about this, and so I set up
this when-is-good

   http://whenisgood.net/k5brwbd

Anyone interested in a preliminary chat about all of this, please sign up
with your FAS id and availability. Nothing is sent in stone or decided
already, although I must say I'm pretty excited about Element's open source
software-as-a-service offering based on what I've heard from them so far.



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

Re: GitLab AMA Topic: Message Bus

2020-11-18 Thread Fabio Valentini

On Mon, Nov 9, 2020 at 3:05 PM Aoife Moloney  wrote:
>
> Hi everyone,
>
> I hope you enjoyed the F33 release party this weekend! Getting back to
> the GitLab topic mail threads, this weeks topic from the GitLab AMA
> session on September 10th is on Message Bus. As always, here are some
> links to the resources I have been pulling content from as well:
> * Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> * Chat log from session
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> * AMA Blog post
> https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> * Here is this email in hackmd if you wish to view it there:
> https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view

Sorry for taking so long to respond, the past weeks have been quite busy.

(snip)

> ## Topic: Message Bus
> - Question: Fedora uses a message bus to integrate different parts of
> its infrastructure. How should we onboard GitLab into this message
> bus?
> - Answer: Currently we would need to have a service that proxies
> GitLab’s events to fedora-messaging something similar to
> github2fedmsg.
> There were some concerns raised about the order of events sent by
> GitLab’s webhooks, these will need to be looked after during a Proof
> of Concept stage.

Do we know if such a proxy would even be theoretically possible for GitLab?
IIRC, some doubts were raised during the AMA that getting a
chronologically consistent stream of events out of GitLab would be ∈
[hard, impossible[.
What would that mean for fedora? Do services relying on
fedora-messaging events related to dist-git need them to be consistent
/ chronological?
What would be the effect of those services not having a reliable
stream of events from dist-git?

Fabio

> - Question: How would git push over http work with GitLab? (assuming
> gitlab does not have Fedora's password since they are stored in FAS)
> - Answer: GitLab has a good number of authentication options and
> integrations where the "best" solution usually depends on a team's
> specific needs and use case. As such,  the best way to know and meet
> Fedora's needs and use cases is to have a conversation and discuss the
> options with GitLab. How does git push over HTTP work with FAS right
> now, and what git push (over HTTP) auth requirements/flow would you
> like to have for your projects in GitLab?
>
> These are the only two questions and answers I could gather relating
> to message bus from the AMA question sheet, however I know there was a
> lot of discussion regarding this topic during the AMA session itself,
> so if you would like to resume/kick off  that conversation again,
> please feel free to use this email to discuss.
>
> A personal note and for full transparency: the weeks seem to be
> passing in the blink of an eye lately, I assume it's because I'm
> busy(?) but it might be just the weird 2020 vibe the world is on
> nowadays. I really don't know. Whatever the reason, there has been no
> further discussion with GitLab since early October-ish, but we will be
> returning to the conversation of how this migration could be
> technically possible soon, so sincerely thank you all again for
> engaging with us/me here as I found reading the discussion on
> permission and access much easier to follow and have been taking notes
> on your expectations to use that feedback in conversations with GitLab
> when we pick the discussion back up.
>
>
>
> I hope you all had a good weekend and will talk to you all next week
> when the topic of Namespace & Issue Tracking is sent!
>
>
> Kindest regards,
> Aoife
> --
> Aoife Moloney
> Product Owner
> Community Platform Engineering Team
> Red Hat EMEA
> Communications House
> Cork Road
> Waterford
> ___
> 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

[Bug 1899180] perl-PAR-Dist-0.50 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|anon.am...@gmail.com,   |
   |st...@silug.org |
   Doc Type|--- |If docs needed, set a value




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

[Bug 1899182] New: Upgrade perl-Type-Tie to 0.015

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

Bug ID: 1899182
   Summary: Upgrade perl-Type-Tie to 0.015
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Type-Tie
  Assignee: rc040...@freenet.de
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
rc040...@freenet.de
  Target Milestone: ---
Classification: Fedora



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


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

[Bug 1899180] New: perl-PAR-Dist-0.50 is available

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

Bug ID: 1899180
   Summary: perl-PAR-Dist-0.50 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-PAR-Dist
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.50
Current version/release in rawhide: 0.49-23.fc33
URL: http://search.cpan.org/dist/PAR-Dist/

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


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

INVALID USER jden...@redhat.com / FAS jdennis

2020-11-18 Thread Miro Hrončok


Hello.

Does anybody has an alternate contact info for jden...@redhat.com / FAS jdennis?

Bugzilla says the account is invalid:

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

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

Summary/Minutes from today's FESCo Meeting (2020-11-18)

2020-11-18 Thread Zbigniew Jędrzejewski-Szmek

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-18/fesco.2020-11-18-15.00.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-18/fesco.2020-11-18-15.00.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-18/fesco.2020-11-18-15.00.log.html

Meeting summary
---
* init process  (zbyszek, 15:00:07)

* #2473 Updates policy is out of date  (zbyszek, 15:02:07)

nirik will update the PR in response to the latest comments and we'll vote 
there.

* #2475 Proposal: let's develop the idea of a new repo for
  lightly-maintained packages  (zbyszek, 15:04:28)
  *

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/P7QMEXGV3X76Z2K67AW32YX6BQVFDHS3/
(zbyszek, 15:05:37)
  * AGREED: Close this ticket and discuss more on devel for a concrete
proposal (+7, 0, 0)  (zbyszek, 15:27:08)

* #2501 F34 System-Wide Change: Remove and deprecate nscd in favour of
  sssd and systemd-resolved  (zbyszek, 15:28:24)

Some additional questions and ideas were posted in the ticket.

* Next week's chair  (zbyszek, 15:46:13)
  * ACTION: mhroncok will chair next meeting (if it happens)  (zbyszek,
15:51:09)
  * ACTION: sgallagh will chair two weeks from now  (zbyszek, 15:51:16)

* Open Floor  (zbyszek, 15:51:26)

Voting in FESCo elections starts tomorrow.

Meeting ended at 15:56:14 UTC.


Action Items

* mhroncok will chair next meeting (if it happens)
* sgallagh will chair two weeks from now
___
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 1898610] perl-Convert-Binary-C-0.80 is available

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Convert-Binary-C-0.80-
   ||1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-18 16:11:17




-- 
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 1898583] perl-Algorithm-CheckDigits-1.3.5 is available

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



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 1730598
  --> https://bugzilla.redhat.com/attachment.cgi?id=1730598=edit
[patch] Update to 1.3.5 (#1898583)


-- 
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 1898583] perl-Algorithm-CheckDigits-1.3.5 is available

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Algorithm-CheckDigits- |perl-Algorithm-CheckDigits-
   |1.3.4 is available  |1.3.5 is available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 1.3.5
Current version/release in rawhide: 1.3.3-2.fc33
URL: http://search.cpan.org/dist/Algorithm-CheckDigits/

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


-- 
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 1899120] perl-Net-DNS-1.29 is available

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.29-1.fc32.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=55807145


-- 
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 1899120] perl-Net-DNS-1.29 is available

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



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


-- 
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 1899120] New: perl-Net-DNS-1.29 is available

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

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



Latest upstream release: 1.29
Current version/release in rawhide: 1.28-1.fc34
URL: http://search.cpan.org/dist/Net-DNS/

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


-- 
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: Upstream SPEC files - was: Re: patch applied without package maintainers' approve

2020-11-18 Thread Miroslav Suchý

Dne 16. 11. 20 v 11:04 Vít Ondruch napsal(a):
> I should not propose this, because I agree with the points bellow. But if we 
> should have it, then:
> 
> ~~~
> 
> Provides: upstream-spec(https://some.url/to/upstream/package.spec)
> 
> ~~~
> 
> would be machine readable and it would give use some idea how common this is.

Great idea.

I sum it up in:
https://pagure.io/packaging-committee/pull-request/1030

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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-20201118.n.0 compose check report

Missing expected images:

Xfce raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 14/177 (x86_64), 19/115 (aarch64)

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

ID: 724671  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/724671
ID: 724747  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/724747
ID: 724762  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/724762
ID: 724765  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/724765
ID: 724775  Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/724775
ID: 724877  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/724877
ID: 724901  Test: aarch64 universal install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/724901
ID: 724902  Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/724902
ID: 724914  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/724914
ID: 724929  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/724929
ID: 724930  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/724930
ID: 724931  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/724931
ID: 724932  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/724932

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

ID: 724677  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/724677
ID: 724689  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/724689
ID: 724696  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/724696
ID: 724697  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/724697
ID: 724699  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/724699
ID: 724773  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/724773
ID: 724819  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/724819
ID: 724854  Test: x86_64 universal install_blivet_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/724854
ID: 724874  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/724874
ID: 724886  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/724886
ID: 724899  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/724899
ID: 724903  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/724903
ID: 724916  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/724916
ID: 724917  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/724917
ID: 724918  Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/724918
ID: 724919  Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/724919
ID: 724920  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/724920
ID: 724923  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/724923
ID: 724925  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/724925
ID: 724927  Test: aarch64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/724927

Soft failed openQA tests: 68/177 (x86_64), 37/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 724629  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/724629
ID: 724630  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/724630
ID: 724636  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/724636
ID: 724637  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/724637
ID: 724638  Test: x86_64

Re: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Fabio Valentini

On Wed, Nov 18, 2020 at 10:49 AM Ankur Sinha  wrote:
>
> On Wed, Nov 18, 2020 09:13:54 +, Gargoyle wrote:
> > I've just made the switch from Ubuntu to Fedora 33 for my main desktop
> > system. Of the few teething problems I am going through, the initial 8192
> > limit for fs.inotify.max_user_watches was probably causing the most side
> > effects. As a developer, I pretty much have netbeans open all day and am
> > forever tailing log files, so I hit this problem pretty much straight away.
> >
> > After some digging around I found a script to list the current count of
> > watchers per process. The half-dozen worst offenders were:-
> >
> >INOTIFY
> >WATCHER
> > COUNT PID CMD
> > 
> >4903 4620  /data/Applications/java/jdk-15/bin/java
> > -Djdk.home=/data/Applications/java/jdk-15 -classpath
> > /data/Applications/netbeans
> > 3573 3032  /usr/libexec/tracker-miner-fs-3
> >   64 2022  /usr/lib/systemd/systemd --user
> >   47 2663  /usr/libexec/gsd-xsettings
> >   2734846  /usr/share/atom/atom --type=renderer
> > --enable-experimental-web-platform-features
> > --field-trial-handle=123480363484759119
> >   18 2812  /usr/bin/gnome-software --gapplication-service
> >
> > So netbeans + tracker-miner had pretty much consumed the entire pool within
> > an hour of starting the system.
> >
> > I've bumped the figure up to 65K by adding an entry to /etc/sysctl.conf and
> > asked on #fedora if anyone knew of the side effects of having a high number
> > - the only answers found were that approx 1K of unswapable kernel memory is
> > used per watcher. So this increase only puts an additional 57MB of such
> > memory usage onto my system.
> >
> > Are there any other side effects of this to worry about?
> >
> > If not, then perhaps the default should be significantly increased with the
> > aim of removing the problem for new users with modern desktop/laptop
> > machines which probably have 4GB+ RAM. I've not rebooted my machine
> > overnight and netbeans is now up to 13,000 watches and tracker-miner upto
> > 4,500. So in less than 24 hours I have exceeded 16K watches.
> >
> > Perhaps an new default value in the region of 32K - 64K would be more
> > appropriate?
>
> To add: Dropbox users often run into this issue, which has interesting
> side effects, like PDF readers not updating when the file is changed:
>
> https://ask.fedoraproject.org/t/pdf-readers-stops-doing-automatic-refresh-on-file-change/9537

This is also an issue for syncthing when inotify support is enabled
for sync'ed folders.
I had to bump that setting to "fs.inotify.max_user_watches=204800" on
my main machine because otherwise it ran out of file watches really
really quickly.
I think bumping it to 2^16 would be a good default value to make sure
most users don't bump against the really low 8K limit ...

Fabio
___
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: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Luca BRUNO

On Wed, 18 Nov 2020 09:13:54 +
Gargoyle  wrote:

> I've just made the switch from Ubuntu to Fedora 33 for my main
> desktop system. Of the few teething problems I am going through, the
> initial 8192 limit for fs.inotify.max_user_watches was probably
> causing the most side effects.
>
> If not, then perhaps the default should be significantly increased
> with the aim of removing the problem for new users with modern
> desktop/laptop machines which probably have 4GB+ RAM.

A dynamic default is being tackled directly at kernel level.
There is a currently in-progress patch on linux-fsdevel for this, first
revision is at
https://patchwork.kernel.org/project/linux-fsdevel/patch/20201026204418.23197-1-long...@redhat.com/.
For further context, see
https://github.com/coreos/fedora-coreos-tracker/issues/637

Ciao, Luca
___
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: systemd-resolved in a container

2020-11-18 Thread Alexander Bokovoy


On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:

Hi,
I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?


I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

 systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
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

systemd-resolved in a container

2020-11-18 Thread Nikos Mavrogiannopoulos

Hi,
 I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

regards,
Nikos
___
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-Cloud-31-20201118.0 compose check report

No missing expected images.

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

Re: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Ondrej Budai

st 18. 11. 2020 v 10:16 odesílatel Gargoyle  napsal:

> I've just made the switch from Ubuntu to Fedora 33 for my main desktop
> system. Of the few teething problems I am going through, the initial
> 8192 limit for fs.inotify.max_user_watches was probably causing the most
> side effects. As a developer, I pretty much have netbeans open all day
> and am forever tailing log files, so I hit this problem pretty much
> straight away.
>
> After some digging around I found a script to list the current count of
> watchers per process. The half-dozen worst offenders were:-
>
> INOTIFY
> WATCHER
>  COUNT PID CMD
> 
> 4903 4620  /data/Applications/java/jdk-15/bin/java
> -Djdk.home=/data/Applications/java/jdk-15 -classpath
> /data/Applications/netbeans
>  3573 3032  /usr/libexec/tracker-miner-fs-3
>64 2022  /usr/lib/systemd/systemd --user
>47 2663  /usr/libexec/gsd-xsettings
>2734846  /usr/share/atom/atom --type=renderer
> --enable-experimental-web-platform-features
> --field-trial-handle=123480363484759119
>18 2812  /usr/bin/gnome-software --gapplication-service
>
> So netbeans + tracker-miner had pretty much consumed the entire pool
> within an hour of starting the system.
>
> I've bumped the figure up to 65K by adding an entry to /etc/sysctl.conf
> and asked on #fedora if anyone knew of the side effects of having a high
> number - the only answers found were that approx 1K of unswapable kernel
> memory is used per watcher. So this increase only puts an additional
> 57MB of such memory usage onto my system.
>
> Are there any other side effects of this to worry about?
>
> If not, then perhaps the default should be significantly increased with
> the aim of removing the problem for new users with modern desktop/laptop
> machines which probably have 4GB+ RAM. I've not rebooted my machine
> overnight and netbeans is now up to 13,000 watches and tracker-miner
> upto 4,500. So in less than 24 hours I have exceeded 16K watches.
>
> Perhaps an new default value in the region of 32K - 64K would be more
> appropriate?
>
>
> -- Gargoyle
> ___
> 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 have the exact same experience with Goland and PyCharm. I raised the
limit to 524288 using this guide[1] and it works like a charm.

[1]: https://confluence.jetbrains.com/display/IDEADEV/Inotify+Watches+Limit

-- 

Ondřej Budai

Software Engineer

Red Hat 

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

Re: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Marius Schwarz


Am 18.11.20 um 10:13 schrieb Gargoyle:


   4903 4620  /data/Applications/java/jdk-15/bin/java 
-Djdk.home=/data/Applications/java/jdk-15 -classpath 
/data/Applications/netbeans


The first action that comes in mind is to reduce the amount of notifiers 
in use.


When my Android Studio runs, it opens a shitload of files for no good 
reason. No idea who big your list of open files in your ide is, but my 
actual open source files are maybe 20 max. No need to have thousands of 
notifiers in use for this.


And for your question: the more notifiers are running, the slower your 
filesystem will react: for any access the list of notfiers needs to be 
checked. Depending on the implementation, a rising number may have an 
exponential increasing impact.


For normal Desktop use, a limit of 8192  is more than enough IMHO.

best regards,
Marius
___
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: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Tom Hughes via devel


On 18/11/2020 09:58, Miro Hrončok wrote:

On 11/18/20 10:13 AM, Gargoyle wrote:


If not, then perhaps the default should be significantly increased 
with the aim of removing the problem for new users with modern 
desktop/laptop machines which probably have 4GB+ RAM. I've not 
rebooted my machine overnight and netbeans is now up to 13,000 watches 
and tracker-miner upto 4,500. So in less than 24 hours I have exceeded 
16K watches.


Perhaps an new default value in the region of 32K - 64K would be more 
appropriate?


See also https://bugzilla.redhat.com/show_bug.cgi?id=1575156

I wonder how was this fixed.


Seems I must have run into it on my work machine as well, due to
vscode by the looks of it, and I increased the limit significantly
as a result.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Miro Hrončok


On 11/18/20 10:13 AM, Gargoyle wrote:
I've just made the switch from Ubuntu to Fedora 33 for my main desktop system. 
Of the few teething problems I am going through, the initial 8192 limit for 
fs.inotify.max_user_watches was probably causing the most side effects. As a 
developer, I pretty much have netbeans open all day and am forever tailing log 
files, so I hit this problem pretty much straight away.


After some digging around I found a script to list the current count of watchers 
per process. The half-dozen worst offenders were:-


    INOTIFY
    WATCHER
     COUNT PID CMD

    4903 4620  /data/Applications/java/jdk-15/bin/java 
-Djdk.home=/data/Applications/java/jdk-15 -classpath /data/Applications/netbeans

     3573 3032  /usr/libexec/tracker-miner-fs-3
   64 2022  /usr/lib/systemd/systemd --user
   47 2663  /usr/libexec/gsd-xsettings
   27    34846  /usr/share/atom/atom --type=renderer 
--enable-experimental-web-platform-features --field-trial-handle=123480363484759119

   18 2812  /usr/bin/gnome-software --gapplication-service

So netbeans + tracker-miner had pretty much consumed the entire pool within an 
hour of starting the system.


I've bumped the figure up to 65K by adding an entry to /etc/sysctl.conf and 
asked on #fedora if anyone knew of the side effects of having a high number - 
the only answers found were that approx 1K of unswapable kernel memory is used 
per watcher. So this increase only puts an additional 57MB of such memory usage 
onto my system.


Are there any other side effects of this to worry about?

If not, then perhaps the default should be significantly increased with the aim 
of removing the problem for new users with modern desktop/laptop machines which 
probably have 4GB+ RAM. I've not rebooted my machine overnight and netbeans is 
now up to 13,000 watches and tracker-miner upto 4,500. So in less than 24 hours 
I have exceeded 16K watches.


Perhaps an new default value in the region of 32K - 64K would be more 
appropriate?


See also https://bugzilla.redhat.com/show_bug.cgi?id=1575156

I wonder how was this fixed.

--
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: The default fs.inotify.max_user_watches limit is too low.

2020-11-18 Thread Ankur Sinha

On Wed, Nov 18, 2020 09:13:54 +, Gargoyle wrote:
> I've just made the switch from Ubuntu to Fedora 33 for my main desktop
> system. Of the few teething problems I am going through, the initial 8192
> limit for fs.inotify.max_user_watches was probably causing the most side
> effects. As a developer, I pretty much have netbeans open all day and am
> forever tailing log files, so I hit this problem pretty much straight away.
> 
> After some digging around I found a script to list the current count of
> watchers per process. The half-dozen worst offenders were:-
> 
>    INOTIFY
>    WATCHER
>     COUNT PID CMD
> 
>    4903 4620  /data/Applications/java/jdk-15/bin/java
> -Djdk.home=/data/Applications/java/jdk-15 -classpath
> /data/Applications/netbeans
>     3573 3032  /usr/libexec/tracker-miner-fs-3
>   64 2022  /usr/lib/systemd/systemd --user
>   47 2663  /usr/libexec/gsd-xsettings
>   27    34846  /usr/share/atom/atom --type=renderer
> --enable-experimental-web-platform-features
> --field-trial-handle=123480363484759119
>   18 2812  /usr/bin/gnome-software --gapplication-service
> 
> So netbeans + tracker-miner had pretty much consumed the entire pool within
> an hour of starting the system.
> 
> I've bumped the figure up to 65K by adding an entry to /etc/sysctl.conf and
> asked on #fedora if anyone knew of the side effects of having a high number
> - the only answers found were that approx 1K of unswapable kernel memory is
> used per watcher. So this increase only puts an additional 57MB of such
> memory usage onto my system.
> 
> Are there any other side effects of this to worry about?
> 
> If not, then perhaps the default should be significantly increased with the
> aim of removing the problem for new users with modern desktop/laptop
> machines which probably have 4GB+ RAM. I've not rebooted my machine
> overnight and netbeans is now up to 13,000 watches and tracker-miner upto
> 4,500. So in less than 24 hours I have exceeded 16K watches.
> 
> Perhaps an new default value in the region of 32K - 64K would be more
> appropriate?

To add: Dropbox users often run into this issue, which has interesting
side effects, like PDF readers not updating when the file is changed:

https://ask.fedoraproject.org/t/pdf-readers-stops-doing-automatic-refresh-on-file-change/9537

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


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

Re: F34 Change proposal: MariaDB 10.5 (Self-Contained Change)

2020-11-18 Thread Michal Schorm

I update the Wiki page to state that the current contingency plan is a
revert of the change by bumping 'mariadb' package epoch.
I also added a note about the dependent packages that need rebuild.
That is a single package (amarok); I tested the rebuild in COPR and
discussed it with the 'amarok' package maintainer.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Tue, Nov 17, 2020 at 8:12 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Nov 05, 2020 at 02:06:37PM +0100, Michal Schorm wrote:
> > On Thu, Nov 5, 2020 at 12:21 AM Fabio Valentini  
> > wrote:
> > > On Mon, Oct 26, 2020 at 5:21 PM Ben Cotton  wrote:
> > > > == Contingency Plan ==
> > > >
> > > > Modules will provide the functional version of MariaDB 10.4, available 
> > > > to all users.
> > > > * Contingency mechanism: Fedora Modules for 10.4 available
> > >
> > > This is not a sufficient contingency plan. Leaving broken 10.5
> > > non-modular packages in f34 is a non-starter.
> > >
> > > Is there a realistic path to back out of the 10.5 update in rawhide /
> > > F34 if there are problems?
> > > It looks like the 10.4 -> 10.5 update requires database upgrades as
> > > well, so would MariaDB 10.4 have problems with accessing databases
> > > that have been migrated to 10.5?
> >
> > In the worst case scenario, I would be forced to revert the change,
> > bump MariaDB 10.4 package epoch and release F34 with MariaDB 10.4
> > instead.
> >
> > Database upgrades in general (this is not just about MariaDB or MySQL)
> > are very problematic.
> > Every sane DB upgrade *ever* should have a data backup prior and I
> > don't want, nor have any means to, solve the cases of corrupted DB
> > data which haven't got a backup.
> >
> > What would be an issue however, if a significant number of users would
> > report the upgrade is problematic and they can't use the DB with the
> > new version.
> > The best thing both they and I can do is to file a BZ ticket (so we
> > are informed about it in the first place).
> > I will search the upstream JIRA ticket system for workarounds as a
> > part of the problem solving.
> > If any are found, I'd try to apply them or at least provide them to the 
> > users.
> >
> > If the issues would be in place but no solution in sight, the revert
> > to MariaDB 10.4 in Rawhide (and F34 if already branched) is the way to
> > go.
> >
> > If you will agree to this contingency mechanism, I will add it to the
> > Self-Contained Change wiki page.
> > Otherwise I'd ask you for a suggestion of what you picture as
> > sufficient contingency mechanism.
>
> So, any progress on this?
>
> 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

Fedora-Cloud-32-20201118.0 compose check report