Re: Fedora 34 Change: Stop Shipping Individual Nodejs Library Packages (Self-Contained)

[Ben Rosser]

On Thu, Dec 10, 2020 at 5:39 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Wednesday, 09 December 2020 at 21:45, Troy Dawson wrote:
> > On Wed, Dec 9, 2020 at 11:52 AM James Cassell
> >  wrote:
> > > On Wed, Dec 9, 2020, at 1:44 PM, Ben Cotton wrote:
> > > > https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault
> [...]
> > > Is there really no better solution?
> >
> > Not that we've found.  This isn't an off the cuff proposal, it was
> > months of discussion on mailling lists and off.
>
> You say months of discussion, but in reality it's no more than 50
> messages between half a dozen people stretching several months, indeed.
> I think you should have started the discussion on devel instead of
> confining it to nodejs list.
>
> > To be honest, this is really years in the making.  macros and scripts
> > were tried for years, making them better and better in hopes that it
> > would ease the problem.  When things finally started falling apart, we
> > really could say we'd tried all we could, but nothing was sustainable.
>
> I think it boils down to not having enough packagers, as usual.

Hi Dominik,

It might be the case that with significantly more packagers involved,
and also more scripts and automation, we could do a better job
packaging nodejs libraries.

I am also disappointed that we're unable to package nodejs
applications the "right" way from a distribution's point of view.
However, with dozens if not hundreds of dependencies per package, and
potentially conflicting requirements for versions of libraries, it is
extremely difficult to keep nodejs packages up to date and in sync.

For many years now, most of the nodejs library packages in Fedora have
been effectively unmaintained anyway-- they were stuck on older
versions, because updates would involve creating dozens, if not
hundreds, of new packages and also require updating dozens of *other*
packages. And there is no guarantee that simply updating to the latest
version will work for all dependent packages anyway, so it was
generally not done. (My experience has been that it generally *does*
work despite what the npm metadata claims-- but it doesn't always, and
even when it does, our macros use the npm metadata to create versioned
Requires tags and so packages will need to be updated regardless).

In some sense, nodejs is not that different from other language
ecosystems with their own packaging frameworks, but it's definitely an
extreme outlier in terms of the size and complexity of the dependency
graphs. Further-- unlike some other language ecosystems, I think--
there's frankly little value in Fedora redistributing most nodejs
modules as separate packages. Most of the packages are noarch and
simply install a handful of javascript files into a directory without
actually doing anything to "build" the package, so it's not like we
can enforce a consistent set of build flags or anything like that.

So, from my point of view, the only other thing distribution packaging
might offer at that point is the ability to ship a series of libraries
with a coherent set of versions. But that's almost impossible with
regards to nodejs anyway-- applications will have conflicting
requirements and developers are not going to want to use the versions
of the libraries that we ship.

So what's the point? At some point, it's simply not worth going
through the process to create and maintain hundreds of these packages
in order to ship a single application. It's a huge time sink and
trying to do it has definitely made me, at least, a less motivated and
engaged Fedora contributor in general.

I will also point out that, earlier this year, a large chunk of nodejs
packages 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 gave up. If the choices are "we don't package
nodejs software at all" and "we package nodejs software by bundling
all the libraries"... I don't like it either, but the latter option is
better than the former.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Ben Rosser]

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, Ben Cotton wrote:
> > > > == Scope ==
> > > > * Proposal owners:
> > > > ** Modify comps to include nano Fedora wide.
> > > > ** Create a new subpackage of nano, called
> > > > nano-editor.
> > > > ** nano-editor to include
> > > > /usr/lib/environment.d/10-nano.conf, which sets
> > > > $EDITOR to nano.
> > >
> > > There's one nitpick with using nano in 'git commit' and similar: it'll
> > > ask about the name to save as:
> > > ^X
> > > Save modified buffer? Y
> > > File Name to Write: 
> > > /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
> > >
> > > Would it be possible to skip this last question in those scenarios?
> > > It the answer is "no", that's OK, but if it would be easy, it'd make
> > > 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
>
> Nice! I wonder if we could make EDITOR='nano --tempfile' the default? For git 
> and
> similar cases this would work nicely, but I'm not sure about all the other 
> cases
> where $EDITOR is used...

Yeah, I'm not sure either. My guess is $EDITOR is mostly invoked to
edit temporary files/buffers or files that already exist somewhere,
but I have no data to back that up.

I did just try running "nano -t" on its own to see what happens; if
you enter some text and then try to quit, it complains that there's no
file name and then, after a short delay, prompts you for one with the
normal save dialog. It's not terrible, but the delay (to give you time
to read the error message, I guess) is a little annoying.

(For what it's worth: this can also apparently be accomplished by a
nanorc setting ("set tempfile"), but presumably we wouldn't want to
set this there).

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Ben Rosser]

On Fri, Jun 26, 2020 at 12:32 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Jun 25, 2020 at 01:18:59PM -0400, Ben Cotton wrote:
> > == Scope ==
> > * Proposal owners:
> > ** Modify comps to include nano Fedora wide.
> > ** Create a new subpackage of nano, called
> > nano-editor.
> > ** nano-editor to include
> > /usr/lib/environment.d/10-nano.conf, which sets
> > $EDITOR to nano.
>
> There's one nitpick with using nano in 'git commit' and similar: it'll
> ask about the name to save as:
> ^X
> Save modified buffer? Y
> File Name to Write: 
> /home/zbyszek/src/systemd/.git/worktrees/systemd-work/COMMIT_EDITMSG
>
> Would it be possible to skip this last question in those scenarios?
> It the answer is "no", that's OK, but if it would be easy, it'd make
> 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 send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Ben Rosser]

On Fri, Jun 26, 2020 at 11:27 AM Adam Williamson
 wrote:
>
> On Fri, 2020-06-26 at 14:03 +0200, Theodore Papadopoulo wrote:
> > >
> > > Then I will +1 for this proposal. Yes, this certainly will make Fedora
> > > easier use for beginners. And for those who would like to use vi as
> > > default, we should make this as easy as possible.
> >
> > This seems the best approach in my opinion.
> > I totally agree that having something simple is important for new users.
> > My only fear (and it applies to any default editor choice) is that the
> > default will be changed only by a minority of new-users, or after many
> > months.
>
> FWIW, I still use nano *precisely because* getting vi thrown at me so
> unexpectedly was so damn annoying I flat out refuse to learn it. In
> other words, being the default 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 a new Fedora system is set EDITOR=nano in my .bashrc.

I strongly support this change.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Ben Rosser]

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 gave up on, and so
> >> those could probably be safely retired. But looking at the orphans
> >> report, I'm not confident I correctly separated out the dependency
> >> trees, and this is now somewhat time sensitive, so I suppose it's
> >> better safe than sorry. (At least this is "only" 80 out of 200
> >> packages...)
> >
> > I will try to isolate the mocha deps.
> >
>
> import requests
>
> r = requests.get('https://churchyard.fedorapeople.org/orphans.json').json()
>
> chain = r['affected_packages']
> orphaned = set(r['status_change'].keys())
>
> todo = {'mocha'}
> needed = set()
>
> while todo:
>  package = todo.pop()
>  for dep in chain[package]:
>  if dep not in needed:
>  needed.add(dep)
>  todo.add(dep)
>
> needed & orphaned ->
>
> nodejs-better-assert
> nodejs-buffer-equal
> nodejs-bunker
> nodejs-burrito
> nodejs-callsite
> nodejs-charm
> nodejs-ejs
> nodejs-nopt
> nodejs-runforcover
> nodejs-slide
> nodejs-traverse
> nodejs-yamlish
>
> Should I assign them to you?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok

Yes, I'll take them. Thanks for the extra check! Not sure why/how I
missed those before.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Ben Rosser]

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.txt still mentions another 40 
> packages:
>
> tc01: nodejs-optimist, nodejs-burrito, nodejs-cookiejar, nodejs-exit,
> nodejs-bunker, nodejs-abbrev, nodejs-which, nodejs-reduce-component,
> nodejs-osenv, nodejs-methods, nodejs-resolve, nodejs-charm, nodejs-formidable,
> nodejs-temporary, nodejs-mime, nodejs-underscore-dot-string, nodejs-nopt,
> nodejs-expect-dot-js, nodejs-superagent, nodejs-findup-sync, 
> nodejs-runforcover,
> nodejs-traverse, nodejs-supertest, nodejs-ejs, nodejs-yamlish, nodejs-through,
> nodejs-js-yaml, nodejs-buffer-equal, nodejs-getobject, nodejs-slide,
> nodejs-better-assert, nodejs-bindings, nodejs-npmlog, nodejs-defined,
> nodejs-package, nodejs-hooker, nodejs-ansi, nodejs-eventemitter2,
> nodejs-callsite, nodejs-component-emitter, nodejs-bytes

Hmm... I suppose I might as well also claim these, at least temporarily.

Some of my nodejs packages are an artifact of a failed attempt to
package quassel-webserver [1], which I eventually gave up on, and so
those could probably be safely retired. But looking at the orphans
report, I'm not confident I correctly separated out the dependency
trees, and this is now somewhat time sensitive, so I suppose it's
better safe than sorry. (At least this is "only" 80 out of 200
packages...)

Ben Rosser

[1] https://github.com/magne4000/quassel-webserver/
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[Ben Rosser]

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:
> > > > 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 packager
> > > > > and
> > > > > write to the SIG to ask to be added to the FAS group
> > > > > gitnodejs-packaging, I'll go ahead and add you.
> > > >
> > > > Hi Stephen,
> > > >
> > > > Thanks. I'll send an email to the SIG mailing list.
> > >
> > > What is the SIG mailing list ?  I'm confused
> >
> > Well, the one I'm subscribed to is the same one that's CC'ed on this
> > thread (and linked to on the wiki)-- nod...@lists.fedoraproject.org.
> > Not sure if there is also another list.
> > https://lists.fedoraproject.org/admin/lists/nodejs.lists.fedoraproject.org/
>
> This is the correct list, yes. And Ben, I went ahead and added you to
> the nodejs-sig FAS group.

Thanks! (Sorry, I forgot to actually send a separate email after
writing this...).

I posted this in the other thread, but I took over ~40 of these 215
npm modules, which I believe is enough to keep the node packages I
care about around, at least for a bit longer. If/when I have some
spare time I might triage through them to see if any can be updated...
although maybe thinking about ways to automate bundling npm modules
would be a better use of my time.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Ben Rosser]

