Re: Is there a way to know which extensions may break when upgrading?

2020-03-08 Thread Daniel

Steve Dunn wrote on 9/03/2020 1:39 AM:

On 2020-03-08 04:43, Daniel wrote:
If "I mostly use SeaMonkey for email and newsgroups" why not use 
Thunderbird in place of SeaMonkey?? That would save using resources on 
the unused Browser portion of SM!


 Eventually that will probably be necessary, but as long as 
SeaMonkey works, there's not much of a reason to bother migrating, 
especially as my computer is not short on resources.


-Steve


P.K.!

--
Daniel

Win7 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) 
Gecko/20100101 SeaMonkey/2.49.5 Build identifier: 20190609032134


Linux User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) 
Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: SM already has a clone tab -- Re: For those who use PrefBar v7.1.1, does its clone button not work anymore for you too?

2020-03-08 Thread alexyu

Ant wrote, on 08 Mar 20 01:03:


On 3/7/2020 6:43 PM, alexyu wrote:


Frank-Rainer Grahl wrote, on 07 Mar 20 20:16:


alexyu wrote:

I commented on using "Duplicate Tab", which I have been using since 
before FF (and, I think, SM too) introduced the "middle-click on 
'reload' button" for this.  Not having a middle-button on my mouse, 
I've read that clicking on the wheel might work, but on my muse it 
doesn't, neither in SM nor in FF -- so I keep using "Duplicate Tab", 
which also has other functionalities, as I mentioned.


And, again: I still haven't tried it in SM 2.53, because I have to 
prepare first (as should anyone considering the move).


Will not work. The clone methods are not (yet) implemented in 
SeaMonkeys tab browser code.


Thanks, FRG; you've just saved me a lot of work:  Since "Duplicate 
Tab" is very useful to me, knowing in advance that it won't work in SM 
2.53 means that I won't even try the migration -- instead, I'll stay 
on 2.49.5 for the foreseeable future.


You could just control or middle mouse button click on web browser's 
reload button in v2.53.1. I don't know if v2.49.5 and earlier versions 
can do that too since I don't have them anymore.


As I already said, I don't have a middle-button on my mouse, and 
clicking on the wheel doesn't work either, but I can try Ctrl-Click.


Yes, that duplicates/clones the page using ctrl-click on the 'Reload', 
in both my SM 2.49.5 and FF 52.7.4ESR; the other functions of the 
"Duplicate Tab" extension would be lost, but I rarely use them anyway -- 
but I dislike using keyboard/mouse shortcuts (besides the eternal 
Ctrl-A/C/V/X), since I usually forget what they were supposed to be 
after some time (I even worry if it's Ctrl-PrtScrn or Shft-PrtScrn). 
Since you said they work in SM 2.53.1, I suppose that would be true of 
FF too.


So, I guess I'll still have to test how my other Extensions work in SM 
2.53.1, then...  But I still don't understand why, if these 
mouse/keyboard shortcuts work in all of them, FRG would say that they 
"will not work [since] the clone methods are not (yet) implemented in 
SeaMonkey's tab browser code"...


--
Best,

s) alexyu   



___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Preference Expired

2020-03-08 Thread Paul in Houston, TX

Larry S. wrote:

Paul in Houston, TX wrote:

Larry S. wrote:

Paul in Houston, TX wrote:

Larry S. wrote:

David E. Ross wrote:

On 3/2/2020 1:11 PM, Larry S. wrote:

I was suddenly denied access to Fox News. Checked my settings, and
discovered that one preference expired today, and another one 
tomorrow.

Permissions was blank. (No others expired for quite a while.)

Now what? How do I get an updated preference for that particular 
site?


Larry



Are you sure it was a preference and not a certificate? 
Preferences do

not expire.

You are, of course, correct. It was cookies, not preferences. A 
couple of cookies expired in the last day or so. Do they matter in 
terms of access to the Web site? (My access to Fox News was o.k. 
until today.)


Larry


It may be something other than cookies.  My cookies are session 
cookies only and I can view Fox News ok.  At the end of each session 
they are all deleted.  You could try changing your UA string to 
Firefox 72.0.1 instead of FF 52.0 and see if it helps.

