Re: Release criteria proposal: networking requirements

2020-08-25 Thread Michel Alexandre Salim 
On Tue, 2020-08-25 at 21:20 -0400, Neal Gompa wrote:
> On Tue, Aug 25, 2020 at 8:33 PM Michael Catanzaro <
> mcatanz...@gnome.org> wrote:
> > On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson
> >  wrote:
> > > Do NetworkManager and its current KDE and GNOME front ends
> > > support it
> > > currently?
> > 
> > Rumor has it that KDE has this working!
> 
> The rumor is true! WireGuard has been supported in plasma-nm since
> Plasma 5.14.
> 
> It'd be nice to add validation for WireGuard to the criteria, but do
> we have a WireGuard VPN to test with?
> 
Mullvad (they've added WireGuard support since before it was merged in
kernel 5.6). For validation, do you mean as part of an automated test
or as something individual contributors can test on their own? If the
latter, I can sign up.

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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: Non-responsive maintainer: echevemaster

2020-08-25 Thread Eduardo Javier Echeverria Alvarado 
Done, let me know if you need anything else, Michel!

Best regards,

Eduardo

On Mon, Aug 24, 2020 at 10:03 PM Michel Alexandre Salim
 wrote:
>
> Hi Eduardo,
>
> Ah, thanks for the quick response! I'll close the non-responsive issue,
> please build this for F31-F34 as the current build does not work with
> Fedora's python-markdown at all.
>
> Could you use some help with this package? I'm happy to comaintain -
> I'm considering branching this for EPEL8 since I run CentOS 8 as well,
> and wouldn't want to intrude on your time.
>
> FAS: salimma
>
> Best regards,
>
> Michel
>
> On Mon, 2020-08-24 at 21:06 -0500, Eduardo Javier Echeverria Alvarado
> wrote:
> > Hi Michael, I merged your pull request, I didn't see your message
> > before, I have been so busy the last weeks
> >
> > On Mon, Aug 24, 2020 at 8:17 PM Michel Alexandre Salim
> >  wrote:
> > > Hi,
> > >
> > > Does anyone know how to reach Eduardo Echeverria? I have a pull
> > > request
> > > and a bug report for python-landslide that has not been responded
> > > in
> > > over two weeks.
> > >
> > > https://src.fedoraproject.org/rpms/python-landslide/pull-request/1
> > >
> > > Other bug reports:
> > > https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&email1=echevemaster%40gmail.com&emailassigned_to1=1&emailtype1=substring&list_id=11308269&query_format=advanced
> > >
> > > Looks like he has not been active for a while?
> > >
> > > ❯ python3 ~/src/fedora/fedora-active-user/fedora_active_user.py --
> > > user
> > > echevemaster
> > > FAS username: salimma
> > > FAS password for salimma:
> > > Last login in FAS:
> > >echevemaster 2020-06-23
> > >
> > > Last action on koji:
> > >Wed, 27 Mar 2019 tag_package_owners entry revoked by oscar
> > >
> > > Last package update on bodhi:
> > >2020-05-03 23:20:24 on package libappindicator-12.10.0-29.fc31
> > > Last actions performed according to fedmsg:
> > >   - bcot...@redhat.com updated 'version' on RHBZ#1866952 'python-
> > > landslide needs updating to suppo...' on 2020-08-11 08:25:49
> > >   - mic...@michel-slm.name updated 'cf_doc_type' on RHBZ#1866952
> > > 'python-landslide needs updating to suppo...' on 2020-08-06
> > > 15:47:00
> > >   - mic...@michel-slm.name filed a new bug RHBZ#1866952 'python-
> > > landslide needs updating to suppo...' on 2020-08-06 15:35:57
> > >   - upstream-release-monitoring updated 'short_desc' on
> > > RHBZ#1600321
> > > 'python-scrapy-2.3.0 is available' on 2020-08-04 12:17:18
> > >   - starosekpd+redhat-bugzi...@gmail.com filed a new bug
> > > RHBZ#1864287
> > > 'Request to build goaccess for EPEL8' on 2020-08-03 12:07:29
> > >   - mre...@redhat.com filed a new bug RHBZ#1861730 'CVE-2020-6070
> > > f2fs-
> > > tools: specially craf...' on 2020-07-29 05:07:02
> > >   - mre...@redhat.com filed a new bug RHBZ#1861729 'CVE-2020-6070
> > > f2fs-
> > > tools: specially craf...' on 2020-07-29 05:06:30
> > >   - upstream-release-monitoring updated 'short_desc' on
> > > RHBZ#1600321
> > > 'python-scrapy-2.2.1 is available' on 2020-07-17 05:14:04
> > >   - mailingli...@tpokorra.de updated 'cc' on RHBZ#1651349 'Please
> > > consider switching over to Ayatan...' on 2020-07-12 12:41:19
> > >   - package-rev...@lists.fedoraproject.org updated 'flag.needinfo'
> > > on
> > > RHBZ#890589 'Review Request: csprng - Entropy source ...' on 2020-
> > > 07-09
> > > 17:47:57
> > >
> > > Best regards,
> > >
> > > --
> > > Michel Alexandre Salim
> > > profile: https://keybase.io/michel_slm
> > > chat via email: https://delta.chat/
> > > GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
> > > ___
> > > 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
> >
> >
> > --
> > Eduardo Echeverria
> > @echevemaster
> > ___
> > 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
>
> --
> Michel Alexandre Salim
> profile: https://keybase.io/michel_slm
> chat via email: https://delta.chat/
> GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
> ___
> 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

Re: Release criteria proposal: networking requirements

2020-08-25 Thread Neal Gompa 
On Tue, Aug 25, 2020 at 8:33 PM Michael Catanzaro  wrote:
>
> On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson
>  wrote:
> > Do NetworkManager and its current KDE and GNOME front ends support it
> > currently?
>
> Rumor has it that KDE has this working!

The rumor is true! WireGuard has been supported in plasma-nm since Plasma 5.14.

It'd be nice to add validation for WireGuard to the criteria, but do
we have a WireGuard VPN to test with?

> But GNOME doesn't support it yet. Help welcome in these bugs:
>
> https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/982
> https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2989
>
> Now, does wireguard work with systemd-resolved? *shrug* dunno!

It *should* work, since that part is managed by NetworkManager...


-- 
真実はいつも一つ！/ 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: Release criteria proposal: networking requirements

2020-08-25 Thread Gary Buhrmaster 
On Tue, Aug 25, 2020 at 10:51 PM Michel Alexandre Salim
 wrote:

> Also, should we add WireGuard to this list for future-proofing?

I had thought about explicitly suggesting
wireguard, but then thought that we should
focus on what is currently being used, and
while *I* use wireguard, it is still not really
a common use case.

We do, of course, need to remember to
regularly review all the criteria to make
sure that they still make sense in the current
environment and be willing to delete some
things from the list when only a few still
have such equipment or use the functionality.

I would almost suggest any addition
should come with a criteria deletion,
to bound the work for the QA team,
who are, after all, a limited resource.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-33-20200825.n.1 compose check report

2020-08-25 Thread Fedora compose checker 
No missing expected images.

Failed openQA tests: 8/181 (x86_64)

Old failures (same test failed in Fedora-33-20200824.n.0):

ID: 647962  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/647962
ID: 647968  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/647968
ID: 648000  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/648000
ID: 648010  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/648010
ID: 648011  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/648011
ID: 648041  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/648041
ID: 648068  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/648068
ID: 648069  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/648069

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

Old soft failures (same test soft failed in Fedora-33-20200824.n.0):

ID: 647891  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/647891
ID: 647892  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/647892
ID: 647894  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/647894
ID: 647895  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/647895
ID: 647896  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/647896
ID: 647897  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/647897
ID: 647898  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/647898
ID: 647899  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/647899
ID: 647902  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/647902
ID: 647903  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/647903
ID: 647904  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/647904
ID: 647905  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/647905
ID: 647920  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/647920
ID: 647926  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/647926
ID: 647931  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/647931
ID: 647932  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/647932
ID: 647936  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/647936
ID: 647937  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/647937
ID: 647949  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/647949
ID: 647972  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/647972
ID: 647983  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/647983
ID: 647990  Test: x86_64 universal install_kickstart_firewall_configured
URL: https://openqa.fedoraproject.org/tests/647990
ID: 647991  Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/647991
ID: 647992  Test: x86_64 universal install_kickstart_user_creation
URL: https://openqa.fedoraproject.org/tests/647992
ID: 647994  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/647994
ID: 647995  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/647995
ID: 647997  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/647997
ID: 647998  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/647998
ID: 647999  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/647999
ID: 648001  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/648001
ID: 648002  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/648002
ID: 648004  Test: x86_64 universal

Fedora 33 compose report: 20200825.n.1 changes

2020-08-25 Thread Fedora Rawhide Report 
OLD: Fedora-33-20200824.n.0
NEW: Fedora-33-20200825.n.1

= SUMMARY =
Added images:7
Dropped images:  0
Added packages:  6
Dropped packages:135
Upgraded packages:   251
Downgraded packages: 0

Size of added packages:  4.27 MiB
Size of dropped packages:412.50 MiB
Size of upgraded packages:   3.43 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-33-20200825.n.1.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-33-20200825.n.1.iso
Image: Xfce raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Xfce-armhfp-33-20200825.n.1-sda.raw.xz
Image: LXDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXDE-armhfp-33-20200825.n.1-sda.raw.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-33-20200825.n.1-sda.raw.xz
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-33-20200825.n.1-sda.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-33-20200825.n.1-sda.raw.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: clevis-pin-tpm2-0.1.2-2.fc33
Summary: Clevis PIN for unlocking with TPM2 supporting Authorized Policies
RPMs:clevis-pin-tpm2
Size:1.95 MiB

Package: fcitx5-configtool-0-0.2.20200825gitecd16e5.fc33
Summary: Configuration tools used by fcitx5
RPMs:fcitx5-configtool
Size:1.61 MiB

Package: golang-github-mholt-certmagic-0.8-0.8.3-1.fc33
Summary: Automatic HTTPS for any Go program: fully-managed TLS certificate 
issuance and renewal
RPMs:golang-github-mholt-certmagic-devel-0.8
Size:66.11 KiB

Package: golang-github-prometheus-client-0.9-0.9.4-6.fc33
Summary: Prometheus instrumentation library for go applications
RPMs:golang-github-prometheus-client-devel-0.9
Size:125.69 KiB

Package: jakarta-saaj-1.4.2-1.fc33
Summary: SOAP with Attachments API for Java
RPMs:jakarta-saaj
Size:44.53 KiB

Package: python-pyro-4.71-12.fc33
Summary: PYthon Remote Objects
RPMs:python3-pyro
Size:487.28 KiB


= DROPPED PACKAGES =
Package: aether-connector-okhttp-0.17.6-3.module_f33+8406+feb0be7b
Summary: OkHttp Aether Connector
RPMs:aether-connector-okhttp aether-connector-okhttp-javadoc
Size:115.90 KiB

Package: antlr32-3.2-24.module_f33+8869+a0fd1c5c
Summary: ANother Tool for Language Recognition
RPMs:antlr32-java antlr32-javadoc antlr32-maven-plugin antlr32-tool
Size:1.56 MiB

Package: apache-commons-collections-3.2.2-15.module_f33+8406+feb0be7b
Summary: Provides new interfaces, implementations and utilities for Java 
Collections
RPMs:apache-commons-collections apache-commons-collections-javadoc 
apache-commons-collections-testframework
Size:1.12 MiB

Package: apache-commons-compress-1.19-1.module_f33+8406+feb0be7b
Summary: Java API for working with compressed files and archivers
RPMs:apache-commons-compress apache-commons-compress-javadoc
Size:1.05 MiB

Package: apache-commons-discovery-2:0.5-23.module_f33+8406+feb0be7b
Summary: Apache Commons Discovery
RPMs:apache-commons-discovery apache-commons-discovery-javadoc
Size:174.61 KiB

Package: apache-commons-jxpath-1.3-34.module_f33+8406+feb0be7b
Summary: Simple XPath interpreter
RPMs:apache-commons-jxpath apache-commons-jxpath-javadoc
Size:584.09 KiB

Package: apache-commons-lang-2.6-27.module_f33+8406+feb0be7b
Summary: Provides a host of helper utilities for the java.lang API
RPMs:apache-commons-lang apache-commons-lang-javadoc
Size:628.56 KiB

Package: apache-commons-validator-1.5.0-10.fc32
Summary: Apache Commons Validator
RPMs:apache-commons-validator apache-commons-validator-javadoc
Size:312.44 KiB

Package: apache-sshd-1:2.2.0-4.module_f33+8406+feb0be7b
Summary: Apache SSHD
RPMs:apache-sshd apache-sshd-javadoc
Size:3.07 MiB

Package: args4j-2.33-9.module_f33+8406+feb0be7b
Summary: Java command line arguments parser
RPMs:args4j args4j-javadoc args4j-parent args4j-tools
Size:292.40 KiB

Package: batik-1.11-3.module_f33+8406+feb0be7b
Summary: Scalable Vector Graphics for Java
RPMs:batik batik-css batik-demo batik-javadoc batik-rasterizer 
batik-slideshow batik-squiggle batik-svgpp batik-ttf2svg batik-util
Size:8.74 MiB

Package: bea-stax-1.2.0-20.fc32
Summary: Streaming API for XML
RPMs:bea-stax bea-stax-api bea-stax-javadoc
Size:307.14 KiB

Package: bouncycastle-1.63-2.module_f33+8406+feb0be7b
Summary: Bouncy Castle Cryptography APIs for Java
RPMs:bouncycastle bouncycastle-javadoc bouncycastle-mail bouncycastle-pg 
bouncycastle-pkix bouncycastle-tls
Size:9.73 MiB

Package: eclipse-egit-5.7.0-2.module_f33+8843+8a8e3dd8
Summary: Eclipse Git Integration
RPMs:eclipse-egit
Size:9.62 MiB

Package: eclipse-gef-3.11.0-12.module_f33+8406+feb0be7b
Summary: Graphical Editing Framework (GEF) Eclipse

Re: Release criteria proposal: networking requirements

2020-08-25 Thread Michael Catanzaro 
On Tue, Aug 25, 2020 at 4:11 pm, Adam Williamson 
 wrote:

Do NetworkManager and its current KDE and GNOME front ends support it
currently?


Rumor has it that KDE has this working! But GNOME doesn't support it 
yet. Help welcome in these bugs:


https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/982
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2989

Now, does wireguard work with systemd-resolved? *shrug* dunno!

___
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: Release criteria proposal: networking requirements

2020-08-25 Thread Michel Alexandre Salim 
On Tue, 2020-08-25 at 16:11 -0700, Adam Williamson wrote:
> On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote:
> > On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
> > >  VPN connections 
> > > 
> > > 
> > > 
> > > Using the default network configuration tools for the console and
> > > for
> > > 
> > > release-blocking desktops, it must be possible to establish a
> > > working
> > > 
> > > connection to common OpenVPN, openconnect-supported and vpnc-
> > > supported
> > > 
> > > VNC servers with typical configurations.
> > 
> > VNC == VPN?
> 
> Oh, yes. Thanks.
> 
> > Also, should we add WireGuard to this list for future-proofing?
> 
> It doesn't really make sense to add things to the release criteria
> for
> future proofing. If it's important *now* we should add it. Otherwise,
> no.
> 
> Do NetworkManager and its current KDE and GNOME front ends support it
> currently?

IIRC not - wireguard-tools is available, but setting up a connection is
manual or needs to use the GUI/CLI from a VPN provider such as Mullvad

https://www.wireguard.com/quickstart/
https://mullvad.net/nl/help/install-mullvad-app-linux/
https://mullvad.net/en/help/how-use-mullvad-cli/

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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: Release criteria proposal: networking requirements

2020-08-25 Thread Adam Williamson 
On Tue, 2020-08-25 at 15:50 -0700, Michel Alexandre Salim wrote:
> On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
> >  VPN connections 
> > 
> > 
> > 
> > Using the default network configuration tools for the console and for
> > 
> > release-blocking desktops, it must be possible to establish a working
> > 
> > connection to common OpenVPN, openconnect-supported and vpnc-
> > supported
> > 
> > VNC servers with typical configurations.
> 
> VNC == VPN?

Oh, yes. Thanks.

> Also, should we add WireGuard to this list for future-proofing?

It doesn't really make sense to add things to the release criteria for
future proofing. If it's important *now* we should add it. Otherwise,
no.

Do NetworkManager and its current KDE and GNOME front ends support it
currently?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
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: Release criteria proposal: networking requirements

2020-08-25 Thread Michel Alexandre Salim 
On Fri, 2020-08-21 at 17:11 -0700, Adam Williamson wrote:
>  VPN connections 
> 
> 
> 
> Using the default network configuration tools for the console and for
> 
> release-blocking desktops, it must be possible to establish a working
> 
> connection to common OpenVPN, openconnect-supported and vpnc-
> supported
> 
> VNC servers with typical configurations.

VNC == VPN?

Also, should we add WireGuard to this list for future-proofing?

Thanks,

-- 
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2


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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-25 Thread Lokesh Mandvekar 
I fixed skopeo and fuse-overlayfs earlier today, so hopefully we should be good
on those soon.

On Mon, Aug 24, 2020 at 01:00:58PM +0200, Miro Hron??ok wrote:
> Hello.
> 
> The following packages are downgrades when I attempt upgrade from Fedora 32
> to Fedora 33:
> 
> - containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
> - fuse-overlayfs 1.1.2 -> 1.1.0
> - strace 5.8 -> 5.7.0.6.7ab6
> - thunderbird 668.11.0 -> 8.10.0
> 
> Is this expected?
> 
> -- 
> Miro Hron??ok
> --
> Phone: +420777974800
> IRC: mhroncok
> 

-- 
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
___
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

2020-08-25 Thread Stephen John Smoogen 
On Tue, 25 Aug 2020 at 15:58, Sérgio Basto  wrote:

> On Mon, 2020-08-24 at 12:25 +0200, Miro Hrončok wrote:
> > usb_modeswitch
>
> any particular reason for usb_modeswitch be orphaned ?  , i.e. is about
> no maintainer ? or about is not used anymore ?
>

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FQDNMCB3O7QNTEIRD5TMXPHKZ6RFRBY2/


> --
> Sérgio M. B.
> ___
> 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

Schedule for Wednesday's FESCo Meeting (2020-08-26)

2020-08-25 Thread David Cantrell 

Following is the list of topics that will be discussed in the
FESCo meeting Wednesday at 14:00UTC in #fedora-meeting-2 on
irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-08-26 14:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Followups =

#topic #2463 F33 Incomplete changes
https://pagure.io/fesco/issue/2463

= New business =

#topic #2454 Proposal: Force compiler / annobin updates to use side tags / 
rawhide gating
https://pagure.io/fesco/issue/2454

#topic #2452 F34 Self-Contained Change: Policy for Modules in Fedora and Fedora 
ELN
https://pagure.io/fesco/issue/2452

#topic #2430 Send notifications of new FESCo tickets to fedora-devel (or 
daily/weekly digests)
https://pagure.io/fesco/issue/2430

#topic #2416 Update 3rd party repo policy
https://pagure.io/fesco/issue/2416

#topic #2410 RFE: Rename dist-git "master" branch to "rawhide"
https://pagure.io/fesco/issue/2410

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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

2020-08-25 Thread Sérgio Basto 
On Mon, 2020-08-24 at 12:25 +0200, Miro Hrončok wrote:
> usb_modeswitch

any particular reason for usb_modeswitch be orphaned ?  , i.e. is about
no maintainer ? or about is not used anymore ? 
-- 
Sérgio M. B.
___
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: What is the real value of Release and %changelog metadata?

2020-08-25 Thread Neal Gompa 
On Tue, Aug 25, 2020 at 3:26 PM kevin  wrote:
>
> On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote:
> > On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
> >  wrote:
> > >
> > > On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > > > That makes it extra steps to see changelogs on a not-installed package.
> > > > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> > > > (for example, to see what is changed since my installed version).
> > > > Converting to an installed file means I would have to extract the RPM
> > > > (possibly after manually downloading) and find it under a different
> > > > directory for every RPM - much less convenient.
> > >
> > > A dnf plugin could be made which shows metadata like this from
> > > src.fedoraproject.org or bodhi or some other source.
> > >
> >
> > That's not helpful beyond Fedora, though. When it's forked into RHEL
> > or CentOS, that changelog history from Fedora is preserved today. RHEL
> > forks Fedora at the git level, so generated changelogs from Git will
> > still work, and since CentOS gets SRPM imports into its Dist-Git,
> > they'll be flattened into %changelog sections as appropriate. But if
> > we rely on a web service to get changelogs, we screw over that
> > particular transition path.
>
> Sure, but how often is that changelog:
>
> "Updated to 10.0.1"
>
> or
>
> "Fixed typo"
>
> I pretty much stopped reading changelogs a while back.
> Looking at the upstream NEWS or announcement is better for releases, and
> just looking at the git commits is better for isolating some change in
> packaging.

I do the opposite. I almost never read upstream news or changelog
files. They just don't matter in most cases when I'm trying to figure
out problems. Those timelines in the packaging changelogs are a good
record of how the package itself has evolved, and sure, most of the
time it's just updating to a new version, but those checkpoints are
useful too.

And in the Fedora -> RHEL -> CentOS case, we do not have those
relationships with Git commits, so the changelog entries are the only
way to figure out packaging deltas and such.



--
真実はいつも一つ！/ 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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-25 Thread kevin 
On Tue, Aug 25, 2020 at 08:14:38PM +0200, Fabio Valentini wrote:
> Do you think it would be a good idea to file bugs for those packages
> where a build for f33 was "forgotten"?
> Since I already have the "downgrade check" scripted [0] it's a simple task of:
> 
> - check if the package has attempted build for f33
> - if yes, check if it's FTBFS, and don't report a bug
> - if no build was attempted for f33, report a bug
> 
> I see ~100 downgraded *binary* packages going from fully updated f32
> to fully updated f33.
> The number of affected *source* packages is naturally lower than that.
> The script also doesn't account for packages being renamed (but in
> those cases, proper Obsoletes and Provides need to be present during
> package review, so I don't think this is a problem).

Yes, I think that would be lovely. 

kevin


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

Re: What is the real value of Release and %changelog metadata?

2020-08-25 Thread kevin 
On Tue, Aug 25, 2020 at 12:57:34PM -0400, Neal Gompa wrote:
> On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
>  wrote:
> >
> > On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > > That makes it extra steps to see changelogs on a not-installed package.
> > > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> > > (for example, to see what is changed since my installed version).
> > > Converting to an installed file means I would have to extract the RPM
> > > (possibly after manually downloading) and find it under a different
> > > directory for every RPM - much less convenient.
> >
> > A dnf plugin could be made which shows metadata like this from
> > src.fedoraproject.org or bodhi or some other source.
> >
> 
> That's not helpful beyond Fedora, though. When it's forked into RHEL
> or CentOS, that changelog history from Fedora is preserved today. RHEL
> forks Fedora at the git level, so generated changelogs from Git will
> still work, and since CentOS gets SRPM imports into its Dist-Git,
> they'll be flattened into %changelog sections as appropriate. But if
> we rely on a web service to get changelogs, we screw over that
> particular transition path.

Sure, but how often is that changelog:

"Updated to 10.0.1" 

or

"Fixed typo"

I pretty much stopped reading changelogs a while back. 
Looking at the upstream NEWS or announcement is better for releases, and
just looking at the git commits is better for isolating some change in
packaging. 

kevin


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

Re: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread kevin 
On Tue, Aug 25, 2020 at 04:49:05PM +0200, Petr Menšík wrote:
> Hi Daniel,
> 
> I am not using any base in fact. I am using container by systemd-nspawn.
> I have installed it long ago by command from man systemd-nspawn, Example
> 2. at the bottom.
> 
> Since then I am trying rolling updates to keep it Raw(hide). It fails
> every release once branched, because signatures cannot be verified.
> 
> I just do dnf upgrade from time to time, when I check something there.
> 
> My main issue is I am too stubborn to turn off gpg verification.
> Instead, I want verification working.
> 
> It seems branching was almost correct this time. But fedora-repos-33-0.9
> does not contain arch symlinks. And rawhide contains packages already
> signed by the new key. Either install first gpg keys from koji, or
> disable gpg when upgrading fedora-gpg-keys.

Right, aside from that bug/issue it should have worked to just update
fedora-gpg-keys and fedora-repos. 

kevin


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

Re: Orphaned packages looking for new maintainers

2020-08-25 Thread kevin 
On Tue, Aug 25, 2020 at 11:19:57AM +0200, Miro Hrončok wrote:
> On 25. 08. 20 10:51, Fabio Valentini wrote:
> > On Tue, Aug 25, 2020, 10:45 Miro Hrončok  > > wrote:
> > 
> > On 25. 08. 20 5:52, Michel Alexandre Salim wrote:
> >  > I'll properly retire lua-logging and luadoc, but keep lua-sql.
> > 
> > Let's merge the retirement commits to f33 as well?
> > 
> > 
> > Doesn't "fedpkg retire" do more than just push something to git, e.g.
> > publish retirement information to PDC or something? So IIUC just merging
> > the retirement commit to f33 won't be enough since it won't block the
> > package in koji.
> 
> It used to (with pkgdb) now it doesn't.

It emits a commit message with 'dead.package' in it.

This is listened for by
https://pagure.io/fedora-infra/toddlers/blob/master/f/toddlers/plugins/pdc_retired_packages.py
which marks the package eol in pdc. 

Then, the next rawhide or branched compose runs 
https://pagure.io/releng/blob/master/f/scripts/block_retired.py
which looks in pdc and for every package that is eol in pdc it 
blocks it in koji. 

> This is how I retire orphaned packages between branching and beta freeze:
> 
> fedpkg clone $pkg && \
> cd $pkg && \
> fedpkg switch-branch f33 && \
> fedpkg retire "Orphaned for 6+ weeks" && \
> fedpkg switch-branch master && \
> git merge f33 && \
> git push
> 
> (There used to be a rule to retire older branches first, but I suppose that
> is no longer required and the command might be simplified.)
> 
> It works fine (except for a slight period when retirements on f33 were
> broken, but that was a server side issue, not the command).

Either way should work, it's looking for the commit, merge or not. 

kevin


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

Re: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-25 Thread Fabio Valentini 
On Tue, Aug 25, 2020 at 3:13 PM Peter Robinson  wrote:
>
> On Tue, Aug 25, 2020 at 1:32 PM Daniel Walsh  wrote:
> >
> > On 8/24/20 07:00, Miro Hrončok wrote:
> > > Hello.
> > >
> > > The following packages are downgrades when I attempt upgrade from
> > > Fedora 32 to Fedora 33:
> > >
> > > - containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
> > > - fuse-overlayfs 1.1.2 -> 1.1.0
> > > - strace 5.8 -> 5.7.0.6.7ab6
> > > - thunderbird 668.11.0 -> 8.10.0
> > >
> > > Is this expected?
> > >
> > Definitely not on the first two.  I have asked the maintainers to look
> > into it.  Looks like packages in rawhide are failing to build.
>
> The container stack never seems to be dealt with well in the branching
> stage of the release, this isn't the first time I've noticed that,
> could it be added to a process or similar to ensure it's smooth, not
> sure we want individual commit related builds once we've branched and
> headed for beta.
>
> Peter

Do you think it would be a good idea to file bugs for those packages
where a build for f33 was "forgotten"?
Since I already have the "downgrade check" scripted [0] it's a simple task of:

- check if the package has attempted build for f33
- if yes, check if it's FTBFS, and don't report a bug
- if no build was attempted for f33, report a bug

I see ~100 downgraded *binary* packages going from fully updated f32
to fully updated f33.
The number of affected *source* packages is naturally lower than that.
The script also doesn't account for packages being renamed (but in
those cases, proper Obsoletes and Provides need to be present during
package review, so I don't think this is a problem).

Fabio

[0]: https://gist.github.com/decathorpe/9b8bf35404c11b4ebf73d06ff303bc88
___
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: Does ELN SIG have some issue tracker?

2020-08-25 Thread Aleksandra Fedorova 
Hi, Vit,

On Tue, Aug 25, 2020 at 11:21 AM Vít Ondruch  wrote:
>
> Looking at the ELN SIG page [1], there is no contact information, no ML,
> no issue tracker. I would like to discuss bootstrapping issues such as
> [2], but there is no place to provide any feedback. Is this group
> working under cover?
>
> (Using the minimization tracker [3], where a lot of ELN stuff appears to
> end up, does not feel appropriate).

Thank you for the question.

The ELN wiki page is outdated, I am working on moving the content to
ELN Docs site [1] right now. I will add contact and contribution info
there as well.

The minimization tracker [2] is indeed better suited for the content
set discussions.

For generic ELN topics please use issues in https://github.com/fedora-eln/eln

[1] https://docs.fedoraproject.org/en-US/eln/
[2] https://github.com/minimization/content-resolver-input

> Vít
>
>
> [1] https://fedoraproject.org/wiki/ELN
>
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1599965
>
> [3] https://github.com/minimization/
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: What is the real value of Release and %changelog metadata?

2020-08-25 Thread Neal Gompa 
On Tue, Aug 25, 2020 at 12:54 PM Matthew Miller
 wrote:
>
> On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> > That makes it extra steps to see changelogs on a not-installed package.
> > I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> > (for example, to see what is changed since my installed version).
> > Converting to an installed file means I would have to extract the RPM
> > (possibly after manually downloading) and find it under a different
> > directory for every RPM - much less convenient.
>
> A dnf plugin could be made which shows metadata like this from
> src.fedoraproject.org or bodhi or some other source.
>

That's not helpful beyond Fedora, though. When it's forked into RHEL
or CentOS, that changelog history from Fedora is preserved today. RHEL
forks Fedora at the git level, so generated changelogs from Git will
still work, and since CentOS gets SRPM imports into its Dist-Git,
they'll be flattened into %changelog sections as appropriate. But if
we rely on a web service to get changelogs, we screw over that
particular transition path.




--
真実はいつも一つ！/ 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: What is the real value of Release and %changelog metadata?

2020-08-25 Thread Matthew Miller 
On Thu, Aug 13, 2020 at 11:51:13AM -0500, Chris Adams wrote:
> That makes it extra steps to see changelogs on a not-installed package.
> I do sometimes do "rpm -q --changelog -p foo.rpm" or "dnf changelog foo"
> (for example, to see what is changed since my installed version).
> Converting to an installed file means I would have to extract the RPM
> (possibly after manually downloading) and find it under a different
> directory for every RPM - much less convenient.

A dnf plugin could be made which shows metadata like this from
src.fedoraproject.org or bodhi or some other source.


-- 
Matthew Miller

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

Re: RFC7919 Diffie-Hellman parameters in Fedora

2020-08-25 Thread Robert Relyea 

On 8/22/20 7:26 PM, Kevin Kofler wrote:

Christopher Engelhard wrote:

tl;dr should we make it easier/automatic for users to use the
Diffie-Hellman parameters defined in RFC7919?

While I understand the motivation behind the RFC (interoperability, safety
against intentionally or unintentionally bad parameters), hardcoded
parameters sound suspicious to me. How do we know that these are not chosen
to allow the NSA or some other country's equivalent agency to decrypt the
conversation?


TL/DR:

Most "randomly" chosen values for primes today are known to be subject 
to small group attacks. Getting this right is difficult (which I'll 
demonstrate below). The chosen primes were vetted by the TLS working 
group based on physical constants and a generation scheme that has the 
required safe criteria. That is these values meet the requirements that 
we already know. We can all recheck them. The chances that the NSA has 
an attack, that happens to work on primes that someone else (IETF) 
generated, and doesn't work on all DH primes is pretty unlikely. As simo 
says, If you are worried, don't use DH. If you aren't using one of these 
primes, your DH connection is probably vulnerable to active attacks.


Longer explanation:

In order to do DH safely, you need to make sure that the public key you 
are provided is in a large subgroup. This can be checked in the 
following ways:


 * The prime 'P' is a safe prime (sometimes incorrectly called a strong
   prime. This means the p is prime and (p-1)/2 is prime (in this case
   (p-1)/2 is called a Sofie-germaine prime).
 o You check p is prime, and (p-1)/2 is prime. This is expensive
   for a random prime.
 o You check that the public key y is < p, and != 0, 1, or -1 mod
   p. This check is very fast.
 * The prime 'P is not a safe prime, but you know a large prime 'q'
   which is a factor of (p-1).
 o You check that p is prime, and q is prime.
 o You check that y^q mod p == 1
 o You check y != 1 or -1

If you precheck known 'P' values you can skip the very expensive prime 
checks (because we've already checked those values and they are known to 
be good). To make matters worse, It's very expensive to generate a safe 
prime for large  prime values. If you search the internet about how to 
do this, they well give you instructions on how to generate a non-safe 
prime with large q, but none of our common protocols include a q value, 
which means you cannot do either the prime check or the y^q mod p ==1 
check, and thus a man in the middle attacker can supply a q that falls 
in a small subgroup and eaves-drop on your connection.


TLS 1.3 allows you to only connect if the server is using a known prime, 
which has already been vetted as a safe prime. If you aren't using and 
requiring these primes, you basically have the following choices:


1) use RSA and loose PFS.

2) use ECDH (which will likely fall to quantum computers first).

Since Quantum computers will ultimately remove PFS, ECDH is probably 
your best bet. But then you are again trusting in fixed sets of Curves 
that came from somewhere, and if you are paranoid about the NSA, well



___
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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Mattia Verga via devel 
Il 25/08/20 11:40, Petr Menšík ha scritto:
> Hi Vít,
>
> Unfortunately your workaround does not on my rawhide container.
> ...

I just did

~~~

$ sudo dnf update fedora-gpg-keys --nogpgcheck

$ sudo dnf update fedora-repos --release 34

~~~

___
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: RFC7919 Diffie-Hellman parameters in Fedora

2020-08-25 Thread Christopher Engelhard 
On 24.08.20 20:06, Simo Sorce wrote:
> This has been proposed (somewhere, I forgot where) before, and it is a
> definite possibility.
> Unclear what package would distribute them, potentially the crypto-
> policies package.

Or a separate package, but at least the logic of selecting a default
from the available groups should probably reside in crypto-policies.

Christopher

P.S.: I put the package I created to install various default DH groups
on my systems on Copr, in case this is useful for anyone else:
https://gitlab.com/lcts/crypto-groups
https://copr.fedorainfracloud.org/coprs/lcts/fedora-rpm-addons/package/crypto-groups/
___
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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Petr Menšík 
Hi Daniel,

I am not using any base in fact. I am using container by systemd-nspawn.
I have installed it long ago by command from man systemd-nspawn, Example
2. at the bottom.

Since then I am trying rolling updates to keep it Raw(hide). It fails
every release once branched, because signatures cannot be verified.

I just do dnf upgrade from time to time, when I check something there.

My main issue is I am too stubborn to turn off gpg verification.
Instead, I want verification working.

It seems branching was almost correct this time. But fedora-repos-33-0.9
does not contain arch symlinks. And rawhide contains packages already
signed by the new key. Either install first gpg keys from koji, or
disable gpg when upgrading fedora-gpg-keys.

Best Regards,
Petr

On 8/25/20 12:05 PM, Daniel P. Berrangé wrote:
> On Tue, Aug 25, 2020 at 11:40:21AM +0200, Petr Menšík wrote:
>> Hi Vít,
>>
>> Unfortunately your workaround does not on my rawhide container. I think
>> the problem is in missing gpg keys from fedora-gpg-keys, which do not
>> contain also architecture specific keys.
> 
> When you say "rawhide container", where are you pulling the base image
> from ?  If you're pulling from docker.io, then perhaps you are hitting
> the same problem as me, which is that the image hasn't been updated in
> over a month:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5QDNMCJHH2JY4E2WDKEKBOMLP3QKGS3S/
> 
> 
> Regards,
> Daniel
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
___
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: GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

2020-08-25 Thread Jakub Jelinek 
On Tue, Aug 25, 2020 at 08:17:57AM -0600, Jeff Law wrote:
> > IOW, don't get too excited by the x1.9 speedup claim. I doubt we'll
> > see that in kojki except in niche scenarios where a project's build
> > is bottlenecked by a serialization point on compiling one file.
> Right.  Also note the code isn't accepted upstream yet.  I strongly suspect
> there's going to be more work required to make what Guiuliano's work ready for
> prime time.
> 
> On a positive note, my understanding from talking to Giuliano last year was 
> that
> he was trying to parallelize GCC itself which I thought was untractable for a
> student project given the amount of unprotected global state.  Instead I 
> think he
> ended up using the LTO partitioning code to find TU split points, then feeds
> those into distinct fork/exec'd copies of GCC which is a much simpler problem 
> to
> solve.
> 
> So there may be uses for his work.  Obviously the GCC team will continue to
> monitor and if/when we think there's a change we should make for Fedora to
> exploit Giuliano's work we'll propose it.

Yeah.  E.g. in the GCC tree itself we have a couple of large generated
sources that are known to be parallelization bottlenecks (even if they are
started to be compiled as soon as possible, they finish often last), and so
instead of enabling it for everything which probably would only slow things
down, it might be useful to enable this only for *-match.c, selected insn-*.c
and perhaps the libsanitizer asan_interceptors.cpp.

Jakub
___
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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Petr Menšík 
No, unfortunately the key is there, but the package is incomplete.

If you have enabled gpg signatures verification, it would fail. At least
it does to me.

Check it with:

rpm -ql fedora-gpg-keys | grep fedora-34-$(arch)

It just does not provide correct key. The same issue is there for f31
and f32. When you create platform link yourself, then you can upgrade
without turning off signature verification.

I got mad it always breaks and prepared automated test [1]. Hope next
time rolling rawhide would be possible. I report issue with that every
release and got tired of it. It is a bit better now, but not great.

1. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/76
2. https://src.fedoraproject.org/rpms/fedora-repos/pull-request/77


On 8/25/20 12:16 PM, Vít Ondruch wrote:
> 
> Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
>> Hi Vít,
>>
>> Unfortunately your workaround does not on my rawhide container. I think
>> the problem is in missing gpg keys from fedora-gpg-keys, which do not
>> contain also architecture specific keys.
>>
>> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
>> fedora-repos-33-0.9.noarch
>> fedora-repos-rawhide-33-0.9.noarch
>> fedora-gpg-keys-33-0.9.noarch
>>
>> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
>> fedora-gpg-keys
> 
> 
> The `--enablerepo=rawhide` is the issue IMO.
> 
> You should understand, that Rawhide up to the branching point was F33
> and signed by F33 key. So first you need to update to at least
> fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is
> signed by known F33 key but already contains the F34 key. Since that
> point you can use F34 packages signed by F34 key.
No, it should have worked this way, but it did not. Made pull request
for f32 update [2]. It should be done also for f31, if there is still
time for that.

> 
> 
> Vít
> 
> 
>> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
>> Dependencies resolved.
>> =
>>  Package   Architecture
>> Version  Repository Size
>> =
>> Upgrading:
>>  fedora-gpg-keys   noarch
>> 34-0.2   rawhide   105 k
>>
>> Transaction Summary
>> =
>> Upgrade  1 Package
>>
>> Total size: 105 k
>> Downloading Packages:
>> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
>>
>> warning:
>> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
>> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
>> Fedora - Rawhide - Developmental packages for the next Fedora release
>>  1.6 MB/s | 1.6 kB 00:00
>> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>> (0x9570FF31) is already installed
>> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
>> for the next Fedora release" repository are already installed but they
>> are not correct for this package.
>> Check that the correct key URLs are configured for this repository..
>> Failing package is: fedora-gpg-keys-34-0.2.noarch
>>  GPG Keys are configured as:
>> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
>> The downloaded packages were saved in cache until the next successful
>> transaction.
>> You can remove cached packages by executing 'dnf clean packages'.
>> Error: GPG check FAILED
>>
>> I have complained two release before and this is still the same. It
>> always break on new release. The only option now is to install it by
>> hand from koji, where it is not yet signed (yuck!)
>>
>> # dnf install
>> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm
>>
>> Then your commands would work, followed by normal upgrade.
>>
>> Filled bug #1872248 for it. It should finally work without user even
>> fiddling with gpg keys manually. Is there some pressure to keep users
>> from using rawhide?
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248
>>
>> On 8/17/20 1:42 PM, Vít Ondruch wrote:
>>> Just as a reminder to all Rawhide users, this is the easiest way to keep
>>> using Rawhide after branching:
>>>
>>>
>>> ~~~
>>>
>>> $ sudo dnf update fedora-gpg-keys
>>>
>>> $ sudo dnf update fedora-repos --release 34
>>>
>>> ~~~
>>>
>>>
>>> Unfortunately, there has been no progress on [1] during past months.
>>>
>>>
>>>
>>> Vít
>>>
>>>
>>>
>>>  [1] https://pagure.io/releng/issue/7445
>>

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



signature.as

Re: GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

2020-08-25 Thread Jeff Law 
On Tue, 2020-08-25 at 10:17 +0100, Daniel P. Berrangé wrote:
> On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote:
> > I think soon we will have a big boost in Koji performances thanks to
> > Giuliano Belinassi and his work on addressing GCC parallelization
> > bottlenecks. According to Phoronix, compiling individual files in
> > parallel may have up to ~1.9x speedup:
> > https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-jobs-Patches
> 
> AFAICT, that is referring to parallelizing single file compilation to
> make use of multiple cores. That's only useful if the other cores on
> your host are otherwise idle.
Correct.  It's going to be most helpful when there's a large TU with many
functions and there's nothing else going on to keep the cores/threads busy.

> 
> In koji we use parallel make (or equivalent) so that multiple files
> are compiled in parallel. Thus most of the time all cores will be fully
> utilized.
RIght.  Except for those which override the parallel make flags because they're
missing dependencies.  But these are very much the exception, not the rule.

> IOW, don't get too excited by the x1.9 speedup claim. I doubt we'll
> see that in kojki except in niche scenarios where a project's build
> is bottlenecked by a serialization point on compiling one file.
Right.  Also note the code isn't accepted upstream yet.  I strongly suspect
there's going to be more work required to make what Guiuliano's work ready for
prime time.

On a positive note, my understanding from talking to Giuliano last year was that
he was trying to parallelize GCC itself which I thought was untractable for a
student project given the amount of unprotected global state.  Instead I think 
he
ended up using the LTO partitioning code to find TU split points, then feeds
those into distinct fork/exec'd copies of GCC which is a much simpler problem to
solve.

So there may be uses for his work.  Obviously the GCC team will continue to
monitor and if/when we think there's a change we should make for Fedora to
exploit Giuliano's work we'll propose it.

jeff
> 
___
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] Bodhi Activation point

2020-08-25 Thread Tomas Hrcka 
Hi all,

Today's an important day on the Fedora 33 schedule[1], with several
significant cut-offs. First of all, today is the Bodhi activation point
[2]. That means that from now on all Fedora 33 packages must be
submitted to updates-testing and pass the relevant requirements[3]
before they will be marked as 'stable' and moved to the fedora
repository.

Today is also the Beta freeze[4]. This means that only packages which
fix accepted blocker or freeze exception bugs[5][6] will be marked as
'stable' and included in the Beta composes. Other builds will remain
in updates-testing until the Beta release is approved, at which point
the Beta freeze is lifted and packages can move to 'stable' as usual
until the Final freeze.

Today is also the '100% code complete deadline' Change
Checkpoint[5], meaning that Fedora 33 Changes must now be code
complete, meaning all the code required to enable the new change is
finished. The level of code completeness is reflected as tracker bug
state ON_QA. The change does not have to be fully tested by this
deadline'.

Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-translated projects should
not now be changed for Fedora 33.

Tomas Hrcka
jednorozec on FreeNode #fedora-releng #fedora-devel #fedora-cs

[1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
___
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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-25 Thread Peter Robinson 
On Tue, Aug 25, 2020 at 1:32 PM Daniel Walsh  wrote:
>
> On 8/24/20 07:00, Miro Hrončok wrote:
> > Hello.
> >
> > The following packages are downgrades when I attempt upgrade from
> > Fedora 32 to Fedora 33:
> >
> > - containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
> > - fuse-overlayfs 1.1.2 -> 1.1.0
> > - strace 5.8 -> 5.7.0.6.7ab6
> > - thunderbird 668.11.0 -> 8.10.0
> >
> > Is this expected?
> >
> Definitely not on the first two.  I have asked the maintainers to look
> into it.  Looks like packages in rawhide are failing to build.

The container stack never seems to be dealt with well in the branching
stage of the release, this isn't the first time I've noticed that,
could it be added to a process or similar to ensure it's smooth, not
sure we want individual commit related builds once we've branched and
headed for beta.

Peter
___
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: Moving tcpdump from /usr/sbin to /usr/bin

2020-08-25 Thread Michal Ruprich 
Good point, thx Zbyszek.

On 8/24/20 4:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Aug 24, 2020 at 02:54:29PM +0200, Michal Ruprich wrote:
>> Hi,
>>
>> after a discussion with upstream, I will be moving tcpdump binary from
>> /usr/sbin to /usr/bin, similar to how wireshark does this. If you can
>> think of any reason why not to do this, please let me know.
> Please provide a compat symlink to ../bin/tcpdump though. People
> occasionally use the full path to various utilities (in scripts, or
> in systemd units, in makefiles, etc.)
>
> 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

-- 
Michal Ruprich
Software Engineer

Email: mrupr...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
___
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: Suspicious downgrades when upgrading from F32 to F33: containers-common, fuse-overlayfs, strace, thunderbird

2020-08-25 Thread Daniel Walsh 
On 8/24/20 07:00, Miro Hrončok wrote:
> Hello.
>
> The following packages are downgrades when I attempt upgrade from
> Fedora 32 to Fedora 33:
>
> - containers-common (skopeo) 1:1.1.1 -> 1:1.0.1
> - fuse-overlayfs 1.1.2 -> 1.1.0
> - strace 5.8 -> 5.7.0.6.7ab6
> - thunderbird 668.11.0 -> 8.10.0
>
> Is this expected?
>
Definitely not on the first two.  I have asked the maintainers to look
into it.  Looks like packages in rawhide are failing to build.
___
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

perl-Digest-MD5 license corrected

2020-08-25 Thread Petr Pisar 
Fedora recognizes RSA license now, so I corrected a perl-Digest-MD5 license
from "(GPL+ or Artistic) and BSD" to "(GPL+ or Artistic) and RSA".

-- Petr


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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Petr Menšík 
Okay, found more correct workaround, this time without required
ignoration of gpg signatures.

Just use:

(sudo) dnf --disablerepo rawhide --enablerepo updates \
   upgrade fedora-gpg-keys
(sudo) ln -s /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-34-{primary,$(arch)}
(sudo) dnf --repo rawhide --releasever 34 upgrade \
   fedora-gpg-keys fedora-repos fedora-repos-rawhide


Then just
(sudo) dnf upgrade

Correct key made it into updates, but no architecture symlinks were
provided.

On 8/25/20 11:40 AM, Petr Menšík wrote:
> Hi Vít,
> 
> Unfortunately your workaround does not on my rawhide container. I think
> the problem is in missing gpg keys from fedora-gpg-keys, which do not
> contain also architecture specific keys.
> 
> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
> fedora-repos-33-0.9.noarch
> fedora-repos-rawhide-33-0.9.noarch
> fedora-gpg-keys-33-0.9.noarch
> 
> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
> fedora-gpg-keys
> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
> Dependencies resolved.
> =
>  Package   Architecture
> Version  Repository Size
> =
> Upgrading:
>  fedora-gpg-keys   noarch
> 34-0.2   rawhide   105 k
> 
> Transaction Summary
> =
> Upgrade  1 Package
> 
> Total size: 105 k
> Downloading Packages:
> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
> 
> warning:
> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
> Fedora - Rawhide - Developmental packages for the next Fedora release
>  1.6 MB/s | 1.6 kB 00:00
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> (0x9570FF31) is already installed
> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
> for the next Fedora release" repository are already installed but they
> are not correct for this package.
> Check that the correct key URLs are configured for this repository..
> Failing package is: fedora-gpg-keys-34-0.2.noarch
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
> 
> I have complained two release before and this is still the same. It
> always break on new release. The only option now is to install it by
> hand from koji, where it is not yet signed (yuck!)
> 
> # dnf install
> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm
> 
> Then your commands would work, followed by normal upgrade.
> 
> Filled bug #1872248 for it. It should finally work without user even
> fiddling with gpg keys manually. Is there some pressure to keep users
> from using rawhide?
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248
> 
> On 8/17/20 1:42 PM, Vít Ondruch wrote:
>> Just as a reminder to all Rawhide users, this is the easiest way to keep
>> using Rawhide after branching:
>>
>>
>> ~~~
>>
>> $ sudo dnf update fedora-gpg-keys
>>
>> $ sudo dnf update fedora-repos --release 34
>>
>> ~~~
>>
>>
>> Unfortunately, there has been no progress on [1] during past months.
>>
>>
>>
>> Vít
>>
>>
>>
>>  [1] https://pagure.io/releng/issue/7445

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

Fedora-Cloud-31-20200825.0 compose check report

2020-08-25 Thread Fedora compose checker 
No missing expected images.

Passed openQA tests: 7/7 (x86_64)
-- 
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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Vít Ondruch 

Dne 25. 08. 20 v 11:40 Petr Menšík napsal(a):
> Hi Vít,
>
> Unfortunately your workaround does not on my rawhide container. I think
> the problem is in missing gpg keys from fedora-gpg-keys, which do not
> contain also architecture specific keys.
>
> # rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
> fedora-repos-33-0.9.noarch
> fedora-repos-rawhide-33-0.9.noarch
> fedora-gpg-keys-33-0.9.noarch
>
> # sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
> fedora-gpg-keys


The `--enablerepo=rawhide` is the issue IMO.

You should understand, that Rawhide up to the branching point was F33
and signed by F33 key. So first you need to update to at least
fedora-gpg-keys-33-0.9.noarch.rpm (and note the '33' there), which is
signed by known F33 key but already contains the F34 key. Since that
point you can use F34 packages signed by F34 key.


Vít


> Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
> Dependencies resolved.
> =
>  Package   Architecture
> Version  Repository Size
> =
> Upgrading:
>  fedora-gpg-keys   noarch
> 34-0.2   rawhide   105 k
>
> Transaction Summary
> =
> Upgrade  1 Package
>
> Total size: 105 k
> Downloading Packages:
> [SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded
>
> warning:
> /var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
> Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
> Fedora - Rawhide - Developmental packages for the next Fedora release
>  1.6 MB/s | 1.6 kB 00:00
> GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> (0x9570FF31) is already installed
> The GPG keys listed for the "Fedora - Rawhide - Developmental packages
> for the next Fedora release" repository are already installed but they
> are not correct for this package.
> Check that the correct key URLs are configured for this repository..
> Failing package is: fedora-gpg-keys-34-0.2.noarch
>  GPG Keys are configured as:
> file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
> The downloaded packages were saved in cache until the next successful
> transaction.
> You can remove cached packages by executing 'dnf clean packages'.
> Error: GPG check FAILED
>
> I have complained two release before and this is still the same. It
> always break on new release. The only option now is to install it by
> hand from koji, where it is not yet signed (yuck!)
>
> # dnf install
> https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm
>
> Then your commands would work, followed by normal upgrade.
>
> Filled bug #1872248 for it. It should finally work without user even
> fiddling with gpg keys manually. Is there some pressure to keep users
> from using rawhide?
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1872248
>
> On 8/17/20 1:42 PM, Vít Ondruch wrote:
>> Just as a reminder to all Rawhide users, this is the easiest way to keep
>> using Rawhide after branching:
>>
>>
>> ~~~
>>
>> $ sudo dnf update fedora-gpg-keys
>>
>> $ sudo dnf update fedora-repos --release 34
>>
>> ~~~
>>
>>
>> Unfortunately, there has been no progress on [1] during past months.
>>
>>
>>
>> Vít
>>
>>
>>
>>  [1] https://pagure.io/releng/issue/7445
>
> ___
> 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


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

Re: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Daniel P . Berrangé 
On Tue, Aug 25, 2020 at 11:40:21AM +0200, Petr Menšík wrote:
> Hi Vít,
> 
> Unfortunately your workaround does not on my rawhide container. I think
> the problem is in missing gpg keys from fedora-gpg-keys, which do not
> contain also architecture specific keys.

When you say "rawhide container", where are you pulling the base image
from ?  If you're pulling from docker.io, then perhaps you are hitting
the same problem as me, which is that the image hasn't been updated in
over a month:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5QDNMCJHH2JY4E2WDKEKBOMLP3QKGS3S/


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: [HOWTO] Keep using Rawhide after branching

2020-08-25 Thread Petr Menšík 
Hi Vít,

Unfortunately your workaround does not on my rawhide container. I think
the problem is in missing gpg keys from fedora-gpg-keys, which do not
contain also architecture specific keys.

# rpm -q fedora-repos fedora-repos-rawhide fedora-gpg-keys
fedora-repos-33-0.9.noarch
fedora-repos-rawhide-33-0.9.noarch
fedora-gpg-keys-33-0.9.noarch

# sudo dnf -y --enablerepo=updates --enablerepo=rawhide update
fedora-gpg-keys
Last metadata expiration check: 0:54:22 ago on Tue Aug 25 10:24:53 2020.
Dependencies resolved.
=
 Package   Architecture
Version  Repository Size
=
Upgrading:
 fedora-gpg-keys   noarch
34-0.2   rawhide   105 k

Transaction Summary
=
Upgrade  1 Package

Total size: 105 k
Downloading Packages:
[SKIPPED] fedora-gpg-keys-34-0.2.noarch.rpm: Already downloaded

warning:
/var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/fedora-gpg-keys-34-0.2.noarch.rpm:
Header V4 RSA/SHA256 Signature, key ID 45719a39: NOKEY
Fedora - Rawhide - Developmental packages for the next Fedora release
 1.6 MB/s | 1.6 kB 00:00
GPG key at file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
(0x9570FF31) is already installed
The GPG keys listed for the "Fedora - Rawhide - Developmental packages
for the next Fedora release" repository are already installed but they
are not correct for this package.
Check that the correct key URLs are configured for this repository..
Failing package is: fedora-gpg-keys-34-0.2.noarch
 GPG Keys are configured as:
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-33-x86_64
The downloaded packages were saved in cache until the next successful
transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED

I have complained two release before and this is still the same. It
always break on new release. The only option now is to install it by
hand from koji, where it is not yet signed (yuck!)

# dnf install
https://kojipkgs.fedoraproject.org//packages/fedora-repos/34/0.2/noarch/fedora-gpg-keys-34-0.2.noarch.rpm

Then your commands would work, followed by normal upgrade.

Filled bug #1872248 for it. It should finally work without user even
fiddling with gpg keys manually. Is there some pressure to keep users
from using rawhide?

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

On 8/17/20 1:42 PM, Vít Ondruch wrote:
> Just as a reminder to all Rawhide users, this is the easiest way to keep
> using Rawhide after branching:
> 
> 
> ~~~
> 
> $ sudo dnf update fedora-gpg-keys
> 
> $ sudo dnf update fedora-repos --release 34
> 
> ~~~
> 
> 
> Unfortunately, there has been no progress on [1] during past months.
> 
> 
> 
> Vít
> 
> 
> 
>  [1] https://pagure.io/releng/issue/7445

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



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

Does ELN SIG have some issue tracker?

2020-08-25 Thread Vít Ondruch 
Looking at the ELN SIG page [1], there is no contact information, no ML,
no issue tracker. I would like to discuss bootstrapping issues such as
[2], but there is no place to provide any feedback. Is this group
working under cover?

(Using the minimization tracker [3], where a lot of ELN stuff appears to
end up, does not feel appropriate).


Vít


[1] https://fedoraproject.org/wiki/ELN

[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1599965

[3] https://github.com/minimization/

___
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

2020-08-25 Thread Miro Hrončok 

On 25. 08. 20 10:51, Fabio Valentini wrote:
On Tue, Aug 25, 2020, 10:45 Miro Hrončok > wrote:


On 25. 08. 20 5:52, Michel Alexandre Salim wrote:
 > I'll properly retire lua-logging and luadoc, but keep lua-sql.

Let's merge the retirement commits to f33 as well?


Doesn't "fedpkg retire" do more than just push something to git, e.g. publish 
retirement information to PDC or something? So IIUC just merging the retirement 
commit to f33 won't be enough since it won't block the package in koji.


It used to (with pkgdb) now it doesn't.

This is how I retire orphaned packages between branching and beta freeze:

fedpkg clone $pkg && \
cd $pkg && \
fedpkg switch-branch f33 && \
fedpkg retire "Orphaned for 6+ weeks" && \
fedpkg switch-branch master && \
git merge f33 && \
git push

(There used to be a rule to retire older branches first, but I suppose that is 
no longer required and the command might be simplified.)


It works fine (except for a slight period when retirements on f33 were broken, 
but that was a server side issue, not the command).


--
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: GCC "-fparallel-jobs" up to ~1.9x speedup when compiling individual files in parallel

2020-08-25 Thread Daniel P . Berrangé 
On Sat, Aug 22, 2020 at 12:53:24PM +0200, Germano Massullo wrote:
> I think soon we will have a big boost in Koji performances thanks to
> Giuliano Belinassi and his work on addressing GCC parallelization
> bottlenecks. According to Phoronix, compiling individual files in
> parallel may have up to ~1.9x speedup:
> https://www.phoronix.com/scan.php?page=news_item&px=GCC-fparallel-jobs-Patches

AFAICT, that is referring to parallelizing single file compilation to
make use of multiple cores. That's only useful if the other cores on
your host are otherwise idle.

In koji we use parallel make (or equivalent) so that multiple files
are compiled in parallel. Thus most of the time all cores will be fully
utilized.

IOW, don't get too excited by the x1.9 speedup claim. I doubt we'll
see that in kojki except in niche scenarios where a project's build
is bottlenecked by a serialization point on compiling one file.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20200825.0 compose check report

2020-08-25 Thread Fedora compose checker 
No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-32-20200824.0):

ID: 647295  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/647295

Passed openQA tests: 6/7 (x86_64)
-- 
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: Orphaned packages looking for new maintainers

2020-08-25 Thread Fabio Valentini 
On Tue, Aug 25, 2020, 10:45 Miro Hrončok  wrote:

> On 25. 08. 20 5:52, Michel Alexandre Salim wrote:
> > I'll properly retire lua-logging and luadoc, but keep lua-sql.
>
> Let's merge the retirement commits to f33 as well?
>

Doesn't "fedpkg retire" do more than just push something to git, e.g.
publish retirement information to PDC or something? So IIUC just merging
the retirement commit to f33 won't be enough since it won't block the
package in koji.

Fabio


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

2020-08-25 Thread Miro Hrončok 

On 25. 08. 20 5:52, Michel Alexandre Salim wrote:

I'll properly retire lua-logging and luadoc, but keep lua-sql.


Let's merge the retirement commits to f33 as well?

--
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: Unannounced soname bump of openvdb from libopenvdb.so.7.0 to libopenvdb.so.7.1

2020-08-25 Thread Miro Hrončok 

On 25. 08. 20 8:44, Luya Tshimbalanga wrote:


On 2020-08-24 2:16 a.m., Miro Hrončok wrote:

Luya,

1) do you plan to update this in Fedora 33 as well?

Yes.


Please let me know when ready and we can build all three packages in a side tag.

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