date:20220121


On 1/21/22 22:55, Jonathan Wakely wrote:

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:


On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:


On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
 168 |   local_server_name_ = qApp->applicationName().toLower();
 |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
from /usr/include/qt5/QtCore/qlist.h:47,
from /usr/include/qt5/QtCore/qstringlist.h:41,
from /usr/include/qt5/QtCore/QStringList:1,
from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
 510 | Q_REQUIRED_RESULT QString toLower() &&
 |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
local_server_name_ = qApp->applicationName().toLower();

if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.


No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.



I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();


This creates an rvalue, which allows the call to toLower().


Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.


The Qt code has two overloads:

 Q_REQUIRED_RESULT QString toLower() const &
 { return toLower_helper(*this); }
 Q_REQUIRED_RESULT QString toLower() &&
 { return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

I don't think this is a GCC change though.


I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173



Thanks so much for looking it up!
___
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: Package information on ELF objects (System-Wide Change proposal)


On 10/25/21 21:09, Ben Cotton wrote:

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

== Summary ==
All binaries (executables and shared libraries) are annotated with an
ELF note that identifies the rpm for which this file was built. This
allows binaries to be identified when they are distributed without any
of the rpm metadata. `systemd-coredump` uses this to log package
versions when reporting crashes.

== Owner ==
* Name: [[User:Zbyszek|Zbigniew Jędrzejewski-Szmek]]
* Email: zbys...@in.waw.pl
* Name: Lennart Poettering
* Email: mzsrq...@0pointer.net


== Detailed Description ==
People mix binaries (programs and libraries) from different
distributions (for example using Fedora containers on Debian or vice
versa), and distribute binaries without packaging metadata (for
example by stripping everything except the binary from a container
image, also removing `/usr/lib/.build-id/*`), compile their own rpm
packages (for internal distribution and installation), and compile and
distribute their own binaries. Sometimes we need to introspect a
binary and figure out its provenance, for example when a program
crashes and we are looking at a core dump, but also when we have a
binary without the packaging metadata. When the need to introspect a
binary arises, we have some very good mechanisms to show the
provenance: when a file is installed through the package manager we
can directly list the providing package, but even without this we can
use build-ids embedded in the binary to uniquely identify the
originating build. But those mechanisms work best when we're in the
realm of a single distribution. In particular, build-ids can be easily
tied to a source rpm, but only when we have the source rpm is part of
the distribution and the build-id was registered in the appropriate
database which maps build-ids to real package names. When we move
outside of the realm of a single distribution, it can be hard to
figure out where a given binary originates from. If we know that a
binary is from a given distribution, we may be able to use some
distro-specific mechanism to figure out this information. But those
mechanisms will be different for different distributions and will
often require network access. With this change we aim to provide a
mechanism that is is very simple, provides a "human-readable" origin
information without further processing, is portable across distros,
and works without network access.

The directly motivating use case is display of core dumps. Right now
we have build-ids, but those are just opaque hexadecimal numbers that
are not meaningful to users. We would like to immediately list
versions of packages involved in the crash (including both the program
and any libraries it links to). It is not enough to query the rpm
database to do the equivalent of `rpm -qf …`: very often programs
crash after some packages have been upgraded and the binaries loaded
into memory are not the binaries that are currently present on disk,
or when through some mishap, the binaries on disk do not match the
installed rpms.  A mechanism that works without rpm database lookup or
network access allows this information to be showed immediately in
`coredumpctl` listings and journal entries about the crash. This
includes crashes that happen in the initrd and sandboxed containers.

A second motivating use case is when users distribute their own
binaries and would like to collect crash information. Build-ids are a
solution that is technically possible, but easy to get wrong in
practice: users would need to immediately record the build-id after
the build and store the mapping to program names, versions, and build
number in some database. It's much easier to be able to record
something during the build in the build product itself.

A third motivating use case is the general mixing of Fedora binaries
with programs and libraries from different distributions, both with
our binaries being used as the base for foreign binaries, and the
other way around. Whilst most distributions provide some mechanism to
figure out the source build information, those mechanisms vary by
distribution and may not be easy to access from a "foreign" system.
Such mixing is expected with containers, flatpaks, snaps, Python
binary wheels, anaconda packages, and quite often when somebody
compiles a binary and puts it up on the web for other people to
download.

We propose a new mechanism which is designed to be very simple but
extensible: a small JSON document is embedded in an section in the ELF
binary. This document can be easily read by a human if necessary, but
it is also well-defined and can be processed programatically. For
example, `systemd-coredump` will immediately make use of this to
display package ''nevra'' information for crashes. The format is also
easy to generate, so it can be added to any build system, either using
the helpers that we provide or even reimplemented from scratch.

For the case where we mix binaries from different

Fedora-Rawhide-20220120.n.1 compose check report

2022-01-21 Thread Fedora compose checker

No missing expected images.

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

Failed openQA tests: 15/225 (x86_64), 17/157 (aarch64)

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

ID: 1110260 Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/1110260
ID: 1110264 Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/1110264
ID: 1110267 Test: x86_64 Everything-boot-iso memory_check@uefi
URL: https://openqa.fedoraproject.org/tests/1110267
ID: 1110356 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1110356
ID: 1110357 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1110357
ID: 1110410 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1110410
ID: 1110415 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1110415
ID: 1110434 Test: x86_64 Workstation-upgrade desktop_login
URL: https://openqa.fedoraproject.org/tests/1110434
ID: 1110445 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1110445
ID: 1110447 Test: x86_64 Workstation-upgrade evince
URL: https://openqa.fedoraproject.org/tests/1110447
ID: 1110455 Test: aarch64 Workstation-upgrade desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110455
ID: 1110546 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110546

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

ID: 1110285 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1110285
ID: 1110287 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1110287
ID: 1110292 Test: x86_64 KDE-live-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1110292
ID: 1110293 Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/1110293
ID: 1110322 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1110322
ID: 1110341 Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1110341
ID: 1110393 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1110393
ID: 1110402 Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/1110402
ID: 1110407 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1110407
ID: 1110412 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1110412
ID: 1110440 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1110440
ID: 1110452 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1110452
ID: 1110454 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1110454
ID: 1110457 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1110457
ID: 1110459 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1110459
ID: 1110545 Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1110545
ID: 1110591 Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/1110591
ID: 1110608 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1110608
ID: 1110609 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1110609
ID: 1110610 Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/1110610

Soft failed openQA tests: 13/157 (aarch64), 17/225 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1110414 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1110414
ID: 1110465 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1110465
ID: 1110482 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1110482
ID: 1110532 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/1110532

ROCm-Device-Libs packaging question

2022-01-21 Thread Jeremy Newton

In order to update "rocm-runtime" to the latest, it requires a new package 
"ROCm-Device-Libs" as a build requirement.
The issue is that the project installs files into /usr/amdgcn, which seems 
incorrect to me based on the FHS and Fedora guidelines. Here's the upstream for 
reference:
https://github.com/RadeonOpenCompute/ROCm-Device-Libs

I made a test package but to get it to pass rpmlint, I patched it to put amdgcn 
in "share/amdgcn" and made it a noarch package because it doesn't compile any 
cpu specific code. I proposed to upstream to make this change and it seems they 
don't agree and strongly prefer putting the files in "lib/amdgcn".

It seems the files are bitcode to be used with clang, so the binaries are not 
traditional libraries. At the moment these files are CPU arch independent, but 
they said they might want to add some x86 bit code later.

I guess I have a few questions:
- does bitcode belong in lib? share? Does it matter if these libraries are 
bitcode or not?
- if they were to add x86_64 bitcode, would it then belong in lib64? What about 
GPU related bitcode?
- If no debug info is generated, does this automatically make it a noarch 
package? I don't think bitcode would generate debug information regardless of 
arch
- Would lib/amdgcn would be ok if it's noarch?
- is this a fesco worthy question?

Thanks!___
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: Build failure in Clementine due to GCC 12

2022-01-21 Thread Jonathan Wakely

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:
>
> On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
> >
> > On 1/21/22 14:46, Robert-André Mauchin wrote:
> > > Hello,
> > >
> > > So I built Clementine last week with no issue, but it failed during
> > > the mass rebuild with the folloing error:
> > >
> > > In file included from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> > >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > > HandlerType = AbstractMessageHandler]':
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > > required from here
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> > >  error: passing 'QString' as 'this' argument discards qualifiers 
> > > [-fpermissive]
> > > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > > |   ^
> > > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> > >from /usr/include/qt5/QtCore/qlist.h:47,
> > >from /usr/include/qt5/QtCore/qstringlist.h:41,
> > >from /usr/include/qt5/QtCore/QStringList:1,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > > QString::toLower() &&'
> > > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > > |   ^~~
> > >
> > >
> > > Nothing stands up to me in the linked code:
> > >
> > > template 
> > > WorkerPool::WorkerPool(QObject* parent)
> > >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> > >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> > >local_server_name_ = qApp->applicationName().toLower();
> > >
> > >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > > }
> > >
> > >
> > > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > > any input at all?
> > >
> > > Best regards,
> > >
> > > Robert-André
> >
> > So the problem is specific to GCC 12 but I can't find anything in the 
> > changelog related to this.
> > It seems toLower() takes a const as input and qApp->applicationName() is 
> > not a const.
>
> No, you have it backwards.
>
> QString::toLower() && can only be called on a non-const rvalue, and
> applicationName() is apparently returning a const object.
>
> >
> > I solved by replacing
> > local_server_name_ = qApp->applicationName().toLower();
> > to
> > local_server_name_ = QString(qApp->applicationName()).toLower();
>
> This creates an rvalue, which allows the call to toLower().
>
> > Still I would love for a GCC specialist to point me to the relevant change 
> > in GCC 12 so I can
> > send a patch upstream with explanation for the change.
>
> The Qt code has two overloads:
>
> Q_REQUIRED_RESULT QString toLower() const &
> { return toLower_helper(*this); }
> Q_REQUIRED_RESULT QString toLower() &&
> { return toLower_helper(*this); }
>
> For some reason, the second one is being used when it should be the first.
>
> I don't think this is a GCC change though.

I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173
___
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

GCC 12 question

2022-01-21 Thread Steven A. Falco


I've been able to rebuild KiCad using the new gcc-12.0.1-0.2 compiler rpms on 
Rawhide via mock.  While KiCad compiles, it doesn't quite run correctly.

As shown in the attached screenshot, all the icons are missing, and have been replaced 
with question marks.  I wonder if this could be caused by some Fedora libraries that have 
not yet been rebuilt using GCC-12.  I don't know if it is possible to "mix and 
match" things previously compiled with GCC-11 with things newly compiled with GCC-12.

I have a few questions:

1) Does it seem likely that some library (like wx) could be the cause, or is it 
more likely to be a bug in KiCad itself?

2) I believe a mass rebuild will be done soon, which might help, if a library 
is at fault - is there a schedule for that?

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

Re: Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Sergio Belkin

Oh My shame it's working indeed it was a typo, sorry and thanks :)

El vie, 21 ene 2022 a las 17:14, Tomasz Torcz ()
escribió:

> On Fri, Jan 21, 2022 at 05:06:01PM -0300, Sergio Belkin wrote:
> > Is there a way that systemd-resolved honors the /etc/hosts file?
> > Thanks in advance
>
>   There's ReadEtcHosts= setting controlling that. See "man resolved.conf"
> or /etc/systemd/resolved.conf itself.
>
> --
> Tomasz Torcz“Funeral in the morning, IDE hacking
> to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
> ___
> 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
>


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

Re: Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Tomasz Torcz

On Fri, Jan 21, 2022 at 05:06:01PM -0300, Sergio Belkin wrote:
> Is there a way that systemd-resolved honors the /etc/hosts file?
> Thanks in advance

  There's ReadEtcHosts= setting controlling that. See "man resolved.conf"
or /etc/systemd/resolved.conf itself.

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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

F37 Change: Python Dist RPM provides to only provide PEP503-normalized names (Self-Contained Change proposal)

2022-01-21 Thread Ben Cotton

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

== Summary ==
The legacy `python3dist(NAME)` and `python3.11dist(NAME)` RPM provides
with dots (`.`) in `NAME` will no longer be automatically provided.
`NAME` will only be normalized according to
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503].
E.g. on Fedora 36 a package provides both `python3dist(ruamel-yaml)`
and `python3dist(ruamel.yaml)`, on Fedora 37+ it will only provide
`python3dist(ruamel-yaml)` (and similarly,
`python3.11dist(ruamel-yaml)`.

== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]]
* Email: mhron...@redhat.com


== Detailed Description ==
This change is only about about automatic RPM provides in the following forms:

* `python3dist(NAME)`
* `python3.Xdist(NAME)`


It does not affect any other provides or package names.

Historically, Python package names were normalized by the RPM
dependency generators in a way that diverged from upstream behavior.
In upstream (e.g. when using `pip`) a package name with a dot is equal
to a package name with a dash (e.g. `pip install ruamel.yaml` and `pip
install ruamel-yaml` are equivalent). In Fedora, the ''Provides'' and
''Requires'' included the dot, but upstream rules defined in
[https://www.python.org/dev/peps/pep-0503/#normalized-names PEP 503]
demand the dot to be replaced by a dash. This caused trouble when
other packages required the packages via a name with a dash. Hence, we
have slowly been migrating to PEP 503 name normalization.

* Since Fedora 32, Python dependency generators have generated both
variants of the ''Provides'' as a preparation for the transition to
PEP 503-only.
* Since Fedora 33, Python dependency generators have generated
''Requires'' in the PEP 503 form (no dots).
* Only packages with manual ''BuildRequires'', ''Requires'',
''Recommends'' etc. with requirements such as `python3dist(foo.bar)`
would be affected by this change. We have fixed all of them in Fedora
36.


Hence, together with [[Changes/Python3.11|the update to Python3.11]],
we will disable the legacy form of the provides.

Python packages with dots in their name will only provide the names with dashes.

=== RHEL/EPEL compatibility ===

This change is fully compatible with RHEL/EPEL 9, which behaves like
Fedora 34 and hence has ''Provides'' in both forms but ''Requires'' in
the PEP 503 form (no dots).

This change is not compatible with RHEL/EPEL 8. If you need to have
manual requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 8 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].

This change is not relevant to RHEL 7.

This change is not compatible with EPEL 7. If you need to have manual
requirements in the specfile that should work on Fedora 37+ and
RHEL/EPEL 7 in this form and the name includes a dot, we recommend
using 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#py3_dist
`%py3_dsit`].