On Tue, Jun 23, 2020 at 2:20 PM Miro Hrončok  wrote:
>
> > On Mon, Jun 22, 2020 at 8:36 AM Miro Hrončok  > wrote:
> >
> > We've been discussing this in the other thread about nodejs, but I
> > figured I'd post this here. I've already taken mocha, and I plan to
> > take the following 41 nodejs packages (at least temporarily...)--
> > these appear to be the common dependencies of mocha and discord-irc
> > that are currently orphaned.
> >
> >
> > (I ran "dnf repoquery --requires --resolve --recursive" to get this
> > list, and then filtered it against what was orphaned-- there are other
> > nodejs packages I own that I care less about so I only 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?
>
> I've done it in bulk. Thanks for talking them.

Thanks Miro, much appreciated!

Just to add: I've also taken uglify-js and uglify-js1, as apparently
something in the mocha dependency tree needs them.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (~200 nodejs packages to be retired in 2 days)

[Ben Rosser]

On Mon, Jun 22, 2020 at 8:36 AM Miro Hrončok  wrote:
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/

We've been discussing this in the other thread about nodejs, but I
figured I'd post this here. I've already taken mocha, and I plan to
take the following 41 nodejs packages (at least temporarily...)--
these appear to be the common dependencies of mocha and discord-irc
that are currently orphaned.

> nodejs-readdirp, nodejs-glob, nodejs-combined-stream, nodejs-forever-agent, 
> nodejs-qs, nodejs-debug, nodejs-oauth-sign, nodejs-ms, nodejs-cryptiles, 
> nodejs-node-uuid, nodejs-form-data, nodejs-tunnel-agent, nodejs-asap, 
> nodejs-ansi-styles, nodejs-commander, nodejs-minimatch, nodejs-assert-plus, 
> nodejs-boom, nodejs-delayed-stream, nodejs-character-parser, nodejs-growl, 
> nodejs-hoek, nodejs-stack-trace, nodejs-hawk, nodejs-css-stringify, 
> nodejs-has-color, nodejs-css-parse, nodejs-diff, nodejs-transformers, 
> nodejs-http-signature, nodejs-async, nodejs-json-stringify-safe, 
> nodejs-promise, nodejs-wordwrap, nodejs-strip-ansi, nodejs-yargs, nodejs-css, 
> nodejs-ctype, nodejs-chalk, nodejs-cycle, nodejs-minimist

(I ran "dnf repoquery --requires --resolve --recursive" to get this
list, and then filtered it against what was orphaned-- there are other
nodejs packages I own that I care less about so I only 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
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[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 packager
> > > and
> > > write to the SIG to ask to be added to the FAS group
> > > gitnodejs-packaging, I'll go ahead and add you.
> >
> > Hi Stephen,
> >
> > Thanks. I'll send an email to the SIG mailing list.
>
> What is the SIG mailing list ?  I'm confused

Well, the one I'm subscribed to is the same one that's CC'ed on this
thread (and linked to on the wiki)-- nod...@lists.fedoraproject.org.
Not sure if there is also another list.
https://lists.fedoraproject.org/admin/lists/nodejs.lists.fedoraproject.org/

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[Ben Rosser]

On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher  wrote:
> The Node.js SIG is very loosely organized. If you are a packager and
> write to the SIG to ask to be added to the FAS group
> gitnodejs-packaging, I'll go ahead and add you.

Hi Stephen,

Thanks. I'll send an email to the SIG mailing list.

> Zuzanna Svetlikova and I maintain the Node.js interpreter and NPM
> package tool in modular and non-modular Fedora releases. This is not
> going away. The packaging for these critical packages includes bundled
> NPM content from upstream rather than consuming packages in Fedora
> because the Node.js packaging ecosystem makes it realistically
> impossible to package every individual dependency into RPMs (NPM alone
> has 402 dependencies and it changes constantly).

Sure, to be clear I wasn't worried about the interpreter and npm
itself-- thanks for the work you do maintaining that! I'm primarily
worried about the npm module ecosystem.

> I've been meaning to bring up this topic on the Node.js SIG mailing
> list for a while: I think Fedora should largely get out of the game of
> delivering NPM modules and only concern itself with delivering tools
> that provide applications or support for other software in Fedora. So
> things like ycssmin and lessc would make sense to keep alive, but
> probably we would build them with their NPM dependencies bundled to
> match their upstream releases rather than waste time building dozens
> or hundreds of dependent packages in Fedora.
>
> I have some thoughts on how this could be made easier, but I'll open a
> different thread on that on nod...@lists.fedoraproject.org to discuss
> those.

This seems sad, but probably inevitable given the mess that is the npm
module ecosystem. My experience trying to package nodejs software has
been that the upstream version requirements on modules are usually
overly strict and can sometimes (but not always, of course) be
considerably softened or worked around-- but in order to package every
dependency we'd wind up needing to maintain hundreds if not thousands
of packages, and it is a lot of work to keep them updated. So I
suppose I'd be cautiously in favor, provided there was some kind of
automation to help write/maintain this part of the spec.

However... what should we do in the meantime to stop further nodejs
software from being orphaned and retired? I imagine it will take some
time to put together some tooling and/or guidelines for this, and
these packages are set to be retired imminently. Can we temporarily
allow the nodejs SIG fas group to become the POC of these packages to
stop 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 evening if no
one suggests doing anything else.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[Ben Rosser]

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:
> > >>
> > >> 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 
> > >> important for other nodejs packages-- notably "mocha", which I suspect 
> > >> is used in at least some packages to run unit tests (at the very least, 
> > >> several of my nodejs packages use it to run unit tests...).
> > >
> > >
> > > Indeed... I'd hate to see mocha disappear.  That being said, there's a 
> > > bunch of these other packages that can probably safely be retired -- I 
> > > pulled in a couple hundred NodeJS packages in my hard-headed attempt to 
> > > get NodeRED into Fedora for the IoT team a couple of years ago, but got 
> > > bogged down in dependency nightmares and ultimately gave up.  Since then, 
> > > I've been busy with my job and grad school to really spend a lot of time 
> > > worrying about NodeJS packages in Fedora, since I'm not a NodeJS 
> > > developer.  That being said, if there are packages like mocha that really 
> > > need to be maintained to keep the NodeJS ecosystem working in Fedora, I 
> > > could probably be persuaded to pick up a few more packages.
> > >
> > > -Jared
> >
> > Hi Jared,
> >
> > That makes sense to me. Maybe the priority should be trying to keep
> > mocha alive, and eventually figuring out how to update it? The current
> > dependencies, according to repoqery, are as follows:
> >
> > (npm(commander) >= 2.2.0 with npm(commander) < 3)
> > (npm(debug) >= 2.2.0 with npm(debug) < 3)
> > (npm(diff) >= 1.0.8 with npm(diff) < 2)
> > (npm(escape-string-regexp) >= 1.0.2 with npm(escape-string-regexp) < 2)
> > (npm(glob) >= 6.0.3 with npm(glob) < 7)
> > (npm(growl) >= 1.7.0 with npm(growl) < 2)
> > (npm(jade) >= 1.3.1 with npm(jade) < 2)
> > (npm(mkdirp) >= 0.5.0 with npm(mkdirp) < 0.6)
> > /usr/bin/env
> > nodejs(engine) >= 0.8.0
> > npm(supports-color)
> >
> > I haven't looked further to see what the dependency tree is like for
> > each of these, but commander, debug, diff, glob, and growl are all
> > currently orphaned.
>
> Hi,
>
> Stewardship SIG guy speaking :)
>
> If you have a limited set of packages that you want to keep working,
> e.g. to keep a minimal environment available to build other NodeJS rpm
> packages in fedora, then that's exactly what the Stewardship SIG was
> originally intended to to, albeit for a limited time only. We also
> have some tooling to check leaf package status and analyze dependency
> trees, which would also help here.
>
> However! I've tried to shepherd our Java packages into the "refounded"
> Java SIG for a few weeks, but so far, I haven't had any success, with
> no contributions from people other than me in the past 2-3 weeks ...
> and I'd rather not try to start adding new packages into the
> Stewardship SIG umbrella without also getting help from packagers
> (both packagers familiar with NodeJS to look after the NodeJS stack,
> and packagers familiar with Java to finalize the move of Java packages
> into the new Java SIG).

Hi Fabio,

I'm not sure how much time I'll be able to put in, but I'd be very
happy to (help) work on this, either as part of the Stewardship or
Nodejs SIGs, or both. Hopefully others interested in the nodejs
ecosystem (Sérgio and Jared, perhaps?) would be willing to consider
helping too.

The Nodejs SIG does have ACLs on (almost?) all of these packages, and
I know there are at least a few active packagers there, so hopefully
they would be willing to help as well. I think the immediate problem
is figuring out what in this large stack of nodejs packages is
actually useful (and stopping them from being retired in a week and a
half), so being able to use the tooling you mentioned would be very
helpful, I think. Then we'd need to ultimately find new
points-of-contact for the useful ones (while allowing the non-useful
ones to be retired); in the long term, I'd be willing to pick up some
of those (hopefully not all, but who knows).

How does one go about joining the Stewardship SIG?

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[Ben Rosser]

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 
>> important for other nodejs packages-- notably "mocha", which I suspect is 
>> used in at least some packages to run unit tests (at the very least, several 
>> of my nodejs packages use it to run unit tests...).
>
>
> Indeed... I'd hate to see mocha disappear.  That being said, there's a bunch 
> of these other packages that can probably safely be retired -- I pulled in a 
> couple hundred NodeJS packages in my hard-headed attempt to get NodeRED into 
> Fedora for the IoT team a couple of years ago, but got bogged down in 
> dependency nightmares and ultimately gave up.  Since then, I've been busy 
> with my job and grad school to really spend a lot of time worrying about 
> NodeJS packages in Fedora, since I'm not a NodeJS developer.  That being 
> said, if there are packages like mocha that really need to be maintained to 
> keep the NodeJS ecosystem working in Fedora, I could probably be persuaded to 
> pick up a few more packages.
>
> -Jared

Hi Jared,

That makes sense to me. Maybe the priority should be trying to keep
mocha alive, and eventually figuring out how to update it? The current
dependencies, according to repoqery, are as follows:

(npm(commander) >= 2.2.0 with npm(commander) < 3)
(npm(debug) >= 2.2.0 with npm(debug) < 3)
(npm(diff) >= 1.0.8 with npm(diff) < 2)
(npm(escape-string-regexp) >= 1.0.2 with npm(escape-string-regexp) < 2)
(npm(glob) >= 6.0.3 with npm(glob) < 7)
(npm(growl) >= 1.7.0 with npm(growl) < 2)
(npm(jade) >= 1.3.1 with npm(jade) < 2)
(npm(mkdirp) >= 0.5.0 with npm(mkdirp) < 0.6)
/usr/bin/env
nodejs(engine) >= 0.8.0
npm(supports-color)

I haven't looked further to see what the dependency tree is like for
each of these, but commander, debug, diff, glob, and growl are all
currently orphaned.

Ben
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned 215 packages

[Ben Rosser]

emp
> - nodejs-temporary
> - nodejs-testswarm
> - nodejs-through
> - nodejs-tiny-lr-fork
> - nodejs-transformers
> - nodejs-traverse
> - nodejs-tunnel-agent
> - nodejs-uglify-to-browserify
> - nodejs-uid-number
> - nodejs-underscore
> - nodejs-underscore-dot-string
> - nodejs-utile
> - nodejs-vhost
> - nodejs-walkdir
> - nodejs-weak-map
> - nodejs-websocket-driver
> - nodejs-which
> - nodejs-wordwrap
> - nodejs-yamlish
> - nodejs-zlib-browserify
> - nodejs-zlibjs
> - uglify-js1
> - web-assets
>

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
important for other nodejs packages-- notably "mocha", which I suspect is
used in at least some packages to run unit tests (at the very least,
several of my nodejs packages use it to run unit tests...).

Has anyone in the nodejs SIG given any thought to picking any of these up?
Do we need some kind of Stewardship SIG-like effort to try and improve the
state of the node.js ecosystem in Fedora? It's probably no secret that a
lot of node packages are outdated and in less-than-fantastic shape...

I've been trying to maintain 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 improve things. As far as I can tell, most node.js specfiles are
pretty simple (in fact, they could probably be generated by a script), the
only problem is the coordination required to keep large dependency trees up
to date. Maybe it would be good to figure out something like:

a) Are there packages that people care about (e.g. applications or
webapps?) that actually use the nodejs modules currently in Fedora?
b) What's required to maintain those? e.g. dependencies or build-time tools
to run tests?
c) What can we do to keep that subset of packages alive and up to date?

Ben Rosser

[1] https://github.com/reactiflux/discord-irc
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Weekly: 2020-04-04

[Ben Rosser]

On Mon, Apr 6, 2020 at 9:36 AM Alex Scheel  wrote:
>
> - Original Message -
> > From: "Nicolas Mailhot via devel" 
> > To: "Development discussions related to Fedora" 
> > 
> > Cc: "Nicolas Mailhot" 
> > Sent: Monday, April 6, 2020 9:10:56 AM
> > Subject: Re: CPE Weekly: 2020-04-04
> >
> > Le lundi 06 avril 2020 à 08:19 -0400, Alex Scheel a écrit :
> > >
> > > It'd be interesting to see if the FESCo election system could be
> > > repurposed to get a sense of all packagers' opinions, rather than
> > > make assumptions on how the community as a whole feels based on a few
> > > vocal members and their participation in the mailing lists.
> >
> >
> > Fedora guidelines ask Fedora packagers to subscribe to the devel list,
> > so it’s the official place to reach Fedora packagers.
>
> That's not the point I was making.
>
> Not everyone is inclined to loudly argue their positions on the mailing
> list. There have only been 12 unique participants to this thread and 57
> to the other thread.
>
> That isn't indicative of the entire Fedora packager ecosystem. A lot of
> people are staying silent.
>
>
> I believe we need a different way to engage the rest of our packager
> base.

I'm a packager who has been staying silent, but I generally strongly
agree with the points that Adam, Miro, Neal, and others have been
making with a few caveats:

* I don't _really_ mind if we wind up using Gitlab over Pagure, but if
we do, I do feel pretty strongly that we should use Gitlab CE and
self-host it-- I don't think it would be right for Fedora to use an
externally hosted solution and I don't think we should use the
enterprise edition.

* I don't like how this process has been conducted, and I think that
official responses from CPE thus far haven't really made things
better-- if anything, the "we apologize, but this is the decision
we've made" attitude is making things worse.

* I fear that, once again, we haven't adequately understood the
consequences of replacing pagure and some of the features that were
recently-- finally!-- added to it in order to replace missing pkgdb2
functionality will again be lost for a long period 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 the
FESCo voting system would really accomplish that either. How many
people actually vote in FESCo elections relative to the number of
active packagers? I'm sure you could argue that, depending on the
turnout, the results wouldn't be necessarily representative either.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Invalid body, keys: sls missing

[Ben Rosser]

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 of whatever
> automation it is that keeps closing it without actually accomplishing
> the requested task?  Thanks,
> --
> Jerry James
> http://www.jamezone.org/

The same thing just happened to me with a f32 branch request as well:
https://pagure.io/releng/fedora-scm-requests/issue/22140

Ben
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Unretire unshield

[Ben Rosser]

Hi,

I'd like to unretire unshield.
https://src.fedoraproject.org/rpms/unshield/

This is a dependency of openmw (maintained by me in RPM Fusion).

The package was retired on 12/17, which was just under eight weeks
ago-- so I think a re-review is not necessary.

Releng ticket:
https://pagure.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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: modular protobuf issue (Dec. 6, 2019) recap

[Ben Rosser]

On Fri, Dec 6, 2019 at 8:19 PM Langdon White  wrote:
> ## What happened:
> First and foremost, this issue appears to be caused by Modularity but, in 
> fact, is just an example of a policy not being followed. When a module wishes 
> to declare a "default stream"[1] it *must* not override a traditional RPM 
> without express permission from FESCo. The policy is documented here[2].
>
> Unfortunately, the recent change to enable an Eclipse Module Stream as a 
> default stream did not follow this policy and provided a different protobuf 
> RPM with different functionality.
>
> ## What we can do going forward:
> * Increase the awareness of the policies for Fedora Modules
> * Investigate an "early warning system" that would indicate to packagers 
> (modular and RPM) when they might be violating this policy

Hi Langdon,

Thanks for the summary of the issue.

Igor wrote in the other thread that, as the maintainer of protobuf, he
had no idea this was happening. In addition to FESCo approval, is it
worth stating explicitly somewhere in the policy that overriding a
traditional RPM should require the consent of the maintainer(s) 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 to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: js-jquery - Re: List of long term FTBFS packages to be retired in February (beta)

[Ben Rosser]

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 be preserved to
> > keep js-jquery around:
> >
> >
> > nodejs-grunt-legacy-util
> >
> > nodejs-load-grunt-tasks
> >
> > nodejs-raw-body

Yes, I started it awhile ago and made some progress. I think it's
still broken though; I lost track of where I'd gotten to. :(

I had fixed legacy-util but didn't own it; I've just claimed the
package in Pagure. Rawhide has the latest version.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Announcing new anitya integration and de-orphaning process

[Ben Rosser]

On Sat, Nov 30, 2019 at 3:00 PM Kevin Fenzi  wrote:
>
> On Sat, Nov 30, 2019 at 02:25:08PM +, Mat Booth wrote:
> > On Fri, 29 Nov 2019 at 07:32, Igor Gnatenko <
> > ignatenkobr...@fedoraproject.org> wrote:
> > >
> > > Because it is really hard to run two systems at the same time and keep
> > them synced?
> >
> > Then let me rephrase. IMO the replacement system shouldn't have been
> > commissioned into production before it reached feature parity.
>
> The problem was new features. The option was either to retire pkgdb and
> move on, or implement new features in pkgdb at large development
> time/cost. There were several things pkgdb couldn't handle, I can't
> recall them all, but stream branches was a big one.

Well, there *was* a third option: wait until pagure reached feature
parity with 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
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: EPEL-8 builds

[Ben Rosser]

On Thu, Nov 7, 2019 at 11:36 AM Miroslav Suchý  wrote:
>
> Dne 07. 11. 19 v 11:12 Peter Robinson napsal(a):
> > I'd like to know why people are pushing EPEL-8 builds without engaging
> > with the maintainers of the packages.
>
> Because they can?
> Nothing in guidelines say: "you have to contact maintainer of different 
> branch when you request new one".
>
> Of course, it is better if they ask you first. And of course, you can ask 
> those people directly too :)

Well... there are actually EPEL guidelines that say you should contact
the 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 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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and all the things

[Ben Rosser]

On Wed, Oct 23, 2019 at 8:43 AM Petr Šabata  wrote:
> I do believe we all intend the best, even if we sometimes disagree. We
> currently don’t have any other proposal that would fulfill the vision
> of our Objective and the needs of our users. The input here helps us
> re-focus on the most acute pain points but the manpower and control we
> have is also rather limited. If you want to and can help with the
> implementation, I’d like to encourage you to do so.

Hi Petr,

Thanks for your message. Yes, I think it's good to acknowledge that
everyone here wants what's best for Fedora, even if we disagree on
what that might be.

I'd like to push back slightly on one point though: does the current
modularity proposal really fulfil the vision of the Objective?

Matthew posted the following three goals for the Modularity Objective
from a recent council meeting:

>  1. Users should have alternate streams of software available.
>  2. Those alternate streams should be able to have different lifecycles.
>  3. Packaging an individual stream for multiple outputs should be easier
>  than before.

Now, please correct me if I'm wrong, but I don't think modularity-- at
the moment-- actually accomplishes the third point. And in fact, I
read the logs from the council meeting and some people made this
point, and others have made it in the other threads: that the
requirement to maintain module metadata for a module means that it'll
almost inevitably be more work to maintain a one-package, one-stream
module than it would be to just maintain one package.

Now, this is just one point but... I think it speaks to what I feel is
an expectation mismatch between "Modularity" as a thing the Council
wants- a high-level proposal of a direction for the distribution-- and
"Modularity" as an attempt to implement a real thing. I can only speak
for myself, but I think some of the frustration that seeps into this
conversation is a feeling or perception that modularity the *thing*
can't be revisited because it's the realization of modularity the
high-level *goal*.

For example, reading the Council meeting logs, people talked about
"trusting" (or "not trusting") the modularity contributors and their
engineering decisions. With respect, I don't think it should be a
matter of trust: we have a well-established process for making
specific changes to Fedora. Changes get approved by FESCo, and if
necessary, FESCo can decide to pull them or implement the fallback
procedure. I don't see any reason modularity should bypass that
process.

Please understand: I'm not trying to demean or disrespect the
modularity team or their work here. While I certainly understand the
benefits modularity might bring us (there are packages I'd strongly
consider modularizing), I want to be confident that decisions to roll
it out are being taken because we think it's ready to be rolled out
and that there are solid plans to mitigate problems we already know
about it. Not because we need to implement the Objective at all costs.

I said this in one of the other threads, but I would really like to
see Modularity Guidelines drawn up before we allow further use of
modules in Fedora. 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 distribution... well, maybe that calls for significant
rethinking?

Sincerely,
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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity and the system-upgrade path

[Ben Rosser]

On Fri, Oct 11, 2019 at 2:38 PM Neal Gompa  wrote:
> On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher  wrote:
> > I'm wary of assuming that this thread represents the whole of Fedoran 
> > opinions, however. As we all know, it's generally the set of people who are 
> > upset that speak up the loudest. I'm not discounting your concerns (far 
> > from it!), but if we only base development decisions on "make sure no one 
> > is upset about it", we'd never accomplish anything new at all. This is why 
> > when I've been sending out these emails to discuss ideas, I've been trying 
> > to carefully describe both the use-cases and the technical limitations 
> > (both intrinsic to the design and those that are the result of imperfect 
> > implementation) each time. It's somewhat disheartening to hear responses 
> > that largely boil down to "If you can't get it perfectly right, stop 
> > trying!".
>
> At least this Fedora packager is getting super burned out with the
> number of problems caused in his day to day by the creation of
> module-only software in Fedora. I've never really had a problem with
> the idea of modules for alternative software, but I deeply despise the
> dependency on modularity for "default" software (per modularity
> parlance).
>
> I still don't have a good grasp of what to do anymore for packaging.
> I've edged away from packaging anything that involves modularity in
> Fedora proper because it's just too complex for me to grok.
>
> And as a third party packager, I really don't want to deal with
> modules for "default distro" setups. How am I supposed to make my
> software compatible with all of the potential module filters imposed
> on me by DNF? I don't know how to deal with depending on content
> existing in default modules either...

For whatever it is worth, I agree with everything Neal wrote too.

Before things are rolled out further, I'd like to see some policies
agreed upon for what modularity is and isn't allowed for in Fedora:
what are the rules for default streams, buildroot only modules,
modularizing non-leaf packages, etc. It feels like we don't or haven't
agreed on what we actually want to use modularity for *in Fedora*.
There could very well be things that modularity should support for
RHEL that don't make sense for Fedora... and I think there's fear that
this distinction isn't being made at the moment. Or that the decisions
have already been made.

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 are made-- I
think the Java Situation has left a bad taste in everyone's mouth--
but it still seems like this is a good time to reflect on the current
implementation of modularity, what its benefits are, what we want it
to do, and if it's doing what we want it to do.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Has fedpkg + dist-git replaced rpmbuild for building new/local packages?

[Ben Rosser]

On Mon, Oct 7, 2019 at 4:15 PM Ankur Sinha  wrote:
>
> Out of curiosity, what workflow do existing package maintainers user
> while packaging new software? Is it `fedpkg` based with a folder for the
> spec to work in? (I still use rpmbuild + mock/koji-scratch builds).
>
> --
> Thanks,
> Regards,
> Ankur Sinha "FranciscoD" (He / Him / His) | 
> https://fedoraproject.org/wiki/User:Ankursinha
> Time zone: Europe/London

I do the same, probably because this is how I learned to do things
back when I first started packaging.

I'll start by writing a spec and building it on my own system with
rpmbuild -ba. In principle I could do this with mock instead, but it
is just faster to build locally and not have to wait for mock to
download and install the base system and all the package dependencies,
especially when I'm building multiple times as I test things. (It is
even worse if I try to do this with a scratch build; at least with
mock I'm only waiting on my own system to download and install
things).

Then, once I have things working with rpmbuild, I'll make sure it
builds in mock and that the dependencies are correct.

So if I'm writing a new spec, it's something like this:

1. cd ~/rpmbuild/SPECS
2. make new foo.spec file (rpmdev-newspec? take an existing one and adapt it?)
3. spectool -g foo.spec -c ~/rpmbuild/SOURCES
4. dnf builddep foo.spec to install deps locally
5. rpmbuild -ba until it builds (and is guideline 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.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

On Fri, Oct 4, 2019 at 5:54 PM Pierre-Yves Chibon  wrote:
> So I've been wondering a little bit how we could solve this and I've been
> wondering if we couldn't leverage the PR workflow for this.
> Imagine:
> - You request a new repo to be created
> - The new repo is automatically created from your request
> - You fork it
> - Push your spec file and patches to your fork
> - Open a PR against the empty repo
>
> The package review becomes then a basic PR. We could leverage the tools we are
> working on for regular PRs.
> If the PR is approved, you get access granted to it.
> If the PR is denied, both repo are deleted.

This is a really interesting idea. I think having to version control
spec files while they're going through review would probably help
things a lot, and it definitely seems like the pull request workflow
is a much more natural fit here.

I'm a little uncomfortable with the "both repos are deleted" part of
this though. One nice thing we have right now is that there's an
archive of failed and/or dead reviews. In principle I could go through
FE-DEADREVIEW and pick up tickets that got closed because a submitter
vanished. Or search for a particular package to see if anyone had
tried to submit it before, find out what went wrong, take a look at
their spec, etc.  So I think it would be important to preserve some
record of failed reviews. As proposed here, it sounds like the pull
request just gets deleted.

But this is definitely a cool starting point for a better review process.

> So there are a few works in the pipes for this.
> Dist-git in staging already offers a better integration between dist-git and
> anitya, you can see it for example at:
> https://src.stg.fedoraproject.org/rpms/guake on the left hand side column.

Yes, I have seen this-- glad to see it has been worked on.

> the-new-hotness is being adjusted so that it opens a pull-request rather than 
> a
> bugzilla ticket. This doesn't quite solve the issue of "there is no-one to
> review the ticket/PR" though.

Having pull requests for this would be really nice. Like Fabio, I also
never look at the patches generated by release monitoring, but if they
were pull requests I'd definitely consider using them.

As for not having someone to review the pull request... I think this
is an area where we just need more monitoring, not necessarily
automation. It would be wonderful if there was a page somewhere where
I could see a list of all packages release monitoring thinks are
outdated. Or (and maybe this is easier) if the "monitoring status" on
the sidebar in 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 not high enough in the priority list.

Sure, I understand. I appreciate that you're taking the time to
think/work on this stuff!

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unretire nodejs-gaze

[Ben Rosser]

On Wed, Oct 2, 2019 at 11:21 PM Jared K. Smith  wrote:
>
> On Wed, Oct 2, 2019 at 9:32 AM Jared K. Smith  
> wrote:
>>
>> I blindly assumed it had been eight weeks already, so I requested a 
>> re-review at RHBZ#1755147.  Obviously I'll just close that review 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! Let me know if I can be of any help.

Cheers,
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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

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 
> > with
> > a long term, ideal, vision of what the packager workflow should be so we can
> > work towards it.
>
> I'm such a person. I tried to put together an Objective on this topic
> back in January before realizing I didn't have enough time to drive it
> forwards due to real life commitments.
>
> I may not have said it explicitly in my other replies on the thread,
> but I _am_ glad to see people thinking seriously about ways to improve
> the packager experience. So I appreciate your proposal, even if I
> disagree with the proposed pull request workflow.
>
> That being said...
>
> > I'm going to ask again what was in my original email: What is your ideal
> > workflow? How do you think things should work?
> > Is what we have today the ideal state of things?
> > If so, great!
> > If not, what can we improve and are there things we can easily change that 
> > will
> > make it easier for a majority of packagers?
>
> My feeling is that you've focused on the wrong part of the workflow.
> My feeling is that the basic "commit, push, build, repeat" part of
> packaging works reasonably well for most packages. Sure, it isn't
> perfect, and it can be tedious to keep branches up to date across many
> packages, and it'd be nice if there was more continuous integration
> and running of a tests.
>
> But as a packager, the things that frustrate _me_-- the things I was
> proposing to help fix, before I realized tha are all the peripherals:
> the bits of the infrastructure that don't feel like they interact as
> well with the workflow as they could. At the moment, two of my biggest
> complaints are:

Whoops, I meant to write here:

"things I was proposing to help fix, before I realized that I didn't
have the time"

>
> 1. Creating new packages has become (more of) a pain since the
> retirement of pkgdb2. I know I keep complaining about needing to
> manually fetch Pagure API keys, but it is actually extremely annoying
> when I go to request a repo and realize I need to first request a new
> API key before doing anything else. The problem isn't the workflow,
> per se, but the infrastructure: reviews could really use a better
> platform than bugzilla. If reviews were more integrated into the
> tooling, automatic checks like fedora-review could maybe be ran
> automatically. Maybe approving a new package could even automatically
> create the repository, without the requestor having to do anything!
>
> 2. Release monitoring is a wonderful tool, but it's poorly integrated
> with the rest of the project. As a packager maintaining probably more
> packages than I should, getting release monitoring notifications to
> tell me to pay attention to a particular package is incredibly useful.
> But I feel like we could do more with the information. There are
> nodejs packages out there, to take an ecosystem at random, that have
> had open tickets created by release monitoring for four+ years, and
> the only activity on those tickets is the release monitoring bot
> detecting new versions. Eventually, maybe, a human comes across the
> package and realizes it might be unmaintained, and proceeds with the
> nonresponsive maintainer policy or manages to track down the
> maintainer to find out why the package hasn't been updated. I don't
> say this to criticize anyone in particular, but surely we could be
> more proactive here?
>
> Basically, I don't think we really need an entirely new packaging
> workflow. (I would argue that attempts to impose an entirely new
> packaging workflow-- like modularity-- are one of the reasons
> packaging has gotten harder recently...). We need to improve the
> contributor-facing _infrastructure_ to make the current workflow
> better.
>
> I would personally advocate starting with a serious look at the review
> process, and the tooling around it. If for no other reason 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...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

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 
> with
> a long term, ideal, vision of what the packager workflow should be so we can
> work towards it.

I'm such a person. I tried to put together an Objective on this topic
back in January before realizing I didn't have enough time to drive it
forwards due to real life commitments.

I may not have said it explicitly in my other replies on the thread,
but I _am_ glad to see people thinking seriously about ways to improve
the packager experience. So I appreciate your proposal, even if I
disagree with the proposed pull request workflow.

That being said...

> I'm going to ask again what was in my original email: What is your ideal
> workflow? How do you think things should work?
> Is what we have today the ideal state of things?
> If so, great!
> If not, what can we improve and are there things we can easily change that 
> will
> make it easier for a majority of packagers?

My feeling is that you've focused on the wrong part of the workflow.
My feeling is that the basic "commit, push, build, repeat" part of
packaging works reasonably well for most packages. Sure, it isn't
perfect, and it can be tedious to keep branches up to date across many
packages, and it'd be nice if there was more continuous integration
and running of a tests.

But as a packager, the things that frustrate _me_-- the things I was
proposing to help fix, before I realized tha are all the peripherals:
the bits of the infrastructure that don't feel like they interact as
well with the workflow as they could. At the moment, two of my biggest
complaints are:

1. Creating new packages has become (more of) a pain since the
retirement of pkgdb2. I know I keep complaining about needing to
manually fetch Pagure API keys, but it is actually extremely annoying
when I go to request a repo and realize I need to first request a new
API key before doing anything else. The problem isn't the workflow,
per se, but the infrastructure: reviews could really use a better
platform than bugzilla. If reviews were more integrated into the
tooling, automatic checks like fedora-review could maybe be ran
automatically. Maybe approving a new package could even automatically
create the repository, without the requestor having to do anything!

2. Release monitoring is a wonderful tool, but it's poorly integrated
with the rest of the project. As a packager maintaining probably more
packages than I should, getting release monitoring notifications to
tell me to pay attention to a particular package is incredibly useful.
But I feel like we could do more with the information. There are
nodejs packages out there, to take an ecosystem at random, that have
had open tickets created by release monitoring for four+ years, and
the only activity on those tickets is the release monitoring bot
detecting new versions. Eventually, maybe, a human comes across the
package and realizes it might be unmaintained, and proceeds with the
nonresponsive maintainer policy or manages to track down the
maintainer to find out why the package hasn't been updated. I don't
say this to criticize anyone in particular, but surely we could be
more proactive here?

Basically, I don't think we really need an entirely new packaging
workflow. (I would argue that attempts to impose an entirely new
packaging workflow-- like modularity-- are one of the reasons
packaging has gotten harder recently...). We need to improve the
contributor-facing _infrastructure_ to make the current workflow
better.

I would personally advocate starting with a serious look at the review
process, and the tooling around it. If for no other reason 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...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Unretire nodejs-gaze

[Ben Rosser]

About a month ago I requested to unretire some nodejs packages in
order to get the "grunt" stack working again. At least one more
package still needs to be unretired to fix the
nodejs-grunt-contrib-watch package, nodejs-gaze:

https://src.fedoraproject.org/rpms/nodejs-gaze

This was retired 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.

Sincerely,
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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

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 
> > > hear that
> > > and that may mean that we never go this way. I'm honestly fine with that 
> > > :)
> > > I do want to see why that is a show-stopper and if we can find ways to 
> > > not have
> > > it be a show-stopper.
> > >
> > > When we work on upstream projects, I think it's pretty standard now to 
> > > always go
> > > via PRs, even for your own branch.
> > > So that tests are run, so that other member of the community can see, 
> > > comment,
> > > review the change.
> > > What is so different in Fedora that we cannot move to this model?
> > > Is it a tooling issue?
> > > Is it something else?
> >
> > Most packages in Fedora are effectively one-person projects (modulo
> > rebuild scripts and other automated tooling). My experience when
> > working on a personal project is that I don't use PRs for changes even
> > if I do develop a change in a branch, rather than master; it's a lot
> > of unnecessary overhead. There are no "other members" of the
> > community. No one is reviewing the change other than me.
>
> Would this change if the PR was automatically tested for you without you 
> having
> to do anything?

No, not really? For a personal project, a continuous integration
system can be set up to run tests on _all_ of my commits, regardless
of whether or not they're to master or to a development branch. What's
the benefit of creating a pull request here?

That being said, packages are slightly different. If it wasn't
necessary to use the web interface to make a pull request and if
fedpkg could do it for me [1], and automatically merge it when the
build succeeds... that might be nice. But if manual work is required
to create a pull request-- filling out a form on Pagure, manually
forking a project, etc.-- I think it's a lot of overhead. And I
wouldn't want to do it for most of my packages.

Ben Rosser

[1] And, in an ideal world, do it without needing an API key but
rather authenticating to Pagure via some other mechanism that doesn't
require manually downloading a key, but I digress...
___
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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

On Thu, Sep 26, 2019 at 4:50 PM Fabio Valentini  wrote:
>
> On Thu, Sep 26, 2019 at 4:47 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Thu, Sep 26, 2019 at 02:57:45PM +0100, Daniel P. Berrangé wrote:
> > > Instead I prefer a clone of the master upstream git repo and maintain a
> > > branch with patches cherry-picked into it. This is used to auto-generate
> > > patches for the Fedora RPM, at the same time updating the patch file list
> > > in the RPM spec. The only manual step is adding the changelog entry &
> > > bumping release number.
> >
> > Quick note: this is essentially what debian does.
>
> Ugh. Can we please just agree that source-git (vs. dist-git) is almost
> always a bad idea?

I can see the benefit for some very complex packages that have lots of
patches, so I think it's not unreasonable for source-git to be an
_option_. (Maybe one that should require approval?)

But I'll echo what I wrote in my other message: for the majority of
packages which are relatively simple and don't deviate much from
upstream, or try not to deviate from upstream, I think it's 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 modify an upstream archive. I would be
disappointed if we moved towards a Debian-like way of doing packaging.

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Defining the future of the packager workflow in Fedora

[Ben Rosser]

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 hear 
> that
> and that may mean that we never go this way. I'm honestly fine with that :)
> I do want to see why that is a show-stopper and if we can find ways to not 
> have
> it be a show-stopper.
>
> When we work on upstream projects, I think it's pretty standard now to always 
> go
> via PRs, even for your own branch.
> So that tests are run, so that other member of the community can see, comment,
> review the change.
> What is so different in Fedora that we cannot move to this model?
> Is it a tooling issue?
> Is it something else?

Most packages in Fedora are effectively one-person projects (modulo
rebuild scripts and other automated tooling). My experience when
working on a personal project is that I don't use PRs for changes even
if I do develop a change in a branch, rather than master; it's a lot
of unnecessary overhead. There are no "other members" of the
community. No one is reviewing the change other than me.

For some critical, high-profile packages maintained by a team of
people, forcing pull requests seems reasonable enough. I'm very
skeptical it makes sense for most of the distribution. I'm glad you're
thinking about improving the packager experience (it's a very
important topic!), but I think it's critical that we keep in mind 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 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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Review swap

[Ben Rosser]

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 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 Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: University people in Fedora: Education/University SIG

[Ben Rosser]

On Wed, Aug 28, 2019 at 12:43 PM Timothée Floure
 wrote:
>
> Hello everyone,
>
> This is a follow-up email for some "coffee discussions" we had at flock a few
> weeks ago. Sorry for the delay!
>
> The Fedora community contains a lot of university students, many of us
> packaging tools for their courses and acting as first-level Linux support for
> the local student community. The problems we encounter and work on are not
> identical but share a common base: it only makes sense to collaborate.
>
> We found (over a few flock coffee breaks) 5-6 fedorans interested in joining
> such an initiative and are currently creating a SIG as a mean to communicate.
> We haven't decided on anything yet, except that we would like to work together
> to make Fedora an accessible platform for student and courses in an university
> context. We expect overlapping interests and collaboration with others SIGs,
> especially if related to the academic world such as NeuroFedora or ML.
>
> We are aware of the dormant Education SIG [1] but have yet to discuss how to
> position - or integrate - ourselve.
>
> A slightly more detailed description can be found on the related wiki page 
> [2].
> I invite you to add your name to its members section you're interested to work
> with us. We will figure out communication and coordination mediums around next
> week.
>
> [1] https://fedoraproject.org/wiki/SIGs/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. :) )

Cheers,
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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Ben Rosser]

On Mon, Aug 26, 2019 at 4:21 AM Miro Hrončok  wrote:
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via releng issues:
> https://pagure.io/releng/issues
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2019-08-26.txt
> grep it for your FAS username and follow the dependency chain.
>
>  Package  (co)maintainers   Status 
> Change
> 
...
> msv   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 take them for now and see what happens.

https://pagure.io/releng/issue/8701

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-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Unretiring some nodejs packages

[Ben Rosser]

I noticed that one of my nodejs packages is broken in Koschei at the
moment due to some broken deps:

https://apps.fedoraproject.org/koschei/package/nodejs-qtdatastream?

Looking into this, it seems some of the pieces of nodejs-grunt were
FTBFS and got retired. I'm currently working on fixing the FTBFSes and
would like to take them over.

To start, I've submitted a releng ticket requesting nodejs-dateformat.
(This seems to have been FTFBS due to a failing unit test, but
otherwise is perfectly fine).

https://src.fedoraproject.org/rpms/nodejs-dateformat
https://pagure.io/releng/issue/8694

Other possible packages which I might want to unretire include:

* https://src.fedoraproject.org/rpms/nodejs-grunt-contrib-nodeunit
* https://src.fedoraproject.org/rpms/nodejs-grunt-legacy-util

These packages were all retired well within the 8-week grace period,
so re-reviews should not be 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 Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning js-jquery

[Ben Rosser]

On Thu, Apr 25, 2019 at 8:25 PM Miro Hrončok  wrote:
> There was the packager UX initiative draft [2] proposed in December 2018,
> however it seems nobody really is eager to go and start doing this.
> It seems that this is a bit too much for volunteers and Red Hat paid Fedora
> contributors are already folly occupied by their primary responsibilities.
>
> [2] https://fedoraproject.org/wiki/Objectives/Packager_Experience

I was the author of that proposal. I started working on it because I
completely agree with the complaints that have been raised in this
thread thus far. In fact, I *made* similar complaints back in December
and was encouraged to file the objective proposal in question.

Unfortunately, I've realized over the last few months that I did not
have the time or energy to be the sole person pushing this forward.
I'm sorry that I've let it languish.

I'd still like to see the objective be realized. Though, perhaps,
rather than have the objective proposal suggest creating a SIG or WG
to organize packager experience efforts, we need to do this the other
way around: we should create a SIG or packager experience and then
*that SIG as 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: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Reviewing a package with an rpmfusion dependency

[Ben Rosser]

On Mon, Mar 18, 2019 at 12:15 PM Sérgio Basto  wrote:
>
> On Thu, 2019-03-14 at 21:53 -0600, Jerry James wrote:
> > I was just looking at reviewing this package:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1684950
> >
> > It is a Go wrapper around ffprobe, which is in the ffmpeg package,
> > which is in rpmfusion-free.  The package can be built without
> > ffprobe,
> > but cannot be used without it.
>
> Some time ago it was forbidden by package guidelines , packages that
> depends exclusively on 3rd party repos , now I'm not sure.

I seem to recall this was discussed more recently in the context of
weak dependencies. I think the conclusion was that Fedora packages
*cannot* (or at least, should not) have weak deps on non-Fedora
packages and that instead non-Fedora packages should use reverse weak
deps (Supplements/Enhances).

The problem, though, is that this would mean the ffmpeg package would
end up with a long list of reverse weak deps. And the maintainers of
ffmpeg in RPM Fusion were-- reasonably, I think-- not so eager to
maintain such a list. I don't remember if a resolution was reached
here. But 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,
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/yum.repos.d -> /etc/distro.repos.d

[Ben Rosser]

On Wed, Mar 13, 2019 at 10:37 AM Miroslav Suchý  wrote:
>
> Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a):
> > Please don't, it's just pointless renaming that invalidates all end user
> > documentation and makes it harder for other programs such as packagekit
> > and gnome-software that all need to adopt for the new paths.
>
> Not exactly true.
>
> When documentaion state: put this file in /etc/yum.repos.d/ ... then it will 
> be still valid. DNF will read that file
> without a problem.
>
> We *may* start slowly change these documentation to "put this file in 
> /etc/distro.repos.d".
>
> Only invalid statement will be "fedora.repo is in /etc/yum.repos.d/"

This isn't a great experience, though. It's kind of nice having all
the repository files in one place-- it means that if I want to find
out which repositories are enabled or installed without actually using
dnf, I can just look at the contents of a single directory.

Breaking that up into two+ directories will just make this slightly
more difficult and annoying. This might be okay if there was a strong
reason in favor of making 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.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Organizing a "packager experience" objective and working group

[Ben Rosser]

On Fri, Jan 11, 2019 at 12:37 PM Michael Cronenworth  wrote:
>
> On 1/11/19 9:18 AM, Matthew Miller wrote:
> > Can we apply the same "flag and remove" approach as currently used in Copr?
>
> I'd rather have a licensing sign-off step. Allow fedora-review to automate 
> the spec
> review and build test, but break out the licensing check. Maybe in the future 
> we can
> automate that, too, but breaking out the mountain that is package review into 
> a
> small rock would still accelerate reviews.

Well, part of fedora-review is running the license check script. I
don't think it would be too difficult to split this off into a
separate automated step, that runs over the src.rpm on the Bugzilla
ticket. Obviously this won't catch everything, but it can at least
alert the submitter (and any potential reviewers) to obvious licensing
problems. Perhaps if the license check passes, then the rest of the
review automation could run; otherwise, it has to be manually
triggered.

Or maybe we could just make the review automation use copr directly,
rather than koji, if it's easier to remove things from copr? The
packages/builds 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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Organizing a "packager experience" objective and working group

[Ben Rosser]

On Fri, Jan 11, 2019 at 8:11 AM Igor Gnatenko
 wrote:
>
> I'm definitely interested to help (I have 6+ years experience as a packager)!
>
> Can we have a topic on discussion.fp.o? I think it is much easier to discuss 
> such things there.

Thanks! Also thanks to everyone who's expressed interest in this
thread so far. :) If no one objects, I'll go through this thread and
add people's names to the wiki page.

I wanted to start the discussion here, since most/all packagers are
subscribed to this mailing list and I wanted to make sure the entire
group saw it. But I agree it makes sense to move discussions
elsewhere, either to a separate mailing list, or discussion.fp.o, or
both. Feel free to start a topic there! I guess this would go under
the "project conversation" section?

I was also thinking about creating an IRC channel... does that sound
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.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Unretiring rtv

[Ben Rosser]

Hi,

I'd like to unretire the 'rtv' package in accordance with the
documented un-retirement policy.

https://src.fedoraproject.org/rpms/rtv/commits/master

The package seems to have been retired because it could not build with
Python 3.7. However, I found that there were new upstream 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.

Cheers,
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Organizing a "packager experience" objective and working group

[Ben Rosser]

Hello,

We had a recent discussion on this list last month about (among other
things) the current state of Pagure as a replacement for pkgdb [1].

I mentioned in that discussion that there are various issues which
have arisen from the deprecation of pkgdb that have made the packager
workflow ever so slightly worse. But it's not just pkgdb-- there are
lots of places where the packager workflow could use improvement.
There are parts of the process that are tedious and manual which could
be replaced with (partial) automation, or parts where automation
exists but is in need of improvement.

For example, there are tools (namely, the "fedora-review" script) to
automate parts of the package review process. But fedora-review has
been lagging behind the packaging guidelines for some time, and has to
be manually ran by packagers over review requests. But, there's no
reason we couldn't run fedora-review automatically over every package
submission-- which might save both reviewers and submitters a lot of
time.

