Re: [gentoo-dev] Request to add USE_EXPAND variable for freecad-0.18*+
Oh, ok I see. Thanks for your reply. Am Mo., 3. Juni 2019 um 17:36 Uhr schrieb Michał Górny : > On Mon, 2019-06-03 at 17:24 +0200, Bernd Waibel wrote: > > Hello Gentoo devs, > > > > I have been maintaining the Qt5 updated media-gfx/freecad-0.18* for some > > time in my overlay[1]. As far as I can see, all dependencies have either > > been released in the main portage tree, or have blocking bugs > open[2][3][4]. > > > > To develop the re-adding of the package further, I'd like to discuss the > > possibility of adding a USE_EXPAND variable called FREECAD_MODULES as > noted > > in profiles/base/make.defaults. > > > > > > Rationale > > === > > FreeCAD has a modular design of different so-called workspaces. This > > enables the program to be built for the particular purposes of i.e. > > architectural CAD, engineering CAD, FEM, ship design and even raytracing > or > > robot simulation. Those workspaces can, to some extent, be built > > independently of each other. They are dependant on some basic modules > which > > serve as the core engine of the program. > > > > To give the user the possibility to build FreeCAD depending on it's > needs, > > the FREECAD_MODULES should be used. > > > > Currently the variable has ~40 modules defined. For a complete list, I'd > > like to refer to the ebuild in my overlay. I'm open for discussion on the > > list of modules, it might be possible, that some of them are better > placed > > in USE flags. > > > > I hope, this variable get's an approval from the devs. I personally found > > the alternative, to use a whole lot of USE flags less elegant than this > > solution. > > > > If this is used by a single package only, it doesn't belong in > USE_EXPAND. Just define local flags. > > -- > Best regards, > Michał Górny > >
[gentoo-dev] Request to add USE_EXPAND variable for freecad-0.18*+
Hello Gentoo devs, I have been maintaining the Qt5 updated media-gfx/freecad-0.18* for some time in my overlay[1]. As far as I can see, all dependencies have either been released in the main portage tree, or have blocking bugs open[2][3][4]. To develop the re-adding of the package further, I'd like to discuss the possibility of adding a USE_EXPAND variable called FREECAD_MODULES as noted in profiles/base/make.defaults. Rationale === FreeCAD has a modular design of different so-called workspaces. This enables the program to be built for the particular purposes of i.e. architectural CAD, engineering CAD, FEM, ship design and even raytracing or robot simulation. Those workspaces can, to some extent, be built independently of each other. They are dependant on some basic modules which serve as the core engine of the program. To give the user the possibility to build FreeCAD depending on it's needs, the FREECAD_MODULES should be used. Currently the variable has ~40 modules defined. For a complete list, I'd like to refer to the ebuild in my overlay. I'm open for discussion on the list of modules, it might be possible, that some of them are better placed in USE flags. I hope, this variable get's an approval from the devs. I personally found the alternative, to use a whole lot of USE flags less elegant than this solution. Thank you for your time! I'm happy for any feedback I'll receive on this topic. Regards, Bernd [1] https://github.com/waebbl/waebbl-gentoo/tree/master/media-gfx/freecad [2] https://bugs.gentoo.org/624682 [3] https://bugs.gentoo.org/659478 [4] https://bugs.gentoo.org/686972 -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: games-rpg/eternal-lands
Hi Rich, I replied to the bug you mentioned and like to proxy-maintain the package. I'd like to see the game stay in the tree if possible at all. Cheers, Bernd Am Mi., 24. Apr. 2019 um 15:17 Uhr schrieb Rich Freeman : > Removing this one as the maintainer, but would be happy to work with a > proxy maintainer if somebody wants to take over. I suspect it isn't > actually in-use... > > # Richard Freeman (24 Apr 2019) > # Masked for removal in 30 days. Likely does not work > # and is essentially unmainted. Please comment in > # bug 548926 if you want to give this some care. > games-rpg/eternal-lands > games-rpg/eternal-lands-bloodsucker > games-rpg/eternal-lands-data > > -- > Rich > > -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
Michał Górny schrieb am So., 25. Nov. 2018 um 11:05 Uhr: > app-eselect/eselect-opencascade > dev-python/pycollada > media-gfx/openscad > sci-libs/opencascade > I'd take these four Regards Bernd -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: dev-db/pgadmin4
The subject seems to be wrong. It says pgadmin4, but the mask says pgadmin3. Aaron W. Swenson schrieb am Fr., 26. Okt. 2018 um 01:38 Uhr: > # Aaron W. Swenson (25 Oct 2018) > # Fails to build against up to date OpenSSL library (Bug 663966). No longer > # supported upstream. Use dev-db/pgadmin4. > # Masked for removal on 2018-11-24, bug #669650. > dev-db/pgadmin3 >
Re: [gentoo-dev] Is there any way I can help with pull requests?
Virgil Dupras schrieb am Di., 16. Okt. 2018 um 20:26 Uhr: > > Maybe I can try to explain why your 3 PRs [1] are still opened. > > Regards, > Virgil > > [1]: https://github.com/gentoo/gentoo/pulls/rseichter > [2]: https://wiki.gentoo.org/wiki/Project:Net-Mail +1 Thanks a lot for this post Virgil. For me it made some things a lot clearer and more tolerable. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] Packages up for grabs: app-misc/gramps, dev-libs/granite, media-gfx/sane-frontends, media-gfx/yafaray, net-dialup/freeradius, sys-apps/miller
> +1 for media-gfx/yafaray > if there are no objections or anyone else is up for it. -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] [PATCH] appimage.eclass: new eclass
Mykyta Holubakha schrieb am Sa., 6. Okt. 2018 um
13:18 Uhr:
> Signed-off-by: Mykyta Holubakha
>
> I'm proposing to add a new eclass: appimage.eclass, to facilitate
> extraction off AppImage bundles. The rationale is that some upstreams
> have migrated to distributing their proprietary software exclusively as
> AppImage bundles. (for instance dev-util/staruml-bin).
>
> An example ebuild can be seen at https://git.io/fx3Mg
>
>
I was also thinking of something, too. This direction of development
happens for a couple of years already, with more and more vendors /
upstream jumping on it. It was also highly recommended by Linus Torvalds as
a way of distributing packages easily along different linux flavors. I
don't think we should easily deny the direction where this is going.
Most appimages are distributed through central well-known servers. The
files have a sha1 BuildID attached to them (can be seen via file command),
which can possibly be used to verify them, so decreasing the possible
vulnerability to such packages somewhat. There might also be additional
ways to verify the integrity of them through the appimage API. They are
statically linked packages with no external dependencies, and contain a
squashfs filesystem in it.
>From a users point of view, I think it'd be a good idea, to give users the
possibility of installing appimages with the package manager, so they can
be handled accordingly, instead of just let them download the files and
move them into a separate folder in ${HOME} for execution. This would be
especially useful for propietary bin-packages, as well as for some big
packages, which are actually hard to maintain for proxy-maintainers, and
therefore get removed from the tree (freecad comes to my mind as an
example).
2. Are we OK with executing AppImage bundles downloaded from the
> Internet (an alternative would be to implement a proper extractor
> program, which would unpack the images without executing them, and add
> it to DEPENDs).
>
It think, this has mostly the same attack vectors which apply for
bin-packages. So there's not much new from my point of view.
> +# @FUNCTION: appimage_src_unpack
> +# @DESCRIPTION:
> +# Unpack all the AppImage bundles from ${A} (with .appimage extension).
> +# Other files are passed to regular unpack.
>
I'm not sure, if it makes sense to unpack them. Most of them are not built
on gentoo systems, so the extracted binaries and libraries might not easily
run without having the ebuild maintainer check every single one of them for
run-time dependencies.
For example, the freecad appimage contains a bin/mkdir program linked
against libselinux.so.1 which is not available on non-selinux profiles by
default, or its usr/lib/freecad/lib/DraftUtils.so, a freecad internal
library, links against libboost_system.so.1.55.0 while we have
libboost_system.so.1.65.0.
I would propose to keep them packed and install them in /opt/AppImages or
something like that, thus providing only a src_install function with the
eclass. Ebuild maintainers could then just add a .desktop file or extract
one from the image if it's present and add it to the files/ directory for
desktop integration.
