Re: i386 version for chrome

[Gene Heskett]

On Friday 02 November 2018 23:08:52 David Wright wrote:

> On Sat 27 Oct 2018 at 11:29:35 (-0400), Gene Heskett wrote:
> > On Saturday 27 October 2018 11:03:56 Matthew Crews wrote:
> > >  Original Message 
> > > On Oct 27, 2018, 06:58, Curt wrote:
> > >
> > > On 2018-10-27, Gene Heskett  wrote:
> > > >> Might be nice, but several of the dependecies can only be
> > > >> satisfied if on stretch, and the curl command lines don't work
> > > >> on wheezy. At all.
> > > >
> > > >At any rate a curl command line that proves
> > > >inoperable on Wheezy arouses
> > > >the interest of even the most jaded observer.
> > >
> > > Correct me if I'm wrong, but Wheezy is no longer supported, and
> > > Jessie is barely supported. Except as a curiosity, why would you
> > > want to use a web browser on Wheezy these days?
> >
> > Because its main application (LinuxCNC) is married to a 32 bit
> > install, wheezy ATM.
> >
> > I understand a stretch version is being worked on, but the increased
> > latency involved in a 64 bit context switch is very very hard to
> > tolerate on real machinery. Real time kernels that actually work are
> > virtually non-existant on 64 bit machinery. I have one that almost
> > works on armhf, but it loves to throw away mouse and keyboard
> > events, but that goes away, or gets worse if you reboot.  And a good
> > reboot is good till the next power bump on that machine, running
> > Jessie..
>
> That explains why you run wheezy at all. But it doesn't explain why
> you run a web browser on wheezy or on a computer that's required to
> have good realtime performance. I thought you ran a LAN of computers
> there.
>
I do, but except for an r-pi-3b running stretch, all the rest are running 
wheezy for the same reason. There is one stretch, a bare bones armbian 
running on a rock64. And this is the only machine with a comfy office 
chair in front of its keyboard. Thats in deference to the aches & pains 
of an 84 yo body. :(

> > > Especially when the expectation of
> > > security updates and compatible software for modern web browsing
> > > is nearly, if not completely, zero.
> >
> > Its certainly getting that way.
>
> Cheers,
> David.
Thanks David.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[David Wright]

On Sat 27 Oct 2018 at 11:29:35 (-0400), Gene Heskett wrote:
> On Saturday 27 October 2018 11:03:56 Matthew Crews wrote:
> 
> >  Original Message 
> > On Oct 27, 2018, 06:58, Curt wrote:
> >
> > On 2018-10-27, Gene Heskett  wrote:
> > >> Might be nice, but several of the dependecies can only be satisfied
> > >> if on stretch, and the curl command lines don't work on wheezy. At
> > >> all.
> > >
> > >At any rate a curl command line that proves
> > >inoperable on Wheezy arouses
> > >the interest of even the most jaded observer.
> >
> > Correct me if I'm wrong, but Wheezy is no longer supported, and Jessie
> > is barely supported. Except as a curiosity, why would you want to use
> > a web browser on Wheezy these days? 
> 
> Because its main application (LinuxCNC) is married to a 32 bit install, 
> wheezy ATM.
> 
> I understand a stretch version is being worked on, but the increased 
> latency involved in a 64 bit context switch is very very hard to 
> tolerate on real machinery. Real time kernels that actually work are 
> virtually non-existant on 64 bit machinery. I have one that almost works 
> on armhf, but it loves to throw away mouse and keyboard events, but that 
> goes away, or gets worse if you reboot.  And a good reboot is good till 
> the next power bump on that machine, running Jessie..

That explains why you run wheezy at all. But it doesn't explain why you
run a web browser on wheezy or on a computer that's required to have
good realtime performance. I thought you ran a LAN of computers there.

> > Especially when the expectation of 
> > security updates and compatible software for modern web browsing is
> > nearly, if not completely, zero.
> 
> Its certainly getting that way.

Cheers,
David.

Re: i386 version for chrome

[Brian]

On Mon 29 Oct 2018 at 20:37:18 +, Brian wrote:

> about, the rewrite could be considered. Baited breath and all that.

"Bated", if preferred.

-- 
Brian.

Re: i386 version for chrome

[Brian]

On Mon 29 Oct 2018 at 16:11:01 -0400, Gene Heskett wrote:

> On Monday 29 October 2018 11:05:32 Michael Stone wrote:
> 
> > On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote:
> > >Is it a separate bug to fuss about the near total lack of meaning to
> > > the man pages for ip and its children.
> >
> > Assuming you have no substantive suggestions, it's not a bug report at
> > all, it's just complaining.
> 
> Hmmf.  If I could make an educated suggestion, but I've not got a clue as 
> to how it is supposed to work, those pages aren't a how-to, so I'd be 
> pinning the tail on the donkey just as if I was blindfolded. But this 
> isn't a party.
> 
> If printed on Northern's TP stock, then they might be good for something.
> 
> So how does one lodge a complaint that might actually be acted on?

You don't want to do that. Complaints get filed in /dev/null by Linux
Central. Now - if you completely rewrote the man page you complain
about, the rewrite could be considered. Baited breath and all that.

> You've read here, and have noted that they have not been defended by 
> anyone, and a couple posts have agreed with my assessment.

The documentation issue is a sideshow to distract from your destruction
of a sane stretch network setup.

-- 
Brian.

Re: i386 version for chrome

[John Hasler]

Just file a bug report describing what you did, what you expected to
happen, what did happen, and why you believe that the difference
constitutes a bug.  No need to include a patch.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: i386 version for chrome

[Michael Stone]

On Mon, Oct 29, 2018 at 04:11:01PM -0400, Gene Heskett wrote:

Hmmf.  If I could make an educated suggestion, but I've not got a clue as
to how it is supposed to work, those pages aren't a how-to, so I'd be
pinning the tail on the donkey just as if I was blindfolded. But this
isn't a party.

If printed on Northern's TP stock, then they might be good for something.


So you're basically just wasting our time. Got it.

Re: i386 version for chrome

[Gene Heskett]

On Monday 29 October 2018 11:05:32 Michael Stone wrote:

> On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote:
> >Is it a separate bug to fuss about the near total lack of meaning to
> > the man pages for ip and its children.
>
> Assuming you have no substantive suggestions, it's not a bug report at
> all, it's just complaining.

Hmmf.  If I could make an educated suggestion, but I've not got a clue as 
to how it is supposed to work, those pages aren't a how-to, so I'd be 
pinning the tail on the donkey just as if I was blindfolded. But this 
isn't a party.

If printed on Northern's TP stock, then they might be good for something.

So how does one lodge a complaint that might actually be acted on?

You've read here, and have noted that they have not been defended by 
anyone, and a couple posts have agreed with my assessment.

Sigh...

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Michael Stone]

On Mon, Oct 29, 2018 at 10:45:50AM -0400, Gene Heskett wrote:

Is it a separate bug to fuss about the near total lack of meaning to the
man pages for ip and its children.


Assuming you have no substantive suggestions, it's not a bug report at 
all, it's just complaining.

Re: i386 version for chrome

[Gene Heskett]

On Monday 29 October 2018 10:45:50 Gene Heskett wrote:

> On Monday 29 October 2018 08:53:35 Michael Stone wrote:
> > On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote:
> > >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:
> > >> The definition for netmask I find in that section is
> > >> netmask mask
> > >> Netmask (dotted quad or CIDR)
> > >>
> > >> which at a glance would lead me to expect a full CIDR-format
> > >> address (e.g., 192.168.1.1/24) here. That would clearly seem
> > >> redundant with the address field immediately above, but I don't
> > >> know of anything else that's consistent with CIDR notation.
> > >
> > >I agree that this part of the manpage is in dire need of good
> > > wording. I'd replace it with "Netmask (dotted quad or number of
> > > bits, eg 24)", because that's how it actually works.
> >
> > I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to
> > clarify this section. If anyone has other suggestions, please add
> > them to the bug.
> >
> > Mike Stone
>
> Is it a separate bug to fuss about the near total lack of meaning to
> the man pages for ip and its children?
added question mark



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Gene Heskett]

On Monday 29 October 2018 08:53:35 Michael Stone wrote:

> On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote:
> >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:
> >> The definition for netmask I find in that section is
> >> netmask mask
> >> Netmask (dotted quad or CIDR)
> >>
> >> which at a glance would lead me to expect a full CIDR-format
> >> address (e.g., 192.168.1.1/24) here. That would clearly seem
> >> redundant with the address field immediately above, but I don't
> >> know of anything else that's consistent with CIDR notation.
> >
> >I agree that this part of the manpage is in dire need of good
> > wording. I'd replace it with "Netmask (dotted quad or number of
> > bits, eg 24)", because that's how it actually works.
>
> I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to
> clarify this section. If anyone has other suggestions, please add them
> to the bug.
>
> Mike Stone

Is it a separate bug to fuss about the near total lack of meaning to the 
man pages for ip and its children.


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Michael Stone]

On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote:

On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:

The definition for netmask I find in that section is
netmask mask
Netmask (dotted quad or CIDR)

which at a glance would lead me to expect a full CIDR-format address
(e.g., 192.168.1.1/24) here. That would clearly seem redundant with the
address field immediately above, but I don't know of anything else
that's consistent with CIDR notation.


I agree that this part of the manpage is in dire need of good wording.
I'd replace it with "Netmask (dotted quad or number of bits, eg 24)",
because that's how it actually works.


I opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912220 to 
clarify this section. If anyone has other suggestions, please add them 
to the bug.


Mike Stone

Re: i386 version for chrome

[Michael Stone]

On Mon, Oct 29, 2018 at 08:19:54AM -0400, Gene Heskett wrote:

And amazingly to me, I read that RFC, and did not encounter the
"netmask 24" syntax anyplace in it. In any event I think all my machines
use the dotted quad representations.


It should be unsurprising that an internet RFC fails to include 
debian-specific configuration syntax.



Because of network managers love for tearing down a working network, and
leaving the scene w/o building a new working linkage, I have always:
composed my own eth0 stanza's in /e/n/i
made them immutable so nm is powerless to tear it down


network manager doesn't do that, but if making it immutable makes you 
happy, carry on. For others reading this: it's another example of 
strange things gene does on his machine that you're best off not 
copying. If you really hate network manager, just remove it. If you 
don't, it will simply ignore interfaces which have entries in 
/etc/network/interfaces.

Re: i386 version for chrome

[Gene Heskett]

On Monday 29 October 2018 07:18:44 Michael Stone wrote:

> On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote:
> >On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:
> >> The definition for netmask I find in that section is
> >> netmask mask
> >> Netmask (dotted quad or CIDR)
> >>
> >> which at a glance would lead me to expect a full CIDR-format
> >> address (e.g., 192.168.1.1/24) here. That would clearly seem
> >> redundant with the address field immediately above, but I don't
> >> know of anything else that's consistent with CIDR notation.
> >
> >I agree that this part of the manpage is in dire need of good
> > wording. I'd replace it with "Netmask (dotted quad or number of
> > bits, eg 24)", because that's how it actually works.

Absolutely.  Where I may have gone aglay is in assumeing the slash was 
part of it, perhaps as a switch to tell that 24 valid bits were assumed.
And amazingly to me, I read that RFC, and did not encounter the 
"netmask 24" syntax anyplace in it. In any event I think all my machines 
use the dotted quad representations.

Because of network managers love for tearing down a working network, and 
leaving the scene w/o building a new working linkage, I have always:
composed my own eth0 stanza's in /e/n/i
made them immutable so nm is powerless to tear it down
composed my own resolv.conf as a real file
this machine for instance:

nameserver 192.168.##.1
search  coyote.den  nameserver

and made it immutable so nm can't attempt to change it.
With a hosts file based local net, I need no local dns setups at all. 

> Mostly the netmask field should be considered a legacy interface.
> Historically, the address was only the address, and the netmask was
> the dotted-quad formatted netmask for that address. When ifupdown
> gained the ability to specify the address field in address/bits format
> (in wheezy), the netmask field was extended to also recognize cidr
> bits in addition to dotted quad.  (This also provides symmetry with
> the ipv6
> representation, where dotted quad doesn't make sense.) With the new
> address syntax the netmask field is fully redundant, but remains for
> upgrades and compatibility with old scripts/etc.

And you insist it can't work, and it has been here for years. All the 
immutable bits were required because years ago, nm was so intertwined 
with everything that it could only be removed with a root session of rm.

More recently it can be removed w/o destroying the OS. I'd offer thanks 
and a cold one to whomever fixed it so it could be removed.

What you need to learn, instead of insisting it can't work, is that 
theres more than one way to skin a cat. My recommendation is that the 
first step is to make sure its dead.
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Michael Stone]

On Sun, Oct 28, 2018 at 08:18:44PM +0300, Reco wrote:

On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:

The definition for netmask I find in that section is
netmask mask
Netmask (dotted quad or CIDR)

which at a glance would lead me to expect a full CIDR-format address
(e.g., 192.168.1.1/24) here. That would clearly seem redundant with the
address field immediately above, but I don't know of anything else
that's consistent with CIDR notation.


I agree that this part of the manpage is in dire need of good wording.
I'd replace it with "Netmask (dotted quad or number of bits, eg 24)",
because that's how it actually works.


Mostly the netmask field should be considered a legacy interface. 
Historically, the address was only the address, and the netmask was the 
dotted-quad formatted netmask for that address. When ifupdown gained the 
ability to specify the address field in address/bits format (in wheezy), 
the netmask field was extended to also recognize cidr bits in addition 
to dotted quad.  (This also provides symmetry with the ipv6 
representation, where dotted quad doesn't make sense.) With the new 
address syntax the netmask field is fully redundant, but remains for 
upgrades and compatibility with old scripts/etc.

Re: i386 version for chrome

[Michael Stone]

On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:

On Sunday 28 October 2018 08:43:33 Reco wrote:


Hi.

On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote:
> > Ever consider you're doing it the wrong way?
> > This will work:
> >
> > iface eth0 inet static
> >   address 192.168.NN.12
> >   netmask 24
> >   gateway 192.168.NN.1
>
> in 20 years, I have never seen that syntax used. What man page do I
> find that format in.

interfaces(5), the usual place.


I just checked that man page on wheezy, jessie and stretch, and no
examples are found using "netmask 24"


All of those indicate in the man page that netmask can either be a 
dotted quad or a CIDR mask length.



address 192.168.##.##/24 is supposed to be understood as netmask
255.255.255.0, and has worked here forever. And remains in the man 5
interfaces page.

And has Just Worked, until now with stretch.


Ironically, a CIDR netmask in the address was not recognized until 
wheezy, which is hardly forever. Prior to that the netmask was mandatory 
(and only recognized the dotted quad format). 


Also, I haven't ever seen an official definition of "CIDR", so its
possible I need tutoring on that. IMO any man page that uses an acronym,
needs to include its definition.


Classless Inter-Domain Routing. Since that probably didn't clear 
anything up, you likely need to do some googling. "CIDR" is probably a 
better keyword than "Classless Inter-Domain Routing" so this is a good 
example of a case where the acronym is best understood (and used) 
without expansion.

Re: i386 version for chrome

[Curt]

On 2018-10-28, Gene Heskett  wrote:
>>
>> I'm reading:
>>
>>  dns-search determines which domain is appended for dns lookups.
>>  Normally you will specify here the same domain as returned by
>> hostname -f.*
>
> Which is itself and patently wrong for this since the local dns query 
> path is supposed to be the hosts file first, and failing that ask 
> dnsmasq in the router, failing finding it in the dnsmasq cache, it gets 
> forwarded to the dns server at my ISP. And I've had it setup that way 
> since red hat 5.1 in 1998. 20 years of linux, and another 10 before that 
> with AmigaDos.
>

The only examples of the dns-search parameter I can find (besides yours)
are of the sort found in the resolv.conf wiki:  

https://wiki.debian.org/resolv.conf

 With resolvconf installed, you can tell it to do nothing whenever some daemon
 tries to modify resolv.conf, by putting resolvconf=NO in the
 /etc/resolvconf.conf file. (Note: this is not the /etc/resolv.conf file!)

 Alternatively, you can use dns-nameserver entries in the appropriate stanza in
 /etc/network/interfaces:


 iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameserver 192.168.1.254
dns-nameserver 8.8.8.8
dns-search foo.org bar.com
 
-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

Re: i386 version for chrome

[Michael Stone]

On Sun, Oct 28, 2018 at 12:18:42PM -0400, Gene Heskett wrote:

On Sunday 28 October 2018 10:51:50 Michael Stone wrote:


On Sat, Oct 27, 2018 at 10:58:49PM +, Steve McIntyre wrote:
>It *looks* like a misunderstood reference to nsswitch.conf maybe:
>
>hosts:  files dns

We've been through this before, explained it thoroughly, he never
listens, then he brings it back again and the cycle repeats. It's
impossible to debug his setup because he ignores the advice and clings
to stuff that doesn't make any sense and can't possibly work.


Except its worked for 20 years, why doesn't it work now? And if its been
changed, why is that change not noted in the man pages?


As has been explained to you over and over, it never worked. In no 
version of debian did it ever do anything like what you seem to think it 
did. But, I'm sure you'll ignore this time also.



2 good questions.


I disagree.

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 15:22:32 Brian wrote:

> On Sun 28 Oct 2018 at 12:04:54 -0400, Gene Heskett wrote:
> > Maybe its time we let this thread die, it is working now, as I have
> > other hardware problems to deal with ATM. With shipping delays
> > delays from the Chinglish writers, till around thanksgiving here in
> > the yuuh ess aye. Needless to say I've ordered spares.
>
> I am having difficulty in understanding the first part of the second
> sentence (up to the comma). Is there a derogatory aspect to it?

A light dose of snide, combined with poor proof reading, refering to the 
time it takes China Post to get a 1 oz package to me from wherever the 
maker is in China. Seems like 20-25 days is too long. Although 10 of 
this item is probably around 3 or 4 oz. The repair will not be completed 
until that package arrives, nominally 2 weeks after the rest of the 
stuff to re-build it in a brand new box is on hand. So the machine will 
be laid up for nearly a month for a failed $2.30 part, which as it 
failed blew a $20 breakout board. Classic chain reaction.

Similar to that old saw about your tv blowing $50 worth of parts (and 
labor to replace them) while protecting a 50 cent fuse.

But in this case, I'm the one that built it, so I have to look in the 
mirror to point a finger at the guilty party. ;-)

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[David]

On Sun, 28 Oct 2018 at 09:59, Gene Heskett  wrote:
> On Saturday 27 October 2018 18:49:13 Gene Heskett wrote:
> > On Saturday 27 October 2018 18:20:16 David wrote:
> > >
> > > There seems to be an ongoing theme here with lines that look like
> > >   *search hosts dns
> > > popping up in other places in Gene's system.
> > >
> > > See:
> > > https://lists.debian.org/debian-user/2017/10/msg00857.html
> > > https://lists.debian.org/debian-user/2017/10/msg00859.html
> > >
> > > Gene, the line
> > >
> > > > >dns-search hosts dns
> > >
> > > that you show above does not match anything documented by
> > > the manpages on wheezy. I checked
> > >   interfaces(5)
> > >   resolv.conf(5)
> > >   resolvconf(8)
> > >   nsswitch.conf(5)
>
> And I just noticed you were checking wheezy, but the problem is in a
> stretch install, wheezy works fine using 5 yo man pages.  Stretch does
> not, using year old man pages that are installed with stretch.

I checked wheezy only because I thought that's what you use, I didn't
read carefully enough, sorry. Regardless, it makes no difference, the
man pages say that lines
  search hosts dns
or
  dns-search hosts dns
do NOT work the way you seem to think, regardless of which file
they're in. The dns-search version that goes in /etc/network/interfaces
is documented in resolvconf(8). It does NOT accept arguments like
"hosts" or "dns", according to the man pages. I have not read the
source though.

Re: i386 version for chrome

[Brian]

On Sun 28 Oct 2018 at 12:04:54 -0400, Gene Heskett wrote:

> Maybe its time we let this thread die, it is working now, as I have other 
> hardware problems to deal with ATM. With shipping delays delays from the 
> Chinglish writers, till around thanksgiving here in the yuuh ess aye. 
> Needless to say I've ordered spares.

I am having difficulty in understanding the first part of the second
sentence (up to the comma). Is there a derogatory aspect to it?

-- 
Brian.

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 12:23:35 Reco wrote:

>   Hi.
>
> On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:
> > > On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote:
> > > > > Ever consider you're doing it the wrong way?
> > > > > This will work:
> > > > >
> > > > > iface eth0 inet static
> > > > >   address 192.168.NN.12
> > > > >   netmask 24
> > > > >   gateway 192.168.NN.1
> > > >
> > > > in 20 years, I have never seen that syntax used. What man page
> > > > do I find that format in.
> > >
> > > interfaces(5), the usual place.
> >
> > I just checked that man page on wheezy, jessie and stretch, and no
> > examples are found using "netmask 24"
>
> You asked for 'format', not 'example'.
> The 'format' is defined at netmask under INET ADDRESS FAMILY.
>
> > address 192.168.##.##/24 is supposed to be understood as netmask
> > 255.255.255.0, and has worked here forever. And remains in the man 5
> > interfaces page.
>
> True.
>
> > And has Just Worked, until now with stretch.
>
> And it does now.
>
> > Also, I haven't ever seen an official definition of "CIDR", so its
> > possible I need tutoring on that. IMO any man page that uses an
> > acronym, needs to include its definition.
>
> RFC 4632. As official as it gets.
>

So I read it. At no place in that document is netmask stated in 
the "netmask 24" format, its always as address/24 or dotted quad.
Next argument?

> > > > > ifdown eth0
> > > > > ifup -v eth0
> >
> > Will have to be done from its own keyboard unless a ; to separate
> > them.
>
> Gene, if I needed a *normal* result of this sequence I'd asked for
> one. What I've asked was a *broken* one, which does not get a default
> route as a result.
>
> So, either it did not happen, or ...?
>
> Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Brian]

On Sun 28 Oct 2018 at 12:56:13 -0400, The Wanderer wrote:

> On 2018-10-28 at 12:23, Reco wrote:
> > 
> > Gene, if I needed a *normal* result of this sequence I'd asked for
> > one. What I've asked was a *broken* one, which does not get a default
> > route as a result.
> 
> If I'm understanding what I've read in this thread to date correctly,
> he's said that the problem *only* happens at boot time, not when he
> issues commands manually.

What we know for sure is that "I installed stretch". That's like saying
"I made a curry". Someone following in the footsteps of both cookers
would have to know what the ingredients were and and whether the outcome
was a success initially. Not much point in carrying on if it wasn't.

I'd suggest that any adjustments after first installation/cooking are,
for some chefs, just as likely to degrade as to enhance the dish.

-- 
Brian.

Re: i386 version for chrome

[Reco]

Hi.

On Sun, Oct 28, 2018 at 12:56:13PM -0400, The Wanderer wrote:
> On 2018-10-28 at 12:23, Reco wrote:
> 
> > Hi.
> > 
> > On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:
> 
> [that in a previous message, Reco wrote:]
> 
> >>> interfaces(5), the usual place.
> >> 
> >> I just checked that man page on wheezy, jessie and stretch, and no 
> >> examples are found using "netmask 24"
> > 
> > You asked for 'format', not 'example'.
> > The 'format' is defined at netmask under INET ADDRESS FAMILY.
> 
> In interfaces(5), you mean?

