https://bugzilla.redhat.com/show_bug.cgi?id=2123187
Bug ID: 2123187
Summary: perl-Test-File-Contents-0.242 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Test-File-Contents
Keywords:
https://bugzilla.redhat.com/show_bug.cgi?id=2123186
Bug ID: 2123186
Summary: perl-HTTP-BrowserDetect-3.36 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-HTTP-BrowserDetect
Keywords:
https://bugzilla.redhat.com/show_bug.cgi?id=2123185
Bug ID: 2123185
Summary: perl-HTML-Tiny-1.06 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-HTML-Tiny
Keywords: FutureFeature, Triaged
Hi All,
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL
maintainer wants to add a package to RHEL 8 or 9 they start a "new package
workflow". There are several automations that happen when they start that
workflow. One of them is checking if the package is already in
As I've been working on converting license tags to SPDX, I have found
myself frequently needing to determine the license for some file that
is not distributed by the package upstream, such as JavaScript and CSS
files copied in by documentation builders, or header files from
header-only packages.
On Wed, 31 Aug 2022 at 17:08, Stephen Smoogen wrote:
>
> When EPEL-8 was launched, it came with some support for modules with the
> hope that a module ecosystem could be built from Fedora packages using RHEL
> modules as an underlying tool. This has never happened and we have ended up
> with a
When EPEL-8 was launched, it came with some support for modules with the
hope that a module ecosystem could be built from Fedora packages using RHEL
modules as an underlying tool. This has never happened and we have ended up
with a muddle of modular packages which will 'build' but may not install
On Thu, Aug 25, 2022 at 7:36 PM Jerry James wrote:
> It is no longer possible to build the sympy documentation, due to
> missing dependencies. However, I have already noted other packages I
> maintain that need each of these. That tells me it is time to get
> them into Fedora. I would like to
https://bugzilla.redhat.com/show_bug.cgi?id=2123150
Bug ID: 2123150
Summary: perl-Net-Netmask-2.0002 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Net-Netmask
Keywords: FutureFeature, Triaged
Bottom line opinion: hardened_malloc ... costs too much.
Attempting to be constructive: Psychologically, I might be willing to pay
a "security tax" of something like 17%, partly on the basis of similarity
to the VAT rate (Value Added Tax) in some parts of the developed world.
On Tue, 2022-08-30 at 18:07 +0200, Ralf Corsépius wrote:
>
> Am 29.08.22 um 15:43 schrieb Dan Čermák:
> > I agree, this needn't block F37, but I still think that this should be
> > fixed. Unless I use microdnf, I cannot upgrade my VPS with 1GB RAM that
> > happily hosts my home page, which is
Adding Daniel for awareness.
Regards.
Pablo
El mié., 31 ago. 2022 16:09, John Reiser escribió:
> Here is one end-to-end performance measurement of using hardened_malloc.
>
> sudo sh -c "echo 1 >/proc/sys/vm/drop_caches"
> /usr/bin/time rpmbuild -bc kernel-5.15.11-100.fc34.spec
On Wed, 2022-08-31 at 12:43 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Aug 30, 2022 at 12:10:00PM -0700, Adam Williamson wrote:
> > On Tue, 2022-08-30 at 09:14 -0400, Ben Cotton wrote:
> > > From my perspective, anything that blocks the release is on the
> > > critical path. So any time
I have patched to add the unversioned .so
https://src.fedoraproject.org/rpms/libid3tag/c/607d7abf709add3e39690adfd3aef871c50d37c2?branch=rawhide
I don't think there is a need to rebuild dependant packages.
[leigh@mpd libid3tag]$ abipkgdiff libid3tag-0.15.1b-37.fc37.x86_64.rpm
On 31/08/2022 16:07, Leigh Scott wrote:
Switching upstream has increased the .so version from libid3tag.so.0 to
libid3tag.so.0.16.2
It looks like a bug. I think they omitted the SOVERSION field when
switching to CMake.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Wed, Aug 31, 2022 at 3:07 PM Leigh Scott wrote:
> Switching upstream has increased the .so version from libid3tag.so.0 to
> libid3tag.so.0.16.2
> I plan to do the rebuilds myself after checking everything builds ok in
> copr.
>
>
> Affected packages
>
> Fedora:
>
In one week (2022-09-07), or slightly later, I plan to update the c4core
library from 0.1.9 to 0.1.10 in Rawhide and F37, which will involve a
.so version bump. This should have no impact on other packagers; I will
handle the necessary rebuilds in c4fs, c4log, and rapidyaml.
Here is one end-to-end performance measurement of using hardened_malloc.
sudo sh -c "echo 1 >/proc/sys/vm/drop_caches"
/usr/bin/time rpmbuild -bc kernel-5.15.11-100.fc34.spec >rpmbuild.out 2>&1
For glibc, the result was
19274.30user 2522.87system 1:49:06elapsed 332%CPU
Switching upstream has increased the .so version from libid3tag.so.0 to
libid3tag.so.0.16.2
I plan to do the rebuilds myself after checking everything builds ok in copr.
Affected packages
Fedora:
audacity-0:3.1.3-5.fc37.x86_64
easytag-0:2.4.3-16.fc37.x86_64
gtkpod-0:2.1.5-21.fc37.x86_64
On 30. 08. 22 20:15, Mikolaj Izdebski wrote:
2) One-time enablement of all existing packages
That should be doable. Right?
3) Automatic enablement of all new packages
That should be just a matter of changing the defaults. Correct?
I can implement points 2 and 3 easily, as long as there is
On Tue, 30 Aug 2022 at 14:16, Mikolaj Izdebski wrote:
> On Thu, Aug 25, 2022 at 9:53 AM Miro Hrončok wrote:
>
> To submit more scratch builds we would need larger builder capacity.
> This doesn't necessarily mean more or better hardware.
> Better Koji configuration would help a lot.
> We have
On 31. 08. 22 15:22, Miroslav Suchý wrote:
Dne 31. 08. 22 v 11:50 Miro Hrončok napsal(a):
Hello license folks.
I see that Fedora's rpmlint is yet to be taught to understand SPDX:
python3-lxml.x86_64: W: invalid-license BSD-3-Clause
python3-lxml.x86_64: W: invalid-license MIT-CMU
Is this
Dne 31. 08. 22 v 11:50 Miro Hrončok napsal(a):
Hello license folks.
I see that Fedora's rpmlint is yet to be taught to understand SPDX:
python3-lxml.x86_64: W: invalid-license BSD-3-Clause
python3-lxml.x86_64: W: invalid-license MIT-CMU
Is this support tracked somewhere? I know openSUSE
Announcing the creation of a new nightly release validation test event
for Fedora-IoT 37 RC 20220831.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
On 31. 08. 22 13:41, Ali Erdinc Koroglu wrote:
- pytest-capturelog not even exits in pypi [2] so can we retire it and
use pytest-catchlog instead ?
Yes. Except pytest-catchlog is retired too, because pytest itself
provides the functionality now:
Björn,
I won't be addressing the comments one-by-one, as it mostly boils down
to "I don't like the UI/UX" (how I read it, at least). And I
absolutely understand and accept that. On the other hand, we (as in
the people who developed this) are, well, developers, and that about
sums up the UX
OLD: Fedora-37-20220830.n.0
NEW: Fedora-37-20220831.n.0
= SUMMARY =
Added images:1
Dropped images: 2
Added packages: 0
Dropped packages:7
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:7.92 MiB
Size
Actually, I am not owner, just maintainer So I'll just remove myself
from the package. But the other packagers are not active, so it will be
eventually orphaned.
Vít
Dne 31. 08. 22 v 14:43 Vít Ondruch napsal(a):
I am orphaning rubygem-activeresource, because:
* I don't have any use
I am orphaning rubygem-activeresource, because:
* I don't have any use for the package
* The upstream is not very active these days
The package is in reasonable shape if somebody is interested. Just fixed
one possible build issue.
Vít
OpenPGP_signature
Description: OpenPGP digital
On Tue, Aug 30, 2022 at 12:10:00PM -0700, Adam Williamson wrote:
> On Tue, 2022-08-30 at 09:14 -0400, Ben Cotton wrote:
> > From my perspective, anything that blocks the release is on the
> > critical path. So any time there's a violation of the release criteria
> > and the package is not on the
Thank you Kevin! This was it!
Strangely `dnf install bodhi-client` would not install v6. But manually
hauling it in via
https://download-ib01.fedoraproject.org/pub/fedora/linux/updates/35/Everything/x86_64/Packages/b/bodhi-client-6.0.0-2.fc35.noarch.rpm
worked great.
Thank you for your help!
On
https://bugzilla.redhat.com/show_bug.cgi?id=2115214
Michal Josef Spacek changed:
What|Removed |Added
Assignee|lkund...@v3.sk |mspa...@redhat.com
On Wed, Aug 31, 2022 at 7:48 AM Miro Hrončok wrote:
>
> On 31. 08. 22 13:39, Neal Gompa wrote:
> > On Wed, Aug 31, 2022 at 5:50 AM Miro Hrončok wrote:
> >>
> >> Hello license folks.
> >>
> >> I see that Fedora's rpmlint is yet to be taught to understand SPDX:
> >>
> >> python3-lxml.x86_64: W:
On Tue, Aug 30, 2022 at 03:20:10PM -0500, Jonathan Wright via devel wrote:
> Ah I see you got someone.
>
> On Tue, Aug 30, 2022 at 3:19 PM Jonathan Wright
> wrote:
>
> I'll trade you for a basic Python package: https://bugzilla.redhat.com/
> show_bug.cgi?id=2121258
I've taken this one
On 31. 08. 22 13:39, Neal Gompa wrote:
On Wed, Aug 31, 2022 at 5:50 AM Miro Hrončok wrote:
Hello license folks.
I see that Fedora's rpmlint is yet to be taught to understand SPDX:
python3-lxml.x86_64: W: invalid-license BSD-3-Clause
python3-lxml.x86_64: W: invalid-license MIT-CMU
Is this
On Wed, Aug 31, 2022 at 5:50 AM Miro Hrončok wrote:
>
> Hello license folks.
>
> I see that Fedora's rpmlint is yet to be taught to understand SPDX:
>
> python3-lxml.x86_64: W: invalid-license BSD-3-Clause
> python3-lxml.x86_64: W: invalid-license MIT-CMU
>
> Is this support tracked somewhere? I
On Wed, Aug 31, 2022 at 12:44 PM Michael J Gruber
wrote:
>
> Funny observation:
>
> - take up an orphaned package
> - refresh dashboard
> - see the package listed in your dashboard as "directly owned" as well as
> "orphaned ... ago" (red warning)
>
> Obviously, different parts of the aggregated
https://bugzilla.redhat.com/show_bug.cgi?id=2119901
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-Business-CreditCard-0. |perl-Business-CreditCard-0.
Funny observation:
- take up an orphaned package
- refresh dashboard
- see the package listed in your dashboard as "directly owned" as well as
"orphaned ... ago" (red warning)
Obviously, different parts of the aggregated information is aggregated on
different schedules ...
The following Fedora EPEL 7 Security updates need testing:
Age URL
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-cf9b662b60
tcpreplay-4.4.2-1.el7
The following builds have been pushed to Fedora EPEL 7 updates-testing
btrbk-0.31.3-2.el7
shdoc-1.1-1.el7
Details
The following Fedora EPEL 8 Security updates need testing:
Age URL
42 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-89ad385971
chromium-103.0.5060.114-1.el8
3 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-00b4829e45
tcpreplay-4.4.2-1.el8
The following builds
https://bugzilla.redhat.com/show_bug.cgi?id=2119901
Fedora Update System changed:
What|Removed |Added
Resolution|--- |ERRATA
Status|ON_QA
Hello license folks.
I see that Fedora's rpmlint is yet to be taught to understand SPDX:
python3-lxml.x86_64: W: invalid-license BSD-3-Clause
python3-lxml.x86_64: W: invalid-license MIT-CMU
Is this support tracked somewhere? I know openSUSE already uses SPDX, so
rpmlint probably knows how to
Hi.
It seems that only one package depends on python3-markdown2 - glogg -
and it seems to be a leaf package. 19 packages depend on python3-markdown_2.
The packages don't conflict.
If I understand it correctly, glogg needs `markdown` executable only to
build documentation. python3-markdown2
Dear Maintainers, while I was looking for the orphaned packages I
realized this markdown dilemma.
We have 2 different python-markdown packages in our repository, is that
ok or should we retire one?
https://src.fedoraproject.org/rpms/python-markdown_2 ->
On ti, 30 elo 2022, Adam Williamson wrote:
On Tue, 2022-08-30 at 09:39 +0300, Alexander Bokovoy wrote:
On ma, 29 elo 2022, Adam Williamson wrote:
> On Tue, 2022-08-30 at 00:32 -0400, DJ Delorie wrote:
> > It sounds to me like the problem is "how do we best use the available
> > automated test
46 matches
Mail list logo
