Re: Heads-up: ODE soname bump

2022-07-24 Thread Robert-André Mauchin

On 7/24/22 16:40, Hedayat Vatankhah wrote:

Hi all,

As part of building ODE 0.16, ode's soname has been bumped from 
libode.so.4/libode-double.so.4  to libode.so.8/libode-double.so.8.


This package is now built as part of Fedora 37 Mass Rebuild, so we expect all dependent 
packages to be automatically built again during this process.


We do not expect to see compilation failures because of this update.


Regards,

Hedayat



Use (Close: rhbz#1438205) instead of (rhbz#1438205)
or Closes: rhbz#1438205, Fix: rhbz#1438205, Fixes: rhbz#1438205
to automatically close the related nug

On 7/24/22 19:14, Maxwell G via devel wrote:
> On 22/07/24 06:05PM, Kalev Lember wrote:
>> If ODE 0.16 was only built as part of the mass rebuild and wasn't
>> available in the buildroot during the mass rebuild (and I don't think
>> it was), then all the other packages that depend on it were still
>> built against the older ODE 0.14 version as part of the mass rebuild.
>> Once the mass rebuild is merged back into f37 then all other packages
>> that depend on ODE are going to have broken dependencies.
>
> That indeed appears to be the case. The f37-rebuild build target[1]
> builds against f37-build but tags completed builds into f37-rebuild.
> ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild.
>
> [1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581
> [2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899
>
> Also, looking at ompl, one of ode's dependents, you can see that it was
> rebuilt against the old version of ode:
>
>> DEBUG util.py:445:   ode-devel  x86_64  0.14-15.fc36 
   build   66 k

>
> -- 
https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log and
> 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925

>
> In order to fix this, a provenpackager will need to build all of the
> dependents in a sidetag like normal. Preferably, this could happen
> before the mass rebuild tag is merged back into f37. I am a bit busy
> today, but I suppose I could do this later if nobody beats me to it.
>

It is done: https://bodhi.fedoraproject.org/updates/FEDORA-2022-26df2fedba

Had to fixup freewrl though, the java thing on i686.

Best regards,

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


Re: repoquery-fu (was Re: Retiring the pcre package from Fedora)

2022-07-24 Thread Fabio Valentini
On Sat, Jul 23, 2022 at 2:01 PM Neal Gompa  wrote:
>
> On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini  wrote:
> >
> > - the sets of dependent packages overlap between concurrently created side 
> > tags
>
> So what? If we're not tracking rebuilds in Git anymore, this is no
> longer a serious problem. The build system knows every time a commit
> is requested and increments the counter accordingly.

So what? This is definitely a problem that would need to be solved somehow.
Assume a package X that depends on both libfoo and libbar, and there's
concurrent soname bumps for those two libraries.
Then package X gets rebuilt in side-tag M for the libfoo soname bump,
and rebuilt in side-tag N for the libbar soname bump,
but it would need to get rebuilt against *both* in order to result in
a working package.
The only way to solve this would be to serialize builds for side tags
instead of running them in parallel, or to run builds multiple times,
until installability tests etc. succeed.

> The fundamental difference between your thought and mine is that you
> want it to be perfect. I want it to be good enough to eliminate the
> *majority* of provenpackager grunt work and stop punishing people so
> hard for bringing useful software library packages into the
> distribution.
>
> Failure is okay. Human intervention is fine. Design a process that
> handles 80% and make it gracefully fail for the remaining 20%.
>
> You seem to think it's unworkable, but I work in a Linux distribution
> that operates this way and has for twenty years! I *know* it works.
> It's not perfect, and there's certainly going to be some human
> intervention and probably some configuration stuff to resolve things
> machines can't figure out on their own (like build cycles and things
> of that nature), but it is absolutely possible to do this and make the
> lives of the majority of packagers easier.

I'm not saying it's impossible, but I think in our current state, we
wouldn't end up with "80% are fine and 20% would require manual
intervention", but rather the other way round. And at that point, any
automated mechanism starts to be rather useless - which is why I'd
like to improve the underlying problems *first* and then implement
automation that *actually works in the majority of cases* later.

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


Re: empty reply from server error

2022-07-24 Thread Adam Williamson
On Tue, 2022-07-19 at 16:47 +0200, Petr Pisar wrote:
> V Tue, Jul 19, 2022 at 01:47:12PM +, Globe Trotter via devel napsal(a):
> > However, I get the following error in the build log (of koji):
> > 
> > 
> > 
> > checking whether the C compiler works... no
> > configure: error: in `/builddir/build/BUILD/osmo-0.4.4':
> > configure: error: C compiler cannot create executables
> > See `config.log' for more details
> > 
> > 
> > Where is the config.log? I only have 
> > 
> In the working directory on a Koji builder. Cleaned up and deleted.
> 
> Ammend your osmo.spec to print config.log content if ./configure command
> fails.  The cause will either be missing BuildRequires: gcc, or the build
> scripts is too creative with compiler or linker flags and produces
> a combination which does not work. Or somebody broke gcc or annobin or other
> vital part of a tool chain.

Another option if the necessary stuff isn't logged to the Koji build
logs is to run a build in mock locally. When a mock build fails the
buildroot is not cleaned up, so you can look at it, either under
wherever your mock home is (/var/lib/mock or /home/mockbase probably)
or with mock -r (whatever) -shell to get a shell inside the mock
environment.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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


[Bug 2029995] perl.req: use keywords not found on BEGIN { lines

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2029995



--- Comment #4 from Charles R. Anderson  ---
Created attachment 1899053
  --> https://bugzilla.redhat.com/attachment.cgi?id=1899053=edit
proposed fix including test cases


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029995
___
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 2110225] New: perl-Devel-CheckOS-1.94 is available

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2110225

Bug ID: 2110225
   Summary: perl-Devel-CheckOS-1.94 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-CheckOS
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.94
Upstream release that is considered latest: 1.94
Current version/release in rawhide: 1.93-2.fc37
URL: http://search.cpan.org/dist/Devel-CheckOS/

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


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Devel-CheckOS


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2110225
___
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: Heads-up: ODE soname bump

2022-07-24 Thread Maxwell G via devel
On 22/07/24 06:05PM, Kalev Lember wrote:
> If ODE 0.16 was only built as part of the mass rebuild and wasn't
> available in the buildroot during the mass rebuild (and I don't think
> it was), then all the other packages that depend on it were still
> built against the older ODE 0.14 version as part of the mass rebuild.
> Once the mass rebuild is merged back into f37 then all other packages
> that depend on ODE are going to have broken dependencies.

That indeed appears to be the case. The f37-rebuild build target[1]
builds against f37-build but tags completed builds into f37-rebuild.
ode-0.16.2-2.fc37[2] is only tagged into f37-rebuild.

[1]: https://koji.fedoraproject.org/koji/buildtargetinfo?targetID=24581
[2]: https://koji.fedoraproject.org/koji/buildinfo?buildID=2016899

Also, looking at ompl, one of ode's dependents, you can see that it was
rebuilt against the old version of ode:

> DEBUG util.py:445:   ode-devel  x86_64  
> 0.14-15.fc36   build   66 k

-- 
https://kojipkgs.fedoraproject.org//packages/ompl/1.5.0/11.fc37/data/logs/x86_64/root.log
 and
https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925https://koji.fedoraproject.org/koji/buildinfo?buildID=2016925

In order to fix this, a provenpackager will need to build all of the
dependents in a sidetag like normal. Preferably, this could happen
before the mass rebuild tag is merged back into f37. I am a bit busy
today, but I suppose I could do this later if nobody beats me to it.

-- 
Thanks,

Maxwell G (@gotmax23)
Pronouns: He/Him/His


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


[Bug 2029995] perl.req: use keywords not found on BEGIN { lines

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2029995

Charles R. Anderson  changed:

   What|Removed |Added

Summary|perl-base Needs to be a |perl.req: use keywords not
   |Required Dependency |found on BEGIN { lines




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029995
___
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: Heads-up: ODE soname bump

2022-07-24 Thread Kalev Lember
On Sun, Jul 24, 2022 at 4:41 PM Hedayat Vatankhah 
wrote:

> Hi all,
>
> As part of building ODE 0.16, ode's soname has been bumped from
> libode.so.4/libode-double.so.4  to libode.so.8/libode-double.so.8.
>
> This package is now built as part of Fedora 37 Mass Rebuild, so we expect
> all dependent packages to be automatically built again during this process.
>
> We do not expect to see compilation failures because of this update.
>

Hi Hedayat,

No, this is not how mass rebuilds work. If ODE 0.16 was only built as part
of the mass rebuild and wasn't available in the buildroot during the mass
rebuild (and I don't think it was), then all the other packages that depend
on it were still built against the older ODE 0.14 version as part of the
mass rebuild. Once the mass rebuild is merged back into f37 then all other
packages that depend on ODE are going to have broken dependencies.

-- 
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 2029995] perl-base Needs to be a Required Dependency

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2029995

Charles R. Anderson  changed:

   What|Removed |Added

  Component|perl|perl-generators



--- Comment #3 from Charles R. Anderson  ---
This is actually a bug in the perl-generators perl.req script:

>/usr/lib/rpm/perl.req 
>~/src/fedora/git/perl/perl-5.36.0/cpan/Module-Loaded/lib/Module/Loaded.pm
perl(Carp)
perl(strict)
perl(vars)

If you add a newline before the 'use base' line in Loaded.pm, it works
correctly:

>diff -ub Loaded.pm~ Loaded.pm
--- Loaded.pm~  2022-07-24 11:46:54.711678673 -0400
+++ Loaded.pm   2022-07-24 11:59:00.149220316 -0400
@@ -3,7 +3,8 @@
 use strict;
 use Carp qw[carp];

-BEGIN { use base 'Exporter';
+BEGIN {
+use base 'Exporter';
 use vars qw[@EXPORT $VERSION];

 $VERSION = '0.08';


>/usr/lib/rpm/perl.req Loaded.pm
perl(Carp)
perl(Exporter)
perl(base)
perl(strict)
perl(vars)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029995
___
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: Retiring the pcre package from Fedora

2022-07-24 Thread Kalev Lember
On Sun, Jul 24, 2022 at 4:45 PM Mamoru TASAKA 
wrote:

> Kalev Lember wrote on 2022/07/24 22:42:
> > glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs
> to
> > be updated for that now so that it BuildRequires pcre2-static instead?
> >
> >
> https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide
> >
>
> Ah... maybe due to this?
>
> A.
> On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby
> language) sees
> test failure with regards to "g_regex_match_all" - note that this is s390x
> only.
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927
>
> B.
> I got lxrandr behavior regression on rawhide:
> https://bugzilla.redhat.com/show_bug.cgi?id=2109187
>
> - what lxrandr does here is lxrander gets the result of "xrandr" and
>passes it to "g_regex_match".
>On F-36 actually "g_regex_match" matches but (while I have not tried
> yet)
>what bug reporter says must be that "g_regex_match" now fails with
>rawhide glib2 (this is happening on x86_64).
>
> I will recheck this tomorrow.
>

Those both sound a lot like regressions in g_regex_match() to me. If you
have time, any chance you could create smaller reproducers and file issues
for these upstream at https://gitlab.gnome.org/GNOME/glib ?

-- 
Thanks,
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 2029995] perl-base Needs to be a Required Dependency

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2029995



--- Comment #2 from Charles R. Anderson  ---
More importantly, perl's subpackage perl-Module-Loaded is missing the
"Requires: perl(base)":

>rpm -q --requires perl-Module-Loaded | grep base
[no output]


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029995
___
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 2029995] perl-base Needs to be a Required Dependency

2022-07-24 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2029995

Charles R. Anderson  changed:

   What|Removed |Added

 CC||caillon+fedoraproject@gmail
   ||.com, iarn...@gmail.com,
   ||jples...@redhat.com,
   ||ka...@ucw.cz,
   ||mmasl...@redhat.com,
   ||mspa...@redhat.com,
   ||perl-devel@lists.fedoraproj
   ||ect.org, ppi...@redhat.com,
   ||psab...@redhat.com,
   ||rhug...@redhat.com,
   ||sandm...@redhat.com,
   ||spo...@gmail.com
  Component|kpcli   |perl
   Assignee|mkre...@gmail.com   |jples...@redhat.com
   Doc Type|--- |If docs needed, set a value



--- Comment #1 from Charles R. Anderson  ---
Reassigned to perl:

"BEGIN failed--compilation aborted at /usr/share/perl5/Module/Loaded.pm line
6."

"package Module::Loaded;

use strict;
use Carp qw[carp];

BEGIN { use base 'Exporter';"

>rpm -qf --qf='%{sourcerpm}\n' /usr/share/perl5/Module/Loaded.pm
perl-5.34.1-486.fc35.src.rpm

>rpm -q --requires perl | grep base
[no output]


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2029995
___
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: Retiring the pcre package from Fedora

2022-07-24 Thread Mamoru TASAKA

Kalev Lember wrote on 2022/07/24 22:42:

On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  wrote:





glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs to
be updated for that now so that it BuildRequires pcre2-static instead?

https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide



Ah... maybe due to this?

A.
On mass-rebuid, rubygem-glib2 (which is a wrapper to glib2 for ruby language) 
sees
test failure with regards to "g_regex_match_all" - note that this is s390x only.

https://koji.fedoraproject.org/koji/taskinfo?taskID=89955927

B.
I got lxrandr behavior regression on rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=2109187

- what lxrandr does here is lxrander gets the result of "xrandr" and
  passes it to "g_regex_match".
  On F-36 actually "g_regex_match" matches but (while I have not tried yet)
  what bug reporter says must be that "g_regex_match" now fails with
  rawhide glib2 (this is happening on x86_64).

I will recheck this tomorrow.

Regards,
Mamoru

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


Heads-up: ODE soname bump

2022-07-24 Thread Hedayat Vatankhah

Hi all,

As part of building ODE 0.16, ode's soname has been bumped from 
libode.so.4/libode-double.so.4  to libode.so.8/libode-double.so.8.


This package is now built as part of Fedora 37 Mass Rebuild, so we 
expect all dependent packages to be automatically built again during 
this process.


We do not expect to see compilation failures because of this update.


Regards,

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

2022-07-24 Thread Kalev Lember
On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini  wrote:

>
>
> Il sab 23 lug 2022, 19:12 Adam Williamson  ha
> scritto:
>
>> This of course begs a question: did qemu also have a non-static pcre
>> requirement at the time? But it seems not:
>>
>> [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
>> BuildRequires: glibc-static pcre-static glib2-static zlib-static
>>
>> so, I'm not sure why Daniel concluded this needs a BuildRequires on
>> pcre-static, but the obvious thing to do would be to ask him, I guess.
>>
>
> I think it could have been a missing requires of glib2-static, because
> glib does use PCRE and therefore has it in the linker flags for a static
> build. I will check next time I am at a computer.
>

glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs to
be updated for that now so that it BuildRequires pcre2-static instead?

https://src.fedoraproject.org/rpms/glib2/c/34b203d5499b579c68b4f923a29fd417efdd9637?branch=rawhide

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

2022-07-24 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20220723.n.0
NEW: Fedora-Rawhide-20220724.n.0

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

Size of added packages:  1010.54 KiB
Size of dropped packages:0 B
Size of upgraded packages:   4.12 GiB
Size of downgraded packages: 27.56 KiB

Size change of upgraded packages:   -8.40 MiB
Size change of downgraded packages: -2.92 KiB

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20220724.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-syntect4-4.6.0-1.fc37
Summary: Library for high quality syntax highlighting and code intelligence
RPMs:rust-syntect4+assets-devel rust-syntect4+bincode-devel 
rust-syntect4+default-devel rust-syntect4+default-fancy-devel 
rust-syntect4+default-onig-devel rust-syntect4+dump-create-devel 
rust-syntect4+dump-create-rs-devel rust-syntect4+dump-load-devel 
rust-syntect4+dump-load-rs-devel rust-syntect4+fancy-regex-devel 
rust-syntect4+flate2-devel rust-syntect4+fnv-devel rust-syntect4+html-devel 
rust-syntect4+metadata-devel rust-syntect4+onig-devel 
rust-syntect4+parsing-devel rust-syntect4+regex-fancy-devel 
rust-syntect4+regex-onig-devel rust-syntect4+regex-syntax-devel 
rust-syntect4+yaml-load-devel rust-syntect4+yaml-rust-devel rust-syntect4-devel
Size:870.42 KiB

Package: rust-sysinfo0.19-0.19.2-1.fc37
Summary: Library to get system information
RPMs:rust-sysinfo0.19+c-interface-devel rust-sysinfo0.19+debug-devel 
rust-sysinfo0.19+default-devel rust-sysinfo0.19+multithread-devel 
rust-sysinfo0.19+rayon-devel rust-sysinfo0.19-devel
Size:140.12 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  atomic-reactor-3.13.0-3.fc37
Old package:  atomic-reactor-3.12.1-1.fc37
Summary:  Improved builder for Docker images
RPMs: atomic-reactor python3-atomic-reactor python3-atomic-reactor-koji 
python3-atomic-reactor-metadata python3-atomic-reactor-rebuilds
Size: 1.14 MiB
Size change:  179.76 KiB
Changelog:
  * Sun May 29 2022 Kevin Fenzi  - 3.13.0-1
  - Update to 3.13.0. Fixes rhbz#2088603

  * Mon Jun 13 2022 Python Maint  - 3.13.0-2
  - Rebuilt for Python 3.11

  * Wed Jul 20 2022 Fedora Release Engineering  - 
3.13.0-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild


Package:  bcm283x-firmware-20220718-1.c818048.fc37
Old package:  bcm283x-firmware-20220527-2.f145afc.fc37
Summary:  Firmware for the Broadcom bcm283x/bcm2711 used in the Raspberry Pi
RPMs: bcm2711-firmware bcm2835-firmware bcm283x-firmware 
bcm283x-overlays
Size: 6.94 MiB
Size change:  49.63 KiB
Changelog:
  * Mon Jul 18 2022 Peter Robinson  - 
20220718-1.c818048
  - Update to latest firmware


Package:  bear-3.0.20-1.fc37
Old package:  bear-3.0.19-3.fc37
Summary:  Tool that generates a compilation database for clang tooling
RPMs: bear
Size: 2.52 MiB
Size change:  19.49 KiB
Changelog:
  * Wed Jul 20 2022 Fedora Release Engineering  
3.0.19-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Sat Jul 23 2022 Dan ??erm??k  3.0.20-1
  - New upstream release 3.0.20
  - drop workaround for fmt 9.0, patch has been merged upstream


Package:  coeurl-0.2.1-1.fc37
Old package:  coeurl-0.2.0-3.fc37
Summary:  Simple async wrapper around CURL for C++
RPMs: coeurl coeurl-devel
Size: 480.17 KiB
Size change:  3.46 KiB
Changelog:
  * Wed Jul 20 2022 Fedora Release Engineering  - 
0.2.0-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Sat Jul 23 2022 Vitaly Zaitsev  - 0.2.1-1
  - Updated to version 0.2.1.


Package:  erlang-iconv-1.0.13-1.fc37
Old package:  erlang-iconv-1.0.11-4.fc36
Summary:  Fast encoding conversion library for Erlang / Elixir
RPMs: erlang-iconv
Size: 82.73 KiB
Size change:  8.60 KiB
Changelog:
  * Thu Jul 21 2022 Fedora Release Engineering  - 
1.0.11-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Sat Jul 23 2022 Peter Lemenkov  - 1.0.13-1
  - Update to 1.0.13


Package:  erlang-stun-1.2.4-1.fc37
Old package:  erlang-stun-1.0.37-4.fc36
Summary:  STUN and TURN library for Erlang / Elixir
RPMs: erlang-stun
Size: 165.46 KiB
Size change:  22.01 KiB
Changelog:
  * Thu Jul 21 2022 Fedora Release Engineering  - 
1.0.37-5
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Sat Jul 23 2022 Peter Lemenkov  - 1.2.4-1
  - Update to 1.2.4


Package:  fcitx-qt5-1.2.6-8.fc37
Old package:  fcitx-qt5-1.2.6-6.fc37
Summary:  Fcitx IM module for Qt5
RPMs: fcitx-qt5 fcitx-qt5-devel
Size: 1.05 MiB
Size change:  26.37 KiB
Changelog:
  * Thu Jul 21 2022 Fedora Release Engineering  - 
1.2.6-7
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

The performance impact of various debug options on Fedora Rawhide debug kernels

2022-07-24 Thread Richard W.M. Jones
The current Fedora Rawhide kernels are too slow to run libguestfs
tests when doing Koji builds.  These run in a qemu VM, running the
Rawhide kernel, emulated using software virtualization (ie. TCG).
They now time out because these kernels are so slow.  Until fairly
recently they were slow but working.

I wondered if particular debug options had a greater effect on
performance, so I compiled many kernels (v5.19-rc7 from upstream)
using the baseline "no debug" config, then adding each debug option
that we use in turn, and measuring the performance using [1], using
qemu software virtualization (TCG).  The tests were run many times
with warmups discarded to get the mean and standard deviation, using
the hyperfine program[2].

The results are below, and not very conclusive, but some options do
have a very large performance impact.

NO_DEBUG is the kernel compiled with no debug options enabled (ie. the
baseline).

In the actual debug kernel I expect the slow downs to be multiplied
together.  To test that I did an extra run with all debug options
enabled (ALL_DEBUG).

CONFIG_PROVE_LOCKING, CONFIG_LOCK_STAT and CONFIG_DEBUG_LOCK_ALLOC
were present and enabled in the kernel when it was imported into git
in 2010.

CONFIG_DEBUG_WW_MUTEX_SLOWPATH was turned off in the past
(RHBZ#1114160).  It seems to have been switched on again in 2020.

CONFIG_DEBUG_KMEMLEAK seems like it was enabled in 2012.

It's also possible that an existing debug option has got slower in the
upstream kernel, that is, it's not that we've recently changed
something in Fedora.

Rich.

[1] https://libguestfs.org/libguestfs-test-tool.1.html
[2] https://github.com/sharkdp/hyperfine



NO_DEBUG:12.362 s ±  0.093 s

ALL_DEBUG:   30.134 s ±  0.402 s(+143%)

CONFIG_PROVE_LOCKING=y:  23.435 s ±  0.526 s(+ 88%)
CONFIG_LOCK_STAT=y:  17.707 s ±  0.254 s(+ 43%)
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y:15.804 s ±  0.161 s(+ 27%)
CONFIG_DEBUG_KMEMLEAK=y: 15.794 s ±  0.261 s(+ 27%)
CONFIG_DEBUG_LOCK_ALLOC=y:   15.696 s ±  0.116 s(+ 27%)
CONFIG_PAGE_TABLE_CHECK_ENFORCED=y:  12.694 s ±  0.104 s(+  2%)
CONFIG_FAILSLAB=y:   12.679 s ±  0.122 s
CONFIG_NOUVEAU_DEBUG_MMU=y:  12.657 s ±  0.156 s
CONFIG_FAULT_INJECTION_DEBUG_FS=y:   12.630 s ±  0.158 s
CONFIG_DMA_API_DEBUG=y:  12.624 s ±  0.148 s
CONFIG_PERF_USE_VMALLOC=y:   12.611 s ±  0.125 s
CONFIG_NOUVEAU_DEBUG_PUSH=y: 12.608 s ±  0.165 s
CONFIG_DEBUG_SPINLOCK=y: 12.600 s ±  0.132 s
CONFIG_PM_ADVANCED_DEBUG=y:  12.586 s ±  0.132 s
CONFIG_FAIL_IO_TIMEOUT=y:12.580 s ±  0.131 s
CONFIG_FAIL_MMC_REQUEST=y:   12.571 s ±  0.103 s
CONFIG_INTEL_IOMMU_DEBUGFS=y:12.569 s ±  0.111 s
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y:   12.564 s ±  0.111 s
CONFIG_SYNTH_EVENT_GEN_TEST=m:   12.552 s ±  0.082 s
CONFIG_LOCK_EVENT_COUNTS=y:  12.551 s ±  0.118 s
CONFIG_FAIL_MAKE_REQUEST=y:  12.550 s ±  0.098 s
CONFIG_TEST_MIN_HEAP=m:  12.545 s ±  0.071 s
CONFIG_DEBUG_RWSEMS=y:   12.543 s ±  0.117 s
CONFIG_FAULT_INJECTION=y:12.541 s ±  0.153 s
CONFIG_LOCKDEP_BITS=16:  12.532 s ±  0.161 s
CONFIG_FAIL_PAGE_ALLOC=y:12.532 s ±  0.136 s
CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12:12.526 s ±  0.068 s
CONFIG_KDB_DEFAULT_ENABLE=0x0:   12.523 s ±  0.143 s
CONFIG_TEST_LIST_SORT=m: 12.522 s ±  0.062 s
CONFIG_SND_VERBOSE_PRINTK=y: 12.522 s ±  0.120 s
CONFIG_WQ_WATCHDOG=y:12.518 s ±  0.141 s
CONFIG_RTW89_DEBUG=y:12.517 s ±  0.099 s
CONFIG_KDB_KEYBOARD=y:   12.517 s ±  0.183 s
CONFIG_DETECT_HUNG_TASK=y:   12.517 s ±  0.123 s
CONFIG_TEST_LOCKUP=m:12.514 s ±  0.080 s
CONFIG_IWLWIFI_DEVICE_TRACING=y: 12.514 s ±  0.139 s
CONFIG_QUOTA_DEBUG=y:12.511 s ±  0.114 s
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120: 12.511 s ±  0.159 s
CONFIG_DEBUG_RT_MUTEXES=y:   12.511 s ±  0.116 s
CONFIG_EFI_PGT_DUMP=y:   12.507 s ±  0.130 s
CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14:  12.506 s ±  0.095 s
CONFIG_PAGE_TABLE_CHECK=y:   12.504 s ±  0.102 s
CONFIG_DEBUG_VM_PGFLAGS=y:   12.500 s ±  0.106 s
CONFIG_XFS_WARN=y:   12.497 s ±  0.168 s
CONFIG_SND_JACK_INJECTION_DEBUG=y:   12.495 s ±  0.098 s
CONFIG_FAIL_FUNCTION=y:  12.495 s ±  0.127 s
CONFIG_DMAR_DEBUG=y: 12.486 s ±  0.145 s
CONFIG_RTW88_DEBUG=y:12.484 s ±  0.050 s
CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE=4096:   12.483 s ±  0.075 s
CONFIG_DEBUG_PERF_USE_VMALLOC=y: 12.481 s ±  0.107 s
CONFIG_KPROBE_EVENT_GEN_TEST=m:  12.478 s ±  0.148 s

Re: Retiring the pcre package from Fedora

2022-07-24 Thread Paolo Bonzini
Il sab 23 lug 2022, 19:12 Adam Williamson  ha
scritto:

> This of course begs a question: did qemu also have a non-static pcre
> requirement at the time? But it seems not:
>
> [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre
> BuildRequires: glibc-static pcre-static glib2-static zlib-static
>
> so, I'm not sure why Daniel concluded this needs a BuildRequires on
> pcre-static, but the obvious thing to do would be to ask him, I guess.
>

I think it could have been a missing requires of glib2-static, because glib
does use PCRE and therefore has it in the linker flags for a static build.
I will check next time I am at a computer.

Paolo

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