How would I do that?
Larry


In the url bar, enter about:config
Enter general
Look for general.useragent.override and click on it.
Enter Firefox/72.0.1
Close and reopen SM and see if Fox News now works.
Make note of the changes that you made in case they do not work and 
you have to remove them.
O.K., it didn't work. Still get the message "You don't have permission 
to access Fox News on this server".

Any other thoughts?
And--how do I reverse the entry that I made? I entered SeaMonkey in the 
space where I put Firefox, but I don't see any effect.

Larry

Did you make written notes of your changes?
If so then reverse what you changed or just clear the override line.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Preference Expired

2020-03-08 Thread Hartmut Figge
Hartmut Figge:

>Curious as I sometimes be I have tried to get that message. First asking
>ixquick about Fox News and then visiting https://www.foxnews.com/politics
>
>No problem with Mozilla/5.0 (X11; Linux x86_64; rv:60.0)
>Gecko/2020030200 SeaMonkey/2.53.2-h

For testing I have changed my UA to yours. Still no problem.

Hartmut, next back to my own UA
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Preference Expired

2020-03-08 Thread Hartmut Figge
Larry S.:

>O.K., it didn't work. Still get the message "You don't have permission 
>to access Fox News on this server".
>Any other thoughts?

Curious as I sometimes be I have tried to get that message. First asking
ixquick about Fox News and then visiting https://www.foxnews.com/politics

No problem with Mozilla/5.0 (X11; Linux x86_64; rv:60.0)
Gecko/2020030200 SeaMonkey/2.53.2-h

Hartmut
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Preference Expired

2020-03-08 Thread Larry S.

Paul in Houston, TX wrote:

Larry S. wrote:

Paul in Houston, TX wrote:

Larry S. wrote:

David E. Ross wrote:

On 3/2/2020 1:11 PM, Larry S. wrote:

I was suddenly denied access to Fox News. Checked my settings, and
discovered that one preference expired today, and another one 
tomorrow.

Permissions was blank. (No others expired for quite a while.)

Now what? How do I get an updated preference for that particular 
site?


Larry



Are you sure it was a preference and not a certificate?  
Preferences do

not expire.

You are, of course, correct. It was cookies, not preferences. A 
couple of cookies expired in the last day or so. Do they matter in 
terms of access to the Web site? (My access to Fox News was o.k. 
until today.)


Larry


It may be something other than cookies.  My cookies are session 
cookies only and I can view Fox News ok.  At the end of each session 
they are all deleted.  You could try changing your UA string to 
Firefox 72.0.1 instead of FF 52.0 and see if it helps.

How would I do that?
Larry


In the url bar, enter about:config
Enter general
Look for general.useragent.override and click on it.
Enter Firefox/72.0.1
Close and reopen SM and see if Fox News now works.
Make note of the changes that you made in case they do not work and you 
have to remove them.
O.K., it didn't work. Still get the message "You don't have permission 
to access Fox News on this server".

Any other thoughts?
And--how do I reverse the entry that I made? I entered SeaMonkey in the 
space where I put Firefox, but I don't see any effect.

Larry
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Hartmut Figge
Frank-Rainer Grahl:

>We are trying to get latest rust support into 2.53.2 at least for Linux. 
>Unfortunately rust is more or less alpha/early beta quality wrt features and 
>deprecation and a constantly moving target.

FWIW, TB-Trunk now requires at least rust-1.41.0.

Hartmut
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Seamonkey-2.53.1 build segmentation fault on Debian, AMD Ryzen

2020-03-08 Thread Hartmut Figge
Frank-Rainer Grahl:

>Bill had at least one problem with 9 I think. Unless you use the unofficial 
>patches on top of the old comm-release and mozilla-release 2.53.1 might not 
>compile with clang 9.

I am only using the official patches from Bill. clang-9.0.1 is installed
here since 23. Dec. My last build of 2.53.1 was on 10. Dec. The next
build was a 2.53.2b1 on 1. Jan.

