Re: [Bug-gnuzilla] Privacy settings do not hide themselves

[Ivan Zaigralin]

Is this new tab screen custom icecat addition? I absolutely love it. Settings 
wheel gear shows it's supposed to be search in new tab, so that's like an 
inconsistency, and the reported bug I didn't really test. Anyways, this is 
amazingly useful way to fill a new tab.

On Tuesday, August 20, 2019 19:44:52 zna...@disroot.org wrote:
> Hi! Here we have noticed Icecat has a bug:
> https://lists.gnu.org/archive/html/help-guix/2019-08/msg00086.html
> 
> 'Privacy settings' block appears always nevertheless Icecat has value
> 'false' by default in
> 
> browser.onboarding.enabled
> 
> in about:config.
> And changing it to 'true' does not help too.
> Can you debug this. I want hide 'Privacy settings' cause I do not use this
> block.

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

Just like Stephan, I am mostly an observer when it comes to web standards, 
although I did wet my toes by writing personally to Tim Berners-Lee about 
their epic EME fail, and later by trying to convince various people of 
consequence that we, the free software community, need to fork everything w3c 
got, and take them out to the curb. So I guess I am not really much like 
Stephan, being a meddler and all that :)

Anyways,

Other replies to this post are correct to point out there are HTML+CSS 
features which allow interactivity and adaptive design without a need to 
resort to client-side scripting. What Stephan says about the application stack 
goes had to hand with that. I think I would agree that regardless of how it's 
accomplished on a technical level, web users do expect something like an 
application platform, or may be even an application marketplace. Even 
something like a simple POST/GET form creates an air of interactivity, and the 
website becomes, essentially, an app in the mind of a user. Web search sites 
function like app stores/repos, you get the idea. It seems kind of pointless 
to object to this way of using the web, as long as we can implement it in an 
ethical, user-friendly manner — as opposed to user-hostile. And it does look 
like this is a tractable problem. Even now, most appy needs can be met with 
HTML+CSS, and the rest can be implemented in browser plugins and new tags. 
Whether or not we can overcome the inertia or even convince most users this is 
a direction worth exploring, that's an open question.

I completely agree about the bloody gooey mess that is HTML without the 
leading X. As TBL himself said back in 2006, when he was still worth paying 
attention to,

> The attempt to get the world to switch to XML … all at once didn't work.
> The large HTML-generating public did not move

12 years later, the large HTML-generating public is guzzling the cool-aid, so 
we are as far from a wide adoption of a sane technical standard as we've ever 
been, and the outlook is not good. Notice how astute this quote is, it 
correctly identifies the culprits, who are not web users, not browser 
developers, not standard-setting bodies, but the web developers. And the 
problem with them, there are only a few good apples in that barrel.

Let's try to analyze this issue and look for possible solutions. The 
commercial web is huge these days, could that be the source of the mess? It 
seems plausible to me that the commercial web design is motivated, in large 
part, by competition. And what could be better than your competitor's website 
being 35% less funteractive than yours? Well, one thing comes to mind — when 
your competitor's website stops working altogether. So if you are a commercial 
web designer, there is this massive *evolutionary* pressure to bend the web 
standards to your personal will, and I doubt it can be counteracted by good 
intentions or even good work done by small minorities. The large HTML-
generating public will surely continue to tug on the standard from all 
directions, chaotically, with the end result of HTML# absorbing more and more 
collective stupidity, with none of the old issues ever being fixed.

Now let's talk solutions.

A pipe-dream solution is a new web standard, basically web 6.0, with 
everything above URIs rewritten from scratch. Dump the XML monster, no one 
will cry. Lay down clear guidelines for going forward, taking the needs of 
users, including privacy and security, into account. From the ground up, 
design the markup with interactive functions in mind.

A safe and practical local solution for the free software community is an 
XHTML+CSS fork, and convincing user-respecting web designers to make a clean 
break.

The only practical global solution would be legislative in nature. We must 
apply enough pressure on commercial web designers to counteract the 
evolutionary force which drives them deeper into the HTML5 jungle. Web users, 
not Web designers, should have the ultimate control over the web platform, 
unless they <3 getting shafted with every click. Indeed, web designers are 
neither demanding nor exercising any direct control, being completely at the 
mercy of what is *perceived* as the web standard, so they won't care or 
notice. Their current influence is simply a superposition of millions of 
little individual tugs, and we could block it very effectively with basic 
regulations protecting the consumer rights on the web.

On Wednesday, March 07, 2018 20:14:50 Stephan Kreutzer wrote:
> Hi guys,
> 
> I don't know to which extend each of you is involved in web standards -- I
> myself only observe it passively, so feel free to object to any of my
> following statements:
> 
> To me, it looks like that there can't be a HTML6 any more than there was a
> HTML4 and HTML5, because in HTML5, the crazy web guys decided that they
> neither need a DOCTYPE any more, and the deprecated version attribute for
> the root element was removed, so now, to my 

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

On Tuesday, February 27, 2018 23:36:37 bill-auger wrote:
> On 02/27/2018 01:33 PM, Ivan Zaigralin wrote:
> > I realized that in order to make the web useful without
> > having to run nonfree software, we must *unscript* it. Fixing individual
> > pages/domains will not solve the problem posed by the disposable software;
> 
> just to be clear about the words you are using - where first you
> mentioned "drive-by-download" and now you say "disposable software" -
> you meant the same by these yes? "disposable software" is quite better -
> that says it very precisely - not unlike a plastic diaper

Well, they are two different facets of the same complex human+computer 
language+protocol we call the web.

Disposable software (which we could also call transient software) is pretty 
much anything rapidly generated by a computer, but especially the obfuscated 
code, which may also be salted to fool automated detectors. The key property 
of such software is that it's not intended for audit (no one has such 
capacity), and the obfuscated part of it is resistant to audit. It is also, as 
you pointed out elsewhere, mostly useless outside of its intended context.

Drive-by-downloading should really be called drive-by-execution (but that's 
too gruesome :), and this term refers to a specific user-side policy, not 
software. The policy is: upon loading a web page, have the web browser 
automatically download and execute arbitrary (and often disposable) code from 
absolutely anywhere on the web.

This is a very detrimental policy. It's bad for agents who follow it, and 
because so many people and computers follow it, it also ruins the web for the 
rest of us. This last bit is a good reason to fight it with legislation aimed 
at protecting the rights of people who choose not to engage is this madness. 
Make commercial and government sites provide free-software-friendly fronts and 
all that.

But another side of that issue is educating the users, and here I am very 
pessimistic. And we probably do need to educate the users if we are ever to 
get the popular support for appropriate legislation. But users are in a 
baad state of mind these days. I am personally blown away by every person 
who is not *aghast* at the fact that they are not allowed to own a mobile 
phone. Even the people who believe in the sanctity of private property are 
seemingly unable to connect the dots. Without the right to repair or even 
control, these are rentals in every sense of the word. Indeed, telling others 
how to repair devices powered by nonfree software will likely result in a 
prison sentence in US:

https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act

What chance do we have explaining the subtle exploitation via the disposable 
software, when users stampede storefronts hoping to become proud renters of 
devices which rob them of basic consumer rights, and spy on the most intimate 
details of their private lives 24/7, text+sound+video?

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

On 02/22/2018 02:56 PM, David Hedlund wrote:
> On 2018-02-22 09:22, Ivan Zaigralin wrote:
>> GPL-licensed code is not necessarily free. An obfuscated source is
>> unmaintainable regardless of the license, so two freedoms are taken
>> away: the freedom to study, and the freedom to run modified versions.
>> LibreJS is unable to detect obfuscated code.
>
> Thank you. This is a bug, can you please file a bug report to
> https://savannah.gnu.org/bugs/?group=librejs ?

If anyone wants to submit this issue/bug via the formal channels, god-speed, 
but I am hardly the right person to do that. The issue being: one of the 
stated design goals of LibreJS is to block non-free JS while allowing free JS, 
but it doesn't look like this goal is attainable even in principle without a 
human or human-grade AI vetting every incoming byte. And even with such 
fantastic vetting in place, there is still the intractable problem of users 
not being able to *afford* to change the behavior of *disposable* software, 
which effectively takes away a core freedom, regardless of how the disposable 
code is licensed. (A detailed explanation is cited at the end of this post.)

So on one hand, it does not feel right to me to create a ticket which will 
basically say that the very concept of LibreJS is misguided, the stated goals 
are unattainable, the users are misled, and the energy would be better spent 
on *unscripting* the web. Not only this would be borderline trolling, but I am 
also taking notice of other people's personal opinions on the matter. RMS, in 
particular, has been reported to believe in the usefulness of LibreJS. Perhaps 
RMS considers the marginal profit stemming from filtering out *some* nonfree 
code as beneficial enough to offset the downsides: the filter is not perfect, 
and users continue to cozy up to a platform which will never be free. Perhaps 
RMS thinks that any amount of attention drawn to this problem is better than 
nothing, even if it's due to a technical non-solution. And perhaps he is 
right, I really cannot build a strong argument against such notions.

On the other hand, I personally have had a single interaction with Savannah 
collective so far, and it was not a very pleasant one, although if I had to 
point a finger to one person most to blame, it would be me :) I basically 
popped a vein and raised hell when they told me my project will not be hosted 
because it's not "generally useful", and I managed to convince them to admit 
the subjective component of the initial review on their web page. It took a 
lot of time and fighting, and the final result looks like "...but is 
ultimately at the discretion of Savannah hackers."

https://savannah.gnu.org/maintenance/HowToGetYourProjectApprovedQuickly/

I'd rather see a clear description of this rejection policy, which is in fact 
based on a *subjective* perception of quality and usefulness by a single 
examiner, but just having them to officially *confirm* this policy in a 
mailing list took KiBs of heated exchange. So I am afraid that if I come back 
with another highly contentious issue like the very fate of LibreJS, no matter 
how good my argument is, it will produce more pointless anger and friction.

I have to say, this thread really made me think about the JS trap some more, 
and I really feel that with the help of bill's sharp questions we are making 
some progress here. I realized that in order to make the web useful without 
having to run nonfree software, we must *unscript* it. Fixing individual 
pages/domains will not solve the problem posed by the disposable software; the 
way we interact with the web must change, and this can only be effected via a 
standardization of a protocol. And the other thing I realized, there is a 
clear path forward, and it has to do with web masters. One of the most 
important parts of LibreJS project is its appeal to web masters, who are being 
asked to free the JS code in order to disabuse the users. We need to go after 
the same web masters, and ask them to do more, if not something else entirely. 
If these web masters already believe that a free web is a worthy goal, we 
should be able to convince them to act now by making sure their web pages are 
fully functional without JS. We should also be able to convince them to make 
the non-JS version the default, and create a long-term plan for ditching JS 
completely. And if they also want to annotate the legacy JS code so that its 
license can be checked by a simple AI, that's fine too, as long as they keep 
their eyes on the prize.

On Tuesday, February 27, 2018 00:19:29 bill-auger wrote:
> On 02/26/2018 10:10 AM, David Hedlund wrote:
> > Issues can be reported to https://savannah.gnu.org/bugs/?group=librejs
> > as well since there are not dedicated "issue" link for LibreJS.
> 
> im not sure what is the difference between "issues" and "bugs" but
&g

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

I am not sure about the details, but this page explains what the web masters 
are expected to do, annotation-wise, in order to placate LibreJS:

https://www.gnu.org/software/librejs/free-your-javascript.html

I would not call this strategy crazy, but ineffective, yes. What's crazy is 
the common user behavior of allowing their computers to download and execute 
the code from literally dozens of independent sources, none of it audited ever 
by anyone, every time they reload a web page. To add insult to injury, 99% of 
these web pages would be fully functional and much faster if they were 
implemented in flat HTML+CSS.

