Re: x86_64-v2 in Fedora

[Gerd Hoffmann]

  Hi,

> The problems with this is that we are taking a fairly fuzzy data set
> and making it much easier to track individual users in ways seen as
> problematic by various laws and regulations.

Well, depends on how you store the data.  You can store one record per
machine (with all properties in there), or you can store one record per
property per machine.

With the latter you basically kill query on subgroups (like "how many
x86_64-v3 machines use UEFI?") because that grouping information is gone
if you store each end every little piece of information in its own
record.  But it'll also much harder to do fingerprinting on such a data
base ...

Standard disclaimer: IANAL.

take care,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Mark Otaris]

For Fedora, linux-hardware.org says 78% use EFI and 16% have Secure Boot 
enabled. Not a very good data set, though Fedora telemetry wouldn’t be either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1972385] perl-POE-Component-IRC-6.93 is available

[bugzilla]

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



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

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


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

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-a6e2c9bc8c   
radare2-5.3.1-1.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-0209079fce   
aom-3.1.1-1.el8


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

editorconfig-0.12.5-1.el8
elmon-13b1-13.el8
fcl-0.6.1-5.el8
qt-creator-4.12.4-7.el8

Details about builds:



 editorconfig-0.12.5-1.el8 (FEDORA-EPEL-2021-9b5b82119d)
 Parser for EditorConfig files written in C

Update Information:

Update to version 0.12.5. This release contains only a fix for a small memory
leak and no other changes.  Release notes:
https://github.com/editorconfig/editorconfig-core-c/releases/tag/v0.12.5

ChangeLog:

* Thu Jun 17 2021 Fabio Valentini  - 0.12.5-1
- Update to version 0.12.5.

References:

  [ 1 ] Bug #1973182 - editorconfig-0.12.5 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1973182




 elmon-13b1-13.el8 (FEDORA-EPEL-2021-e4b6a36bbd)
 Performance monitoring tool

Update Information:

New branch build for the EPEL8

ChangeLog:





 fcl-0.6.1-5.el8 (FEDORA-EPEL-2021-312189d6c3)
 Flexible Collision Library

Update Information:

Introducing the fcl package to EPEL8

ChangeLog:


References:

  [ 1 ] Bug #1971986 - Please build fcl for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1971986




 qt-creator-4.12.4-7.el8 (FEDORA-EPEL-2021-f40a1214b9)
 Cross-platform IDE for Qt

Update Information:

Rebuild for RHEL 8.4

ChangeLog:

* Thu Jun 17 2021 Sandro Mani  - 4.12.4-7
- Rebuild (llvm)
* Fri May 21 2021 Carl George  - 4.12.4-6
- Rebuild for llvm/clang 11 (RHEL 8.4)
* Thu May 20 2021 Carl George  - 4.12.4-5
- Rebuild for llvm/clang 11 (RHEL 8.4)

References:

  [ 1 ] Bug #1973331 - Request to rebuild qt-creator for RHEL 8.4
https://bugzilla.redhat.com/show_bug.cgi?id=1973331


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

[Bug 1972385] perl-POE-Component-IRC-6.93 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2021-777c04ebc1 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2021-777c04ebc1`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2021-777c04ebc1

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


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

debugging pipewire & root access to systemd userspace

[Alexander Ploumistos]

Hello,

Apologies if you find the subject line vague or misleading, I couldn't
figure out what to write. I've been trying to debug a transient
pipewire issue so that I can file a bug report, but I keep stumbling
from one roadblock to the next.

When the problem occurs, pipewire receives a SIGSEGV and dies, e.g.
kernel: pipewire[2239]: segfault at 0 ip  sp
7fc634298998 error 14 in pipewire[55d7316d+1000]
kernel: Code: Unable to access opcode bytes at RIP 0xffd6.

At that point, abrt tries to get gdb to process the core dump, which
fails because it wants to open a sound device:
audit[7970]: AVC avc:  denied  { read } for  pid=7970 comm="gdb"
name="pcmC0D0p" dev="devtmpfs" ino=594
scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
permissive=0

Should gdb be able to read from a sound device?

There seems to be a problem in impl_node_process.lto_priv.0, but a) I
can't reproduce it at will and b) abrt can't send a report to someone
who knows what they're doing because it can't process the core dump.

Having root logged in a terminal, I tried to check the state of
pipewire.service:
systemctl --machine=myuser@.host --user status pipewire.service

to which I got the reply:
Failed to get properties: Transport endpoint is not connected

Am I doing something wrong here? How is root supposed to control (or
just check on) userspace systemd services? I've also tried the
loopback address and my actual IP instead of .host, but no luck with
them either. The user can run all the systemctl --user commands just
fine.

By the way, what is the proper, Fedora way to restart pipewire? Is
$ systemctl --user restart pipewire.service
what I should be doing?

I haven't had to bother with a userspace systemd service before, so
going down that rabbit hole, at some point I started messing with
machinectl, and apparently, running something seemingly innocuous such
as "machinectl list-images --all" triggers a SELinux denial. But not
always…
The message I'm seeing is this:
audit[1079]: AVC avc:  denied  { write } for  pid=1079
comm="systemd-machine" name="/" dev="dm-1" ino=2
scontext=system_u:system_r:systemd_machined_t:s0
tcontext=system_u:object_r:root_t:s0 tclass=dir permissive=0

setroubleshoot tells me that if I want to allow daemons to dump core,
then I should enable the 'daemons_dump_core' boolean. I don't know if
I want to, do I need to do that in order to dive deeper into my
pipewire issue? How is listing the images on a system related to
allowing demons to dump core though?

If anyone can shed some light on any of the above, please do.
Again, sorry for the messy subject and the even messier post.


Best regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd unit auto-enabling question

[Peter Hutterer]

On Thu, Jun 17, 2021 at 07:48:24AM -0500, Michael Catanzaro wrote:
> On Thu, Jun 17 2021 at 11:52:44 AM +1000, Peter Hutterer
>  wrote:
> > What I need is manager.service being auto-enabled at install time. How
> > do I
> > get this done?
> 
> Hi, you're missing a systemd preset. You generally need FESCo approval to
> add a preset. See:
> 
> * https://src.fedoraproject.org/rpms/fedora-release/tree/rawhide,
> specifically 90-default-user.preset
> * https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/
> 
> That said, we already have user session presets for pipewire in
> 90-default-user.preset:
> 
> enable pipewire.socket
> enable pipewire-pulse.socket
> 
> This allows Pipewire to be enabled by default, but via socket activation
> only. The lack of a preset for pipewire.service itself seems to be
> intentional.

Thanks for the info. The preset for pipewire.socket affects only the daemon
itself, not the manager process (pipewire-media-session or wireplumber,
depending on which one of the two is installed).

What this means is that pipewire starts up fine after installing, but
neither management daemon starts automatically after install, it needs the
manual systemctl enable.

Right now pipewire gets around this by hardcoding pipewire-media-session and
starting it directly (instead of the systemd service) but that makes it hard
to replace.

Anyway, sounds like I'd need to get the FESCo approval for both packages
then?

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

Re: x86_64-v2 in Fedora

[Stephen Snow]

Okay,
So here comes another naive suggestion.

The metrics that are desired are really innocuous content which should
not risk anonymity, correct? Such things like BIOS/UEFI/?, CPU, Memory,
installed edition or spin, when it was installed, optional packages,
storage setup, etc... I presume. Why not create install time json file
with desired info, which is available info at the time, show the user
the content and ask for permission to transmit the file encrypted to
. Or even make it a non-fungable file
maybe, which gets generated at update time too with additional info
like package diff etc... Instead of a tool say that is continuously on.

Stephen Snow


On Thu, 2021-06-17 at 13:10 -0700, Kevin Fenzi wrote:
> On Thu, Jun 17, 2021 at 10:36:47AM -0500, Ron Olson wrote:
> > Apologies in advance if this is laughable naïveté, but would a
> > possible solution be to have a different repo for packages compiled
> > against the latest-n-greatest architectures, and packagers could
> > choose to include their packages in there, similar to EPEL?
> > Packages in this hypothetical repo could be marked to replace
> > existing ones via %obsoletes or some other mechanism; this would
> > give the user the control to decide if he or she wants to switch to
> > a “higher-performant” version and not have to rely on HW checks or
> > telemetry.
> > 
> > Just a thought.
> 
> Sure, thats possible, however it would use a lot of resources. ;( 
> 
> * builder cpu cycles and disk
> * mirror disk space
> * buildsystem disk space
> * mirroring BW
> etc. 
> 
> and... the most important resource: everyone's time. If you have
> multiple versions of your package you have to ask everyone in bug
> reports which one they are using, you might not be able to duplicate
> due
> to lack of hardware, you have 2x as many things to worry about, etc. 
> 
> So, while thats very possible, I fear we don't have the resources to
> do
> it. (Nor do I think the benifits are worth it currently). 
> 
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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

Re: Pipewire and Jack usage in an RPM

[Ian McInerney]

On Thu, Jun 17, 2021 at 8:40 PM Leigh Scott  wrote:

> Why are you trying to install a srpm?
>
>
D'oh *facepalm*. That is what I get when I don't pay attention when copying
the rpm from one folder to another. Yep, it works on the actual RPM now.

-Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Kevin Fenzi]

On Thu, Jun 17, 2021 at 10:36:47AM -0500, Ron Olson wrote:
> Apologies in advance if this is laughable naïveté, but would a possible 
> solution be to have a different repo for packages compiled against the 
> latest-n-greatest architectures, and packagers could choose to include their 
> packages in there, similar to EPEL?
> Packages in this hypothetical repo could be marked to replace existing ones 
> via %obsoletes or some other mechanism; this would give the user the control 
> to decide if he or she wants to switch to a “higher-performant” version and 
> not have to rely on HW checks or telemetry.
> 
> Just a thought.

Sure, thats possible, however it would use a lot of resources. ;( 

* builder cpu cycles and disk
* mirror disk space
* buildsystem disk space
* mirroring BW
etc. 

and... the most important resource: everyone's time. If you have
multiple versions of your package you have to ask everyone in bug
reports which one they are using, you might not be able to duplicate due
to lack of hardware, you have 2x as many things to worry about, etc. 

So, while thats very possible, I fear we don't have the resources to do
it. (Nor do I think the benifits are worth it currently). 

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: Can't login with kinit using 2FA

[Kevin Fenzi]

On Thu, Jun 17, 2021 at 11:00:33AM -0400, Simo Sorce wrote:
> On Thu, 2021-06-17 at 07:54 -0500, Michael Catanzaro wrote:
> > On Thu, Jun 17 2021 at 10:09:26 AM +0100, David Howells 
> >  wrote:
> > > What if you're not using gnome?
> > 
> > Then you should install fedora-packager-kerberos? Or fedora-packager, 
> > which has a dependency on fedora-packager-kerberos.
> > 
> > Anyway, at first I thought that gnome-online-accounts needed a 
> > dependency on this new fedora-packager-kerberos if special kerberos 
> > configuration is required now, but as Kevin explained that dep is only 
> > required if using OTP, and OTP doesn't work with gnome-online-accounts 
> > anyway, so we're fine. (Well, as fine as we can be when enabling OTP is 
> > an irreversible trap that will permanently break your 
> > gnome-online-accounts, requiring the creation of a new FAS account to 
> > recover.)
> 
> I am pretty sure you can ask an admin to fix the FAS account if really
> needed.
> OTP cannot be reversed by users themselves, but admins can fix it if
> really needed.

Indeed. We do need to verify you are you before we clear your last token
thought. (gpg signed email from the same key as attached to your
account, etc).

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: Can't login with kinit using 2FA

[Kevin Fenzi]

On Wed, Jun 16, 2021 at 12:32:43PM -0500, Michael Catanzaro wrote:
> On Wed, Jun 16 2021 at 09:54:02 AM -0700, Kevin Fenzi 
> wrote:
> > I think there are plans to improve this use case in krb5 utils.
> > I suppose we could also see if GOA could support this case somehow and
> > add a dep on fedora-packager-kerberos. Where should I file that? gitlab?
> > Or would someone else like to do so?
> 
> Do you have an account on GNOME GitLab? That would be the best place. I can
> report it for you if not.

I do: 
https://gitlab.gnome.org/GNOME/gnome-online-accounts/-/issues/171
feel free to comment there. 

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: Pipewire and Jack usage in an RPM

[Leigh Scott]

Why are you trying to install a srpm?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Pipewire and Jack usage in an RPM

[Ian McInerney]

I was just trying amock build of Audacity to test some updates and I am now
having trouble installing it on F34 because of a conflict between
jack-audio-connection-kit and pipewire-jack-audio-connection-kit:

$ sudo dnf install ./audacity-3.0.2-3.fc34.src.rpm
Last metadata expiration check: 2:19:21 ago on Thu 17 Jun 2021 06:06:28 PM
BST.
Error:
 Problem: package audacity-3.0.2-3.fc34.src requires
jack-audio-connection-kit-devel, but none of the providers can be installed
  - package jack-audio-connection-kit-devel-1.9.17-1.fc34.x86_64 requires
jack-audio-connection-kit = 1.9.17-1.fc34, but none of the providers can be
installed
  - package jack-audio-connection-kit-devel-1.9.17-1.fc34.i686 requires
jack-audio-connection-kit = 1.9.17-1.fc34, but none of the providers can be
installed
  - package jack-audio-connection-kit-devel-1.9.16-2.fc34.x86_64 requires
jack-audio-connection-kit = 1.9.16-2.fc34, but none of the providers can be
installed
  - package jack-audio-connection-kit-devel-1.9.16-2.fc34.i686 requires
jack-audio-connection-kit = 1.9.16-2.fc34, but none of the providers can be
installed
  - package pipewire-jack-audio-connection-kit-0.3.25-1.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.17-1.fc34.i686
  - package pipewire-jack-audio-connection-kit-0.3.25-1.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.17-1.fc34.x86_64
  - package pipewire-jack-audio-connection-kit-0.3.25-1.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.16-2.fc34.i686
  - package pipewire-jack-audio-connection-kit-0.3.25-1.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.16-2.fc34.x86_64
  - problem with installed package
pipewire-jack-audio-connection-kit-0.3.30-2.fc34.x86_64
  - package pipewire-jack-audio-connection-kit-0.3.30-2.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.17-1.fc34.x86_64
  - package pipewire-jack-audio-connection-kit-0.3.30-2.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.16-2.fc34.x86_64
  - conflicting requests
  - package pipewire-jack-audio-connection-kit-0.3.30-2.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.17-1.fc34.i686
  - package pipewire-jack-audio-connection-kit-0.3.30-2.fc34.x86_64
conflicts with jack-audio-connection-kit provided by
jack-audio-connection-kit-1.9.16-2.fc34.i686
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages)

Are these two Jack packages interchangable? If so, how can I avoid having
this error appear during the installation. It is also interesting to note
that this doesn't happen with the version currently in the repository, but
only with my mockbuild version of Audacity.

Any ideas?

Thanks,
-Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 16, 2021 at 11:02:23PM +0200, Fabio Valentini wrote:
> On Wed, Jun 16, 2021 at 9:52 PM Benjamin Beasley
>  wrote:
> >
> > At the risk of overextending an already well-elaborated thread, I would 
> > like to point out that my main workstation, for Fedora packaging and other 
> > purposes, has an Intel Q6600 (Core 2 Quad) that does NOT meet the 
> > requirements for x86_64-v2. I built it in 2007, and it has exceeded all 
> > expectations for how long it would remain useful. The desktop I maintain 
> > for my parents uses an AMD Phenom II X4 965 processor, circa 2009-2010, and 
> > it doesn’t support x86_64-v2 either—but it just keeps on working.
> >
> > Now, I can afford to replace my own workstation if I must—and I’m planning 
> > to do so in another year or two when the rolling component shortages settle 
> > out a little—but I suspect there are still many others like me, some of 
> > whom might not be in a position to just sigh and buy new hardware. Even for 
> > those who can, the pandemic and the crypto crazes have made it an 
> > exceptionally bad time to be forced into an upgrade.
> 
> So ... maybe the following approach would be a way forward that would
> benefit everybody (TM):
> 
> 1. stay with x86-64-baseline for Fedora for now (performance critical
> software often has runtime CPU feature detection and dynamic dispatch
> anyway)
> 2. identify "performance sensitive" libraries in Fedora that do not
> have runtime CPU feature detection, and which would benefit from
> having the instructions that are added with x86-64-v2 available (looks
> like the the performance benefit of enabling this overall is small
> (?), but maybe there are exceptions, where bumping from x86-64 to
> x86-64-v2 would make a bigger difference for some library)
> 3. make it easy to build the libraries identified under 2. twice (or
> three times, with x86-64-v3?) and install them in the locations where
> the loader can find them (leveraging the new HWCAPS functionality)

A good idea. But in that case it'd make sense to raise the bar quite
a bit higher, and e.g. compile specifically for modern Intel CPUs
and e.g. AMD Ryzen. If we don't have to make the baseline acceptable
to everyone, we should make a big jump.

Zbyszek

> This approach would allow older machines to continue to run the latest
> Fedora just fine, while libraries that *would* benefit from more
> available CPU instructions would run faster for the people who have
> newer hardware.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Thu, 17 Jun 2021 at 12:27, Justin Forbes  wrote:
>
> On Wed, Jun 16, 2021 at 3:23 PM Matthew Miller  
> wrote:
> >
> > On Wed, Jun 16, 2021 at 02:57:17PM +0200, Vitaly Zaitsev via devel wrote:
> > > >We'll at least gather information about capabilities of Fedora
> > > >users hardware.
> > > Telemetry is evil. It must not be allowed.
> >
> > Well, that's certainly A Position. I don't think it's anything nearly so
> > absolute, though, and depends on what, who, how, why, and a host of other
> > things. And "it can help us answer questions like this for our community" is
> > a pretty non-evil "why".
>
> I think there can be a lot of benefit in anonymized hardware data (not
> mandatory).  It does help answer questions like this, but more
> importantly, it would make a lot of the kernel work a bit easier, or
> at least more focused.   It answers questions like, "should we enable
> these drivers as they are likely to be used?" or "can we disable these
> drivers because no one is using them?". It is also very helpful in
> working out bug priority in drivers.  A lot of people never bother
> filing bugs, and are happy to keep booting a known good kernel since
> we allow parallel installs. If we get a few users chiming in, and
> realize the hardware in question is used by a significant chunk of
> users, it would  tell me that perhaps that should take priority over a
> bug which impacts hardware with considerably fewer users.   Yes, you
> have to be extremely careful about what data you collect, and how that
> data is handled, but if done correctly, there are a lot of benefits.
>


The major problem is that 'anonymized' data does not exist. Pretty
much every method which says it 'anonymizes' stuff does not and can
lead to a strong 'fingerprint' back to an individual or group. The
only methods which truly do seem to stop this basically add so much
random noise to the data that it is 'useless' for whatever analysis.
[AKA you might as well just tell /dev/urandom to give you a couple of
gigabytes of answers.]

This means that any program you use to collect information needs to
assume that it will have to be regularly purged/cleaned/etc. You will
have to only take snapshots of very high level data to compare to
other timeframes. It also has to assume that there are enough people
who do not want to be watched (even if you ask for them to volunteer
info) that they will feed you bad data. This is why we had more
PDP-11's in smolt than we had some valid architectures we shipped.

Once you start finding these limits, you realize you don't want to mix
it with data you need for continual operation of service. If you do,
you will lose that data regularly also, may be told to turn off, or
find yourself spending too many resources to keep it. This is the
reason I object to adding too much to mirrorlist data. That is a
service which we need to keep up and we need to keep some history for
general operations. [We need to know how many resources we are
servicing and how long it takes to respond. Having multiple years
helped show when the mirror program began to fall over from too many
customers and the fact that the change in certain yum cron jobs were
increasingly causing issues.]

-- 
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...
time to reboot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Chris Murphy]

On Thu, Jun 17, 2021 at 10:26 AM Justin Forbes  wrote:
>
> On Wed, Jun 16, 2021 at 3:23 PM Matthew Miller  
> wrote:
> >
> > On Wed, Jun 16, 2021 at 02:57:17PM +0200, Vitaly Zaitsev via devel wrote:
> > > >We'll at least gather information about capabilities of Fedora
> > > >users hardware.
> > > Telemetry is evil. It must not be allowed.
> >
> > Well, that's certainly A Position. I don't think it's anything nearly so
> > absolute, though, and depends on what, who, how, why, and a host of other
> > things. And "it can help us answer questions like this for our community" is
> > a pretty non-evil "why".
>
> I think there can be a lot of benefit in anonymized hardware data (not
> mandatory).  It does help answer questions like this, but more
> importantly, it would make a lot of the kernel work a bit easier, or
> at least more focused.   It answers questions like, "should we enable
> these drivers as they are likely to be used?" or "can we disable these
> drivers because no one is using them?". It is also very helpful in
> working out bug priority in drivers.  A lot of people never bother
> filing bugs, and are happy to keep booting a known good kernel since
> we allow parallel installs. If we get a few users chiming in, and
> realize the hardware in question is used by a significant chunk of
> users, it would  tell me that perhaps that should take priority over a
> bug which impacts hardware with considerably fewer users.   Yes, you
> have to be extremely careful about what data you collect, and how that
> data is handled, but if done correctly, there are a lot of benefits.


I agree. I'm curious how many folks have TPMs at all, if they're 1.2
enabled or 2.0; whether the system is Secure Boot capable, enabled or
disabled; whether the firmware is BIOS, UEFI, coreboot.


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

Re: Updating sources file using fedpkg

[Otto Urpelainen]

Ken Dreyer kirjoitti 17.6.2021 klo 19.04:

On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw  wrote:


On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden 
 wrote:



To be clear: I don't want to fiddle with the sources file, hence this
email. However, I would like to at least complete a local mockbuild
before uploading to the lookaside cache. It is my understanding that
new-sources always does this.



That's actually a nit I've been tempted to complain about. If I'm upgrading a 
package to a new version I update the spec file:

rpmdev-bumpspec -n  -c "Update to ." *.spec

And download the new source:

spectool -g *.spec

But then I have to upload the new source with 'fedpkg new-sources' if I don't 
want it to download the old version.


Yeah, the way I deal with this is I zero out the sources file, like ">
sources". Or another alternative that I use sometimes is "sha512sum
--tag", like:

   sha512sum --tag kstart-4.2.tar.gz > sources


Hi Ewould and everybody,

I am a bit confused about this discussion. My fedpkg does not care about 
the 'sources' file or the lookaside cache at all on 'fedpkg mockbuild'. 
It simply looks up the expected filename of downloaded Source, grabs it 
from the local working directory and uses that. So for me this works:


rpmdev-bumpspec -D -n 1.2.3 *.spec
# Update specfile as needed
spectool -g *.spec
fedpkg mockbuild

After that is done, the rpm is available at results_mypackage, I install 
it locally and see that everything works. At that point it is a good 
time do 'fedpkg new-sources'.


This also means that non-packagers actually *can* properly test their 
changes. The maintainer has to do new-sources, commit, push and build 
after merging the pull request, so annoyingly there are those steps to 
remember. But at least the pull request author does not have to submit 
their changes blindly.


A simple test to make sure that it really uses the local download:

$ sed -i 's/^Source.*/Source:https:\/\/example.com\/foo/' *.spec
$ fedpkg mockbuild
SOME_OUTPUT
error: Bad file: SOMEPATH/foo: No such file or directory
$ touch foo
$ fedpkg mockbuild
LOTS_OF_OUTPUT
SOME_ERROR_DUE_TO_EMPTY_SOURCE

When I started, I was having exactly the same trouble, so wrote 
something in the wiki:


https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously

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: Unannounced pcre2-posix SONAME bump, I think

[Stephen J. Turnbull]

Lukas Javorsky writes:

 > I want to apologize one more time.
 > This experience will be written in my mind forever.

Try not to punish yourself.  A good friend once completely broke
XEmacs by bumping the version number in version.el from "20.0-betaXX"
to "20.0".  (It turned out that somebody had left in some debugging
code that checked for "beta" in the version string, and the else code
path disappeared -- the function called had been renamed -- so in most
configurations the program fairly quickly crashed. Yikes!)

This stuff eventually happens to everybody.  Even with CI!

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: x86_64-v2 in Fedora

[Justin Forbes]

On Wed, Jun 16, 2021 at 3:23 PM Matthew Miller  wrote:
>
> On Wed, Jun 16, 2021 at 02:57:17PM +0200, Vitaly Zaitsev via devel wrote:
> > >We'll at least gather information about capabilities of Fedora
> > >users hardware.
> > Telemetry is evil. It must not be allowed.
>
> Well, that's certainly A Position. I don't think it's anything nearly so
> absolute, though, and depends on what, who, how, why, and a host of other
> things. And "it can help us answer questions like this for our community" is
> a pretty non-evil "why".

I think there can be a lot of benefit in anonymized hardware data (not
mandatory).  It does help answer questions like this, but more
importantly, it would make a lot of the kernel work a bit easier, or
at least more focused.   It answers questions like, "should we enable
these drivers as they are likely to be used?" or "can we disable these
drivers because no one is using them?". It is also very helpful in
working out bug priority in drivers.  A lot of people never bother
filing bugs, and are happy to keep booting a known good kernel since
we allow parallel installs. If we get a few users chiming in, and
realize the hardware in question is used by a significant chunk of
users, it would  tell me that perhaps that should take priority over a
bug which impacts hardware with considerably fewer users.   Yes, you
have to be extremely careful about what data you collect, and how that
data is handled, but if done correctly, there are a lot of benefits.

Justin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updating sources file using fedpkg

[Ken Dreyer]

On Thu, Jun 17, 2021 at 8:33 AM Richard Shaw  wrote:
>
> On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden 
>  wrote:
>>
>>
>> To be clear: I don't want to fiddle with the sources file, hence this
>> email. However, I would like to at least complete a local mockbuild
>> before uploading to the lookaside cache. It is my understanding that
>> new-sources always does this.
>
>
> That's actually a nit I've been tempted to complain about. If I'm upgrading a 
> package to a new version I update the spec file:
>
> rpmdev-bumpspec -n  -c "Update to ." *.spec
>
> And download the new source:
>
> spectool -g *.spec
>
> But then I have to upload the new source with 'fedpkg new-sources' if I don't 
> want it to download the old version.

Yeah, the way I deal with this is I zero out the sources file, like ">
sources". Or another alternative that I use sometimes is "sha512sum
--tag", like:

  sha512sum --tag kstart-4.2.tar.gz > sources

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1973319] New: perl-libwww-perl-6.55 is available

[bugzilla]

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

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



Latest upstream release: 6.55
Current version/release in rawhide: 6.54-2.fc35
URL: http://search.cpan.org/dist/libwww-perl/

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


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

Re: Let's retire original glib and gtk+

[Jerry James]

On Thu, Jun 17, 2021 at 9:42 AM Michael Catanzaro  wrote:
> No, you need to drop the dependency on libgnomeui as well. That's been
> obsolete for over a decade now. If we manage to retire gconf2, that
> will go with it.

Okay, that's good to know.  It looks like the gnomeui bindings in
ocaml-lablgtk are optional.  I'll have to check whether anything
sitting on top of ocaml-lablgtk uses those bindings.
-- 
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

Intent to orphan JDK Mission Control

[Alex Macdonald]

Hi everyone,

I am writing to let everyone know that JDK Mission Control (JMC) and
it’s dependencies will be orphaned in Fedora by the end of tomorrow
(June 18th). This encompasses packages owned by both myself (almac)
and jkang, and includes the jmc and jmc-core packages along with the
dependencies we currently maintain.

This includes packages owned by:

almac, 4:
- jakarta-activation
- jakarta-mail
- mvel
- lz4-java

jkang, 8:
- felix-scr
- directory-maven-plugin
- HdrHistogram
- jaf
- jmc
- modules/jmc
- jmc-core
- owasp-java-encoder

I’ll be co-ordinating the orphaning of these packages by the end of
tomorrow. In their place, I have created a couple of copr repositories
containing rpm wrappers for AdoptOpenJDK’s JMC builds, which can be
used to install and use their JMC builds in Fedora. I currently have a
repo for the JMC 8.0.0 release
(https://copr.fedorainfracloud.org/coprs/almac/jmc8/) and a repo for
snapshot builds
(https://copr.fedorainfracloud.org/coprs/almac/jmc-snapshot/).

Regards,

Alex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Thu, 17 Jun 2021 at 11:38, Ron Olson  wrote:
>
> Apologies in advance if this is laughable naïveté, but would a possible 
> solution be to have a different repo for packages compiled against the 
> latest-n-greatest architectures, and packagers could choose to include their 
> packages in there, similar to EPEL?
> Packages in this hypothetical repo could be marked to replace existing ones 
> via %obsoletes or some other mechanism; this would give the user the control 
> to decide if he or she wants to switch to a “higher-performant” version and 
> not have to rely on HW checks or telemetry.
>

The problem mainly comes from
a) making the build system do this work
b) spreading a limited number of build systems to do more work
c) additional time to do composes of these extra repositories and deliverables
d) dealing with the usual packager backlash of 'I don't want to deal
with more bugs so I am exclusive arching my stuff out of that repo'


> Just a thought.
>
> On 15 Jun 2021, at 16:34, Neal Gompa wrote:
>
> > Hey all,
> >
> > Earlier this week, I was helping with processing features for openSUSE
> > Leap 15.4[1] and I discovered that they're planning on introducing
> > x86_64-v2 to openSUSE soon. The reference for this change was that
> > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> > have been considering bumping up to v2 or v3[3][4].
> >
> > Some cursory examination of the new x86_64 sublevels seem to indicate
> > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> > first couple of generations of x86_64 CPUs from Intel and AMD. I
> > personally don't have any computers that don't have support for
> > x86_64-v2 anymore.
> >
> > Does anyone know if anyone is planning to propose this for Fedora
> > anytime soon, either as an addon architecture (like what Arch is
> > doing) or an upgrade of our x86_64 baseline like RHEL is doing?
> >
> > [1]: https://en.opensuse.org/Feature_Planning_15.4
> > [2]: 
> > https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> > [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
> > [4]: 
> > https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC
> >
> > --
> > 真実はいつも一つ！/ 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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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...
time to reboot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Let's retire original glib and gtk+

[Michael Catanzaro]

On Thu, Jun 17 2021 at 09:29:52 AM -0600, Jerry James 
 wrote:

Got it.  None of the packages I listed depend directly on gconf2.
They seem to be on the list due to:

ocaml-lablgtk -> libgnomeui -> GConf2
  |
  ---> libgnome -> GConf2

which means no action is really needed for those packages, right?


No, you need to drop the dependency on libgnomeui as well. That's been 
obsolete for over a decade now. If we manage to retire gconf2, that 
will go with 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: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Michael Catanzaro]

Hi, the script is failing the glib2 build due to an invalid rpath, but 
unless I'm missing something obvious, I think it's valid. Reported:


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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Upcoming soname bumps

[Jerry James]

On Sat, Jun 12, 2021 at 7:14 PM Jerry James  wrote:
> It's nearly time for another round of mathematical software updates,
> including some soname bumps.  I am going to do the following, in this
> approximate order:

I have worked out the issues I was having with Macaulay2 and sagemath,
so I am going to start doing these builds.  The list of packages to be
built has changed slightly since the first email I sent.  If you need
to build any of the packages listed below in the next couple of days,
please use "fedpkg build --target=f35-build-side-42841".

L-function
Macaulay2
Singular
cliquer
clisp
cocoalib
eclib
ffcall
gap-pkg-hap
giac
mathic
mathicgb
memtailor
normaliz
palp
pari
polymake
primecount
pynac
python-cypari2
python-cysignals
python-fpylll
python-jupymake
python-pplpy
python-pysingular
sagemath

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Ron Olson]

Apologies in advance if this is laughable naïveté, but would a possible 
solution be to have a different repo for packages compiled against the 
latest-n-greatest architectures, and packagers could choose to include their 
packages in there, similar to EPEL?
Packages in this hypothetical repo could be marked to replace existing ones via 
%obsoletes or some other mechanism; this would give the user the control to 
decide if he or she wants to switch to a “higher-performant” version and not 
have to rely on HW checks or telemetry.

Just a thought.

On 15 Jun 2021, at 16:34, Neal Gompa wrote:

> Hey all,
>
> Earlier this week, I was helping with processing features for openSUSE
> Leap 15.4[1] and I discovered that they're planning on introducing
> x86_64-v2 to openSUSE soon. The reference for this change was that
> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> have been considering bumping up to v2 or v3[3][4].
>
> Some cursory examination of the new x86_64 sublevels seem to indicate
> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> first couple of generations of x86_64 CPUs from Intel and AMD. I
> personally don't have any computers that don't have support for
> x86_64-v2 anymore.
>
> Does anyone know if anyone is planning to propose this for Fedora
> anytime soon, either as an addon architecture (like what Arch is
> doing) or an upgrade of our x86_64 baseline like RHEL is doing?
>
> [1]: https://en.opensuse.org/Feature_Planning_15.4
> [2]: 
> https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level
> [3]: https://ml.mageia.org/l/arc/dev/2021-02/msg00583.html
> [4]: 
> https://www.phoronix.com/scan.php?page=news_item=Arch-Linux-x86-64-v3-Port-RFC
>
> -- 
> 真実はいつも一つ！/ 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Let's retire original glib and gtk+

[Jerry James]

On Thu, Jun 17, 2021 at 6:58 AM Michael Catanzaro  wrote:
> Hi, nobody proposed removing gtk2. The problem there is gconf2. gtk2
> does not depend on gconf2.
>
> Packages to be retired:
>
>  * glib
>  * gtk+
>  * gconf2

Got it.  None of the packages I listed depend directly on gconf2.
They seem to be on the list due to:

ocaml-lablgtk -> libgnomeui -> GConf2
  |
  ---> libgnome -> GConf2

which means no action is really needed for those packages, right?
-- 
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

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Tom Stellard]

On 6/16/21 10:58 PM, Tom Stellard wrote:

On 6/16/21 2:11 PM, Charalampos Stratakis wrote:

On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard mailto:tstel...@redhat.com>> wrote:

    On 5/7/21 10:48 AM, Ben Cotton wrote:
 > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild 

 >
 > == Summary ==
 > Enable broken RPATH detection
 > 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
 

 > buildroot policy] script by default. This will make the RPM build fail
 > once a broken RPATH was detected within a binary or a shared library
 > file. An opt-out mechanism will be provided as well.
 >
 > == Owner ==
 > * Name: [[User:cstratak| Charalampos Stratakis]]
 > * Email: cstratak AT redhat.com 
 >
 >

    Hi,

    Was there any testing done to determine how much this script would increase
    build times?  I've noticed it takes quite a while on the kernel builds, and
    I'm curious what factors influence how long the script takes.  Is it
    number of binaries, binary sizes, etc?

    -Tom
    ___
    devel mailing list -- devel@lists.fedoraproject.org 

    To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

    Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 



Hey Tom,

Unfortunately no, a potential increase in build time was not taken into account 
at the time of the implementation of this change, as it never came up when 
considering other buildroot policy scripts as well.

Here is the actual script that runs: 
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
 


Could you try and compare two scratch builds? One as is and one by adding 
|%global __brp_check_rpaths %{nil} |at the SPEC?|
|



Instead of doing two scratch builds, I just added:
%global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec file
and did a scratch build[1].

The results on x86_64 were:

real    13m51.517s
user    8m53.216s
sys    7m34.105s

Overall build time for the scratch build was 88m37s, so  that means check-rpaths
accounted for 15% of the build time.  I'm going to do some more tests on some
of the larger packages I maintain (llvm and clang) and see what the impact is.



LLVM was ~2 minutes and clang ~30 seconds, so not that big of an impact.  The
kernel build might just be an outlier.

-Tom


I do think it would be worth trying to profile the script and see if there is
room for optimization.

- Tom

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=70270039




Also adding here for completion that the script will also check for RUNPATH as of rpm 
4.17: https://github.com/rpm-software-management/rpm/pull/1487/files 


--
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
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: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/17/21 4:44 AM, Vitaly Zaitsev via devel wrote:

On 16.06.2021 22:22, Matthew Miller wrote:

Well, that's certainly A Position. I don't think it's anything nearly so
absolute, though, and depends on what, who, how, why, and a host of 
other
things. And "it can help us answer questions like this for our 
community" is

a pretty non-evil "why".


Built-in system level keylogger in one well-known operating system 
also helps its developers?


You are arguing a 'slippery slope' of increasingly intrusive telemetry, 
but we should judge each thing on its own merits. Yes, a keylogger is a 
bad idea--but it does not follow that keeping track of the hardware 
configurations, or logging software failures is also super-bad. If the 
benefits outweigh costs, the tradeoff is worth considering---this is 
true of software just as well as of, say, vaccines.


The problem with 'slippery slope' arguments is that they themselves can 
be abused to say that no change is possible because it could be taken 
too far and lead to abuse.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1973290] New: perl-Email-Sender-1.300036 is available

[bugzilla]

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

Bug ID: 1973290
   Summary: perl-Email-Sender-1.300036 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Email-Sender
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.300036
Current version/release in rawhide: 1.300035-3.fc35
URL: http://search.cpan.org/dist/Email-Sender/

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


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

Re: Can't login with kinit using 2FA

[Simo Sorce]

On Thu, 2021-06-17 at 07:54 -0500, Michael Catanzaro wrote:
> On Thu, Jun 17 2021 at 10:09:26 AM +0100, David Howells 
>  wrote:
> > What if you're not using gnome?
> 
> Then you should install fedora-packager-kerberos? Or fedora-packager, 
> which has a dependency on fedora-packager-kerberos.
> 
> Anyway, at first I thought that gnome-online-accounts needed a 
> dependency on this new fedora-packager-kerberos if special kerberos 
> configuration is required now, but as Kevin explained that dep is only 
> required if using OTP, and OTP doesn't work with gnome-online-accounts 
> anyway, so we're fine. (Well, as fine as we can be when enabling OTP is 
> an irreversible trap that will permanently break your 
> gnome-online-accounts, requiring the creation of a new FAS account to 
> recover.)

I am pretty sure you can ask an admin to fix the FAS account if really
needed.
OTP cannot be reversed by users themselves, but admins can fix it if
really needed.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

[389-devel] Reminder: please review: PR 4807 - Repl Plugin name upgrade did not update global dependency plugin list

[Mark Reynolds]

https://github.com/389ds/389-ds-base/pull/4807

--

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

Re: Updating sources file using fedpkg

[Tom Hughes via devel]

On 17/06/2021 12:57, Ewoud Kohl van Wijngaarden wrote:

After that, I'm looking for a command to update the sources file with 
new checksums so I can run:


fedpkg new-sources 

I could not find such a command so until now I've been using sha512sum 
manually, but there must be a better way :)


Well that will work for a local build but as it won't
upload them to the lookaside it won't work in koji.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Michael Catanzaro]

Hi, nobody proposed removing gtk2. The problem there is gconf2. gtk2 
does not depend on gconf2.


Packages to be retired:

* glib
* gtk+
* gconf2

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Can't login with kinit using 2FA

[Michael Catanzaro]

On Thu, Jun 17 2021 at 10:09:26 AM +0100, David Howells 
 wrote:

What if you're not using gnome?


Then you should install fedora-packager-kerberos? Or fedora-packager, 
which has a dependency on fedora-packager-kerberos.


Anyway, at first I thought that gnome-online-accounts needed a 
dependency on this new fedora-packager-kerberos if special kerberos 
configuration is required now, but as Kevin explained that dep is only 
required if using OTP, and OTP doesn't work with gnome-online-accounts 
anyway, so we're fine. (Well, as fine as we can be when enabling OTP is 
an irreversible trap that will permanently break your 
gnome-online-accounts, requiring the creation of a new FAS account to 
recover.)


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd unit auto-enabling question

[Michael Catanzaro]

On Thu, Jun 17 2021 at 11:52:44 AM +1000, Peter Hutterer 
 wrote:
What I need is manager.service being auto-enabled at install time. 
How do I

get this done?


Hi, you're missing a systemd preset. You generally need FESCo approval 
to add a preset. See:


* https://src.fedoraproject.org/rpms/fedora-release/tree/rawhide, 
specifically 90-default-user.preset
* 
https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/


That said, we already have user session presets for pipewire in 
90-default-user.preset:


enable pipewire.socket
enable pipewire-pulse.socket

This allows Pipewire to be enabled by default, but via socket 
activation only. The lack of a preset for pipewire.service itself seems 
to be intentional.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Vít Ondruch]

Dne 17. 06. 21 v 13:26 Ewoud Kohl van Wijngaarden napsal(a):

On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote:


Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a):

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged 
module)

*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby 
packaging we've also felt a similar pain. Mostly with C extensions 
that were built in the wrong directory. We also added a %check 
section to do a basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not 
clear what should be actually required. With Bundler putting into 
place more conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to 
above? There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52 




And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found 
that there are various bugs in SCL macros that s.o ended up in the 
wrong directories so it wouldn't load.



SCLs or not, this is what always happens for several reasons:

1) While upstream leaves the .so files along side other parts of the 
library, we place the platform independent code in /usr/share while 
placing the platform dependent code into /usr/lib. This is done via 
[1] and it was actually supposed to be default in RubyGems 3, but 
unfortunately with change of upstream maintainers, it got forgotten [2].


2) The paths used during rpmbuild are never on Ruby LOAD_PATH. 
Upstream might add the `lib` directory on the load path, which be 
defaults contains the .so file. But that is not case on Fedora as I 
explained in (1), therefore it is always necessary to add the 
directory with .so file on the LOAD_PATH explicitly.


In theory, we could somehow extend the GEM_PATH to include the RPM 
directories, but upstream test suites are not prepared for this 
scenario, so it would not help.



Really, majority of Ruby packages has fragments like `-Ilib` or 
`-Ilib:test` in the `%check` section. This is grep across the Fedora 
.spec files [3]:


~~~

$ find . -name rubygem\* -exec grep ' \-I' {} \; | wc -l
311

~~~

You just need to add the path to the .so file on the LOAD_PATH 
similarly.


That does leave a feeling that we can't test the correct .so location 
at all in %check.



Right, you can't. You never work with correct locations during rpmbuild. 
The location can be just faked for better or worse. The correct .so 
location can be tested only via integration tests which are run outside 
of rpmbuild environment.


Please note that neither upstreams test the "correct" location, they are 
faking them just to the extend to have their test suite green. That does 
not mean the test suite necessarily follows all conventions.





It feels like we need a phase where the package was installed 
(respecting %files and all). If we can *then* import the library using 
Ruby, then we're content. While it may not be RPMs job, an easy 
verification point that's also usable outside of some fixed 
infrastructure (such as Fedora) would be great. Is there such a thing 
today?



Yes, you can use CI:

https://docs.fedoraproject.org/en-US/ci/

And Fedora actually runs some test by default:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-be0f7a99dd

But there is unfortunately no generic smoke test, which would try to 
load the library from the right location.



Vít

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

Re: x86_64-v2 in Fedora

[Vitaly Zaitsev via devel]

On 17.06.2021 13:43, Stephen John Smoogen wrote:

1. This conversation is not about other operating systems.


It was just an example of telemetry usage.


2. No one is talking about installing keyloggers or similar tools.


Appetite comes with eating. More and more telemetry will be introduced 
over time. We will open Pandora's box.



The problems with this is that we are taking a fairly fuzzy data set
and making it much easier to track individual users in ways seen as
problematic by various laws and regulations.


GDPR is the best thing that has happened to the industry. I love it.


There are useful points in getting telemetry data of this sort. We
could know better that we have a 60% population of v2 systems or that
90% of our arm systems are not system ready but raspberry pi's. That
would allow for engineering to focus its resources on things which the
consumers of the OS need versus what  a 'vocal population' want.


And will also spy on users, violating their freedom.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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-20210617.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 37/198 (x86_64), 18/134 (aarch64)

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

ID: 910378  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/910378
ID: 910379  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/910379
ID: 910380  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/910380
ID: 910436  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/910436
ID: 910437  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/910437
ID: 910439  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/910439
ID: 910448  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/910448
ID: 910451  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/910451
ID: 910452  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/910452
ID: 910453  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/910453
ID: 910454  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/910454
ID: 910455  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/910455
ID: 910456  Test: x86_64 Workstation-live-iso base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/910456
ID: 910457  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/910457
ID: 910463  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/910463
ID: 910464  Test: x86_64 KDE-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/910464
ID: 910465  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/910465
ID: 910466  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/910466
ID: 910467  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/910467
ID: 910475  Test: x86_64 KDE-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/910475
ID: 910476  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/910476
ID: 910479  Test: x86_64 KDE-live-iso base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/910479
ID: 910509  Test: aarch64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/910509
ID: 910577  Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/910577
ID: 910641  Test: x86_64 universal install_mirrorlist_graphical **GATING**
URL: https://openqa.fedoraproject.org/tests/910641
ID: 910678  Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/910678

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

ID: 910395  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/910395
ID: 910396  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/910396
ID: 910409  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/910409
ID: 910416  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/910416
ID: 910417  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/910417
ID: 910418  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/910418
ID: 910426  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/910426
ID: 910430  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/910430
ID: 910433  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/910433
ID: 910478  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/910478
ID: 910522  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/910522
ID: 910532  Test: 

Re: Updating sources file using fedpkg

[Richard Shaw]

On Thu, Jun 17, 2021 at 7:22 AM Ewoud Kohl van Wijngaarden <
ewoud+fed...@kohlvanwijngaarden.nl> wrote:

>
> To be clear: I don't want to fiddle with the sources file, hence this
> email. However, I would like to at least complete a local mockbuild
> before uploading to the lookaside cache. It is my understanding that
> new-sources always does this.
>

That's actually a nit I've been tempted to complain about. If I'm upgrading
a package to a new version I update the spec file:

rpmdev-bumpspec -n  -c "Update to ." *.spec

And download the new source:

spectool -g *.spec

But then I have to upload the new source with 'fedpkg new-sources' if I
don't want it to download the old version.

Perhaps fedpkg could check if the new source is available before
automatically downloading whatever is in the 'sources" file.

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

Re: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Thu, Jun 17, 2021 at 02:11:41PM +0200, Matthias Runge wrote:

On Thu, Jun 17, 2021 at 01:57:03PM +0200, Ewoud Kohl van Wijngaarden wrote:

Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to make
sure I have some clean branch to start working from (clone is just for
completeness):

fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I usually
perform:

spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with new
checksums so I can run:


fedpkg new-sources

This should push the new sources (compressed tarball, whatever), defined
under SOURCE* in the spec file to the cache storing the sources.
For just local builds, this step is not necessary. You could run

fedpkg mockbuild


I found that mockbuild still retrieves what's in sources. I guess a 
possible workaround is to remove the entries from sources and rely on 
spectool.


As a non-packager you also can't run new-source. So perhaps new-sources 
should gain a --no-upload flag? --noop sounds wrong if it does make 
changes and a prep-sources command makes the command listing less 
useful.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

On Thu, Jun 17, 2021 at 02:05:16PM +0200, Fabio Valentini wrote:

On Thu, Jun 17, 2021 at 1:57 PM Ewoud Kohl van Wijngaarden
 wrote:


Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to
make sure I have some clean branch to start working from (clone is just
for completeness):

fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I
usually perform:

spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with
new checksums so I can run:

fedpkg --release f35 mockbuild

I could not find such a command so until now I've been using sha512sum
manually, but there must be a better way :)


I assume you're looking for the "fedpkg new-sources" subcommand.

Using sha512sum alone is not doing everything you need, i.e. it's not
uploading the sources to the dist-git lookaside cache, so not using
"fedpkg new-sources" but only fiddling with the "sources" file
manually would result in broken builds, because the build system would
not find those sources.


To be clear: I don't want to fiddle with the sources file, hence this 
email. However, I would like to at least complete a local mockbuild 
before uploading to the lookaside cache. It is my understanding that 
new-sources always does this.



PS: I would recommend not creating custom branches, not even locally.
If you ever accidentally push such a branch, you might not be able to
delete it, *ever*. Additionally, if you stick to the normal "rawhide",
"f34", "f33" branches, then "fedpkg mockbuild" will infer the
"--release fXX" argument for you instead of you having to specify it
manually.


This feels very odd to me as a new contributor but very familiar with 
git.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Updating sources file using fedpkg

[Matthias Runge]

On Thu, Jun 17, 2021 at 01:57:03PM +0200, Ewoud Kohl van Wijngaarden wrote:
> Hello everyone,
> 
> As someone who just got started, I'm looking for some help.
> 
> I'd like to update packages. I'm used to git, so my typical flow is to make
> sure I have some clean branch to start working from (clone is just for
> completeness):
> 
> fedpkg clone mypackage
> cd mypackage
> git checkout -b rawhide-update-to-new-version
> rpmdev-bumpspec -n 1.2.3 mypackage.spec
> 
> Now comes the part I'm not sure about. To fetch the new sources I usually
> perform:
> 
> spectool -g mypackage.spec
> 
> After that, I'm looking for a command to update the sources file with new
> checksums so I can run:

fedpkg new-sources

This should push the new sources (compressed tarball, whatever), defined
under SOURCE* in the spec file to the cache storing the sources.
For just local builds, this step is not necessary. You could run

fedpkg mockbuild

Hope that helps,
Matthias
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Fedocal] Reminder meeting : Fedora Classroom - RPM Packaging 101

[Ankur Sinha]

Folks, please use this link to join the session. We're starting in a few
minutes.

https://redhat.bluejeans.com/473822117/3398

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


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

Re: Updating sources file using fedpkg

[Fabio Valentini]

On Thu, Jun 17, 2021 at 1:57 PM Ewoud Kohl van Wijngaarden
 wrote:
>
> Hello everyone,
>
> As someone who just got started, I'm looking for some help.
>
> I'd like to update packages. I'm used to git, so my typical flow is to
> make sure I have some clean branch to start working from (clone is just
> for completeness):
>
> fedpkg clone mypackage
> cd mypackage
> git checkout -b rawhide-update-to-new-version
> rpmdev-bumpspec -n 1.2.3 mypackage.spec
>
> Now comes the part I'm not sure about. To fetch the new sources I
> usually perform:
>
> spectool -g mypackage.spec
>
> After that, I'm looking for a command to update the sources file with
> new checksums so I can run:
>
> fedpkg --release f35 mockbuild
>
> I could not find such a command so until now I've been using sha512sum
> manually, but there must be a better way :)

I assume you're looking for the "fedpkg new-sources" subcommand.

Using sha512sum alone is not doing everything you need, i.e. it's not
uploading the sources to the dist-git lookaside cache, so not using
"fedpkg new-sources" but only fiddling with the "sources" file
manually would result in broken builds, because the build system would
not find those sources.

PS: I would recommend not creating custom branches, not even locally.
If you ever accidentally push such a branch, you might not be able to
delete it, *ever*. Additionally, if you stick to the normal "rawhide",
"f34", "f33" branches, then "fedpkg mockbuild" will infer the
"--release fXX" argument for you instead of you having to specify it
manually.

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

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2021-06-18 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/9920/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Fedocal] Reminder meeting : ELN SIG

[sgallagh]

Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2021-06-18 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.net

The meeting will be about:



Source: https://apps.fedoraproject.org/calendar/meeting/9920/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-35-20210617.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

ID: 910778  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/910778
ID: 910779  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/910779
ID: 910794  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/910794
ID: 910797  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/910797
ID: 910806  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/910806

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

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

ID: 910776  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/910776
ID: 910783  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/910783
ID: 910787  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/910787
ID: 910792  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/910792

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) removed since previous compose: systemd-resolved.service
Previous test data: https://openqa.fedoraproject.org/tests/909776#downloads
Current test data: https://openqa.fedoraproject.org/tests/910776#downloads

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

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
1 services(s) removed since previous compose: systemd-resolved.service
Previous test data: https://openqa.fedoraproject.org/tests/909792#downloads
Current test data: https://openqa.fedoraproject.org/tests/910792#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Updating sources file using fedpkg

[Ewoud Kohl van Wijngaarden]

Hello everyone,

As someone who just got started, I'm looking for some help.

I'd like to update packages. I'm used to git, so my typical flow is to 
make sure I have some clean branch to start working from (clone is just 
for completeness):


fedpkg clone mypackage
cd mypackage
git checkout -b rawhide-update-to-new-version
rpmdev-bumpspec -n 1.2.3 mypackage.spec

Now comes the part I'm not sure about. To fetch the new sources I 
usually perform:


spectool -g mypackage.spec

After that, I'm looking for a command to update the sources file with 
new checksums so I can run:


fedpkg --release f35 mockbuild

I could not find such a command so until now I've been using sha512sum 
manually, but there must be a better way :)


Regards,
Ewoud Kohl van Wijngaarden
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Thu, 17 Jun 2021 at 04:45, Vitaly Zaitsev via devel
 wrote:
>
> On 16.06.2021 22:22, Matthew Miller wrote:
> > Well, that's certainly A Position. I don't think it's anything nearly so
> > absolute, though, and depends on what, who, how, why, and a host of other
> > things. And "it can help us answer questions like this for our community" is
> > a pretty non-evil "why".
>
> Built-in system level keylogger in one well-known operating system also
> helps its developers?
>


1. This conversation is not about other operating systems.
2. No one is talking about installing keyloggers or similar tools.

I am saying the following from learning this the hard way. Bringing up
extremes only causes people who are 'neutral' minded that you want to
bring to your side to think the other side is probably more valid. If
you want to talk about the evils of telemetry, stick to the case in
point as limited as it is.

The case being: adding such information to dnf reporting so that
countme or similar centralized logging can survey the Fedora user
audience better.

The problems with this is that we are taking a fairly fuzzy data set
and making it much easier to track individual users in ways seen as
problematic by various laws and regulations. HTTPD logs already have
the ip address, timestamp, requested information, and user-agent of
the system. However it is very hard to say which of 10,000 systems
behind a VPN was a particular request because the information just
says x86_64 versus.. x86_64-v1 (v2 or v3). While not really
pinpointing an individual it helps narrow down a search extremely.

There are useful points in getting telemetry data of this sort. We
could know better that we have a 60% population of v2 systems or that
90% of our arm systems are not system ready but raspberry pi's. That
would allow for engineering to focus its resources on things which the
consumers of the OS need versus what  a 'vocal population' want.

It is also a slippery slope that quickly adds more and more to the
point where 'keyboard stroke telemetry' doesn't look like a big leap
because you already have so many other ways to keep track of people,
but you aren't sure if your new autospell or extra code key features
are working well.


> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.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



-- 
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...
time to reboot.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 02:21:18PM +0200, Vít Ondruch wrote:


Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a):

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby 
packaging we've also felt a similar pain. Mostly with C 
extensions that were built in the wrong directory. We also added 
a %check section to do a basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not 
clear what should be actually required. With Bundler putting into 
place more conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to 
above? There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52


And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found 
that there are various bugs in SCL macros that s.o ended up in the 
wrong directories so it wouldn't load.



SCLs or not, this is what always happens for several reasons:

1) While upstream leaves the .so files along side other parts of the 
library, we place the platform independent code in /usr/share while 
placing the platform dependent code into /usr/lib. This is done via 
[1] and it was actually supposed to be default in RubyGems 3, but 
unfortunately with change of upstream maintainers, it got forgotten 
[2].


2) The paths used during rpmbuild are never on Ruby LOAD_PATH. 
Upstream might add the `lib` directory on the load path, which be 
defaults contains the .so file. But that is not case on Fedora as I 
explained in (1), therefore it is always necessary to add the 
directory with .so file on the LOAD_PATH explicitly.


In theory, we could somehow extend the GEM_PATH to include the RPM 
directories, but upstream test suites are not prepared for this 
scenario, so it would not help.



Really, majority of Ruby packages has fragments like `-Ilib` or 
`-Ilib:test` in the `%check` section. This is grep across the Fedora 
.spec files [3]:


~~~

$ find . -name rubygem\* -exec grep ' \-I' {} \; | wc -l
311

~~~

You just need to add the path to the .so file on the LOAD_PATH similarly.


That does leave a feeling that we can't test the correct .so location at 
all in %check.


It feels like we need a phase where the package was installed 
(respecting %files and all). If we can *then* import the library using 
Ruby, then we're content. While it may not be RPMs job, an easy 
verification point that's also usable outside of some fixed 
infrastructure (such as Fedora) would be great. Is there such a thing 
today?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 09:57:13AM -0700, Kevin Fenzi wrote:

On Wed, Jun 16, 2021 at 03:05:59PM +0200, Ewoud Kohl van Wijngaarden wrote:

Interesting, I had not tried that.

What I used was the clone button. That shows a small dialog with this (as
packager):

   Source Code

 SSH 
 GIT 

As non-packager it does NOT have the SSH URL. So what I initially did was to
manually clone it with git, not fedpkg. Then you have no way to push.


You can stll use 'fedpkg push' in this case and it will setup things and
push. But you have to use fedpkg for one of clone/push.


This wasn't clear to me. I was used to Github where it's more of a 
vanilla git experience.



It looks like fedpkg clone does configure a credential helper which probably
allows you to push via SSH.


It's via https and a token. fedpkg sets up the token for you. After the
initial setup in fedpkg, you can use normal git for everything.


Good to know. Thanks!


It would be my recommendation to add a third "URL" to it and that's the
fedpkg command to clone.


Yeah, might be a reasonable idea indeed. Can you file a issue at
https://pagure.io/pagure/issues/ ?


Filed as https://pagure.io/pagure/issue/5185 which also links back to 
the archive URL for this thread.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Branching in the container namespace

[Tomas Hrcka]

Hello all,

we got a ticket[1] raised with release engineering regarding branching
container namespace in distgit.
We don't branch container namespace as we initially thought we will let
maintainers decide whether they want the repo to be branched or not.
We would like to get some feedback from container developers if there is
any value for you in having containers branched with every Fedora release?

[1] - https://pagure.io/releng/issue/10162

-- 
Tomas Hrcka
role: CPE Team - Senior Software Engineer
fas: humaton
libera: jednorozec
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: 20210617.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210616.n.0
NEW: Fedora-Rawhide-20210617.n.0

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

Size of added packages:  32.25 MiB
Size of dropped packages:1.23 MiB
Size of upgraded packages:   1.81 GiB
Size of downgraded packages: 0 B

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

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

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: aerc-0.5.2-2.fc35
Summary: Email client for your terminal
RPMs:aerc
Size:18.03 MiB

Package: golang-github-emersion-imap-1.1.0-1.fc35
Summary: IMAP library for clients and servers
RPMs:golang-github-emersion-imap-devel
Size:103.49 KiB

Package: golang-github-emersion-imap-idle-0-0.2.20210616git6f42b90.fc35
Summary: IDLE extension for go-imap
RPMs:golang-github-emersion-imap-idle-devel
Size:13.06 KiB

Package: golang-github-emersion-imap-sortthread-1.2.0-1.fc35
Summary: SORT and THREAD extensions for go-imap
RPMs:golang-github-emersion-imap-sortthread-devel
Size:16.64 KiB

Package: golang-github-emersion-maildir-0.2.0-1.20210616gitced1977.fc35
Summary: Maildir library for Go
RPMs:golang-github-emersion-maildir-devel
Size:15.94 KiB

Package: golang-github-emersion-message-0.15.0-1.fc35
Summary: Streaming Go library for the Internet Message Format and mail messages
RPMs:golang-github-emersion-message-devel
Size:50.01 KiB

Package: golang-github-emersion-pgpmail-0.1.0-1.fc35
Summary: PGP-encrypted email library for Go
RPMs:golang-github-emersion-pgpmail-devel
Size:22.52 KiB

Package: golang-github-emersion-smtp-0.15.0-1.fc35
Summary: SMTP client & server library written in Go
RPMs:golang-github-emersion-smtp golang-github-emersion-smtp-devel
Size:6.81 MiB

Package: kiln-0.2.0-1.fc35
Summary: Simple static site generator.
RPMs:kiln
Size:6.62 MiB

Package: pg_repack-1.4.6-3.module_f35+12232+461c06ff
Summary: Reorganize tables in PostgreSQL databases without any locks
RPMs:pg_repack
Size:583.78 KiB


= DROPPED PACKAGES =
Package: man-pages-cs-0.18.20090209-31.fc34
Summary: Czech man pages from the Linux Documentation Project
RPMs:man-pages-cs
Size:586.44 KiB

Package: mingw-SDL-1.2.15-18.fc34
Summary: MinGW Windows port of SDL cross-platform multimedia library
RPMs:mingw32-SDL mingw64-SDL
Size:568.51 KiB

Package: rust-procfs0.8-0.8.1-2.fc34
Summary: Interface to the linux procfs pseudo-filesystem
RPMs:rust-procfs0.8+backtrace-devel rust-procfs0.8+chrono-devel 
rust-procfs0.8+default-devel rust-procfs0.8-devel
Size:108.28 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.32.0-1.fc35
Old package:  NetworkManager-1:1.32.0-0.4.fc35
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 28.84 MiB
Size change:  -111.89 KiB
Changelog:
  * Wed Jun 16 2021 Thomas Haller  - 1:1.32.0-1
  - update to 1.32.0 release
  - default to "iptables" firewall-backend due to SELinux bug rh #1972911.


Package:  awscli-1.19.96-1.fc35
Old package:  awscli-1.19.95-1.fc35
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.05 MiB
Size change:  31 B
Changelog:
  * Wed Jun 16 2021 Gwyn Ciesla  - 1.19.96-1
  - 1.19.96


Package:  bst-external-0.23.1-1.fc35
Old package:  bst-external-0.21.0-4.fc35
Summary:  Additional BuildStream plugins
RPMs: bst-external
Size: 96.57 KiB
Size change:  2.53 KiB
Changelog:
  * Wed Jun 16 2021 Artem Polishchuk  - 0.23.1-1
  - build(update): 0.23.1


Package:  ca-certificates-2021.2.50-2.fc35
Old package:  ca-certificates-2021.2.48-2.fc35
Summary:  The Mozilla CA root certificate bundle
RPMs: ca-certificates
Size: 352.12 KiB
Size change:  -56.07 KiB
Changelog:
  * Wed Jun 16 2021 Bob Relyea  - 2021.2.50-2
  - Update to CKBI 2.50 from NSS 3.67
  -Removing:
  - # Certificate "Trustis FPS Root CA"
  - # Certificate "GlobalSign Code Signing Root R45"
  - # Certificate "GlobalSign Code Signing Root E45"
  - # Certificate "Halcom Root Certificate Authority"
  - # Certificate "Symantec Class 3 Public Primary Certification Authority 
- G6"
  - # Certificate "GLOBALTR

and Gconf2 ? Re: Let's retire original glib and gtk+

[Sérgio Basto]

On Wed, 2021-06-16 at 18:42 -0600, Jerry James wrote:
> Sorry, didn't see this when it first came through.
> 
> On Mon, May 31, 2021 at 4:18 AM Sérgio Basto  wrote:
> > I propose, for F36, the retire of Gconf2 (1)
> > 
> > dnf repoquery --disablerepo='*' \
> > --enablerepo={rpmfusion-{non,}free-,}rawhide --recursive \
> > --whatrequires "libgconf*" --qf "%{repoid} %{sourcerpm}"  -q
> 
> [snip]
> 
> > rawhide frama-c-22.0-10.fc35.src.rpm
> > rawhide ocaml-cairo-0.6.1-11.fc35.src.rpm
> > rawhide ocaml-camlimages-4.2.5-28.fc35.src.rpm
> > rawhide ocaml-dose3-5.0.1-32.20200502git24316fe.fc35.src.rpm
> > rawhide ocaml-lablgtk-2.18.11-6.fc35.src.rpm
> > rawhide ocaml-ocamlgraph-1.8.8-25.fc35.src.rpm
> > rawhide ocaml-ocamlnet-4.1.8-4.fc35.src.rpm
> > rawhide ocaml-xmlrpc-light-0.6.1-61.fc35.src.rpm
> 
> These packages are very useful, and have active upstreams.  They are
> all in the process of switching from gtk2 to gtk3, but haven't
> completed the transition yet.  The ocaml-cairo package, for example,
> is an OCaml interface to cairo.  It has a cairo-gtk subpackage for
> rendering cairo on a gtk2 canvas, and a cairo-pango subpackage for
> using pango with cairo in OCaml programs.  The ocaml-lablgtk3 package,
> which is an OCaml interface to gtk3, depends on the non-gtk2 parts of
> ocaml-cairo.
> 
> We might be able to excise the gtk2 parts of these packages, but it
> would not be simple, nor something that could be done overnight.  A
> little more time for the upstreams to make more progress would be
> greatly appreciated.

In this point, I think, is about replace Gconf2 by gsettings (1)


(1)
https://github.com/rawstudio/rawstudio/issues/61



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

[Bug 1972889] perl-Prima-1.62 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 136834




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

[Bug 1972385] perl-POE-Component-IRC-6.93 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-e69f1c2e75 has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-e69f1c2e75


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

[Bug 1972385] perl-POE-Component-IRC-6.93 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-777c04ebc1 has been submitted as an update to Fedora 34.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-777c04ebc1


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

[Bug 1972889] perl-Prima-1.62 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.62-1.fc35



--- Comment #2 from Petr Pisar  ---
A few, always the same, tests fail on non-Intel platforms:

#   Failed test 'float Sinc'
#   at t/Image/Stretch.t line 83.
# accumulated errors: 0 0 10 12
#   Failed test 'double Sinc'
#   at t/Image/Stretch.t line 83.
# accumulated errors: 0 0 10 12
#   Failed test 'complex Sinc'
#   at t/Image/Stretch.t line 83.
# accumulated errors: 0 0 10 12
#   Failed test 'dcomplex Sinc'
#   at t/Image/Stretch.t line 83.
# accumulated errors: 0 0 10 12
# Looks like you failed 4 tests of 168.
t/Image/Stretch.t ... 
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/168 subtests


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

Fedora-Cloud-34-20210617.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/8 (x86_64)

Old failures (same test failed in Fedora-Cloud-34-20210616.0):

ID: 910284  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/910284
ID: 910285  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/910285
ID: 910286  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/910286
ID: 910287  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/910287
ID: 910288  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/910288
ID: 910289  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/910289
ID: 910290  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/910290
ID: 910291  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/910291

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210616.0):

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

Passed openQA tests: 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: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Björn 'besser82' Esser]

Am Donnerstag, dem 17.06.2021 um 08:55 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 16.06.2021 um 21:18 +0200 schrieb Björn 'besser82'
> Esser:
> > Am Mittwoch, dem 16.06.2021 um 19:53 +0200 schrieb Jiri Kucera:
> > > Adding devel-list for a broader audience. My side tag will expire
> > > for
> > > a couple of days. Can some proven packager add me please to gdal,
> > > OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds
> > > for
> > > libgta?
> > > 
> > > Cheers,
> > > Jiri
> > > 
> > > 
> > > -- Forwarded message -
> > > From: Jiri Kucera 
> > > Date: Fri, Jun 11, 2021 at 10:29 AM
> > > Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
> > > To: , ,
> > > 
> > > 
> > > 
> > > Hi Sandro, Ralph, and Orion,
> > > 
> > > I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora
> > > 34,
> > > which bumps libgta.so.0 to libgta.so.1. Please,
> > > rebuild your packages against this sidetag:
> > > * gdal need to be probably rebased to 3.3.0 (I did a scratch
> > > build[2]
> > > against the sidetag from f34 branch and its succeeded, but the
> > > scratch
> > > build[3] of OpenSceneGraph failed[4])
> > > * after gdal OpenSceneGraph and vtk need to be rebuilt
> > > * last, opencv need to be rebuilt (I do this by myself)
> > > 
> > > Regards,
> > > Jiri
> > > 
> > > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
> > > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
> > > [4] Excerpt from the mock_output.log:
> > 
> > 
> > I'll take care of the needed rebuilds in your sidetag as a
> > provenpackager, and will give you a short notice, as soon as you can
> > start rebuilding opencv.
> 
> 
> gdal and OpenSceneGraph have been seccessfully rebuilt in the sidetag.
> vtk is still building.


vtk has finished successfully, too.


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

[Bug 1972889] perl-Prima-1.62 is available

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
New features and it renames few modules. Suitable only for Rawhide.


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

Re: Can't login with kinit using 2FA

[David Howells]

Michael Catanzaro  wrote:

> Whatever is needed for Fedora kerberos to work needs to be a dependency of
> gnome-online-accounts

What if you're not using gnome?

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

Re: x86_64-v2 in Fedora

[Vitaly Zaitsev via devel]

On 16.06.2021 22:22, Matthew Miller wrote:

Well, that's certainly A Position. I don't think it's anything nearly so
absolute, though, and depends on what, who, how, why, and a host of other
things. And "it can help us answer questions like this for our community" is
a pretty non-evil "why".


Built-in system level keylogger in one well-known operating system also 
helps its developers?


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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-Cloud-33-20210617.0 compose check report

[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-20210616.0):

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

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

[Bug 1972889] perl-Prima-1.62 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|ppi...@redhat.com   |
   Doc Type|--- |If docs needed, set a value




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

[389-devel] 389 DS nightly 2021-06-17 - 94% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2021/06/17/report-389-ds-base-2.0.5-20210617gita8703f010.fc34.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Björn 'besser82' Esser]

Am Mittwoch, dem 16.06.2021 um 21:18 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 16.06.2021 um 19:53 +0200 schrieb Jiri Kucera:
> > Adding devel-list for a broader audience. My side tag will expire
> > for
> > a couple of days. Can some proven packager add me please to gdal,
> > OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for
> > libgta?
> > 
> > Cheers,
> > Jiri
> > 
> > 
> > -- Forwarded message -
> > From: Jiri Kucera 
> > Date: Fri, Jun 11, 2021 at 10:29 AM
> > Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
> > To: , ,
> > 
> > 
> > 
> > Hi Sandro, Ralph, and Orion,
> > 
> > I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora 34,
> > which bumps libgta.so.0 to libgta.so.1. Please,
> > rebuild your packages against this sidetag:
> > * gdal need to be probably rebased to 3.3.0 (I did a scratch
> > build[2]
> > against the sidetag from f34 branch and its succeeded, but the
> > scratch
> > build[3] of OpenSceneGraph failed[4])
> > * after gdal OpenSceneGraph and vtk need to be rebuilt
> > * last, opencv need to be rebuilt (I do this by myself)
> > 
> > Regards,
> > Jiri
> > 
> > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
> > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
> > [4] Excerpt from the mock_output.log:
> 
> 
> I'll take care of the needed rebuilds in your sidetag as a
> provenpackager, and will give you a short notice, as soon as you can
> start rebuilding opencv.


gdal and OpenSceneGraph have been seccessfully rebuilt in the sidetag. 
vtk is still building.


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: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 16, 2021 at 10:58:13PM -0700, Tom Stellard wrote:
> On 6/16/21 2:11 PM, Charalampos Stratakis wrote:
> >On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard  >> wrote:
> >
> >On 5/7/21 10:48 AM, Ben Cotton wrote:
> > > 
> > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild 
> > 
> > >
> > > == Summary ==
> > > Enable broken RPATH detection
> > > 
> > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> >  
> > 
> > > buildroot policy] script by default. This will make the RPM build fail
> > > once a broken RPATH was detected within a binary or a shared library
> > > file. An opt-out mechanism will be provided as well.
> > >
> > > == Owner ==
> > > * Name: [[User:cstratak| Charalampos Stratakis]]
> > > * Email: cstratak AT redhat.com 
> > >
> > >
> >
> >Hi,
> >
> >Was there any testing done to determine how much this script would 
> > increase
> >build times?  I've noticed it takes quite a while on the kernel builds, 
> > and
> >I'm curious what factors influence how long the script takes.  Is it
> >number of binaries, binary sizes, etc?
> >
> >-Tom
> >___
> >devel mailing list -- devel@lists.fedoraproject.org 
> > 
> >To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> > 
> >Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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 
> > 
> >
> >
> >Hey Tom,
> >
> >Unfortunately no, a potential increase in build time was not taken into 
> >account at the time of the implementation of this change, as it never came 
> >up when considering other buildroot policy scripts as well.
> >
> >Here is the actual script that runs: 
> >https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
> > 
> >
> >
> >Could you try and compare two scratch builds? One as is and one by adding 
> >|%global __brp_check_rpaths %{nil} |at the SPEC?|
> >|
> >
> 
> Instead of doing two scratch builds, I just added:
> %global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec file
> and did a scratch build[1].
> 
> The results on x86_64 were:
> 
> real  13m51.517s
> user  8m53.216s
> sys   7m34.105s

An fairly easy fix might be to stuff 'parallel --group' there, to at
least process different files concurrently.

> Overall build time for the scratch build was 88m37s, so  that means 
> check-rpaths
> accounted for 15% of the build time.  I'm going to do some more tests on some
> of the larger packages I maintain (llvm and clang) and see what the impact is.
> 
> I do think it would be worth trying to profile the script and see if there is
> room for optimization.
> 
> - Tom
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=70270039
> 
> 
> 
> >Also adding here for completion that the script will also check for RUNPATH 
> >as of rpm 4.17: 
> >https://github.com/rpm-software-management/rpm/pull/1487/files 
> >

From a quick look, that looks like it'll double the time.

What about:
-check_rpath $i "RPATH"
-check_rpath $i "RUNPATH"
+check_rpath $i "RPATH|RUNPATH"

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