Fedora-Cloud-35-20211220.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-35-20211219.0):

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

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

Fedora-Cloud-34-20211220.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

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

Schedule for Monday's FESCo Meeting (2021-12-20)

[Zbigniew Jędrzejewski-Szmek]

Following is the list of topics that will be discussed in the
FESCo meeting Monday at 19:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2021-12-20 19:00 UTC'


Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2706 F36 Change: PostgreSQL 14
https://pagure.io/fesco/issue/2706
APPROVED (+7,0,-0)

#2707 F36 Change: LXQt 1.0
https://pagure.io/fesco/issue/2707
APPROVED (+6, 0, -0)

#2708 F36 Change: Users are administrators by default in the installer GUI
https://pagure.io/fesco/issue/2708
APPROVED (+7,0,-0)


= Followups =

= New business =

New meeting time

#2711 F36 Change: Enable fs-verity in RPM
https://pagure.io/fesco/issue/2711

#2713 F36 Change: Make Rescue Mode Work With Locked Root
https://pagure.io/fesco/issue/2713


= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 


I'm not convinced that we'll have quorum today, since many people are
already on vacation. No matter if we hold the meeting or not, let's
plan to meet 3/1/2022. In other words, the meeting between X-mas and
New Year is hereby cancelled.

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

Non-responsive maintainer check for Eric Smith (brouhaha)

[Dominik 'Rathann' Mierzejewski]

Hi,

This is a non-responsive maintainer check for Eric Smith (brouhaha).

I've been maintaining solaar for over two years now. It was maintained
by tibbs before. I asked the original maintainer, Eric Smith to change
the default bugzilla assignee to myself several times in the past. The
last time was on September 13th this year. There was no response.

I've just filed the required Non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2034199

Does anyone know how to contact Eric?  Direct email and bug reports have had
no response.

Thanks and regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: debug_package when using go_generate_buildrequires

[Panu Matilainen]

On 12/20/21 01:39, Robert-André Mauchin wrote:

On 12/6/21 12:42, Mikel Olasagasti wrote:

Hi all,

I was updating some golang specs I've and switching them to use
go_generate_buildrequires.

I realized that some specs that are using it fail to build if `%global
debug_package %{nil}` is not set. Same spec with all BuildRequires
defined works just fine.

Example:

- Full spec (go2rpm):
https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec 


- go_generate_buildrequires spec:
https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec 



- Full spec build: 
https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572

- go_generate_buildrequires build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147

Is this expected?
Is adding `%global debug_package %{nil}` correct or good practice for
this scenario?

Kind regards,
Mikel Olasagasti (mikelo2)


Hello,

Yes this is an issue I have noticed but I don't know where/what causes it.

I know that if we have a %build section it will cause the debug info to 
be looked for. It does it too with %generate_buildrequires and I think 
it shouldn't, but I don't know if this is a behavior triggered by rpm 
itself or is it triggered somewhere else during the build process?


CC Panu and Devel to weigh in.

In the meantime, as long as you don't have a %build section and thus do 
not produce a binaries, you can use %global debug_package %{nil}


Having to disable debug packages practically always indicates a bug in 
the package - either packaging, upstream or both.


Typical causes for "error: Empty %files file 
<...>/debugsourcefiles.list" are missing debug info in the build (eg -g 
flag of gcc) and building outside the designated build directory. 
Unfortunately diagnosing these from rpm isn't easy.


"%global debug_package %{nil}" is always a workaround and never a fix.

 - Panu -



Best regards,

Robert-André


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

Re: Non-responsive Maintainer Check for ishcherb

[Miro Hrončok]

On 19. 12. 21 19:03, Miro Hrončok wrote:

On 19. 12. 21 18:26, Maxwell G via devel wrote:

Hi everyone,

I hope you are having/had a good weekend. I am sending this email in 
accordance with the Non-Responsive Maintainer Policy[0].


I created a non-responsive maintainer bug[1] for @ishcherb over two weeks ago 
and have not received a response. I am happy to help maintain this package.


A month ago, I created a PR[2] to update `python-ansi2html` to the latest 
upstream release (1.6.0) and implement the new Python Packaging Guidelines. 
The PR did not receive a response from the package's main maintainer 
(@ishcherb) nor the co-maintainer (@ralph). The latest upstream version, 
1.6.0, was released a year ago. The release-monitoring bug[3] for this 
release similarly did not receive a response from the maintainers.


...

Does anyone know if @ishcherb and @ralph are still active in Fedora?


@ishcherb is a former teammate of mine and I think she is no longer active in 
Fedora, but I'll try to ask her.


Indeed she's not. I see she assigned python-ansi2html to you, so all is well?

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

Re: debug_package when using go_generate_buildrequires

[Bob Mauchin]

On Mon, 20 Dec 2021, 14:09 Panu Matilainen,  wrote:

> On 12/20/21 01:39, Robert-André Mauchin wrote:
> > On 12/6/21 12:42, Mikel Olasagasti wrote:
> >> Hi all,
> >>
> >> I was updating some golang specs I've and switching them to use
> >> go_generate_buildrequires.
> >>
> >> I realized that some specs that are using it fail to build if `%global
> >> debug_package %{nil}` is not set. Same spec with all BuildRequires
> >> defined works just fine.
> >>
> >> Example:
> >>
> >> - Full spec (go2rpm):
> >>
> https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec
> >>
> >> - go_generate_buildrequires spec:
> >>
> https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec
> >>
> >>
> >> - Full spec build:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572
> >> - go_generate_buildrequires build:
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147
> >>
> >> Is this expected?
> >> Is adding `%global debug_package %{nil}` correct or good practice for
> >> this scenario?
> >>
> >> Kind regards,
> >> Mikel Olasagasti (mikelo2)
> >
> > Hello,
> >
> > Yes this is an issue I have noticed but I don't know where/what causes
> it.
> >
> > I know that if we have a %build section it will cause the debug info to
> > be looked for. It does it too with %generate_buildrequires and I think
> > it shouldn't, but I don't know if this is a behavior triggered by rpm
> > itself or is it triggered somewhere else during the build process?
> >
> > CC Panu and Devel to weigh in.
> >
> > In the meantime, as long as you don't have a %build section and thus do
> > not produce a binaries, you can use %global debug_package %{nil}
>
> Having to disable debug packages practically always indicates a bug in
> the package - either packaging, upstream or both.
>
> Typical causes for "error: Empty %files file
> <...>/debugsourcefiles.list" are missing debug info in the build (eg -g
> flag of gcc) and building outside the designated build directory.
> Unfortunately diagnosing these from rpm isn't easy.
>
> "%global debug_package %{nil}" is always a workaround and never a fix.
>
>  - Panu -
>
> >
> > Best regards,
> >
> > Robert-André
> >


