[Bug 2161311] perl-Coro: Use %_fortify_level instead of twiddling with RPM_OPT_FLAGS

[bugzilla]

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

Michal Josef Spacek  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Coro-6.570-10.fc38
Last Closed||2023-01-18 06:59:22




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Yet another unwinding approach

[Florian Weimer]

* Daniel Colascione:

> See, both pro-FP and anti-FP camps think that it's the kernel that has
> to do the unwinding unless we copy whole stacks into traces.

Well, I think we should explore hardware-assisted backtraces (shadow
stacks), which hopefully are going to get merged in Linux 6.2.

> Why should that be? As mentioned in [1], instead of finding a way to
> have the kernel unwind user programs, we can create a protocol through
> which the kernel can ask usermode to unwind itself. It could work like
> this:

If the unwind information is incomplete, this …

> 7) signal handler unwinds the calling thread however it wants (and can
> sleep and take page faults if needed)

… might encounter segmentation faults and terminate the process.  So
far, incorrect unwind information (whether it's a clobbered frame
pointer, or missing DWARF information about clobbered registers) is not
a problem, but it's kind of hard to validate this information from
within the process itself.  Maybe we'd have to add a magic memcpy first
to the vDSO, which the kernel recognizes based on the code addresses,
and suppresses sending the signal for it.

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

Re: How to build two flavors of the same package?

[Orion Poplawski]

On 1/17/23 14:28, Till Hofmann wrote:

Hi all,

Someone (rightfully) suggested that we should build glfw twice, once 
with wayland support and once without:

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

Is there any best practice how to build the same package in two 
different flavors, in this case cmake-based? I vaguely remember seeing a 
spec file that did that, but I don't remember where.


Thanks for any pointers!


In vtk.spec I do things like:

%global _vpath_builddir build
%cmake %{cmake_gen} \
 %{vtk_cmake_options} \
 -DVTK_BUILD_DOCUMENTATION:BOOL=ON \
 -DVTK_BUILD_EXAMPLES:BOOL=ON \
 -DVTK_BUILD_TESTING:BOOL=ON
%cmake_build -- --output-sync
%cmake_build --target DoxygenDoc

%if %{with mpich}
%global _vpath_builddir build-mpich
%_mpich_load
export CC=mpicc
export CXX=mpic++
%cmake %{cmake_gen} \
 %{vtk_cmake_options} \
 -DCMAKE_PREFIX_PATH:PATH=$MPI_HOME \
 -DCMAKE_INSTALL_PREFIX:PATH=$MPI_HOME \
 -DCMAKE_INSTALL_LIBDIR:PATH=lib \
 -DCMAKE_INSTALL_JNILIBDIR:PATH=lib/%{name} \
 -DCMAKE_INSTALL_QMLDIR:PATH=lib/qt5/qml \
 -DVTK_USE_MPI:BOOL=ON
%cmake_build -- --output-sync
%_mpich_unload
%endif

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/



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

Re: How to build two flavors of the same package?

[Jerry James]

On Tue, Jan 17, 2023 at 2:28 PM Till Hofmann  wrote:
> Hi all,
>
> Someone (rightfully) suggested that we should build glfw twice, once
> with wayland support and once without:
> https://bugzilla.redhat.com/show_bug.cgi?id=2152319
>
> Is there any best practice how to build the same package in two
> different flavors, in this case cmake-based? I vaguely remember seeing a
> spec file that did that, but I don't remember where.
>
> Thanks for any pointers!
>
> Kind regards,
> Till

I don't know about best practices, but it seems like you could do
something like this:

%build
%cmake 
%cmake_build
mv %{_vpath_builddir} build-first

%cmake 
%cmake_build
mv %{_vpath_builddir} build-second

%install
mv build-first %{_vpath_builddir}
%cmake_install
mv %{_vpath_builddir} build-first

mv build-second %{_vpath_builddir}
%cmake_install
mv %{_vpath_builddir} build-second

%check
mv build-first %{_vpath_builddir}
%ctest
mv %{_vpath_builddir} build-first

mv build-second %{_vpath_builddir}
%ctest
mv %{_vpath_builddir} build-second


I made that up off the top of my head and haven't tried it, so it may
have some fatal flaw.  Take with a large grain of salt.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[John Reiser]

On 1/17/23 14:37, Björn Persson wrote:


So as things stand, these rebuilds need to be done by a human who knows
the dependency graph.


Requiring "a human who knows the dependency graph" is *severely* broken.
There should be a shell script which computes an acceptable order from the
old installed version, and outputs the order for examination and modification.
Probably the script involves ldd, "readelf --dynamic", and tsort.
For new dependencies the script may need to be re-run during the builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a884ce2c71   
tor-0.4.7.13-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

mimedefang-3.3-1.el7
singularity-ce-3.10.5-1.el7

Details about builds:



 mimedefang-3.3-1.el7 (FEDORA-EPEL-2023-8a000e474c)
 E-mail filtering framework using Sendmail's Milter interface

Update Information:

# MIMEDefang 3.3* Add UTF-8 support to `md_graphdefang_log`* Add a
`gen_mx_id` Perl implementation, needed for OpenSMTPd support

ChangeLog:

* Wed Jan 18 2023 Robert Scheck  3.3-1
- Upgrade to 3.3 (#2161362)

References:

  [ 1 ] Bug #2161362 - mimedefang-3.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2161362




 singularity-ce-3.10.5-1.el7 (FEDORA-EPEL-2023-3ab686a79f)
 Application and environment virtualization

Update Information:

Upgrade to 3.10.5 upstream version. Addresses CVE-2022-23538 /
GHSA-7p8m-22h4-9pj7

ChangeLog:

* Tue Jan 17 2023 David Trudgian  - 3.10.5-1
- Upgrade to 3.10.5 upstream version.
- Addresses CVE-2022-23538 / GHSA-7p8m-22h4-9pj7


___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Package Review] draco

[Luya Tshimbalanga]

On 2023-01-17 07:22, Arthur Bols wrote:

On 15/01/2023 03:44, Luya Tshimbalanga wrote:

Hello team,

draco package is ready for review.
https://bugzilla.redhat.com/show_bug.cgi?id=2160996


The spec file was originally from UnitedRPM [1] which only needs a 
clean up to adhere to the packaging guideline. The library itself is 
useful for Blender to compress 3D geometry.


Thanks in advance for taking this package for review.


Reference

[1] https://github.com/UnitedRPMs/draco/blob/main/draco.spec

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer


Hi Luya,

I took the review. I would appreciate it if you could review 
mooltipass-udev: https://bugzilla.redhat.com/show_bug.cgi?id=2160449 .


It's a simple package for the udev rules for mooltipass devices, which 
were previously included in the moolticute package.



Ok, I took it.

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

[Bug 2158853] perl-System-Info-0.063 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|perl-System-Info-0.063-1.fc |perl-System-Info-0.063-1.fc
   |38  |38
   ||perl-System-Info-0.063-1.fc
   ||37
 Resolution|--- |ERRATA
Last Closed||2023-01-18 01:38:46



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-5dcad355f2 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158853
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Yet another unwinding approach

[Demi Marie Obenour]

On 1/17/23 19:21, Mark Wielaard wrote:
> Hi Daniel,
> 
> On Mon, Jan 16, 2023 at 08:30:21PM -, Daniel Colascione wrote:
>> As mentioned in [1], instead of finding a way to have the kernel
>> unwind user programs, we can create a protocol through which the
>> kernel can ask usermode to unwind itself.
> 
> I like this idea and was discussing and thinking along similar lines.
> It would be great if we can implement this using existing mechanisms
> to prototype something to show it is feasible and fast enough.  And
> for existing linux/glibc installs that don't yet have the new
> interfaces.
> 
>> It could work like this:
>>
>> 1) backtrace requested in the kernel (e.g. to a perf counter
>> overflow)
>>
>> 2) kernel unwinds itself to the userspace boundary the usual way
>>
>> 3) kernel forms a nonce (e.g. by incrementing a 64-bit counter)
>>
>> 4) kernel logs a stack trace the usual way (e.g. to the ftrace ring
>> buffer), but with the final frame referring to the nonce created in
>> the previous step
>>
>> 5) kernel queues a signal (one userspace has explicitly opted into
>> via a new prctl()); the siginfo_t structure encodes (e.g. via
>> si_status and si_value) the nonce
> 
> So before it does this prctl the process needs to setup all
> datastructures it needs to safely handle the unwinding during signal
> handling. That does mean that early process setup won't be able to be
> profiled with user backtraces.

There could be an unwinder in the vDSO that is used if userspace has
not registered a replacement one.

>> 6) kernel eventually returns to userspace; queued signal handler
>> gains control
> 
> So at this point, if the event triggered while that user space thread
> was running the event logged by the kernel is basically just that
> nonce?
> 
>> 7) signal handler unwinds the calling thread however it wants (and
>> can sleep and take page faults if needed)
> 
> So in theory this can do anything that is async signal safe. But what
> if it takes too long and another event gets triggered? Or it does a
> syscall that produces an event? Another signal arrives? Or if it
> causes a SEGV?
> 
>> 8) signal handler logs the result of its unwind, along with the
>> nonce, to the system log (e.g. via a new system call, a sysfs write,
>> an io_uring submission, etc.)
> 
> A (shared) memory region seems simplest, whatever has been put into it
> when the signal handler returns is the user space backtrace
> contribution. Maybe the prctl call can set this up? Or maybe the
> kernel can provide it through one of the siginfo_t fields?

siginfo_t seems simplest, and also works with a vDSO unwinder.

>> Post-processing tools can associate kernel stacks with user stacks
>> tagged with the corresponding nonces and reconstitute the full
>> stacks in effect at the time of each logged event.
>>
>> We can avoid duplicating unwindgs too: at step #3, if the kernel
>> finds that the current thread already has an unwind pending, it can
>> uses the already-pending nonce instead of making a new one and
>> queuing a signal: many kernel stacks can end with the same user
>> stack "tail".
> 
> This is probably a generic optimization for most backtraces, most will
> have a similar tail.
>  
>> One nice property of this scheme is that the userspace unwinding
>> isn't limited to native code. Libc could arbitrate unwinding across
>> an arbitrary number of managed runtime environments in the context
>> of a single process: the system could be smart enough to know that
>> instead of unwinding through, e.g. Python interpreter frames, the
>> unwinder (which is normal userspace code, pluggable via DSO!) could
>> traverse and log *Python* stack frames instead, with meaningful
>> function names. And if you happened to have, say, a JavaScript
>> runtime in the same process, both JavaScript and Python could
>> participate in the semantic unwinding process.
>>
>> A pluggable userspace unwind mechanism would have zero cost in the
>> case that we're not recording stack frames. On top of that, a
>> pluggable userspace unwinder *could* be written to traverse frame
>> pointers just as the kernel unwinder does today, if userspace thinks
>> that's the best option. Without breaking kernel ABI, that userspace
>> unwinder could use DWARF, or ORC, or any other userspace unwinding
>> approach. It's future-proof.
> 
> This is nice, but does need some coordination for handing off the
> unwinding context between different unwinders. You could register an
> unwinder by memory region (if address is in this range, it is in the
> lua interpreter). And then you can start generating a backtrace using
> the dedicated unwinder for that memory region. That original unwinder
> can start with the full ucontext_t. But what is the contract between
> unwinders? If we start with e.g. a frame-pointer unwinder then when we
> get to a part that needs to use the python unwinder we only have a pc,
> sp and fp left. Is that enough context for the python unwinder to
> continue?
> 
> What 

Re: Yet another unwinding approach

[Mark Wielaard]

Hi Daniel,

On Mon, Jan 16, 2023 at 08:30:21PM -, Daniel Colascione wrote:
> As mentioned in [1], instead of finding a way to have the kernel
> unwind user programs, we can create a protocol through which the
> kernel can ask usermode to unwind itself.

I like this idea and was discussing and thinking along similar lines.
It would be great if we can implement this using existing mechanisms
to prototype something to show it is feasible and fast enough.  And
for existing linux/glibc installs that don't yet have the new
interfaces.

> It could work like this:
> 
> 1) backtrace requested in the kernel (e.g. to a perf counter
> overflow)
> 
> 2) kernel unwinds itself to the userspace boundary the usual way
> 
> 3) kernel forms a nonce (e.g. by incrementing a 64-bit counter)
> 
> 4) kernel logs a stack trace the usual way (e.g. to the ftrace ring
> buffer), but with the final frame referring to the nonce created in
> the previous step
> 
> 5) kernel queues a signal (one userspace has explicitly opted into
> via a new prctl()); the siginfo_t structure encodes (e.g. via
> si_status and si_value) the nonce

So before it does this prctl the process needs to setup all
datastructures it needs to safely handle the unwinding during signal
handling. That does mean that early process setup won't be able to be
profiled with user backtraces.

> 6) kernel eventually returns to userspace; queued signal handler
> gains control

So at this point, if the event triggered while that user space thread
was running the event logged by the kernel is basically just that
nonce?

> 7) signal handler unwinds the calling thread however it wants (and
> can sleep and take page faults if needed)

So in theory this can do anything that is async signal safe. But what
if it takes too long and another event gets triggered? Or it does a
syscall that produces an event? Another signal arrives? Or if it
causes a SEGV?

> 8) signal handler logs the result of its unwind, along with the
> nonce, to the system log (e.g. via a new system call, a sysfs write,
> an io_uring submission, etc.)

A (shared) memory region seems simplest, whatever has been put into it
when the signal handler returns is the user space backtrace
contribution. Maybe the prctl call can set this up? Or maybe the
kernel can provide it through one of the siginfo_t fields?

> Post-processing tools can associate kernel stacks with user stacks
> tagged with the corresponding nonces and reconstitute the full
> stacks in effect at the time of each logged event.
>
> We can avoid duplicating unwindgs too: at step #3, if the kernel
> finds that the current thread already has an unwind pending, it can
> uses the already-pending nonce instead of making a new one and
> queuing a signal: many kernel stacks can end with the same user
> stack "tail".

This is probably a generic optimization for most backtraces, most will
have a similar tail.
 
> One nice property of this scheme is that the userspace unwinding
> isn't limited to native code. Libc could arbitrate unwinding across
> an arbitrary number of managed runtime environments in the context
> of a single process: the system could be smart enough to know that
> instead of unwinding through, e.g. Python interpreter frames, the
> unwinder (which is normal userspace code, pluggable via DSO!) could
> traverse and log *Python* stack frames instead, with meaningful
> function names. And if you happened to have, say, a JavaScript
> runtime in the same process, both JavaScript and Python could
> participate in the semantic unwinding process.
>
> A pluggable userspace unwind mechanism would have zero cost in the
> case that we're not recording stack frames. On top of that, a
> pluggable userspace unwinder *could* be written to traverse frame
> pointers just as the kernel unwinder does today, if userspace thinks
> that's the best option. Without breaking kernel ABI, that userspace
> unwinder could use DWARF, or ORC, or any other userspace unwinding
> approach. It's future-proof.

This is nice, but does need some coordination for handing off the
unwinding context between different unwinders. You could register an
unwinder by memory region (if address is in this range, it is in the
lua interpreter). And then you can start generating a backtrace using
the dedicated unwinder for that memory region. That original unwinder
can start with the full ucontext_t. But what is the contract between
unwinders? If we start with e.g. a frame-pointer unwinder then when we
get to a part that needs to use the python unwinder we only have a pc,
sp and fp left. Is that enough context for the python unwinder to
continue?

What would we need to prototype this idea and show that we can produce
quick backtraces using fast eh_frame unwinding before we convinced the
kernel to provide this interface and have it in glibc (or the vdso,
without any fancy caching, it might fit the vdso)?

We could use LD_PRELOAD or some ptrace parasite code like criu uses to
insert the unwinder code 

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Peter Boy]

> Am 17.01.2023 um 22:30 schrieb Chris Murphy :
> 
> 
> 
> On Tue, Jan 17, 2023, at 11:51 AM, Peter Boy wrote:
>>> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
>>> 
>>> Just to say this cleary btw: when we introduced the time-out initially
>>> we were coming from sysvinit where no such time-out existed at
>>> all. Hence we picked a conservative (i.e. overly long) value to not
>>> upset things too badly. And yes, some people were very much upset we
>>> now defaulted to a time-out.
>>> 
>>> If we'd start from scratch without sysvinit heritage, I think we
>>> would have started with something much much lower right-away.
>> 
>> When introducing a timeout, you obviously had the grace to choose a 
>> fairly conservative  (i.e. cautious) default value that did not lead to 
>> major problems. Would be interesting what would have been if you had 
>> started with 15 sec.
> 
> Why? it was 0 sec before systemd.

As far as I understood Lennart, there was no timeout in Sys V that killed a 
hanging process. But that is not the relevant point. 

> If anything, the time out behavior is masking problems with services not 
> shutting down in a timely manner.

It's not necessarily that. It is only one of at least 2 possibilities. 

One possibility is indeed that a service "hangs" and therefore does not 
terminate in a timely manner. This is then a bug or inappropriate programming 
in the service. And there is no point in waiting for this service, you have to 
abort, the sooner the better. 

The other possibility, especially on a highly loaded server, is that processes 
impede each other in the special situation of a shutdown and resource 
bottleneck resp. resource concurrency. And this is not dependent on the 
individual service, but on the multitude of services and their 
interdependencies. This process is not determined and is randomly driven. The 
time required for a single event, i.e. an individual shutdown, is not 
predictable. At best, one can approximate a range. If the range is exceeded, 
the assumption of a non-faulty flow becomes increasingly improbable and there 
is no point in waiting for any service anymore. No more improvement can be 
expected. You have to abort.

Unfortunately, we have no data in this case, only different "feelings". We 
can't estimate a plausible range, we can only kind of guess. And in the case of 
a server, we might be accept to wait a little longer in light of potential, 
major follow-on issues.  

So, the current decision is not optimal, but OK and manageable.



>> The way it is proposed it doesn’t make a lot of sense. Desktops and 
>> servers work very differently and have different requirements. For 
>> servers, this proposal in its present form makes no sense at all, and 
>> is on the contrary dangerous.
> 
> Why? It's been said in this thread that servers come with a higher 
> expectation of rebooting upon request rather than indefinitely hanging, in 
> contrast to desktops where there can be some tolerance for delay in exchange 
> for safety.

Maybe I don’t fully understand this due to translation issues. On a server, a 
reboot is a rare event. Optimally it is up 24/7/365. If I suffer the misfortune 
of having to reboot the server, it doesn't matter if it's 45 sec, 2 min or 5 
min. All important services are redundant, there is no total failure. And the 
startup BIOS processing often takes longer than any (regular) shutdown process. 
So, if I have 15 sec timeout instead of 2 mins, is no noticeable improvement. 
The most important thing is to get back up without any damage. 


> What I've seen on Fedora Server when there are services that hold things up 
> is invariably sshd does immediately quit so now I can't even log back in to 
> find out what's holding up the reboot. It's quite substantially a worse Ux 
> than on the desktop. I mean, ostensibly I know what I'm doing on my own 
> server and don't need to be second guessed like a desktop user.

Yes, it's pretty annoying that ssh always reliably stops immediately, unlike 
all other processes. It would be most helpful if systemd would terminate ssh 
last. 

> At least postgresql and libvirtd are configured to inhibit reboot/shutdown 
> indefinitely until they properly quit. Services can opt into this behavior, 
> overriding the default. But indefinite delay would  pose a bigger problem on 
> server than on desktops, due to the loss of any feedback and control.

Agreed. Nobody voted for an indefinite delay, as far as I have read the posts. 
It's all about how long who is willing to wait and about the relevance of 
possible damages.  





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Björn Persson]

Pavel Zhukov wrote:
> Yes, that happens every year because of koji limitation.
> Ada rebuild is not just mass-rebuild thing.
> Because of circular dependencies: gprbuild buildrequires xmlada and
> xmlada build requires gprbuild and both of them requires
> gcc-gnat.so. they were built with
> bootstrap of gprbuild should be done which requires manual steps (pretty
> straightforward process and documented in xmlada and gprbuild spec files 
> though. thanks to Bjorn!) 

The bootstrap is actually needed only if something is seriously broken,
or to add a new arch. GPRbuild is statically linked precisely to remain
functional each time GCC or XMLada is upgraded, so that it can rebuild
itself and the other Ada packages. Thus the dependency loop isn't
normally a problem. A bump and a rebuild per package should be
sufficient, but they must be done in the right order.

A package can't be built if it requires a library that can't be
installed. Therefore those libraries that depend only on Libgnat must be
built first, so they become installable again. Once those packages
appear in the buildroot, the packages that depend on them can be built.
Then those packages in turn must be added to the buildroot before the
third tier can be built. (I have now done all that for all packages I
have commit access to. I rebuilt GPRbuild too, so it's now statically
linked to the new Libgnat. Nobody needs to worry that the static
linking will cause old code to linger.)

For the mass rebuild to handle this automatically, two changes would be
needed:

· It would have to walk the dependency graph and build the packages in
dependency order instead of alphabetical order.

· It would have to make the newly built packages available to packages
that depend on them, not set them aside and then tag them all in at the
end.

So as things stand, these rebuilds need to be done by a human who knows
the dependency graph.

Björn Persson


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

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Chris Murphy]

On Tue, Jan 17, 2023, at 11:51 AM, Peter Boy wrote:
>> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
>> 
>> Just to say this cleary btw: when we introduced the time-out initially
>> we were coming from sysvinit where no such time-out existed at
>> all. Hence we picked a conservative (i.e. overly long) value to not
>> upset things too badly. And yes, some people were very much upset we
>> now defaulted to a time-out.
>> 
>> If we'd start from scratch without sysvinit heritage, I think we
>> would have started with something much much lower right-away.
>
> When introducing a timeout, you obviously had the grace to choose a 
> fairly conservative  (i.e. cautious) default value that did not lead to 
> major problems. Would be interesting what would have been if you had 
> started with 15 sec.

Why? it was 0 sec before systemd. If anything, the time out behavior is masking 
problems with services not shutting down in a timely manner.


>> It
>> appears to me fedora is considering switch to that now, and I
>> certainly think that would make a lot of sense.
>
> The way it is proposed it doesn’t make a lot of sense. Desktops and 
> servers work very differently and have different requirements. For 
> servers, this proposal in its present form makes no sense at all, and 
> is on the contrary dangerous.

Why? It's been said in this thread that servers come with a higher expectation 
of rebooting upon request rather than indefinitely hanging, in contrast to 
desktops where there can be some tolerance for delay in exchange for safety.

Why should a server sysadmin's request for a reboot or shutdown be second 
guessed? What are the consequences of second guessing?

What I've seen on Fedora Server when there are services that hold things up is 
invariably sshd does immediately quit so now I can't even log back in to find 
out what's holding up the reboot. It's quite substantially a worse Ux than on 
the desktop. I mean, ostensibly I know what I'm doing on my own server and 
don't need to be second guessed like a desktop user. 

At least postgresql and libvirtd are configured to inhibit reboot/shutdown 
indefinitely until they properly quit. Services can opt into this behavior, 
overriding the default. But indefinite delay would  pose a bigger problem on 
server than on desktops, due to the loss of any feedback and control.


> A strangely ignorant attitude to take a positive view of the change, 
> even if those affected, the customers, are upset and fear considerable 
> disadvantages. Only someone who is not responsible for TBs of data and 
> thousands of users can talk like this. The least you have to do is test 
> and check what effects it has and prove that the concern is unjustified.

The proposal changes a default behavior. It's not itself an override.



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

F38 proposal: IoT Simplified Installer (Self-Contained Change proposal)

[Ben Cotton]

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

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


== Summary ==
Offer Fedora IoT users a new method to create and deploy customized
Fedora IoT disk images using a new installer called Simplified
Installer.

== Owner ==
* Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
* Email: amurd...@redhat.com, pwha...@fedoraproject.org


== Detailed Description ==
The Fedora IoT Simplified Installer will use coreos-installer to write
an OStree raw image straight to a disk specified in a kernel argument,
without the need for a kickstart or user interaction. This type of
installation is ideal for devices connected at the edge where
connectivity can be slow or intermittent. It offers the ability to
configure the system via osbuild itself, FDO and Ignition.

== Feedback ==


== Benefit to Fedora ==
The addition of the Fedora IoT Simplified Installer will benefit IoT
users by allowing them to create customized disk images for use on
their edge devices. This feature is already available downstream,
adding it to Fedora will once again bring Fedora back to the true
upstream of RHEL for edge and allows testing and adoption of new
functionality like FIDO Device Onboarding.

== Scope ==
* Proposal owners:
** Test building Fedora IoT Simplified Installer with `osbuild-composer`
** Update Fedora IoT documentation with usage instructions.

* Other developers:

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

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


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

== How To Test ==
Testable by installing `osbuild-composer` in Fedora 38 and using the
command line tool or the Cockpit web interface to create a Fedora IoT
Simplified Installer iso to deploy a UEFI enabled edge device.


== User Experience ==
This change will greatly enhance the Fedora IoT user experience by
allowing users to utilize `osbuild-composer` and blueprints to create
customized Fedora IoT deployments and leverage new features like FIDO
Device Onboarding for secure zero touch device onboarding of edge
devices as well as Ignition to configure the device once it starts.


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

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

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

== Release Notes ==


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

How to build two flavors of the same package?

[Till Hofmann]

Hi all,

Someone (rightfully) suggested that we should build glfw twice, once 
with wayland support and once without:

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

Is there any best practice how to build the same package in two 
different flavors, in this case cmake-based? I vaguely remember seeing a 
spec file that did that, but I don't remember where.


Thanks for any pointers!

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

F38 proposal: IoT Simplified Installer (Self-Contained Change proposal)

[Ben Cotton]

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

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


== Summary ==
Offer Fedora IoT users a new method to create and deploy customized
Fedora IoT disk images using a new installer called Simplified
Installer.

== Owner ==
* Name: [[User:runcom| Antonio Murdaca]], [[User:pwhalen| Paul Whalen]]
* Email: amurd...@redhat.com, pwha...@fedoraproject.org


== Detailed Description ==
The Fedora IoT Simplified Installer will use coreos-installer to write
an OStree raw image straight to a disk specified in a kernel argument,
without the need for a kickstart or user interaction. This type of
installation is ideal for devices connected at the edge where
connectivity can be slow or intermittent. It offers the ability to
configure the system via osbuild itself, FDO and Ignition.

== Feedback ==


== Benefit to Fedora ==
The addition of the Fedora IoT Simplified Installer will benefit IoT
users by allowing them to create customized disk images for use on
their edge devices. This feature is already available downstream,
adding it to Fedora will once again bring Fedora back to the true
upstream of RHEL for edge and allows testing and adoption of new
functionality like FIDO Device Onboarding.

== Scope ==
* Proposal owners:
** Test building Fedora IoT Simplified Installer with `osbuild-composer`
** Update Fedora IoT documentation with usage instructions.

* Other developers:

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

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


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

== How To Test ==
Testable by installing `osbuild-composer` in Fedora 38 and using the
command line tool or the Cockpit web interface to create a Fedora IoT
Simplified Installer iso to deploy a UEFI enabled edge device.


== User Experience ==
This change will greatly enhance the Fedora IoT user experience by
allowing users to utilize `osbuild-composer` and blueprints to create
customized Fedora IoT deployments and leverage new features like FIDO
Device Onboarding for secure zero touch device onboarding of edge
devices as well as Ignition to configure the device once it starts.


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

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

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

== Release Notes ==


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

Re: Bodhi 7.0.1 deployed to prod

[Bojan Smojver via devel]

Yay! Thank you!

-- 
Bojan

-Original Message-
From: Mattia Verga 
Reply-To: devel@lists.fedoraproject.org
To: devel-annou...@lists.fedoraproject.org
Subject: Bodhi 7.0.1 deployed to prod
Date: 17/01/23 16:39:49

- Frozen releases updates will now be forced into testing before being
pushed to stable. Previously, when a release was frozen, an update which
was just submitted (pending), but had received enough votes to be pushed
directly to stable, was not pushed in testing nor stable. Now it will be
pushed to testing and remain there until the release is un-frozen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Pavel Zhukov]

Fabio Valentini  writes:

> On Tue, Jan 17, 2023 at 1:39 PM Jakub Jelinek  wrote:>
>> On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
>> > Hello. GCC was updated to 13 in rawhide while the Fedora change was still
>> > being voted about by FESCo.
>> >
>> > Apparently, the following packages now don't install:
>>
>> There is a mass rebuild tomorrow.  The Ada soname changes every year
>> and we've never rebuilt Ada packages separately for that, just during the
>> mass rebuild.
>
> "Because we've always done it like that" is usually not a good
> argument for something bad to remain the way it is -
> (especially since this change hasn't even formally been approved by FESCo).
Yes, that happens every year because of koji limitation.
Ada rebuild is not just mass-rebuild thing.
Because of circular dependencies: gprbuild buildrequires xmlada and
xmlada build requires gprbuild and both of them requires
gcc-gnat.so. they were built with
bootstrap of gprbuild should be done which requires manual steps (pretty
straightforward process and documented in xmlada and gprbuild spec files 
though. thanks to Bjorn!) 

-- 
Pavel

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

Re: Use cases for 'fedpkg scratch-build'

[Otto Liljalaakso]

Vít Ondruch kirjoitti 17.1.2023 klo 13.34:


Dne 16. 01. 23 v 21:59 Otto Liljalaakso napsal(a):

Vít Ondruch kirjoitti 16.1.2023 klo 16.50:

I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So 
how would the proposed change influence this command?


I do not intend to change that behavior in any way.



But you proposed to basically drop the `--srpm` option. So maybe this 
should work: `fedpkg scratch-build some.rpm` instead. Not sure. I have 
not thought about this into details especially in relation to plain 
`fedpkg build`.


My original idea was to make --srpm the default, i.e. 'fedpkg 
scratch-build' would be the same as 'fedpkg scratch-build --srpm'. No 
change to 'fedpkg scratch-build --srpm ', or to 'fedpkg 
scratch-build --srpm-mock' (with or without path). The lost feature 
would have been what 'fedpkg scratch-build' currently does: build the 
srpm in Koji, then do a scratch build from it.


Anyhow, Richard has a better proposal in another subthread, which I 
intend to follow: All existing behaviour is kept, but if there are local 
changes, 'fedpkg scratch-build' does what 'fedpkg scratch-build --srpm' 
does — currently an error is printed in this situation.

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

Re: LLVM support for '-Wl,-WX'

[Tom Stellard]

On 1/17/23 09:48, Michael Cronenworth wrote:

On 1/17/23 10:15 AM, Tom Stellard wrote:


It sounds like the option is not relevant for Windows.  See
https://reviews.llvm.org/D116484


Thanks, Tom. Do you think modifying the wine configure to not use -Wl,WX is the 
best option?



Yes, I think that might be best for now.

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

Re: Version number of python-future

[Antonio T. sagitter]

Thank you

On 16/01/23 06:19, Lumír Balhar wrote:

Hi Antonio.

The problem is in the project metadata. When I open the SRPM this 
package is built from and the take a look at the source tarball, I find 
this in the src/future/__init__.py:


__ver_major__ = 0
__ver_minor__ = 18
__ver_patch__ = 2

So it seems that they released version 0.18.3 with the wrong version in 
this file. This is already fixed upstream and when I download the 
tarball again, it also has a different hash.


I did a mock rebuild with the new tarball and the result contains:

Provides: future = 0:0.18.3-2.fc38 future-python3 = 0:0.18.3-2.fc38 
python-future = 0.18.3-2.fc38 python3-future = 0.18.3-2.fc38 
python3.11-future = 0.18.3-2.fc38 python3.11dist(future) = 0.18.3 
python3dist(future) = 0.18.3


Have a nice day.

Lumír

On 1/13/23 21:52, Antonio T. sagitter wrote:


Hi all.

Latest release of `future`, the 0.18.3 
(https://koji.fedoraproject.org/koji/rpminfo?rpmID=32957279), is 
generating


future = 0:0.18.3-2.fc38
future-python3 = 0:0.18.3-2.fc38
python-future = 0.18.3-2.fc38
python3-future = 0.18.3-2.fc38
python3.11-future = 0.18.3-2.fc38
python3.11dist(future) = 0.18.2    <---
python3dist(future) = 0.18.2  <---

Can you help to understand why?

Regards.

--
---
Antonio Trande
Fedora Project
mailto:sagit...@fedoraproject.org
GPG key: 0x40FDA7B70789A9CD
GPG keys server:https://keyserver.dcc.sib.swiss/

___
python-devel mailing list --python-devel@lists.fedoraproject.org
To unsubscribe send an email topython-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report 
it:https://pagure.io/fedora-infrastructure/new_issue


--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x40FDA7B70789A9CD
GPG keys server: https://keyserver.dcc.sib.swiss/


OpenPGP_signature
Description: OpenPGP digital signature
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jan 12, 2023 at 09:36:39AM -0500, Colin Walters wrote:
> Ideally, we'd have a mechanism to define timeouts like this somehow
> relative to system speed (throughput) not simple wall clock time.

That's a nice idea. Meson has '-t' that is a multiplier for test
timeouts and it's quite useful. I guess we could add something like this
in systemd (with the usual trifecta of a config file setting, and commandline
and kernel commandline options).

Another option is for things that have hard-to-predict timeout needs to extend
the timeout dynamically using sd_notify with EXTEND_TIMEOUT_USEC=…. [1]
It's a bit more work for the service, but is a much more flexible solution.

[1] 
https://www.freedesktop.org/software/systemd/man/sd_notify.html#EXTEND_TIMEOUT_USEC=%E2%80%A6

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

Summary/Minutes from today's FESCo Meeting (2023-01-17)

[Zbigniew Jędrzejewski-Szmek]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-17/fesco.2023-01-17-17.01.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-17/fesco.2023-01-17-17.01.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-17/fesco.2023-01-17-17.01.log.html

Meeting summary
---
* init process  (zbyszek, 17:01:18)

* #2928 Change: Shorter Shutdown Timer   (zbyszek, 17:03:38)
  * AGREED: REJECTED (+3,1,-3)  (zbyszek, 17:33:55)
  * AGREED: Change is approved with a timeout of 45 s and the caveat
that editions must be able to override the change (+8,0,-1)
(zbyszek, 18:02:24)

* #2930 Change: Rpmautospec by Default  (zbyszek, 18:03:11)
  * AGREED: APPROVED (+6, 0, -1)  (zbyszek, 18:22:06)
  * ACTION: nils to work with sgallagh on maintainance access  (zbyszek,
18:22:38)

* Next week's chair  (zbyszek, 18:22:56)
  * ACTION: zbyszek will chair next meeting  (zbyszek, 18:24:25)

* Open Floor  (zbyszek, 18:24:29)

Meeting ended at 18:26:01 UTC.


Action Items

* nils to work with sgallagh on maintainance access
* zbyszek will chair next meeting
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: bodhi upgraded to 7.0.1

[Fabio Valentini]

On Tue, Jan 17, 2023 at 7:05 PM Mattia Verga via devel
 wrote:
>
> Il 17/01/23 12:54, Miro Hrončok ha scritto:
> >
> > Is it possible that bodhi no longer automatically recognizes the changelog 
> > of
> > Rawhide updates?
> >
> > See before the update:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-9090058f62
> >
> > And after:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-df57e062f6
>
> It should not, but possibly
> https://github.com/fedora-infra/bodhi/issues/4316 is still randomly
> happening on a very few cases.

One of my updates for rawhide has the correct changelog:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-e28fb18044

So it seems it was a fluke indeed.

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

Re: bodhi upgraded to 7.0.1

[Mattia Verga via devel]

Il 17/01/23 12:54, Miro Hrončok ha scritto:
>
> Is it possible that bodhi no longer automatically recognizes the changelog of
> Rawhide updates?
>
> See before the update:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-9090058f62
>
> And after:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-df57e062f6

It should not, but possibly
https://github.com/fedora-infra/bodhi/issues/4316 is still randomly
happening on a very few cases.

Mattia

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

Re: vtk build failure with gcc 13.0.0 - enum class

[Jonathan Wakely]

On Tue, 17 Jan 2023 at 09:04, Jakub Jelinek wrote:
>
> On Mon, Jan 16, 2023 at 09:36:39PM -0700, Orion Poplawski wrote:
> > elaborated-type-specifier for a scoped enum must not use the 'class' keyword
> >33 | enum class EndiannessType : std::uint8_t
> >   |  ^
>
> The actual bug is shown in later errors.
> > 'int32_t' is not a member of 'std'; did you mean 'int32_t'?
> >   103 |   std::array ComputeExtent() const;
> >   |   ^~~

Yes, unfortunately GCC gives a pretty bad diagnostic when an
undeclared type is used as an enum-base:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758


>
> See https://gcc.gnu.org/gcc-13/porting_to.html , in particular (something
> that is there every year) Header dependency changes:
>
> Some C++ Standard Library headers have been changed to no longer include 
> other headers that were being used internally by the library. As such, C++ 
> programs that used standard library components without including the right 
> headers will no longer compile.
>
> The following headers are used less widely in libstdc++ and may need to be 
> included explicitly when compiling with GCC 13:
>
>  (for std::int8_t, std::int32_t etc.) // This case
>
> So, likely with GCC 12 and older cstdint has been included as implementation
> detail by one of the libstdc++ headers VTK includes but isn't included
> anymore.
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM support for '-Wl,-WX'

[Michael Cronenworth]

On 1/17/23 10:15 AM, Tom Stellard wrote:


It sounds like the option is not relevant for Windows.  See
https://reviews.llvm.org/D116484


Thanks, Tom. Do you think modifying the wine configure to not use -Wl,WX is the best 
option?

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

Re: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Peter Boy]

> Am 16.01.2023 um 13:23 schrieb Lennart Poettering :
> 
> Just to say this cleary btw: when we introduced the time-out initially
> we were coming from sysvinit where no such time-out existed at
> all. Hence we picked a conservative (i.e. overly long) value to not
> upset things too badly. And yes, some people were very much upset we
> now defaulted to a time-out.
> 
> If we'd start from scratch without sysvinit heritage, I think we
> would have started with something much much lower right-away.

When introducing a timeout, you obviously had the grace to choose a fairly 
conservative  (i.e. cautious) default value that did not lead to major 
problems. Would be interesting what would have been if you had started with 15 
sec.


> It
> appears to me fedora is considering switch to that now, and I
> certainly think that would make a lot of sense.

The way it is proposed it doesn’t make a lot of sense. Desktops and servers 
work very differently and have different requirements. For servers, this 
proposal in its present form makes no sense at all, and is on the contrary 
dangerous.

One indispensable amendment is that nothing changes for servers.


> Anyway, if fedora now wants to lower the default setup, then I
> certainly sympathize. I think a policy of "aggressive time-out by
> default, individual opt-outs per-service" is a better policy for a
> stable OS than the current "conservative time-out by default,
> individual opt-in per-service for something more aggressive".
> 
> So yes, lowering the time-outs by default would make sense to me, but
> of course, people will be upset...

A strangely ignorant attitude to take a positive view of the change, even if 
those affected, the customers, are upset and fear considerable disadvantages. 
Only someone who is not responsible for TBs of data and thousands of users can 
talk like this. The least you have to do is test and check what effects it has 
and prove that the concern is unjustified.


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor and board member
Java developer and enthusiast

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

Re: List of long term FTBFS packages to be retired in February

[Jens-Ulrik Petersen]

On Wed, Jan 11, 2023 at 8:59 PM Miro Hrončok  wrote:

> llvm10   petersen, sergesanspaille
>
Probably okay to drop at this point.

> llvm11   jistone, petersen, 
> sergesanspaille,
> tstellar
> llvm12   petersen, sergesanspaille,
> tstellar
>
These two are also still in use by ghc for some archs: aarch64 (ghc,
ghc8.10, ghc9.0) and s390x (ghc9.2 and ghc9.4).
Though I am planning to move them to only llvm12 at least for F38.

Anyway I think I may be able to workaround these by disabling the testsuite
probably...

llvm9.0  jistone, petersen, tstellar

I think this could be retired now.  At least I am not aware of any
remaining dependents.

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

Re: LLVM support for '-Wl,-WX'

[Tom Stellard]

On 1/17/23 07:57, Tom Stellard wrote:

On 1/17/23 06:17, Michael Cronenworth wrote:

On 1/16/23 11:30 PM, Tom Stellard wrote:

-WX means treat warnings as errors.  It's possible the configure
check is failing for other reasons.  Is that the first check run
with -target aarch64-windows?  Do you have the full config.log? 


Yes. I do not have the full log. This is from a Koji ARM builder.

Here's the parent Koji task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96232039


I did another scratch build and dumped the config.log:

https://kojipkgs.fedoraproject.org//work/tasks/3616/96253616/build.log

It looks like the configure check is failing because of the --as-needed flag
which the linker does not support.  As a workaround you can add %undefine 
_ld_as_needed
although this will impact the whole project, not just the cross compilation 
parts.

I'll look into this.  I think it may be the case that --as-needed just doesn't 
make
sense for the Windows file format, which could be why the linker doesn't accept 
it.



It sounds like the option is not relevant for Windows.  See
https://reviews.llvm.org/D116484



-Tom


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



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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[tdawson]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-01-18 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/9854/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: LLVM support for '-Wl,-WX'

[Tom Stellard]

On 1/17/23 06:17, Michael Cronenworth wrote:

On 1/16/23 11:30 PM, Tom Stellard wrote:

-WX means treat warnings as errors.  It's possible the configure
check is failing for other reasons.  Is that the first check run
with -target aarch64-windows?  Do you have the full config.log? 


Yes. I do not have the full log. This is from a Koji ARM builder.

Here's the parent Koji task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96232039


I did another scratch build and dumped the config.log:

https://kojipkgs.fedoraproject.org//work/tasks/3616/96253616/build.log

It looks like the configure check is failing because of the --as-needed flag
which the linker does not support.  As a workaround you can add %undefine 
_ld_as_needed
although this will impact the whole project, not just the cross compilation 
parts.

I'll look into this.  I think it may be the case that --as-needed just doesn't 
make
sense for the Windows file format, which could be why the linker doesn't accept 
it.

-Tom


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

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

Re: Heads up: tox 4 in Rawhide buildroot

[Miro Hrončok]

On 11. 01. 23 15:59, Miro Hrončok wrote:
 > Successfully waited 0:00 for python-tox-4.2.6-1.fc38 to appear in the 
f38-build repo.


If you hit unexpected issues with %tox, let us know here or in Bugzilla.


First gotcha:

tox 4 no longer fails without configuration:

$ tox --print-deps-to -
ROOT: No tox.ini or setup.cfg or pyproject.toml found, assuming empty tox.ini 
at .../patiencediff-0.2.12

tox
  py: OK (0.01 seconds)
  congratulations :) (0.04 seconds)
$ echo $?
0

So packages that us:

  %generate_buildrequires
  %pyproject_buildrequires -t

Without any tox configuration at all will now simply BuildRequire tox and 
tox-current-env for no good reason, instead of failing :/


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python

[Fabio Valentini]

On Mon, Jan 16, 2023 at 10:02 PM Miro Hrončok  wrote:
>
> On 16. 01. 23 21:37, Fabio Valentini wrote:
> > Isn't the problem here that building Python extensions needs to work
> > correctly in two - possibly conflicting - scenarios:
> >
> > - in RPM packages, where using system compiler flags is a MUST
>
> Yes and packages get *all* the Fedora RPM flags that way via:
>
>   - https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck
>   - %py3_build, %pyproject_wheel, etc.
>
> > - when user installs Python packages manually, for example with pip in
> > a venv, where using system compiler flags isn't necessary (or
> > necessarily a good idea)
>
> This is the case this thread is about.

Ok, thanks for the explanation!
In that case, I think it would make sense to have C / C++ compiler
flags for user-installed Python packages to fall back to GCC defaults
(same as for user-compiled C / C++ code), and only add flags that are
necessary for compatibility with system Python (looks like this is
only "-fexceptions"?).

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

Re: Bodhi slow with 504 gateway timeouts

[Arthur Bols]

On 17/01/2023 16:15, Fabio Valentini wrote:

On Tue, Jan 17, 2023 at 4:13 PM Richard Shaw  wrote:

On Tue, Jan 17, 2023 at 8:18 AM Arthur Bols  wrote:

On 17/01/2023 14:57, Stephen Smoogen wrote:

So bodhi and pagure are at different datacenters with hopefully different
network paths. Could people do some mtr or traceroutes from their locations
so we can see if this can be ironed out. Currently the limited tools we
have in Fedora Infra for checking this all show 'green' so the
'interconnects' between the services are working.


Fedora infra is usually very slow for me, but Bodhi seemed much slower
than usual (taking a full minute to load).

After being really slow, I had a bunch of 503's (not 504) for a while,
but now it seems to work fine:
- /releases takes 10 seconds (and had a 500 error once)
- /updates seems fast with 2.2 seconds

I had some slow issues before the update to Bodhi but it looks like now I'm 
getting a different route and Bodhi is nice and snappy for me now.

Things were similar for me - some queries were really slow and / or
timing out earlier today, but now everything is nice and fast without
any errors.
So whatever it was, it was probably a temporary issue.

Fabio
Just to clarify, because I think I wasn't clear, now it works fine for 
me. I believe even better than before! :)

Some slowness is probably due to my connection (ping of ~200ms).

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

Re: [Package Review] draco

[Arthur Bols]

On 15/01/2023 03:44, Luya Tshimbalanga wrote:

Hello team,

draco package is ready for review.
https://bugzilla.redhat.com/show_bug.cgi?id=2160996


The spec file was originally from UnitedRPM [1] which only needs a 
clean up to adhere to the packaging guideline. The library itself is 
useful for Blender to compress 3D geometry.


Thanks in advance for taking this package for review.


Reference

[1] https://github.com/UnitedRPMs/draco/blob/main/draco.spec

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer


Hi Luya,

I took the review. I would appreciate it if you could review 
mooltipass-udev: https://bugzilla.redhat.com/show_bug.cgi?id=2160449 .


It's a simple package for the udev rules for mooltipass devices, which 
were previously included in the moolticute package.


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

Re: Changes in the Fedora Packaging Guidelines

[Miro Hrončok]

On 17. 01. 23 15:53, Olivier Fourdan wrote:

Hi Miro

On Mon, Jan 16, 2023 at 8:18 PM Miro Hrončok  wrote:


[…]

---

Packages are told not to conditionalize Sources definitions
(e.g. on %fedora or %rhel).

https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_do_not_conditionalize_sources
https://pagure.io/packaging-committee/pull-request/1163

---


The example there on how to do that correctly would not work with
%autosetup though.


That is exactly why the example does not use %autosetup.

If you'd like to use %autosetup, you could use something like this:

Patch:  I-am-always-applied.patch
Patch:  So-am-I.patch
Patch:  This-patch-is-also-always-applied.patch

# RHEL-only patches
Patch201:   This-patch-is-not-applied-on-Fedora.patch
Patch202:   This-patch-is-only-for-the-enterprise.patch

%prep
%autosetup -N   <--- don't apply patches
%autopatch -M 200  <--- apply patches up until 200
%if 0%{?rhel}
%autopatch -m 201 <--- apply patches >= 201
%endif


Or even:

...
%prep
%autosetup -N
%autopatch %{!?rhel:-M 200}


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

Re: Bodhi slow with 504 gateway timeouts

[Fabio Valentini]

On Tue, Jan 17, 2023 at 4:13 PM Richard Shaw  wrote:
>
> On Tue, Jan 17, 2023 at 8:18 AM Arthur Bols  wrote:
>>
>> On 17/01/2023 14:57, Stephen Smoogen wrote:
>> > So bodhi and pagure are at different datacenters with hopefully different
>> > network paths. Could people do some mtr or traceroutes from their locations
>> > so we can see if this can be ironed out. Currently the limited tools we
>> > have in Fedora Infra for checking this all show 'green' so the
>> > 'interconnects' between the services are working.
>> >
>> Fedora infra is usually very slow for me, but Bodhi seemed much slower
>> than usual (taking a full minute to load).
>>
>> After being really slow, I had a bunch of 503's (not 504) for a while,
>> but now it seems to work fine:
>> - /releases takes 10 seconds (and had a 500 error once)
>> - /updates seems fast with 2.2 seconds
>
>
> I had some slow issues before the update to Bodhi but it looks like now I'm 
> getting a different route and Bodhi is nice and snappy for me now.

Things were similar for me - some queries were really slow and / or
timing out earlier today, but now everything is nice and fast without
any errors.
So whatever it was, it was probably a temporary issue.

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

Re: Bodhi slow with 504 gateway timeouts

[Richard Shaw]

On Tue, Jan 17, 2023 at 8:18 AM Arthur Bols  wrote:

> On 17/01/2023 14:57, Stephen Smoogen wrote:
> > So bodhi and pagure are at different datacenters with hopefully different
> > network paths. Could people do some mtr or traceroutes from their
> locations
> > so we can see if this can be ironed out. Currently the limited tools we
> > have in Fedora Infra for checking this all show 'green' so the
> > 'interconnects' between the services are working.
> >
> Fedora infra is usually very slow for me, but Bodhi seemed much slower
> than usual (taking a full minute to load).
>
> After being really slow, I had a bunch of 503's (not 504) for a while,
> but now it seems to work fine:
> - /releases takes 10 seconds (and had a 500 error once)
> - /updates seems fast with 2.2 seconds
>

I had some slow issues before the update to Bodhi but it looks like now I'm
getting a different route and Bodhi is nice and snappy for me now.

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

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Jakub Jelinek]

On Tue, Jan 17, 2023 at 03:24:16PM +0100, Björn Persson wrote:
> Jakub Jelinek wrote:
> > On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> > > Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> > > being voted about by FESCo.
> > > 
> > > Apparently, the following packages now don't install:  
> > 
> > There is a mass rebuild tomorrow.  The Ada soname changes every year
> > and we've never rebuilt Ada packages separately for that, just during the
> > mass rebuild.
> 
> Pavel and I have always rebuilt the Ada packages separately for the
> yearly soname change. They must be rebuilt in dependency order, and
> that's not how the mass rebuild does it.

Thanks.

> I'd be willing to cooperate to do the rebuild in a side tag, but I
> can't promise to always be available at a moment's notice.

I've been using a side-tag for gcc 13 for a couple of weeks so that annobin
and libtool can be rebuilt against gcc 13.
For trying to rebuild other packages, the problem is to find the right time,
if it is done too early (weeks before it is actually merged into rawhide),
it will make the Ada (or whatever else needs to be rebuilt) packages
buildable either in the side-tag or in rawhide but pain if needed in both,
and if it is too short before the tagging then there won't be enough time to
rebuild those.
E.g. even the annobin and libtool in the side-tag I had to rebuild again
because it was bumped several times in rawhide in between.
It is already pain now to find the right time for this (based on what
critical bugs are already fixed and what is the general state of the
compiler snapshot at that point, plus when is the scheduled mass rebuild
time) and having to do the decision several days or more before it can be
done would be even more painful.

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

Re: Changes in the Fedora Packaging Guidelines

[Olivier Fourdan]

Hi Miro

On Mon, Jan 16, 2023 at 8:18 PM Miro Hrončok  wrote:
>
> […]
>
> ---
>
> Packages are told not to conditionalize Sources definitions
> (e.g. on %fedora or %rhel).
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_do_not_conditionalize_sources
> https://pagure.io/packaging-committee/pull-request/1163
>
> ---

The example there on how to do that correctly would not work with
%autosetup though.

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

Re: F39 proposal: Remove pam_console (System-Wide Change proposal)

[Dmitry Butskoy]

Ben Cotton wrote:

== Summary ==
Remove pam_console as it is not enabled by default, can be replaced by
systemd and has security issues.


Just to make sure -- pam_console provided an "auth" feature (see 
https://bugzilla.redhat.com/show_bug.cgi?id=137802 ), which allows to 
log just once when working on several virtual consoles (and yes, it was 
19 years ago :) ). Is it possible with systemd-logind now?



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

Re: Changes in the Fedora Packaging Guidelines

[Petr Pisar]

V Mon, Jan 16, 2023 at 08:18:09PM +0100, Miro Hrončok napsal(a):
> Hello packagers,
> 
> the Fedora Packaging Committee has been asked to send summaries of changes
> in the Fedora Packaging Guidelines. Here is my attempt to do that. Since
> this hasn't been done in years, this first announcement sets the boundary of
> what to announce somewhat arbitrarily. I will try to followup on this
> announcement in the future once there is something new to announce.
> 
> 
> Here are the noteworthy "recent" changes, newest to oldest (more or less):
> 
Thanks.

-- Petr


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

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

[Zdenek Dohnal]

On 1/16/23 12:31, Björn Persson wrote:

Robert Marcano via devel wrote:

The admin can implement CUPS
authentication but an ipp://localhost:6 open port entirely open to
anyone on the local machine to submit print jobs directly bypassing CUPS.

In that case it's also accessible to all the untrusted Javascript junk
that regularly runs in the user's browser. Because IPP is built on HTTP,
a Javascript program can tell the browser to send an IPP request. What
has been done to secure those "virtual printer devices" against DNS
rebinding attacks?
https://en.wikipedia.org/wiki/DNS_rebinding

I'll ask IPP-USB upstream about it, stay tuned.


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


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

Re: Bodhi slow with 504 gateway timeouts

[Jonathan Wright via devel]

On Tue, Jan 17, 2023 at 8:21 AM Stephen Smoogen  wrote:

>
>
> On Tue, 17 Jan 2023 at 09:19, Arthur Bols  wrote:
>
>> On 17/01/2023 14:57, Stephen Smoogen wrote:
>> > So bodhi and pagure are at different datacenters with hopefully
>> different
>> > network paths. Could people do some mtr or traceroutes from their
>> locations
>> > so we can see if this can be ironed out. Currently the limited tools we
>> > have in Fedora Infra for checking this all show 'green' so the
>> > 'interconnects' between the services are working.
>> >
>> Fedora infra is usually very slow for me, but Bodhi seemed much slower
>> than usual (taking a full minute to load).
>>
>> After being really slow, I had a bunch of 503's (not 504) for a while,
>> but now it seems to work fine:
>> - /releases takes 10 seconds (and had a 500 error once)
>> - /updates seems fast with 2.2 seconds
>>
>>
> Please note that from other announcements bodhi was updated today to
> 7.0.1. The slowdowns may have been due to that.
>
> However I notice both you and Richard have large packet drops on
> twelve99.net ip addresses. I don't know yet if that is an additional
> problem or not.
>
>

Without packet loss at the endpoint the stuff in the middle doesn't much
matter.  Based on the MTR and trace I'd say this is not network related.


>
>> $ mtr bodhi.fedoraproject.org -r -G
>> Start: 2023-01-17T15:14:31+0100
>> HOST: MarkV   Loss%   Snt   Last   Avg  Best Wrst
>> StDev
>>1.|-- ptr-82pqtg1hqu6kedca1n3.1 90.0%106.0   6.0   6.0 6.0
>> 0.0
>>2.|-- ptr-377wgf58htvrzp7oh0ch. 20.0%10   13.7  15.3  12.7 20.1
>> 2.7
>>3.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>4.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>5.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>6.|-- 2001:730:2302::d52e:a209   0.0%10   16.3  18.0  13.1 24.9
>> 3.5
>>7.|-- 2001:730:2302:1::d52e:a20  0.0%10   17.9  17.4  13.4 20.4
>> 2.7
>>8.|-- prs-bb1-v6.ip.twelve99.ne 10.0%10   61.1  31.3  16.4 62.1
>> 17.8
>>9.|-- ash-bb2-v6.ip.twelve99.ne  0.0%10  105.2 108.7 104.0
>> 118.7   5.0
>>   10.|-- lax-b22-v6.ip.twelve99.ne 90.0%10  160.2 160.2 160.2
>> 160.2   0.0
>>   11.|-- a100-ic325183-las-b24.ip.  0.0%10  175.7 162.1 158.0
>> 175.7   5.2
>>   12.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   13.|-- 2620:107:4000:8006::1260.0%10  182.8 187.3 177.4
>> 199.7   7.1
>>   14.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   15.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   16.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   17.|-- 2620:107:4000:c5e0::f3fd:  0.0%10  188.3 188.2 182.0
>> 192.4   2.8
>>   18.|-- 2620:107:4000:a090::f000:  0.0%10  185.3 185.5 182.5
>> 187.6   1.6
>>   19.|-- 2620:107:4000:cfff::f200:  0.0%10  183.1 185.7 181.9
>> 192.2   3.3
>>   20.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   21.|-- ???   100.0100.0   0.0   0.0 0.0
>> 0.0
>>   22.|-- 2620:107:4000:4205:8000:0  0.0%10  182.8 188.9 182.0 220.5
>> 11.5
>>   23.|-- 2600:1f14:fad:5c02:7c8a:7  0.0%10  188.2 187.1 180.4
>> 210.5   8.5
>>
>>
>> $ traceroute bodhi.fedoraproject.org
>> traceroute to bodhi.fedoraproject.org (8.43.85.67), 30 hops max, 60 byte
>> packets
>>   1  _gateway (192.168.0.1)  6.347 ms  10.770 ms  11.768 ms
>>   2  d51A4C401.access.telenet.be (81.164.196.1)  20.244 ms  22.376 ms
>> 22.311 ms
>>   3  * * *
>>   4  * * *
>>   5  be-dgb01a-rb1-ae-19-0.aorta.net (213.46.162.9)  23.660 ms 23.584
>> ms  27.996 ms
>>   6  be-bru02a-ra1-vl-6.aorta.net (213.46.162.14)  29.026 ms 21.811 ms
>> 18.822 ms
>>   7  prs-bb1-link.ip.twelve99.net (62.115.116.238)  22.234 ms 19.546 ms
>> 25.043 ms
>>   8  ash-bb2-link.ip.twelve99.net (62.115.112.242)  116.324 ms 117.718
>> ms  114.206 ms
>>   9  ash-b2-link.ip.twelve99.net (62.115.123.125)  117.633 ms 117.595
>> ms  117.555 ms
>> 10  viawest-svc073699-ic361683.ip.twelve99-cust.net (213.248.67.199)
>> 117.473 ms  117.424 ms  117.385 ms
>> 11  be23.bbrt01.iad10.flexential.net (66.51.1.148)  129.400 ms 130.492
>> ms  130.451 ms
>> 12  be209.bbrt02.ral01.flexential.net (66.51.5.117)  120.744 ms 120.705
>> ms  120.597 ms
>> 13  * be32.crrt02.ral01.flexential.net (148.66.238.113)  119.944 ms
>> 122.230 ms
>> 14  128.136.224.140 (128.136.224.140)  112.075 ms  111.922 ms 110.807 ms
>> 15  8.43.84.1 (8.43.84.1)  176.779 ms  203.379 ms  205.480 ms
>> 16  8.43.84.3 (8.43.84.3)  122.495 ms  120.608 ms  122.398 ms
>> 17  8.43.84.4 (8.43.84.4)  215.289 ms  215.232 ms  211.599 ms
>> 18  ip-8-43-86-126.foo.bar (8.43.86.126)  124.226 ms  126.584 ms 142.354
>> ms
>> 19  proxy14.fedoraproject.org (8.43.85.67)  134.550 ms !X  116.964 ms
>> !X  121.806 ms !X
>>
>>
>> --
>> Arthur Bols
>> fas/irc: principis
>> 

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Björn Persson]

Jakub Jelinek wrote:
> On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> > Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> > being voted about by FESCo.
> > 
> > Apparently, the following packages now don't install:  
> 
> There is a mass rebuild tomorrow.  The Ada soname changes every year
> and we've never rebuilt Ada packages separately for that, just during the
> mass rebuild.

Pavel and I have always rebuilt the Ada packages separately for the
yearly soname change. They must be rebuilt in dependency order, and
that's not how the mass rebuild does it.

I'd be willing to cooperate to do the rebuild in a side tag, but I
can't promise to always be available at a moment's notice.

Björn Persson


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

Re: Bodhi slow with 504 gateway timeouts

[Stephen Smoogen]

On Tue, 17 Jan 2023 at 09:19, Arthur Bols  wrote:

> On 17/01/2023 14:57, Stephen Smoogen wrote:
> > So bodhi and pagure are at different datacenters with hopefully different
> > network paths. Could people do some mtr or traceroutes from their
> locations
> > so we can see if this can be ironed out. Currently the limited tools we
> > have in Fedora Infra for checking this all show 'green' so the
> > 'interconnects' between the services are working.
> >
> Fedora infra is usually very slow for me, but Bodhi seemed much slower
> than usual (taking a full minute to load).
>
> After being really slow, I had a bunch of 503's (not 504) for a while,
> but now it seems to work fine:
> - /releases takes 10 seconds (and had a 500 error once)
> - /updates seems fast with 2.2 seconds
>
>
Please note that from other announcements bodhi was updated today to 7.0.1.
The slowdowns may have been due to that.

However I notice both you and Richard have large packet drops on
twelve99.net ip addresses. I don't know yet if that is an additional
problem or not.


>
> $ mtr bodhi.fedoraproject.org -r -G
> Start: 2023-01-17T15:14:31+0100
> HOST: MarkV   Loss%   Snt   Last   Avg  Best Wrst StDev
>1.|-- ptr-82pqtg1hqu6kedca1n3.1 90.0%106.0   6.0   6.0 6.0   0.0
>2.|-- ptr-377wgf58htvrzp7oh0ch. 20.0%10   13.7  15.3  12.7 20.1
> 2.7
>3.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>4.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>5.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>6.|-- 2001:730:2302::d52e:a209   0.0%10   16.3  18.0  13.1 24.9
> 3.5
>7.|-- 2001:730:2302:1::d52e:a20  0.0%10   17.9  17.4  13.4 20.4
> 2.7
>8.|-- prs-bb1-v6.ip.twelve99.ne 10.0%10   61.1  31.3  16.4 62.1
> 17.8
>9.|-- ash-bb2-v6.ip.twelve99.ne  0.0%10  105.2 108.7 104.0
> 118.7   5.0
>   10.|-- lax-b22-v6.ip.twelve99.ne 90.0%10  160.2 160.2 160.2
> 160.2   0.0
>   11.|-- a100-ic325183-las-b24.ip.  0.0%10  175.7 162.1 158.0
> 175.7   5.2
>   12.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   13.|-- 2620:107:4000:8006::1260.0%10  182.8 187.3 177.4
> 199.7   7.1
>   14.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   15.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   16.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   17.|-- 2620:107:4000:c5e0::f3fd:  0.0%10  188.3 188.2 182.0
> 192.4   2.8
>   18.|-- 2620:107:4000:a090::f000:  0.0%10  185.3 185.5 182.5
> 187.6   1.6
>   19.|-- 2620:107:4000:cfff::f200:  0.0%10  183.1 185.7 181.9
> 192.2   3.3
>   20.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   21.|-- ???   100.0100.0   0.0   0.0 0.0   0.0
>   22.|-- 2620:107:4000:4205:8000:0  0.0%10  182.8 188.9 182.0 220.5
> 11.5
>   23.|-- 2600:1f14:fad:5c02:7c8a:7  0.0%10  188.2 187.1 180.4
> 210.5   8.5
>
>
> $ traceroute bodhi.fedoraproject.org
> traceroute to bodhi.fedoraproject.org (8.43.85.67), 30 hops max, 60 byte
> packets
>   1  _gateway (192.168.0.1)  6.347 ms  10.770 ms  11.768 ms
>   2  d51A4C401.access.telenet.be (81.164.196.1)  20.244 ms  22.376 ms
> 22.311 ms
>   3  * * *
>   4  * * *
>   5  be-dgb01a-rb1-ae-19-0.aorta.net (213.46.162.9)  23.660 ms 23.584
> ms  27.996 ms
>   6  be-bru02a-ra1-vl-6.aorta.net (213.46.162.14)  29.026 ms 21.811 ms
> 18.822 ms
>   7  prs-bb1-link.ip.twelve99.net (62.115.116.238)  22.234 ms 19.546 ms
> 25.043 ms
>   8  ash-bb2-link.ip.twelve99.net (62.115.112.242)  116.324 ms 117.718
> ms  114.206 ms
>   9  ash-b2-link.ip.twelve99.net (62.115.123.125)  117.633 ms 117.595
> ms  117.555 ms
> 10  viawest-svc073699-ic361683.ip.twelve99-cust.net (213.248.67.199)
> 117.473 ms  117.424 ms  117.385 ms
> 11  be23.bbrt01.iad10.flexential.net (66.51.1.148)  129.400 ms 130.492
> ms  130.451 ms
> 12  be209.bbrt02.ral01.flexential.net (66.51.5.117)  120.744 ms 120.705
> ms  120.597 ms
> 13  * be32.crrt02.ral01.flexential.net (148.66.238.113)  119.944 ms
> 122.230 ms
> 14  128.136.224.140 (128.136.224.140)  112.075 ms  111.922 ms 110.807 ms
> 15  8.43.84.1 (8.43.84.1)  176.779 ms  203.379 ms  205.480 ms
> 16  8.43.84.3 (8.43.84.3)  122.495 ms  120.608 ms  122.398 ms
> 17  8.43.84.4 (8.43.84.4)  215.289 ms  215.232 ms  211.599 ms
> 18  ip-8-43-86-126.foo.bar (8.43.86.126)  124.226 ms  126.584 ms 142.354 ms
> 19  proxy14.fedoraproject.org (8.43.85.67)  134.550 ms !X  116.964 ms
> !X  121.806 ms !X
>
>
> --
> 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:
> 

Re: Bodhi slow with 504 gateway timeouts

[Arthur Bols]

On 17/01/2023 14:57, Stephen Smoogen wrote:

So bodhi and pagure are at different datacenters with hopefully different
network paths. Could people do some mtr or traceroutes from their locations
so we can see if this can be ironed out. Currently the limited tools we
have in Fedora Infra for checking this all show 'green' so the
'interconnects' between the services are working.

Fedora infra is usually very slow for me, but Bodhi seemed much slower 
than usual (taking a full minute to load).


After being really slow, I had a bunch of 503's (not 504) for a while, 
but now it seems to work fine:

- /releases takes 10 seconds (and had a 500 error once)
- /updates seems fast with 2.2 seconds


$ mtr bodhi.fedoraproject.org -r -G
Start: 2023-01-17T15:14:31+0100
HOST: MarkV   Loss%   Snt   Last   Avg  Best Wrst StDev
  1.|-- ptr-82pqtg1hqu6kedca1n3.1 90.0%    10    6.0   6.0   6.0 6.0   0.0
  2.|-- ptr-377wgf58htvrzp7oh0ch. 20.0%    10   13.7  15.3  12.7 20.1   2.7
  3.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
  4.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
  5.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
  6.|-- 2001:730:2302::d52e:a209   0.0%    10   16.3  18.0  13.1 24.9   3.5
  7.|-- 2001:730:2302:1::d52e:a20  0.0%    10   17.9  17.4  13.4 20.4   2.7
  8.|-- prs-bb1-v6.ip.twelve99.ne 10.0%    10   61.1  31.3  16.4 62.1  17.8
  9.|-- ash-bb2-v6.ip.twelve99.ne  0.0%    10  105.2 108.7 104.0 
118.7   5.0
 10.|-- lax-b22-v6.ip.twelve99.ne 90.0%    10  160.2 160.2 160.2 
160.2   0.0
 11.|-- a100-ic325183-las-b24.ip.  0.0%    10  175.7 162.1 158.0 
175.7   5.2

 12.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 13.|-- 2620:107:4000:8006::126    0.0%    10  182.8 187.3 177.4 
199.7   7.1

 14.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 15.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 16.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 17.|-- 2620:107:4000:c5e0::f3fd:  0.0%    10  188.3 188.2 182.0 
192.4   2.8
 18.|-- 2620:107:4000:a090::f000:  0.0%    10  185.3 185.5 182.5 
187.6   1.6
 19.|-- 2620:107:4000:cfff::f200:  0.0%    10  183.1 185.7 181.9 
192.2   3.3

 20.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 21.|-- ???   100.0    10    0.0   0.0   0.0 0.0   0.0
 22.|-- 2620:107:4000:4205:8000:0  0.0%    10  182.8 188.9 182.0 220.5  
11.5
 23.|-- 2600:1f14:fad:5c02:7c8a:7  0.0%    10  188.2 187.1 180.4 
210.5   8.5



$ traceroute bodhi.fedoraproject.org
traceroute to bodhi.fedoraproject.org (8.43.85.67), 30 hops max, 60 byte 
packets

 1  _gateway (192.168.0.1)  6.347 ms  10.770 ms  11.768 ms
 2  d51A4C401.access.telenet.be (81.164.196.1)  20.244 ms  22.376 ms  
22.311 ms

 3  * * *
 4  * * *
 5  be-dgb01a-rb1-ae-19-0.aorta.net (213.46.162.9)  23.660 ms 23.584 
ms  27.996 ms
 6  be-bru02a-ra1-vl-6.aorta.net (213.46.162.14)  29.026 ms 21.811 ms  
18.822 ms
 7  prs-bb1-link.ip.twelve99.net (62.115.116.238)  22.234 ms 19.546 ms  
25.043 ms
 8  ash-bb2-link.ip.twelve99.net (62.115.112.242)  116.324 ms 117.718 
ms  114.206 ms
 9  ash-b2-link.ip.twelve99.net (62.115.123.125)  117.633 ms 117.595 
ms  117.555 ms
10  viawest-svc073699-ic361683.ip.twelve99-cust.net (213.248.67.199)  
117.473 ms  117.424 ms  117.385 ms
11  be23.bbrt01.iad10.flexential.net (66.51.1.148)  129.400 ms 130.492 
ms  130.451 ms
12  be209.bbrt02.ral01.flexential.net (66.51.5.117)  120.744 ms 120.705 
ms  120.597 ms
13  * be32.crrt02.ral01.flexential.net (148.66.238.113)  119.944 ms  
122.230 ms

14  128.136.224.140 (128.136.224.140)  112.075 ms  111.922 ms 110.807 ms
15  8.43.84.1 (8.43.84.1)  176.779 ms  203.379 ms  205.480 ms
16  8.43.84.3 (8.43.84.3)  122.495 ms  120.608 ms  122.398 ms
17  8.43.84.4 (8.43.84.4)  215.289 ms  215.232 ms  211.599 ms
18  ip-8-43-86-126.foo.bar (8.43.86.126)  124.226 ms  126.584 ms 142.354 ms
19  proxy14.fedoraproject.org (8.43.85.67)  134.550 ms !X  116.964 ms 
!X  121.806 ms !X



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

Re: LLVM support for '-Wl,-WX'

[Michael Cronenworth]

On 1/16/23 11:30 PM, Tom Stellard wrote:

-WX means treat warnings as errors.  It's possible the configure
check is failing for other reasons.  Is that the first check run
with -target aarch64-windows?  Do you have the full config.log? 


Yes. I do not have the full log. This is from a Koji ARM builder.

Here's the parent Koji task:
https://koji.fedoraproject.org/koji/taskinfo?taskID=96232039
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bodhi slow with 504 gateway timeouts

[Richard Shaw]

On Tue, Jan 17, 2023 at 7:58 AM Stephen Smoogen  wrote:

>
> On Tue, 17 Jan 2023 at 08:55, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Tue, Jan 17, 2023 at 07:49:48AM -0600, Richard Shaw wrote:
>> > On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar  wrote:
>> >
>> > > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a):
>> > > > Is anyone but me experiencing this? I want to know before I call C
>> Spire.
>> > > >
>> > > Since yesterday I randomly experience long delays between sending a
>> query
>> > > and
>> > > receiving the response. However, no HTTP errors.
>> > >
>> >
>> > I only got the timeout once, but it's been very slow and not properly
>> > loading completely. I'm trying bodhi command line for an update and
>> having
>> > similar issues but I think my update did finally get created though.
>> >
>> > One of the attempts from the command line it spit back HTML saying
>> > "Application is not available".
>>
>> Bodhi is slow for me. Some pages loaded slowly and without icons and
>> stuff. But
>> I also had timeouts on pagure.io today, so I was suspecting some network
>> issue.
>>
>>
> So bodhi and pagure are at different datacenters with hopefully different
> network paths. Could people do some mtr or traceroutes from their locations
> so we can see if this can be ironed out. Currently the limited tools we
> have in Fedora Infra for checking this all show 'green' so the
> 'interconnects' between the services are working.
>

Does this help?

Host  Loss%   Snt
Last   Avg  Best  Wrst StDev
 1. _gateway1.5%   134
 0.3   0.4   0.2   3.5   0.3
 2. 136.239.67.3.static.cspire.com  0.0%   134
 7.0   8.7   6.3  58.1   7.2
 3. et-1-1-5.SKVLAR01.cspire.net0.0%   134
 7.7   9.4   6.8  34.7   3.9
 4. 198.28.137.84   0.0%   134
10.2  10.7   9.5  11.9   0.4
 5. et-0-1-1.jcsncr01.cspire.net0.0%   134
11.0  11.7   9.9  47.2   4.3
 6. hu0-0-0-0.rcr51.jan01.atlas.cogentco.com0.0%   134
10.4  10.5   9.5  11.6   0.3
 7. be3520.rcr21.msy01.atlas.cogentco.com   0.0%   134
14.8  14.9  14.0  18.6   0.5
 8. be3302.ccr42.iah01.atlas.cogentco.com   0.0%   134
21.5  23.7  20.7  76.2   8.1
 9. be2418.rcr51.b023723-0.iah01.atlas.cogentco.com 0.0%   134
23.0  23.0  21.9  25.2   0.4
10. telia.iah01.atlas.cogentco.com  6.0%   134
49.9  23.2  21.0  51.8   5.0
11. dls-b24-link.ip.twelve99.net0.0%   134
31.6  31.5  30.6  32.4   0.3
12. dls-bb2-link.ip.twelve99.net   78.2%   134
29.6  29.8  28.7  30.5   0.4
13. (waiting for reply)
14. viawest-svc067149-ic350576.ip.twelve99-cust.net 0.0%   134
32.3  32.2  31.4  37.5   0.5
15. be23.bbrt01.dal01.flexential.net0.0%   134
49.1  49.1  48.2  49.9   0.2
16. be136.bbrt01.atl10.flexential.net   0.0%   134
49.2  49.3  48.4  55.5   0.6
17. be10.bbrt02.atl10.flexential.net0.0%   134
49.4  49.8  48.5  50.6   0.4
18. be166.bbrt01.atl03.flexential.net   0.0%   134
49.2  49.4  48.4  57.9   0.8
19. be170.bbrt02.clt01.flexential.net   0.0%   134
49.6  49.7  48.8  50.7   0.2
20. be10.bbrt01.clt01.flexential.net0.0%   133
49.6  49.8  48.8  56.3   0.6
21. be184.bbrt01.ral01.flexential.net   0.0%   133
49.3  49.4  48.6  50.3   0.3
22. be31.crrt01.ral01.flexential.net0.0%   133
49.4  49.7  48.7  51.1   0.4
23. 128.136.224.140 0.0%   133
47.1  53.9  46.4  89.2  10.5
24. 8.43.84.1   0.0%   133
53.0  73.2  53.0 172.1  18.1
25. 8.43.84.3   0.8%   133
47.8  53.2  46.8  91.7  10.3
26. 8.43.84.4   1.5%   133
69.4  77.6  53.3 176.2  25.6
27. ip-8-43-86-126.foo.bar  0.8%   133
50.7  71.7  48.6 226.7  36.6
28. proxy14.fedoraproject.org   0.8%   133
48.2  53.1  47.4  81.8   8.6
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Bodhi slow with 504 gateway timeouts

[Stephen Smoogen]

On Tue, 17 Jan 2023 at 08:55, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Tue, Jan 17, 2023 at 07:49:48AM -0600, Richard Shaw wrote:
> > On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar  wrote:
> >
> > > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a):
> > > > Is anyone but me experiencing this? I want to know before I call C
> Spire.
> > > >
> > > Since yesterday I randomly experience long delays between sending a
> query
> > > and
> > > receiving the response. However, no HTTP errors.
> > >
> >
> > I only got the timeout once, but it's been very slow and not properly
> > loading completely. I'm trying bodhi command line for an update and
> having
> > similar issues but I think my update did finally get created though.
> >
> > One of the attempts from the command line it spit back HTML saying
> > "Application is not available".
>
> Bodhi is slow for me. Some pages loaded slowly and without icons and
> stuff. But
> I also had timeouts on pagure.io today, so I was suspecting some network
> issue.
>
>
So bodhi and pagure are at different datacenters with hopefully different
network paths. Could people do some mtr or traceroutes from their locations
so we can see if this can be ironed out. Currently the limited tools we
have in Fedora Infra for checking this all show 'green' so the
'interconnects' between the services are working.


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

Re: Bodhi slow with 504 gateway timeouts

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 17, 2023 at 07:49:48AM -0600, Richard Shaw wrote:
> On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar  wrote:
> 
> > V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a):
> > > Is anyone but me experiencing this? I want to know before I call C Spire.
> > >
> > Since yesterday I randomly experience long delays between sending a query
> > and
> > receiving the response. However, no HTTP errors.
> >
> 
> I only got the timeout once, but it's been very slow and not properly
> loading completely. I'm trying bodhi command line for an update and having
> similar issues but I think my update did finally get created though.
> 
> One of the attempts from the command line it spit back HTML saying
> "Application is not available".

Bodhi is slow for me. Some pages loaded slowly and without icons and stuff. But
I also had timeouts on pagure.io today, so I was suspecting some network issue.

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

Re: Bodhi slow with 504 gateway timeouts

[Richard Shaw]

On Tue, Jan 17, 2023 at 7:42 AM Petr Pisar  wrote:

> V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a):
> > Is anyone but me experiencing this? I want to know before I call C Spire.
> >
> Since yesterday I randomly experience long delays between sending a query
> and
> receiving the response. However, no HTTP errors.
>

I only got the timeout once, but it's been very slow and not properly
loading completely. I'm trying bodhi command line for an update and having
similar issues but I think my update did finally get created though.

One of the attempts from the command line it spit back HTML saying
"Application is not available".

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

Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts

[Michal Konecny]

Hi everybody,

TL;DR; Check if you have correct e-mail in Red Hat Bugzilla Mail field 
in Fedora Accounts [0]. Empty mail is also OK.


the Red Hat Bugzilla Email field in Fedora Accounts [0] was till now 
ignored by most of the apps.


This was changed now with the latest update to toddlers [1], which 
contains most of the syncing scripts that are run automatically in 
Fedora Infra including distgit_bugzilla_sync [2], packager_bugzilla_sync 
[3] and packagers_without_bugzilla [4] scripts. All these scripts are 
using shared methods for working with Fedora Accounts system.


With the addition of scm_request_processor [5] there was a small change 
in how the Fedora Accounts mails are handled in regard to Red Hat 
Bugzilla mail. This change caused it to first look for Red Hat Bugzilla 
Mail and then look at the personnel e-mail associated with the account 
if Bugzilla mail is not set.


This unfortunately caused issues for some users that had Red Hat 
Bugzilla Mail field set incorrectly. I was the one who did the change 
and I actually forgot about it, because it happened at the beginning of 
scm_request_processor development cycle and I didn't know it could have 
that large impact. So I apologize for any issue this could have caused 
for you.


If you are one of the users, who were impacted by this change, you can 
fix it by adding correct Red Hat Bugzilla mail to your Fedora Account. 
You can do this in Settings->Emails in Fedora Accounts page [0].


We will fix the message that is being sent to packagers without Bugzilla 
e-mail to correspond with this change.


On behalf of CPE Team,
Michal

[0] - https://accounts.fedoraproject.org
[1] - https://pagure.io/fedora-infra/toddlers
[2] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/distgit_bugzilla_sync.py
[3] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packager_bugzilla_sync.py
[4] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packagers_without_bugzilla.py
[5] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/scm_request_processor.py

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

Red Hat Bugzilla mail FAS field is now handled correctly by Bugzilla sync scripts

[Michal Konecny]

Hi everybody,

TL;DR; Check if you have correct e-mail in Red Hat Bugzilla Mail field 
in Fedora Accounts [0]. Empty mail is also OK.


the Red Hat Bugzilla Email field in Fedora Accounts [0] was till now 
ignored by most of the apps.


This was changed now with the latest update to toddlers [1], which 
contains most of the syncing scripts that are run automatically in 
Fedora Infra including distgit_bugzilla_sync [2], packager_bugzilla_sync 
[3] and packagers_without_bugzilla [4] scripts. All these scripts are 
using shared methods for working with Fedora Accounts system.


With the addition of scm_request_processor [5] there was a small change 
in how the Fedora Accounts mails are handled in regard to Red Hat 
Bugzilla mail. This change caused it to first look for Red Hat Bugzilla 
Mail and then look at the personnel e-mail associated with the account 
if Bugzilla mail is not set.


This unfortunately caused issues for some users that had Red Hat 
Bugzilla Mail field set incorrectly. I was the one who did the change 
and I actually forgot about it, because it happened at the beginning of 
scm_request_processor development cycle and I didn't know it could have 
that large impact. So I apologize for any issue this could have caused 
for you.


If you are one of the users, who were impacted by this change, you can 
fix it by adding correct Red Hat Bugzilla mail to your Fedora Account. 
You can do this in Settings->Emails in Fedora Accounts page [0].


We will fix the message that is being sent to packagers without Bugzilla 
e-mail to correspond with this change.


On behalf of CPE Team,
Michal

[0] - https://accounts.fedoraproject.org
[1] - https://pagure.io/fedora-infra/toddlers
[2] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/distgit_bugzilla_sync.py
[3] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packager_bugzilla_sync.py
[4] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/packagers_without_bugzilla.py
[5] - 
https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/scm_request_processor.py

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

Re: Bodhi slow with 504 gateway timeouts

[Petr Pisar]

V Tue, Jan 17, 2023 at 07:28:32AM -0600, Richard Shaw napsal(a):
> Is anyone but me experiencing this? I want to know before I call C Spire.
> 
Since yesterday I randomly experience long delays between sending a query and
receiving the response. However, no HTTP errors.

-- Petr


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

Bodhi slow with 504 gateway timeouts

[Richard Shaw]

Is anyone but me experiencing this? I want to know before I call C Spire.

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

[Bug 2161639] Pregenerated File-RsyncP-0.76/FileList/configure is missing a source

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||CPAN 145945




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161639
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Bodhi 7.0.1 deployed to prod

[Mattia Verga via devel]

Hello folks,

I'd like to announce that Bodhi 7.0.1 has been deployed to production.
Apart from a webUI new look, due to the switch to fedora-bootstrap 2.x,
these are the main changes that may interest you:

- Bodhi client now autenticates using Kerberos by default and falls back
to browser-based OIDC mechanism. Also, Bodhi client will not show the
secret in terminal while typing the password when logging in via browser.

- Frozen releases updates will now be forced into testing before being
pushed to stable. Previously, when a release was frozen, an update which
was just submitted (pending), but had received enough votes to be pushed
directly to stable, was not pushed in testing nor stable. Now it will be
pushed to testing and remain there until the release is un-frozen.

- The new update form UI will now display a warning when a release is
approaching EOL. Also, a warning box will be showed in the update
details page to inform the user that the update will not be pushed out
to stable until the freeze is over.

You can find the full changelog at
https://fedora-infra.github.io/bodhi/7.0/user/release_notes.html (note
that the link at the bottom of Bodhi web pages is currently broken, as
it points to 6.x docs... )

Have a nice day
Mattia

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

Bodhi 7.0.1 deployed to prod

[Mattia Verga]

Hello folks,

I'd like to announce that Bodhi 7.0.1 has been deployed to production.
Apart from a webUI new look, due to the switch to fedora-bootstrap 2.x,
these are the main changes that may interest you:

- Bodhi client now autenticates using Kerberos by default and falls back
to browser-based OIDC mechanism. Also, Bodhi client will not show the
secret in terminal while typing the password when logging in via browser.

- Frozen releases updates will now be forced into testing before being
pushed to stable. Previously, when a release was frozen, an update which
was just submitted (pending), but had received enough votes to be pushed
directly to stable, was not pushed in testing nor stable. Now it will be
pushed to testing and remain there until the release is un-frozen.

- The new update form UI will now display a warning when a release is
approaching EOL. Also, a warning box will be showed in the update
details page to inform the user that the update will not be pushed out
to stable until the freeze is over.

You can find the full changelog at
https://fedora-infra.github.io/bodhi/7.0/user/release_notes.html (note
that the link at the bottom of Bodhi web pages is currently broken, as
it points to 6.x docs... )

Have a nice day
Mattia

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

Re: -fno-omit-frame-pointer does not work as advertised

[Daan De Meyer via devel]

> What about the new SFrame unwind info?

We're closely following up on this new format and will compare it against frame 
pointers if a patch introducing a kernel unwinder for sframe is proposed and 
likely to be merged. It's still very early days for SFrame though so we'll have 
to see what happens first.

Cheers,

Daan


From: Demi Marie Obenour 
Sent: 16 January 2023 20:33
To: devel@lists.fedoraproject.org
Subject: Re: -fno-omit-frame-pointer does not work as advertised

!---|
  This Message Is From an External Sender

|---!

On 1/16/23 08:40, Florian Weimer wrote:
> * Daniel Alley:
>
>> What has happened is that because -O2 optimized away all of the stack
>> access for the function, so it uses no space on the stack, so there is
>> no stack frame separate from the caller's.
>>
>> It is unlikely that the critical bottleneck of any applications will
>> be on such a function.
>
> Is it?  Plenty of math functions and cryptographic primitives are like
> that.  Anything that makes an inline system call, too.  Maybe you can
> infer from the caller's caller where the time is spent in these cases.
> People certainly seem to be concerned about this gap because they
> included -mno-omit-leaf-frame-pointer in the build flags.
>
> This is something that an upstream/ABI discussion could cover, with some
> sort of protocol that ensures the toolchain produces something the
> intended tools can consume.  For example, there could be a rule that
> only frames up to a certain size may lack a frame pointer, so that a
> fixed-size copy from the top of the stack can recover the caller address
> by looking at the DWARF unwinding data (out of context, for that frame
> alone).  Or it could be spelt out that LBR has to be used to recover the
> calling frame.  This isn't really something that Fedora can implement in
> a downstream change, though.
What about the new SFrame unwind info?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2161639] New: Pregenerated File-RsyncP-0.76/FileList/configure is missing a source

[bugzilla]

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

Bug ID: 2161639
   Summary: Pregenerated File-RsyncP-0.76/FileList/configure is
missing a source
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-File-RsyncP
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: imlinux+fed...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
   Link ID: Red Hat Bugzilla 199647
Classification: Fedora



perl-File-RsyncP-0.76-10.fc38 source package delivers
File-RsyncP-0.76/FileList/configure file which itsels was generated with
Autoconf, but the original source for Autoconf tool (configure.in according to
File-RsyncP-0.76/FileList/Makefile.PL is missing from the source archive and
thus from the source package.

While the file is licensed as FSFULL which does not require distributing
sources, it is deemed to be against Fedora spirit (and Packaging guidelines?)
.

We should either reimplement configure.in or remove this package from a
distribution.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161639
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Fabio Valentini]

On Tue, Jan 17, 2023 at 1:39 PM Jakub Jelinek  wrote:>
> On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> > Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> > being voted about by FESCo.
> >
> > Apparently, the following packages now don't install:
>
> There is a mass rebuild tomorrow.  The Ada soname changes every year
> and we've never rebuilt Ada packages separately for that, just during the
> mass rebuild.

"Because we've always done it like that" is usually not a good
argument for something bad to remain the way it is -
(especially since this change hasn't even formally been approved by FESCo).

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

Re: GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Jakub Jelinek]

On Tue, Jan 17, 2023 at 01:24:45PM +0100, Miro Hrončok wrote:
> Hello. GCC was updated to 13 in rawhide while the Fedora change was still
> being voted about by FESCo.
> 
> Apparently, the following packages now don't install:

There is a mass rebuild tomorrow.  The Ada soname changes every year
and we've never rebuilt Ada packages separately for that, just during the
mass rebuild.

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

[Bug 2160887] perl-CPAN-Uploader-0.103018 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-CPAN-Uploader-0.103018
   ||-1.fc38
 Status|ASSIGNED|CLOSED
Last Closed||2023-01-17 12:31:23




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160887
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

GCC 13 broke 50 packages requiring libgnat-12.so() and libgnarl-12.so()

[Miro Hrončok]

Hello. GCC was updated to 13 in rawhide while the Fedora change was still being 
voted about by FESCo.


Apparently, the following packages now don't install:

$ repoquery -q --repo=rawhide --whatrequires 'libgnat-12.so()(64bit)' 
--whatrequires 'libgnarl-12.so()(64bit)'

GtkAda3-0:2020-7.fc37.x86_64
GtkAda3-devel-0:2020-7.fc37.x86_64
GtkAda3-gl-0:2020-7.fc37.x86_64
PragmARC-0:20130728-27.fc37.x86_64
ahven-0:2.8-4.fc37.x86_64
anet-0:0.4.1-12.fc37.x86_64
aunit-0:2020-6.fc37.x86_64
aws-0:2020-8.fc37.x86_64
aws-devel-0:2020-8.fc37.x86_64
aws-tools-0:2020-8.fc37.x86_64
florist-2:22.0.0-2.fc38.x86_64
ghdl-0:0.38~dev-16.20201208git83dfd49.fc37.x86_64
ghdl-llvm-0:0.38~dev-16.20201208git83dfd49.fc37.x86_64
ghdl-mcode-0:0.38~dev-16.20201208git83dfd49.fc37.x86_64
gnatcoll-core-2:21.0.0-8.fc38.x86_64
gnatcoll-db-devel-2:21.0.0-5.fc37.x86_64
gnatcoll-gmp-2:21.0.0-9.fc37.x86_64
gnatcoll-iconv-2:21.0.0-9.fc37.x86_64
gnatcoll-postgres-2:21.0.0-5.fc37.x86_64
gnatcoll-readline-2:21.0.0-9.fc37.x86_64
gnatcoll-sql-2:21.0.0-5.fc37.x86_64
gnatcoll-sqlite-2:21.0.0-5.fc37.x86_64
gnatcoll-syslog-2:21.0.0-9.fc37.x86_64
gnatcoll-xref-2:21.0.0-5.fc37.x86_64
matreshka-0:20.1-11.fc37.x86_64
matreshka-amf-0:20.1-11.fc37.x86_64
matreshka-amf-dd-0:20.1-11.fc37.x86_64
matreshka-amf-mofext-0:20.1-11.fc37.x86_64
matreshka-amf-ocl-0:20.1-11.fc37.x86_64
matreshka-amf-uml-0:20.1-11.fc37.x86_64
matreshka-amf-utp-0:20.1-11.fc37.x86_64
matreshka-fastcgi-0:20.1-11.fc37.x86_64
matreshka-servlet-lib-0:20.1-11.fc37.x86_64
matreshka-soap-core-0:20.1-11.fc37.x86_64
matreshka-soap-wsse-0:20.1-11.fc37.x86_64
matreshka-spikedog-api-lib-0:20.1-11.fc37.x86_64
matreshka-spikedog-awsd-0:20.1-11.fc37.x86_64
matreshka-spikedog-core-lib-0:20.1-11.fc37.x86_64
matreshka-sql-core-0:20.1-11.fc37.x86_64
matreshka-sql-mysql-0:20.1-11.fc37.x86_64
matreshka-sql-postgresql-0:20.1-11.fc37.x86_64
matreshka-sql-sqlite-0:20.1-11.fc37.x86_64
matreshka-xml-0:20.1-11.fc37.x86_64
mine_detector-0:6.0-43.fc37.x86_64
plplot-ada-0:5.15.0-47.fc38.x86_64
templates_parser-0:11.8.0-31.fc37.x86_64
templates_parser-tools-0:11.8.0-31.fc37.x86_64
xmlada-0:2020-8.fc37.x86_64
zeromq-ada-0:4.1.5-8.git.fc37.x86_64
zlib-ada-0:1.4-0.31.20120830CVS.fc37.x86_64

Please use side tags for updates that bump soname version.

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

Re: F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)

[Zdenek Dohnal]

Hi Robert,

On 1/13/23 15:12, Robert Marcano via devel wrote:
Nothing against driverless printing, this is something I really like, 
bit I think all the move to HTTP is ignoring the feature that is being 
removed, and that I have an use for. There is not possible to have a 
printer connected to a computer that can't be restricted by CUPS to be 
used by only a few authorized users. The admin can implement CUPS 
authentication but an ipp://localhost:6 open port entirely open to 
anyone on the local machine to submit print jobs directly bypassing CUPS.


Well in a matter of speaking this is doable even without IPP-USB 
advertised device. Every application can just send data to printer's 
port and IP or get USB interface handler and talk with the device via 
USB. Even an application which implements IPP client can omit CUPS and 
talk with IPP printer directly. In cases where application generates a 
printer ready file (f.e. in PCL format) which have all user's option 
applied already is desired to bypass CUPS and talk with the printer - 
I've heard there are such applications already bypassing CUPS, because 
they want to pass such a file.


So it is not something uncommon in my opinion.



There are many other reasons to disallow direct access to the printer 
application, like wanting to do printing accounting with CUPS, for 
example.
If an application uses CUPS API, the communication will go via CUPS 
daemon (CUPS Local daemon in CUPS 3.x) which will do a printing 
accounting (in CUPS 3.x it will be in CUPS sharing daemon). We can't 
forbid the application to bypass CUPS if it is its developer's will, as 
we can't now.


Unless every printer application support some kind of authentication 
mechanism over their HTTP server, controlling direct access to the 
printers is not possible. Do ipp-usb support at least basic 
authentication so a permanent queue could be setup with these 
credentials?


IPP-USB currently does not provide authentication functionality AFAIK 
and how it looks from the code, but I've asked upstream. According 
IPP-USB man page you can turn off mDNS advertising to don't share the 
port existence on your localhost, or probably create a firewall rule 
Chris mentioned. The ticket is here 
https://github.com/OpenPrinting/ipp-usb/issues/61




Note: I really wish CUPS supported some kind of IPP over Unix domain 
sockets so file system restrictions could be used to control access to 
locally installed printer applications, but the last time I mentioned 
that on a CUPS issue, sadly it was plainly rejected.


Do you have a link to the ticket? AFAIK Unix domain socket is one of the 
features which is planned for CUPS 3.x, but it might not be the one you 
mean.



Zdenek



[https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_install_a_permanent_print_queue 


here] is the manual. However if mDNS is enabled, the virtual device
shared by `ipp-usb` can be automatically picked up by other services
(as `cups` or `sane-airscan`), so no further configuration is required
to get the device installed. The feature is called ''temporary queue''
in CUPS and it is supported in applications using the up-to-date CUPS
API or toolkits using up-to-date CUPS API - f.e. GTK3+ based
applications, Libreoffice and Firefox. The fax functionality is
available at URI `ipp://localhost:6/ipp/faxout`, but the automatic
installation doesn't work for it and it has to be installed manually.

As mentioned above, the `ipp-usb` daemon claims the USB interface of
the device which supports IPP over USB standard. This behavior
conflicts with the previous driver approach, where the discovery
mechanism only scans USB ports for available devices, but doesn't try
to claim the USB interface, which is unavailable because `ipp-usb` has
claimed it already. The result is the device can be discovered by
classic driver tools, but it won't work once user wants to print, scan
or fax. In such cases user intervention is needed, where user has to
make a decision whether to use driverless USB support or classic
support with drivers. The way how to do it will be explained later in
this proposal.

Based on the current `ipp-usb` design the following specific setups
aren't expected to work, because they are not common with USB device
usage:

* combining driverless and classic driver's support doesn't work on
the same device - driverless or classic driver has to be used for
whole device's functionality.
* if user has several devices of the same model, all of them has to be
supported by a single solution - driverless or classic driver -
because quirks and SANE backends use model name, vendor ID or product
ID, which are the same for all devices of the same model, for denying
the support.
* if scanner backend does not support disabling support for a specific
device (f.e. `hpaio`, `pixma` are such backends), the whole backend
can be disabled to prevent discovering broken scanners - it results in
the scanner support provided by the 

[Bug 2160887] perl-CPAN-Uploader-0.103018 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value
 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160887
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2160856] perl-Redis-2.000 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Redis-2.000-1.fc38
Last Closed||2023-01-17 12:12:52




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2160856
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2161364] perl-Module-ExtractUse-0.345 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Module-ExtractUse-0.34
   ||5-1.fc38
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2023-01-17 12:03:57



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-a7f3d9599d has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2161364] perl-Module-ExtractUse-0.345 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-a7f3d9599d has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-a7f3d9599d


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

golang-race package relevance

[Alejandro Saez Morollon]

Hi everyone!

Currently, golang ships the golang-race package, but this process is
going to get trickier with Go 1.20 due to this change:

The directory $GOROOT/pkg no longer stores pre-compiled package
archives for the standard library: go install no longer writes them,
the go build no longer checks for them, and the Go distribution no
longer ships them. Instead, packages in the standard library are built
as needed and cached in the build cache, just like packages outside
GOROOT. This change reduces the size of the Go distribution and also
avoids C toolchain skew for packages that use cgo.

Source: https://tip.golang.org/doc/go1.20 Under Tools -> Go command

It uses the cache, which is a little tricky to retrieve information from.

I didn't find anything that requires golang-race, and I'm not sure why
someone would want to install the package, so I'm curious if the
effort of fixing the issue is worth the time because right now, I
can't build Go1.20rc3 unless I remove the package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: bodhi upgraded to 7.0.1

[Miro Hrončok]

On 17. 01. 23 1:07, Kevin Fenzi wrote:

Hey folks, just a heads up that bodhi has been updated to 7.0.1 now.

https://bodhi.fedoraproject.org

See:
https://github.com/fedora-infra/bodhi/releases
for a full list of bugs fixed/enhancements.

Note that this adds the concept of 'frozen' releases, which will:
* show a warning / note for those releases to explain that it's frozen
   and updates will stay in testing unless cleared by QA as fixing a
   blocker/exception.
* allow releng to use the same automated push process, meaning that
   updates pushes will stay at the same time (00:14UTC) as always.

Along with many other bugfixes and enhancements.

Thanks to everyone who worked on it!


Is it possible that bodhi no longer automatically recognizes the changelog of 
Rawhide updates?


See before the update:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-9090058f62

And after:

https://bodhi.fedoraproject.org/updates/FEDORA-2023-df57e062f6

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

Re: Use cases for 'fedpkg scratch-build'

[Vít Ondruch]

Dne 16. 01. 23 v 21:59 Otto Liljalaakso napsal(a):

Vít Ondruch kirjoitti 16.1.2023 klo 16.50:

I don't oppose to change of the defaults.

However, I am also using `fedpkg scratch-build --srpm some.rpm`. So 
how would the proposed change influence this command?


I do not intend to change that behavior in any way.



But you proposed to basically drop the `--srpm` option. So maybe this 
should work: `fedpkg scratch-build some.rpm` instead. Not sure. I have 
not thought about this into details especially in relation to plain 
`fedpkg build`.



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

Re: FESCo wants to know what you use i686 packages for

[Steve Cossette]

Same here. To be honest, most older games still use 32-bit binaries (even
some more recent ones). That's one of the reasons why Windows will prolly
never remove WoW64. Or at least for an extremely long time still.

Le lun. 16 janv. 2023, 18 h 13, Arthur Bols  a écrit :

> On 17/03/2022 10:49, Matyáš Kroupa wrote:
> > Hi,
> > I use wine and steam (and some libraries which are required to run them)
> with total of 254 i686 packages.
> > Matyáš
> I'm also using them for wine and steam.
>
> --
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg local - do not clean build directory

[Sérgio Basto]

On Tue, 2023-01-17 at 18:54 +0900, Mamoru TASAKA wrote:
> Petr Pisar wrote on 2023/01/17 18:29:
> > V Tue, Jan 17, 2023 at 10:11:48AM +0100, Dan Horák napsal(a):
> > > On Mon, 16 Jan 2023 21:21:39 -0700
> > > Orion Poplawski  wrote:
> > > 
> > > > How the #$@! do I get fedpkg local to not cleanup the local
> > > > build
> > > > directory after a successful build?  This is the most annoying
> > > > change to
> > > > come around in a long time IMHO.
> > > 
> > > hmm, it doesn't clean the build directory here (fedpkg-1.43-
> > > 2.fc36)
> > > 
> > rpmbuild does that:
> > 
> > Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.oNsT7U
>   
> >  From rpm-4.18.0-beta1 changelog:
> > 
> > commit 6f945960affc7a2a2b49337458457273d8a4faf5
> > Author: Panu Matilainen 
> > Date:   Wed May 25 15:08:30 2022 +0300
> > 
> >  Remove build tree automatically on successfull binary package
> > creation
> > 
> > 
> > It think "fedpkg local" needs a new "--noclean" option.
> > 
> > -- Petr
> > 
> 
> Currently I do "$ fedpkg local -- --noclean" .
> 
> $ fedpkg local --help
> positional arguments:
>    extra_args    Custom arguments that are passed to the
> 'rpmbuild'. Use '--' to separate them from other arguments.
> 

in my notes I have: 

mock -r fedora-35-x86_64 --no-clean --rebuild mock-rpmfusion-free-
$VERSION-1.fc38.src.rpm --rpmbuild-opts=--noclean --no-cleanup-after


so I'd say 

fedpkg local -- --rpmbuild-opts=--noclean --no-cleanup-after

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

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

Re: Web Assembly on Fedora: interested in a Fedora SIG to work on this?

[Zuzana Svetlikova]

I opened an issue for a mailing list to be created in case someone wants to
follow/provide feedback.

https://pagure.io/fedora-infrastructure/issue/11087

Zuzka

On Wed, Jan 11, 2023 at 4:34 PM Michael Dawson  wrote:

> It's the new year and we are going to get things going.
>
> Zuzana is going to set up a Wiki page where we can track info and we are
> going to setup an initial meeting to get together to discuss how  we get
> started.
>
> The proposed initial agenda is:
>
> - Communication channels
>   - Mailing list
>   - Slack/IRC/etc ?
>   - Pagure/Wiki
> - Capturing existing work/initiatives
> - Known Gaps
>
> And the proposed time is 23 Jan at 4pm UTC (9am Pacific, 11am ET,  5pm
> CET). We picked 11 ET as an attempt to span the timezones from Europe and
> NA.
>
> Let us know if that works for you and what timezone you are in so that if
> we need to choose a different time we know what timezones we should try to
> allow for.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Schedule for Tuesday's FESCo Meeting (2023-01-17)

[Zbigniew Jędrzejewski-Szmek]

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

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

or run:
  date -d '2023-01-17 17:00 UTC'


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

= Discussed and Voted in the Ticket =

#2927 Change: X Server Prohibits Byte-swapped Clients
https://pagure.io/fesco/issue/2927
APPROVED (+6,0,-0)

#2926 Change: Unified Kernel Support Phase 1
https://pagure.io/fesco/issue/2926
APPROVED (+5,0,-0)

#2925 Change: Xfce 4.18
https://pagure.io/fesco/issue/2925
APPROVED (+6,0,-0)

#2924 Change: Pyramid 2.0
https://pagure.io/fesco/issue/2924
APPROVED (+6,0,-0)

#2922 Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922
APPROVED (+5,0,-0)


= Followups =


= New business =

#2930 Change: Rpmautospec by Default
https://pagure.io/fesco/issue/2930

#2928 Change: Shorter Shutdown Timer
https://pagure.io/fesco/issue/2928


= Open Floor = 

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

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20230117.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230116.n.1
NEW: Fedora-Rawhide-20230117.n.0

= SUMMARY =
Added images:4
Dropped images:  2
Added packages:  1
Dropped packages:6
Upgraded packages:   38
Downgraded packages: 0

Size of added packages:  340.74 KiB
Size of dropped packages:8.39 MiB
Size of upgraded packages:   1.46 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-Rawhide-20230117.n.0.s390x.qcow2
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20230117.n.0.iso
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230117.n.0.ppc64le.qcow2
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20230117.n.0.ppc64le.raw.xz

= DROPPED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230116.n.1.iso
Image: Server_KVM qcow2 ppc64le
Path: Server/ppc64le/images/Fedora-Server-KVM-Rawhide-20230116.n.1.ppc64le.qcow2

= ADDED PACKAGES =
Package: rapidfuzz-cpp-1.10.4-1.fc38
Summary: A fast string matching header-only library for C++
RPMs:rapidfuzz-cpp-devel
Size:340.74 KiB


= DROPPED PACKAGES =
Package: golang-github-sqshq-sampler-1.1.0-11.fc37
Summary: Tool for shell commands execution, visualization and alerting
RPMs:golang-github-sqshq-sampler golang-github-sqshq-sampler-devel
Size:4.72 MiB

Package: libpmemobj-cpp-1.13-4.fc37
Summary: C++ bindings for libpmemobj
RPMs:libpmemobj++-devel libpmemobj++-doc
Size:1.98 MiB

Package: pmdk-convert-1.7-8.fc36
Summary: Conversion tool for PMDK pools
RPMs:pmdk-convert
Size:249.57 KiB

Package: pmemkv-1.5.0-4.fc37
Summary: Key/Value Datastore for Persistent Memory
RPMs:pmemkv pmemkv-devel
Size:233.71 KiB

Package: scim-anthy-1.2.7-31.fc37
Summary: SCIM IMEngine for anthy for Japanese input
RPMs:scim-anthy
Size:1.05 MiB

Package: vmemcache-0.8.1-5.fc37
Summary: Buffer-based LRU cache
RPMs:vmemcache vmemcache-devel
Size:165.09 KiB


= UPGRADED PACKAGES =
Package:  apr-1.7.0-20.fc38
Old package:  apr-1.7.0-19.fc38
Summary:  Apache Portable Runtime library
RPMs: apr apr-devel
Size: 1.78 MiB
Size change:  13.41 KiB
Changelog:
  * Mon Jan 16 2023 Florian Weimer  - 1.7.0-20
  - Port configure script to C99


Package:  autotrace-0.31.9-3.fc38
Old package:  autotrace-0.31.9-2.fc38
Summary:  Utility for converting bitmaps to vector graphics
RPMs: autotrace autotrace-devel
Size: 841.94 KiB
Size change:  13.89 KiB
Changelog:
  * Mon Jan 16 2023 Mamoru TASAKA  - 0.31.9-3
  - Backport upstream fix for supporting ImageMagick 7


Package:  claws-mail-4.1.1-4.fc38
Old package:  claws-mail-4.1.1-3.fc38
Summary:  Email client and news reader based on GTK+
RPMs: claws-mail claws-mail-devel claws-mail-plugins 
claws-mail-plugins-acpi-notifier claws-mail-plugins-address-keeper 
claws-mail-plugins-archive claws-mail-plugins-att-remover 
claws-mail-plugins-attachwarner claws-mail-plugins-bogofilter 
claws-mail-plugins-bsfilter claws-mail-plugins-clamd claws-mail-plugins-fancy 
claws-mail-plugins-fetchinfo claws-mail-plugins-gdata 
claws-mail-plugins-keyword_warner claws-mail-plugins-libravatar 
claws-mail-plugins-litehtml-viewer claws-mail-plugins-mailmbox 
claws-mail-plugins-managesieve claws-mail-plugins-newmail 
claws-mail-plugins-notification claws-mail-plugins-pdf-viewer 
claws-mail-plugins-perl claws-mail-plugins-pgp claws-mail-plugins-python 
claws-mail-plugins-rssyl claws-mail-plugins-smime 
claws-mail-plugins-spam-report claws-mail-plugins-spamassassin 
claws-mail-plugins-tnef claws-mail-plugins-vcalendar
Size: 23.58 MiB
Size change:  166.22 KiB
Changelog:
  * Mon Jan 16 2023 Michael Schwendt  - 4.1.1-4
  - For GCC 13 fix missing cstdint in litehtml plugin.


Package:  ffmpeg-5.1.2-4.fc38
Old package:  ffmpeg-5.1.2-3.fc38
Summary:  A complete solution to record, convert and stream audio and video
RPMs: ffmpeg-free ffmpeg-free-devel libavcodec-free 
libavcodec-free-devel libavdevice-free libavdevice-free-devel libavfilter-free 
libavfilter-free-devel libavformat-free libavformat-free-devel libavutil-free 
libavutil-free-devel libpostproc-free libpostproc-free-devel libswresample-free 
libswresample-free-devel libswscale-free libswscale-free-devel
Size: 34.99 MiB
Size change:  670.81 KiB
Changelog:
  * Sun Jan 15 2023 Yaakov Selkowitz  - 5.1.2-4
  - Properly enable libzvbi_teletext decoder


Package:  ghc8.10-8.10.7-6.fc38
Old package:  ghc8.10-8.10.7-5.fc37
Summary:  Glasgow Haskell Compiler
RPMs: ghc8.10 ghc8.10-Cabal ghc8.10-Cabal-devel ghc8.10-Cabal-doc 
ghc8.10-Cabal-prof ghc8.10-array ghc8.10-array-devel ghc8.10-array-doc 
ghc8.10

Re: F38 proposal: FPC repackaging (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 17, 2023 at 10:33:10AM -, Artur Frenszek-Iwicki wrote:
> Haven't planned on this originally, but it seems like a good idea.
> 
> Never really used Obsoletes before, so I have to ask:
> what's the dnf behaviour when a package is obsoleted by multiple packages?
> If it tries to install all of them, then that'd be okay. I'd like to
> avoid a situation where dnf decides that it prefers to upgrade by
> removing the "old" fpc package and installing only fpc-ide.

You need to add 'Obsoletes: $original_package_name < $some_version_after_split'
to both the $original_package_name subpackage and to the new split-out
subpackage. With that, dnf will install both on upgrade of 
$original_package_name.

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

Re: F38 proposal: FPC repackaging (Self-Contained Change proposal)

[Artur Frenszek-Iwicki]

Haven't planned on this originally, but it seems like a good idea.

Never really used Obsoletes before, so I have to ask:
what's the dnf behaviour when a package is obsoleted by multiple packages?
If it tries to install all of them, then that'd be okay. I'd like to
avoid a situation where dnf decides that it prefers to upgrade by
removing the "old" fpc package and installing only fpc-ide.

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

[Bug 2161420] perl-Class-Method-Modifiers-2.14 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version||perl-Class-Method-Modifiers
   ||-2.14-1.fc38
 Status|MODIFIED|CLOSED
Last Closed||2023-01-17 10:12:56



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-99bf181c12 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161420
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2161420] perl-Class-Method-Modifiers-2.14 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-99bf181c12 has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-99bf181c12


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2161420
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg local - do not clean build directory

[Mamoru TASAKA]

Petr Pisar wrote on 2023/01/17 18:29:

V Tue, Jan 17, 2023 at 10:11:48AM +0100, Dan Horák napsal(a):

On Mon, 16 Jan 2023 21:21:39 -0700
Orion Poplawski  wrote:


How the #$@! do I get fedpkg local to not cleanup the local build
directory after a successful build?  This is the most annoying change to
come around in a long time IMHO.


hmm, it doesn't clean the build directory here (fedpkg-1.43-2.fc36)


rpmbuild does that:

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.oNsT7U
 

 From rpm-4.18.0-beta1 changelog:

commit 6f945960affc7a2a2b49337458457273d8a4faf5
Author: Panu Matilainen 
Date:   Wed May 25 15:08:30 2022 +0300

 Remove build tree automatically on successfull binary package creation


It think "fedpkg local" needs a new "--noclean" option.

-- Petr



Currently I do "$ fedpkg local -- --noclean" .

$ fedpkg local --help
positional arguments:
  extra_argsCustom arguments that are passed to the 'rpmbuild'. Use 
'--' to separate them from other arguments.


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

Re: fedpkg local - do not clean build directory

[Petr Pisar]

V Tue, Jan 17, 2023 at 10:11:48AM +0100, Dan Horák napsal(a):
> On Mon, 16 Jan 2023 21:21:39 -0700
> Orion Poplawski  wrote:
> 
> > How the #$@! do I get fedpkg local to not cleanup the local build 
> > directory after a successful build?  This is the most annoying change to 
> > come around in a long time IMHO.
> 
> hmm, it doesn't clean the build directory here (fedpkg-1.43-2.fc36)
> 
rpmbuild does that:

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.oNsT7U
+ umask 022
+ cd /home/test/fedora/perl-Fedora-VSP
+ cd Fedora-VSP-0.001
+ /usr/bin/rm -rf 
/home/test/rpmbuild/BUILDROOT/perl-Fedora-VSP-0.001-29.fc38.x86_64
+ RPM_EC=0
++ jobs -p
+ exit 0
Executing(rmbuild): /bin/sh -e /var/tmp/rpm-tmp.WqaIrM
+ umask 022
+ cd /home/test/fedora/perl-Fedora-VSP
+ rm -rf Fedora-VSP-0.001 Fedora-VSP-0.001.gemspec
  ^^^
+ RPM_EC=0
++ jobs -p
+ exit 0

From rpm-4.18.0-beta1 changelog:

commit 6f945960affc7a2a2b49337458457273d8a4faf5
Author: Panu Matilainen 
Date:   Wed May 25 15:08:30 2022 +0300

Remove build tree automatically on successfull binary package creation

Traditionally rpmbuild has only cleaned up the build directory on
--rebuild mode, but by default leaving tonnes of digital waste behind in
the far more common -bb mode. Default to cleaning up build directory
in addition to buildroot on successfull binary package creation,
with the exception of short-circuit'ed builds.

To go with this, have --noclean affect the build directory removal too.
Change the diagnostics message from "--clean" to "rmbuild" because
--clean is just misleading as it can get executed by other means too.

(cherry picked from commit b34333fa021c0ee7215714eeef96d1a2843ea08e)

It think "fedpkg local" needs a new "--noclean" option.

-- Petr


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

tintin: license updated

[Petr Šabata]

PSA: I've updated the license of tintin from GPLv2+ to GPL-3.0-only in
its 2.02.30 update. This should have been done a while ago, in 2.01.8;
Bodhi updates submitted.

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

Re: fedpkg local - do not clean build directory

[Dan Horák]

On Mon, 16 Jan 2023 21:21:39 -0700
Orion Poplawski  wrote:

> How the #$@! do I get fedpkg local to not cleanup the local build 
> directory after a successful build?  This is the most annoying change to 
> come around in a long time IMHO.

hmm, it doesn't clean the build directory here (fedpkg-1.43-2.fc36)


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

Re: vtk build failure with gcc 13.0.0 - enum class

[Jakub Jelinek]

On Mon, Jan 16, 2023 at 09:36:39PM -0700, Orion Poplawski wrote:
> elaborated-type-specifier for a scoped enum must not use the 'class' keyword
>33 | enum class EndiannessType : std::uint8_t
>   |  ^

The actual bug is shown in later errors.
> 'int32_t' is not a member of 'std'; did you mean 'int32_t'?
>   103 |   std::array ComputeExtent() const;
>   |   ^~~

See https://gcc.gnu.org/gcc-13/porting_to.html , in particular (something
that is there every year) Header dependency changes:

Some C++ Standard Library headers have been changed to no longer include other 
headers that were being used internally by the library. As such, C++ programs 
that used standard library components without including the right headers will 
no longer compile.

The following headers are used less widely in libstdc++ and may need to be 
included explicitly when compiling with GCC 13: 

 (for std::int8_t, std::int32_t etc.) // This case

So, likely with GCC 12 and older cstdint has been included as implementation
detail by one of the libstdc++ headers VTK includes but isn't included
anymore.

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

Re: updating cmark to 0.30

[Jens-Ulrik Petersen]

On Tue, Jan 17, 2023 at 3:38 PM Milan Crha  wrote:

> On Tue, 2023-01-17 at 13:55 +0800, Jens-Ulrik Petersen wrote:
> > So I plan to go ahead with this rebase and rebuilding these packages
> > after the mass rebuild if that's okay.
>
> Hi,
> does the new version change any API and/or soname version?
>

I don't think so and the test results look quite good actually (only
neochat fails due to cmark-0.30.2):
https://copr.fedorainfracloud.org/coprs/petersen/cmark/monitor/
(I think upstream is a bit conservative with still linking the SONAME to
the version.)

so I think we can go ahead and push this to rawhide.


> > We can consider whether to backport to F37 and possibly F36 if needed
> > afterwards.
>
> I do not think you should change API/soname version in stable releases,
> that can lead to trouble (for example for 3rd-party packages).


You are right - let's not plan to do that yet, though I know one new
dependent package newly needs 0.30.

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

Re: F38 proposal: FPC repackaging (Self-Contained Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 30, 2022 at 02:06:20PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/F38-FPC-repackaging

> == Detailed Description ==
> The `fpc` package will be split into three packages:
> * `fpc` - the compiler itself, plus utility programs
> * `fpc-ide` - the terminal-based TUI IDE (`/usr/bin/fp`)
> * `fpc-units-ARCHNAME-linux` - pre-compiled units (think "FPC's
> stdlib") for developing programs for Linux
> 
> The "units" subpackage will be a shared dependency for both `fpc` and 
> `fpc-ide`.

> == Upgrade/compatibility impact ==
> After upgrading to Fedora 38, users interested in the TUI IDE will
> need to manually install the `fpc-ide` package. For those not
> interested in the TUI IDE, there will be no impact.

Do you plan to add the usual Obsoletes:fpc<… to
both fpc and fpc-ide so that both are installed on upgrades?
This would make the user experience nicer.

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

[Bug 2158089] Add perl-Locale-Codes to EPEL9

[bugzilla]

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



--- Comment #1 from Petr Pisar  ---
Any progress? If you don't have time maintaining this package in EPEL, please
give me access to this package or to EPEL branches and I will add this package
into EPEL9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158089
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

License correction for glances

[Ali Erdinc Koroglu]

The License for glances changed from GPLv3 to LGPL-3.0-only AND MIT

https://github.com/nicolargo/glances/blob/develop/LICENSES/LGPL-3.0-only.txt
https://github.com/nicolargo/glances/blob/develop/glances/outputs/static/css/bootstrap.less

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