Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Petr Lautrbach]

Ben Beasley  writes:


>      sestatus

This is based on upstream commit d464187c37529c [1]:

policycoreutils: sestatus belongs to bin not sbin

It is quite useful even to non-privileged users and doesn't require any
privileges to work, except for maybe -v.

Some tools hard code the old path, so a compatibility symlink is also
created.

-   install -m 755 sestatus $(DESTDIR)$(SBINDIR)
+   # Some tools hard code /usr/sbin/sestatus ; add a compatibility symlink
+   # install will overwrite a symlink, so create the symlink before calling
+   # install to allow distributions with BINDIR == SBINDIR
+   ln -sf --relative $(DESTDIR)$(BINDIR)/sestatus $(DESTDIR)$(SBINDIR)
+   install -m 755 sestatus $(DESTDIR)$(BINDIR)

So it's should be ready for BINDIR == SBINDIR from upstream POV.

But it can't be built [2] without %{_sbindir}/sestatus until this change
is implemented:

error: Installed (but unpackaged) file(s) found:
   /usr/sbin/sestatus
Installed (but unpackaged) file(s) found:
   /usr/sbin/sestatus


[1] 
https://github.com/SELinuxProject/selinux/commit/d464187c37529ca75fd417174f39ce0eaf13efb5
[2] https://src.fedoraproject.org/rpms/policycoreutils/pull-request/41

Petr


>
> That should be a reasonably accurate list of the executables that need 
> investigation, and for which the packages that provide them probably 
> need some kind of modification.
>
> On 1/7/24 10:47, Gary Buhrmaster wrote:
>> On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney  wrote:
>>> Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
>>>
>> I do not see as part of the plan a process to
>> go through all Fedora packages and identifying
>> binaries in /usr/bin that have the same name
>> as a binary in /usr/sbin (from the same, or
>> different packages) such that the packager
>> (or the multiple packages) will need to
>> coordinate the changes (perhaps by engaging
>> upstream).
>>
>> I agree that there should be few, but
>> identifying impacts in advance provides
>> for a better decision process, and minimizes
>> the last minute work that packagers need
>> to do (they will have a longer warning and
>> preparation time).
>> --
>> ___
>> 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
--
___
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

[Tomas Hrcka]

On Tue, Jan 16, 2024 at 10:52 PM 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"?
>

This is not a good idea. Because of a few packages that are not rebuilding
we would disable the hook for every push the script does.


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


-- 
Tomas Hrcka
fas: humaton
libera.CHAT: jednorozec
matrix: @humaton:fedora.im
--
___
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: [Fedora-packaging] BuildrootError: could not init mock buildroot ... see root.log ...

[Jonathan Wakely]

On Thu, 18 Jan 2024 at 06:43, Mamoru TASAKA  wrote:
>
> Brad Bell wrote on 2024/01/18 14:00:
> > I got the Result in the subject above for the following build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=111912575
> >
> > Looking at the corresponding root.log
> > https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log
> > does not indicate to me what went wrong or how I should proceed ?
> > --
> > ___
>
> Looking at root.log:
>
> x86_64 (successful)
> https://kojipkgs.fedoraproject.org//work/tasks/2577/111912577/root.log
>
> DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
> 'remount,private,rbind', '--target', 
> '/var/lib/mock/f40-build-48240062-5748626-bootstrap/root/var/lib/mock/f40-build-48240062-5748626/root']
>  with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 
> 'C.UTF-8'} and shell False
> DEBUG util.py:610:  Child return code was: 0
> DEBUG file_util.py:18:  ensuring that dir exists: 
> /var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
> DEBUG file_util.py:21:  created dir: 
> /var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
> DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
> '/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 'install', 
> 'build', '--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes']
> DEBUG util.py:636:  child environment: None
> DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf']
> DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', 
> '-M', '69286198251d4cbebe3bbba5ac862e76', '-D', 
> '/var/lib/mock/f40-build-48240062-5748626-bootstrap/root', '-a', 
> '--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf', '--console=pipe', 
> '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
> '--setenv=HOME=/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir',
>  '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
> '--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
> '--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
> '--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf5', 
> '--installroot', '/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 
> 'install', 'build', '--setopt=deltarpm=False', 
> '--setopt=allow_vendor_change=yes', '--setopt=tsflags=nocontexts'] with env 
> {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': 
> '/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 
> 'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1': 
> ' \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 
> 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 'SYSTEMD_SECCOMP': '0'} and shell False
> DEBUG util.py:463:  Updating and loading repositories:
> DEBUG util.py:463:   build  100% |  97.2 
> MiB/s |  17.6 MiB |  00m00s
>
> i686 (failing)
> https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log
>
> DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
> 'remount,private,rbind', '--target', 
> '/var/lib/mock/f40-build-48240060-5748626-bootstrap/root/var/lib/mock/f40-build-48240060-5748626/root']
>  with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 
> 'C.UTF-8'} and shell False
> DEBUG util.py:610:  Child return code was: 0
> DEBUG file_util.py:18:  ensuring that dir exists: 
> /var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
> DEBUG file_util.py:21:  created dir: 
> /var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
> DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
> '/var/lib/mock/f40-build-48240060-5748626/root/', 'group', 'install', 
> 'build', '--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes', 
> '--allowerasing'] 
> <=
> DEBUG util.py:636:  child environment: None
> DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf']
> DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', 
> '-M', '41961b9ee3b140eda2ee2c91559a676a', '-D', 
> '/var/lib/mock/f40-build-48240060-5748626-bootstrap/root', '-a', 
> '--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf', '--console=pipe', 
> '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
> '--setenv=HOME=/var/lib/mock/f40-build-48240060-5748626/root/installation-homedir',
>  '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
> '--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
> '--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
> '--setenv=LC_MESS