On Thursday, February 22, 2018 18:50:30 Narcis Garcia wrote:
> It seems a crazy strategy.
> If GNU distributions used this kind of analysis instead of trusting
> software from subscribed repositories, all our computers could be a
> jungle (either with scripts and compiled files).
> 
> How does LibreJS check an script's license?
> 
> El 22/02/18 a les 18:43, Ivan Zaigralin ha escrit:
> > From what I can pick up, LibreJS tries to detect and whitelist "trivial"
> > code first, meaning, the code which an algorithm can recognize as
> > data-like and harmless. For all other code, it checks the license. I
> > don't have details on how these things are done, but both can clearly be
> > programmed in a variety of ways.
> > 
> > On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
> >> I was asking about the CURRENT principle for LibreJS, not for "good" or
> >> "bad" of theoretically prossibilities.
> >> 
> >> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> >>> On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
> >>>> Which is the principle for LibreJS to approve JavaScript functions
> >>>> and/or files?
> >>>> A license mention?
> >>> 
> >>> Can be regarded as necessary, but not sufficient.
> >>> 
> >>>> A signature?
> >>> 
> >>> Useful for creating a trust model between users and web parties, but
> >>> this
> >>> is already implemented by https+noscript, and it solves a different
> >>> problem, not directly freedom-related.
> >>> 
> >>>> A well-known functions comparison? A code analysis? It replaces
> >>>> funcions?
> >>> 
> >>> A code analysis is pointless. Detecting obfuscated code, in particular,
> >>> is
> >>> an intractable problem. If you could define "obfuscated" formally,
> >>> chances are, there would be a formal proof that the detection is
> >>> unsolvable by a TM. But generally speaking, a good way to obfuscate is
> >>> by
> >>> writing a virtual assembly interpreter, and then feeding it "binaries"
> >>> which appear to be perfectly cromulent, poetic even, JavaScript sources.
> >>> And obfuscated code cannot be considered free.
> >>> 
> >>> None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
> >>> miners are all the rage right now. This is where we are today.
> >>> 
> >>> 
> >>> 
> >>> --
> >>> http://gnuzilla.gnu.org
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> >> 
> >> 
> >> --
> >> http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

From what I can pick up, LibreJS tries to detect and whitelist "trivial" code 
first, meaning, the code which an algorithm can recognize as data-like and 
harmless. For all other code, it checks the license. I don't have details on 
how these things are done, but both can clearly be programmed in a variety of  
ways.

On Thursday, February 22, 2018 10:57:28 Narcis Garcia wrote:
> I was asking about the CURRENT principle for LibreJS, not for "good" or
> "bad" of theoretically prossibilities.
> 
> El 22/02/18 a les 09:35, Ivan Zaigralin ha escrit:
> > On Thursday, February 22, 2018 08:43:38 Narcis Garcia wrote:
> >> Which is the principle for LibreJS to approve JavaScript functions
> >> and/or files?
> >> A license mention?
> > 
> > Can be regarded as necessary, but not sufficient.
> > 
> >> A signature?
> > 
> > Useful for creating a trust model between users and web parties, but this
> > is already implemented by https+noscript, and it solves a different
> > problem, not directly freedom-related.
> > 
> >> A well-known functions comparison? A code analysis? It replaces funcions?
> > 
> > A code analysis is pointless. Detecting obfuscated code, in particular, is
> > an intractable problem. If you could define "obfuscated" formally,
> > chances are, there would be a formal proof that the detection is
> > unsolvable by a TM. But generally speaking, a good way to obfuscate is by
> > writing a virtual assembly interpreter, and then feeding it "binaries"
> > which appear to be perfectly cromulent, poetic even, JavaScript sources.
> > And obfuscated code cannot be considered free.
> > 
> > None of this is purely academic. Dynamic, obfuscated JavaScript bitcash
> > miners are all the rage right now. This is where we are today.
> > 
> > 
> > 
> > --
> > http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

On Thursday, February 22, 2018 01:04:30 bill-auger wrote:
> this is confusing - what exactly is a
> "drive-by-download" and how are they inherently "non-free no matter what
> license is attached to them"?
> 
> also, how could LibreJS "incorrectly mark an obfuscated piece of
> GPL-licensed code as free" - GPL-licensed code IS free

GPL-licensed code is not necessarily free. An obfuscated source is 
unmaintainable regardless of the license, so two freedoms are taken away: the 
freedom to study, and the freedom to run modified versions. LibreJS is unable 
to detect obfuscated code.

What I mean by drive-by-downloading, here we get philosophical. How free is 
the code which is only meant to be executed once? No one audits > 99% of this 
code, and it's all in constant flux. I would even argue, there's no hope it 
can ever be audited. There are already (I am sure) websites that generate 
brand-new code for every visit, making this assertion literal. How do you 
audit all that code? With an automated tool? An algorithm can't even solve a 
halting problem, let alone audit itself out of a paper bag.

Now put yourself in the shoes of an average web user. Average here is the key 
word. Their freedoms to understand and modify the JavaScript code have all but 
completely eroded. In a traditional software distribution market they can hire 
experts to explain and fix the software for them. This is utterly unaffordable 
if every click generates new software.

And now back to drive-by-downloading, which is important because it is perhaps 
the source of the problem. All of this is happening, as we all know very well, 
because average users are willing to run software from any source, as long as 
it doesn't make their computer explode right away. They don't even understand 
the basic difference between downloading data versus downloading and executing 
an arbitrary algorithm. When a blog, or a news site, or a government website 
won't load because you didn't let it run an arbitrary algorithm on your 
computer, that's crazy, just crazy. And the norm. These users who leave all 
JavaScript on, they already buried 2 of their freedoms, and the boilerplate 
license on the disposable code can't change that. They need to be told to 
boycott sites which require JS to function, and to demand legislation which 
would require something like HTML+CSS web fronts from commercial and 
government entities. It is not at all helpful, in my opinion, to differentiate 
between varieties of JavaScript sources, because none of them should be 
downloaded in the first place. Most importantly, web masters who want a free 
web should stop using JavaScript, and they should be transitioning right now, 
and not stop until there's nothing left for LibreJS to mark as free. All 
desired JavaScript functionality can be trivially recreated via a combination 
of free browser plugins and calls to free and standard libraries. The drive-
by-download culture, on the other hand, will plunge us deeper into the sea of 
disposable software.

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU LibreJS won't be removed from GNU IceCat

[Ivan Zaigralin]

I think NoScript is an essential privacy+security tool with a feature set not 
fully replicated by icecat, so including it would not hurt anyone :)

It should be considered that LibreJS, which is enabled by default, is already 
intended to block all non-free JavaScript. So at least from the gnuzilla's 
point of view, all non-free JavaScript is already disabled, and there seems to 
be no danger in NoScript whitelisting some unsavory domains. The same 
consideration makes it theoretically unimportant to turn off the JavaScript 
completely via browser config.

However, LibreJS cannot possibly detect non-free software with any kind of 
reliability, and it is easy to argue that drive-by-downloads, which are un-
auditable by their very nature, are non-free no matter what license is 
attached to them. To wit, LibreJS will incorrectly mark an obfuscated piece of 
GPL-licensed code as free every time. So from the practical point of view, 
starting out with all JavaScript disabled is the way to go.

On Wednesday, February 21, 2018 23:04:48 Julie Marchant wrote:
> On 2018年02月21日 22:02, b...@iinet.net.au wrote:
> > Hmmm...If that'd be the case, is it well worth considering "NoScript"
> > and "HTTPS Everywhere" as part of the default extensions suite?
> 
> I still think shipping with JavaScript disabled entirely by default
> would be preferable. Perhaps add an extension with a "danger button"
> that allows all scripts on a particular page to run (like LibreJS's
> similar option, instead of being like what NoScript does).
> 
> Note regarding NoScript: it would have to be modified, since its default
> settings whitelist dozens of websites serving proprietary JavaScript
> code. Anyway, I wouldn't see much point.
> 
> --
> Julie Marchant
> https://onpon4.github.io

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] I am really getting sick of this. Goodbye

[Ivan Zaigralin]

On Sunday, March 19, 2017 19:34:28 awake...@tutanota.de wrote:
>> "Also, even the FSF supports building software for Windows." 
> yes yes and linux has systemd. truly imperfect world we live in.

awake...@tutanota.de, julie is making a pertinent point: no one was arguing 
with you in this forum for like 4 days now. You remark, on the other hand, is 
a classic troll. Also your reference to gamergate. This list is, ostensibly, 
for discussing issues with gnuzilla, such as bugs. A lot of the things you've 
been saying in the last few days are completely, factually offtopic.


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] I am really getting sick of this. Goodbye

[Ivan Zaigralin]

And I am getting more and more satisfied with icecat. I have critiqued the 
release schedule in the past, but I came to understand that developers need to 
strike a balance between upstream updates and downstream fixes, which are 
often just as important. And since I don't understand any of the technical 
issues facing them, I could as well shut up.

> The GNU project is about providing freedom to
> people who need it, not *deliberately* harming people's lives with insecure
> software just because they use closed-source OSes.

Lacking resources is what is happening, and you just called it "*deliberately* 
harming people's lives". Please consider contributing a binary window$ build 
or a build instruction manual, I am sure the project will accept them. I do 
believe icecat would be better than firefox on any os, and I suspect 
developers would agree. But I would also argue that the edge gained with 
icecat on window$ simply does not warrant an effort to provide it. I am afraid  
that it could also create a false sense of privacy, while no such thing exists 
in the window$ world.

Not worth developing, don't you agree, Daniel? It sounds like you, for one, 
have absolutely no time to contribute, so may be that's all that's happening. 
With more resources, I am sure it would still be provided.


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 45.7.0 release

[Ivan Zaigralin]

On Wednesday, March 15, 2017 19:23:24 Gary wrote:
> On Wed, Mar 15, 2017, Ivan Zaigralin wrote:
> > Here you go, pal. Section 7.b. You see where it says "computer
> > information"?
> 
> 7b states: "Microsoft may use the computer information, accelerator
> information, search suggestions information, error reports, and Malware
> reports to improve our software and services. We may also share it with
> others, such as hardware and software vendors. They may use the information
> to improve how their products run with Microsoft software."
> 
> But in 7a they also point out that "in some cases, you may switch off these
> features or not use them." Of course, if I were concerned I would turn
> these features off then block outbound connections to Microsoft, use an
> offline update utility like WSUSoffline, and not use Internet Explorer or
> other web services.

You can't turn them off. In some cases you can, which means absolutely 
nothing, since in other cases you cannot. Which other cases? All the ones you 
don't know about because they don't have to tell you jack.

> They *do* have the *capability* to get absolutely any information from your
> > computer, like real-time screenshots, keystrokes, or webcam feed. ... that
> > is, if you ever ever ever dectect the leak.
> 
> [citation needed]

Please do not take this the wrong way, but if you need a citation for this, 
then you must be missing on some really basic understanding of how a modern 
computer works. In short, micro$soft runs a mystery program on your pc, and it 
runs with the highest privelege afforded by your hardware (CPU, etc.). No one 
even *knows* what it does, let alone able to fully control it, besides 
micro$oft. Absolutely anything you can direct your computer to do from within 
window$, micro$oft can do remotely, surreptuously, and *trivially* in the 
technical sense. I would read on wikipedia about software, and then free 
software, and hopefully all of this will become obvious.


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 45.7.0 release

[Ivan Zaigralin]

No. But the difference between icecat and firefox on window$ is the difference 
between good rubber boots and leaky rubber boots, while crossing the ocean.

