Re: [ovirt-users] [feedback needed] VirtIO Windows Drivers - new installer

[Sandro Bonazzola]

Il giorno gio 24 ott 2019 alle ore 19:28 Strahil  ha
scritto:

> Hi Sandro,All,
>
> Can I upgrade the tools on existing VM , or it requires a fresh one? Best
> Regards
>

If you have oVirt windows guest tools already installed suggestion is to
uninstall it before installing this new installer.



> Best Regards,
> Strahil Nikolov
> On Oct 24, 2019 14:35, Sandro Bonazzola  wrote:
>
> Hi,
> as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
> Drivers installer using the open source framework WiX.
> Thanks to the virtio-win maintainer, the new installer is not shipped
> anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
> Windows ISO[1]
>
> Please give it a run on your testing environment / testing VMs and let us
> know about your experience at de...@ovirt.org.
> Thanks,
>
>
> [1]
> https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.173-2/
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> *Red Hat respects your work life balance.
> Therefore there is no need to answer this email out of your office hours.*
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.
*
___
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 31 compose report: 20191024.n.2 changes

[Fedora Branched Report]

OLD: Fedora-31-20191024.n.0
NEW: Fedora-31-20191024.n.2

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   6
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   534.88 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-31-20191024.n.2-sda.raw.xz

= DROPPED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-31-20191024.n.0-sda.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  gtk3-3.24.12-3.fc31
Old package:  gtk3-3.24.12-1.fc31
Summary:  GTK+ graphical user interface library
RPMs: gtk-update-icon-cache gtk3 gtk3-devel gtk3-devel-docs 
gtk3-immodule-xim gtk3-immodules gtk3-tests
Size: 74.96 MiB
Size change:  2.92 KiB
Changelog:
  * Mon Oct 21 2019 Adam Williamson  - 3.24.12-2
  - Backport PR #1142 to try and fix intermittent copy/cut failures

  * Tue Oct 22 2019 Adam Williamson  - 3.24.12-3
  - Backport PR #1146 to fix a bug that #1142 introduced...


Package:  kernel-5.3.7-301.fc31
Old package:  kernel-5.3.6-300.fc31
Summary:  The Linux kernel
RPMs: kernel kernel-core kernel-debug kernel-debug-core 
kernel-debug-devel kernel-debug-modules kernel-debug-modules-extra kernel-devel 
kernel-lpae kernel-lpae-core kernel-lpae-devel kernel-lpae-modules 
kernel-lpae-modules-extra kernel-modules kernel-modules-extra
Size: 430.54 MiB
Size change:  6.47 KiB
Changelog:
  * Fri Oct 18 2019 Laura Abbott  - 5.3.7-300
  - Linux v5.3.7

  * Mon Oct 21 2019 Laura Abbott  - 5.3.7-301
  - Fix CVE-2019-17666 (rhbz 1763692)


Package:  kernel-tools-5.3.7-300.fc31
Old package:  kernel-tools-5.3.6-300.fc31
Summary:  Assortment of tools for the Linux kernel
RPMs: bpftool kernel-tools kernel-tools-libs kernel-tools-libs-devel 
perf python3-perf
Size: 13.26 MiB
Size change:  3.40 KiB
Changelog:
  * Fri Oct 18 2019 Laura Abbott  - 5.3.7-300
  - Linux v5.3.7


Package:  libdnf-0.35.3-6.fc31
Old package:  libdnf-0.35.3-5.fc31
Summary:  Library providing simplified C and Python API to libsolv
RPMs: libdnf libdnf-devel python3-hawkey python3-libdnf
Size: 7.52 MiB
Size change:  -22.89 KiB
Changelog:
  * Mon Oct 21 2019 Ales Matej  - 0.35.3-6
  - Fixes for some issues on Arm platforms (RhBug:1691430)


Package:  python-meh-0.48-1.fc31
Old package:  python-meh-0.47-3.fc31
Summary:  A python library for handling exceptions
RPMs: python3-meh python3-meh-gui
Size: 112.98 KiB
Size change:  1.35 KiB
Changelog:
  * Wed Oct 23 2019 Martin Kolman  - 0.48-1
  - Handle bytes and strings from RPM (#1764642) (vponcova)


Package:  rpm-4.15.0-6.fc31
Old package:  rpm-4.15.0-3.fc31
Summary:  The RPM package management system
RPMs: python2-rpm python3-rpm rpm rpm-apidocs rpm-build rpm-build-libs 
rpm-cron rpm-devel rpm-libs rpm-plugin-audit rpm-plugin-ima 
rpm-plugin-prioreset rpm-plugin-selinux rpm-plugin-syslog 
rpm-plugin-systemd-inhibit rpm-sign rpm-sign-libs
Size: 8.50 MiB
Size change:  13.19 KiB
Changelog:
  * Mon Oct 21 2019 Stephen Gallagher  - 4.15.0-5
  - Revert aliasing arm64 to aarch64
  - Resolves: rhbz#1763831

  * Wed Oct 23 2019 Peter Robinson  4.15.0-6
  - Revert armv8 detection improvements



= DOWNGRADED PACKAGES =
___
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-31-20191024.n.2 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 3/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191024.n.0):

ID: 476418  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/476418
ID: 476497  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/476497

Old failures (same test failed in Fedora-31-20191024.n.0):

ID: 476365  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/476365
ID: 476427  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/476427

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

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

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

Old soft failures (same test soft failed in Fedora-31-20191024.n.0):

ID: 476404  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/476404
ID: 476483  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/476483

Passed openQA tests: 147/153 (x86_64)

New passes (same test not passed in Fedora-31-20191024.n.0):

ID: 476423  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/476423
ID: 476493  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/476493
ID: 476494  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/476494
ID: 476499  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/476499

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
System load changed from 0.45 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/475917#downloads
Current test data: https://openqa.fedoraproject.org/tests/476398#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 905 MiB to 723 MiB
System load changed from 2.28 to 0.61
Average CPU usage changed from 40.34285714 to 3.55714286
Previous test data: https://openqa.fedoraproject.org/tests/475930#downloads
Current test data: https://openqa.fedoraproject.org/tests/476411#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 1.23 to 0.75
Previous test data: https://openqa.fedoraproject.org/tests/475932#downloads
Current test data: https://openqa.fedoraproject.org/tests/476413#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.50 to 0.39
Average CPU usage changed from 18.53809524 to 5.60952381
Previous test data: https://openqa.fedoraproject.org/tests/475948#downloads
Current test data: https://openqa.fedoraproject.org/tests/476429#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Used swap changed from 4 MiB to 5 MiB
Previous test data: https://openqa.fedoraproject.org/tests/475950#downloads
Current test data: https://openqa.fedoraproject.org/tests/476431#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
System load changed from 3.85 to 2.65
Average CPU usage changed from 83.52380952 to 35.76190476
Previous test data: https://openqa.fedoraproject.org/tests/476023#downloads
Current test data: https://openqa.fedoraproject.org/tests/476504#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: Intent to replace bzr (bazaar) with brz (breezy)

[Miro Hrončok]

On 08. 10. 19 14:26, Miro Hrončok wrote:

On 08. 10. 19 14:04, Miro Hrončok wrote:

On 08. 10. 19 13:53, Peter Robinson wrote:

bzr (bazaar) FTBFS and is orphaned.

I have a Python 3 replacement called breezy (brz) ready, but it has some
problems with remote repositories on Python 3.8, so I was not ready to build 
it,

obsolete bzr and have a broken alternative.

However, bzr now also fails to install, so it cannot be any more broken than it
already is. I intent to build and ship half-broken breezy to obsolete
fully-broken bazaar sometimes this week.


Shouldn't this be a change so it can be more easily found for issues
etc than just on devel@ list and go through the right process?


Good point. Will do.


Here https://fedoraproject.org/wiki/Changes/ReplaceBazaarWithBreezy


Done.

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

review swap for wdune (white_dune)

[J. Scheurich]

Hi,

Cause the last review is too old, i need a fresh review for wdune
(white_dune):

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

This package requires vcglib:

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

I'm available for any review in exchange.

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

[Test-Announce] Fedora 31 testing required: F29 and F30 libdnf / gnome-software updates

[Adam Williamson]

Hi folks! While F31 is signed off, there's still some testing required.
There are two updates, one each for F29 and F30, which must be pushed
stable before the release date:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-2fb39de3ce (F29)
https://bodhi.fedoraproject.org/updates/FEDORA-2019-2368fc415f (F30)

These updates work around the libgit2 module problems on upgrade. What
they should achieve is, when upgrading from F29 to F31 or F30 to F31
using gnome-software, the 'libgit2' module should get reset, avoiding
any problems with installed packages that require libgit 0.27.

To reproduce the problem, install F29 or F30 Workstation, install 'kf5-
ktexteditor' package (which pulls in libgit2 0.27), and try to upgrade
to F31 using gnome-software (you will need to run `gsettings set
org.gnome.software show-upgrade-prerelease true`, as your user not as
root, to make the upgrade appear). When you hit the 'install' button
after 'download' step is complete, you should see a warning that kf5-
ktexteditor will be removed. If you retry with the updated gnome-
software and libdnf from the update - you will need to re-trigger the
download step somehow, I find a reboot should clear the state - it
should work correctly, there should be no warning and after the
upgrade, kf5-ktexteditor should be installed along with a non-modular
libgit2 0.28 package.

If folks can test these updates and provide karma that'd be a great
help! Thanks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 Final is GO

[Matthew Miller]

On Thu, Oct 24, 2019 at 11:40:22AM -0400, Ben Cotton wrote:
> For more information please check the Go/No-Go meeting minutes [2] or logs 
> [3].
> Thank you to everyone who has worked on this release and getting it out on 
> time.

Yes! Special thinks to everyone who worked extra hard to make sure we ship a
high quality release on time. It really does make a big difference to our
users and to our reputation.

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

[Test-Announce] Fedora 31 Final is GO

[Ben Cotton]

The Fedora 31 Final RC1.9 compose [1] is GO and will be shipped live
on Tuesday, 29 October 2019.

For more information please check the Go/No-Go meeting minutes [2] or logs [3].

Thank you to everyone who has worked on this release and getting it out on time.

[1] https://dl.fedoraproject.org/pub/alt/stage/31_RC-1.9/
[2] 
https://meetbot.fedoraproject.org/fedora-meeting/2019-10-24/f31-final-go_no_go-meeting.2019-10-24-14.00.txt
[3] 
https://meetbot.fedoraproject.org/fedora-meeting/2019-10-24/f31-final-go_no_go-meeting.2019-10-24-14.00.log.html
-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

No NeuroFedora meeting today (Was: Re: New meeting time: whenisgood)

[Ankur Sinha]

Hello!

We won't have a meeting today. If you've not filled the whenisgood yet,
please do so. We will continue meetings next week at the new time.

http://whenisgood.net/ips5zm2

I will close the whenisgood at 2359 UTC later today (in about 9 hours)
so that I can announce the new time tomorrow. Please ensure that you've
filled in before then.

-- 
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: Modularity and all the things

[Randy Barlow]

On Thu, 2019-10-24 at 08:09 -0400, Stephen Gallagher wrote:
> There's a very large difference between feedback like "I think the
> user experience is suboptimal here, for this reason" and "I don't
> like the entire design, you should scrap it and start over".
> 
> In the first case, it's possible to incorporate that into an existing
> project if the benefits justify the investment. In the latter case,
> it requires a *substantial* reinvestment in work while simultaneously
> demoralizing and disrespecting the people who have been working on
> it. It's a fundamental difference between constructive and
> destructive criticism.

It's possible to respectfully suggest that an entirely different design
is worth considering. I believe that my messages have been respectful.
If you think I have not been respectful, please let me know.

I agree that the suggestion can be demoralizing, and I hope you know me
well enough to know that I am not trying to demoralize anyone. I don't
know if there's a way to avoid demoralizing while also retaining open
discourse, one of the key properties of open source.

I respect the people who have made modularity go. That doesn't mean I
have to agree with the solution, or that I should not speak up when I
know an easier way. Bad things happen when people don't speak up when
they see problems.


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

Re: [feedback needed] VirtIO Windows Drivers - new installer

[François Kooman]

On 24.10.19 13:35, Sandro Bonazzola wrote:
> Please give it a run on your testing environment / testing VMs and let
> us know about your experience at de...@ovirt.org .

Works great in Windows 10 on GNOME Boxes (Fedora 30)! Until now I wasn't
able to get automatic display resolution changing working (based on size
of Boxes window), but that started working right after installing!

Will this also be integrated in the (unattended) Windows 10 installation
from GNOME Boxes so it will work out of the box?

Thanks,
François
___
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: Modularity and all the things

[Randy Barlow]

On Wed, 2019-10-23 at 12:58 -0400, Matthew Miller wrote:
> Are you proposing to _do_ those things, or proposing that someone
> else
> oughta?

This feels like an attempt to suggest that I have made a demand when I
have not. I'm willing to give you the benefit of the doubt, but I
suggest avoiding language like this in the future because it seems like
a false accusation.

If the above was written in good faith, it is at best a false
dichotomy. As Zbigniew said elsewhere, just because someone does the
work does not mean that the distribution is obligated to accept it.

I think we have seen compelling arguments as to why the distribution
should disable modularity by default, and so that is what I and others
are proposing. We gave it a fair chance.

The question remains however, why not just use the time tested
strategies that other distributions have employed to address the "too
fast, too slow" problem for over a decade? I say that as a helpful
suggestion, not as a demand - it would save those who are doing the
work a lot of work, and it would avoid the contentious threads that
happen over and over again. Plus, other distributions have proven that
it works.


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

Fedora-31-20191024.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/153 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20191023.n.0):

ID: 475942  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/475942
ID: 476012  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/476012
ID: 476013  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/476013
ID: 476018  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/476018

Old failures (same test failed in Fedora-31-20191023.n.0):

ID: 475884  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/475884
ID: 475946  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/475946

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

Old soft failures (same test soft failed in Fedora-31-20191023.n.0):

ID: 475923  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/475923
ID: 476002  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/476002

Passed openQA tests: 146/153 (x86_64)

Skipped non-gating openQA tests: 1 of 155

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
3 packages(s) added since previous compose: criu, libnet, runc
System load changed from 0.58 to 0.42
Average CPU usage changed from 6.34761905 to 18.31904762
Previous test data: https://openqa.fedoraproject.org/tests/474844#downloads
Current test data: https://openqa.fedoraproject.org/tests/475915#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
3 packages(s) added since previous compose: criu, libnet, runc
System load changed from 0.57 to 0.45
Previous test data: https://openqa.fedoraproject.org/tests/474846#downloads
Current test data: https://openqa.fedoraproject.org/tests/475917#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.52 to 2.28
Average CPU usage changed from 30.17142857 to 40.34285714
Previous test data: https://openqa.fedoraproject.org/tests/474859#downloads
Current test data: https://openqa.fedoraproject.org/tests/475930#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
Used mem changed from 727 MiB to 902 MiB
System load changed from 1.95 to 1.23
Average CPU usage changed from 1.4 to 20.71904762
Previous test data: https://openqa.fedoraproject.org/tests/474861#downloads
Current test data: https://openqa.fedoraproject.org/tests/475932#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.62 to 0.50
Previous test data: https://openqa.fedoraproject.org/tests/474877#downloads
Current test data: https://openqa.fedoraproject.org/tests/475948#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
Mount /run contents changed to 69.90005879% of previous size
Used swap changed from 7 MiB to 4 MiB
Previous test data: https://openqa.fedoraproject.org/tests/474879#downloads
Current test data: https://openqa.fedoraproject.org/tests/475950#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
1 services(s) removed since previous compose: pcscd.service
System load changed from 0.65 to 3.85
Average CPU usage changed from 22.77142857 to 83.52380952
Previous test data: https://openqa.fedoraproject.org/tests/474952#downloads
Current test data: https://openqa.fedoraproject.org/tests/476023#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 compose report: 20191024.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20191023.n.0
NEW: Fedora-31-20191024.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:3
Upgraded packages:   2
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:7.47 MiB
Size of upgraded packages:   145.11 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-31-20191023.n.0-sda.raw.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: oci-register-machine-0-11.git66fa845.fc31
Summary: Golang binary to register OCI containers with systemd-machined
RPMs:oci-register-machine
Size:6.99 MiB

Package: oci-systemd-hook-1:0.2.0-2.git05e6923.fc31
Summary: OCI systemd hook for docker
RPMs:oci-systemd-hook
Size:187.38 KiB

Package: system-config-users-docs-1.0.9-15.fc31
Summary: Documentation for administering users and groups
RPMs:system-config-users-docs
Size:301.22 KiB


= UPGRADED PACKAGES =
Package:  grub2-1:2.02-100.fc31
Old package:  grub2-1:2.02-98.fc31
Summary:  Bootloader with support for Linux, Multiboot and more
RPMs: grub2-common grub2-efi-aa64 grub2-efi-aa64-cdboot 
grub2-efi-aa64-modules grub2-efi-arm grub2-efi-arm-cdboot grub2-efi-arm-modules 
grub2-efi-ia32 grub2-efi-ia32-cdboot grub2-efi-ia32-modules grub2-efi-x64 
grub2-efi-x64-cdboot grub2-efi-x64-modules grub2-emu grub2-emu-modules grub2-pc 
grub2-pc-modules grub2-ppc64le grub2-ppc64le-modules grub2-tools 
grub2-tools-efi grub2-tools-extra grub2-tools-minimal
Size: 36.92 MiB
Size change:  -8.58 KiB
Changelog:
  * Wed Oct 09 2019 Javier Martinez Canillas  - 2.02-99
  - 99-grub-mkconfig: Disable BLS usage for Xen DomU guests
Resolves: rhbz#1703700

  * Thu Oct 10 2019 Javier Martinez Canillas  - 2.02-100
  - 99-grub-mkconfig: Fix script condition to exit and remove ppc64 BE check
Related: rhbz#1703700


Package:  podman-2:1.6.2-2.fc31
Old package:  podman-2:1.6.1-2.fc31
Summary:  Manage Pods, Containers and Container Images
RPMs: podman podman-docker podman-manpages podman-remote podman-tests
Size: 108.19 MiB
Size change:  996.13 KiB
Changelog:
  * Tue Oct 08 2019 Lokesh Mandvekar  - 2:1.6.1-3
  - add Recommends: runc for fedora

  * Wed Oct 09 2019 Lokesh Mandvekar  - 2:1.6.1-4
  - Requires: crun >= 0.10.2-1 and polkit

  * Wed Oct 09 2019 Lokesh Mandvekar  - 2:1.6.1-5
  - remove polkit dependency for now

  * Wed Oct 16 2019 RH Container Bot  - 
2:1.6.2-0.2.rc1
  - bump to v1.6.2-rc1
  - autobuilt 4d653f0

  * Thu Oct 17 2019 RH Container Bot  - 
2:1.6.2-2
  - bump to v1.6.2
  - autobuilt f3ffda1



= DOWNGRADED PACKAGES =
___
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: Modularity and all the things

[Lukas Ruzicka]

*There's a very large difference between feedback like "I think the user
experience is suboptimal here, for this reason" and "I don't like the
entire design, you should scrap it and start over".*

Well, I can agree with that.


>
> In the first case, it's possible to incorporate that into an existing
> project if the benefits justify the investment. In the latter case, it
> requires a *substantial* reinvestment in work while simultaneously
> demoralizing and disrespecting the people who have been working on it. It's
> a fundamental difference between constructive and destructive criticism.
>
> By all means, if there are user experience problems, highlight those.
>

I was already trying to point things out from my perspective while testing
modularity in Fedora:

   1. You cannot choose if you want to be modular, you just become modular
   when installing applications that depend on modules. At this status quo,
   this behaviour is hard to accept.
   2. Broken upgrades for users with libgit2 - instead of a proper solution
   we have implemented a hack to reset the libgit2 module and thus enable to
   upgrade. If users knew about this (because they would have opted-in), they
   would be able to reset libgit2 for themselves and we would not need to hack
   it.
   3. I do not understand why we want to hide modularity from users by
   shipping default modules to make users not notice we are modular. What is
   wrong about non-modular defaults and modular streams for various use cases?
   Nobody has ever explained why having everything modular is so much better.
   4. Why absence of modular repos will break the system? Why cannot users
   choose what they need best?
   5. Some modules are not correctly formed according to criteria, we have
   agreed upon. Bugs were opened.
   6. Some streams are not correctly formed. Bugs were opened.
   7. Some modules still do not have a yaml file in the
   fedora-module-defaults, you especially told me they must have it.
   8. Naming conventions are not good, streams are named ad hoc.
   9. Some modules cannot be installed on Fedora 31 due broken
   dependencies. Bugs opened.
   10. Yet, many bugs I open against particular modules remain unresolved.
   11. Even the testmodule, which should be there for people to look at how
   to do it, is broken.

And this all will be shipped with Fedora 31, because we block on DNF
behaviour but not on modular sanity.


> Just don't draw the conclusion that the whole system is unsalvageable. Let
> the team that's working on it figure out if there's a way to fix the UX or
> if it truly does mean that a structural flaw exists in the design. The
> Modularity Team is reading these threads and is keeping notes on all of the
> legitimate issues raised. As of right now, we don't feel that the situation
> is unrecoverable.
>
>
I did not say anything like that.

Please keep your suggestions constructive. Tell us where we are falling
short. We are listening. We're just not ready to throw away years of work
because it isn't perfect yet. If we did that every time, we'd never get
anywhere. We wouldn't have taken projects like systemd, KDE 4,
NetworkManager, and GNOME 3 from their rocky starts to where they are now.
All of those examples were hard-fought changes that brought considerable
instability to Fedora when they initially landed and now are cornerstones
of the Fedora story.

Do you point this to me or is it a general statement? I will go with the
second here, because I have never said that anybody should throw their
entire work away. I have only been consistently suggesting to have
modularity opt-in *until the problems are fully solved*.

Right now, they are not fully solved and we still force modularity upon our
users. I do not think this is correct from the QE perspective.

I cannot help you to code, since I am not as good,  and I have never
commented on how you decide to make things work.
I am pointing to things that do not work, and I will be doing it again and
again, because I believe it is part of my job to make sure the users get
what they deserve.



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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Gu

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
4 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 16/153 (x86_64), 1/2 (arm)

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

ID: 475694  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/475694
ID: 475720  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/475720
ID: 475726  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/475726

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

ID: 475592  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/475592
ID: 475606  Test: x86_64 Server-dvd-iso server_cockpit_updates
URL: https://openqa.fedoraproject.org/tests/475606
ID: 475633  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/475633
ID: 475636  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/475636
ID: 475641  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/475641
ID: 475650  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/475650
ID: 475652  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/475652
ID: 475654  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/475654
ID: 475664  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/475664
ID: 475704  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/475704
ID: 475710  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/475710
ID: 475734  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/475734
ID: 475735  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/475735
ID: 475736  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/475736

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

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

ID: 475586  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/475586
ID: 475587  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/475587
ID: 475621  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/475621
ID: 475622  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/475622
ID: 475646  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/475646
ID: 475677  Test: x86_64 universal install_kickstart_firewall_disabled
URL: https://openqa.fedoraproject.org/tests/475677
ID: 475678  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/475678
ID: 475684  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/475684
ID: 475723  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/475723
ID: 475728  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/475728
ID: 475737  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/475737

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

ID: 475588  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/475588
ID: 475590  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/475590
ID: 475601  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/475601
ID: 475603  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/475603
ID: 475611  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/475611
ID: 475616  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/475616
ID: 475619  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: ht