Sure. It's the context of this part of the discussion.


> The definition for netmask I find in that section is
> netmask mask
> Netmask (dotted quad or CIDR)
> 
> which at a glance would lead me to expect a full CIDR-format address
> (e.g., 192.168.1.1/24) here. That would clearly seem redundant with the
> address field immediately above, but I don't know of anything else
> that's consistent with CIDR notation.

I agree that this part of the manpage is in dire need of good wording.
I'd replace it with "Netmask (dotted quad or number of bits, eg 24)",
because that's how it actually works.


> I'm not saying that using just the bit count in that field doesn't work;
> I haven't tested it, and I have no particular reason to doubt your
> testimony on the subject. But I don't see anything in the documentation
> which would lead me to expect it to work.
> 
> Is there something I'm missing which should lead me to that expectation?

No, you're correct. This part of a manpage is a subject to
interpretation, someone may even call it 'obscure'.


> > ifdown eth0 ifup -v eth0
> >> 
> >> Will have to be done from its own keyboard unless a ; to separate
> >> them.
> > 
> > Gene, if I needed a *normal* result of this sequence I'd asked for
> > one. What I've asked was a *broken* one, which does not get a default
> > route as a result.
> 
> If I'm understanding what I've read in this thread to date correctly,
> he's said that the problem *only* happens at boot time, not when he
> issues commands manually.

I had and I have a different impression that the problem is a persistent
one. But I may be wrong.


> If correct, that would be a reason why he wanted to know how to make the
> boot-time invocations go into the system log, so that he can review what
> they report in appropriate detail (and/or share it, for others to
> review). It would also be a reason for making the boot-time invocations
> fully verbose, at least temporarily.

If that's true, then there's no need for such drastic measures. Good old
bootlogd should cover it.

Reco

Re: i386 version for chrome

[john doe]

On 10/28/2018 5:56 PM, The Wanderer wrote:
> On 2018-10-28 at 12:23, Reco wrote:
> 
>>  Hi.
>>
>> On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:
> 
> [that in a previous message, Reco wrote:]
> 
 interfaces(5), the usual place.
>>>
>>> I just checked that man page on wheezy, jessie and stretch, and no 
>>> examples are found using "netmask 24"
>>
>> You asked for 'format', not 'example'.
>> The 'format' is defined at netmask under INET ADDRESS FAMILY.
> 
> In interfaces(5), you mean?
> 
> The definition for netmask I find in that section is
> netmask mask
> Netmask (dotted quad or CIDR)
> 
> which at a glance would lead me to expect a full CIDR-format address
> (e.g., 192.168.1.1/24) here. That would clearly seem redundant with the

TL-DR.
Don't you mean '192.168.1.0/24'?

-- 
John Doe

Re: i386 version for chrome

[The Wanderer]

On 2018-10-28 at 12:23, Reco wrote:

>   Hi.
> 
> On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:

[that in a previous message, Reco wrote:]

>>> interfaces(5), the usual place.
>> 
>> I just checked that man page on wheezy, jessie and stretch, and no 
>> examples are found using "netmask 24"
> 
> You asked for 'format', not 'example'.
> The 'format' is defined at netmask under INET ADDRESS FAMILY.

In interfaces(5), you mean?

The definition for netmask I find in that section is
netmask mask
Netmask (dotted quad or CIDR)

which at a glance would lead me to expect a full CIDR-format address
(e.g., 192.168.1.1/24) here. That would clearly seem redundant with the
address field immediately above, but I don't know of anything else
that's consistent with CIDR notation.

I'm not saying that using just the bit count in that field doesn't work;
I haven't tested it, and I have no particular reason to doubt your
testimony on the subject. But I don't see anything in the documentation
which would lead me to expect it to work.

Is there something I'm missing which should lead me to that expectation?

> ifdown eth0 ifup -v eth0
>> 
>> Will have to be done from its own keyboard unless a ; to separate
>> them.
> 
> Gene, if I needed a *normal* result of this sequence I'd asked for
> one. What I've asked was a *broken* one, which does not get a default
> route as a result.

If I'm understanding what I've read in this thread to date correctly,
he's said that the problem *only* happens at boot time, not when he
issues commands manually.

If correct, that would be a reason why he wanted to know how to make the
boot-time invocations go into the system log, so that he can review what
they report in appropriate detail (and/or share it, for others to
review). It would also be a reason for making the boot-time invocations
fully verbose, at least temporarily.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: i386 version for chrome

[Reco]

Hi.

On Sun, Oct 28, 2018 at 12:04:54PM -0400, Gene Heskett wrote:
> > On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote:
> > > > Ever consider you're doing it the wrong way?
> > > > This will work:
> > > >
> > > > iface eth0 inet static
> > > > address 192.168.NN.12
> > > > netmask 24
> > > > gateway 192.168.NN.1
> > >
> > > in 20 years, I have never seen that syntax used. What man page do I
> > > find that format in.
> >
> > interfaces(5), the usual place.
> 
> I just checked that man page on wheezy, jessie and stretch, and no 
> examples are found using "netmask 24"

You asked for 'format', not 'example'.
The 'format' is defined at netmask under INET ADDRESS FAMILY.


> address 192.168.##.##/24 is supposed to be understood as netmask 
> 255.255.255.0, and has worked here forever. And remains in the man 5 
> interfaces page.

True.


> And has Just Worked, until now with stretch.

And it does now.

> Also, I haven't ever seen an official definition of "CIDR", so its 
> possible I need tutoring on that. IMO any man page that uses an acronym, 
> needs to include its definition.

RFC 4632. As official as it gets.


> > > > ifdown eth0
> > > > ifup -v eth0
> 
> Will have to be done from its own keyboard unless a ; to separate them.

Gene, if I needed a *normal* result of this sequence I'd asked for one.
What I've asked was a *broken* one, which does not get a default route
as a result.

So, either it did not happen, or ...?

Reco

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 10:51:50 Michael Stone wrote:

> On Sat, Oct 27, 2018 at 10:58:49PM +, Steve McIntyre wrote:
> >It *looks* like a misunderstood reference to nsswitch.conf maybe:
> >
> >hosts:  files dns
>
> We've been through this before, explained it thoroughly, he never
> listens, then he brings it back again and the cycle repeats. It's
> impossible to debug his setup because he ignores the advice and clings
> to stuff that doesn't make any sense and can't possibly work.

Except its worked for 20 years, why doesn't it work now? And if its been 
changed, why is that change not noted in the man pages?

2 good questions.

If the best you can do is take pot shots at me for asking why, its best 
dropped as I've found an install that works on arm64 in armbian.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 08:43:33 Reco wrote:

>   Hi.
>
> On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote:
> > > Ever consider you're doing it the wrong way?
> > > This will work:
> > >
> > > iface eth0 inet static
> > >   address 192.168.NN.12
> > >   netmask 24
> > >   gateway 192.168.NN.1
> >
> > in 20 years, I have never seen that syntax used. What man page do I
> > find that format in.
>
> interfaces(5), the usual place.

I just checked that man page on wheezy, jessie and stretch, and no 
examples are found using "netmask 24"
address 192.168.##.##/24 is supposed to be understood as netmask 
255.255.255.0, and has worked here forever. And remains in the man 5 
interfaces page.

And has Just Worked, until now with stretch.

> > > -vvv is not documented, and I'm too lazy to dig into the source to
> > > see if it does something at all.

Normally used to expand the verbosity.  Not all of these utility's 
understand multiples means noisier. And it does not cause the called 
functions to inherit the -v, so you get no feedback from them. IMO thats 
wrong, and the -vv SHOULD cause the listed subcalls to get a -v 
invocation. But I'm not steering this ship called Linux, so my voice is 
carried away by the wind.

Also, I haven't ever seen an official definition of "CIDR", so its 
possible I need tutoring on that. IMO any man page that uses an acronym, 
needs to include its definition.

> > > ifdown eth0
> > > ifup -v eth0

Will have to be done from its own keyboard unless a ; to separate them.

That gets me:
===
root@rock64:~# ifdown eth0;ifup -v eth0
ifup: parsing file /etc/network/interfaces.d/eth0

ifup: configuring interface eth0=eth0 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/hostapd
run-parts: executing /etc/network/if-pre-up.d/ifenslave
+ [ inet = meta ]
+ IF_BOND_SLAVES=
+ [  ]
+ [  ]
+ [ -z  ]
+ exit
run-parts: executing /etc/network/if-pre-up.d/vlan
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/bin/ip addr add 192.168.##.2/255.255.255.0 broadcast 192.168.##.255  
dev eth0 label eth0
/bin/ip link set dev eth0   up
 /bin/ip route add default via 192.168.##.1  dev eth0 onlink
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/avahi-autoipd
run-parts: executing /etc/network/if-up.d/avahi-daemon
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ifenslave
+ [ inet = meta ]
+ [  ]
run-parts: executing /etc/network/if-up.d/ip
run-parts: executing /etc/network/if-up.d/openssh-server
run-parts: executing /etc/network/if-up.d/openvpn
run-parts: executing /etc/network/if-up.d/upstart
run-parts: executing /etc/network/if-up.d/wpasupplicant

and it all works again, with:
route -n
Kernel IP routing table
Destination   Gateway   Genmask Flags Metric RefUse Iface
0.0.0.0   192.168.##.1  0.0.0.0 UG0  0   0  eth0
169.254.0.0   0.0.0.0   255.255.0.0 U 1000   0   0  eth0
192.168.##.0  0.0.0.0   255.255.255.0   U 0  0   0  eth0

Thats from stretch on arm64/rock64. While booting to the armbian image 
only, debian-arm fails to set a gateway, and so does raspian. I half 
expected it not to boot raspian since the architecture was so different 
from the raspi 3b.

> > > > What log file, on stretch, would I find that trace data in?
> > >
> > > Stdout/stderr, as documented by ifup(8).
> >
> > Too volatile, scrolled off screen by the remainder of the boot. I
> > want a log file I can insert into an email. Then we'll all see whats
> > happening.
>
> Er, Gene, -v is there for user invocations, not for init scripts.
> /etc/init.d/networking uses ordinary ifup, as nobody will want seeing
> all those gory implementation details at each boot.

And they do seem to be gory, almost looks as if its looping, but not 
quite.

> > > > Theres not anything in /v/l/syslog w/o the -v.
> > >
> > > And there should not be anything about ifupdown, unless someone
> > > redirects stdout/stderr of /etc/init.d/networking to syslog.
> >
> > Howto?
>
> Don't. Simply don't. It requires wrapping with '| logger' every
> ifup/ifdown at /etc/init.d/networking.
>
> Reco

Maybe its time we let this thread die, it is working now, as I have other 
hardware problems to deal with ATM. With shipping delays delays from the 
Chinglish writers, till around thanksgiving here in the yuuh ess aye. 
Needless to say I've ordered spares.

Thanks Reco.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Michael Stone]

On Sat, Oct 27, 2018 at 10:58:49PM +, Steve McIntyre wrote:

It *looks* like a misunderstood reference to nsswitch.conf maybe:

hosts:  files dns


We've been through this before, explained it thoroughly, he never 
listens, then he brings it back again and the cycle repeats. It's 
impossible to debug his setup because he ignores the advice and clings 
to stuff that doesn't make any sense and can't possibly work.

Re: i386 version for chrome

[Michael Stone]

On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:

Sorry Steve, but your claim that its simply not true, pulls my trigger,
best to duck.


You doing it wrong and refusing to listen when people try to correct you 
is no reason for anyohne else to "duck" as if they're at fault.

Re: i386 version for chrome

[Reco]

Hi.

On Sun, Oct 28, 2018 at 07:04:02AM -0400, Gene Heskett wrote:
> > Ever consider you're doing it the wrong way?
> > This will work:
> >
> > iface eth0 inet static
> > address 192.168.NN.12
> > netmask 24
> > gateway 192.168.NN.1
> >
> in 20 years, I have never seen that syntax used. What man page do I find 
> that format in.

interfaces(5), the usual place.

> > -vvv is not documented, and I'm too lazy to dig into the source to see
> > if it does something at all.
> >
> > ifdown eth0
> > ifup -v eth0
> >
> > > What log file, on stretch, would I find that trace data in?
> >
> > Stdout/stderr, as documented by ifup(8).
> 
> Too volatile, scrolled off screen by the remainder of the boot. I want a 
> log file I can insert into an email. Then we'll all see whats happening.

Er, Gene, -v is there for user invocations, not for init scripts.
/etc/init.d/networking uses ordinary ifup, as nobody will want seeing
all those gory implementation details at each boot.


> > > Theres not anything in /v/l/syslog w/o the -v.
> >
> > And there should not be anything about ifupdown, unless someone
> > redirects stdout/stderr of /etc/init.d/networking to syslog.
> 
> Howto?

Don't. Simply don't. It requires wrapping with '| logger' every
ifup/ifdown at /etc/init.d/networking.

Reco

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 06:30:32 Reco wrote:

>   Hi.
>
> On Sun, Oct 28, 2018 at 05:59:52AM -0400, Gene Heskett wrote:
> > On Sunday 28 October 2018 02:55:09 Reco wrote:
> > >   Hi.
> > >
> > > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote:
> > > > On Saturday 27 October 2018 14:37:38 Reco wrote:
> > > > >   Hi.
> > > > >
> > > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > > > > > Then give me an install that can be made to work in a hosts
> > > > > > file defined local network that can accept a gateway
> > > > > > statement in its e/n/i file. The default install does NOT
> > > > > > accept it until the network has been brought up.
> > > > >
> > > > > In another news, you cannot have a default gateway unless it's
> > > > > reachable according to existing routing table.
> >
> > That is the problem, a route -n is without a gateway assignment and
> > has been missing since my first attempt to install stretch.
>
> Ok.
>
> > > > Its reachable, and listed in every hosts file here by both name
> > > > and address.
> > >
> > > Not before you bring up any non-local network interface.
> >
> > Then why, after giving the installer all that info, and it uses that
> > during the install, does it not have a gateway set after the initial
> > reboot or any subsequent reboot?
>
> Works for me every time I tried it, so I cannot answer that.
>
> > And nothing you can do will give it a gateway, so you wind up
> > playing 10,000 monkeys writing Shakespear, and a reboot for every
> > session of nano trying to find the magic twanger that makes it work?
> > I have made jessie work on an armhf but its been done after the
> > initial reboot.  An armbian install that claims its debian 9, is the
> > only install out of 5 or 6 from various sources including the
> > debian-arm iso twice.
> >
> > For the jessie install on an r-pi-3b, this /e/n/i works:
> >
> > auto lo
> >
> > # The loopback network interface
> > iface lo inet loopback
> > address 127.0.0.1
> > netmask 255.255.255.0
> >
> > auto eth0
> >
> > # regular network for coyote.den
> > iface eth0 inet static
> > address 192.168.NN.12
> > netmask 255.255.255.0
> > gateway 192.168.NN.1
> >
> > but it doesn't work if the interface address is given in address/24
> > format so the netmask isn't needed.
>
> Ever consider you're doing it the wrong way?
> This will work:
>
> iface eth0 inet static
>   address 192.168.NN.12
>   netmask 24
>   gateway 192.168.NN.1
>
in 20 years, I have never seen that syntax used. What man page do I find 
that format in.

> > To me, thats all the evidence needed
> > to point the guilty finger at something in the ifup code.
>
> Accusing software of something may ease one's mind, but it won't make
> it work. Usually, that is.
>
> > > > > The reason is simple - a default gateway is not 'global', the
> > > > > kernel must decide with interface to attach to a default
> > > > > gateway route. So you bring a network interface up, add an
> > > > > address to it and only then configure a default gateway.
> > > >
> > > > Then how does one guarantee its done in that order?
> > >
> > > By using ifupdown, for instance.
> > >
> > > > And what was changed
> > > > to prevent its working in the newer way of doing things?
>
> They have this wonderful principle at movie industry - show but do not
> tell.
> Please provide 'ifup -v' output that shows ifupdown misbehaviour, or
> it did not happen.

Now that I know theres a new syntax in town, I'll try it. When the next 
install fails.

> > > ifupdown works for me that way since etch was testing.
> > > If it does not - there's always troubleshooting in form of 'ifup
> > > -v'.
> >
> > As in "ifup -vvv eth0"?
>
> -vvv is not documented, and I'm too lazy to dig into the source to see
> if it does something at all.
>
> ifdown eth0
> ifup -v eth0
>
> > What log file, on stretch, would I find that trace data in?
>
> Stdout/stderr, as documented by ifup(8).

Too volatile, scrolled off screen by the remainder of the boot. I want a 
log file I can insert into an email. Then we'll all see whats happening.

> > Theres not anything in /v/l/syslog w/o the -v.
>
> And there should not be anything about ifupdown, unless someone
> redirects stdout/stderr of /etc/init.d/networking to syslog.

Howto?
>
> Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 04:53:10 Curt wrote:

> On 2018-10-27, Gene Heskett  wrote:
> >> Gene, the line
> >>
> >> > >dns-search hosts dns
> >>
> >> that you show above does not match anything documented by
> >> the manpages on wheezy. I checked
> >>   interfaces(5)
> >>   resolv.conf(5)
> >>   resolvconf(8)
> >>   nsswitch.conf(5)
> >>
> >> Gene, what are you trying to achieve with that line?
> >
> > Whatever it takes to get a working gateway at bootup. Next time I
> > reboot, I'll kill that line first. If I can't ping yahoo.com, (= no
> > gateway. so it cannot get to the internet) I'll put it back.
>
> It seems 'dns-search' is fairly well-known but undocumented, the flags
> (if that's the term) 'hosts' and 'dns' seem weird, though (and
> exclusive to your config).
>
> I'm reading:
>
>  dns-search determines which domain is appended for dns lookups.
>  Normally you will specify here the same domain as returned by
> hostname -f.*

Which is itself and patently wrong for this since the local dns query 
path is supposed to be the hosts file first, and failing that ask 
dnsmasq in the router, failing finding it in the dnsmasq cache, it gets 
forwarded to the dns server at my ISP. And I've had it setup that way 
since red hat 5.1 in 1998. 20 years of linux, and another 10 before that 
with AmigaDos.

> The dns-search entry would create a corresponding entry in
> /etc/resolv.conf (if you have resolvconf installed--or something, too
> complicated for my pea-brain).

Mine too. And resolvconf is installed by the installer, so the best you 
can do is blow away that link and make resolv.conf a real file with a 
list of nameservers topped by the search order which starts with the 
hosts file, followed by either dns or nameserver which are, or were, 
interchangeable in effect.

> Maybe you know all this already.

The above is what I've understood since my first successful linux 
install.

If its been changed then fix the man pages to reflect todays practice. 
The pages for ip are incomprehensible gibberish.

> *(As per man resolv.conf:
>
>  search Search list for host-name lookup.  The  search  list  is 
> normally determined from the local domain name; by default, it
> contains only the local domain name.  This may be changed by listing
> the desired domain search path following the search keyword with
> spaces or tabs separating  the  names.)
>
> So it seems your config would create the following entries in
> /etc/resolv.conf
>
>  nameserver 192.168.NN.1
>  search hosts dns
>
> Anyway, hope I haven't added to the confusion rather than the
> contrary.

No. you are confirming what I've been doing for 20 years, but not until 
jessie was I ever forced to put stuff that belongs in /e/resolv.conf, 
into that AND the /e/n/i/eth0 to make jessie work. The armbian stretch 
install is what gave me a working gateway. Nobody elses amd64/arm64 
install based on stretch has worked. I'll try it on an SSD in an old 
dell dimension next after dl-ing the latest iso, but right now a $2.30 
buck regulator in the BoB box driving my big mill has died a horrible 
death, spitting epoxy off the top of the chip, and probably toasted the 
BoB by applying 7x its normal vcc voltage to it while the chip was 
exploding 200 milliseconds after power up on my biggest milling machine. 
So I expect I'd better get 2 of them ordered from ebay today. I also 
bought 10 of that regulator just so I'll have spares.

Out here in the wilds of West (by God) Virginia, I'm often nearly 30 days 
acquiring service parts so when I design something, I am learning to buy 
spares, or draw it up and make it on a milling machine or lathe, 
generally writing my own gcode to make the pcb's. That I can do, but 
make stretch assign a gateway? Taint happened yet except for armbian on 
an arm64.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Reco]

Hi.

On Sun, Oct 28, 2018 at 05:59:52AM -0400, Gene Heskett wrote:
> On Sunday 28 October 2018 02:55:09 Reco wrote:
> 
> > Hi.
> >
> > On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote:
> > > On Saturday 27 October 2018 14:37:38 Reco wrote:
> > > > Hi.
> > > >
> > > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > > > > Then give me an install that can be made to work in a hosts file
> > > > > defined local network that can accept a gateway statement in its
> > > > > e/n/i file. The default install does NOT accept it until the
> > > > > network has been brought up.
> > > >
> > > > In another news, you cannot have a default gateway unless it's
> > > > reachable according to existing routing table.
> > >
> That is the problem, a route -n is without a gateway assignment and has 
> been missing since my first attempt to install stretch.

Ok.


> > > Its reachable, and listed in every hosts file here by both name and
> > > address.
> >
> > Not before you bring up any non-local network interface.
> 
> Then why, after giving the installer all that info, and it uses that 
> during the install, does it not have a gateway set after the initial 
> reboot or any subsequent reboot?

Works for me every time I tried it, so I cannot answer that.


> And nothing you can do will give it a gateway, so you wind up playing 
> 10,000 monkeys writing Shakespear, and a reboot for every session of 
> nano trying to find the magic twanger that makes it work? I have made 
> jessie work on an armhf but its been done after the initial reboot.  An 
> armbian install that claims its debian 9, is the only install out of 5 
> or 6 from various sources including the debian-arm iso twice.
> 
> For the jessie install on an r-pi-3b, this /e/n/i works:
> 
> auto lo
> 
> # The loopback network interface
> iface lo inet loopback
> address 127.0.0.1
> netmask 255.255.255.0
> 
> auto eth0
> 
> # regular network for coyote.den
> iface eth0 inet static
> address 192.168.NN.12
> netmask 255.255.255.0
> gateway 192.168.NN.1
> 
> but it doesn't work if the interface address is given in address/24 
> format so the netmask isn't needed.

Ever consider you're doing it the wrong way?
This will work:

iface eth0 inet static
address 192.168.NN.12
netmask 24
gateway 192.168.NN.1


> To me, thats all the evidence needed 
> to point the guilty finger at something in the ifup code.

Accusing software of something may ease one's mind, but it won't make it
work. Usually, that is.


> > > > The reason is simple - a default gateway is not 'global', the
> > > > kernel must decide with interface to attach to a default gateway
> > > > route. So you bring a network interface up, add an address to it
> > > > and only then configure a default gateway.
> > >
> > > Then how does one guarantee its done in that order?
> >
> > By using ifupdown, for instance.
> >
> > > And what was changed
> > > to prevent its working in the newer way of doing things?

They have this wonderful principle at movie industry - show but do not
tell.
Please provide 'ifup -v' output that shows ifupdown misbehaviour, or it
did not happen.


> > ifupdown works for me that way since etch was testing.
> > If it does not - there's always troubleshooting in form of 'ifup -v'.
> 
> As in "ifup -vvv eth0"?

-vvv is not documented, and I'm too lazy to dig into the source to see
if it does something at all.

ifdown eth0
ifup -v eth0


> What log file, on stretch, would I find that trace data in?

Stdout/stderr, as documented by ifup(8).


> Theres not anything in /v/l/syslog w/o the -v.

And there should not be anything about ifupdown, unless someone
redirects stdout/stderr of /etc/init.d/networking to syslog.

Reco

Re: i386 version for chrome

[Gene Heskett]

On Sunday 28 October 2018 02:55:09 Reco wrote:

>   Hi.
>
> On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote:
> > On Saturday 27 October 2018 14:37:38 Reco wrote:
> > >   Hi.
> > >
> > > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > > > Then give me an install that can be made to work in a hosts file
> > > > defined local network that can accept a gateway statement in its
> > > > e/n/i file. The default install does NOT accept it until the
> > > > network has been brought up.
> > >
> > > In another news, you cannot have a default gateway unless it's
> > > reachable according to existing routing table.
> >
That is the problem, a route -n is without a gateway assignment and has 
been missing since my first attempt to install stretch.

> > Its reachable, and listed in every hosts file here by both name and
> > address.
>
> Not before you bring up any non-local network interface.

Then why, after giving the installer all that info, and it uses that 
during the install, does it not have a gateway set after the initial 
reboot or any subsequent reboot?

And nothing you can do will give it a gateway, so you wind up playing 
10,000 monkeys writing Shakespear, and a reboot for every session of 
nano trying to find the magic twanger that makes it work? I have made 
jessie work on an armhf but its been done after the initial reboot.  An 
armbian install that claims its debian 9, is the only install out of 5 
or 6 from various sources including the debian-arm iso twice.

For the jessie install on an r-pi-3b, this /e/n/i works:

auto lo

# The loopback network interface
iface lo inet loopback
address 127.0.0.1
netmask 255.255.255.0

auto eth0

# regular network for coyote.den
iface eth0 inet static
address 192.168.NN.12
netmask 255.255.255.0
gateway 192.168.NN.1

but it doesn't work if the interface address is given in address/24 
format so the netmask isn't needed. To me, thats all the evidence needed 
to point the guilty finger at something in the ifup code.
>
> > > The reason is simple - a default gateway is not 'global', the
> > > kernel must decide with interface to attach to a default gateway
> > > route. So you bring a network interface up, add an address to it
> > > and only then configure a default gateway.
> >
> > Then how does one guarantee its done in that order?
>
> By using ifupdown, for instance.
>
> > And what was changed
> > to prevent its working in the newer way of doing things?
>
> ifupdown works for me that way since etch was testing.
> If it does not - there's always troubleshooting in form of 'ifup -v'.

As in "ifup -vvv eth0"?

What log file, on stretch, would I find that trace data in? Theres not 
anything in /v/l/syslog w/o the -v. And theres nothing more frustrating 
than a silent failure like this has been so far.

> Reco



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Curt]

On 2018-10-27, Gene Heskett  wrote:
>>
>> Gene, the line
>>
>> > >dns-search hosts dns
>>
>> that you show above does not match anything documented by
>> the manpages on wheezy. I checked
>>   interfaces(5)
>>   resolv.conf(5)
>>   resolvconf(8)
>>   nsswitch.conf(5)
>>
>> Gene, what are you trying to achieve with that line?
>
> Whatever it takes to get a working gateway at bootup. Next time I reboot, 
> I'll kill that line first. If I can't ping yahoo.com, (= no gateway. so 
> it cannot get to the internet) I'll put it back. 
>

It seems 'dns-search' is fairly well-known but undocumented, the flags (if
that's the term) 'hosts' and 'dns' seem weird, though (and exclusive to your
config).

I'm reading:

 dns-search determines which domain is appended for dns lookups.
 Normally you will specify here the same domain as returned by hostname -f.*

The dns-search entry would create a corresponding entry in /etc/resolv.conf (if
you have resolvconf installed--or something, too complicated for my pea-brain).

Maybe you know all this already.

*(As per man resolv.conf:

 search Search list for host-name lookup.  The  search  list  is  normally
 determined from the local domain name; by default, it contains only the local
 domain name.  This may be changed by listing the desired domain search path
 following the search keyword with spaces or tabs separating  the  names.)

So it seems your config would create the following entries in /etc/resolv.conf

 nameserver 192.168.NN.1 
 search hosts dns

Anyway, hope I haven't added to the confusion rather than the contrary.



-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

Re: i386 version for chrome

[Reco]

Hi.

On Sat, Oct 27, 2018 at 05:35:49PM -0400, Gene Heskett wrote:
> On Saturday 27 October 2018 14:37:38 Reco wrote:
> 
> > Hi.
> >
> > On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > > Then give me an install that can be made to work in a hosts file
> > > defined local network that can accept a gateway statement in its
> > > e/n/i file. The default install does NOT accept it until the network
> > > has been brought up.
> >
> > In another news, you cannot have a default gateway unless it's
> > reachable according to existing routing table.
> 
> Its reachable, and listed in every hosts file here by both name and 
> address.

Not before you bring up any non-local network interface.


> > The reason is simple - a default gateway is not 'global', the kernel
> > must decide with interface to attach to a default gateway route.
> > So you bring a network interface up, add an address to it and only
> > then configure a default gateway.
> 
> Then how does one guarantee its done in that order?

By using ifupdown, for instance.


> And what was changed 
> to prevent its working in the newer way of doing things?

ifupdown works for me that way since etch was testing.
If it does not - there's always troubleshooting in form of 'ifup -v'.

Reco

Re: i386 version for chrome

[Thomas D Dial]

On Sat, 2018-10-27 at 13:13 -0400, Gene Heskett wrote:
> On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:
> 
> > Gene Heskett wrote:
> > >On Saturday 27 October 2018 09:58:45 Curt wrote:
> > >
> > >root@coyote:/home/gene/Downloads# dpkg -i
> > >vivaldi-stable_2.1.1337.36-1_i386.deb
> > >Selecting previously unselected package vivaldi-stable.
> > >(Reading database ... 517038 files and directories currently
> > > installed.) Unpacking vivaldi-stable (from
> > > vivaldi-stable_2.1.1337.36-1_i386.deb) ...
> > >
> > >dpkg: dependency problems prevent configuration of vivaldi-stable:
> > > vivaldi-stable depends on libappindicator3-1; however:
> > >  Package libappindicator3-1 is not installed.
> > >
> > > vivaldi-stable depends on libc6 (>= 2.16); however:
> > >  Version of libc6:i386 on system is 2.13-38+deb7u12.
> > >
> > > vivaldi-stable depends on libgtk-3-0 (>= 3.9.10); however:
> > >  Version of libgtk-3-0:i386 on system is 3.4.2-7+deb7u1.
> > >
> > > vivaldi-stable depends on libpango-1.0-0 (>= 1.14.0); however:
> > >  Package libpango-1.0-0 is not installed.
> > >
> > > vivaldi-stable depends on libpangocairo-1.0-0 (>= 1.14.0);
> however:
> > >  Package libpangocairo-1.0-0 is not installed.
> > >
> > >dpkg: error processing vivaldi-stable (--install):
> > > dependency problems - leaving unconfigured
> > >Processing triggers for menu ...
> > >Processing triggers for desktop-file-utils ...
> > >Errors were encountered while processing:
> > > vivaldi-stable
> > >
> > >So its not going to work on a 32 bit wheezy, ever.
> >
> > That's hardly a surprise. Wheezy was released over 5 years ago, and
> > isn't even in LTS any more.
> >
> > >I'll update this machine to a 64 bit stretch if and when the
> network
> > >works again. Armbian is now working on a rock64, but thats the only
> > >variety of nix for arm64 that will accept and use a gateway
> statement
> > >in its net config
> >
> > You keep on asserting this, but it's patently not true. That's a
> > standard feature of Debian on all architectures. I understand you've
> > seen problems, but it just needs debugging to see how things were
> > broken in your case. :-(
> 
> Then give me an install that can be made to work in a hosts file
> defined 
> local network that can accept a gateway statement in its e/n/i file.
> The 
> default install does NOT accept it until the network has been brought 
> up.  And the syntax for the deprecated route command is too complex
> to 
> remember, then everybody wants me to use ip-(mumble) for that without 
> anything that resembles a man page to tell me how to use it for
> that.  
> Thats the singular most obtuse man pages group I've tried to make
> sense 
> of in 35+ years of making networks work starting even before Hayes 
> modems were the default.
> 
> The arm64 stretch install has, as e/n/i.d/eth0:
> 
> auto eth0
> iface eth0 inet static
> address 192.168.NN.2/24
> gateway 192.168.NN.1
> dns-nameserver 192.168.NN.1
> dns-search hosts dns
> 
> And that works, I just got it from that machine with an ssh login.
> 
> So all the stuff that used to be in e/resolv.conf is now in that
> file, 
> but no one in 2 damned years of my asking questions has ever
> mentioned 
> that its been moved or why. To add to the confusion, /etc/resolv.conf
> is 
> now a link that returns a list of nameservers only. But is there any 
> documentation for all the shuffling? Not thats been converted to a
> utf8 
> file I can peruse and learn from.

#===
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s18
iface enp0s18 inet static
  address 192.168.1.60/24
  gateway 192.168.1.1
  dns-nameserver 192.168.1.60
  dns-nameserver 192.168.1.4
  dns-search xx.org
#===
This /etc/network/interfaces file has been in use for 2+ years through
several upgrades without issues, so it might not be a really bad pattern
to look at. The nameservers at .60 and .4 are authoritative for
xx.org and refer other requests to opendns.

> 
> Sorry Steve, but your claim that its simply not true, pulls my
> trigger, 
> best to duck. And maybe fix a few man pages. Please. ;-)
> 
> -- 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 

Best wishes

Tom Dial

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 18:49:13 Gene Heskett wrote:

> On Saturday 27 October 2018 18:20:16 David wrote:
> > On Sun, 28 Oct 2018 at 05:21, Steve McIntyre  
wrote:
> > > Gene Heskett wrote:
> > > >auto eth0
> > > >iface eth0 inet static
> > > >address 192.168.NN.2/24
> > > >gateway 192.168.NN.1
> > > >dns-nameserver 192.168.NN.1
> > > >dns-search hosts dns
> > >
> > > I'm assuming that "NN" is a placeholder you've added, and not
> > > copied verbatim from the file!
> > >
> > > Otherwise, that last line looks suspect. The "dns-nameserver" and
> > > "dns-search" lines are instructions for resolvconf when setting up
> > > networking. The "dns-search" line is meant to be passed straight
> > > through into resolv.conf to set up a DNS search path. A valid
> > > example from the resolvconf man page is "dns-search foo.org
> > > bar.com". What that means is that each time you look up something
> > > that's no fully-qualified (e.g. "foo"), this machine will be
> > > looking for "foo.hosts" then "foo.dns". That's probably not what
> > > you want. However, it'll be harmless if you're looking up FQDN
> > > hostnames all the time.
> >
> > There seems to be an ongoing theme here with lines that look like
> >   *search hosts dns
> > popping up in other places in Gene's system.
> >
> > See:
> > https://lists.debian.org/debian-user/2017/10/msg00857.html
> > https://lists.debian.org/debian-user/2017/10/msg00859.html
> >
> > Gene, the line
> >
> > > >dns-search hosts dns
> >
> > that you show above does not match anything documented by
> > the manpages on wheezy. I checked
> >   interfaces(5)
> >   resolv.conf(5)
> >   resolvconf(8)
> >   nsswitch.conf(5)

And I just noticed you were checking wheezy, but the problem is in a 
stretch install, wheezy works fine using 5 yo man pages.  Stretch does 
not, using year old man pages that are installed with stretch.
 
> > Gene, what are you trying to achieve with that line?
>
> Whatever it takes to get a working gateway at bootup. Next time I
> reboot, I'll kill that line first. If I can't ping yahoo.com, (= no
> gateway. so it cannot get to the internet) I'll put it back.

Thanks David.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Steve McIntyre]

David wrote:
>On Sun, 28 Oct 2018 at 05:21, Steve McIntyre  wrote:
>
>There seems to be an ongoing theme here with lines that look like
>  *search hosts dns
>popping up in other places in Gene's system.
>
>See:
>https://lists.debian.org/debian-user/2017/10/msg00857.html
>https://lists.debian.org/debian-user/2017/10/msg00859.html
>
>Gene, the line
>> >dns-search hosts dns
>that you show above does not match anything documented by
>the manpages on wheezy. I checked
>  interfaces(5)
>  resolv.conf(5)
>  resolvconf(8)
>  nsswitch.conf(5)
>
>Gene, what are you trying to achieve with that line?

It *looks* like a misunderstood reference to nsswitch.conf maybe:

hosts:  files dns

(from my system).

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 18:20:16 David wrote:

> On Sun, 28 Oct 2018 at 05:21, Steve McIntyre  wrote:
> > Gene Heskett wrote:
> > >auto eth0
> > >iface eth0 inet static
> > >address 192.168.NN.2/24
> > >gateway 192.168.NN.1
> > >dns-nameserver 192.168.NN.1
> > >dns-search hosts dns
> >
> > I'm assuming that "NN" is a placeholder you've added, and not copied
> > verbatim from the file!
> >
> > Otherwise, that last line looks suspect. The "dns-nameserver" and
> > "dns-search" lines are instructions for resolvconf when setting up
> > networking. The "dns-search" line is meant to be passed straight
> > through into resolv.conf to set up a DNS search path. A valid
> > example from the resolvconf man page is "dns-search foo.org
> > bar.com". What that means is that each time you look up something
> > that's no fully-qualified (e.g. "foo"), this machine will be looking
> > for "foo.hosts" then "foo.dns". That's probably not what you
> > want. However, it'll be harmless if you're looking up FQDN hostnames
> > all the time.
>
> There seems to be an ongoing theme here with lines that look like
>   *search hosts dns
> popping up in other places in Gene's system.
>
> See:
> https://lists.debian.org/debian-user/2017/10/msg00857.html
> https://lists.debian.org/debian-user/2017/10/msg00859.html
>
> Gene, the line
>
> > >dns-search hosts dns
>
> that you show above does not match anything documented by
> the manpages on wheezy. I checked
>   interfaces(5)
>   resolv.conf(5)
>   resolvconf(8)
>   nsswitch.conf(5)
>
> Gene, what are you trying to achieve with that line?

Whatever it takes to get a working gateway at bootup. Next time I reboot, 
I'll kill that line first. If I can't ping yahoo.com, (= no gateway. so 
it cannot get to the internet) I'll put it back. 


-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Brian]

On Sat 27 Oct 2018 at 17:21:43 -0400, Gene Heskett wrote:

> On Saturday 27 October 2018 14:21:23 Steve McIntyre wrote:
> 
> > Gene Heskett wrote:
> > >On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:
> > >> You keep on asserting this, but it's patently not true. That's a
> > >> standard feature of Debian on all architectures. I understand
> > >> you've seen problems, but it just needs debugging to see how things
> > >> were broken in your case. :-(
> > >
> > >Then give me an install that can be made to work in a hosts file
> > > defined local network that can accept a gateway statement in its
> > > e/n/i file. The default install does NOT accept it until the network
> > > has been brought up.  And the syntax for the deprecated route
> > > command is too complex to remember, then everybody wants me to use
> > > ip-(mumble) for that without anything that resembles a man page to
> > > tell me how to use it for that. Thats the singular most obtuse man
> > > pages group I've tried to make sense of in 35+ years of making
> > > networks work starting even before Hayes modems were the default.
> >
> > Right. The ip-* man pages are atrocious, I won't argue - they're
> > basically not human-readable. :-(
> 
> And who might we beat about the brow over that, I've already got the elm 
> club for that job carved. :)

Not really on topic but that's in tune with many of your posts. Violence
is never a solution. (Your smiley doesn't take the edge off the implied
threat).
> 
> -- 
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 

-- 
Since 1968, more than 1.5 million Americans have died in gun-related
  
incidents in the USA. More than have been killed in war in US history.
Defending freedom has a high price.

Re: i386 version for chrome

[David]

On Sun, 28 Oct 2018 at 05:21, Steve McIntyre  wrote:
> Gene Heskett wrote:
>
> >auto eth0
> >iface eth0 inet static
> >address 192.168.NN.2/24
> >gateway 192.168.NN.1
> >dns-nameserver 192.168.NN.1
> >dns-search hosts dns
>
> I'm assuming that "NN" is a placeholder you've added, and not copied
> verbatim from the file!
>
> Otherwise, that last line looks suspect. The "dns-nameserver" and
> "dns-search" lines are instructions for resolvconf when setting up
> networking. The "dns-search" line is meant to be passed straight
> through into resolv.conf to set up a DNS search path. A valid example
> from the resolvconf man page is "dns-search foo.org bar.com". What
> that means is that each time you look up something that's no
> fully-qualified (e.g. "foo"), this machine will be looking for
> "foo.hosts" then "foo.dns". That's probably not what you
> want. However, it'll be harmless if you're looking up FQDN hostnames
> all the time.

There seems to be an ongoing theme here with lines that look like
  *search hosts dns
popping up in other places in Gene's system.

See:
https://lists.debian.org/debian-user/2017/10/msg00857.html
https://lists.debian.org/debian-user/2017/10/msg00859.html

Gene, the line
> >dns-search hosts dns
that you show above does not match anything documented by
the manpages on wheezy. I checked
  interfaces(5)
  resolv.conf(5)
  resolvconf(8)
  nsswitch.conf(5)

Gene, what are you trying to achieve with that line?

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 15:52:53 Matthew Crews wrote:

> ‐‐‐ Original Message ‐‐‐
>
> On Saturday, October 27, 2018 8:29 AM, Gene Heskett 
 wrote:
> > On Saturday 27 October 2018 11:03:56 Matthew Crews wrote:
> > > Correct me if I'm wrong, but Wheezy is no longer supported, and
> > > Jessie is barely supported. Except as a curiosity, why would you
> > > want to use a web browser on Wheezy these days?
> >
> > Because its main application (LinuxCNC) is married to a 32 bit
> > install, wheezy ATM.
>
> Gotcha, I suspected it was something like that.
>
> I personally wouldn't connect such a device to the internet unless I
> had to, or if I had firewalls configured correctly. But I'm going to
> assume you know what you're doing in that regard :)
>
> I would prepare for the inevitable time when a Chromium-based web
> browser simply becomes unsupported on i386.
>
> Also I was incorrect about Wheezy support. It still has commercial
> Extended LTS support for another seven months.
> https://wiki.debian.org/LTS/Extended Looks like the LinuxCNC folks
> will need to plan on migrating to a later version of Debian soon.

They are working on it. For stretch. The problem is that its also 
expected to run on 25+ yo hardware too. Telling some shop owner who 
isn't computer literate, that he has to pop for a new computer, and a 
consultant to come in and make it work, upping the cost for that new 
hardware and the consultant to marry it all together, brings the cost of 
free software to often north of 5 grand per machine since the consultant 
likes to eat and have a warm place to sleep while he is doing it.

He, not figuring on that, will junk the machine and buy a new one with a 
fanuc control, for 30-60 grand just to get that spot on the floor back 
to making money, but with 20% of linuxcnc's capability (but his 
machinists can understand the loss as that loss of capability translates 
into lost piecework bonuses for them). Fanuc and several others treat 
the specialty stuff that LCNC can do OOTB as extra fee addons that 
because the shop owner is not savvy, costs him a bunch. So the LCNC 
developers have to jump thru burning hoops to try and recover the lost 
latency that jumping to a 64 bit kernel costs them. I'm not doing the 
broadcast consulant scene anymore, not at 84 and taking care of a wife 
dying from copd.

I think the characterization is "between a rock and a hard place".

Thanks Matthew.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 14:37:38 Reco wrote:

>   Hi.
>
> On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> > Then give me an install that can be made to work in a hosts file
> > defined local network that can accept a gateway statement in its
> > e/n/i file. The default install does NOT accept it until the network
> > has been brought up.
>
> In another news, you cannot have a default gateway unless it's
> reachable according to existing routing table.

Its reachable, and listed in every hosts file here by both name and 
address.

> The reason is simple - a default gateway is not 'global', the kernel
> must decide with interface to attach to a default gateway route.
> So you bring a network interface up, add an address to it and only
> then configure a default gateway.

Then how does one guarantee its done in that order? And what was changed 
to prevent its working in the newer way of doing things?

> And that's not specific to a Linux, it works that way in any OS I've
> seen so far.

Windows, since xp anyway, must have an internal sequence for that as I 
have yet to have any trouble setting up a gateway assignment in any of 
the neighbors windows boxen. Thats not even a major reason I don't allow 
a windows install on the property any longer than it takes to fix up 
their fumble fingers attempts to make it connect to their cable or dsl 
modem.

> Reco

Thanks Reco.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 14:21:23 Steve McIntyre wrote:

> Gene Heskett wrote:
> >On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:
> >> You keep on asserting this, but it's patently not true. That's a
> >> standard feature of Debian on all architectures. I understand
> >> you've seen problems, but it just needs debugging to see how things
> >> were broken in your case. :-(
> >
> >Then give me an install that can be made to work in a hosts file
> > defined local network that can accept a gateway statement in its
> > e/n/i file. The default install does NOT accept it until the network
> > has been brought up.  And the syntax for the deprecated route
> > command is too complex to remember, then everybody wants me to use
> > ip-(mumble) for that without anything that resembles a man page to
> > tell me how to use it for that. Thats the singular most obtuse man
> > pages group I've tried to make sense of in 35+ years of making
> > networks work starting even before Hayes modems were the default.
>
> Right. The ip-* man pages are atrocious, I won't argue - they're
> basically not human-readable. :-(

And who might we beat about the brow over that, I've already got the elm 
club for that job carved. :)

> >The arm64 stretch install has, as e/n/i.d/eth0:
>
> Checking: is that straight Debian stretch, or some derivative?
Armbian I believe, Steve, thats what the default xfce login gui says 
anyway, but a cat /etc/issue says:
gene@rock64:~$ cat /etc/issue
Debian GNU/Linux 9 \n \l,
and a uname -a:
gene@rock64:~$ uname -a
Linux rock64 4.4.124-rk3328 #24 SMP Wed Mar 28 17:15:52 CEST 2018 aarch64 
GNU/Linux

> >auto eth0
> >iface eth0 inet static
> >address 192.168.NN.2/24
> >gateway 192.168.NN.1
> >dns-nameserver 192.168.NN.1
> >dns-search hosts dns
>
> I'm assuming that "NN" is a placeholder you've added, and not copied
> verbatim from the file!

Of course, I don't really want to give the farm to the first hacker that 
gets thru dd-wrt (which FWIW has yet to occur in 15+ years of having it 
standing guard here).

> Otherwise, that last line looks suspect. The "dns-nameserver" and
> "dns-search" lines are instructions for resolvconf when setting up
> networking. The "dns-search" line is meant to be passed straight
> through into resolv.conf to set up a DNS search path. A valid example
> from the resolvconf man page is "dns-search foo.org bar.com". What
> that means is that each time you look up something that's no
> fully-qualified (e.g. "foo"), this machine will be looking for
> "foo.hosts" then "foo.dns". That's probably not what you
> want. However, it'll be harmless if you're looking up FQDN hostnames
> all the time.
>
> >And that works, I just got it from that machine with an ssh login.
> >
> >So all the stuff that used to be in e/resolv.conf is now in that
> > file, but no one in 2 damned years of my asking questions has ever
> > mentioned that its been moved or why. To add to the confusion,
> > /etc/resolv.conf is now a link that returns a list of nameservers
> > only. But is there any documentation for all the shuffling? Not
> > thats been converted to a utf8 file I can peruse and learn from.
>
> This is down to the resolvconf package, which is often pulled in via
> Recommends: from other packages. For a simple network with simple
> needs, you shouldn't need to use it. It should work for you,
> though. It manages resolv.conf, hence wanting to move the normal
> config from that file.
>
> If you *don't* have resolvconf installed, putting the details in
> /etc/resolv.conf still works, and it's how I configure static things
> on my own network (e.g. on the gateway/router box).
>
> >Sorry Steve, but your claim that its simply not true, pulls my
> > trigger, best to duck.
>
> I understand - I've seen you're struggling, but I know this stuff
> works on lots of other machines. There's nothing broken here on
> standard Debian on any architecture that I know of. *However*,
> remotely debugging what other thing might be causing your woes is
> really difficult.

I've considered enableing dhcpd in the router, and matching the mac to 
the address issued. I did have that setup years ago to service my old 
lappy but that only worked around 25% of the time, and since I am no 
longer playing visiting fireman at other tv stations, its now hard coded 
in the hosts files which works unless the cat5 has been cut. In 15 years 
of blowing in the wind that piece of cat5 is still doing 100 megabaud 
over 45 feet of it to the shop building. I'm suitably amazed, as its 
survived 110+ mph winds that it took $18K to fix up the rest of the 
damages to the house and fencing, took out 3.5 40+ foot pines too. I 
finally took out the half of the 4th one last year as it was looking 
uglier by the year.

Back on topic, sorta.

The last time I tried a debian-arm as a dl and write to the sd card, 
failed just like the amd64 versions, plus armbian doesn't hard code the 
first user=1000, which IMNSHO is just inexcusable breakage by 

Re: i386 version for chrome

[Matthew Crews]

‐‐‐ Original Message ‐‐‐
On Saturday, October 27, 2018 8:29 AM, Gene Heskett  
wrote:

> On Saturday 27 October 2018 11:03:56 Matthew Crews wrote:
>
> > Correct me if I'm wrong, but Wheezy is no longer supported, and Jessie
> > is barely supported. Except as a curiosity, why would you want to use
> > a web browser on Wheezy these days?
>
> Because its main application (LinuxCNC) is married to a 32 bit install,
> wheezy ATM.
>

Gotcha, I suspected it was something like that.

I personally wouldn't connect such a device to the internet unless I had to, or 
if I had firewalls configured correctly. But I'm going to assume you know what 
you're doing in that regard :)

I would prepare for the inevitable time when a Chromium-based web browser 
simply becomes unsupported on i386.

Also I was incorrect about Wheezy support. It still has commercial Extended LTS 
support for another seven months. https://wiki.debian.org/LTS/Extended
Looks like the LinuxCNC folks will need to plan on migrating to a later version 
of Debian soon.

Re: i386 version for chrome

[Reco]

Hi.

On Sat, Oct 27, 2018 at 01:13:07PM -0400, Gene Heskett wrote:
> Then give me an install that can be made to work in a hosts file defined 
> local network that can accept a gateway statement in its e/n/i file. The 
> default install does NOT accept it until the network has been brought 
> up.

In another news, you cannot have a default gateway unless it's reachable
according to existing routing table.
The reason is simple - a default gateway is not 'global', the kernel
must decide with interface to attach to a default gateway route.
So you bring a network interface up, add an address to it and only then
configure a default gateway.
And that's not specific to a Linux, it works that way in any OS I've
seen so far.

Reco

Re: i386 version for chrome

[Steve McIntyre]

Gene Heskett wrote:
>On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:
>>
>> You keep on asserting this, but it's patently not true. That's a
>> standard feature of Debian on all architectures. I understand you've
>> seen problems, but it just needs debugging to see how things were
>> broken in your case. :-(
>
>Then give me an install that can be made to work in a hosts file defined 
>local network that can accept a gateway statement in its e/n/i file. The 
>default install does NOT accept it until the network has been brought 
>up.  And the syntax for the deprecated route command is too complex to 
>remember, then everybody wants me to use ip-(mumble) for that without 
>anything that resembles a man page to tell me how to use it for that.  
>Thats the singular most obtuse man pages group I've tried to make sense 
>of in 35+ years of making networks work starting even before Hayes 
>modems were the default.

Right. The ip-* man pages are atrocious, I won't argue - they're
basically not human-readable. :-(

>The arm64 stretch install has, as e/n/i.d/eth0:

Checking: is that straight Debian stretch, or some derivative?

>auto eth0
>iface eth0 inet static
>address 192.168.NN.2/24
>gateway 192.168.NN.1
>dns-nameserver 192.168.NN.1
>dns-search hosts dns

I'm assuming that "NN" is a placeholder you've added, and not copied
verbatim from the file!

Otherwise, that last line looks suspect. The "dns-nameserver" and
"dns-search" lines are instructions for resolvconf when setting up
networking. The "dns-search" line is meant to be passed straight
through into resolv.conf to set up a DNS search path. A valid example
from the resolvconf man page is "dns-search foo.org bar.com". What
that means is that each time you look up something that's no
fully-qualified (e.g. "foo"), this machine will be looking for
"foo.hosts" then "foo.dns". That's probably not what you
want. However, it'll be harmless if you're looking up FQDN hostnames
all the time.

>And that works, I just got it from that machine with an ssh login.
>
>So all the stuff that used to be in e/resolv.conf is now in that file, 
>but no one in 2 damned years of my asking questions has ever mentioned 
>that its been moved or why. To add to the confusion, /etc/resolv.conf is 
>now a link that returns a list of nameservers only. But is there any 
>documentation for all the shuffling? Not thats been converted to a utf8 
>file I can peruse and learn from.

This is down to the resolvconf package, which is often pulled in via
Recommends: from other packages. For a simple network with simple
needs, you shouldn't need to use it. It should work for you,
though. It manages resolv.conf, hence wanting to move the normal
config from that file.

If you *don't* have resolvconf installed, putting the details in
/etc/resolv.conf still works, and it's how I configure static things
on my own network (e.g. on the gateway/router box).

>Sorry Steve, but your claim that its simply not true, pulls my trigger, 
>best to duck.

I understand - I've seen you're struggling, but I know this stuff
works on lots of other machines. There's nothing broken here on
standard Debian on any architecture that I know of. *However*,
remotely debugging what other thing might be causing your woes is
really difficult.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 11:09:48 Steve McIntyre wrote:

> Gene Heskett wrote:
> >On Saturday 27 October 2018 09:58:45 Curt wrote:
> >
> >root@coyote:/home/gene/Downloads# dpkg -i
> >vivaldi-stable_2.1.1337.36-1_i386.deb
> >Selecting previously unselected package vivaldi-stable.
> >(Reading database ... 517038 files and directories currently
> > installed.) Unpacking vivaldi-stable (from
> > vivaldi-stable_2.1.1337.36-1_i386.deb) ...
> >
> >dpkg: dependency problems prevent configuration of vivaldi-stable:
> > vivaldi-stable depends on libappindicator3-1; however:
> >  Package libappindicator3-1 is not installed.
> >
> > vivaldi-stable depends on libc6 (>= 2.16); however:
> >  Version of libc6:i386 on system is 2.13-38+deb7u12.
> >
> > vivaldi-stable depends on libgtk-3-0 (>= 3.9.10); however:
> >  Version of libgtk-3-0:i386 on system is 3.4.2-7+deb7u1.
> >
> > vivaldi-stable depends on libpango-1.0-0 (>= 1.14.0); however:
> >  Package libpango-1.0-0 is not installed.
> >
> > vivaldi-stable depends on libpangocairo-1.0-0 (>= 1.14.0); however:
> >  Package libpangocairo-1.0-0 is not installed.
> >
> >dpkg: error processing vivaldi-stable (--install):
> > dependency problems - leaving unconfigured
> >Processing triggers for menu ...
> >Processing triggers for desktop-file-utils ...
> >Errors were encountered while processing:
> > vivaldi-stable
> >
> >So its not going to work on a 32 bit wheezy, ever.
>
> That's hardly a surprise. Wheezy was released over 5 years ago, and
> isn't even in LTS any more.
>
> >I'll update this machine to a 64 bit stretch if and when the network
> >works again. Armbian is now working on a rock64, but thats the only
> >variety of nix for arm64 that will accept and use a gateway statement
> >in its net config
>
> You keep on asserting this, but it's patently not true. That's a
> standard feature of Debian on all architectures. I understand you've
> seen problems, but it just needs debugging to see how things were
> broken in your case. :-(

Then give me an install that can be made to work in a hosts file defined 
local network that can accept a gateway statement in its e/n/i file. The 
default install does NOT accept it until the network has been brought 
up.  And the syntax for the deprecated route command is too complex to 
remember, then everybody wants me to use ip-(mumble) for that without 
anything that resembles a man page to tell me how to use it for that.  
Thats the singular most obtuse man pages group I've tried to make sense 
of in 35+ years of making networks work starting even before Hayes 
modems were the default.

The arm64 stretch install has, as e/n/i.d/eth0:

auto eth0
iface eth0 inet static
address 192.168.NN.2/24
gateway 192.168.NN.1
dns-nameserver 192.168.NN.1
dns-search hosts dns

And that works, I just got it from that machine with an ssh login.

So all the stuff that used to be in e/resolv.conf is now in that file, 
but no one in 2 damned years of my asking questions has ever mentioned 
that its been moved or why. To add to the confusion, /etc/resolv.conf is 
now a link that returns a list of nameservers only. But is there any 
documentation for all the shuffling? Not thats been converted to a utf8 
file I can peruse and learn from.

Sorry Steve, but your claim that its simply not true, pulls my trigger, 
best to duck. And maybe fix a few man pages. Please. ;-)

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Curt]

On 2018-10-27, Pierre Frenkiel  wrote:
> On Sat, 27 Oct 2018, Curt wrote:
>
>> At any rate a curl command line that proves inoperable on Wheezy arouses
>> the interest of even the most jaded observer.
>
>I found it on Stretch, but was unable to use it for a ftp transfer,
>while ncftp works like a charm.

That's interesting.

> best regards,


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 11:03:56 Matthew Crews wrote:

>  Original Message 
> On Oct 27, 2018, 06:58, Curt wrote:
>
> On 2018-10-27, Gene Heskett  wrote:
> >> Might be nice, but several of the dependecies can only be satisfied
> >> if on stretch, and the curl command lines don't work on wheezy. At
> >> all.
> >
> >At any rate a curl command line that proves
> >inoperable on Wheezy arouses
> >the interest of even the most jaded observer.
>
> Correct me if I'm wrong, but Wheezy is no longer supported, and Jessie
> is barely supported. Except as a curiosity, why would you want to use
> a web browser on Wheezy these days? 

Because its main application (LinuxCNC) is married to a 32 bit install, 
wheezy ATM.

I understand a stretch version is being worked on, but the increased 
latency involved in a 64 bit context switch is very very hard to 
tolerate on real machinery. Real time kernels that actually work are 
virtually non-existant on 64 bit machinery. I have one that almost works 
on armhf, but it loves to throw away mouse and keyboard events, but that 
goes away, or gets worse if you reboot.  And a good reboot is good till 
the next power bump on that machine, running Jessie..

> Especially when the expectation of 
> security updates and compatible software for modern web browsing is
> nearly, if not completely, zero.

Its certainly getting that way.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Steve McIntyre]

Gene Heskett wrote:
>On Saturday 27 October 2018 09:58:45 Curt wrote:
>
>root@coyote:/home/gene/Downloads# dpkg -i 
>vivaldi-stable_2.1.1337.36-1_i386.deb
>Selecting previously unselected package vivaldi-stable.
>(Reading database ... 517038 files and directories currently installed.)
>Unpacking vivaldi-stable (from vivaldi-stable_2.1.1337.36-1_i386.deb) ...
>
>dpkg: dependency problems prevent configuration of vivaldi-stable:
> vivaldi-stable depends on libappindicator3-1; however:
>  Package libappindicator3-1 is not installed.
>
> vivaldi-stable depends on libc6 (>= 2.16); however:
>  Version of libc6:i386 on system is 2.13-38+deb7u12.
>
> vivaldi-stable depends on libgtk-3-0 (>= 3.9.10); however:
>  Version of libgtk-3-0:i386 on system is 3.4.2-7+deb7u1.
>
> vivaldi-stable depends on libpango-1.0-0 (>= 1.14.0); however:
>  Package libpango-1.0-0 is not installed.
>
> vivaldi-stable depends on libpangocairo-1.0-0 (>= 1.14.0); however:
>  Package libpangocairo-1.0-0 is not installed.
>
>dpkg: error processing vivaldi-stable (--install):
> dependency problems - leaving unconfigured
>Processing triggers for menu ...
>Processing triggers for desktop-file-utils ...
>Errors were encountered while processing:
> vivaldi-stable
>
>So its not going to work on a 32 bit wheezy, ever.

That's hardly a surprise. Wheezy was released over 5 years ago, and
isn't even in LTS any more.

>I'll update this machine to a 64 bit stretch if and when the network
>works again. Armbian is now working on a rock64, but thats the only
>variety of nix for arm64 that will accept and use a gateway statement
>in its net config

You keep on asserting this, but it's patently not true. That's a
standard feature of Debian on all architectures. I understand you've
seen problems, but it just needs debugging to see how things were
broken in your case. :-(
 
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: i386 version for chrome

[Matthew Crews]

 Original Message 
On Oct 27, 2018, 06:58, Curt wrote:

On 2018-10-27, Gene Heskett  wrote:

>
>> Might be nice, but several of the dependecies can only be satisfied if on
>> stretch, and the curl command lines don't work on wheezy. At all.
>>

>At any rate a curl command line that proves
>inoperable on Wheezy arouses
>the interest of even the most jaded observer.

Correct me if I'm wrong, but Wheezy is no longer supported, and Jessie is 
barely supported. Except as a curiosity, why would you want to use a web 
browser on Wheezy these days? Especially when the expectation of security 
updates and compatible software for modern web browsing is nearly, if not 
completely, zero.

Re: i386 version for chrome

[Pierre Frenkiel]

On Sat, 27 Oct 2018, Curt wrote:


At any rate a curl command line that proves inoperable on Wheezy arouses
the interest of even the most jaded observer.


  I found it on Stretch, but was unable to use it for a ftp transfer,
  while ncftp works like a charm.

best regards,
--
Pierre Frenkiel

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 09:58:45 Curt wrote:

> On 2018-10-27, Gene Heskett  wrote:
> >> These folks appear to have found some kind of workaround for the
> >> https prefixation syndrome:
> >>
> >> https://forum.vivaldi.net/topic/28038/how-to-set-a-local-file-as-ho
> >>me- page
> >>
> >> > best regards,
> >
> > Might be nice, but several of the dependecies can only be satisfied
> > if on stretch, and the curl command lines don't work on wheezy.  At
> > all.
>
> Gnomic. I searched the cited page for 'curl' and didn't find one
> reference to it; then I realized you were talking about something else
> but remain uncertain exactly what.
>
> At any rate a curl command line that proves inoperable on Wheezy
> arouses the interest of even the most jaded observer.

f you goto the vivaladi page, and look up its helpers, it gives a 
loong curl command to fetch them, but pasted into bash shell and 
return is pressed, you wind up with zero action and an empty prompt. A 
ctl+c gets you back your normal prompt. But thats all experimental any 
way since dpkg outputs quite a string of its own dependencies not met:

root@coyote:/home/gene/Downloads# dpkg -i 
vivaldi-stable_2.1.1337.36-1_i386.deb
Selecting previously unselected package vivaldi-stable.
(Reading database ... 517038 files and directories currently installed.)
Unpacking vivaldi-stable (from vivaldi-stable_2.1.1337.36-1_i386.deb) ...

dpkg: dependency problems prevent configuration of vivaldi-stable:
 vivaldi-stable depends on libappindicator3-1; however:
  Package libappindicator3-1 is not installed.

 vivaldi-stable depends on libc6 (>= 2.16); however:
  Version of libc6:i386 on system is 2.13-38+deb7u12.

 vivaldi-stable depends on libgtk-3-0 (>= 3.9.10); however:
  Version of libgtk-3-0:i386 on system is 3.4.2-7+deb7u1.

 vivaldi-stable depends on libpango-1.0-0 (>= 1.14.0); however:
  Package libpango-1.0-0 is not installed.

 vivaldi-stable depends on libpangocairo-1.0-0 (>= 1.14.0); however:
  Package libpangocairo-1.0-0 is not installed.

dpkg: error processing vivaldi-stable (--install):
 dependency problems - leaving unconfigured
Processing triggers for menu ...
Processing triggers for desktop-file-utils ...
Errors were encountered while processing:
 vivaldi-stable

So its not going to work on a 32 bit wheezy, ever. I'll update this 
machine to a 64 bit stretch if and when the network works again. Armbian 
is now working on a rock64, but thats the only variety of nix for arm64 
that will accept and use a gateway statement in its net config and it 
took me a week to make that work. I put another drive in an older dell 
dimension and installed 64 bit stretch, but was never able to get it to 
accept a gateway statement. No errors, it just ignores it unless applied 
by hand using route. So its back on the old wheezy drive which Just 
Works(TM)  That machine isn't quite sacrificial as its the box I use to 
program the mesa fpga based CNC cards, so its needed eventually. Its 
actually got a parport! And them is scarce on new machines today. :(

Thanks Curt.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Curt]

On 2018-10-27, Gene Heskett  wrote:
>>
>> These folks appear to have found some kind of workaround for the https
>> prefixation syndrome:
>>
>> https://forum.vivaldi.net/topic/28038/how-to-set-a-local-file-as-home-
>>page
>>
>> > best regards,
>
> Might be nice, but several of the dependecies can only be satisfied if on 
> stretch, and the curl command lines don't work on wheezy.  At all.
>

Gnomic. I searched the cited page for 'curl' and didn't find one
reference to it; then I realized you were talking about something else
but remain uncertain exactly what.

At any rate a curl command line that proves inoperable on Wheezy arouses
the interest of even the most jaded observer.

-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

Re: i386 version for chrome

[tony]

On 27/10/2018 13:24, Pierre Frenkiel wrote:
> On Sat, 27 Oct 2018, Roberto C. S?nchez wrote:
> 
>> Did you try an absolute path?
>>
>> file:///home/user/bookmarks.html
>   I tried it, and also file://~user...
> 

I set my home page to http://localhost/index.shtml

Cheers, Tony

Re: i386 version for chrome

[Gene Heskett]

On Saturday 27 October 2018 08:05:13 Curt wrote:

> On 2018-10-27, Pierre Frenkiel  wrote:
> > On Sat, 27 Oct 2018, Roberto C. S?nchez wrote:
> >> Did you try an absolute path?
> >>
> >> file:///home/user/bookmarks.html
> >
> >I tried it, and also file://~user...
> >
> >but the problem is not there, but in the fact that, as I said,
> >it puts a https:// before..
> >which of course can't work
> >
> >Anyway, what interested me was the additional features that
> > chrome adds to chromium.
>
> These folks appear to have found some kind of workaround for the https
> prefixation syndrome:
>
> https://forum.vivaldi.net/topic/28038/how-to-set-a-local-file-as-home-
>page
>
> > best regards,

Might be nice, but several of the dependecies can only be satisfied if on 
stretch, and the curl command lines don't work on wheezy.  At all.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: i386 version for chrome

[Pierre Frenkiel]

On Sat, 27 Oct 2018, Matthew Crews wrote:


Use Chromium instead of Chrome. Chrome is actually based on Chromium.
i386 versions of Chromium are in the Debian repos.


  It's what I do since several years, but I saw that:

 The biggest difference between the two browsers is that, while Chrome is
 based on Chromium, Google also adds a number of proprietary features to
 Chrome like automatic updates and support for additional video formats.

  Unfortunately, they only provide a 64 bit version.

best regards,
--
Pierre Frenkiel

Re: i386 version for chrome

[Curt]

On 2018-10-27, Pierre Frenkiel  wrote:
> On Sat, 27 Oct 2018, Roberto C. S?nchez wrote:
>
>> Did you try an absolute path?
>>
>> file:///home/user/bookmarks.html
>I tried it, and also file://~user...
>
>but the problem is not there, but in the fact that, as I said,
>it puts a https:// before..
>which of course can't work
>
>Anyway, what interested me was the additional features that chrome
>adds to chromium.

These folks appear to have found some kind of workaround for the https
prefixation syndrome:

https://forum.vivaldi.net/topic/28038/how-to-set-a-local-file-as-home-page


> best regards,


-- 
"Now she understood that Anna could not have been in lilac, and that her charm
was just that she always stood out against her attire, that her dress could
never be noticeable on her." Leo Tolstoy, Anna Karenina 

Re: i386 version for chrome

[Matthew Crews]

On 10/27/18 1:19 AM, Pierre Frenkiel wrote:
> hi,
> I wanted to install chrome on my intel desktop, but the only version I found
> is amd64.
> Is it possible to get the i386 version?
> 
> best regards,
> --
> Pierre Frenkiel
> 

Use Chromium instead of Chrome. Chrome is actually based on Chromium.
i386 versions of Chromium are in the Debian repos.

# apt install chromium

Re: i386 version for chrome

[Pierre Frenkiel]

On Sat, 27 Oct 2018, Roberto C. S?nchez wrote:


Did you try an absolute path?

file:///home/user/bookmarks.html

  I tried it, and also file://~user...

  but the problem is not there, but in the fact that, as I said,
  it puts a https:// before..
  which of course can't work

  Anyway, what interested me was the additional features that chrome
  adds to chromium.

best regards,
--
Pierre Frenkiel

Re: i386 version for chrome

[Roberto C . Sánchez]

On Sat, Oct 27, 2018 at 12:37:04PM +0200, Pierre Frenkiel wrote:
> On Sat, 27 Oct 2018, Andrew Wood wrote:
> 
> > Google no longer produce a 32 bit version but you could try vivaldi
> > which is based on Chrome and has a 32 bit version
> > https://vivaldi.com/download/
> > 
>   thank you.
>   I installed it, but I'm not convince by its features
> 
>1/ I want to define my ~/bookmarks.html file as home page, but
>   it insists putting a https:// before my file://...
> 
Did you try an absolute path?

file:///home/user/bookmarks.html

I don't think the file:// protocol works with a path unless it starts
with /.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: i386 version for chrome

[Pierre Frenkiel]

On Sat, 27 Oct 2018, Andrew Wood wrote:

Google no longer produce a 32 bit version but you could try vivaldi which is 
based on Chrome and has a 32 bit version

https://vivaldi.com/download/


  thank you.
  I installed it, but I'm not convince by its features

   1/ I want to define my ~/bookmarks.html file as home page, but
  it insists putting a https:// before my file://...

   2/ worst: playing sound only works on youtube, but I can't play
  mp3 files from other sites. I get the error:

  ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY 
{"error":"FFmpegDemuxer: no supported streams"}
  ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR 
DEMUXER_ERROR_NO_SUPPORTED_STREAMS

   I think I'll revert to chromium

best regards,
--
Pierre Frenkiel

Re: i386 version for chrome

[Andrew Wood]

On 27/10/2018 09:19, Pierre Frenkiel wrote:

hi,
I wanted to install chrome on my intel desktop, but the only version I 
found

is amd64. Is it possible to get the i386 version?

best regards,
Google no longer produce a 32 bit version but you could try vivaldi 
which is based on Chrome and has a 32 bit version

https://vivaldi.com/download/