So I have never build a 2.53.1 with clang-9.0.1. :)

Hartmut
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Seamonkey-2.53.1 build segmentation fault on Debian, AMD Ryzen

2020-03-08 Thread Frank-Rainer Grahl

Hartmut Figge wrote:

Frank-Rainer Grahl:


The official release was done with gcc  6 but I regularly build with gcc 8 in
a Cent OS 7 vm. Sorry no idea. gcc 6 to 8 should work. Maybe try clang 6 to 8.
9 might work too.


I am using Gentoo and have abandoned gcc for building SM for some time
now. At the moment I am using clang-9.0.1 and rust-1.37.0.

My .mozconf-253:
export CC=clang
export CXX=clang++

ac_add_options --enable-application=suite
ac_add_options --disable-tests

Hartmut



Bill had at least one problem with 9 I think. Unless you use the unofficial 
patches on top of the old comm-release and mozilla-release 2.53.1 might not 
compile with clang 9.


FRG
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Seamonkey-2.53.1 build segmentation fault on Debian, AMD Ryzen

2020-03-08 Thread Hartmut Figge
Frank-Rainer Grahl:

>The official release was done with gcc  6 but I regularly build with gcc 8 in 
>a Cent OS 7 vm. Sorry no idea. gcc 6 to 8 should work. Maybe try clang 6 to 8. 
>9 might work too.

I am using Gentoo and have abandoned gcc for building SM for some time
now. At the moment I am using clang-9.0.1 and rust-1.37.0.

My .mozconf-253:
export CC=clang
export CXX=clang++

ac_add_options --enable-application=suite
ac_add_options --disable-tests

Hartmut
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Seamonkey-2.53.1 build segmentation fault on Debian, AMD Ryzen

2020-03-08 Thread Frank-Rainer Grahl

Hendrik-Jan Heins wrote:

Hi again,

With the rust issue solved, I now get a next error on Debian.
For the build I am using gcc 8.3.0
The error is as below.

Is there any way to recover from this?

thanks,

Hendrik-Jan


In file included from 
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/obj-builddir/widget/Unified_cpp_widget1.cpp:137:
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/mozilla/widget/nsNativeTheme.cpp:
 At global scope:
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/mozilla/widget/nsNativeTheme.cpp:786:1:
 internal compiler error: Segmentation fault
  }
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.



The official release was done with gcc  6 but I regularly build with gcc 8 in 
a Cent OS 7 vm. Sorry no idea. gcc 6 to 8 should work. Maybe try clang 6 to 8. 
9 might work too.


FRG
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Hendrik-Jan Heins
On Sunday, 8 March 2020 16:47:30 UTC+1, Frank-Rainer Grahl  wrote:
> Hendrik-Jan Heins wrote:
> > On Sunday, 8 March 2020 16:20:46 UTC+1, Frank-Rainer Grahl  wrote:
> >> Hendrik-Jan Heins wrote:
> >>> On Sunday, 8 March 2020 00:13:51 UTC+1, Frank-Rainer Grahl  wrote:
>  hjhe...@gmail.com wrote:
> 
>  Use rust 1.36. rust 1.37 might also work.
> 
>  FRG
> >>>
> >>> Thank you FRG!
> >>>
> >>> For anyone with the same issue:
> >>> I ended up installing "rustup"
> >>> Within rustup, I installed and set rustc 1.36.0 as default
> >>> Then I built the package and after quite some time (single thread as I 
> >>> needed to see where it would potentially fail), I now have a working 
> >>> seamonkey-2.53.1 on Arch.
> >>>
> >>
> >> We are trying to get latest rust support into 2.53.2 at least for Linux.
> >> Unfortunately rust is more or less alpha/early beta quality wrt features 
> >> and
> >> deprecation and a constantly moving target.
> >>
> >> FRG
> > 
> > Rust is a pain to have as a dependancy regardless; Every distro has ist own 
> > versions, and rustup is by no means a standard that works with every (any?) 
> > packaging tool. Arch is fairly flexible here, but for instance Debian is a 
> > real issue: I can not create a complete, from source rebuildable package 
> > according to the Debian package guidelines with this thing in there...
> > 
> > By the way: thank you for telling me I needed rust 1.36.0, but how would I 
> > have been able to find out myself?
> > 
> > Hendrik-Jan
> > 
> 
> In the ideal world we would have detailed build instructions available at the 
> website. We are trying to fix it and make the website usable again for devs. 
> Unfortunately with Linux every distribution is different. If you run into a 
> build error best to ask on irc. If no one answers check the logs later. At 
> least I look at them daily if something came up. The others too I think.
> 
> FRG

