nodejs

nodejs@lists.fedoraproject.org

167 discussions

[Node.js] Stepping down as Node.js Maintainer in Fedora
by Stephen Gallagher 24 Jun '24

24 Jun '24

tl;dr: I'll be stepping down from maintaining the nodejs22, nodejs20 and nodejs16 packages in Fedora, effective June 30, 2024. I will continue to maintain libuv. It's been a hard decision to come to, but I think this is the correct decision for me. I've been effectively the sole maintainer of Node.js in Fedora for nearly a dozen years now (apparently, I landed the first official package in Fedora on Dec. 18, 2012). It has been a long, long road. I first picked up Node.js because it was being added as a new dependency on a package I maintained at the time: Review Board (a Django-base code-review application). When I looked into it, I discovered that others had tried - and failed - to package Node.js previously, but Fedora's rules at the time were *very* strict with regards to carrying bundled software and Node.js upstream at the time had a build-system that pretty much only allowed bundling. It took quite a bit of effort to work through that, but we got there in the end and I was able to deliver Node.js 0.8 as the very first version to ship as part of Fedora. It's been a wild ride ever since. For a long time, Fedora carried a single version of Node.js - whatever was the latest version destined for LTS status at the time that Fedora version would be released. Then, along came... Modularity. As you may know, I was heavily involved with the design of Modularity. Node.js in particular was something I viewed as a perfect consumer of this new packaging mechanism: it gave us the ability to ship all versions of Node.js in Fedora (not just the LTS ones) in a way that could be packaged in VMs and (new at the time) container images without needing to modify the way the applications were launched. Sadly, as you probably know, the implementation of Modularity fell short of its lofty goals and has largely been relegated to the dust-bin of history. When it became clear that Modules were going to be dropped from Fedora, I took on another big packaging exercise: DE-modularizing Node.js. Rather than go back to the "single Node.js version in Fedora" approach, I moved to a hybrid approach where we would have a single "system" version of Node.js LTS like in the older style, but we would also package the older (and newer!) LTS releases in a non-default arrangement, similar to how Python packages are delivered in Fedora. I've been doing it this way for a few years now, and while there have been some bumps in the road around major-release upgrades, it's been overall quite workable. Recently, the Node.js downstream maintainers made some additional improvements in Node.js 20 to unbundle some previously-precompiled WASM code into their own packages which build it properly. This is great! Unfortunately, it has introduced some new issues with the non-default version in the release (as many of you probably saw last week). We sorted this out by temporarily re-bundling the WASM in the non-default versions, but this is really a stop-gap solution. It's not a huge issue, but it took a big chunk out of my week to get that resolved and in doing it, I came to an important realization: I'm burnt out. I took a moment to think through it and realized that I don't actually *use* Node.js anywhere anymore. I've been maintaining it for so long that it's become a habit, but I'm not a real consumer of it. I've sent requests in the past to fedora-devel asking for comaintainers, but I've never actually had anyone step up, so I've just kept going. So that brings us to today and my decision to step down. It's been a wild ride, but I need to step away and focus on other things. I hope someone out there will pop up and take over for me. I'm perfectly happy to train someone on how I maintain the various versions, but my time as a maintainer is coming to an end. I'll keep things going for another month, but after that it becomes Someone Else's Problem. If you read this far, thanks for suffering through that rambling journey.

3 6

[Input Requested] Ending support for i686 builds of Node.js
by Stephen Gallagher 13 May '24

13 May '24

Upstream Node.js has not supported the i686 architecture officially since Node.js 10.x (released in 2018). As of Node.js 22, it appears that v8 will no longer build at all on that architecture. I'm not particularly willing to go to any great lengths to keep it alive on i686, but I want to know if there's anyone out there who is *desperately* in need of it in Fedora.

1 0

nodepick idea: allow using any node version as /usr/bin/node
by Honza Horak 09 Aug '23

09 Aug '23