Or, as another example, there's currently a lot of work going on in
the distribution to support new packaging formats-- like containers
and modules. New workflows for making containers or modules out of
existing packages are being created, and I think it's vital we make
sure these workflows and processes are designed in such a way to make
things as easy as possible for packagers.

Anyway, as part of that discussion, I was encouraged to propose a new
Fedora Community Objective focused on improving the packaging
experience and workflow in Fedora. Community Objectives are approved
by the Fedora Council and intended to be 12-18 month goals for the
entire project. The goal of this Objective would be to identify
problems with the current packager workflow(s), put together a group
of packagers interested in fixing things, and then fix them!

If this sounds like something you'd be interested in helping out with,
great! The Objective will need two things, if it's to succeed:

1. People who are interested in helping! Some people did express
interest in the other thread, but I thought I would put out a general
call for interested packagers and volunteers. Anyone who is interested
and thinks they'll have some available time is more than welcome.

2. A concrete list of goals to accomplish. What glitches are there in
the current workflow, and how can they be fixed? What do you wish was
simpler, or better, or easier to do? What, basically, would make your
life easier a packager?

I've written an initial draft proposal [2] on the wiki here, though
the list of tasks to focus on is pretty sparse at present. If you are
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to avoid re-generating Pagure API keys all the time?

[Ben Rosser]

On Wed, Dec 12, 2018 at 6:50 PM Kevin Fenzi  wrote:
> I'm not sure this really deserves the level of community objective...
> but perhaps I am wrong.

So, here's why a community objective sounds like a good idea to me
(though other people should feel free to comment if they have
different ideas):

Firstly, I would hope that "making sure the experience of packaging
software in Fedora is a good one" is one of our goals, as a
distribution. (An "objective" with a lower case "o").

Two of our current objectives are "Modularity" and "Rethink the Fedora
lifecycle". I think it is very important that, as we move in the
direction of these sorts of big, sweeping changes, we also make sure
that the experience of packaging remains positive. I don't know what
is necessary to make sure that this happens. But I worry that it won't
happen on its own. I am worried because I feel like the experience
packaging *already* has gotten a bit worse since we retired pkgdb2,
and we haven't done anything to fix that yet.

So I would see the scope or mission statement of such a Community
Objective as follows:

1. To identify parts of the packager workflow that are difficult or
tedious, and to work with the maintainers of the relevant software
components to resolve these issues.
2. In the short term, to identify things that pkgdb2 used to do that
are now harder, or more difficult, for packagers to do today (and to
try and improve things).
3. In the long term, to ensure that the core packager experience
remains high as we continue to roll out Modularity and other future
changes to come.

Maybe what I've just written is the mission statement for a SIG or a
Working Group. But perhaps an Objective could lead to the creation of
such a group?

> IMHO, it mostly needs people spending time and driving it. First,
> gathering a list of issues that are non ideal for maintainers, then
> finding out what it would take to solve each and helping create and land
> fixes for them, be that a pagure bugfix or a workflow change or whatever.
>
> I'd love to help out, but just haven't had the time. If a group of folks
> could help by triaging and labeling things that might make it easier to
> know what needs work and where.

Sure, I agree that this is what needs to be done. But I don'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,
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to avoid re-generating Pagure API keys all the time?

[Ben Rosser]

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 minor
> > annoyances. (But here I am complaining on the devel list and not
> > actually doing anything to help, so I guess I'm part of the problem
> > too).
>
> you are right. I am thinking this, too. Would you maybe be interested in
> making this a Community Objective[0] such as "Packaging Contribution
> Experience"?
>
> Kind regards
> Till
>
> [0] https://docs.fedoraproject.org/en-US/project/objectives/

Hi Till,

Sure, I think it would be great to have packager quality of life as a
community objective! Should I start by writing something up and
sending an email to council-discuss?

Thanks,
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to avoid re-generating Pagure API keys all the time?

[Ben Rosser]

On Mon, Dec 10, 2018 at 6:58 PM Randy Barlow
 wrote:
>
> On Mon, 2018-12-10 at 17:20 +0100, Pavel Raiskup wrote:
> > From time to time I have to submit a ticket with 'fedpkg request-
> > repo' or
> > 'fedpkg request-branch', and I have feeling that I have to regenerate
> > the API
> > key very often (since 2018-02-17 I have 5th key already?!).
>
> I proposed that fedpkg could manage the API token here:
>
> https://pagure.io/fedpkg/issue/192

This would definitely be a huge improvement over the current situation too.

I guess what bothers me here is that it's been a year since I filed my
ticket against pagure, and nine months since you filed yours against
fedpkg, and it seems like nothing has been done to fix this. I know
it's only a minor annoyance, and I know there are more important
things to be worked on, but... this isn't the only minor annoyance
that's cropped up since we've moved away from pkgdb2 that still exists
today.

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 minor
annoyances. (But here 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.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How to avoid re-generating Pagure API keys all the time?

[Ben Rosser]

On Mon, Dec 10, 2018 at 5:22 PM Pavel Raiskup  wrote:
> Is this necessary requirement for 'fedpkg' to work if when we have
> gssapi support in Fedora?

This is something that's been annoying me too. It would be a huge
packager quality of life improvement (IMO) if we didn't have to
request pagure keys and could instead authenticate using
GSSAPI/Kerberos for all interactions with Fedora infrastructure.

Sadly, Pagure does not support GSSAPI authentication.

I actually suggested this some time ago, when the migration from
pkgdb2 first happened-- I don't *think* 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.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Packaging FOSS that requires MATLab at runtime

[Ben Rosser]

On Mon, Dec 3, 2018 at 9:52 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Dec 03, 2018 at 07:39:31PM +, Ankur Sinha wrote:
> > On Mon, Dec 03, 2018 12:56:37 -0600, Rex Dieter wrote:
> > > https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr
> > >
> > > "You agree not to use Copr to upload software code or other material
> > > (“Material”) that:
> > > ...
> > > violates any rules or guidelines of the Fedora Project;
> > > "
> >
> > Surely that's not meant to be interpreted as "your packages must follow
> > the Fedora packaging guidelines", for if it is, packages in COPR will
> > need review too.
>
> That's my understanding too, since that would make copr semi-pointless.
> But strictly speaking the text "any rules or guidelines", which, when 
> interpreted
> literally, includes the packaging guidelines.

I think this has been brought up before, and it was concluded that
this language in the copr guidelines is much too broad and we should
look at changing the wording. In this 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 unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[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
> > > minimum and 7 is their what we really want. It usually takes the
> > > vendor about 3-6 months of work to make sure the OS works on their
> > > hardware without major problems and then they want people to buy
> > > support contracts for 3-5 years where the number of problems needed in
> > > year 3-5 are none. [This means that they want to have Fedora N for 3-6
> > > months before their laptops ship with it. So you ship them a frozen
> > > preload before you release to public. They also want any shipped to
> > > 'last' for the warranty cycle because trying to deal with update
> > > questions when N eol's in the middle costs them a lot.]
> >
> > If 7 years is what manufacturers really want, then it sounds like
>
> Well they also want a Ferrari and all support to be done upstream for
> free. 7 is usually their counter to 13 months. You start going down
> there to find that what they really settle for will be 3-4 years as
> most people don't extend warranties that long.

Well, even so, 3-4 years would be a pretty long time.

My point about EPEL was that, Fedora currently does produce a
long-term-support type product (admittedly for another distro). It's
EPEL.

Except we don't really push it. EPEL is an opt-in thing, which means
lots of packages don't have EPEL branches-- possibly because the
maintainers didn't want to commit to maintaining a package in a
long-term-support type environment, or possibly because the
maintainers never thought or bothered to create an EPEL branch, or
possibly because there are too many dependencies that don't exist in
EPEL and tracking down those maintainers isn't worth the time and
effort. I know that I would package more things for EPEL if I could
reuse Fedora specs with a minimum of fuss and I didn't have to spend
time getting a bunch of dependent packages built.

It is not clear to me that Fedora having two long-term-support type
products would be a good idea, as I am not sure that we have the
resources to maintain *one* at the moment. That makes me think we'd
want to tie a hypothetical "Fedora LTS" directly to RHEL/CentOS/EPEL
somehow, and find a way to reuse the work for both efforts.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

[Ben Rosser]

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
> minimum and 7 is their what we really want. It usually takes the
> vendor about 3-6 months of work to make sure the OS works on their
> hardware without major problems and then they want people to buy
> support contracts for 3-5 years where the number of problems needed in
> year 3-5 are none. [This means that they want to have Fedora N for 3-6
> months before their laptops ship with it. So you ship them a frozen
> preload before you release to public. They also want any shipped to
> 'last' for the warranty cycle because trying to deal with update
> questions when N eol's in the middle costs them a lot.]

If 7 years is what manufacturers really want, then it sounds like
CentOS is much better positioned to be get 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ursa Major (modules in buildroot) enablement

[Ben Rosser]

On Fri, Nov 9, 2018 at 11:20 AM Stephen Gallagher  wrote:
> Consider the Go case: we know that most Go packages will be statically
> linked (issues with that are a different topic), so we know they will
> work fine once built.

How does this scale to ecosystems that *aren't* statically linked,
though? Suppose I turn a C++ library, or set of libraries, into a
module, and ship incompatible versions in different streams (different
soname versions, say). Then suppose there are non-module dependencies
of this library in the distribution. What happens when someone tries
to switch the module to the non-default stream on their system?

It doesn't sound like Ursa Major can solve this problem.  As far as I
understand, the only solution is to turn those dependencies into
modules too, and somehow keep the streams synchronized? Is there
planned tooling to do this?

It's all 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 everything is
statically linked.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning several packages.

[Ben Rosser]

On Wed, Oct 17, 2018 at 10:11 AM Kiara Navarro
 wrote:
> Hi all,
>
> I am orphaning a list of packages that I am not able to longer maintain. Most 
> of them are related to electronic applications.
>
> https://src.fedoraproject.org/rpms/emacs-verilog-mode

Hi Kiara,

I looked 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 retired?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Ben Rosser]

On Fri, Oct 19, 2018 at 3:58 PM stan  wrote:
> On Fri, 19 Oct 2018 08:58:57 -0700
> "Gerald B. Cox"  wrote:
> > Software is a tool for me.  I don't get emotionally attached to it -
> > as some people apparently are.  It's a bit telling that
> > many people seem to be afraid that Discourse will be a success.
>
> It isn't free for people who have already a good working system to
> adopt Discourse.  They have to invest time and effort in learning,
> adapting, and helping fix the new system.  What's in it for them?  I've
> had this happen to me in the past, but I was paid by my employer for
> the time and effort.
>
> You aren't really selling Discourse, so much as trying to bludgeon
> people into going along with your opinion.  Anyone who's been around
> the block a few times knows that there are lots of fads with fabulous
> press that don't pan out.

Indeed-- this thread feels like it has deteriorated into pro-Discourse
and pro-email people sniping at each other. I am not sure how useful
continuing to say things like "And if this conversation were in
Discourse..." or "perhaps Discourse could help with that" really is
when trying to convince people who don't agree with you.

I don't know that I feel strongly one way or the other about Discourse
vs. email. What I do feel strongly about, as I wrote much earlier in
the thread, is that any plan to move something as important to the
project as email to a new system really needs to be carefully
considered. And part of that careful consideration needs to be an
honest assessment of what the negative consequences are likely to be.
I suspect the negative consequences (as many have already said) are
that it won't be possible to use Discourse as a drop-in replacement
for these mailing lists, which will break the workflows of numerous
current contributors, causing them to become less involved in
discussions and perhaps the project altogether.

It is a bit disheartening that some of those 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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Ben Rosser]

On Tue, Oct 16, 2018 at 11:12 AM Gerald B. Cox  wrote:
> Did you checkout the Fedora Discourse site and read the Foreman analysis that 
> Matt provided?

Unless I'm missing something, I am not sure that either of these
things answers my questions. I am not asking the question "will
switching to Discourse increase user engagement" (which seems to be
what the linked Foreman article covers, unless I missed something?)--
I'm asking "what does the transition actually look like for current
users of the mailing lists".

> We're not talking about re-inventing the wheel here... nor are we the first 
> organization that have done this.
>
> I'm sure there are lots of lessons learned available to review - and I would 
> expect that the Fedora team
> that is working on Discourse now is totally aware of this.

Great, then it should be easy for someone to write up a change
proposal-like document detailing the migration strategy.

I am not saying switching to Discourse is a *bad* idea. I am saying
that I, at least, would like to see a more serious proposal than
simply "just do it because it's better". That might require 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 unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Ben Rosser]

On Tue, Oct 16, 2018 at 10:39 AM Gerald B. Cox  wrote:
> But RSS really isn't the point of this thread.  My point is that Fedora 
> should move to Discourse.  It's a much better solution for
> discussion.  We should publish a timeline and just do it.

Fedora should not "just do it" because "it's a much better solution".
If you want Fedora to consider moving to Discourse over email, it
would be nice to see an analysis like:

1) What are the pros and cons? Is Discourse's mailing list mode an
acceptable interface for people who prefer maillng lists and wouldn't
want to interact with Discourse itself?

2) What's the migration strategy look like? Can users on the mailing
lists be automatically added to the relevant discourse lists?

3) Will there be a transition period where the old list addresses
continue to work? Can they be maintained in perpetuity, or at least
aliased to the right thing?

I'm not saying *you* need to answer these questions, but I think
*someone* should before proposing to move all of Fedora's mailing list
infrastructure to Discourse. We would request answers to similar
questions for a system-wide 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Modularity is still confusing

[Ben Rosser]

On Wed, Oct 10, 2018 at 3:15 PM Matthew Miller  wrote:
>
> On Tue, Oct 09, 2018 at 06:07:44PM -0600, Al Stone wrote:
> >-- And the one question I have to add on to Christopher's wonderful
> >   list: I have a package where upstream releases about once a month,
> >   and each new release must by definition be backwards compatible
> >   (acpica-tools, specifically). I can think of no scenario where a
> >   module provides value to me or end-users; in fact, using anything
> >   other than the most recent causes problems. Do I have to create and
> >   maintain a module for this package anyway? Or are the defaults
> >   robust enough that a package can remain a package without touching
> >   modularity at all? The answer to this is completely unclear to me --
> >   what I've read seems to imply that I must create a module definition
> >   regardless.
>
>
> This actually seems like the ideal case for a single stream -- instead of
> maintaining rawhide, f29, f28, epel7, you'd just maintain "latest",
> and that would get build into all of these releases simultaneously.