== Benefit to Fedora ==
* Less automatic provides in the repos - there are 93+93=186 provides
like `python3dist(x.y)` and `python3.Xdist(x.y)` in rawhide today.
* There will be only way way to express a Python package name in this
context, not two.
* One more thing the Python maintainers will cross off their TODO list.

== Scope ==
* Proposal owners:
# check there are really no more manual requirements with dots
# disable the automatically generated provides with dots when we
update to Python 3.11
# double-check there are really no more manual requirements with dots

* Other developers:
** stop adding new manual Python dist requirements with dots
* Release engineering: not needed for this Change
* Policies and guidelines: they already only cover PEP 503
* Trademark approval: not needed for this Change
* Alignment with Objectives: not really


== Upgrade/compatibility impact ==
This is done together with the Python 3.11 update to not have to deal
with little problems, such as packages that can't be rebuilt after the
manual requirements were changed.

== How To Test ==
The following 2 commands should yield nothing:

 $ repoquery --repo=rawhide --provides | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'
 $ repoquery --repo=rawhide --requires | grep -E
'^python3(\.[[:digit:]]+)?dist\(\S+\.\S+\)'

With the exception of packages that failed to rebuild with Python 3.11
(and those will need to be dealt with anyway one way or another).


The following example commands should only give the variant with dashes:

 $ repoquery --repo=rawhide --provides python3-ruamel-yaml | grep -E
'^python3(\.[[:digit:]]+)?dist\('
 $ repoquery --repo=rawhide --provides python3-jaraco-path | grep -E
'^python3(\.[[:digit:]]+)?dist\('

There should be no new broken dependencies because of this.

Note that wiki is eating my double `[]` in the regexes above around
`:digit:`. See the page source for the actual commands :(

== User Experience ==
The actual users should not

Re: Non-responsive packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

2022-01-21 Thread Matthias Runge



> Am 20.01.2022 um 09:57 schrieb Pierre-Yves Chibon :
> 
> Good Morning Everyone,
> 
> The packagers listed here have been receiving a daily email asking them to
> either adjust their bugzilla or their FAS account so the email address in FAS
> matches an existing bugzilla account.
> 
> Having a bugzilla account is mandatory per:
> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> 
> 
> 
> - sebix contacted since December 4th
> 
> sebix is maintainer of rpms/lockfile-progs
> sebix has a bugzilla override on rpms/lockfile-progs
> sebix is maintainer of rpms/logcheck
> sebix has a bugzilla override on rpms/logcheck
> 
> 
> Thanks,
> 
> Pierre
> 

I have cc’d sebix to this email.

Sebastian, could you please take a look?

Thank you,
Matthias
___
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

Is systemd-resolved ignoring /etc/hosts?

2022-01-21 Thread Sergio Belkin

Hi, On Fedora 35, I was that some domain name to be resolved by /etc/hosts
entry.

Let's says:

54.x.y.z somesite.miexample.com

(54.x.y.z is a ipv4 address)

With systemd-resolved is not working.

This my config:
resolvectl domain
Global:
Link 2 (wlp108s0):
Link 3 (docker0):
Link 4 (br-775990106ebc):
Link 13 (vboxnet0):
Link 14 (vboxnet1):
Link 15 (vboxnet2):
Link 16 (vboxnet3):
Link 22 (tun0): example.com

resolvectl dns
global:
Link 2 (wlp108s0): x.y.119.211 x.y.119.212
Link 3 (docker0):
Link 4 (br-775990106ebc):
Link 13 (vboxnet0):
Link 14 (vboxnet1):
Link 15 (vboxnet2):
Link 16 (vboxnet3):
Link 22 (tun0): 192.168.40.40 8.8.8.8

Is there a way that systemd-resolved honors the /etc/hosts file?

Thanks in advance

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

Fedora rawhide compose report: 20220120.n.1 changes

2022-01-21 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220119.n.0
NEW: Fedora-Rawhide-20220120.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  8
Dropped packages:0
Upgraded packages:   129
Downgraded packages: 0

Size of added packages:  345.21 MiB
Size of dropped packages:0 B
Size of upgraded packages:   6.26 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   66.61 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-Rawhide-20220120.n.1.armhfp.raw.xz

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20220119.n.0.iso

= ADDED PACKAGES =
Package: erlang-protobuffs-0.9.2-4.fc36
Summary: A set of Protocol Buffers tools and modules for Erlang applications
RPMs:erlang-protobuffs
Size:46.01 KiB

Package: erlang-triq-1.3.0-8.fc36
Summary: A property-based testing library for Erlang
RPMs:erlang-triq
Size:41.24 KiB

Package: intel-llvm8.0-vc-intrinsics-0-1.20211222git753ad50.fc36
Summary: New intrinsics on top of core LLVM IR instructions
RPMs:intel-llvm8.0-vc-intrinsics intel-llvm8.0-vc-intrinsics-devel
Size:894.41 KiB

Package: intel-opencl-clang-13.0.0-1.fc36
Summary: Library to compile OpenCL C kernels to SPIR-V modules
RPMs:intel-opencl-clang intel-opencl-clang-devel
Size:543.91 KiB

Package: libnetconf2-2.0.24-1.fc36
Summary: NETCONF protocol library
RPMs:libnetconf2 libnetconf2-devel
Size:930.65 KiB

Package: libsoup3-3.0.4-1.fc36
Summary: Soup, an HTTP library implementation
RPMs:libsoup3 libsoup3-devel libsoup3-doc
Size:2.88 MiB

Package: llvm8.0-8.0.1-1.fc36
Summary: The Low Level Virtual Machine
RPMs:llvm8.0 llvm8.0-devel llvm8.0-doc llvm8.0-libs llvm8.0-static
Size:336.53 MiB

Package: spirv-llvm8.0-translator-8-1.20211223gita44863e.fc36
Summary: LLVM 8.0 to SPIRV Translator
RPMs:spirv-llvm8.0-translator spirv-llvm8.0-translator-devel 
spirv-llvm8.0-translator-tools
Size:3.40 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  CImg-1:3.0.2-1.fc36
Old package:  CImg-1:3.0.1-1.fc36
Summary:  C++ Template Image Processing Toolkit
RPMs: CImg-devel
Size: 11.19 MiB
Size change:  -1.27 KiB
Changelog:
  * Wed Jan 19 2022 Fedora Release Engineering  - 
1:3.0.1-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

  * Thu Jan 20 2022 josef radinger  -3.0.2-1
  - bump version


Package:  abrt-2.15.0-2.fc36
Old package:  abrt-2.14.6-7.fc35
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-retrace-client abrt-tui python3-abrt python3-abrt-addon 
python3-abrt-container-addon python3-abrt-doc
Size: 6.48 MiB
Size change:  -185.33 KiB
Changelog:
  * Mon Sep 27 2021 Mat??j Grabovsk??  - 2.14.6-8
  - Use lazy import in the Python exception handler to avoid slowdown in Python
startup (rhbz#2007664)

  * Wed Dec 22 2021 Mat??j Grabovsk??  - 2.14.6-9
  - Rebuild for satyr 0.39

  * Thu Jan 06 2022 Mat??j Grabovsk??  - 2.14.6-10
  - Bump release for rebuild

  * Wed Jan 12 2022 Miro Hron??ok  - 2.14.6-11
  - Make abrt-tui and python3-abrt-container-addon noarch as they contain no 
architecture-specific content
  - Ensure Python bytecode in noarch subpackages is reproducible

  * Mon Jan 17 2022 Mat??j Grabovsk??  - 2.15.0-1
  - Bump abrt library version to 1:0:1
  - cli: Fix path and glob matching for abrt info etc.
  - abrt-dump-oops: Fix vmcore call trace parsing
  - Use lazy imports in abrt_exception_handler3
  - Don't copy coredump to problem dir
  - Detect Python 3.10 and Perl correctly in abrt-action-save-package-data
  - Fix calls to deprecated methods in tests
  - Update translations

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 2.15.0-2
  - Rebuild for testing


Package:  abrt-java-connector-1.3.1-2.fc36
Old package:  abrt-java-connector-1.2.0-8.fc35
Summary:  JNI Agent library converting Java exceptions to ABRT problems
RPMs: abrt-java-connector abrt-java-connector-container
Size: 399.69 KiB
Size change:  5.95 KiB
Changelog:
  * Mon Jan 17 2022 Mat??j Grabovsk??  1.3.0-1
  - Bump libreport dependency to 2.14.0
  - Add make to build-time dependencies

  * Tue Jan 18 2022 Mat??j Grabovsk??  - 1.3.0-2
  - Fix failing tests

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 1.3.1-1
  - New upstream release

  * Wed Jan 19 2022 Mat??j Grabovsk??  - 1.3.1-2
  - Rebuild for testing


Package:  alexandria-0.7.8-6.fc36.1
Old package:  alexandria-0.7.8-6.fc36
Summary:  Book collection manager
RPMs: alexandria
Size: 2.36 MiB
Size change:  1.14

Re: GCC 12 related issues in rawhide


On 21. 01. 22 19:17, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:10:53PM +0100, Miro Hrončok wrote:

On 21. 01. 22 19:07, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:

On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.



Sorry for not speaking clearly. That was supposed to be a question.

What is the best way to obtain the files you need in order to share them with 
you?


Unless it is LTO related (that complicates things), best is to rerun
whatever gcc/g++ invocation failed with an unexpected error
or internal compiler error with additional -save-temps option, that will
leave the preprocessed file around.  For ICEs, the gcc/g++ driver even tries
to reproduce ICEs and if successful stores everything I need into
/tmp/cc*.out file and writes the name of that file to stderr.
So, if one sees that, using fedpkg to request tarball from the failed build
is one possibility and then copying the /tmp/cc*.out file out of there.
When it is reproducible in a local mock, rerunning the command by hand with
-save-temps is easy too, without access to the arch, one option is to hack
up the spec file, such that it will do:
make usual_stuff || \
( Either uuencode compressed /tmp/cc*.out to stdout here so that it shows up
in build.log or rerun failing gcc/g++ command line with the added
-save-temps here and uuencode compressed *.i or *.ii to stdout etc.
exit 1 )
(done that several times in the past when needed).


Thanks, Jakub.

--
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: GCC 12 related issues in rawhide

On Fri, 21 Jan 2022 19:10:53 +0100
Miro Hrončok  wrote:

> On 21. 01. 22 19:07, Jakub Jelinek wrote:
> > On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> >> On 21. 01. 22 17:55, Jakub Jelinek wrote:
> >>> In all cases, if it is some compiler error or internal compiler error,
> >>> preprocessed source + gcc command line would be highly appreciated,
> >>> having us to try to rebuild all the packages again and dig those up
> >>> will be very time consuming.
> >>
> >> But I suppose you know the best way to obtain those?
> >>
> >> I build the package in mock and share the entire
> >> .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?
> > 
> > The reports are from various architectures, and mock takes some time,
> > especially if the error is hours into building.
> > I'm not saying I won't do it if what I'm asking for is not provided,
> > just that if somebody provides it to me, I will greatly appreciate it
> > and I (and my team collegues) can spend more time on fixing the bugs
> > and less on trying to reproduce them.
> > Several people already mailed me preprocessed sources (thanks a lot for
> > that) and I've been able to reply quickly to those.
> > 
> 
> Sorry for not speaking clearly. That was supposed to be a question.
> 
> What is the best way to obtain the files you need in order to share them with 
> you?

- rebuild locally in rawhide mock
- go to the mock chroot
- then to the build directory that calls gcc/g++
- rerun the gcc/g++ command to verify it still happens
- substitute -c for -E and *.o for *.i on the command line
- rerun
- grab the resulting *.i plus the full command line

That's roughly how I do it. Hope it answers your question :-)


Dan
___
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: GCC 12 related issues in rawhide

On Fri, Jan 21, 2022 at 07:10:53PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 19:07, Jakub Jelinek wrote:
> > On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> > > On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > > > In all cases, if it is some compiler error or internal compiler error,
> > > > preprocessed source + gcc command line would be highly appreciated,
> > > > having us to try to rebuild all the packages again and dig those up
> > > > will be very time consuming.
> > > 
> > > But I suppose you know the best way to obtain those?
> > > 
> > > I build the package in mock and share the entire
> > > .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?
> > 
> > The reports are from various architectures, and mock takes some time,
> > especially if the error is hours into building.
> > I'm not saying I won't do it if what I'm asking for is not provided,
> > just that if somebody provides it to me, I will greatly appreciate it
> > and I (and my team collegues) can spend more time on fixing the bugs
> > and less on trying to reproduce them.
> > Several people already mailed me preprocessed sources (thanks a lot for
> > that) and I've been able to reply quickly to those.
> > 
> 
> Sorry for not speaking clearly. That was supposed to be a question.
> 
> What is the best way to obtain the files you need in order to share them with 
> you?

Unless it is LTO related (that complicates things), best is to rerun
whatever gcc/g++ invocation failed with an unexpected error
or internal compiler error with additional -save-temps option, that will
leave the preprocessed file around.  For ICEs, the gcc/g++ driver even tries
to reproduce ICEs and if successful stores everything I need into
/tmp/cc*.out file and writes the name of that file to stderr.
So, if one sees that, using fedpkg to request tarball from the failed build
is one possibility and then copying the /tmp/cc*.out file out of there.
When it is reproducible in a local mock, rerunning the command by hand with
-save-temps is easy too, without access to the arch, one option is to hack
up the spec file, such that it will do:
make usual_stuff || \
( Either uuencode compressed /tmp/cc*.out to stdout here so that it shows up
in build.log or rerun failing gcc/g++ command line with the added
-save-temps here and uuencode compressed *.i or *.ii to stdout etc.
exit 1 )
(done that several times in the past when needed).

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

Re: Uninitialized variables and F37

2022-01-21 Thread Michael Catanzaro

On Fri, Jan 21 2022 at 01:04:51 PM -0500, Steve Grubb 
 wrote:
He said this would have prevented over 900 fixed CVE's in Chrome and 
12% of

all Android CVE's.


I believe it. This should be treated like any other security hardening 
flag.


Michael

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

Re: GCC 12 related issues in rawhide


On 21. 01. 22 19:07, Jakub Jelinek wrote:

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:

On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.



Sorry for not speaking clearly. That was supposed to be a question.

What is the best way to obtain the files you need in order to share them with 
you?

--
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: GCC 12 related issues in rawhide

On Fri, Jan 21, 2022 at 07:00:41PM +0100, Miro Hrončok wrote:
> On 21. 01. 22 17:55, Jakub Jelinek wrote:
> > In all cases, if it is some compiler error or internal compiler error,
> > preprocessed source + gcc command line would be highly appreciated,
> > having us to try to rebuild all the packages again and dig those up
> > will be very time consuming.
> 
> But I suppose you know the best way to obtain those?
> 
> I build the package in mock and share the entire
> .../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?

The reports are from various architectures, and mock takes some time,
especially if the error is hours into building.
I'm not saying I won't do it if what I'm asking for is not provided,
just that if somebody provides it to me, I will greatly appreciate it
and I (and my team collegues) can spend more time on fixing the bugs
and less on trying to reproduce them.
Several people already mailed me preprocessed sources (thanks a lot for
that) and I've been able to reply quickly to those.

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

Re: Self Introduction: Chung Chung

On Fri, Jan 21, 2022 at 07:34:05AM -0500, Chung Chung wrote:
> 
> Hi All:
> 
>   My name is Chung, I work in Red Hat and maintain lab systems for my team.
> 
>   I have been doing DevOps/SysAdmin for quite a few years now.   I have done
> some RPM package build for my group internally and I would like to contribute
> as a package maintainer.
> 
>   There are some packages we used in the lab I plan to take ownership of and I
> am open to taking on maintaining other packages also.
> 
>   Thanks and excited for the opportunity to contribute.

Hi and welcome to Fedora.  Let me know once the packager status has
gone through and we can look at Coccinelle.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Marek Polacek

On Fri, Jan 21, 2022 at 06:33:21PM +0100, Dan Horák wrote:
> On Fri, 21 Jan 2022 09:55:01 -0700
> Jerry James  wrote:
> 
> > On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > > Another important thing I wanted to say is that we'd like to switch
> > > ppc64le from the numerically problematic IBM extended long double to
> > > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > > are already built so that they support both ABIs at the same time,
> > > including glibc, libstdc++, libgcc, libgfortran etc.
> > > For other libraries and binaries, the compiler, assembler and linker
> > > will notice if they use long double and flag them as using either
> > > IBM or IEEE long double and linker (or I think dynamic linker too)
> > > might complain when things are mixed.
> > > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > > but the glibc/gcc libraries are built compatibly with both.
> > > We'd like to configure gcc shortly before the mass rebuild with
> > > --with-long-double-format=ieee so that it will default to
> > > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > > will be highly desirable to rebuild at least some of the most commonly
> > > used library packages in the order of dependencies there, otherwise
> > > I'd be afraid the mass rebuild could fail for way too many packages
> > > (as the mass rebuild doesn't do dependency order rebuilds but just
> > > goes through packages alphabetically or so).
> > 
> > I don't know if this change is involved, but I've got several packages
> > that failed to build on ppc64le only, with what look like gcc
> > segfaults:
> > - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> > - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> > - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> > - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> 
> ^^^ those are probably
> https://bugzilla.redhat.com/show_bug.cgi?id=2043517

I think you're right.  And #2043517 is the same as #2043357.

Marek
___
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: s390 ruby build failure

To follow up on this thread, I did a scratch build this morning with
some extra instrumentation which was meant to capture the Ruby log
file if the build failed.  But the scratch build succeeded this time
on s390x, although it still failed overall because of the kernel bug.

So I decided to leave it until the kernel bug is fixed and worry about
it afterwards if it happens again.

Thanks all!

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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

Uninitialized variables and F37

2022-01-21 Thread Steve Grubb

Hello,

This is a continuation of the discussion from F36 Change: GNU Toolchain
Update.

Uninitialized variables are a big problem. They can be sources of information
exposure if parts of a buffer are not initialized. They can also cause
unexpected execution paths if the attacker can groom the memory to a value of
their choosing. If the variable is a pointer to heap, this can cause free to
corrupt memory under certain circumstances. If the uninitialized memory is
part of user input, this can lead to improper input validation. This is not
hypothetical. All of these come from a paper doing an emprical study of
android flaws. [1] The data used in the paper is here. [2]

Part of the problem is that compilers and static analysis tools can't always
find them. I created a test program that has 8 uses of unintialized variables.
Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2
or
3 - but does so much complaining you'd think it found all. Valgrind finds 2.
Flexelint, a commercial linter, finds 1.

Since tools can't always find them, the only option we have right now is force
initialization to something the attacker cannot control. Kees Cook started a
discussion on the llvm developers mail list a while back. He makes a very
clear argument. I would be repeating his points, so please read the original
discussion here (also read the replies):

https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html

He talks about -ftrivial-auto-var-init=zero being used for production builds
and -ftrivial-auto-var-init= being used for debug builds. The use
is not just the kernel. Consider a server that returns data across the
network to a client. It could possibly leak crypto keys or passwords if the
returned data structure has uninitialized memory.

For more background, the creator of this technology for LLVM presented a talk
about this feature at a past LLVM developer conference:

https://www.youtube.com/watch?v=I-XUHPimq3o

He said this would have prevented over 900 fixed CVE's in Chrome and 12% of
all Android CVE's.

From deep inside the LLVM thread above, comes this nugget:
---
To add in, we (Microsoft) currently use zero initialization technology in
Visual Studio in a large amount of production code we ship to customers (all
kernel components, a number of user-mode components). This code is both C and
C++.

We already have had multiple vulnerabilities killed because we shipped this
technology in production. We received bug reports with repros that worked on
older versions of Windows without the mitigation and new versions of Windows
that do have it. The new versions don't repro, the old ones do.
---

Microsoft is also digging in to uninitialized variables. They have a lengthy
blog post that talks about extending this to heap memory. [3]

I think this would be an important step forward to turn this on across all
compilations. We could wipe out an entire class of bugs in one fell swoop.
But then, what about heap allocations? Calloc has existed for a long time. It
might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
to substitute something like calloc for malloc.

Cheers,
-Steve

[1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf

[2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/
MSR2017/vulnerabilitiesList.html

[3] -
https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-pool-memory-on-windows/

___
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: GCC 12 related issues in rawhide


On 21. 01. 22 17:55, Jakub Jelinek wrote:

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.


But I suppose you know the best way to obtain those?

I build the package in mock and share the entire 
.../fedora-rawhide-x86_64/root/builddir/build/BUILD/ directory?


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

Orphaned package: imake

2022-01-21 Thread Adam Jackson

I ported X off of imake a bit over 16 years ago but apparently there's
still 20-odd packages that use it. I don't have the bandwidth or
interest to maintain it, so someone who does is welcome to pick it up.

- ajax
___
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: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

2022-01-21 Thread Mark Wielaard

Hi,

On Thu, 2022-01-20 at 17:56 -0500, Marek Polacek wrote:
> On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
> > On 1/11/22 13:00, Steve Grubb wrote:
> > > Reading through the GCC 12 changes, there is a significant new feature to 
> > > GCC 
> > > that would appear to be useful for security. There is a new:
> > > 
> > > -ftrivial-auto-var-init=zero
> > > 
> > > flag that initializes all stack variables to zero. Zero being a nice safe 
> > > value that makes programs crash instead of being exploitable.
> > > 
> > > Are there plans to enable this flag so that all applications, but more 
> > > importantly the kernel, are hardened against uninitialized stack 
> > > variables? 
> > > This is one of the major classes of security bugs that could potentially 
> > > be 
> > > eliminated during this mass rebuild.
> > 
> > There are currently no plans that I am aware of that involve turning on
> > '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub
> > and Marek to comment.
> 
> Also not aware of any plans to always enable it.
>  
> > It is something that should be discussed, turned on in Rawhide first,
> > and likely via redhat-rpm-config default flags first, and then we should
> > fix any fallout.
> > 
> > I'd only be comfortable if we did it early and worked through the 
> > consequences.
> > So it could be something to discuss for F37.
> 
> Right.  It reminds me of MALLOC_PERTURB_, but for automatic variables.
> 
> Obviously it's always important to measure its slowdown (maybe run a SPEC
> benchmark) / compile time / stack usage.  Some of it has been done:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
> but that was an early version of the patch.  Still, it seems like it'd be
> acceptable.
> 
> It's a new feature, only present in GCC 12 (which hasn't been released as of
> now), so I think it needs more testing before it could be (considered to be)
> enabled by default.
> 
> A good thing is that it doesn't suppress the -Wuninitialized warning so
> you still get a chance to fix your bugs.  It also comes with an attribute
> to keep variables uninitialized even when the options is turned on.

Note that it does make it impossible for valgrind memcheck to track use
of uninitialized (stack) values because it will believe they have been
initialized with zero in any code that is build with this flag, and it
will assume that zero is a valid value.

Obviously as a valgrind hacker I am biased, believing lots of people
run valgrind on production code. So I do think that makes it harder to
find real security issues. Now the code will just appear to work using
a possibly bogus value of zero instead of valgrind memcheck pointing
out where and why you are using an uninitialized value.

Cheers,

Mark
___
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: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, Jan 21, 2022 at 06:42:23PM +0100, Dan Horák wrote:
> > > 
> > > Also note that libmpc failed to build on ppc64le only:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> > 
> > one test core-dumps, I will try a local build to see what's in the core
> 
> Error for mpc_pow_ld (1)
> expected (-9 46)
> got (1.00e0 0)
> FAIL tpow_ld (exit status: 1)
> 
> ^^^ might be related to
> https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition
> 
> 
> dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
> FAIL tset (exit status: 134)
> 
> ^^^ dunno

I'd bet the rebuilds need to go in gmp, then mpfr, then libmpc order
so that the first ones pick the new long double ABI.

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

Re: Build failure in Clementine due to GCC 12

2022-01-21 Thread Jonathan Wakely

On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
>
> On 1/21/22 14:46, Robert-André Mauchin wrote:
> > Hello,
> >
> > So I built Clementine last week with no issue, but it failed during
> > the mass rebuild with the folloing error:
> >
> > In file included from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > HandlerType = AbstractMessageHandler]':
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > required from here
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> >  error: passing 'QString' as 'this' argument discards qualifiers 
> > [-fpermissive]
> > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > |   ^
> > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> >from /usr/include/qt5/QtCore/qlist.h:47,
> >from /usr/include/qt5/QtCore/qstringlist.h:41,
> >from /usr/include/qt5/QtCore/QStringList:1,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > QString::toLower() &&'
> > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > |   ^~~
> >
> >
> > Nothing stands up to me in the linked code:
> >
> > template 
> > WorkerPool::WorkerPool(QObject* parent)
> >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> >local_server_name_ = qApp->applicationName().toLower();
> >
> >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > }
> >
> >
> > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > any input at all?
> >
> > Best regards,
> >
> > Robert-André
>
> So the problem is specific to GCC 12 but I can't find anything in the 
> changelog related to this.
> It seems toLower() takes a const as input and qApp->applicationName() is not 
> a const.

No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.

>
> I solved by replacing
> local_server_name_ = qApp->applicationName().toLower();
> to
> local_server_name_ = QString(qApp->applicationName()).toLower();

This creates an rvalue, which allows the call to toLower().

> Still I would love for a GCC specialist to point me to the relevant change in 
> GCC 12 so I can
> send a patch upstream with explanation for the change.

The Qt code has two overloads:

Q_REQUIRED_RESULT QString toLower() const &
{ return toLower_helper(*this); }
Q_REQUIRED_RESULT QString toLower() &&
{ return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

I don't think this is a GCC change though.
___
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: gcc-12.0.0-0.4.fc36 in rawhide

> > 
> > Also note that libmpc failed to build on ppc64le only:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> one test core-dumps, I will try a local build to see what's in the core

Error for mpc_pow_ld (1)
expected (-9 46)
got (1.00e0 0)
FAIL tpow_ld (exit status: 1)

^^^ might be related to
https://fedoraproject.org/wiki/Changes/PPC64LE_Float128_Transition


dd1.c:545: MPFR assertion failed: rnd_mode == MPFR_RNDA
FAIL tset (exit status: 134)

^^^ dunno


Dan
___
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: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297

^^^ those are probably
https://bugzilla.redhat.com/show_bug.cgi?id=2043517

> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

^^^ those are different, but also LTO related

> 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

one test core-dumps, I will try a local build to see what's in the core


Dan
___
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: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 10:09:39 -0700
Jerry James  wrote:

> On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> > could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517
> 
> Thanks for the pointer, Dan.

I think the keyword for this bug is "during RTL pass: final" followed
by an ICE segfault

But there could be other issues too ...


Dan
___
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: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

2022-01-21 Thread Steve Grubb

Hello,

On Thursday, January 20, 2022 5:56:04 PM EST Marek Polacek wrote:
> > > Are there plans to enable this flag so that all applications, but more
> > > importantly the kernel, are hardened against uninitialized stack
> > > variables? This is one of the major classes of security bugs that
> > > could potentially be eliminated during this mass rebuild.
> > 
> > There are currently no plans that I am aware of that involve turning on
> > '-ftrivial-auto-var-init=zero' in the short term for Fedora. CC'ing Jakub
> > and Marek to comment.
> 
> Also not aware of any plans to always enable it.

I think we should consider it. I'll start a new thread so that the topic is 
clearer.
 
> > It is something that should be discussed, turned on in Rawhide first,
> > and likely via redhat-rpm-config default flags first, and then we should
> > fix any fallout.
> > 
> > I'd only be comfortable if we did it early and worked through the
> > consequences. So it could be something to discuss for F37.
> 
> Right.  It reminds me of MALLOC_PERTURB_, but for automatic variables.
> 
> Obviously it's always important to measure its slowdown (maybe run a SPEC
> benchmark) / compile time / stack usage.  Some of it has been done:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562872.html
> but that was an early version of the patch.  Still, it seems like it'd be
> acceptable.
> 
> It's a new feature, only present in GCC 12 (which hasn't been released as
> of now), so I think it needs more testing before it could be (considered
> to be) enabled by default.

That's fine. I think F37 is a good target.

> A good thing is that it doesn't suppress the -Wuninitialized warning so
> you still get a chance to fix your bugs.  It also comes with an attribute
> to keep variables uninitialized even when the options is turned on.
> 
> From what I've seen its the kernel that would most benefit from the option,
> and it looks like it already has support for it:
> 
> CONFIG_INIT_STACK_ALL_ZERO
> CONFIG_INIT_STACK_ALL_PATTERN
> 
> so maybe it's enough to enable it for the kernel.  Or start there, see how
> it does, then add it to our hardening flags.

Unless it's been reworked to also allow gcc, this was a clang only option. 
There are a number of distributions that use clang as the compiler for the 
whole project. But let's discuss this in a separate thread about this topic.

Best Regards,
-Steve

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Jerry James

On Fri, Jan 21, 2022 at 10:06 AM Dan Horák  wrote:
> could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517

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

Re: s390 ruby build failure

2022-01-21 Thread Kevin Fenzi

On Fri, Jan 21, 2022 at 12:20:48PM +0100, Vít Ondruch wrote:
> 
> 
> I can't do that:
> 
> 
> ~~~
> 
> $ koji save-failed-tree 81534987
> 2022-01-21 12:20:12,267 [ERROR] koji: ActionNotAllowed: Only owner of failed
> task or 'admin' can run this task.

And sadly due to the mass rebuild churn it's already not available: 

 ~ koji save-failed-tree 81534987
Created task 81611235 for buildroot 32534387
Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=81611235
Watching tasks (this may be safely interrupted)...
81611235 saveFailedTree (noarch): assigned
81611235 saveFailedTree (noarch): assigned -> FAILED: GenericError: Buildroot 
directory is missing: /var/lib/mock/f36-build-32534387-4400356/root/builddir
  0 free  0 open  0 done  1 failed

81611235 saveFailedTree (noarch) failed

I'd suggest just doing a scratch build and in that spec dumping out the
files you need for debugging.

kevin

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, 21 Jan 2022 09:55:01 -0700
Jerry James  wrote:

> On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double.  This is an ABI change.  Some libraries
> > are already built so that they support both ABIs at the same time,
> > including glibc, libstdc++, libgcc, libgfortran etc.
> > For other libraries and binaries, the compiler, assembler and linker
> > will notice if they use long double and flag them as using either
> > IBM or IEEE long double and linker (or I think dynamic linker too)
> > might complain when things are mixed.
> > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> > but the glibc/gcc libraries are built compatibly with both.
> > We'd like to configure gcc shortly before the mass rebuild with
> > --with-long-double-format=ieee so that it will default to
> > -mabi=ieeelongdouble, probably on a side-tag build first, and it
> > will be highly desirable to rebuild at least some of the most commonly
> > used library packages in the order of dependencies there, otherwise
> > I'd be afraid the mass rebuild could fail for way too many packages
> > (as the mass rebuild doesn't do dependency order rebuilds but just
> > goes through packages alphabetically or so).
> 
> I don't know if this change is involved, but I've got several packages
> that failed to build on ppc64le only, with what look like gcc
> segfaults:
> - cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
> - dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
> - libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
> - libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
> - mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
> - python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

could be https://bugzilla.redhat.com/show_bug.cgi?id=2043517


Dan
 
> Also note that libmpc failed to build on ppc64le only:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783
> 
> Since gcc uses libmpc, it's probably important to look at that one carefully.
> -- 
> Jerry James
> http://www.jamezone.org/
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: DIGLIM (System-Wide Change proposal)

2022-01-21 Thread Kevin Fenzi

On Wed, Jan 19, 2022 at 11:34:28AM +, Roberto Sassu via devel wrote:
> > From: Roberto Sassu
> > Sent: Tuesday, January 18, 2022 3:36 PM
> > Hi everyone
> > 
> > I recently sent to the kernel mailing lists a patch set to support
> > PGP keys and signatures.
> > 
> > Other than allowing the appraisal of RPM headers without
> > changes to the building infrastructure, it would also simplify
> > key management for the use cases requiring file or fsverity
> > signatures (no need for a secondary key).
> > 
> > This is the link of the patch set:
> > 
> > https://lore.kernel.org/linux-integrity/2022080318.591029-1-
> > roberto.sa...@huawei.com/
> > 
> > One point of the discussion was if there is the need to support
> > PGP in the kernel, or if a distribution should adapt its key
> > management to be compatible with key types currently available
> > in the kernel.
> 
> I have a question related to this. Is the private key used to sign
> kernel modules available also when other packages are built?

Nope. My understanding is that this is only available during that kernel
build and then disguarded. (But you could perhaps ask on fedora's kernel
list about it for more info). 

kevin


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

GCC 12 related issues in rawhide

Hi!

There have been way too many mails recently in the
gcc-12.0.0-0.4.fc36 in rawhide thread and separate threads,
so for those which we haven't responded to yet or new issues,
can I ask you to track it in bugzilla instead of mailing list?

For issues where you suspect it is a bug on a package side and
you'd just like the compiler team to help answer questions,
please file a FTBS bug against the package which fails to build
and CC me and/or Marek Polacek and/or for libstdc++ related questions
Jonathan Wakely.
For issues where you suspect or are sure about a bug on the compiler
side please file a bug against GCC (worst case the component can
be changed against the package).

In all cases, if it is some compiler error or internal compiler error,
preprocessed source + gcc command line would be highly appreciated,
having us to try to rebuild all the packages again and dig those up
will be very time consuming.

Thanks

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

Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-21 Thread Jerry James

On Fri, Jan 14, 2022 at 7:32 AM Jakub Jelinek  wrote:
> Another important thing I wanted to say is that we'd like to switch
> ppc64le from the numerically problematic IBM extended long double to
> IEEE 754 quad long double.  This is an ABI change.  Some libraries
> are already built so that they support both ABIs at the same time,
> including glibc, libstdc++, libgcc, libgfortran etc.
> For other libraries and binaries, the compiler, assembler and linker
> will notice if they use long double and flag them as using either
> IBM or IEEE long double and linker (or I think dynamic linker too)
> might complain when things are mixed.
> Right now the rawhide gcc still defaults to -mabi=ibmlongdouble
> but the glibc/gcc libraries are built compatibly with both.
> We'd like to configure gcc shortly before the mass rebuild with
> --with-long-double-format=ieee so that it will default to
> -mabi=ieeelongdouble, probably on a side-tag build first, and it
> will be highly desirable to rebuild at least some of the most commonly
> used library packages in the order of dependencies there, otherwise
> I'd be afraid the mass rebuild could fail for way too many packages
> (as the mass rebuild doesn't do dependency order rebuilds but just
> goes through packages alphabetically or so).

I don't know if this change is involved, but I've got several packages
that failed to build on ppc64le only, with what look like gcc
segfaults:
- cli11: https://koji.fedoraproject.org/koji/taskinfo?taskID=81476792
- dra2ter: https://koji.fedoraproject.org/koji/taskinfo?taskID=81482527
- libfplll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81533813
- libpoly: https://koji.fedoraproject.org/koji/taskinfo?taskID=81536797
- mp: https://koji.fedoraproject.org/koji/taskinfo?taskID=81548297
- python-fpylll: https://koji.fedoraproject.org/koji/taskinfo?taskID=81597035

Also note that libmpc failed to build on ppc64le only:
https://koji.fedoraproject.org/koji/taskinfo?taskID=81535783

Since gcc uses libmpc, it's probably important to look at that one carefully.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: git clone under mock/koji builders


On 21. 01. 22 17:39, Ron Olson wrote:

Is it possible to clone a repo as part of a Source line? I’ve been looking and 
can’t find any examples.


See 
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_using_revision_control 
and 
https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_git_hosting_services


--
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: git clone under mock/koji builders

2022-01-21 Thread Ron Olson

Is it possible to clone a repo as part of a Source line? I’ve been looking and 
can’t find any examples.

On 21 Jan 2022, at 10:34, Miro Hrončok wrote:

> On 21. 01. 22 17:21, Ron Olson wrote:
>> Hey all-
>>
>> I have a package that gets an artifact from a repo /and/ expects to have 
>> code from a different branch in the same repo. In my spec file, I can easily 
>> get the artifact via Sources, but getting the code from the separate branch 
>> required me to execute a “git clone” then checkout the branch. This works 
>> fine until I tried doing a mock build where I ran into the issue that 
>> networking like this is apparently unavailable. I saw that I can enabled it 
>> with a command line switch, but I presume that’s not possible with koji.
>>
>> Is there any proper way to checkout code with git from within koji?
>
> No. You need to add it as an extra Source. Koji builds are always offline.
>
> -- 
> 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: git clone under mock/koji builders

2022-01-21 Thread Vitaly Zaitsev via devel


On 21/01/2022 17:21, Ron Olson wrote:

Is there any proper way to checkout code with git from within koji?


No. Koji doesn't have network access for security reasons. You must 
download submodules/etc as sources.


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

Re: git clone under mock/koji builders


On 21. 01. 22 17:21, Ron Olson wrote:

Hey all-

I have a package that gets an artifact from a repo /and/ expects to have code 
from a different branch in the same repo. In my spec file, I can easily get the 
artifact via Sources, but getting the code from the separate branch required me 
to execute a “git clone” then checkout the branch. This works fine until I 
tried doing a mock build where I ran into the issue that networking like this 
is apparently unavailable. I saw that I can enabled it with a command line 
switch, but I presume that’s not possible with koji.


Is there any proper way to checkout code with git from within koji?


No. You need to add it as an extra Source. Koji builds are always offline.

--
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: Build failure in Clementine due to GCC 12


On 1/21/22 14:46, Robert-André Mauchin wrote:

Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
    required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
    168 |   local_server_name_ = qApp->applicationName().toLower();
    |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
   from /usr/include/qt5/QtCore/qlist.h:47,
   from /usr/include/qt5/QtCore/qstringlist.h:41,
   from /usr/include/qt5/QtCore/QStringList:1,
   from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
    510 | Q_REQUIRED_RESULT QString toLower() &&
    |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
     : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
   worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
   local_server_name_ = qApp->applicationName().toLower();

   if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

Best regards,

Robert-André


So the problem is specific to GCC 12 but I can't find anything in the changelog 
related to this.
It seems toLower() takes a const as input and qApp->applicationName() is not a 
const.

I solved by replacing
local_server_name_ = qApp->applicationName().toLower();
to
local_server_name_ = QString(qApp->applicationName()).toLower();

Still I would love for a GCC specialist to point me to the relevant change in 
GCC 12 so I can
send a patch upstream with explanation for the change.

Thank you.

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: git clone under mock/koji builders

On Fri, 21 Jan 2022 10:21:11 -0600
Ron Olson  wrote:

> Hey all-
> 
> I have a package that gets an artifact from a repo *and* expects to have 
> code from a different branch in the same repo. In my spec file, I can 
> easily get the artifact via Sources, but getting the code from the 
> separate branch required me to execute a “git clone” then checkout 
> the branch. This works fine until I tried doing a mock build where I ran 
> into the issue that networking like this is apparently unavailable. I 
> saw that I can enabled it with a command line switch, but I presume 
> that’s not possible with koji.
> 
> Is there any proper way to checkout code with git from within koji?

builds in koji have network disabled by design


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

git clone under mock/koji builders

2022-01-21 Thread Ron Olson


Hey all-

I have a package that gets an artifact from a repo *and* expects to have 
code from a different branch in the same repo. In my spec file, I can 
easily get the artifact via Sources, but getting the code from the 
separate branch required me to execute a “git clone” then checkout 
the branch. This works fine until I tried doing a mock build where I ran 
into the issue that networking like this is apparently unavailable. I 
saw that I can enabled it with a command line switch, but I presume 
that’s not possible with koji.


Is there any proper way to checkout code with git from within koji?

Thanks for any info!

Ron___
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: Plocate as the default locate implementation (Self-Contained Change proposal)


On 21. 01. 22 17:03, Zdenek Pytela wrote:

Hey folks,

I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot of:

type=AVC msg=audit(1642770831.616:31668): avc:  denied  { read } for
pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0

Is this a bug, or some kind of error in configuration?

plocate uses /var/lib/plocate as its data directory, so it needs to have 
assigned the correct label in selinux-policy. I've already submitted a PR for 
the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018 



Thanks!

--
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: Enable fs-verity in RPM (System-Wide Change proposal)

2022-01-21 Thread Roberto Sassu via devel

Hi everyone

(note for the infrastructure mailing list: please check if the changes
I'm proposing could be tested in the Fedora infrastructure, like Copr)

I made the first version of the rpm extension to sign fsverity
digests with a GPG key. The patch set (with some bug fixes)
is available here:

https://github.com/robertosassu/rpm/commits/fsverity-gpg-v1

I tested it locally with my own GPG key. I took an existing
Fedora 34 package and signed it with rpmsign:

$ usr/bin/rpmsign --define "%_gpg_name testhost " \
 --define "%_file_signing_key _GPG_" \
 --define "%_file_signing_cert _GPG_" \
 --addsign --signverity 
tmux-3.1c-2.fc34.x86_64.rpm


I then checked that the package has now fsverity signatures:

$ usr/bin/rpm -qp tmux-3.1c-2.fc34.x86_64.rpm \
  --queryformat '[%{RPMTAG_FILENAMES} 
%{RPMTAG_VERITYSIGNATURES}\n]'
[...]
/usr/bin/tmux iQHHBAABCgAxFiEEEiFa0dGZVYzTrIN+rxtXRMfK0McFAmHq0+4THHRlc3Rob3N0
QHRlc3QudGVzdAAKCRCvG1dEx8rQx81nC/42NW9xJx3rcTiR6/5oL55GPkan+OIq
t2dW1clJUOrxOGVy/5JQTQf0MQXA7gzH1yPgcrskkahjSfWlp4pt7oOw3rukUyaO
zVZxue4XE6XESYtolczK4VEhpc8lbm4hj0e4NCg/dKri/+L5wIdJvmqWNeCfl7uZ
[...]

In a VM I tried to install the modified package. The root filesystem
is ext4 and has the fsverity feature enabled.

The fsverity rpm plugin is also enabled and hasn't been modified
to work with the new PGP signatures.

The kernel includes the patch set I recently sent to the kernel
mailing lists to add support for PGP keys and signatures:

https://lore.kernel.org/linux-integrity/2022080318.591029-1-roberto.sa...@huawei.com/

and another patch that calls verify_pgp_signature() in
fs/verity/signature.c.

The first installation attempt fails, due to the missing key
in the .fs-verity keyring:

# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug
[...]
D: Plugin: calling hook fsm_file_prepare in fsverity plugin
D: applying signature: 
[...]
D: failed to enable verity (errno 126) for /usr/bin/tmux;61ead62d

Then, I added the required GPG key to the .fs-verity keyring:

# cat /mnt/repos/linux/certs/pubring.gpg | keyctl padd asymmetric test 
%keyring:.fs-verity
76292211

The key is now loaded:

# keyctl show %keyring:.fs-verity
Keyring
  66741466 --a-swrv  0 0  keyring: .fs-verity
  76292211 --als--v  0 0   \_ asymmetric: test

I retried the tmux installation:

# usr/bin/rpm -Uhvi ../tmux-3.1c-2.fc34.x86_64.rpm --debug
[...]
D: Plugin: calling hook fsm_file_prepare in fsverity plugin
D: applying signature: 
[...]
D: fsverity enabled signature for: path /usr/bin/tmux;61ead713 dest 
/usr/bin/tmux

This time the installation is successful, which means that the PGP
signature has been successfully verified.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua
___
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: Plocate as the default locate implementation (Self-Contained Change proposal)

2022-01-21 Thread Zdenek Pytela

On Fri, Jan 21, 2022 at 2:24 PM Miro Hrončok  wrote:

> On 23. 11. 21 18:18, Ben Cotton wrote:
> >
> https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation
> >
> > == Summary ==
> > The venerable `mlocate` program is replaced by `plocate` — a
> > compatible reimplementation that is faster and uses less disk space.
> >
> >
> > == Owner ==
> > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbyszek at in.waw.pl
> > * Name: [[User:Msekleta| Michal Sekletár]]
> > * Email: msekleta at redhat.com
> > ...
>
> Hey folks,
>
> I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot
> of:
>
> type=AVC msg=audit(1642770831.616:31668): avc:  denied  { read } for
> pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
> scontext=system_u:system_r:setroubleshootd_t:s0
> tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
>
> Is this a bug, or some kind of error in configuration?
>
plocate uses /var/lib/plocate as its data directory, so it needs to have
assigned the correct label in selinux-policy. I've already submitted a PR
for the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018


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


-- 

Zdenek Pytela
Security SELinux team
___
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: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Gary Buhrmaster

On Fri, Jan 21, 2022 at 3:27 PM Vít Ondruch  wrote:

> Isn't it just the standard GMail deduplication?

Likely.  For better or worse, that is the way gmail works.

One can see both the advantages and disadvantages
of the gmail approach, but it does catch some of the
people off-guard at least some of the time (even
those that are familiar with it).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Prioritized Bugs update

2022-01-21 Thread Ben Cotton

It's been a while since we've had some Prioritized Bugs that are
stuck, but here we are. If you can help move these forward, you are a
hero.

1. shim — https://bugzilla.redhat.com/show_bug.cgi?id=1955416 — NEW
Lenovo ThinkPad T490, unable to boot following clean install, stuck at
splash screen

This bug appears to affect multiple popular hardware vendors. Lenovo
is aware of the issue but hasn't been able to reproduce, nor have
maintainers. mattdm was going to connect with the Red Hat Desktop team
to see if they could reproduce. If someone can reliably reproduce this
and test development builds of shim, that would help diagnose the
issue.

2. flatpak — https://bugzilla.redhat.com/show_bug.cgi?id=2032528 — NEW
Flatpak using excessive space in /var/lib/flatpak/appstream

For some users, the appstream directory contains a lot of hidden
subdirectories resulting in many gigabytes of usage.

For more information about the Fedora Prioritized Bugs process, see
https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/

Minutes and logs from the most recent meeting are at
https://meetbot.fedoraproject.org/teams/fedora_prioritized_bugs_and_issues/fedora_prioritized_bugs_and_issues.2022-01-12-16.00.html

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

Re: Do I have a @fedoraproject.org e-mail address ?



Dne 21. 01. 22 v 15:57 Alain Vigne napsal(a):

Thank you all
To conclude

  * I have a working @fedoraproject.org
 email alias
  * "external" people can reach me via this alias
  * I can't receive emails I sent to this alias from my gmail address
(which is my email address registered in Fedora Accounts)



Isn't it just the standard GMail deduplication?


Vít



  * I need to dig into
https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/

Best regards
Alain

On Fri, Jan 21, 2022 at 3:44 PM Luna Jernberg  
wrote:


Seems my test email worked

On Fri, Jan 21, 2022 at 3:18 PM Alain Vigne
 wrote:

Thank you, I did read this wiki page a long time ago, but was
not able to retrieve it :(

I remembered that it should work this way, so I sent a test
email to my fedora... address, and I was expecting to get it
in my gmail mailbox...  But it doesn't seem to work for me ?
Maybe an infinite loop ?

  * gmail sends to fedoraproject which forwards to gmail ?

My test e-mail doesn't land in my gmail spam either...

Could someone send me something at   avigne AT fedoraproject
org   please ?
Is there something wrong with me ?
TIA
Alain

On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha
 wrote:

On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
> Hi
> I am a Fedora packager [1] and I thought writing to
> my_...@fedoraproject.org
> would redirect to my registered e-mail address... It
seems not !?
> If yes, how to enter needed information to Thunderbird
client, for ex. ?
>
> I couldn't find documentation about this question. Thank
you for your
> explanations.

It is an e-mail alias, there's no mailbox attached to it.
It simply
redirects to whatever e-mail you've specified in FAS.

More information here:

https://fedoraproject.org/wiki/EmailAliases

-- 
Thanks,

Regards,
Ankur Sinha "FranciscoD" (He / Him / His) |
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
___
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



-- 
Alain V.

___
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



--
Alain V.

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


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

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread arthur


On 21/01/2022 15:57, Alain Vigne wrote:

Thank you all
To conclude

  * I have a working @fedoraproject.org
 email alias
  * "external" people can reach me via this alias
  * I can't receive emails I sent to this alias from my gmail address
(which is my email address registered in Fedora Accounts)
  * I need to dig into
https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/

Best regards
Alain



Sometimes it takes a while (multiple minutes) to receive an email. It 
could also be that gmail drops the emails for some reason, but if you 
receive emails sent from a different address it should be fine.

I think you have all information now, good luck!

PS. Since I've noticed it several times in this thread, please don't top 
post.
Please read this wiki article: 
https://fedoraproject.org/wiki/Mailing_list_guidelines#Proper_posting_style


--
Arthur Bols
fas/irc: principis
___
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: Do I have a @fedoraproject.org e-mail address ?

Thank you all
To conclude

   - I have a working @fedoraproject.org  email alias
   - "external" people can reach me via this alias
   - I can't receive emails I sent to this alias from my gmail address
   (which is my email address registered in Fedora Accounts)
   - I need to dig into
   https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/

Best regards
Alain

On Fri, Jan 21, 2022 at 3:44 PM Luna Jernberg  wrote:

> Seems my test email worked
>
> On Fri, Jan 21, 2022 at 3:18 PM Alain Vigne 
> wrote:
>
>> Thank you, I did read this wiki page a long time ago, but was not able to
>> retrieve it :(
>>
>> I remembered that it should work this way, so I sent a test email to my
>> fedora... address, and I was expecting to get it in my gmail mailbox...
>> But it doesn't seem to work for me ?
>> Maybe an infinite loop ?
>>
>>- gmail sends to fedoraproject which forwards to gmail ?
>>
>> My test e-mail doesn't land in my gmail spam either...
>>
>> Could someone send me something at   avigne AT fedoraproject org   please
>> ?
>> Is there something wrong with me ?
>> TIA
>> Alain
>>
>> On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha 
>> wrote:
>>
>>> On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
>>> > Hi
>>> > I am a Fedora packager [1] and I thought writing to
>>> > my_...@fedoraproject.org
>>> > would redirect to my registered e-mail address... It seems not !?
>>> > If yes, how to enter needed information to Thunderbird client, for ex.
>>> ?
>>> >
>>> > I couldn't find documentation about this question. Thank you for your
>>> > explanations.
>>>
>>> It is an e-mail alias, there's no mailbox attached to it. It simply
>>> redirects to whatever e-mail you've specified in FAS.
>>>
>>> More information here:
>>>
>>> https://fedoraproject.org/wiki/EmailAliases
>>>
>>> --
>>> Thanks,
>>> Regards,
>>> Ankur Sinha "FranciscoD" (He / Him / His) |
>>> https://fedoraproject.org/wiki/User:Ankursinha
>>> Time zone: Europe/London
>>> ___
>>> 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
>>>
>>
>>
>> --
>> Alain V.
>> ___
>> 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
>>
>

-- 
Alain V.
___
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: Self Introduction: Chung Chung

2022-01-21 Thread David Kirwan

 Welcome Chung!

On Fri, 21 Jan 2022 at 12:45, Chihurumnaya Ibiam <
ibiamchihurumn...@gmail.com> wrote:

> Welcome Chung!
>
> --
>
> Ibiam Chihurumnaya
> ibiamchihurumn...@gmail.com
>
>
>
>
> On Fri, Jan 21, 2022 at 1:34 PM Chung Chung  wrote:
>
>>
>> Hi All:
>>
>>   My name is Chung, I work in Red Hat and maintain lab systems for my
>> team.
>>
>>   I have been doing DevOps/SysAdmin for quite a few years now.   I have
>> done some RPM package build for my group internally and I would like to
>> contribute as a package maintainer.
>>
>>   There are some packages we used in the lab I plan to take ownership of
>> and I am open to taking on maintaining other packages also.
>>
>>   Thanks and excited for the opportunity to contribute.
>>
>> Chung
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam on the list, report it:
>> https://pagure.io/fedora-infrastructure
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
David Kirwan
Software Engineer

Community Platform Engineering @ Red Hat

T: +(353) 86-8624108 IM: @dkirwan
___
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: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Luna Jernberg

Seems my test email worked

On Fri, Jan 21, 2022 at 3:18 PM Alain Vigne 
wrote:

> Thank you, I did read this wiki page a long time ago, but was not able to
> retrieve it :(
>
> I remembered that it should work this way, so I sent a test email to my
> fedora... address, and I was expecting to get it in my gmail mailbox...
> But it doesn't seem to work for me ?
> Maybe an infinite loop ?
>
>- gmail sends to fedoraproject which forwards to gmail ?
>
> My test e-mail doesn't land in my gmail spam either...
>
> Could someone send me something at   avigne AT fedoraproject org   please ?
> Is there something wrong with me ?
> TIA
> Alain
>
> On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha 
> wrote:
>
>> On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
>> > Hi
>> > I am a Fedora packager [1] and I thought writing to
>> > my_...@fedoraproject.org
>> > would redirect to my registered e-mail address... It seems not !?
>> > If yes, how to enter needed information to Thunderbird client, for ex. ?
>> >
>> > I couldn't find documentation about this question. Thank you for your
>> > explanations.
>>
>> It is an e-mail alias, there's no mailbox attached to it. It simply
>> redirects to whatever e-mail you've specified in FAS.
>>
>> More information here:
>>
>> https://fedoraproject.org/wiki/EmailAliases
>>
>> --
>> Thanks,
>> Regards,
>> Ankur Sinha "FranciscoD" (He / Him / His) |
>> https://fedoraproject.org/wiki/User:Ankursinha
>> Time zone: Europe/London
>> ___
>> 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
>>
>
>
> --
> Alain V.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Do I have a @fedoraproject.org e-mail address ?

Why this has to be SO complicated ?

On Fri, Jan 21, 2022 at 3:35 PM Eduard Lucena 
wrote:

> El vie., 21 de enero de 2022 11:18, Alain Vigne 
> escribió:
>
>> Thank you, I did read this wiki page a long time ago, but was not able to
>> retrieve it :(
>>
>> I remembered that it should work this way, so I sent a test email to my
>> fedora... address, and I was expecting to get it in my gmail mailbox...
>> But it doesn't seem to work for me ?
>> Maybe an infinite loop ?
>>
>>- gmail sends to fedoraproject which forwards to gmail ?
>>
>> My test e-mail doesn't land in my gmail spam either...
>>
>> Could someone send me something at   avigne AT fedoraproject org   please
>> ?
>> Is there something wrong with me ?
>> TIA
>> Alain
>>
>> On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha 
>> wrote:
>>
>>> On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
>>> > Hi
>>> > I am a Fedora packager [1] and I thought writing to
>>> > my_...@fedoraproject.org
>>> > would redirect to my registered e-mail address... It seems not !?
>>> > If yes, how to enter needed information to Thunderbird client, for ex.
>>> ?
>>> >
>>> > I couldn't find documentation about this question. Thank you for your
>>> > explanations.
>>>
>>> It is an e-mail alias, there's no mailbox attached to it. It simply
>>> redirects to whatever e-mail you've specified in FAS.
>>>
>>> More information here:
>>>
>>> https://fedoraproject.org/wiki/EmailAliases
>>>
>>> --
>>> Thanks,
>>> Regards,
>>> Ankur Sinha "FranciscoD" (He / Him / His) |
>>> https://fedoraproject.org/wiki/User:Ankursinha
>>> Time zone: Europe/London
>>> ___
>>> 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
>>>
>>
>>
>> --
>> Alain V.
>> ___
>> 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
>>
>
>>
>>
>
> It's a little harder to make it work with Gmail, but not impossible. Take
> a look at
> https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/
>
>
> There is comment I did about how to complete a step. It's related to 2FA.
>
>
> Hope it helps.
>
> Br,
> ___
> 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
>


-- 
Alain V.
___
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: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Eduard Lucena

El vie., 21 de enero de 2022 11:18, Alain Vigne 
escribió:

> Thank you, I did read this wiki page a long time ago, but was not able to
> retrieve it :(
>
> I remembered that it should work this way, so I sent a test email to my
> fedora... address, and I was expecting to get it in my gmail mailbox...
> But it doesn't seem to work for me ?
> Maybe an infinite loop ?
>
>- gmail sends to fedoraproject which forwards to gmail ?
>
> My test e-mail doesn't land in my gmail spam either...
>
> Could someone send me something at   avigne AT fedoraproject org   please ?
> Is there something wrong with me ?
> TIA
> Alain
>
> On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha 
> wrote:
>
>> On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
>> > Hi
>> > I am a Fedora packager [1] and I thought writing to
>> > my_...@fedoraproject.org
>> > would redirect to my registered e-mail address... It seems not !?
>> > If yes, how to enter needed information to Thunderbird client, for ex. ?
>> >
>> > I couldn't find documentation about this question. Thank you for your
>> > explanations.
>>
>> It is an e-mail alias, there's no mailbox attached to it. It simply
>> redirects to whatever e-mail you've specified in FAS.
>>
>> More information here:
>>
>> https://fedoraproject.org/wiki/EmailAliases
>>
>> --
>> Thanks,
>> Regards,
>> Ankur Sinha "FranciscoD" (He / Him / His) |
>> https://fedoraproject.org/wiki/User:Ankursinha
>> Time zone: Europe/London
>> ___
>> 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
>>
>
>
> --
> Alain V.
> ___
> 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
>

>
>

It's a little harder to make it work with Gmail, but not impossible. Take a
look at
https://communityblog.fedoraproject.org/using-fedora-email-alias-gmail/


There is comment I did about how to complete a step. It's related to 2FA.


Hope it helps.

Br,
___
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: Do I have a @fedoraproject.org e-mail address ?

Thank you, I did read this wiki page a long time ago, but was not able to
retrieve it :(

I remembered that it should work this way, so I sent a test email to my
fedora... address, and I was expecting to get it in my gmail mailbox...
But it doesn't seem to work for me ?
Maybe an infinite loop ?

   - gmail sends to fedoraproject which forwards to gmail ?

My test e-mail doesn't land in my gmail spam either...

Could someone send me something at   avigne AT fedoraproject org   please ?
Is there something wrong with me ?
TIA
Alain

On Fri, Jan 21, 2022 at 2:52 PM Ankur Sinha  wrote:

> On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
> > Hi
> > I am a Fedora packager [1] and I thought writing to
> > my_...@fedoraproject.org
> > would redirect to my registered e-mail address... It seems not !?
> > If yes, how to enter needed information to Thunderbird client, for ex. ?
> >
> > I couldn't find documentation about this question. Thank you for your
> > explanations.
>
> It is an e-mail alias, there's no mailbox attached to it. It simply
> redirects to whatever e-mail you've specified in FAS.
>
> More information here:
>
> https://fedoraproject.org/wiki/EmailAliases
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) |
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London
> ___
> 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
>


-- 
Alain V.
___
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

CPE Weekly Update - Week of January 17th-22nd

2022-01-21 Thread Vipul Siddharth

Hi everyone,

This is a weekly report from the CPE (Community Platform Engineering)
Team. If you have any questions or feedback, please respond to this
report or contact us on #redhat-cpe channel on libera.chat
(https://libera.chat/).

We (CPE team) will be joining Fedora Social Hour on Jan 27th.
Looking forward to seeing a lot of you!
(https://discussion.fedoraproject.org/t/join-us-for-fedora-social-hour-every-week/18869/46)

If you wish to read this in form of a blog post, check the post on
Fedora community blog:
(https://communityblog.fedoraproject.org/cpe-weekly-update-week-of-january-17th-22nd/)


# Highlights of the week

## Infrastructure & Release Engineering
Goal of this initiative
---
Purpose of this team is to take care of day to day business regarding
CentOS and Fedora Infrastructure and Fedora release engineering work.
It’s responsible for services running in Fedora and CentOS
infrastructure and preparing things for the new Fedora release
(mirrors, mass branching, new namespaces etc.). The ARC (which is a
subset of the team) investigates possible initiatives that CPE might
take on.

Update
--

### Fedora Infra
* All koji builders/hubs upgraded to F35 and ready for mass rebuild ( 🤞 )
* Additional s390x disk space appeared, so added 10 more s390x builders.
* Fixed IPA issue with certs ( known upgrade bug)
* Difficult container builds failing issue solved.


### CentOS Infra including CentOS CI
* CentOS Linux 8 EOL plan
* Hardware issues (storage box, 64 compute nodes for CI infra)
* Kmods SIG DuD discussion (koji plugin vs external script)
* CI storage for ocp/openshift migration completed and working faster/better !
* CentOS CI tenants Survey (for the upcoming DC move)



### Release Engineering
* Mass rebuild starts today
* Several rawhide issues fixed and composes have been good the last few days.



## CentOS Stream
Goal of this initiative
---
This initiative is working on CentOS Stream/Emerging RHEL to make this
new distribution a reality. The goal of this initiative is to prepare
the ecosystem for the new CentOS Stream.

Updates
---
* The NFV repo was added to CentOS Stream 8, work is happening now on
the repo files in centos-release
* Module branching work is ongoing
* Libffi is causing some interesting breakage in ELN
* GCC bugs in ELN
* Koji/brew Inheritance discussions are still happening
* Testing Content Resolver with production data before deployment




## Datanommer/Datagrepper V.2
Goal of this initiative
---
The datanommer and datagrepper stacks are currently relying on fedmsg which
we want to deprecate.
These two applications need to be ported off fedmsg to fedora-messaging.
As these applications are 'old-timers' in the fedora infrastructure, we would
also like to look at optimizing the database or potentially redesigning it to
better suit the current infrastructure needs.
For a phase two, we would like to focus on a DB overhaul.

Updates
---
* It’s done! Data is migrated, the new code is now running in prod.


## CentOS Duffy CI
Goal of this initiative
---
Duffy is a system within CentOS CI Infra which allows tenants to provision and
access bare metal resources of multiple architectures for the purposes of
CI testing.
We need to add the ability to checkout VMs in CentOS CI in Duffy. We have
OpenNebula hypervisor available, and have started developing playbooks which
can be used to create VMs using the OpenNebula API, but due to the current state
of how Duffy is deployed, we are blocked with new dev work to add the
VM checkout functionality.

Updates
---
* Legacy API
* Node Pools & Ansible Backend


## Image builder for Fedora IoT
Goal of this initiative
---
Integration of Image builder as a service with Fedora infra to allow Fedora IoT
migrate their pipeline to Fedora infra.

Updates
---
* Officially kicked off this week
* Fact finding at the moment
* Met with Peter Robinson and team from Fedora IoT
* Need to figure out a way to run their pipeline
* At least 1 koji plugin to be written + deployed
* Meeting with Image Builder team tomorrow
* They are currently blocked by auth, development underway
* Need to get an idea of their API and what they expect from us


## Bodhi
Goal of this initiative
---
This initiative is to separate Bodhi into multiple sub packages,
fix integration and unit tests in CI, fix dependency management,
and automate part of the release process.
Read ARC team findings in detail at:
https://fedora-arc.readthedocs.io/en/latest/bodhi/index.html

Updates
---
* splitting the codebase into separate python packages
* migrating from CentOS CI to Zuul


## EPEL
Goal of this initiative
---
Extra Packages for Enterprise Linux (or EPEL) is a Fedora Special Interest
Group that creates, maintains, and manages a high quality set of additional
packages for Enterprise Linux, including, but not lim

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Ankur Sinha

On Fri, Jan 21, 2022 14:29:07 +0100, Alain Vigne wrote:
> Hi
> I am a Fedora packager [1] and I thought writing to
> my_...@fedoraproject.org
> would redirect to my registered e-mail address... It seems not !?
> If yes, how to enter needed information to Thunderbird client, for ex. ?
> 
> I couldn't find documentation about this question. Thank you for your
> explanations.

It is an e-mail alias, there's no mailbox attached to it. It simply
redirects to whatever e-mail you've specified in FAS.

More information here:

https://fedoraproject.org/wiki/EmailAliases

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


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

Re: Do I have a @fedoraproject.org e-mail address ?

2022-01-21 Thread Onuralp SEZER

Hello, please check here : https://fedoraproject.org/wiki/EmailAliases


On Fri, Jan 21, 2022 at 4:30 PM Alain Vigne 
wrote:

> Hi
> I am a Fedora packager [1] and I thought writing to
> my_...@fedoraproject.org
> would redirect to my registered e-mail address... It seems not !?
> If yes, how to enter needed information to Thunderbird client, for ex. ?
>
> I couldn't find documentation about this question. Thank you for your
> explanations.
>
> Kind regards
> --
> Alain V.
>
> [1] https://src.fedoraproject.org/user/avigne
> ___
> 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
>


-- 





--
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Turkey
Fedora Translations Turkish Team Member

Fedora Design Member 
___
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

Build failure in Clementine: I need help


Hello,

So I built Clementine last week with no issue, but it failed during
the mass rebuild with the folloing error:

In file included from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
  from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
 In instantiation of 'WorkerPool::WorkerPool(QObject*) [with HandlerType 
= AbstractMessageHandler]':
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
required from here
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
 error: passing 'QString' as 'this' argument discards qualifiers [-fpermissive]
   168 |   local_server_name_ = qApp->applicationName().toLower();
   |   ^
In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
  from /usr/include/qt5/QtCore/qlist.h:47,
  from /usr/include/qt5/QtCore/qstringlist.h:41,
  from /usr/include/qt5/QtCore/QStringList:1,
  from 
/builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
/usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
QString::toLower() &&'
   510 | Q_REQUIRED_RESULT QString toLower() &&
   |   ^~~


Nothing stands up to me in the linked code:

template 
WorkerPool::WorkerPool(QObject* parent)
: _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
  worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
  local_server_name_ = qApp->applicationName().toLower();

  if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
}


Anyone knows if a flag, or compiler, has changed since last week? Or have any 
input at all?

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

Do I have a @fedoraproject.org e-mail address ?

Hi
I am a Fedora packager [1] and I thought writing to
my_...@fedoraproject.org
would redirect to my registered e-mail address... It seems not !?
If yes, how to enter needed information to Thunderbird client, for ex. ?

I couldn't find documentation about this question. Thank you for your
explanations.

Kind regards
-- 
Alain V.

[1] https://src.fedoraproject.org/user/avigne
___
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: Plocate as the default locate implementation (Self-Contained Change proposal)


On 23. 11. 21 18:18, Ben Cotton wrote:

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

== Summary ==
The venerable `mlocate` program is replaced by `plocate` — a
compatible reimplementation that is faster and uses less disk space.


== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Msekleta| Michal Sekletár]]
* Email: msekleta at redhat.com
...


Hey folks,

I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot of:

type=AVC msg=audit(1642770831.616:31668): avc:  denied  { read } for 
pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062 
scontext=system_u:system_r:setroubleshootd_t:s0 
tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0


Is this a bug, or some kind of error in configuration?


--
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

2022-01-21 Thread Paolo Bonzini


On 1/21/22 13:47, Richard W.M. Jones wrote:

On Fri, Jan 21, 2022 at 01:30:38PM +0100, Paolo Bonzini wrote:

On 1/21/22 10:49, Richard W.M. Jones wrote:

Yes that works!


Are you going to make the change?  (For all of the QEMU firmware
packages---edk2, openbios, seabios in addition to SLOF---since you
are at it).


However edk2 has other problems revealed probably by GCC 12, see:
https://kojipkgs.fedoraproject.org//work/tasks/4195/81484195/build.log


A valid warning, perhaps slightly overzealous depending on how Error is defined:

GenSec.c:1065:5: error: pointer used after 'fclose' [-Werror=use-after-free]
 1065 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated  of 
%s", InFileHandle);
  | 
^~~
GenSec.c:1064:5: note: call to 'fclose' here
 1064 | fclose (InFileHandle);
  | ^

But it seems more likely that the bug is real.  Maybe that %s should be %p,
or the function call is bogus in some other way.


openbios has a segfault somewhere during the FORTH bootstrap:
https://kojipkgs.fedoraproject.org//work/tasks/6090/81556090/build.log
I was not able to reproduce this one locally.


I would try reproducing with -O0 first.  It might be a dup of the QEMU bug
https://gcc.gnu.org/PR104067, even.  It's a problem with loop optimizations,
so it could be the kind of thing that can wreak havoc on a FORTH interpreter!
Once the fix for PR104067 hits Fedora, if it's not fixed I can take a look.

Thanks,

Paolo
___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 01:30:38PM +0100, Paolo Bonzini wrote:
> On 1/21/22 10:49, Richard W.M. Jones wrote:
> >Yes that works!
> 
> Are you going to make the change?  (For all of the QEMU firmware
> packages---edk2, openbios, seabios in addition to SLOF---since you
> are at it).

However edk2 has other problems revealed probably by GCC 12, see:
https://kojipkgs.fedoraproject.org//work/tasks/4195/81484195/build.log

openbios has a segfault somewhere during the FORTH bootstrap:
https://kojipkgs.fedoraproject.org//work/tasks/6090/81556090/build.log
I was not able to reproduce this one locally.

I've added undefine _auto_set_build_flags to both packages now.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: gcc-12.0.0-0.4.fc36 in rawhide

On Thu, Jan 20, 2022 at 07:50:58AM -0500, Kaleb Keithley wrote:
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch
> --arch-override=x86_64 builds, so I tried a full build and ran into this on
> aarch64. :-(
> 
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing
> conversion of '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
> 
> Are we expecting an update to boost by any chance?

Thanks for the preprocessed source.  That clearly shows a bug in
python3:
# 1681 "/usr/include/python3.10/pyconfig-64.h" 3 4
#define _DARWIN_C_SOURCE 1
#define _FILE_OFFSET_BITS 64
#define _GNU_SOURCE 1
#define _LARGEFILE_SOURCE 1
#define _NETBSD_SOURCE 1
#define _POSIX_C_SOURCE 200809L
#define _PYTHONFRAMEWORK ""
#define _REENTRANT 1
#define _XOPEN_SOURCE 700
#define _XOPEN_SOURCE_EXTENDED 1
#define __BSD_VISIBLE 1
#define __CHAR_UNSIGNED__ 1

__CHAR_UNSIGNED__ is a gcc predefined macro that is defined iff
-funsigned-char is in effect (by default or explicit), while it
shouldn't be defined if -fsigned-char is in effect (by default or
explicit).  As you used -fsigned-char option on -funsigned-char
defaulting arch, gcc correctly doesn't predefine __CHAR_UNSIGNED__.

But this python header defines it anyway which is just wrong,
because it breaks -fsigned-char explicit option on arches that default
to -funsigned-char - glibc limits.h that is included later will:
/* Minimum and maximum values a `char' can hold.  */
#  ifdef __CHAR_UNSIGNED__
#   define CHAR_MIN 0
#   define CHAR_MAX UCHAR_MAX
#  else
#   define CHAR_MIN SCHAR_MIN
#   define CHAR_MAX SCHAR_MAX
#  endif
and so CHAR_{MIN,MAX} won't match what char actually is.
If python wants in configure some macro for its own purposes,
it shouldn't use __CHAR_UNSIGNED__ but should use some
ideally non-reserved namespace identifier of its own.

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

Re: Self Introduction: Chung Chung

2022-01-21 Thread Chihurumnaya Ibiam

Welcome Chung!

-- 

Ibiam Chihurumnaya
ibiamchihurumn...@gmail.com




On Fri, Jan 21, 2022 at 1:34 PM Chung Chung  wrote:

>
> Hi All:
>
>   My name is Chung, I work in Red Hat and maintain lab systems for my team.
>
>   I have been doing DevOps/SysAdmin for quite a few years now.   I have
> done some RPM package build for my group internally and I would like to
> contribute as a package maintainer.
>
>   There are some packages we used in the lab I plan to take ownership of
> and I am open to taking on maintaining other packages also.
>
>   Thanks and excited for the opportunity to contribute.
>
> Chung
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 01:30:38PM +0100, Paolo Bonzini wrote:
> On 1/21/22 10:49, Richard W.M. Jones wrote:
> >Yes that works!
> 
> Are you going to make the change?  (For all of the QEMU firmware
> packages---edk2, openbios, seabios in addition to SLOF---since you
> are at it).

I've done it for SLOF already, will do the others shortly.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Chung Chung

2022-01-21 Thread Chung Chung

Hi All:

  My name is Chung, I work in Red Hat and maintain lab systems for my team.

  I have been doing DevOps/SysAdmin for quite a few years now.   I have
done some RPM package build for my group internally and I would like to
contribute as a package maintainer.

  There are some packages we used in the lab I plan to take ownership of
and I am open to taking on maintaining other packages also.

  Thanks and excited for the opportunity to contribute.

Chung
___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

2022-01-21 Thread Paolo Bonzini


On 1/21/22 10:49, Richard W.M. Jones wrote:

Yes that works!


Are you going to make the change?  (For all of the QEMU firmware 
packages---edk2, openbios, seabios in addition to SLOF---since you are 
at it).


Paolo
___
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: s390 ruby build failure

Dne 21. 01. 22 v 12:19 Vít Ondruch napsal(a):

Dne 21. 01. 22 v 11:35 Richard W.M. Jones napsal(a):

On Fri, Jan 21, 2022 at 11:28:18AM +0100, Vít Ondruch wrote:

Dne 21. 01. 22 v 10:47 Mamoru TASAKA napsal(a):

Richard W.M. Jones wrote on 2022/01/21 18:26:

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

/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to
generate an executable file. (RuntimeError)

This appears to be a compiler problem that only affects ruby
builds on
s390x. However I have no way to diagnose it further (it works
fine on

x86-64). Do we have an s390x development machine with Rawhide
installed?

Rich.

Does this really affects only on s390x?

It passes behind this step locally on x86_64, but fails after all
with some different issue.

The different issue is probably this kernel bug:

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

Yep, looks familiar.

Anyway, could you please obtain the:

/builddir/build/BUILD/libguestfs-1.47.2/ruby/ext/guestfs/mkmf.log

You can probably ignore the build failure and `cat` the content.

Unfortunately I couldn't reproduce it on an s390x machine :-(

Unless someone can grab the file from the above failed Koji build I'm
not sure what to do.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN42RUJUMWN63CAZAMJSTDG7YXQPRY2U/

Never tried that, maybe this could be the moment ;)

I can't do that:

~~~

$ koji save-failed-tree 81534987
2022-01-21 12:20:12,267 [ERROR] koji: ActionNotAllowed: Only owner of
failed task or 'admin' can run this task.

~~~

Vít

I'll keep plugging away here on the s390x machine to see if I can
reproduce it with a different mix of packages installed.

Rich.

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

Re: s390 ruby build failure

Dne 21. 01. 22 v 11:35 Richard W.M. Jones napsal(a):

On Fri, Jan 21, 2022 at 11:28:18AM +0100, Vít Ondruch wrote:

Dne 21. 01. 22 v 10:47 Mamoru TASAKA napsal(a):

Richard W.M. Jones wrote on 2022/01/21 18:26:

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

/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to
generate an executable file. (RuntimeError)

This appears to be a compiler problem that only affects ruby builds on
s390x. However I have no way to diagnose it further (it works fine on
x86-64). Do we have an s390x development machine with Rawhide
installed?

Rich.

Does this really affects only on s390x?

It passes behind this step locally on x86_64, but fails after all
with some different issue.

The different issue is probably this kernel bug:

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

Yep, looks familiar.

Anyway, could you please obtain the:

/builddir/build/BUILD/libguestfs-1.47.2/ruby/ext/guestfs/mkmf.log

You can probably ignore the build failure and `cat` the content.

Unfortunately I couldn't reproduce it on an s390x machine :-(

Unless someone can grab the file from the above failed Koji build I'm
not sure what to do.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN42RUJUMWN63CAZAMJSTDG7YXQPRY2U/

Never tried that, maybe this could be the moment ;)

Vít

I'll keep plugging away here on the s390x machine to see if I can
reproduce it with a different mix of packages installed.

Rich.

[rpms/perl-SOAP-WSDL] PR #1: Disable using of mod_perl

2022-01-21 Thread Jitka Plesnikova


jplesnik closed without merging a pull-request against the project: 
`perl-SOAP-WSDL` that you
are following.

Closed pull-request:

``
Disable using of mod_perl
``

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

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'



Dne 21. 01. 22 v 10:52 Florian Weimer napsal(a):

* Richard W. M. Jones:


On Fri, Jan 21, 2022 at 10:43:16AM +0100, Florian Weimer wrote:

* Tom Hughes via devel:


On 21/01/2022 09:08, Richard W.M. Jones wrote:


https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
This seems like a compiler bug or a bug in the standard switches
being
added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
the -mtune flag.

That's not even a ppc64le build, it's an x86_64 build using a cross
compiler from the gcc-powerpc64-linux-gnu package - that is actually
still 11.2 and hasn't been upgraded to 12 yet.

I don't know where -mtune=generic comes from but a normal ppc64le
build uses -mcpu=power8 -mtune=power8 as it's defaults.

It's probably a result of implicit %set_build_flags.

%undefine _auto_set_build_flags

should fix it.

Yes that works!

But I don't quite understand what "implicit build flags" means here.
It's not using %configure.

Rawhide was changed to call %set_build_flags automatically:

   %set_build_flags for %build, %check, and %install phases
   



Shouldn't the `%configure` macro drop setting of the env variables? This 
looks to be excessive:


~~~

+ '[' -f /builddir/build/BUILD/.package_note-ruby-0.15.2-158.fc36.x86_64.ld ']'
+ '[' -f /usr/lib/rpm/generate-rpm-note.sh ']'
+ /usr/lib/rpm/generate-rpm-note.sh ruby 0.15.2-158.fc36 x86_64
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-I/usr/lib64/gfortran/modules'
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-I/usr/lib64/gfortran/modules'
+ export FCFLAGS
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now 
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 '
+ export LDFLAGS
+ LT_SYS_LIBRARY_PATH=/usr/lib64:
+ export LT_SYS_LIBRARY_PATH
+ CC=gcc
+ export CC
+ CXX=g++
+ export CXX
+ cd ruby-3.0.3
+ autoconf
configure.ac:4190: warning: AC_C_BIGENDIAN should be used with AC_CONFIG_HEADERS
+ '[' -f /builddir/build/BUILD/.package_note-ruby-0.15.2-158.fc36.x86_64.ld ']'
+ CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CFLAGS
+ CXXFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
+ export CXXFLAGS
+ FFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-I/usr/lib64/gfortran/modules'
+ export FFLAGS
+ FCFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-

Re: s390 ruby build failure

On Fri, Jan 21, 2022 at 11:28:18AM +0100, Vít Ondruch wrote:
> 
> Dne 21. 01. 22 v 10:47 Mamoru TASAKA napsal(a):
> >Richard W.M. Jones wrote on 2022/01/21 18:26:
> >>https://koji.fedoraproject.org/koji/taskinfo?taskID=81534987
> >>
> >>/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to
> >>generate an executable file. (RuntimeError)
> >>
> >>This appears to be a compiler problem that only affects ruby builds on
> >>s390x.  However I have no way to diagnose it further (it works fine on
> >>x86-64).  Do we have an s390x development machine with Rawhide
> >>installed?
> >>
> >>Rich.
> >
> >Does this really affects only on s390x?
> 
> 
> It passes behind this step locally on x86_64, but fails after all
> with some different issue.

The different issue is probably this kernel bug:

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

> Anyway, could you please obtain the:
> 
> /builddir/build/BUILD/libguestfs-1.47.2/ruby/ext/guestfs/mkmf.log
> 
> You can probably ignore the build failure and `cat` the content.

Unfortunately I couldn't reproduce it on an s390x machine :-(

Unless someone can grab the file from the above failed Koji build I'm
not sure what to do.

I'll keep plugging away here on the s390x machine to see if I can
reproduce it with a different mix of packages installed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: s390 ruby build failure

On Fri, Jan 21, 2022 at 06:47:37PM +0900, Mamoru TASAKA wrote:
> Richard W.M. Jones wrote on 2022/01/21 18:26:
> >https://koji.fedoraproject.org/koji/taskinfo?taskID=81534987
> >
> >/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to generate an 
> >executable file. (RuntimeError)
> >
> >This appears to be a compiler problem that only affects ruby builds on
> >s390x.  However I have no way to diagnose it further (it works fine on
> >x86-64).  Do we have an s390x development machine with Rawhide
> >installed?
> >
> >Rich.
> 
> Does this really affects only on s390x?
> mass rebuild sets "fail_fast", which means that if one of the arches fails to 
> build,
> builds on rest arches gets cancelled at that time.
> 
> Looking at the parent task and builds on other arches, it looks like builds on
> other arches were all cancelled before ruby related tasks are executed:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81534564

I couldn't reproduce it locally (x86-64).  I am now testing it on
Rawhide/s390x thanks to Danny, so let's see if I can reproduce it
there.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)



Dne 21. 01. 22 v 11:23 Pavel Březina napsal(a):

On 1/20/22 15:15, Vít Ondruch wrote:


Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not 
static, generated at build time, not having anything in /etc unless 
somebody really wants to change something.


The files are not static at all, they are change with different 
kinds of authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature



As I said, the above is not my case and I'd say not case for most of 
Fedora users.




- apply changes when package is updated: authselect apply-changes



Why is this needed? In which packages? Why simply not apply the 
changes regardless of the previous state?



- apply changes when you modify your custom profile: authselect 
apply-changes



This is again belongs to the initial group.




They remembers how the current configuration looks like so we can 
check if user modified nsswitch and PAM configuration on their own 
or not.



"user modified nsswitch and PAM configuration" is not thing I do. The 
only time I needed to touch nsswitch configuration was always because 
the configuration was screwed up by some updates, not by me.



IOW, from users perspective, the configuration is static. If 
installation/updates changes the configuration, then it is again 
static from user perspective. So I still don't see the need to have 
the configuration files around by default.


Also, I think this proposal is focusing on wrong aspect, i.e. moving 
files around from one location to another. It would be much better to 
remove their need.



Vít


That would be the ideal world, wouldn't it? Especially for me, as 
authselect maintainer :-)


Fedora 36 will move most of the users to authselect and packages won't 
screw the configuration anymore. However, most of the guides on the 
internet on the subject matter don't mention authselect yet



1) If there is no configuration file, which is mentioned in such guide, 
that could give them hint


2) If the hint from previous step is not enough, then authselect could warn.


so there will be cases when users modify the configuration manually 
without disabling authselect even though not intentionally. And again 
- not overwriting user's configuration is important design decision to 
authselect.


We can of course simplify the detection and not rely on the 
configuration content anymore but perhaps just rely on the presence 
and validity of /etc/authselect/authselect.conf - if it is there, 
assume that user wants to use authselect. I'd would certainly welcome 
such change.


This however would be a major functional change, so perhaps something 
to consider for the next release.




That would be great. Looking forward to it. Thx for considering!


Vít



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

Re: s390 ruby build failure



Dne 21. 01. 22 v 10:47 Mamoru TASAKA napsal(a):

Richard W.M. Jones wrote on 2022/01/21 18:26:

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

/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to 
generate an executable file. (RuntimeError)


This appears to be a compiler problem that only affects ruby builds on
s390x.  However I have no way to diagnose it further (it works fine on
x86-64).  Do we have an s390x development machine with Rawhide
installed?

Rich.


Does this really affects only on s390x?



It passes behind this step locally on x86_64, but fails after all with 
some different issue.


Anyway, could you please obtain the:

/builddir/build/BUILD/libguestfs-1.47.2/ruby/ext/guestfs/mkmf.log

You can probably ignore the build failure and `cat` the content.


Vít



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

Re: F36 Change: Authselect: Move State Files to /etc (Self-Contained Change proposal)

2022-01-21 Thread Pavel Březina


On 1/20/22 15:15, Vít Ondruch wrote:


Dne 20. 01. 22 v 14:53 Pavel Březina napsal(a):

On 1/20/22 12:52, Vít Ondruch wrote:

I have naive question why these files are not static and in /usr.

I mean, I am pretty sure I won't run `authselect select --force` or 
anything similar any time soon. So why the configuration is not 
static, generated at build time, not having anything in /etc unless 
somebody really wants to change something.


The files are not static at all, they are change with different kinds 
of authselect calls:


- user wants to use different profile then default: authselect select
- enable/disable single feature: authselect enable/disable-feature



As I said, the above is not my case and I'd say not case for most of 
Fedora users.




- apply changes when package is updated: authselect apply-changes



Why is this needed? In which packages? Why simply not apply the changes 
regardless of the previous state?



- apply changes when you modify your custom profile: authselect 
apply-changes



This is again belongs to the initial group.




They remembers how the current configuration looks like so we can 
check if user modified nsswitch and PAM configuration on their own or 
not.



"user modified nsswitch and PAM configuration" is not thing I do. The 
only time I needed to touch nsswitch configuration was always because 
the configuration was screwed up by some updates, not by me.



IOW, from users perspective, the configuration is static. If 
installation/updates changes the configuration, then it is again static 
from user perspective. So I still don't see the need to have the 
configuration files around by default.


Also, I think this proposal is focusing on wrong aspect, i.e. moving 
files around from one location to another. It would be much better to 
remove their need.



Vít


That would be the ideal world, wouldn't it? Especially for me, as 
authselect maintainer :-)


Fedora 36 will move most of the users to authselect and packages won't 
screw the configuration anymore. However, most of the guides on the 
internet on the subject matter don't mention authselect yet so there 
will be cases when users modify the configuration manually without 
disabling authselect even though not intentionally. And again - not 
overwriting user's configuration is important design decision to authselect.


We can of course simplify the detection and not rely on the 
configuration content anymore but perhaps just rely on the presence and 
validity of /etc/authselect/authselect.conf - if it is there, assume 
that user wants to use authselect. I'd would certainly welcome such change.


This however would be a major functional change, so perhaps something to 
consider for the next release.

___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

* Richard W. M. Jones:

> On Fri, Jan 21, 2022 at 11:11:07AM +0100, Florian Weimer wrote:
>> * Richard W. M. Jones:
>> 
>> >> Rawhide was changed to call %set_build_flags automatically:
>> >> 
>> >>   %set_build_flags for %build, %check, and %install phases
>> >>   
>> >
>> > That looks broken.
>> 
>> Sorry, the web page, or the change itself?
>
> The change itself.  It doesn't take into account cross-compilation.

Ah, well, that is such a fringe use case that I don't think prioritizing
it makes sense.  It also doesn't work for building anything that is not
Fedora userspace, either.

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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 11:11:07AM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> >> Rawhide was changed to call %set_build_flags automatically:
> >> 
> >>   %set_build_flags for %build, %check, and %install phases
> >>   
> >
> > That looks broken.
> 
> Sorry, the web page, or the change itself?

The change itself.  It doesn't take into account cross-compilation.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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 packagers: anoopcs, gtiwari, msehnout, sebix, vanessa_kris

2022-01-21 Thread Anoop C S via devel

On Fri, 2022-01-21 at 10:32 +0100, Pierre-Yves Chibon wrote:
> On Fri, Jan 21, 2022 at 02:31:57PM +0530, Anoop C S wrote:
> > On Thu, 2022-01-20 at 09:57 +0100, Pierre-Yves Chibon wrote:
> > > Good Morning Everyone,
> > > 
> > > The packagers listed here have been receiving a daily email
> > > asking
> > > them to
> > > either adjust their bugzilla or their FAS account so the email
> > > address in FAS
> > > matches an existing bugzilla account.
> > > 
> > > Having a bugzilla account is mandatory per:
> > > https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_a_Bugzilla_Account
> > > 
> > > - anoopcs contacted since November 27th
> > > 
> > > anoopcs is maintainer of rpms/glusterfs
> > > anoopcs is main admin of rpms/glusterfs-coreutils
> > > anoopcs has a bugzilla override on rpms/glusterfs-coreutils
> > > anoopcs is maintainer of rpms/richacl
> > > anoopcs is maintainer of rpms/samba
> > > anoopcs is watching rpms/socket_wrapper
> > 
> > I am aware and was ignoring it based on the reply I got for the
> > ticket
> > raised[1] on the exact same issue. I also wanted to know where the
> > ongoing work for making use of bugzilla field in FAS(I made another
> > comment after ticket got closed) is being tracked. May be issue
> > #9863[2]?
> 
> That's a question I do not have the answer to.
> 

Fine. I'll keep an eye on #9863 for now.

> > Very recent request(via email) for bugzilla email validation gave
> > me an
> > impression that its finally gonna happen.
> 
> It is being worked on but it is not ready yet (I expect that it will
> be
> announced once it is).
> 
> > If not, how important it is to match both(FAS and bugzilla) email
> > addresses at this point? Or is it a requirement now to have same
> > email
> > address to get the work completed? Sorry, I am little confused.
> 
> It is important as it breaks the sync from dist-git to bugzilla and
> for the
> entire component (package), so it impacts you as well as potentially
> any other
> co-maintainers or watchers of the packages you are linked to.
> 
> Currently there are two ways to get this sync working:
> - either have a valid bugzilla account corresponding to your main FAS
> email

May be not.

> - add an override to manually map your main FAS email to your
> bugzilla account
>   in:
>  
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/openshift-apps/toddlers/templates/email_overrides.toml

Ahaa..for the time being, I'll go for an email override. In that case I
hope a ticket is expected?

Thanks for the pointers.

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

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

* Richard W. M. Jones:

>> Rawhide was changed to call %set_build_flags automatically:
>> 
>>   %set_build_flags for %build, %check, and %install phases
>>   
>
> That looks broken.

Sorry, the web page, or the change itself?

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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 10:52:07AM +0100, Florian Weimer wrote:
> * Richard W. M. Jones:
> 
> > On Fri, Jan 21, 2022 at 10:43:16AM +0100, Florian Weimer wrote:
> >> * Tom Hughes via devel:
> >> 
> >> > On 21/01/2022 09:08, Richard W.M. Jones wrote:
> >> >
> >> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
> >> >> This seems like a compiler bug or a bug in the standard switches
> >> >> being
> >> >> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
> >> >> the -mtune flag.
> >> >
> >> > That's not even a ppc64le build, it's an x86_64 build using a cross
> >> > compiler from the gcc-powerpc64-linux-gnu package - that is actually
> >> > still 11.2 and hasn't been upgraded to 12 yet.
> >> >
> >> > I don't know where -mtune=generic comes from but a normal ppc64le
> >> > build uses -mcpu=power8 -mtune=power8 as it's defaults.
> >> 
> >> It's probably a result of implicit %set_build_flags.
> >> 
> >> %undefine _auto_set_build_flags
> >> 
> >> should fix it.
> >
> > Yes that works!
> >
> > But I don't quite understand what "implicit build flags" means here.
> > It's not using %configure.
> 
> Rawhide was changed to call %set_build_flags automatically:
> 
>   %set_build_flags for %build, %check, and %install phases
>   

That looks broken.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

On Fri, 21 Jan 2022 10:55:51 +0100
Remi Collet  wrote:

> Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :
> > On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:
> >> Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :
> >>> gcc 12 snapshot has landed as the system compiler into rawhide today.
> >>
> >> PHP is now FTBFS on s390x only
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437
> >>
> >>
> >> Any help welcome,
> >> Remi
> >>
> >>
> >> P.S. from build.log
> >>
> >>
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
> >> 'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: 
> >> inlining
> >> failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
> >> option mismatch
> >> 32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
> >>|^~
> >> In file included from
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
> >> /builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
> >> from here
> >>   8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
> >>| ^~~
> > 
> > That error means that there is difference in the target attribute or #pragma
> > GCC target between the caller of the always_inline function and the
> > always_inline function which prevents the inlining (and always_inline
> > requires to be inlined).
> > I'd need preprocessed source + gcc command line to say more.
> 
> Still failing with 12.0.1-0.2 recently built on rawhide
> 
> Trying to disabled the always_inline don't solves the problem
> (same issue with memcpy call)
> 
> Sorry, but I have no idea how to check the "target" used
> can't find anything in the source code
> and don't have (simple) access to s390x computer

we have both public and internal s390x machines with Fedora, if needed,
please ping me for details.


Dan
___
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: GCC 12 no longer understands -fsanitize-coverage=trace-pc,trace-cmp

On Fri, Jan 21, 2022 at 09:15:04AM +, Richard W.M. Jones wrote:
> 
> honggfuzz fails to build in Rawhide with:
> 
>   + hfuzz_cc/hfuzz-gcc hello.c -o hello
>   gcc: error: unrecognized argument in option 
> '-fsanitize-coverage=trace-pc,trace-cmp'
>   gcc: note: valid arguments to '-fsanitize-coverage=' are: trace-cmp trace-pc
> 
> Note the flag is added by honggfuzz itself when it instruments a
> binary:
> 
>   
> https://github.com/google/honggfuzz/blob/876ff411938b1ab911c213bf640e2696e7ebd695/hfuzz_cc/hfuzz-cc.c#L375
> 
> This worked with older GCC.  It also works if I patch honggfuzz like this:

Filed https://gcc.gnu.org/PR104158 and am going to look at it.

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

Re: gcc-12.0.0-0.4.fc36 in rawhide - s390x regression ?

2022-01-21 Thread Remi Collet


Le 19/01/2022 à 11:53, Jakub Jelinek a écrit :

On Wed, Jan 19, 2022 at 07:27:44AM +0100, Remi Collet wrote:

Le 14/01/2022 à 15:31, Jakub Jelinek a écrit :

gcc 12 snapshot has landed as the system compiler into rawhide today.


PHP is now FTBFS on s390x only
https://koji.fedoraproject.org/koji/taskinfo?taskID=81436437


Any help welcome,
Remi


P.S. from build.log


/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h: In function
'ZEND_FETCH_OBJ_IS_SPEC_CONST_TMPVAR_HANDLER':
/builddir/build/BUILD/php-8.1.2/Zend/zend_variables.h:32:32: error: inlining
failed in call to 'always_inline' 'zval_ptr_dtor_nogc': target specific
option mismatch
32 | static zend_always_inline void zval_ptr_dtor_nogc(zval *zval_ptr)
   |^~
In file included from
/builddir/build/BUILD/php-8.1.2/Zend/zend_execute.c:5071:
/builddir/build/BUILD/php-8.1.2/Zend/zend_vm_execute.h:8772:9: note: called
from here
  8772 | zval_ptr_dtor_nogc(EX_VAR(opline->op2.var));
   | ^~~


That error means that there is difference in the target attribute or #pragma
GCC target between the caller of the always_inline function and the
always_inline function which prevents the inlining (and always_inline
requires to be inlined).
I'd need preprocessed source + gcc command line to say more.


Still failing with 12.0.1-0.2 recently built on rawhide

Trying to disabled the always_inline don't solves the problem
(same issue with memcpy call)

Sorry, but I have no idea how to check the "target" used
can't find anything in the source code
and don't have (simple) access to s390x computer


Remi
___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

* Richard W. M. Jones:

> On Fri, Jan 21, 2022 at 10:43:16AM +0100, Florian Weimer wrote:
>> * Tom Hughes via devel:
>> 
>> > On 21/01/2022 09:08, Richard W.M. Jones wrote:
>> >
>> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
>> >> This seems like a compiler bug or a bug in the standard switches
>> >> being
>> >> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
>> >> the -mtune flag.
>> >
>> > That's not even a ppc64le build, it's an x86_64 build using a cross
>> > compiler from the gcc-powerpc64-linux-gnu package - that is actually
>> > still 11.2 and hasn't been upgraded to 12 yet.
>> >
>> > I don't know where -mtune=generic comes from but a normal ppc64le
>> > build uses -mcpu=power8 -mtune=power8 as it's defaults.
>> 
>> It's probably a result of implicit %set_build_flags.
>> 
>> %undefine _auto_set_build_flags
>> 
>> should fix it.
>
> Yes that works!
>
> But I don't quite understand what "implicit build flags" means here.
> It's not using %configure.

Rawhide was changed to call %set_build_flags automatically:

  %set_build_flags for %build, %check, and %install phases
  

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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 10:43:16AM +0100, Florian Weimer wrote:
> * Tom Hughes via devel:
> 
> > On 21/01/2022 09:08, Richard W.M. Jones wrote:
> >
> >> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
> >> This seems like a compiler bug or a bug in the standard switches
> >> being
> >> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
> >> the -mtune flag.
> >
> > That's not even a ppc64le build, it's an x86_64 build using a cross
> > compiler from the gcc-powerpc64-linux-gnu package - that is actually
> > still 11.2 and hasn't been upgraded to 12 yet.
> >
> > I don't know where -mtune=generic comes from but a normal ppc64le
> > build uses -mcpu=power8 -mtune=power8 as it's defaults.
> 
> It's probably a result of implicit %set_build_flags.
> 
> %undefine _auto_set_build_flags
> 
> should fix it.

Yes that works!

But I don't quite understand what "implicit build flags" means here.
It's not using %configure.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 09:32:56AM +, Tom Hughes wrote:
> On 21/01/2022 09:29, Tom Hughes via devel wrote:
> >On 21/01/2022 09:08, Richard W.M. Jones wrote:
> >
> >>https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
> >>
> >>This seems like a compiler bug or a bug in the standard switches being
> >>added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
> >>the -mtune flag.
> >
> >That's not even a ppc64le build, it's an x86_64 build using a cross
> >compiler from the gcc-powerpc64-linux-gnu package - that is actually
> >still 11.2 and hasn't been upgraded to 12 yet.
> >
> >I don't know where -mtune=generic comes from but a normal ppc64le
> >build uses -mcpu=power8 -mtune=power8 as it's defaults.
> 
> Ah the problem is that -mtune=generic is the x864_64 default which
> the spec is passing in CFLAGS because you're building on x86_64 but
> that doesn't work for the ppc64 cross compiler.

Indeed.  The weird thing is that something in redhat-rpm-config
changed:

redhat-rpm-config-206-1.fc36.noarch => builds OK
redhat-rpm-config-209-1.fc36.noarch => build fails

I cannot see what in the spec file could pull in the wrong cflags,
since it doesn't use %configure.  Not seeing it at the moment ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: s390 ruby build failure

2022-01-21 Thread Mamoru TASAKA


Richard W.M. Jones wrote on 2022/01/21 18:26:

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

/usr/share/ruby/mkmf.rb:471:in `try_do': The compiler failed to generate an 
executable file. (RuntimeError)

This appears to be a compiler problem that only affects ruby builds on
s390x.  However I have no way to diagnose it further (it works fine on
x86-64).  Do we have an s390x development machine with Rawhide
installed?

Rich.


Does this really affects only on s390x?
mass rebuild sets "fail_fast", which means that if one of the arches fails to 
build,
builds on rest arches gets cancelled at that time.

Looking at the parent task and builds on other arches, it looks like builds on
other arches were all cancelled before ruby related tasks are executed:

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

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

Fedora-Cloud-34-20220121.0 compose check report

2022-01-21 Thread 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-20220120.0):

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

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

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On Fri, Jan 21, 2022 at 09:08:35AM +, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
> 
> This seems like a compiler bug or a bug in the standard switches being
> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
> the -mtune flag.
> 
> Rich.
> 
> powerpc64-linux-gnu-gcc -m64  -I../libc/include -DCPU_PPCP7 
> -I/builddir/build/BUILD/SLOF-qemu-slof-20210217/include 
> -I/builddir/build/BUILD/SLOF-qemu-slof-20210217/include/ppcp7 -O2 -flto=auto 
> -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -o 
> elf32.o -c /builddir/build/BUILD/SLOF-qemu-slof-20210217/lib/libelf/elf32.c
> make[3]: Leaving directory 
> '/builddir/build/BUILD/SLOF-qemu-slof-20210217/lib/libelf'
> powerpc64-linux-gnu-gcc: error: unrecognized argument in option 
> '-mtune=generic'
> powerpc64-linux-gnu-gcc: note: valid arguments to '-mtune=' are: 401 403 405 
> 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 
> 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 
> e500mc e500mc64 e5500 e6500 ec603e native power10 power3 power4 power5 
> power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le 
> rs64 titan

gcc has never supported -mtune=generic on ppc*, and redhat-rpm-config
doesn't list it either for ppc* (only i386/i586/i686/x86_64).
But if something puts that into CFLAGS, I'd expect all ppc64le builds to
fail, not just this one.

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

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

* Tom Hughes via devel:

> On 21/01/2022 09:08, Richard W.M. Jones wrote:
>
>> https://koji.fedoraproject.org/koji/taskinfo?taskID=81468000
>> This seems like a compiler bug or a bug in the standard switches
>> being
>> added by RPM on ppc64le.  SLOF itself does not appear to add or adjust
>> the -mtune flag.
>
> That's not even a ppc64le build, it's an x86_64 build using a cross
> compiler from the gcc-powerpc64-linux-gnu package - that is actually
> still 11.2 and hasn't been upgraded to 12 yet.
>
> I don't know where -mtune=generic comes from but a normal ppc64le
> build uses -mcpu=power8 -mtune=power8 as it's defaults.

It's probably a result of implicit %set_build_flags.

%undefine _auto_set_build_flags

should fix it.

Thanks,
Flroian
___
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: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'