On Thu, 2025-05-22 at 11:15 -0400, Matthew Miller wrote:
> The lack of a defined process for situations like this needs to be
> addressed
> before such a decision can be made, including provisions for
> appropriate
> warnings and chances to respond by the contributor. In addition, the
> announcemen
On Thu, 2024-12-19 at 00:31 +0100, Javier Martinez Canillas wrote:
> I don't understand what was the goal exactly of making this a public
> announcement rather than just notifying the decision to the affected
> person. And I also don't understand what was the hurry to do it
> before
> having a publ
On Fri, 2024-12-13 at 17:33 -0800, Josh Stone wrote:
> The Fedora Proven Packager Policy[1] reads: “Provenpackagers lend a
> hand
> when help is needed, always with a desire to improve the quality of
> Fedora. Prior to making changes, provenpackagers should try to
> communicate with owners of a pac
On Wed, 2024-07-24 at 22:13 +0200, Albert Larsan wrote:
> Know that this is one of the cases that is explicitly not covered
> under
> the stability guarantee, i.e that code without warnings may get
> warnings
> on the next version
Agreed.
> This, the crate should fix the bug, and a one-line pat
On Wed, Jul 24, 2024 at 06:03:10PM -, Emanuel Lima wrote:
> It's kata-containers. It works from 1.75 to 1.78 but not with 1.79.
>
> I opened an issue upstream:
> https://github.com/kata-containers/kata-containers/issues/10067
One more note: You could also work around this by patching that one
On Wed, Jul 24, 2024 at 06:03:10PM -, Emanuel Lima wrote:
> It's kata-containers. It works from 1.75 to 1.78 but not with 1.79.
>
> I opened an issue upstream:
> https://github.com/kata-containers/kata-containers/issues/10067
For what it's worth, this isn't really a true issue. It looks like
On Wed, Jul 24, 2024 at 11:29:43AM -0300, Emanuel Lima wrote:
> To build the package that I maintain, I need a specific version of rustc,
> 1.75. Given that the default buildroot has rustc 1.79, how do I create a
> new buildroot (or side tag) just for my package with this specific rustc?
Rust shou
As a tangent on this thread, it would be cool if there were a mechanism
in dnf to tell users when an upgrade needs special
attention/instructions. Another example like this is postgresql updates,
which also require manual intervention.
--
___
devel ma
On 7/7/23 19:59, Demi Marie Obenour wrote:
That is not consent. The GDPR explicitly states that consent must
be opt-IN.
I agree.
I think it is important to make it possible for a user to ask for the
data collected from their machine to be deleted in the event they
mistakenly submitted data,
On 4/26/23 08:42, Kevin Kofler via devel wrote:
As I see it, the main roadblocks for new packagers are:
* accepting the FPCA,
* getting sponsored,
* learning the Packaging Guidelines, and
* getting their package(s) through review,
and that last point can be a roadblock even for existing packagers
On 4/26/23 11:25, Matthew Miller wrote:
Use j/k to scroll up and down (ah, vi, your legacy will live forever)
According to Wikipedia, it's actually the ADM-3A:
https://en.wikipedia.org/wiki/ADM-3A#Legacy
I recently learned this, and find it fascinating ☺
__
On 4/21/23 14:05, Matthew Miller wrote:
Accessiblity is important to Fedora, and I take this seriously. For
Discourse, hit the ? key to bring up the page describing keyboard shortcuts.
One thing I don't care for when it comes to web apps and keyboard
shortcuts is that they are non-standard. Wh
On Thu, 2022-08-18 at 14:01 -0700, Kevin Fenzi wrote:
> Thoughts?
♥ nspawn ♥
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
On Thu, 2022-04-07 at 17:02 -0400, Simo Sorce wrote:
> > I like Zbigniew's plan too! But I gotta ask, what is "FWMOIW"?
>
> For What My Opinion Is Worth :-)
I also hadn't seen this acronym, but I was hoping it was going to be
some kind of cipher since Simo works on the crypto team ☺
signature.a
On Wed, 2021-06-30 at 14:31 +0200, Tomas Tomecek wrote:
> After reading your explanation of how gentoo does packaging, it
> indeed makes a lot of sense and feels like that most of the
> concerns I pointed out have solutions or could be mitigated.
>
> The biggest problem I personally see is the eff
On Wed, 2021-06-30 at 01:01 +, Randy Barlow via devel wrote:
> An example of this is gstreamer - in Gentoo I just have
> gstreamer installed, and the various plugin packs like good bad and
> ugly are just USE variables on that one package.
Ooops, I was wrong on this example. They d
On Tue, 2021-06-29 at 15:36 +0200, Tomas Tomecek wrote:
> > On the "uni-repo" counter proposal: there's a bunch of real-world
> > examples here of distributions using this successfully:
> >
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md#unified-sour
On 7/3/20 12:41 PM, Chris Murphy wrote:
# rm -rf/var/lib/mysql/
# mv/var/lib/mysql2/ /var/lib/mysql/
## resume operation
BTW this should be proofread/sanity checked, especially because
there's an rm command (that will fail in the original).
You also might need a restorecon after this, since
On 6/25/20 1:54 PM, Randy Barlow wrote:
I would like to counter propose that we make ed the default editor :P
Just in case it wasn't clear, I was joking here. I support nano as a
default. Let's make Fedora easier for new users, especially those who
are new to the command line an
On 6/25/20 1:18 PM, Ben Cotton wrote:
Let's make Fedora more approachable, by having a default editor that
doesn't require specialist knowledge to use.
I would like to counter propose that we make ed the default editor :P
___
devel mailing list -- dev
On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how
the team historically worked. As a team we are being tasked more and
more with adding what I call real value which is at a new app / service
level that has scale, quality and requiremen
On 4/6/20 11:17 AM, Leigh Griffin wrote:
It's a form of engagement among others that we are partaking in day in
day out, week in week out.
Ironically, you have illustrated my point here with your response, which
isn't engagement.
I have answered every question directly, if I missed one in th
On 4/6/20 11:02 AM, Leigh Griffin wrote:
Ok let's scenario this out so as several people want us to restart and
go again, largely because they disagree with the decision and Pagure is
the choice that they would have made.
Much of the consternation is due to you not having employed an open
pro
On 4/6/20 10:36 AM, Leigh Griffin wrote:
Answering 100+ replies individually is engaging with the community.
Happy to stop that if people aren't seeing the benefit of it though.
Writing 100 e-mails isn't automatically "engagement".
I could reply to what you wrote above with "If I had a world o
On 4/6/20 8:28 AM, Miro Hrončok wrote:
I think it's hard to see who's vocal against GitLab and who just wants a
truly open decision process for this.
I've heard people who would love to get GitLab, but who are genuinely
sad about how CPE management handled this.
This. I personally actually l
On 4/6/20 6:41 AM, Leigh Griffin wrote:
We are engaged with the Fedora Council on the next steps here for the
adoption of Gitlab / the retirement of Pagure from the CPE remit. That
much of the decision has been made, the actual specifics are what we are
engaging on to make sure that the Fedora
On 4/6/20 6:37 AM, Leigh Griffin wrote:
I'm sorry if you took my mail up as implying a lack of value from how
the team historically worked.
It's a classic no-no to start an apology with "I'm sorry *if you*". It's
not an apology at all, it's a defense disguised as an apology. It is
thus dishon
On 4/6/20 6:13 AM, Leigh Griffin wrote:
CPE is entirely unique in this industry and is not perfectly aligned to
the idealistic software engineering process, we are getting there.
No software team is perfectly aligned to the idealistic software
engineering process. CPE is not unique in that eithe
On 4/4/20 3:02 PM, Aoife Moloney wrote:
However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.
It's simply not true that this is the only thing that can be d
On 4/3/20 4:41 PM, Leigh Griffin wrote:
This is how a specific flavour of software development works centered on
a singular product, with a shared vision. The CPE relationship with
stakeholders is unique, it's clear the visions are not aligned across
all bodies (and we do not expect it to be) a
On 4/3/20 3:08 PM, Leigh Griffin wrote:
It may have caught that for sure but it would have opened a lot more
problems as stakeholders try to counter each others requirements with
new more specific requirements to influence the decision.
This is how software development is *supposed* to work. I
On 4/3/20 1:53 PM, Neal Gompa wrote:
Honestly, the main app I have trouble seeing a broader community for
is Bodhi. It*could* be done, but I'd have to sit down and do a fair
bit of work to figure out what parts are "Fedora-only" verses
"Fedora-favored". It speaks volumes that even*Red Hat* does
On 4/2/20 3:03 AM, Adam Williamson wrote:
At the outset of this whole mess, quite a lot of people said "well this
is obviously just all a pretext for dropping Pagure and going to hosted
Gitlab". Much offence seemed to be taken at this, and much was made of
this absolutely not being the case at al
On 4/1/20 1:16 PM, Adam Williamson wrote:
Has it been demonstrated that either Pagure or Gitlab CE are
"not viable" for the purposes Fedora needs?
Hey Adam!
I agree with you that Pagure and Gitlab CE are both viable for Fedora's
needs in terms of feature matrices and requirements. We have shi
On 4/1/20 11:25 AM, Felix Schwarz wrote:
I don't want to presume too much but I just hope you researched why packagedb
was decommissioned and why people thought integrating the functionality into
pagure was a good idea?
pkgdb was decommissioned because modularity needed a lot of changes
across
On 3/10/20 12:17 PM, Ron Olson wrote:
is there a way to pass the body.template.last file to ‘fedpkg update’ so
I don’t have to fill it out for every single release, or fill it out
again when I get a timeout and have to rerun fedpkg update?
See the --file flag on bodhi updates new. It's not exa
On 3/9/20 11:53 AM, Fabio Valentini wrote:
Source-only rust packages (those only shipping noarch -devel
subpackages) have been untagged from f32 on purpose by Igor. For
reasons I disagree with:)
I too wish that we kept the Rust devel packages in stable releases. I am
unable to build updates fo
On 2/25/20 3:12 PM, Ankur Sinha wrote:
Basically, packages do not pass review merely because they use good
licenses.
Note that I just said that I thought it was the primary purpose, not the
only purpose.
___
devel mailing list -- devel@lists.fedorap
On 2/21/20 9:57 AM, Martin Sehnoutka wrote:
Every time there is a new release it would automatically synchronize our
own Fedora-specific registry, which would in turn be accessible in
buildroot.
One thing that comes to my mind with this proposal is that we still need
some way to vet licenses.
I plan to orphan js-jquery-noty unless someone wants to maintain it.
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
erlang-jose has changed licenses from MPLv2.0 to MIT.
https://src.fedoraproject.org/rpms/erlang-jose/c/cb981bf5
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe se
On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
> cough cough errata cough cough
>
> Honestly, sometimes the disconnect between what is going on in Fedora
> and internally in Red Hat is intriguing.
I did think about Errata tool* a bit back when I worked on Bodhi. I
like the idea of sharing
On Wed, 2020-01-29 at 09:43 +, Richard W.M. Jones wrote:
> Also AIUI fedpkg chain-build doesn't work except in
> Rawhide, although I'm not sure why that is?
It doesn't work in stable because you need to create buildroot
overrides for each dependency before you can proceed with building the
nex
On Tue, 2020-01-28 at 09:03 +, Richard W.M. Jones wrote:
> If you want to go even further with this idea, then it could even be
> possible we allow packages into Fedora without any review. They
> would
> start in the outermost stream in a "there be dragons" repository that
> only the foolhardy
This documentation seems to be out of date:
https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_become_the_default_assignee_of_a_branch_in_bugzilla.3F
I say that because the cited repository hasn't had commits since
December 09.
How do we set the default assignee of a bran
On Tue, 2020-01-14 at 00:30 +0100, David Kaufmann wrote:
> The field for bodhi I usually copy from the changelog - but to be
> honest I only fill it, because it's there - I don't even really know
> what it is used for, except being shown on the update page.
Users can read the update text with the
On Sat, 2020-01-11 at 11:19 -0600, Martin Jackson wrote:
> I don't know if things like pipx exist for other scripting
> languages, but do other people think that's worth exploring?
> (Currently pipx uses tox in what seems like a weird way, and we'd
> need to package userpath and tox-venv to make th
On Mon, 2020-01-13 at 12:28 +0100, Pierre-Yves Chibon wrote:
> If I tag foo 1.0 with a first changelog entry, then koji builds 1.0-1
> with that changelog.
I think it would be better if the release were part of the git tag,
instead of automatically generating it. Not all packages use an integer
f
On Fri, 2020-01-10 at 14:37 +0100, Pierre-Yves Chibon wrote:
> For historical reasons, bodhi treats the "greenwave_failed" status as
> "passed", so it will not gate updates if greenwave failed to give it
> a go/nogo answer.
It's not historical, or we wouldn't be discussing this - the message
means
I have orphaned js-jquery-file-upload.
___
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/
List
Would anybody like to maintain js-jquery-file-upload? If not, I will
orphan it.
https://src.fedoraproject.org/rpms/js-jquery-file-upload
signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproj
On Wed, 2019-11-13 at 04:30 -0500, Ben Cotton wrote:
> I don't think that's a fair characterization. For example, the FESCo
> representative is appointed by FESCo, which is 100% community-
> elected.
>
> Breaking it down, three seats (FPL, FCAIC, FPgM) are positions for
> specific Red Hat employee
On Tue, 2019-11-12 at 09:24 -0500, Matthew Miller wrote:
> Have the same opportunity to participate in leadership.
Only two of the council seats are elected. The rest are appointed, and
some of those appointed only by specific Red Hat employees.
Thus, I don't think it's exactly the same opportuni
On Wed, 2019-11-06 at 21:32 +0100, Miro Hrončok wrote:
> Is there any good way to get notified about this sort of problems in
> timely manner prior to the update being pushed? This is currently not
> optimal.
I'm not familiar with an existing solution to this problem, but I agree
that it is not op
On Wed, 2019-11-06 at 00:20 -0700, John M. Harris Jr wrote:
> This only works to a limited degree in Gentoo, and even then, if you
> want a stable system, you can't really install different versions of
> packages as X version of Y package will break package Z, generally
> not in the ebuild either.
On Tue, 2019-11-05 at 21:17 -0500, Neal Gompa wrote:
> This feature of "slotting" multiple EVRs of the same name actually
> already exists in RPM. DNF currently restricts this to packages that
> contain one of the following provides:
> * installonlypkg(kernel)
> * installonlypkg(kernel-module)
> *
hink 1. is by far superior (even though it is more work), and
> AFAIK, FPC
> and FESCo mostly agree: in fact, Fedora ships packages that do 1.,
> but not
> packages that do 2. (SCLs have basically been rejected in Fedora).
Agreed.
> langdon wrote:
> > > * compat-libs (or
On Tue, 2019-11-05 at 19:13 -0500, Randy Barlow wrote:
> For packagers who want to put the same spec file in all branches
> today (I think Kevin Koffler often likes to do this)
*Kofler - sorry for misspelling your name Kevin.
signature.asc
Description: This is a digitally signed messag
On Wed, 2019-11-06 at 01:24 +0100, Kevin Kofler wrote:
> Actually, it could also mean that Gentoo users are just in a habit of
> not complaining, no matter what. :-) After all, those are the same
> users who find it perfectly fine that installing the kernel or
> LibreOffice takes days (at least in
On Tue, 2019-11-05 at 19:00 -0500, Stephen Gallagher wrote:
> Randy, I think you are misinterpreting Matthew’s statements here.
> You’re attributing malice and dismissiveness where “text is a poor
> communication medium” is a valid answer.
Hi Stephen,
Text is a poor communication medium. I've wor
Hi Adam!
On Tue, 2019-11-05 at 15:24 -0800, Adam Williamson wrote:
> This has a few consequences I can think of. For a start it means the
> actual problem we're currently having with our current module streams
> wouldn't necessarily be solved by your system - we could've run into
> exactly the sam
On Tue, 2019-11-05 at 14:14 -0500, Matthew Miller wrote:
> Well, exactly. This is what I meant with my short "who is going to do
> that work?" comment. Gentoo's solution is not a drop-in thing for
> Fedora and would require changes to RPM, DNF, and the *significant*
> work of figuring out what all
On Tue, 2019-11-05 at 17:19 -0500, Stephen Gallagher wrote:
> Others have contacted me privately and indicated that my choice of
> words here did not convey the tone that I had intended. It makes it
> sound as if I am accusing people of being disingenuous.
For what it's worth, I didn't take it tha
Thanks for writing this post Langdon!
On Tue, 2019-11-05 at 12:55 -0500, langdon wrote:
> * The two most promising candidates, Gentoo's slots (etc) and nix
> both
> require a substantial user experience change both as a command line
> person and in how / where things land in the OS. We believe t
On Tue, 2019-11-05 at 14:57 -0500, Neal Gompa wrote:
> Yeah, the reason OpenPKG was able to do this is because their flavor
> of RPM had specific enhancements for it:
> * Macros used in the spec had their definitions embedded into the
> SRPM
> * Generated package names and provides were discoverabl
On Tue, 2019-11-05 at 12:11 -0500, Matthew Miller wrote:
> But, I still am having a hard time seeing the thing I quoted as a
> respectful
> approach. I avoided paraphrasing before, but I'm going to now, not to
> caricature what Randy said but to clarify how it sounds to me and
> what I'm
> reacting
On Mon, 2019-11-04 at 20:40 -0500, Matthew Miller wrote:
> I actually quoted less than the entire message before because I felt
> like the rest of it was even more inflammatory and trolling and I
> didn't want to escalate.
Accusing someone of trolling is not consistent with the actions of a
person
On Mon, 2019-11-04 at 14:20 -0500, Matthew Miller wrote:
> It would be useful for that contributor to be able to say "I build
> these
> packages so I can ship the thing I'm invested in, but... user and
> other
> contributors, beware".
> Now, solving that isn't in the requirements modularity, but i
On Mon, 2019-11-04 at 14:12 -0500, Matthew Miller wrote:
> That said, it's hard to read "I see it as a solved problem and I
> don't
> understand why we are trying to solve it again" as ... helpful.
>
Consider the message that comments like this one and your last post
send. I took the time to thou
On Sun, 2019-11-03 at 20:28 +0100, Miro Hrončok wrote:
> On 03. 11. 19 20:24, Miro Hrončok wrote:
> > Hero maintenance
>
> I don't normally correct my typos on mailing lists to avoid further
> e-mails, but
> this one is particularly bad. I meant "zero" of course. Sorry about
> that.
I disagree t
On Mon, 2019-11-04 at 03:18 +0100, Kevin Kofler wrote:
> > *Requirement*: Users must be able to discover what alternative
> > software
> > versions are available with tools that are shipped with the OS by
> > default.
> > Ideally, these should be the same tools that they are already
> > comfortable
This is a repost from
https://blog.electronsweatshop.com/join-us-in-redhat-cpe-on-freenode.html
tl;dr; join us in #redhat-cpe on Freenode!
Many moons ago, Red Hat merged the CentOS infrastructure team with the
Fedora Infrastructure team, into a team known as "Community Platform
Engineering" (CPE)
On Mon, 2019-10-28 at 15:35 -0400, Neal Gompa wrote:
> If we could operate on spec files and SRPMs, then the Gentoo solution
> gets to be an interesting option.
Yeah that's what I'm suggesting - to study Gentoo's solution and to
make similar changes to our tooling to achieve a similar solution. I'
On Mon, 2019-10-28 at 15:33 -0400, Randy Barlow wrote:
> Gentoo's solution to "too fast, too slow" addresses every requirement
> in this post, except for this one:
>
> On Mon, 2019-10-28 at 10:08 -0400, Stephen Gallagher wrote:
> > Requirement: Packagers mus
Gentoo's solution to "too fast, too slow" addresses every requirement
in this post, except for this one:
On Mon, 2019-10-28 at 10:08 -0400, Stephen Gallagher wrote:
> Requirement: Packagers must be able to encode whether their output
> artifacts are intended for use by other projects or if they ar
On Fri, 2019-10-25 at 09:43 +0200, Pierre-Yves Chibon wrote:
> That is true, but the wording used also implied that this design has
> not been
> considered.
The question of whether other designs have been considered has been
raised many times over the years, and I've not seen it claimed that
yes,
On Thu, 2019-10-24 at 08:09 -0400, Stephen Gallagher wrote:
> There's a very large difference between feedback like "I think the
> user experience is suboptimal here, for this reason" and "I don't
> like the entire design, you should scrap it and start over".
>
> In the first case, it's possible t
On Wed, 2019-10-23 at 12:58 -0400, Matthew Miller wrote:
> Are you proposing to _do_ those things, or proposing that someone
> else
> oughta?
This feels like an attempt to suggest that I have made a demand when I
have not. I'm willing to give you the benefit of the doubt, but I
suggest avoiding la
On Wed, 2019-10-23 at 14:41 +0200, Petr Šabata wrote:
> We
> currently don’t have any other proposal that would fulfill the vision
> of our Objective and the needs of our users.
How do the proposals I've mentioned not fulfill the goals?
signature.asc
Description: This is a digitally signed mess
On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> Packaging in Fedora is
> definitely harder than it used to be. We still haven't really
> recovered from
> pkgdb retirement, various infra tools don't have enough support, etc.
> No easy solutions to this problem either, but I t
On Mon, 2019-10-21 at 14:00 +, Zbigniew Jędrzejewski-Szmek wrote:
> The problem is hard. If there was an obvious solution, we wouldn't be
> having this discussion.
I've pointed out a few times that other distros have solved the "too
fast, too slow" problem. In at least one case, as long ago as
On Mon, 2019-10-21 at 09:16 -0400, Stephen John Smoogen wrote:
> The problem is that COPRs do not have any way of communicating with
> each other. If I grab from copr-A and it has libfoo-2.3.1-1 and I
> grab
> from copr-B and it has libfoo-2.3.2-2 then I am going to replace
> copr-A's packages whic
On Fri, 2019-10-18 at 11:21 -0400, Robbie Harwood wrote:
> Obviously we
> can't use their code wholesale without migrating to APT, but as you
> say,
> the goal is to derive inspiration.
I honestly think it should be on the table to consider switching to a
different packaging technology than rpm/dn
On Thu, 2019-10-17 at 15:04 -0400, Stephen John Smoogen wrote:
> Not without using their packaging system, their build system and
> their
> other design choices.
Frankly, this is not a bad caveat. Keep in mind that we also had to
change our build system for modularity.
> Working out slots would
On Thu, 2019-10-17 at 08:08 -0400, Stephen Gallagher wrote:
> One of the (often un- or misinformed) major arguments people keep
> using against Modularity is "it makes packaging harder!".
One thing I've found to be a problem with modularity is that it's easy
to be un- or misinformed. I spent a lot
On Thu, 2019-10-17 at 12:56 -0400, Randy Barlow wrote:
> I
> had to write a yaml file that listed hashes of every dependency of
> rpick, and every dependency of those dependencies, and their
> dependencies, and so on.
By the way, I didn't actually end up doing this, Igor did it
On Thu, 2019-10-17 at 10:52 -0400, Randy Barlow wrote:
> I've always liked Gentoo's solution to "too fast too slow"
> with their slots mechanism.
I realized it would be good if I explained what this is in more detail
for those who aren't familiar.
The slot is an
On Thu, 2019-10-17 at 11:19 +0100, Peter Robinson wrote:
> It doesn't obsolete it if it's already transitioning from testing ->
> stable because it's basically not in "testing" state. This happens
> all
> the time even during the usual cycle, it's generally just not seen
> during the usual cycle be
On Thu, 2019-10-17 at 08:08 -0400, Stephen Gallagher wrote:
> One of the (often un- or misinformed) major arguments people keep
> using against Modularity is "it makes packaging harder!". This is one
> place where it makes things *much* easier on the packagers. It's a
> clear reduction in complexit
On Thu, 2019-10-17 at 03:53 +0200, Kevin Kofler wrote:
> The user-friendly approach for that is to use a parallel-installable
> compatibility package (with a suffixed Name, such as django1.6)
> instead of a
> module.
I've always liked Gentoo's solution to "too fast too slow" (which has
been arou
On Thu, 2019-10-03 at 19:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> > As pointed out elsewhere, we would have fewer conflicts if we could
> > get
> > the version, release, and changelog out of the spec file, and then
> > I
> > think maintaining different spec in different release branches
> > w
On Fri, 2019-10-11 at 14:34 -0700, Adam Williamson wrote:
> That seems like a personal call, really. I very much like being able
> to
> keep branches in sync without merge commits as it means I can do
> stuff
> like:
>
> for i in el6 epel7 f29 f30 f31 master; do fedpkg switch-branch $i;
> git
> pu
On Sat, 2019-10-05 at 02:38 +0200, Kevin Kofler wrote:
> No. Resolving conflicts implies that you need to do an actual merge,
> NOT a
> fast forward. Fast-forwarding means that I am shipping the SAME
> commit on
> all branches, so the changelog must be identical (unless I play games
> with
> %if
On Thu, 2019-10-03 at 11:58 +0200, Kevin Kofler wrote:
> I even go as far as reverting branch-only commits and then doing the
> bidirectional merge trick to restore fast forwardability. That of
> course
> clobbers the branch-only changelog section and replaces it with the
> one from
> master, bu
On Fri, 2019-09-27 at 10:26 +0200, Michal Konecny wrote:
> There is still possibility to use libraries.io
> instead of Anitya, but there are some issues:
> - lack of downstream mapping (this could be easily solved by some
> database with only downstream mapping)
> - lack of custom project additio
I am updating dogpile.cache to 0.8.0 on Rawhide, and it has switched
from BSD to MIT:
https://github.com/sqlalchemy/dogpile.cache/commit/474a9a329f86e4c2d1cdf6e35e346979c9dd07c6
https://src.fedoraproject.org/rpms/python-dogpile-cache/c/b6bac12befdace274a1c21a215fc2e9a1236da0a?branch=master
signa
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> > ○ Every commit to dist-git (ie: PR merged) is automatically built
> > in koji
> > ○ Every build in koji results automatically in an update in bodhi
>
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don'
On Thu, 2019-09-26 at 19:05 +, Jeremy Cline wrote:
> The tag also provides a nice place to write release notes for the
> update. I suppose you could also add support for some sort of text
> tag
> inside commits (like when you mark a commit as fixing an issue in
> Git{Lab,Hub} and look at the co
On Thu, 2019-09-26 at 14:49 +, Jeremy Cline wrote:
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don't want to build it (specfile cleanup, patches,
> configuration
> changes, etc.). I want a build that goes to users be explicit.
>
> A better model, in my
On Thu, 2019-09-26 at 08:58 -0700, Brian C. Lane wrote:
> I'm also not clear on where the .spec files and tests would live if
> you
> are using a fork of the upstream. We still need dist-git to store
> those,
> even if everything that touches them is a tool other than vim. Or
> maybe
> I missed som
1 - 100 of 422 matches
Mail list logo