What is the overhead of maintaining a module for a single package,
plus the package itself, vs just maintaining the package the current
way?

My understanding-- from skimming the documentation a few times and
reading discussions about modularity-- is that I'd now need to keep
track of two dist-git repositories, and two different metadata files.
This feels like a lot of extra overhead. It also requires learning
about a new thing-- modulemd files.

Is this really less work? I admit I haven't tried to do it myself yet,
so I don't know. But part 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning some Java packages

[Ben Rosser]

On Mon, Sep 24, 2018 at 3:39 PM, Mikolaj Izdebski  wrote:
> On 09/24/2018 08:52 PM, Miro Hrončok wrote:
>> On 24.9.2018 19:09, Mikolaj Izdebski wrote:
>>> I'm in the process of transitioning maintenance of all software to
>>> modules only. The reason is that module maintenance is much easier
>>> compared to maintenance of non-modular, "ursine" packages.
>>>
>>> Ideally these packages should be retired instead of orphaning them, but
>>> these packages are build-required by a lot of other things.
>> This is an interesting situation. If more maintainers will decide to do
>> this, we can easily break everything and only have modules, except we
>> will no longer have any system to have those modules run on.
>>
>> (I'm not saying you shouldn't do this; I'm just really concerned if
>> modularity is actually helping Fedora as a whole or if it will
>> eventually break it entirely.)
>
> I was hoping for a solution like "ursa-major" described in [1], that
> would allow modules to be used as build-dependencies for non-modular
> packages. This would allow properly retiring non-modular packages and
> maintaining only modules, which would be also used as build dependencies
> for non-modular packages. But it seems that currently no one is
> interested in implementing such solution.
>
> Java SIG is dying slowly, this package set recently lost another
> co-maintainer and I don't have time to maintain all these packages by
> myself. Switching to module-only content is probably the best move to
> keep high-quality software delivered to our users and reduce maintenance
> work at the same time.
>
> [1]
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/message/JZMPGE2VMBHDO4D6SC4YTRSYNQYZOT63/

This is something that worried me also when I read this message.

Are modules only intended for leaf packages at the moment? I admit
that I have not really been keeping up to date with modularity. Or is
the intended workflow that (eventually) everything's a module, and so
if something needs to depend on a module, it too must be inside a
module for this to work?

This seems like it could become a problem, because I imagine that
there are lots of leaf 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: fedora-package purpose and future

[Ben Rosser]

On Tue, Sep 4, 2018 at 2:59 PM, Rex Dieter  wrote:
> Vít Ondruch wrote:
>
>> This is a bit unfortunate considering this is package
>> every Fedora packager has to have installed
>
> I don't think that's true, can you explain?
>
> -- rex

Well, the "join the package collection maintainers" document
explicitly tells new packagers to install fedora-packager, because it
will "bring in everything necessary for general packaging work".

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Install_the_developer_client_tools

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.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Automating Package Review (Was: fedora-review -- do we have a maintainer?)

[Ben Rosser]

On Thu, Aug 16, 2018 at 4:09 PM, Stephen Gallagher  wrote:
> I'd *really* like to see us get to a point where package review is
> fully-automated. Basically we could just have a web-service that you pass a
> URL to an SRPM plus authenticate with your FAS account and it will perform
> all of the validity checks and if they all pass would go ahead and request
> the branches for you and import the SRPM.
>
> Once this is fully automated, we can then *also* add the same checks to CI
> (taskotron, OSCI or whatever) so that on each build it gets rerun, which
> will allow us to help reduce the rate of packages falling out of compliance
> (as well as being updated whenever the checks get made more comprehensive).
>
> Historically, we've had human review mainly to protect against two things,
> bundling and unacceptable licenses. In both of these cases, I'd like for us
> to move towards a culture of assuming goodwill on behalf of our packagers.
> Most of the packagers in Fedora have been doing it for a long time and know
> what is and is not acceptable. Optimizing for the minority case is wasteful,
> especially when it adds hurdles and delays to getting software delivered.

Also (at least in my experience), generally licensing issues get
caught by a human inspecting the output of "licensecheck", which
fedora-review currently runs automatically anyway. If the automated
review process did this and showed the results 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TH7WI36C373Y65YOK5LUXHMCGBFRB5TG/

Re: Packages which use the BuildRoot: directive

[Ben Rosser]

On Wed, Jul 11, 2018 at 3:42 PM, Josh Boyer  wrote:
> I disagree.  "Ownership" within Fedora is one aspect we've tried to
> address, but we're pretending that Fedora "owns" the code base which
> is a falsity.  There are many more people involved and in this
> specific kind of situation, pretending there aren't is just odd.

Only if you consider packaging metadata to be part of "the code base".
I guess that's the crux of the issue, some people want to treat it
this way and others don't.

Fedora's attitude, at least officially, has hitherto been that
"packaging metadata" is managed downstream by packagers as a group. I
struggle to see why "upstream author considers the package spec part
of their upstream project and does not want other Fedora packagers to
touch it without going through upstream" is all that different from
"downstream packager considers spec they wrote to be their private
project and does not want other Fedora packagers to touch it without
going through them".

That being said, you are right that people are ignoring the existing
guidelines, and so maybe something should be changed.

>> If this is really something that's necessary, maybe it would be good
>> 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.
>
> That's a thing that could be done, but I'm skeptical it will help much
> without the other things.

Sure, this would be in addition to having some metadata on the package
to indicate external management. I am just suggesting that we
shouldn't let packagers do this themselves; 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 people?

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/33VZUAEXNSMBEHNAZ2XJCEYCGQX47JAX/

Re: Packages which use the BuildRoot: directive

[Ben Rosser]

On Wed, Jul 11, 2018 at 12:16 PM, Josh Boyer  wrote:
> Because nobody is communicating with upstream and fixing it there.  In
> some cases it'll be met with a shrug (like changelogs).  In many, it
> might actually result in upstream making a similar fix.

What is "upstream", though? Some repository the packager uses to hold
the spec files? The actual upstream project that's being packaged?
Some other distribution's package repository? Presumably the people
doing automated cleanups would need to know this information, somehow.

And if an automated cleanup involves hundreds or thousands of
packages, is it realistic to have the person doing that cleanup look
up and contact various different upstreams manually for all of these?
Doesn't this make it harder, not easier, to do automated package
cleanups?

We have been telling people for a while now that they don't "own"
their packages. Making it easier for people to maintain their packages
outside of dist-git and (effectively) ignore changes from
proven-packagers seems to take us in the opposite direction.

If this is really something that's necessary, maybe it would be good
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 send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JUDNK2UZQCAZUNDJGQWOWJNVD67WGC7H/

Re: Fedora Elections May 2018 - Voting period of FESCo elections has started

[Ben Rosser]

On Fri, Jun 8, 2018 at 11:39 AM, Randy Barlow
 wrote:
> It's actually kinda
> strange to me that there seems to be a common pattern of using git merge
> to bring changes on the master branch back to older branches, especially
> since you can ask Koji to build off the master branch for non-rawhide
> releases. IMO, if you are going to have a spec file with if statements,
> why not just build all builds off master?

I actually didn't know this. Is this a recently added feature? Is
there some place I can read about it?

My suspicion is that people are using "git merge" to bring changes to
other branches because a) people don't know they can just build from
master, and b) because various packaging tutorials [1] tell them to.
(I think this is actually a big problem in Fedora right now--
infrastructure changes are happening faster than people are learning
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_collection_maintainers#Update_Your_Branches_.28if_desired.29
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GBUIPYPOJHMJGNOYBUWRSVDF5G25PVWA/

Re: F29 System Wide Change: Hide the grub menu

[Ben Rosser]

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 somewhere for end users on how to enable or disable the
>> grub boot menu, so they can _choose_ the behavior that they want. A
>> quick Google search for "fedora hide grub menu" turned 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?
>
> There's nothing Fedora-specific about it. It's just a grub config
> option.

Well, yes, that's true. But, from the justification presented earlier
in this thread, it seems like this change proposal is geared around
less technical users who may not know this?

My assumption right now is that there are people unhappy with seeing
the boot menu and want to not see the boot menu, hence this change
proposal. (If that's not true then I'm not sure why we should change
the behavior to begin with). If we don't change the default, we should
at least make sure they know how to get the behavior we want. And it
presumably goes without saying that if we do change the default, we
should document what was changed and how to get back the old behavior.

I think that philosophy applies even though this is nothing specific to Fedora.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CTTRIOGRT3SEY3NEGC3SOVHTUWJUPHOK/

Re: F29 System Wide Change: Hide the grub menu

[Ben Rosser]

On Thu, May 31, 2018 at 6:31 PM, Adam Williamson
 wrote:
> On Thu, 2018-05-31 at 15:58 -0400, Ken Coar wrote:
>> At 2018-05-31T02:36, Jason L Tibbitts III irritated the
>> Akashic Field to say:
>> >
>> > If a user is technical, and our documentation is reasonably good,
>> > then they should be able to achieve the level of verbosity they want.
>>
>> When you need to get into single-user mode, the documentation
>> is probably not to hand. :-)
>>
>> How about making this a yes/no installation option?
>
> http://islinuxaboutchoice.com/

I know that this page was created by Fedora developers, so this is
probably going to be an unpopular opinion here, but...

I've always found this argument incredibly suspect (and, frankly, the
page overly condescending). At its core, for users (especially desktop
users), using Linux at all very frequently _is_ a choice. The choice
to use open source software at all is, well, a choice. They are
choosing to install an operating system that is open source on
hardware that probably didn't come with it.

Now I do agree that this does not mean the development of a Linux
distribution necessarily has to be "about choice". But my somewhat
cynical observation is that people usually pull out the "Linux isn't
about choice" card when they are trying to justify some choice they
have made and want others to adopt.

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 somewhere for end users on how to enable or disable the
grub boot menu, so they can _choose_ the behavior that they want. A
quick Google search for "fedora hide grub menu" turned 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
discussion is.

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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DFSPLL3LEHJWOI6J4RJL2OPN4EFEA6MV/

Re: Status of OwnCloud/NextCloud

[Ben Rosser]

On Tue, Apr 3, 2018 at 3:00 PM, Christian Glombek <c...@petersen-glombek.de> 
wrote:
> I should probably add that the actual updater program has not been shipped in 
> the rpms thus far. Although I'm not sure how this affects major updates, it 
> is leading to problems elsewhere (i.e. people have to uninstall some apps on 
> v13 and re-install them on v13.0.1 for them to work again).
>
> And how many people actually still run NC v10?

Well, I have an installation of OwnCloud that I never even migrated to
NextCloud in the first place... I wouldn't underestimate the number of
people stuck on 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 unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Avoiding Jargon: dist-git

[Ben Rosser]

On Sat, Mar 24, 2018 at 4:53 PM, Miroslav Suchý <msu...@redhat.com> wrote:
> Dne 24.3.2018 v 06:59 Christopher napsal(a):
>> Can we stop saying "dist-git" in our docs? Nobody knows what that is.
>> The service at https://src.fedoraproject.org is clearly branded as "Fedora 
>> Package Sources".
>
> BTW dist-git is (for some time) documented quite well:
>   https://github.com/release-engineering/dist-git
>
> And AFAIK the Pagure is frontend to "just" that git part. It does not handle 
> lookaside cache at all.

I think that's kind of Christopher's point. We use "dist-git"
pervasively to refer to our package repositories, but from a
packager's perspective they are more or less just normal git
repositories. I can interact with them using normal git commands. The
only thing that makes these "dist-git" repositories special is the
existence of the lookaside cache, but I don't know that this is enough
to motivate using an entirely separate term to describe the
repositories.

Looking at the dist-git README further reinforces this impression. The
first sentence says: "DistGit (Distributed Git) is Git with additional
data storage". My initial reaction to that is "so, it is basically
just git". My second reaction is "why does additional data storage
somehow make git (a distributed version control system) even _more_
distributed?".

The rest of the README goes 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

Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++

[Ben Rosser]

On Sun, Feb 18, 2018 at 12:09 PM, Igor Gnatenko
<ignatenkobr...@fedoraproject.org> wrote:
> If you fixed package(s), found false positive, found missing packages in list
> or anything else -- please let me know.

I've added the missing BuildRequires to the following packages:

elog gfm hyperrogue ocaml-mccs spasm-ng tfdocgen tilp2

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Clean up your spec files

[Ben Rosser]

On Thu, Feb 8, 2018 at 9:53 AM, Neal Gompa <ngomp...@gmail.com> wrote:
> On Thu, Feb 8, 2018 at 9:49 AM, Brett Lentz <ble...@redhat.com> wrote:
>> On 08/02/18 14:09 +0100, Miroslav Suchý wrote:
>>>
>>>
>>> * rm -rf $RPM_BUILD_ROOT
>>>
>>
>> rpmdev-newspec still inserts this. It may be worthwhile to file a bug to get
>> it to stop.
>>
>
> The only reason I haven't dropped it yet is because SLE 11 still is
> supported, and it requires it.
>
> I could see into adding some magic into removing it when newer rpm is
> detected, but I'm not 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 other people feel, though.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swaps