On Wednesday, March 15, 2017 22:23:01 Daniel Quintiliani wrote:
> So you would recommend most of the planet use Microsoft Edge then?
> 
> --
> 
> -Dan Q
> 
> On Thu, 16 Mar 2017 00:58:25 +0100 (CET),  wrote:
> > I totally agree, there is ABSOLUTELY NO REASON to use a slightly more
> > secure browser like icecate on ABSOLUTELY DISGUSTINGLY BACKDOORED BOTNET
> > surveillance, freedom and privacy destroying operating systems like those
> > of apple and microsoft. why? because there is no benefit. the levels of
> > disrespect that apple and microsoft have for user privacy (remember, they
> > are a part of the nsa spying cult known as PRISM) are so high that there
> > is no doubt in my opinion that any possible benefit to using icecat is
> > instantly reduced to nothing while using it on windows or mac.
> > 
> > Using icecat on windows or mac is like bringing a bucket of fresh water
> > with you everywhere you go because it has the salt removed and is more
> > secure against salt, and then going to the middle of the ocean and
> > expecting your freshwater to not get salty. I honestly believe that
> > everyone who suggests more hard work for those involved with icecat to
> > make it function on windows or mac are some kind of weirdos with hidden
> > intentions.> 
> > 14. Mar 2017 02:13 by m...@netris.org:
> > > "Daniel Quintiliani" <> d...@runbox.com> > writes:
> > >> Please reconsider your discontinuation of Windows and Mac versions, as
> > >> libre browsing is most needed in DRM-based OSes, not Linux :(
> > > 
> > > Please, let's not propose adding more work for Rubén.  Given that he's
> > > already too overloaded to produce IceCat releases in a timely fashion,
> > > and given the paramount importance of reducing the latency of IceCat
> > > security updates, I fully support his decision to reduce the amount of
> > > work associated with each release.  Let someone else volunteer to build
> > > binaries for Windows and Mac, if there's sufficient interest.
> > > 
> > >  Regards,
> > >  
> > >Mark
> > > 
> > > --
> > > http://gnuzilla.gnu.org
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat browser default on Windows 7?

[Ivan Zaigralin]

On Wednesday, December 28, 2016 21:37:31 Daniel Quintiliani wrote:
> I doubt Microsoft would risk taking screenshots of employee's computers at
> Fortune 500 companies. Do you know how dangerously illegal that is?

No, I do not. Please enlighten us. When was the last time a major tech company 
exec went to jail or prison over an obvious computer crime, like when $ony 
rooted millions of PCs? Was anyone ever indicted even? With their game 
consoles, Micro$oft routinely takes pictures of naked teenagers and sends them 
over the internet, without their knowledge or informed consent, what is up 
with that? Clearly, this is an invasion of privacy and an illegal porn 
production, so what is being done about it?

Please stop the nonsense. Your analogies are awful and misleading. if icecat 
is a band-aid, then you are asking us to put it on a brain tumor. Yes, I would 
refuse to distribute GNU-branded band-aids to brain tumor patients, while 
claiming they help, even though some may slap them on their foreheads and feel 
better due to a placebo effect. What these people need is an invasive, but 
life-saving operation. Once the windoze tumor is removed, it makes sense 
applying a band-aid.

Once again, I am not in principle against building icecat for nonfree 
platforms such as windoze, but please get a grip. It is next to useless. 
Either kindly contribute a build, or stop pestering the developers, who 
already have more work than they can handle.

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 45.5.1 release

[Ivan Zaigralin]

Thanks, that cured it :)

On Saturday, December 03, 2016 08:59:26 Marek Buras wrote:
> Hi Melikamp!
> 
> Ivan Zaigralin <melik...@melikamp.com> writes:
> > I am hitting the following snafoo when trying to build. I checked, and
> > this
> > unofficial/ folder does not exist:
> > 
> > /opt/SBo/icecat-45.5.1/browser/branding/unofficial/moz.build
> > 
> > Build script is also listed below.
> 
> I think what you need is:
> 
> @@ -134,6 +134,7 @@ OPTIONS="\
>--disable-installer \
>--disable-mailnews \
>--disable-composer \
> +  --enable-official-branding \
>--disable-profilesharing"
>  # Complains about missing APNG support in Slackware's libpng:
>  # --with-system-png \
> 
> It seems that GNU IceCat branding we get from the repository is the official
> one ;-)
> 
> Happy hacking!
> 
> PS. Thanks for maintaining the SlackBuild files and FreeSlack!
> 
> --
> Marek Buras
> cyfr0n (at) onet.pl
> 
> --
> http://gnuzilla.gnu.org

signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 45.5.1 release

[Ivan Zaigralin]

I am hitting the following snafoo when trying to build. I checked, and this 
unofficial/ folder does not exist:

/opt/SBo/icecat-45.5.1/browser/branding/unofficial/moz.build

Build script is also listed below.



js/src/ctypes/libffi> config.status: executing buildir commands
js/src/ctypes/libffi> config.status: skipping top_srcdir/Makefile - not 
created
js/src/ctypes/libffi> config.status: executing depfiles commands
js/src/ctypes/libffi> config.status: executing libtool commands
js/src/ctypes/libffi> config.status: executing include commands
js/src/ctypes/libffi> config.status: executing src commands

Reticulating splines...
Traceback (most recent call last):
  File "./config.status", line 1062, in 
config_status(**args)
  File "/opt/SBo/icecat-45.5.1/python/mozbuild/mozbuild/config_status.py", 
line 175, in config_status
definitions = list(definitions)
  File "/opt/SBo/icecat-45.5.1/python/mozbuild/mozbuild/frontend/emitter.py", 
line 165, in emit
for out in output:
  File "/opt/SBo/icecat-45.5.1/python/mozbuild/mozbuild/frontend/reader.py", 
line 1062, in read_mozbuild
raise bre
mozbuild.frontend.reader.BuildReaderError: 
==
ERROR PROCESSING MOZBUILD FILE
==

The error occurred while processing the following file:

/opt/SBo/icecat-45.5.1/moz.build

The underlying problem is we referenced a path that does not exist. That path 
is:

/opt/SBo/icecat-45.5.1/browser/branding/unofficial/moz.build

Either create the file if it needs to exist or do not reference it.

*** Fix above errors and then restart with\
   "make -f client.mk build"
/opt/SBo/icecat-45.5.1/client.mk:359: recipe for target 'configure' failed
make[2]: *** [configure] Error 1
make[2]: Leaving directory '/opt/SBo/icecat-45.5.1'
/opt/SBo/icecat-45.5.1/client.mk:373: recipe for target 
'/opt/SBo/icecat-45.5.1/obj/Makefile' failed
make[1]: *** [/opt/SBo/icecat-45.5.1/obj/Makefile] Error 2
make[1]: Leaving directory '/opt/SBo/icecat-45.5.1'
client.mk:171: recipe for target 'build' failed
make: *** [build] Error 2








build script starts here




PRGNAM="icecat"
VERSION=${VERSION:-45.5.1}
RELEASEVER="$VERSION"
RELEASEVERMAJ=$(echo $RELEASEVER | cut -f 1 -d .)
BUILD=${BUILD:-1}
TAG=${TAG:-_SBo}

if [ -z "$ARCH" ]; then
  case "$( uname -m )" in
i?86) ARCH=i486 ;;
arm*) ARCH=arm ;;
   *) ARCH=$( uname -m ) ;;
  esac
fi

CWD=$(pwd)
TMP=${TMP:-/tmp/SBo}
PKG=$TMP/package-$PRGNAM
OUTPUT=${OUTPUT:-/tmp}

if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS=""
  LIBDIRSUFFIX=""
  OPTIMIZE=" --enable-optimize=-O2 "
  # On IA32, use gold since GNU ld runs out of memory linking libxul.so:
  PATH="$(pwd)/gold:$PATH"
  export CC="gcc -B$(pwd)/gold"
  export CXX="g++ -B$(pwd)/gold"
elif [ "$ARCH" = "s390" ]; then
  SLKCFLAGS="-O2"
  LIBDIRSUFFIX=""
  OPTIMIZE=" --enable-optimize=-O2 "
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
  OPTIMIZE=" --enable-optimize=-O2 "
elif [ "$ARCH" = "arm" ]; then
  SLKCFLAGS="-O2 -march=armv4 -mtune=xscale"
  LIBDIRSUFFIX=""
  OPTIMIZE=" --enable-optimize=-O2 "
elif [ "$ARCH" = "armel" ]; then
  SLKCFLAGS="-O2 -march=armv4t"
  LIBDIRSUFFIX=""
  OPTIMIZE=" --enable-optimize=-O2 "
else
  SLKCFLAGS="-O2"
  LIBDIRSUFFIX=""
  OPTIMIZE=" --enable-optimize=-O2 "
fi

# workaround to prevent unidentified crashes on some cpus
OPTIMIZE="$(echo "$OPTIMIZE" | sed 's/O2/Os/g')"

# When it works, it builds much faster.
#NUMJOBS=${NUMJOBS:-" -j7 "}

set -e

rm -rf $PKG
mkdir -p $TMP $PKG $OUTPUT
cd $TMP
rm -rf $PRGNAM-$VERSION
tar xvf $CWD/${PRGNAM}-$VERSION-gnu1.tar.bz2
cd ${PRGNAM}-$VERSION

# https://bugzilla.mozilla.org/show_bug.cgi?id=1194520
sed -e '/^ftglyph.h/i ftfntfmt.h' \
  -e '/^freetype\/ftcache.h/a freetype\/ftfntfmt.h' \
  -i config/system-headers

chown -R root:root .
find -L . \
 \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
  -o -perm 511 \) -exec chmod 755 {} \; -o \
 \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
  -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;

# Our building options, in a configure-like display ;)
OPTIONS="\
  --prefix=/usr \
  --libdir=/usr/lib${LIBDIRSUFFIX} \
  --with-system-zlib \
  --enable-application=browser \
  --enable-default-toolkit=cairo-gtk2 \
  --enable-startup-notification \
  --enable-crypto \
  --enable-svg \
  --enable-canvas \
  --enable-logging \
  --enable-xft \
  --enable-webm \
  --enable-xinerama \
  $OPTIMIZE \
  --enable-reorder \
  --enable-strip \
  --enable-cpp-rtti \
  --enable-single-profile \
  --enable-pulseaudio \
  --disable-gnomevfs \
  --disable-ldap \
  --disable-accessibility \
  --disable-crashreporter \
  --disable-debug \
  --disable-pedantic \
  --disable-installer \
  --disable-mailnews \
  --disable-composer \
  --disable-profilesharing"
# Complains about missing APNG 

[Bug-gnuzilla] concerning voting & further directions

[Ivan Zaigralin]

This is just brain-storming, meant for comment only.

I am not convinced voting over a bunch of small initiatives would be very 
effective, at any rate, I will abstain for now.

I think before voting we need to have a consensus on the general direction as 
we are moving forward, which is not something we can solve with just applying 
the democracy. We've got some technical problems looming for a while now, and 
they need some love and care from the few people doing the actual work.

The terrible lag behind the upstream releases was recognized as an issue for a 
while now, and it feels to me that part of the problem is that modifications 
applied to the upstream are too invasive. May be we can separate this project 
into 2 distinct subprojects:

(1)

This one applies the minimal possible changes to the upstream in order to make 
it FSDG-compliant. I haven't looked very carefully, but if it's anything like 
building FSDG-compliant thunderbird, then may be the following would be 
enough:

(1.1) disable add-on page or replace it with a good page
(1.2) build without official branding
(1.3) add icecat branding, or leave it for (2)

(2)

Here we build the icecat proper, with all the extra privacy features. icecat 
branding can also be added at this stage, if it wasn't added earlier. I have 
nothing against putting the features inside addons, but I must insist the way 
it's being done right now is suboptimal. All these feature-imparting addons 
must be made in-house, have their own distinct namespaces, and should not 
replicate functionality provided by upstream addons. In particular, icecat 
signature addons should not prevent the user from installing and using any of 
the general-purpose ad-blockers, https enforcers, etc. If we close our eyes on 
its philosophical issues and bugs, LibreJS is how we do it right. spyblock, on 
the other hand, needs to go. The users should be able to choose whatever free 
ad blocker they want.

