Re: How to handle nodejs bundling with native compiled modules ?
Hi Daniel, Node.js in Fedora generally suffers from lack of community/interest in this particular combination. Aside from sporadic drive-by contribution, AFAIK I'm the only one somewhat invested/paid for caring for it. As a consequence, there's currently *no good way* to package Node.js stuff. The bundling exception and `nodejs-packaging-bundler` script are stop-gap solutions to allow us to package at least something. Basically any improvements and patches welcome, let me know! "Daniel P. Berrangé" writes: > Since maintainers run 'nodejs-packaging-bundler' on their local dev > machine, we're running compilation on this dev machine, with whatever > toolchain is present. The maintainer then uploads this to the lookaside > cache. > > This is obviously not good, as any compilation tasks must take place > inside koji with known toolchains used. Should, but as stated above, hands are generally thrown in the air when Node is concerned. I recently also ran into an issue when a dependency (esbuild) pulls an optional dependency based on the current architecture. As a consequence, now the package that uses it can only be built on x86_64 builder, since my laptop is x86_64. :-( I'm not even sure what can be done about that. > I'm wondering how to deal with this ? > > A first step would be patching nodejs-packaging-bundler script to > look for any .a, .o and .node files, and exclude them from the > tarball. > > The spec would then have to manually run 'node-gyp' to re-create > the .node files. That is probably sufficient to avoid this particular > problem. If you manage to get this working, patches welcome. > More generally though I'm concerned that using 'npm install' in the > 'nodejs-packaging-bundler' tool to create deps bundles is a flawed > conceptual approach. > > The result of 'npm install' is not a pristine source tree, it is > something that is derived from the source tree in some manner. > > Even if no native toolchain is used, IIUC, the package.json file > can request execution of arbirary scripts which get triggered by > 'npm install'. We surely want all this to be run in a known > environment, not the maintainer's local machine ? > > I would think for bundling nodejs deps, we want to be downloading > all the pristine tarballs for each package, and then run 'npm install' > against this set of tarballs during %build ? As far as I know, there is no easy way to get the pristine source tarballs easily. The npmjs.io registry does not contain the source tarballs, but whatever distribution files (built, preprocessed, minified, …) the author decided to upload. Also keep in mind that the Koji machines have no internet access during build, so downloading anything is generally out of the picture. Not sure if you proposed to do that in the first place, but worth mentioning in any case. --- If you decide to push on and try to tackle any issues with Node, I'll be more than happy to work with you on improvements. Just be aware that this might be a very Sisyphean effort. Best regards! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Private installation location for NodeJS modules
Vít Ondruch writes:
> I don't think that `/var` is the right place for RPM installed content.
I double-checked hier(7) and file-hierarchy(7), and `/var/lib` is indeed
reserved for library state files, not a private "lib" namespace. Oops, thanks!
> If the original directory is `/usr/lib/node_modules`, then why not use
> something like `/usr/lib/node_modules_shared`?
I would like to avoid confusion as much as possible.
Looking at that, I would naively assume that the `node_modules_shared`
is in the npm import search path, which it is not.
The same reasoning applies to why I just do not turn the unversioned
`node_modules` to a proper directory instead of symlink.
Given the above, now I'm thinking about something like `/usr/lib/nodejs`
with possible suffix/subdir ({`-shared`/`-private`/`-22`/…}).
It does not suggest being a part of the npm search path,
looks flexible enough and should be compliant with FHS.
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com irc: jstanek
signature.asc
Description: PGP signature
--
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
RFC: Private installation location for NodeJS modules
Hello list! # TL;DR I'm looking for installation location for node_modules shared between multiple NodeJS streams without necessarily being visible to other packages. The current candidate is /var/lib/nodejs/node_modules. # Longer version During recent onboarding of nodejs22 package, we ran into issues with un-bundled WASM dependencies/components (nodejs-undici/nodejs-cjs-module-lexer packages). They are currently installed into the default `%nodejs_sitelib` (/usr/lib/node_modules/); that directory is a symlink pointing to /usr/lib/node_modules_XY, where XY is the current default NodeJS stream. The problem is that I would like to have these components shared between all streams, without needing for them to be built separately for each stream unless proven necessary. But because the un-versioned `/usr/lib/node_modules` is not an actual directory, I'm forced to use the default stream. This has several drawbacks: 1. For other streams, it's tricky (although doable) to point the configure script to the un-bundled components. Current macros aren't usable, as they are being parametrized by the current stream automatically. 2. Parts of any non-default streams are located in a location owned by another stream/package. If you only install non-default stream, you would end up with at least 2 `/usr/lib/node_modules_XY` folders on your system. 3. Possibly others. :-) I can come up with a workaround for most of the drawbacks; nevertheless, I would prefer coming up with a cleaner solution. While discussing the problems with more upstream-adjacent colleagues, they mentioned that exposing the components used by the NodeJS engine itself fot other packages/apps is generally frowned upon. While I'm not generally partial to the way any NodeJS application bundles dependencies, it gave me an idea that could alleviate most of my problems. I'm now thinking of making the un-bundled components semi-private, in the sense that while they will be installed on the system and visible to any properly configured NodeJS engine, they would not generally be importable by outside applications: 1. Instead of /usr/lib/node_modules, use /var/lib/nodejs/node_modules for any shared, un-bundled components of NodeJS. 2. Use that location directly in configure script of any NodeJS engine (that part does not use the usual import mechanism for npm modules). 3. For backward compatibility, the private directories could be symlinked to /usr/lib/node_modules_XY, which should make them importable by npm. --- I like this idea, but I would like to hear any opinions from wider Fedora community. It's entirely possible I overlooked something important, and I would rather scrap the idea than commit to something broken. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Node.js] Stepping down as Node.js Maintainer in Fedora
Hi Stephen! Stephen Gallagher writes: > Just a reminder that I will be orphaning the nodejsXX packages in a > little over a week. As of yet, no one has requested access to take it > over. If anyone is going to do so, I encourage you to do it soon if > you would like my help coming up to speed. Unless any brave hero appears from the weeds, I'll be taking them. Right now I see no way on Pagure to request ownership/co-maintenance (maybe I'm just blind). Anyway, feel free to add me to maintainers and/or transfer the ownership. As for getting up to speed, unless you've added anything new in the last month or so, I think I'm good. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [Node.js] Stepping down as Node.js Maintainer in Fedora
As the downstream maintainer of NodeJS, I want to express both thanks and deep understanding of your situation. Especially with the de-modularization effort, your work was always a godsend for us. Take care and good luck! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Major version update of reuse tool (3.0.2) incoming
Hello all! As of today, I have picked up maintenance of FSFE's reuse tool [1]. I have a major update in progress, which IIRC includes changes on how the CLI should be used. I do not know if any Fedora tooling uses this tool, but in case it does, consider this your heads-up. The update should land in rawhide sometime next week, and later also in F40 and F39. Let me know if that works for you or if I should change my plans. Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default NodeJS stream packages with versioned names are not available
Miro Hrončok writes: > Python does this similarly to nodejs (we have python3.11, pytohn3, > python3.13 in rawhide today), with one difference. The python3 package > provides python3.12. So when you do: > > requires: > - python3.12 > > It just works. > > I believe nodejs should provide nodejs20, the same way. Thanks for the suggestion, I did not think about provides at all when mulling over the problem. Kudos! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default NodeJS stream packages with versioned names are not available
Stephen Gallagher writes: > That said, I agree that it's completely reasonable to have the default > version also `Provides: nodejsXX` and I'll look into it. Provides is something I did not consider at all, and it looks like the easiest way forward! Let me know when you get around to it; alternatively, I can throw together a package PR. > I'm confused; it *is* in addition to the versioned ones. We just don't > duplicate the default version because it would be a complete waste. I meant having both versioned and unversioned packages for the *same* (default) stream available. Probably really overkill if the provides works. > The overly-simplified answer here is mainly that there are too many > symlinks to maintain for this to be practical. Acknowledged; thanks for info. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Default NodeJS stream packages with versioned names are not available
Hello all,
recently, when trying to spin up a CI for NodeJS in Fedora, I ran into a
slight problem: when a NodeJS stream is the default one, versioned
packages (i.e. nodejs20) are not generated and are not installable.
For example, on current rawhide, I cannot install `nodejs20` package,
only `nodejs`; this will give me the version 20.x as expected.
The problem is that this complicates the CI setup,
and requires me to take into account which Fedora I'm currently on.
As an example, when adding tests for nodejs20 dist-git[1],
I would like to simply specify `requires: nodejs20` into the test
metadata. However, with the current setup, I would need something akin
to the following (pseudocode, I did not really test if that would work):
requires:
- {% if fedora == 40 %}nodejs{% else %}nodejs20{% fi %}
In addition to being more complicated, this will also break if the
default stream for a given Fedora version ever change
(which is not unlikely to happen, as the upstream release schedule
is not really synchronized with the Fedore one).
---
I recall that the current status is the result of already existing
long discussion, with associated debugging, so I would like to have this
solved with as minimal disruption as possible. That being said,
what is the reason for having the non-versioned packages (`nodejs`) *in
stead* of the versioned ones (`nodejs20`), as opposed to *in addition*
to them?
The non-versioned packages could then require the appropriate versioned
ones and contain only symlinks (/usr/bin/node → /usr/bin/node-20,
/usr/lib/node_modules → /usr/lib/node_modules_20, etc.).
Let me know what you think!
Best regards,
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com irc: jstanek
signature.asc
Description: PGP signature
--
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Adding/creating wasi-libc++ into the wasi-libc package
Hello! Tom Stellard writes: > Would it be possible to re-use the existing libcxx package and > just build it twice, once for the host and once for wasm? Kind > of like what some packages do for mingw? Maybe; I assume nor me nor Jan have any previous experience with building libcxx, so we are not really qualified to answer. The upstream wasi-sdk project (which my wasi-libc is one part of) generally relies on llvm toolchain for everything. The SDK itself is basically a llvm/clang/clang++ built to emit WASM with associated standard libraries thrown in. Now it might be possible to just build the GNU libcxx for wasm32-wasi target (presumably using wasi-libc as the libc implementation) and that would be usable; on the other hand, it might not, and the llvm libcxx would be needed. Tom, would you be able to provide a test build of libcxx for wasm32-wasi, so the other Jan can see if that would work for him? Then we can decide what approach to take next. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature -- ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: dlmalloc CC0 license (was Re: Packaging a cross-compilation environment (wasi-libc))
Hi Daniel, "Daniel P. Berrangé" writes: > I'm reviewing another package (sgxsdk) which also includes a copy > of dlmalloc with the CC0 license declaration. I wondered if you > ever made contact with Doug Lea around this question ? I recall trying to reach him via mail and not being successful; however, since at that time we were pivoting to use another malloc implementation, I did not push that very far (i.e. trying to find other e-mails than the one from changelog). -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Review swap – wasi-libc
Hello, I have a RR opened for wasi-libc, C standard library implementation on top of WebAssembly System Interface. There were already some back and forth discussion on the package, and I feel it is now ready for the formal review. https://bugzilla.redhat.com/show_bug.cgi?id=2166379 I'm willing to take a review or two in exchange for helping me push this forward. Thanks in advance! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
Hi Jun, "Jun Aruga (he / him)" writes: > Do you have a plan to create the RPM package for wasi-sdk[1]? Not really, since we already (almost) have it available :) The wasi-sdk consists of llvm toolchain (clang & friends) compiled so that it can emit WASM code, and the wasi-libc, which implements standard C library atop WebAssembly System Interface "syscalls". Fedora's clang is already capable of emitting wasm (`clang --target=wasm32-wasi -nostdlib …` works), so I see no need to package it again. The thing we are missing is the wasi-libc, which I aimed to package. In other words, packaging wasi-sdk seems redundant to me – you would have to maintain separate version of clang, while the Fedora one is already able to compile what you need. We still need the C lib. Unfortunately, recent NodeJS releases had me occupied pretty much entirely, so I was unable to work on this. I hope I can get back to it this week. Fingers crossed. > But I > feel it takes more than 60 minutes, and is still in progress. > I wonder how other program languages supporting WebAssembly manage > this situation. Yeah, building entire compiler toolchain takes a while :) I had a COPR of the WIP wasi-sdk, but I set it to expire automatically, so it is currently not available. I'll try to spin in back up today and send you a link, in case you want to start testing the Ruby stuff with it already. Have a nice day! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
To better collaborate on this, I've pushed my working copy of the package to gitlab [1]. It's a bit experimental (i.e. it tries to use source-git [2] approach to development), but should allow any interested party to review what I'm doing :) Integration with COPR is on my TODO list. [1]: https://gitlab.com/khx/fedora/wasi-libc [2]: https://docs.fedoraproject.org/en-US/ci/source-git/ Florian Weimer writes: > You can try to replace the current version with dlmalloc 2.7.2, which > still comes with the previous public domain dedication: > > <https://gee.cs.oswego.edu/pub/misc/> > > We can also ask Doug Lea if he can go back to the previous public domain > dedication. I've got some comments on the wasi-libc issue that another malloc might work as well. Nevertheless, I'll try to contact Doug Lea with the explanation and see where that leads. Thanks! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
Hello all again! Some good news: With a gentle poking [1], the wasi-libc now have a tagged version(s) - or at least tags corresponding to the version used in a WASI-SDK. That should help us better agreement on which version to use down the road. [1]: https://github.com/WebAssembly/wasi-libc/issues/317 Josh Stone writes: > It might be fine to share this, as long as you are not patching upstream > wasi-libc in some weird way. Rust's use is pretty minimal from vanilla > sources, and mostly only updated when we need compatibility to build > with a new Clang, in wasi-libc's Makefile "check-symbols" target. I'm hoping we will be able to build it as-is; the only thing I'm now currently patching is the Makefile, so that it picks up CFLAGS from the environment. These flags get filtered to only those applicable to the wasm32-wasi target. The main issue I'm fighting with currently is the CC0-licensed dlmalloc and it's possible replacement with the musl one. It seems that the dlmalloc is used mainly because it does not need a mmap-like capabilities on the system; WebAssembly does not provide that. I'm yet to succesfully compile the libc with any other malloc implementation – any help or pointers appreciated. I've also opened an inquiry about this upstream [3]; we'll see how that goes. [3]: https://github.com/WebAssembly/wasi-libc/issues/319 -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Packaging a cross-compilation environment (wasi-libc)
Hi again, thanks for all the suggestions! I'm taking the AVR approach so far; if you want to play with my drafts, I have a experimental COPR: https://copr.fedorainfracloud.org/coprs/jstanek/wasi-libc/ I plan to open a proper Fedora Review request on Monday; right now, I'm a bit too tired to go through the bureaucracy 🙂 Have a nice weekend! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Packaging a cross-compilation environment (wasi-libc)
Hi list,
in order to be able to compile WASM natively on Fedora,
I'm trying to package wasi-libc[1] to provide the Web Assembly System
Interface.
[1]: https://github.com/WebAssembly/wasi-libc
My trouble is that this is in essence a cross-compilation environment,
and I have zero experience in trying to package these.
Also, I did not have much luck in trying to find any related
documentation.
Some issues I have run into so far:
- This is a libc implementation, which would probably conflict with the
glibc package by default. Looking at musl, the solution seems to be to
install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`).
Not really sure how this works, any pointers appreciated.
- Clang seems to have issue with `-fstack-clash-protection` flag for the
`wasm32-wasi` target. What's the proper way to adjust these?
Any additional tips on cross-compilation support in Fedora would also be
appreciated :)
Thanks in advance for any help!
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com irc: jstanek
signature.asc
Description: PGP signature
___
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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora ID and HTTPS
Kevin Fenzi writes: > On Thu, Feb 03, 2022 at 07:16:01AM -0800, Jan Staněk wrote: > > Hi list, > > > > tl;dr: Why is the Fedora ID server using HTTP communication by default? > > Fedora openid is using http because long ago when we started offering > openid users were 'http://username.id.fedoraproject.org' and thus were > tied to this identity. If we changed it, everyone using that openid > would be a new different person to whoever they were authenticating. That makes sense – thanks for the explanation! > Some things to note: > > * openid is old, most places have dropped it. > ... > > really these days you want to move to OIDC or the like. Probably, but this is not a new app, and given it's projected lifespan, I do not consider it worthwhile to redo the authentication method. Thanks for the insight! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fedora ID and HTTPS
Hi list, tl;dr: Why is the Fedora ID server using HTTP communication by default? Some context: I was debugging a login process for the www.softwarecollections.org website, which utilizes Fedora ID. After pulling my hair for a bit, it turned out that the somewhere along the network road, any un-encrypted HTTP requests were getting blocked, while HTTPS requests were allowed. This causes the login process to timeout in the middle, since it tried to do OpenID discovery using HTTP. Now, I really do not understand how the OpenID is *supposed* to work, but unless I missed something, the HTTP requests were issued in reaction to initial response from the Fedora ID service. To put it differently, my app was instructed to issue next request in the process on HTTP, even if the original one was over HTTPS. AFAIK that requests is immediately 302'd to HTTPS afterwards, but given the network settings, I have never get that far. That got me wandering – why is the HTTPS not used in the communication by default? In other words, why are the URLs returned in responses from Fedora ID using HTTP instead of HTTPS, when the redirect suggests that HTTPS is preferred? As stated above, I have no real idea about how OpenID actually works, so link to the docs and "That's why" is considered a perfectly valid answer :) Preliminary thanks to anyone who takes the time to educate me on this! -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [Sway] wlroots 0.15 update is coming to rawhide
Hi Aleksei, that's awesome news! Thanks for the continous work you do. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaning python-bsddb3
As announced in the OP of this thread, I have now orphaned the package. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Orphaning python-bsddb3
Hello all, I'm the current maintainer for the python-bsddb3. Recently, it FTBFS in Rawhide [1], and the upstream now considers it deprecated [2], replaced with the `berkeleydb` python package. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2019310 [2]: https://www.jcea.es/programacion/pybsddb.htm I have packaged the `bsddb3` back when I was also maintainer of libdb in Fedora. I no longer take care of it, and I'm not interested in packaging the newer bindings. I've reached out to libdb maintainer, and they are not interested either [3]. [3]: https://bugzilla.redhat.com/show_bug.cgi?id=2019310#c4 The only packages that require the python-bsddb3 packages seem to be: exaile (runtime and buildtime) gramps (runtime) python-zarr (buildtime only) The maintainers are CC'd; feel free to reach to me if you want to take over python-bsddb3. If not, be advised that I intend to orphan it in a week or two, and your package will probably need changes. Best regards, -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review swap: rust-clang-ast
Hi all, one of my packages (newsboat) grew yet another rust dependency, and I need that dependency RPM reviewed [1]. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1974377 I'm willing to take a review in exchange, if you need any. Note that I tried to write directly to rust-sig ML, but that list is moderated and I do not know if anyone actually checks the queue :) If any Rust SIG members picks this one up, then I'm sorry for the double offer. -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek signature.asc Description: PGP signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Review swap: newsboat rust dependencies
Hi, Jerry James wrote: > I took them all. Thanks! Your OCaml packages should now be also reviewed, althoug Dan has beaten me to #1927441 :) -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek OpenPGP_signature Description: OpenPGP digital signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Review swap: newsboat rust dependencies
Hi all, I maintain newsboat [1], which in the latest version(s) grew new rust dependencies. I have prepared a review request for all of them, and I'm willing to review other packages in return. The reviews are the following bugs: 1927183, 1927210, 1927248, 1927353, 1927362, 1927385, 1927763, 1927790 All of them are generated with rust2rpm, so the review should be a quick one. Note however that they might depend on one another – I suggest using the TreeView+ in bugzilla to see their relations. As a rule of thumb, lower numbers generally needs to be reviewed/built before a higher one could begin. Thanks in advance to the brave soul(s) that are willing to pick this up :) [1]: https://newsboat.org -- Jan Staněk Software Engineer, Red Hat jsta...@redhat.com irc: jstanek OpenPGP_signature Description: OpenPGP digital signature ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Failure creating Fedora ID
Hello, I cannot help you with FAS, but if you could specify what problems do you have with the softwarecollections.org, I may be able to do something. Is this an issue with the website itself, or with a certain collections? Best regards, Jan -- Jan Staněk Associate Software Engineer Red Hat EMEA jsta...@redhat.com IM: jstanek ___ 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 need new maintainers (lot of nodejs deps will be retired next week)
On 29. 04. 19 18:44, Miro Hrončok wrote: > jstanek: nodejs-formatio, nodejs-sinon, nodejs-lolex, nodejs-util, > nodejs-samsam Claimed: https://pagure.io/releng/issue/8317 -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: Un-orphaned NodeJS packages upgrades in rawhide
On 29. 04. 19 15:42, Jared K. Smith wrote: > One of the frustrating things with NodeJS packaging in Fedora is that > because of the crazy number of dependencies between NodeJS packages, a > simple version bump in one package could cause a whole cascade of other > packages that need to be updated to newer versions to support that > dependency here. That's why I'm only doing this in Rawhide (and I would love to have something akin to Rawhide-testing). > The right thing to do in this case is to look at each of those packages, > find anything that's dependent upon those packages, and make sure each > one will still work with the newer version of the package. That will never work (long-term) without the cooperation with the maintainers of the affected packages. I'm happy to help with any issues caused by the update, but I would leave finding these issues to koschei. Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of. Best regards, -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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
Un-orphaned NodeJS packages upgrades in rawhide
Hello, I have recently (last week) taken on maintenance of several to-be orphaned nodejs packages. Since the packages were not upgraded for a while, they are usually a major version behind the upstream release. I have started to remedy this, but given the relatively large jump in version numbers, there might be issues. If your node package stops building in rawhide suddenly, check the dependencies for updates; feel free to reach to me with related issues. The upgraded (or soon to be upgraded) packages in question: - nodejs-bluebird - nodejs-clean-css - nodejs-grunt-known-options - nodejs-path-exists Keep in mind that the above list might expand in the near future, given the current situation with many nodejs-* orphans. -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: Orphaned packages need new maintainers
On 27. 04. 19 10:51, Miro Hrončok wrote: > Zuzka, Jan, I've seen you requested soem nodejs packages recently. Would > you be able to take some more? If needed to keep them from orphaning, yes; but I cannot promise any really active maintenance. The best I can promise is that I will *try* to keep them up to date with upstream; any bugs will likely go unfixed (unless included in upstream update, OFC). -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: Orphaned packages need new maintainers
On 26. 04. 19 16:24, Zuzana Svetlikova wrote: > I'll take them. Already mine (announced in the js-jquery orphaning thread) ;) -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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 js-jquery
On 25. 04. 19 12:13, Vít Ondruch wrote: > The reasons are the same as why I keep alive the other versions. I'm not > really going to maintain it unless I am totally bored. Also, there are > other dependencies which are going to be orphaned soon, so I might > change my mind ... I have claimed the dependencies (all I could find): https://pagure.io/releng/issue/8309 The maintenance will be on best-effort basis, since I do not have any working knowledge of JavaScript. -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: sway SIG
Before the social UNIX fallacy [1] kicks in, let me say that I'm interested in joining, and thank you for your activity ;) As a side note, a taiga board was noted in the sway bug discussion; as I have recently found out, the Fedora one is invite only – is there anyone with access to invite others, if there is interest? Good luck with the SIG process! [1]: "If nothing is going wrong, nothing needs to be said." -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: I've orphaned spec2scl
I'm willing to take it over, as it may come handy for my work with SCLs in CentOS. Also I'm planning in the near future to play with it and see if there is any need for necromancy :) -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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: Review swap: newsboat
On 15. 02. 19 17:01, J. Scheurich wrote:> I would review it (unclear, if i have the rights (i have a fedora > account, but i don't know, if this is sufficent for a offical review)) > in return for white_dune fedora sponsoring... I'm not able to sponsor new packagers, sorry. In the meantime, the review was done by ignatenkobrain -- thanks. -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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
Review swap: newsboat
Hi all, I have packaged terminal RSS/Atom reader newsboat [1] for Fedora, and I would like to have it reviewed [2] (ideally before F30 beta). Any volunteers? I offer to do a package review in return -- let me know if you need anything reviewed. Best regards, Jan [1]: https://newsboat.org/ [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1677291 -- Jan Staněk Associate Software Engineer, Core Services Red Hat Czech jsta...@redhat.com IM: jstanek signature.asc Description: OpenPGP digital signature ___ 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
Removing (or trying to) BerkeleyDB from Fedora
Hi guys, as the new BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2), and due to that many projects cannot use it, perhaps it is time to get rid of it from Fedora for good - or at least trim down the list of packages dependent on it as much as possible. The topic of BerkeleyDB v6 in Fedora was already discussed at this list [1], and it turned out that peaceful cooperation of multiple libdb versions in system is very problematic. As some packages cannot use newer versions, we are basically stuck with v5 - unless we get rid of it altogether or find another solution. I already started probing which packages depend on libdb and what can be done to remove that dependency. My findings are briefly documented on [2] and so far it seems that with some work it could be done. However, as I have only very hazy ideas on how some of the dependent packages are used or why they need libdb, I would like to ask for cooperation, ideally from the package maintainers themselves. The information on how to remove dependency, what would need to be done in addition to removing the dependency, or why it is a bad idea to try drop the dependency are all valuable. Thank you very much for any help. I welcome both edits in the wiki at [2] in case of relatively simple solutions, and ideas, thoughts and explanations on this mailing list. [1] https://lists.fedoraproject.org/pipermail/devel/2014-April/197406.html [2] https://fedoraproject.org/wiki/User:Jstanek/Draft_-_Removing_BerkeleyDB_from_Fedora -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
BerkeleyDB 6 symbol versioning and associated problems
One of the planned parts of the F21 System Wide Change: BerkeleyDB 6 [1] is the introduction of downstream symbol versioning of both versions of the libraries (libdb with v6 and libdb5 with v5). This part is planned in order to not introduce bugs similar to [2]. However, if we introduce downstream versioning (as upstream is generally unresponsive), then we face the problem similar to [3]. In short, if we introduce the downstream versioning, we will ship library with ABI incompatible with upstream ABI. If we won't, applications with modules/plugins (ie. Apache with mod_perl) that each use different version of the library may break due to double symbols (one from the v5 and other from v6, and ld would not know which symbol is which). I'd like to ask for suggestions on how to resolve this problem. The ideal solution would be to convince upstream to version their symbols (and I will contact them about it), but from my experience with them this is very unlikely. Or we could try to keep an eye on troublesome applications and force them and all their modules/plugins to be built with the same version of libdb, but I have no idea if this is even possible. As I stated above, I welcome any suggestions. I would also like to hear from someone responsible for the distro architecture which of the aforementioned issues is more painful for us, so we know which path to take if no complete solution is found. Best regards and thanks for replies, Jan [1] https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 [2] https://bugzilla.redhat.com/show_bug.cgi?id=768846 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1045013 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 24.4.2014 17:22, Jerry James napsal(a): > I need some advice on how to handle this for XEmacs, which is a GPLv3+ > package. Well, both GPLv3+ and AGPLv3+ have clause ([1], [2]) that allow code licensed under one of them link with code under the other one legally - only if you run the full product on a server and it interact with users trough network, you have to provide the source code. So AFAIK in your case you can use even the v6 libdb without license change. [1] http://www.gnu.org/licenses/gpl-3.0.html#section13 [2] http://www.gnu.org/licenses/agpl-3.0.html#section13 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 23.4.2014 20:23, Miloslav Trmač napsal(a): > Hello, > 2014-04-11 13:18 GMT+02:00 Jaroslav Reznik : > >> = Proposed System Wide Change: BerkeleyDB 6 = >> https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 >> > > At the FESCo meeting, we were unclear what happens to packages that don't > get updated; will they sty at v5, or will they (immediately, or after a > possible mass rebuild) start using v6? > > FESCo would prefer a transition plan in which we don't risk violating > licenses by omission (e.g. requiring an active maintainer's action to move > a package to v6, or having somebody sign up to verify all packages in case > the owners forgot). > Mirek > Well, in the current plan (make libdb5 "compat" package and updating the libdb to v6), after the mass rebuild the packages would start using v6. We could do it other way around (keep libdb in v5 and make libdb6 package), but this approach invites future problems with consecutive versions (v7, v8 probably should not be packaged in libdb*6*). Using another naming scheme would take care of part of the problem. I would actually prefer somebody to verify all packages that Require libdb and work with maintainers of said packages to eventually update their requires. If no one signes up to this, I will do it as part of the change (but even the I could use some help). If this proposal seems good to you, I will update the wiki page to reflect the agreement. Regards, Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 16.4.2014 15:44, Petr Pisar napsal(a): > On 2014-04-11, Jaroslav Reznik wrote: >> = Proposed System Wide Change: BerkeleyDB 6 = >> https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 > [...] >> The BerkeleyDB, used between others by rpm [1], changed license between >> versions 5.* and 6.* to AGPLv3+ from GPLv2+. As those two licenses are not >> compatible, packages using the BerkeleyDB either has to change its license >> to >> AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB >> entirely. >> > Does that mean than any GPL+ package linked to libdb-6 will have to > change license to AGPLv3+? That would have significant impact not only > on packagers but also on users. > I'm no lawyer, but as I understand it, any GPLv2+ package linked against libdb-6 will need to change license - however, AFAIK it could change its license to GPLv3+, because AGPLv3+ and GPLv3+ both have clauses that make them compatible with each other ([1], [2]). On the other hand, the clause [1] basically states (if I understood it correctly) that any such combination is basically under AGPLv3+, so i don't know if it makes much difference. [1] http://www.gnu.org/licenses/gpl-3.0.html#section13 [2] http://www.gnu.org/licenses/agpl-3.0.html#section13 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 16:59, Bill Nottingham napsal(a): > Jaroslav Reznik (jrez...@redhat.com) said: >> == Scope == >> * Proposal owners: Create new set of packages and introduce proper >> versioning >> in order to not confuse the dynamic linker. > > Is this symbol versioning intended to be upstream? Ideally, yes, but given the upstream willingness to incorporate community-proposed changes, I fear that we may in fact introduce downstream symbol versioning. The fact is that in order to reliably provide both library versions, we *need* the symbol versioning - preferably upstream, but if it won't be possible, we will have to version downstream (or find another solution to this problem). I will contact the upstream about this. -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 14:57, Chris Adams napsal(a): > Once upon a time, Jaroslav Reznik said: >> Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to >> AGPLv3+), to Fedora while keeping the older version for packages which >> cannot >> use BerkeleyDB with the new license. > > Have the packages that cannot use libdb-6 because of the license been > identified? That probably needs to be confirmed before moving forward, > due to libdb's symbols conflicting between versions if both get loaded. > For example (don't think these have license issues, just picked them off > the top of my head), if Apache linked with libdb-5 (because of license), > and perl linked with libdb-6, mod_perl would be broken. > > If there are any conflicts because of the license incompatibility, then > moving to libdb-6 may not be a good idea. > I'm aware of that problem, and it should be addressed by introducing the symbol versioning (see [1], first bullet). The exact problem you are mentioning was encountered before ([2]), and similar problem was dealt with in [3]. I intend to follow that case. To answer your question, I've not yet identified the packages, but I will look into it (or you are welcome to :) ). [1] https://fedoraproject.org/wiki/Changes/BerkeleyDB_6#Scope [2] https://bugzilla.redhat.com/show_bug.cgi?id=768846 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1045013 -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
Dne 11.4.2014 15:55, Florian Weimer napsal(a): > On 04/11/2014 01:18 PM, Jaroslav Reznik wrote: >> = Proposed System Wide Change: BerkeleyDB 6 = >> https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 >> >> Change owner(s): Jan Staněk >> >> Add BerkeleyDB v. 6, which changed license from previous releases >> (GPLv2+ to >> AGPLv3+), to Fedora while keeping the older version for packages which >> cannot >> use BerkeleyDB with the new license. > > Please correct the wiki page. The old license was Sleepycat (a short > license with a relatively strong copyleft component), and not GPLv2+. > > We had a packaging bug in some Fedora versions which labeled the libdb > license incorrectly, but this was fixed in Fedora 20. > Wiki page corrected, thanks for pointing that out. -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging of libdb-6+
Dne 7.4.2014 17:47, Honza Horak napsal(a): > On 04/07/2014 05:31 PM, Paul Howarth wrote: ... snap ... >> Does libdb-6 have the same symbol names as libdb-5? If so, there's >> probably not a lot of packages that can be built with libdb-6 without >> the possibility of causing symbol conflicts with others built against >> libdb-5 (which can't be updated for license reasons). > > Good question. Jan, can you investigate it, please? I built the upstream source for v6, and unfortunately it seems that the upstream does not version the symbols - which from the quick glance over them is the same as in v5. We will probably need to introduce the versioning, even if only downstream. Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaging of libdb-6+
Hello, as Oracle is unlikely to re-license the libdb6 back to GPL, I like to bring up the possibility of the libdb6 package. The idea is that the current libdb package would still provide the libdb-5+, which is still under GPL, and the new package would provide the newest, AGPL-ed libdb. I would like to hear opinions on this idea, and any suggestions are welcome. Cheers, Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Downstream .so versioning
Hi, What should one do if the SW he is trying to package produce only unversioned *.so files? I'm currently trying to package LMDB [1] as possible alternative for BerkeleyDB in Fedora, and the hand-written makefile produce only liblmdb.so. I'm trying to persuade the upstream to change it and start to do it properly, however if that fails, what can I do with it on my end? Thanks for answer, Jan [1] http://symas.com/mdb/ -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Oracle considering DB6 license
Hello, some time back Oracle released new version of Berkeley DB under AGPL, which is incompatible with Fedora licensing politics. However, it turns out that Oracle might consider re-licensing it back: https://forums.oracle.com/message/11184885#11184885 If you are interested in DB6, consider leaving feedback there :) -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
