https://bugzilla.redhat.com/show_bug.cgi?id=2133144
--- Comment #2 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-Devel-Timer-0.14-1.fc36.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=92781513
--
You
https://bugzilla.redhat.com/show_bug.cgi?id=2133144
--- Comment #1 from Upstream Release Monitoring
---
Created attachment 1916790
--> https://bugzilla.redhat.com/attachment.cgi?id=1916790=edit
Update to 0.14 (#2133144)
--
You are receiving this mail because:
You are on the CC list for
https://bugzilla.redhat.com/show_bug.cgi?id=2133144
Bug ID: 2133144
Summary: perl-Devel-Timer-0.14 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Devel-Timer
Keywords: FutureFeature, Triaged
https://bugzilla.redhat.com/show_bug.cgi?id=2133140
Bug ID: 2133140
Summary: perl-Term-ProgressBar-2.23 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Term-ProgressBar
Keywords: FutureFeature,
On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/NodejsRepackaging
>
> 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
On Fri, Oct 07, 2022 at 08:33:38AM -0700, John Reiser wrote:
> >... it [memtest.efi] can be accessed by a trivial two line command.
>
> Please write the literal two-line command here.
> It takes too long to search documentation or invent the code,
> and the various imagined versions might have
=
#fedora-meeting: ELN (2022-10-07)
=
Meeting started by sgallagh at 16:01:12 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2022-10-07/eln.2022-10-07-16.01.log.html
.
Meeting summary
Once upon a time, Mattia Verga said:
> Il 07/10/22 17:28, Chris Adams ha scritto:
> > Once upon a time, Mattia Verga said:
> >> I don't understand, why RPM automatically adds a dependency on a noarch
> >> subpackage which consists only of data files?
> >>
> >>
The following Fedora EPEL 8 Security updates need testing:
Age URL
6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-f70a782e69
gitqlient-1.5.0-2.el8
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6ae624fe64
libopenmpt-0.6.6-1.el8
3
Il 07/10/22 17:28, Chris Adams ha scritto:
> Once upon a time, Mattia Verga said:
>> I don't understand, why RPM automatically adds a dependency on a noarch
>> subpackage which consists only of data files?
>>
>> https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
>>
>> Any idea?
>
... it [memtest.efi] can be accessed by a trivial two line command.
Please write the literal two-line command here.
It takes too long to search documentation or invent the code,
and the various imagined versions might have bugs.
___
devel mailing
Once upon a time, Mattia Verga said:
> I don't understand, why RPM automatically adds a dependency on a noarch
> subpackage which consists only of data files?
>
> https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
>
> Any idea?
Because it isn't just data files?
I don't understand, why RPM automatically adds a dependency on a noarch
subpackage which consists only of data files?
https://koji.fedoraproject.org/koji/buildinfo?buildID=2072456
Any idea?
Mattia
___
devel mailing list --
-- Petr
Possibly related (?), today I've noticed that opening a .fedorapeople
website in a browser I get an error about expired certificate...
Also prevents downloading spec and srpm files.
Mattia
___
devel mailing list --
Autorpmspec requiring direct use of git (with commit --allow-empty) because
rpmdev-bumpspec can't be used is a problem. Fedpkg needs to grow the
ability to handle this, preferably transparently if possible. But that's
another thread...
I just performed a:
$ git commit --allow-empty -m "Rebuild
Il 07/10/22 13:50, Petr Pisar ha scritto:
> V Thu, Oct 06, 2022 at 08:17:15PM -0500, Richard Shaw napsal(a):
>> I'm still getting this on occasion and have no idea what the issue is:
>>
>> $ fedpkg new-sources OpenImageIO-2.4.4.2.tar.gz
>> Uploading: OpenImageIO-2.4.4.2.tar.gz
>>
V Fri, Oct 07, 2022 at 08:56:41AM -0400, Stephen Smoogen napsal(a):
> On Fri, 7 Oct 2022 at 03:34, Petr Pisar wrote:
>
> > V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> > > - epel-release will be updated.
> > > -- epel-modular will set enabled = 0
> >
> > Does it only mean
On Fri, Oct 7, 2022 at 5:54 AM Stephen Smoogen wrote:
>
>
> On Fri, 7 Oct 2022 at 05:59, Miro Hrončok wrote:
>
>> On 07. 10. 22 9:33, Petr Pisar wrote:
>> > Does EPEL have any communication channel to EPEL users besides this
>> mailing
>> > list? If it does, do you plan to announce this change
Earlier discussion:
https://www.mail-archive.com/devel@lists.fedoraproject.org/msg169800.html
Current memtest86+ 5.x requires non-UEFI, which makes it increasingly
irrelevant to modern hardware. memtest86 forked into a proprietary
product some time ago. However there is hope because upstream
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 Fri, 7 Oct 2022 at 03:34, Petr Pisar wrote:
> V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> > - epel-release will be updated.
> > -- epel-modular will set enabled = 0
>
> Does it only mean releasing a new epel-release package with epel-modular
> configuration file set to
On Fri, 7 Oct 2022 at 05:59, Miro Hrončok wrote:
> On 07. 10. 22 9:33, Petr Pisar wrote:
> > Does EPEL have any communication channel to EPEL users besides this
> mailing
> > list? If it does, do you plan to announce this change there? Preferably
> ahead
> > of time.
> >
> > I worry that users
Dne 07. 10. 22 v 14:19 Paul Howarth napsal(a):
On Thu, 6 Oct 2022 14:38:38 +0200
This is good point. I have already forget the details. So if there
was embedded just the right amount of information in the main data,
we would not need the full list (and lazy loading). Currently, the
data
OLD: Fedora-37-20221006.n.0
NEW: Fedora-37-20221007.n.0
= SUMMARY =
Added images:0
Dropped images: 0
Added packages: 0
Dropped packages:0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size of upgraded
On Thu, 6 Oct 2022 14:38:38 +0200
> This is good point. I have already forget the details. So if there
> was embedded just the right amount of information in the main data,
> we would not need the full list (and lazy loading). Currently, the
> data contains e.g. /usr/bin/*, which is useful for
Dne 06. 10. 22 v 14:38 Vít Ondruch napsal(a):
Dne 06. 10. 22 v 14:18 Panu Matilainen napsal(a):
On 10/6/22 11:55, Vít Ondruch wrote:
Dne 06. 10. 22 v 9:18 Otto Liljalaakso napsal(a):
Miro Hrončok kirjoitti 6.10.2022 klo 2.33:
On 06. 10. 22 1:21, Otto Liljalaakso wrote:
Recently, I have
V Thu, Oct 06, 2022 at 08:17:15PM -0500, Richard Shaw napsal(a):
> I'm still getting this on occasion and have no idea what the issue is:
>
> $ fedpkg new-sources OpenImageIO-2.4.4.2.tar.gz
> Uploading: OpenImageIO-2.4.4.2.tar.gz
> #
> 52.0%Could not execute
https://bugzilla.redhat.com/show_bug.cgi?id=2132720
--- Comment #5 from Fedora Update System ---
FEDORA-2022-27b66516ad has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
On Thu, Oct 06, 2022 at 01:22:01PM -0400, Robbie Harwood wrote:
> Daniel P. Berrangé writes:
>
> > We need PCRs to cover at minimum
> >
> > 1. Machine firmware
> > 2. Bootloader(s)
> > 3. Bootloader configuration
> > 4. Booted kernel
> > 5. Booted initrd
> > 6. Booted cmdline
>
> >
On 07. 10. 22 12:56, Vít Ondruch wrote:
Dne 06. 10. 22 v 19:51 Miro Hrončok napsal(a):
On 06. 10. 22 15:04, Kalev Lember wrote:
I guess a transition plan (if we make up our minds that it makes sense to do
it) could be to first make sure the provides are autogenerated, then do a
mass rebuild,
https://bugzilla.redhat.com/show_bug.cgi?id=2132803
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #1 from
Dne 06. 10. 22 v 19:51 Miro Hrončok napsal(a):
On 06. 10. 22 15:04, Kalev Lember wrote:
I guess a transition plan (if we make up our minds that it makes
sense to do it) could be to first make sure the provides are
autogenerated, then do a mass rebuild, let people try it out in their
packages
Hi all,
Fedora Developer Portal contains information various information on
technologies that require update from time to time to work with current
Fedoras.
We have identified a few pages that require updating as they contain old
information,
outdated (or unsupported) versions of the
I took a look at epel-rpm-macros. Interestingly, in EPEL9,
the package has "Recommends: fpc-srpm-macros". [0]
Despite this, when I try building in the side tag,
the package isn't pulled in. I guess koji is configured
not to pull in weak deps?
Anyway, I've opened a PR on epel-rpm-macros
to change
On 07. 10. 22 9:33, Petr Pisar wrote:
Does EPEL have any communication channel to EPEL users besides this mailing
list? If it does, do you plan to announce this change there? Preferably ahead
of time.
I worry that users do not follow a list called epel-devel because they think
it's only for
https://bugzilla.redhat.com/show_bug.cgi?id=2132720
--- Comment #4 from Fedora Update System ---
FEDORA-2022-27b66516ad has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-27b66516ad
--
You are receiving this mail because:
You are on the CC list
https://bugzilla.redhat.com/show_bug.cgi?id=2132720
Fedora Update System changed:
What|Removed |Added
Status|MODIFIED|CLOSED
Resolution|---
https://bugzilla.redhat.com/show_bug.cgi?id=2132720
Fedora Update System changed:
What|Removed |Added
Status|ASSIGNED|MODIFIED
--- Comment #2 from
https://bugzilla.redhat.com/show_bug.cgi?id=2132803
Jitka Plesnikova changed:
What|Removed |Added
CC|caillon+fedoraproject@gmail |
|.com,
V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
> - epel-release will be updated.
> -- epel-modular will set enabled = 0
Does it only mean releasing a new epel-release package with epel-modular
configuration file set to "enabled = 0", or does it also involve more magic
like
40 matches
Mail list logo