Is packager dashboard supposed to contain up-to-date bugs?

[Julian Sikorski]

Hello,

In my packager dashboard there are six AusweisApp2 bugs listed, all of 
them are actually resolved. The bugs currently open are not listed 
either. Is this a known problem?


Best regards,
Julian
--
___
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

F40 Change Proposal: Arm Minimal Image OS-Build (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
Build the Arm minimal image to be built using osbuild.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]

* Email: 


== Detailed Description ==
The Fedora Arm Minimal image is widely used as a base for various
usecases from low level board bring up right through to the basis of
other images. Over time the existing ImageFactory build process has
stagnated limiting our ability to enhance this image. The osbuild team
have worked with the Arm SIG to enable a number of enhancements around
things like Arm SystemReady and other such functionality to improve
this image creation process and to make it easier to use these images
with a much wider range of Arm devices making it easier to bring up
new types of Arm device in Fedora. In the future we are planning
further enhancements to ensure it's easy for developers and users to
make use of the Fedora within the Arm ecosystem.

== Feedback ==


== Benefit to Fedora ==
The Fedora arm Minimal Image currently requires a number of changes
and hacks to be used on specific devices or SoCs, the move to osbuild
will reduce or entirely eliminate these hacks right away with further
enhancements coming in the future.

== Scope ==
* Proposal owners:
The proposal owners will:
** Enable the creation of Minimal image using osbuild in pungi
** Test the available artifacts

* Other developers:

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] 
Changes to the pungi config to use osbuild for minimal image will be
submitted as a PR by feature owners.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
No upgrade impact. Only for new users.

== How To Test ==
There will be a new Minimal Image, it will be testable in the same way
as the old image. Test various SoCs with arm-image-installer to ensure
devices boot and run as expected.

== User Experience ==
There should be no change to the user experience for existing users.
We will enable the wider use of

== Dependencies ==
All changes are already in osbuild but we will work with the osbuild
team if any issues arise.

== Contingency Plan ==
The contingency plan is to build the Arm minimal image in the same way
we currently do.

== Documentation ==
There should be no changes required to documentation for existing
users, docs will be updated for specific devices where enhancements
have been made.

== Release Notes ==
TBD.


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: F40 Change Proposal: Arm Minimal Image OS-Build (Self-Contained)

[Neal Gompa]

On Thu, Jan 18, 2024 at 9:30 AM Aoife Moloney  wrote:
>
> Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild
>
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
>
> == Summary ==
> Build the Arm minimal image to be built using osbuild.
>
> == Owner ==
> * Name: [[User:pbrobinson| Peter Robinson]]
>
> * Email: 
>
>
> == Detailed Description ==
> The Fedora Arm Minimal image is widely used as a base for various
> usecases from low level board bring up right through to the basis of
> other images. Over time the existing ImageFactory build process has
> stagnated limiting our ability to enhance this image. The osbuild team
> have worked with the Arm SIG to enable a number of enhancements around
> things like Arm SystemReady and other such functionality to improve
> this image creation process and to make it easier to use these images
> with a much wider range of Arm devices making it easier to bring up
> new types of Arm device in Fedora. In the future we are planning
> further enhancements to ensure it's easy for developers and users to
> make use of the Fedora within the Arm ecosystem.
>
> == Feedback ==
> 
>
> == Benefit to Fedora ==
> The Fedora arm Minimal Image currently requires a number of changes
> and hacks to be used on specific devices or SoCs, the move to osbuild
> will reduce or entirely eliminate these hacks right away with further
> enhancements coming in the future.
>
> == Scope ==
> * Proposal owners:
> The proposal owners will:
> ** Enable the creation of Minimal image using osbuild in pungi
> ** Test the available artifacts
>
> * Other developers:
>
> * Release engineering: [https://pagure.io/releng/issues #Releng issue
> number] 
> Changes to the pungi config to use osbuild for minimal image will be
> submitted as a PR by feature owners.
>
> * Policies and guidelines: N/A (not needed for this Change)
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with Community Initiatives:
>
> == Upgrade/compatibility impact ==
> No upgrade impact. Only for new users.
>
> == How To Test ==
> There will be a new Minimal Image, it will be testable in the same way
> as the old image. Test various SoCs with arm-image-installer to ensure
> devices boot and run as expected.
>
> == User Experience ==
> There should be no change to the user experience for existing users.
> We will enable the wider use of
>
> == Dependencies ==
> All changes are already in osbuild but we will work with the osbuild
> team if any issues arise.
>
> == Contingency Plan ==
> The contingency plan is to build the Arm minimal image in the same way
> we currently do.
>
> == Documentation ==
> There should be no changes required to documentation for existing
> users, docs will be updated for specific devices where enhancements
> have been made.
>
> == Release Notes ==
> TBD.


Is there a repository where the blueprint for the minimal image will
be stored? Otherwise there’s not exactly anything Fedora side that
anyone can actually observe, extend, or maintain.



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