Yes I know, but not in this case as go libraries are noarch.
The problem that when we add the %generate_buildrequires section, it
triggers the detection of the debug info. Without it, the detection of
debug info is skipped so the package builds normally. I don't know what is
the expected behavior.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: debug_package when using go_generate_buildrequires

[Panu Matilainen]

On 12/20/21 16:02, Bob Mauchin wrote:



On Mon, 20 Dec 2021, 14:09 Panu Matilainen, > wrote:


On 12/20/21 01:39, Robert-André Mauchin wrote:
 > On 12/6/21 12:42, Mikel Olasagasti wrote:
 >> Hi all,
 >>
 >> I was updating some golang specs I've and switching them to use
 >> go_generate_buildrequires.
 >>
 >> I realized that some specs that are using it fail to build if
`%global
 >> debug_package %{nil}` is not set. Same spec with all BuildRequires
 >> defined works just fine.
 >>
 >> Example:
 >>
 >> - Full spec (go2rpm):
 >>

https://mikel.olasagasti.info/tmp/fedora/golang-github-alecaivazis-survey-2.spec



 >>
 >> - go_generate_buildrequires spec:
 >>

https://raw.githubusercontent.com/mikelolasagasti/github-cli/main/golang-github-alecaivazis-survey-2.spec



 >>
 >>
 >> - Full spec build:
 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=79642572

 >> - go_generate_buildrequires build:
 >> https://koji.fedoraproject.org/koji/taskinfo?taskID=79642147

 >>
 >> Is this expected?
 >> Is adding `%global debug_package %{nil}` correct or good
practice for
 >> this scenario?
 >>
 >> Kind regards,
 >> Mikel Olasagasti (mikelo2)
 >
 > Hello,
 >
 > Yes this is an issue I have noticed but I don't know where/what
causes it.
 >
 > I know that if we have a %build section it will cause the debug
info to
 > be looked for. It does it too with %generate_buildrequires and I
think
 > it shouldn't, but I don't know if this is a behavior triggered by
rpm
 > itself or is it triggered somewhere else during the build process?
 >
 > CC Panu and Devel to weigh in.
 >
 > In the meantime, as long as you don't have a %build section and
thus do
 > not produce a binaries, you can use %global debug_package %{nil}

Having to disable debug packages practically always indicates a bug in
the package - either packaging, upstream or both.

Typical causes for "error: Empty %files file
<...>/debugsourcefiles.list" are missing debug info in the build (eg -g
flag of gcc) and building outside the designated build directory.
Unfortunately diagnosing these from rpm isn't easy.

"%global debug_package %{nil}" is always a workaround and never a fix.

          - Panu -

 >
 > Best regards,
 >
 > Robert-André
 >


Yes I know, but not in this case as go libraries are noarch.
The problem that when we add the %generate_buildrequires section, it 
triggers the detection of the debug info. Without it, the detection of 
debug info is skipped so the package builds normally. I don't know what 
is the expected behavior.


Okay, this wasn't quite so clear in the initial context. 
%generate_buildrequires should not trigger the debuginfo machinery, 
that's a bug of some sort. Please file a ticket at 
https://github.com/rpm-software-management/rpm


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

Rust Stack Spring Cleaning (in Winter)

[Fabio Valentini]

Hello Rust packagers,

(I'm sending this email to the devel and rust lists, and I've added all directly
affected package maintainers in Bcc - because adding them all to the "To" or
"CC" fields would make the lists reject this message, I believe.)

I have been working on and preparing some more clean-ups in the Rust stack, and
I came across a large-ish number of Rust packages that were imported to Fedora,
but the recommended "initial setup" for them was never finished.

I have started by adding them all "rust-*" packages to koschei, which makes it
way easier for me to see at a glance whether there are any broken packages in
our Rust stack at any point in time.

I will also make sure all those packages are correctly set up with anitya /
release-monitoring.org, so that we actually get notifications for new versions
of all those crate packages.

Additionally, I would ask of all of you to make sure all your packages have been
added to the @rust-sig group on src.fedoraproject.org (at least with "commit"
access). Without that, it makes it very hard for us to keep the Rust stack
up-to-date and in working order, because the "rust-sig" list / bugzilla account
does not get CC'd on new bugs that way, and your bugs do not show up in our
BugZilla queries.

For example, I have been working on packaging and updating the RustCrypto
stack of crates, and found that most of the already existing
(security-sensitive!) crates are not "completely" set up, and are now out of
date, just because I didn't even know about those packages (and some were also
not set up with release-monitoring.org).

In the interest of keeping the Rust stack in Fedora in a good state, please
add "@rust-sig" group to all you Rust packages on src.fedoraproject.org, unless
there is a very good reason not to do so (and if that is the case for a
particular package in this list, I'd be interested in knowing the reason, as
well).

