ols
So I would guess that many packagers have followed this advice and
have it installed on their systems. I certainly do.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproje
packages out there that aren't in modules, or
don't necessarily need to be in modules-- unless parts of the
distribution start becoming module-only.
(Maybe this discussion belongs in a new thread, but I think it's important).
Ben Rosser
___
t of the reason I haven't tried it is because
I'm not sure if it will actually be better...
I guess it would be nice to read a sort of "modularity for the
skeptical contributor" document or article that answers questions like
this.
Ben Rosser
___
ide change proposal, and I think generally
similar policies should be applied when considering major changes to
the distribution's infrastructure. And the mailing lists are
definitely an important part of the distribution's infrastructure.
Ben Rosser
quire switching
one list over and seeing how well it works (and it sounded like the
Council was considering doing this with council-discuss, which is
probably a good first step).
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscr
advocating the change
seem unwilling to acknowledge this, or have dismissed it as people who
aren't willing to move with the times, or as just "hyperbole".
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
at this briefly a while ago-- it seems to me like
verilog-mode is now part of emacs-common:
$ rpm -qf /usr/share/emacs/26.1/lisp/progmodes/verilog-mode.elc
emacs-common-26.1-3.fc28.x86_64
Is the stand-alone emacs-verilog-mode package necessary anymore, or
can it just be re
very well to add default streams of modules to the buildroot
automatically-- I think that makes sense, if it can be done in a way
that's transparent to end users and packagers. But-- unless I'm
missing something obvious-- this isn't enough, unless every
et shipped on laptops than
Fedora. Instead of working on a new "Fedora LTS" for this usage case,
would time be better spent improving EPEL and CentOS for the
desktop/laptop use case? I'd always thought of CentOS/RHEL as "Fedora
LTS" anyway, to be honest.
Ben Rosser
_
On Wed, Nov 14, 2018 at 6:04 PM Stephen John Smoogen wrote:
>
> On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote:
> >
> > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen
> > wrote:
> > > From what I have talked with in the past.. 3 years is their bare
>
On Mon, Jan 8, 2018 at 12:58 PM, Rob Crittenden wrote:
> Florian Weimer wrote:
>> On 01/08/2018 06:21 PM, Steve Dickson wrote:
>>> Is it a problem for a package to pull from two different
>>> upstream tar balls? Basically have
>>>
>>> Source0:http://server.com/package1/package1.tar
>>> Source1:htt
esponses on the pull request you linked within the last
week, including from the maintainer 5 days ago. I'm not sure how this
qualifies as "unresponsive"?
https://src.fedoraproject.org/rpms/net-snmp/pull-request/2#comment-3999
Ben Rosser
_
On Tue, Feb 6, 2018 at 1:09 PM, Robert-André Mauchin wrote:
> Hello,
>
> I have a handful of packages that I'd like to be reviewed. I'm available for
> any reviews you want in exchange (to the best of my ability).
Hello,
I'm happy to take ddgr and QEverCloud. Are you willing to review the
follow
sure it's worth it for a single line.
Well... personally, it's pretty annoying to have to remove this from
every spec I generate using rpmdev-newspec. It also gives the
impression that the newspec-generated specs might be outdated in other
respects too.
I don't know how ot
ocgen tilp2
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
s onto describe technical details about
dist-git and then includes a "user's guide", which is helpful... if
you are a user trying to set up infrastructure. It's not very relevant
to a packager trying to learn their way around things.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
ckages were orphaned and no one was particularly interested in
stepping up to take them over. I ended up taking some of them with the
hopes of keeping a few pieces of software alive in the short term, but
then another large chunk of nodejs packages were orphaned, no one took
them, and, frankly, I gav
roviding
these packages (https://copr.fedorainfracloud.org/coprs/jonludlam/opam/)
about a year ago and never heard back, so... technically I guess I
could proceed with the non-responsive maintainer policy. But is that
the right thing to do?
Thanks in advance,
Ben Rosser
On Wed, Jul 19, 2017 at 9:40 AM, Richard W.M. Jones wrote:
> The story with this package (and I think there were some others) is
> that they are required for 'opam' which is a source-based OCaml
> packaging tool (think: Perl and the ‘cpan’ command). Jon Ludlam
> turned up wanting to get opam into
someone from flagging their bodhi update as "newpackage" when
it's not, in fact, a new package to bypass the batching, but this
seems like something that should be easy to do.
Thanks,
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
dea - care to propose it on the pull request yourself
> since it was your idea? This is the line where an "or self.type is
> newpackage" would go:
>
> https://github.com/fedora-infra/bodhi/pull/1678/files#diff-6406e7faaf25263056c68009517cf66dR2376
Certainly; I've left a
gration!-- but the lack of one seems like an annoying but small
regression.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
e interested in submitting prename to the review queue in
addition to your other packages, I would be happy to take the review.
I see you've already been sponsored, which is great!
Ben Rosser
___
devel mailing list -- devel@lists.fedor
ge to need the
change process, but it should be discussed) making rename into an
alternative.
[1]
https://stackoverflow.com/questions/22577767/get-the-perl-rename-utility-instead-of-the-built-in-rename
[2] https://fedoraproject.org/wiki/Packaging:Alternatives
Ben Rosser
__
or at least giving
a brief statement about your goals for the position, should be a
*requirement* for running for an elected position in the project.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
?
>
> I'm not sure where I should file a bug.
>
> Thanks,
> Dridi
The same thing happened to me for my recently retired packages.
When I inquired on IRC yesterday, I was told to file a bug against
infra, so I did here:
https://pagure.io/fedora-infrastructure/issue/6256.
Ben Ross
e for
modularity-- on a short timescale in a half-baked manner (as you said)
is an example of how it's all too easy *for* it to happen.
Respectfully, this does not inspire confidence in how well the rollout
of modularity across the entire distribution will go.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
on
my system in order to interact with the different parts of the
packaging plumbing. It seems to me that in an ideal world it would
only require one mechanism to interact with all these services.
That mechanism doesn't need to be Kerberos, bu
d this; I'd be happy to take it.
> In rpmfusion (free):
>
> * openmw -- Unofficial open source engine re-implementation of the game
> Morrowind ( master f26 f25 f24 )
I would be happy to take this one too. I've requested ACLs via RPM Fusion pkgd
tential concern under the rug with the "taking the distro hostage"
comment, which I think is an overly excitable way to phrase a
legitimate concern.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
https://koji.fedoraproject.org/koji/packageinfo?packageID=23320
https://koji.fedoraproject.org/koji/packageinfo?packageID=23342
This makes me slightly dubious about the rest of the list.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
7;s not clear to me why; as far as I
knew, they both passed the mass rebuild. Or, rather, the binutils mass
rebuild: https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild.
I haven't touched the packages since then.
I'd be interested to know if this has happened to any of the other
pac
n an older version.
(I'd be happy to remake it from scratch on a new NextCloud
installation, though. I figured I would probably have to do that
anyway at some point).
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsu
urned up a blog post
or two, an ask.fp.o post, a couple forum threads, and a Stack Exchange
post as the first few results, which makes me believe it's not
currently well explained anywhere in our documentation? Perhaps that
should be fixed, regardless whatever the outcome of this change
discussi
On Thu, May 31, 2018 at 7:29 PM, Adam Williamson
wrote:
> On Thu, 2018-05-31 at 19:19 -0400, Ben Rosser wrote:
>> So, back to the topic of this thread: while I don't think this choice
>> belongs in the installer, I do think there should be detailed
>> instructions some
arning
to use the new infrastructure, which is making it really hard for
packagers to stay up to speed. It doesn't help that this stuff isn't
always communicated clearly.)
Ben Rosser
[1]
https://fedoraproject.org/wiki/Join_the_package_collect
d
to require someone's approval (FESCo? FPC?) to maintain a package
outside of Fedora dist-git. Then at least the number of such packages
could be hopefully kept low.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
lves; some external body or
person should need to sign off on it first.
And as Matthew said, perhaps a requirement for approving this
arrangement could be that the packager in question agrees to respect
changes in dist-git (or automatically opened Pagure pull requests, or
whatever) made by other
101 - 138 of 138 matches
Mail list logo
