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
On Fri, Jun 26, 2020 at 12:46 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Fri, Jun 26, 2020 at 12:38:40PM -0400, Ben Rosser wrote:
> > On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
> > wrote:
> > >
> > > On Thu, Jun 25, 2020 at 01:18:59PM -0400
> usage a bit nicer. 'vi' and 'emacs -nw' don't ask.
The -t/--tempfile switch for nano (and pico) does exactly this:
https://linux.die.net/man/1/nano
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
lt was *actively harmful* to vi's chances
> in my case. :P
Same here, to be honest. Being dropped into vi when I ran some command
(I think it was visudo?) was honestly pretty traumatizing as a new
Linux user a ~decade ago, and to this day one of the first things I do
on
On Tue, Jun 23, 2020 at 7:23 PM Miro Hrončok wrote:
>
> On 24. 06. 20 1:10, Miro Hrončok wrote:
> > On 24. 06. 20 1:07, Ben Rosser wrote:
> >> Some of my nodejs packages are an artifact of a failed attempt to
> >> package quassel-webserver [1], which I eventually
On Tue, Jun 23, 2020 at 6:38 PM Miro Hrončok wrote:
>
> On 23. 06. 20 21:11, Ben Rosser wrote:
> > Thanks Miro, much appreciated!
>
> You are welocme.
>
> However, I am afraid I have some bad news. The recent report in
> https://churchyard.fedorapeople.org/orphans.tx
On Tue, Jun 23, 2020 at 5:24 PM Stephen Gallagher wrote:
>
> On Mon, Jun 22, 2020 at 11:53 AM Ben Rosser wrote:
> >
> > On Mon, Jun 22, 2020 at 11:34 AM Sérgio Basto wrote:
> > >
> > > On Mon, 2020-06-22 at 11:29 -0400, Ben Rosser wrote:
> > > > O
guess I'll find out.)
> >
> > Can I do this via releng ticket or do I need to actually go to each
> > page on Pagure and click the button?
>
> I've done it in bulk. Thanks for talking them.
Thanks Miro, much appreciated!
Just to add: I've also taken uglify-js
nly wanted to take
what I actually needed for mocha and discord-irc. I think this is the
complete list; if I'm wrong, I guess I'll find out.)
Can I do this via releng ticket or do I need to actually go to each
page on Pagure and click the button?
Ben Rosser
Ben Rosser
___
On Mon, Jun 22, 2020 at 11:34 AM Sérgio Basto wrote:
>
> On Mon, 2020-06-22 at 11:29 -0400, Ben Rosser wrote:
> > On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher <
> > sgall...@redhat.com> wrote:
> > > The Node.js SIG is very loosely organized. If you are a pack
top their retirement?
I've gone ahead and taken mocha (running tests will be useful
regardless of whether or not we start bundling NPM modules). I haven't
yet figured out what I need to take to keep it + my other node
packages alive for now, but I'll work through that this eveni
On Wed, Jun 17, 2020 at 12:50 PM Fabio Valentini wrote:
>
> On Wed, Jun 17, 2020 at 6:30 PM Ben Rosser wrote:
> >
> > On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith
> > wrote:
> > >
> > > On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser wrote:
> > &
On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith wrote:
>
> On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser wrote:
>>
>> So... this is a lot of node.js packages, and I haven't really seen any
>> discussion of this on the lists. And at least some of these are possibly
n packages for a node application [1] and its
dependencies, and it's increasingly difficult due to old dependencies, even
when they're not FTBFS or FTI or orphaned. I don't have the bandwidth to
take over all of these, but I'd be willing to join some kind of collective
effort to impr
eriod of time... and
nothing I've read in any of these threads so far has helped reassure
me that's not the case.
Not saying you're wrong that it would be nice to have the ability to
poll a broader selection of packagers. But I'm not sure using
On Thu, Feb 13, 2020 at 12:01 PM Jerry James wrote:
>
> I'm trying to get an f32 branch for a newly created package. Branch
> creation has failed twice now with the error in $SUBJECT:
>
> https://pagure.io/releng/fedora-scm-requests/issue/22127
>
> Can I get a human to look at that ticket instead
re.io/releng/issue/9236
Thanks in advance,
Ben Rosser
___
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
of
that RPM?
(I realize that in this particular case, Igor is on FESCo, and so had
the policy been followed more carefully, he would have been aware
anyway).
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email
On Tue, Dec 3, 2019 at 3:18 AM Tom Hughes wrote:
>
> Ben Rosser was working on sorting out grunt. In fact I believe he
> took the first of those at least.
>
> Tom
>
> On 03/12/2019 07:45, Vít Ondruch wrote:
> > According to [1], these are the packages which need to
pkgdb before implementing new features like stream
expansion.
But in any case, I'm really glad that we do now finally have anitya
integration and easy de-orphaning back in pkgdb. Thanks to everyone
who made this happen!
Ben Rosser
___
maintainer first:
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Getting_a_Fedora_package_in_EPEL
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscrib
ora. We should decide what is and isn't acceptable to
modularize, what the rules are and aren't for creating and upgrading
streams, and so on. And if we can't figure out a way to square the
goals for modularity with the necessary guidelines to not cause major
problems in the distri
It's certainly true that the loudest and most unhappy voices tend to
dominate discussions, but so far I haven't seen many people speak up
who are enthusiastic about modularity who aren't also involved in it
in some way.
Granted, that could well change over time as improvements
ideline compliant)
6. rpmbuild -bs && mock ../SRPMS/foo*.src.rpm until it builds (and is
guideline compliant)
7. Upload somewhere when it is ready for review
I agree that this might not be the ideal workflow to teach new
packagers, but I don't think it is terrible.
Pagure showed that information too. If nothing else, it
would save me a click or two when trying to check if a package is up
to date.
> Trying to improve the package review process is something that has been in my
> radar for a while now but n
w request if
>> we can get this unretired before the deadline.
>
>
> It looks like this has been un-retired, so I'll go ahead and try to push an
> updated build to rawhide just as soon as the Koji outage is over.
Oops, I missed that you had requested a re-review.
Thanks! L
On Wed, Oct 2, 2019 at 8:17 PM Ben Rosser wrote:
>
> On Wed, Oct 2, 2019 at 1:59 PM Pierre-Yves Chibon wrote:
> > There are regularly people complaining on this very list about how hard
> > packaging has become. So here is a thread trying to see if you can come up
> &
n than it is
the first thing most new contributors will interact with, so perhaps
it is in our interest to make it as pleasant as possible.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lis
tired just under eight weeks ago for being FTBFS-- on
2019-08-08. Hopefully it still is within the deadline for not
requiring rereview (that's eight weeks on Thursday)!
I'll submit a releng ticket, and am notifying devel as requested by the policy.
S
On Thu, Sep 26, 2019 at 5:29 PM Pierre-Yves Chibon wrote:
>
> On Thu, Sep 26, 2019 at 04:46:32PM +0200, Ben Rosser wrote:
> > On Thu, Sep 26, 2019 at 4:29 PM Pierre-Yves Chibon
> > wrote:
> > > There is a clear initial rejection of a PR-only contribution model. I
>
a bad idea
and won't improve things. We need to keep the simple/everyday use
cases in mind here.
I like that I can build a Fedora package with just a specfile--
essentially, a bit of metadata about how to build and install a
package-- and don't need to
the
use case of the "ordinary packager", not the "expert packager". And I
think that's packages with limited divergence from upstream (only a
few patches) that only one, _maybe_ two, people regularly touch.
Ben Rosser
___
devel mai
Hi all,
Is anyone interested in a review swap for a Python(-ish) package?
cocotb: https://bugzilla.redhat.com/show_bug.cgi?id=1747574
Happy to review anything in exchange.
Cheers,
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To
Gs/Education
> [2] https://fedoraproject.org/wiki/SIGs/University
Hi Timothée,
I think this is a great initiative! Maybe it's a bit early to ask, but
I'm curious what sort of projects you see a SIG focusing on?
(If grad students would be welcome here too, I might be interested. :) )
C
mizdebsk, orphan 3 weeks ago
...
> reflections orphan 4 weeks ago
I have one Java package that requires both of these... although I'm
sure if I take them I'll wind up needing to take more of the Java
stack too.
I guess I'll t
e required. Still, the policy requires an
announcement on this list, so here it is. :)
Cheers,
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Condu
a group* should prepare and submit an objective proposal
describing what they want to work on.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: http
ut I think the difficulty is that you can't rely on ffmpeg
being provided by RPM Fusion, because users could have a
non-RPM-Fusion repository on their system that provides ffmpeg, so if
could be dangerous to make assumptions about what the "ffmpeg" package
actually is?
Cheers
the change, but it's not clear to me that
there is one beyond a desire to get away from using the name "yum".
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.o
could then be deleted from copr once the package gets
approved (or removed if the review is closed WONTFIX, or something).
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
nd
like a good idea? (Maybe #fedora-packaging, if it is not in use? Or
maybe #fedora-packaging-qol or something instead.)
Cheers,
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fe
stream releases
which built just fine with Python 3.7-- upstream still seems to be
active.
I've submitted a new review here (and also built the package in copr):
https://bugzilla.redhat.com/show_bug.cgi?id=1665303
Happy to exchange a review swap.
interested in helping out, please feel free to add your own thoughts
as well.
Sincerely,
Ben Rosser
[1]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FYNU7W6KQQWA65JWVPUFDHKUP3RX6EKR/
[2] https://fedoraproject.org/wiki/Objectives/Packager_Experience
__
7;t think it
is going to happen on its own without some sort of organization to
make it happen, and to try and organize/focus the work. I don't know
if that organization requires an Objective to make happen, but I think
it would be nice to enshrine this as one of our medium-term goals.
Cheers,
On Tue, Dec 11, 2018 at 4:07 PM Till Maas wrote:
>
> Hi Ben,
>
> On Tue, Dec 11, 2018 at 11:42:51AM +0100, Ben Rosser wrote:
>
> > I don't know. I feel like we could do a lot to improve the experience
> > of packaging by investing time into fixing these sorts of m
I am complaining on the devel list and not
actually doing anything to help, so I guess I'm part of the problem
too).
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
there was an opposition to the
idea, there just wasn't enough time or person-power to do it:
https://pagure.io/pagure/issue/2549
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
thread from September, for
instance:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FZZVKXUOW3TNUNX2JV2JGPUWFFGS3V3C/#426PWWHO6FVWBQSC6PP2D5HIKBONY6UE
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To
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
>
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
_
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
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
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
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
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
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
___
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
___
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
esults to the packager, I bet
we would catch a lot of the licensing/bundling problems.
Anyway, I really like this idea. Maybe we should still require
quasi-manual reviews for new contributors as part of the sponsorship
process, though?
Ben Rosser
___
deve
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
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
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
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
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
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
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
ocgen tilp2
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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
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
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 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
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
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
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
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
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
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
?
>
> 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
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
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
__
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
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
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
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
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
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
latpaks over RPMs, that doesn't particularly
bother me. So I have no issue with this particular change. But I felt
like I should chime in here because this change thread has turned (as
any discussion on flatpak seems to) into a general discussion o
On Mon, Jul 3, 2017 at 7:01 PM, Sandro Mani wrote:
> Hi Ben
>
> I'm happy to take the first two in exchange for
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1461368
> https://bugzilla.redhat.com/show_bug.cgi?id=1465676
>
> which are simple C/C++ MinGW packages. Deal?
>
> Thanks
> Sandro
Taken
ow_bug.cgi?id=1426962
nodejs-simple-markdown - Javascript markdown parsing, made simple:
https://bugzilla.redhat.com/show_bug.cgi?id=1463821
nodejs-irc-colors - Color and formatting for irc made easy:
https://bugzilla.redhat.com/show_bug.cgi?id=1463797
Many of the packages I maintain are essentially one-offs that I'm not
convinced will ever belong in a specific module-- where would things
like this end up?
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
a.redhat.com/show_bug.cgi?id=1411962
https://bugzilla.redhat.com/show_bug.cgi?id=1411961
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
uthor and
still compatible with the new license, as quassel-irssi is the only
Fedora package depending on quasselc at this time.
Ben Rosser
[1] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#License_Changes
[2]
https://github.com/phhusson/QuasselC/c
estingly, it seems that "appstream-util validate-relax
--nonet" doesn't seem to care. It happily validates tilp2's appstream
information [2], which is why I never noticed this at the time. I
would think that "referenced desktop file doesn't exist on system"
shoul
ike it or not, users, myself included, install nonfree software
like Steam on systems and generally expect it to continue working from
release to release.
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
i build fired in response to (among a few other
things) a glibc upgrade, I wonder if this is a glibc bug on aarch64?
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
* nodejs-int64-buffer: https://bugzilla.redhat.com/show_bug.cgi?id=1397620
* nodejs-qtdatastream: https://bugzilla.redhat.com/show_bug.cgi?id=1397621
(depends on nodejs-int64-buffer)
Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To
current developers" writeup somewhere? (by which I mean
"Fedora developers" in general).
Ben Rosser
[1] https://fedoraproject.org/wiki/Modularity
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
nd - Frontend for the ResultsDB
> * https://bugzilla.redhat.com/show_bug.cgi?id=1346245
>
> Thanks,
>
> Tim
>
Taken resultsdb_frontend, any chance you could look at hddfancontrol? (
https://bugzilla.redhat.com/show_bug.cgi?id=1373666).
Thanks,
Ben Rosser
___
), and new packages
have theoretically just been tested by both the maintainer (when packaging
them) and the reviewer (when reviewing them), so there is likely less need
for further testing than there would be for other updates. And also, it
should be significantly less likely for a new package to bre
t sources. Sets _builddir to current working directory.
Skips handling of -n and untar in the %setup and the deletion of the
buildSubdir."
This might be helpful, if the current working directory is the root of the
git repository. I think it's a relatively new option-- I seem to r
1 - 100 of 138 matches
Mail list logo