[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
following in exchange?

ocaml-lambda-term: https://bugzilla.redhat.com/show_bug.cgi?id=1538259

bitlbee-discord: https://bugzilla.redhat.com/show_bug.cgi?id=1542663

> Bug 4769 - Review Request: qtox - Feature-rich Tox client
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=4769

I am a member of RPM Fusion-- would you care to take dwarftherapist
(https://bugzilla.rpmfusion.org/show_bug.cgi?id=4059) in exchange for
this one too?

Cheers,
Ben
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: net-snmp, cmake, mc unresponsive packagers

[Ben Rosser]

On Tue, Jan 30, 2018 at 4:32 PM, Tomasz Kłoczko
<kloczko.tom...@gmail.com> wrote:
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
>
> net-snmp
>   https://bugzilla.redhat.com/show_bug.cgi?id=1529716
>   https://src.fedoraproject.org/rpms/net-snmp/pull-request/2

There were responses 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[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:http://server.com/package2/package2.tar
>>>
>>> Then I would, by hand, untar Source1 into Source0 directory.
>>
>> That's fairly common.  I don't particularly like it, but if it's the way
>> upstream ships things, there isn't much choice.
>
> wine is an example of this. wine-staging is provided as a separate
> tarball of patches that are applied before build.

This is also the recommended way to handle git submodules, according
to the packaging guidelines.

https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Submodules

Ben
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Ben Rosser]

On Mon, Oct 23, 2017 at 8:43 PM, Xose Vazquez Perez
<xose.vazq...@gmail.com> wrote:
> They are not tagged for fedora 27.
>
> # hostnamectl  | egrep "Operating|CPE"
>   Operating System: Fedora 27 (Workstation Edition)
>CPE OS Name: cpe:/o:fedoraproject:fedora:27
>
> # dnf install quasselc quassel-irssi
> Last metadata expiration check: 0:03:44 ago on Tue 24 Oct 2017 02:35:19 AM 
> CEST.
> Dependencies resolved.
> ===
>  Package   Arch   
> Version 
> Repository  Size
> ===
> Installing:
>  quassel-irssi x86_64 
> 0-4.20170119git7b034e3.fc26 fedora
>   38 k
> Installing dependencies:
>  irssi x86_64 
> 1.0.4-3.fc27fedora
>  758 k
>  quasselc  x86_64 
> 0-3.20170111gita0a1e6b.fc26 fedora
>   23 k
>
> Transaction Summary
> ===
> Install  3 Packages
>
> Total download size: 819 k
> Installed size: 2.4 M
> Is this ok [y/N]:

Well, that's... interesting. It'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
packages on the list...

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass rebuilds update

[Ben Rosser]

On Mon, Oct 23, 2017 at 9:49 AM, Xose Vazquez Perez
<xose.vazq...@gmail.com> wrote:
> On 10/22/2017 04:08 PM, Xose Vazquez Perez wrote:
>> Mat Booth wrote:
>>
>>> On 7 August 2017 at 15:35, Dennis Gilmore <den...@ausil.us> wrote:
>>>
>>>> [3] https://kojipkgs.fedoraproject.org/mass-rebuild/f27-failures.html
>>>>
>>>
>>> This file seems suspiciously small... I somehow don't believe that there
>>> were "0 failed builds" :-)
>> Current status?
>
> Digging a bit deeper, there are ~880 packages with building problems.
> Some of them since fedora 20/21:
>

> quasselc-0-3.20170111gita0a1e6b | fc26
> quassel-irssi-0-4.20170119git7b034e3 | fc26

Where is this list sourced from? I maintain both of these packages,
and to my knowledge, they're building fine. (And no FTBFS bugs have
been filed against them).

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

Re: Kernel 4.13 rebase plans

[Ben Rosser]

On Fri, Sep 22, 2017 at 1:06 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
> On 22 September 2017 at 12:43,  <mcatanz...@gnome.org> wrote:
>> But if Negativo users start complaining that their computers don't boot
>> anymore, then we'll definitely need to stop doing major kernel updates
>> ("taking the entire distro hostage" I guess) as the Negativo support is
>> important for product strategy. Hopefully it doesn't come to that.
>>
>
> Please don't try that. No one wins from fights like that.
>
> Anything further I could write on this is hard because I am so tired
> of this yearly self-inflicted headache.

I, too, am tired of this sort of thing, but I feel that someone needs
to say something here so...

Something seems wrong about basing "product strategy" for Fedora on
compatibility with a single third party repository. This is *not* how
the third party repository policy was sold; the goal was supposedly to
curate useful repositories for given Fedora editions, not to make them
the center of our "strategy". In fact I was concerned at the time that
more central oversight of third party repositories was needed rather
than leaving it up to the individual working groups, but I was
reassured that it wasn't because they were just sort of optional
extras.

If we block changes to the entire distro because we are concerned
about breaking a specific third party repository, then effectively,
it's *not* a third party repository. It's as much a part of Fedora as
any other component, except for a thin pretense that we are not
distributing this nonfree software directly.

In which case, I would be prepared to argue again that it should be
FESCo that curates the list of such repositories, not the working
groups.

I use nvidia drivers on my system and I'm all for acknowledging that
in the "real world" people use nonfree software, but I find myself
somewhat concerned at the apparent change of culture and direction
here. All the more so because of the apparent attempt to brush this
potential 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

Re: Sailing to others seas

[Ben Rosser]

On Tue, Sep 19, 2017 at 3:44 PM, Alexandre Moine <nobra...@cthugha.org> wrote:
> Hi all,
>
> Short version: I am leaving from fedora to archlinux.

Thanks for everything you've done for Fedora!

> * hyperrogue -- An SDL roguelike in a non-euclidean world ( master f26
> f25 f24 )

I believe I reviewed 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 pkgdb.

My FAS (for both) is tc01.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: story of kerberos

[Ben Rosser]

On Wed, Sep 6, 2017 at 12:51 PM, Kevin Fenzi <ke...@scrye.com> wrote:
> On 09/06/2017 05:25 AM, Nikos Mavrogiannopoulos wrote:
>> Hi,
>>  What's the story between the recently introduced support of kerberos
>> in koji? My understanding was that eventually all services of fedora
>> would switch to kerberos authentication, though information on the
>> following bugs for bodhi seems to contradict that:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1483538
>> https://github.com/fedora-infra/bodhi/issues/1179
>
> I'm not sure where you got the understanding that everything was moving
> to kerberos. Did we say that somewhere?

No, but it seems to me like one of the advantages of using a system
like Kerberos is that, theoretically, we *could* standardize all
authentication on it

For example, I complained recently that I need Kerberos tickets to
submit builds but "pagure auth tokens" to actually request branches
using fedrepo-req: https://pagure.io/pagure/issue/2549. The same is
true to interact with copr via copr-cli. It's not clear to me why, as
a packager, I should need N different types of authentication token 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, but... if it's not going
to be Kerberos, why *did* Koji switch over to Kerberos?

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [modularity] Modules and AppStream

[Ben Rosser]

On Fri, Aug 25, 2017 at 4:23 PM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> Modularity will allowing *us* at the packaging end to separate source
> and spec lifecycle from binary and artifact lifecycle. And, it will
> also allow those of us working on assembling spins and more options —
> for example, we can have different streams for Atomic without needing
> to actually duplicate every package. (And we could do the same for KDE
> or whatever other artifacts would benefit from that, if we want.)
>
> And that's not even with doing arbitrary branching for individual
> packages. If everything works out successfully with _that_, it will
> eventually make _less_ work for packagers. Right now, I have a package
> which I maintain for F25, F26, Rawhide, EPEL6, and EPEL7. There's no
> difference in any of the versions and no real reason to keep them
> separated; in the future, I will be able to have just one branch that
> goes to all of them. Or I could have a "stable" and "experimental"
> branch that people could choose from regardless of the base. This can
> benefit *way* more packages than simply leaf desktop applications.
>
> Will we get there? I don't know! It's new and different and definitely
> scary. But... it's also worth trying.
>
> In the meantime, if you're a packager who doesn't care about any of
> this, until modularity can demonstrate real success and advantages, you
> can _continue_ to not care. Modules are going to be drawn from f27 (and
> I expect f28) streams which will act as always, and even if Fedora
> Modular Server is a success, I expect we'll also provide a minimal
> install from which a traditional Fedora-based server can be built for a
> good long time.

I have similar concerns and frustrations as Neal does, I think.

I first want to comment that I appreciate your willingness to engage
people (like Neal, and like myself) who seem frustrated with the
future direction of Fedora. And also, I think modularity-- as you
described it above-- is a very admirable goal. I have plenty of
packages that do not really need separate versions per each Fedora
release, and it would be nice to only need to maintain one branch for
them.

My fear is that Fedora, in the process of rolling out modularity, will
get halfway to the idealized goal and then discover that it's not
possible to go the rest of the way (for whatever reason), but also
that it's not possible to easily roll back to a non-modular world, and
we'll be stuck. Even if we don't encounter some critical design flaw,
I could certainly see us learning that it's far more complex to
maintain modules in practice than we think, or perhaps that it
ultimately makes things more complicated for users rather than less.

Now, perhaps this won't happen. Indeed, hopefully it does not. But I
think the retirement of pkgdb-- which is a prerequisite 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

Re: f27 branch of retired package (was: pkgdb created branch 'f27' for the 'rpms/varnish-agent' package)

[Ben Rosser]

On Wed, Aug 16, 2017 at 3:36 PM, Dridi Boukelmoune
<dr...@fedoraproject.org> wrote:
> Hello,
>
> I just received the notification above and I'm very surprised. I
> retired this package before f26 was branched because of
> incompatibility with recent Varnish releases.
>
> The old pkgdb web page shows that:
>
> https://admin.fedoraproject.org/pkgdb/package/rpms/varnish-agent/
>
> I think I saw at some point that packages were wrongfully retired in
> the branching process and that things would be fixed and reverted
> soon. Maybe this is a false-positive for those reverts?
>
> 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 Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Council Elections - July/August 2017 - Result announcement

[Ben Rosser]

On Tue, Aug 15, 2017 at 9:54 AM, Silvia Sanchez <bhkoh...@gmail.com> wrote:

>
> I don't think Justin won *only* because of the interview but I do think
> it had a lot to do.
> Personally, I think that dedicating some time to answer these questions
> (it doesn't take that much anyway, I know because I did it for FAmSCo)
> shows interest and commitment.
> My 2 cents.
>

I agree.

I know that, for example, I wasn't personally familiar with two of the
Council candidates' history in the Fedora project (and most of the FAmSCo
candidates, for that matter). I didn't know why they wanted to run, what
their goals for the project were, etc. If they'd filled out the interview
it would have been much clearer what their positions were and why I should
vote for them and what they might focus on if elected.

I would go so far as to say answering the questionnaire, 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

Re: Introduction/looking for a sponsorship

[Ben Rosser]

On Sun, Aug 6, 2017 at 10:03 PM, Matthew Miller
<mat...@fedoraproject.org> wrote:
> Does this package exist in other distros? Doing what they do is usually
> a good choice. Most ideally, you convince the upstream to switch to a
> compatible name.

Apparently, the way this is done in Debian [1] is that the program is
installed as /usr/bin/prename and provided as an alternative to the
util-linux version of /usr/bin/rename via the alternatives system.
(After learning that I was able to find the Fedora copr by searching
for "Fedora prename").

However our packaging guidelines say alternatives binaries should be
given a suffix [2]. So maybe a reasonable thing to do is:

* call the package "prename" for cross-distro compatibility.
* install the binary as "rename.pl" or something but provide
/usr/bin/prename via symlink.
* propose (I'm not sure if this is a big enough change 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Introduction/looking for a sponsorship

[Ben Rosser]

On Mon, Jul 31, 2017 at 5:56 AM, Robert-André Mauchin
<eclip...@fedoraproject.org> wrote:
> Hello,
>
> My name is Robert-André and I'm looking to become a packager for Fedora.
[...]
>
> So if you like my work so far, please consider sponsoring me for the 
> packaging team o/
>
> Thank you.
>
> Robert-André
> FAS username: eclipseo

Welcome to Fedora!

This is interesting timing; a few days ago I found myself looking for
the Perl version of "rename" and installed your copr repository for
the script (https://copr.fedorainfracloud.org/coprs/eclipseo/prename/).

If you are 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.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pagure over dist-git: what changes?

[Ben Rosser]

On Thu, Aug 3, 2017 at 11:21 AM, Pierre-Yves Chibon <pin...@pingoured.fr> wrote:
> New package and new branch request process
> --
>
> PkgDB used to be the place where packagers could request a new branch or a new
> package to be added.
> The new package and branch processes will now rely on a project
> hosted on pagure.io where people can open a ticket to request additions.
> There is a CLI tool for packagers to use: fedrepo-req (already present
> in updates-testing) that opens the ticket for you in
> such a way that these requests can be automatically handled by release
> engineering.
>
> More information about this tool at: https://pagure.io/fedrepo_req

Are there any plans to potentially create a web interface wrapper
around fedrepo-req, similar to the old pkgdb admin requests interface?
Or perhaps even tear that part out of pkgdb and refactor it to shell
out to fedrepo-req? Being able to submit those requests via the web
was handy and (IMO) once of the nicest parts of pkgdb.

I imagine such an interface would be a very low priority, which is
fine-- I'm sure there are far more important things to work on in the
migration!-- 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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Ben Rosser]

On Mon, Jul 31, 2017 at 10:51 PM, Randy Barlow
<bowlofe...@fedoraproject.org> wrote:
> It would be activated whenever the Bodhi that has it is deployed.
> However, it won't be a forced policy - developers will still be free to
> click "push to stable" if they please. The autokarma feature will
> simply move updates to batched now. Once the UI work is completed, the
> plan is for the UI to offer a "push to batched" option for testing
> updates that meet the 7 day criteria, and a "push to stable" button for
> all batched updates. Thus, I didn't think it would be necessary to file
> for a change, but I'd be happy to do so if it is necessary.
>

Oh! Somehow I misunderstood what the change actually was. This seems
entirely reasonable. :)

>
> That's a good suggestion that I hadn't though about. Sure, I think
> that's a good idea - 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 comment on the PR suggesting this.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Ben Rosser]

On Mon, Jul 31, 2017 at 5:34 PM, Randy Barlow
<bowlofe...@fedoraproject.org> wrote:
> To necromance this old thread, I wanted to give a heads up that we're about 
> to get a cool feature in Bodhi in response to this thread:
>
> https://github.com/fedora-infra/bodhi/pull/1678
>
> With that pull request, there will be a new request state called "batched". 
> When non-priority[0] updates reach the karma threshold, they will go into 
> request:batched instead of request:stable (they will remain status:testing). 
> Once a week, a cron script will look for all updates in the batched state and 
> will switch them all the request:stable. Then they will continue on as they 
> do today. This should help us to reduce the daily churn of Fedora updates for 
> end-users to only be updates they truly need. It may also make the masher be 
> a little faster on 6 days of the week (and slower on one ☺).
>
> There will still be a little more polish work to do after that pull request 
> is merged. For example, for non-autokarma updates we want to change the "push 
> to stable" button to be "push to batched".
>
>
> [0] The code considers two things to determine whether the update is priority 
> or not: security updates are high prioritity, and urgent updates are 
> considered high priority. All other updates are considered "normal" and will 
> go through the new batched workflow.

