Re: RPM package for gql

[Nico Kadel-Garcia]

Why not look into the "pyprpm" tool to build a source RPM to start
with, to see if it has the dependency stack of doom common to some
other python modules?

On Tue, Oct 6, 2020 at 12:19 AM Sreeraj  wrote:
>
> gql from https://github.com/graphql-python/gql is very widely used python 
> client for graphql (stars in the github repo would tell you that.)
> Can we have an RPM for the python package ? Current stable version is present 
> in v2.x branch.
>
> Let me know if this is not the right place to put this.
> ___
> 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: F33 podman: unpacking of archive failed cpio: cap_set_file

[Lumír Balhar]

On 10/5/20 2:32 PM, Miro Hrončok wrote:

On 05. 10. 20 14:23, Miro Hrončok wrote:

On 05. 10. 20 14:08, Daniel Walsh wrote:


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc


Hi.

The update is unpushed and there is no active update for Fedora 33 now. 



Lumír


Lokesh can you explain what is going on?


The CI system had an outage:

https://lists.centos.org/pipermail/ci-users/2020-October/002124.html

So the tests never run and since the package is gated, it failed.

I suppose the CI test needs to be restarted, however, I don't know how.

I'd open a ticket at https://pagure.io/fedora-ci/general/issues


However, bodhi does to let me to resubmit the update:

Cannot submit skopeo ('1', '1.2.0', '2.fc33') to testing since it is 
older than ('1', '1.2.0', '3.fc33')


And indeed, skopeo-1.2.0-3.fc33 seem to be in:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b6058fec9



I can confirm that with containers-common 1:1.2.0-3.fc33 it works again.

Thank you!

Lumír
___
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

RPM package for gql

[Sreeraj]

gql from https://github.com/graphql-python/gql is very widely used python 
client for graphql (stars in the github repo would tell you that.)
Can we have an RPM for the python package ? Current stable version is present 
in v2.x branch.

Let me know if this is not the right place to put this.
___
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 Final Freeze

[Mohan Boddu]

Hi all,

Tomorrow, October 6th 2020, is an important day on the Fedora 33
schedule [1], with significant cut-offs.

Tomorrow we have the Final Freeze [2] which starts at 14:00 UTC. This
means that only packages which fix accepted blocker or freeze
exception bugs [3][4][5] will be marked as 'stable' and included in
the Final composes. Other builds will remain in updates-testing until
the Final release is approved, at which point the Final freeze is
lifted and packages can move to the 'updates' repository, pending
updates will be pushed before final release as zero day updates.

[1] https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://qa.fedoraproject.org/blockerbugs/milestone/33/final/buglist

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

Fedora-IoT-34-20201005.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

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

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

ID: 685497  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/685497

Passed openQA tests: 15/16 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.24 to 0.35
Previous test data: https://openqa.fedoraproject.org/tests/679171#downloads
Current test data: https://openqa.fedoraproject.org/tests/685498#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: Fedora 32/33 livedisks do not boot on M$ system(s)

[Chris Murphy]

On Mon, Oct 5, 2020 at 12:59 PM Samuel Sieb  wrote:
>
> On 10/5/20 11:21 AM, Marius Schwarz wrote:
> > Am 04.10.20 um 21:01 schrieb Samuel Sieb:
> >> On 10/4/20 9:36 AM, Marius Schwarz wrote:
> >>> And still,we do not know why the f33 livedisc does not boot at all when
> >>> inserted early
> >>> AND
> >>> why grub-install /dev/USBDRIVE  (correct devicename ofcourse ) is
> >>> overwriting the ssd boot setup, instead of the usbdrive bootconfig.
> >>
> >> You can't use "grub2-install /dev/USBDRIVE", that's for non-EFI
> >> systems.  And as Chris explained, you can't use "grub2-install" either
> >> or it will mess things up badly.
> >
> > So, this is a loose-loose-situation.
> >
> > Still, how the heck could the system be installed in the first place,
> > because it was booted with secure-boot enabled? :)
>
> I don't understand why you think that would be a problem.  You left out
> the following line.
>
> >>If you have the usb drive EFI partition mounted at /boot/efi, then
> >> re-installing "grub2-efi" should fix the grub install on your usb drive.
>
> When Fedora is installed on a UEFI system, the "grub2-efi" package is
> installed which puts grub on the EFI partition where it should be.  If
> you want to fix the grub install, then you need to reinstall that
> package with the right EFI partition mounted at /boot/efi.

Right and this cannot be done with a USB stick imaged using dd (or
variant including Fedora Media Writer) from a Fedora produced ISO
image. And that's because that image is a read-only ISO 9660 file
system. Hence my advice in related bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1883609#c30

In this case  you can replace it by just copying a substitute
grubx64.efi to the proper location on the USB stick... which might be
EFI/BOOT, I'd have to poke it with a stick to find out.


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

Fedora-33-20201005.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Failed openQA tests: 6/181 (x86_64)

New failures (same test not failed in Fedora-33-20201004.n.1):

ID: 685236  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/685236
ID: 685269  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/685269
ID: 685293  Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/685293
ID: 685353  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/685353

Old failures (same test failed in Fedora-33-20201004.n.1):

ID: 685276  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/685276
ID: 685287  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/685287

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

Old soft failures (same test soft failed in Fedora-33-20201004.n.1):

ID: 685212  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/685212
ID: 685231  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/685231
ID: 685258  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/685258
ID: 685271  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/685271
ID: 685291  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/685291
ID: 685294  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/685294
ID: 685308  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/685308
ID: 685320  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/685320
ID: 685321  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/685321
ID: 685342  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/685342
ID: 685345  Test: x86_64 universal upgrade_2_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/685345

Passed openQA tests: 164/181 (x86_64)

New passes (same test not passed in Fedora-33-20201004.n.1):

ID: 685286  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/685286
ID: 685356  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/685356
ID: 685365  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/685365

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
Used swap changed from 20 MiB to 34 MiB
1 packages(s) added since previous compose: systemd-networkd
Previous test data: https://openqa.fedoraproject.org/tests/684437#downloads
Current test data: https://openqa.fedoraproject.org/tests/685255#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used swap changed from 14 MiB to 29 MiB
1 packages(s) added since previous compose: systemd-networkd
System load changed from 0.91 to 0.61
Average CPU usage changed from 35.17619048 to 16.62857143
Previous test data: https://openqa.fedoraproject.org/tests/684439#downloads
Current test data: https://openqa.fedoraproject.org/tests/685257#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 881 MiB to 974 MiB
1 packages(s) added since previous compose: systemd-networkd
Previous test data: https://openqa.fedoraproject.org/tests/684456#downloads
Current test data: https://openqa.fedoraproject.org/tests/685274#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 packages(s) added since previous compose: systemd-networkd
System load changed from 1.10 to 1.26
Previous test data: https://openqa.fedoraproject.org/tests/684457#downloads
Current test data: https://openqa.fedoraproject.org/tests/685275#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default_upload: 
Used swap changed from 18 MiB to 13 MiB
Previous test data: https://openqa.fedoraproject.org/tests/684473#downloads
Current test data: https://openqa.fedoraproject.org/tests/685291#downloads

Installed system changes in test x86_64 Silverblue-dvd_ostree-iso 
install_default@uefi: 
System load changed from 0.40 to 0.67
Previous test data: https://openqa.fedoraproject.org/tests/684476#downloads
Current test data: https://openqa.fedoraproject.org/tests/685294#downloads

Installed system changes in test x86_64 universal install_package_set_kde: 
Used swap changed from 6 MiB to 4

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Denys Vlasenko]

On 9/28/20 6:44 AM, Paul Wouters wrote:



Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved


I was just hit by the first bug in systemd-resolved 4 days after I
upgraded to fedora33. I will file a bug report for that, but I wanted
to discuss something more fundamental.

systemd-resolved has a number of architectural flaws. When these were
pointed out, bugs are not accepted and closed or ignored. Worse, I
was told that systemd-resolved would not become the system DNS resolver,
so I could just choose to not use it.

Unfortunately, with my upgrade to fedora 33 I was unwittingly upgraded
to systemd-resolved. I want to remove it from my system, but I cannot
because it is not even a sub-package of systemd, it is part of the
core systemd package. This goes against promises made in the past.


First time?
It's standard operating procedure for systemd from the inception
of that project.
___
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 package provide qmake?

[Rex Dieter]

Robbi Nespu wrote:

> Hello there, I want to get involve with KDE development. I have follow
> the step from https://community.kde.org/Get_Involved/development but
> unable to proceed to next step to build dolphin

(as root):
dnf builddep dolphin

will install everything the fedora's packaged dolphin needs to build.

-- Rex
___
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 compose report: 20201005.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-33-20201004.n.1
NEW: Fedora-33-20201005.n.0

= SUMMARY =
Added images:62
Dropped images:  0
Added packages:  8
Dropped packages:0
Upgraded packages:   105
Downgraded packages: 0

Size of added packages:  5.68 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.54 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   157.49 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base qcow2 aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-33-20201005.n.0.aarch64.qcow2
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-33-20201005.n.0.iso
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-33-20201005.n.0.x86_64.tar.xz
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-33-20201005.n.0-sda.raw.xz
Image: Mate live x86_64
Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-33-20201005.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-33-20201005.n.0.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20201005.n.0.ppc64le.raw.xz
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-33-20201005.n.0.iso
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-33-20201005.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-33-20201005.n.0.iso
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-33-20201005.n.0.ppc64le.tar.xz
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-33-20201005.n.0.iso
Image: Cloud_Base raw-xz x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-33-20201005.n.0.x86_64.raw.xz
Image: Everything boot armhfp
Path: Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-33-20201005.n.0.iso
Image: Server boot x86_64
Path: Server/x86_64/iso/Fedora-Server-netinst-x86_64-33-20201005.n.0.iso
Image: Server dvd x86_64
Path: Server/x86_64/iso/Fedora-Server-dvd-x86_64-33-20201005.n.0.iso
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-33-20201005.n.0.iso
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-33-20201005.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-33-20201005.n.0.x86_64.vagrant-libvirt.box
Image: Workstation live ppc64le
Path: 
Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-33-20201005.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-33-20201005.n.0.iso
Image: Minimal raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Minimal-armhfp-33-20201005.n.0-sda.raw.xz
Image: Container_Minimal_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Minimal-Base-33-20201005.n.0.x86_64.tar.xz
Image: Workstation live x86_64
Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-33-20201005.n.0.iso
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-33-20201005.n.0.iso
Image: Everything boot s390x
Path: Everything/s390x/iso/Fedora-Everything-netinst-s390x-33-20201005.n.0.iso
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-33-20201005.n.0.aarch64.tar.xz
Image: Python_Classroom live x86_64
Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-33-20201005.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-33-20201005.n.0.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-33-20201005.n.0.iso
Image: Everything boot x86_64
Path: Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-33-20201005.n.0.iso
Image: Server boot aarch64
Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-33-20201005.n.0.iso
Image: Cloud_Base raw-xz aarch64
Path: Cloud/aarch64/images/Fedora-Cloud-Base-33-20201005.n.0.aarch64.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-33-20201005.n.0.ppc64le.qcow2
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-33-20201005.n.0.x86_64.vagrant-virtualbox.box
Image: Server dvd aarch64
Path: Server/aarch64/iso/Fedora-Server-dvd-aarch64-33-20201005.n.0.iso
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-33-20201005.n.0.aarch64.raw.xz
Image: SoaS live x86_64
Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-33-20201005.n.0.iso
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-33-20201005.n.0.x86_64.vagrant-virtualbox.box
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-33-20201005.n.0.aarch64.tar.xz
Image: Cloud_Base tar-gz x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-33-20201005.n.0.x86_64.tar.gz
Image: Xfce

Re: Self Indroduction: Rafael Jeffman

[Matthew Miller]

On Mon, Oct 05, 2020 at 05:46:52PM -0300, Rafael Jeffman wrote:
> I am involved in the development of ansible-freeipa (
> https://github.com/freeipa/ansible-freeipa) and plan to co-maintain it for
> Fedora.

Cool, welcome!

> 
> Years ago I helped with the development and packages for an alternative
> Linux distribution, GoboLinux (https://gobolinux.org), which I helped
> develop from the start.

Nice! While it was never my thing, I appreciate the experimental approach
and willingness to try new things GoboLinux represents!



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

Intel specs

[Robert-André Mauchin]

Hello,

Could someone buddy-buddy with Intel and who has patience can give feedback on 
their Review Requests:

https://bugzilla.redhat.com/show_bug.cgi?id=1771343
https://github.com/intel-secl/trustagent/blob/v1.5.1/packages/trustagent-linux/src/build/trustagent-linux.spec

https://bugzilla.redhat.com/show_bug.cgi?id=1771338
https://github.com/intel-secl/verification-service/blob/v1.5.1/packages/host-verification-service-linux/src/build/host-verification-service.spec

https://bugzilla.redhat.com/show_bug.cgi?id=1771346
https://github.com/intel-secl/attestation-hub/blob/v1.5.1/packages/attestation-hub/src/build/attestation-hub.spec

This is above my paygrade.

Thanks to all,

Robert-André

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

Self Indroduction: Rafael Jeffman

[Rafael Jeffman]

Hello,

I am involved in the development of ansible-freeipa (
https://github.com/freeipa/ansible-freeipa) and plan to co-maintain it for
Fedora.

Years ago I helped with the development and packages for an alternative
Linux distribution, GoboLinux (https://gobolinux.org), which I helped
develop from the start.

I'm still learning the tools for building packages for Fedora, but since I
am doing the upstream development on the project, it is convenient to do
both, so the package can be updated in a more responsive way, avoiding
issues due to outdated versions, as happened recently.

Regards,

Rafael

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

Re: Follow-up - Please BuildRequire python3-setuptools explicitly

[Ankur Sinha]

On Mon, Oct 05, 2020 12:55:49 +0200, Tomas Hrnciar wrote:
> 
> ankursinha arbor python-petlink 

I've fixed both of these now. Apologies for the delay.

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

Fedora-Rawhide-20201004.n.1 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 10/181 (x86_64)

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

ID: 684990  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/684990
ID: 685146  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/685146
ID: 685148  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/685148

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

ID: 685014  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/685014
ID: 685018  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/685018
ID: 685026  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/685026
ID: 685049  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/685049
ID: 685110  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/685110
ID: 685144  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/685144
ID: 685147  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/685147

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

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

ID: 684966  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/684966
ID: 684985  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/684985
ID: 685012  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/685012

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

ID: 685025  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/685025
ID: 685045  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/685045
ID: 685048  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/685048
ID: 685062  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/685062
ID: 685075  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/685075

Passed openQA tests: 148/181 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20201003.n.0):

ID: 685085  Test: x86_64 universal install_blivet_resize_lvm
URL: https://openqa.fedoraproject.org/tests/685085

Skipped gating openQA tests: 4/181 (x86_64)

New skipped gating tests (same test not skipped in Fedora-Rawhide-20201003.n.0):

ID: 685151  Test: x86_64 KDE-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/685151
ID: 685152  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/685152
ID: 685161  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/685161
ID: 685163  Test: x86_64 KDE-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/685163

Skipped non-gating openQA tests: 11 of 181

Installed system changes in test x86_64 Server-boot-iso install_default: 
Used mem changed from 184 MiB to 207 MiB
System load changed from 0.09 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/683993#downloads
Current test data: https://openqa.fedoraproject.org/tests/684964#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
Used mem changed from 186 MiB to 209 MiB
Previous test data: https://openqa.fedoraproject.org/tests/683994#downloads
Current test data: https://openqa.fedoraproject.org/tests/684965#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 0.13 to 0.26
Previous test data: https://openqa.fedoraproject.org/tests/684003#downloads
Current test data: https://openqa.fedoraproject.org/tests/684974#downloads

Installed system changes in test x86_64 Everything-boot-iso install_default: 
Used mem changed from 140 MiB to 162 MiB
Previous test data: https://openqa.fedoraproject.org/tests/684035#downloads
Current test data: https://openqa.fedoraproject.org/tests/685006#downloads

Installed system changes in test x86_64 Everything-boot-iso 
install_default@uefi: 
Used mem changed from 140 MiB to 163 MiB
Previous test data: https://ope

Re: Donate 1 minute of your time to test upgrades from F32 to F33

[Przemek Klosowski via devel]

On 10/2/20 3:50 AM, Miroslav Suchý wrote:

Do you want to make Fedora 33 better? Please spend 1 minute of your time and 
try to run:

   sudo dnf --releasever=33 --setopt=module_platform_id=platform:f33 \
 --enablerepo=updates-testing --enablerepo=updates-testing-modular \
 distro-sync


Fedora 33 openh264 (From Cisco) - x86_64 8.9 kB/s | 5.1 kB 00:00
Fedora Modular 33 - x86_64 2.0 MB/s | 3.3 MB 00:01
Fedora Modular 33 - x86_64 - Updates 712  B/s | 257  B 00:00
Fedora Modular 33 - x86_64 - Test Updates 1.3 MB/s | 1.0 MB 00:00
Fedora 33 - x86_64 - Test Updates 4.6 MB/s |  18 MB 00:03
Fedora 33 - x86_64 - Updates 844  B/s | 257  B 00:00
Fedora 33 - x86_64 6.4 MB/s |  65 MB 00:10
RPM Fusion for Fedora 33 - Free - Updates 363  B/s | 257  B 00:00
RPM Fusion for Fedora 33 - Free 969 kB/s | 913 kB 00:00
RPM Fusion for Fedora 33 - Nonfree - Updates 629  B/s | 257  B 00:00
RPM Fusion for Fedora 33 - Nonfree 339 kB/s | 278 kB 00:00
Error:
 Problem 1: problem with installed package mosquitto-1.6.10-1.fc32.x86_64
  - mosquitto-1.6.10-1.fc32.x86_64 does not belong to a distupgrade 
repository
  - nothing provides libwebsockets.so.16()(64bit) needed by 
mosquitto-1.6.12-1.fc33.x86_64
 Problem 2: package collectd-mqtt-5.9.2-2.fc32.x86_64 requires 
collectd(x86-64) = 5.9.2-2.fc32, but none of the providers can be installed
  - collectd-5.9.2-2.fc32.x86_64 does not belong to a distupgrade 
repository

  - problem with installed package collectd-mqtt-5.9.2-2.fc32.x86_64
 Problem 3: package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_common.so.1.9()(64bit), but none of the providers can be installed
  - package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_io.so.1.9()(64bit), but none of the providers can be installed
  - package gtatool-pcd-2.2.3-6.fc33.x86_64 requires 
libpcl_octree.so.1.9()(64bit), but none of the providers can be installed

  - problem with installed package gtatool-pcd-2.2.3-4.fc32.x86_64
  - pcl-1.9.1-6.fc32.x86_64 does not belong to a distupgrade repository
  - gtatool-pcd-2.2.3-4.fc32.x86_64 does not belong to a distupgrade 
repository
 Problem 4: package qgis-3.12.1-4.fc33.x86_64 requires 
libQt5Core.so.5(Qt_5.14.2_PRIVATE_API)(64bit), but none of the providers 
can be installed
  - package qgis-3.12.1-4.fc33.x86_64 requires 
libQt5Sql.so.5(Qt_5.14.2_PRIVATE_API)(64bit), but none of the providers 
can be installed

  - problem with installed package qgis-3.12.1-4.fc32.x86_64
  - qt5-qtbase-5.14.2-5.fc32.x86_64 does not belong to a distupgrade 
repository

  - qgis-3.12.1-4.fc32.x86_64 does not belong to a distupgrade repository
(try to add '--skip-broken' to skip uninstallable 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 rawhide compose report: 20201004.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201003.n.0
NEW: Fedora-Rawhide-20201004.n.1

= SUMMARY =
Added images:7
Dropped images:  1
Added packages:  1
Dropped packages:0
Upgraded packages:   133
Downgraded packages: 0

Size of added packages:  129.14 KiB
Size of dropped packages:0 B
Size of upgraded packages:   2.33 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   10.94 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Cloud_Base vagrant-libvirt x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-libvirt.box
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20201004.n.1-sda.raw.xz
Image: Mate raw-xz armhfp
Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20201004.n.1-sda.raw.xz
Image: Cloud_Base vagrant-virtualbox x86_64
Path: 
Cloud/x86_64/images/Fedora-Cloud-Base-Vagrant-Rawhide-20201004.n.1.x86_64.vagrant-virtualbox.box
Image: Server raw-xz armhfp
Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20201004.n.1-sda.raw.xz
Image: LXQt raw-xz armhfp
Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20201004.n.1-sda.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201004.n.1-sda.raw.xz

= DROPPED IMAGES =
Image: Jam_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20201003.n.0.iso

= ADDED PACKAGES =
Package: python-zope-i18nmessageid-4.0.3-21.fc34
Summary: Message Identifiers for internationalization
RPMs:python3-zope-i18nmessageid
Size:129.14 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  AusweisApp2-1.20.2-9.fc34
Old package:  AusweisApp2-1.20.2-8.fc34
Summary:  Online identification with German ID card (Personalausweis)
RPMs: AusweisApp2 AusweisApp2-data AusweisApp2-doc
Size: 22.90 MiB
Size change:  -1.98 KiB
Changelog:
  * Sat Oct 03 2020 Bj??rn Esser  - 1.20.2-9
  - Disable fipscheck in shell wrapper as it does not work in Fedora 33+


Package:  akonadi-calendar-tools-20.08.1-1.fc34
Old package:  akonadi-calendar-tools-20.08.0-1.fc34
Summary:  Akonadi Calendar Tools
RPMs: akonadi-calendar-tools
Size: 1.20 MiB
Size change:  6.91 KiB
Changelog:
  * Tue Sep 15 2020 Rex Dieter  - 20.08.1-1
  - 20.08.1


Package:  akonadi-import-wizard-20.08.1-1.fc34
Old package:  akonadi-import-wizard-20.08.0-1.fc34
Summary:  Akonadi Import Wizard
RPMs: akonadi-import-wizard akonadi-import-wizard-devel
Size: 2.96 MiB
Size change:  -2.31 KiB
Changelog:
  * Tue Sep 15 2020 Rex Dieter  - 20.08.1-1
  - 20.08.1


Package:  akonadiconsole-20.08.1-1.fc34
Old package:  akonadiconsole-20.08.0-1.fc34
Summary:  Akonadi developer tool
RPMs: akonadiconsole
Size: 1.60 MiB
Size change:  -385 B
Changelog:
  * Tue Sep 15 2020 Rex Dieter  - 20.08.1-1
  - 20.08.1


Package:  akregator-20.08.1-1.fc34
Old package:  akregator-20.08.0-1.fc34
Summary:  Feed Reader
RPMs: akregator akregator-libs
Size: 8.13 MiB
Size change:  -561 B
Changelog:
  * Tue Sep 15 2020 Rex Dieter  - 20.08.1-1
  - 20.08.1


Package:  blivet-gui-2.2.1-1.fc34
Old package:  blivet-gui-2.2.0-1.fc34
Summary:  Tool for data storage configuration
RPMs: blivet-gui blivet-gui-runtime
Size: 319.66 KiB
Size change:  854 B
Changelog:
  * Tue Sep 29 2020 Vojtech Trefny  - 2.2.1-1
  - Translated using Weblate (Friulian) (f.t.public)
  - Fix ValueError when trying to set both upper and lower size limits (vtrefny)
  - Fix getting list of supported filesystems in installer mode (vtrefny)
  - Fix missing attribute _resizable_filesystems in BlivetUtilsAnaconda 
(vtrefny)
  - Translated using Weblate (Friulian) (f.t.public)
  - Update translation files (noreply)
  - Translated using Weblate (Turkish) (oguzersen)
  - Sync spec with downstream (vtrefny)


Package:  boinc-tui-2.5.0-4.fc34
Old package:  boinc-tui-2.5.0-4.fc33
Summary:  Fullscreen Text Mode Manager For BOINC Client
RPMs: boinc-tui
Size: 667.25 KiB
Size change:  -386 B

Package:  bst-external-0.21.0-1.fc34
Old package:  bst-external-0.20.0-3.fc33
Summary:  Additional BuildStream plugins
RPMs: bst-external
Size: 93.72 KiB
Size change:  113 B
Changelog:
  * Sat Oct 03 2020 Artem Polishchuk  - 0.21.0-1
  - Update to 0.21.0


Package:  buildstream-1.6.0-1.fc34
Old package:  buildstream-1.4.3-1.fc34
Summary:  Build/integrate software stacks
RPMs: buildstream buildstream-docs
Size: 5.30 MiB
Size change:  15.50 KiB
Changelog:
  * Sat Oct 03 2020 Artem Polishchuk  - 1.6.0-1
  - Update to 1.6.0


Package:  compiler-rt-11.0.0-0.3.rc5.fc34
Old package:  compiler-rt-11.0.0-0.2.rc3.fc34
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 9.36 MiB
Size change:  235.38 KiB
Changelog:
  * Fri Oct 02 2020 sgue

Re: Fedora 32/33 livedisks do not boot on M$ system(s)

[Samuel Sieb]

On 10/5/20 11:21 AM, Marius Schwarz wrote:

Am 04.10.20 um 21:01 schrieb Samuel Sieb:

On 10/4/20 9:36 AM, Marius Schwarz wrote:

And still,we do not know why the f33 livedisc does not boot at all when
inserted early
AND
why grub-install /dev/USBDRIVE  (correct devicename ofcourse ) is
overwriting the ssd boot setup, instead of the usbdrive bootconfig.


You can't use "grub2-install /dev/USBDRIVE", that's for non-EFI
systems.  And as Chris explained, you can't use "grub2-install" either
or it will mess things up badly.


So, this is a loose-loose-situation.

Still, how the heck could the system be installed in the first place,
because it was booted with secure-boot enabled? :)


I don't understand why you think that would be a problem.  You left out 
the following line.



   If you have the usb drive EFI partition mounted at /boot/efi, then
re-installing "grub2-efi" should fix the grub install on your usb drive.


When Fedora is installed on a UEFI system, the "grub2-efi" package is 
installed which puts grub on the EFI partition where it should be.  If 
you want to fix the grub install, then you need to reinstall that 
package with the right EFI partition mounted at /boot/efi.

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

Re: Fedora 32/33 livedisks do not boot on M$ system(s)

[Marius Schwarz]

Am 04.10.20 um 21:01 schrieb Samuel Sieb:
> On 10/4/20 9:36 AM, Marius Schwarz wrote:
>> And still,we do not know why the f33 livedisc does not boot at all when
>> inserted early
>> AND
>> why grub-install /dev/USBDRIVE  (correct devicename ofcourse ) is
>> overwriting the ssd boot setup, instead of the usbdrive bootconfig.
>
> You can't use "grub2-install /dev/USBDRIVE", that's for non-EFI
> systems.  And as Chris explained, you can't use "grub2-install" either
> or it will mess things up badly.

So, this is a loose-loose-situation.

Still, how the heck could the system be installed in the first place,
because it was booted with secure-boot enabled? :)

>   If you have the usb drive EFI partition mounted at /boot/efi, then
> re-installing "grub2-efi" should fix the grub install on your usb drive.
>
> As for why the live image isn't booting, that really seems like a BIOS
> problem.

hard to tell, when there is nothing to debug on.

So i need to try the update to F32 (first version not to boot on usb)
and see what happens :(

ok, thanks to all for the affords.

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

Re: interest in debuginfod as fedora service

[Adam Williamson]

On Mon, 2020-10-05 at 13:35 -0400, Frank Ch. Eigler wrote:
> Adam Williamson  writes:
> 
> > This seems like it sort of overlaps a bit with what the abrt retrace
> > server does. It's not the same, but in order to do what it does, the
> > retrace server *does* need to act as a remote provider of debuginfo. I
> > wonder if it's possible to combine these somehow?
> 
> As I understand it, the retrace server doesn't serve debuginfo - it
> consumes it.  An exception appears to be the "symbol transfer" machinery
> (faf/pull/387 ?), but even there it appears to memoize individual symbol
> table lookup results, as opposed to transferring debuginfo dwarf files.

Well, I guess it doesn't exactly serve it out: rather, you send the
retrace server a coredump and it generates a backtrace locally, using a
store of debuginfo.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
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: interest in debuginfod as fedora service

[Frank Ch. Eigler]

Adam Williamson  writes:

> This seems like it sort of overlaps a bit with what the abrt retrace
> server does. It's not the same, but in order to do what it does, the
> retrace server *does* need to act as a remote provider of debuginfo. I
> wonder if it's possible to combine these somehow?

Another possible integration path would be simply to co-site the retrace
and debuginfod services.  The former already needs to mirror (or
directly access?) various distro RPMs.  debuginfod could use the retrace
server's rpm repo as its source.

- FChE
___
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: interest in debuginfod as fedora service

[Frank Ch. Eigler]

Adam Williamson  writes:

> This seems like it sort of overlaps a bit with what the abrt retrace
> server does. It's not the same, but in order to do what it does, the
> retrace server *does* need to act as a remote provider of debuginfo. I
> wonder if it's possible to combine these somehow?

As I understand it, the retrace server doesn't serve debuginfo - it
consumes it.  An exception appears to be the "symbol transfer" machinery
(faf/pull/387 ?), but even there it appears to memoize individual symbol
table lookup results, as opposed to transferring debuginfo dwarf files.

It would be possible to make faf a client of debuginfod, so such a
server could run in more places, not just at fedora HQ.

- FChE
___
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 package provide qmake?

[Samuel Sieb]

On 10/5/20 12:55 AM, Robbi Nespu wrote:

Unable to find qmake. This program is absolutely essential for building

Please ensure the development packages for
Qt are installed by using your distribution's package manager.


This is actually a tricky program to find, although this line provides a 
good hint.  The name of the program is actually "qmake-qt5" and it's 
provided by the "qt5-qtbase-devel" which should have been brought in if 
you've installed any of the other qt5 devel packages you'll be needing 
as 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: interest in debuginfod as fedora service

[Ben Woodard]

I for one really support this idea. 

Having immediate access to all the debuginfo for all the installed software 
really useful. The practical benefit is not entirely obvious. For example a 
week or so ago I needed to track down a problem with libboost and where it was 
storing a variable. So I ended up doing:

$ ~/bin/objdump  --dwarf=loc,follow-links /lib64/libboost_system.so.1.69.0 

Also being able to use userspace systemtap quickly and easily really is helpful

For example listing the functions in a library and what parameters they take is 
helpful. 

$ stap -L 'process("/lib64/libm.so.6").function("*").call'

It is really useful when you are looking at some unusual library that you 
aren't familiar with. All of these functions can become systemtap tracepoints 
that you tap into and monitor.

Having online access really makes it much more convenient. Yes you can 
debuginfo install things as needed and most of us have plenty of disk space and 
we don't mind installing the debuginfo in an ad hoc matter. But when you are 
working on minimal software sets like containers, you don't want to have to be 
installing all sorts of debuginfo in your containers while you are tracking 
down problems.

I think that overall providing online access to debuginfo through a debuginfod 
service is one of those things which may seem like redundant to something more 
manual but it is one of those things which is of creeping utility as you find 
that the convenience of it leads to you using it more (mostly indirectly) than 
you ever thought that you would just because it is always there.

-ben
___
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: interest in debuginfod as fedora service

[Adam Williamson]

On Mon, 2020-10-05 at 11:20 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> If you never use debuggers, tracing tools, profilers, crash dump
> analysis tools, go ahead and skip this note!
> 
> If you're still reading, you know you sometimes need debuginfo for the
> packages you're working with.  And you probably know that
> % sudo debuginfo-install 
> is still the official way of getting at it.  But did you know that we
> have a better way?
> 
> DEBUGINFOD has been a part of elfutils since late 2019.  It can serve
> debuginfo and source code for your own or for other people's binaries
> to a whole gamut of tools.  (GDB 10 will include support too!)  It
> works across HTTP, no root, no manual debuginfo-install, no big
> downloads, no big deal.  There are even some public servers that have
> some Fedora content already, as well as from other distros.  This page
> covers more about the client & server situation:
> 
>   https://sourceware.org/elfutils/Debuginfod.html
> 
> You can try it today against our test server:
> 
>   % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
>   % export DEBUGINFOD_PROGRESS=1
>   % # $debugger-type-tool /path/to/program
>   % eu-stack -v -p $$
>   % stap -L 'process.function("*").call' -c /bin/ls
> 
> 
> The problem is that Fedora itself doesn't run a server, and our test
> server can afford to carry only a subset of debuginfo/debugsource rpms
> & architectures.  So, fedora developers / users cannot get at all the
> info, or from an official source.  I wonder if it's time to get one
> set up.  If there is interest, I'd be happy to start discussing
> logistics with fedora infrastructure folks.

This seems like it sort of overlaps a bit with what the abrt retrace
server does. It's not the same, but in order to do what it does, the
retrace server *does* need to act as a remote provider of debuginfo. I
wonder if it's possible to combine these somehow?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
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

fio accidentally Provided a few libraries like librbd.so.1, libaio.so.1, librdma.so.1, etc

[Richard W.M. Jones]

Ooops:

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

It causes various packages like libvirt in Rawhide to be uninstallable
or not startable because dnf may prefer fio over the proper dependency.

Anyway it's fixed now so just make sure your Rawhide repo caches are
up to date.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: how to list contents of a side tag?

[Kevin Fenzi]

On Mon, Oct 05, 2020 at 12:08:11PM +0200, Miro Hrončok wrote:
> On 05. 10. 20 11:59, Zbigniew Jędrzejewski-Szmek wrote:
> > I'd like to introspect a side tag:
> > 'koji list-pkgs --tag f34-build-side-31299' lists many many packages.
> > 'koji list-pkgs --noinherit --tag f34-build-side-31299' lists nothing.
> > Is there some command which would list packages that are in the side tag?
> 
> Partial answer:
> 
> This will give you list of latest builds tagged into the side tag:
> 
> $ koji list-tagged --latest f34-build-side-31299
> 
> From that you can get package names via usual shell piping.
> 
> $ koji list-tagged f34-build-side-31299 | cut -f1 -d" " | pkgname
> 
> Similarly, this is the web UI for the same:
> 
> https://koji.fedoraproject.org/koji/builds?latest=1&tagID=31299&order=-completion_time&inherited=0
> 
> (Errors now, no idea why.)

https://pagure.io/koji/issue/2491 (already fixed upstream, will be in
next release). 

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: how to list contents of a side tag?

[Kevin Fenzi]

On Mon, Oct 05, 2020 at 09:59:06AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I'd like to introspect a side tag:
> 'koji list-pkgs --tag f34-build-side-31299' lists many many packages.
> 'koji list-pkgs --noinherit --tag f34-build-side-31299' lists nothing.
> Is there some command which would list packages that are in the side tag?

koji list-tagged f34-build-side-31299

> Also, is there a nice way to lists builds (failed or not, finished or not)
> done against the side tag?

no, because they only are tagged in when they work, failed or not
finished are not tagged into the side tag. 

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: Donate 1 minute of your time to test upgrades from F32 to F33

[Sashreek Shankar]

Hey!
while upgrading I get this error :

Problem: package nodejs-grunt-1.0.4-4.fc33.noarch requires (npm(rimraf) >= 2.0 
with npm(rimraf) < 3), but none of the providers can be installed
  - package nodejs-grunt-cli-1.2.0-9.fc32.noarch requires npm(grunt), but none 
of the providers can be installed
  - nodejs-rimraf-2.6.1-7.fc32.noarch does not belong to a distupgrade 
repository
  - nodejs-grunt-1.0.4-3.fc32.noarch does not belong to a distupgrade repository
  - problem with installed package nodejs-grunt-cli-1.2.0-9.fc32.noarch
___
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: Donate 1 minute of your time to test upgrades from F32 to F33

[Sven Kieske]

On Fr, 2020-10-02 at 09:50 +0200, Miroslav Suchý wrote:
> Do you want to make Fedora 33 better? Please spend 1 minute of your time and 
> try to run:
> 
>   # Run this only if you use default Fedora modules
>   # next time you run any DNF command default modules will be enabled again
>   sudo dnf module reset '*'
> 
>   sudo dnf --releasever=33 --setopt=module_platform_id=platform:f33 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync

Hi,

I got no real problems, but the following packages would get downgraded:

appstream-data
noarch   32-
7.fc33  fedora  
 17 M
 firefox   
x86_64   81.0.1-1.fc33  
updates-
testing 102 M
 radare2   
x86_64   4.5.0-
1.fc33.1 fedora 
 4.0 M
 radare2-common
noarch   4.5.0-
1.fc33.1 fedora 
 1.3 M
 strace
x86_64   5.7.0.6.7ab6-
1.fc33fedora
  1.1 M
 thunderbird   
x86_64   68.10.0-
1.fc33 fedora   
83 M


as far as I see there should be already bugreports for radare2 and strace.

I suppose firefox and thunderbird should not go unnoticed?

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske
Systementwickler
 
 
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 4-6
32339 Espelkamp
 
Tel.: 05772 / 293-900
Fax: 05772 / 293-333
 
https://www.mittwald.de
 
Geschäftsführer: Robert Meyer, Florian Jürgens
 
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit 
gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.



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: interest in debuginfod as fedora service

[Neal Gompa]

On Mon, Oct 5, 2020 at 11:21 AM Frank Ch. Eigler  wrote:
>
> Hi -
>
> If you never use debuggers, tracing tools, profilers, crash dump
> analysis tools, go ahead and skip this note!
>
> If you're still reading, you know you sometimes need debuginfo for the
> packages you're working with.  And you probably know that
> % sudo debuginfo-install
> is still the official way of getting at it.  But did you know that we
> have a better way?
>
> DEBUGINFOD has been a part of elfutils since late 2019.  It can serve
> debuginfo and source code for your own or for other people's binaries
> to a whole gamut of tools.  (GDB 10 will include support too!)  It
> works across HTTP, no root, no manual debuginfo-install, no big
> downloads, no big deal.  There are even some public servers that have
> some Fedora content already, as well as from other distros.  This page
> covers more about the client & server situation:
>
>   https://sourceware.org/elfutils/Debuginfod.html
>
> You can try it today against our test server:
>
>   % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
>   % export DEBUGINFOD_PROGRESS=1
>   % # $debugger-type-tool /path/to/program
>   % eu-stack -v -p $$
>   % stap -L 'process.function("*").call' -c /bin/ls
>
>
> The problem is that Fedora itself doesn't run a server, and our test
> server can afford to carry only a subset of debuginfo/debugsource rpms
> & architectures.  So, fedora developers / users cannot get at all the
> info, or from an official source.  I wonder if it's time to get one
> set up.  If there is interest, I'd be happy to start discussing
> logistics with fedora infrastructure folks.
>

This sounds great, I'd love to see this rolled out. Please file a
ticket in fedora-infrastructure:
https://pagure.io/fedora-infrastructure/issues




--
真実はいつも一つ！/ 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

interest in debuginfod as fedora service

[Frank Ch. Eigler]

Hi -

If you never use debuggers, tracing tools, profilers, crash dump
analysis tools, go ahead and skip this note!

If you're still reading, you know you sometimes need debuginfo for the
packages you're working with.  And you probably know that
% sudo debuginfo-install 
is still the official way of getting at it.  But did you know that we
have a better way?

DEBUGINFOD has been a part of elfutils since late 2019.  It can serve
debuginfo and source code for your own or for other people's binaries
to a whole gamut of tools.  (GDB 10 will include support too!)  It
works across HTTP, no root, no manual debuginfo-install, no big
downloads, no big deal.  There are even some public servers that have
some Fedora content already, as well as from other distros.  This page
covers more about the client & server situation:

  https://sourceware.org/elfutils/Debuginfod.html

You can try it today against our test server:

  % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
  % export DEBUGINFOD_PROGRESS=1
  % # $debugger-type-tool /path/to/program
  % eu-stack -v -p $$
  % stap -L 'process.function("*").call' -c /bin/ls


The problem is that Fedora itself doesn't run a server, and our test
server can afford to carry only a subset of debuginfo/debugsource rpms
& architectures.  So, fedora developers / users cannot get at all the
info, or from an official source.  I wonder if it's time to get one
set up.  If there is interest, I'd be happy to start discussing
logistics with fedora infrastructure folks.


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

Orphaned poetry and some of its dependencies

[Fabio Valentini]

Hi everybody,

I've decided to orphan poetry and some of its python dependencies.

I don't actually use those packages myself (I've seen the light and
switched to Rust for my own projects), and maintaining them has become
a major headache with the upstream projects being very "special".

Some of the packages are up-to-date, and the rest have pending pull
requests to update them to the latest version in preparation for
poetry 1.1.0 (which split off poetry/core directory into a separate
poetry-core / poetry.core python package, which will need to be
packaged separately , while taking care to not introduce conflicts
during packaging ...)

- poetry
- python-CacheControl
- python-cleo
- python-clikit
- python-crashtest
- python-lockfile
- python-pastel
- python-pkginfo
- python-pylev

I hope they can find a home with a packager who will give them the
love these packages do (or don't?) deserve.

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

Re: s390x: Fedora ELN switched to z13 baseline (in redhat-rpm-config)

[Richard Shaw]

On Mon, Oct 5, 2020 at 9:09 AM Florian Weimer  wrote:

> * Richard Shaw:
>
> > Excellent! I'm pretty sure this brings in some intrinsics that weren't
> > available in z11(?), so I had to excludearch s390x for one of my


> > packages. Now I just have to remember which one it was!
>
> Note that Fedora rawhide is still at zEC12, so the impact on your
> packages may be quite limited at this point.
>

Yes, 12, not 11. Was going from memory. No worries at this point, I'll keep
an eye on things and wait for the switchover.

Thanks,
Richard
___
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: s390x: Fedora ELN switched to z13 baseline (in redhat-rpm-config)

[Florian Weimer]

* Richard Shaw:

> Excellent! I'm pretty sure this brings in some intrinsics that weren't
> available in z11(?), so I had to excludearch s390x for one of my

z196?

> packages. Now I just have to remember which one it was!

Note that Fedora rawhide is still at zEC12, so the impact on your
packages may be quite limited at this point.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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: new dnf mode of listing upgraded packages

[Zbigniew Jędrzejewski-Szmek]

On Mon, Oct 05, 2020 at 09:17:46AM -0400, Neal Gompa wrote:
> On Mon, Oct 5, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On rawhide:
> > $ sudo dnf upgrade
> > 
> >  PackageArch   Version 
> > Repository  Size
> > 
> > Installing:
> >  kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
> > fedora-rawhide-kernel-nodebug
> > 
> >32 M
> >  kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
> > fedora-rawhide-kernel-nodebug
> > 
> >30 M
> > Upgrading:
> >  NetworkManager x86_64 1:1.26.2-2.fc34 
> > rawhide2.2 M
> >  replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
> > rawhide1.6 M
> >  replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-teamx86_64 1:1.26.2-2.fc34 
> > rawhide 31 k
> >  replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
> >  NetworkManager-wifix86_64 1:1.26.2-2.fc34 
> > rawhide 99 k
> >  replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
> >  OpenIPMI-libs  x86_64 2.0.29-1.fc34   
> > rawhide524 k
> >  replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
> >  abrt   x86_64 2.14.4-2.fc34   
> > rawhide497 k
> >  replacing  abrt.x86_64 2.14.2-5.fc33
> >  abrt-addon-ccppx86_64 2.14.4-2.fc34   
> > rawhide132 k
> >  replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
> >  abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
> > rawhide 50 k
> >  replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
> >  abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
> > rawhide 26 k
> >  replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
> >  abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
> > rawhide 37 k
> >  replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
> >  abrt-addon-xorgx86_64 2.14.4-2.fc34   
> > rawhide 41 k
> >  replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
> >  abrt-cli   x86_64 2.14.4-2.fc34   
> > rawhide 16 k
> >  abrt-dbus  x86_64 2.14.4-2.fc34   
> > rawhide 72 k
> >  replacing  abrt-dbus.x86_64 2.14.2-5.fc33
> >
> > Most packages that are upgraded are shown as "replacing" themselves. This is
> > technically true, but this mode of listing is very verbose. But not all 
> > packages
> > that are upgraded are listed like that, so I think there must be some 
> > additional
> > variable I'm missing?
> >
> > (This output takes a lot of space and is hard to scan quickly, so I can't 
> > say I
> > quite like it.)
> >
> > (dnf-4.2.23-2.fc33.noarch)
> >
> 
> "replacing" stanzas show up if Obsoletes are declared. That's how DNF
> tells you something is Obsoleting something else.

Not in this case. It turns out I had many duplicated packages on this system.
dnf seems to be saying that the upgrade is upgrading the newer
version of the package and removing the dup at the same time.
I think so, the output doesn't make this obvious.

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: s390x: Fedora ELN switched to z13 baseline (in redhat-rpm-config)

[Richard Shaw]

On Mon, Oct 5, 2020 at 8:14 AM Florian Weimer  wrote:

> We established a while back the the Fedora infrastructure is capable of
> running z13 binaries for the IBM Z (s390x) architecture, so I do not
> expect any issues.
>
> The rationale for this change is that this aligns with the toolchain
> default in Red Hat Enterprise Linux 8.
>
> The default built into gcc will be updated in a subsequent GCC update.
> It is usually overridden by the redhat-rpm-config settings anyway (if
> build flags injection is working at all).
>

Excellent! I'm pretty sure this brings in some intrinsics that weren't
available in z11(?), so I had to excludearch s390x for one of my packages.
Now I just have to remember which one it was!

Thanks,
Richard
___
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: new dnf mode of listing upgraded packages

[Neal Gompa]

On Mon, Oct 5, 2020 at 9:15 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On rawhide:
> $ sudo dnf upgrade
> 
>  PackageArch   Version 
> Repository  Size
> 
> Installing:
>  kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
> fedora-rawhide-kernel-nodebug
>   
>  32 M
>  kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
> fedora-rawhide-kernel-nodebug
>   
>  30 M
> Upgrading:
>  NetworkManager x86_64 1:1.26.2-2.fc34 
> rawhide2.2 M
>  replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
> rawhide1.6 M
>  replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-teamx86_64 1:1.26.2-2.fc34 
> rawhide 31 k
>  replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
>  NetworkManager-wifix86_64 1:1.26.2-2.fc34 
> rawhide 99 k
>  replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
>  OpenIPMI-libs  x86_64 2.0.29-1.fc34   
> rawhide524 k
>  replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
>  abrt   x86_64 2.14.4-2.fc34   
> rawhide497 k
>  replacing  abrt.x86_64 2.14.2-5.fc33
>  abrt-addon-ccppx86_64 2.14.4-2.fc34   
> rawhide132 k
>  replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
>  abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
> rawhide 50 k
>  replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
>  abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
> rawhide 26 k
>  replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
>  abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
> rawhide 37 k
>  replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
>  abrt-addon-xorgx86_64 2.14.4-2.fc34   
> rawhide 41 k
>  replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
>  abrt-cli   x86_64 2.14.4-2.fc34   
> rawhide 16 k
>  abrt-dbus  x86_64 2.14.4-2.fc34   
> rawhide 72 k
>  replacing  abrt-dbus.x86_64 2.14.2-5.fc33
>
> Most packages that are upgraded are shown as "replacing" themselves. This is
> technically true, but this mode of listing is very verbose. But not all 
> packages
> that are upgraded are listed like that, so I think there must be some 
> additional
> variable I'm missing?
>
> (This output takes a lot of space and is hard to scan quickly, so I can't say 
> I
> quite like it.)
>
> (dnf-4.2.23-2.fc33.noarch)
>

"replacing" stanzas show up if Obsoletes are declared. That's how DNF
tells you something is Obsoleting something else.



-- 
真実はいつも一つ！/ 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

new dnf mode of listing upgraded packages

[Zbigniew Jędrzejewski-Szmek]

On rawhide:
$ sudo dnf upgrade

 PackageArch   Version 
Repository  Size

Installing:
 kernel-corex86_64 5.9.0-0.rc7.20201002git.24.fc34 
fedora-rawhide-kernel-nodebug

   32 M
 kernel-modules x86_64 5.9.0-0.rc7.20201002git.24.fc34 
fedora-rawhide-kernel-nodebug

   30 M
Upgrading:
 NetworkManager x86_64 1:1.26.2-2.fc34 
rawhide2.2 M
 replacing  NetworkManager.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-libnm   x86_64 1:1.26.2-2.fc34 
rawhide1.6 M
 replacing  NetworkManager-libnm.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-teamx86_64 1:1.26.2-2.fc34 
rawhide 31 k
 replacing  NetworkManager-team.x86_64 1:1.26.2-1.fc34.1
 NetworkManager-wifix86_64 1:1.26.2-2.fc34 
rawhide 99 k
 replacing  NetworkManager-wifi.x86_64 1:1.26.2-1.fc34.1
 OpenIPMI-libs  x86_64 2.0.29-1.fc34   
rawhide524 k
 replacing  OpenIPMI-libs.x86_64 2.0.28-6.fc33
 abrt   x86_64 2.14.4-2.fc34   
rawhide497 k
 replacing  abrt.x86_64 2.14.2-5.fc33
 abrt-addon-ccppx86_64 2.14.4-2.fc34   
rawhide132 k
 replacing  abrt-addon-ccpp.x86_64 2.14.2-5.fc33
 abrt-addon-kerneloops  x86_64 2.14.4-2.fc34   
rawhide 50 k
 replacing  abrt-addon-kerneloops.x86_64 2.14.2-5.fc33
 abrt-addon-pstoreoops  x86_64 2.14.4-2.fc34   
rawhide 26 k
 replacing  abrt-addon-pstoreoops.x86_64 2.14.2-5.fc33
 abrt-addon-vmcore  x86_64 2.14.4-2.fc34   
rawhide 37 k
 replacing  abrt-addon-vmcore.x86_64 2.14.2-5.fc33
 abrt-addon-xorgx86_64 2.14.4-2.fc34   
rawhide 41 k
 replacing  abrt-addon-xorg.x86_64 2.14.2-5.fc33
 abrt-cli   x86_64 2.14.4-2.fc34   
rawhide 16 k
 abrt-dbus  x86_64 2.14.4-2.fc34   
rawhide 72 k
 replacing  abrt-dbus.x86_64 2.14.2-5.fc33

Most packages that are upgraded are shown as "replacing" themselves. This is
technically true, but this mode of listing is very verbose. But not all packages
that are upgraded are listed like that, so I think there must be some additional
variable I'm missing?

(This output takes a lot of space and is hard to scan quickly, so I can't say I
quite like it.)

(dnf-4.2.23-2.fc33.noarch)

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

s390x: Fedora ELN switched to z13 baseline (in redhat-rpm-config)

[Florian Weimer]

We established a while back the the Fedora infrastructure is capable of
running z13 binaries for the IBM Z (s390x) architecture, so I do not
expect any issues.

The rationale for this change is that this aligns with the toolchain
default in Red Hat Enterprise Linux 8.

The default built into gcc will be updated in a subsequent GCC update.
It is usually overridden by the redhat-rpm-config settings anyway (if
build flags injection is working at all).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F33 podman: unpacking of archive failed cpio: cap_set_file

[Miro Hrončok]

On 05. 10. 20 14:23, Miro Hrončok wrote:

On 05. 10. 20 14:08, Daniel Walsh wrote:


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc


Hi.

The update is unpushed and there is no active update for Fedora 33 now.

Lumír


Lokesh can you explain what is going on?


The CI system had an outage:

https://lists.centos.org/pipermail/ci-users/2020-October/002124.html

So the tests never run and since the package is gated, it failed.

I suppose the CI test needs to be restarted, however, I don't know how.

I'd open a ticket at https://pagure.io/fedora-ci/general/issues


However, bodhi does to let me to resubmit the update:

Cannot submit skopeo ('1', '1.2.0', '2.fc33') to testing since it is older than 
('1', '1.2.0', '3.fc33')


And indeed, skopeo-1.2.0-3.fc33 seem to be in:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-7b6058fec9


--
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: F33 podman: unpacking of archive failed cpio: cap_set_file

[Miro Hrončok]

On 05. 10. 20 14:08, Daniel Walsh wrote:


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc


Hi.

The update is unpushed and there is no active update for Fedora 33 now.

Lumír


Lokesh can you explain what is going on?


The CI system had an outage:

https://lists.centos.org/pipermail/ci-users/2020-October/002124.html

So the tests never run and since the package is gated, it failed.

I suppose the CI test needs to be restarted, however, I don't know how.

I'd open a ticket at https://pagure.io/fedora-ci/general/issues

--
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: Follow-up - Please BuildRequire python3-setuptools explicitly

[Parag Nemade]

Hi,

I think fontforge is a false positive. It's just one line which imports
setuptools and that is from third party sources in the pycontrib directory.
That file (or directory) is not installed by the fontforge package.

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

Re: F33 podman: unpacking of archive failed cpio: cap_set_file

[Daniel Walsh]

On 10/5/20 02:13, Lumír Balhar wrote:

On 10/2/20 9:52 PM, Daniel Walsh wrote:

On 10/2/20 06:09, Lumír Balhar wrote:

Hello.

I have fully upgraded Fedora 33 on my laptop and when I try to use 
podman and install httpd package into container, I get the following 
error message:


Error unpacking rpm package httpd-2.4.46-1.fc32.x86_64
error: unpacking of archive failed on file 
/usr/sbin/suexec;5f76fa6a: cpio: cap_set_file

error: httpd-2.4.46-1.fc32.x86_64: install failed

The same thing happens for various different containers like 
fedora:33, fedora:32, centos:7 etc so I guess the problem is 
somewhere on the host and not in the containers.


It seems that the problem is not new and it was previously fixed in 
kernel where a patch added v3 namespaced file capabilities: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340


Does anybody know why the latest kernel should not support it? 
Should I report a bug for the kernel?


Have a nice day.

Lumír
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


I have an update for skopeo (containers-common) that should fix this 
problem.


Please try this out and set the karma if it fixes the problem.

https://bodhi.fedoraproject.org/updates/FEDORA-2020-15e7ef1dcc


Hi.

The update is unpushed and there is no active update for Fedora 33 now.

Lumír


Lokesh can you explain what is going on?


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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


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

Re: Follow-up - Please BuildRequire python3-setuptools explicitly

[Richard Shaw]

I updated fail2ban and gmsh and committed to master. I assume that is
sufficient?

Thanks,
Richard
___
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

[Antonio T. sagitter]

I'm adopting `pstoedit`

On 05/10/20 12:19, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for
> sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 


-- 
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.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: Donate 1 minute of your time to test upgrades from F32 to F33

[Tom Yates]

Error:
 Problem: package mbrowse-0.4.3-20.fc31.x86_64 requires 
libnetsnmp.so.35()(64bit), but none of the providers can be installed
  - net-snmp-libs-1:5.8-25.fc32.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package mbrowse-0.4.3-20.fc31.x86_64


--

  Tom Yates  -  https://www.teaparty.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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-10-05.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

fedora-icon-theme orphan   4 weeks ago
freight   orphan   4 weeks ago
golang-github-mholt-  orphan   5 weeks ago
certmagic-0.9
hub   orphan, ralph, sgallagh  0 weeks ago
jboss-interceptors-1.2-apiorphan   3 weeks ago
jvnet-parent  mizdebsk, orphan 6 weeks ago
lockdev   orphan   0 weeks ago
log4j12   mizdebsk, orphan 3 weeks ago
marble-widget orphan, rdieter  5 weeks ago
mockito   jerboaa, omajid, orphan, 0 weeks ago
  raphgro
nodejs-babel-code-frame   orphan   4 weeks ago
nodejs-base   orphan   4 weeks ago
nodejs-bcrypt nodejs-sig, orphan   4 weeks ago
nodejs-body-parserorphan   4 weeks ago
nodejs-bufferutil nodejs-sig, orphan   4 weeks ago
nodejs-cache-base orphan   4 weeks ago
nodejs-call-matcher   orphan   4 weeks ago
nodejs-cross-spawnnodejs-sig, orphan   4 weeks ago
nodejs-cross-spawn-async  nodejs-sig, orphan   4 weeks ago
nodejs-doctrine   galileo, nodejs-sig, orphan, 4 weeks ago
  vjancik
nodejs-esrecurse  nodejs-sig, orphan   4 weeks ago
nodejs-faucet orphan   4 weeks ago
nodejs-fs-dot-notify  orphan   4 weeks ago
nodejs-gauge  nodejs-sig, orphan   4 weeks ago
nodejs-global-prefix  nodejs-sig, orphan   4 weeks ago
nodejs-grunt-legacy-util  nodejs-sig, orphan, patches, 4 weeks ago
  piotrp
nodejs-http-signature nodejs-sig, orphan, patches  3 weeks ago
nodejs-jsonm  nodejs-sig, orphan   4 weeks ago
nodejs-jsonstream nodejs-sig, orphan   4 weeks ago
nodejs-markdown-it-testgennodejs-sig, orphan   4 weeks ago
nodejs-node-staticnodejs-sig, orphan, tdawson  3 weeks ago
nodejs-nopt   nodejs-sig, orphan, patches  3 weeks ago
nodejs-option-cache   orphan   4 weeks ago
nodejs-raw-body   nodejs-sig, orphan, patches  4 weeks ago
nodejs-rechoirnodejs-sig, orphan   4 weeks ago
nodejs-require-yaml   nodejs-sig, orphan   4 weeks ago
nodejs-rfile  orphan   4 weeks ago
nodejs-rollup-plugin-commonjs orphan   4 weeks ago
nodejs-rollup-plugin-node-orphan   4 weeks ago
resolve
nodejs-socket-dot-io-parser   orphan   4 weeks ago
nodejs-tap-mocha-reporter nodejs-sig, orphan   4 weeks ago
nodejs-tap-parser nodejs-sig, orphan   4 weeks ago
pipsi orphan, python-sig   1 weeks ago
plexus-ant-factorymizdebsk, orphan 5 weeks ago
plexus-component-factories-pommizdebsk, orphan 5 weeks ago
powermock dchen, jerboaa, lef, neugens,0 weeks ago
  orphan
pstoedit  

Re: how to list contents of a side tag?

[Miro Hrončok]

On 05. 10. 20 11:59, Zbigniew Jędrzejewski-Szmek wrote:

I'd like to introspect a side tag:
'koji list-pkgs --tag f34-build-side-31299' lists many many packages.
'koji list-pkgs --noinherit --tag f34-build-side-31299' lists nothing.
Is there some command which would list packages that are in the side tag?


Partial answer:

This will give you list of latest builds tagged into the side tag:

$ koji list-tagged --latest f34-build-side-31299

From that you can get package names via usual shell piping.

$ koji list-tagged f34-build-side-31299 | cut -f1 -d" " | pkgname

Similarly, this is the web UI for the same:

https://koji.fedoraproject.org/koji/builds?latest=1&tagID=31299&order=-completion_time&inherited=0

(Errors now, no idea why.)

However, I don't know how to list all builds (failed or not, finished or not).

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

how to list contents of a side tag?

[Zbigniew Jędrzejewski-Szmek]

I'd like to introspect a side tag:
'koji list-pkgs --tag f34-build-side-31299' lists many many packages.
'koji list-pkgs --noinherit --tag f34-build-side-31299' lists nothing.
Is there some command which would list packages that are in the side tag?
Also, is there a nice way to lists builds (failed or not, finished or not)
done against the side tag?

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: Donate 1 minute of your time to test upgrades from F32 to F33

[Miro Hrončok]

On 05. 10. 20 9:30, Petr Pisar wrote:

  Problem 3: package irssi-1.2.2-6.fc33.x86_64 requires 
libperl.so.5.32()(64bit), but none of the providers can be installed
   - cannot install both perl-libs-4:5.32.0-462.fc33.x86_64 and 
perl-libs-4:5.30.3-455.fc31.x86_64
   - problem with installed package irssi-1.2.2-2.fc31.x86_64
   - package perl-Digest-Bcrypt-1.209-9.fc31.noarch requires 
perl(:MODULE_COMPAT_5.30.0), but none of the providers can be installed

perl-Digest-Bcrypt was removed from F33. I added the package into
fedora-obsolete-packages-33-27 package that ensures that perl-Digest-Bcrypt
will be uninstalled.


More such package will be handled right after the freeze:

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

Adding them one by one is tedious (but does not harm anything). I recommend not 
to do it unless absolutely time critical.


--
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: libtbb.so.2 not found

[Dominik 'Rathann' Mierzejewski]

On Sunday, 04 October 2020 at 19:41, Iñaki Ucar wrote:
> On Sun, 4 Oct 2020 at 18:29, Dominik 'Rathann' Mierzejewski
>  wrote:
> >
> > On Sunday, 04 October 2020 at 15:06, Iñaki Ucar wrote:
> > > Hi,
> > >
> > > I'm not sure what's the issue here:
> > >
> > > - tbb provides libtbb.so.2
> >
> > That seems correct.
> >
> > > - opencv-core requires libtbb.so.2
> >
> > Does it? Not on F32:
> > $ sudo dnf repoquery --whatprovides 'libtbb.so.2()(64bit)'
> > Last metadata expiration check: 1:09:38 ago on Sun 04 Oct 2020 17:08:45 
> > CEST.
> > tbb-0:2020.2-1.fc32.x86_64
> 
> $ sudo dnf repoquery --requires opencv-core
> Last metadata expiration check: 0:59:24 ago on dom 04 oct 2020 18:38:18.
> ...
> libtbb.so.2
> libtbb.so.2()(64bit)
> ...

Right. I misread your "requires" as "provides". Sorry for the confusion.

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 10/1/20 5:44 PM, Vitaly Zaitsev via devel wrote:
> On 01.10.2020 16:54, Petr Menšík wrote:
>> But DNS over TLS does not bring you more privacy usually.
> 
> It does. DoT and DoH encrypt all DNS traffic. Your ISP can no longer spy
> on you and sell the collected data to third parties.
> 
No, it doesn't. Unless you operate the remote resolver as well, it moves
ability to see your name lookups from your ISP to DoT or DoH provider.
They can see it instead. It makes you able to choose different receiver,
but it does not 'protect' it from other parties in general.

Now your DoH provider can sell the collected data to third parties.
Living in the EU, I expect GDPR protects me better than DoH in the US.
My ISP needs legal consent to sell such information.

Cheers,
Petr

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

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal:?? systemd-resolved

[Petr Menšík]

On 10/2/20 2:16 PM, Michael Catanzaro wrote:
> On Fri, Oct 2, 2020 at 12:34 am, Marius Schwarz 
> wrote:
>> If you send a DNS REQUEST to a US DNS server from within a company
>> network, and with ipv6 the internal ip is sent out i learned lately, you
>> have sent personal data which is protected under the GDRP. It's not
>> unlikely to use company pcs for private webvisits while having a meal
>> break.
> 
> Hm, thanks for the explanation. I guess the DNS request would indeed be
> the *first* way you lose, because you have to do DNS before you do
> anything else. But you are going to lose immediately after anyway:
> 
> * Immediately after you connect to the network, Fedora connects to
> http://fedoraproject.org/static/hotspot.txt to see if you're behind a
> captive portal
Fedora is contacting fedora server, seems predictable.
> * Next, GNOME Software starts checking for updates in the background.
> You've leaked "personal data" to fedoraproject.org again, and also fwupd.
It checks also to Fedora servers, right?
> * You open Firefox, it downloads Safe Browsing data from Google.
> (Admittedly this one is probably only behind a European CDN, but maybe
> Google is having a bad day, or maybe IP address logs are sent to the
> US.) Oh yeah, it also displays news from Pocket. Probably it does more
> connections to the US that I don't know about.
> * You switch to Financial Mode in Calculator, it downloads exchange rate
> data.
Might ask question to user, whether that is okay. Can you please fill a
RFE bug?
> * Anything crashes. A truncated stack trace gets sent to Fedora.
> 
> I'm sure my list is missing quite a lot. If your interpretation is
> correct, then I suppose German companies should immediately discontinue
> use of Fedora, and also most other computer operating systems

I think you are missing one important detail. When you choose to install
Fedora, you are likely to accept it sends something to its servers.
Anyway, they would usually have your IP somewhere, when you downloaded
system image.

However, forwarding queries to every name you visit online to some
party, which you never agreed to or maybe heard its name, is something
different. It just provides your site history to company never mentioned
even in configuration files. It is only mentioned by resolvectl, which
normal user would never hear about.

It seems this should be easily configurable on installation (kickstart
default or something), but by default should be empty.

Prepared commented out FallbackDNS=8.8.8.8,... would work well.

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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Petr Menšík]

On 4/16/20 5:43 PM, Tomasz Torcz wrote:
> On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote:
>>
>> Really, it may be best to go about this in the same way as Ubuntu, with nss-
>> dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done 
>> on Fedora, especially on servers. In fact, I never knew that NetworkManager 
>> would clobber that until this thread. If this isn't mean to wreck everyone's 
>> systems, backwards compatibility is key.
> 
>  Relying on nss_dns causes bugs like
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
> (systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
> entries).
>  It still gets (angry) comments, years after it was filled.
> 
It is not nss_dns use, which makes angry comments from people. It should
not be pushed into nameservers list when its broken. It should be
possible to use resolved just for mdns and llmnr and leave dns for
proper servers. If it were opt-in and not opt-out, no annoyed comments
would be required.

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

Re: Fwd: Orphaned packages of skisela

[Vít Ondruch]

Dne 03. 10. 20 v 17:41 Andy Mender napsal(a):
> On Fri, 2 Oct 2020 at 11:53, Vít Ondruch  > wrote:
>
> Hi,
>
> I was in contact with Sebastian, who used to work for RH and
> maintained several Fedora packages. However, due to chances in his
> live, he decided to orphan his packages. Since he is not
> subscribed to fedora-devel ML, I'm forwarding his email.
>
>
> Vít
>
>
>
>
>  Přeposlaná zpráva 
> Předmět:  Fwd: Orphaned packages of skisela
> Datum:Fri, 2 Oct 2020 11:48:32 +0200
> Od:   Sebastián Kisela 
> 
> Komu: Vít Ondruch  
>
>
>
>
>
> -- Forwarded message -
> From:  >
> Date: Fri 2. Oct 2020 at 11:32
> Subject: Orphaned packages of skisela
> To: mailto:sebastian.kis...@gmail.com>>
>
>
> Your message to the devel mailing-list was rejected for the following
>
> reasons:
>
>
>
> The message is not from a list member
>
>
>
> The original message as received by Mailman is attached.
>
>
>
>
> -- Forwarded message --
> From: "Sebastián Kisela"  >
> To: devel@lists.fedoraproject.org
> 
> Cc: 
> Bcc: 
> Date: Fri, 2 Oct 2020 11:31:16 +0200
> Subject: Orphaned packages of skisela
> Dear all,
>
> sorry for leaving so much time for that, but I finally orphaned
> the packages I did not manage to maintain.
>
> The list is:
>
> lockdev
> pstoedit
> psutils
> python-ansicolors
> python-yattag
>
>
> If possible, I'd like to pick up python-ansicolors.


It should be as easy as click on "Take" button here:


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


Vít

___
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 package provide qmake?

[Robbi Nespu]

On 5/10/2020 4:00 pm, Tom Hughes wrote:

Nothing provides qtmake.

There is qmake-qt5 though, in qt5-qtbase-devel.

There's also qmake-qt4 in qt-devel but I assume that it's
the qt5 one you want.


Yes you are right, qmake-qt5 is what i looking for. Thank you
___
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 package provide qmake?

[Tom Hughes via devel]

Nothing provides qtmake.

There is qmake-qt5 though, in qt5-qtbase-devel.

There's also qmake-qt4 in qt-devel but I assume that it's
the qt5 one you want.

Tom

On 05/10/2020 08:55, Robbi Nespu wrote:
Hello there, I want to get involve with KDE development. I have follow 
the step from https://community.kde.org/Get_Involved/development but 
unable to proceed to next step to build dolphin



$ kdesrc-build dolphin
Cloning sysadmin-repo-metadata


Unable to find qmake. This program is absolutely essential for building
the modules: knotifications plasma-wayland-protocols kcoreaddons 
extra-cmake-modules kdesignerplugin kinit kparts kdnssd 
plasma-framework kitemviews kservice kauth kdoctools ktextwidgets 
kpackage kbookmarks kio polkit-qt-1 kirigami kross kiconthemes 
kconfigwidgets kcodecs kglobalaccel ktexteditor kunitconversion 
kguiaddons kdeclarative kconfig kfilemetadata kactivities kded 
karchive solid kwindowsystem knewstuff dolphin kjobwidgets 
oxygen-icons5 kidletime kpty kcompletion kwidgetsaddons kxmlgui kcrash 
attica kemoticons threadweaver kwayland.


Please ensure the development packages for
Qt are installed by using your distribution's package manager.

 * Aborting now to save a lot of wasted time.
 * export KDESRC_BUILD_IGNORE_MISSING_PROGRAMS=1 and re-run (perhaps 
with --no-src)
 * to continue anyways. If this check was in error please report a bug 
against

 * kdesrc-build at https://bugs.kde.org/


what package provide qmake?

$ dnf provides qmake
Fedora 34 openh264 (From Cisco) - 
x86_64  
1.0 kB/s | 2.5 kB 00:02 Fedora - Modular Rawhide - Developmental 
packages for the next Fedora 
release 345 kB/s | 3.1 MB 
00:09 Fedora - Rawhide - Developmental packages for the next Fedora 
release 565 kB/s |  74 
MB 02:13 Error: No Matches found


I am using Fedora rawhide

$ cat /etc/fedora-release Fedora release 34 (Rawhide)


The reason I use rawhide is because it can provide me latest qt. I am 
rookie with this development stuff.

___
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



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

Re: What package provide qmake?

[James Lukash]

Try this
dnf provides '*/bin/qmake'

пн, 5 окт. 2020 г. в 12:55, Robbi Nespu :

> Hello there, I want to get involve with KDE development. I have follow
> the step from https://community.kde.org/Get_Involved/development but
> unable to proceed to next step to build dolphin
>
> > $ kdesrc-build dolphin
> > Cloning sysadmin-repo-metadata
> >
> >
> > Unable to find qmake. This program is absolutely essential for building
> > the modules: knotifications plasma-wayland-protocols kcoreaddons
> extra-cmake-modules kdesignerplugin kinit kparts kdnssd plasma-framework
> kitemviews kservice kauth kdoctools ktextwidgets kpackage kbookmarks kio
> polkit-qt-1 kirigami kross kiconthemes kconfigwidgets kcodecs kglobalaccel
> ktexteditor kunitconversion kguiaddons kdeclarative kconfig kfilemetadata
> kactivities kded karchive solid kwindowsystem knewstuff dolphin kjobwidgets
> oxygen-icons5 kidletime kpty kcompletion kwidgetsaddons kxmlgui kcrash
> attica kemoticons threadweaver kwayland.
> >
> > Please ensure the development packages for
> > Qt are installed by using your distribution's package manager.
> >
> >  * Aborting now to save a lot of wasted time.
> >  * export KDESRC_BUILD_IGNORE_MISSING_PROGRAMS=1 and re-run (perhaps
> with --no-src)
> >  * to continue anyways. If this check was in error please report a bug
> against
> >  * kdesrc-build at https://bugs.kde.org/
>
> what package provide qmake?
> > $ dnf provides qmake
> > Fedora 34 openh264 (From Cisco) - x86_64
>   1.0 kB/s | 2.5 kB 00:02
>
> > Fedora - Modular Rawhide - Developmental packages for the next Fedora
> release 345 kB/s | 3.1 MB
>  00:09
> > Fedora - Rawhide - Developmental packages for the next Fedora release
>  565 kB/s |  74 MB 02:13
> > Error: No Matches found
>
> I am using Fedora rawhide
> > $ cat /etc/fedora-release
> > Fedora release 34 (Rawhide)
>
> The reason I use rawhide is because it can provide me latest qt. I am
> rookie with this development stuff.
> ___
> 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: What package provide qmake?

[ycollette . nospam]

Hello,

I think you should look after qmake-qt5 instead of qmake ...

qmake-qt5 is shipped by qt5-qtbase-devel

Best regards,

Yann

- Mail original -
De: "Robbi Nespu" 
À: devel@lists.fedoraproject.org
Envoyé: Lundi 5 Octobre 2020 09:55:01
Objet: What package provide qmake?

Hello there, I want to get involve with KDE development. I have follow 
the step from https://community.kde.org/Get_Involved/development but 
unable to proceed to next step to build dolphin

> $ kdesrc-build dolphin
> Cloning sysadmin-repo-metadata
> 
> 
> Unable to find qmake. This program is absolutely essential for building
> the modules: knotifications plasma-wayland-protocols kcoreaddons 
> extra-cmake-modules kdesignerplugin kinit kparts kdnssd plasma-framework 
> kitemviews kservice kauth kdoctools ktextwidgets kpackage kbookmarks kio 
> polkit-qt-1 kirigami kross kiconthemes kconfigwidgets kcodecs kglobalaccel 
> ktexteditor kunitconversion kguiaddons kdeclarative kconfig kfilemetadata 
> kactivities kded karchive solid kwindowsystem knewstuff dolphin kjobwidgets 
> oxygen-icons5 kidletime kpty kcompletion kwidgetsaddons kxmlgui kcrash attica 
> kemoticons threadweaver kwayland.
> 
> Please ensure the development packages for
> Qt are installed by using your distribution's package manager.
> 
>  * Aborting now to save a lot of wasted time.
>  * export KDESRC_BUILD_IGNORE_MISSING_PROGRAMS=1 and re-run (perhaps with 
> --no-src)
>  * to continue anyways. If this check was in error please report a bug against
>  * kdesrc-build at https://bugs.kde.org/

what package provide qmake?
> $ dnf provides qmake
> Fedora 34 openh264 (From Cisco) - x86_64  
> 1.0 kB/s | 2.5 kB 00:02
> Fedora - Modular Rawhide - Developmental packages for the next Fedora release 
> 345 kB/s | 3.1 MB 00:09
> Fedora - Rawhide - Developmental packages for the next Fedora release 
> 565 kB/s |  74 MB 02:13
> Error: No Matches found

I am using Fedora rawhide
> $ cat /etc/fedora-release 
> Fedora release 34 (Rawhide)

The reason I use rawhide is because it can provide me latest qt. I am 
rookie with this development stuff.
___
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

What package provide qmake?

[Robbi Nespu]

Hello there, I want to get involve with KDE development. I have follow 
the step from https://community.kde.org/Get_Involved/development but 
unable to proceed to next step to build dolphin



$ kdesrc-build dolphin
Cloning sysadmin-repo-metadata


Unable to find qmake. This program is absolutely essential for building
the modules: knotifications plasma-wayland-protocols kcoreaddons 
extra-cmake-modules kdesignerplugin kinit kparts kdnssd plasma-framework 
kitemviews kservice kauth kdoctools ktextwidgets kpackage kbookmarks kio 
polkit-qt-1 kirigami kross kiconthemes kconfigwidgets kcodecs kglobalaccel 
ktexteditor kunitconversion kguiaddons kdeclarative kconfig kfilemetadata 
kactivities kded karchive solid kwindowsystem knewstuff dolphin kjobwidgets 
oxygen-icons5 kidletime kpty kcompletion kwidgetsaddons kxmlgui kcrash attica 
kemoticons threadweaver kwayland.

Please ensure the development packages for
Qt are installed by using your distribution's package manager.

 * Aborting now to save a lot of wasted time.
 * export KDESRC_BUILD_IGNORE_MISSING_PROGRAMS=1 and re-run (perhaps with 
--no-src)
 * to continue anyways. If this check was in error please report a bug against
 * kdesrc-build at https://bugs.kde.org/


what package provide qmake?

$ dnf provides qmake
Fedora 34 openh264 (From Cisco) - x86_64  1.0 kB/s | 2.5 kB 00:02
Fedora - Modular Rawhide - Developmental packages for the next Fedora release 345 kB/s | 3.1 MB 00:09
Fedora - Rawhide - Developmental packages for the next Fedora release 565 kB/s |  74 MB 02:13
Error: No Matches found


I am using Fedora rawhide
$ cat /etc/fedora-release 
Fedora release 34 (Rawhide)


The reason I use rawhide is because it can provide me latest qt. I am 
rookie with this development stuff.

___
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: libtbb.so.2 not found

[Iñaki Ucar]

On Mon, 5 Oct 2020 at 07:59, Pavel Raiskup  wrote:
>
> On Sunday, October 4, 2020 7:44:49 PM CEST Iñaki Ucar wrote:
> > On Sun, 4 Oct 2020 at 18:39, Jerry James  wrote:
> > >
> > > On Sun, Oct 4, 2020 at 7:07 AM Iñaki Ucar  wrote:
> > > > I'm not sure what's the issue here:
> > > >
> > > > - tbb provides libtbb.so.2
> > > > - opencv-core requires libtbb.so.2
> > > >
> > > > but [1] pulls opencv-devel and tbb is not pulled too, so the linker
> > > > throws the following error:
> > > >
> > > > libtbb.so.2: cannot open shared object file: No such file or directory
> > > >
> > > > tbb issue?, opencv issue?, dnf issue?, mock issue?, other?
> > > >
> > > > [1] 
> > > > https://download.copr.fedorainfracloud.org/results/iucar/cran/fedora-rawhide-x86_64/01694086-R-CRAN-image.textlinedetector/builder-live.log.gz
> > >
> > > I did local mock fedora-rawhide-x86_64 builds of R-CRAN-curl,
> > > R-CRAN-Rcpp, R-CRAN-magrittr, R-CRAN-magick, and finally
> > > R-CRAN-image.textlinedetector.  The R-CRAN-image.texlinedetector build
> > > was successful.  I don't know why you are hitting this error in COPR.
> >
> > Interesting. So mock or Copr? Adding @praiskup to CC.
>
> That's because your project provides alternative libtbb soname, which is
> installed instead of tbb:
>
>   $ dnf repoquery "--disablerepo=*" --enablerepo custom 
> --repofrompath=custom,https://copr-be.cloud.fedoraproject.org/results/iucar/cran/fedora-rawhide-x86_64/
>  --whatprovides 'libtbb.so.2()(64bit)' 2>/dev/null
>   R-CRAN-RcppParallel-0:5.0.2-1.fc33.x86_64

You are right, didn't see that. Thanks all for your help.

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

Re: %set_build_flags problem in rpm spec file

[Panu Matilainen]

On 10/3/20 3:06 PM, Neal Gompa wrote:

On Sat, Oct 3, 2020 at 2:45 AM Miro Hrončok  wrote:


On 03. 10. 20 5:04, Ruki Wang wrote:

Hi, every one.

I am making rpm spec and doing tests on copr.

But on opensuse-leap-15.1-*, %set_build_flags still causes some problems.


+ %set_build_flags
/var/tmp/rpm-tmp.9RYL8i: line 32: fg: no job control
error: Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)
  Bad exit status from /var/tmp/rpm-tmp.9RYL8i (%build)


Links:

https://copr.fedorainfracloud.org/coprs/waruqi/xmake/build/1693007/
https://download.copr.fedorainfracloud.org/results/waruqi/xmake/opensuse-leap-15.2-x86_64/01693007-xmake/builder-live.log.gz


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

Does anyone know the reason for this? Thanks!



Yes. The reason is openSUSE and Fedora are different. and they don't have our 
macro.

A quick "make it build" action would be to add ?:

  %?set_build_flags

However, the openSUSE build might not have the proper flags.



It's because %set_build_flags was introduced in RPM 4.15, and openSUSE
Leap 15.x uses RPM 4.14. Moreover, openSUSE Leap 15.1 predates the
introduction of the macro even upstream. It was not backported into
openSUSE Leap 15.2 either, so the macro just doesn't exist in openSUSE
Leap yet.

The macro was backported to RHEL 8 during its development, so it
exists there despite it using RPM 4.14 as well.


Not quite. The macro originated in Fedora in early 2018 and RHEL 
8inherited it from there. Upstream adopted it spring 2019 and was 
consequently included in 4.15.


Please check your facts when making such statements. This may be a 
mostly harmless error but that's not always the case.


- Panu -
___
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: build rpm from spec file fails on fedora-eln-armhfp

[Pavel Raiskup]

On Monday, October 5, 2020 9:23:14 AM CEST Florian Weimer wrote:
> * Ruki Wang:
> 
> > Errors during downloading metadata for repository 'eln':
> >   - Status code: 404 for 
> > https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/Everything/armhfp/os/repodata/repomd.xml
> >  (IP: 67.219.144.68)
> 
> Looks like COPR is still trying to build ELN on armhfp, but it's not
> longer available.
> 
> I believe there is a checkbox in the COPR web UI you can untick, but
> eventually, this has to be adjusted by the COPR administrators.

Thanks for the reminder.  The chroot has just been deactivated in Copr.

Pavel

> Thanks,
> Florian
> -- 
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 



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

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Mon, 05 Oct 2020 09:20:53 +0200, Florian Weimer wrote:
> Fedora Server still defaults to LVM and XFS, as far as I know.  I expect
> that downstream will continue to use XFS as well.
> 
> I don't think you can assume that debugging information will be stored
> on btrfs file systems.

OK. Then DWARF consumers could just decompress zstd themselves. Then we can
argue about tracing tools overhead. Either cache of uncompressed files or even
some little performance hit. Still that would be worth 50% of debuginfo size.
And that would be needed only on non-btrfs filesystems which (maybe) will
disappear in the future.


Jan
___
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: Donate 1 minute of your time to test upgrades from F32 to F33

[Petr Pisar]

On Fri, Oct 02, 2020 at 08:01:16AM -0400, Solomon Peachy wrote:
>  Problem 2: package python2-libxml2-2.9.10-4.fc31.x86_64 requires 
> libxml2(x86-64) = 2.9.10-4.fc31, but none of the providers can be installed
>   - libxml2-2.9.10-4.fc31.x86_64 does not belong to a distupgrade repository
>   - problem with installed package python2-libxml2-2.9.10-4.fc31.x86_64
python2-libxml2 was updated to python2-libxml2-2.9.10-4 in F31. I updated the
release number in fedora-obsolete-packages-33-27 package that ensures that
python2-libxml2 will be uninstalled.

>  Problem 3: package irssi-1.2.2-6.fc33.x86_64 requires 
> libperl.so.5.32()(64bit), but none of the providers can be installed
>   - cannot install both perl-libs-4:5.32.0-462.fc33.x86_64 and 
> perl-libs-4:5.30.3-455.fc31.x86_64
>   - problem with installed package irssi-1.2.2-2.fc31.x86_64
>   - package perl-Digest-Bcrypt-1.209-9.fc31.noarch requires 
> perl(:MODULE_COMPAT_5.30.0), but none of the providers can be installed

perl-Digest-Bcrypt was removed from F33. I added the package into
fedora-obsolete-packages-33-27 package that ensures that perl-Digest-Bcrypt
will be uninstalled.

Thanks for the report.

-- 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: build rpm from spec file fails on fedora-eln-armhfp

[Florian Weimer]

* Ruki Wang:

> Errors during downloading metadata for repository 'eln':
>   - Status code: 404 for 
> https://odcs.fedoraproject.org/composes/production/latest-Fedora-ELN/compose/Everything/armhfp/os/repodata/repomd.xml
>  (IP: 67.219.144.68)

Looks like COPR is still trying to build ELN on armhfp, but it's not
longer available.

I believe there is a checkbox in the COPR web UI you can untick, but
eventually, this has to be adjusted by the COPR administrators.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Florian Weimer]

* Jan Kratochvil:

> On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
>> Why do you think that?  Using debuginfo for perf and the like seems to
>> be much more common than actual debugging, based on what I see
>> downstream.
>
> OK, interesting, thanks for the info. Still that does not change anything with
> btrfs zstd. btrfs zstd would save on-disk size ~50% (I did not measure zstd
> for Fedora distro, zlib saves on Fedora distro 52%) compared to DWZ's on-disk
> size saving of 20% (or just 10% if one makes some non-DWZ optimizations in
> addition to -fdebug-types-section).

Fedora Server still defaults to LVM and XFS, as far as I know.  I expect
that downstream will continue to use XFS as well.

I don't think you can assume that debugging information will be stored
on btrfs file systems.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Debug Info Standardization (from DWZ to -fdebug-types-section) (System-Wide Change proposal)

[Jan Kratochvil]

On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
> Why do you think that?  Using debuginfo for perf and the like seems to
> be much more common than actual debugging, based on what I see
> downstream.

OK, interesting, thanks for the info. Still that does not change anything with
btrfs zstd. btrfs zstd would save on-disk size ~50% (I did not measure zstd
for Fedora distro, zlib saves on Fedora distro 52%) compared to DWZ's on-disk
size saving of 20% (or just 10% if one makes some non-DWZ optimizations in
addition to -fdebug-types-section).


> > The problem is that you have to wait for minutes for GDB to print anything.
> 
> Is this about slow tab completion?

No. GDB always converts DWARF->IR (=expands) for whole CUs (Compilation Units).
Moreover for some constructs GDB requires complete type definition which makes
CUs dependent on other CUs. So in practice accessing one variable will expand
around 50 CUs. And each CU is nowadays huge for real C++ templatized programs.

In other cases (such as in lambda functions) GDB even expands completely all
CUs. That is probably some GDB bug. But it makes GDB to eat 20+ GB of memory
and several minutes of runtime on fast machines to print a variable.

Compared to that LLDB expands only one DIE and it is done. But LLDB needs to
know where the DIE is. This is why LLDB needs .debug_names index and not
.gdb_index which does not contain DIE offsets. And this is why .gdb_index is
easy to update for DWZed DWARF but for .debug_names there is currently even no
DWARF specification how to make it compatible with DWZ. DWZ .debug_names index
has to express two CUs for each DIE:
(1) DW_TAG_partial_unit where the DIE is located in the DWARF file
(and whether it is in DWZ common file or not)
(2) DW_TAG_compile_unit which did DW_TAG_imported_unit that
DW_TAG_partial_unit)
LLDB DWZ support had to extend its in-memory index this way but it does waste
LLDB memory+runtime on all OSes not using DWZ (=most of the LLDB use - for
Android/iOS/OSX).


> > It is faster to add cout<<, recompile and rerun the program (with clang+lld 
> > as
> > with g++ it takes more than 3x as much time) than to wait for GDB. LLDB 
> > would
> > sure print it immediately but it is incompatible with Fedora DWARF. Enjoy.
> 
> I can't use LLDB because it does not support thread-local variables.

I have this item in my LLDB TODO list (and I even fixed the TLS support in GDB
in the past). But without DWARF (DWZ) support it makes no sense to support TLS.
So I rather returned to working on the DWZ support saving 1.8% of distribution
size wasting 2 years on it and probably going to continue wasting more
forthcoming years on those 1.8% of distribution size.


> Not even initial-exec variables, which could be implemented without
> peeking at glibc internals.

Yes, a lot of useful things could be working if we did not have to waste time
on useless stuff.


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