F40 Change Proposal: Deprecate_ntlm_in_cyrus_sasl (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/Deprecate_ntlm_in_cyrus_sasl

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==

NTLM has been deprecated for years and is obsolete. Support for it
should be removed as a SASL mechanism. This is no longer supported by
cyrus-sasl upstream. The cyrus-sasl-ntlm subpackage should be removed.

== Owner ==
* Name: [[User:rcritten| Rob Crittenden]]
* Email: rcrit...@redhat.com.



== Detailed Description ==
NTLM authentication is a family of authentication protocols to
authenticate users and computers.  It has been supplanted by more
secure protocols (e.g. Kerberos).
[https://specopssoft.com/blog/microsoft-phases-out-ntlm-with-kerberos/
Microsoft is removing support for NTLM in favor of Kerberos in Windows
to boost security]

[https://en.wikipedia.org/wiki/NTLM#Availability_and_use_of_NTLM Since
2010, Microsoft no longer recommends NTLM in applications:]

Implementers should be aware that NTLM does not support any recent
cryptographic methods, such as AES or SHA-256. It uses cyclic
redundancy checks (CRC) or MD5 for integrity, and RC4 for encryption.
Deriving a key from a password is as specified in RFC1320 and
FIPS46-2. Therefore, applications are generally advised not to use
NTLM.

== Feedback ==

== Benefit to Fedora ==
The cyrus-sasl project dropped support for the ntlm plugin in July,
2023. This proposal removes an unsupported and insecure protocol.
Without upstream support from upstream this plugin is potentially a
heavy burden for Fedora packagers and a risk to security.

== Scope ==
* Proposal owners:
Proposal owner: Deprecate cyrus-sasl-ntlm. This will allow for
sub-package from the distribution in a future release.

* Other developers:
** There do not appear to be any packages that rely on cyrus-sasl-ntlm

* Release engineering:
Some coordination may be necessary so the subpackage never appears in
a given Fedora release. Ideally it is removed in rawhide before the
Fedora-next fork.

* Policies and guidelines: Release notes will be needed to announce
the deprecation and removal.

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==
Existing users of cyrus-sasl-ntlm will need to authenticate using a
different mechanism.

== How To Test ==

This will only affect a narrow set of users. It will be an exercise
for the end-user to determine which mechanism(s) may be a suitable
replacement.

== User Experience ==

This will not be visible to users that aren't using cyrus-sasl-ntml.
It will be '''very''' visible to those that are as they will have to
revise their authentication configuration in order to upgrade or
install the cyrus-sasl package.

== Dependencies ==
None.

== Contingency Plan ==

The proposal involves removing a subpackage from the spec file. There
backup plan is to not do it.

== Documentation ==

This was removed in upstream PR
https://github.com/cyrusimap/cyrus-sasl/issues/708

== Release Notes ==




-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: F40 Change Proposal: Arm Minimal Image OS-Build (Self-Contained)

[Peter Robinson]

On Thu, 18 Jan 2024 at 14:39, Neal Gompa  wrote:
>
> On Thu, Jan 18, 2024 at 9:30 AM Aoife Moloney  wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/ArmMinimalImageOSBuild
> >
> > This is a proposed Change for Fedora Linux.
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> >
> > == Summary ==
> > Build the Arm minimal image to be built using osbuild.
> >
> > == Owner ==
> > * Name: [[User:pbrobinson| Peter Robinson]]
> >
> > * Email: 
> >
> >
> > == Detailed Description ==
> > The Fedora Arm Minimal image is widely used as a base for various
> > usecases from low level board bring up right through to the basis of
> > other images. Over time the existing ImageFactory build process has
> > stagnated limiting our ability to enhance this image. The osbuild team
> > have worked with the Arm SIG to enable a number of enhancements around
> > things like Arm SystemReady and other such functionality to improve
> > this image creation process and to make it easier to use these images
> > with a much wider range of Arm devices making it easier to bring up
> > new types of Arm device in Fedora. In the future we are planning
> > further enhancements to ensure it's easy for developers and users to
> > make use of the Fedora within the Arm ecosystem.
> >
> > == Feedback ==
> > 
> >
> > == Benefit to Fedora ==
> > The Fedora arm Minimal Image currently requires a number of changes
> > and hacks to be used on specific devices or SoCs, the move to osbuild
> > will reduce or entirely eliminate these hacks right away with further
> > enhancements coming in the future.
> >
> > == Scope ==
> > * Proposal owners:
> > The proposal owners will:
> > ** Enable the creation of Minimal image using osbuild in pungi
> > ** Test the available artifacts
> >
> > * Other developers:
> >
> > * Release engineering: [https://pagure.io/releng/issues #Releng issue
> > number] 
> > Changes to the pungi config to use osbuild for minimal image will be
> > submitted as a PR by feature owners.
> >
> > * Policies and guidelines: N/A (not needed for this Change)
> >
> > * Trademark approval: N/A (not needed for this Change)
> >
> > * Alignment with Community Initiatives:
> >
> > == Upgrade/compatibility impact ==
> > No upgrade impact. Only for new users.
> >
> > == How To Test ==
> > There will be a new Minimal Image, it will be testable in the same way
> > as the old image. Test various SoCs with arm-image-installer to ensure
> > devices boot and run as expected.
> >
> > == User Experience ==
> > There should be no change to the user experience for existing users.
> > We will enable the wider use of
> >
> > == Dependencies ==
> > All changes are already in osbuild but we will work with the osbuild
> > team if any issues arise.
> >
> > == Contingency Plan ==
> > The contingency plan is to build the Arm minimal image in the same way
> > we currently do.
> >
> > == Documentation ==
> > There should be no changes required to documentation for existing
> > users, docs will be updated for specific devices where enhancements
> > have been made.
> >
> > == Release Notes ==
> > TBD.
>
>
> Is there a repository where the blueprint for the minimal image will
> be stored? Otherwise there’s not exactly anything Fedora side that
> anyone can actually observe, extend, or maintain.

At the moment no, because the minimal image hasn’t changed in years,
but we will be introducing that for the other images in a future
release. This is currently focused on Minimal just to get the full
process in place and issues ironed out.

It's available in osbuild so people can do their own blueprints and
extend and maintain if they want their own custom version.
--
___
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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

[Stephen Gallagher]

On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik  wrote:
>
> Hello,
> I just wanted to quickly announce a small project I did in collaboration with 
> the Packit folks.
>
> Do you have some tools or services that perform actions on all currently 
> active Fedora releases? And do you have to manually update their list every 
> time a new Fedora release is branched or EOLed? The fedora-distro-aliases 
> will make your life easier.
>
> https://github.com/rpm-software-management/fedora-distro-aliases
>
> It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, etc. 
> To evaluate them, it queries Bodhi, so they are always up-to-date (but the 
> tradeoff is that it requires an internet connection). There are multiple 
> examples in the project README but the usage is simple, e.g.:
>
> >>> from fedora_distro_aliases import get_distro_aliases
> >>> aliases = get_distro_aliases()
> >>> [x.namever for x in aliases["fedora-all"]]
> ['fedora-38', 'fedora-39', 'fedora-rawhide']
>
> The package is already in Fedora, give it a shot,

Thanks! I'll look into updating
https://github.com/sgallagher/get-fedora-releases-action with this.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F40 Change Proposal: Fedora IoT Bootable Containers

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/Fedora_IoT_Bootable_Container

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Fedora IoT uses OSTree to provide an OS suitable for Edge and IoT
usecases, Ostree Native Container or Bootable Containers, are a new
and interesting mechanism for both building and delivering OSTree
content. This brings this initiative to Fedora IoT to enable other
means of users consuming Fedora IoT.

== Owner ==
* Name: [[User:pbrobinson| Peter Robinson]]
* Name: [[User:pwhalen| Paul Whalen]]
* Email: 
* Email: 


== Detailed Description ==
Fedora IoT uses OSTree to provide an OS suitable for Edge and IoT
usecases, Ostree Native Container or Bootable Containers, are a new
and interesting mechanism for both building and delivering OSTree
content. This brings this initiative to Fedora IoT to enable other
means of users consuming Fedora IoT.


== Feedback ==


== Benefit to Fedora ==
This benefits Fedora IoT users by being able to use container
technologies in the build pipelines and OS definitions. It allows
users to consume Fedora IoT in different ways that may better suit
their environment and ecosystem allowing wider adoption. This is an
expansion of the technologies available and there is no requirement
for users to change.

This will deliver two bootc containers for Fedora IoT users, firstly a
cut down minimal version for users to use as a base to build their own
vision of Fedora IoT and well as the traditional Fedora IoT user
experience.

== Scope ==
* Proposal owners:
The proposal owners will
** Enable the creation of bootable containers artifacts in pungi
** Work with the osbuild team to ensure artifacts are produced
** Test to ensure the user experience is what's expected

* Other developers:

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] 
There's no direct requirement from release engineering. We may need
some adjustment to the koji-osbuild policy.

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
There is no upgrade impact, this is a new means of deployment of
Fedora IoT, existing users and artifacts will continue to work as
usual.

