Re: [gentoo-dev] Interest in a yarn / NPM eclass
Il giorno mer 8 giu 2022 alle ore 22:45 Robin H. Johnson ha scritto: > On Wed, Jun 08, 2022 at 07:23:15PM +0200, Alessandro Barbieri wrote: > > I'm interested in an eclass that doesn't bundle everything together. Also > > I'm interested in anyone that can share the package maintainership (in > guru > > first). > > > > I've already tried 3 approaches: > ... > > Since you know this yarn/NPM ecosystem well, could you evaluate two > other ideas? > 4) Solutions like EGO_SUM > My second approach was like that > 5) EGO_SUM successor of 2nd-level-Metadata-Manifest that I described in > the recent EGO_SUM thread. > I havent' well understood it. In practice would be the same as 2/4 with the same issues. Let me remind you that unlike go/rust, nodejs packages aren't compiled and if you bundle everything you'll end up with a massive amount of files installed. Please don't consider node any different from python/ruby/perl/php.
Re: [gentoo-dev] Interest in a yarn / NPM eclass
Il Lun 6 Giu 2022, 13:16 Andrew Ammerlaan ha scritto: > Hi Chris, > > I think @Alessandro (CC) has already done some work on this over at [1]. > I'm not sure what the status of it is though. Maybe you two can discuss > this together to avoid doing double work. > > Best regards, > Andrew > > [1] https://github.com/Alessandro-Barbieri/node-overlay > > On 05/06/2022 07:47, Chris Pritchard wrote: > > Hello, > > > > Would there be any interest in a yarn / NPM eclass that supports offline > > installs. For a personal overlay I’ve got a working yarn.eclass > > ( > https://github.com/chriscpritchard/overseerr-overlay/blob/main/eclass/yarn.eclass > > < > https://github.com/chriscpritchard/overseerr-overlay/blob/main/eclass/yarn.eclass>) > > > and I’ve been able to make a version that supports npm from > > NPM-Shrinkwrap or npm-lock.json files (this is still being tested). > > > > If there is an interest, would anyone be willing to support me in having > > an eclass added to the tree? > > > > Thanks, > > > > Chris > > I'm interested in an eclass that doesn't bundle everything together. Also I'm interested in anyone that can share the package maintainership (in guru first). I've already tried 3 approaches: 1) one package per dependency. The npm eclass is working fine for now, you can unbundle packages that depend on system libs (like sqlite), the major issue I've found is in the circular dependencies of the rollup package. 2) bundle everything. This approach doesn't always work. Some packages fail to build dependencies written in C and you can't unbundle them. 3) package every runtime dependency and bundle build time dependencies. Since rollup is a build time dep, I've tried to bundle every build time dep but this require to create a custom stuff and host it somewhere.
[gentoo-dev] Reliably find MPI implementation
I have a package that uncorrectly guesses the mpi implementation because it's grepping the /usr/include/mpi.h and since it's a multilib wrapper, it doesn't contain the defines. I can specify the mpi implementation while configuring. How to reliably detect the MPI implementation? I need something (eclass ?) that return one the following: openmpi/mpich/mpich2/mpich3/lam/etc. based on the current installed status
Re: [gentoo-dev] [PATCH 0/2] Add esed.eclass for sed that dies if caused no changes
Il giorno mar 31 mag 2022 alle ore 13:23 Ionen Wolkens ha scritto: > Often preferable to use patches so this happens, but sed have its > uses/convenience and this intend to help reduce the amount of old > broken seds causing issues that go unnoticed on bumps. > > Inspired by app-portage/iwdevtools' qa-sed (warns on any seds), but > this is for more deterministic use in ebuilds. > > Also slightly shortens sed use, -i is default, and no need to || die. > (see @EXAMPLE in eclass for a quick usage overview). > > Implementation / available wrappers / usefulness still up for debate, > but without further comments I consider this ready (albeit first time > touching / making an eclass, so I could be overlooking simple things). > Also partly uses >=bash-4.4, so EAPI-7 is not considered. > > See github PR[1] for old changelog background. > > Up to maintainers but personally would encourage to slowly replace > (almost) all use of sed with either this or patches. Some cases > where it can be inconvenient like eclasses "guessing" that a package > may or may not have something to replace, and that nothing happened > is not an issue. > > [1] https://github.com/gentoo/gentoo/pull/25662 > > Ionen Wolkens (2): > esed.eclass: new eclass > eclass/tests/esed.sh: basic tests for esed.eclass > > eclass/esed.eclass | 199 +++ > eclass/tests/esed.sh | 173 + > 2 files changed, 372 insertions(+) > create mode 100644 eclass/esed.eclass > create mode 100755 eclass/tests/esed.sh > > -- > 2.35.1 > > > I use patches for static content, not a big fan of wall of sed in ebuilds When I use sed is for dynamic content and mostly like to do this: s|lib|$(get_libdir)|g In this case esed would be deleterious because it would fail on 32 bit arches
Re: [gentoo-dev] Upstream remote-id types in package metadata
Il Dom 22 Mag 2022, 09:09 Ulrich Mueller ha scritto: > According to the XML schema [1], the following remote-id types are > currently allowed: > >bitbucket >cpan >cpan-module >cpe >cran >ctan >freecode >freshmeat >github >gitlab >gitorious >google-code >heptapod >launchpad >pear >pecl >pypi >rubyforge >rubygems >sourceforge >sourceforge-jp >vim > > Some of them seem to be obsolete. Presumably freshmeat, gitorious, and > google-code should be removed? Any other removal candidates? > > Looks like SourceForge-JP was renamed to OSDN, should the file reflect > that? > > Also, the "gentoo" remote-id was added the the DTD [2] but is missing > from the XML schema. Presumably it should be added there, too? > > Comments please. > How to propose new values? >
Re: [gentoo-dev] [PATCH 0/1] Add 'notes' element to metadata.xml (GLEP 68)
> Maybe we could just add README files to the package directories > in question. This would have the clear advantage that the files will be > immediately visible. > I'll personally prefer a readme. Also almost all metadata.xml features are underused >
Re: [gentoo-dev] [PATCH] Add deblob support only for python3
> > IIUC, it will disable CPU microcode updates. The code being removed is > entirely free (but it could load some non-free third-party microcode). > Do we really endorse that, from a security (spectre, meltdown, etc.) > point of view? > rt-sources aren't supported by the kernel team >
Re: [gentoo-dev] [PATCH] Add 2021-06-30-libxcrypt-migration
Il Mar 6 Lug 2021, 05:55 Marco Scardovi ha scritto: > Hi there, > > attached italian translation too > >Se, per qualunque motivo, *non* hai desidero di fare il passaggio ora Se, per qualunque motivo, *non* hai desiderio di fare il passaggio ora >
Re: [gentoo-dev] last-rite: some java stuff
> > # Miroslav Šulc (2021-04-28) > # no consumers > # removal in 30 days > # see bug: https://bugs.gentoo.org/786783 > dev-java/skinlf > It's needed for scilab[gui] from the science overlay. It may be worth keeping it or moving it to science >
Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...
Il Mar 2 Mar 2021, 20:03 Matt Turner ha scritto: > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > why don't we just enforce putting each > > keyword on a separate line instead, so that we don't have this problem > > in the first place? > > Why don't we change 30 thousand ebuilds rather than use this script? > IMO before this the keyword mechanism should be reworked to be three-state: 1 Arch known working 2 Arch known not working 3 Arch untested/status unknown And let the user choose to use packages from 3 or not
Re: [gentoo-dev] Make 'man' global USE flag from currently local
Il Sab 13 Feb 2021, 02:19 Aisha Tammy ha scritto: > Hi all, >I am proposing to make the `man` USE flag into a global one. > Currently it is used by ~45 packages most of which have the same > description 'Build and install man pages': > https://packages.gentoo.org/useflags/man > Hopefully no objections to this part? > > Cheers, > Aisha > IMO manpages should be installed unconditionally and the useflag dropped >
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
Il Lun 8 Feb 2021, 12:19 Michał Górny ha scritto: > Hi, > > FYI the developers of dev-python/cryptography decided that Rust is going > to be mandatory for 1.5+ versions. It's unlikely that they're going to > provide LTS support or security fixes for the old versions. > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. > > According to upstream platform support information [1], this probably > means (eventually) entirely removing the following architectures: > - alpha (stable) > - hppa (stable) > - ia64 (stable) > - m68k (exp) > - s390 (except for s390x, exp) > > Furthermore, the Gentoo Rust packages are missing support > for the following platforms, apparently supported upstream: > - mips (exp) > - ppc (32) (stable) > - sparc (stable) > - s390x (exp) > - riscv (stable) > > Apparently it's non-trivial to bootstrap Rust on these platforms, > so it's unclear when Gentoo is going to start providing Rust on them. > > I've raised a protest on the cryptography bug tracker [2] but apparently > upstream considers Rust's 'memory safety' more important than ability to > actually use the package. > > Honestly, I don't think it likely that Rust will gain support for these > platforms. This involves a lot of work, starting with writing a new > LLVM backend and getting it accepted (getting new code into LLVM is very > hard unless you're doing that on behalf one of the big companies). You > can imagine how much effort that involves compared to rewriting the new > code from Cryptography into C. > > If we can't convince upstream, I'm afraid we'll either have to drop > these architectures entirely or fork Cryptography. > > > [1] https://doc.rust-lang.org/nightly/rustc/platform-support.html > [2] https://github.com/pyca/cryptography/issues/5771 > > -- > Best regards, > Michał Górny > Should we shed tears for those legacy architectures or move forward? Does anyone really use them in production? >
Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?
>
> Installing both openssl and libressl .a files in different directories
> seems both useful and straightforward. I don't object to openssl being
> favored for /usr/lib here, libressl gets a directory of its own, but
> libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
> Obviously this will only be useful for packages wanting to statically link
> with libressl lib{crypto,ssl}
There is an ongoing effort to remove static libraries from packages.
but I think that's far better than removing
> libressl.
>
No, it's not better, it's more work for the security team.
>
Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal
Il giorno lun 7 set 2020 alle ore 14:10 Ulrich Mueller ha scritto: > The devmanual [1] says that a revbump should be done when a new runtime > dependency is added to an ebuild, but it doesn't say that for removal of > a dependency. > > We are talking about the second case here, because the dependency on the > virtual is being removed, while the dependency on its provider remains > in place (it only changes from an indirect to a direct dependency). > > Ulrich > > [1] > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html > > That what's I've done here https://github.com/gentoo/gentoo/pull/13443#issuecomment-553764133 but you decided to make me do a revbump. Being consistent in decision is hard I see.
Re: [gentoo-dev] zoom concerns
What about moving all of these binary-only packages in an official overlay (made for the scope) or in GURU? Il Gio 2 Apr 2020, 02:48 Rich Freeman ha scritto: > On Wed, Apr 1, 2020 at 8:18 PM Alessandro Barbieri > wrote: > > > > I have concerns about the inclusion of zoom in ::gentoo. For me it's > more like a malware. > > From the hacker news feed you'll find out that: > > I guess we could stick an einfo in the post-install messages, but if > you're joining a zoom meeting are you going to be any more secure if > you manually install the files instead? I can't imagine that people > are going to stop attending meetings just because they picked the > wrong software to host them. Plus a few of those concerns apply to > MANY packages - such as a lack of end-to-end encryption, or ever > having had a zero day. > > I'm not intending to endorse Zoom here, but Gentoo isn't really > intended as a purist distro that will never include a package if it is > associated with a service that might collect user data and so on. In > fact, we have many packages with these associations. Ultimately users > can decide what they want to run, and we're just providing the files > in the most convenient and secure manner possible. For example, when > the zero day is fixed if you're using Gentoo you'll benefit from our > security policy, while you would not if you had just manually > installed some files/etc... > > -- > Rich > >
[gentoo-dev] ceph's static-libs
I was trying to remove static-libs from hwloc and I noticed that the last bump of ceph is requiring hwloc:=[static-libs?] And I notices it needs also alot of other dependencies with [static-libs?] Is there a *valid* reason for having ceph[static-libs] around in the first place? For more context on static-libs see: https://projects.gentoo.org/qa/policy-guide/installed-files.html?highlight=static#pg0302 https://flameeyes.blog/2011/08/29/useless-flag-static-libs/ https://archives.gentoo.org/gentoo-dev/message/2dada80c2b9c85b0e83e6328428bf8ab
[gentoo-dev] zoom concerns
I have concerns about the inclusion of zoom in ::gentoo. For me it's more like a malware. >From the hacker news feed you'll find out that: [1] zero day vulnerability found [2] passwords are truncated to 32 bit [3] previously sent data to facebook [4] end to end traffic isn't encrypted [5] signed binary run unsigned script 1 https://techcrunch.com/2020/04/01/zoom-doom/?guccounter=1 2 https://news.ycombinator.com/item?id=22749706 3 https://www.vice.com/en_us/article/z3b745/zoom-removes-code-that-sends-data-to-facebook 4 https://theintercept.com/2020/03/31/zoom-meeting-encryption/ 5 https://news.ycombinator.com/item?id=22746764
Re: [gentoo-dev] Last rites: media-fonts/symbola
Version 10.23 is here https://web.archive.org/web/20180129230141/http://users.teilar.gr/~g1951d/Symbola.zip Il Dom 29 Mar 2020, 23:20 Chí-Thanh Christopher Nguyễn ha scritto: > # Chí-Thanh Christopher Nguyễn (2020-03-29) > # Old releases gone from upstream, new releases use overly restrictive > # license. For ancient scripts and symbols, use media-fonts/quivira > instead. > # For emojis and pictographs, use media-fonts/noto-emoji instead. > # Masked for removal in 30 days, bug #715226 > media-fonts/symbola > >
