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
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
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
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
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
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
> 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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2157233
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Config-INI-Reader-Orde |perl-Config-INI-Reader-Orde
https://bugzilla.redhat.com/show_bug.cgi?id=2157213
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Perl-Critic-Tics-0.010 |perl-Perl-Critic-Tics-0.010
https://bugzilla.redhat.com/show_bug.cgi?id=2157222
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Number-Tolerant-1.710- |perl-Number-Tolerant-1.710-
https://bugzilla.redhat.com/show_bug.cgi?id=2157223
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Pod-Elemental-PerlMung |perl-Pod-Elemental-PerlMung
mspacek merged a pull-request against the project: `perl-Coro` that you are
following.
Merged pull-request:
``
Use _fortify_level
``
https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=2157233
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=2157223
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Pod-Elemental-PerlMung |perl-Pod-Elemental-PerlMung
https://bugzilla.redhat.com/show_bug.cgi?id=2157222
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=2157213
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2155545
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=2155539
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Resolution|---
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
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
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2161420
Bug ID: 2161420
Summary: perl-Class-Method-Modifiers-2.14 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Class-Method-Modifiers
Keywords:
> 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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
siddhesh commented on the pull-request: `Use _fortify_level` that you are
following:
``
Actually since this is only for arm, I wonder if we could simply drop that
whole block.
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
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,
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,
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
Siddhesh Poyarekar changed:
What|Removed |Added
Summary|Use %_fortify_level instead |perl-Coro: Use
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
--- Comment #2 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-Module-ExtractUse-0.345-1.fc36.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=96214046
--
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
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
--- Comment #1 from Upstream Release Monitoring
---
Created attachment 1938423
--> https://bugzilla.redhat.com/attachment.cgi?id=1938423=edit
Update to 0.345 (#2161364)
--
You are receiving this mail because:
You are on the CC list for
https://bugzilla.redhat.com/show_bug.cgi?id=2161364
Bug ID: 2161364
Summary: perl-Module-ExtractUse-0.345 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Module-ExtractUse
Keywords:
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:
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:
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]`
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]`
siddhesh opened a new pull-request against the project: `perl-Coro` that you
are following:
``
Use _fortify_level
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
Siddhesh Poyarekar changed:
What|Removed |Added
Blocks||2158232
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2161311
Bug ID: 2161311
Summary: Use %_fortify_level instead of twiddling with
RPM_OPT_FLAGS
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Coro
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
Siddhesh Poyarekar changed:
What|Removed |Added
Blocks||2158232
Referenced Bugs:
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
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
* 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
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
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:
>
>
>
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
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
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
Petr Pisar changed:
What|Removed |Added
Status|MODIFIED|CLOSED
Resolution|---
mspacek merged a pull-request against the project:
`perl-Dist-Zilla-Plugin-GithubMeta` that you are following.
Merged pull-request:
``
Package tests and update license to SPDX license
``
https://src.fedoraproject.org/rpms/perl-Dist-Zilla-Plugin-GithubMeta/pull-request/1
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
https://bugzilla.redhat.com/show_bug.cgi?id=2160077
Petr Pisar changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
Fixed In Version|
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
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
mspacek opened a new pull-request against the project:
`perl-Dist-Zilla-Plugin-GithubMeta` that you are following:
``
Package tests and update license to SPDX license
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Dist-Zilla-Plugin-GithubMeta/pull-request/1
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
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
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.
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
> 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"
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 --
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
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
1 - 100 of 105 matches
Mail list logo