== How To Test ==
There will be new bootc containers published, once they are enabled we
will update documentation on how to use and consume them and ways to
provide feedback.

== User Experience ==
There will be a new user experience available for new deployments of
Fedora IoT as well as for upgrades where users wish to be able to pull
updates via a container registry.

== Dependencies ==
There's some dependencies on in-progress work in osbuild which we are
coordinating with the osbuild team.

== Contingency Plan ==
The contingency plan is to delay shipping OSTree bootable containers
if we run into issues with producing them.

== Documentation ==
The Fedora IoT docs will be updated as part of this change.

== Release Notes ==
TBD.


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: Mass rebuild: git push --no-verify

[Jerry James]

On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto  wrote:
> 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 ?

Thank you for the pointer, Sérgio.  I have opened
https://pagure.io/releng/pull-request/11897.

It is not rpmdev-bumpspec that fails.  That works just fine.  But any
package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
requires --no-verify today when pushing to git, due to the referenced
bug.  That's merely annoying for a human, but fatal to an automated
build script that doesn't pass --noverify.
-- 
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: Mass rebuild: git push --no-verify

[Jerry James]

On Wed, Jan 17, 2024 at 3:48 PM kevin  wrote:
> I suppose this might be a good idea... I'd be afraid of what it might
> break, while fixing the fonts packages though. But of course if it was
> completely broken it would fail after that anyhow...

That's exactly my thinking.  The package is either broken already or
it is not.  If it is, then allowing a mass rebuild push won't change
the situation.  If it is not, then skipping verification has no
effect.
-- 
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: Mass rebuild: git push --no-verify

[Jerry James]

On Thu, Jan 18, 2024 at 4:50 AM Tomas Hrcka  wrote:
> This is not a good idea. Because of a few packages that are not rebuilding we 
> would disable the hook for every push the script does.

My thinking is that the hook is not useful for automated build scripts
anyway, so disabling it doesn't hurt.  See my previous replies in this
thread.
-- 
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

cryptominisat soname bump

[Jerry James]

In about a week, I plan to update the cryptominisat package to version
5.11.15 in Rawhide, which comes with an soname bump.  We have been
stuck on version 5.8.0 for a long time because some consuming packages
were not compatible with newer versions.  At last all of them are
ready for the update.  In addition to the cryptominisat package, I
will also rebuild:

- cvc5
- stp
- yices

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

