Re: make check nested variables

[Thomas Schmitt]

Hi,

mlnl wrote:
> when i compile something in a tmux or rxvt window, sometimes i get:
> $ ./configure
> [...]
> checking whether make supports nested variables...
> and than it hangs. Then i have to go in a terminal, where it works.

What particular terminal program does work ?

The last visible message probably stems from aclocal.m4. In a configure
file of my own i can see the expanded macro code. It should have added
the message text "yes" or "no" if the test had finished.
So indeed the hang seems to be in there.

The test consists of piping a makefile into "make -f -" and checking
its exit value. Hard to guess what difference between tmux, rxvt, and
other terminal programs could make this test getting stuck.

Are you really sure that the problem never appears on the terminal
program which you use for a second try ? (Would tmux and rxvt work too
on second try ?)


Have a nice day :)

Thomas

Re: Online copies of textinfo content available?

[mick crane]

On 2018-10-26 19:17, Brian wrote:
 > {plain text fine --  HTML *NOT* needed} is MUCH more functional.


Agreed, a good man page is the best. I've no clue why there seems to 
be
an aversion to a man page that has to be scrolled to read it all. All 
of
us have up/down arrows on our keyboards, and 99% have a mouse wheel, 
so

there is no excuse that holds water to not put it all in the man
page. "man bash" if you man page authors want to see what a real man
page looks like.


An excellent man page. Intended for masochists and those who have all
the time in the world to read and absorb it. :)


I made the mistake of printing out man bash once. It's really, really 
long


mick

--
Key ID4BFEBB31

i386 version for chrome

[Pierre Frenkiel]

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

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/

Re: Online copies of textinfo content available?

[Curt]

On 2018-10-27, rhkra...@gmail.com  wrote:
> On Friday, October 26, 2018 06:10:13 PM Brian wrote:
>> On Fri 26 Oct 2018 at 18:02:39 -0400, rhkra...@gmail.com wrote:
>> > It's probably been 15 years since I bothered looking at an info page --
>> > maybe there are no more duplicate man and info pages -- but I don't
>> > believe that.
>> 
>> You can vouch for whatever you want. Without an example it is worthless.
>
> What would you do with an example?

I just thought of a cozy place for it.

whois
info
file
acpi

There's also the case of the (generally succinct) man page referring you
to the full documentation via the info page, the latter of which is
identical to the former, a rubbing-it-in kind of "bug" by which I've
been bitten in the past.

I can't summon an example of this frustrating insect offhand.

Jesus. Shoot me.

-- 
"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

[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

[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, 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

[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

[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

[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

[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

[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: Online copies of textinfo content available?

[rhkramer]

Thanks -- two comments below!

On Saturday, October 27, 2018 05:04:37 AM Curt wrote:
> On 2018-10-27, rhkra...@gmail.com  wrote:
> > On Friday, October 26, 2018 06:10:13 PM Brian wrote:
> >> On Fri 26 Oct 2018 at 18:02:39 -0400, rhkra...@gmail.com wrote:
> >> > It's probably been 15 years since I bothered looking at an info page
> >> > -- maybe there are no more duplicate man and info pages -- but I
> >> > don't believe that.
> >> 
> >> You can vouch for whatever you want. Without an example it is worthless.
> > 
> > What would you do with an example?
> 
> I just thought of a cozy place for it.

Great minds ...

> 
> whois
> info
> file
> acpi
> 
> There's also the case of the (generally succinct) man page referring you
> to the full documentation via the info page, the latter of which is
> identical to the former, a rubbing-it-in kind of "bug" by which I've
> been bitten in the past.

I remember those, also!
 
> I can't summon an example of this frustrating insect offhand.

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

[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

[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

[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

[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

[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

[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 

make check nested variables

[mlnl]

Hi Thomas,

First, thanks for your answer and infos.

> Are you really sure that the problem never appears on the terminal 
> program which you use for a second try ? (Would tmux and rxvt work 
> too on second try ?)

I meant Alt+Fn or logout and doing it in the console - there it works,
sorry. And i have observed in tmux and rxvt window (on KDE), sometimes
it works too on a second try, yes.

-- 
mlnl

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: make check nested variables

[Thomas Schmitt]

Hi,

mlnl wrote:
> I meant Alt+Fn or logout and doing it in the console - there it works,
> sorry. And i have observed in tmux and rxvt window (on KDE), sometimes
> it works too on a second try, yes.

So it never fails on the console but sometimes fails two times in a row
on your terminal windows ?

I am running my own ./configure scripts in xterm windows since about
12 years without such problems at least once per week and often more
than once per day.
So i propose to compare the success rates of xterm and console.

If you get a stuck ./configure again, then try to find out whether a
"make" process exists. E.g.
  ps -ef | fgrep make
will list any process with string "make" in its command line.
(So this search run should find at least itself.)


I read in the web that tmux is a bit strange but rxvt is supposed to be
a leaner competitor to xterm. So i still riddle what could cause the
"make" run to stall. A vague idea is that standard input does not close
when "$as_echo" has done its job in

   if $as_echo 'TRUE=$(BAR$(V))
  BAR0=false
  BAR1=true
  V=1
  am__doit:
  @$(TRUE)
  .PHONY: am__doit' | $am_make -f - >/dev/null 2>&1; then

But why should something prevent EOF to happen on the pipe ?

(Please check whether you find that gesture in your ./configure script.
 It is preceded by the message and a check for already set variable:

  $as_echo_n "checking whether $am_make supports nested variables... " >&6; }
  if ${am_cv_make_support_nested_variables+:} false; then :
$as_echo_n "(cached) " >&6
  else

then comes above pipe of" $as_echo: and "make".)


Have a nice day :)

Thomas

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: make check nested variables

[Steve McIntyre]

mlnl wrote:
>Hi,
>
>when i compile something in a tmux or rxvt window, sometimes i get:
>
>$ ./configure
>checking for a BSD-compatible install... /usr/bin/install -c
>checking whether build environment is sane... yes
>checking for a thread-safe mkdir -p... /bin/mkdir -p
>checking for gawk... gawk
>checking whether make sets $(MAKE)... yes
>checking whether make supports nested variables...
>
>and than it hangs. Then i have to go in a terminal, where it works. My
>question: Why does the check hangs and how can i avoid it?

That's really weird. Are there any particular configure scripts that
show this? What shell are you using?

In terms of debugging it, I'd try using "bash -x ./configure" and see
what that says. Maybe "strace -f -o logfile ./configure" to see what
it's doing. Both will produce a lot of output...

-- 
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

[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: make check nested variables

[Reco]

Hi.

On Sat, Oct 27, 2018 at 06:24:51PM +, Steve McIntyre wrote:
> mlnl wrote:
> >Hi,
> >
> >when i compile something in a tmux or rxvt window, sometimes i get:
> >
> >$ ./configure
> >checking for a BSD-compatible install... /usr/bin/install -c
> >checking whether build environment is sane... yes
> >checking for a thread-safe mkdir -p... /bin/mkdir -p
> >checking for gawk... gawk
> >checking whether make sets $(MAKE)... yes
> >checking whether make supports nested variables...
> >
> >and than it hangs. Then i have to go in a terminal, where it works. My
> >question: Why does the check hangs and how can i avoid it?
> 
> That's really weird. Are there any particular configure scripts that
> show this? What shell are you using?
> 
> In terms of debugging it, I'd try using "bash -x ./configure" and see
> what that says. Maybe "strace -f -o logfile ./configure" to see what
> it's doing. Both will produce a lot of output...

I'd add a simple shell redirection to that.
If it's the terminal/shell issue, why not deny configure a tty and force
it to write to a file?

Reco

Re: make check nested variables

[Thomas Schmitt]

Hi,

more ideas would be:

Add option -d to the "make" command in ./configure.

Or skip the test by setting variable am_cv_make_support_nested_variables
to "yes" before running configure:

  export am_cv_make_support_nested_variables=yes
  ./configure

If skipping the test does reliably help, then the problem is with that
single test. If ./configure gets stuck some steps later, then there is a
general problem with the terminal or the shell which is running in it.

When i do this with the ./configure of GNU xorriso, i get the message

  checking whether make supports nested variables... (cached) yes

The text "(cached)" is emitted it "make" is not run.

The further code in ./configure then acts as if the test yielded the result
which we expect on Debian. See e.g. the result in
  
https://buildd.debian.org/status/fetch.php?pkg=libisoburn&arch=amd64&ver=1.5.0-1&stamp=1539085692&raw=0

If i set the variable to "no", i get
  checking whether make supports nested variables... (cached) no
A following run of "make" yields no suspicious messages. The binary starts
and reports its version.


Have a nice day :)

Thomas

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

[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 denying

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 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

[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

[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

[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

[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

[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

[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