Re: [gentoo-dev] virtual/sctp to choose the right SCTP lib for Linux/FreeBSD?
On 04/06/2014 17:05, Ulrich Mueller wrote:
On Sun, 06 Apr 2014, Joshua Kinard wrote:
Derp, since this is a virtual for a linkable library, set DEPEND
first, then RDEPEND to ${DEPEND}.
No, setting RDEPEND (as it was in your previous version) in the
virtual is enough.
The package depending on a virtual for a library must have it in
DEPEND, though.
Gotcha. Never had to create a virtual before. Doesn't seem there's any
other feedback, so I'll try to put this into the tree sometime this week and
just add the multilib stuff later on when I figure it out. Thanks for the
feedback!
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
[gentoo-dev] Re: Stabilization of netifrc-0.2.2, extra testers wanted
Samuli Suominen posted on Mon, 07 Apr 2014 23:08:38 +0300 as excerpted: Extra testers requested for netifrc-0.2.2 stabilization, also, if you know a reason this shouldn't go stable, like regression from 0.1, speak up now. See, http://bugs.gentoo.org/507070 (I'm purposely special casing this package over others like this.) FWIW, I have/had been running both netifrc- and openrc-, along with udev-init-scripts-26-r2. However I quite recently switched to systemd for booting, so while they're still installed, I'm only using trivial bits of openrc now, and perhaps (?) non of netifrc, tho I guess I'm still using udev-init-scripts. I've seen no problems related to those packages here, either before or after I switched to systemd, save for the file-collisions that are the reason both netif and udev-init-scripts must stabilize together (as in the bug but not mentioned in your post.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
It would take considerably amount of time to start extracting tarballs, installing ebuilds, and reporting bugs about possible broken .png files within packages. The problem is broken IDAT lenght, an error that libpng15 still gracefully ignored, but libpng16 no longer ignores. The bug, http://bugs.gentoo.org/468386 List created by Tobias at 2013 May, https://bugs.gentoo.org/attachment.cgi?id=347306 mailto:klaus...@gentoo.org This has been discussed on the ML before, and most important packages got already fixed, but there are packages still left. Any help addressing the issue is welcome, and I'm sending this mail in hopes people will see packages on the lists that intrest them, and fix them. Thanks, Samuli mailto:klaus...@gentoo.org
Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
On 08/04/14 16:14, Samuli Suominen wrote: mailto:klausman... mailto:klausman... No idea how that happened. I blame Thunderbird.
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
W dniu 2014-03-31 19:35, Toralf Förster pisze: On 03/31/2014 01:15 PM, Alex Xu wrote: On 31/03/14 03:36 AM, Dirkjan Ochtman wrote: So, I'm interested... How widely used is the HPN patch set? Are there any good indications that it doesn't negatively impact security? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=292932 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693424 https://lists.fedoraproject.org/pipermail/devel/2007-July/105570.html https://aur.archlinux.org/packages/openssh-hpn/ https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/162253 Those bug reports are good arguments to have HPN as a feature in openssh. And most of them now many years old and still open. That's an argument to rethink if HPN should be activated quietly. According to last problem with openssl and +tls-heartbeat I'd like to see less features enabled by default. USE=-* isn't the best solution;) Marcin
Re: [gentoo-dev] Why is IUSE=hpn mandatory in openssh ?
On Tue, Apr 8, 2014 at 2:34 PM, Marcin Mirosław mar...@mejor.pl wrote: According to last problem with openssl and +tls-heartbeat I'd like to see less features enabled by default. USE=-* isn't the best solution;) A bug in an upstream-supported feature is quite different from a patched-in feature that upstream doesn't support.
Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió: It would take considerably amount of time to start extracting tarballs, installing ebuilds, and reporting bugs about possible broken .png files within packages. The problem is broken IDAT lenght, an error that libpng15 still gracefully ignored, but libpng16 no longer ignores. The bug, http://bugs.gentoo.org/468386 List created by Tobias at 2013 May, https://bugs.gentoo.org/attachment.cgi?id=347306 mailto:klaus...@gentoo.org This has been discussed on the ML before, and most important packages got already fixed, but there are packages still left. Any help addressing the issue is welcome, and I'm sending this mail in hopes people will see packages on the lists that intrest them, and fix them. Thanks, Samuli mailto:klaus...@gentoo.org If there exists a tool that detects that broken png files, maybe a QA portage check (like the one used to detect broken .desktop files) could be added to help to detect and fix the problematic images :/
Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
On 08/04/14 22:26, Pacho Ramos wrote: El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió: It would take considerably amount of time to start extracting tarballs, installing ebuilds, and reporting bugs about possible broken .png files within packages. The problem is broken IDAT lenght, an error that libpng15 still gracefully ignored, but libpng16 no longer ignores. The bug, http://bugs.gentoo.org/468386 List created by Tobias at 2013 May, https://bugs.gentoo.org/attachment.cgi?id=347306 mailto:klaus...@gentoo.org This has been discussed on the ML before, and most important packages got already fixed, but there are packages still left. Any help addressing the issue is welcome, and I'm sending this mail in hopes people will see packages on the lists that intrest them, and fix them. Thanks, Samuli mailto:klaus...@gentoo.org If there exists a tool that detects that broken png files, maybe a QA portage check (like the one used to detect broken .desktop files) could be added to help to detect and fix the problematic images :/ Pretty good idea, there is the script in python, and Portage is python, maybe it can be adopted somehow. The script is at, https://bugs.gentoo.org/show_bug.cgi?id=466190#c11 - Samuli
Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
El mar, 08-04-2014 a las 22:25 +0300, Samuli Suominen escribió: On 08/04/14 22:26, Pacho Ramos wrote: El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió: It would take considerably amount of time to start extracting tarballs, installing ebuilds, and reporting bugs about possible broken .png files within packages. The problem is broken IDAT lenght, an error that libpng15 still gracefully ignored, but libpng16 no longer ignores. The bug, http://bugs.gentoo.org/468386 List created by Tobias at 2013 May, https://bugs.gentoo.org/attachment.cgi?id=347306 mailto:klaus...@gentoo.org This has been discussed on the ML before, and most important packages got already fixed, but there are packages still left. Any help addressing the issue is welcome, and I'm sending this mail in hopes people will see packages on the lists that intrest them, and fix them. Thanks, Samuli mailto:klaus...@gentoo.org If there exists a tool that detects that broken png files, maybe a QA portage check (like the one used to detect broken .desktop files) could be added to help to detect and fix the problematic images :/ Pretty good idea, there is the script in python, and Portage is python, maybe it can be adopted somehow. The script is at, https://bugs.gentoo.org/show_bug.cgi?id=466190#c11 - Samuli Probably we will need to open a bug report, do you prefer to report that one or should I? ;)
Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, Tracker bug #468386
On 08/04/14 23:26, Pacho Ramos wrote: El mar, 08-04-2014 a las 22:25 +0300, Samuli Suominen escribió: On 08/04/14 22:26, Pacho Ramos wrote: El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió: It would take considerably amount of time to start extracting tarballs, installing ebuilds, and reporting bugs about possible broken .png files within packages. The problem is broken IDAT lenght, an error that libpng15 still gracefully ignored, but libpng16 no longer ignores. The bug, http://bugs.gentoo.org/468386 List created by Tobias at 2013 May, https://bugs.gentoo.org/attachment.cgi?id=347306 mailto:klaus...@gentoo.org This has been discussed on the ML before, and most important packages got already fixed, but there are packages still left. Any help addressing the issue is welcome, and I'm sending this mail in hopes people will see packages on the lists that intrest them, and fix them. Thanks, Samuli mailto:klaus...@gentoo.org If there exists a tool that detects that broken png files, maybe a QA portage check (like the one used to detect broken .desktop files) could be added to help to detect and fix the problematic images :/ Pretty good idea, there is the script in python, and Portage is python, maybe it can be adopted somehow. The script is at, https://bugs.gentoo.org/show_bug.cgi?id=466190#c11 - Samuli Probably we will need to open a bug report, do you prefer to report that one or should I? ;) https://bugs.gentoo.org/show_bug.cgi?id=507172