I have two questions about this:

1. Are you saying that this feature will be *activated* once it's
merged, or just that it will be available should Fedora decide to turn
it on as a policy decision? I'm assuming it's the latter, as I don't
think I've seen a change proposal or anything be formally filed about
this, and I would have expected that for this kind of change, but it's
not entirely clear to me from this email.

2. If we do implement this, could we consider not batching new package
updates in addition to security and "urgent" updates? New package
updates wouldn't get downloaded onto users systems upon running "dnf
upgrade", so the update process would still *feel* batched from an
end-user point of view. But we would simultaneously be able to deliver
new software quickly to users, or at least as quickly as we do today.
(I find that people rarely test new package updates, or at least
rarely test them and give karma, which means that a newpackage request
generally sits the full 7 or 14 days in bodhi-- so I don't think we
should add up to 7 days to that timetable).

I guess if this were done there might need to be a check put in place
to stop 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

Re: Approved packages that never get imported?

[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 Fedora.
>
> Although opam modules "compete" in some sense with the Fedora ocaml-*
> RPMs we create, there are slightly different use cases because opam
> can access development versions of OCaml which we don't tend to
> package, and it also confines itself to the user's home directory, so
> I don't think there's anything particularly wrong about this.  However
> Jon did then disappear before we got all the opam dependencies into
> Fedora, so that was that.

That's actually why I stumbled across it; I just started using OCaml
for a new project a few days ago and was disappointed that opam was
still not in Fedora, so I decided to investigate what would be
required to make it happen.  I assumed it would probably be safe to
resubmit the other reviews (which I may do over the next few weeks as
time permits), but I wasn't sure what to do about this one. Thanks for
clarifying!

Ben
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Approved packages that never get imported?

[Ben Rosser]

Hi,

What is the right thing to do when a package's review is approved, but
the package never gets imported into the distribution because the
packager subsequently becomes non-responsive?

Is the non-responsive maintainer policy appropriate, or should the
review be resubmitted entirely?

I've seen this in a few places and not been entirely sure what to do,
as this isn't entirely spelled out in our policies. But the specific
example I'm looking at right now is ocaml-re
(https://bugzilla.redhat.com/show_bug.cgi?id=1174036), which was
approved back in 2015 but has not been imported.

Now the contributor in question (Jon Ludlam) hasn't been sponsored,
but they've also been generally unresponsive to other review requests
(https://bugzilla.redhat.com/show_bug.cgi?id=1172771). I also sent Jon
an email inquiring about the state of his copr repository providing
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Ben Rosser]

On Sun, Jul 16, 2017 at 9:21 AM, Christian Dersch <lupi...@mailbox.org> wrote:
> I hope we will *never* reach that point, if we reach it, I have to move
> to another Linux distribution which follows the rules of construction I
> prefer. As a packager I know how much many upstreams love bundling (and
> not updating bundled libs), IMHO Flatpak (in general) encourages them to
> do that (yes I know, they can do also for RPM, but Flatpak makes it
> easy). And outdated libraries are a high security risk (heartbleed etc.
> ;)) and sandboxing can never save you from all possible impacts.
> Sandboxing is an *additional* and as said in some other mail
> *orthogonal* mechanism to clean packaging. I feel we lose many
> advantages over operating systems like Windows if we open that door and
> continue that way…

[snip]

> That said, for the optional availability of flatpak for packagers: I'm
> perfectly fine with that, I'll just ignore it for my stuff. But if there
> will be proposals which will change Fedora in a way that I think is
> wrong, I'll be back to discuss them ;) Also I know from IRC that there
> are more packagers thinking the same way.

I'm definitely such a packager, so I figured I'd chime in and add my
voice here. I agree completely.

Six years or so ago, I installed a Linux distribution-- Fedora, as it
happens-- for the first time, and was very quickly sold on the package
management model as a method to distribute software. I became a Fedora
packager because it seemed so self-evident to me that it was a better
way to distribute software than either the Windows model or the
smartphone application store model. These days I primarily use Fedora
and only occasionally boot into Windows, and one of the things that
helped more or less fully convert me to Linux was traditional package
management.

As an end-user, the only way I'd find the flatpakization of Fedora
acceptable is if I could still do "[package manager] install firefox;
firefox [options]" and have it launch Firefox, regardless as to how
Firefox was packaged. (As an aside, I suspect a *lot* of people are
going to complain if this sort of thing doesn't work if/when Firefox
is turned into a flatpak). If so, I might consider continuing to *use*
the distribution. But as a packager, I'm just not convinced the
potential benefits of sandboxing are worth it, and would have to
seriously consider whether I'm still interested in contributing to
Fedora, if this were to happen.

I can't presume to speak for anyone else, but it wouldn't surprise me
to learn that there are other contributors who feel similarly-- who
chose to contribute because they liked traditional package management
and are now uncomfortable at the idea of replacing it.

All that being said:

I don't have any problem with Fedora growing the technology to build
flatpaks and other packaging formats, as it already has for those who
want to distribute and ship them. I think that there's nothing wrong
with Fedora offering up a choice of images composed using technologies
such as Atomic, flatpak, docker, and so on, for people with different
usage cases. And I don't use Fedora Workstation, so if GNOME Software
wants to advertise flatpaks 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 on the
future of packaging technology, and I've been uneasy for about a year
now about the direction Fedora might go here.

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Review swaps

[Ben Rosser]

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 both of those, thanks!

The three nodejs packages are still available for anyone else
interested in review swaps.

Ben
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Review swaps

[Ben Rosser]

Hi,

I have a handful of packages in the review queue that I'd be willing
to exchange reviews for.  I'm happy to exchange for reviews of
similarly sized packages, or several for a more complicated review.

Two miscellaneous packages (C/C++):

qotd - A simple and lightweight Quote of the Day daemon:
https://bugzilla.redhat.com/show_bug.cgi?id=1462472

xoreos-tools - Tools to help the development of xoreos:
https://bugzilla.redhat.com/show_bug.cgi?id=1465588

Three nodejs packages:

nodejs-net-browserify-alt - A port of the net module for the browser:
https://bugzilla.redhat.com/show_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

Ben Rosser
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modules & Fedora 27 Server Edition (Changes)

[Ben Rosser]

On Mon, Jun 26, 2017 at 4:06 PM, Petr Šabata <con...@redhat.com> wrote:
>
> The modular release is effectively a separate distro.
>
> While using single RPMs from traditional Fedora might work in
> most cases, I wouldn't recommend enabling the entire repository
> which also provides packages conflicting with (and possibly
> updating) those provided by modules.
>
> Creating logical modules would be the best approach here.
> Containers are also an option but someone needs to make them, too.
>
> P

Perhaps I'm confused or have outdated information, but I thought I
recalled reading plans to (at least initially) potentially throw all
non-already-module'd packages into something like an "Everything"
module so it continued to be installable? And then gradually migrate
things out from it into modules.

It seems like doing so would solve this problem.

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

Re: Review Swaps: (mostly) very simple golang packages

[Ben Rosser]

On Mon, Mar 13, 2017 at 6:52 PM, Fabio Valentini <decatho...@gmail.com> wrote:
> 7) golang-github-cznic-sortutil - Supplemental utilities for Go's sort
> package (depends on [2])
> https://bugzilla.redhat.com/show_bug.cgi?id=1431735
>
> 8) golang-github-cznic-strutil - Supplemental utilities for Go's strings
> package (depends on [2])
> https://bugzilla.redhat.com/show_bug.cgi?id=1431736

I took these two; I'll review them once the dependencies get reviewed.

I also have two small golang packages in the review queue, any chance
you could look at them in return?

https://bugzilla.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

License change in quasselc

[Ben Rosser]

Hello,

As per policy [1] I'm notifying devel@ that the license of quasselc, a
C library implementing the quassel protocol, has changed from GPL v3+
to LGPL v3 [2].

This should only affect the GPLv3+-licensed quassel-irssi (an irssi
plugin that uses quasselc), which is by the same upstream author 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/commit/389419eb1210f13be40bee2d5f3d084473ea4d48
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Applications with AppData and not visible in the software center

[Ben Rosser]

On Thu, Jan 5, 2017 at 6:56 AM, Richard Hughes <hughsi...@gmail.com> wrote:
>  * tilp2

It turns out that I am very silly, and, when writing the appstream
file for tilp2, never changed "comical.desktop" in the template here
[1] to "tilp.desktop".

...whoops! I can, uh, fix that.

However, interestingly, 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"
should at least be a warning or something when validating?

Ben Rosser

[1] https://fedoraproject.org/wiki/Packaging:AppData#.appdata.xml_file_creation

[2] As evidenced by this scratch-build build I just ran
https://koji.fedoraproject.org/koji/taskinfo?taskID=17172267
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Ben Rosser]

On Thu, Jan 5, 2017 at 11:28 AM, Christian Schaller <cscha...@redhat.com>
wrote:

> While most desktop applications have migrated to 64 bit at this point
> there are
> still many that hasn't. Steam for instance is still 32-bit afaict. So
> doing a clean
> cutover like this feel a bit to drastic to me and I am not sure we have
> the market power
> to 'force' vendors to quickly migrate to containers.
>
> Christian
>
>
I would go further and say that I'm almost certain Fedora does not have the
market power to accomplish this at the moment. Perhaps we could
*eventually* get major software vendors to migrate to containers but I'm
pretty sure there would be a period where at least some major proprietary
desktop applications are broken.

Speaking from an end-user perspective, I actually really like the way
multilib on Fedora is currently implemented. All I need to do to get a
32-bit application-- be it some Windows application under wine, some
proprietary application like Steam, etc.-- to work is to install the 32-bit
packages via yum/dnf, and then things Just Work.

I understand that from a building-the-distribution perspective the way this
is done currently is kind of a hack, but I can't help but notice that the
*only* benefits to this proposal would be that it makes building the
distribution easier. There are no proposed benefits for our users beyond
breaking the way things currently work with probably no upgrade path. And
whether we like 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

Re: Rawhide aarch64: gcc bus error

[Ben Rosser]

On Wed, Nov 30, 2016 at 4:07 PM, Jerry James <loganje...@gmail.com> wrote:

> I'm trying to build python-cvxopt, but gcc is failing on aarch64 with
> a bus error:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16684863
>
> I took a quick look at koji and found another recent failing build
> with the same problem:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=16684488
>
> Both builds indicate that gcc was compiling a simple arithmetic
> expression when the bus error occurred.  Does anybody know what's
> going on there?  Thanks,
> --
> Jerry James
>

I'm seeing the same thing with elog; koschei alerted me to an aarch64
failure here: https://apps.fedoraproject.org/koschei/build/2381814. I was
able to reproduce the failure by running a scratch-build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=16684965.

Given that the koschei 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

Review swaps

[Ben Rosser]

Anyone interested in review swaps? I have four smallish packages in the
queue, would be happy to take other smallish packages in exchange:

* quassel-irssi: https://bugzilla.redhat.com/show_bug.cgi?id=1374899

* golang-github-knieriem-markdown:
https://bugzilla.redhat.com/show_bug.cgi?id=1396636

* 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 unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: List of packages owning %{python3_sitelib}/__pycache__

[Ben Rosser]

On Mon, Nov 14, 2016 at 8:49 PM, Athos Ribeiro <athoscribe...@gmail.com>
wrote:

> python-scp
>

I've fixed python-scp in Rawhide, thanks for the heads up.

Ben Rosser.
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Module Build Service

[Ben Rosser]

On Mon, Nov 7, 2016 at 4:13 AM, Jan Kurik <jku...@redhat.com> wrote:

> For the Fedora 26 timeframe, we will lock down the users who can
> submit to the MBS to a small number of Modularity WG members. This is
> not ideal, but the thought is that we want to limit the amount of spam
> that the MBS will impose on the production koji instance - we don't
> want to interfere with the general release of Fedora 26.
>

Is the intention then that users will be able to install modules on their
system and have things work within the Fedora 26 timeframe, or would that
not be possible until Fedora 27, assuming nothing slips? It seems like that
would require at least one other change proposal (probably a system-wide
one).

I ask as someone who's aware that Modularity is being worked on but not too
clear on what it's actually going to wind up looking like and how my system
/ our package collection is going to change as a result. By which I mean, I
understand the goal and basic concept (split packages into higher level
units), but I'm iffy on the implementation details, and if we're at the
point where things are going to start getting deployed in upcoming releases
I'd like to read more about them.

A lot of the wiki pages on modularity [1] seem to be focused on "why is
modularity a good idea" or "how do I contribute to modularity projects",
but neither of these is quite what I'm looking for. Is there a "Fedora
Modularity for 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

Re: Review Swaps

[Ben Rosser]

On Thu, Sep 15, 2016 at 10:31 AM, Tim Flink <tfl...@redhat.com> wrote:

> We have some packages which are in need of review, anyone interested in
> a swap?
>
> execdb - Execution status database for Taskotron
>   * https://bugzilla.redhat.com/show_bug.cgi?id=1346243
>
> resultsdb_frontend - 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please unpush FEDORA-2016-7776983633 on all releases or drop support for libjasper

[Ben Rosser]

On Wed, Sep 14, 2016 at 4:11 PM, Michael Catanzaro <mcatanz...@gnome.org>
wrote:

> On Wed, 2016-09-14 at 20:50 +0100, Richard Hughes wrote:
> > Three people gave the update positive
> > karma and I can't believe all three did so without actually opening a
> > JPEG-2000 image in any GTK-using or KDE-using app so there might be
> > something more subtle going on.
>
> I can believe it.
>
> I repeat my call that packages should spend more time in testing. This
> is very far from the first time we've had an update fly past without
> sufficient time for testing. Serious proposal: +3 karma and the update
> can be pushed after one week in testing, otherwise it has to wait two
> weeks. Packages maintainers could still be able to push an update
> through faster, but would be expected to do so only in exceptional
> circumstances, like to respond to a serious regression.
>
> This isn't a very extreme idea.
>
> Michael


Updates to existing packages, perhaps, but I don't think this is a good
idea for *new* packages. My experience is that new package updates rarely
get tested (unless they're something extremely popular), 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 break things than
it would be for updates to existing packages.

Ben Rosser
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org