The current implementation of alternative nodejs versions in a single Fedora (say 38), is this: * the main version (v18 in F38) ships /usr/bin/node * alternative versions ship only /usr/bin/node-XX Node modules packaged as RPM (e.g. nodejs-nodemon) then often include this hard dependency: Requires: /usr/bin/node Suppose I want to install only the alternative (non-default) version of node and install a module nodejs-nodemon (that can run fine with any nodejs version). I cannot do this at this point, because the nodejs-nodemon pulls in the default node as a dependency. New proposal: use a concept that has proofed to work for ruby for longer time (except it's used for alternative implementations, rather than alternative versions, but the logic is similar) -- rubypick package ships /usr/bin/ruby that is actually a simple shell script. This script executes a particular binary of ruby based on a reasonable defaults, explicit parameters of environment variables. How it would work for node: The default nodejs version would ship a new sub-package called "nodepick", which would only ship a couple of shell scripts: /usr/bin/node, /usr/bin/npm, etc.. All nodejs versions (including the default one) would only ship versioned binaries /usr/bin/node-XX. The shell scripts would execute a particular versioned binary based on some reasonable logic (environment variables, default, available version)... From the RPM metadata perspective: There would need to be some soft dependency from nodepick -> node-XX, with priority for the default version (dnf honours priority by Suggests I think), and a hard dependency of each of the nodejs-XX -> nodepick. Thoughts? Honza

3 11

[INPUT REQUESTED] Re: F38 proposal: Node.js Repackaging (Self-Contained Change proposal)
by Stephen Gallagher 12 Dec '22

12 Dec '22

On Tue, Sep 6, 2022 at 2:29 PM Ben Cotton <bcotton(a)redhat.com> wrote: > > https://fedoraproject.org/wiki/Changes/NodejsRepackaging > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > We are reworking the Node.js packaging to make Node.js versions > available as parallel-installable packages. So, I'd like to give an update here and address potential issues that I discovered this week surrounding the upgrade path. First and most exciting: I've got the packaging work for Node.js 16 and Node.js 18 in good shape and it can be tried out by using my COPR at https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ (`dnf copr enable sgallagh/nodejs-alternatives`) on x86_64 systems. Thanks to the input of folks on this thread, I've now put together parallel-installable versions, any of which can provide the /usr/bin/node by installing the appropriate `nodejsXX-interpreter-default` package. I've also got the dependencies established in such a way that a fresh install of `dnf install nodejs` on releases will result in automatically installing the latest stable version that was available at the Fedora release's Beta Freeze. (So for F38 it will be Node.js 18, for F39 it will be Node.js 20). On upgrade from Fedora 37 (which has nodejs == 18.x) to Fedora 38, the nodejs18 package will Obsolete the nodejs package. On upgrade of the same system to Fedora 39 later, it will continue on the Node.js 18 package. To switch to the newer version, the user will need to manually run `dnf swap nodejs18-interpreter-default nodejs20-interpreter-default). While this may seem unexpected behavior, I feel that it's better to maintain compatibility on upgrade with any applications in use rather than to force the upgrade unless the current version is going out of support. When a Node.js release goes out of support, we have a question to answer: do we Obsolete it with a newer version? If so, which one? The most recent version or the oldest one? It will not be 100% compatible in either case. Do we Obsolete it with fedora-retired-packages? Do we just leave the packages in Fedora forever (possibly patching the `/usr/bin/node` binary to warn that it's out of support)? There's another potential upgrade issue: We have multiple choices of how to upgrade from the nodejs package to the nodejsXX packages: 1) Upgrading from either F36 or F37 will result in you getting Node.js 18. (This method is closest to how things worked prior to this Change, where the nodejs package would just get updated to the latest stable release) 2) Upgrading from F36 will move you onto nodejs16 in F38. Upgrading from F37 will move you onto Node.js 18 in F38. (This method maintains compatibility with applications running on the current system) 3) Upgrading from F36 or F37 will *remove* the nodejs package and the user will need to manually select one to install. (This method has increased friction, but more user choice) 4) Upgrading from F36 or F37 will leave the existing nodejs package on the system, receiving no updates. Users of F38 will need to manually remove and install a newer version. (This method is high-friction, offers nothing over any of the others and potentially leaves people vulnerable) With options 1), 3) and 4), we can make the change in F38 exclusively. However if we want to do 2), we *also* need to either backport this Change to Fedora 37 and Fedora 36 because otherwise we would have to continuously update the Obsoletes: values in F38. With 1) I can update the Obsoletes: to just treat any Node.js with an epoch < 3 as the trigger to move to nodejs18. My questions to those brave souls who have read this far: 1) Which do you think is the best of the above options for upgrades to F38? 2) What do we do about future upgrades in the following scenarios: a. The user has nodejsXX installed as the default interpreter. The nodejsXX package is no longer available upon upgrade (EOL). b. The user has nodejsXX installed as the default interpreter. The nodejsXX package is available but non-default upon upgrade. Thank you for reading to the end.

1 2

The Future of Node.js Packaging
by Stephen Gallagher 07 Sep '22

07 Sep '22

tl;dr: I want to drop the Node.js modules and make Node available as parallel-installable interpreters (with /usr/bin/node managed by the alternatives subsystem). For some time now, I've been looking at ways to improve our Node.js story to make it more maintainable. Modules seemed like a Good Idea at the Time™, but it has been difficult to maintain over the years. I'd like to propose that we abandon Modules as our strategy and instead move to parallel-installable packages. I've been quietly working on a proof-of-concept for this for a while now and it's finally in good-enough shape[1] that I can share it with you. The change involves several key pieces: 1. The NPM package is no longer delivered as a subpackage of Node.js. We return to maintaining it as a separate package in Fedora.[2] 2. We ship the Node.js interpreter as `/usr/bin/node-$MAJOR` and use the alternatives[3] subsystem to maintain the `/usr/bin/node` symlink. 3. We configure the alternatives priority system such that newer versions of Node are preferred, with the exception of the version selected as the default for that Fedora release which will always be preferred over any other, if multiple versions are installed. Some examples: On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs` would result in the `nodejs18` package being installed. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also `dnf install nodejs16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`. On Fedora 37, the `nodejs` package is not installed (F37's default Node is v18). A `dnf install nodejs16` would result in the `nodejs16` package being installed. This package would provide `/usr/bin/node` as a symlink to `/usr/bin/node-16`. A user could also install `nodejs-18`, which would provide the `/usr/bin/node-18` binary. Because Node.js v18 is the default for Fedora 37, this would result in the `/usr/bin/node` symlink being changed to point at `/usr/bin/node-18`. On Fedora 37, the existing `nodejs` package is installed (F37's default Node is v18). A `dnf upgrade` would result in the `nodejs-18` package being installed, replacing `nodejs`. This package would provide `/usr/bin/node `as a symlink to `/usr/bin/node-18`. A user could also install `nodejs-16`, which would provide the `/usr/bin/node-16` binary. This would not change the symlink for `/usr/bin/node`. Some benefits to this approach: * With parallel-install, it becomes possible to run test suites against multiple major versions at the same time. For example, the NPM package will be able[4] to run its suite against v16 and v18 to ensure that it is compatible with both versions. * The complexities of the Module build would go away. Some risks to this approach: * If Node.js dependencies like libuv or libnghttp2 make incompatible changes that cannot work with both older and newer Node.js releases, we will need to create compat- packages for them. [1] https://copr.fedorainfracloud.org/coprs/sgallagh/nodejs-alternatives/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=2075170 [3] https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ [4] https://download.copr.fedorainfracloud.org/results/sgallagh/nodejs-alternat…

5 17

Fwd: [Bug 2075170] New: Review Request: npm - A JavaScript Package Manager
by Stephen Gallagher 27 Apr '22

27 Apr '22

I've just submitted a review request for separating out NPM into its own package (again). This is being done for a couple reasons: 1) To get rid of the ridiculous release field and take advantage of the %autorelease macro 2) I'm planning to rework how the nodejs packages work to make different versions parallel-installable (with the alternatives infrastructure owning /usr/bin/node). I want to keep NPM in a common location (/usr/lib/node_modules) so that it will work with whatever Node is in use. If someone on this list would be willing to perform the package review, I'd be appreciative. ---------- Forwarded message --------- From: <bugzilla(a)redhat.com> Date: Wed, Apr 13, 2022 at 2:27 PM Subject: [Bug 2075170] New: Review Request: npm - A JavaScript Package Manager To: <sgallagh(a)redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=2075170 Bug ID: 2075170 Summary: Review Request: npm - A JavaScript Package Manager Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody(a)fedoraproject.org Reporter: sgallagh(a)redhat.com QA Contact: extras-qa(a)fedoraproject.org CC: package-review(a)lists.fedoraproject.org Target Milestone: --- Classification: Fedora Spec URL: https://copr-dist-git.fedorainfracloud.org/cgit/sgallagh/npm/npm.git/plain/… SRPM URL: https://download.copr.fedorainfracloud.org/results/sgallagh/npm/srpm-builds… Description: npm is the world's largest software registry. Open source developers from every continent use npm to share and borrow packages, and many organizations use npm to manage private development as well. npm consists of three distinct components: * the website * the Command Line Interface (CLI) * the registry Use the [*website*](https://npmjs.com) to discover packages, set up profiles, and manage other aspects of your npm experience. For example, you can set up [organizations](https://www.npmjs.com/features) to manage access to public or private packages. The [*CLI*](https://docs.npmjs.com/cli/npm) runs from a terminal, and is how most developers interact with npm. The [*registry*](https://docs.npmjs.com/misc/registry) is a large public database of JavaScript software and the meta-information surrounding it. ## Use npm to . . . * Adapt packages of code for your apps, or incorporate packages as they are. * Download standalone tools you can use right away. * Run packages without downloading using [npx](https://www.npmjs.com/package/npx). * Share code with any npm user, anywhere. * Restrict code to specific developers. * Create organizations to coordinate package maintenance, coding, and developers. * Form virtual teams by using organizations. * Manage multiple versions of code and code dependencies. * Update applications easily when underlying code is updated. * Discover multiple ways to solve the same puzzle. * Find other developers who are working on similar problems and projects. Fedora Account System Username: sgallagh -- You are receiving this mail because: You reported the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2075170

3 6

Not updating Node to Mar. 17 security patches
by Stephen Gallagher 18 Mar '22

18 Mar '22

The patches provided apply only to the bundled OpenSSL sources that we do not use. The affected CVEs are addressed instead by the `openssl` package.

1 0

nodejs-packaging-bundler error
by Sérgio Basto 10 Jul '21

10 Jul '21

Hi, I'm testing nodejs-packaging-bundler , I'd packing nativefier #nodejs-packaging-bundler nativefier end with [1] Error: Cannot find module 'buffer-from' and I haven't found anyway to workaround it, any tips ? Thank you [1] > core-js(a)3.15.2 postinstall /tmp/ci- 92tRUpHvYD/package/app/node_modules/core-js > node -e "try{require('./postinstall')}catch(e){}" Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library! The project needs your help! Please consider supporting of core-js on Open Collective or Patreon: > https://opencollective.com/core-js > https://www.patreon.com/zloirock Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -) > electron(a)12.0.14 postinstall /tmp/ci- 92tRUpHvYD/package/app/node_modules/electron > node install.js internal/modules/cjs/loader.js:888 throw err; ^ Error: Cannot find module 'buffer-from' Require stack: - /tmp/ci-92tRUpHvYD/package/app/node_modules/concat-stream/index.js - /tmp/ci-92tRUpHvYD/package/app/node_modules/extract-zip/index.js - /tmp/ci-92tRUpHvYD/package/app/node_modules/electron/install.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:885:15) at Function.Module._load (internal/modules/cjs/loader.js:730:27) at Module.require (internal/modules/cjs/loader.js:957:19) at require (internal/modules/cjs/helpers.js:88:18) at Object.<anonymous> (/tmp/ci- 92tRUpHvYD/package/app/node_modules/concat-stream/index.js:3:18) at Module._compile (internal/modules/cjs/loader.js:1068:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10) at Module.load (internal/modules/cjs/loader.js:933:32) at Function.Module._load (internal/modules/cjs/loader.js:774:14) at Module.require (internal/modules/cjs/loader.js:957:19) { code: 'MODULE_NOT_FOUND', requireStack: [ '/tmp/ci-92tRUpHvYD/package/app/node_modules/concat-stream/index.js', '/tmp/ci-92tRUpHvYD/package/app/node_modules/extract-zip/index.js', '/tmp/ci-92tRUpHvYD/package/app/node_modules/electron/install.js' ] } npm WARN nativefier-placeholder(a)1.0.0 No repository field. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! electron(a)12.0.14 postinstall: `node install.js` npm ERR! Exit status 1 npm ERR! -- Sérgio M. B.

2 3

Re: F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Stephen Gallagher 02 Jul '21

02 Jul '21

Yes, it is. I'm working with Jeroen to resolve this. On Fri, Jul 2, 2021 at 9:20 AM Miro Hrončok <mhroncok(a)redhat.com> wrote: > > On 02. 07. 21 14:13, Stephen Gallagher wrote: > > On Thu, Jun 24, 2021 at 2:13 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote: > >> > >> I'm a little behind on this, but I've created side-tag > >> f35-build-side-42997 to perform any necessary nodejs-* rebuilds. > >> Currently I'm only aware of the `nodejs` and `R-V8` packages needing > >> to be rebuilt there. Most Node.js packages don't have a tight > >> dependency on the interpreter. If you have a package that needs to be > >> rebuilt against Node.js 16 (currently 16.4.0), please let me know > >> immediately, as well as whether you want me to rebuild it for you or > >> you will be doing it yourself in the side-tag. > >> > > > > This side-tag has now been merged and Node.js 16.x is in Rawhide. > > Is this relevant? > > can't install R-V8: > - nothing provides libnode.so.83()(64bit) needed by R-V8-3.4.2-1.fc35.x86_64 > > https://bugzilla.redhat.com/show_bug.cgi?id=1978630 > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok >

1 1

Re: F35 Change: Node.js 16.x by default (System-Wide Change proposal)
by Stephen Gallagher 02 Jul '21

02 Jul '21

Just a quick reminder, this switch will be occurring in a little over three weeks, so make sure to test your NPM packages with Node.js 16.x! On Thu, Apr 29, 2021 at 3:46 PM Ben Cotton <bcotton(a)redhat.com> wrote: > > https://fedoraproject.org/wiki/Changes/Nodejs16 > > == Summary == > The latest release of Node.js to carry a 30-month lifecycle is the > 16.x series. As with 14.x, 12.x, 10.x and 8.x before it, Fedora 35 > will carry 16.x as the default Node.js interpreter for the system. The > 14.x and 12.x interpreters will remain available as non-default module > streams. > > == Owner == > * Name: [[User:zvetlik| Zuzana Svetlikova]] > * Email: zsvetlik(a)redhat.com > * Name: [[User:Sgallagh| Stephen Gallagher]] > * Email: sgallagh(a)fedoraproject.org > * Responsible SIG: Node.js SIG > > > > == Detailed Description == > Fedora 35 will ship with the latest LTS version of Node.js. '''dnf > install nodejs''' will give users nodejs-16.x and the matching npm > package. > > == Benefit to Fedora == > Node.js is a popular server-side JavaScript engine. Keeping Fedora on > the latest release allows us to continue tracking the state-of-the-art > in that space. For those whose applications do not yet work with the > 16.x release, Fedora 35 will also have the 14.x and 12.x releases > available as selectable module streams. > > == Scope == > * Proposal owners: The packages are already built for Fedora 33, 34 > and 35 in a non-default module stream. On June 14th, 2021, the > nodejs-16.x packages will be built in the non-modular repository and > thus become the default in Fedora 35. > > * Other developers: Any developer with a package that depends on > Node.js at run-time or build-time should test with the 16.x module > stream enabled as soon as possible. Issues should be reported to > nodejs(a)lists.fedoraproject.org > > * Release engineering: We will coordinate with the Node.js SIG to > create a side-tag to perform the rebuilds before making 16.x the > default. > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > As with previous releases, users running Fedora 33 or Fedora 34 with > the non-modular nodejs-14.x packages will be automatically upgraded to > the 16.x packages when they upgrade to Fedora 35, which may cause > issues. If users are running software known not to support Node.js > 16.x yet, they can switch the system to use 14.x with '''dnf module''' > commands. > > == How To Test == > * Confirm that `dnf install nodejs` results in Node.js 16.x being installed. > * Confirm that upgrading from Fedora 33 or Fedora 34 with nodejs-14.x > installed (non-modular) results in an upgrade to nodejs-16.x > * Confirm that upgrading from Fedora 33 or Fedora 34 with the > `nodejs:14` module enabled does *not* result in an upgrade to 16.x and > still has `nodejs:14` enabled on Fedora 35. > * Confirm that upgrading from Fedora 33 or Fedora 34 with the > `nodejs:16` module enabled upgrades successfully and still has > `nodejs:16` enabled on Fedora 33. > > == User Experience == > Users will have the 16.x release of Node.js available by default. See > the "Upgrade/compatibility impact" section for specific details. > > == Dependencies == > All packages prefixed with `nodejs-` depend on this package. If they > do not work with Node.js 16.x, they will need to be updated, made > modular and dependent upon the `nodejs:14` stream or else removed from > Fedora 35. > > Prior to the switchover date to Node.js 16.x as the default, packagers > are strongly encouraged to test their existing Node modules with 16.x > via the Modular version by running: > > <pre> > dnf module reset nodejs > dnf module install nodejs:16/development > </pre> > > Packagers can also test their builds using `mock` by creating the file > `/etc/mock/fedora-rawhide-x86_64-nodejs16.cfg` with the following > contents: > > <pre> > config_opts['target_arch'] = 'x86_64' > config_opts['legal_host_arches'] = ('x86_64',) > config_opts['enable_disable_repos'] = ['--enablerepo', 'rawhide-modular'] > config_opts['module_install'] = ['nodejs:16/development'] > > include('templates/fedora-rawhide.tpl') > </pre> > > Then call > <pre> > mock -r fedora-rawhide-x86_64-nodejs16 --enablerepo=rawhide-modular nodejs-foo > </pre> > > (Note that the `--enablerepo=rawhide-modular` portion looks redundant, > but this is because of > [https://github.com/rpm-software-management/mock/issues/591 a mock > bug]) > > == Contingency Plan == > * Contingency mechanism: > Revert to Node.js 14.x as the default Node.js interpreter. This will > require bumping epoch. > > * Contingency deadline: Beta Freeze > * Blocks release? No > * Blocks product? No > > == Documentation == > * https://nodejs.org/dist/latest-v16.x/docs/api/ > * https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V16.md > > == Release Notes == > Fedora 35 now ships with Node.js 16.x as the default Node.js > JavaScript server-side engine. If your applications are not yet ready > for this newer version, you can revert to the 14.x series by running > the following commands > > <pre> > dnf remove nodejs > dnf module reset nodejs > dnf module install nodejs:14 > </pre> > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)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 > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

1 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs