[gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
media-gfx/splashutils fails to build, and it fails everytime one of it's reverse dependency changes dependencies because it fails to use pkg-config to query Libs: it's supposed to have proxy-maint, but nobody is pushing fixes for the supposed proxy-maint it's in no shape to be in tree as-is, and since spock@g.o has retired and was also the upstream of it, well, there is no upstream for it no upstream, no downstream, fails to build, bugs with patches but nobody to push them - lastriting the package in 2 weeks, this is the first heads up mail 17 bugs found: 326759 Gentoo S Vulnerab secur...@gentoo.org IN_P --- media-gfx/splashutils-1.5.4.3-r3: internal copy of vuln. libpng (CVE-2010-1205) 2013-10-13 307525 Gentoo S Auditing secur...@gentoo.org IN_P --- media-gfx/splashutils-1.5.4.3-r2: statically links to vulnerable jpeg and freetype 2013-06-16 354157 Gentoo L Core sys asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.3-r3: does not copy the initrd.splash into the initrd 2013-06-16 354639 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.3-r3 does not go into verbose mode with 'nox' boot option 2013-06-16 233267 Gentoo L Unspecif asaf.g...@gmail.com CONF --- media-gfx/splashutils: fsck vs bootsplash 2013-06-16 271835 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: some password prompt would be great for silent mode 2013-06-16 434368 Gentoo L Unspecif asaf.g...@gmail.com CONF --- media-gfx/splashutils-1.5.4.4-r1: linking to freetype fails due to missing static library zlib (-lz) 18:49:49 443856 Gentoo L Applicat asaf.g...@gmail.com UNCO --- media-gfx/splashutils-1.5.4.4-r2 failed to build - asm/posix_types.h: No such file or directory 2014-07-01 473512 Gentoo L Applicat asaf.g...@gmail.com IN_P --- media-gfx/splashutils-1.5.4.4-r2 /usr/bin/i686-pc-linux-gnu-ld: error in /usr/lib/klibc/lib/libc.so(.eh_frame); no .eh_frame_hdr table will be created. 2014-02-18 488524 Gentoo L Applicat asaf.g...@gmail.com UNCO --- =media-gfx/splashutils-1.5.4.4-r1 - splash_geninitramfs --append corrupts initramfs with kernel-3.10.16 2013-10-19 490530 Gentoo L Applicat asaf.g...@gmail.com CONF --- =media-gfx/splashutils-1.5.4.4-r4 needs freetype2 fixed as it has gained a libpng dependency 2014-04-01 499654 Gentoo L Applicat asaf.g...@gmail.com UNCO --- media-gfx/splashutils-1.5.4.4-r4 with media-libs/libmng-2.0.2-r1 - .../work/libmng-2.0.2/libmng_cms.c:160: undefined reference to `cmsFreeToneCurve' 2014-06-17 506124 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils[truetype] fails to build with =media-libs/freetype-2.5 18:51:59 398077 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: /sbin/fbtruetype links to libraries in /usr 2013-06-16 417375 Gentoo L New Ebui asaf.g...@gmail.com CONF --- media-gfx/splashutils: initramfs corruption when compression is not gzip (new genkernel feature) 2013-12-07 398075 Gentoo L Applicat asaf.g...@gmail.com CONF --- media-gfx/splashutils: please make the static linkage optional 2013-06-16 417439 Gentoo L Core sys asaf.g...@gmail.com UNCO --- media-gfx/splashutils should move cachedir /lib/splash/cache to /run
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
Besides, people should migrate to something with active upstream, like plymouth
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/07/14 11:52 AM, Samuli Suominen wrote: media-gfx/splashutils fails to build, and it fails everytime one of it's reverse dependency changes dependencies because it fails to use pkg-config to query Libs: it's supposed to have proxy-maint, but nobody is pushing fixes for the supposed proxy-maint it's in no shape to be in tree as-is, and since spock@g.o has retired and was also the upstream of it, well, there is no upstream for it no upstream, no downstream, fails to build, bugs with patches but nobody to push them - lastriting the package in 2 weeks, this is the first heads up mail 17 bugs found: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Note that this package is a DEPEND or RDEPEND for all of the splash-themes packages too, so they'll also need to be lastrite'd if we don't have an alternative utility. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlPNWOQACgkQ2ugaI38ACPDlLAD/VLhgdj/f+Ns7AGnUfsOZKOI2 wlkDTcLy6eV0s0s64VsA/iqIIcCAcj8lmOF1/zIv8aUQU/IRRgbuq+R3SDGW4p6z =Z6Dt -END PGP SIGNATURE-
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Fbsplash is a part of splashutils. There is also an fbcondecor kernel patch, apparently maintained by someone else now. Splashutils have an extremely complex structure of daemons, control programs, and interaction with the kernel via UVESAFB — I had to revisit this structure every time I had to change something wrt. splashutils integration. Not to claim that plymouth is the solution — last time I tried it (~ 2 years ago) it was practically unusable with OpenRC. It took control of the console in some weird and buggy way, etc. I guess you could integrate it into a specific system with specific video driver, but I gave up on plymouth as a generic solution. Maybe it works well with systemd, but from what I gathered the last time, it is (or used to be) explicitly disabled on unsupported video cards by the relevant distros. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.
2014-07-21 23:29 GMT+04:00 Maxim Kammerer m...@dee.su: On Mon, Jul 21, 2014 at 9:16 PM, Ian Stakenvicius a...@gentoo.org wrote: I'm not against dropping splashutils, but is there an alternative to creating or managing framebuffer-splash in the tree? fbsplash doesn't seem to be there (tho i don't know if that's the same upstream package or not) Fbsplash is a part of splashutils. There is also an fbcondecor kernel patch, apparently maintained by someone else now. Splashutils have an extremely complex structure of daemons, control programs, and interaction with the kernel via UVESAFB — I had to revisit this structure every time I had to change something wrt. splashutils integration. Not to claim that plymouth is the solution — last time I tried it (~ 2 years ago) it was practically unusable with OpenRC. It took control of the console in some weird and buggy way, etc. I guess you could integrate it into a specific system with specific video driver, but I gave up on plymouth as a generic solution. Maybe it works well with systemd, but from what I gathered the last time, it is (or used to be) explicitly disabled on unsupported video cards by the relevant distros. Well, at the moment plymouth works fine for me with OpenRC. I've installed plymouth-openrc-plugin and it's ok, despite being old and rather unmaintained. FYI, I use plymouth with dracut initramfs generator. And I also heard from maintainer (I'm proxy maintainer of plymouth) that it works with systemd too. -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