That sounds good. I was unsure how to contact anyone about this. I stumbled 
upon this group, and gave it a shot.
Thank you FRG!

Hendrik-Jan
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Seamonkey-2.53.1 build segmentation fault on Debian, AMD Ryzen

2020-03-08 Thread Hendrik-Jan Heins
Hi again,

With the rust issue solved, I now get a next error on Debian.
For the build I am using gcc 8.3.0
The error is as below.

Is there any way to recover from this?

thanks,

Hendrik-Jan


In file included from 
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/obj-builddir/widget/Unified_cpp_widget1.cpp:137:
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/mozilla/widget/nsNativeTheme.cpp:
 At global scope:
/home/hjheins/build/Seamonkey/seamonkey-2.53.1/mozilla/widget/nsNativeTheme.cpp:786:1:
 internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Frank-Rainer Grahl




Hendrik-Jan Heins wrote:

On Sunday, 8 March 2020 16:20:46 UTC+1, Frank-Rainer Grahl  wrote:

Hendrik-Jan Heins wrote:

On Sunday, 8 March 2020 00:13:51 UTC+1, Frank-Rainer Grahl  wrote:

hjhe...@gmail.com wrote:

Use rust 1.36. rust 1.37 might also work.

FRG


Thank you FRG!

For anyone with the same issue:
I ended up installing "rustup"
Within rustup, I installed and set rustc 1.36.0 as default
Then I built the package and after quite some time (single thread as I needed 
to see where it would potentially fail), I now have a working seamonkey-2.53.1 
on Arch.



We are trying to get latest rust support into 2.53.2 at least for Linux.
Unfortunately rust is more or less alpha/early beta quality wrt features and
deprecation and a constantly moving target.

FRG


Rust is a pain to have as a dependancy regardless; Every distro has ist own 
versions, and rustup is by no means a standard that works with every (any?) 
packaging tool. Arch is fairly flexible here, but for instance Debian is a real 
issue: I can not create a complete, from source rebuildable package according 
to the Debian package guidelines with this thing in there...

By the way: thank you for telling me I needed rust 1.36.0, but how would I have 
been able to find out myself?

Hendrik-Jan



In the ideal world we would have detailed build instructions available at the 
website. We are trying to fix it and make the website usable again for devs. 
Unfortunately with Linux every distribution is different. If you run into a 
build error best to ask on irc. If no one answers check the logs later. At 
least I look at them daily if something came up. The others too I think.


