filed against
> the package.
The main assignee for the firefox package has been going to /dev/null
for many many years. ;)
Just not having email notifications doesn't always mean the package
isn't being maintained. For example, there are groups that just handle
bugs via queries and d
o merge.
* If the bug isn't a packaging one, perhaps try engaging with upstream?
If the bug is known/fixed there it would get pulled in the next release
hopefully...
Its a hard balance. There's way more bugs than people to fix them, so
sometimes there's no good answer.
kevin
On Fri, Apr 25, 2025 at 03:55:40PM +0200, Fabio Valentini wrote:
> On Thu, Apr 24, 2025 at 12:52 AM Kevin Fenzi wrote:
> >
> > So, some things I wonder about this process (in no particular order):
> >
> > If this lightweight process is easier, will not people just
.
Yeah, this is old data I think using the old countme stuff.
I think there is definitely interest in fixing it up. I think that would
probibly happen before flock.
So, I wouldn't use this for much right now...
kevin
--
___
devel mailing list -- d
3 (which this change is for) _will_ have removed it
upstream.
In that sense, isn't this just a 'hey, heads up, this is going away in
f43' change?
kevin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
7;s
not working out.
kevin
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/e
On Thu, Apr 17, 2025 at 12:27:26AM +0200, Fabio Valentini wrote:
> On Wed, Apr 16, 2025 at 10:04 PM Kevin Fenzi wrote:
> >
> > On Tue, Apr 15, 2025 at 06:21:20PM +0200, Fabio Valentini wrote:
> > ...snip...
> >
> > > The only remaining blocker fr
hat is possible.
I'd be happy to help.
kevin
--
___
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-co
; https://gitlab.com/fedora/docs/docs-website/docs-fp-o/-/blob/stg/site.yml#L109
I'm happy to work with any websites / packaging / docs folks to get this
done.
> Please reply with other examples so we can have a TODO list.
> (Not just branch names, but that is the least-effo
or the like, but
note that some functionality may be missing if you do. In particular in
the past (but I have not tested at all recently), screen locking may not
work (since it depended on the 'gdm' session being there).
kevin
--
___
devel mailing
Kevin Fenzi wrote:
> On Wed, Apr 09, 2025 at 03:35:06PM -0400, Eduard Lucena wrote:
>> Can we go ahead in time and let kevin to create the gdm-x11 package? We
>
> Sure, if he wants to?
I do not currently have plans to introduce that package, though I would
encourage people
On Wed, Apr 09, 2025 at 03:35:06PM -0400, Eduard Lucena wrote:
> Can we go ahead in time and let kevin to create the gdm-x11 package? We
Sure, if he wants to?
But I'll note that as far as I know, upstream plans to remove this in
the upcoming gnome cycle, so you would need to re-add it
ges would not exist in Fedora today
if it were not for me and my perseverance over this issue.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Co
Neal Gompa wrote:
> You need to switch to another display manager, as GDM no longer
> supports X11 sessions.
Time to fork GDM.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to de
if GDM is not the display manager being used
(which is another issue, but not a new one, and not Fedora's fault).
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fed
Jared K. Smith wrote:
> On Wed, Apr 9, 2025 at 12:59 PM Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> This crusade against X11 in Fedora needs to stop NOW!
>>
>
> I'm not involved in this change -- but I take exception to your l
a Change? If yes, I'd argue that it should be reverted
> and done in F43 with a proper Change.
Note that this was a DOWNSTREAM Fedora change, upstream GDM still supports
X11 sessions!
This crusade against X11 in Fedora needs to stop NOW!
Kevin Kofler
--
___
n. It should be easily possible for anyone interested to build a
gdm-x11 package in Fedora without even patching the upstream code (at this
time – patching might become required in a later version).
Kevin Kofler
--
___
devel mailing list -- de
an see, is a specific subpackage…
> kf5-sonnet-aspel
… and the same goes for Sonnet.
For the other reverse dependencies:
> eiskaltdcpp-qt
> perl-Text-Aspell
> php-pspel
> recoll
> yagf
it might be harder to make them use something else
rsions).
if(IS_ABSOLUTE path) has been supported since forever.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedor
Kevin Fenzi wrote:
> Ideally things would just be more resistant to being able to make the
> mistakes in the first place, but sometimes thats not easy to do.
As far as I can see, things are quite resistant already considering that the
gating has blocked this from going into Rawhide. :-)
I
li, @michich, @salimma
> dledford has a bugzilla override on rpms/qperf
> dledford is maintainer of rpms/rdma-core
kevin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraprojec
Planned Outage - updates / reboots - 2025-03-26 21:00UTC
There will be an outage starting at 2025-03-26 21:00UTC
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2025-03-26 21:00UTC'
R
On Fri, Mar 21, 2025 at 02:58:46AM +, Gary Buhrmaster wrote:
> On Thu, Mar 20, 2025 at 6:15 PM Kevin Fenzi wrote:
>
> > As a side note: if this sort of thing happens and you need something
> > untagged for some reason, please file a releng ticket.
> > ( https://pagu
kage
> libfido2-1.15.0-3.fc42.x86_64
> - cannot install the best update candidate for package
> libcbor-0.11.0-3.fc42.x86_64
As a side note: if this sort of thing happens and you need something
untagged for some reason, please file a releng ticket.
( https://pagure.io/releng )
Thats likely
idate tag (ie,
f42-updates-candidate),
which any maintainer can do with a 'koji tag-build f42-updates-candidate
NVR).
kevin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedorapr
the
> > frama-c build now fails in Rawhide:
> >
> > We seem to have zero cmake builds tagged into Rawhide at the moment.
>
> Yep.
> cmake-3.31.6-1.fc43 /
> https://koji.fedoraproject.org/koji/buildinfo?buildID=26
and needs to be fixed.
Removing those -D arguments from the %cmake macro is a completely gratuitous
backwards-incompatible change that will break a whole bunch of specfiles for
no good reason.
Kevin Kofler
--
___
devel maili
gt; https://pagure.io/releng/issue/12617
> https://pagure.io/fedora-infrastructure/issue/12112
Just FYI, this should be fixed (for rawhide at least) now.
kevin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em
the tool.
I think having a rpm would be awesome and agree with your reasons.
That said, we shouldn't say it's a requirement for Infrastructure.
We already deploy some applications other ways and don't have a hard
requirement on an rpm being available anymore.
But w
feedback as they can.
kevin
--
___
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/
Li
-6.1.3-13.fc42
> for F43. Maybe the error is somewhere else.
I can never recall what the flow is for those.
I think it's something strange like mdapi to packager-dashboard or
something. But obviously it's not right. :(
So, we should probibly look and see if we can
k it's a good first step. The only thing I don't like is
> > having to track
> > somebody down to do the untagging. Maybe under a special request a few of
> > us could be
> > given the powers to untag?
>
> In practice how this generally works is "I fil
name=linux-*&branch=master&repo=&arch=&origin=
Especially for mobile devices, it is usual to have a separate kernel fork
for every device. Even for a close-to-mainline distribution such as
postmarketOS – we are not even talking about downstream Android kernels
here!
Kevin Kofl
a good thing. Even more so if we are
talking about megabytes, not just kilobytes.
We are already accumulating way too many size increases. (For a comparison,
F10-x86_64-Live-KDE.iso was 684M, Fedora-KDE-Live-x86_64-41-1.4.iso is 2.6G.
That is almost a factor 4 increase from Fedora 10 to Fedora
gure.io/fedora-infrastructure/issue/12425
I was fighting this all day yesterday, but I think it's now fixed.
See https://pagure.io/fedora-infrastructure/issue/12419
and do let me know (in the ticket) if you see any failures
after about 02:00 UTC on today (2025-02-27).
kevin
--
__
(adding maintainer to cc)
On Tue, Feb 18, 2025 at 03:03:10PM +0100, Andreas Schneider wrote:
> Hi,
>
> we are trying to get a rebuild of rizin [1] but the maintainer doesn't react.
> Same applies to the co-maintainer. I've created a non-responsive maintainer
> bugzilla ticket at [2].
>
>
> Be
owser, so
thats why it's redirecting to localhost. :(
I'm not sure how off hand to get this working in a container.
I suppose you could do a push outside the container and copy the token
in?
kevin
--
___
devel mailing list -- de
On Thu, Feb 13, 2025 at 12:15:16PM -0500, Dusty Mabe wrote:
>
>
> On 2/13/25 11:42 AM, Kevin Fenzi wrote:
> > I agree with downthread folks that that seems like way too high a
> > failure rate to enable gating on. However, a few questions if I can:
> >
> > I
nable (non gating) these to show up
there so maintainers/you can be more aware and help reduce problems?
Also, I see in the table a few packages have really high failure rate.
(nbdkit, makedumpfile, etc). Perhaps fixing these would lower the entire
failure rate a good de
Mario Torre wrote:
> On Tue, Feb 11, 2025 at 2:11 AM Kevin Kofler via devel
> wrote:
>>
>> Mario Torre wrote:
>> > OpenJDK 11 is EOL in Fedora regardless of the Fedora version, it hasn’t
>> > been updated in January for example.
>>
>> This is
ant to take care of that, they should orphan the package and let
somebody else push the required security updates.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
m opposed to this. Bundling is discouraged in Fedora for reasons that are
well documented. It does not make sense to exempt individual programming
languages wholesale from that. Vendoring is already allowed if there really
is no other way to make something work, but it should not be the default.
On Mon, Feb 10, 2025 at 09:13:57AM +0100, Dan Horák wrote:
>
> I suppose it's related to the status of the "http-ipsilon" service
> reported as critical on the sysadmin list, so the admins should know
> about it.
Yes, there was a outage of auth and koji. ;(
So
e updated then? It looks recent,
> it mentions `f42`. Updating the wiki, anyone can benefit,
> not only me.
> Thanks and bye,
> Milan
>
> [3] https://fedoraproject.org/wiki/QA/Test_Days/Live_Image
Yeah, that page needs a rework for sure. ;(
kevin
--
___
be identified. Perhaps we could move the
mass rebuild to another time, but I would need to ponder on that more.
Thanks for the discussion!
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubs
for work accross components
* wishlist items "add accessability", "fix hibernate"
* I don't know what "install didn't work" (with no more info), etc
Anyhow, we don't have to solve that now, but we should definitely think
about it.
kevin
--
_
or "testing"
> state) during the mass branching will end up in a weird state, and
> will always require manual action to fix and end up in a consistent
> state.
>
> In most cases, submitting a new build for rawhide (now F43) and F42
> should work (assuming the gating fa
ve admin access?
> https://src.fedoraproject.org/rpms/babeltrace , for example.
You will need to contact someone who is an admin for the package(s) to
remove you. ;(
Or, I suppose if it's a long list and there's difficulty contacting
ev
Full logs at:
https://meetbot-raw.fedoraproject.org//meeting_matrix_fedoraproject-org/2025-02-04/fesco.2025-02-04-17.00.log.txt
=
# #meeting:fedoraproject.org: fesco
=
Meeting started by @nirik:matrix.scrye.com at 2025-02-04
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org
on Matrix.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2025-02-04 17:00 UTC'
Links to all issues to be
7;s no automation.
If you would like to submit the same package, just submit your new
review and close the stalled one as a duplicate.
kevin
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lis
I'd like to plug
https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/
for next time.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to dev
nded. Also this doesn't work for big global changes like
rpm payload changes or global packaging changes. Or at least it delays
them 6 months.
I don't see what we gain by doing the mass rebuild after branching.
All 3 of your points are valid. If the FTBF
On Thu, Jan 30, 2025 at 11:13:24PM +0100, Neal Gompa wrote:
> On Thu, Jan 30, 2025 at 11:05 PM Kevin Fenzi wrote:
> >
> > On Wed, Jan 29, 2025 at 07:18:23AM -0500, Matthew Miller wrote:
> > > On Tue, Jan 21, 2025 at 08:21:26AM -0500, Neal Gompa wrote:
> > > >
entify
those packages. Perhaps we could move to requiring change owners to
identify all packages they want to have rebuilt?
Of course we also have had cases were we did want to actually rebuild
everything (rpm payload changes, etc).
kevin
signatu
On Tue, Jan 28, 2025 at 07:32:49PM +0100, Vít Ondruch wrote:
>
> Dne 28. 01. 25 v 19:18 Kevin Fenzi napsal(a):
...snip...
> > Mass rebuilding which? Rawhide or the new branched? Or both?
>
>
> I am talking about Rawhide
>
>
> > rawhide would be fine, but a
t build of foo
tag into side-tag (because draft builds can be in the buildroot)
do a build of bar
If everything is well, promote foo to real and submit sidetag
If everything is bad, iterate on foo with more drafts until the foo/bar
unit works.
But yeah, if we were doing automatic builds draf
would have to be made again
in branched when found.
branched would be bad because then we would have to fix rawhide, but
rawhide is supposed to be ahead of branched so we are working backwards.
both is a gigantic waste of resources, double builds, more bugs, more
churn for maintainers.
kevi
area, please do look and chime in in the
ticket.
> So the F42FTBFS blocker bug already exists
> (https://bugzilla.redhat.com/show_bug.cgi?id=F42FTBFS).
> It's possible that one of your package was affected by the double-run
> and wasn't "cleaned up" prope
without an immediate functional
> impact like the SPDX changes.
>
> That said, I agree with Kevin that we should have the compose reports list
> anything in the compose whose state is "The commit at the HEAD of the
> `rawhide` branch does not match the commit used for the latest
ff the build. Then the maintainer would only need to
> do 'git pull && fedpkg build' if everything is OK.
I guess you mean for the case where something was built before the mass
rebuild, but stuck in gating/side tag and should be rebuilt with the
tools from the m
an it would find the foo-1.0-1 commit in git and bump that
to foo-1.0-2 and just revert the foo-2.0-1 commit?
In the end I think if we find fixing these cases too anoying/frequent,
we probibly need to look at all the existing sidetags before the mass
rebuild and tell pe
For those of you who don't read the community blog,
(and you really should!)
I thought I would raise awareness of a post from today:
https://communityblog.fedoraproject.org/fedora-datacenter-move-later-this-year-2025-version/
kevin
--
___
Planned Outage - updates / reboots - 2025-01-29 21:00UTC
There will be an outage starting at 2025-01-29 21:00UTC
which will last approximately 5 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2025-01-29 21:00UTC'
R
Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org
on Matrix.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/UTCHowto
or run:
date -d '2025-01-21 17:00 UTC'
Links to all issues to be
ebuild commit lands and the build runs.
You can/should use the normal workflow even duing the mass rebuild and
it should work fine.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproj
On Sun, Jan 19, 2025 at 03:36:32PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Jan 18, 2025 at 10:04:28AM -0800, Kevin Fenzi wrote:
> > > The only way that works, is what mockchain does: build the packages in
> > > random order. if any fails, repeat while at least on
ould of course make things take longer and would
be a waste of cpu/etc, and it would generate more notification noise to
maintainers, but it might save work in the end? Most of the failing
packages would likely fail pretty fast too.
kevin
signature.asc
Description: PGP signature
--
IM.
> I would just say any domain with SPF + DMARC, but without DKIM just
> has a broken mail config & not our problem. All use of mailing lists
> is doomed in that scenario unless every list takes countermeasures
> to rewrite From. Not worth the hassle for Fedora IMHO.
mailing
; strict DMARC rules by the "via devel" that gets appended to their names.
Right.
I don't know of any existing software setup that does this, so
one would have to be written. :) (not me).
kevin
signature.asc
Description: PGP signature
--
___
The f42 mass rebuild is waiting on golang 1.24 landing in the buildroot.
See:
https://pagure.io/releng/issue/12527
Once thats sorted out we will start the mass rebuild.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list
Or we could just look at sunsetting these aliases as modern email
continues to make it less tenable.
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@l
/coprs/amatej/createrepo_c/
until createrepo_c is updated.
kevin
signature.asc
Description: PGP signature
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le
On Thu, Jan 09, 2025 at 06:51:18PM -0800, Brendan Conoboy wrote:
> On Thu, Jan 9, 2025 at 3:53 PM Michel Lind wrote:
> > Ahh, the perfect person to deal with our s390x capacity crunch ;)
> >
>
> Yes! Actually, I think Kevin and IT just applied a bandaid that has made a
>
e to emulate Neoverse N1, N2 & V1, so running a software
> emulated qemu-system-aarch64 virtual machine may be the way to go.
> (https://fedoraproject.org/wiki/Architectures/AArch64/Install_with_QEMU)
We do have some maintainer test machines if that would help:
https://fedoraproject.org/w
uy new one to replace
it.
We have come to expect that from proprietary software, including the
proprietary NVidia driver, but for Free Software, this is a new low.
Introducing a compatibility package is the least we can do. Ideally, the
project should be forked upstream to restore support for
s anymore, and
someone could reply to devel list quoting the report from another list.
So, I'm kinda on the fence anymore.
It's worth noting that they already do go to the test-reports list, so
if we decide to drop them here we should just point people there instead
of making
sue perhaps?
Is it still happening for you?
If so, please file a infrastructure ticket and we can try and figure it
out.
Sorry for the slow reply, but while I was keeping an eye out for
tickets, I wasn't keeping up on mailing lists.
kevin
signature.asc
Description: PGP signature
--
_
Oh, one additional item I wanted to mention...
I wonder if we could encourage maintainers/community members to do
something like this:
https://cassidoo.co/post/remote-intros/
TLDR: a small page listing your contact prefs, timezones, etc.
kevin
signature.asc
Description: PGP signature
On Mon, Dec 09, 2024 at 10:09:44AM -0800, Kevin Fenzi wrote:
> Hey folks.
>
> In 1 week, I'd like to bump libntlm from 1.6 to 1.8.
> This involves a soname bump.
>
> Affected are I think (gkrellm and libgsasl).
> Maintainers bcced here.
>
> I ran a mpb o
npackagers from those arches to push fixes?
I would argue yes, but again communication is very important.
I do think a new gitforge may be a good chance for us to adjust our
workflows both to it and to better serve everyone.
kevin
signature.asc
Description: PGP signature
--
___
mohanboddu, orphan, tibbs
> >
>
> I can't think of any reason this shouldn't simply be retired. All of
> the SCM processing is now handled via a completely different method, and
> I doubt the tool has any utility at
Turns out there was something deeper going on here. There was a rebase
that was somehow stuck and causing problems.
See:
https://pagure.io/releng/issue/12497
I think I have it all fixed up now.
kevin
signature.asc
Description: PGP signature
.
This seems to be some kind of race and we have seen it before.
We can use an admin tool to reset the state and you can delete and
re-create the fork.
I have now done that on this fork... so, delete it and refork and things
should work.
kevin
signature.asc
Description: PGP signature
creation of a ticket in the packager sponsor project on
> pagure:
>
> https://pagure.io/packager-sponsors/issue/690
>
> I have reached out on Matrix on #devel:fedoraproject.org a few times but I
> didn't get any response yet.
>
> Is there anybody that would be
rsubscribed (the old ones have 3 vcpus each), but I will
move them to 2 cpus over time. That does mean some builds might be
slower, but the majority of the builds will get to a builder faster and
get processed instead of waiting for long running builds.
Do let us know how it looks after this cha
Hey folks.
In 1 week, I'd like to bump libntlm from 1.6 to 1.8.
This involves a soname bump.
Affected are I think (gkrellm and libgsasl).
Maintainers bcced here.
I ran a mpb on the 1.8 version and both those packages built fine.
https://copr.fedorainfracloud.org/coprs/kevin/libntlm/pac
On Fri, Dec 06, 2024 at 08:30:15PM -0800, Kevin Fenzi wrote:
> On Sat, Dec 07, 2024 at 03:03:04AM +, Bojan Smojver via devel wrote:
> > Looks like bodhi upgrade may have caused composes to go haywire today:
> > https://bodhi.fedoraproject.org/composes/
> >
> > It
that is around.
Yeah, already looking into it.
kevin
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
On Tue, Dec 03, 2024 at 11:11:42AM +, Christopher Klooz wrote:
> Kevin and I have already worked on this in a pagure ticket (I experienced it
> as well frequently in the past):
> https://pagure.io/fedora-infrastructure/issue/11962
>
> I already posted this mailing list threa
at least add a link to a ticket to the "orphan reason"?
This was due to the main admin of that package being removed from the
packager group for inactivity...
https://pagure.io/fedora-infrastructure/issue/12277
Last cycle I did a devel-announce with the list of newly orp
ion on my PinePhone!)
As for this particular update, IMHO, anything breaking eduroam is completely
unacceptable in an update for a stable release and should never have made it
through testing. It should be reverted immediately.
Kev
Dominik 'Rathann' Mierzejewski wrote:
> Dirac codec support is optional in the above.
It still means that the claim that nothing is using this library anymore is
false.
Kevin Kofler
--
___
devel mailing list -- devel@lists.fedo
kagers/issue/2055
So the package was orphaned when they were removed.
At least as far as I can tell...
kevin
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
this a recent change in
> behaviour?
Perhaps the same thing as this thread:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GG4LQYBEKGWAGFSJ5PKTKJAOHLAB3A27/#QYIK5E642MDB4NGBXLRLLTMU7HAJOVV5
ie, debugedit 5.1?
kevin
signature.asc
Description: PGP signatur
Kevin Kofler via devel wrote:
> PS: I suspect the documentation was actually just an attempt to document
> the previous broken Bodhi policy implementation. (See
> https://github.com/fedora-infra/bodhi/issues/772 and
> https://github.com/fedora-infra/bodhi/issues/1033 – both got close
to ignore it if it has a more efficient alternative, as was in fact
already suggested in the discussion of the change (but refused by the change
owners). Backwards compatibility is something that needs to be retained
wherever possible.
Kevin Kofler
--
___
roved at +2 because of the hardcoded check. So that is where the +2
probably came from.
So it is a combination of multiple Bodhi glitches that ended up accidentally
encoded in the documentation and now made it back into Bodhi in a strict
reinterpretation.
I think it kinda makes critpath pointless if we
Kevin Kofler via devel wrote:
> When was this decided? I only remember FESCo ever having decided to
> require +2 for critpath updates, not for non-critpath ones.
>
> At some point, those values were written down in the documentation, but
> under what authority? Where was the FES
1 - 100 of 7457 matches
Mail list logo