Re: Modularity and the system-upgrade path

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 24, 2019 at 12:42:27PM +0200, Kevin Kofler wrote:
> Neal Gompa wrote:
> 
> > On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka  wrote:
> >> I believe, that if modularity was opt-in, we would be able to use it just
> >> fine, as it is designed now with some little tweakings, such as DNF
> >> providing enough info on retired or discontinued streams, offering a
> >> possibility to choose a different stream to switch to on upgrades. The
> >> longing for default modular Fedora is what makes it more problematic,
> >> because we need to hide everything from the users and make everything
> >> work automatically. If modularity was a matter of personal choice we
> >> would not have to hide anything from anybody, because those users would
> >> be able to read the necessary documentation and tweak their systems just
> >> fine.
> > 
> > Unfortunately there have also been major performance regressions
> > because of the additional work to handle modules being default
> > enabled. The current handling of modules in DNF is not cheap. I'm not
> > sure if this is because it uses libmodulemd1 vs libmodulemd2 or if
> > it's because modules aren't implemented at the libsolv layer and can't
> > be computed as part of the initial constraint set through the base
> > solver. But whatever the reason, it is markedly slower than on systems
> > that don't have modular repositories at all.
> 
> All these are convincing technical arguments for disabling Modularity by 
> default from F32 onwards. (It is unfortunate that these have not been 
> considered for the existing releases, but we cannot turn the time back, we 
> have to focus on improving things for the upcoming releases, hence "from F32 
> onwards". I would even propose it from F31 onwards, but I do not think FESCo 
> is willing to delay the F31 release long enough to implement the required 
> demodularization upgrade path in DNF, hence F32.)

Yes, F32. Doing any significant changes to F31 at this point is out of question.
Please remember that if this path is taken, we'll have to demodularize various
packages, and this will take time too.

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

Re: Modularity and all the things

[Stephen John Smoogen]

On Thu, 24 Oct 2019 at 08:10, Stephen Gallagher  wrote:
>
>
>
> On Thu, Oct 24, 2019 at 4:45 AM Lukas Ruzicka  wrote:
>>
>>
>>
>>> Are you proposing to _do_ those things, or proposing that someone else
>>> oughta?
>>
>>
>> This is an unfair statement!
>>
>> I thought Fedora is a community of people. In the community, we have
>> programmers, visionaries, idealists, testers, graphics ... and we also have 
>> users, that only know
>> if they like or dislike something, if the want or don'ŧ want to use the 
>> product somehow. Not everybody
>> is a good programmer or a software designer, so they cannot go and make it 
>> betterby themselves,
>> but they can still give valid ideas. And it may be good to hear their voice, 
>> because they may have
>> good ideas, too.
>
>
> There's a very large difference between feedback like "I think the user 
> experience is suboptimal here, for this reason" and "I don't like the entire 
> design, you should scrap it and start over".
>

