nushell
No description set
- Devel package for openSUSE:Factory
-
5
derived packages
- Links to openSUSE:Factory / nushell
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout shells/nushell && cd $_ - Create Badge
Refresh
Refresh
Source Files (show unmerged sources)
| Filename | Size | Changed |
|---|---|---|
| _constraints | 0000000152 152 Bytes | |
| _service | 0000000966 966 Bytes | |
| _servicedata | 0000000236 236 Bytes | |
| nushell-0.96.0.obscpio | 0011637773 11.1 MB | |
| nushell.changes | 0000134049 131 KB | |
| nushell.obsinfo | 0000000097 97 Bytes | |
| nushell.spec | 0000001461 1.43 KB | |
| vendor.tar.zst | 0081888655 78.1 MB |
Latest Revision
buildservice-autocommit
accepted
request 1189289
from
Dead Mozay (Dead_Mozay)
(revision 63)
Dead Mozay (Dead_Mozay)
(revision 63)
baserev update by copy to link target
Comments 10
Is there anything blocking this from being submitted to factory?
There are some permissions issues, it is not yet clear what this is connected with, but if you set this shell by default, for some users the user session stops starting. https://github.com/nushell/nushell/issues/934 In this form, I would not send it to the factory.
I don't really think that should be a blocker as nushell is also useful as an interpreted language. Perhaps nushell could be submitted to factory through devel:languages:misc (or something similar) until it can function as the default shell (if that ever happens)?
Also, why does a shell have to be able function as the default shell in order to be submitted to factory? If you just don't add it to /etc/shells, the end user would have to manually add it in order to encounter the issue mentioned above.
The developers don’t know yet how to solve this problem, there is a workaround https://github.com/nushell/nushell/issues/10316, but the user will have to take care of it himself, not everyone will immediately understand why their session stopped starting
You can take a risk and send only to the devel repository, and see how many complaints there are, or suppress the message output when installing a package on the link with a workaround https://github.com/nushell/nushell/issues/10316
I think it would make more sense to just not add it to /etc/shells so that it could not be set as the default shell. That would avoid the issue entirely while still allowing it to be used as intended.
It can still be used as the interactive shell (either just by running it or configuring your terminal to use nushell as the shell), and it is quite useful as an interpreted language on top of that (for example, it has built in HTTP request support, can parse JSON, XML, etc...).
Is there some sort of rule for submitting shells to Factory that says they must function as the default shell? If not, I don't really understand the issue with not adding it to /etc/shells and letting it be used as an interactive shell and interpreted language.
https://en.opensuse.org/openSUSE:Factory_review doesn't say a thing about it. Also
fishis definitely in Factory on one hand, and making it work as login shell was a disaster back then in my time with it on another.My vote would be submitting a package to Factory as is and disable
/etc/shellsentry if reviewers will require it.In fact, anyone could submit it and see what happens.
/cc @dead_mozay
I'll bite, https://build.opensuse.org/request/show/1180698
AAAAND IT IS DONE! https://build.opensuse.org/request/show/1180945
Binary from latest version 0.89.0
nu: error while loading shared libraries: libssl.so.52: cannot open shared object file: No such file or directory
I don’t believe it, I just checked it on TW and Leap, I didn’t see any errors. Where did this library even come from? openssl 1.0 = /usr/lib64/libssl.so.1.0.0 openssl 1.1 = /usr/lib64/libssl.so.1.1 openssl 3 = /usr/lib64/libssl.so.3, /usr/lib64/libssl.so.3.1.4