If you want a scripted way of adding "@rust-sig" group to many packages, you
can generate an API token on src.fedoraproject.org (with "Modify an existing
project") access level, and use the simple Python script from this GitHub gist:

https://gist.github.com/decathorpe/9d128982cb00e2d345d9e397372538ec

Below is the list of "incompletely set-up" packages, in alphabetic order, and
at the bottom, there is a list of packages per affected package maintainer.

Thanks,
Fabio

===

- rust-arrayvec0.5: eclipseo
- rust-asn1: cheimes
- rust-asn1_derive: cheimes
- rust-assert-impl: dcavalca
- rust-aws-nitro-enclaves-cose: pbrobinson
- rust-benfred-read-process-memory: dcavalca
- rust-biscuit: orphan
- rust-bitfield: ignatenkobrain
- rust-block-cipher: ignatenkobrain
- rust-blsctl: javierm
- rust-btrd: dcavalca
- rust-bytelines: ignatenkobrain
- rust-clap_generate: eclipseo
- rust-clap_generate_fig: eclipseo
- rust-clircle: eclipseo
- rust-combine: dcavalca
- rust-console0.13: ignatenkobrain
- rust-cryptoki: pbrobinson
- rust-cryptoki-sys: pbrobinson
- rust-cty: nickblack
- rust-dbus-codegen: pbrobinson
- rust-dbus-crossroads: pbrobinson
- rust-derivative: pbrobinson
- rust-directories-next: jbtrystram
- rust-dirs2: ignatenkobrain
- rust-elf: dcavalca
- rust-enumflags2: ignatenkobrain, pbrobinson
- rust-env_proxy: dcavalca
- rust-epoll: slp
- rust-event-listener: dcavalca
- rust-fasteval: zbyszek
- rust-hostname-validator: ignatenkobrain
- rust-inferno: dcavalca
- rust-itertools0.9: ignatenkobrain
- rust-josekit: pbrobinson
- rust-js-sys: pbrobinson
- rust-keccak: pbrobinson
- rust-log-panics: salimma
- rust-mbox: ignatenkobrain, pbrobinson
- rust-navi: jbtrystram
- rust-netlink-packet-core: cathay4t, ffmancera
- rust-netlink-packet-route: cathay4t, ffmancera
- rust-netlink-packet-utils: cathay4t, ffmancera
- rust-netlink-proto: cathay4t, ffmancera
- rust-netlink-sys: cathay4t, ffmancera
- rust-num-format: dcavalca
- rust-oauth2: ctron, jbtrystram
- rust-oid: pbrobinson
- rust-openat-ext: walters
- rust-pam-sys: eneville
- rust-parsec-client: pbrobinson
- rust-parsec-interface: pbrobinson
- rust-picky-asn1: pbrobinson
- rust-picky-asn1-der: pbrobinson
- rust-picky-asn1-x509: pbrobinson
- rust-psa-crypto: pbrobinson
- rust-pkcs11: pbrobinson
- rust-pleaser: eneville
- rust-process_control: atim, petersen
- rust-proc-maps: dcavalca
- rust-prost: pbrobinson
- rust-prost-build: pbrobinson
- rust-prost-derive: pbrobinson
- rust-prost-types: pbrobinson
- rust-psa-crypto-sys: pbrobinson
- rust-qstring: ctron, jbtrystram
- rust-rand0.7: ignatenkobrain
- rust-rand_chacha0.2: ignatenkobrain
- rust-rand_core0.5: ignatenkobrain
- rust-rand_pcg0.2: ignatenkobrain
- rust-rbspy-ruby-structs: dcavalca
- rust-rbspy-testdata: dcavalca
- rust-read-process-memory: dcavalca
- rust-remoteprocess: dcavalca
- rust-rsa: pbrobinson
- rust-rtnetlink: cathay4t, ffmancera
- rust-sd-notify: pbrobinson
- rust-secrecy: pbrobinson
- rust-serde_with: pbrobinson
- rust-sha3: pbrobinson
- rust-shadow-rs: atim
- rust-shellwords: jbtrystram
- rust-signal-hook-mio: dcavalca
- rust-sign

Creating users/groups in RPMs with EL7 compatibility

[Ewoud Kohl van Wijngaarden]

Hello everyone,

I'm looking at modernizing the upstream Jenkins RPM packaging and 
reading through the packaging guidelines[1]. I see some decent macros 
but these are incompatible with EL7. What would be the recommendation 
for RPM specs that should work on EL7 and newer?


Regards,
Ewoud Kohl van Wijngaarden

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

Re: About how Go is updated in Fedora

[Colin Walters]

On Sat, Dec 18, 2021, at 5:06 PM, Fabio Valentini wrote:
> 
> Sure, I saw that ticket. But I fail to see how this is this a "new problem".
> If you use, for example, some shiny, new features that are only going
> to be in GCC 12 or LLVM 14, 

There's a *big* difference between Go and C/C++/Rust though, which is that the 
version of the Go compiler you use at build time becomes the version of the Go 
*runtime* statically linked into your binary, with implications for things like 
GC performance.

Go's 6-month cadence is also much faster than C/C++ (though also much slower 
than Rust's, but the Rust 6 week releases are also smaller, and anyways 
generally the ecosystem is OK with "older" Rust compilers).  Also relating to 
the release cycle, Go releases tend to add new features that parts of the 
ecosystem adapt relatively quickly.  That seems likely to continue with 1.18 
and the early generics.

> you'd be out of luck on stable Fedora
> branches, as well.

Not quite; one doesn't need to use the single Go compiler version in RPM form 
from Fedora except currently when shipping software built as Fedora RPMs.  (I 
know this was implicit in this discussion, but it's worth noting because people 
can and do get the Go compiler from e.g. upstream on Fedora systems too to 
build and ship software outside of the Fedora package collection itself)