F40 Change Proposal: Build Fedora IoT using rpm-ostree unified core (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/Fedora_IoT_Unified_Core


This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.



= Build Fedora IoT using rpm-ostree unified core =

== Summary ==
Upstream rpm-ostree development is now focused on "unified core" mode,
with plans to deprecate the previous mode in the future. Fedora IoT is
the last rpm-ostree based Fedora edition using this older, soon to be
deprecated mode with SilverBlue and Kinoite making the change in
Fedora 39. This change will align IoT with the other ostree-based
editions in Fedora.

== Owner ==
* Name: [[User:pwhalen| Paul Whalen]], [[User:idiez| Irene Diez]]
* Email: pwha...@fedoraproject.org, id...@redhat.com


== Detailed Description ==
To learn about the differences between unified core and the previous
mode, please read the upstream
[https://github.com/coreos/rpm-ostree/issues/729 issue]. The main
advantage is that it is stricter and safer, while enabling some post
processing steps to happen during or after the image build. In
addition, unified core support is required for bootupd integration in
Fedora IoT and to align with other rpm-ostree editions in Fedora.

Related changes (already complete):

* https://fedoraproject.org/wiki/Changes/FedoraSilverblueUnifiedCore
* https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd

== Feedback ==



== Benefit to Fedora ==
The previous mode in rpm-ostree is not maintained anymore, less tested
and thus prone to bugs. Moving to unified core will align IoT with
what is used to build Fedora CoreOS, SilverBlue and Kinoite as well as
benefit from the additional testing those editions receive. Making the
change in IoT should also reduce the maintenance burden from the
rpm-ostree project as they will be able to remove the old code.
Unified core makes composes work the same on the server side as the
client side and makes them safer by more strictly confining scriptlet
execution.

== Scope ==
* Proposal owners: Testing with the new mode to ensure there are no regressions.
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/11815 #11815]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A
* Alignment with Community Initiatives: N/A

== Upgrade/compatibility impact ==
* There will be no impact to end users, upgrades will work the same as
previous releases

== How To Test ==
* Upgrade to Fedora 40 IoT Edition or deploy a new installation.

== User Experience ==
* There will be no impact to users.

== Dependencies ==
N/A

== Contingency Plan ==
* Contingency mechanism: Revert to older non-unified core mode.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)

== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==
N/A



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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

F40 Change Proposal: ibus-anthy 1.5.16 (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/ibus-anthy_1.5.16

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


== Summary ==
ibus-anthy will update the Japanese era for 2024.

== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]

* Email: fujiwara [at] redhat [dot] com


== Detailed Description ==
* ibus-anthy will convert the Japanese era and "2024" mutually


== Feedback ==


== Benefit to Fedora ==
This change will enhance the usability in Japanese.


== Scope ==
* Proposal owners: ibus-anthy

* Other developers:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:



== Upgrade/compatibility impact ==



== How To Test ==
# Enable ibus-anthy
# Run gnome-text-editor
# Select the Dictionary mode to Era on IBus panel menu.
# Type "２０２４" or "れいわ６" and space keys
# The Japanese era and 2024 is converted mutually


== User Experience ==
Users can use the latest Japanese era.


== Dependencies ==


== Contingency Plan ==
* Contingency mechanism: Revert the change to ibus-anthy.
* Contingency deadline: Beta release
* Blocks release? No


== Documentation ==
N/A (not a System Wide Change)

== Release Notes ==


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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

F40 Change Proposal: ibus 1.5.30 (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/IBus_1.5.30

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


= IBus 1.5.30 =

== Summary ==
IBus 1.5.30 will have some enhancements.

== Owner ==
* Name: [[User:Fujiwara|Takao Fujiwara]]

* Email: fujiwara [at] redhat [dot] com


== Detailed Description ==
* `ibus start` and `ibus restart` commands will work for Plasma
Wayland. (They have worked in Plasma Xorg.)
* "Preference" menu item will be shown in IBus activate menu in Plasma
Wayland. (The change is not needed in Plasma Xorg since the context
menu is also available.)

== Feedback ==


== Benefit to Fedora ==
This change will enhance the usability in Plasma Wayland.


== Scope ==
* Proposal owners: ibus 1.5.30

* Other developers:

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==



== How To Test ==

=== `ibus restart` ===
# Log into Plasma wayland desktop session and confirm ibus-daemon is running
# Open konsole
# Run `ibus restart`
# ibus-daemon is restarted

=== Panel menu ===
# Log into Plasma wayland desktop session and confirm ibus-daemon is running
# Click on the IBus panel menu
# "Preference" menu item is available

== User Experience ==
`ibus restart` command has been useful for users to reload the IBus
configurations in non-Plasma Wayland desktop sessions and it will work
in Plasma Wayland too. Currently IBus can toggle the activate menu and
context menu with clicking the mouse middle button on the panel icon
but most users won't have to use the middle clicking after the
"Preferences" menu item is shown in the activate menu.


== Dependencies ==
IBus will use D-Bus methods of Plasma Wayland to reload the on-screen
keyboard configuration or show the panel menu.


== Contingency Plan ==
* Contingency mechanism: Revert the change to ibus.
* Contingency deadline: Beta release


== Documentation ==
N/A (not a System Wide Change)


== Release Notes ==





-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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

F40 Change Proposal: IoT Simplified Provisioning (Self-Contained)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/IoTSimplifiedProvisioning

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.


= IoT Simplified Provisioning =


== Summary ==
Offer Fedora IoT users a new, non-release blocking deliverable to
deploy and configure Fedora IoT systems using a new tool called
Simplified Provisioning.

== Owner ==

* Name: [[User:pwhalen| Paul Whalen]]
* Email: pwha...@fedoraproject.org

* Name: [[User:djachimo| David Jachimowicz]]
* Email: djach...@redhat.com


== Detailed Description ==
The Fedora IoT Simplified Provisioning tool uses the
`coreos-installer` to write an OStree raw image straight to a disk
specified in a kernel argument, without the need for a kickstart or
user interaction. This type of installation is ideal for devices
connected at the edge where connectivity can be slow or intermittent.
This new, non-release blocking deliverable, offers users the ability
to easily configure the system with Fido Device Onboarding or Ignition
and allows for headless, secure, zero touch installations including
optional automated disk encryption with enrollment into TPM2.

== Feedback ==


== Benefit to Fedora ==
The addition of the Fedora IoT Simplified Provisioning deliverable
will benefit IoT users by allowing them to easily deploy Fedora IoT
systems and leverage existing tools like Fido Device Onboarding and
Ignition for configuration.

== Scope ==
* Proposal owners:
** Test building the new deliverable in Fedora infrastructure as part
of the IoT compose process.
** Update Fedora IoT documentation with usage details.
** Update website so users can download artifacts.

* Other developers:
* N/A

* Release engineering: N/A (not needed for this Change)

* Policies and guidelines: N/A (not needed for this Change) 

* Trademark approval: N/A (not needed for this Change)

* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
* Not applicable to this change.

== How To Test ==
* Testable by downloading the new ISO and deploying to a UEFI enabled
edge device.

== User Experience ==
This change will enhance the Fedora IoT user experience by allowing
users to easily customize Fedora IoT deployments and leverage new
technologies like FIDO Device Onboarding for secure zero touch device
onboarding of edge devices as well as Ignition to configure the
device.

== Dependencies ==
N/A (not a System Wide Change)

== Contingency Plan ==
* Contingency deadline: Beta
* Blocks release? No.
* Blocks product? No.


== Documentation ==
* Usage documentation to be written and included in the
[https://docs.fedoraproject.org/en-US/iot/user-guide/ Fedora IoT user
guide].

== Release Notes ==

-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: Re: Mass rebuild: git push --no-verify

[kevin]

On Thu, Jan 18, 2024 at 09:15:18AM -0700, Jerry James wrote:
> On Thu, Jan 18, 2024 at 4:50 AM Tomas Hrcka  wrote:
> > This is not a good idea. Because of a few packages that are not rebuilding 
> > we would disable the hook for every push the script does.
> 
> My thinking is that the hook is not useful for automated build scripts
> anyway, so disabling it doesn't hurt.  See my previous replies in this
> thread.

yeah... 

* Current setup with the hook:
  Bunch of fonts don't even get touched by the mass rebuild
  Some other packages with problems caught by the hook also are
completely missed.

* With --no-verify:
  Bunch of fonts do rebuild in the mass rebuild
  Some packages with problems get a mass rebuild commit at least and
attempted build. It might fail, but it's at least tried.

The mass rebuild is only doing a bump/rebuild. There's no reason it
should ever cause something that be caught by the hook, and if it did,
it would be better for it to do the commit anyhow and cause a failed
build. IMHO.

So, I think we should run with --no-verify.

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

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

[Björn Persson]

kevin wrote:
> The mass rebuild is only doing a bump/rebuild. There's no reason it
> should ever cause something that be caught by the hook, and if it did,
> it would be better for it to do the commit anyhow and cause a failed
> build. IMHO.

If, hypothetically, a defect in the mass-rebuild script would corrupt
thousands of spec files, how easy would it be to write a mass-revert
script to repair the damage? The mass-revert script shouldn't just
revert the latest commit in every package, because the corruption might
not have happened in every package, and some might have been reverted
manually in the meantime. The mass-revert script would need to verify
that it reverts only commits done by the defective mass-rebuild script.

If that's nontrivial to get right, then it seems to me that there is
value in a hook that validates changes made by a script.

Björn Persson


pgppkAN1N_aVJ.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: Re: Mass rebuild: git push --no-verify

[kevin]

On Thu, Jan 18, 2024 at 08:24:38PM +0100, Björn Persson wrote:
> 
> If, hypothetically, a defect in the mass-rebuild script would corrupt
> thousands of spec files, how easy would it be to write a mass-revert
> script to repair the damage? The mass-revert script shouldn't just
> revert the latest commit in every package, because the corruption might
> not have happened in every package, and some might have been reverted
> manually in the meantime. The mass-revert script would need to verify
> that it reverts only commits done by the defective mass-rebuild script.
> 
> If that's nontrivial to get right, then it seems to me that there is
> value in a hook that validates changes made by a script.

That seems pretty hypothetical.

The pre-push check simply looks at the sources/patches defineed in the
spec and checks them against the sources file. The mass rebuild script
only uses rpmdev-bumpspec, which should only change the release and add
a changelog entry (or even less if the spec is using rpmautospec).

Should these font packages get fixed? Absolutely. 
But I think doing no-verify helps us because we will track more of those
packages that were simply skipped. I think it's better to not skip them
and have them fail than ignore them.

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

Re: -fcf-protection dropped from i686 compiler flags

[Michael Catanzaro]

Unfortunately this is causing gating tests to fail for rawhide builds, 
e.g.:


https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/

Hardened: /usr/bin/pkcon: FAIL: cf-protection test because 
.note.gnu.property section did not contain the necessary flags


I'm not sure whether to report a bug to rpminspect or to annocheck. One 
or the other needs to stop testing for this.


The timing is unfortunate because the mass rebuild has started today. 
I'm not sure what the impact will be. I guess packages will build, but 
get stuck in gating?


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

Re: -fcf-protection dropped from i686 compiler flags

[Adam Williamson]

On 2024-01-18 12:28, Michael Catanzaro wrote:


Unfortunately this is causing gating tests to fail for rawhide builds, 
e.g.:


https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/

Hardened: /usr/bin/pkcon: FAIL: cf-protection test because 
.note.gnu.property section did not contain the necessary flags


I'm not sure whether to report a bug to rpminspect or to annocheck. One 
or the other needs to stop testing for this.


The timing is unfortunate because the mass rebuild has started today. 
I'm not sure what the impact will be. I guess packages will build, but 
get stuck in gating?


rpminspect does not gate by default. None of the tests run by Fedora CI 
(any test whose name as shown in Bodhi begins with 'fedora-ci') gates by 
default, in fact.


Only packages which opt in to gating on these tests via their 
per-package gating.yaml files should be gated by failures of Fedora CI 
tests.


The only tests that gate packages *without* a per-package gating.yaml 
are the openQA tests that gate critpath packages (the names for these 
always start with 'update.').


In Bodhi's 'automated test results' table, gating tests have an asterisk 
as the first item in their row. Non-gating tests do not.

--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Linux 40 Change Proposal Submission Deadlines have now passed

[Aoife Moloney]

Hi all,

Please note that we are now past all change proposal submission deadlines.
Thank you to all who have submitted changes to Fedora Linux 40. If you have
changes accepted, please note your changes must be in a 'Testable
'
state by *6th Feb 2024*. Changes currently in the early feedback stage, i.e
the part of the process where the change is announced for broad visibility
to be discussed and iterated on where necessary before submission to FESCo
for voting, are the following:


   - Changes/ArmMinimalImageOSBuild
   
   - Changes/DefaultBpfman
   
   - Changes/Fedora IoT Bootable Container
   
   - Changes/Fedora IoT Unified Core
   
   - Changes/GNUToolchainF40
   
   - Changes/IBus 1.5.30
   
   - Changes/ibus-anthy 1.5.16
   
   - Changes/Optimized Binaries for the AMD64 Architecture
   

   - Changes/PytorchRelese
   
   - Changes/Replace iotop with iotop-c
   
   - Changes/ROCm6Release
   


View the Releases/40/ChangeSet
 wiki page for the
current set of accepted changes, and the Fedora Linux 40 schedule
 for
other key milestones and dates for this release.



Kindest regards,
Aoife
-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, 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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
>
> I'll be building boost, tbb, and the packages that depend on them in
> the f40-build-side-81691
> side tag over the next few hours (in advance of the mass rebuild tomorrow).
>
> If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> don't rebuild it in rawhide, we're building it in the side tag and
> will merge it back to rawhide. If you need to update your package
> before the mass rebuild, please let me and Patrick (CC'd) know and
> your changes can be built in the side tag too.
>
> (Since there is overlap between the packages that depend on boost and
> tbb I'm doing them all at once)
> https://fedoraproject.org/wiki/Changes/F40Boost183
> https://fedoraproject.org/wiki/Changes/F39TBB2020.3

Most of the packages have now been rebuilt and will be merged to
rawhide soon (I hope!).
See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2

The following packages failed to build, for the reasons shown. Some
other packages that depend on these ones couldn't be built due to
these failures. There are some others that weren't rebuild, like
OpenImageIO and python-graph-tool, but the maintainers are aware.

root
unit tests 213 - gtest-math-matrix-test-testMatrixTSparse (Failed)

0ad
../../contrib/libzip/mkstemp.c:76:15: error: implicit declaration of
function ‘getpid’ [-Wimplicit-function-declaration]

botan
unit tests fail?

codeblocks
needs non-existent squirrel-devel.i686

easystroke
cellrenderertextish.c:422:56: error: assignment to ...
[-Wincompatible-pointer-types]

espresso
unit tests fail?

galera
Errors while running CTest

glob2
scons-3: command not found

gnucash
gnucash-5.5/redhat-linux-build/bindings/python/gnucash_core.c: error:
-Wno-implicit-int detected - is this intentional ? [-Werror]

heaptrack
Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)

libpst
configure: error: cannot import Python module "distutils".

libzypp
libzypp-17.31.8/zypp-curl/proxyinfo/proxyinfolibproxy.h:18:10: fatal
error: proxy.h: No such file or directory

nextpnr
gui/quadtree.h:228:20: error: assignment of read-only member

osmium-tool
rapidjson/document.h:319:82: error: assignment of read-only member
‘rapidjson::GenericStringRef::length’

prusa-slicer
PrusaSlicer-version_2.4.2/src/slic3r/GUI/Plater.cpp:5128:21: error:
call of overloaded ‘load_files()’ is
ambiguous

slic3r
The package does -std=c++NN -U__STRICT_ANSI__ which is dumb and
doesn't work. Just use -std=gnu++NN instead, which actually works.
bits/c++config.h:2509:2: warning: #warning "__STRICT_ANSI__ seems to
have been undefined; this is not supported" [-Wcpp]

systemtap
new GCC warnings promoted to errors with -Werror

vtk
linker error: "defined in discarded section"
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Thu, 18 Jan 2024 at 22:15, Jonathan Wakely  wrote:
> heaptrack
> Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)

This one's already fixed in dist-git! (thanks, aleasto)
--
___
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: Fedora Linux 40 Change Proposal Submission Deadlines have now passed

[Elliott Sales de Andrade]

On Thu, Jan 18, 2024 at 4:33 PM Aoife Moloney  wrote:

> Hi all,
>
> Please note that we are now past all change proposal submission deadlines.
> Thank you to all who have submitted changes to Fedora Linux 40. If you have
> changes accepted, please note your changes must be in a 'Testable
> '
> state by *6th Feb 2024*. Changes currently in the early feedback stage,
> i.e the part of the process where the change is announced for broad
> visibility to be discussed and iterated on where necessary before
> submission to FESCo for voting, are the following:
>
>- Changes/ArmMinimalImageOSBuild
>
>- Changes/DefaultBpfman
>
>- Changes/Fedora IoT Bootable Container
>
>- Changes/Fedora IoT Unified Core
>
>- Changes/GNUToolchainF40
>
>- Changes/IBus 1.5.30
>
>- Changes/ibus-anthy 1.5.16
>
>- Changes/Optimized Binaries for the AMD64 Architecture
>
> 
>- Changes/PytorchRelese
>
>
>
Is it possible to fix the typo in the Wiki URL?


>
>- Changes/Replace iotop with iotop-c
>
>- Changes/ROCm6Release
>
>
> View the Releases/40/ChangeSet
>  wiki page for the
> current set of accepted changes, and the Fedora Linux 40 schedule
>  for
> other key milestones and dates for this release.
>
> Kindest regards,
> Aoife
>
--
___
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)

[Fabio Valentini]

On Tue, Jan 16, 2024 at 2:43 PM Dridi Boukelmoune
 wrote:
>
> > 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.

But ... you would be able to do this if the proposal was implemented
as-is, as well?
The "non-optimized" variant would still be installed, and PATH would
be set appropriately to fall back to it if you stick the hard drive
into an old machine
(unless I misunderstand the proposal, or your argument here).

Just to give my 2¢ here as well, I was skeptical about the "systemd
sets the $PATH appropriately for the hardware it's booting on", but I
actually like that approach now. Using symbolic links smells too much
like using alternatives, and those have always been a bit brittle.

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

Re: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
>
> I'll be building boost, tbb, and the packages that depend on them in
> the f40-build-side-81691
> side tag over the next few hours (in advance of the mass rebuild tomorrow).
>
> If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> don't rebuild it in rawhide, we're building it in the side tag and
> will merge it back to rawhide. If you need to update your package
> before the mass rebuild, please let me and Patrick (CC'd) know and
> your changes can be built in the side tag too.

Please DO NOT build your package in rawhide if we're rebuilding it in
the boost side tag. It will require another rebuild in the side tag
and another bodhi update and delay the mass rebuild by several more
hours while the gating tests run.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely  wrote:
>
> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
> >
> > I'll be building boost, tbb, and the packages that depend on them in
> > the f40-build-side-81691
> > side tag over the next few hours (in advance of the mass rebuild tomorrow).
> >
> > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > don't rebuild it in rawhide, we're building it in the side tag and
> > will merge it back to rawhide. If you need to update your package
> > before the mass rebuild, please let me and Patrick (CC'd) know and
> > your changes can be built in the side tag too.
>
> Please DO NOT build your package in rawhide if we're rebuilding it in
> the boost side tag. It will require another rebuild in the side tag
> and another bodhi update and delay the mass rebuild by several more
> hours while the gating tests run.

OK, the side tag has been merged. Builds can be done in rawhide again now.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Sérgio Basto]

On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
> On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> wrote:
> > 
> > On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> > wrote:
> > > 
> > > I'll be building boost, tbb, and the packages that depend on them
> > > in
> > > the f40-build-side-81691
> > > side tag over the next few hours (in advance of the mass rebuild
> > > tomorrow).
> > > 
> > > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > > don't rebuild it in rawhide, we're building it in the side tag
> > > and
> > > will merge it back to rawhide. If you need to update your package
> > > before the mass rebuild, please let me and Patrick (CC'd) know
> > > and
> > > your changes can be built in the side tag too.
> > 
> > Please DO NOT build your package in rawhide if we're rebuilding it
> > in
> > the boost side tag. It will require another rebuild in the side tag
> > and another bodhi update and delay the mass rebuild by several more
> > hours while the gating tests run.
> 
> OK, the side tag has been merged. Builds can be done in rawhide again
> now.


not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
needs pass in all "Test Gating" or is running again "Test Gating" for
new build(s)

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

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

[Sérgio Basto]

On Thu, 2024-01-18 at 09:13 -0700, Jerry James wrote:
> On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto 
> wrote:
> > 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 ?
> 
> Thank you for the pointer, Sérgio.  I have opened
> https://pagure.io/releng/pull-request/11897.
> 
> It is not rpmdev-bumpspec that fails.  That works just fine.  But any
> package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
> requires --no-verify today when pushing to git, due to the referenced
> bug.  That's merely annoying for a human, but fatal to an automated
> build script that doesn't pass --noverify.

ok, is git push that fails .
As an idea , you may do "no verify" build option like noautobuild, in
line 143 of mass-rebuild.py [1] we have "Check for a noautobuild file"
to optout to skip mass rebuild, we may add an option in similar way for
noverify push, for example file "noverifybuild" . 

Kodi use noautobuild (and it works :) ) :
https://github.com/rpmfusion/kodi/ 
 
[1]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_143


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

KDE Plasma 6 Sets Release Date

[Ryan Bach via devel]

https://www.linux-magazine.com/Online/News/KDE-Plasma-6-Sets-Release-Date

February 28th, 2024. Mark your calendars, as that's the official date the KDE 
team has set for the release of KDE Plasma 6.0.
--
___
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