# A Tentative at dillo-3.1-dev ebuild

## miroR

A Tentative at dillo-3.1 ebuild

==============================================

Don't get carried away by the name I gave to this ebuild, using the string:

```

3.1.0_pre20150712

```

3.1-dev was complained against by repoman to be illegal, but most of this first post has started as little more than a copy-paste ebuild exercize, as you will clearly be able to see.

As I described in a few topics of mine, that were read well in the span of months (and of years some), I install in air-gap, and I use a clone of the air-gapped for online; both (or more systems) of same hardware, as I explained here:

Postfix smtp/TLS, Bkp/Cloning Mthd, Censorship/Intrusion

https://forums.gentoo.org/viewtopic-t-999436.html

I've made this tentative on my online box, and if I am successful at repeating it in the air-gapped box (in somewhat improved way), then I can, regardless of the partly non-standard method, recommend it for both, at your own responsability, trying it out for yourself, and surely, also for improving it further and making it compliant to the teachings of the Elders of Gentoo FOSS Linux, as enshrined in the https://devmanual.gentoo.org and other arcane sources of illumination  :Wink:  , so we can deny it (in some later posts of this topic) the copy-paste status it now deplores to be in.

In a directory with all the permissions as user, such as:

```

$ mkdir ~/hg

```

(which we'll be using consistently because it simplifies explanations)

while online (I'd never, at this age of near total global surveillance, recommend to anybody to keep online all the time), do:

[[ just, if you haven't yet, install mercurial with:

```

# emerge -av mercurial

```

 ]]

And so [while online, do]:

```

$ hg clone http://hg.dillo.org/dillo dillo3

```

You will also need, for the copying work, the current dillo-3.0.5 source, as well as the ebuild (or better yet the corrected ebuild in your local overlay. For local overlay look into:

Local overlay

https://wiki.gentoo.org/wiki/Overlay/Local_overlay

The ebuild is already there if you sync'ed in July 2015, and if you haven't yet, fetch the tar archive:

```

$ emerge -avf www-client/dillo

```

You sure can also try:

```

$ emerge -av www-client/dillo

```

installing the current dillo version, to see the browser which we are dealing with, if you are not familiar with it, but I don't know if the bug that I submitted will have been acted upon by the time I post this on Gentoo Forums, so you may not install the full Dillo browser, as the fonts for the browser may not be found (but read about that in the bug and the links, it's easy to fix that, now). 

What I did with the mercurial dillo source that I downloaded, is, I tried to see how I get a snapshot, a tar'd archive, to serve for the ebuild as source, and I found about it on:

hg -- Mercurial source code management system

https://www.selenic.com/mercurial/hg.1.html#archive

Didn't study all of it yet, but did what was at hand (and you can, for now, retrace my steps)

```

$ cd ~/hg/dillo3

$ hg archive dillo3.tar.gz -X ".hg*"

```

You should now have:

```

$ ls -l dillo3.tar.gz 

-rw-r--r-- 1 miro miro 934287 2015-07-12 22:17 dillo3.tar.gz

$

```

That's not the final name, nor would simply a rename work.

```

$ mv -iv dillo3.tar.gz ../

‘dillo3.tar.gz’ -> ‘../dillo3.tar.gz’

$ mkdir ~/Test.d

$ cd ~/Test.d

$ tar xf ../dillo3.tar.gz

$ ls -l

total 4

drwxr-xr-x 12 miro miro 4096 2015-07-12 22:24 dillo3

$ mv -iv dillo3 dillo-3.1.0_pre20150712

‘dillo3’ -> ‘dillo-3.1.0_pre20150712’

$ 

```

Notice the rename of directory. And you try and notice further below that I use the same string for the name of the ebuild. For the purpose of copying-pasting, the current predominant level of my ebuild writing  :Wink:  .

My current level of ebuild writing goes as far as understanding that I should use the eclasses such as versionator and autobuild-<tools?>_<something>, in this current case, but haven't yet applied it.

Now, for a particular purpose of comparing the two archives, we need to unpack what you fetched further above.

```

$ cd ~/

$ tar xf /usr/portage/distfiles/dillo-3.0.5.tar.bz2

```

Or, if you can't, as I can't, since I have much stricter than shipped-in in most FOSS Linuces permissions, with my grsecurity-hardened kernel, and with gradm RBAC policy deployed (but that is a matter out of scope here), first, as root:

```

cd ~ukrainian/

# cp /usr/portage/distfiles/dillo-3.0.5.tar.bz2 .

```

(surely substitute 'ukrainian' for your own username)

and then:

```

$ cd ~/

$ tar xf dillo-3.0.5.tar.bz2

```

[[ At this phase in my writing of this post, it dawned on me that I will probably need to use the autogen.sh from the live dillo3 repository, so this entire post seems to be changing direction. A little. Because, the autogen.sh is, as it reads in the head of it:

```

# Script to generate configure&make stuff

```

(which, in my previous copy-paste attempt on the for-online box, I copied, most or all of the missing files, over from 3.0.5; ended up with a successful installation, mind you; some complaints only, not failure)

But just take a look at what change in direction my unfinished topic in Grsecurity Forums took:

A denied seteuid issue with Postfix (Role: root)

http://forums.grsecurity.net/viewtopic.php?f=5&t=4230#p15370

(

NOTE: The following digression about, for anyone who feels for FOSS, an important issue, is not needed for the dillo-3.1-dev ebuild setup.

find, exampli gratia, "broke my grsecurity exec_logging" and then in the linked:

Syslog-ng from Delay Logging to BrokenPipe/no Logging

https://forums.gentoo.org/viewtopic-t-1001994.html

find the bug:

app-admin/syslog-ng-3.6.2: scary time stamp jumps 

https://bugs.gentoo.org/show_bug.cgi?id=533328

[[[ And if any experts are reading this, isn't the excuse on what the error was, and the closing of the bug on:

Kernel log message time drift #121

https://github.com/balabit/syslog-ng/issues/121

completely lacking in credibility...??? Closing a very extant and very active bug like this one. Or what should I call it? Closing it like that?! Prove me wrong, and I will even apologize to balabit devs, but this does look like having some nepharious purpose underneath... ]]]

)

A change in direction for all the right and justified reasons there!

And this is just a minor change of direction in comparison.

]]

To see the differences btwn the snapshot of the live build and the one of the most recent release, I'll run a script for the purpose.

NOTE: as I figured out the right way for this overlay ebuild deployment, during my writing of this, this comparing the two dirs is less important.

```

#!/bin/bash

#

# cmp-two-dirs.sh

#

# under /usr/portage/licenses/BSD miroR, Gentoo Forums ;-)

#

# comparing two directories, $1 and $2;

# only makes sense if they are similar

#

echo "You can use other input, to compare in similar circumstances."

echo "Just give, say, the older dir as first arg, the newer as second."

prev=$1

curr=$2

if [ ! -e "$1" ] ; then

   prev=$(echo dillo-3.0.5)

   echo -n \$prev:; echo $prev

   curr=$(echo dillo-3.1.0_pre20150712)

   echo -n \$curr:; echo $curr

fi

read FAKE

cd ~/Test.d/

if [ ! -e "$prev" ] ; then ln -s ../$prev/ ; fi

ls -ld $prev/

read FAKE

ls -ld $curr/

read FAKE

for i in $(ls -1 $prev/) ; do

   if [ -f "$prev/$i" ] ; then

      #echo "A file. 1 level deep."

      #echo "ls -l $prev/$i"

      ls -l $prev/$i

      echo "ls -l $curr/$i"

      ls -l $curr/$i

      read FAKE

   elif [ -d "$prev/$i" ] ; then

      #echo "A dir. 1 level deep."

      #echo "ls -ld $prev/$i"

      ls -ld $prev/$i

      echo "ls -ld $curr/$i"

      ls -ld $curr/$i

      read FAKE

      echo "ls -l $prev/$i"

      ls -l $prev/$i

      echo "ls -l $curr/$i"

      ls -l $curr/$i

      for j in $(ls -1 $prev/$i/) ; do

         if [ -f "$prev/$i" ] ; then

            #echo "A file. 2 levels deep."

            #echo "ls -l $prev/$i/$j"

            ls -l $prev/$i/$j

            echo "ls -l $curr/$i/$j"

            ls -l $curr/$i/$j

            read FAKE

         elif [ -d "$prev/$i/$j" ] ; then

            #echo "A directory. 2 levels deep."

            #echo "ls -ld $prev/$i/$j"

            ls -ld $prev/$i/$j

            echo "ls -ld $curr/$i/$j"

            ls -ld $curr/$i/$j

            read FAKE

            echo "ls -l $prev/$i/$j"

            ls -l $prev/$i/$j

            echo "ls -l $curr/$i/$j"

            ls -l $curr/$i/$j

         else

            #echo "I thought we wouldn't reach here."

            #echo "Neither a dir nor a file?"

            #echo "2 levels deep."

            echo "ls -l $prev/$i/$j"

            ls -l $prev/$i/$j

            echo "ls -l $curr/$i/$j"

            ls -l $curr/$i/$j

            read FAKE

         fi

      done

   else

      #echo "I thought we wouldn't reach here."

      #echo "Neither a dir nor a file?"

      #echo "1 level deep."

      echo "ls -l $prev/$i"

      ls -l $prev/$i

      echo "ls -l $curr/$i"

      ls -l $curr/$i

      read FAKE

   fi

done

```

Lots of files are not in the dillo-3.1.0_pre20150712/ dir which are in dillo-3.0.5/ ! 

And conversely. Just run both: 

```

./cmp-two-dirs.sh dillo-3.0.5 dillo-3.1.0_pre20150712 |& tee \

   dillo-3.0.5-to-dillo-3.1.0_pre20150712_$(date +%y%m%d_%H%M).log

```

and

```

./cmp-two-dirs.sh dillo-3.1.0_pre20150712 dillo-3.0.5 |& tee \

   dillo-3.1.0_pre20150712-to-dillo-3.0.5_$(date +%y%m%d_%H%M).log

```

You'll be able to compare what has changed after running:

```

$ cd ~/Test.d/dillo-3.1.0_pre20150712

$ ./autogen.sh

```

, but rerunning those two cmp-two-dirs.sh lines above, and comparing the logs.

You probably will not have this temporary failure like mine:

```

ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $ ./autogen.sh

aclocal      found

autoheader      found

autoconf      found

automake      found

[Checks passed]

Generating...

sh: /dev/null: Permission denied

autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4

aclocal-1.15: error: echo failed with exit status: 1

sh: /dev/null: Permission denied

autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4

autoheader-2.69: '/usr/bin/autom4te-2.69' failed with exit status: 1

sh: /dev/null: Permission denied

autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4

sh: /dev/null: Permission denied

autom4te-2.69: need GNU m4 1.4 or later: /usr/bin/m4

automake-1.15: error: autoconf failed with exit status: 1

ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $ 

```

But read about that, on Grsecurity Forums:

denied open of /dev/null for reading

http://forums.grsecurity.net/viewtopic.php?f=5&t=4233

But rather (after I fixed the RBAC policy for the strange case):

```

ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $ ./autogen.sh 

aclocal      found

autoheader      found

autoconf      found

automake      found

[Checks passed]

Generating...

configure.ac:41: installing './compile'

configure.ac:6: installing './config.guess'

configure.ac:6: installing './config.sub'

configure.ac:8: installing './install-sh'

configure.ac:8: installing './missing'

dlib/Makefile.am: installing './depcomp'

ukra@box ~/Test.d/dillo-3.1.0_pre20150712 $

```

But the autogen.sh wasn't too verbose, really. It did more than it said in the messages it printed on stout. Just run the cmp-two-dirs.sh and you'll see! (Exampli gratia, all the Makefile.in are now there as well!)

Next, is preparing the archive to store it in /usr/portage/distfiles/:

```

$ rm dillo-3.0.5

$ mv -iv dillo-3.*.log ../Out-of-way/

```

The dir must only contain the archive to be:

```

ukra@box ~/Test.d $ ls -la

total 32

drwxr-xr-x  3 miro miro  4096 2015-07-13 12:01 .

drwxr-xr-x 45 miro miro 20480 2015-07-13 11:52 ..

drwxr-xr-x 13 miro miro  4096 2015-07-13 11:07 dillo-3.1.0_pre20150712

ukra@box ~/Test.d $ 

```

And:

```

$ tar cjf ../dillo-3.1.0_pre20150712.tar.bz2 .

$ cd ../

```

As root:

```

# cd ~ukrainian/

# cp -iav dillo-3.1.0_pre20150712.tar.bz2 /usr/portage/distfiles/

```

(surely substitute 'ukrainian' for your own username)

```

# chown portage:portage /usr/portage/distfiles/dillo-3.1.0_pre20150712.tar.bz2

# ls -l /usr/portage/distfiles/dillo-3.1.0_pre20150712.tar.bz2 

-rw-r--r-- 1 portage portage 995942 2015-07-13 12:02 /usr/portage/distfiles/dillo-3.1.0_pre20150712.tar.bz2

#

```

The archive should be (we'll see..) prepared for including it as source in our new ebuild, and then emerging into our system (WARNING: at your own responsability).

At this point I assume you have mastered the arcane secrets of the local overlay

(

onto which I stumbled upon in:

Mutt without Portage/in Local Overlay, for Air-Gappers

https://forums.gentoo.org/viewtopic-t-1002146.html

, and was almost mobbed, and people are still waiting around for a mistake like that which I made, so they can really lynch me  :Wink:  ... Sorry, can't help making a joke about it, but I really don't want to make a mistake like that again!

)

We'll copy the ebuild we already have in our portage tree giving it a new name in our local portage overlay:

```

cp -iav /usr/portage/www-client/dillo/dillo-3.0.5.ebuild \

   /usr/local/portage/www-client/dillo/dillo-3.1.0_pre20150712.ebuild

```

But actually, if the bug (

Dillo ebuild is missing xft flag for fltk, causes eye-sore 

https://bugs.gentoo.org/show_bug.cgi?id=554588

), that I submitted has not been acted upon yet, let's also make the Gentoo revision in our overlay, which will differ very little (in only 5 chars) from the currently most recent Dillo version in Portage:

```

cp -iav /usr/portage/www-client/dillo/dillo-3.0.5.ebuild \

   /usr/local/portage/www-client/dillo/dillo-3.0.5-r1.ebuild

```

And, to be complete, let's also copy the files/ dir over:

```

cp -iav /usr/portage/www-client/dillo/files/     /usr/local/portage/www-client/dillo/

```

So now our local portage overlay looks like:

```

# ls -lR  /usr/local/portage/www-client/dillo/

/usr/local/portage/www-client/dillo/:

total 12

-rw-r--r-- 1 portage portage 1409 2015-07-04 07:30 dillo-3.0.5-r1.ebuild

-rw-r--r-- 1 portage portage 1409 2015-07-04 07:30 dillo-3.1.0_pre20150712.ebuild

drwxr-xr-x 2 portage portage 4096 2014-10-09 18:46 files

/usr/local/portage/www-client/dillo/files:

total 4

-rw-r--r-- 1 portage portage 313 2014-08-23 12:01 dillo2-inbuf.patch

```

The files/ dir we won't be messing with at all, but just use it as in the original ebuild.

We need some rewriting to the copied files, though. A little to the -r1, and more to the 3.1.0. We'll open both in <your preferred editor>.

In the dillo-3.0.5-r1.ebuild find the line:

```

    >=x11-libs/fltk-1.3

```

and change it to read:

```

    >=x11-libs/fltk-1.3[xft]

```

and save and close that file. It's done.

And, more work, or just maybe more work, figuring it still out as I write (remember, I already had a successful installation by mere copying of files from the 3.0.5 archive on the other machine), on the dillo-3.1.0_pre20150712.ebuild...

I know there are instructions about how to deal with the header, but it may be faster trying it this will work, first. Because, the:

```

dillo-3.1.0_pre20150712.ebuild

```

in the local overlay,

and the:

```

dillo-3.1.0_pre20150712.tar.bz2

```

in the distfiles/ correspond correctly, since the line for the source in the ebuild is:

```

SRC_URI="http://www.dillo.org/download/${P}.tar.bz2

```

We're not online, and if the ${P}.tar.bz2 which is exactly dillo-3.1.0_pre20150712.tar.bz2 is in /usr/portage/distfiles/, the emerge will only check the hashes on it, and if they are fine, it will try compiling it.

So maybe not more work at all. Actually, the two ebuilds differ in name only (which sufficient for them to work with the accordingly-named source each):

```

# diff dillo-3.*.ebuild

#

```

returns an empty string.

And the hashes we now make for the dillo dir in our overlay:

```

# ls -l

total 12

-rw-r--r-- 1 portage portage 1414 2015-07-13 12:31 dillo-3.0.5-r1.ebuild

-rw-r--r-- 1 portage portage 1414 2015-07-13 12:31 dillo-3.1.0_pre20150712.ebuild

drwxr-xr-x 2 portage portage 4096 2014-10-09 18:46 files

# repoman manifest

>>> Creating Manifest for /usr/local/portage/www-client/dillo

# ls -l

total 16

-rw-r--r-- 1 portage portage 1414 2015-07-13 12:31 dillo-3.0.5-r1.ebuild

-rw-r--r-- 1 portage portage 1414 2015-07-13 12:31 dillo-3.1.0_pre20150712.ebuild

drwxr-xr-x 2 portage portage 4096 2014-10-09 18:46 files

-rw-r--r-- 1 root    root    2282 2015-07-13 12:39 Manifest

#

```

And now I think I can try emerging this new version. I have --ask and --verbose in my /etc/portage/make.conf. Have a look:

```

# grep '\--ask' /etc/portage/make.conf

EMERGE_DEFAULT_OPTS="--keep-going --with-bdeps=y --autounmask-keep-masks --ask --verbose"

#

```

If you don't, then change the emerge line to include '--ask' at least, else emerge won't wait for you to see what it will do and hit Enter to go on.

```

# emerge dillo 

These are the packages that would be merged, in order:

Calculating dependencies            ... done!                

[ebuild     U  ] www-client/dillo-3.1.0_pre20150712::miro [3.0.5-r1::miro] USE="gif ipv6 jpeg png ssl -doc" 0 KiB

Total: 1 package (1 upgrade), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] 

```

And I just hit Enter at that prompt, and, apparently, all went completely smooth...

Really?

Yes. I right click anywhere in empty, no-windows area of my openbox desktop (no dbus, no poetterware whatsoever

Uninstalling dbus and *kits (to Unfacilitate Remote Seats)

https://forums.gentoo.org/viewtopic-t-992146.html

), and choose dillo from the menu, and, really, I see a nice clear:

```

Welcome to Dillo 3.1-dev 

```

That much for now. I'll go into the other (the for-online) box, to post this, as my work with Dillo is not over, along with other FOSS areas that I feel keen interest for.

I hope this is useable for other Gentooers too. Mind this:

weirdly scaled images

http://lists.dillo.org/pipermail/dillo-dev/2015-July/010597.html

where find: "the STASI's of the world"

(which, if I could, would only want to correct that those devs lie --in the sense of dishonesty-- to users by serving also the big business, which are, rare exceptions --and honest exceptions surely are in among the spies-- mostly as dishonest as the state subject surveillors).

Surely this is sufficient for the purposes of demonstration. However, in comparison to 3.0.5 where I had ample documentation, here I have only:

```

# equery f dillo

 * Searching for dillo ...

 * Contents of www-client/dillo-3.1.0_pre20150712:

/etc

/etc/dillo

/etc/dillo/dillorc

/etc/dillo/domainrc

/etc/dillo/dpidrc

/etc/dillo/hsts_preload

/etc/dillo/keysrc

/usr

/usr/bin

/usr/bin/dillo

/usr/bin/dillo-install-hyphenation

/usr/bin/dpid

/usr/bin/dpidc

/usr/lib64

/usr/lib64/dillo

/usr/lib64/dillo/dpi

/usr/lib64/dillo/dpi/bookmarks

/usr/lib64/dillo/dpi/bookmarks/bookmarks.dpi

/usr/lib64/dillo/dpi/cookies

/usr/lib64/dillo/dpi/cookies/cookies.dpi

/usr/lib64/dillo/dpi/datauri

/usr/lib64/dillo/dpi/datauri/datauri.filter.dpi

/usr/lib64/dillo/dpi/downloads

/usr/lib64/dillo/dpi/downloads/downloads.dpi

/usr/lib64/dillo/dpi/file

/usr/lib64/dillo/dpi/file/file.dpi

/usr/lib64/dillo/dpi/ftp

/usr/lib64/dillo/dpi/ftp/ftp.filter.dpi

/usr/lib64/dillo/dpi/hello

/usr/lib64/dillo/dpi/hello/hello.filter.dpi

/usr/lib64/dillo/dpi/https

/usr/lib64/dillo/dpi/https/https.filter.dpi

/usr/lib64/dillo/dpi/vsource

/usr/lib64/dillo/dpi/vsource/vsource.filter.dpi

/usr/share

/usr/share/applications

/usr/share/applications/dillo-dillo.desktop

/usr/share/doc

/usr/share/doc/dillo-3.1.0_pre20150712

/usr/share/doc/dillo-3.1.0_pre20150712/AUTHORS.bz2

/usr/share/doc/dillo-3.1.0_pre20150712/ChangeLog.bz2

/usr/share/doc/dillo-3.1.0_pre20150712/Cookies.txt.bz2

/usr/share/doc/dillo-3.1.0_pre20150712/NEWS.bz2

/usr/share/doc/dillo-3.1.0_pre20150712/README.bz2

/usr/share/doc/dillo-3.1.0_pre20150712/user_help.html

/usr/share/man

/usr/share/man/man1

/usr/share/man/man1/dillo.1.bz2

/usr/share/pixmaps

/usr/share/pixmaps/dillo.png

```

But, this post suffices for the purposes of demonstration of the method.

Cheers!

----------

## miroR

I noticed some improvements in dillo-3.1-dev, but also I need to warn possible users of issues.

The CSS appears in some cases broken (I noticed the layout is not right on forums.debian.net), and...

...I stumbled on a real bad unexpected breakage. Go and see the bug that I submitted:

toggle header weeding in Mutt doesn't work

https://bugs.gentoo.org/show_bug.cgi?id=555180

and see the first, opening, comment of mine, as well as the first try to post my emerge --info.

Both those I posted with dillo-3.1-dev and I only noticed the ugly error when it was already done.

Masked 3.1-dev and emerged 3.0.5, and posted the rest (mostly) successfully. (mostly meaning: couldn't post the .muttrc as attachment, but had to put it into the comment.)

See also possible followups on:

no text wrapping on Gentoo Bugzilla

http://lists.dillo.org/pipermail/dillo-dev/2015-July/010603.html

----------

## miroR

That was (and apparently still is) a Dillo issue...

[Apparently still is.] However, I'm not expert to have the insight into all the possible influencing factors. See the post that I did with 3.0.5 Dillo:

toggle header weeding in Mutt doesn't work

https://bugs.gentoo.org/show_bug.cgi?id=555180#c8

This is the text, read it here more comfortably:

Well, how come, then, that that same .muttrc works, verbatim, unchanged, unmodified, just that exact configuration file, when I only install the upstream mutt, say the LFS way, not the Gentoo portage way?

RESOLVED INVALID. But, I bet we will see it applied!

Just as now a non-gpgme system like mine can install mutt which previously was not the case. See the Forums page linked in the bug 527338 (add support for app-crypt/gnupg as alternative to app-crypt/gpgme). That one was RESOLVED INVALID, but the support is now there.

Thanks!

----------

## miroR

This is a Dillo issue, along with the other part of the story as posted on the Mutt Outside Portage/In Local Overlay topic. That part, on the mangling of text I continue here, to not disturb that topic.

Literal text that I just posted in 

bug 554588

---

I cannot use newlines here, because something on the way changes thoese to something illegible (see my other bug 555180). In reply to Jeroen Roovers from comment #3 and #4) If you respect the Dillo program (which I hope you do), and you respect Gentoo Dillo users (which I also hope you do), please. do the advisory note that Walter Dnes suggested, and all will be fine. An average user like me will otherwise most likely live with miserable, no-unicode supporting fonts, that can not scale, which was my case for (sad to admit, but true:) at least some three months. A torture in itself. There is (I can only speak as user, really) comparison with the Dillo now: configurable, scalable, Unicode-supporting fonts, and before. (And it doesn't matter if you leave the bug invalid or not, only mercy from you towards users, by way of advicory as Walter suggested. matters. Thank you most kindly in advance!

---

There's only:

sed '/ comparison/ no comparison/'

the other minor errors are not rendering that text unintelligable, but see what appears there! And the text is the same that I pasted.

Sorry for the inconvenience!

----------

## miroR

I made a video. I really believe that the bug:

www-client/dillo should depend on x11-libs/fltk[xft]

https://bugs.gentoo.org/show_bug.cgi?id=554588

needs to be fixed, and I explained it in this video is such way that even newbies can understand. You should be able to see it, if you use any of the harvester browsers that bought you privacy for the convenience they bring you, directly (it's a HTML5 WEBM):

http://www.CroatiaFidelis.hr/foss/cap/cap-150824-Schm-capt/Screen_150824-Gen-Dillo.webm

With Dillo, the browser that is safe, but not sold out, I, if I didn't have it, would download it from the folder, where I'd first verify it's sum:

http://www.CroatiaFidelis.hr/foss/cap/cap-150824-Schm-capt/

Pls. somebody tell me, what is the way to try to ask higher-ups in Gentoo, to look into this matter?

Thanks!

----------