FRG
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Hendrik-Jan Heins
On Sunday, 8 March 2020 16:20:46 UTC+1, Frank-Rainer Grahl  wrote:
> Hendrik-Jan Heins wrote:
> > On Sunday, 8 March 2020 00:13:51 UTC+1, Frank-Rainer Grahl  wrote:
> >> hjhe...@gmail.com wrote:
> >>> On Saturday, 7 March 2020 23:27:45 UTC+1, hjh...@gmail.com  wrote:
>  Hi All,
> 
>  I hope someone here is familiar with this issue and can point me in the 
>  right direction. I have been trying to build Seamonkey 2.53.1 for a 
>  while now, but to no avail. Whichever mozconfig settings I take, I 
>  always get kicked off the build with an error on nsstring v0.10.
>  The error is:
> 
>  __
> 
>   Compiling nsstring v0.1.0 
>  (/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring)
>  error: use of deprecated item 'try': use the `?` operator instead
>   --> 
>  /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
>    |
>  138 | / bitflags! {
>  139 | | // While this has the same layout as u16, it cannot be 
>  passed
>  140 | | // over FFI safely as a u16.
>  141 | | #[repr(C)]
>  ...   |
>  149 | | }
>  150 | | }
>    | |_^
>    |
>  note: lint level defined here
>   --> 
>  /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:116:9
>    |
>  116 | #![deny(warnings)]
>    | 
>    = note: `#[deny(deprecated)]` implied by `#[deny(warnings)]`
>    = note: this error originates in a macro outside of the current 
>  crate (in Nightly builds, run with -Z external-macro-backtrace for more 
>  info)
> 
>  error: use of deprecated item 'try': use the `?` operator instead
>   --> 
>  /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
>    |
>  138 | / bitflags! {
>  139 | | // While this has the same layout as u16, it cannot be 
>  passed
>  140 | | // over FFI safely as a u16.
>  141 | | #[repr(C)]
>  ...   |
>  149 | | }
>  150 | | }
>    | |_^
>    |
>    = note: this error originates in a macro outside of the current 
>  crate (in Nightly builds, run with -Z external-macro-backtrace for more 
>  info)
> 
>  error: use of deprecated item 'try': use the `?` operator instead
>   --> 
>  /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
>    |
>  154 | / bitflags! {
>  155 | | // While this has the same layout as u16, it cannot be 
>  passed
>  156 | | // over FFI safely as a u16.
>  157 | | #[repr(C)]
>  ...   |
>  161 | | }
>  162 | | }
>    | |_^
>    |
>    = note: this error originates in a macro outside of the current 
>  crate (in Nightly builds, run with -Z external-macro-backtrace for more 
>  info)
> 
>  error: use of deprecated item 'try': use the `?` operator instead
>   --> 
>  /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
>    |
>  154 | / bitflags! {
>  155 | | // While this has the same layout as u16, it cannot be 
>  passed
>  156 | | // over FFI safely as a u16.
>  157 | | #[repr(C)]
>  ...   |
>  161 | | }
>  162 | | }
>    | |_^
>    |
>    = note: this error originates in a macro outside of the current 
>  crate (in Nightly builds, run with -Z external-macro-backtrace for more 
>  info)
> 
>  error: aborting due to 4 previous errors
> 
>  error: could not compile `nsstring`.
> 
>  ___
> 
>  Could someone please tell me what I am doing wrong? I have cargo and 
>  rustc installed, and am compiling with gcc.
> 
>  Thank you for any input!
> 
>  regards,
> 
>  Hendrik-Jan Heins
> >>>
> >>> Not sure if it is impportant: gcc on Arch is 9.2.0, on Debian 8.3.0.
> >>> But both produce the same error (as mentioned above)
> >>>
> >>
> >> Use rust 1.36. rust 1.37 might also work.
> >>
> >> FRG
> > 
> > Thank you FRG!
> > 
> > For anyone with the same issue:
> > I ended up installing "rustup"
> > Within rustup, I installed and set rustc 1.36.0 as default
> > Then I built the package and after quite some time (single thread as I 
> > needed to see where it would potentially fail), I now have a working 
> > seamonkey-2.53.1 on Arch.
> > 
> 
> We are trying to get latest rust support into 2.53.2 at least for Linux. 
> 

Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Frank-Rainer Grahl

Hendrik-Jan Heins wrote:

On Sunday, 8 March 2020 00:13:51 UTC+1, Frank-Rainer Grahl  wrote:

hjhe...@gmail.com wrote:

On Saturday, 7 March 2020 23:27:45 UTC+1, hjh...@gmail.com  wrote:

Hi All,

I hope someone here is familiar with this issue and can point me in the right 
direction. I have been trying to build Seamonkey 2.53.1 for a while now, but to 
no avail. Whichever mozconfig settings I take, I always get kicked off the 
build with an error on nsstring v0.10.
The error is:

__

 Compiling nsstring v0.1.0 
(/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring)
error: use of deprecated item 'try': use the `?` operator instead
 --> 
/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
  |
138 | / bitflags! {
139 | | // While this has the same layout as u16, it cannot be passed
140 | | // over FFI safely as a u16.
141 | | #[repr(C)]
...   |
149 | | }
150 | | }
  | |_^
  |
note: lint level defined here
 --> 
/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:116:9
  |
116 | #![deny(warnings)]
  | 
  = note: `#[deny(deprecated)]` implied by `#[deny(warnings)]`
  = note: this error originates in a macro outside of the current crate (in 
Nightly builds, run with -Z external-macro-backtrace for more info)

error: use of deprecated item 'try': use the `?` operator instead
 --> 
/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
  |
138 | / bitflags! {
139 | | // While this has the same layout as u16, it cannot be passed
140 | | // over FFI safely as a u16.
141 | | #[repr(C)]
...   |
149 | | }
150 | | }
  | |_^
  |
  = note: this error originates in a macro outside of the current crate (in 
Nightly builds, run with -Z external-macro-backtrace for more info)

error: use of deprecated item 'try': use the `?` operator instead
 --> 
/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
  |
154 | / bitflags! {
155 | | // While this has the same layout as u16, it cannot be passed
156 | | // over FFI safely as a u16.
157 | | #[repr(C)]
...   |
161 | | }
162 | | }
  | |_^
  |
  = note: this error originates in a macro outside of the current crate (in 
Nightly builds, run with -Z external-macro-backtrace for more info)

error: use of deprecated item 'try': use the `?` operator instead
 --> 
/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
  |
154 | / bitflags! {
155 | | // While this has the same layout as u16, it cannot be passed
156 | | // over FFI safely as a u16.
157 | | #[repr(C)]
...   |
161 | | }
162 | | }
  | |_^
  |
  = note: this error originates in a macro outside of the current crate (in 
Nightly builds, run with -Z external-macro-backtrace for more info)

error: aborting due to 4 previous errors

error: could not compile `nsstring`.

___

Could someone please tell me what I am doing wrong? I have cargo and rustc 
installed, and am compiling with gcc.

Thank you for any input!

regards,

Hendrik-Jan Heins


Not sure if it is impportant: gcc on Arch is 9.2.0, on Debian 8.3.0.
But both produce the same error (as mentioned above)



Use rust 1.36. rust 1.37 might also work.

FRG


Thank you FRG!

For anyone with the same issue:
I ended up installing "rustup"
Within rustup, I installed and set rustc 1.36.0 as default
Then I built the package and after quite some time (single thread as I needed 
to see where it would potentially fail), I now have a working seamonkey-2.53.1 
on Arch.



We are trying to get latest rust support into 2.53.2 at least for Linux. 
Unfortunately rust is more or less alpha/early beta quality wrt features and 
deprecation and a constantly moving target.


FRG
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Building Seamonkey 2.53.1 error on nsstring v0.1.0, both on Devuan and on Arch Linux

