Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On úterý 16. ledna 2024 21:00:14 CET Chuck Anderson wrote:
> On Tue, Jan 16, 2024 at 08:02:28PM +0100, Pavel Raiskup wrote:
> > I just want to bump this thread; @kevin updated Fedora Koji today
> > - the Fedora 40+ (current Rawhide) builds are already handled with DNF5.
> > 
> > Happy (faster) building!  And should you face any issue, please report.
> > Pavel
> 
> In case it helps someone else, as documented here:
> 
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> 
> You need to do:
> 
> mock -r fedora-40-x86_64 --scrub=all
> 
> to allow "fedpkg mockbuild" to work again, otherwise one gets this error:
> 
> DEBUG util.py:461:  execv(/usr/bin/dnf5) failed: No such file or directory

Indeed, thank you.  It would be nice if Mock detected this situation, so
there's this RFE now:
https://github.com/rpm-software-management/mock/issues/1289

Pavel


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Daniel P . Berrangé]

On Tue, Jan 16, 2024 at 11:54:48PM +, Tom Hughes via devel wrote:
> On 16/01/2024 23:49, Richard Shaw wrote:
> > On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin
> > mailto:aleba...@fedoraproject.org>> wrote:
> > 
> > Ah, I misread the include path. It's our package that is too old :(
> > https://src.fedoraproject.org/rpms/rapidjson/pull-request/4
> >  should
> > help.
> > 
> > It doesn't look like the pull request has gotten any attention. Perhaps
> > it's time to initiate the non-responsive maintainer process?
> 
> Right because the other two PRs I've merged in the last couple of
> weeks, including one today, are not evidence of responsiveness?
> 
> That PR is on my to look at list but rather obviously it needs
> more work than the other ones.
> 
> I'm not really keen on packaging a random git snapshot because
> there's no way to know how good or bad it is but I realise that
> due to upstream being a pain it may be necessary here.

The big question is whether the git snapshot is API compatible with
the current version in Fedora.  There are a decent number of things
that depend on rapidjson in the distro and so this needs testing
IMHO before pulling in a git snapshot.

Given the upstream seemingly has no intention of doing more releases,
it feels like our hand will be forced though.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Tom Hughes via devel]

On 16/01/2024 23:49, Richard Shaw wrote:
On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin 
mailto:aleba...@fedoraproject.org>> wrote:


Ah, I misread the include path. It's our package that is too old :(
https://src.fedoraproject.org/rpms/rapidjson/pull-request/4
 should
help.

It doesn't look like the pull request has gotten any attention. Perhaps 
it's time to initiate the non-responsive maintainer process?


Right because the other two PRs I've merged in the last couple of
weeks, including one today, are not evidence of responsiveness?

That PR is on my to look at list but rather obviously it needs
more work than the other ones.

I'm not really keen on packaging a random git snapshot because
there's no way to know how good or bad it is but I realise that
due to upstream being a pain it may be necessary here.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Richard Shaw]

On Tue, Jan 16, 2024 at 5:36 PM Aleksei Bavshin 
wrote:

> Ah, I misread the include path. It's our package that is too old :(
> https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 should help.
>

It doesn't look like the pull request has gotten any attention. Perhaps
it's time to initiate the non-responsive maintainer process?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Jakub Jelinek]

On Tue, Jan 16, 2024 at 03:32:14PM -0800, Aleksei Bavshin wrote:
> On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw  wrote:
> >
> > I'm working on getting a new dependency of one of my packages into Fedora:
> >
> > https://github.com/socketio/socket.io-client-cpp/releases
> >
> > After doing successful test builds locally in mock (no error output at all) 
> > I used fedora-create-review but all the builds failed with:
> >
> > In file included from 
> > /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> > /usr/include/rapidjson/document.h: In member function 
> > ‘rapidjson::GenericStringRef& 
> > rapidjson::GenericStringRef::operator=(const 
> > rapidjson::GenericStringRef&)’:
> > /usr/include/rapidjson/document.h:319:82: error: assignment of read-only 
> > member ‘rapidjson::GenericStringRef::length’
> >   319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s = 
> > rhs.s; length = rhs.length; }
> >   | 
> >   ~~~^~~~
> > gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121: 
> > CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
> >
> > Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
> >
> > Is this a real error?
> 
> Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
> implementation is most certainly not legal, but previous versions of
> the compiler may have been ignoring that due to not being asked to
> instantiate the specific method.
> This was fixed 8 years ago, apparently bundled deps in
> socket.io-client-cpp are even older.

