Re: [gentoo-user] Network scanner [SOLVED]
On Sun, 26 Feb 2017 17:54:32 -0700, the...@sys-concept.com wrote: > I just tried gscan2pdf. > It does not offer auto-feed either; black borders still persist (so it > must be an issue with Brother driver. Sounds like it. > In addition, I've noticed big difference is scan size of an image. > Small receipt size: ~4in x 3in saved as pdf B/W in 200dpi resolution: > > gscan2pdf produced file size: 66.7kB > xsane produce file size: 12.4kB File saving is a different process from scanning. For B/W scans, I use djvu with gscan2pdf, the files are *much* smaller. > So in file size perspective xsane produced much smaller size. > gscan2pdf provide crop tool to cut the borders, xsane does not have any > crop tools. Xsane doesn't need to provide image manipulation as it works as a GIMP plugin. -- Neil Bothwick WinErr 01D: System crash - We are unable to figure out our own code. pgpXz4KrYpBZM.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Need coaching with emerge failure logs (Understanting the problem)
On Mon, 27 Feb 2017 07:31:22 +, Thomas Mueller wrote: > > On Sat, 25 Feb 2017 21:58:05 +0100, Miroslav Rovis wrote: > > > > On 170225-09:19-0500, Harry Putnam wrote: > > > > Setup: VBox vm running gentoo(amd64) guest on a win-10 (64bit) > > > > host Hardware: HP xw8600 - 2x Xeon CPU X5450 @ 3.00GHz - 32 GB > > > > ram > > > > [ some cca. 80k text cut here ] > > > > Go for the guides, in which you will find that sending 5.5M log in > > > an email is plain wrong. > > > On this list, it is preferred to attach logs rather than post them > > elsewhere with a link. That way all the information stays together. > > > However, as Stroller mentioned, the escape codes make a bit of a mess. > > Logs this large could be gzipped before attaching. > A 5.5M log is too much for most people, myself included, to read. Reading it is a separate issue from how you provide it, but this particular log was unusually large. > Gzipping has two disadvantages: can not be read directly, one being > that the attachment must be extracted to a separate file for reading > outside the mail client. The same is true of providing a link to a file stored elsewhere. > Other downside is that a gzipped file must then be base64-encoded for > email. Base64 encoding multiplies the attachment size by 4/3 > (four-thirds), negating most of the reason for gzipping. In the case of logfiles, you can often achieve 90% compression, so it is one of the few cases where this does still save a lot of space. But the real solution here would be to strip the escape codes first as they add a lot of bloat and make the logs more difficult to read. It's all about making the information as accessible as possible, if you put barriers in the way of reading it, people won't bother, including some that know the answer. -- Neil Bothwick What did the first man to discover you can get milk from cows think he was doing? - anon. pgp6MHedBrc3d.pgp Description: OpenPGP digital signature
Re: [gentoo-user] SHA-1 has just been broken
On 170226-14:32-0600, R0b0t1 wrote: > On Sun, Feb 26, 2017 at 5:00 AM, Miroslav Rovis > wrote: > > On 170225-21:34-0600, R0b0t1 wrote: > >> On Saturday, February 25, 2017, Miroslav Rovis > >> > >> wrote: > >> > > >> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html > > ... > >> ... > >> Aside: > >> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html > > > > Too technical for me. Too little learning gain for too much mumbo-jumbo > > noise, at this > > stage of my understanding of crypto, for me. > > My apologies. The useful part of the link is really the title. It > explains how, if you *do* successfully break a given key, you have > necessarily broken millions of them - you are just unsure if they are > currently in use. The wise option is then to record every key > combination you brute force in the hope that someone will start using > it in the future. I did figure that much out. But all of it useful... for true cryptographers. It's so appealing, but so distant yet (or forever, where can one find the time to learn that much?). > > > > But, when we talk crypto being broken, I can help thinking of other I meant: But, when we talk crypto being broken, I can't help thinking of other ( ... can't ... ) > > threats to Gentoo and other FOSS GNU Linux that I fear are perfectly > > feasible (for the resourceful subjects) ( And also, the Message-ID given in my email can only be found by subcribers to the gentoo-dev mailing list, not gentoo-user ML. ) > > Gentoo distro is increasingly served the insecure way, IMO, that is: via > > git, without the repositories being, for end users, PGP-verifiable. > > > > And via a new private big business, the Github. Giving over all users to > > big Github brother. > > > > And, in the trasition all the history got lost. Git started remembering > > only from 2015. > > > > I have asked a question about getting git-served repository verifiable > > for end users, but I didn't get any replies: > > > > This is something I was concerned about myself, especially since the > bare git protocol that most users access the repository from, even if > it is the repository hosted by the Gentoo Foundation, is insecure. Git > access via SSH or HTTPS *is* secure but is not implemented - I'm not > sure why, as they've purchased a "real" certificate and the Git > subdomain may already be covered by it. > And there's even no need purchasing certs any more. LetsEncrypt cetrificates are free in both some GNU/GNU-compatible way, and the free-of-charge way. But a repository can also really be verifiable only if it is PGP-signed (or some other cryptro-verifiable-way signed). So HTTPS alone does not do it. > Well, maybe someone will noticed this message. Or not. > > R0b0t1. > I hope too. Because it's depressing how large swathes of FOSS are getting under control of big business and to some extent, very minor here, but not negligeable, actually covertly privatized... I can't help but remind ( I wrote about it in: GUI-less (non-dbus) virt-manager (to run Tails in Gentoo) https://lists.gt.net/gentoo/user/321797 Message-ID: <20170111205529.GB28353@g0n.xdwgrp> ) how big dirty stingy Schmoogle the Schmoog treats Gentoo which it uses for its CoreOS [[ important thing there to find is the link to: Gentoo Foundation, background and status report Robin Johnson https://youtu.be/S3bmXVbxMgE and if a reader don't get to the same conclusion about the Schmoog that I arrived at, then the reader might be missing something ]] Ah, as far as distribution verifiability, I guess emerge-webrsync and PGP-signed portage trees functionality needs to be kept forever, then... Thanks for replying! ( BTW, about the link, in the first email, to my message to secure-os ML, one of the secure-os folks kindly confirmed, but in a private message, that they were considering my email... ) Sad how this topic, or the other linked in my first mail, to the gentoo-dev ML, didn't attract more discussion... It can't be too late to fix these issues... Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)
On 170226-09:42-0500, Harry Putnam wrote: > Stroller writes: ... > > > Example at the beginning: [32;01m * > > Example from the end: * > > > > Output to the terminal these would show the text in different colours, > > but the output was redirected to a textfile or mishandled in a > > copy-paste operation (not sure if screen or tmux does this?). > > > > Running emerge with `--color n` would have made this log much more > > readable. Its size already makes it hard to search. > > Yes, and I am sorry about that, its just that I could not discern what > parts were important. Still I should have posted only the last > 400-500 lines. > > Just so you know... I did try that. [--color n] The resulting log > looked exactly the same. ... This is hard to believe. I just tried, and either: --color n or: --color=n added to the emerge line, worked. These: --color no # throws help on you --color=no # throws help on you didn't work. -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Is this a dependency bug?
On Mon, 20 Feb 2017 17:45:28 + (UTC) Grant Edwards wrote: > I installed weasyprint-0.29, but it won't run: > > $ weasyprint > Traceback (most recent call last): > File "/usr/lib/python-exec/python2.7/weasyprint", line 6, in > from pkg_resources import load_entry_point > [...] > File "/usr/lib64/python2.7/site-packages/pkg_resources/__init__.py", line > 849, in resolve > raise DistributionNotFound(req, requirers) > pkg_resources.DistributionNotFound: The 'CairoSVG<2,>=1.0.20' distribution > was not found and is required by WeasyPrint > > I have cairosvg installed, but apparently it's not recent enough (1.07 vs. > 1.20)? > > $ emerge --search cairosvg > > > * media-gfx/cairosvg > Latest version available: 1.0.7 > Latest version installed: 1.0.7 > Size of files: 29 KiB > Homepage: http://cairosvg.org/ > Description: A simple cairo based SVG converter with support for PDF, > PostScript and PNG formats > License: LGPL-3 > > Is this a dependency bug in the weasyprint ebuild? Yes, please report on bugzilla. Best regards, Andrew Savchenko pgpbd1PsZ_M4e.pgp Description: PGP signature
Re: [gentoo-user] Cross-compiling for an unstable architecture.
On Thu, 23 Feb 2017 16:21:04 -0600 R0b0t1 wrote: > Hello, > > So apparently I am single-handedly attempting to stabilize arm64 (at > least, it feels that way). Per the "Gentoo on Alternative > Architectures" subforum > (https://forums.gentoo.org/viewforum-f-32.html) two users have gotten > almost everything working, in some cases having to resort to building > packages not in @system on-device. Ideally I want to be able to build > every package I make use of from my desktop but in some cases this > will involve bug reports to the projects to see if they will change > their build process. > > However it's gotten to the point where not even building on-device > works. I'm experiencing breakage in a lot of core packages that may or > may not be related to portage. What is the best way to ask for help? > The users on the forums and IRC do not seem to really know how to go > about solving some of the problems or do not have the time, and I'm > not sure it's polite to open up a bunch of bug reports on > https://bugs.gentoo.org. What seems to complicate this is solving some > of the issues looks like it will take knowledge only the developers of > the corresponding software have. Get in touch with the arm Gentoo team. If you sure your fix is correct, open bugs on bugzilla. There is nothing wrong in opening tons of good bug reports with patches :) Best regards, Andrew Savchenko pgpfTa_N6QIrm.pgp Description: PGP signature
Re: [gentoo-user] SSH rekeying straight after authentication
On Thu, 23 Feb 2017 20:10:05 + Mick wrote: > I am trying to understand why an ssh server keeps dropping the connection > when > using openssh on Linux straight after a successful authentication, but it > works fine with Filezilla in MSWindows. [...] > I am guessing all this respawning probably triggers some DDoS protection > limit > on the server and it disconnects the client. Have you observed anything > similar and would you know why Linux fails, but MSWindows works as it should? I use HPN for years and connect to hundreds of servers, most of them are without HPN support. I have no problems so far. But HPN is unofficial and it may trigger problems. Maybe this is a bug in HPN, maybe a server's custom protection. Try to report this on bugzilla for openssh maintainers. Best regards, Andrew Savchenko pgpEM5hBjqNZP.pgp Description: PGP signature
Re: [gentoo-user] SHA-1 has just been broken
On Sat, 25 Feb 2017 22:12:10 +0100 Miroslav Rovis wrote: > https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html > > ( you know I hate the Schmoog, and didn't take their cookies, and so > they didn't show me their page in my Palemoon --working great here!, an > Angel of Honesty in comparison to Firefox --and if anybody else don't > want Schmoog prying in his machine, likely: Mass generation of collisions is much easier if document structure is taken into account, e.g. for PDF it is sufficient to compute collision block once and it is possible to generate different PDFs with the same SHA1 hash. On-line service is available together with detailed description: https://alf.nu/SHA1 So danger of SHA1 collision is much closer than 9,223,372,036,854,775,808 SHA1 computations or 1 110-GPU year. Best regards, Andrew Savchenko pgpdZdRXx8Qdq.pgp Description: PGP signature
[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)
Dale writes:
> Harry Putnam wrote:
>>
>> Just so you know... I did try that. [--color n] The resulting log
>> looked exactly the same. I posted that fact in an earlier request for
>> help a week or so ago in which I remarked how using the no-color
>> emerge option didn't seem to make a bit of difference. I don't expect
>> anyone would have noticed the comment... but it does seem a bit off
>> that I see no differernce here. That is, no difference in the actual
>> log emerge creates. I do see the difference in the terminal output.
>>
>>
>>
>
> I think it may be your PS1 variable that is broken. That is here for me
> at least:
>
> /etc/bash/bashrc
>
> I think it can be in other places as well. If you recall changing the
> setting, it should look something like this:
>
> PS1+='\[\033[01;31m\]\u@\h \[\033[01;34m\]\w \$ \[\033[00m\]'
>
> It may be that you are missing the ' on the end or some other character
> is missing. If you copy mine, it will look like this:
>
> root@fireball / #
>
> Either way, you likely just have something missing or out of place and
> it is throwing it off. Maybe this will help you fix it, maybe.
>
> Dale
>
I'm a bit lost here. What makes you think something is broken?
I mean other than than a failed compile of some pkgs?
I guess you mean the fact that there are escapes in the log I
posted... as I've said that was the log as emerge created it. The
`build.log' from /var/tmp [...]
my PS1 looks similar with a few diffeneces from yours but the quoting
is intact: See below from the machine where the log was created:
,
| [Intended to pass muster for either USER or ROOT]
|
| if [ ${UID} -gt 0 ];then
|sign='>'
| else
|sign='#'
| fi
| PS1='\[\033[01;31m\]HOST:\h \[\033[01;32m\]\w\n\u ${sign}
\[\033[00m\]';export PS1
|
| PS4='$LINENO: ';export PS4
`
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 9:46 AM, Andrew Savchenko wrote: > > So danger of SHA1 collision is much closer than > 9,223,372,036,854,775,808 SHA1 computations or 1 110-GPU year. Indeed in every way it is closer than that than when Google started their project, and tomorrow it will be closer still. The subject line shouldn't really be "SHA-1 has just been broken" but "Another recent confirmation of SHA-1 being broken." We've known it has been broken for quite a while. In the same way, DES wasn't broken when the EFF built their ASIC-based machine. That was just the final nail in the coffin. Anybody who waited for somebody to actually build that machine (and I'd be shocked if bigger players than the EFF didn't have such a machine much sooner) was deluded. When somebody discovers an attack on a hash function that greatly reduces the cost to generate collisions into a number that is even remotely forseeable in the next decade, it is time to stop using that hash function. Sheer inertia ensures that even if everybody started changing overnight it probably would still cause problems when the attacks start getting practical. Sure, there are threat models where it doesn't matter, but on the SHA-1 front it seems like people have been underestimating their exposure. Certainly Gentoo has exposure until git is fixed and the active tree has non-SHA-1 hashes. Even then the historical tree is vulnerable if we don't rehash everything, though in practice I don't think that matters as much, and obviously slipping a non-preimage collision into the historical tree is impossible unless it is done before the hash functions are changed. Sure, you can wave your hands about how hard it is to expoit in practice, and I agree with many of these arguments. However, SHA-1 should be viewed as a vulnerability and fixing it as a priority. For Gentoo specifically it isn't really the weakest link in the chain as was pointed out in the other thread, so I'm not sure I'd go rushing out to fork git. Still, we shouldn't be entirely comfortable with git as it stands at the moment. -- Rich
[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)
Stroller writes: >> On 25 Feb 2017, at 14:19, Harry Putnam wrote: >> >> I've attached a hefty log of some 4000 lines and hope someone will be >> patient enough to try to identify what is causing the problem. > > I took a look at this, but the broken colour codes throughout the log make it > quite hard to read. > > Example at the beginning: [32;01m * > Example from the end: * > > Output to the terminal these would show the text in different colours, > but the output was redirected to a textfile or mishandled in a > copy-paste operation (not sure if screen or tmux does this?). > > Running emerge with `--color n` would have made this log much more readable. > Its size already makes it hard to search. I guess I'll try this once more... Its still a big log but I cleaned up the escapes ... it is a fresh try at building xf86-video-virtualbox-5.1.14 Still failing in the same way and still not seeing clues in the log... probably my own fault. xf86-video-virtualbox-5.1.14_emerge-170227_094550.log.gz Description: Failed emerge of xf86-video-virtualbox-5.1.14
Re: [gentoo-user] SHA-1 has just been broken
On Sun, 26 Feb 2017 12:00:50 +0100 Miroslav Rovis wrote: > But, when we talk crypto being broken, Git is not in the immediate threat due to SHA1 collision being practical. See Linux blog about this: https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL Note that git devs are working on moving to a more secure hash function. Also note that git can handle several files in the repo with the same hash function. While this doesn't protect from the possible repo forgery, it protects from accidental file collision where subversion fails badly: https://www.bleepingcomputer.com/news/security/sha1-collision-attack-makes-its-first-victim-subversion-repositories/ I do not want to offence subversion devs, but they haven't even considered the possibility that hash function may collide. Huge blunder on their side. > I can help thinking of other > threats to Gentoo and other FOSS GNU Linux that I fear are perfectly > feasible (for the resourceful subjects) > > Gentoo distro is increasingly served the insecure way, IMO, that is: via > git, without the repositories being, for end users, PGP-verifiable. It is verifiable for end users, but not in an easy way. You can either use web rsync or verify git commits yourself using gpupg and gkeys. > And via a new private big business, the Github. Giving over all users to > big Github brother. ??? Github is entirely optional and is only for those who want to use it (we have both users and devs willing so), but in no way anyone demands its usage. If you want to have sync-friendly git repo, Gentoo infra provides one for you: https://gitweb.gentoo.org/repo/sync/gentoo.git/ > And, in the trasition all the history got lost. Git started remembering > only from 2015. No, it isn't. Full historical git repo is available: https://gitweb.gentoo.org/repo/gentoo/historical.git/ One may use git graft to join historical and actual repo together. > I have asked a question about getting git-served repository verifiable > for end users, but I didn't get any replies: Do not forget that all devs are volunteers. User-transparent GnuPG tree verification is indeed important. You can help! Join gkeys project, get in touch with infra, discuss what needs to be done. Don't just rattle about how insecure data is provided, help to make it secure! (And as I shown above actual state is not that bad and some options are already available.) Best regards, Andrew Savchenko pgp2DzXAJ_N32.pgp Description: PGP signature
Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)
On Monday 27 Feb 2017 10:09:34 Harry Putnam wrote:
> I guess I'll try this once more... Its still a big log but I cleaned
> up the escapes ... it is a fresh try at building
> xf86-video-virtualbox-5.1.14
>
> Still failing in the same way and still not seeing clues in the
> log... probably my own fault.
I see this, starting at line 3324 in your newly attached log:
In file included from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/types.h:140:0,
from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/mem.h:31,
from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34:
/lib/modules/4.9.10-gentoo/build/arch/x86/include/asm/atomic.h: In function
‘int atomic_read(const atomic_t*)’:
/lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error:
uninitialized const member in ‘union atomic_read(const
atomic_t*)::’
union { typeof(x) __val; char __c[1]; } __u; \
That's similar to what Stroller found the first time, just not quite the
same. It looks like a code error in VirtualBox, but it can't be because I've
compiled that version here with no trouble. That means something is awry in
your setup.
Have you tried setting -j1? I ask because it looks as though components are
being compiled in a different order from the last time.
If I have a useful suggestion after some time for thought, I'll offer it
then.
--
Regards
Peter
Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)
On Monday 27 Feb 2017 10:09:34 Harry Putnam wrote:
> I guess I'll try this once more... Its still a big log but I cleaned
> up the escapes ... it is a fresh try at building
> xf86-video-virtualbox-5.1.14
>
> Still failing in the same way and still not seeing clues in the
> log... probably my own fault.
I see this, starting at line 3324 in your newly attached log:
In file included from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/types.h:140:0,
from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/include/iprt/mem.h:31,
from /var/tmp/portage/x11-drivers/xf86-video-
virtualbox-5.1.14/work/VirtualBox-5.1.14/src/VBox/Runtime/common/alloc/alloc.cpp:34:
/lib/modules/4.9.10-gentoo/build/arch/x86/include/asm/atomic.h: In function
‘int atomic_read(const atomic_t*)’:
/lib/modules/4.9.10-gentoo/build/include/linux/compiler.h:305:42: error:
uninitialized const member in ‘union atomic_read(const
atomic_t*)::’
union { typeof(x) __val; char __c[1]; } __u; \
That's similar to what Stroller found the first time, just not quite the
same. It looks like a code error in VirtualBox, but it can't be because I've
compiled that version here with no trouble. That means something is awry in
your setup.
Have you tried setting -j1? I ask because it looks as though components are
being compiled in a different order from the last time.
If I have a useful suggestion after some time for thought, I'll offer it
then.
--
Regards
Peter
Re: [gentoo-user] SHA-1 has just been broken
On 26/02/2017 22:32, R0b0t1 wrote: > On Sun, Feb 26, 2017 at 5:00 AM, Miroslav Rovis > wrote: >> On 170225-21:34-0600, R0b0t1 wrote: >>> On Saturday, February 25, 2017, Miroslav Rovis >>> >>> wrote: >>> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html >> ... >>> >>> Very interesting. The first useful SHA-1 collision was, if I remember, done >>> in 2015, and subverted an HTTPS certificate (though not one which had been >>> issued). This was some guys with a couple of servers lined with graphics >>> cards. >>> >>> Seeing someone manage to do it in a garage a number of years before it was >>> cosidered feasible should, hopefully, make you have more conservative >>> estimates of the strength of modern cryptography. >>> >>> Aside: >>> http://ecrypt-eu.blogspot.com/2015/11/break-dozen-secret-keys-get-million.html >> >> Too technical for me. Too little learning gain for too much mumbo-jumbo >> noise, at this >> stage of my understanding of crypto, for me. >> > > My apologies. The useful part of the link is really the title. It > explains how, if you *do* successfully break a given key, you have > necessarily broken millions of them - you are just unsure if they are > currently in use. The wise option is then to record every key > combination you brute force in the hope that someone will start using > it in the future. > >>> R0b0t1. >> >> But, when we talk crypto being broken, I can help thinking of other >> threats to Gentoo and other FOSS GNU Linux that I fear are perfectly >> feasible (for the resourceful subjects) >> >> Gentoo distro is increasingly served the insecure way, IMO, that is: via >> git, without the repositories being, for end users, PGP-verifiable. >> >> And via a new private big business, the Github. Giving over all users to >> big Github brother. >> >> And, in the trasition all the history got lost. Git started remembering >> only from 2015. >> >> I have asked a question about getting git-served repository verifiable >> for end users, but I didn't get any replies: >> > > This is something I was concerned about myself, especially since the > bare git protocol that most users access the repository from, even if > it is the repository hosted by the Gentoo Foundation, is insecure. Git > access via SSH or HTTPS *is* secure but is not implemented - I'm not > sure why, as they've purchased a "real" certificate and the Git > subdomain may already be covered by it. I always though git's use of SHA hashes was to identify commits and detect random bit flips, not to provide any measure of security. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 1:02 PM, Alan McKinnon wrote: > > I always though git's use of SHA hashes was to identify commits and > detect random bit flips, not to provide any measure of security. > As somebody said in Twitter recently (and Linus to some degree in his post), it is, except when it isn't. git supports gpg signatures on tags and commits. The only thing that binds these signatures to the information being signed are sha1 hashes and file sizes, and Google has already demonstrated the ability to manipulate hashes without changing file size. Those hashes apply to blobs and trees, and doing a collision on either lets you modify the contents of the tree. Now, if every commit is being carefully reviewed (via git diff/etc) then the chances of leaking the data needed to make collisions less expensive into the repo is low, as long as you're talking exclusively about text files (which is all we store in the tree). If you go storing pdfs or images/etc in a repo I'm less confident that you could detect attempts to sneak easy-to-collide data into a repo. So, this isn't a reason to panic, but it is a reason for concern. People have been talking about sha-1 collisions for a while. Commit signatures are not the only way to secure the Gentoo repository, but they seem like one of the most convenient to use, assuming we could trust them. I've always seen sha1 brought up as one of the biggest reasons not to. -- Rich
Re: [gentoo-user] Network scanner [SOLVED]
On 02/27/2017 01:45 AM, Neil Bothwick wrote: > On Sun, 26 Feb 2017 17:54:32 -0700, the...@sys-concept.com wrote: > >> I just tried gscan2pdf. >> It does not offer auto-feed either; black borders still persist (so it >> must be an issue with Brother driver. > > Sounds like it. > >> In addition, I've noticed big difference is scan size of an image. >> Small receipt size: ~4in x 3in saved as pdf B/W in 200dpi resolution: >> >> gscan2pdf produced file size: 66.7kB >> xsane produce file size: 12.4kB > > File saving is a different process from scanning. For B/W scans, I use > djvu with gscan2pdf, the files are *much* smaller. Just for curiosity can you scan small piece of paper 4in x 3in in B/W 200dpi in PDF; see what size you get. -- Thelma
[gentoo-user] dev-lang/php-5.6
When will they drop the dev-lang/php-5.6.30 from the portage? php-7.0 is not working with my application (modification are too intensive) besides I'm not a programmer. -- Thelma
Re: [gentoo-user] dev-lang/php-5.6
On 27/02/2017 22:14, the...@sys-concept.com wrote: > When will they drop the dev-lang/php-5.6.30 from the portage? If you copy the ebuild into your local overlay, then never > > php-7.0 is not working with my application (modification are too > intensive) besides I'm not a programmer. > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] webkit-gtk-2.14.2 cant find sqlite3 symbols
corbin,
i've finally discovered the problem with this.
it turns out that there were a set of stale .so files in /usr/iocal/bin/
installed in the year 2015. i discovered this by running:
ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.14.5.ebuild configure
the resulting ninja files showed that's where it was sourcing
libsqlite3.so. moving it out of the way solved the issue. its a complete
mystery why it would look for libs in a bin directory or why portage
would prefer /usr/local over the standard paths.
anyway, thanks for your thoughts and sorry for the long turnaround.
kelly
On 02/07/2017 06:23 PM, Corbin Bird wrote:
On 02/07/2017 09:55 AM, kelly hirai wrote:
On 02/06/2017 06:31 PM, Corbin Bird wrote:
On 02/06/2017 01:09 PM, kelly hirai wrote:
hello fellow gentoo-users,
for about a month now, i have not been able to make
webkit-gtk-2.14.[2,3] compile. it terminates at the linking step
complaining it cant find some sqlite functions.
./configure phase reports sqlite3 availability
-- Checking for module 'sqlite3'
-- Found sqlite3, version 3.13.0
-- Found Sqlite: /usr/include
but when it comes time to do the linking it cant find it:
FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -march=native -O2
-pipe -fno-strict-aliasing -std=c++1y -Wl,--no-undefined -Wl,-O1
-Wl,--as-needed -Wl,--no-keep-memory -fuse-ld=gold
-Wl,--disable-new-dtags -fuse-ld=gold -Wl,--disable-new-dtags
-Wl,--version-script,/var/tmp/portage/net-libs/webkit-gtk-2.14.2/work/webkitgtk-2.14.2/Source/cmake/gtksymbols.filter
-shared -Wl,-soname,libwebkit2gtk-4.0.so.37 -o
lib/libwebkit2gtk-4.0.so.37.14.9 @CMakeFiles/WebKit2.rsp && :
lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
void
std::__once_call_impl >(): error: undefined reference to 'sqlite3_initialize'
lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
void
std::__once_call_impl >(): error: undefined reference to 'sqlite3_errstr'
lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
WebCore::SQLiteDatabase::setCollationFunction(WTF::String const&,
std::function): error:
undefined reference to 'sqlite3_create_collation_v2'
lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
WebCore::SQLiteDatabase::removeCollationFunction(WTF::String const&):
error: undefined reference to 'sqlite3_create_collation_v2'
collect2: error: ld returned 1 exit status
the symbols seem to be in the library:
strings /usr/lib32/libsqlite3.so | grep create_collation_
sqlite3_create_collation_v2
strings /usr/lib64/libsqlite3.so | grep create_collation_
sqlite3_create_collation_v2
i'm stumped here. i don't see any explicit linking flags. the
@CMakefiles/WebKit2.rsp doesn't make sense to me, maybe its in there?
k.
Please post the USE flags set for all the following : "dev-db/sqlite:3"
and "net-libs/webkit-gtk:2", "net-libs/webkit-gtk:3",
"net-libs/webkit-gtk:4". ( Yes, webkit-gtk has three slots. 3 slots = 3
possible different sets of use flags. )
Corbin
thanks for looking at this Corbin. :)
[I] net-libs/webkit-gtk
Available versions:
(3)2.4.11-r1(3/25)
(2)2.4.11-r200
(4)2.12.5(4/37)^t ~2.14.2(4/37)^t ~2.14.3(4/37)^t
{(+)X aqua coverage debug doc +egl +geoloc +geolocation gles2
gnome-keyring +gstreamer +introspection +jit libnotify nsplugin
+opengl spell test wayland +webgl
Installed versions:
2.4.11-r1(3)(01:04:58 PM 01/13/2017)(X egl geolocation
gnome-keyring gstreamer introspection jit opengl spell webgl -aqua
-coverage -debug -gles2 -test -wayland)
2.12.5(4)^t(01:07:41 AM 12/13/2016)(X egl geolocation
gnome-keyring gstreamer introspection jit libnotify opengl spell webgl
-aqua -coverage -doc -gles2 -nsplugin -test -wayland)
[I] dev-db/sqlite
Available versions: (3) 3.12.0 ~3.12.1 ~3.12.2 3.13.0 ~3.14.1
~3.14.2 ~3.15.1 ~3.15.2 ~3.16.2
{debug doc icu +readline secure-delete static-libs tcl test
tools ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64"
ABI_X86="32 64 x32"}
Installed versions: 3.13.0(3)(11:35:43 AM 02/06/2017)(readline
-debug -doc -icu -secure-delete -static-libs -tcl -test -tools
ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64"
ABI_X86="32 64 -x32")
-
I just compiled / installed webkit-gtk-2.14.3 with no problems.
It replaced this version of webkit :
[ebuild R] net-libs/webkit-gtk-2.12.5:4/37::gentoo USE="(X)
coverage egl geolocation gnome-keyring gstreamer introspection libnotify
nsplugin opengl spell wayland webgl (-aqua) -doc -gles2 -jit {-test}" 0 KiB
These are the USE flags and package versions on my system :
[ebuild R ~] dev-db/sqlite-3.16.2:3::gentoo USE="icu readline
secure-delete static-libs tcl tools -deb
[gentoo-user] prevent 'openoffice-bin' rebuild
I have in: /etc/revdep-rebuild/99revdep-rebuild ... SEARCH_DIRS_MASK="/usr/lib64/openoffice" But my openoffice-bin constantly rebuilds. Is there a way to prevent it besides switching to non bin ver.? !!! existing preserved libs: >>> package: dev-libs/libbsd-0.8.3 * - /usr/lib32/libbsd.so.0 * - /usr/lib32/libbsd.so.0.8.2 * used by /usr/lib32/libXdmcp.so.6.0.0 (x11-libs/libXdmcp-1.1.2-r1) >>> package: gnome-base/orbit-2.14.19-r4 * - /usr/lib64/libORBit-2.so.0 * - /usr/lib64/libORBit-2.so.0.1.0 * used by /usr/lib64/openoffice/program/gconfbe1.uno.so (app-office/openoffice-bin-4.1.2) >>> package: sys-libs/ncurses-5.9-r5 * - /usr/lib64/libpanelw.so.5 * - /usr/lib64/libpanelw.so.5.9 * used by /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/_curses_panel.so (app-office/openoffice-bin-4.1.2) * - /lib64/libncursesw.so.5 * - /lib64/libncursesw.so.5.9 * used by /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/_curses.so (app-office/openoffice-bin-4.1.2) * used by /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/_curses_panel.so (app-office/openoffice-bin-4.1.2) * used by /usr/lib64/openoffice/program/python-core-2.7.6/lib/lib-dynload/readline.so (app-office/openoffice-bin-4.1.2) -- Thelma
Re: [gentoo-user] SHA-1 has just been broken
Apologies for my not being able to reply sooner! On 170227-18:18+0300, Andrew Savchenko wrote: > On Sun, 26 Feb 2017 12:00:50 +0100 Miroslav Rovis wrote: > > > But, when we talk crypto being broken, > > Git is not in the immediate threat due to SHA1 collision being > practical. See Linux blog about this: > > https://plus.google.com/+LinusTorvalds/posts/7tp2gYWQugL Will read it. (it's 02:00 past midnight CET) > Note that git devs are working on moving to a more secure hash > function. Good to hear! > Also note that git can handle several files in the repo with the > same hash function. While this doesn't protect from the possible > repo forgery, it protects from accidental file collision where > subversion fails badly: > https://www.bleepingcomputer.com/news/security/sha1-collision-attack-makes-its-first-victim-subversion-repositories/ Pretty sad! > I do not want to offence subversion devs, but they haven't even > considered the possibility that hash function may collide. Huge > blunder on their side. > > > I can help thinking of other > > threats to Gentoo and other FOSS GNU Linux that I fear are perfectly > > feasible (for the resourceful subjects) > > > > Gentoo distro is increasingly served the insecure way, IMO, that is: via > > git, without the repositories being, for end users, PGP-verifiable. > > It is verifiable for end users, but not in an easy way. You can > either use web rsync or verify git commits yourself using gpupg and > gkeys. I'll try and do that. I have been trying to figure it out, a few times already, but I would always get lost in the volume of new stuff to digest... Will need more time to do it. However I am already using signed portage snapshots via emerge-webrsync, and I use local mirror. I am pretty safe, but on obsolete technology. > > And via a new private big business, the Github. Giving over all users to > > big Github brother. > > ??? > Github is entirely optional and is only for those who want to use it > (we have both users and devs willing so), but in no way anyone > demands its usage. Yeah! Still, it would be great if git was used in distributed way, and not from a central private business... > If you want to have sync-friendly git repo, Gentoo infra provides > one for you: > https://gitweb.gentoo.org/repo/sync/gentoo.git/ Harder to use than Github. Github is foolproof, extremely easy for newbies, compared to any other git server. The reason for their success... > > And, in the trasition all the history got lost. Git started remembering > > only from 2015. > > No, it isn't. Full historical git repo is available: > https://gitweb.gentoo.org/repo/gentoo/historical.git/ Great to know! Sorry for wrong claims that I made. > One may use git graft to join historical and actual repo together. Which is advanced usage for me at this stage. > > I have asked a question about getting git-served repository verifiable > > for end users, but I didn't get any replies: > > Do not forget that all devs are volunteers. I know that. Always keep that in mind. > User-transparent > GnuPG tree verification is indeed important. You can help! If I get that savvy in git/portage/other I will... That time is still distant yet, I'm afraid. > Join gkeys project, get in touch with infra, discuss what needs to be > done. I'll look gkeys up... > Don't just rattle about how insecure data is provided, You're right. > help to make it secure! (And as I shown above actual state is not that > bad and some options are already available.) I'm busy figuring how to deploy virtualization on my sans-dbus system, and have spent months on things like that... and only lately finally getting there. Also, practical verifiability in Gentoo is something I have been keen on for pretty long now. But you having showed to me (I haven't digested it yet, too late in the night right now) that verifiability is possibly does make it the next big wish of mine to apply for my Gentoo ( and my dream is to help test it, so everybody can use git for verifiable installations! ). > > Best regards, > Andrew Savchenko Your email means a lot to me! Thank you! Good night! (I see other emails, but have to go to sleep now first) -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] prevent 'openoffice-bin' rebuild
On 02/27/2017 06:06 PM, the...@sys-concept.com wrote: > I have in: > /etc/revdep-rebuild/99revdep-rebuild > ... > SEARCH_DIRS_MASK="/usr/lib64/openoffice" > [snip] The above should be: SEARCH_DIRS_MASK="/usr/lib/openoffice" -- Thelma
Re: [gentoo-user] dev-lang/php-5.6
On 02/27/2017 03:14 PM, the...@sys-concept.com wrote: > When will they drop the dev-lang/php-5.6.30 from the portage? > > php-7.0 is not working with my application (modification are too > intensive) besides I'm not a programmer. > The php-5.6 series will receive security updates until the end of 2018: http://php.net/supported-versions.php We plan on supporting it in Gentoo for at least that long. It will most likely be removed once it has an *unfixed* vulnerability.
Re: [gentoo-user] SHA-1 has just been broken
On Mon, Feb 27, 2017 at 8:10 PM, Miroslav Rovis wrote: > Apologies for my not being able to reply sooner! > > On 170227-18:18+0300, Andrew Savchenko wrote: > >> > And via a new private big business, the Github. Giving over all users to >> > big Github brother. >> >> ??? >> Github is entirely optional and is only for those who want to use it >> (we have both users and devs willing so), but in no way anyone >> demands its usage. > Yeah! Still, it would be great if git was used in distributed way, and > not from a central private business... > Git can pretty-much ONLY be used in a distributed way. In the sync workflow github is basically just a mirror. A lot of our mirrors are run by private businesses, and nobody knows what OS they're even hosted on, let alone whether the firmware and CPU microcode are FOSS along with their hard drive firmware. As far as distribution goes I think github is the wrong thing to worry about. What you want is traceable signatures from dev to user. Once you have that you can download from an NSA mirror and there shouldn't be any risk. All a mirror does is replicate data, and if modifications are detectable the worst they can do is a DoS. Most of the concerns that people tend to have with github is that you can become dependent on them for issue and pull request tracking and then if they decide to pull the plug you lose all that data. We try to minimize the use of these features and not make it a core part of the dev workflow. But, we do use pull requests and in theory we could lose those someday. The actual code itself gets pushed to the Gentoo infra Repo from a developer's box using plain old git after they've inspected/tested/etc it. So, there isn't really any way for Github to go injecting commits into the repositories we actually use. I guess they could do it for anybody using our github mirrors on the distribution side, but that's only because we don't have that all locked down and the same issue applies with any other mirror (rsync, etc). Again, you really need end-to-end signature checking to make any of these things truly safe. -- Rich
Re: [gentoo-user] webkit-gtk-2.14.2 cant find sqlite3 symbols
On 02/27/2017 03:44 PM, kelly hirai wrote:
> corbin,
>
> i've finally discovered the problem with this.
>
> it turns out that there were a set of stale .so files in
> /usr/iocal/bin/ installed in the year 2015. i discovered this by running:
>
> ebuild /usr/portage/net-libs/webkit-gtk/webkit-gtk-2.14.5.ebuild
> configure
>
> the resulting ninja files showed that's where it was sourcing
> libsqlite3.so. moving it out of the way solved the issue. its a
> complete mystery why it would look for libs in a bin directory or why
> portage would prefer /usr/local over the standard paths.
>
> anyway, thanks for your thoughts and sorry for the long turnaround.
>
> kelly
>
>
>
> On 02/07/2017 06:23 PM, Corbin Bird wrote:
>> On 02/07/2017 09:55 AM, kelly hirai wrote:
>>>
>>> On 02/06/2017 06:31 PM, Corbin Bird wrote:
On 02/06/2017 01:09 PM, kelly hirai wrote:
> hello fellow gentoo-users,
>
> for about a month now, i have not been able to make
> webkit-gtk-2.14.[2,3] compile. it terminates at the linking step
> complaining it cant find some sqlite functions.
>
> ./configure phase reports sqlite3 availability
>
> -- Checking for module 'sqlite3'
> -- Found sqlite3, version 3.13.0
> -- Found Sqlite: /usr/include
>
> but when it comes time to do the linking it cant find it:
>
> FAILED: : && /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -march=native
> -O2
> -pipe -fno-strict-aliasing -std=c++1y -Wl,--no-undefined -Wl,-O1
> -Wl,--as-needed -Wl,--no-keep-memory -fuse-ld=gold
> -Wl,--disable-new-dtags -fuse-ld=gold -Wl,--disable-new-dtags
> -Wl,--version-script,/var/tmp/portage/net-libs/webkit-gtk-2.14.2/work/webkitgtk-2.14.2/Source/cmake/gtksymbols.filter
>
>
> -shared -Wl,-soname,libwebkit2gtk-4.0.so.37 -o
> lib/libwebkit2gtk-4.0.so.37.14.9 @CMakeFiles/WebKit2.rsp && :
> lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
>
>
> void
> std::__once_call_impl
>
> ()> >(): error: undefined reference to 'sqlite3_initialize'
> lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
>
>
> void
> std::__once_call_impl
>
> ()> >(): error: undefined reference to 'sqlite3_errstr'
> lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
>
>
> WebCore::SQLiteDatabase::setCollationFunction(WTF::String const&,
> std::function): error:
> undefined reference to 'sqlite3_create_collation_v2'
> lib/libWebCoreGTK.a(lib/../Source/WebCore/CMakeFiles/WebCore.dir/platform/sql/SQLiteDatabase.cpp.o):SQLiteDatabase.cpp:function
>
>
> WebCore::SQLiteDatabase::removeCollationFunction(WTF::String const&):
> error: undefined reference to 'sqlite3_create_collation_v2'
> collect2: error: ld returned 1 exit status
>
> the symbols seem to be in the library:
>
> strings /usr/lib32/libsqlite3.so | grep create_collation_
> sqlite3_create_collation_v2
>
> strings /usr/lib64/libsqlite3.so | grep create_collation_
> sqlite3_create_collation_v2
>
> i'm stumped here. i don't see any explicit linking flags. the
> @CMakefiles/WebKit2.rsp doesn't make sense to me, maybe its in there?
>
> k.
Please post the USE flags set for all the following :
"dev-db/sqlite:3"
and "net-libs/webkit-gtk:2", "net-libs/webkit-gtk:3",
"net-libs/webkit-gtk:4". ( Yes, webkit-gtk has three slots. 3 slots
= 3
possible different sets of use flags. )
Corbin
>>> thanks for looking at this Corbin. :)
>>>
>>> [I] net-libs/webkit-gtk
>>> Available versions:
>>> (3)2.4.11-r1(3/25)
>>> (2)2.4.11-r200
>>> (4)2.12.5(4/37)^t ~2.14.2(4/37)^t ~2.14.3(4/37)^t
>>> {(+)X aqua coverage debug doc +egl +geoloc +geolocation gles2
>>> gnome-keyring +gstreamer +introspection +jit libnotify nsplugin
>>> +opengl spell test wayland +webgl
>>> Installed versions:
>>> 2.4.11-r1(3)(01:04:58 PM 01/13/2017)(X egl geolocation
>>> gnome-keyring gstreamer introspection jit opengl spell webgl -aqua
>>> -coverage -debug -gles2 -test -wayland)
>>> 2.12.5(4)^t(01:07:41 AM 12/13/2016)(X egl geolocation
>>> gnome-keyring gstreamer introspection jit libnotify opengl spell webgl
>>> -aqua -coverage -doc -gles2 -nsplugin -test -wayland)
>>>
>>> [I] dev-db/sqlite
>>> Available versions: (3) 3.12.0 ~3.12.1 ~3.12.2 3.13.0 ~3.14.1
>>> ~3.14.2 ~3.15.1 ~3.15.2 ~3.16.2
>>> {debug doc icu +readline secure-delete static-libs tcl test
>>> tools ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64"
>>> ABI_X86="32 64 x32"}
>>> Installed versions: 3.13.0(3)(11:35:43 AM 02/06/2017)(readline
>>> -debug -doc -icu -secure-delete -static-libs -t
Re: [gentoo-user] dev-lang/php-5.6
On 02/27/2017 02:11 PM, Alan McKinnon wrote: > On 27/02/2017 22:14, the...@sys-concept.com wrote: >> When will they drop the dev-lang/php-5.6.30 from the portage? > > If you copy the ebuild into your local overlay, then never > I'll do it just in case but eventually I'll be force to upgrade. I've upgraded 4-old boxes, three more to go + apache-2.4 -- Thelma
Re: [gentoo-user] Cross-compiling for an unstable architecture.
> On 23 Feb 2017, at 22:21, R0b0t1 wrote: > > However it's gotten to the point where not even building on-device > works. I'm experiencing breakage in a lot of core packages that may or > may not be related to portage. What is the best way to ask for help? > The users on the forums and IRC do not seem to really know how to go > about solving some of the problems or do not have the time, and I'm > not sure it's polite to open up a bunch of bug reports on > https://bugs.gentoo.org. What seems to complicate this is solving some > of the issues looks like it will take knowledge only the developers of > the corresponding software have. I've taken bugs upstream in the past, including with gcc and glibc. I've also filed bugs with bugs.gentoo.org, but response times can be variable in my experience. If you file a bug about something minor for a package that a dev happens to be interested in it'll probably get picked up quickly, but the Gentoo devs don't have the manpower to fix everything quickly. One of my bugs was for how gcc handled --march-native on the AMD K6-2 CPU (in the Cobalt Qube 3) - it was misdetected as an Athlon or Duron, gcc created binaries with an instruction unrecognised by the CPU and hence packages compiled fine but crashed as soon as you ran the program (I noticed this with vim, soon after I installed the box). I found a couple of ways to document what was happening, posted for help on the gcc mailing list and someone posted a patch within a few weeks. Once I confirmed the patch worked, it was added to the gcc tree and was in a new release within another few weeks. It wasn't the quickest experience I've had getting help from an open source developer - when I had a problem with dovecot its developer had a patch (which worked) for me to test the next day - but no-one was rude to me or made me feel unwelcome. I'm no-one of importance, but the gcc list helped me, fixed my bug and treated me as good as anyone else. Of course the Gentoo devs are just as helpful, but they don't normally spend their days fixing compiler bugs. Better IMO for you to take the problem upstream yourself, and then when it's fixed open a ticket on bugs.gentoo.org saying "this is the problem, it's fixed in release 1.2.3.4 of gcc, please add this to the tree ASAP as it's needed for arm64". IMO this is a good was for people like us to contribute to the distro. I'd expect everything you need, at least for an initial report, is in the emerge logs - surely all they do is dump the compiler output to a textfile? So you're taking the compiler output to the authors of the compiler - that's what they need to see in order to help you and fix problems with their program. It's helpful that you Gentoo is a fairly vanilla-upstream distro. Stroller.
[gentoo-user] Re: dev-lang/php-5.6
Am Mon, 27 Feb 2017 21:00:40 -0700 schrieb the...@sys-concept.com: > On 02/27/2017 02:11 PM, Alan McKinnon wrote: > > On 27/02/2017 22:14, the...@sys-concept.com wrote: > >> When will they drop the dev-lang/php-5.6.30 from the portage? > > > > If you copy the ebuild into your local overlay, then never > > > > I'll do it just in case but eventually I'll be force to upgrade. > I've upgraded 4-old boxes, three more to go + apache-2.4 I'm running an overlay for that matter: https://github.com/kakra/php-graveyard It will receive php-5.6 as soon as it leaves the main repository. But PLEASE, take note, that this receives no security updates. It's purpose is only to be able to still run installations which cannot be ported to newer PHP versions. Also, I can only give very limited support if something won't compile. The overlay exists for the purpose of running our own boxes with legacy PHP web applications and still being able to apply other security updates and do the resulting PHP rebuilds. -- Regards, Kai Replies to list-only preferred.