2020-03-08 Thread Hendrik-Jan Heins
On Sunday, 8 March 2020 00:13:51 UTC+1, Frank-Rainer Grahl  wrote:
> hjhe...@gmail.com wrote:
> > On Saturday, 7 March 2020 23:27:45 UTC+1, hjh...@gmail.com  wrote:
> >> Hi All,
> >>
> >> I hope someone here is familiar with this issue and can point me in the 
> >> right direction. I have been trying to build Seamonkey 2.53.1 for a while 
> >> now, but to no avail. Whichever mozconfig settings I take, I always get 
> >> kicked off the build with an error on nsstring v0.10.
> >> The error is:
> >>
> >> __
> >>
> >> Compiling nsstring v0.1.0 
> >> (/home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring)
> >> error: use of deprecated item 'try': use the `?` operator instead
> >> --> 
> >> /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
> >>  |
> >> 138 | / bitflags! {
> >> 139 | | // While this has the same layout as u16, it cannot be 
> >> passed
> >> 140 | | // over FFI safely as a u16.
> >> 141 | | #[repr(C)]
> >> ...   |
> >> 149 | | }
> >> 150 | | }
> >>  | |_^
> >>  |
> >> note: lint level defined here
> >> --> 
> >> /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:116:9
> >>  |
> >> 116 | #![deny(warnings)]
> >>  | 
> >>  = note: `#[deny(deprecated)]` implied by `#[deny(warnings)]`
> >>  = note: this error originates in a macro outside of the current crate 
> >> (in Nightly builds, run with -Z external-macro-backtrace for more info)
> >>
> >> error: use of deprecated item 'try': use the `?` operator instead
> >> --> 
> >> /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:138:5
> >>  |
> >> 138 | / bitflags! {
> >> 139 | | // While this has the same layout as u16, it cannot be 
> >> passed
> >> 140 | | // over FFI safely as a u16.
> >> 141 | | #[repr(C)]
> >> ...   |
> >> 149 | | }
> >> 150 | | }
> >>  | |_^
> >>  |
> >>  = note: this error originates in a macro outside of the current crate 
> >> (in Nightly builds, run with -Z external-macro-backtrace for more info)
> >>
> >> error: use of deprecated item 'try': use the `?` operator instead
> >> --> 
> >> /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
> >>  |
> >> 154 | / bitflags! {
> >> 155 | | // While this has the same layout as u16, it cannot be 
> >> passed
> >> 156 | | // over FFI safely as a u16.
> >> 157 | | #[repr(C)]
> >> ...   |
> >> 161 | | }
> >> 162 | | }
> >>  | |_^
> >>  |
> >>  = note: this error originates in a macro outside of the current crate 
> >> (in Nightly builds, run with -Z external-macro-backtrace for more info)
> >>
> >> error: use of deprecated item 'try': use the `?` operator instead
> >> --> 
> >> /home/hjheins/build/Seamonkey/src/seamonkey-2.53.1/mozilla/xpcom/rust/nsstring/src/lib.rs:154:5
> >>  |
> >> 154 | / bitflags! {
> >> 155 | | // While this has the same layout as u16, it cannot be 
> >> passed
> >> 156 | | // over FFI safely as a u16.
> >> 157 | | #[repr(C)]
> >> ...   |
> >> 161 | | }
> >> 162 | | }
> >>  | |_^
> >>  |
> >>  = note: this error originates in a macro outside of the current crate 
> >> (in Nightly builds, run with -Z external-macro-backtrace for more info)
> >>
> >> error: aborting due to 4 previous errors
> >>
> >> error: could not compile `nsstring`.
> >>
> >> ___
> >>
> >> Could someone please tell me what I am doing wrong? I have cargo and rustc 
> >> installed, and am compiling with gcc.
> >>
> >> Thank you for any input!
> >>
> >> regards,
> >>
> >> Hendrik-Jan Heins
> > 
> > Not sure if it is impportant: gcc on Arch is 9.2.0, on Debian 8.3.0.
> > But both produce the same error (as mentioned above)
> > 
> 
> Use rust 1.36. rust 1.37 might also work.
> 
> FRG

Thank you FRG!

For anyone with the same issue:
I ended up installing "rustup"
Within rustup, I installed and set rustc 1.36.0 as default
Then I built the package and after quite some time (single thread as I needed 
to see where it would potentially fail), I now have a working seamonkey-2.53.1 
on Arch.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Is there a way to know which extensions may break when upgrading?

2020-03-08 Thread Steve Dunn

On 2020-03-08 04:43, Daniel wrote:
If "I mostly use SeaMonkey for email and newsgroups" why not use 
Thunderbird in place of SeaMonkey?? That would save using resources on 
the unused Browser portion of SM!


	Eventually that will probably be necessary, but as long as SeaMonkey 
works, there's not much of a reason to bother migrating, especially as 
my computer is not short on resources.


-Steve

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Lightning extension and cookies

2020-03-08 Thread user

Frank-Rainer Grahl a écrit :

user wrote:


Hello

It seems to exist a relation between the Ligntning extension and 
cookies in Seamonkey.


On most websites, there is no problem. But with some, there is a 
cookies problem when Lightning extension is enabled.
In such a case, it is not possible to log in, or to add products in 
the basket, and the website ask for enabling cookies in the browser.


All is ok when the Lightning extension is disabled.

The problem is the same with 2.53.1 and 2.49.5
Not tested with older Seamonkey versions.