That said, I don't quite understand why it's so complex to use modularity as 
part of building non-modular RPMs.  (But I know this was extensively discussed, 
I didn't follow it really)
It seems like it's more about maintaining multiple builds of the 
compiler/runtime.

It's interesting to note that in CentOS Stream 8, go-toolset is modularized, 
but that's not true in CentOS Stream 9.

Also related to this, it's worth looking at what others do; e.g. NixOS seems to 
maintain a few versions of Go: 
https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/go
But they only have one Rust version.  Although there are a ton of derivations 
for gcc and llvm, I suspect only a few are used.  

It looks like Debian ships package+versions, e.g. `golang` is 1.17, and there's 
`golang-1.15` in unstable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Unable to login as root with a recent Rawhide Fedora Cloud image

[Ondrej Mosnacek]

Hi,

When I set up a rawhide cloud image
(Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
download.fedoraproject.org) with a root password using virt-sysprep:

virt-sysprep -a  --root-password password:123456
--selinux-relabel [...]

...I am unable to login as root on the console once I boot it. When I
enter "root" in the login prompt, I immediately get "Login incorrect"
(it doesn't even ask for password). With the F35 Cloud image I can
login just fine with the same procedure.

Anyone know if this is an intentional change or a bug? If it's
intentional, what do I need to do to make root login work again? If
it's a bug, any idea which component to report it against?

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

Re: About how Go is updated in Fedora

[Stephen John Smoogen]

On Mon, 20 Dec 2021 at 10:16, Colin Walters  wrote:
>
>
>
> On Sat, Dec 18, 2021, at 5:06 PM, Fabio Valentini wrote:
> >
> > Sure, I saw that ticket. But I fail to see how this is this a "new problem".
> > If you use, for example, some shiny, new features that are only going
> > to be in GCC 12 or LLVM 14,
>
> There's a *big* difference between Go and C/C++/Rust though, which is that 
> the version of the Go compiler you use at build time becomes the version of 
> the Go *runtime* statically linked into your binary, with implications for 
> things like GC performance.
>
> Go's 6-month cadence is also much faster than C/C++ (though also much slower 
> than Rust's, but the Rust 6 week releases are also smaller, and anyways 
> generally the ecosystem is OK with "older" Rust compilers).  Also relating to 
> the release cycle, Go releases tend to add new features that parts of the 
> ecosystem adapt relatively quickly.  That seems likely to continue with 1.18 
> and the early generics.
>
> > you'd be out of luck on stable Fedora
> > branches, as well.
>
> Not quite; one doesn't need to use the single Go compiler version in RPM form 
> from Fedora except currently when shipping software built as Fedora RPMs.  (I 
> know this was implicit in this discussion, but it's worth noting because 
> people can and do get the Go compiler from e.g. upstream on Fedora systems 
> too to build and ship software outside of the Fedora package collection 
> itself)
>
> That said, I don't quite understand why it's so complex to use modularity as 
> part of building non-modular RPMs.  (But I know this was extensively 
> discussed, I didn't follow it really)
> It seems like it's more about maintaining multiple builds of the 
> compiler/runtime.
>

The following is based on the lessons learned from EPEL-8.
Koji does not really know much about modules or even RPMs beyond a
src.rpm. So when koji is putting together a build root it will pull in
things which best satisfy a spec files requires.

Case 1:
Module A:
- golang-17
- golang-foo-3.4-

Module B:
- golang-18
- golang-foo-3.4

In this case, you could define a spec which requires golang-17 but
koji's dep resolver pulls in golang-foo- from Module B for non-modular
packages. This breaks the build.

Case 2:
Module A
:
- golang-17
- golang-foo-3.4-

Module B:
- golang-18
- golang-foo-3.4
or
- golang-foo-3.3 

Koji's dep resolver in this case will then pull in Module A's
golang-foo for any 'non-modular' package which required golang-foo.

You can configure koji to do a slightly different depsolving using dnf
versus the koji algorithms, which fix things in that only default
modules may get enabled in mock. [However may is a strong word.. it
sometimes does not.]

The fixes to this are:
a) use a tool like grobisplitter which breaks out all modules into
separate repositories versus 'virtual repositories'. This allows koji
and mock better ability to sort out what is the right package to put
into the buildroot.
b) use a script program like ursa major which basically hardwires in
MBS determinations. This works for EL8/EL9 because the changes in
modules has to go through a lot of internal checklists and such to
make sure the script is updated and doesn't break in builds. It
doesn't work that well in Fedora unless we put in similar 'please mark
this package as to be used for this and get a PR signoff' [or someone
writes and maintains a tool to do this which they did in MBS...]
c) everything which uses a module, requires to be a module. Then MBS
does all this determination and tells koji -> I don't care what you
think, tag in Module-B's golang-foobar for this build.
d) someone replaces koji with a build system which knows about MBS and
other meta-tools.

> It's interesting to note that in CentOS Stream 8, go-toolset is modularized, 
> but that's not true in CentOS Stream 9.
>
> Also related to this, it's worth looking at what others do; e.g. NixOS seems 
> to maintain a few versions of Go: 
> https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/compilers/go
> But they only have one Rust version.  Although there are a ton of derivations 
> for gcc and llvm, I suspect only a few are used.
>
> It looks like Debian ships package+versions, e.g. `golang` is 1.17, and 
> there's `golang-1.15` in unstable.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing 

Re: Unable to login as root with a recent Rawhide Fedora Cloud image

[Stephen John Smoogen]

On Mon, 20 Dec 2021 at 10:31, Ondrej Mosnacek  wrote:
>
> Hi,
>
> When I set up a rawhide cloud image
> (Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
> download.fedoraproject.org) with a root password using virt-sysprep:
>
> virt-sysprep -a  --root-password password:123456
> --selinux-relabel [...]
>

I believe this is intentional. Please see emails with subjects:

F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)
F36 Change: Users are administrators by default in the installer GUI.
(Self-Contained Change proposal)

there may be some others. Basically root login is no longer allowed
via PAM and possibly other tools. My understanding is that you need to
login as a user, and then become root.


> ...I am unable to login as root on the console once I boot it. When I
> enter "root" in the login prompt, I immediately get "Login incorrect"
> (it doesn't even ask for password). With the F35 Cloud image I can
> login just fine with the same procedure.
>
> Anyone know if this is an intentional change or a bug? If it's
> intentional, what do I need to do to make root login work again? If
> it's a bug, any idea which component to report it against?
>
> Thanks,
> --
> Ondrej Mosnacek
> Software Engineer, Linux Security - SELinux kernel
> Red Hat, Inc.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



--
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Authselect Mandatory (System-Wide Change proposal)

[Colin Walters]

On Tue, Oct 12, 2021, at 11:32 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Make_Authselect_Mandatory

Just to raise the visibility here, this currently breaks all ostree-based 
systems (*again*):

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

Re: Unable to login as root with a recent Rawhide Fedora Cloud image

[Adam Williamson]

On Mon, 2021-12-20 at 10:43 -0500, Stephen John Smoogen wrote:
> On Mon, 20 Dec 2021 at 10:31, Ondrej Mosnacek  wrote:
> > 
> > Hi,
> > 
> > When I set up a rawhide cloud image
> > (Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
> > download.fedoraproject.org) with a root password using virt-sysprep:
> > 
> > virt-sysprep -a  --root-password password:123456
> > --selinux-relabel [...]
> > 
> 
> I believe this is intentional. Please see emails with subjects:
> 
> F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change 
> proposal)
> F36 Change: Users are administrators by default in the installer GUI.
> (Self-Contained Change proposal)
> 
> there may be some others. Basically root login is no longer allowed
> via PAM and possibly other tools. My understanding is that you need to
> login as a user, and then become root.

No, I don't think that's it. None of those changes is meant to preclude
explicitly setting a root password.

I think this is actually a bug in Rawhide since 20211215.n.0 . I did
not investigate it in detail since I'm on PTO, my colleague Frantisek
Zatloukal (CC'ed) is looking into it. We see the same problem with any
login attempt on console after a minimal install; it works OK after a
Server install. The Workstation live images also fail to boot, they
just get stuck at the splash screen. We're not sure yet if it's two
different problems.

The most likely suspect seems to be:

Package:  authselect-1.3.0-3.fc36
Old package:  authselect-1.2.4-2.fc36

So CCing pbrezina. It's notable that the bug doesn't happen on upgraded
systems - there's a test that starts from a minimal install of F35 and
upgrades to F36, and that test works OK. So I suspect the problem
occurs when the installer tries to do initial authselect configuration
of the installed system. That's about as far as we got up to the
weekend. Frantisek has logs he could forward to pbrezina.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

F36 Change: LLVM 14 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LLVM-14

== Summary ==
Update all llvm sub-projects in Fedora Linux to version 14.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 



== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 14, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang13 and llvm13 will be added to ensure that
packages that currently depend on clang and llvm version 13 libraries
will continue to work.

Unlike previous releases, we will no longer be packaging release
candidate builds in Rawhide or F36.  Release candidates are not
guaranteed to be ABI compatible with each other, so upgrading from one
release candidate to another (or to the final release) requires
rebuilding all the clang/LLVM library users.  This has become very
difficult to coordinate given the increased number of packages using
the clang/LLVM libraries, so we decided to only package the final
release.

We do plan to build release candidate versions into a side-tag for
testing.  We will also create an llvm-14 branch in dist-git, so that
we can build the release candidate versions while still being able to
fix bugs and make changes to LLVM 13 in the rawhide branch.

'''Note: we are still discussing with Release Engineering if a branch
+ side-tag will be possible [https://pagure.io/releng/issue/10414
#10414].  If it's not possible, we will use COPR instead.'''


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.


== Scope ==
* Proposal owners:
** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Request an llvm-14 branch in dist-git for each llvm sub-project.
** Request a side-tag.
** Build llvm13 and clang13 compat packages into the side-tag.
** When upstream LLVM project releases version 14.0.0-rc1 (Late
January 2021), package this using the llvm-14 branches and build it
into the side-tag.
*** Repeat process for each release candidate.
** When upstream LLVM project releases version 14.0.0-final (March
2021), package this using the rawhide and f36 branches.


* Other developers:
** Maintainers of packages that depend on clang-libs or llvm-libs will
need to update their spec files to depend on the clang13 and llvm13
compatibility packages if they want to rebuild their package and it
does not work with LLVM 14 yet. The key point here is that spec file
changes are only needed if a package is going to be rebuilt after LLVM
14 is added to Fedora. The compatibility packages will ensure that
already built packages continue to work.

* Release engineering: [https://pagure.io/releng/issue/10414 #10414]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
14.


== User Experience ==
Users will benefit from new features and bug-fixes in the latest
version of LLVM.


== Dependencies ==
This change can be made without updating any other packages. However,
as mention before, packages that need to use LLVM 13 will need to
update their spec file on their first rebuild after this change.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?): If there are
major problems with LLVM 14, the compatibility package provide a way
for other packages to continue using LLVM 13.
* Contingency deadline: Final Freeze
* Blocks release? No

== Documentation ==
Release notes will be added for this change.

== Release Notes ==

LLVM sub-projects in Fedora have been updated to version 14:
* llvm
* clang
* lld
* lldb
* compiler-rt
* libomp
* llvm-test-suite
* libcxx
* libcxxabi
* python-lit
* flang
* mlir
* polly
* libclc
* llvm-unwind


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

F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Ben Cotton]

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

== Summary ==
Call %set_build_flags macro automatically at the beginning of the
%build and %check phases of RPM builds in Fedora Linux.  This will
ensure that the compiler flag environment variables are set for every
RPM build.


== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 


== Detailed Description ==
The %set_build_flags macro exports common environment variables used
for building packages:
* CFLAGS
* CXXFLAGS
* FFLAGS
* FCFLAGS
* LDFLAGS
* LT_SYS_LIBRARY_PATH
* CC
* CXX


These environment variables are set to the compiler flags defined in
the system RPM configuration.  This macro is currently implicitly
called when packages use some of the build system helper macros, like
%configure, %cmake, and %meson.  However, not all packages use these
macros and so some packages do not use the correct compiler flags as
required by the Fedora packaging guidelines[1].