This two-pronged approach would insure that users and distributions are 
getting the security updates in a timely manner. And may be we can find a way 
for the additional features to be packaged separately, and updated 
independently?


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Build Spyblock from uBlock Origin

[Ivan Zaigralin]

Please do not take this as anything but constructive criticism. I fully 
understand how limited the
resources are, and I firmly believe that even in the present state icecat & 
most of the bundled
features are incredibly useful and effective. I am merely trying to point out 
some directions for
future development, once the resources are plentiful :)

I believe icecat should do something more drastic than simply switch the 
adblocker. Something
needs to change in the way features are added. It was a technical mistake to 
put core
functionality into an existing adblocker, just as it is far from ideal to 
bundle https everywhere.
This practice robs users of their freedom to choose addons, and it breaks 
icecat when it is
repackaged for inclusion into a distribution (maintainers have to choose 
between locking users
into a specific addon combination, or stripping addons, with both options 
clearly bad).

One cromulent way to include functionality is by producing own in-house addons, 
like LibreJS,
which minimize the interference with other addons by narrowing their function 
and keeping a
separate namespace.

Instead of writing features into an adblocker or httpser, these features need 
to be decoupled, so
that users are free choose among dozens of functional equivalents, without 
sacrificing the extra
privacy provided by gnuzilla code.

On Friday, September 23, 2016 09:48:36 Sedov Andrey wrote:
> Adblock Plus began to distribute advertising (Acceptable Ads Platform
> ) = Adblock Plus died. uBlock Origin
> is the only solution.
>
> 23.09.2016 08:56, David Hedlund пишет:
> > I think it is time to build Spyblock from Adblock Plus (ABP) to uBlock
> > Origin (uBO).
> >
> > Adblock Plus is as usually the most popular add-on on
> > addons.mozilla.org but have grow less popular over time, while uBlock
> > Origin is currently the 6th most popular add-on on addons.mozilla.org
> > and have grow more popular over time. uBlock Origin one of the fastest
> > trending add-on I've seen.
> >
> > uBO has dozens of features that's missing in ABP. For example uBO can
> > block popunders that ABP cannot.
> >
> > --
> > http://gnuzilla.gnu.org


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] [Slackbuilds-users] icecat 38.8.0 crashes

[Ivan Zaigralin]

I don't understand what exactly is "filthy" about a deblobbed mozilla browser. 
One reason it may be preferable to icecat is that it would track the upstream 
releases more closely, and we wouldn't have to sit on disclosed critical 
vulnerabilities for weeks or months. Moreover, anyone could still install 
gnuzilla addons, if they so desire, and get a similar functionality. I do not 
/really/ think this is preferable to icecat, but I would definitely consider 
both options carefully, and it's just nice to have options.

(By the way, there should probably be a way to download spyblock, but I don't 
see it in the list of addons.)

You know what's filthy? The internet is filthy. I understand the desire of 
gnuzilla project to protect users from non-free software, but a line has to be 
drawn somewhere. Kicking the non-free addon repo to the curb is a good thing, 
ans so is the default search engine choice. But one has to realize that at the 
end of the day a web browser is for accessing the web, and there is a 
looot of non-free software out there, and it's all accessible via a single 
web search, regardless of the engine. Should gnuzilla filter skype out of voip 
web searches? At some point we just have to trust the user to understand 
free/non-free software situation and not to be an idiot. icecat drew the line 
where it did, and a minimally deblobbed browser would draw it a few feet over, 
giving another viable option to users.

I really hope though that the icecat development will become more streamlined 
in the future, with more prompt releases, and we won't even have to discuss 
this issue.

On Thursday, August 18, 2016 18:50:14 awake...@tutanota.de wrote:
> sounds really nice, but why would we want to pass along such strongly
> minimalistic "un-de-freedomed" browsers along to the normal people
> specifically without added security features? this basically lands them
> back right where they started since they are immediately washed clean and
> then re-exposed to the filth of the world again. we have to help them but
> "here don't go alone, take this!" without security- without defense there
> is nothing worth defending.
> 
> --
> Securely sent with Tutanota. Claim your encrypted mailbox today!
> https://tutanota.com
> 
> 17. Aug 2016 04:35 by hjen...@gmx.de:
> > Hello,
> > 
> > On Tue, Aug 16, 2016 at 11:05:28AM -0700, Ivan Zaigralin wrote:
> >> Finally, I believe there is a niche opening up for a firefox-based
> >> browser
> >> which is libre and meets free software distrubution guidelines like
> >> icecat,
> >> but has no extra privacy features, and passes all the mozilla pearls onto
> >> the users. Such minimal deblobbing could be potentially more robust:
> >> that is, new releases could be churned out as quickly and reliably as
> >> linux-libre. Looking at Parabola's thunderbird & seamonkey builds, I
> >> imagine something like that could be done for firefox as well. Anyone
> >> can step in and claim the glory for this one :) I don't have time to
> >> write a slackbuild like that and run it by FSF, but if anyone did it, I
> >> think I would actually switch.
> > 
> > Parabola GNU/linux and ConnochaetOS have such a liberated mozilla based
> > Browser based an Debian's Iceweasel. Parabola's Iceweasel is based on
> > current Firefox, ConnochaetOS uses LTS.
> > 
> > https://www.parabola.nu/packages/libre/i686/iceweasel
> > 
> > https://connochaetos.org/slack-n-free/slack-n-free-14.2/xap/iceweasel-45.3
> > .0-i486-1_libre.txz
> > https://connochaetos.org/slack-n-free/source/src/iceweasel
> > https://connochaetos.org/slack-n-free/source/dist/slack-n-free-14.2/icewea
> > sel/iceweasel.SlackBuild
> > 
> > Regards,
> > 
> > Henry
> > 
> > 
> > 
> > --
> > http://gnuzilla.gnu.org


signature.asc
Description: This is a digitally signed message part.
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] [Slackbuilds-users] icecat 38.8.0 crashes

[Ivan Zaigralin]

Personally, I am somewhat unhappy about the gnuzilla update/security policy. 
The move to forties apparently is not happening because it breaks saved cookie 
preferences or something, but I have to question the wisdom of withholding 
fixes for remote code execution because of that.

Having said that, I think we need to take a few factors into consideration. 
First of all, it's not gnuzilla's fault firefox is so insequre, it's mozilla's 
fault. This browser has like a million holes in it, and may be the most 
updated package in Slackware. Lagging a few releases behind sucks, especially 
when the bugs are made public, but at the same time it looks like every 
firefox release in the last few years had terrible security holes in it, so I 
don't really feel that much safer using the latest version, and neither should 
you. If security is very important to a user, it may be prudent to switch 
browsers.

Also, gnuzilla has a mission and a goal, and mozilla is not making it easy. 
They keep putting more and more ugly stuff into firefox and changing the 
security policy, like with the cookies above, while gnuzilla team is committed 
to releasing a product which meets their rather high standards. As a volunteer 
effort, they've done great, and it would be completely unfair to chastise them 
for lagging behind mozilla, since gnizilla are not the ones breaking it it 
every release cycle. 

Finally, I believe there is a niche opening up for a firefox-based browser 
which is libre and meets free software distrubution guidelines like icecat, 
but has no extra privacy features, and passes all the mozilla pearls onto the 
users. Such minimal deblobbing could be potentially more robust: that is, new 
releases could be churned out as quickly and reliably as linux-libre. Looking 
at Parabola's thunderbird & seamonkey builds, I imagine something like that 
could be done for firefox as well. Anyone can step in and claim the glory for 
this one :) I don't have time to write a slackbuild like that and run it by 
FSF, but if anyone did it, I think I would actually switch.

On Tuesday, August 16, 2016 09:57:03 b...@shroggslodge.freeserve.co.uk wrote:
> Good morning
> 
> Having got latest Icecat building with the -Os switch, it seems there are
> some reports of [serious?] security issues with it.
> 
> Here is where I first read something:
> https://lists.gnu.org/archive/html/bug-gnuzilla/2016-08/msg0.html
> 
> And I have seen further discussion and consternation about what to do with
> Icecat and perhaps not using Firefox as base etc.  I'm really relatively
> only a 'user' so to speak, so I'm interested to know what others feelis
> there a serious security risk ?
> 
> I realise this is SBo and not an Icecat forum,  but I wonder what the
> contributors (and maintainer) on SBo feel about the reports being made;
> should it affect whether Icecat is on SBo if its known to be 'risky', or
> does it not matter, should comments be made [in the info] or is it up to
> anyone wanting to use it to be self-aware and generally any other comments
> to share.
> 
> If this list really is inappropriate for posts like this (whatever 'this'
> is), then just let me know.but I would be interested in what more
> knowledgeable people on SBo feel ?
> 
> 
> Thank you and good day to all.
> Habs
> 
> On 8 August 2016 at 23:16, <b...@shroggslodge.freeserve.co.uk> wrote:
> > hi there all
> > 
> > I have tried the -Os switch and it does appear to remedy the problem.
> > Icecat no longer crashes in the scenario(s) I have documented.
> > 
> > I wonder what the -O2 switch does differently to the -Os one.
> > 
> > So for now that does appear to be the 'fix'. Thank you all.
> > 
> > 
> > Habs
> > 
> > On 8 August 2016 at 20:36, Ryan P.C. McQuen <rya...@linux.com> wrote:
> >> On Monday, August 8, 2016, Ivan Zaigralin <melik...@melikamp.com> wrote:
> >>> I still can't replicate any crash whatsoever, even in places where
> >>> others
> >>> report them. However, Matt tells me that crashes went away after he
> >>> rebuilt
> >>> with -Os. He also mentioned he's got an AMD Phenom, whereas I am using
> >>> Intel
> >>> CPU, which may explain why I am unable to hit this snag.
> >>> 
> >>> I can certainly submit a fixed SlackBuild if there's a consensus -Os is
> >>> an
> >>> effective fix. Please let me know :)
> >> 
> >> Seems like that would be valid, since Slackware's own Firefox build was
> >> passing that for version 43, and only removed it for versions past 43:
> >> 
> >> (Changelog reference):
> >> 
> >> Wed Dec 23 22:44:58 UTC 2015
> >> a/lvm2-2.02.138-i586-1.txz: 

Re: [Bug-gnuzilla] [Slackbuilds-users] icecat 38.8.0 crashes

[Ivan Zaigralin]

I still can't replicate any crash whatsoever, even in places where others 
report them. However, Matt tells me that crashes went away after he rebuilt 
with -Os. He also mentioned he's got an AMD Phenom, whereas I am using Intel 
CPU, which may explain why I am unable to hit this snag.

I can certainly submit a fixed SlackBuild if there's a consensus -Os is an 
effective fix. Please let me know :)