Also checked with the same result on another computer, and with a 
brand new profile.


Why does the Lightning extension change the behaviour of the cookies 
in the browser ?


Disable "Advertize Lightning" in preferences: Advanced->HTTP Networking.

FRG



Thanks

That was the problem.

All is ok now with Lightning enabled.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Mail date format changed in 2.53.1

2020-03-08 Thread Manuel Casal Lodeiro

In 08/03/20 10:55, Manuel Casal Lodeiro dixit:

In 3/8/20 9:35 AM, mike dixit:

On 08.03.2020 08:58, Manuel Casal Lodeiro wrote:

The locale format in message headers (in Thread pane in Mail window) has
changed from previous versions after updating to 2.53.1.


In Edit/Preferences/Appearance/Date and Time Formatting you can switch
between Application locale an Regional locale. That solved it for me.


Thanks, Mike. I had been searching for such a setting but hadn't found it.

I'll close Seamonkey and start it back to see if it worked.


Worked like a charm! Thank you so much!

--
< Manuel Casal Lodeiro, (a) «Casdeiro» >

«We approach winter the most depressing period in the history
of this industrial empire, with threats of oil shortages and
energy crises. But we, as Black people, have been a source of
endless energy, endless beauty and endless determination. I
have many things to tell you about tomorrow’s love and light.
We will see you in Spring.»

  — Gil Scott-Heron (Winter in America, 1974)

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Mail date format changed in 2.53.1

2020-03-08 Thread Manuel Casal Lodeiro

In 3/8/20 9:35 AM, mike dixit:

On 08.03.2020 08:58, Manuel Casal Lodeiro wrote:

The locale format in message headers (in Thread pane in Mail window) has
changed from previous versions after updating to 2.53.1.


In Edit/Preferences/Appearance/Date and Time Formatting you can switch
between Application locale an Regional locale. That solved it for me.


Thanks, Mike. I had been searching for such a setting but hadn't found it.

I'll close Seamonkey and start it back to see if it worked.
--
< Manuel Casal Lodeiro, (a) «Casdeiro» >

«We approach winter the most depressing period in the history
of this industrial empire, with threats of oil shortages and
energy crises. But we, as Black people, have been a source of
endless energy, endless beauty and endless determination. I
have many things to tell you about tomorrow’s love and light.
We will see you in Spring.»

  — Gil Scott-Heron (Winter in America, 1974)

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Is there a way to know which extensions may break when upgrading?

2020-03-08 Thread Daniel

Steve Dunn wrote on 8/03/2020 2:49 AM:

On 2020-03-06 18:09, Ant wrote:
You could share what extensions you have and we can tell you. Here's 
mine:


 The most important ones for me are:

* JunQuilla 1.0.4
* Adblock Plus 2.9.1 (which the 2.53.1 release notes say is problematic, 
but someone else in this thread is also using)

* HTTPS Everywhere 5.2.20

 I stopped using SeaMonkey for most browsing a couple of years ago - 
Firefox is so much faster, has fewer sites that refuse to work with it, 
gets security updates much more promptly, and doesn't have to rely on 
obsolete extensions.  I mostly use SeaMonkey for email and newsgroups, 
and if some of my other extensions break, I can deal with it.


-Steve


If "I mostly use SeaMonkey for email and newsgroups" why not use 
Thunderbird in place of SeaMonkey?? That would save using resources on 
the unused Browser portion of SM!


--
Daniel

Win7 User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) 
Gecko/20100101 SeaMonkey/2.49.5 Build identifier: 20190609032134


Linux User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) 
Gecko/20100101 SeaMonkey/2.49.1 Build identifier: 20171015235623

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey


Re: Mail date format changed in 2.53.1

2020-03-08 Thread mike
On 08.03.2020 08:58, Manuel Casal Lodeiro wrote:
> The locale format in message headers (in Thread pane in Mail window) has
> changed from previous versions after updating to 2.53.1.

In Edit/Preferences/Appearance/Date and Time Formatting you can switch
between Application locale an Regional locale. That solved it for me.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey