date:20210505

Re: PWG virtual meetup 2021

2021-05-05 Thread Zdenek Dohnal

On 5/5/21 8:31 PM, Matthew Miller wrote:
> On Wed, May 05, 2021 at 08:27:08PM +0200, Zdenek Dohnal wrote:
>> I attended PWG virtual meetup 2021 yesterday and today and created
>> reported about it.
> Thanks! Printers are objectively every sysadmin's least favorite (even beating
> out DNS), so I really appreciate you and everyone working on making it
> better!

You're welcome! IMO the situation is a lot better since 2015 when both
(network printers got the driverless support sooner - in 2010) network
and usb printers got driverless standards implemented into actual devices.

Driverless support for network printers comes with cups and cups-filters
projects by default, so it is in Fedora since upstream introduced it.
Regarding USB printers, I packaged ipp-usb project into Fedora last
year, so printers supporting IPP-over-USB work without driver too.

Additionally, if your scanner/multi function device (MFD) supports IPP
over USB, you have it connected via USB and your device supports eSCL or
WSD protocols for scanning, you can even scan driverlessly with
sane-airscan. Network scanners/MFD in the same LAN work out-of-the-box
once you put your device into your LAN and let Avahi to do its job (all
LAN printing/scanning heavily depends on mDNS).

And once your PC supports driverless printing/scanning, your device has
driverless support (AirPrint/IPP Everywhere/Mopria for printing,
eSCL/WSD for scanning + IPP over USB if you connect via USB) and once
you configure your PC (allow ipp and mdns in firewall, have avahi-daemon
running) and device (enabled IPP, eSCL or WSD) you don't need to install
a device at all. Your printer will 'appear' just at the time you print
(in print dialog) and goes away after successful printing (so it does
not block any of memory resources).

Printing/scanning to devices outside of LAN requires more steps -
usually you need to setup cups-browsed to browsepoll your print server
(which currently has the most issues and I'm working on it to make it
better) or install a permanent printer via a printer tool.

So IMO it got better since times when there were a difficult questions
like 'Is printer supported in Linux?' and 'How to install it in Linux?'
- since any new device in shop is okay and installing works
out-of-the-box for desktops.

More terminology and tricks here [1] and here [2].

[1]
https://fedoraproject.org/wiki/How_to_debug_printing_problems#Terminology_for_printing_and_scanning

[2]
https://fedoraproject.org/wiki/How_to_debug_printing_problems#Useful_tricks

P.S. I know the page should be rewritten into docs.fedoraproject (I and
Matt even talked together about it once), I have never got a time to do
that. So if someone is willing to rewrite it in docs.fedoraproject, give
me access to edit it and merge the changes, that person is very welcomed :)

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

OpenPGP_signature
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Storing package metadata in ELF objects

2021-05-05 Thread Mark Wielaard

Hi Luca,

On Tue, 2021-05-04 at 14:43 +0100, Luca Boccassi wrote:
> On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> > Is there a list of default keys (and their canonical spelling, upper-
> > lower-Camel_Case, etc.)? If there is, could we have a "debuginfod" key
> > with as value an URL pointing to the debuginfod server URL where the
> > embedded build-id executable, debuginfo and sources can be found?
> > https://sourceware.org/elfutils/Debuginfod.html
> 
> The "Implementation" section of the spec lists the "main" fields:
> 
> https://systemd.io/COREDUMP_PACKAGE_METADATA/
> 
> (source for that is 
> https://github.com/systemd/systemd/blob/main/docs/COREDUMP_PACKAGE_METADATA.md
>  )
> 
> Would you like to send a PR to update it and add that field?

Sorry, I don't have a github account. But attached is a patch for to
document it and one for the package-notes generator to add an --
debuginfod argument (maybe the distro should set a default value for
that?) Hopefully those patches could be applied somehow.

Thanks,

Mark
From 176dde09fcfeff9bff97fbf65d47a641dbd2fa3a Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Thu, 6 May 2021 03:05:02 +0200
Subject: [PATCH] docs/COREDUMP_PACKAGE_METADATA.md: Add debuginfod key

Signed-off-by: Mark Wielaard 
---
 docs/COREDUMP_PACKAGE_METADATA.md | 5 +
 1 file changed, 5 insertions(+)

diff --git a/docs/COREDUMP_PACKAGE_METADATA.md b/docs/COREDUMP_PACKAGE_METADATA.md
index ab7c4596de..b7be9ca797 100644
--- a/docs/COREDUMP_PACKAGE_METADATA.md
+++ b/docs/COREDUMP_PACKAGE_METADATA.md
@@ -26,6 +26,10 @@ Thus it becomes desirable to add additional metadata to a binary at build time,
 `systemd-coredump` and other services analyzing core files are able to extract said
 metadata simply from the core file itself, without external dependencies.
 
+And in case external dependencies and network are available the core file
+should also include the debuginfod server URL that can provide the original
+executable, debuginfo and sources to facilitate debugging.
+
 ## Implementation
 
 This document will attempt to define a common metadata format specification, so that
@@ -58,6 +62,7 @@ Value: a JSON string with the structure described below
  "name":"coreutils",
  "version": "4711.0815.fc13.arm32",
  "osCpe":   # A CPE name for the operating system, `CPE_NAME` from os-release is a good default
+ "debuginfod": "https://debuginfod.fedoraproject.org;
 }
 ```
 
-- 
2.18.4

From 6264605699cbac02ed3060cc1ff6497b32e90382 Mon Sep 17 00:00:00 2001
From: Mark Wielaard 
Date: Thu, 6 May 2021 03:13:57 +0200
Subject: [PATCH] generate-package-notes.py: Add --debuginfod argument

Signed-off-by: Mark Wielaard 
---
 generate-package-notes.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/generate-package-notes.py b/generate-package-notes.py
index c0b5d98..92126f7 100755
--- a/generate-package-notes.py
+++ b/generate-package-notes.py
@@ -71,6 +71,7 @@ def parse_args():
 p.add_argument('--package-version')
 p.add_argument('--cpe')
 p.add_argument('--rpm', metavar='NEVRA')
+p.add_argument('--debuginfod')
 
 opts = p.parse_args()
 
@@ -143,6 +144,8 @@ def generate_section(opts):
 else:
 data['os'] = read_os_release('ID')
 data['osVersion'] = read_os_release('VERSION_ID')
+if opts.debuginfod:
+data['debuginfod'] = opts.debuginfod
 
 json = json_serialize(data)
 
-- 
2.18.4

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo election nominations are now open

2021-05-05 Thread Ben Cotton

Reminder that through 12 May, you may nominate candidates for the open
seat on the Fedora Engineering Steering Committee.

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.

For more information, including the election information for the
Fedora Council and the Mindshare Committee, see the Community Blog
post:
https://communityblog.fedoraproject.org/f34-elections-nominations-now-open/




-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo election nominations are now open

2021-05-05 Thread Ben Cotton

Reminder that through 12 May, you may nominate candidates for the open
seat on the Fedora Engineering Steering Committee.

To nominate yourself (or others, if you check with them first), visit:
https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

FESCo is currently selecting the questions for the interview
questionnaire, which will be finalized before the beginning of the
interview period.

For more information, including the election information for the
Fedora Council and the Mindshare Committee, see the Community Blog
post:
https://communityblog.fedoraproject.org/f34-elections-nominations-now-open/




-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Wayland and basic graphics mode

2021-05-05 Thread Samuel Sieb


On 5/5/21 9:42 AM, Neal Gompa wrote:

Do we want to support a "basic graphics mode"? If so (which I think we
do), are there any alternatives to disabling KMS entirely that we
could use? Perhaps vkms[2] is an option? If not, what do we do about
it?

[2]: https://dri.freedesktop.org/docs/drm/gpu/vkms.html


I don't see how this would be useful.  It's a *virtual* display.  It 
doesn't connect to any physical hardware, so the display manager would 
run, but no one could see it. :-)

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PETSc 3.15

2021-05-05 Thread Kevin Fenzi

On Wed, May 05, 2021 at 11:50:05AM +0200, Antonio T. sagitter wrote:
> This side-tag is obsolete because of recent rebuild of PETSc-3.15 rebuild #2
> for cgnslib:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1741817
> 
> I'm removing the side-tag f35-build-side-40112
> Must i untag the related builds in this case? (bout++-4.3.2-8.fc35 and
> python-steps-3.5.0-8.fc35)

You can, but I don't think they would get tagged in f35 without you
submitting a bodhi update from the sidetag. 

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PWG virtual meetup 2021

2021-05-05 Thread Neal Gompa

On Wed, May 5, 2021 at 2:27 PM Zdenek Dohnal  wrote:
>
> Hi all,
>
> I attended PWG virtual meetup 2021 yesterday and today and created
> reported about it.
>
> Highlights:
>
> - CUPS got into OpenPrinting group from Apple
>

I'm confused, what does this mean? I saw a while back that
OpenPrinting had a fork of it. I see now that the fork relationship is
broken, but it seems like both Apple and OpenPrinting have trees.
What's going on now?



-- 
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PWG virtual meetup 2021

2021-05-05 Thread Matthew Miller

On Wed, May 05, 2021 at 08:27:08PM +0200, Zdenek Dohnal wrote:
> I attended PWG virtual meetup 2021 yesterday and today and created
> reported about it.

Thanks! Printers are objectively every sysadmin's least favorite (even beating
out DNS), so I really appreciate you and everyone working on making it
better!

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

PWG virtual meetup 2021

2021-05-05 Thread Zdenek Dohnal

Hi all,

I attended PWG virtual meetup 2021 yesterday and today and created
reported about it.

Highlights:

- CUPS got into OpenPrinting group from Apple

- still working on upgrade path for non-driverless printers after
removing printer drivers and raw queues:

 1) printer application library was created - PAPPL (already in Fedora)

 2) the first printer application library created by Till Kamppeter -
ps-printer-app - which supports postscript printers in the wild

- ippusbxd is dead for ipp-over-usb standard - standard for driverless
printing via usb [1] - we use ipp-usb (already in Fedora, how to find
out my device is supported [2])


[1]
https://fedoraproject.org/wiki/How_to_debug_printing_problems#Driverless_printing_.28USB.29

[2]
https://fedoraproject.org/wiki/How_to_debug_printing_problems#How_to_find_out_if_my_USB_device_supports_IPP_over_USB

==

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C

PWG 2021


PWG Plenary
---
- 692 printers IPP Everywhere certified! https://www.pwg.org/printers/
- standards - IPP Everywhere 2.0 on the way, IPP Enterprise Printing Extensions 
2.0, IPP Production Printing Extensions 2.0,
  IPP driverless printing extensions 2.0 etc.
- IDS (Image Device Security) - now focus on hard copy devices protection 
profiles, hard copy devices security guidelines and standards
- IPP - maintenance of the protocol and SNMP MIBs - recently published Job 
Accounting with IPP v1.0, in working IPP 2.0 (fourth edition),
  IPP driverless printing extensions 2.0, IPP encrypted jobs and documents 1.0, 
IPP enterprise printing extensions 2.0, IPP finishings 3.0,
  IPP production printing extensions 2.0
  - pending IANA registrations https://www.pwg.org/ipp/ipp-registrations.xml
- 3D printing - reaching 3D printer manufacturers about IPP to convince them to 
use IPP instead of drivers

OpenPrinting Plenary

- linux markets - windows lost to linux in public server market share, web 
server market share
- linux distro popularity on distrowatch - 5th Fedora, 7th CentOS
- cups-filters - highlights - clustering, dns-sd enhancing, filters
- cups in SNAP - no drivers, working out of the box
- participated in GSOC, GSOD abd LFMP (Linux Foundation Mentorship Program)
- took over CUPS, released 2.3.3op1 and 2.3.3op2, working on 2.4.x
- pappl - recent v1.0.3, written by Mike Sweet, library for printer applications
- ps-printer-app - the first printerapp for postscript printers, written by 
Till Kamppeter
- driverless - IPP Faxout support implemented in cups-filters
- ipp over usb - ippusbxd removed, now we use ipp-usb written in Golang
- scanning - Mopria released eSCL specification publicly, IPP scan service 
isn't supported by devices, so we go with eSCL and
  WSD
- GSoC 2021 - halfed hours for projects, now only 5 students for us
- GSoD 2021 - more complicated than before (legal stuff, payments to tech 
writer)... - cups-filters docs wasn't accepted
- LFMP 2021 - currently considering projects which will go into LFMP - only 
technical projects (no bug fixing, maintenance, web creation, docs)

GSOC, GSOD, LFMP updates

- 2020 - CPDB and IPP scan projects weren't completed, but other students works 
on bugs in printer applications and cups-filters
- LFMP 2020 - 4 students, none of them finished because LFMP started when 
universities in India started to have classes, so students were busy
- GSoC 2021 - topics - create a single universal filter
 - firmware and other file handling in PAPPL
 - GUI for listing and managing available IPP Print/Scan 
services - modern IPP printers will be as IPP services, and printer
   applications will be drivers
 - converting filters to functions instead of executables
 - all filters must work without PPD files
- coding period is reduced to half :(

CUPS Plenary

- future 2.4 - working on oauth 2.0 instead of kerberos, added compatibility 
with airprint and mopria (already done),
added pkg-config support, kerberos and cups-config deprecated, snapcraft 
support mostly done, working on job-sheets-col
and media-col (like using different output trays without postscript 
commands), working on TLS and X.509 (bringing OpenSSL
back as an option, better X509 for servers - sharing certificates between 
devices instead of locally generated self-signed
certs)
- oauth - don't need root, Mike uses its own version - moauth, bearer and 
refresh tokens cached per-user/auth-server, asking for
  OAUTH server already implemented in IPP protocol
- deprecations:
 - already removed in past:
  - due security issues - moving directives to cups-files.conf, interface script
  - performance and design issues - CUPS browsing (removed mainly because of 
wifi)
 - deprecated, will go away in the future:
  - printer drivers - now

Re: RPM name collisions

2021-05-05 Thread Neal Gompa

On Wed, May 5, 2021 at 11:55 AM Qiyu Yan  wrote:
>
> 在 2021-05-05星期三的 07:44 +0200，Dan Čermák写道：
> > przemek klosowski via devel  writes:
> >
> > > Is that something we need to worry about? I couldn't think of any new
> > > rules to impose on repositories, but maybe dnf should have more
> > > explicit
> > > warnings when it sees multiple versions of the same package, or at
> > > least
> > > a way to show such versions.
> >
> > Or how about teaching dnf that only certain repositories are allowed to
> > be used for updates (with an allowedlist for exceptions)? Then
> > microsoft
> > or any other third party repo could put hello-5000-1 into their repo
> > and
> > it could never compromise your system, as dnf would not consider the
> > 3rd
> > party repo a valid update repo for a base system package.
> >
> > That would require dnf to track where it got the package from though
> > and I am not sure if it does that at the moment?
> This reminds me of an idea named Vendor Change from Zypper of openSUSE
> https://en.opensuse.org/SDB:Vendor_change_update
> This approach seems to solve our problems here?

Well, we do have the sticky vendor feature in DNF, DNF on openSUSE has
it switched on by default[1]. If we want to have this feature turned
on in Fedora, we could look at having it switched on.

[1]: 
https://build.opensuse.org/package/view_file/openSUSE:Factory/libdnf/libdnf-0.55.0-Switch-allow_vendor_change-off.patch?expand=1




--
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Wayland and basic graphics mode

2021-05-05 Thread Neal Gompa

Hey all,

During the final days of Fedora Linux 34 development, it was
discovered that Plasma Wayland hangs when kernel modesetting isn't
available[1]. It was resolved for F34 with a downstream change to sddm
that checks if "nomodeset" is set and disables Wayland sessions
accordingly.

However, this is not a sustainable solution. Technically, Plasma
Wayland supports fbdev, but it is not very good relative to the
standard drm backend (and requires extra configuration to work).
Additionally, GNOME Wayland *only* supports the drm backend and it
fails entirely when "nomodeset" is set, thus GDM forces back to X11 in
this scenario. As we move forward with adopting Wayland across the
board, variations of this problem will happen over and over again.

So my questions are:

Do we want to support a "basic graphics mode"? If so (which I think we
do), are there any alternatives to disabling KMS entirely that we
could use? Perhaps vkms[2] is an option? If not, what do we do about
it?


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1952431
[2]: https://dri.freedesktop.org/docs/drm/gpu/vkms.html

-- 
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

2021-05-05 Thread Qiyu Yan

在 2021-05-05星期三的 07:44 +0200，Dan Čermák写道：
> przemek klosowski via devel  writes:
> 
> > Is that something we need to worry about? I couldn't think of any new
> > rules to impose on repositories, but maybe dnf should have more
> > explicit 
> > warnings when it sees multiple versions of the same package, or at
> > least 
> > a way to show such versions.
> 
> Or how about teaching dnf that only certain repositories are allowed to
> be used for updates (with an allowedlist for exceptions)? Then
> microsoft
> or any other third party repo could put hello-5000-1 into their repo
> and
> it could never compromise your system, as dnf would not consider the
> 3rd
> party repo a valid update repo for a base system package.
> 
> That would require dnf to track where it got the package from though
> and I am not sure if it does that at the moment?
This reminds me of an idea named Vendor Change from Zypper of openSUSE
https://en.opensuse.org/SDB:Vendor_change_update
This approach seems to solve our problems here? 
> 
> 
> Cheers,
> 
> Dan
> ___
> 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
> Do not reply to spam on the list, report it: https://pagure.io/fedora-
> infrastructure

-- 
Qiyu Yan
GPG keyid: 0x4FC914F065F2DF12
About: https://fedoraproject.org/wiki/User:Yanqiyu






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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: how to ignore fedora's rawhide repo in the kickstarts file?

2021-05-05 Thread przemek klosowski via devel

so fedora-live-base.ks includes fedora-repo.ks which by default has 
fedora-repo-rawhide.ks uncommented (and fedora-repo-not-rawhide.ks 
commented out). I think the only way would be to edit that file. Of 
course you can edit it programmatically, or via some sort of symlink 
swapping


ln -sf /usr/share/spin-kickstarts/fedora-repo{,-not-rawhide}.ks

What are your goals and/or requirements here---not having to modify the 
RPM-owned directory?


On 5/4/21 6:15 PM, Globe Trotter via devel wrote:

Ny kickstart file has the following:

%include /usr/share/spin-kickstarts/fedora-live-base.ks
%include /usr/share/spin-kickstarts/fedora-live-minimization.ks

But I have noticed that it wants to go into the rawhide repo. That is because 
/usr/share/spin-kickstarts/fedora-live-base.ks has fedora-repo-rawhide.ks as 
the repo by default. Now, I know that I can comment it out but I dont want to 
do this everytime. Is it possible to require the repo to be set at 
fedora-repo-not-rawhide.ks by default without modifying the system file?

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.1.5 in Rawhide

2021-05-05 Thread Steven A. Falco


On 5/5/21 11:33 AM, Scott Talbert wrote:

On Wed, 5 May 2021, Steven A. Falco wrote:


Hi,

I'm updating wxWidgets (wxGTK package) to v3.1.5 in Rawhide.  This includes a 
soname bump.  I'm doing the build in a side tag: f35-build-side-40779.

As far as I can tell, the only users are CubicSDR and audacity.  I'll rebuild 
CubicSDR.  Gwyn or Ian, can you please take care of rebuilding audacity in the 
side tag?


KiCAD uses wxGTK, so I think it would require a new build as well.

I haven't done a build in a side tag before.  I think the command would be:

fedpkg build --target=f35-build-side-40779

Is that correct?  Would you like me to kick off a KiCAD build?


Looks like KiCAD uses wxGTK3 [1] (wxWidgets 3.0), so not affected by this 
change.

[1] https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec#_38


Thanks for the clarification, Scott.

Steve
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.1.5 in Rawhide

2021-05-05 Thread Scott Talbert


On Wed, 5 May 2021, Steven A. Falco wrote:


Hi,

I'm updating wxWidgets (wxGTK package) to v3.1.5 in Rawhide.  This includes 
a soname bump.  I'm doing the build in a side tag: f35-build-side-40779.


As far as I can tell, the only users are CubicSDR and audacity.  I'll 
rebuild CubicSDR.  Gwyn or Ian, can you please take care of rebuilding 
audacity in the side tag?


KiCAD uses wxGTK, so I think it would require a new build as well.

I haven't done a build in a side tag before.  I think the command would be:

fedpkg build --target=f35-build-side-40779

Is that correct?  Would you like me to kick off a KiCAD build?


Looks like KiCAD uses wxGTK3 [1] (wxWidgets 3.0), so not affected by this 
change.


[1] https://src.fedoraproject.org/rpms/kicad/blob/rawhide/f/kicad.spec#_38

Thanks,
Scott___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

2021-05-05 Thread Luk Claes

In Debian based systems you can configure if a repository is to be
considered for updates or only when manually installing a package that
either is only included in that repo or where you explicitly state you want
it to be from that repo.

apt can also show all the versions from all the repositories of a package
and which one it sees as the default for update/install.

Cheers

Luk

On Wed, 5 May 2021 at 08:30, Adam Williamson 
wrote:

> On Wed, 2021-05-05 at 07:44 +0200, Dan Čermák wrote:
> > przemek klosowski via devel  writes:
> >
> > > Is that something we need to worry about? I couldn't think of any new
> > > rules to impose on repositories, but maybe dnf should have more
> explicit
> > > warnings when it sees multiple versions of the same package, or at
> least
> > > a way to show such versions.
> >
> > Or how about teaching dnf that only certain repositories are allowed to
> > be used for updates (with an allowedlist for exceptions)? Then microsoft
> > or any other third party repo could put hello-5000-1 into their repo and
> > it could never compromise your system, as dnf would not consider the 3rd
> > party repo a valid update repo for a base system package.
> >
> > That would require dnf to track where it got the package from though
> > and I am not sure if it does that at the moment?
>
> It does, but then you're just opening up a whole can of worms. And, I
> mean, this seems like a very narrow focus. If a third party wants to do
> something nefarious and can convince you to "install a repository" in
> some way, that means that at minimum they convinced you to drop an
> arbitrary file in /etc/yum.repos.d . What they probably did was
> convince you to install a package containing the repo definition, as
> that's the way most third party repos deploy. Well, that package could
> do *absolutely anything else at all* on your system with root
> privileges, because that's how packaging works.
>
> And a nefarious repo doesn't really need to use an RPM name collision
> to do...well...anything much, really. It can just have a perfectly
> correctly-named package contain whatever nefarious payload it wants.
>
> So I guess my question is: is there something specific we are
> preventing by worrying about package name collisions, which any person
> in a position to produce a package name collision could not just
> achieve in a dozen or more other ways?
> --
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Help with LDFLAGS for a golang package

2021-05-05 Thread Jérémy Bertozzi

Hello,

I am trying to build a golang package in COPR, before opening the BZ for
inclusion into fedora.

go2rpm does almost everything, expect setting a LDFLAG needed for the
binary to display the appropriate binary version [1].

When I build locally using mock (with a default config), the binary within
the RPM generated is displaying the appropriate version.

When I install the package from the COPR repository (built using the same
SRPM), the binary is different and prints a version "dev build", like if
the LDFLAG was ignored.

Looking at the build.log [2], we can see the LDFLAG is set during the
gobuild command.

I suspected some cache at the COPR repository level, so I tried to clean
everything and rebuild it. Same result.

At this point I am a bit lost. Anybody to give some hint?

My spec file and my SRPM can be found here. [3]

Thanks in advance for your help.

Jérémy

[1] https://github.com/ivn/smug/blob/v0.2.2/Makefile
[2]
https://download.copr.fedorainfracloud.org/results/jbertozzi/smug/fedora-34-x86_64/02166586-golang-github-ivn-smug/builder-live.log.gz
[3] https://github.com/jbertozzi/copr-build-smug
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

2021-05-05 Thread Matthew Miller

On Wed, May 05, 2021 at 09:47:31AM +0300, Otto Urpelainen wrote:
> Thank you the explanation. If you hand the repository over to me, I
> can see that material from the wiki is migrated there and the
> repository published at docs.fp.o Engineering Teams [1] as "Package
> Maintainers" ( or is it officially "Fedora Package Maintainers"?).
> And that tooling is updated to Antora for sure.

That's awesome, thanks. It's yours!

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-34-20210505.0 compose check report

2021-05-05 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

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

ID: 879287  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/879287

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

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

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

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

Polyml soname bump

2021-05-05 Thread Jerry James

Version 5.8.2 of polyml has been released and includes an soname bump
for libpolyml.so.  Nothing in Fedora depends on that library, so I am
going to proceed with updating in Rawhide.  I may update F34 as well,
depending on how tests in Rawhide go.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2021-05-05 Thread Fedora compose checker

Missing expected images:

Xfce raw-xz armhfp

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

Failed openQA tests: 14/194 (x86_64), 11/133 (aarch64)

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

ID: 878867  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/878867
ID: 878870  Test: x86_64 Server-dvd-iso install_vncconnect_server
URL: https://openqa.fedoraproject.org/tests/878870
ID: 878907  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/878907
ID: 878910  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/878910
ID: 878913  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/878913
ID: 878914  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/878914
ID: 878940  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/878940
ID: 879046  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/879046
ID: 879051  Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/879051
ID: 879166  Test: aarch64 universal support_server@uefi
URL: https://openqa.fedoraproject.org/tests/879166
ID: 879185  Test: aarch64 universal install_iscsi@uefi
URL: https://openqa.fedoraproject.org/tests/879185

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

ID: 878866  Test: x86_64 Server-dvd-iso install_vnc_server
URL: https://openqa.fedoraproject.org/tests/878866
ID: 878887  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/878887
ID: 879026  Test: aarch64 Server-dvd-iso install_vnc_server@uefi
URL: https://openqa.fedoraproject.org/tests/879026
ID: 879031  Test: aarch64 Server-dvd-iso install_vnc_client@uefi
URL: https://openqa.fedoraproject.org/tests/879031
ID: 879099  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/879099
ID: 879116  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/879116
ID: 879135  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/879135
ID: 879139  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/879139
ID: 879142  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/879142
ID: 879169  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/879169
ID: 879170  Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/879170
ID: 879183  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/879183
ID: 879186  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/879186
ID: 879187  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/879187

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

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

ID: 879035  Test: aarch64 Server-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/879035
ID: 879056  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/879056

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

ID: 878978  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/878978
ID: 878979  Test: aarch64 Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/878979
ID: 879066  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/879066

Passed openQA tests: 163/194 (x86_64), 118/133 (aarch64)

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

ID: 878927  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/878927
ID: 878939  Test: x86_64 Workstation-live-iso unwanted_packages
URL: https://openqa.fedoraproject.org/tests/878939
ID: 878943  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/878943
ID: 879010  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/879010

Re: [HEADS UP] wxGTK 3.1.5 in Rawhide

2021-05-05 Thread Steven A. Falco


On 5/5/21 8:16 AM, Scott Talbert wrote:

Hi,

I'm updating wxWidgets (wxGTK package) to v3.1.5 in Rawhide.  This includes a 
soname bump.  I'm doing the build in a side tag: f35-build-side-40779.

As far as I can tell, the only users are CubicSDR and audacity.  I'll rebuild 
CubicSDR.  Gwyn or Ian, can you please take care of rebuilding audacity in the 
side tag?


KiCAD uses wxGTK, so I think it would require a new build as well.

I haven't done a build in a side tag before.  I think the command would be:

fedpkg build --target=f35-build-side-40779

Is that correct?  Would you like me to kick off a KiCAD build?

Steve
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] wxGTK 3.1.5 in Rawhide

2021-05-05 Thread Gwyn Ciesla via devel

On it.


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, May 5, 2021 7:16 AM, Scott Talbert  wrote:

> Hi,
> 

> I'm updating wxWidgets (wxGTK package) to v3.1.5 in Rawhide. This
> includes a soname bump. I'm doing the build in a side tag:
> f35-build-side-40779.
> 

> As far as I can tell, the only users are CubicSDR and audacity. I'll
> rebuild CubicSDR. Gwyn or Ian, can you please take care of rebuilding
> audacity in the side tag?
> 

> Thanks,
> Scott



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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packaging for EPEL8 with gcc-9+

2021-05-05 Thread Stephen John Smoogen

On Wed, 5 May 2021 at 03:33, Евгений Пивнев  wrote:

> May be this is trivial question but I cannot find how to package
> application for EPEL8 that requires C++17+
> Adding «Requires: gcc-toolchain-10» into *.spec not helps.
>

The package name is gcc-toolset-9 and it is a SCL so you need to set up the
build environment like it is using other SCL's with an `scl enable` in the
spec file.




> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS...
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Carp] PR #1: Tests

2021-05-05 Thread Jitka Plesnikova


jplesnik merged a pull-request against the project: `perl-Carp` that you are 
following.

Merged pull-request:

``
Tests
``

https://src.fedoraproject.org/rpms/perl-Carp/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Packaging for EPEL8 with gcc-9+

2021-05-05 Thread Nico Kadel-Garcia

On Wed, May 5, 2021 at 3:32 AM Евгений Пивнев  wrote:
>
> May be this is trivial question but I cannot find how to package application 
> for EPEL8 that requires C++17+
> Adding «Requires: gcc-toolchain-10» into *.spec not helps.

Maybe one hasn't been published? I find that https://rpm.pbone.net/ is
really, really useful for this kind of search for an RPM.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Carp] PR #1: Tests

2021-05-05 Thread Jitka Plesnikova


jplesnik opened a new pull-request against the project: `perl-Carp` that you 
are following:
``
Tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Carp/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-35-20210505.0 compose check report

2021-05-05 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64)

Old failures (same test failed in Fedora-IoT-35-20210504.0):

ID: 879238  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/879238
ID: 879240  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/879240
ID: 879248  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/879248
ID: 879254  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/879254
ID: 879256  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/879256

Skipped non-gating openQA tests: 26 of 31
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20210505.n.0 changes

2021-05-05 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20210504.n.0
NEW: Fedora-Rawhide-20210505.n.0

= SUMMARY =
Added images:25
Dropped images:  0
Added packages:  4
Dropped packages:2
Upgraded packages:   159
Downgraded packages: 0

Size of added packages:  127.45 KiB
Size of dropped packages:646.37 KiB
Size of upgraded packages:   2.28 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20210505.n.0.iso
Image: Security live x86_64
Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Xfce raw-xz aarch64
Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20210505.n.0.aarch64.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210505.n.0.ppc64le.qcow2
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210505.n.0.x86_64.vagrant-virtualbox.box
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210505.n.0.s390x.qcow2
Image: Server dvd ppc64le
Path: Server/ppc64le/iso/Fedora-Server-dvd-ppc64le-Rawhide-20210505.n.0.iso
Image: Python_Classroom live x86_64
Path: 
Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20210505.n.0.iso
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20210505.n.0.ppc64le.raw.xz
Image: Everything boot ppc64le
Path: 
Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20210505.n.0.iso
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20210505.n.0.aarch64.raw.xz
Image: Xfce live x86_64
Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20210505.n.0.iso
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20210505.n.0.s390x.raw.xz
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20210505.n.0.iso
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210505.n.0.x86_64.vagrant-libvirt.box
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210505.n.0.x86_64.vagrant-libvirt.box
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20210505.n.0.iso
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20210505.n.0.x86_64.vagrant-virtualbox.box
Image: Server boot ppc64le
Path: Server/ppc64le/iso/Fedora-Server-netinst-ppc64le-Rawhide-20210505.n.0.iso
Image: Cinnamon live x86_64
Path: Spins/x86_64/iso/Fedora-Cinnamon-Live-x86_64-Rawhide-20210505.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: centos-packager-0.7.0-6.fc35
Summary: Tools and files necessary for building CentOS packages
RPMs:centos-packager
Size:21.60 KiB

Package: perl-CLI-Osprey-0.08-2.fc35
Summary: MooX::Options + MooX::Cmd + Sanity
RPMs:perl-CLI-Osprey
Size:43.51 KiB

Package: perl-Glib-IO-0.001-1.fc35
Summary: Perl bindings to the GIO library
RPMs:perl-Glib-IO
Size:22.22 KiB

Package: perl-PPIx-Utils-0.003-2.fc35
Summary: Utility functions for PPI
RPMs:perl-PPIx-Utils
Size:40.12 KiB


= DROPPED PACKAGES =
Package: clearlooks-phenix-7.0.1-10.fc34
Summary: Clearlooks-Phenix theme
RPMs:clearlooks-phenix-common clearlooks-phenix-gtk2-theme 
clearlooks-phenix-gtk3-theme clearlooks-phenix-metacity-theme 
clearlooks-phenix-openbox-theme clearlooks-phenix-xfwm4-theme
Size:465.79 KiB

Package: sidc-1.8-22.fc35
Summary: A VLF signal monitor for recording sudden ionospheric disturbances
RPMs:sidc
Size:180.57 KiB


= UPGRADED PACKAGES =
Package:  ansible-lint-1:5.0.8-1.fc35
Old package:  ansible-lint-1:5.0.7-1.fc35
Summary:  Best practices checker for Ansible
RPMs: python3-ansible-lint
Size: 177.63 KiB
Size change:  4.98 KiB
Changelog:
  * Tue May 04 2021 Parag Nemade  - 1:5.0.8-1
  - Update to 5.0.8 version (#1956328)


Package:  arm-none-eabi-binutils-cs-1:2.36.1-1.fc35
Old package:  arm-none-eabi-binutils-cs-1:2.35-4.fc35
Summary:  GNU Binutils for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-binutils-cs
Size: 11.58 MiB
Size change:  438.63 KiB
Changelog

[HEADS UP] wxGTK 3.1.5 in Rawhide

2021-05-05 Thread Scott Talbert


Hi,

I'm updating wxWidgets (wxGTK package) to v3.1.5 in Rawhide.  This 
includes a soname bump.  I'm doing the build in a side tag: 
f35-build-side-40779.


As far as I can tell, the only users are CubicSDR and audacity.  I'll 
rebuild CubicSDR.  Gwyn or Ian, can you please take care of rebuilding 
audacity in the side tag?


Thanks,
Scott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Upgrading Rawhide yesterday set hostname to localhost.localdomain

2021-05-05 Thread Zbigniew Jędrzejewski-Szmek

On Wed, May 05, 2021 at 12:28:56PM +0100, Richard W.M. Jones wrote:
> On Wed, May 05, 2021 at 09:16:38AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > I assume you had 'localhost.localdomain' in /etc/hostname, and now
> > you have 'pick.home.annexia.org' after the call to 'hostnamectl
> > set-hostname'. This sounds like a bug in NM then, because the static
> > configuration in /etc/ should take precedence, so NM shouldn't set
> > the hostname at all.
> 
> This is possible, yes.
> 
> > If it's not too much trouble, could you attach the output from
> > 'busctl introspect org.freedesktop.hostname1
> > /org/freedesktop/hostname1 org.freedesktop.hostname1', ideally
> > without NM running, so we know what hostnamed thinks on its own?
> 
> With NM disabled:
> 
> $ busctl introspect org.freedesktop.hostname1 /org/freedesktop/hostname1 
> org.freedesktop.hostname1  | cat
> NAME   TYPE  SIGNATURE RESULT/VALUE   
>   FLAGS
> .GetProductUUIDmethodb ay 
>   -
> .SetChassismethodsb-  
>   -
> .SetDeployment methodsb-  
>   -
> .SetHostname   methodsb-  
>   -
> .SetIconName   methodsb-  
>   -
> .SetLocation   methodsb-  
>   -
> .SetPrettyHostname methodsb-  
>   -
> .SetStaticHostname methodsb-  
>   -
> .Chassis   property  s "desktop"  
>   emits-change
> .DefaultHostname   property  s "fedora"   
>   const
> .Deploymentproperty  s "" 
>   emits-change
> .HardwareModel property  s "" 
>   const
> .HardwareVendorproperty  s "" 
>   const
> .HomeURL   property  s "https://fedoraproject.org/;   
>   const
> .Hostname  property  s "pick.home.annexia.org"
>   emits-change
> .HostnameSourceproperty  s "static"   
>   emits-change
> .IconName  property  s "computer-desktop" 
>   emits-change
> .KernelNameproperty  s "Linux"
>   const
> .KernelRelease property  s "5.11.0-0.rc3.122.fc34.x86_64" 
>   const
> .KernelVersion property  s "#1 SMP Mon Jan 11 15:10:32 
> UTC 2021"const
> .Location  property  s "" 
>   emits-change
> .OperatingSystemCPENameproperty  s 
> "cpe:/o:fedoraproject:fedora:35" const
> .OperatingSystemPrettyName property  s "Fedora 35 (Workstation 
> Edition Prerele… const
> .PrettyHostnameproperty  s "" 
>   emits-change
> .StaticHostnameproperty  s "pick.home.annexia.org"
>   emits-change

Looks all legit.

> Should we move this discussion to a BZ?

+1

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Upgrading Rawhide yesterday set hostname to localhost.localdomain

2021-05-05 Thread Richard W.M. Jones

On Wed, May 05, 2021 at 09:16:38AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I assume you had 'localhost.localdomain' in /etc/hostname, and now
> you have 'pick.home.annexia.org' after the call to 'hostnamectl
> set-hostname'. This sounds like a bug in NM then, because the static
> configuration in /etc/ should take precedence, so NM shouldn't set
> the hostname at all.

This is possible, yes.

> If it's not too much trouble, could you attach the output from
> 'busctl introspect org.freedesktop.hostname1
> /org/freedesktop/hostname1 org.freedesktop.hostname1', ideally
> without NM running, so we know what hostnamed thinks on its own?

With NM disabled:

$ busctl introspect org.freedesktop.hostname1 /org/freedesktop/hostname1 
org.freedesktop.hostname1  | cat
NAME   TYPE  SIGNATURE RESULT/VALUE 
FLAGS
.GetProductUUIDmethodb ay   
-
.SetChassismethodsb-
-
.SetDeployment methodsb-
-
.SetHostname   methodsb-
-
.SetIconName   methodsb-
-
.SetLocation   methodsb-
-
.SetPrettyHostname methodsb-
-
.SetStaticHostname methodsb-
-
.Chassis   property  s "desktop"
emits-change
.DefaultHostname   property  s "fedora" 
const
.Deploymentproperty  s ""   
emits-change
.HardwareModel property  s ""   
const
.HardwareVendorproperty  s ""   
const
.HomeURL   property  s "https://fedoraproject.org/; 
const
.Hostname  property  s "pick.home.annexia.org"  
emits-change
.HostnameSourceproperty  s "static" 
emits-change
.IconName  property  s "computer-desktop"   
emits-change
.KernelNameproperty  s "Linux"  
const
.KernelRelease property  s "5.11.0-0.rc3.122.fc34.x86_64"   
const
.KernelVersion property  s "#1 SMP Mon Jan 11 15:10:32 UTC 
2021"const
.Location  property  s ""   
emits-change
.OperatingSystemCPENameproperty  s "cpe:/o:fedoraproject:fedora:35" 
const
.OperatingSystemPrettyName property  s "Fedora 35 (Workstation Edition 
Prerele… const
.PrettyHostnameproperty  s ""   
emits-change
.StaticHostnameproperty  s "pick.home.annexia.org"  
emits-change

Should we move this discussion to a BZ?

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1957176] New: perl-CPAN-Perl-Releases-5.20210505 is available

2021-05-05 Thread bugzilla

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

Bug ID: 1957176
   Summary: perl-CPAN-Perl-Releases-5.20210505 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.20210505
Current version/release in rawhide: 5.20210420-1.fc35
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


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

co/lead-maintainer sought: python-mailmerge (python)

2021-05-05 Thread Brian (bex) Exelbierd

Hi,

I added python-mailmerge to Fedora Linux as it was super important to
large parts of my work as FCAIC.  In my current $dayjob I use it less
frequently, though I know of colleagues who still depend on it.

I'd love to find a maintainer to help me with it.  There is a new
release pending, which I suspect will just be "build the rpm with new
code; test it; ship it" level effort.  I am happy to hand the whole
thing off to someone or to work with you.

Thank you.

regards,

bex
-- 
Did this email arrive after work for you?  Stop reading it and enjoy
some work/life balance.

Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

co/lead-maintainer sought: gocryptfs+dependencies (go-lang)

2021-05-05 Thread Brian (bex) Exelbierd

Hi,

While I still actively use gocryptfs, I am busy enough with my $dayjob
that I know I am not able to put enough time into maintaining it.
Right now this has been OK as they have stopped new releases while
they get v2.0 out the door.  However, that will ship soon.

I'd love to get some help maintaining the main rpm and the 6
dependencies I have for it.  I am happy to hand it all over to you or
to work with you.

Thank you.

regards,

bex
-- 
Did this email arrive after work for you?  Stop reading it and enjoy
some work/life balance.

Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: PETSc 3.15

2021-05-05 Thread Antonio T. sagitter

This side-tag is obsolete because of recent rebuild of PETSc-3.15 
rebuild #2 for cgnslib:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1741817

I'm removing the side-tag f35-build-side-40112
Must i untag the related builds in this case? (bout++-4.3.2-8.fc35 and 
python-steps-3.5.0-8.fc35)


On 4/25/21 6:16 PM, Antonio T. sagitter wrote:

$ koji list-tagged --latest f35-build-side-40112

Build Tag   Built by

   



bout++-4.3.2-8.fc35   f35-build-side-40112  davidsch

petsc-3.15.0-1.fc35   f35-build-side-40112  sagitter

python-steps-3.5.0-8.fc35    f35-build-side-40112 ankursinha

On 4/10/21 7:30 PM, Antonio T. sagitter wrote:

Also

dolfin-0:2019.1.0.post0-10.fc33.src
getdp-0:3.3.0-6.fc33.src


On 4/10/21 7:26 PM, Antonio T. sagitter wrote:

Hi all.

PETSc 3.15 is coming in Rawhide branch.

Release notes: 
https://www.mcs.anl.gov/petsc/documentation/changes/315.html


Dependencies in Fedora:

$ repoquery --disablerepo=* --enablerepo=fedora*-source 
--whatrequires petsc-openmpi-devel

bout++-0:4.3.1-7.fc33.src
freefem++-0:4.6-6.fc33.src
petsc4py-0:3.13.0-5.fc33.src
python-steps-0:3.5.0-5.fc33.src







--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


OpenPGP_signature
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20210505.0 compose check report

2021-05-05 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

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

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

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

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

Re: Upgrading Rawhide yesterday set hostname to localhost.localdomain

2021-05-05 Thread Zbigniew Jędrzejewski-Szmek

On Wed, May 05, 2021 at 10:03:29AM +0100, Richard W.M. Jones wrote:
> On Wed, May 05, 2021 at 09:41:48AM +0100, Richard W.M. Jones wrote:
> > 
> > No idea what particular component / update caused that though,
> > or even how to find out.
> 
> So it started with:
> 
> localhost.localdomain systemd-hostnamed[1796302]: Hostname set to 
>  (static)
> 
> but this seems uncorrelated with any package installation or removal.
> After this systemd and NetworkManager appear to be battling with each
> other to set the hostname.  I have hundreds of messages like this:
> 
> May 04 13:52:08 localhost.localdomain NetworkManager[1503]:   
> [1620132728.1664] policy: set-hostname: set hostname to 'pick' (from DHCPv4)
> May 04 13:52:08 localhost.localdomain systemd[1]: Starting Hostname Service...
> May 04 13:52:08 localhost.localdomain systemd[1]: Started Hostname Service.
> May 04 13:52:08 localhost.localdomain systemd-hostnamed[4074869]: Hostname 
> set to  (static)
> ...
> May 04 13:52:47 localhost.localdomain NetworkManager[1503]:   
> [1620132767.0935] policy: set-hostname: current hostname was changed outside 
> NetworkManager: 'localhost.localdomain'
> May 04 13:52:47 localhost.localdomain NetworkManager[1503]:   
> [1620132767.0938] policy: set-hostname: set hostname to 'pick' (from DHCPv4)
> 
> Setting the hostname now through hostnamectl hasn't calmed things
> down, now they're battling to set the hostname to 'pick' (NM) or
> 'pick.home.annexia.org' (systemd).
> 
> Is this a bug?  What component would it be filed against?

I assume you had 'localhost.localdomain' in /etc/hostname, and now you have 
'pick.home.annexia.org'
after the call to 'hostnamectl set-hostname'. This sounds like a bug in NM 
then, because
the static configuration in /etc/ should take precedence, so NM shouldn't set 
the hostname
at all.

If it's not too much trouble, could you attach the output from
'busctl introspect org.freedesktop.hostname1 /org/freedesktop/hostname1 
org.freedesktop.hostname1',
ideally without NM running, so we know what hostnamed thinks on its own?

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Upgrading Rawhide yesterday set hostname to localhost.localdomain

2021-05-05 Thread Richard W.M. Jones

On Wed, May 05, 2021 at 09:41:48AM +0100, Richard W.M. Jones wrote:
> 
> No idea what particular component / update caused that though,
> or even how to find out.

So it started with:

localhost.localdomain systemd-hostnamed[1796302]: Hostname set to 
 (static)

but this seems uncorrelated with any package installation or removal.
After this systemd and NetworkManager appear to be battling with each
other to set the hostname.  I have hundreds of messages like this:

May 04 13:52:08 localhost.localdomain NetworkManager[1503]:   
[1620132728.1664] policy: set-hostname: set hostname to 'pick' (from DHCPv4)
May 04 13:52:08 localhost.localdomain systemd[1]: Starting Hostname Service...
May 04 13:52:08 localhost.localdomain systemd[1]: Started Hostname Service.
May 04 13:52:08 localhost.localdomain systemd-hostnamed[4074869]: Hostname set 
to  (static)
...
May 04 13:52:47 localhost.localdomain NetworkManager[1503]:   
[1620132767.0935] policy: set-hostname: current hostname was changed outside 
NetworkManager: 'localhost.localdomain'
May 04 13:52:47 localhost.localdomain NetworkManager[1503]:   
[1620132767.0938] policy: set-hostname: set hostname to 'pick' (from DHCPv4)

Setting the hostname now through hostnamectl hasn't calmed things
down, now they're battling to set the hostname to 'pick' (NM) or
'pick.home.annexia.org' (systemd).

Is this a bug?  What component would it be filed against?

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1956816] Package perl-Mojolicious with broken dependencies from EPEL Repository

2021-05-05 Thread bugzilla

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |NOTABUG
Last Closed||2021-05-05 09:03:12



--- Comment #4 from Petr Pisar  ---
Obviously you have a problem with perl-Time-HiRes. Not with perl-Mojolicious.
perl-Time-HiRes is not provided by EPEL and thus you report cannot be handled
here.
Should you still experience problems with perl-Time-HiRes, please contact your
vendor of the package. In case it is Red Hat, Inc., use Red Hat support at
.


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

Upgrading Rawhide yesterday set hostname to localhost.localdomain

2021-05-05 Thread Richard W.M. Jones


No idea what particular component / update caused that though,
or even how to find out.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads-up: RPM 4.17 alpha coming to rawhide near you

2021-05-05 Thread Panu Matilainen


On 5/5/21 11:22 AM, Miro Hrončok wrote:

On 05. 05. 21 10:15, Panu Matilainen wrote:

On 4/29/21 3:49 PM, Miro Hrončok wrote:

On 29. 04. 21 14:23, Panu Matilainen wrote:

On 4/29/21 11:58 AM, Miro Hrončok wrote:

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the 
season for new rpm in rawhide. As per 
https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite 
large, and while it's supposed to be backwards compatible with 
changes this big it'd be foolish not to expect some amount of the 
unexpected. So please pay attention, and don't be shy about filing 
bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999



An intentional change does not classify as a regression in my books.


It is a matter of perspective: A sudden unannounced breakage of 
something that worked and appeared as part of the API classifies as 
regression in my books :)


The macro always was just an internal helper and intentionally 
entirely undocumented, just mistakenly lacking the preceding 
undrescores (but then neither of those ever stopped people from 
using "stuff").


It is documented in the macros file (very briefly), like all the 
other related macros.


We can make the change more visible, and we can consider temporary 
patches in Fedora, but %apply_patch is not an interface we want to 
support.


Let's deprecate it maybe in that case?


If it was something that is used by dozens of packages, we wouldn't be 
here in the first place. As it is, it's exactly 10 packages in Fedora, 
most of which are different versions of Python. So going through a 
deprecation process seems over the top.


I understand that point of view, but maybe deprecating stuff isn't that 
complex?


It's not about complicated per single change, it's about collapsing 
under the weight of backwards compatibility if we start worrying about 
and going through deprecation process for every undocumented behavior 
and interface that people may have discovered.




I've tried to do it in 
https://github.com/rpm-software-management/rpm/pull/1668



What is the supported alternative?



%autopatch -m  -M 

It's a bit silly of course but it IS supported, and easily wrapped in 
a local helper as well.


I've tried to add an explicit -n option to %autopatch in the PR linked 
above to make it less silly.


What do you think?



Adding -n is totally sensible.

- 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads-up: RPM 4.17 alpha coming to rawhide near you

2021-05-05 Thread Miro Hrončok


On 05. 05. 21 10:15, Panu Matilainen wrote:

On 4/29/21 3:49 PM, Miro Hrončok wrote:

On 29. 04. 21 14:23, Panu Matilainen wrote:

On 4/29/21 11:58 AM, Miro Hrončok wrote:

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the season for 
new rpm in rawhide. As per https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite large, and 
while it's supposed to be backwards compatible with changes this big it'd 
be foolish not to expect some amount of the unexpected. So please pay 
attention, and don't be shy about filing bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999



An intentional change does not classify as a regression in my books.


It is a matter of perspective: A sudden unannounced breakage of something that 
worked and appeared as part of the API classifies as regression in my books :)


The macro always was just an internal helper and intentionally entirely 
undocumented, just mistakenly lacking the preceding undrescores (but then 
neither of those ever stopped people from using "stuff").


It is documented in the macros file (very briefly), like all the other related 
macros.


We can make the change more visible, and we can consider temporary patches in 
Fedora, but %apply_patch is not an interface we want to support.


Let's deprecate it maybe in that case?


If it was something that is used by dozens of packages, we wouldn't be here in 
the first place. As it is, it's exactly 10 packages in Fedora, most of which are 
different versions of Python. So going through a deprecation process seems over 
the top.


I understand that point of view, but maybe deprecating stuff isn't that complex?

I've tried to do it in https://github.com/rpm-software-management/rpm/pull/1668


What is the supported alternative?



%autopatch -m  -M 

It's a bit silly of course but it IS supported, and easily wrapped in a local 
helper as well.


I've tried to add an explicit -n option to %autopatch in the PR linked above to 
make it less silly.


What do you think?

--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210505.0 compose check report

2021-05-05 Thread Fedora compose checker

No missing expected images.

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

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

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

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

Re: Heads-up: RPM 4.17 alpha coming to rawhide near you

2021-05-05 Thread Panu Matilainen


On 4/29/21 3:49 PM, Miro Hrončok wrote:

On 29. 04. 21 14:23, Panu Matilainen wrote:

On 4/29/21 11:58 AM, Miro Hrončok wrote:

On 26. 04. 21 12:36, Panu Matilainen wrote:
It's spring, it's raining sleet where I live, and it's also the 
season for new rpm in rawhide. As per 
https://fedoraproject.org/wiki/Changes/RPM-4.17.


The changes to the macro subsystem internals have been quite large, 
and while it's supposed to be backwards compatible with changes this 
big it'd be foolish not to expect some amount of the unexpected. So 
please pay attention, and don't be shy about filing bugs.


Another regression found:

Convenient public macro %apply_patch removed without warning
https://bugzilla.redhat.com/show_bug.cgi?id=1954999



An intentional change does not classify as a regression in my books.


It is a matter of perspective: A sudden unannounced breakage of 
something that worked and appeared as part of the API classifies as 
regression in my books :)


The macro always was just an internal helper and intentionally 
entirely undocumented, just mistakenly lacking the preceding 
undrescores (but then neither of those ever stopped people from using 
"stuff").


It is documented in the macros file (very briefly), like all the other 
related macros.


We can make the change more visible, and we can consider temporary 
patches in Fedora, but %apply_patch is not an interface we want to 
support.


Let's deprecate it maybe in that case?


If it was something that is used by dozens of packages, we wouldn't be 
here in the first place. As it is, it's exactly 10 packages in Fedora, 
most of which are different versions of Python. So going through a 
deprecation process seems over the top.




What is the supported alternative?



%autopatch -m  -M 

It's a bit silly of course but it IS supported, and easily wrapped in a 
local helper as well.


- 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning packages: multi-git-status, pass-pwned, dayjournal

2021-05-05 Thread Brian (bex) Exelbierd

Hi,

I've orphaned the following two packages:

* multi-git-status: It scans directory trees of git repos and reports
if they have uncommitted changes, branches not pushed, etc.  It has a
low release cadence, however it has never fit my workflow.

Note: There is a new release pending

* pass-pwned: An extension to the pass password manager that checks
passwords against Have I been Pwned.  This has a low release cadence.
I am orphaning it because I no longer use pass in any significant way.

* dayjournal: A journaling program.  The upstream is dead and never
really had it's act together.  It is an attempt at a compatible
journal (by format) with Day One (v1).  It has not been updated in
years.

If you have questions, don't hesitate to ask.

regards,

bex
--
Did this email arrive after work for you?  Stop reading it and enjoy
some work/life balance.

Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Packaging for EPEL8 with gcc-9+

2021-05-05 Thread Евгений Пивнев

May be this is trivial question but I cannot find how to package application 
for EPEL8 that requires C++17+
Adding «Requires: gcc-toolchain-10» into *.spec not helps.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New RPM submission

2021-05-05 Thread Otto Urpelainen


Matthew Miller kirjoitti 4.5.2021 klo 19.38:

On Tue, May 04, 2021 at 10:09:09AM +0300, Otto Urpelainen wrote:

Could you comment on the status of repository
package-maintainer-docs at pagure.io [1]? It looks like it is
intended to be that migration, I wanted to contribute and started
with a tiny pull request (to be followed by more substantial ones),
but there has been no reaction from you or other admins.


I am the nominal owner of that repo by happenstance.  I'm happy to just give
ownership of it to you, if you like, or a new one could be started. (We'd
want to migrate it to antora rather than pelican, I think!)



Thank you the explanation. If you hand the repository over to me, I can 
see that material from the wiki is migrated there and the repository 
published at docs.fp.o Engineering Teams [1] as "Package Maintainers" ( 
or is it officially "Fedora Package Maintainers"?). And that tooling is 
updated to Antora for sure.


I will not sign up for a complete review, at least not now. Such 
efforts, as well as smaller updates can be coordinated and implemented 
through issues and pull requests.


Regarding the immediate update needs, before this migration happens, 
please just keep the wiki updated.


[1]: https://docs.fedoraproject.org/en-US/engineering/

Otto
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RPM name collisions

2021-05-05 Thread Adam Williamson

On Wed, 2021-05-05 at 07:44 +0200, Dan Čermák wrote:
> przemek klosowski via devel  writes:
> 
> > Is that something we need to worry about? I couldn't think of any new 
> > rules to impose on repositories, but maybe dnf should have more explicit 
> > warnings when it sees multiple versions of the same package, or at least 
> > a way to show such versions.
> 
> Or how about teaching dnf that only certain repositories are allowed to
> be used for updates (with an allowedlist for exceptions)? Then microsoft
> or any other third party repo could put hello-5000-1 into their repo and
> it could never compromise your system, as dnf would not consider the 3rd
> party repo a valid update repo for a base system package.
> 
> That would require dnf to track where it got the package from though
> and I am not sure if it does that at the moment?

It does, but then you're just opening up a whole can of worms. And, I
mean, this seems like a very narrow focus. If a third party wants to do
something nefarious and can convince you to "install a repository" in
some way, that means that at minimum they convinced you to drop an
arbitrary file in /etc/yum.repos.d . What they probably did was
convince you to install a package containing the repo definition, as
that's the way most third party repos deploy. Well, that package could
do *absolutely anything else at all* on your system with root
privileges, because that's how packaging works.

And a nefarious repo doesn't really need to use an RPM name collision
to do...well...anything much, really. It can just have a perfectly
correctly-named package contain whatever nefarious payload it wants.

So I guess my question is: is there something specific we are
preventing by worrying about package name collisions, which any person
in a position to produce a package name collision could not just
achieve in a dozen or more other ways?
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

49 matches

Mail list logo