The Konqueror Bug - What Would it Take?
- Anmelden oder Registrieren um Kommentare zu schreiben
I am curious about the Konqueror bug. The problem is Konqueror suggests non-free software, by recommending Adobe Flash on certain websites. My question is, what methods are necessary to fix this bug? Could it only be fixed by a programmer or could it be fixed by searching and replacing text in source files? What might be the correct suggestion for Konqueror to make instead of suggesting Flash? Should it suggest Gnash or Lightspark? (My money is on Gnash, but only because I love it.)
If you had dug through the links to and in gNewsense bugs your
question is answered here:
http://lists.nongnu.org/archive/html/gnu-linux-libre/2011-05/msg00007.html
In short a code change is required.
> I am curious about the Konqueror bug.
There are two bugs, the other one is that it's about screen links to
nonfree plugins that it supports. The one you describe technically
isn't a Konqueror bug, it's in KHTML in kdelibs (I don't know if this
message occurs in other programs using KHTML).
> The problem is Konqueror
> suggests non-free software, by recommending Adobe Flash on certain
> websites.
It recommends the plugin recommended by the site, using the embed tag.
> My question is, what methods are necessary to fix this bug?
> Could it only be fixed by a programmer or could it be fixed by
> searching and replacing text in source files?
It's nearly the same, it might need some understanding of what the code
does. If I have fixed them in Parabola (I don't remember who did it), I
had no previous experience with KDE code (and I don't know C++ nor Qt
well).
> What might be the
> correct suggestion for Konqueror to make instead of suggesting Flash?
> Should it suggest Gnash or Lightspark? (My money is on Gnash, but only
> because I love it.)
It suggest the plugin suggested by the site (maybe some suggest free
plugins), I don't consider it a useful feature, so in Parabola it
doesn't suggest any plugin. (On many sites this isn't used, JavaScript
or the object tag handles it.)
The patches in Parabola:
https://projects.parabolagnulinux.org/abslibre.git/tree/libre/kdelibs-libre/khtml-fsdg.diff
https://projects.parabolagnulinux.org/abslibre.git/tree/libre/kdebase-konqueror-libre/konq-about-fsdg.diff
I had wondered if Parabola had altered some part of KDE, because I noticed parts of KDE were replaced when I migrated to Parabola from a fresh Arch install. (I've never been able to boot the Parabola iso from USB, so I installed Arch, then migrated to Parabola per the instructions on the Parabola website. I also have a question about Parabola, which would be off-topic here.)
Based on the information you provided, would it be possible to compare/diff the KDE source files from Parabola, to those in Trisquel, to spot the differences and make whatever alterations necessary?
I had no way of knowing these bugs exist, probably due to the strange way I use Konqueror. I only use Konqueror with the kwebkit-part backend. All plugins are turned off. Java & javascript are also turned off. Konqueror points to Privoxy, which chains to Tor. I just went to Youtube and verified there is no message shown for videos with such a configuration.
> I had wondered if Parabola had altered some part of KDE, because I
> noticed parts of KDE were replaced when I migrated to Parabola from a
> fresh Arch install.
They do, it might be easy to find the changes from the pages I linked to
(I think the other changes are just recommending Duck Duck Go, not
supporting Skype and not recommending nonfree optional dependencies).
> (I've never been able to boot the Parabola iso
> from USB, so I installed Arch, then migrated to Parabola per the
> instructions on the Parabola website. I also have a question about
> Parabola, which would be off-topic here.)
Ask on name at domain (needs subscription at
https://lists.parabolagnulinux.org/mailman/listinfo/assist) or #parabola
at FreeNode.
> Based on the information you provided, would it be possible to
> compare/diff the KDE source files from Parabola, to those in Trisquel,
> to spot the differences and make whatever alterations necessary?
The easiest way to do this is to use the patch program to apply these
changes to the sources that Trisquel uses and edit the patch if it won't
apply.
I just checked the Konqueror 'About' screen. This is on Gentoo Hardened, using KDE 4.9.3. It states the following:
"Web browser, file manager and document viewer
C) 1999-2008, The Konqueror developers
http://konqueror.kde.org"
I probably need to boot into Trisquel and check it there, or download the source in Trisquel and look there. Or maybe it
would be better to nose around in the Toutatis VM and do it there.
I can see one of the bugs in the source now. There is an html page that appears when you first open Konqueror, that says "Be Free' & shows links to the home folders, network folder Trash & Bookmarks. Above those links, there are 4 more links:
Starting Points
Introduction
Tips
Specifications.
If you click on the 'Specifications' link, it takes you to the page which recommends non-free software, including Flash and Real. The link to real.com returns an error - 'detected that the server is redirecting the request for this address in a way that will never complete.' Those links are placed in the original source files like this:
QString("http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"),
QString("http://www.real.com"), QString("http://www.real.com"),
Would it be better to remove the entire line that contains the non-free links: "Netscape Communicator® plugins (for viewing Flash®, Real®Audio, Real®Video, etc.)" ?
> Would it be better to remove the entire line that contains the
> non-free links: "Netscape Communicator® plugins (for viewing Flash®,
> Real®Audio, Real®Video, etc.)" ?
It's ok to state that Netscape Communicator plugins are supported, since
e.g. Gnash and IcedTea provide such plugins.
Is this the end result we are looking for, as far as the Konqueror 'About' page:
[ http://oi47.tinypic.com/delmqs.jpg - Fixed Konq ]
That's Trisquel Brigantia. It should be no problem to fix the other bug, following the example Parabola patches posted earlier in this thread. I only added the specific lines shown in the Parabola patches, then only removed the specific lines shown in the Parabola patches.
I've never done this before, so I need some guidance on the next step. I don't know how to submit patches. I don't know who I should submit them to, aside from Trisquel.
I will do the other Parabola patch posted in this thread as well. Should I also do both patches for Toutatis and submit those as well?
> I've never done this before, so I need some guidance on the next
> step. I don't know how to submit patches. I don't know who I should
> submit them to, aside from Trisquel.
>
> I will do the other Parabola patch posted in this thread as
> well. Should I also do both patches for Toutatis and submit those as
> well?
The Trisquel process is to code a package helper as per this page:
https://trisquel.info/en/wiki/package-helpers
In brief you need to create (not from scratch) a bash/sed|awk job to
make the patches to the package.
After that it is a matter of attaching the output of a bzr diff
incorporating you helper to a post to the trisquel-devel mailing list
(which you will have to join first). It would be a good idea to
provide a link to your email in the Issue on the website as well.
Last I looked the Toutatis helpers were not yet online. I haven't
yet looked at IRC and found quidam online to ask him to do that, a
second pair of eyes watching for him might help.
> Last I looked the Toutatis helpers were not yet online. I haven't yet
> looked at IRC and found quidam online to ask him to do that, a second
> pair of eyes watching for him might help.
They are at git://devel.trisquel.info/package-helpers.git,
http://devel.trisquel.info/gitweb/?p=package-helpers.git;a=shortlog;h=refs/heads/toutatis.
I haven't seen an official mention of it outside the
https://trisquel.info/en/forum/open-distribution-closed-development
thread. (Never used them.)
>> Last I looked the Toutatis helpers were not yet online. I haven't
>> yet
>> looked at IRC and found quidam online to ask him to do that, a sec
>> ond
>> pair of eyes watching for him might help.
>
> They are at git://devel.trisquel.info/package-helpers.git,
> http://devel.trisquel.info/gitweb/?p=package-helpers.git;a=shortlog
> ;h=refs/heads/toutatis.
misleading statement removed.
Correction - You can get them from
git://devel.trisquel.info/packages-helpers.git
It transpires after I dug about a bit, each release's helpers are in a separate branch in the repo. So a 'git checkout toutatis' will get you the 6.0 helpers.
> Unless they're not the helpers available at
> git://devel.trisquel.info/package-helpers.git then all the git repo
> there is is the helper framework code (the two commands), not the
> helpers themselves.
There are separate branches per release with helpers. Try this:
git clone git://devel.trisquel.info/package-helpers.git
cd package-helpers
git checkout toutatis
>> Unless they're not the helpers available at
>> git://devel.trisquel.info/package-helpers.git then all the git repo
>> there is is the helper framework code (the two commands), not the
>> helpers themselves.
>
> There are separate branches per release with helpers. Try this:
>
> git clone git://devel.trisquel.info/package-helpers.git
> cd package-helpers
> git checkout toutatis
Thanks! I got there myself just before seeing yuor post. I have
edited the original misleading stuff out of the forum entry.
As a result of your information I've had enough of a 'play' with the
git package helpers to be able to update the package helpers page
here:
https://trisquel.info/en/wiki/package-helpers
Please read, comments welcome.
I found out about the package helpers and bzr by nosing around on this site last night. I am WAY out of my league here, because I barely know a wee bit of bash, and I know nothing at all about sed nor awk. However, I do enjoy learning new things. I can test again and again before I submit anything because I've still got the sources installed.
Let me go find an online Dummies guide to sed & awk and see what I can do. Give me some time.
> Let me go find an online Dummies guide to sed & awk and see what I can
> do. Give me some time.
From the info sed Other Resources node:
6 Other Resources for Learning About `sed'
******************************************
In addition to several books that have been written about `sed' (either
specifically or as chapters in books which discuss shell programming),
one can find out more about `sed' (including suggestions of a few
books) from the FAQ for the `sed-users' mailing list, available from:
`http://sed.sourceforge.net/sedfaq.html'
Also of interest are
`http://www.student.northpark.edu/pemente/sed/index.htm' and
`http://sed.sf.net/grabbag', which include `sed' tutorials and other
`sed'-related goodies.
The `sed-users' mailing list itself maintained by Sven Guckes. To
subscribe, visit `http://groups.yahoo.com' and search for the
`sed-users' mailing list.
The links to the Trisquel helpers for the next release are helpful. I first checked the source for KDE 4.9.3 on Gentoo Hardened. It didn't seem that anything had changed as far as these patches go. It should be no problem to do this for Brigantia & Toutatis as well. One patch should apply to either, but I will check and recheck to make sure, as soon as I figure this out.
Ok. Sed is easy, at least as far as deleting text, as in the first Parabola patch posted in this thread. For the KDE 4.9.3 sources, that patch would be done like this:
sed -e '578,617d' htmp_objectimpl.cpp
(assuming you were already in the same directory as the file)
> sed -e '578,617d' htmp_objectimpl.cpp
Use this instead:
patch -p1 -i khtml-fsdg.patch
It will work if there are other lines changed (outside the context of
the patch) and will clearly error if the patch cannot be applied,
e.g. due to the affected lines being changed.
Michael:
I am not sure I understand your reference to using patch instead of sed. How can the patch app know what to do to the source files, without a list of instructions? Or, are you saying I can copy the two patches from Parabola, then make whatever changes are necessary (for example, change the line numbers to 578-616, instead of 580-619, or just copy the changed/removed lines wholesale.)
Toutatis uses KDE 4.8.5, so as it stands now
Brigantia - remove lines 580-619 in kde4libs-4.7.4/khtml/html/html_objectimpl.cpp
Toutatis - remove lines 578-616 in kdelibs-4.8.5/khtml/html/html_objectimpl.cpp
> How can the patch app know what to do to the source files,
> without a list of instructions?
The patch file works like a list of instructions (to replace some lines
in a context with other lines; there are other diff formats which aren't
as useful for patches as unified diffs).
> Or, are you saying I can copy the two
> patches from Parabola, then make whatever changes are necessary (for
> example, change the line numbers to 578-616, instead of 580-619, or
> just copy the changed/removed lines wholesale.)
There is no need to change the line numbers, patch will find the parts
to change from the context (the original lines with the before and after
context) and show the difference in line numbers. (Patches are rarely
manually modified, they are usually made using diff or various VCS
commands.)
Most changes in source code occur in other functions and just add or
remove lines outside the part included in the patch, so this usually
works (and in other cases it clearly fails with an error).
The kdelibs patch in Parabola had no change since 4.8.0.
OK, I get the same error when using this command:
patch -p1 -i khtml-fsdg.patch
It's actually khtm-fsdg.diff
After changing the name of the command and issuing it in the directory kde4libs-whatever-version/khtml/html, the output is always this, whether on Brigantia or Toutatis:
----------------------------------
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -ru kdelibs-4.8.0.orig/khtml/html/html_objectimpl.cpp kdelibs-4.8.0/khtml/html/html_objectimpl.cpp
|--- kdelibs-4.8.0.orig/khtml/html/html_objectimpl.cpp 2012-01-30 19:46:27.684114289 +0100
|+++ kdelibs-4.8.0/khtml/html/html_objectimpl.cpp 2012-01-30 19:47:47.222111046 +0100
--------------------------
File to patch:
-------------------------------------
It's easy enough to get past. If I type the name of the file, the patch applies. However, if I am to (eventually, hopefully) write a helper off of this diff, won't the diff need to apply correctly on the first shot, without having to specify the exact name of the file to edit?
This must be occurring because the diff itself references kdelibs-4.8.0, whereas on Brigantia the diff is in the 4.7.4 folder and on Toutatis it is in the 4.8.5 folder. Additionally, Trisquel is renaming the kdelibs directories to kde4libs-version-number, instead of kdelibs-version-number.
Should I edit the first three lines with the Trisquel-correct directory names to get the patch/diff to apply on the first shot?
> patch -p1 -i khtml-fsdg.patch
[...]
> After changing the name of the command and issuing it in the directory
> kde4libs-whatever-version/khtml/html, the output is always this,
> whether on Brigantia or Toutatis:
>
> ----------------------------------
> can't find file to patch at input line 4
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |diff -ru kdelibs-4.8.0.orig/khtml/html/html_objectimpl.cpp
> kdelibs-4.8.0/khtml/html/html_objectimpl.cpp
> |--- kdelibs-4.8.0.orig/khtml/html/html_objectimpl.cpp 2012-01-30
> 19:46:27.684114289 +0100
> |+++ kdelibs-4.8.0/khtml/html/html_objectimpl.cpp 2012-01-30
> 19:47:47.222111046 +0100
The -p1 option tells patch to ignore the first component of the file
name, so it will look for khtml/html/html_objectimpl.cpp in the current
directory. The solution is to run it in the kde4libs-whatever-version
directory. (Patches can change multiple files, it's simpler to apply
all from the main package source directory.)
Okey dokey. I'll try that next.
You know, this is driving me NUTS, because I've got to fix these bugs in my Gentoo systems too. I've set up a local overlay, named the '4Freedoms' overlay. I haven't done anything to it yet. But I know once I have both of these Konqueror bugs fixed and submitted for Trisquel, I should be able to apply these same patches to my own system (assuming I can ever get the overlay setup correctly and the patches applied correctly.)
And after that, there are the mesa bugs and well, pretty much the entire list of non-free bugs I want out of/blocked from my 2 Gentoo installs. It's not an issue in my Parabola install. obviously, and won't be soon in my Trisquel install.
Finally I am back. I switched to Parabola while I was gone. I've had a couple of very minor issues with it, which I have mostly managed to work out. Aside from VLC, everything works perfectly. (I prefer smplayer anyway.) Parabola has MANY very nice perks and runs faster than Gentoo hardened does. I did install a couple of apps from Arch's AUR, which were nomacs and qbittorrent. Since they are both under the GPL, the 'your-freedom' app had no complaints.
I installed Parabola over my normal Gentoo install, but haven't wiped the hardened install yet. I am wondering if I might be able to create an overlay to build some of these totally free changes into Gentoo. On the other hand, Gentoo's mplayer is insisting I make a license exception for unrar, which has gotten me to the point where I am ready to ditch Gentoo completely.
Anyway, to get back on the real topic here, would it be best to continue this conversation on the devel list? I can't pick back up with this just yet. I need to get Toutatis on my third hard drive, because I really don't care to unzip kdelibs source code in a virtual machine again. It will be much, much easier for me to mess with this with Toutatis on it's own drive.
Let me know if it's best to continue the conversation here in these forums or to move it over to the devel list, which I've already joined.
- Anmelden oder Registrieren um Kommentare zu schreiben