Yeah, basically what rapidjson does is something like
using size_t = decltype (sizeof 0); 

  
template

  
struct S {  

  
  template

  
  S (const T (&str)[N]) : s (str), length (N - 1) {}

  
  S (const T *str, size_t len) : s (str), length (len) {}   

  
  S (const S &rhs) : s (rhs.s), length (rhs.length) {}  

  
  S &operator= (const S &rhs) { s = rhs.s; length = rhs.length; }   

  
  const T *const s; 

  
  const size_t length;  

  
};  

  
and gcc only diagnoses that starting with https://gcc.gnu.org/r14-4111
when operator= doesn't need to be instantiated (C++ generally allows
but doesn't require such diagnostics on uninstantiated always invalid
templates), though only for the length store, the s store is invalid
too but it has a dependent type in that case.

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

Re: Build error with GCC 14, not even a warning in GCC 13

[Aleksei Bavshin]

Ah, I misread the include path. It's our package that is too old :(
https://src.fedoraproject.org/rpms/rapidjson/pull-request/4 should help.

On Tue, Jan 16, 2024 at 3:32 PM Aleksei Bavshin
 wrote:
>
> On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw  wrote:
> >
> > I'm working on getting a new dependency of one of my packages into Fedora:
> >
> > https://github.com/socketio/socket.io-client-cpp/releases
> >
> > After doing successful test builds locally in mock (no error output at all) 
> > I used fedora-create-review but all the builds failed with:
> >
> > In file included from 
> > /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> > /usr/include/rapidjson/document.h: In member function 
> > ‘rapidjson::GenericStringRef& 
> > rapidjson::GenericStringRef::operator=(const 
> > rapidjson::GenericStringRef&)’:
> > /usr/include/rapidjson/document.h:319:82: error: assignment of read-only 
> > member ‘rapidjson::GenericStringRef::length’
> >   319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s = 
> > rhs.s; length = rhs.length; }
> >   | 
> >   ~~~^~~~
> > gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121: 
> > CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
> >
> > Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
> >
> > Is this a real error?
>
> Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
> implementation is most certainly not legal, but previous versions of
> the compiler may have been ignoring that due to not being asked to
> instantiate the specific method.
> This was fixed 8 years ago, apparently bundled deps in
> socket.io-client-cpp are even older.
>
> >
> > 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, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Build error with GCC 14, not even a warning in GCC 13

[Aleksei Bavshin]

On Tue, Jan 16, 2024 at 3:07 PM Richard Shaw  wrote:
>
> I'm working on getting a new dependency of one of my packages into Fedora:
>
> https://github.com/socketio/socket.io-client-cpp/releases
>
> After doing successful test builds locally in mock (no error output at all) I 
> used fedora-create-review but all the builds failed with:
>
> In file included from 
> /builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
> /usr/include/rapidjson/document.h: In member function 
> ‘rapidjson::GenericStringRef& 
> rapidjson::GenericStringRef::operator=(const 
> rapidjson::GenericStringRef&)’:
> /usr/include/rapidjson/document.h:319:82: error: assignment of read-only 
> member ‘rapidjson::GenericStringRef::length’
>   319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s = 
> rhs.s; length = rhs.length; }
>   |   
> ~~~^~~~
> gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121: 
> CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1
>
> Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023
>
> Is this a real error?

Yes, see https://github.com/Tencent/rapidjson/issues/718. The operator
implementation is most certainly not legal, but previous versions of
the compiler may have been ignoring that due to not being asked to
instantiate the specific method.
This was fixed 8 years ago, apparently bundled deps in
socket.io-client-cpp are even older.

>
> 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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Build error with GCC 14, not even a warning in GCC 13

[Richard Shaw]

I'm working on getting a new dependency of one of my packages into Fedora:

https://github.com/socketio/socket.io-client-cpp/releases

After doing successful test builds locally in mock (no error output at all)
I used fedora-create-review but all the builds failed with:

In file included from
/builddir/build/BUILD/socket.io-client-cpp-3.1.0/src/internal/sio_packet.cpp:8:
/usr/include/rapidjson/document.h: In member function
‘rapidjson::GenericStringRef&
rapidjson::GenericStringRef::operator=(const
rapidjson::GenericStringRef&)’:
/usr/include/rapidjson/document.h:319:82: error: assignment of read-only
member ‘rapidjson::GenericStringRef::length’
  319 | GenericStringRef& operator=(const GenericStringRef& rhs) { s =
rhs.s; length = rhs.length; }
  |
  ~~~^~~~
gmake[2]: *** [CMakeFiles/sioclient.dir/build.make:121:
CMakeFiles/sioclient.dir/src/internal/sio_packet.cpp.o] Error 1

Full logs: https://koji.fedoraproject.org/koji/taskinfo?taskID=111852023

Is this a real error?

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mass rebuild: git push --no-verify

[Sérgio Basto]

On Tue, 2024-01-16 at 14:50 -0700, Jerry James wrote:
> Given the problems we had with font packages not being rebuilt in the
> last mass rebuild, can we ensure that the mass rebuild script uses
> "git push --no-verify" instead of plain "git push"?
> 
> See:
> - https://bugzilla.redhat.com/show_bug.cgi?id=2233878
> -
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7IIZPEC6B4BEOOOV5YFEUGOONNOH5LZO/


You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
define what packages you are going to rebuild ,  in line 93 of mass-
rebuild.py [3] you got the list of packages that you go rebuild  
and since line 132 [4] you have the commands that will run . 
Is rpmdev-bumpspec that fails ? 


[1]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py

[2]
https://pagure.io/releng/blob/main/f/scripts/massrebuildsinfo.py


[3] 
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_93

[4]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_132

> -- 
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mass rebuild: git push --no-verify

[Jerry James]

Given the problems we had with font packages not being rebuilt in the
last mass rebuild, can we ensure that the mass rebuild script uses
"git push --no-verify" instead of plain "git push"?

See:
- https://bugzilla.redhat.com/show_bug.cgi?id=2233878
- 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7IIZPEC6B4BEOOOV5YFEUGOONNOH5LZO/
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

pl License updates

[Jerry James]

I did a reanalysis of the pl package License field.  The main package
is changing from:

BSD-2-Clause AND BSD-3-Clause AND (BSD-3-Clause OR GPL-1.0-or-later)
AND Beerware AND CC-BY-SA-3.0 AND (GPL-1.0-or-later OR
Artistic-1.0-Perl) AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
SWI-Exception AND (GPL-2.0-or-later WITH SWI-Exception OR
Artistic-2.0) AND LGPL-2.0-or-later AND
LicenseRef-Fedora-Public-Domain AND LPPL-1.2 AND MIT AND Sleepycat AND
Unicode-DFS-2015 AND Unicode-DFS-2016 AND Zlib

to:

BSD-2-Clause AND BSD-3-Clause AND (Brian-Gladman-3-Clause OR
GPL-1.0-or-later) AND Beerware AND CC-BY-SA-3.0 AND (GPL-1.0-or-later
OR Artistic-1.0-Perl) AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
SWI-Exception AND (GPL-2.0-or-later WITH SWI-Exception OR
Artistic-2.0) AND LGPL-2.0-or-later AND
LicenseRef-Fedora-Public-Domain AND LPPL-1.3a AND MIT AND Sleepycat
AND Unicode-DFS-2015 AND Unicode-DFS-2016 AND Zlib AND dtoa

i.e., the following changes:
- Change (BSD-3-Clause OR GPL-1.0-or-later) to (Brian-Gladman-3-Clause
OR GPL-1.0-or-later)
- Change LPPL-1.2 to LPPL-1.3a
- Add dtoa

The License field of the compat-yap-devel subpackage is changing from:

BSD-2-Clause AND AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
Bison-exception-2.2 AND LicenseRef-Fedora-Public-Domain AND Spencer-99
AND TCL

to:

BSD-2-Clause AND AND GPL-2.0-or-later AND GPL-2.0-or-later WITH
Bison-exception-2.2 AND LicenseRef-Fedora-Public-Domain AND Spencer-99
AND TCL AND FBM

i.e., FBM is added.

I have pushed this change to git, and will let the mass rebuild do the
package build.
-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Chuck Anderson]

On Tue, Jan 16, 2024 at 08:02:28PM +0100, Pavel Raiskup wrote:
> I just want to bump this thread; @kevin updated Fedora Koji today
> - the Fedora 40+ (current Rawhide) builds are already handled with DNF5.
> 
> Happy (faster) building!  And should you face any issue, please report.
> Pavel

In case it helps someone else, as documented here:

https://fedoraproject.org/wiki/Changes/BuildWithDNF5

You need to do:

mock -r fedora-40-x86_64 --scrub=all

to allow "fedpkg mockbuild" to work again, otherwise one gets this error:

DEBUG util.py:461:  execv(/usr/bin/dnf5) failed: No such file or directory
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On pátek 5. ledna 2024 10:06:34 CET Pavel Raiskup wrote:
> On čtvrtek 4. ledna 2024 19:20:46 CET Pavel Raiskup wrote:
> > On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote:
> > > I just wanted to give you a quick heads-up that I plan to enable the
> > > BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
> > > gets distributed to mirrors.
> > 
> > This has happened now.  Fedora Copr builds F40 (Rawhide) with DNF5 now.
> > Should you face any issue, please report it.
> 
> Two more hints:
> 
> - I noticed that `dnf5` on Fedora Copr builders (F38) was buggy (old
>   version) because the latest update was not yet in the stable
>   repository.  This was breaking Rawhide builds in Copr projects with
>   `bootstrap=off` (using dnf5 on host).  This is no longer the case, the
>   DNF5 package has been updated to v5.1.10.  If you observed a
>   suspicious problem, please consider `bootstrap=on` or at least check
>   that DNF v5.1.10 is used.
> 
> - DNF5 isn't downloading filelists (resource cost optimization), which
>   in turn means that the packages can not (build)depend on random file
>   paths.  So just a small reminder that, per the updated packaging
>   guidelines https://pagure.io/packaging-committee/pull-request/1321 ,
>   you MUST NOT do things like `BuildRequires: /some/random/file/name`.

I just want to bump this thread; @kevin updated Fedora Koji today
- the Fedora 40+ (current Rawhide) builds are already handled with DNF5.

Happy (faster) building!  And should you face any issue, please report.
Pavel


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Dridi Boukelmoune]

> This is also a valid approach. This is the first alternative proposal
> which makes me say "hmm, this would also work". It is possibly even
> simpler than setting the $PATH. A very small disadvantage is that the
> wrapper would need to do its work every time the binary is called.
> But the wrapper could be trivially implemented in shell or it could be
> a compiled binary, making the wrapper very cheap.
>
> Hmm, what do other people think?

With my computer user hat on, I would much prefer this approach. If
the supposed "dozen" of relevant packages can be built with several
binaries variants, then let's pack them all in the same RPM and use
this mechanism. I'm sure that if successful it would extend to more
packages, including packages on the critical path. I'm fine with that
eventual outcome with this scheme.

This way, if I ever need to take my drive out of a fried laptop and
USB-boot from it on my spare laptop from 2013, then I'm not painting
myself into a corner with binaries too recent for that hardware. I was
happy to be able to do that last summer, and hope to still be able to
in the future (but also hope not to ever need it again). And yes,
Fedora (Xfce) works just fine on that decade-old laptop.

For a wrapper I would be in favor of a shell script, it makes things
much easier to understand as an end user, and it can be installed
once, for example:

> ls -l /usr/bin/cp
> lrwxrwxrwx. 1 root root 26 Jan  1 00:00 /usr/bin/cp -> 
> /usr/libexec/uarch-exec.sh

On the condition of course that the generic binary is always present,
which shouldn't be difficult if all variants are in the same package
in the first place. In theory there should be less moving parts, but
the difference between theory and reality...

My 2 cents
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Jakub Jelinek]

On Tue, Jan 16, 2024 at 01:21:19PM +0100, Björn Persson wrote:
> Jakub Jelinek wrote:
> > The f40-build-side-81394 side-tag contains new
> > gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> > tagged into rawhide shortly before the mass rebuild.
> > 
> > If there is anything you'd like to rebuild against it before the mass
> > rebuild (such as packages depending on Ada which like every year bumped
> > sonames of its shared libraries), please do so soon.
> 
> Thanks for the side-tag. Most of the Ada packages – those that I have
> access to – are now rebuilt if I did everything right. The rebuild went
> smoothly this time.

Thanks.

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

Re: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Björn Persson]

Jakub Jelinek wrote:
> The f40-build-side-81394 side-tag contains new
> gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> tagged into rawhide shortly before the mass rebuild.
> 
> If there is anything you'd like to rebuild against it before the mass
> rebuild (such as packages depending on Ada which like every year bumped
> sonames of its shared libraries), please do so soon.

Thanks for the side-tag. Most of the Ada packages – those that I have
access to – are now rebuilt if I did everything right. The rebuild went
smoothly this time.

Björn Persson


pgpS9LIgzjWcq.pgp
Description: OpenPGP digital signatur
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: EncourageI686LeafRemoval Change: Please make sure it's actually a leaf package

[Pavel Březina]

On 1/15/24 19:55, Colin Walters wrote:



On Mon, Jan 15, 2024, at 8:57 AM, Fabio Valentini wrote:

Hi all,

I've been made aware that there has been a cascade of packages that
dropped i686 support in Rawhide, most of them referencing my
EncourageI686LeafRemoval Change Proposal, but none of which *actually
are* leaf packages:

https://src.fedoraproject.org/rpms/composefs/c/b95af99


This one should be fixed by 
https://src.fedoraproject.org/rpms/composefs/c/c840e7496ad9a0a008903a4cfe5d38c22f49fd54?branch=rawhide


https://src.fedoraproject.org/rpms/xdg-desktop-portal/c/93310f7
https://src.fedoraproject.org/rpms/gdm/c/940885b
https://src.fedoraproject.org/rpms/sssd/c/e0023ec


I went ahead and pushed changes to these 3.


Thank you. SSSD build still failed. I think you need to built it in a 
sidetag or wait until the dependencies get into 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-01-15)

[Tom Hughes via devel]

On 16/01/2024 10:43, Florian Weimer wrote:


We still don't have approval for the toolchain updates that we need for
the mass rebuild (notably Changes/GNUToolchainF40).


As far as I can see there isn't even a Fesco ticket for it?

The fields in https://discussion.fedoraproject.org/t/100414 for ticket
numbers are just placeholders and there's nothing in the fesco issue
tracker that I can see.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-01-15)

[Neal Gompa]

On Tue, Jan 16, 2024 at 5:43 AM Florian Weimer  wrote:
>
> We still don't have approval for the toolchain updates that we need for
> the mass rebuild (notably Changes/GNUToolchainF40).
>
> How do we resolve this?  Do we delay the mass rebuild until we have
> FESCo approval?  We can delay the GNU TLS descriptor change for x86-64
> to Fedora 41, but doing that for the glibc 2.39 and GCC 14 updates would
> be awkward (and substantial extra work for glibc).
>

Aoife, can you please file a ticket for the Change on the fesco
tracker and I'll sponsor it for fast-track. We need to get this sorted
out because the work has already started.

Florian, in the future, please file these Changes as early as you know
what you're going to be doing, because that maximizes the lead time.
This is happening because the time window wound up overlapping because
of when it was processed and published for discussion. Ordinarily, I
think the ticket would be filed with FESCo today or tomorrow, but
obviously it needs to be done now so we can get things in order.




--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Schedule for Monday's FESCo Meeting (2024-01-15)

[Florian Weimer]

We still don't have approval for the toolchain updates that we need for
the mass rebuild (notably Changes/GNUToolchainF40).

How do we resolve this?  Do we delay the mass rebuild until we have
FESCo approval?  We can delay the GNU TLS descriptor change for x86-64
to Fedora 41, but doing that for the glibc 2.39 and GCC 14 updates would
be awkward (and substantial extra work for glibc).

Thanks,
Florian
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

-fcf-protection dropped from i686 compiler flags

[Florian Weimer]

This feature will never be implemented in the Linux kernel, so it does
not make sense to generate the additional support code for it.  Related
code has already been removed from rawhide glibc.

Thanks,
Florian
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: redhat-rpm-config now tied to Changes/GNUToolchainF40

[Florian Weimer]

* Florian Weimer:

> I pushed the changes that enable C type safety level handling once GCC
> 14 is merged and built it into the GCC 14 side tag (currently
> f40-build-side-81394).  I didn't add any conflicts with GCC 13 because
> the incompatibility is only present if a package lowers the C type
> safety level to 0.

So this warning didn't work and we have a new build with that change
tagged into f40.  I'll keep doing updates in f40 then, despite the
incompatibility with type safety level 0.

Thanks,
Florian
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnsmasq default configuration changed

[Miroslav Lichvar]

On Mon, Jan 15, 2024 at 05:31:36PM +0100, Kevin Kofler via devel wrote:
> Petr Menšík wrote:
> > Anyway, dnsmasq will listen by default on 127.0.0.1, as every standard
> > resolver does. You can use listen-address=127.0.0.53 if you like, but
> > then it will conflict with systemd-resolved.
> 
> You just wrote that you make it listen by default on all interfaces, and 
> then filter.

If I understand it correctly, it will do that only if the
configuration was modified (an additional interface was specified).
The default configuration should work exactly as before.

> This means it will conflict over the port 53.

They bind to different addresses by default.

-- 
Miroslav Lichvar
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue