Re: User experience issue on btrfs

2020-07-04 Thread Randy Barlow
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Randy Barlow
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 and/or Linux

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-25 Thread Randy Barlow
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 --

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Weekly: 2020-04-04

2020-04-06 Thread Randy Barlow
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

Re: CPE Weekly: 2020-04-04

2020-04-06 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-06 Thread Randy Barlow
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

Re: CPE Weekly: 2020-04-04

2020-04-04 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-03 Thread Randy Barlow
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)

Re: CPE Git Forge Decision

2020-04-03 Thread Randy Barlow
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.

Re: CPE Git Forge Decision

2020-04-03 Thread Randy Barlow
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*

Re: CPE Git Forge Decision

2020-04-02 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-01 Thread Randy Barlow
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

Re: CPE Git Forge Decision

2020-04-01 Thread Randy Barlow
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

Re: submitting bodhi.template.last to fedpkg update?

2020-03-11 Thread Randy Barlow
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

Re: Reducing broken dependencies in fedora (32) repositories

2020-03-11 Thread Randy Barlow
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

Re: Include non-RPM content in buildroot

2020-02-25 Thread Randy Barlow
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 --

Re: Include non-RPM content in buildroot

2020-02-21 Thread Randy Barlow
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

Anybody want js-jquery-noty?

2020-02-17 Thread Randy Barlow
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

erlang-jose license change

2020-02-17 Thread Randy Barlow
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

Re: Git Forge Requirements: Please see the Community Blog

2020-01-30 Thread Randy Barlow
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

Re: Ideas for better development processes when maintaining hundreds of packages

2020-01-29 Thread Randy Barlow
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

Re: Ideas for better development processes when maintaining hundreds of packages

2020-01-28 Thread Randy Barlow
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

Default bugzilla assignee

2020-01-22 Thread Randy Barlow
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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-15 Thread Randy Barlow
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

Re: Let's talk about Fedora in the '20s!

2020-01-13 Thread Randy Barlow
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

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

2020-01-13 Thread Randy Barlow
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

Re: This update's test gating status has been changed to, 'greenwave_failed'.

2020-01-13 Thread Randy Barlow
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

Re: Orphaning js-jquery-file-upload

2019-11-25 Thread Randy Barlow
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

Orphaning js-jquery-file-upload

2019-11-18 Thread Randy Barlow
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 --

Re: Modularity and all the things

2019-11-13 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-12 Thread Randy Barlow
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

Re: Getting notified on broken deps from updates-testing

2019-11-06 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-06 Thread Randy Barlow
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.

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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) > *

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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 compat lib styl

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity: The Official Complaint Thread

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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 >

Re: Modularity and all the things

2019-11-05 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-04 Thread Randy Barlow
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

Re: Modularity and all the things

2019-11-04 Thread Randy Barlow
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

Re: ask.fedoraproject.org - redirects?

2019-11-04 Thread Randy Barlow
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

Re: Fedora Modularity: What's the Problem?

2019-11-04 Thread Randy Barlow
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 > >

Join us in #redhat-cpe on Freenode

2019-10-31 Thread Randy Barlow
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"

Re: Fedora Modularity: What's the Problem?

2019-10-28 Thread Randy Barlow
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.

Re: Fedora Modularity: What's the Problem?

2019-10-28 Thread Randy Barlow
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 mu

Re: Fedora Modularity: What's the Problem?

2019-10-28 Thread Randy Barlow
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

Re: Modularity and all the things

2019-10-25 Thread Randy Barlow
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,

Re: Modularity and all the things

2019-10-24 Thread Randy Barlow
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

Re: Modularity and all the things

2019-10-24 Thread Randy Barlow
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

Re: Modularity and all the things

2019-10-23 Thread Randy Barlow
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

Re: Modularity and the system-upgrade path

2019-10-21 Thread Randy Barlow
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

Re: Modularity and the system-upgrade path

2019-10-21 Thread Randy Barlow
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

Re: Modularity and the system-upgrade path

2019-10-21 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-18 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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 for

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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 another fiel

Re: Do F31 updates not obsolete each other during freeze?

2019-10-17 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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

Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-17 Thread Randy Barlow
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

Re: Defining the future of the packager workflow in Fedora

2019-10-11 Thread Randy Barlow
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 > >

Re: Defining the future of the packager workflow in Fedora

2019-10-11 Thread Randy Barlow
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 >

Re: Defining the future of the packager workflow in Fedora

2019-10-11 Thread Randy Barlow
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 >

Re: Defining the future of the packager workflow in Fedora

2019-10-03 Thread Randy Barlow
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,

Re: Defining the future of the packager workflow in Fedora

2019-09-27 Thread Randy Barlow
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

dogpile.cache has switched to the MIT license

2019-09-27 Thread Randy Barlow
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

Re: Defining the future of the packager workflow in Fedora

2019-09-26 Thread Randy Barlow
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

Re: Defining the future of the packager workflow in Fedora

2019-09-26 Thread Randy Barlow
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

Re: Defining the future of the packager workflow in Fedora

2019-09-26 Thread Randy Barlow
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

Re: Defining the future of the packager workflow in Fedora

2019-09-26 Thread Randy Barlow
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

Re: Fedora 31 Beta Release Announcement

2019-09-19 Thread Randy Barlow
On Wed, 2019-09-18 at 23:24 +0200, Kevin Kofler wrote: > And if an otherwise maintained package FTBFS, if it does not actually > need > any change, I don't see how this is even an issue at all. FTBFS packages can get CVEs filed against them and then they can be difficult to fix. There are a few

Re: Fedora 31 Beta Release Announcement

2019-09-18 Thread Randy Barlow
On Tue, 2019-09-17 at 19:15 -0400, Stephen John Smoogen wrote: > fork it and make Memdora for low memory systems. If you make Memdora, then you will also need to think of four values that start with M: Mriends Mreedom Mirst Meatures signature.asc Description: This is a digitally signed message

Re: Intent to orphan php-gettext-gettext

2019-09-05 Thread Randy Barlow
On Thu, 2019-09-05 at 10:41 +0530, Sundeep Anand wrote: > ah, sorry I didn't mention that; fas: suanand Done, and thanks! signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Intent to orphan php-gettext-gettext

2019-09-04 Thread Randy Barlow
On Wed, 2019-09-04 at 11:12 +0530, Sundeep Anand wrote: > Hi Randy, > > I have some interest maintaining it. Is your FAS account sundeepanand? If so, it doesn't appear that you are a Fedora packager at the moment. signature.asc Description: This is a digitally signed message part

Intent to orphan php-gettext-gettext

2019-09-03 Thread Randy Barlow
Greetings! I plan to orphan php-gettext-gettext in a week, unless someone else wants to take care of it. I originally packaged it so I could add Ampache to Fedora, but that project was far more difficult than I expected and I decided to abandon it. signature.asc Description: This is a digitally

Re: Intent to orphan: php-maennchen-zipstream-php

2019-06-18 Thread Randy Barlow
On Wed, 2019-06-05 at 12:23 -0400, Randy Barlow wrote: > I intend to orphan php-maennchen-zipstream-php. This package is now orphaned. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- de

[EPEL-devel] Bodhi 4 in EPEL 7

2019-06-13 Thread Randy Barlow
Greetings! Fedora Infrastructure recently deployed Bodhi 4.0.0 to production, which included quite a few backwards incompatible changes[0]. Some of the changes have resulted in older Bodhi clients (less than 4.0.0) not being compatible with the new version of the server. In Fedora, FESCo decided

Backwards incompatible python-cryptography-2.7

2019-06-05 Thread Randy Barlow
Greetings! I was looking at updating python-cryptography in Rawhide today, and I noticed that there's a note about a backwards incompatible change: https://bugzilla.redhat.com/show_bug.cgi?id=1715680#c2 Does anyone object to applying this update in Rawhide? signature.asc Description: This is

Backwards incompatible python-cryptography-2.7

2019-06-05 Thread Randy Barlow
Greetings! I was looking at updating python-cryptography in Rawhide today, and I noticed that there's a note about a backwards incompatible change: https://bugzilla.redhat.com/show_bug.cgi?id=1715680#c2 Does anyone object to applying this update in Rawhide? signature.asc Description: This is

Intent to orphan: php-maennchen-zipstream-php

2019-06-05 Thread Randy Barlow
Greetings! I intend to orphan php-maennchen-zipstream-php. I originally packaged it as part of an effort to get Ampache into Fedora, but I ran out of steam a long time ago and don't otherwise use this package. If you want it let me know, otherwise I'll orphan it in about a week or so.

Re: Another ceph build stuck in pending testing, four days

2019-06-03 Thread Randy Barlow
On Sun, 2019-06-02 at 18:03 -0400, Kaleb Keithley wrote: > https://bodhi.fedoraproject.org/updates/FEDORA-2019-60ba61b5ab > > Why does this happen every time? > > Would someone please kick it? Thanks I filed an issue about this for you: https://pagure.io/fedora-infrastructure/issue/7871

Re: Bodhi 4.0.0 deployed, one known issue so far

2019-05-30 Thread Randy Barlow
On Thu, 2019-05-30 at 16:13 +0200, Robert-André Mauchin wrote: > I've installed Bodhi 4 from Rawhide but fedpkg doesn't seem to be > compatible > with it yet: > > Could not execute update: This system has bodhi v4, which is > unsupported. https://pagure.io/fedpkg/issue/330 signature.asc

Re: Bodhi 4.0.0 deployed, one known issue so far

2019-05-29 Thread Randy Barlow
On Wed, 2019-05-29 at 20:29 +0200, Fabio Valentini wrote: > I just noticed one other thing: fedora-easy-karma is now broken, > because the REST API doesn't return the "anonymous" field on comments > anymore, which the tool checks for. See https://pagure.io/fesco/issue/2137 signature.asc

Re: Bodhi 4.0.0 deployed, one known issue so far

2019-05-29 Thread Randy Barlow
On Wed, 2019-05-29 at 17:51 +0200, Fabio Valentini wrote: > If you're already working on fixing bugs - searching in the web > interface also seems to be broken. > Entries on an autocompleted result in the "package" section link to a > (usually non-existent) user page. That's surprising, and

Re: Bodhi 4.0.0 deployed, one known issue so far

2019-05-29 Thread Randy Barlow
On Wed, 2019-05-29 at 11:58 -0400, Josh Boyer wrote: > Could you make a container image based on F30 that can be run on > F29/EPEL 7/8? That offers users a way to use the new tool on the OS > of their choice and avoids you having to write new code or bring back > a bunch of dependencies to the

[EPEL-devel] Re: Updateinfo file is not valid XML - Zchunk support?

2019-05-29 Thread Randy Barlow
On Wed, 2019-05-29 at 14:36 +, Anderson, Charles R wrote: > I'm getting this error as of last night on all of my CentOS 7 boxes: > > /etc/cron.hourly/0yum-hourly.cron: > > Updateinfo file is not valid XML: '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1 >

Re: Bodhi 4.0.0 deployed, one known issue so far

2019-05-29 Thread Randy Barlow
On Tue, 2019-05-28 at 20:22 -0600, Orion Poplawski wrote: > Perhaps this is the source of: > > # /etc/cron.hourly/0yum-hourly.cron > Updateinfo file is not valid XML: '/var/cache/yum/x86_64/7/epel/92f2e15cad66d79ea1ad327e2af7af89d98e4d1 > 53d7a3e27ff41946f476af5b4-updateinfo.xml.zck', > mode

  1   2   3   4   5   >