This change will be implemented by updating the %__spec_build_pre and
%__speck_check_pre macros in redhat-rpm-config to include
%set_build_flags.  This will set these environment variables
automatically before the %build and %check sections.  See the proposed
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741bbebd645c46e5d675920b4bffe390c95bb?branch=set-build-flags-build-check
implementation] for more details.

The purpose for making this change in both the %build and %check
sections is because sometimes test code gets built in the %check
sections for unit tests and this will ensure that the application code
and its tests are built with the same set of flags.

This change should have no impact on packages that already use
%set_build_flags either directly or indirectly through another macro.
It also won't impact any package that currently sets these environment
variables or modifies any of the %{build*_flags} macros in their
%build or %check sections.

[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags


== Benefit to Fedora ==
This change will ensure that more packages are built using the correct
compiler flags, and bring them in compliance with the Fedora packaging
guidelines.  It will also help improve the security of the
distribution as many of the compiler flags help defend against common
security attacks.


== Scope ==
* Proposal owners:
** Make the necessary changes to redhat-rpm-config.
** Help debug any issues uncovered by this change during the mass rebuild.
* Other developers:
** Report bugs to the proposal owner.

* Release engineering: [https://pagure.io/releng/issue/10482 #10482]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== How To Test ==
This change will be tested by rebuilding packages as part of the mass rebuild.


== User Experience ==
This change will make some packages less susceptible to security exploits.


== Contingency Plan ==

* Contingency mechanism: The proposal owner will revert the change in
redhat-rpm-config
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
None needed.


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

F36 Change: Ruby 3.1 (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Ruby_3.1

== Summary ==
Ruby 3.1 is the latest stable version of Ruby. Many new features and
improvements are included for the increasingly diverse and expanding
demands for Ruby. With this major update from Ruby 3.0 in Fedora 35 to
Ruby 3.1 in Fedora 36, Fedora becomes the superior Ruby development
platform.

== Owner ==
* Name: [[User:vondruch| Vít Ondruch]]
* Email: vondr...@redhat.com


== Detailed Description ==
Ruby 3.1 is upstream's new major release of Ruby. Many new features
and improvements are included.

=== YJIT: New experimental in-process JIT compiler ===

Ruby 3.1 merges YJIT, a new in-process JIT compiler developed by Shopify.

Since Ruby 2.6 introduced MJIT in 2018, its performance greatly
improved, and finally we achieved Ruby3x3 last year. But even though
Optcarrot has shown impressive speedups, the JIT hasn’t benefited real
world business applications.

Recently Shopify contributed many Ruby improvements to speed up their
Rails application. YJIT is an important contribution, and aims to
improve the performance of Rails applications.

Though MJIT is a method-based JIT compiler and uses an external C
compiler, YJIT uses Basic Block Versioning and includes JIT compiler
inside it. With Lazy Basic Block Versioning (LBBV) it first compiles
the beginning of a method, and incrementally compiles the rest when
the type of arguments and variables are dynamically determined. See
YJIT: a basic block versioning JIT compiler for CRuby for a detailed
introduction.

With this technology, YJIT achieves both fast warmup time and
performance improvements on most real-world software, up to 22% on
railsbench, 39% on liquid-render.

YJIT is still an experimental feature, and as such, it is disabled by
default. If you want to use this, specify the --yjit command-line
option to enable YJIT. It is also limited to macOS & Linux on x86-64
platforms for now.

https://bugs.ruby-lang.org/issues/18229
https://shopify.engineering/yjit-just-in-time-compiler-cruby
https://www.youtube.com/watch?v=PBVLf3yfMs8

=== debug gem: A new debugger ===

A new debugger debug.gem is bundled. debug.gem is fast debugger
implementation and it provides many features like remote debugging,
colorful REPL, IDE (VSCode) integration and more. It replaces
lib/debug.rb standard library.

=== error_highlight: Fine-grained error location in backtrace ===

A built-in gem, error_highlight, has been introduced. It includes
fine-grained error location in backtrace:

$ ruby test.rb
test.rb:1:in `': undefined method `time' for 1:Integer (NoMethodError)

1.time {}
 ^
Did you mean?  times

This gem is enabled by default. You can disable it by using a
command-line option --disable-error_highlight. See the repository in
detail.

=== Irb improvement ===

=== Other Notable New Features ===

* Language
** Values in Hash literals and keyword arguments can be omitted.
** Pin operator in pattern matching now takes an expression.
* RBS
** `rbs collection` has been introduced to manage gems’ RBSs.
** Many signatures for built-in and standard libraries have been added/updated.
** It includes many bug fixes and performance improvements too.
* TypeProf
** Experimental IDE support has been implemented.
** Many bug fixes and performance improvements.

=== Performance improvements ===

* MJIT
** For workloads like Rails, the default --jit-max-cache is changed
from 100 to 1. The JIT compiler no longer skips compilation of
methods longer than 1000 instructions.
** To support Zeitwerk of Rails, JIT-ed code is no longer cancelled
when a TracePoint for class events is enabled.

=== Other notable changes since 3.0 ===

* One-line pattern matching, e.g., ary => [x, y, z], is no longer experimental.
* Multiple assignment evaluation order has been changed slightly.
** foo[0], bar[0] = baz, qux was evaluated in order baz, qux, foo, and
then bar in Ruby 3.0. In Ruby 3.1, it is evaluated in order foo, bar,
baz, and then qux.
* Variable Width Allocation: Strings (experimental)
* Standard libraries updates


== Benefit to Fedora ==
With a latest release, Ruby language is supporting the newest language
features, which enables even faster and easier development of Ruby
applications.

== Scope ==
* Proposal owners:
** Finish packaging of Ruby 3.1. Current changes available in PR
https://src.fedoraproject.org/rpms/ruby/pull-request/106
** Rebuilding of Ruby packages providing native extensions (i.e.
packages which depends on libruby).

* Other developers:
** Rebuild of packages with binary extensions (i.e. packages which
depends on libruby) will be handled automatically, but some packages
might need fixes/updates to support Ruby 3.1 properly.

* Release engineering: [https://pagure.io/releng/issue/10478 #10478]
** The packages are going to be rebuild in side-tag, but that does not
need releng involvement nowadays.

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Miro Hrončok]

On 20. 12. 21 18:41, Ben Cotton wrote:

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

== Summary ==
Call %set_build_flags macro automatically at the beginning of the
%build and %check phases of RPM builds in Fedora Linux.  This will
ensure that the compiler flag environment variables are set for every
RPM build.


Should we also do this in %install for completeness? As in "just in case".

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

Re: Unable to login as root with a recent Rawhide Fedora Cloud image

[Adam Williamson]

On Mon, 2021-12-20 at 09:35 -0800, Adam Williamson wrote:
> On Mon, 2021-12-20 at 10:43 -0500, Stephen John Smoogen wrote:
> > On Mon, 20 Dec 2021 at 10:31, Ondrej Mosnacek  wrote:
> > > 
> > > Hi,
> > > 
> > > When I set up a rawhide cloud image
> > > (Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
> > > download.fedoraproject.org) with a root password using virt-sysprep:
> > > 
> > > virt-sysprep -a  --root-password password:123456
> > > --selinux-relabel [...]
> > > 
> > 
> > I believe this is intentional. Please see emails with subjects:
> > 
> > F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change 
> > proposal)
> > F36 Change: Users are administrators by default in the installer GUI.
> > (Self-Contained Change proposal)
> > 
> > there may be some others. Basically root login is no longer allowed
> > via PAM and possibly other tools. My understanding is that you need to
> > login as a user, and then become root.
> 
> No, I don't think that's it. None of those changes is meant to preclude
> explicitly setting a root password.
> 
> I think this is actually a bug in Rawhide since 20211215.n.0 . I did
> not investigate it in detail since I'm on PTO, my colleague Frantisek
> Zatloukal (CC'ed) is looking into it. We see the same problem with any
> login attempt on console after a minimal install; it works OK after a
> Server install. The Workstation live images also fail to boot, they
> just get stuck at the splash screen. We're not sure yet if it's two
> different problems.
> 
> The most likely suspect seems to be:
> 
> Package:  authselect-1.3.0-3.fc36
> Old package:  authselect-1.2.4-2.fc36
> 
> So CCing pbrezina. It's notable that the bug doesn't happen on upgraded
> systems - there's a test that starts from a minimal install of F35 and
> upgrades to F36, and that test works OK. So I suspect the problem
> occurs when the installer tries to do initial authselect configuration
> of the installed system. That's about as far as we got up to the
> weekend. Frantisek has logs he could forward to pbrezina.

I've filed a bug for this now:
https://bugzilla.redhat.com/show_bug.cgi?id=2034336
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Summary/Minutes from today's FESCo Meeting (2021-12-20)

[Zbigniew Jędrzejewski-Szmek]

The meeting was cancelled because we didn't have quorum.
The next meeting will be on the 3rd.

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Tom Stellard]

On 12/20/21 10:17, Miro Hrončok wrote:

On 20. 12. 21 18:41, Ben Cotton wrote:

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

== Summary ==
Call %set_build_flags macro automatically at the beginning of the
%build and %check phases of RPM builds in Fedora Linux.  This will
ensure that the compiler flag environment variables are set for every
RPM build.


Should we also do this in %install for completeness? As in "just in case".



Yes, this seems like a good idea.

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

Re: Unable to login as root with a recent Rawhide Fedora Cloud image

[Ondrej Mosnacek]

On Mon, Dec 20, 2021 at 7:36 PM Adam Williamson
 wrote:
> On Mon, 2021-12-20 at 09:35 -0800, Adam Williamson wrote:
> > On Mon, 2021-12-20 at 10:43 -0500, Stephen John Smoogen wrote:
> > > On Mon, 20 Dec 2021 at 10:31, Ondrej Mosnacek  wrote:
> > > >
> > > > Hi,
> > > >
> > > > When I set up a rawhide cloud image
> > > > (Fedora-Cloud-Base-Rawhide-20211217.n.1.x86_64.qcow2 from
> > > > download.fedoraproject.org) with a root password using virt-sysprep:
> > > >
> > > > virt-sysprep -a  --root-password password:123456
> > > > --selinux-relabel [...]
> > > >
> > >
> > > I believe this is intentional. Please see emails with subjects:
> > >
> > > F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change 
> > > proposal)
> > > F36 Change: Users are administrators by default in the installer GUI.
> > > (Self-Contained Change proposal)
> > >
> > > there may be some others. Basically root login is no longer allowed
> > > via PAM and possibly other tools. My understanding is that you need to
> > > login as a user, and then become root.
> >
> > No, I don't think that's it. None of those changes is meant to preclude
> > explicitly setting a root password.
> >
> > I think this is actually a bug in Rawhide since 20211215.n.0 . I did
> > not investigate it in detail since I'm on PTO, my colleague Frantisek
> > Zatloukal (CC'ed) is looking into it. We see the same problem with any
> > login attempt on console after a minimal install; it works OK after a
> > Server install. The Workstation live images also fail to boot, they
> > just get stuck at the splash screen. We're not sure yet if it's two
> > different problems.
> >
> > The most likely suspect seems to be:
> >
> > Package:  authselect-1.3.0-3.fc36
> > Old package:  authselect-1.2.4-2.fc36
> >
> > So CCing pbrezina. It's notable that the bug doesn't happen on upgraded
> > systems - there's a test that starts from a minimal install of F35 and
> > upgrades to F36, and that test works OK. So I suspect the problem
> > occurs when the installer tries to do initial authselect configuration
> > of the installed system. That's about as far as we got up to the
> > weekend. Frantisek has logs he could forward to pbrezina.
>
> I've filed a bug for this now:
> https://bugzilla.redhat.com/show_bug.cgi?id=2034336

Thanks! Glad to see that this is actually a bug and is being worked
on. After Stephen's reply I was scratching my head over how to
"unlock" the root user and why none of the solutions I found online
were working :) Looks like I should be able to do what I wanted also
on an F35 image, so at least I'm not blocked by the bug.

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Florian Weimer]

