Re: [gentoo-user] Is this a dependency bug?

[Andrew Savchenko]

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] SHA-1 has just been broken

[Miroslav Rovis]

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)

[Miroslav Rovis]

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] Cross-compiling for an unstable architecture.

[Andrew Savchenko]

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

[Andrew Savchenko]

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

[Rich Freeman]

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] dev-lang/php-5.6

[thelma]

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.

[Stroller]

> 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.

Re: [gentoo-user] prevent 'openoffice-bin' rebuild

[thelma]

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

[Michael Orlitzky]

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] webkit-gtk-2.14.2 cant find sqlite3 symbols

[Corbin Bird]

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"
>>> 

[gentoo-user] prevent 'openoffice-bin' rebuild

[thelma]

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

[Miroslav Rovis]

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

[gentoo-user] Re: dev-lang/php-5.6

[Kai Krakow]

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.

Re: [gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Peter Humphrey]

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

[gentoo-user] Re: Need coaching with emerge failure logs (Understanting the problem)

[Harry Putnam]

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] Re: Need coaching with emerge failure logs (Understanting the problem)

[Peter Humphrey]

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

[Andrew Savchenko]

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

Re: [gentoo-user] SHA-1 has just been broken

[Andrew Savchenko]

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

[gentoo-user] dev-lang/php-5.6

[thelma]

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] Network scanner [SOLVED]

[thelma]

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

Re: [gentoo-user] SHA-1 has just been broken

[Rich Freeman]

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)

[Harry Putnam]

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

[Rich Freeman]

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] SHA-1 has just been broken

[Alan McKinnon]

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] dev-lang/php-5.6

[Alan McKinnon]

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

[kelly hirai]

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 

Re: [gentoo-user] Network scanner [SOLVED]

[Neil Bothwick]

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)

[Neil Bothwick]

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