The problem is that there are two different ideas of what the actual
problems needing fixed are. Many of the people coming up with
solutions feel that you have built a 3 wheeled car
(https://en.wikipedia.org/wiki/Reliant_Robin) and you want it not to
flip over. You instead feel you built a 4 wheeled car but the doors
are stuck a lot (a UX problem). The door problem to them is because
they see the car flipping over a lot.. so maybe start with the wheels
instead of the door.

Whether that is true or not is the difference between virtual reality
and physical reality. If modularity was a real thing you could show
that you do have 4 wheels with equal separation between each axle. In
our virtual world, the picture people are going to have is pretty much
their first impression. Trying to fix that first impression takes a
lot of emotional effort by the people making the product which means
they can't fix the door problem either.

Until we actually agree on what the 'modularity' is, does, and is
going.. I expect that the most common answer here is going to be 'go
back and add a 4th wheel'.


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

Fedora rawhide compose report: 20191024.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20191023.n.0
NEW: Fedora-Rawhide-20191024.n.0

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  1
Dropped packages:23
Upgraded packages:   111
Downgraded packages: 0

Size of added packages:  12.27 MiB
Size of dropped packages:40.00 MiB
Size of upgraded packages:   5.59 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20191024.n.0-sda.raw.xz

= DROPPED IMAGES =
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20191023.n.0.iso

= ADDED PACKAGES =
Package: kitty-0.14.6-12.fc32
Summary: Cross-platform, fast, feature full, GPU based terminal emulator
RPMs:kitty kitty-doc kitty-terminfo
Size:12.27 MiB


= DROPPED PACKAGES =
Package: alacarte-3.11.91-14.fc31
Summary: Menu editor for the GNOME desktop
RPMs:alacarte
Size:129.84 KiB

Package: audio-convert-mod-3.46.0b-18.fc31
Summary: A simple audio file converter that supports many formats
RPMs:audio-convert-mod
Size:56.92 KiB

Package: batti-0.3.8-18.fc31
Summary: Simple battery monitor for the system tray
RPMs:batti
Size:68.45 KiB

Package: chm2pdf-0.9.1-25.fc31
Summary: A tool to convert CHM files to PDF files
RPMs:chm2pdf
Size:26.82 KiB

Package: euca2ools-3.4.1-8.fc31
Summary: Eucalyptus/AWS-compatible command line tools
RPMs:euca2ools
Size:789.58 KiB

Package: func-0.30-16.fc31
Summary: Remote management framework
RPMs:func
Size:345.42 KiB

Package: ginfo-1.0.3-13.fc31
Summary: A versatile tool for discovering Grid services
RPMs:ginfo
Size:13.80 KiB

Package: gnome-python2-extras-2.25.3-57.fc32
Summary: Additional PyGNOME Python extension modules
RPMs:gnome-python2-extras gnome-python2-gtkspell
Size:205.20 KiB

Package: gstreamer-python-0.10.22-21.fc31
Summary: Python bindings for GStreamer
RPMs:gstreamer-python-devel python2-gstreamer
Size:2.10 MiB

Package: laditools-1.1.0-3.20160307git97b8cf3.fc31
Summary: Set of tools to control and monitor LADI system
RPMs:laditools
Size:234.89 KiB

Package: oci-register-machine-0-11.git66fa845.fc31
Summary: Golang binary to register OCI containers with systemd-machined
RPMs:oci-register-machine
Size:6.99 MiB

Package: oci-systemd-hook-1:0.2.0-2.git05e6923.fc31
Summary: OCI systemd hook for docker
RPMs:oci-systemd-hook
Size:187.38 KiB

Package: openxcap-2.2.0-3.fc31
Summary: Fully featured XCAP server
RPMs:openxcap
Size:211.84 KiB

Package: python-backports-ssl_match_hostname-3.5.0.1-12.fc31
Summary: The ssl.match_hostname() function from Python 3
RPMs:python2-backports-ssl_match_hostname
Size:16.33 KiB

Package: python-chm-0.8.4-26.fc29
Summary: Python package for CHM files handling
RPMs:python2-chm
Size:235.93 KiB

Package: python-openid-2.2.5-21.fc31
Summary: Python OpenID libraries
RPMs:python2-openid
Size:200.44 KiB

Package: python-progressbar-2.3-16.20170808git32422c1.fc31
Summary: Text progressbar library for python
RPMs:python2-progressbar
Size:24.67 KiB

Package: python-qpid-1.37.0-8.fc31
Summary: Python client library for AMQP
RPMs:python2-qpid qpid-tests
Size:477.43 KiB

Package: qpid-cpp-1.39.0-5.fc31
Summary: Libraries for Qpid C++ client applications
RPMs:perl-qpid-messaging python2-qpid-messaging python2-qpid-qmf 
qpid-cpp-client qpid-cpp-client-devel qpid-cpp-client-docs qpid-cpp-client-rdma 
qpid-cpp-server qpid-cpp-server-ha qpid-cpp-server-linearstore 
qpid-cpp-server-rdma qpid-qmf qpid-qmf-devel qpid-tools
Size:25.01 MiB

Package: radiotray-0.7.3-14.fc31
Summary: Radio Tray is a streaming player for listening to online radios
RPMs:radiotray
Size:150.18 KiB

Package: system-config-users-docs-1.0.9-15.fc31
Summary: Documentation for administering users and groups
RPMs:system-config-users-docs
Size:301.22 KiB

Package: winswitch-0.12.21-27.fc31
Summary: Utility for controlling remote desktop sessions
RPMs:winswitch
Size:1.48 MiB

Package: zynjacku-6-25.fc31
Summary: LV2 synths and plugins host
RPMs:zynjacku
Size:857.06 KiB


= UPGRADED PACKAGES =
Package:  R-ncdf4-1.17-1.fc32
Old package:  R-ncdf4-1.16.1-2.fc31
Summary:  Interface to Unidata netCDF (Version 4 or Earlier) Format Data 
Files
RPMs: R-ncdf4
Size: 1.43 MiB
Size change:  17.58 KiB
Changelog:
  * Wed Oct 23 2019 Elliott Sales de Andrade  - 
1.17-1
  - Update to latest version


Package:  SuperLUMT-3.1.0-23.fc32
Old package:  SuperLUMT-3.1.0-22.fc31
Summary:  Single precision real SuperLU routines for shared memory parallel 
machines
RPMs: SuperLUMT SuperLUMT-common SuperLUMT-complex SuperLUMT-complex16 
SuperLUMT-devel SuperLUMT-double SuperLUMT64 SuperLUMT64-complex 
SuperLUMT64

Re: Modularity and all the things

[Stephen John Smoogen]

On Thu, 24 Oct 2019 at 06:55, Kevin Kofler  wrote:
>
> IMHO:
>
> Igor Gnatenko wrote:
> > * Do we want to support "buildroot-only" packages?
>
> No, because this contradicts both the transparency expected from a
> community-developed project and the self-hosting expectations.
>

I am in agreement with Kevin on this. I find that the self-hosting
expectation (the hood of the car is not welded shut) is what makes me
interested in working on Linux distributions. That said, I also
understand one reason why there are buildroot-only packages: lots of
software needs 'extra' things and there are not enough packagers to
cover all of them at the same level as leaf and some core packages.
(Hypothetical) If I need libfoo to build libreoffice and I don't want
to support/trackdown bugs on libfoo then I either drop libreoffice,
make a half-ass job on libfoo, or try to do both and burn out because
libreoffice is going to take 150% of my time anyway. Being able to put
a libfoo in a 'yeah its there but if you open bugs on it .. no one is
going to really fix them unless they affect my package libreoffice' is
very appealing.

> > * Do we want to build streams against all combinations (aka
> > py{2,3}+nodejs{8,9,10}+fedora{30,31,32} would result into 18 builds of
> > a packages)?
>
> For modules that depend on both Python and NodeJS, that is what it would
> boil up to indeed. And it should be clear that this does not scale. This was
> one of the inherent design issues I had pointed out with Modularity from day
> one: the promise that you can pick&choose arbitrary versions to mix&match at
> will only works if packages are isolated islands (or at least leaves), but
> not in the real world where there are interdependencies everywhere. The more
> libraries get modularized and the more alternative versions get offered, the
> worse the combinatorial explosion will become. (The number of combinations
> grows exponentially with the number of modular dependencies, and linearly
> with the number of alternative versions for every single module.)

Again agreed. Mathematically this is going to grow immensely because
each packager is going to do their own thing ot get the job done and
you are going to end up with 100 minidistributions with a larger
bureaucracy than we have currently to make sure things aren't stepping
on each others toes all the time.

> I guess that in the end, you will have to leave that decision (which
> combinations of dependency versions to support) to the maintainer of the
> module (in your example, the one that depends on both Python and NodeJS),
> which will necessarily leave some users in the cold because their choice of
> combination of versions is not supported. But I do not see another option,
> also because which depencency versions can be supported also depends on
> upstream.
>
> 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



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

Re: Modularity and all the things

[Stephen Gallagher]

On Thu, Oct 24, 2019 at 4:45 AM Lukas Ruzicka  wrote:

>
>
> Are you proposing to _do_ those things, or proposing that someone else
>> oughta?
>>
>
> This is an unfair statement!
>
> I thought Fedora is a community of people. In the community, we have
> programmers, visionaries, idealists, testers, graphics ... and we also
> have users, that only know
> if they like or dislike something, if the want or don'ŧ want to use the
> product somehow. Not everybody
> is a good programmer or a software designer, so they cannot go and make it
> betterby themselves,
> but they can still give valid ideas. And it may be good to hear their
> voice, because they may have
> good ideas, too.
>

There's a very large difference between feedback like "I think the user
experience is suboptimal here, for this reason" and "I don't like the
entire design, you should scrap it and start over".

In the first case, it's possible to incorporate that into an existing
project if the benefits justify the investment. In the latter case, it
requires a *substantial* reinvestment in work while simultaneously
demoralizing and disrespecting the people who have been working on it. It's
a fundamental difference between constructive and destructive criticism.

By all means, if there are user experience problems, highlight those. Just
don't draw the conclusion that the whole system is unsalvageable. Let the
team that's working on it figure out if there's a way to fix the UX or if
it truly does mean that a structural flaw exists in the design. The
Modularity Team is reading these threads and is keeping notes on all of the
legitimate issues raised. As of right now, we don't feel that the situation
is unrecoverable.

Please keep your suggestions constructive. Tell us where we are falling
short. We are listening. We're just not ready to throw away years of work
because it isn't perfect yet. If we did that every time, we'd never get
anywhere. We wouldn't have taken projects like systemd, KDE 4,
NetworkManager, and GNOME 3 from their rocky starts to where they are now.
All of those examples were hard-fought changes that brought considerable
instability to Fedora when they initially landed and now are cornerstones
of the Fedora story.
___
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: Modularity and all the things

[Stephen Gallagher]

On Thu, Oct 24, 2019 at 6:56 AM Kevin Kofler  wrote:
>
> IMHO:
>
> Igor Gnatenko wrote:
> > * Do we want to support "buildroot-only" packages?
>
> No, because this contradicts both the transparency expected from a
> community-developed project and the self-hosting expectations.
>

I think there's some confusion about what a "buildroot-only" module
stream is meant to be (at least aspirationally; until Ursa Major we
didn't have the technical implementation for this).

What a "buildroot-only" module should be is a module stream that we
discourage from use at runtime. This does *not* preclude it from being
shipped in the public repositories. Prior to Ursa Major, we didn't
have any way to get these streams into the non-modular buildroot, so
they effectively became modular-dependency-only streams. With recent
changes to support Ursa Major, this problem would go away.

The ideal behavior would be for there to be UX that lets users know
that if they enable one of these streams, it's
unsupported/unsupportable (such as if they tried to use a
stripped-down version of a build tool). The module streams have a
"description" field that we should require to contain this
information, as well as setting the "api" field to an empty list. I
don't see any reason that we couldn't then ship these streams in the
public repos, unless I'm forgetting something.
___
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: utf8cpp major update

[Dominik 'Rathann' Mierzejewski]

On Wednesday, 23 October 2019 at 16:27, Dominik 'Rathann' Mierzejewski wrote:
[...]
> Only one (ledger) requires some porting as it's using a deprecated
> method which got dropped in utf8cpp-3.0.

So, the good news is that this is already fixed upstream and I've just
mentioned that in the bug report, too:
https://bugzilla.redhat.com/show_bug.cgi?id=1764254

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

[feedback needed] VirtIO Windows Drivers - new installer

[Sandro Bonazzola]

Hi,
as part of the work on oVirt 4.4, the team rewrote the VirtiIO Windows
Drivers installer using the open source framework WiX.
Thanks to the virtio-win maintainer, the new installer is not shipped
anymore within oVirt Guest Tools ISO: it's shipped now directly into VirtIO
Windows ISO[1]

Please give it a run on your testing environment / testing VMs and let us
know about your experience at de...@ovirt.org.
Thanks,


[1]
https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.173-2/

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV

Red Hat EMEA 

sbona...@redhat.com
*Red Hat respects your work life balance.
Therefore there is no need to answer this email out of your office hours.*
___
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 1765097] [RFE] EPEL8 branch of perl-Browser-Open

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jples...@redhat.com
   Assignee|ppi...@redhat.com   |jples...@redhat.com



--- Comment #1 from Jitka Plesnikova  ---
https://pagure.io/releng/fedora-scm-requests/issue/18739
https://pagure.io/releng/fedora-scm-requests/issue/18740

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-de...@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-de...@lists.fedoraproject.org

Re: How to figure out why is Python 2 in critpath

[Peter Robinson]

On Thu, Oct 24, 2019 at 11:48 AM Miro Hrončok  wrote:

> I've recently updated Python 2 to the penultimate release for Python 2.7:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d3fcae639
>
> Bodhi tells me that Python 2 is in criptpath in Fedora 31. That almost
> gave me a
> heart attack. I've checked in PDC and indeed it is 😱
>
> Reading https://fedoraproject.org/wiki/Critical_path_package
>
> I've installed a F31 mock and install @core and @critical-path-base into
> it. No
> python2.
>
> I've tried to install all the other groups, but mock tells me:
>
>Module or Group 'critical-path-base-apps' is not available.
>Module or Group 'critical-path-base-gnome' is not available.
>Module or Group 'critical-path-base-kde' is not available.
>Module or Group 'critical-path-base-lxde' is not available.
>Module or Group 'critical-path-base-xfce' is not available
>
> How do I find our why is Python 2 in the critical path?
>

Does running scripts/get-critpath from the releng repo give any insight?
___
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: Modularity and all the things

[Kevin Kofler]

Igor Gnatenko wrote:

> On Wed, Oct 23, 2019 at 2:52 PM Petr Šabata  wrote:
>> While these issues are being resolved, we are considering temporarily
>> disallowing default streams in Fedora. I don’t want to abandon the
>> idea completely, as doing so reduces the motivation to actually build
>> modules and reap the benefits they might provide.
> 
> This basically makes modularity not useful for many things:
> 
> 1. People will have to have different workflows between "default"
> version (standard workflow, as we have today) and "modular" version.
> Also that means, on the distribution upgrade maintainers will have to
> do many things to remove modular stream, add old one and upgrade
> non-modular version. This is also not only about maintainers, but end
> users too:
> 
> FXX: fish 3.x is non-modular, stream 4.x exists
> FXX+1: fish 4.x is non-modular, stream 3.x exists
> 
> * If user wants to stay on 3.x, he needs to enable stream explicitly
> *after* upgrade and then downgrade the package (which is actually
> unsupported).
> * If user wants to stay on 4.x, he needs to enable stream explicitly
> during FXX (which is totally fine), but after upgrade he has to
> explicitly disable it.

I think the right approach would just be to have both fish 3.x and 4.x as 
module streams for all releases, independently of what they ship:

> Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that
> means:
> 
> * Maintainer has to maintain that version *twice* (modular and
> non-modular version)

It should just be a matter of git merge (usually a fast forward) and fedpkg 
build.

> * Nobody can guarantee that those will be compatible

If they are built from the same specfile and against the same libraries (the 
distro defaults, not other modules, but that would be the default if you do 
not specificially specify otherwise in your module metadata), why would they 
not?

But of course, there is no *guarantee* that a module stream is compatible 
with the default, non-modular version. That is why they are alternate 
streams to begin with.

> 2. In Rust we use modularity to build bunch of packages, filter
> buildroot-only packages and ship only one user-facing RPM. If we
> remove default stream, people won't be ever able to do `dnf install
> ripgrep'. This is worst UX we can provide.

This means that the packaging guidelines for Rust need to be improved. If 
you need a build-time dependency to build the package, it needs to be 
shipped, so that users can reproduce the build and so that they can compile 
other Rust software.

> I think problems with modularity is not about packager experience or
> some missing features (e.g. I'm waiting for some features for 1+
> years, but that's not crucial). The problem is that we don't have
> well-defined *user* experience.
> 
> Do you think you will be able to come up with some exhaustive
> documentation how installation/upgrades/downgrades/switches/whatnot
> should look like in modularity? I would imagine you need at least 70
> "test-cases" for simple things.

That part, I mostly agree with. I think the packager experience is also 
lacking and that this cannot be neglected either, but the worst is indeed 
the end-user experience. (The promise that users would not notice the 
default streams at all just does not work out. The difference shows in the 
form of upgrade path issues, differences in handling retired packages (due 
to the possible hard dependency on a distro/platform version), performance 
regressions, etc.)

> After last few years with modularity, I don't think it is improving
> but it definitely causes some problems.
> 
> While I would like to achieve goals you stated in the beginning, I
> don't think we are ready to introduce modularity to our users and
> packagers yet. I would like to see it getting back to whiteboard,
> together with our community define behaviors and implement it outside
> of our main infrastructure. Give it feedback for 1-2 releases and if
> it makes sense for people here, get it in here.
> Yes, that means that people who enjoy modularity will have to start
> maintaining non-modular packages again and experiment with modularity
> somewhere else but I don't think it is bad iddea.

That is actually a more radical change than disallowing default streams. It 
would basically disallow default streams too, or allow them only in a
non-default repository (which means that you still have to maintain the
non-modular version).

I would personally be OK with either approach (just disallowing default 
streams or reverting/externalizing Modularity entirely), I am fine with 
everything that makes modules fully optional again, but I guess the former 
would be easier to get consensus on and implement.

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-

Re: Modularity and all the things

[Kevin Kofler]

IMHO:

Igor Gnatenko wrote:
> * Do we want to support "buildroot-only" packages?

No, because this contradicts both the transparency expected from a 
community-developed project and the self-hosting expectations.

> * Do we want to build streams against all combinations (aka
> py{2,3}+nodejs{8,9,10}+fedora{30,31,32} would result into 18 builds of
> a packages)?

For modules that depend on both Python and NodeJS, that is what it would 
boil up to indeed. And it should be clear that this does not scale. This was 
one of the inherent design issues I had pointed out with Modularity from day 
one: the promise that you can pick&choose arbitrary versions to mix&match at 
will only works if packages are isolated islands (or at least leaves), but 
not in the real world where there are interdependencies everywhere. The more 
libraries get modularized and the more alternative versions get offered, the 
worse the combinatorial explosion will become. (The number of combinations 
grows exponentially with the number of modular dependencies, and linearly 
with the number of alternative versions for every single module.)

I guess that in the end, you will have to leave that decision (which 
combinations of dependency versions to support) to the maintainer of the 
module (in your example, the one that depends on both Python and NodeJS), 
which will necessarily leave some users in the cold because their choice of 
combination of versions is not supported. But I do not see another option, 
also because which depencency versions can be supported also depends on 
upstream.

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

Non-responsive maintainer wzzrd

[Michal Konecny]

Hi,

I'm sending this e-mail according to non-responsive maintainer policy 
with link to created issue in bugzilla: 
https://bugzilla.redhat.com/show_bug.cgi?id=1765093


This maintainer has also two other issues on him:
https://bugzilla.redhat.com/show_bug.cgi?id=1605696
https://bugzilla.redhat.com/show_bug.cgi?id=1605738

And PR I sent waiting for review:
https://src.fedoraproject.org/rpms/libyubikey/pull-request/1

If anybody knows how to contact this maintainer, please let him know.

Regards,
Michal

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

How to figure out why is Python 2 in critpath

[Miro Hrončok]

I've recently updated Python 2 to the penultimate release for Python 2.7:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d3fcae639

Bodhi tells me that Python 2 is in criptpath in Fedora 31. That almost gave me a 
heart attack. I've checked in PDC and indeed it is 😱


Reading https://fedoraproject.org/wiki/Critical_path_package

I've installed a F31 mock and install @core and @critical-path-base into it. No 
python2.


I've tried to install all the other groups, but mock tells me:

  Module or Group 'critical-path-base-apps' is not available.
  Module or Group 'critical-path-base-gnome' is not available.
  Module or Group 'critical-path-base-kde' is not available.
  Module or Group 'critical-path-base-lxde' is not available.
  Module or Group 'critical-path-base-xfce' is not available

How do I find our why is Python 2 in the critical path?

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

Re: Modularity and the system-upgrade path

[Kevin Kofler]

Neal Gompa wrote:

> On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka  wrote:
>> I believe, that if modularity was opt-in, we would be able to use it just
>> fine, as it is designed now with some little tweakings, such as DNF
>> providing enough info on retired or discontinued streams, offering a
>> possibility to choose a different stream to switch to on upgrades. The
>> longing for default modular Fedora is what makes it more problematic,
>> because we need to hide everything from the users and make everything
>> work automatically. If modularity was a matter of personal choice we
>> would not have to hide anything from anybody, because those users would
>> be able to read the necessary documentation and tweak their systems just
>> fine.
> 
> Unfortunately there have also been major performance regressions
> because of the additional work to handle modules being default
> enabled. The current handling of modules in DNF is not cheap. I'm not
> sure if this is because it uses libmodulemd1 vs libmodulemd2 or if
> it's because modules aren't implemented at the libsolv layer and can't
> be computed as part of the initial constraint set through the base
> solver. But whatever the reason, it is markedly slower than on systems
> that don't have modular repositories at all.

All these are convincing technical arguments for disabling Modularity by 
default from F32 onwards. (It is unfortunate that these have not been 
considered for the existing releases, but we cannot turn the time back, we 
have to focus on improving things for the upcoming releases, hence "from F32 
onwards". I would even propose it from F31 onwards, but I do not think FESCo 
is willing to delay the F31 release long enough to implement the required 
demodularization upgrade path in DNF, hence F32.)

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

Re: A new workflow for newcomers

[alciregi]

On Wed, 2019-10-23 at 13:00 -0400, Matthew Miller wrote:
> On Tue, Oct 22, 2019 at 12:17:26AM +0200, alcir...@gmail.com wrote:
> > [2] https://fedoraproject.org/wiki/Welcome
> 
> can we get this onto the docs site?

I forgot that.
There is already a PR
https://pagure.io/Fedora-Council/council-docs/pull-request/63


Ciao,
A.

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

Re: Orphaned packages looking for new maintainers

[Miro Hrončok]

On 24. 10. 19 4:21, Michal Ambroz wrote:
> Why I'm not listed as the original owner?

Pagure doesn't know any concept of "original owner". When a package is orphaned 
by releng, the owner is replaced by orphan user. Sometimes, there are 
co-maintainers and they stay as co-miantainers.


I've opened this as a followup:

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

--
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: efivar and mokutil long standing FTBFS

[Leigh Scott]

> On Thu, Oct 24, 2019 at 07:45:03AM -, Leigh Scott wrote:
> 
> 
> mokutil.c:1977:16: error: comparison of integer expressions of different 
> signedness:
> 'unsigned int' and 'int' [-Werror=sign-compare]
>  1977 |  if (salt_size > settings_len - (next - settings)) {
>   |^
> 
> That should be fairly easy to fix...
> 
> Zbyszek

I have a fix for efivar as well but  it only compiles on 64 bit  
https://leigh123linux.fedorapeople.org/pub/patches/0001-fix-ftbfs.patch


https://koji.fedoraproject.org/koji/taskinfo?taskID=38517342
___
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: Modularity and the system-upgrade path

[Neal Gompa]

On Thu, Oct 24, 2019 at 4:31 AM Lukas Ruzicka  wrote:
>
> As far as tooling is concerned, I have been seeing complaints about DNF doing 
> a bad job, but from the perspective of acceptance
> testing, it's the DNF operations that usually work fine with installing, 
> enabling, disabling, removing, resetting and switching modules and streams.
>
> I believe, that if modularity was opt-in, we would be able to use it just 
> fine, as it is designed now with some little tweakings, such as DNF providing 
> enough info on retired or discontinued streams, offering a possibility to 
> choose a different stream to switch to on upgrades. The longing for default 
> modular Fedora is what makes it more problematic, because we need to hide 
> everything from the users and make everything work automatically. If 
> modularity was a matter of personal choice we would not have to hide anything 
> from anybody, because those users would be able to read the necessary 
> documentation and tweak their systems just fine.
>

Unfortunately there have also been major performance regressions
because of the additional work to handle modules being default
enabled. The current handling of modules in DNF is not cheap. I'm not
sure if this is because it uses libmodulemd1 vs libmodulemd2 or if
it's because modules aren't implemented at the libsolv layer and can't
be computed as part of the initial constraint set through the base
solver. But whatever the reason, it is markedly slower than on systems
that don't have modular repositories at all.


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

Re: Modularity and all the things

[Lukas Ruzicka]

On Thu, Oct 24, 2019 at 10:40 AM Igor Gnatenko <
ignatenkobr...@fedoraproject.org> wrote:

>
> This basically makes modularity not useful for many things:
>
> 1. People will have to have different workflows between "default"
> version (standard workflow, as we have today) and "modular" version.
>

I do not think so. If modularity was an opt-in, then people could consume
the default non-modular
content and only switch to modules when they wanted to solve a specific
problem. Those specific
problems were in the beginning to be slower or be faster than the normal
Fedora would be.

 Also that means, on the distribution upgrade maintainers will have to

> do many things to remove modular stream, add old one and upgrade
> non-modular version.


The packagers would probably maintain one non-modular version for each
Fedora release
and other versions in modules, if they liked to.



> This is also not only about maintainers, but end
> users too:
>
> FXX: fish 3.x is non-modular, stream 4.x exists
> FXX+1: fish 4.x is non-modular, stream 3.x exists
>

This is not what I'd expect. I would rather like:

FXX: fish 3 is non-modular, streams 3, 4 exist as modules
FXX+1: fish 4 is non-modular, streams 3, 4 exist as modules.

>From the users' perspective, if I did not care about the fish version and I
only wanted fish, they would do *dnf install fish *which
will result in non-modular content. If someone wanted a specific version of
the fish, they might do
*dnf module install fish:3 *
which would result in a modular fish, of the same version, but this version
would stay on the system as long as the user would switch
manually.

If fish:3 became EOL, DNF would say something like: *The fish:3 stream does
not have a follower in the new Fedora release,*
*what to you want to do:*
*a) switch to a non-modular default (version 4)*
*b) switch to a different modular stream (fish:4)*
*c) switch to a different modular stream (fish:5)*


* Nobody can guarantee that those will be compatible
>

Very true. So we should probably be very much aware of this, because if we
cannot maintain compatibility between single
modular streams, how do we maintain compatibility across all the modules,
default or non-default, in a typical desktop
environment of Fedora?
Or wait, is modularity still the food for containers as advocated in the
beginning? Then we do not have to worry about compatibility
too much, because once you want to switch to a different stream, just
create a new container.


> 2. In Rust we use modularity to build bunch of packages, filter
> buildroot-only packages and ship only one user-facing RPM. If we
> remove default stream, people won't be ever able to do `dnf install
> ripgrep'. This is worst UX we can provide.
>

If DNF said, in this case, something like
*The package you are trying to install is only available as a module, *
*please use dnf module install ripgrep to install it. -> *I do not see that
as the worst UX at all. On the contrary, this
is a clear message to the user that he should either go modular (with
everything it brings) or forget about that package.
The choice remains in their hands.


The problem is that we don't have
> well-defined *user* experience.
>

Agreed 100%.



> After last few years with modularity, I don't think it is improving
> but it definitely causes some problems.
>

> P

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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and all the things

[Igor Gnatenko]

On Wed, Oct 23, 2019 at 7:07 PM Matthew Miller  wrote:
>
> On Wed, Oct 23, 2019 at 12:44:06PM -0400, Randy Barlow wrote:
> > On Wed, 2019-10-23 at 14:41 +0200, Petr Šabata wrote:
> > > We currently don’t have any other proposal that would fulfill the vision
> > > of our Objective and the needs of our users.
> > How do the proposals I've mentioned not fulfill the goals?
>
> Are you proposing to _do_ those things, or proposing that someone else
> oughta?

I agree with Lukas that this is unfair. As we talked on the Flock,
that means only people working @ RH can do such things since they have
dedicated time.

But I would definitely like to do some work in this regard, however, I
can't find full list of things we would like to achieve.

* Do we want to support "buildroot-only" packages?
* Do we want to build streams against all combinations (aka
py{2,3}+nodejs{8,9,10}+fedora{30,31,32} would result into 18 builds of
a packages)?

Those are just few points where I don't know answer. But if you can
provide list of all things we would like to achieve, I can definitely
come up with some proposal.

> --
> 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
___
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: Modularity and all the things

[Lukas Ruzicka]

Are you proposing to _do_ those things, or proposing that someone else
> oughta?
>

This is an unfair statement!

I thought Fedora is a community of people. In the community, we have
programmers, visionaries, idealists, testers, graphics ... and we also have
users, that only know
if they like or dislike something, if the want or don'ŧ want to use the
product somehow. Not everybody
is a good programmer or a software designer, so they cannot go and make it
betterby themselves,
but they can still give valid ideas. And it may be good to hear their
voice, because they may have
good ideas, too.

It is easy to fall in love with someone or something no matter what others
tell me, and
not see any problems and flaws because love can fool us quite well.

In the end . love hurts.



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


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and all the things

[Igor Gnatenko]

Hey Petr,

First of all, thanks for writing this up, much appreciated.

On Wed, Oct 23, 2019 at 2:52 PM Petr Šabata  wrote:
>
> Starting a new thread since the old one is hard to navigate at this point.
>
> Modularity is a distribution-level change and requires some mindset
> shift from packagers and users alike. I understand the concerns some
> people have, feeling it’s something new and half-baked that is being
> forced on them.

I entirely agree with you here. Though I'm not sure if "requires
mindset shift" is good.

> We’re an open source community and in order to drive innovation, we
> need to be able to try new approaches and technologies in the open,
> not develop them without any input and hands-on experience behind
> closed doors, later serving them on a silver plate. The feedback we’re
> getting is extremely valuable, but some of it is too narrowly focused
> on one specific problem area and not taking into account the other
> aspects, requirements, or goals that we’re pursuing. Our objective is
> still to deliver multiple versions, or variants, of our content across
> releases or even distributions (think EPEL or CentOS). And it’s a good
> one.
>
> The concept of default streams was introduced to make modularity
> invisible to anyone who has no interest in alternatives and wants the
> system to operate as it historically has. Whether a specific package
> is delivered via a module or not shouldn’t matter. (This does not mean
> it should be hidden, just that it should have no practical difference
> to the system.) This applies to both buildroots and runtime, leaving
> the choice of whether to modularize or not to the maintainer.
> Obviously, the implementation is falling short in this regard right
> now, but we have solutions in development or under design. This
> includes making the default streams available in the non-modular
> buildroot via Ursa Prime or tracking the module enablement intent in
> our software management stack, as Stephen suggested in the original
> post.
>
> While these issues are being resolved, we are considering temporarily
> disallowing default streams in Fedora. I don’t want to abandon the
> idea completely, as doing so reduces the motivation to actually build
> modules and reap the benefits they might provide.

This basically makes modularity not useful for many things:

1. People will have to have different workflows between "default"
version (standard workflow, as we have today) and "modular" version.
Also that means, on the distribution upgrade maintainers will have to
do many things to remove modular stream, add old one and upgrade
non-modular version. This is also not only about maintainers, but end
users too:

FXX: fish 3.x is non-modular, stream 4.x exists
FXX+1: fish 4.x is non-modular, stream 3.x exists

* If user wants to stay on 3.x, he needs to enable stream explicitly
*after* upgrade and then downgrade the package (which is actually
unsupported).
* If user wants to stay on 4.x, he needs to enable stream explicitly
during FXX (which is totally fine), but after upgrade he has to
explicitly disable it.

Obviously you can have 3.x stream for FXX and 4.x for FXX+1, but that means:

* Maintainer has to maintain that version *twice* (modular and
non-modular version)
* Nobody can guarantee that those will be compatible

2. In Rust we use modularity to build bunch of packages, filter
buildroot-only packages and ship only one user-facing RPM. If we
remove default stream, people won't be ever able to do `dnf install
ripgrep'. This is worst UX we can provide.

> Yes, modularity still has some additional development ahead. We need
> to improve the software management stack experience; we need to
> revisit our release engineering SOPs; we need to stabilize and boost
> performance of our infrastructure; and last but not least, we need to
> improve the packager experience, providing more features to make the
> creation of modules easier, as well as guidance, best practices and
> policies that make it easy to collaborate. These changes are similar
> to those for other useful but disruptive technologies that Fedora has
> successfully introduced in the past.

I think problems with modularity is not about packager experience or
some missing features (e.g. I'm waiting for some features for 1+
years, but that's not crucial). The problem is that we don't have
well-defined *user* experience.

Do you think you will be able to come up with some exhaustive
documentation how installation/upgrades/downgrades/switches/whatnot
should look like in modularity? I would imagine you need at least 70
"test-cases" for simple things.

> I do believe we all intend the best, even if we sometimes disagree. We
> currently don’t have any other proposal that would fulfill the vision
> of our Objective and the needs of our users. The input here helps us
> re-focus on the most acute pain points but the manpower and control we
> have is also rather limited. If you want to and can help with the
> implementat

Re: Modularity and the system-upgrade path

[Lukas Ruzicka]

This is a policy choice, not a technical matter. If modules became more
> popular, and the dependencies between modules grew, we'd need
> to settle on similar rules, where bigger changes are done with a certain
> cadence. This is why I think that the "independent lifecycles for modules"
> are illusory, made possible by current scarcity of modules.
>

Currently (F31), there are about 63 modules listed with *dnf module list*.
I have attempted to install all modules and all streams. Between single
installations
I always reverted the system to its default state, i.e. modular repos
enabled, but no
modules installed, enabled, disabled or anything.

>From those 63 modules,

   - about 18 are not correctly defined according to criteria that I had
   agreed on with Stephen, https://pagure.io/modularity/issue/149.
   - about 8 modules cannot be installed because of some dependency
   problems: #1764546, #1764616, #1764623, #1764624, #1764606, #1764606,
   #1764611, #1764604

In some of the cases, packagers themselves report that the particular
module should NOT be included
in that particular version of Fedora, currently 31, but they still ARE.

So, not just the tooling, the content is problematic as well, it is not
ready and nobody seems to care, as there
are bugs reported that have not been resolved for several weeks. And since
we do not currently block on modular sanity,
we cannot enforce anything.

As far as tooling is concerned, I have been seeing complaints about DNF
doing a bad job, but from the perspective of acceptance
testing, it's the DNF operations that usually work fine with installing,
enabling, disabling, removing, resetting and switching modules and streams.

I believe, that if modularity was opt-in, we would be able to use it just
fine, as it is designed now with some little tweakings, such as DNF
providing enough info on retired or discontinued streams, offering a
possibility to choose a different stream to switch to on upgrades. The
longing for default modular Fedora is what makes it more problematic,
because we need to hide everything from the users and make everything work
automatically. If modularity was a matter of personal choice we would not
have to hide anything from anybody, because those users would be able to
read the necessary documentation and tweak their systems just fine.

---

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: efivar and mokutil long standing FTBFS

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 24, 2019 at 07:45:03AM -, Leigh Scott wrote:
> > On Tue, Sep 10, 2019 at 01:38:03PM +0200, Miro Hrončok wrote:
> > 
> > We're in final freeze now. Any progress?
> > 
> > Zbyszek
> 
> I poked mokutil with a couple of upstream fixes, now it fails only on i686.
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=38515227


mokutil.c:1977:16: error: comparison of integer expressions of different 
signedness: 'unsigned int' and 'int' [-Werror=sign-compare]
 1977 |  if (salt_size > settings_len - (next - settings)) {
  |^

That should be fairly easy to fix...

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

Re: efivar and mokutil long standing FTBFS

[Leigh Scott]

> On Tue, Sep 10, 2019 at 01:38:03PM +0200, Miro Hrončok wrote:
> 
> We're in final freeze now. Any progress?
> 
> Zbyszek

I poked mokutil with a couple of upstream fixes, now it fails only on i686.

https://koji.fedoraproject.org/koji/taskinfo?taskID=38515227
___
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