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?
> We can consider whether to backport to F37 and pos
Currently we have an old version of cmark in Fedora: version 0.29.
I had several requests to update it to the latest release 0.30.2 from 2021.
https://bugzilla.redhat.com/show_bug.cgi?id=1974335
I created a copr repo for testing:
https://copr.fedorainfracloud.org/coprs/petersen/cmark/
>From my r
On 1/16/23 20:49, Michael Cronenworth wrote:
Hi,
Wine 8.0 is checking for support for the '-Wl,-WX' flag in LLVM and it is
showing as not supported in Rawhide (LLVM 15).
LLVM is used to cross-compile ARM 64-bit binaries of Wine.
Wine 7.22 configure check:
checking whether clang supports -tar
Hi,
Wine 8.0 is checking for support for the '-Wl,-WX' flag in LLVM and it is showing as
not supported in Rawhide (LLVM 15).
LLVM is used to cross-compile ARM 64-bit binaries of Wine.
Wine 7.22 configure check:
checking whether clang supports -target aarch64-windows -fuse-ld=lld
-Wl,-subsys
On Mon, Jan 16, 2023 at 11:33 PM Daniel Colascione wrote:
>
> > Having the vDSO do the unwinding allows the unwinding to be entirely
> transparent to userspace programs and libraries
>
> Why *should* unwinding be transparent to userspace programs and libraries?
> Userspace can contribute to makin
With the change to gcc 13, vtk is failing to build with:
[ 39%] Building CXX object
IO/Image/CMakeFiles/IOImage.dir/vtkSEPReader.cxx.o
cd /builddir/build/BUILD/VTK-9.2.5/build/IO/Image && /usr/bin/g++
-DIOImage_EXPORTS -DVTK_IN_VTK -Dkiss_fft_scalar=double
-I/builddir/build/BUILD/VTK-9.2.5/bui
> Having the vDSO do the unwinding allows the unwinding to be entirely
transparent to userspace programs and libraries
Why *should* unwinding be transparent to userspace programs and libraries?
Userspace can contribute to making unwinding better, especially in the managed
case, by hooking into t
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.
Thanks.
--
Orion Poplawski
he/him/his - surely the least important thing about me
IT Systems Manager
On Mon, Jan 16, 2023 at 7:34 PM Petr Menšík wrote:
>
> Hi!
>
> I heard (read) objections to any alternatives macros usage often. But
> unless I am mistaken, we do not have any user (enough) friendly way to
> support similar functionality tools with just minor differences.
>
> I thought about it re
On 1/16/23 16:32, Daniel Colascione wrote:
>> Could the vDSO do the unwinding?
>
> The vDSO is just userspace code that happens to be provided by the kernel,
> so, sure, a function in vDSO *could* unwind. But why would it? What would be
> the advantage of doing that over putting the unwinding in
OLD: Fedora-Rawhide-20230114.n.0
NEW: Fedora-Rawhide-20230116.n.1
= SUMMARY =
Added images:10
Dropped images: 4
Added packages: 2
Dropped packages:0
Upgraded packages: 276
Downgraded packages: 0
Size of added packages: 1.04 MiB
Size of dropped packages:0
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 t
On Mon, Jan 16, 2023 at 3:31 PM Lukas Zaoral wrote:
> Hi,
> there is no need to wait for klee. Unfortunately, the package cannot be
> build
> in Rawhide at the moment since the project cannot be built with LLVM 15 and
> the llvm14 compatibility package cannot be used with clang 15 (and clang14
>
> * As of today the module does nothing because one of the configuration
> files use to define the permissions (50-default.perms) is not
> installed in the distribution. Other packages may install their own
> configuration files to specify the permissions, but I haven't found
> any.
So basically,
Lukas Zaoral wrote:
> there is no need to wait for klee. Unfortunately, the package cannot be
> build in Rawhide at the moment since the project cannot be built with LLVM
> 15 and the llvm14 compatibility package cannot be used with clang 15 (and
> clang14 is a library only package).
Looks like we
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
On Wed, Jan 11, 2023 at 1:59 PM Miro Hrončok wrote:
>
> Dear maintainers.
>
> Based on the current fail to build from source policy, the following packages
> should be retired from Fedora 38 approximately one week before branching.
>
> tabbed psabata
Okay
On 16. 03. 22 15:15, Miro Hrončok wrote:
On 16. 03. 22 14:54, David Cantrell wrote:
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686
builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the
larger question of "what do people use i686 packages
> Could the vDSO do the unwinding?
The vDSO is just userspace code that happens to be provided by the kernel, so,
sure, a function in vDSO *could* unwind. But why would it? What would be the
advantage of doing that over putting the unwinding in libc? To change the vDSO,
you have to change the k
Miro Hrončok kirjoitti 16.1.2023 klo 16.05:
On 16. 01. 23 14:57, Richard Shaw wrote:
Since `fedpkg scratch-build` bombs out with an error if you've made
local changes I propose a slight modification:
If no changes are made then it does a normal scratch build for the
"does this still build /
Michael J Gruber kirjoitti 16.1.2023 klo 14.46:
`--srpm` is named misleadingly, by the way, because it names the "transport of the
source" when indeed it implies a potentially different source version. That's
another reasons why removing it (the name) and making it the mode of operation for
`
On 1/16/23 15:54, Daniel Colascione wrote:
>> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione > wrote:
>>
>> This sounds great, but how is it going to get made?
> Someone has to do it. 😄 I've been thinking about adding this mechanism for a
> few years, but haven't had time so far. I suppose the
On 2023-01-16 05:24, Kalev Lember wrote:
On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones
wrote:
Also make use of suppressions:
https://gitlab.com/nbdkit/nbdkit/-/tree/master/valgrind
Also, to add to this, glib2 has a suppressions file you can use to cut
down on the false positiv
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:
-
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.
__
> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione wrote:
>
> This sounds great, but how is it going to get made?
Someone has to do it. :-) I've been thinking about adding this mechanism for a
few years, but haven't had time so far. I suppose the first step would be
raising the subject on li
On Mon, Jan 16, 2023 at 9:01 PM Jakub Jelinek wrote:
>
> On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> > On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > > If it is for distribution packages then I reckon the flags should be
> > > as close as possible for the mere reason of con
On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione wrote:
>
> Frame pointers also have the disadvantage of working only with AOT-compiled
> languages for which a trace analysis tool can associate an instruction
> pointer with a semantically-relevant bit of code. If you try to use frame
> pointer
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 bottle
Frame pointers also have the disadvantage of working only with AOT-compiled
languages for which a trace analysis tool can associate an instruction pointer
with a semantically-relevant bit of code. If you try to use frame pointers to
profile a Python program, all you're going to get is a profile
On Mon, Jan 16, 2023 at 11:56 AM Vít Ondruch wrote:
>
>
> Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):
> > Hi!
> >
> > I heard (read) objections to any alternatives macros usage often. But
> > unless I am mistaken, we do not have any user (enough) friendly way to
> > support similar functionality
https://fedoraproject.org/wiki/Changes/RemovePamConsole
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 Committ
https://fedoraproject.org/wiki/Changes/Cups-filters2.0b
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 Committ
On Mon, Jan 16, 2023 at 08:42:32PM +0100, Miro Hrončok wrote:
> On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
> > If it is for distribution packages then I reckon the flags should be
> > as close as possible for the mere reason of consistency within the
> > distribution.
>
> Nope, the individual
On 16. 01. 23 20:53, Simo Sorce wrote:
On Fri, 2023-01-13 at 12:28 +0100, Miro Hrončok wrote:
On 13. 01. 23 0:35, Chuck Anderson wrote:
For receiving/filtering emails, you can filter on the List-Id: header
rather than the To: or Cc: headers. In that way you can differentiate
between normal lis
On Fri, 2023-01-13 at 12:28 +0100, Miro Hrončok wrote:
> On 13. 01. 23 0:35, Chuck Anderson wrote:
> > For receiving/filtering emails, you can filter on the List-Id: header
> > rather than the To: or Cc: headers. In that way you can differentiate
> > between normal list distribution and Bcc:. If
On 16. 01. 23 20:30, Siddhesh Poyarekar wrote:
If it is for distribution packages then I reckon the flags should be
as close as possible for the mere reason of consistency within the
distribution.
Nope, the individual packages with extension modules all¹ use the
%{build_cflags} flags by defaul
On Mon, Jan 16, 2023 at 1:40 PM Miro Hrončok wrote:
>
> Hello folks,
> this recent Fedora change:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
> Made me think:
>
> Which compiler flags we need to store in Python and which can we omit?
>
> In order
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
On 1/16/23 13:39, Miro Hrončok wrote:
Isn't Python built e.g. with -Werror=format-security or -Wsign-compare
binary compatible with extension modules built without it?
That's a good question, it's almost as if "extension_flags" should be
named "abi_compatibility_flags" or something similar.
Hello folks,
this recent Fedora change:
https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
Made me think:
Which compiler flags we need to store in Python and which can we omit?
In order to make Python extension modules binary compatible with Python, Pytho
On 2023-01-16 01:38, Tom Hughes wrote:
I suspect this is a result of libraries being opened and closed
dynamically...
Try using --keep-debuginfo=yes to make valgrind cache debuginfo
for libraries that have been closed.
Yes, that was it. I did not know this about valgrind. Thank you!
I'll r
On Mon, Jan 16, 2023 at 1:05 PM Daniel P. Berrangé wrote:
>
> I'm getting the strange error in $SUBJECT in an upstream CI job that
> is targetting Fedora rawhide. I'm guessing it is something related to
> the recent changes to set the _FOTIFY_SOURCE value to 3 instead of
> 2, but not sure what.
>
On Mon, Jan 16, 2023 at 12:06:59PM -0600, Jonathan Wright wrote:
> Are you by chance running this inside of a rawhide docker container within
> GH actions? If so, I'm in the same boat and haven't figured out how to
> force it back to "2", or why it's failing in the first place.
No, I'm using GitL
Are you by chance running this inside of a rawhide docker container within
GH actions? If so, I'm in the same boat and haven't figured out how to
force it back to "2", or why it's failing in the first place.
On Mon, Jan 16, 2023 at 12:05 PM Daniel P. Berrangé
wrote:
> I'm getting the strange er
I'm getting the strange error in $SUBJECT in an upstream CI job that
is targetting Fedora rawhide. I'm guessing it is something related to
the recent changes to set the _FOTIFY_SOURCE value to 3 instead of
2, but not sure what.
What I'm finding especially bizarre is that I can't reproduce it on
Dne 16. 01. 23 v 12:34 Petr Menšík napsal(a):
Hi!
I heard (read) objections to any alternatives macros usage often. But
unless I am mistaken, we do not have any user (enough) friendly way to
support similar functionality tools with just minor differences.
I have not tried this:
https://gi
I will be updating clamav to 1.0.0 next week in rawhide. This includes
a switch to rust, a soname update and a slight API change. Dependent
packages have been rebuilt here:
https://copr.fedorainfracloud.org/coprs/orion/clamav-1.0/builds/
Fix for klamav has been filed here:
https://src.fedor
Hey there,
Kevin Fenzi recently updated the Koji builders in production and with
this, the rpmautospec plugin got updated to version 0.3.1.
These are the changes in this version which affect building packages on
Koji in Fedora Infrastructure:
- You can mark a commit log with `[skip changelog]` (
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?
Vít
Dne 16. 01. 23 v 8:56 Otto Liljalaakso napsal(a):
Hello everybody,
I would like to gather different use cases for the 'fe
Hello,
Unfortunately, klee cannot be built in Rawhide at the moment since it
is incompatible with LLVM 15 and it requires the corresponding Clang
version during the build. Therefore, the llvm14 and clang14
compatibility packages cannot be used as clang14 only contains
libraries.
I've ported this
Hi,
there is no need to wait for klee. Unfortunately, the package cannot be build
in Rawhide at the moment since the project cannot be built with LLVM 15 and
the llvm14 compatibility package cannot be used with clang 15 (and clang14 is
a library only package).
Unfortunately, I do not have the nece
On Mon, Jan 16, 2023 at 8:06 AM Miro Hrončok wrote:
> On 16. 01. 23 14:57, Richard Shaw wrote:
> >
> > Since `fedpkg scratch-build` bombs out with an error if you've made
> local
> > changes I propose a slight modification:
> >
> > If no changes are made then it does a normal scratch build for th
On 16. 01. 23 14:57, Richard Shaw wrote:
Since `fedpkg scratch-build` bombs out with an error if you've made local
changes I propose a slight modification:
If no changes are made then it does a normal scratch build for the "does this
still build / not build" 1% use case
If there are local
On Mon, Jan 16, 2023 at 3:38 AM Sandro wrote:
> On 16-01-2023 08:56, Otto Liljalaakso wrote:
> > Above change seems like a clear improvement to me, making the most used
> > option the default. But I have noticed that workflows differ wildly
> > between packagers, so before submitting any code for
* 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 func
On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
> Hello everybody,
>
> I would like to gather different use cases for the 'fedpkg
> scratch-build' command.
>
> Currently, this is exactly the same as 'fedpkg build --scratch',
> meaning that is performs a scratch build of the push
On Mon, Jan 16, 2023 at 2:21 PM Richard W.M. Jones
wrote:
> Also want to mention that your valgrind command line is ... a little
> naive. Many other options are useful. Here's what we use in nbdkit:
>
>
> https://gitlab.com/nbdkit/nbdkit/-/blob/a5f804180240aea7031470cb8ed294f904268f0a/wrapper.c
On Mon, Jan 16, 2023 at 12:52:38AM -0800, Gordon Messmer wrote:
> ==29692== 30 bytes in 2 blocks are definitely lost in loss record
> 917 of 2,602
> ==29692== at 0x484386F: malloc (vg_replace_malloc.c:393)
> ==29692== by 0x14806539: ???
> ==29692== by 0x14BA7D87: ???
> ==29692== by 0x14
On Sun, Jan 15, 2023 at 10:10:24PM -0800, Gordon Messmer wrote:
> I'm working on reducing memory use in packagekitd, and so far
> progress has been very good. I've opened 4 memory-related PRs
> against PackageKit and libdnf this week, and locally I've reduced
> memory use at idle by almost 90% (I
Yes, testing local changes with `srpm` is the main use case. I would even say
that using `scratch-build` without `--srpm` is a typical mistake for new
packagers - thinking they test before they push, when in effect they don't.
Testing (scratch-building) the pushed head makes sense when there are
On Mi, 11.01.23 16:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)
> This is never
On 16. 01. 23 12:34, Petr Menšík wrote:
Hi!
I heard (read) objections to any alternatives macros usage often. But unless I
am mistaken, we do not have any user (enough) friendly way to support similar
functionality tools with just minor differences.
I recall that Sphinx in Fedora once used h
Hi!
I heard (read) objections to any alternatives macros usage often. But
unless I am mistaken, we do not have any user (enough) friendly way to
support similar functionality tools with just minor differences.
I thought about it recently and I think we have similar issue solved by
systemd-sy
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 regularl
For me it is:
99% "I want to check if local changes build" - fedpkg scratch-build --srpm
1% "Something changed in Rawhide and I want to see if X still builds" -
fedpkg scratch-build
I didn't know "fedpkg build" has a scratch option, TIL.
Cheers,
Chris
On Mon, 16 Jan 2023 at 10:52, Daniel P. Be
On Mon, Jan 16, 2023 at 09:56:31AM +0200, Otto Liljalaakso wrote:
> Hello everybody,
>
> I would like to gather different use cases for the 'fedpkg scratch-build'
> command.
>
> Currently, this is exactly the same as 'fedpkg build --scratch', meaning
> that is performs a scratch build of the push
> At least in my workflow, I only do scratch builds before pushing,
> to ensure that what I am about to push builds correctly in Koji.
Same here. Some of my packages are prone to break and in need
of patching on non-x86_64, so that's my main use case as well.
Never used "fedpkg scratch-build" sinc
Hello,
I intend to unretire the 'rshim' package:
https://src.fedoraproject.org/rpms/rshim
The package is needed in RHEL.
Upstream is active. The latest tagged release was just 2 months ago.
Michal
___
devel mailing list -- devel@lists.fedoraproject.org
On 16/01/2023 08:52, Gordon Messmer wrote:
On 2023-01-16 00:31, Tom Hughes via devel wrote:
If that doesn't work then some examples would help, at least if you're
getting a partial trace, so that we can get some idea of what component
it is not able to unwind.
==29692== 30 bytes in 2 blocks
On 16-01-2023 08:56, Otto Liljalaakso wrote:
Above change seems like a clear improvement to me, making the most used
option the default. But I have noticed that workflows differ wildly
between packagers, so before submitting any code for review, I would
like to hear if somebody regularly uses the
On 2023-01-16 00:31, Tom Hughes via devel wrote:
On 16/01/2023 08:12, Florian Festi wrote:
Have you installed the debuginfo packages for the packages involved?
See man debuginfo-install
Making sure debuginfod fetching works should also do it as valgrind
has support for that.
I've tried this
Am 16.01.23 um 08:37 schrieb Dominik 'Rathann' Mierzejewski:
Issues with nvidia driver init/usage detected.
See https://bugzilla.redhat.com/show_bug.cgi?id=2161104
Missing CONFIG_FB_EFI, apparently.
$ grep FB_EFI /boot/config-6.0.15-300.fc37.x86_64
CONFIG_FB_EFI=y
$ grep FB_EFI /boot/config-
On 16/01/2023 08:12, Florian Festi wrote:
On 1/16/23 07:10, Gordon Messmer wrote:
Does anyone have any hints for improving the information I get from
valgrind?
Have you installed the debuginfo packages for the packages involved?
See man debuginfo-install
Making sure debuginfod fetching works
On 1/16/23 07:10, Gordon Messmer wrote:
> Does anyone have any hints for improving the information I get from
> valgrind?
Have you installed the debuginfo packages for the packages involved?
See man debuginfo-install
Florian
___
devel mailing list -- dev
Otto Liljalaakso writes:
> Hello everybody,
>
> I would like to gather different use cases for the 'fedpkg
> scratch-build' command.
>
> Currently, this is exactly the same as 'fedpkg build --scratch', meaning
> that is performs a scratch build of the pushed head of the current
> branch. At le
76 matches
Mail list logo