* Ben Cotton:

> This change will be implemented by updating the %__spec_build_pre and
> %__speck_check_pre macros in redhat-rpm-config to include
> %set_build_flags.  This will set these environment variables
> automatically before the %build and %check sections.  See the proposed
> [https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741bbebd645c46e5d675920b4bffe390c95bb?branch=set-build-flags-build-check
> implementation] for more details.

Would you please add a clear opt-out mechanism, and document the
behavior and the mechanism in buildflags.md?

I can't tell right now how much is going to break because of this, but I
think it's worth a try.

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

Re: Non-responsive maintainer check for Eric Smith (brouhaha)

[Felix Schwarz]

Am 20.12.21 um 12:49 schrieb Dominik 'Rathann' Mierzejewski:

This is a non-responsive maintainer check for Eric Smith (brouhaha).

I've been maintaining solaar for over two years now. It was maintained
by tibbs before. I asked the original maintainer, Eric Smith to change
the default bugzilla assignee to myself several times in the past. The
last time was on September 13th this year. There was no response.

I've just filed the required Non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2034199


This might be relevant:
https://pagure.io/fesco/issue/2283#comment-615251

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Miro Hrončok]

On 20. 12. 21 21:39, Florian Weimer wrote:

* Ben Cotton:


This change will be implemented by updating the %__spec_build_pre and
%__speck_check_pre macros in redhat-rpm-config to include
%set_build_flags.  This will set these environment variables
automatically before the %build and %check sections.  See the proposed
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741bbebd645c46e5d675920b4bffe390c95bb?branch=set-build-flags-build-check
implementation] for more details.


Would you please add a clear opt-out mechanism, and document the
behavior and the mechanism in buildflags.md?

I can't tell right now how much is going to break because of this, but I
think it's worth a try.


I suppose the obvious opt-out mechanism is to call unset on the CFLAGS, LDFLAGS 
etc. Shell variables, no? I agree it needs documentation.


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

Re: Non-responsive maintainer check for Eric Smith (brouhaha)

[Miro Hrončok]

On 20. 12. 21 22:44, Felix Schwarz wrote:


Am 20.12.21 um 12:49 schrieb Dominik 'Rathann' Mierzejewski:

This is a non-responsive maintainer check for Eric Smith (brouhaha).

I've been maintaining solaar for over two years now. It was maintained
by tibbs before. I asked the original maintainer, Eric Smith to change
the default bugzilla assignee to myself several times in the past. The
last time was on September 13th this year. There was no response.

I've just filed the required Non-responsive maintainer check bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2034199


This might be relevant:
https://pagure.io/fesco/issue/2283#comment-615251


And in the light of that, I've made @rathann the main admin of solaar.

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Tom Stellard]

On 12/20/21 14:04, Miro Hrončok wrote:

On 20. 12. 21 21:39, Florian Weimer wrote:

* Ben Cotton:


This change will be implemented by updating the %__spec_build_pre and
%__speck_check_pre macros in redhat-rpm-config to include
%set_build_flags.  This will set these environment variables
automatically before the %build and %check sections.  See the proposed
[https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741bbebd645c46e5d675920b4bffe390c95bb?branch=set-build-flags-build-check
implementation] for more details.


Would you please add a clear opt-out mechanism, and document the
behavior and the mechanism in buildflags.md?

I can't tell right now how much is going to break because of this, but I
think it's worth a try.


I suppose the obvious opt-out mechanism is to call unset on the CFLAGS, LDFLAGS 
etc. Shell variables, no? I agree it needs documentation.



What do you think the best place is to document this?
I was thinking in the Packaging Guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Florian Weimer]

* Miro Hrončok:

> On 20. 12. 21 21:39, Florian Weimer wrote:
>> * Ben Cotton:
>> 
>>> This change will be implemented by updating the %__spec_build_pre and
>>> %__speck_check_pre macros in redhat-rpm-config to include
>>> %set_build_flags.  This will set these environment variables
>>> automatically before the %build and %check sections.  See the proposed
>>> [https://src.fedoraproject.org/fork/tstellar/rpms/redhat-rpm-config/c/a39741bbebd645c46e5d675920b4bffe390c95bb?branch=set-build-flags-build-check
>>> implementation] for more details.
>> Would you please add a clear opt-out mechanism, and document the
>> behavior and the mechanism in buildflags.md?
>> I can't tell right now how much is going to break because of this,
>> but I
>> think it's worth a try.
>
> I suppose the obvious opt-out mechanism is to call unset on the
> CFLAGS, LDFLAGS etc. Shell variables, no?

We might introduce further variables in the future, so I'd prefer an
explicit mechanism.  We added LT_SYS_LIBRARY_PATH fairly recently, for
example.

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

Re: F36 Change: %set_build_flags for %build and %check (System-Wide Change proposal)

[Florian Weimer]

* Tom Stellard:

> What do you think the best place is to document this?
> I was thinking in the Packaging Guidelines:
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_compiler_flags

Please update the in-place package documentation (buildflags.md) at the
very least.

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

Re: debug_package when using go_generate_buildrequires

[Demi Marie Obenour]

On 12/20/21 8:09 AM, Panu Matilainen wrote:
> Having to disable debug packages practically always indicates a bug in 
> the package - either packaging, upstream or both.
> 
> Typical causes for "error: Empty %files file 
> <...>/debugsourcefiles.list" are missing debug info in the build (eg -g 
> flag of gcc) and building outside the designated build directory. 
> Unfortunately diagnosing these from rpm isn't easy.
> 
> "%global debug_package %{nil}" is always a workaround and never a fix.
> 
>- Panu -

Is the only exception when the debuginfo for a huge package consumes too
much memory or disk space?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


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