Re: Orphaned 215 packages
by Ben Rosser
On Mon, Jun 22, 2020 at 11:34 AM Sérgio Basto <sergio(a)serjux.com> wrote:
>
> On Mon, 2020-06-22 at 11:29 -0400, Ben Rosser wrote:
> > On Thu, Jun 18, 2020 at 3:09 PM Stephen Gallagher <
> > sgallagh(a)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)-- nodejs(a)lists.fedoraproject.org.
Not sure if there is also another list.
https://lists.fedoraproject.org/admin/lists/nodejs.lists.fedoraproject.org/
Ben Rosser
3 years, 3 months
Re: Orphaned 215 packages
by Stephen Gallagher
On Thu, Jun 18, 2020 at 12:51 PM Ben Rosser <rosser.bjr(a)gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 12:50 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 6:30 PM Ben Rosser <rosser.bjr(a)gmail.com> wrote:
> > >
> > > On Tue, Jun 16, 2020 at 5:38 PM Jared K. Smith <jsmith(a)fedoraproject.org> wrote:
> > > >
> > > > On Tue, Jun 16, 2020 at 3:41 PM Ben Rosser <rosser.bjr(a)gmail.com> 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?
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.
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).
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 nodejs(a)lists.fedoraproject.org to discuss
those.
3 years, 3 months
Re: Orphaned 215 packages
by Ben Rosser
On Wed, May 13, 2020 at 3:56 AM Jamie Nguyen <j(a)jamielinux.com> wrote:
> Hi,
>
> This is a follow up for this post:
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
>
> Below are the packages I've orphaned. See section [d] of the linked
> email to see how many times each package is listed as Requires by
> something else.
>
> Most are Node.js packages, some still maintained via the 'nodejs-sig'
> user, though 'nodejs-sig' can't own packages so I orphaned instead.
>
>
> - compat-libuv010
> - CutyCapt
> - dateformat
> - expresso
> - jasmine-node
> - js-json
> - js-zlib
> - marked
> - mocha
> - nodejs-abbrev
> - nodejs-ain2
> - nodejs-ansi
> - nodejs-ansi-styles
> - nodejs-archy
> - nodejs-asap
> - nodejs-asn1
> - nodejs-assertplus
> - nodejs-async
> - nodejs-aws-sign
> - nodejs-basic-auth-connect
> - nodejs-batch
> - nodejs-better-assert
> - nodejs-bindings
> - nodejs-block-stream
> - nodejs-boom
> - nodejs-buffer-crc32
> - nodejs-buffer-equal
> - nodejs-bunker
> - nodejs-burrito
> - nodejs-bytes
> - nodejs-callsite
> - nodejs-chalk
> - nodejs-character-parser
> - nodejs-charm
> - nodejs-child-process-close
> - nodejs-chmodr
> - nodejs-chownr
> - nodejs-cmd-shim
> - nodejs-combined-stream
> - nodejs-commander
> - nodejs-component-emitter
> - nodejs-config-chain
> - nodejs-connect-timeout
> - nodejs-console-dot-log
> - nodejs-cookie
> - nodejs-cookiejar
> - nodejs-cookie-jar
> - nodejs-cookie-parser
> - nodejs-cookie-signature
> - nodejs-couch-login
> - nodejs-cryptiles
> - nodejs-css
> - nodejs-cssom
> - nodejs-css-parse
> - nodejs-css-stringify
> - nodejs-csurf
> - nodejs-ctype
> - nodejs-cycle
> - nodejs-debug
> - nodejs-defined
> - nodejs-delayed-stream
> - nodejs-detective
> - nodejs-diff
> - nodejs-dryice
> - nodejs-editor
> - nodejs-ejs
> - nodejs-escodegen
> - nodejs-estraverse
> - nodejs-esutils
> - nodejs-eventemitter2
> - nodejs-exit
> - nodejs-expect-dot-js
> - nodejs-express-session
> - nodejs-faye-websocket
> - nodejs-fileset
> - nodejs-findup-sync
> - nodejs-forever-agent
> - nodejs-form-data
> - nodejs-formidable
> - nodejs-fresh
> - nodejs-fstream
> - nodejs-fstream-ignore
> - nodejs-fstream-npm
> - nodejs-generic-pool
> - nodejs-getobject
> - nodejs-github-url-from-git
> - nodejs-glob
> - nodejs-grip
> - nodejs-growl
> - nodejs-grunt-compare-size
> - nodejs-grunt-contrib-concat
> - nodejs-grunt-contrib-internal
> - nodejs-grunt-contrib-uglify
> - nodejs-grunt-contrib-watch
> - nodejs-grunt-git-authors
> - nodejs-gzip-size
> - nodejs-has-color
> - nodejs-hawk
> - nodejs-hoek
> - nodejs-hooker
> - nodejs-http-signature
> - nodejs-inherits1
> - nodejs-ini
> - nodejs-iso8601
> - nodejs-isodate
> - nodejs-jasmine-reporters
> - nodejs-joose
> - nodejs-joosex-namespace-depended
> - nodejs-joosex-simplerequest
> - nodejs-jscoverage
> - nodejs-jsonfile
> - nodejs-jsonify
> - nodejs-json-stringify-safe
> - nodejs-js-yaml
> - nodejs-jwt-simple
> - nodejs-keypress
> - nodejs-lazystream
> - nodejs-lockfile
> - nodejs-markdown
> - nodejs-maxmin
> - nodejs-methods
> - nodejs-mime
> - nodejs-mimeparse
> - nodejs-minimatch
> - nodejs-minimist
> - nodejs-morgan
> - nodejs-ms
> - nodejs-muffin
> - nodejs-multiparty
> - nodejs-mute-stream
> - nodejs-nan0
> - nodejs-ncp
> - nodejs-node-int64
> - nodejs-node-uuid
> - nodejs-nopt
> - nodejs-noptify
> - nodejs-npmlog
> - nodejs-npm-user-validate
> - nodejs-oauth-sign
> - nodejs-opener
> - nodejs-optimist
> - nodejs-opts
> - nodejs-osenv
> - nodejs-package
> - nodejs-paperboy
> - nodejs-parseurl
> - nodejs-pause
> - nodejs-pkginfo
> - nodejs-pretty-bytes
> - nodejs-promise
> - nodejs-promzard
> - nodejs-proto-list
> - nodejs-pubcontrol
> - nodejs-qs
> - nodejs-range-parser
> - nodejs-read
> - nodejs-readdirp
> - nodejs-read-package-json
> - nodejs-reduce-component
> - nodejs-repl
> - nodejs-require-cs
> - nodejs-requirejs
> - nodejs-resolve
> - nodejs-response-time
> - odejs-response-time rpms
> - nodejs-retry
> - nodejs-rimraf
> - nodejs-ronn
> - nodejs-runforcover
> - nodejs-sax
> - nodejs-semver
> - nodejs-serve-index
> - nodejs-setimmediate
> - nodejs-sha
> - nodejs-shelljs
> - nodejs-showdown
> - nodejs-sigmund
> - nodejs-slide
> - nodejs-source-map
> - nodejs-stack-trace
> - nodejs-static-favicon
> - nodejs-stream-counter
> - nodejs-strip-ansi
> - nodejs-superagent
> - nodejs-supertest
> - nodejs-tar
> - nodejs-temp
> - 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
3 years, 3 months
Upgrading nodejs-winston
by Ben Rosser
Hello nodejs SIG,
A few months ago, nodejs-winston was orphaned due to a (trivial) FTBFS
issue. It's a dependency of discord-irc, which I maintain, so I took
it over and fixed it.
https://src.fedoraproject.org/rpms/nodejs-winston
However, we ship winston 0.7.3, which is quite old-- it's now so old,
in fact, that the latest releases of discord-irc don't work with it. A
few weeks ago i decided to see what it would take to update it to
winston 3.2.1, the latest release, to fix this.
The answer was... quite a lot. I did this in a copr and wound up
needing to package 20 new nodejs packages:
https://copr.fedorainfracloud.org/coprs/tc01/nodejs-winston/packages/
Most appeared to be trivial, with two exceptions:
* winston itself wanted a newer version of async than we ship, but I
was able to patch it relatively easily to work with async 1.5.1.
* diagnostics has support for a couple different adapters, including
an "asyncstorage" adapter which ultimately depends on the entire React
stack. It doesn't seem like this asyncstorage adapter is strictly
necessary for the package to work, so I just removed it / patched it
out for now.
According to a repoquery, the only other package in F32 which requires
winston is nodejs-prompt. I'm not sure what updating winston will do
to prompt; it looks like the latest release of prompt claims to want
winston 2.x, which is newer than what we have now but still a bit
older than what I packaged in copr. Repoquery on F32 says only
"grunt-init" and "muffin" are dependencies of prompt, and these appear
to be leaf packages.
Should I go ahead and try to get these packages into Fedora (and then
update winston)? If I do, is it alright to then grant rights on them
to the nodejs SIG group? I'm a bit reluctant to become the sole
maintainer of 20 new nodejs packages... so I wanted to check in on
this list before moving ahead and opening 20 package review tickets.
Thanks in advance,
Ben Rosser
3 years, 3 months