> Slackware 14.2 64bit
> 
> Hello folks - I have been 'talking' on slackbuilds.org (SBo) about icecat
> 38.8.0, which I use, about a problem I came across with it crashing.
> 
> I've only noticed it when I was browsing the twitter.com website and more
> specifically only when navigating away from that site. There may be other
> situations of course.
> 
> Even more, it would seem it happens only when logged in to twitter
> account;  if not logged in, then no crash when navigating away.
> 
> Some contributors on SBo pointed out to me similar issues that they had
> found reported on other sites.
> 
> There has been some suggestion to build using a different parameter (with
> '-Os' instead of '-O2' i do not know what that does or how?) as a *work
> around*, but I have not tried it as yet.
> 
> As this issue has been around for a while it would seem and affected
> earlier releases too, is there any knowledge as to what it might be, as it
> seems Firefox does not appear to suffer the same problem from my experience?
> 
> I am sorry, but my skills do not allow me (yet) to provide the sort of
> detailed info that others produce, however there is a console output below,
> though relating to an earlier build of Icecat. It may be of some use.
> Hopefully just raising this issue as I found it, is enough to help others
> understand. If there is anything I can do (bearing in mind I use others'
> build scripts [SBo] for these things), please let me know.
> 
> If anyone has any info or if a bug report needs [re]creating, then how to ?
> 
> Peace and best wishes.
> Habs
> 
> console.error:
>   [CustomizableUI]
>   Custom widget with id loop-button does not return a valid node
> 
> 2016-08-06 08:08:01: range_map-inl.h:91: INFO: StoreRange failed, an
> existing range contains or extends higher than the new range: new
> 0x7f6ce0717000+0xbf798, existing 0x7f6ce05e3000+0x226168
> 2016-08-06 08:08:01: basic_code_modules.cc:70: ERROR: Module
> /usr/lib64/icecat-38.5.2/libmozsqlite3.so could not be stored
> 2016-08-06 08:08:01: range_map-inl.h:91: INFO: StoreRange failed, an
> existing range contains or extends higher than the new range: new
> 0x7f6ce0803000+0x2bc0, existing 0x7f6ce05e3000+0x226168
> 2016-08-06 08:08:01: basic_code_modules.cc:70: ERROR: Module
> /usr/lib64/icecat-38.5.2/libmozalloc.so could not be stored
> 2016-08-06 08:08:01: range_map-inl.h:91: INFO: StoreRange failed, an
> existing range contains or extends higher than the new range: new
> 0x7f6ce07dd000+0x1b860, existing 0x7f6ce05e3000+0x226168
> 2016-08-06 08:08:01: basic_code_modules.cc:70: ERROR: Module
> /usr/lib64/icecat-38.5.2/components/libdbusservice.so could not be stored
> 2016-08-06 08:08:01: range_map-inl.h:91: INFO: StoreRange failed, an
> existing range contains or extends higher than the new range: new
> 0x7f6ce06b+0x23720, existing 0x7f6ce05e3000+0x226168
> 2016-08-06 08:08:01: basic_code_modules.cc:70: ERROR: Module
> /usr/lib64/icecat-38.5.2/components/libmozgnome.so could not be stored
> 2016-08-06 08:08:01: range_map-inl.h:91: INFO: StoreRange failed, an
> existing range contains or extends higher than the new range: new
> 0x7f6ce068d000+0x222e0, existing 0x7f6ce05e3000+0x226168
> 2016-08-06 08:08:01: basic_code_modules.cc:70: ERROR: Module
> /usr/lib64/icecat-38.5.2/browser/components/libbrowsercomps.so could not be
> stored
> 2016-08-06 08:08:01: stackwalker.cc:125: INFO: Couldn't load symbols for:
> /lib64/libc.so.6|B6662863DCEBA13A731B3DA192D023DF0
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at 0x0
> 2016-08-06 08:08:01: stackwalker.cc:125: INFO: Couldn't load symbols for:
> /usr/lib64/icecat-38.5.2/libxul.so|41AD907282E15602EA526D1E50C673020
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at
> 0x7f6ccf736060
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at 0x5
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at
> 0x7f6cb5eb3700
> 2016-08-06 08:08:01: stackwalker.cc:125: INFO: Couldn't load symbols for:
> /usr/lib64/libglib-2.0.so.0|7D36F9F9E95A6CA6B68E20EA6ABFC1940
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at
> 0x7f6ccf736060
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at 0x5
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at
> 0x7f6cb5eb3700
> 2016-08-06 08:08:01: stackwalker.cc:125: INFO: Couldn't load symbols for:
> /usr/lib64/libglib-2.0.so.0|7D36F9F9E95A6CA6B68E20EA6ABFC1940
> 2016-08-06 08:08:01: basic_code_modules.cc:88: INFO: No module at
> 0x7f6cb98d7c00
> 2016-08-06 08:08:01: 

Re: [Bug-gnuzilla] IceCat 38.4.0 release

[Ivan Zaigralin]

Do you actually run out of memory? Check the disk space also, that thing
grows to many GiBs.

The memory bug seems to be x32-related (not just windoze though), and
apparently you can sidestep it by using gold:

# On IA32, use gold since GNU ld runs out of memory linking libxul.so
export CC="gcc -B$(path to)/gold"
export CXX="g++ -B$(path to)/gold"

or something along these lines. Never actually had to do anything like
that myself, and not at all sure this will fix anything.

Good luck :)

On 12/05/2015 01:08 PM, Dimitris Arvanitis wrote:
> Hallo!
> 
> Thank you. Unfortunately I am not able to compile it. It stops after
> some minutes, these are the last lines of output:
> 
> make[6]: Leaving directory
> '/tmp/compile/icecat-38.4.0/src/obj-x86_64-linux-gnu/dom/bindings'
> make[5]: Leaving directory
> '/tmp/compile/icecat-38.4.0/src/obj-x86_64-linux-gnu'
> /tmp/compile/icecat-38.4.0/src/config/recurse.mk:36: recipe for target
> 'compile' failed
> make[4]: *** [compile] Error 2
> make[4]: Leaving directory
> '/tmp/compile/icecat-38.4.0/src/obj-x86_64-linux-gnu'
> /tmp/compile/icecat-38.4.0/src/config/rules.mk:541: recipe for target
> 'default' failed
> make[3]: *** [default] Error 2
> make[3]: Leaving directory
> '/tmp/compile/icecat-38.4.0/src/obj-x86_64-linux-gnu'
> /tmp/compile/icecat-38.4.0/src/client.mk:398: recipe for target
> 'realbuild' failed
> make[2]: *** [realbuild] Error 2
> make[2]: Leaving directory '/tmp/compile/icecat-38.4.0/src'
> client.mk:171: recipe for target 'build' failed
> make[1]: *** [build] Error 2
> make[1]: Leaving directory '/tmp/compile/icecat-38.4.0/src'
> /usr/share/cdbs/1/class/makefile.mk:47: recipe for target
> 'debian/stamp-makefile-build' failed
> make: *** [debian/stamp-makefile-build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> There are some hits when searching the net, but no actual solutions. One
> analysis suggests it is due to memory limits, 8 GB of RAM would be
> necessary to successfully compile Firefox. But then again, this was only
> reported with 32 bit Windows. I am using a fully updated 64 bit Debian
> 8.2 with 4 GB RAM memory, and RAM is not even near limit when compiling
> aborts, swap is hardly touched.
> 
> Anyone got an idea? It is frustrating, I have yet to successfully
> compile an IceCat version of the 38 branch.
> 
> Dimitris
> 
> 
> 
> --
> http://gnuzilla.gnu.org
> 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 31.8.0-gnu2 release

[Ivan Zaigralin]

Is source available? Or at least a diff?

On 08/22/2015 02:46 PM, Rubén Rodríguez wrote:
> GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the
> GNU version of the Firefox browser. Its main advantage is an ethical
> one: it is entirely free software. While the Firefox source code from
> the Mozilla project is free software, they distribute and recommend
> non-free software as plug-ins and addons. Also their trademark license
> restricts distribution in several ways incompatible with freedom 0.
> https://www.gnu.org/software/gnuzilla/
> 
> The user manual pages are at http://libreplanet.org/wiki/Group:IceCat/
> You can contribute by joining the wiki and editing the manuals.
> 
> Source tarballs, binaries for generic GNU/Linux systems and translations
> are available at http://ftp.gnu.org/gnu/gnuzilla/31.8.0-gnu2/
> GPG key ID:D7E04784 GNU IceCat releases
> Fingerprint: A573 69A8 BABC 2542 B5A0  368C 3C76 EED7 D7E0 4784
> https://savannah.gnu.org/project/memberlist-gpgkeys.php?group=gnuzilla
> 
> == Changes since v31.8.0 ==
> 
>  * Applied patch for CVE-2015-4473 CVE-2015-4482 CVE-2015-4488
> CVE-2015-4489 CVE-2015-4491 CVE-2015-4492 CVE-2015-4495 from Guix
> 
> 
> --
> http://gnuzilla.gnu.org
> 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] I hope you can fix the spyblock bug. It isn't working atm.

[Ivan Zaigralin]

I got the following filters enabled:
* Block ... privacy trackers
* EasyList
* RuAdList+EasyList
* custom filter with https://soylentnews.org/images/neutral.gif;

The first three filters must be working to some extent, as I can see
stuff getting blocked on yahoo.com, for example. However, none of the
hit counters get updated, and my custom filter simply does not work,
although it used to before the last update or so.

On 07/27/2015 08:03 AM, Rubén Rodríguez wrote:
 El dom, 26-07-2015 a las 14:07 +, Zap escribió:
 Spyblock isn't persay blocking anything on icecat and I don't know why.
 
 What filters do you have set on it?



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Windows 8.1 Icecat Bug Report

[Ivan Zaigralin]

Narcis, I am a bit confused by your apparent confusion, even as you seem
to be providing a Win32 binary.

What I want to say here is my strictly personal opinion, and it does not
represent the views of other people associated with this project, nor
those of any organizations I happen to be affiliated with.

I believe that Gnuzilla providing support for either Win32, OS X, or any
commercial mobile platform is a mistake because it is a total waste of
the development resources. The following argument would also work for
any platform which spits on (user) privacy and security.

Sometimes it makes sense to provide free software on a non-free
platform, especially when it replaces a non-free app (e.g. libreoffice),
or has no non-free equivalent (e.g. LaTeX). But is there a point at all
in providing something like IceCat? Its only differences from the stock
Firefox focus on privacy and security, which the users of non-free
platforms already gave up completely. Giving a Windoze user IceCat is
like giving a pillow to a man who jumped from the roof of the Empire
State. Technically speaking, it will soften the blow, but in practice
it's just dead weight. When compatibility issues are taken into account,
there is basically no advantage over the stock Firefox.

This issue reminds me of a lengthy rant I left on the TOR dev list,
accusing them of, well, incompetence (since I didn't want to assume
malice right away) for providing Windoze binaries. This was right after
the big dragnet closed on the drug stores, with (allegedly) hundreds of
secret services and users unmasked. I argued that giving Windoze users
TOR is not just useless, but counterproductive, since it gives a
completely false sense of anonymity where there is absolutely none. As a
matter of fact, it would be trivial for the law enforcement to update
Windoze to report and/or poison all local TOR activity, and by now it
has probably been done.

IceCat for Win32 is definitely not in the same incompetence category,
but unless a case can be made for why it has anything on Firefox in that
environment, I'll keep calling it a waste.

On 07/12/2015 11:19 AM, Narcis Garcia wrote:
 I'm trying to install icecat on Windows 8.1 
 
 WHY ?!
 
 
 El 12/07/15 a les 13:42, John ha escrit:
 I'm trying to install icecat on Windows 8.1

 Steps to produce bug:
 1Download 31.7.0 win32 zip file
 2Extract with 7zip
 3Navigate to the directory *\icecat-31.6.0.en-US.win32\icecat
 4Run icecat.exe as administrator
 Result:
 1My mouse will have a hourglass symbol and I'm able to find
 icecat.exe in task manager for 1 second
 2Normal cursor returns and icecat isn't found in taskmanager. There
 is no trade of me ever having tried to run icecat.exe

 I've tried running in various Windows comparability modes and version
 31.6.0. I still get the same result.


 -- 
 http://gnuzilla.gnu.org
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] DuckDuckNo

[Ivan Zaigralin]

I still think startpage.com (ixquick) is better, what with being
European, audited (allegedly), and an aggregator (so way better results
than DDG, which borders on useless, imo). But lately I think none of the
centralized search engines deserve to be suggested. How about a
Wikipedia box instead :) ? I would let the user pick her own web spy...
er, search engine. Just a thought.

On 04/30/2015 07:57 PM, David Englund/Hedlund wrote:
 DDG is apparently hosted by Verizon, a company guarded by the NSA -
 http://etherrag.blogspot.se/2013/07/duck-duck-go-illusion-of-privacy.html
 
 -- 
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 31.6.0 release

[Ivan Zaigralin]

Looks like the profile dir reverted to ~/.mozilla/icecat. Is that
intentional, a bug, or did I screw up the build somewhow?

On 04/03/2015 03:25 PM, Rubén Rodríguez wrote:
 GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the
 GNU version of the Firefox browser. Its main advantage is an ethical
 one: it is entirely free software. While the Firefox source code from
 the Mozilla project is free software, they distribute and recommend
 non-free software as plug-ins and addons. Also their trademark license
 restricts distribution in several ways incompatible with freedom 0.
 https://www.gnu.org/software/gnuzilla/
 
 The user manual pages are at http://libreplanet.org/wiki/Group:IceCat/
 You can contribute by joining the wiki and editing the manuals.
 
 Source tarballs, binaries for generic GNU/Linux systems and translations
 are available at http://ftp.gnu.org/gnu/gnuzilla/31.6.0/
 GPG key ID:D7E04784 GNU IceCat releases
 Fingerprint: A573 69A8 BABC 2542 B5A0  368C 3C76 EED7 D7E0 4784
 
 == Changes since v31.5.0 ==
 
 Other than applying the upstream fixes listed here
 https://www.mozilla.org/en-US/security/known-vulnerabilities/firefox-esr/
 the only change for this release is the removal of the CNNIC root
 certificates, as explained at
 http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
 https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate
 
 
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] No Flash - Proposed being part of IceCat

[Ivan Zaigralin]

Actually, it may help the user if the addon checkboxes both named the
corresponding addons and described their basic functions (not just the
privacy implications).

And props on no-JS box :) I have to say, this menu is an excellent
feature overall.

On 03/21/2015 03:54 PM, Ivan Zaigralin wrote:
 Also, SpyBlock should probably be described better here (that it blocks
 ads, etc.)
 
 Also, video addon should probably be added to that checkbox list.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] SpyBlock Wikipedia centralNotice

[Ivan Zaigralin]

On 03/10/2015 06:57 PM, David Englund wrote:
 Please add `wikipedia.org##div#centralNotice' to
 http://gnuzilla.gnu.org/filters/
 
 This hides the centralNotice element used by Wikipedia to display
 donation requests.

AdBlock people do adblock, filter people do filters, and icecat people
do nothing but package the stuff. Doing it any other way would subvert
the purpose. If you are not happy with EASYLIST or whatnot, complain to
them please, or add your own custom filter.

 Wikipedia needs to stop begging for donations and start implementing
 ads
 -
http://www.zdnet.com/article/wikipedia-needs-to-stop-begging-for-donations-and-start-implementing-ads/

This is just creepy, dude. But anyway, please don't troll here, take it
outside:

https://en.wikipedia.org/wiki/Wikipedia:Funding_Wikipedia_through_advertisements




signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] ads on wikipedia

[Ivan Zaigralin]

On 03/10/2015 09:07 PM, David Englund wrote:
 I'm not trolling. Even Wikimedia Foundation's former exec complained
 about their fundraising -

http://www.theregister.co.uk/2013/10/08/wikipedia_foundation_money_in_wrong_place/

This whole subject is completely outside of this mailing list, that's
all. There is no reason to bring this up here. Even with our best effort
to address this issue, we cannot do anything about it here. This list is
for icecat-related issues. This is the very definition of trolling. I
will not reply to any more queries about this subject.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] A need of a paradigm shift for solving the JavaScript Trap

[Ivan Zaigralin]

Please forgive the length and rantiness of my reply. Please understand
that I admire the effort that went into creation of LibreJS, and I hope
that many people will find it useful or at least enjoy it. Here I only
argue the merits of its inclusion by default in icecat. If you see me
yell, it's only because I care that much.

On 10/26/2014 06:37 PM, Julian Marchant wrote:
 I highly appreciate what LibreJS is trying to do, and it's better than
 nothing. But I seriously think that LibreJS is entirely the wrong
 approach to the problem of non-free JavaScript.

I completely agree with every part. However, I am also willing to argue that
LibreJS is not effective, efficient, or even high enough quality to force it
upon the users of icecat. By force I mean only what is being done right
now, and I know we can disable it (I did).

It being low quality is of the least concern to me, and my assessment is
based on my very modest exposure and the fact that one very rude user of
my Slackware package yelled at me. In fact, I care so little that I am
willing to yield on this front without fighting. However, I want to
mention a rather spotty record, with questionable UI choices (animation,
in-page display) and things just plainly not working. I can't really see
any tabs at the moment, and when I can, they are in the bottom of the page
for some reason. But once again, forget it, the real issue is ahead.

 Right now, LibreJS is failing because it requires a format that isn't
 recognized anywhere, but theoretically, this could be solved in the
 future, so let's suppose that it does. Let's suppose even further that
 LibreJS succeeds so much that it causes a large portion of the Web to
 release scripts under libre licenses and document the licenses in a
 format LibreJS can understand.

 So LibreJS is popular, and people are labeling their scripts and
 linking to source code. But people are still behaving the same as
 before, blindly trusting several JavaScript programs that are silently
 being installed into their browsers every day. The only difference is
 that LibreJS thinks the scripts are libre. These are still scripts
 that are updated automatically, basically completely unaudited, and
 never edited by anyone.

Read the last paragraph very carefully please, for it is very insightful.
The biggest problem with LibreJS is that it's painfully, systemically
ineffective. It is based on the false premise that the user agent checks whether
the code is free; on an explicit (and false) assumption that the presence
of some boiler-plate is equivalent to freedom. But false positives are
both incurable and unavoidable; even a slightly obfuscated code is already
non-free. And false negatives are just as enraging. For example, look at the
ENTIRE javascript code on my website:

var showAnswersP = 0;
function toggleAnswers() {
if (showAnswersP == 1){
var arr = document.getElementsByClassName(hidden-answer);
for (i = 0; i  arr.length; i++) {
arr[i].style.display = none;
}
showAnswersP = 0;
} else {
var arr = document.getElementsByClassName(hidden-answer);
for (i = 0; i  arr.length; i++) {
arr[i].style.display = block;
}
showAnswersP = 1;
}
}

This is not even copyrightable, and is trivial in every sense of the word,
yet detected as non-free. NoScript is in fact better at what LibreJS is trying
to do than LibreJS. With NS, a user can check whether the source serves free
software, and then white-list that source. And when a user whitelists, say,
fsf.org, it makes sense to load all scripts from there. White-listing is
justified not because of some boiler-plate, but because user trusts the
software source, the FSF, to serve javascript that is actually, practically
free in all four senses of that word.

And we are just scratching the surface of the problem. Read it again,
for Julian said it in the best way possible:

 But people are still behaving the same as before, blindly trusting several
 JavaScript programs that are silently being installed into their browsers
 every day.

This is the root of all evil: users are habituated to drive-by downloads
from sources unknown. If you think about it long enough, you will realize
that javascript itself is the problem. Users who value their freedom browse
with javascript off, and web designers who value users' freedom SHOULD NOT
USE javascript AT ALL unless they complement it with a commitment to audit,
document, and publish all source in a timely manner.

 I get that LibreJS is supposed to be only a first step, but I think
 it's the *wrong* first step. I think we need an entire paradigm shift
 in how we deal with the problem of JavaScript code, one which involves
 not automatic script analysis, but direct user intervention.

Again, spot on. And I will tell you right now what the solution is. It is
very simple, but you will probably think I am crazy simply because you got so
used to javascript. The said 

Re: [Bug-gnuzilla] IceCat 31.2.0 Links Don't Load Or Slow

[Ivan Zaigralin]

Have you tried safe mode?
$ icecat -safe-mode

On 10/31/2014 02:21 PM, E R wrote:
 Hello,
 
 On Slackware 14.1 x86_64 running IceCat 31.20 I noticed links didn't
 load or were very slow compared to Firefox  QupZilla.
 
 I tested this over several times on all three borwsers and IceCat
 consistently showed it either wouldn't load a site when clicking a
 link, or load slow compared to the other two browsers.
 
 I tested this on a fresh install of IceCat after I just compiled and
 installed it.
 
 The addons enabled by default were left untouched on default settings.
 
 One example of this problem I noticed was when I typed in 'cnn' in the
 search Home page provided by IceCat for DuckDuckGo, after the page
 loaded, then I clicked on the cnn link and cnn would never load. I
 tested this playing with addons enabled and disabled, it made no
 difference, I tried this for 30 minutes, but cnn would never load when
 clicking the link on DuckDuckGo.
 
 I thought there might just be a search engine problem, but as soon as
 I tested this on Firefox  QupZilla cnn loaded immediately.
 
 I noticed in general, for any website, either typing the URL in the
 address bar, or clicking a link on a search engine, I tested both
 DuckDuckGo and Google, the results were the same, some sites didn't
 load or were very slow.
 
 I'm not sure what's causing this, but it makes the browser not
 productive at all to use...
 
 Cheers
 Mii
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 31.2.0 release

[Ivan Zaigralin]

Simply superb, thanks!

On 10/21/2014 08:14 AM, Rubén Rodríguez wrote:
 GNUzilla is the GNU version of the Mozilla suite, and GNU IceCat is the
 GNU version of the Firefox browser. Its main advantage is an ethical
 one: it is entirely free software. While the Firefox source code from
 the Mozilla project is free software, they distribute and recommend
 non-free software as plug-ins and addons. Also their trademark license
 restricts distribution in several ways incompatible with freedom 0.
 https://www.gnu.org/software/gnuzilla/
 
 Source tarballs, binaries for generic GNU/Linux systems and translations
 are available at http://ftp.gnu.org/gnu/gnuzilla/31.2.0/
 New gpg key ID:D7E04784 GNU IceCat releases
 Fingerprint: A573 69A8 BABC 2542 B5A0  368C 3C76 EED7 D7E0 4784
 
 This is a new iteration of the IceCat project, based on new build
 scripts and with an extra focus on privacy.
 The new maintainer is Ruben Rodriguez.
 
 IceCat will continue to stick to the ESR (Extended Support Release)
 cycle (https://www.mozilla.org/en-US/firefox/organizations/faq/) because
 it provides security updates over a stable base. That will also allow to
 port privacy features from TorBrowser, which is now following v31ESR.
 
  == Changes since v24 ==
 
  * Javascript can be disabled through the configuration interface.
  * Third party cookies are disabled.
  * Referrers are spoofed (to the same server where the file lives).
  * The user is not asked to install plugins (such as flash or java).
  * Only free software gets offered by IceCat.
  * Installed plugins (flash, java) require per-site activation.
  * DuckDuckGO as default search engine, through https and without JS.
  * DoNotTrack header enabled.
  * Reporting features disabled (Avoids send data to mozilla's partners 
about crashes or security related events).
  * Disabled Social API that brings integration with Facebook.
  * Disabled Safe browsing, which asks Google if websites are safe 
before browsing them.
  * Disabled access to the clipboard from JS.
  * Don't recommend online services for IRC.
 
 Preinstalled add-ons:
 
  * LibreJS 6.0.1 checks for the freedom of the javascript you run
  * HttpsEverywhere 4.0.2 redirects requests through https when possible.
  * Spyblock, custom made and based on AdblockPlus, provides:
- A blacklist of trackers that is used in any browsing mode.
  Self-served, privacy-friendly advertising is preserved.
- A filter for all third-party requests while in private browsing.
- A filter for javascript data retrieval while in private browsing.
- Autoupdate for filter lists is optional.
  * A custom homepage lists this and other features with links to 
documentation and the possibility to disable them quickly if needed.
 
 Fingerprinting:
 
  * Spoofing the useragent to:
- Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Firefox/31.0
  * Fonts can be listed with this methods:
- Plugins like java or flash: these are disabled by default in
IceCat, requiring the user to enable them in a per-site basis. Also 
Gnash doesn't work for fingerprinting.
- JS probing: the custom homepage allows to disable custom fonts.
  * Plugins: IceCat no longer discloses the list of installed plugins.
  * Extra spoofing: appname, appversion, buildID, oscpu and platform.
  * Request pages in english by default.

 To Do:
 
  * Add the needed documentation at libreplanet (volunteers welcome!):
- http://libreplanet.org/wiki/Group:IceCat/
- http://libreplanet.org/wiki/Group:IceCat/icecat-help
- http://libreplanet.org/wiki/Group:IceCat/Tour
- http://libreplanet.org/wiki/Group:IceCat/keyboard-shortcuts
  * Incorporate patches from TorBrowser 4.0
  * Build binaries for Windows and MacOS
 
 
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Compiling Icecat-24

[Ivan Zaigralin]

I have no idea really, but may be this is related:

From the Slackware build script for firefox:

if [ $ARCH = i486 ]; then
  SLKCFLAGS=
  LIBDIRSUFFIX=
  OPTIMIZE= --enable-optimize=-O2 
  # On IA32, use gold since GNU ld runs out of memory linking libxul.so:
  PATH=$(pwd)/gold:$PATH
  export CC=gcc -B$(pwd)/gold
  export CXX=g++ -B$(pwd)/gold

On 10/07/2014 11:46 PM, Narcis Garcia wrote:
 Memory exhausted was the result for me too, when trying to compile in
 a 32-bit system with 16GiB of RAM.
 Probably it wasn't a memory problem.
 
 
 El 13/09/14 a les 08:22, Michał Masłowski ha escrit:
 Hi, when compiling Icecat-24 I have four times done
 './configure' successfully
 but always failed at the end of 'make' with error msg

 /usr/bin/ld: final link failed: Memory exhausted
 [...]
 My system has 3.1 Gb memory and I have tried to minimise
 memory load. 

 It's a 32-bit system?  The problem is amount of virtual memory, not RAM,
 assuming you have several gigabytes of swap.

 Possible solutions:

 - cross compile on a 64-bit system with more memory/swap

 - compile with -Wl,--reduce-memory-overheads and/or
   -Wl,--no-keep-memory: makes linking slower, but might fit in memory
   (there are also some other options that reduce resource usage at cost
   of the built binary's speed)

 - compile with the -g0 option, disable debug symbols: will make the
   resulting build impossible to debug, but will vastly reduce its size

 You can easily find what compiler flags are used by the Icecat build
 system.  Looking for values like -O2 or -g in scripts and makefiles
 should help; I think it didn't trust the user-supplied options.

 I had the same issue when linking WebKit with debug symbols on MIPS N32
 (64-bit registers, 32-bit pointers: only 2 GiB of virtual memory).
 Linking without debug symbols worked, while it wasn't useful when the
 binary crashed deep in WebKit code (memory alignment issue: it enabled
 alignment required by any MIPS on O32 only).  With the above linker
 flags and debug symbols, linking took 17 minutes (1 GiB of RAM, a
 gigabyte of swap used), while it worked.  I think Icecat enables debug
 symbols by default.



 --
 http://gnuzilla.gnu.org

 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 31.1.1 pre-release announcement

[Ivan Zaigralin]

Thanks a bunch, Rubén :) It looks like it's a complete success on
Slackware x64. Switching to ESR was a great decision, IMHO.

On 10/07/2014 11:54 PM, Narcis Garcia wrote:
 It's a very good news that Ruben is taking care of the IceCat project.
 I'm a bulk desktops installer, and this year I had the Gnuzilla packages
 installation completely abandoned.
 
 I hope that can set this internet suite (or only web browser) as default
 for next users.
 
 
 
 El 08/10/14 a les 01:56, Rubén Rodríguez ha escrit:
 After many small changes and improvements I managed to produce a new
 release for IceCat, available (by now) here:
 http://gnuzilla.gnu.org/releases/31.1.1/

 I'd like to get some testing and feedback before doing the official
 release, also to get time to update the documentation.

 Some notes:

 - It is based on Firefox 31 ESR. I decided to stick to the ESR upstream
 releases (https://www.mozilla.org/en-US/firefox/organizations/faq/)
 because they provide security updates over a stable base. This way we
 won't have to fight with changes in the APIs we base our features on.
 That will also eventually allow to port privacy features from
 TorBrowser, which is being upgraded to follow v31 ESR too.

 - To filter privacy trackers I modified Adblock Plus to allow filter
 subscriptions to be optionally enabled during Private Browsing mode. I
 did some other small changes, along with removing the acceptable ads
 pseudofeature. Because of all this I decided to rebrand the extension to
 Spyblock, to avoid confusion with the upstream project.
 I also set custom lists at http://gnuzilla.gnu.org/filters/ and I made a
 point of preserving self-served advertisement, as the goal is not to
 block ads but to preserve privacy. That's another reason for rebranding.

 - I compiled binary packages for GNU/Linux using Trisquel 6, both for 32
 and 64 bit. Those binaries should work in most recent distros. These are
 the ones I'm more certain that should work: Trisquel 6 and 7, Ubuntu
 Precise or newer, Debian Wheezy, testing and sid. Please test in other
 distros and send reports of success and any bugs you find.

 - Video in h264 format (youtube, vimeo...) only shows a black screen in
 my machines, but so do the precompiled Firefox bundles, so I guess they
 need to be compiled in a less portable way for that feature to work.
 It seems to work when packaged for Trisquel.

 - Packagers are welcome! We want to get the package in other distros and
 also compiled for MacOS and Windows.

 Happy testing!


 --
 http://gnuzilla.gnu.org

 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat searche engines : free software, my foot!

[Ivan Zaigralin]

FYI, people, startpage.com is what TOR bundle is using as default.
They really seem to be benign.

https://en.wikipedia.org/wiki/Ixquick

On 03/12/2014 10:45 AM, f...@futuremotion.biz wrote:
 
 or startpage.com
 
 On 2014-03-12 10:41, Solal wrote:
 Default search engine : Google. Er...
 For an browser which have the goal to be entirely ethical and free, YaCy
 or DuckDuckGo is better.

 -- 
 http://gnuzilla.gnu.org
 
 -- 
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

[Bug-gnuzilla] Alternative for about:home search engine

[Ivan Zaigralin]

There is this neat-looking search engine:

www.startpage.com

It's exceptionally privacy-respecting, and it's meta, relying
primarily on Google results. I much prefer it to duckduckgo.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU IceCat 24.0 released!

[Ivan Zaigralin]

Hi! Does gnuzilla.gnu.org actually collect the health reports?
I am curious to know what's in them :)

https://www.mozilla.org/en-US/legal/privacy/firefox.html#health-report




signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 24.0 released (Loic J. Duros)

[Ivan Zaigralin]

Removing a library is not an option for me. I noticed that ./configure
succeeds if I only comment out

ac_add_options --with-system-jpeg

I wonder, is there a downside? Am I loosing functionality or
taking a performance hit?

On 10/19/2013 06:47 AM, Fernando de Oliveira wrote:
 Em 19-10-2013 01:14, Ivan Zaigralin escreveu:
 On 10/18/2013 11:59 PM, Adam Bogacki wrote:
 #error Insufficient JPEG library version (62
 required).
 This is the portion that fails in my Slackware build, even though
 /usr/include/jpeglib.h says
 #define JPEG_LIB_VERSION  80/* Version 8.0 */
 
 Is this jpegsrc or libjpeg-turbo? It has been about 9 months that FF
 build is know to fail with former, needs the latter. Problem is that
 jpegsrc (only version 8, not earlier versions) needs to be removed,
 *before* installing libjpeg-turbo. This one needs to be configured with
 --with-jpeg8 switch.
 
 http://www.linuxfromscratch.org/blfs/view/svn/general/libjpeg.html
 
 http://wiki.linuxfromscratch.org/blfs/ticket/3765
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 24.0 released (Loic J. Duros)

[Ivan Zaigralin]

Sounds great, thanks :)

On 10/19/2013 09:36 PM, Fernando de Oliveira wrote:
 Em 19-10-2013 20:10, Ivan Zaigralin escreveu:
 Removing a library is not an option for me. I noticed that ./configure
 succeeds if I only comment out

 ac_add_options --with-system-jpeg

 I wonder, is there a downside? Am I loosing functionality or
 taking a performance hit?
 
 In this case, I would leave it commented out. Do not know which libjpeg
 version is shipped with IceCat (or FF), but I guess the only downside
 would be some increase in the size of the binaries.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] IceCat 24.0 released (Loic J. Duros)

[Ivan Zaigralin]

On 10/18/2013 11:59 PM, Adam Bogacki wrote:
 #error Insufficient JPEG library version (62
 required).
This is the portion that fails in my Slackware build, even though
/usr/include/jpeglib.h says
#define JPEG_LIB_VERSION  80/* Version 8.0 */



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

[Bug-gnuzilla] feature request: disable torch thingy

[Ivan Zaigralin]

Hi! I would love to start using the LibreJS extension, specifically to
complain in writing :) But the sliding torch thingy is too annoying.
Is it possible to move it out of the webpage area? Ideally, this info
should be available in a toolbar button pop-up. An option to switch
between the two modes would be great.

Please, let me know if you like this idea. I am a total newbie when it
comes to JS and mozilla plugins, but I'd like to try and write a patch :)



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Segfault on IceCat when visiting specific website

[Ivan Zaigralin]

Looks fine to me, even after disabling noscript and adblock.
I don't have a flash machine, though, and the page has some flash.

On 06/25/2013 08:09 PM, Rodrigo Pimentel wrote:
 Hello everyone,
 
 I recently migrated from Firefox to IceCat. However, IceCat experiences
 a segfault whenever I go on this specific website:
 thewyldkatzclan.enjin.com 
 
 This has not occurred on any other website. Here is the output:
 https://ezcrypt.it/X56n#0W4kTeyY65qHJwWvlni58RQu
 
 Thank you,
 Rodrigo P. 
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] [gnu.org #829168] GNUzilla and IceCat for Windows?

[Ivan Zaigralin]

On 05/10/2013 05:44 PM, Jason Self wrote:
 One aspect of being a free program is being able to distribute verbatim
 copies (as you received it) commercially, under freedom 2. I cannot go to
 http://www.mozilla.org/ and download Firefox (or Thunderbird for that matter)
 and do that.

On the contrary: https://www.mozilla.org/foundation/trademarks/faq.html

 If you are redistributing unchanged official stable binaries downloaded from
 mozilla.org, to anyone in any way and for any purpose, no further
 permissions are required from us.





signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Bug report

[Ivan Zaigralin]

On 12/06/2012 05:39 AM, Sognametal wrote:
 If I disable the Shockwave Flash plugin, GNU IceCat doesn't crashes, but with
 this plugin active it crashes systematically.
 But, I don't understand why it crashes only on this page (
 https://particuliers.societegenerale.fr ).

May be that's because it links to this file?

https://static.societegenerale.fr/pri/PRI/Repertoire_par_type_de_contenus/Type_de_contenu/Communication/Home_page/bandeau/2012/03_decembre_2012/Grand_Jeu_Visa/n2g_Grand_Jeu_Visa.swf

I find it rather strange that you use Flash with icecat. Freedom is icecat's
only advantage over firefox. If you insist on using icecat, you could as well
give Gnash a try.

https://en.wikipedia.org/wiki/Gnash



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Free Software Add-on for IceCat

[Ivan Zaigralin]

I wouldn't call ABP malicious. Rather, it comes with malicious
defaults, but a benign configuration is one check-box away.
I am willing to concur with Sam Geeraerts: it's not a big deal
if it stays.

On 10/22/2012 12:00 PM, Loic J. Duros wrote:
 Hi:
 
 As mentioned before, the primary criterion is software freedom. Of course, we
 also care about privacy, and in fact it is one of my main focuses for the next
 release on IceCat.
 
 I think that as long as the extension provides a checkbox to stop allowing 
 these
 whitelisted ads, the user still gets a choice, and because it is released 
 under
 the MPL2.0, users can also just fork the addon and make their own, without 
 this
 particular functionality or any other.
 
 Of course we can list the two variants along with the original. As I stated
 earlier, I'm building a new interface for the addon list. Unfortunately, the 
 GNU
 webmasters and sysadmins don't want to set up an MVC on the main server, and 
 so
 I'm building a dynamic addon page entirely in (free) JavaScript for this
 purpose. In the backend (which I'm afraid will have to run from another 
 server,
 such as my own) it will automatically generate lists of free addons, and 
 perform
 a rudimentary file check for license notices, and provide updated data. I 
 guess 
 we could blacklist those free addons that are perceived as malicious. I'm not
 sure it's the case for ABP since I don't use it, but I'll take a closer look 
 at it.
 
 Thanks,
 
 
 
 On 10/21/2012 11:26 AM, Ivan Zaigralin wrote:
 What you are saying makes sense, and I definitely think this
 is a borderline case. Still, I think APB is distributed with
 a malicious feature turned on by default. There are forks which
 have the malicious feature removed, such as Adblock Lite and
 Trueblock Plus. At the very least, they should be listed
 alongside ABP. But then why have ABP at all? It is strictly
 inferior to its forks, so there is now a redundancy issue.

 Than being said, your explanation made me reconsider my position
 and I won't advocate removal anymore.

 On 10/21/2012 05:55 AM, Sam Geeraerts wrote:
 Ivan Zaigralin wrote:
 Adblock Lite is MPL. It has the Adblock Plus' current feature set
 with the old (pre-2) interface. The main difference is the absence
 of Allow Some Ads option, which is enabled by default in Adblock
 Plus. In an ironic twist of fate, Palant sold out to advertisers :)
 While the code of ABP is still free, IMHO, it should be removed
 because its default settings are designed to abuse the user, and
 replacements are available.
 The criterion for inclusion in the Gnuzilla list is software freedom. If
 extensions are barred for other reasons, then the purpose of the list 
 becomes
 less clear. There are also extensions in the list that facilitate the use of
 Google and other websites/services that have raised privacy concerns. With 
 the
 current policy they could only be excluded if you'd argue that they 
 encourage
 the use of websites that require running non-free Javascript.

 That being said, the Gnuzilla project does pay attention to user privacy. 
 Loic
 could choose to add that as a second criterion for the list (with the
 aforementioned risk). Another option is to add warnings to the list. That 
 still
 requires that every extension be checked for privacy issues, because it
 shouldn't be that no privacy warning could also mean that it hasn't been
 checked. So it would take more work to get (certain types of) extensions on 
 the
 list, making people less inclined to submit them. And like with SaaS, it's 
 not
 always clear cut whether something crossed the line. I'm not opposed to the 
 idea
 per se, though. :)

 Anyway, I'm not sure ABP's default settings are even a privacy issue. And 
 if I
 recall correctly, it does explicitly give users the choice to disable the
 whitelist when it's installed.






 --
 http://gnuzilla.gnu.org
 
 
 
 --
 http://gnuzilla.gnu.org
 





signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Free Software Add-on for IceCat

[Ivan Zaigralin]

bookmark favicon changer is GPL V3, with all non-trivial source files
carrying the license notice and a file with the license text present.
https://addons.mozilla.org/en-us/firefox/addon/bookmark-favicon-changer/



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Free Software Add-on for IceCat

[Ivan Zaigralin]

What you are saying makes sense, and I definitely think this
is a borderline case. Still, I think APB is distributed with
a malicious feature turned on by default. There are forks which
have the malicious feature removed, such as Adblock Lite and
Trueblock Plus. At the very least, they should be listed
alongside ABP. But then why have ABP at all? It is strictly
inferior to its forks, so there is now a redundancy issue.

Than being said, your explanation made me reconsider my position
and I won't advocate removal anymore.

On 10/21/2012 05:55 AM, Sam Geeraerts wrote:
 Ivan Zaigralin wrote:
 Adblock Lite is MPL. It has the Adblock Plus' current feature set
 with the old (pre-2) interface. The main difference is the absence
 of Allow Some Ads option, which is enabled by default in Adblock
 Plus. In an ironic twist of fate, Palant sold out to advertisers :)
 While the code of ABP is still free, IMHO, it should be removed
 because its default settings are designed to abuse the user, and
 replacements are available.
 
 The criterion for inclusion in the Gnuzilla list is software freedom. If
 extensions are barred for other reasons, then the purpose of the list becomes
 less clear. There are also extensions in the list that facilitate the use of
 Google and other websites/services that have raised privacy concerns. With the
 current policy they could only be excluded if you'd argue that they encourage
 the use of websites that require running non-free Javascript.
 
 That being said, the Gnuzilla project does pay attention to user privacy. Loic
 could choose to add that as a second criterion for the list (with the
 aforementioned risk). Another option is to add warnings to the list. That 
 still
 requires that every extension be checked for privacy issues, because it
 shouldn't be that no privacy warning could also mean that it hasn't been
 checked. So it would take more work to get (certain types of) extensions on 
 the
 list, making people less inclined to submit them. And like with SaaS, it's not
 always clear cut whether something crossed the line. I'm not opposed to the 
 idea
 per se, though. :)
 
 Anyway, I'm not sure ABP's default settings are even a privacy issue. And if I
 recall correctly, it does explicitly give users the choice to disable the
 whitelist when it's installed.
 
 





signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU IceCat 12.0 released

[Ivan Zaigralin]

What's the rationale for disabling sync? Just wondering.
Would I need to make changes before building (from source)
to enable it?

On 06/02/2012 02:36 AM, Loic J. Duros wrote:
 I am happy to announce the new version of the IceCat web browser.
 
 This version is based on the Mozilla Firefox version 12.0.
 
 GNU IceCat 12.0 is available for download here:
 ftp://ftp.gnu.org/gnu/gnuzilla/12.0/icecat-12.0.tar.xz
 
 [CHANGES]
 
 * GNU LibreJS is now loaded by default.
 
 * In the same manner as Debian Iceweasel and Trisquel Abrowser, the profile
 directories are now located within the home .mozilla directory, under
 .mozilla/icecat. This addresses the issue with the --with-user-appdir option
 that has been reported multiple times through the years.
 
 * Firefox Sync is now disabled by default.
 
 Please report any problem you may experience to the bug-gnuzilla@gnu.org 
 mailing
 list.
 
 Thank you,
 
 Loic Duros
 Gnuzilla and IceCat maintainer
 
 
 
 -- 
 http://gnuzilla.gnu.org
 
 




signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] GNU IceCat 10.0 released

[Ivan Zaigralin]

priv3 and MAFIAAFire addons supplied with icecat are reported
to be incompatible with 10.0.




signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

[Bug-gnuzilla] Slackware64 binaries

[Ivan Zaigralin]

Hi all! I will be making latest Slackware64 binary packages
available via a trackerless torrent, enjoy :)

http://melikamp.com/features/slackbuilds.shtml#icecat



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Showing full URL in the urlbar (bug?)

[Ivan Zaigralin]

Εύρηκα!

I compared with other keys present in Firefox,
created a Boolean browser.urlbar.formatting.enabled
and set to true. Now the trim is gone for good.

Unlike official Firefox binaries, my builds of Icecat 7.0 and 7.0.1
do not have keys

browser.urlbar.formatting.enabled
browser.urlbar.trimURLs

set on arrival, just FYI.

On 10/08/2011 12:55 PM, Ivan Zaigralin wrote:
 On 10/08/2011 08:18 AM, Giuseppe Scrivano wrote:
 Ivan Zaigralin melik...@melikamp.com writes:

 The same behavior persists in 7.0.1. Did anyone manage to disable
 URL trim?

 It works for me.  Trough about:config I have created the new boolean
 key browser.urlbar.trimURLs then set it to false.  Have you tried it?
 
 I tried that, but the effect does not persist through a restart.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: [Bug-gnuzilla] Showing full URL in the urlbar (bug?)

[Ivan Zaigralin]

The same behavior persists in 7.0.1. Did anyone manage to disable
URL trim?

Also, Privacy Extension and MAFIAA Redirector are incompatible with
7.0.1. Is that normal?

On 10/05/2011 07:50 PM, Ivan Zaigralin wrote:
 I am trying to make Icecat show full URL in the urlbar.
 Internets say that I need to flip the Boolean browser.urlbar.trimURLs
 Icecat 7.0, however, did not have it on arrival. So
 I created the field and set it to false. This appears to have effect
 until restart. Upon restart, the URLs are trimmed, and I need to
 flip browser.urlbar.trimURLs twice to to make them full again.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: GNU IceCat 6.0.1 released

[Ivan Zaigralin]

What happened to the pretty graphics in the About dialog?



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Building IceCat with 3.1 kernel

[Ivan Zaigralin]

Hi! I have a question about the build process that only Mozilla
developers may be able to answer, but I figured I'll ask here first,
since I am building IceCat and not Firefox.

I am building IceCat 6.0 on a machine with the latest mainline
3.1.0-rc2 kernel. Make fails because it cannot find the file

security/coreconf/Linux3.1.mk

I found that the build goes on just fine if I create a missing file
with the same contents as

security/coreconf/Linux3.0.mk

Is there a better way to do this? I would rather build it without making
unnecessary changes to the source code.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: Building IceCat with 3.1 kernel

[Ivan Zaigralin]

Thanks. Seems like someone already reported it...
https://bugzilla.mozilla.org/show_bug.cgi?id=679006

On 08/19/2011 08:20 AM, Giuseppe Scrivano wrote:
 I have done exactly the same thing for the 3.0 kernel, it will be enough
 to copy the file, until it is not fixed upstream by Firefox :-)
 
 Cheers,
 Giuseppe
 
 Ivan Zaigralin melik...@melikamp.com writes:
 
 Hi! I have a question about the build process that only Mozilla
 developers may be able to answer, but I figured I'll ask here first,
 since I am building IceCat and not Firefox.

 I am building IceCat 6.0 on a machine with the latest mainline
 3.1.0-rc2 kernel. Make fails because it cannot find the file

 security/coreconf/Linux3.1.mk

 I found that the build goes on just fine if I create a missing file
 with the same contents as

 security/coreconf/Linux3.0.mk

 Is there a better way to do this? I would rather build it without making
 unnecessary changes to the source code.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Re: IceCat 5.0.1

[Ivan Zaigralin]

I was not surprised. People who run IceCat on Mac OS X are, IMHO,
a bit crazy, and should reconsider. They agree to an unavoidable
lag in security patches in exchange for removing trademark concerns.
If running 100% free software is more important to them than a timely
security update, then why are they running a proprietary OS?

Regardless, thanks for the update :)

On 08/04/2011 08:42 AM, Giuseppe Scrivano wrote:
 Hello,
 
 I was preparing the new IceCat packages when I have suddenly realized
 that no one of the introduced changes affects IceCat users.
 
 That is the reason why I have decided to skip this release.
 
 Am I missing something?
 
 Cheers,
 Giuseppe
 
 --
 http://gnuzilla.gnu.org
 



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org

Gnuzilla Privacy Extension

[Ivan Zaigralin]

I think the privacy extension is pretty sweet, but may
I suggest a white-listing button for cookies next to the existing
black-listing button? IMHO, this feature alone would make it a must-have
cookie management add-on. And personally, I would prefer to white/black-list
by 2nd level domain (gnu.org), the way noscript lets me do it.



signature.asc
Description: OpenPGP digital signature
--
http://gnuzilla.gnu.org