bug#40173: Update
I was able to acquire a signed version of the extension for distribution outside of addons.mozilla.com after changing the add-on ID. I moved the source code here: https://nosuchdomain.mooo.com/git/doc/librifyjs-libgen.me You can find the signed binaries in the releases folder, e.g. for the currently latest release: https://nosuchdomain.mooo.com/git/doc/librifyjs-libgen.me/raw/branch/master/releases/librifyjs_libgenme-0.1.1-fx.xpi It should be possible to download the file from here and include it in the IceCat build. Let me know if there are any issues or if I can do anything else to help.
bug#40173: libgen.me browser extension
Unfortunately, Mozilla has recently disabled the extension based on alleged copyright infringements against LibGen itself (full message at the bottom). Can someone please remove the extension from the 68 branch of IceCat as well? Thanks Johannes Original message from Mozilla: Dear contributor, We received a notification under Mozilla’s Digital Millennium Copyright Act (“DMCA”) and Trademark policy (https://www.mozilla.org/about/legal/report-infringement/) complaining of allegedly infringing activity by you on our service at https://addons.mozilla.org/en-US/firefox/addon/librifyjs-libgen-me. We have removed or disabled access to your add-on identified by the claimant as infringing the claimant's copyright. The notice included the following report: >From DeVore & DeMarco LLP: We are litigation counsel for Elsevier Inc., a leading publisher of scientific, engineering, and medical books and journals. Elsevier provides , among other things, the ScienceDirect platform, through which it distributes scientific journal articles in which it holds the copyright. In order to protect its copyright interest in those articles, Elsevier brought a civil action against a number of websites commonly known as "Sci-Hub" and "LibGen" or "Library Genesis" and their respective mirrors which engage in the large-scale infringement of those copyrights. On June 21, 2017, Elsevier obtained a judgement against those websites which, among other things, enjoined the websites, their operators, and anyone acting in concert with them, from infringing Elsevier' s copyrighted works or assisting others in doing so. We write to inform you of the presence of a number of add-ons for the Firefox web browser which are designed specifically to assist their users in infringing Elsevier 's (and other publisher') copyrights through the websites operated by the defendants in the above-mentioned civil action. We request that these extensions be removed from the Firefox Browser Add-Ons website (addons.mozilla.org) because they (1) violate the DMCA, including Section 1201 (circumvention of copyright protection systems); (2) operate in concert with the defendants in the above-mentioned civil action to violate Elsevier's copyrights in violation of the court 's order enjoining such conduct; and (3) are manifestly in violation of Mozilla's Conditions of Use (https://www.mozilla.om:/enUS/about/legal /acceptable-useD which expressly prohibit, among other things, illegal content and content which violates the copyright or other intellectual property rights of others. We therefore request that the following add-ons be promptly removed. ... • LibrifyJS: Libgen.me o https :// addons.mozi l la.erg/ en-US/firefox/addon/li brifvj s-libgen-me o Published by "h3nn3s" o Last updated Nov. 7, 2019 o Javascript fix for the Libgen.me site If you believe your content was removed or disabled as a result of a mistake or misidentification of the material to be removed or disabled (e.g., you have permission to post it or you believe it is a fair use), you may submit a counter notification to us at dmcanot...@mozilla.com. We refer you to our DMCA and Trademark policy page at https://www.mozilla.org/about/legal/report-infringement/ for the requirements for a valid counter notification and more information. We remind you of our repeat infringer termination policy. Under our policy, we may terminate, at our discretion, a user’s account if under appropriate circumstances they are determined to be a repeat infringer. Sincerely, Mozilla Legal Team On 11/8/19 8:03 PM, Johannes Marbach wrote: > Hello everyone, > > This might not be the best place to post this but in lack of awareness > of other options: I recently put together a browser extension for making > the libgen.me website work in IceCat with LibreJS enabled. I didn't > spend much time on polishing the UI but functionally search, item > details and item link list work - at least in my testing. > > If anyone is interested in using or contributing to this, you can find > the extension on AMO: > > https://addons.mozilla.org/en-US/firefox/addon/librifyjs-libgen-me > > and the code on GitLab: > > https://gitlab.com/cherrypicker/librifyjs---libgen.me > > Best, > Johannes
Re: IceCat-68.2.0-guix0-preview2 now available via GNU Guix
Hi Mark, Johannes Marbach wrote: > One thing I noticed when downloading other extensions from > addons.mozilla.org is that they have a cose.manifest and a cose.sig file > in the META-INF folder. These seem to not be present in the extensions > bundled with IceCat. I'm not sure how the copies that are bundled with > the IceCat source were acquired but maybe they have to be redownloaded > from Mozilla to get the latest signature variant? Picking up on my own quote here, I noticed that these "cose" files are deleted in the script that fetches the extensions (https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/update-extensions.sh?h=68#n33): find extensions -name cose.manifest -delete find extensions -name cose.sig -delete There's probably been a good reason for this at some point but given that there are signature issues in the 68 preview, maybe this could be related? Looking at that script some more, I also noticed that it already has fallbacks for extensions that don't define an explicit ID in their manifest. However, these fallback IDs are only used for the directory and file name: if [ -f /tmp/update-extension/manifest.json ]; then ID=$(grep '"id":' /tmp/update-extension/manifest.json |head -n1|cut -d \" -f 4) fi [ $extension = "tortm-browser-button" ] && ID="tortm-browser-button@jeremybenthum" [ $extension = "use-google-drive-with-librejs" ] && ID="google_drive@0xbeef.coffee" [ -z $ID ] && ID=$extension"@extension" rm -rf extensions/$ID mv /tmp/update-extension extensions/$ID I wonder if maybe we could add these to the manifest as well to try and fix the issue of ID-less extensions (such as tortm-browser-button@jeremybenthum) not showing up in IceCat? Best, Johannes pEpkey.asc Description: application/pgp-keys
libgen.me browser extension
Hello everyone, This might not be the best place to post this but in lack of awareness of other options: I recently put together a browser extension for making the libgen.me website work in IceCat with LibreJS enabled. I didn't spend much time on polishing the UI but functionally search, item details and item link list work - at least in my testing. If anyone is interested in using or contributing to this, you can find the extension on AMO: https://addons.mozilla.org/en-US/firefox/addon/librifyjs-libgen-me and the code on GitLab: https://gitlab.com/cherrypicker/librifyjs---libgen.me Best, Johannes pEpkey.asc Description: application/pgp-keys
Re: sumofus.org extension broken / replacement extension
Hi Mark, Mark H Weaver wrote: > Thanks *very* much for this, and I'm sorry that no one has responded to > your contribution before now. Regrettably, I'm so overloaded at present > with other urgent matters that it may be another few weeks before I can > properly evaluate it, but if no one else beats me to it, I will > certainly do so. Thanks a lot and really no reason to be sorry. My main goal was to raise the fact that the bundled extension was broken. I would have tried to patch it but there didn't seem to be any code repository for it sadly. I realize that evaluating my own extension is not a high priority but also anyone who wants to can just get it from AMO so I'm not trying to push this at all. Maybe as an intermediate quick fix the broken one could be disabled in the Guix IceCat preview? Best, Johannes pEpkey.asc Description: application/pgp-keys
Re: IceCat-68.2.0-guix0-preview2 now available via GNU Guix
Hi Mark,
Mark H Weaver wrote:
> * Reconsider this somewhat questionable IceCat-specific setting
> (in gnuzilla/data/settings.js):
>
> // Do not require xpi extensions to be signed by Mozilla
> pref("xpinstall.signatures.required", false);
I've noticed this, too, a while ago and it does seem bad to me. I am not
sure what the backstory with this setting is (and I'm sure there is one)
but having Mozilla sign add-ons seems safer than not requiring any
signature at all to me. AFAIK this doesn't require the add-on to be
distributed via addons.mozilla.org. As an add-on author you can upload
your package on addons.mozilla.org and then download a signed archive
for manual distribution.
> * These bundled extensions are not shown in :
>
> tortm-browser-button@jeremybenthum
> disable-polymer-youtube@extension
> viewtube@extension
>
> for each one, there are text messages like this printed to
> stdout/stderr on launch:
>
> 1572735499245 addons.xpi-utilsWARNaddMetadata: Add-on
> tortm-browser-button@jeremybenthum is invalid: Error: Invalid addon ID:
> expected addon ID tortm-browser-button@jeremybenthum, found undefined in
> manifest(resource://gre/modules/addons/XPIDatabase.jsm:2715:15) JS Stack
> trace: addmetad...@xpidatabase.jsm:2715:15
From cross-checking, all of the extensions that show in about:addons
seem to have an explicit ID...
"applications": {
"gecko": {
"id":"tprb.ad...@searxes.danwin1210.me",
...
...while those that are missing do not. I had similar issues with my own
extensions on IceCat 60.7.0 that required me to explicitly set their ID
in the manifest. Interestingly the bundled extensions that fail in
68.2.0 seem to work on 60.7.0 despite lacking the ID which totally
confuses me.
> * These bundled extensions look okay in , but I
> haven't tested them:
>
> goteo@0xbeef.coffee
> DMCAreg@0xbeef.coffee
> google_drive@0xbeef.coffee
> FreeUSPS@0xbeef.coffee
> rnrMcDonalds@0xbeef.coffee
> rsf@0xbeef.coffee
It's funny but for some reason all of these show the big yellow
signature disclaimer for me.
One thing I noticed when downloading other extensions from
addons.mozilla.org is that they have a cose.manifest and a cose.sig file
in the META-INF folder. These seem to not be present in the extensions
bundled with IceCat. I'm not sure how the copies that are bundled with
the IceCat source were acquired but maybe they have to be redownloaded
from Mozilla to get the latest signature variant?
Best,
Johannes
pEpkey.asc
Description: application/pgp-keys
Re: IceCat-68.2.0-guix0-preview2 now available via GNU Guix
On 10/30/19 5:58 AM, Mike Gerwitz wrote: > On Tue, Oct 29, 2019 at 16:47:26 -0400, Mark H Weaver wrote: >> Although the IceCat project has not yet released IceCat-68, for the >> benefit of those who are impatient to update their IceCat (e.g. due to >> security flaws recently publicized by Mozilla which affect IceCat-60), I >> wanted to let you all know that the GNU Guix project now provides a >> preliminary preview version of IceCat-68. > You've done excellent work, Mark, thank you. > >> For now, to generate a source tarball for this preview version, you'll >> need to install Guix, update it using "guix pull", and then run: >> >> guix build --source icecat >> >> The resulting source tarball should, in theory, work on any system that >> IceCat supports, not just Guix (although Android support is completely >> untested so far, and might very well be broken at present). >> >> More precisely, the command above tries to emulate what the IceCat >> maintainers would normally do themselves to produce an official source >> tarball, except that Guix does it *deterministically*, such that >> precisely the same bit pattern should be produced every time. Toward >> that end, the timestamps and file ordering in the tarball are different >> from what would be found in an official IceCat source tarball, the l10n >> files are downloaded from fixed upstream revisions instead of grabbing >> the latest at the time 'makeicecat' is run, and the included manifests >> may be sorted differently. Those are the only differences I found the >> last time I checked. >> >> If there are any courageous souls who would like to try generating the >> source tarball using Guix and building it on their preferred OS, I would >> be grateful to hear about your experiences, positive or negative. > My hope is to use Guix to produce the distribution tarballs for IceCat > going forward (as Mark showed above). I have done some preliminary > testing building with the Guix-generated tarball using a foreign distro. > > If others could try building using the tarball created by Guix, please > let us know here if you experience any problems. > > We won't be publishing tarballs to alpha.gnu.org just yet, since there's > still more work to do first. I have successfully built the source tarball with guix on OpenSuse and then after installing all needed dependencies managed to compile it following the steps in the README. Nothing stuck out during compilation and IceCat seems to run fine from what I can tell. Two minor things I noticed: 1. All extensions are listed with a big yellow disclaimer about being unverified on about:addons. 2. about:rights brings up an XML parsing error message. pEpkey.asc Description: application/pgp-keys
Re: IceCat-68.2.0-guix0-preview2 now available via GNU Guix
On 10/31/19 9:12 PM, Mark H Weaver wrote: > Hi Gary, > > I took the liberty of rearranging your reply to bottom-posting style and > making the quoting more clear, to make it easier for others to follow > the natural order of our conversation. > > Gary Driggs writes: > >> On Oct 31, 2019, at 12:41 PM, Mark H Weaver wrote: >> >>> Gary Driggs writes: >>> Kudos for your work on this, Mark. Is there any chance that this is also available on a source code repository? >>> I can understand the desire for this, but I personally do not have the >>> server resources required to host a 388 megabyte source tarball for >>> public download, sorry. >> There are several free repos out there; GitLab, Bit Bucket, >> Sourceforge, etc. I think GNU runs one as well called >> Savannah. q.v. https://www.gnu.org/software/repo-criteria-evaluation.html >> & https://about.gitlab.com/2015/05/20/gitlab-gitorious-free-software > To be clear, I'm not officially part of the upstream IceCat project. I > haven't even asked for commit access to the git repository. I'm just a > volunteer who stepped up to contribute some patches, and I happen to be > the defacto maintainer of the IceCat package in GNU Guix. > > If someone else would like to build the preliminary source tarball using > Guix and make it available for public download, I would welcome it. I'm > already heavily overloaded with other urgent tasks unrelated to IceCat, > and I cannot afford to take on another job, sorry. > > Regards, >Mark > For what it's worth, once guix is installed, creating the source tarball locally with the command given in the initial mail in this thread is not very fast but quite easy. I had no issues with it on OpenSuse. Still waiting for my laptop to finish compiling it though.. pEpkey.asc Description: application/pgp-keys
Re: Missing Tor Button
Sorry for getting a bit off-topic but while we talk about extensions in IceCat, I'd like to re-raise my report about the currently bundled sumofus extension being broken (see https://lists.gnu.org/archive/html/bug-gnuzilla/2019-09/msg2.html). On 10/30/19 5:53 AM, Mike Gerwitz wrote: > On Tue, Oct 29, 2019 at 16:12:50 -0400, Mark H Weaver wrote: >> It was not intentional. I cannot speak for the IceCat project, but I >> think it's safe to say that they intend to continue including the Tor >> button in IceCat. > I have serious concerns about this addon, which I raised previously: > > https://lists.gnu.org/archive/html/bug-gnuzilla/2019-01/msg2.html > > I will want to look into what's needed to resolve those, otherwise I'd > still recommend against it being included in IceCat. But I'd want to > discuss it with the other IceCat maintainers before removing it. > pEpkey.asc Description: application/pgp-keys
Re: [Bug-gnuzilla] sumofus.org extension broken / replacement extension
I fixed the install of my sumofus.org extension in IceCat by explicitly setting the ID assigned by Mozilla in the manifest and making a new release. Version 0.1.1 installs fine now from addons.mozilla.org. Still unsure why the explicit ID is needed in IceCat though. On 9/30/19 8:56 PM, Johannes Marbach wrote: > Hello GNUzillians, > > The "LibreJS compatible SumOfUs.org" extension that ships with IceCat > appears to be broken. It renders a list of petitions but the petition > details page shows up with broken layout and the signing form hidden. I > wanted to analyze this but the extensions homepage, > http://0xbeef.coffee/, seems to be defunct as well and I couldn't find > any place that hosts the code. > > So because of this I ended up throwing together my own extension to make > sumofus.org work in IceCat: > https://addons.mozilla.org/en-US/firefox/addon/librifyjs-sumofus-org > > For reasons unknown, this currently fails to download from > addons.mozilla.org but installing the extension via about:debug works fine. > > I opted for just adding the bits and pieces that were needed to make the > homepage, the petitions list and the petition details with the signing > form functional. This leaves the site looking and feeling almost like in > standard Firefox and appears to work ok in my testing. > > Anyway, I'm not trying to advocate that you bundle my extension with > IceCat but I think you might want to remove (or fix) the current one as > it doesn't currently seem to work. > > Best, > Johannes > > -- > http://gnuzilla.gnu.org pEpkey.asc Description: application/pgp-keys -- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Addons
I dug into this some more today and noticed this output when running
IceCat from the terminal
1569952665143 addons.xpi WARN Download of
https://addons.mozilla.org/firefox/downloads/file/3413998/librifyjs_sumofusorg-0.1.0-an+fx.xpi?src=dp-btn-primary
failed: Error: Cannot find id for addon /tmp/tmp-nym.xpi
(resource://gre/modules/addons/XPIInstall.jsm:1544:17) JS Stack trace:
loadmanif...@xpiinstall.jsm:1544:17
So that indeed confirms that the missing extension ID is the culprit.
Some people have also mentioned a similar error message in posts about
the expired certificate problem that broke *all* Firefox extensions
earlier this year (see
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/).
However, if I'm understanding correctly, this has been fixed in 60.6.3
so IceCat being based on 60.7.0 should not be affected. Indeed, the
extension(s) they offered as a temporary workaround in the post linked
above did not seem to help in IceCat. This also doesn't seem related
because IceCat appears to be setting xpinstall.signatures.required to
false by default which should skip the signature check.
On 9/30/19 10:01 PM, Johannes Marbach wrote:
> Hi Michael,
>
> I'm facing similar issues with my own extensions and I think I've
> tracked it down to a setting in the extension's manifest. Out of my
> three extensions, the only one that installs in IceCat from
> addons.mozilla.org has this in its manifest:
>
> "browser_specific_settings": {
> "gecko": {
> "id": "...",
> "strict_min_version": "50.0"
> }
> }
>
> The other two don't have the ID or minimum version set in their manifest
> and they fail to install from addons.mozilla.org.
>
> I downloaded the XPIs for the extensions you listed and none of them
> seem to have this settings section either in their manifest.
>
> This guy here describes how one could download the extension's XPI,
> modify the manifest, then have Mozilla sign it for self distribution to
> finally install it:
> https://github.com/mozilla/addons/issues/851#issuecomment-480539714
>
> That doesn't seem to be a long-term solution though. :/
>
> Best,
> Johannes
>
> --
> http://gnuzilla.gnu.org
pEpkey.asc
Description: application/pgp-keys
--
http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Addons
Hi Michael,
I'm facing similar issues with my own extensions and I think I've
tracked it down to a setting in the extension's manifest. Out of my
three extensions, the only one that installs in IceCat from
addons.mozilla.org has this in its manifest:
"browser_specific_settings": {
"gecko": {
"id": "...",
"strict_min_version": "50.0"
}
}
The other two don't have the ID or minimum version set in their manifest
and they fail to install from addons.mozilla.org.
I downloaded the XPIs for the extensions you listed and none of them
seem to have this settings section either in their manifest.
This guy here describes how one could download the extension's XPI,
modify the manifest, then have Mozilla sign it for self distribution to
finally install it:
https://github.com/mozilla/addons/issues/851#issuecomment-480539714
That doesn't seem to be a long-term solution though. :/
Best,
Johannes
pEpkey.asc
Description: application/pgp-keys
--
http://gnuzilla.gnu.org
[Bug-gnuzilla] sumofus.org extension broken / replacement extension
Hello GNUzillians, The "LibreJS compatible SumOfUs.org" extension that ships with IceCat appears to be broken. It renders a list of petitions but the petition details page shows up with broken layout and the signing form hidden. I wanted to analyze this but the extensions homepage, http://0xbeef.coffee/, seems to be defunct as well and I couldn't find any place that hosts the code. So because of this I ended up throwing together my own extension to make sumofus.org work in IceCat: https://addons.mozilla.org/en-US/firefox/addon/librifyjs-sumofus-org For reasons unknown, this currently fails to download from addons.mozilla.org but installing the extension via about:debug works fine. I opted for just adding the bits and pieces that were needed to make the homepage, the petitions list and the petition details with the signing form functional. This leaves the site looking and feeling almost like in standard Firefox and appears to work ok in my testing. Anyway, I'm not trying to advocate that you bundle my extension with IceCat but I think you might want to remove (or fix) the current one as it doesn't currently seem to work. Best, Johannes pEpkey.asc Description: application/pgp-keys -- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Bug on IceCat mobile
Hi William, I don't have a solution to your problem but as there generally hasn't been much of a response to any mobile-related questions on this list I was actually wondering if the GNUzilla team themselves actually maintains the F-Droid version or if that is an external effort. The Android app seems to be at 60.5.1 while the desktop app is at 60.3.0. Best, Johannes On 3/9/19 7:11 AM, baud.will...@free.fr wrote: Hi, First, let me tell you I'm French. So i apologize if my English is not perfect. I have a Nokia 7 plus and I downloaded F-Droid. With F-Droid, I downloaded IceCat but I can't login in the parameters. A circle turn over and over and nothing (I already tried all a night). Somebody already had the same problem 2 years ago : https://bugzilla.mozilla.org/show_bug.cgi?id=1379601 An other on a desktop version too (I don't find again the link). This one could log in with an upgrade. It's the only software I need to emancipate the Play store. I hope you will can resolve this bug. Thank you for your work. Best regards. William -- http://gnuzilla.gnu.org -- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] IceCat v60.3.0esr 64bit
Hi Flemmig, I can't speak for the Debian package but I'm not seeing this on macOS neither on IceCat nor on standard Firefox. Any chance this traffic could be coming from another application or some browser add-on? Best Johannes On 21 January 2019 15:37:59 CET, lcf wrote: >Hello > >I am currently testing IceCat on Debian v 9.6 64bit OS. > >When I start the IceCat and just leave it open, without using it, it >stands and connects to Amazon's different IP addresses 1 to 2 times per >minute. Why ? > >Are you sponsored by Amazon? > > >Flemmig Christensen >Denmark >-- >lcf > >-- >http://gnuzilla.gnu.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Building Icecat 60.3.0 on macOS Mojave 10.14.1
Thanks all. I talked to Hein-Pieter van Braam-Stewart (who primarily maintains NotABug) and he generously permitted me to host the binary still. If anyone else is interested, you can find it in the dmgs subfolder of https://notabug.org/h3nn3s/icecat-mac now. Hein-Pieter also suggested to set up a cross build for IceCat for Mac from Linux but I haven't been successful with that so far. > On January 20, 2019 at 1:21 AM Jean-Christophe Helary > wrote: > > > > > > > On Jan 20, 2019, at 0:57, Johannes Marbach < > johannesmarb...@mailbox.org mailto:johannesmarb...@mailbox.org > wrote: > > > > Noob question: If add the final dmg to the repo, the license of > > IceCat / Firefox requires me to also host the original sources there, right? > > > > > IANAL, but, like I did, if you clearly specify what you did and > > where you got the elements from, you should be able to host the dmg without > > having a troll bugging you. If somebody bugs you just remove the dmg. > > > Jean-Christophe Helary > --- > http://mac4translators.blogspot.com @brandelune > > > -- > http://gnuzilla.gnu.org > -- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Building Icecat 60.3.0 on macOS Mojave 10.14.1
Thanks Bill, I see how this is not a good fit from an ethical point of view now. :/ In an attempt to make things easier for other people like me (GNU enthusiasts who have to use a Mac for certain parts of their life) I collected my patches together with a super simple build script here: https://notabug.org/h3nn3s/icecat-mac I still need to add some of the steps I shared about setting up the environment to the README though. Noob question: If add the final dmg to the repo, the license of IceCat / Firefox requires me to also host the original sources there, right? On 1/18/19 9:48 PM, bill-auger wrote: On Jan 19, 2019, at 1:19, Johannes Marbach wrote: GNUzilla wouldn't be interested in hosting my .dmg of Icecat on their site, right? just to be clear, GNU used to build for mac some years ago - then something changed in the toolset (maybe that SDK?) and now building icecat for mac requires non-free software - for that reason, GNU does not build it any longer, and does not recommend or assist anyone to build it - that is the primary and only reason that it is not already available on the GNU website -- http://gnuzilla.gnu.org -- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] icecat 60.3.0 on android 8.1 missing functionality
Hi Bodo, I believe this is an issue on standard Firefox as well. You might be able to get around it with a download manager add-on that you can then send the link to from the normal share menu but I haven't tried. Best, Johannes On 18 January 2019 16:41:37 CET, Bodo wrote: >Hi all, >I'm using icecat on my handheld devices where they are installed and >maintained via F-Droid. I admire the work and the power embraced by the > >FOS-tools. Despite this fact I'm sadly missing the >"right-click"-function on an URL to download the URL (save link as ..). > >I'm aware of this sophisticated mechanism who decide for me what to do >with different URL-content. But if I want to download a video I can't. >If this was a mozilla decision then is also an answer. How can I >circumvent this issue? Right now I'm sidestepping to chrome which I'm >not prefer. >thanks for any answer >Bodo > >-- >http://gnuzilla.gnu.org -- Sent from my Android device with K-9 Mail. Please excuse my brevity.-- http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Building Icecat 60.3.0 on macOS Mojave 10.14.1
e error codes.
2019-01-18 08:53:51.605 plugin-container[29305:2259516] +[NSXPCSharedListener
endpointForReply:withListenerName:]: an error occurred while attempting to
obtain endpoint for listener 'ClientCallsAuxiliary': Connection invalid
> On January 18, 2019 at 9:52 AM Johannes Marbach
> wrote:
>
>
> Forgot to add one important piece needed to make it compile here: After
> installing the CLI developer tools, I had to manually go to
> /Library/Developer/CommandLineTools/Packages and install the header package.
>
> > On January 18, 2019 at 9:36 AM Johannes Marbach
> > wrote:
> >
> >
> > Hi all,
> >
> > I wanted to follow up on a thread from last week where Brennan and
> > Jean-Christophe discussed building Icecat 60.3.0 on macOS (I can't reply to
> > the old thread because I just joined the list and my web mailer doesn't let
> > me set the In-Reply-To header).
> >
> > I've been struggling with this on macOS Mojave 10.14.1, too, for some time
> > now. First I couldn't get configure and make to work because they'd always
> > fail with missing includes. I finally got it to compile by using
> >
> > env CXX='/usr/bin/clang++ -stdlib=libc++' ../configure
> > --with-l10n-base=../l10n --enable-official-branding
> > make
> >
> > Note that I have to use env because my shell is fish. Afterwards make
> > package failed with the missing files errors Brennan reported.
> >
> > Error:
> > /Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:593:
> > Missing file(s):
> > /IceCat.app/Contents/MacOS/browser/extensions/tprb.ad...@searxes.danwin1210.me/*
> > Error:
> > /Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:594:
> > Missing file(s):
> > /IceCat.app/Contents/MacOS/browser/extensions/tortm-browser-button@jeremybenthum/*
> > ...
> >
> > I found the files existed but not in IceCat.app/Contents/MacOS but in
> > IceCat.app/Contents/Resources. So I went into
> > browser/installer/package-manifest.in and replaced @BINPATH@ with @RESPATH@
> > on lines 593 through 604. That finally made make package go through.
> >
> > However, after installing the .dmg and launching Icecat it just sits there
> > with an all black window. There's a bit of output on the terminal but the
> > only important thing to me seems this
> >
> > 2019-01-18 08:15:45.325 plugin-container[25006:2228360] unable to obtain
> > configuration from file:///Library/Preferences/com.apple.ViewBridge.plist
> > due to Error Domain=NSCocoaErrorDomain Code=257 "The file
> > “com.apple.ViewBridge.plist” couldn’t be opened because you don’t have
> > permission to view it."
> > UserInfo={NSFilePath=/Library/Preferences/com.apple.ViewBridge.plist,
> > NSUnderlyingError=0x10b9ec250 {Error Domain=NSPOSIXErrorDomain Code=1
> > "Operation not permitted"}}
> >
> > I found a reference to this in the tor browser project
> > (https://trac.torproject.org/projects/tor/ticket/20989) and it sounds like
> > it may be related to app sand boxing being configured too strict. However,
> > I'm unsure on how to apply their fix to Icecat (or if this is the actual
> > culprit).
> >
> > Does anyone have any pointers on what I could do from here?
> >
> > Thanks,
> > Johannes
> >
> > --
> > http://gnuzilla.gnu.org
>
> --
> http://gnuzilla.gnu.org
--
http://gnuzilla.gnu.org
Re: [Bug-gnuzilla] Building Icecat 60.3.0 on macOS Mojave 10.14.1
Forgot to add one important piece needed to make it compile here: After
installing the CLI developer tools, I had to manually go to
/Library/Developer/CommandLineTools/Packages and install the header package.
> On January 18, 2019 at 9:36 AM Johannes Marbach
> wrote:
>
>
> Hi all,
>
> I wanted to follow up on a thread from last week where Brennan and
> Jean-Christophe discussed building Icecat 60.3.0 on macOS (I can't reply to
> the old thread because I just joined the list and my web mailer doesn't let
> me set the In-Reply-To header).
>
> I've been struggling with this on macOS Mojave 10.14.1, too, for some time
> now. First I couldn't get configure and make to work because they'd always
> fail with missing includes. I finally got it to compile by using
>
> env CXX='/usr/bin/clang++ -stdlib=libc++' ../configure
> --with-l10n-base=../l10n --enable-official-branding
> make
>
> Note that I have to use env because my shell is fish. Afterwards make package
> failed with the missing files errors Brennan reported.
>
> Error:
> /Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:593:
> Missing file(s):
> /IceCat.app/Contents/MacOS/browser/extensions/tprb.ad...@searxes.danwin1210.me/*
> Error:
> /Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:594:
> Missing file(s):
> /IceCat.app/Contents/MacOS/browser/extensions/tortm-browser-button@jeremybenthum/*
> ...
>
> I found the files existed but not in IceCat.app/Contents/MacOS but in
> IceCat.app/Contents/Resources. So I went into
> browser/installer/package-manifest.in and replaced @BINPATH@ with @RESPATH@
> on lines 593 through 604. That finally made make package go through.
>
> However, after installing the .dmg and launching Icecat it just sits there
> with an all black window. There's a bit of output on the terminal but the
> only important thing to me seems this
>
> 2019-01-18 08:15:45.325 plugin-container[25006:2228360] unable to obtain
> configuration from file:///Library/Preferences/com.apple.ViewBridge.plist due
> to Error Domain=NSCocoaErrorDomain Code=257 "The file
> “com.apple.ViewBridge.plist” couldn’t be opened because you don’t have
> permission to view it."
> UserInfo={NSFilePath=/Library/Preferences/com.apple.ViewBridge.plist,
> NSUnderlyingError=0x10b9ec250 {Error Domain=NSPOSIXErrorDomain Code=1
> "Operation not permitted"}}
>
> I found a reference to this in the tor browser project
> (https://trac.torproject.org/projects/tor/ticket/20989) and it sounds like it
> may be related to app sand boxing being configured too strict. However, I'm
> unsure on how to apply their fix to Icecat (or if this is the actual culprit).
>
> Does anyone have any pointers on what I could do from here?
>
> Thanks,
> Johannes
>
> --
> http://gnuzilla.gnu.org
--
http://gnuzilla.gnu.org
[Bug-gnuzilla] Building Icecat 60.3.0 on macOS Mojave 10.14.1
Hi all,
I wanted to follow up on a thread from last week where Brennan and
Jean-Christophe discussed building Icecat 60.3.0 on macOS (I can't reply to the
old thread because I just joined the list and my web mailer doesn't let me set
the In-Reply-To header).
I've been struggling with this on macOS Mojave 10.14.1, too, for some time now.
First I couldn't get configure and make to work because they'd always fail with
missing includes. I finally got it to compile by using
env CXX='/usr/bin/clang++ -stdlib=libc++' ../configure --with-l10n-base=../l10n
--enable-official-branding
make
Note that I have to use env because my shell is fish. Afterwards make package
failed with the missing files errors Brennan reported.
Error:
/Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:593:
Missing file(s):
/IceCat.app/Contents/MacOS/browser/extensions/tprb.ad...@searxes.danwin1210.me/*
Error:
/Users/jmarbach/Code/icecat/icecat-60.3.0/browser/installer/package-manifest.in:594:
Missing file(s):
/IceCat.app/Contents/MacOS/browser/extensions/tortm-browser-button@jeremybenthum/*
...
I found the files existed but not in IceCat.app/Contents/MacOS but in
IceCat.app/Contents/Resources. So I went into
browser/installer/package-manifest.in and replaced @BINPATH@ with @RESPATH@ on
lines 593 through 604. That finally made make package go through.
However, after installing the .dmg and launching Icecat it just sits there with
an all black window. There's a bit of output on the terminal but the only
important thing to me seems this
2019-01-18 08:15:45.325 plugin-container[25006:2228360] unable to obtain
configuration from file:///Library/Preferences/com.apple.ViewBridge.plist due
to Error Domain=NSCocoaErrorDomain Code=257 "The file
“com.apple.ViewBridge.plist” couldn’t be opened because you don’t have
permission to view it."
UserInfo={NSFilePath=/Library/Preferences/com.apple.ViewBridge.plist,
NSUnderlyingError=0x10b9ec250 {Error Domain=NSPOSIXErrorDomain Code=1
"Operation not permitted"}}
I found a reference to this in the tor browser project
(https://trac.torproject.org/projects/tor/ticket/20989) and it sounds like it
may be related to app sand boxing being configured too strict. However, I'm
unsure on how to apply their fix to Icecat (or if this is the actual culprit).
Does anyone have any pointers on what I could do from here?
Thanks,
Johannes
--
http://gnuzilla.gnu.org
