date:20180430

On Mon 30 Apr 2018 at 15:15:41 (-0500), Richard Owlett wrote:
> On 04/30/2018 11:58 AM, Brian wrote:
> >On Mon 30 Apr 2018 at 09:27:02 -0500, Richard Owlett wrote:
> >[snip]
> >>
> >>You have identified a documentation bug!
> >
> >No, I haven't. You may think *you* have, but you haven't.
> >
> >>The relevant line of the HTML of
> >>https://manpages.debian.org/stretch/coreutils/ls.1.en.html is
> >>
> >>
> >>GNU coreutils online help: < >>href="http://www.gnu.org/software/coreutils/";>http://www.gnu.org/software/coreutils/
> >>
> >>and www.gnu.org/software/coreutils/ gives no navigational guidance.
> >>
> 
> *YES*
> *YOU* have identified a bug.
> Just not the one either of us thought we were discussing.

I only saw a misunderstanding of how man pages impart information.

> Carefully read the quoted HTML.
> There be a missing "ls".

I'm not in the habit of reading HTML but I went to your reference
and it looks like your quotation is rendered as:

REPORTING BUGS

GNU coreutils online help: 

This is exactly what's written at the end of the local man page too.
Clicking on this link takes me (after allowing an automatic redirect) to:
https://www.gnu.org/software/coreutils/coreutils.html

where there's a bug reporting section a little over halfway down the page:

Bug Reports

If you think you have found a bug in Coreutils, then …

> I suspect a corrupt mirror.

Why? Where is the "ls" string missing from?

> Have *NO* idea how to verify.
> Will try at a similar time tomorrow.

You can compare the webpage above with the output of
$ man ls
yourself at any time of day.

> Is there any way to establish *EXACTLY* which mirror I'm viewing?

Cheers,
David.

Re: Access a sub partition from KVM host

2018-04-30 Thread Richard Hector

On 01/05/18 04:31, André Rodier wrote:
> Hello Debian experts,
> 
> I have a kvm/libvirt installed on Debian, with a Windows 10 virtual
> machine.
> The Windows virtual machine has access the a whole disk partition,
> /dev/sda2, that I have added using the virtual machine manager.
> Because Windows "see" this partition as a disk, it has created
> partitions inside.
> 
> When I use kpartx, I see the partitions:
> 
> root@main:/etc# kpartx /dev/sda2
> sda2p1 : 0 262144 /dev/sda2 34
> sda2p2 : 0 4469876736 /dev/sda2 264192
> 
> However, kpartx does not create the device files in /dev
> 
> I need to mount this partition from Linux, as *read only*, to share the
> files easily between Linux and Windows.
> 
> Can I mount these partitions from Linux easily, or should I use loop
> device?

kpartx can do that, with -a ...

But I would seriously not do that, unless the Windows VM isn't running.
Even read only.

Neither OS will know what the other one is doing, and could be keeping
caches or whatever ... you're liable to get corruption.

I would suggest sharing the directories over the network instead. A
little slower, but much safer.

Richard



signature.asc
Description: OpenPGP digital signature

Re: messed up release in apt

2018-04-30 Thread Anil Duggirala

> > The Debian English-language backports wiki FAQ suggests (to find
> all backported packages on a given machine):
> 
> https://backports.debian.org/FAQ/
> 

I  removed all backported packages. Then did apt-get autoremove. Then
removed the jessie-backports line from sources.list. I appear to have
come back to my original system. However I am now getting an error on
apt update.
W: http://security.debian.org/debian-security/dists/stretch/updates/InR
elease: The key(s) in the keyring /etc/apt/trusted.gpg are ignored as
the file is not readable by user '_apt' executing apt-key.
W: http://ftp.us.debian.org/debian/dists/stretch-updates/InRelease: The
key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file is
not readable by user '_apt' executing apt-key.
W: http://ftp.us.debian.org/debian/dists/stretch/Release.gpg: The
key(s) in the keyring /etc/apt/trusted.gpg are ignored as the file is
not readable by user '_apt' executing apt-key.

Any help on that?
thanks!

Re: Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

2018-04-30 Thread Charlie S

On Mon, 30 Apr 2018 10:09:44 -0400 Roberto C. Sánchez sent:

> On Mon, Apr 30, 2018 at 04:18:01PM +0300, Abdullah Ramazanoglu wrote:
> > 
> > AFAIK it is still there untouched in git sources, as originally
> > mentioned in the bug report
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806
> > 
> > That aside, the question of whether it will ever get fixed in
> > upstream or not, is of secondary importance. OTOH, the fact that
> > official Debian developers and maintainers adopted a stance of
> > neglecting users' privacy is of utmost importance.
> >   
> That is a rather serious charge to make and one which is not supported
> by the evidence in this matter. Without a doubt there are personality
> issues, misunderstandings, and miscommunications. However, accusations
> of malice should be made with the utmost of care or not at all.
> 
> > I had taken Debian Social Contract and DFSG for granted for a long
> > time. This thing forced me to review my assumptions about Debian.
> >   
> In what way? Debian as a project is made up of ~1000 official
> developers and thousands more contributors enaged in a variety of
> different efforts. To expect perfect conformance and adherence is
> somewhat unreasonable. People make mistakes.
> 
> It appears that the issue here (with systemd-resolved) is most likely
> an honest mistake or perhaps an oversight.  Had Martin (the reporter
> of the bug) ended his bug report with the sentence, "Unless all four
> conditions are true, the default Google DNS servers are not used."
> and left out the last few paragraphs, I suspect the reaction would
> have been somewhat different. The fact is, however, that the second
> half of the bug report is essentially a screed against Google, is
> focused entirely on the "wrongs" of Google, completely ignores the
> fact that Google makes a great deal of positive contribution to the
> community, and also ignores the fact that quite a number of past and
> present Debian developers work or have worked at Google.
> 
> A far more effective approach would have been to include a patch to
> the Debian bug report that effected the desired change. Even better,
> a patch should have been submitted to upstream that added a configure
> or build option to disable the Google DNS servers. Then the Debian
> bug report could have a included a link to the proposed upstream
> patch.
> 
> Speaking as someone who is involved in maintaining quite a few
> different packages, my preferences for making changes to a Debian
> package are odered like so:
> 
> 1. New upstream release
> 2. Patch created from commit made to upstream source
> 3. Patch created from patch proposed to upstream project
> 4. Patch submitted to Debian BTS
> 5. Patch I have to conjure up myself
> 6. Somebody screaming at me that I need to fix something
> 
> Additionally, as the level of inflamatory rhetoric in a bug report
> increases, the more difficult it is to get motivated to work on fixing
> it.
> 
> Regards,
> 
> -Roberto
> 
> -- 
> Roberto C. Sánchez
> 

After contemplation, my reply is:

Thank you Roberto. It's true that such thanks are insufficient.

Remembering, each time a program is used, that someone has taken the
time from other things in their life and done an enormous amount of
work. Mostly or always unpaid and oft taken for granted and continues
with this commitment so it runs smoothly, is hardly enough.

Like most people, I don't know who maintains most FOSS and other
software in Debian. Am usually too busy using the program to take the
time to look for the name of the maintainer.

As a wildlife carer on a fixed income, without any payment from
government, company or other source, caring for animals to release back
into their environment, always broke of course. I chafe at not being
able to give a donation to so many who are deserving.

As a grateful user of Debian, even if I had the time, like this text,
stolen from another task, I know nothing of writing code and am
probably now to old to learn.

So yes, thank you for what you do. The difference it makes to my life
is huge. I do think about, and thank everyone for what I have on this
machine which is 10 years old now and salvaged from a rubbish dump.

Stay well,
Charlie 

-- 
Registered Linux User:- 329524
***

Whatever you do will be insignificant, but it is very important
that you do it. -Gandhi

***

Debian GNU/Linux - Magic indeed.

-

Re: messed up release in apt

2018-04-30 Thread Anil Duggirala

> I would first use old sources.list to purge wine and follow it up
> with
> autoremove. But after that new, this time intended and correct,
> sources.list with apt-get should solve problem.
> 

When you say "old" do you mean the sources.list without the jessie
backports entry? Could you explain to me why exactly you would do that,
thanks a lot for your help

Re: Debian glossary?


On 04/30/2018 11:58 AM, Brian wrote:

On Mon 30 Apr 2018 at 09:27:02 -0500, Richard Owlett wrote:
[snip]


You have identified a documentation bug!


No, I haven't. You may think *you* have, but you haven't.


The relevant line of the HTML of
https://manpages.debian.org/stretch/coreutils/ls.1.en.html is


GNU coreutils online help: http://www.gnu.org/software/coreutils/

and www.gnu.org/software/coreutils/ gives no navigational guidance.



*YES*
*YOU* have identified a bug.
Just not the one either of us thought we were discussing.

Carefully read the quoted HTML.
There be a missing "ls".

I suspect a corrupt mirror.
Have *NO* idea how to verify.
Will try at a similar time tomorrow.

Is there any way to establish *EXACTLY* which mirror I'm viewing?

Re: stuck at Debian's text installer numerical Software Selection menu

2018-04-30 Thread john doe


On 4/30/2018 5:00 PM, john doe wrote:

Hi Alan,

On 4/30/2018 2:54 PM, Alan Tu wrote:

John, I do enjoy giving back by documenting and reporting bugs.



:)


Is there some way, at least theoretically, that you know of to get the
text installer to record the output and the responses it think its
receiving? There's going to be an issue if the media is read-only and
it can't write files, that's why I say "at least theoretically".

I know that if an installation is successful, one can do

debconf-get-selections --installer

to get all the variables but I was hoping for something a little more
low level. Thanks.

 >

The only way I can think of would be to install debian through ssh and 
recorde your terminal session.
The below link don't use text mode but should give you an idea on how to 
install remotely! :)


https://blog.sleeplessbeastie.eu/2015/10/12/how-to-install-debian-remotely/



Note that when using this approach, it doesn't seem to be possible to 
set the remote frontend  to text mode.


--
John Doe

Re: Debian glossary?

On Monday 30 April 2018 12:03:31 David Wright wrote:

> On Mon 30 Apr 2018 at 10:44:58 (-0400), Gene Heskett wrote:
> > On Monday 30 April 2018 09:24:12 Richard Owlett wrote:
> > > Sometimes automount and cousins are convenient. Other times
> > > %@%$^$!*() ;/
> >
> > Let me clarify that, to a right Pain In The Ass when trying to write
> > an armhf or arm64 systen to its boot u-sd card. They grab the card
> > the instant its plugged in and then dd has a hell of a time trying
> > to write to a mounted device.
>
> Yes, I seem to remember pointing out that the cause might be Package:
> usbmount, and being told that it wasn't there and I had an attitude
> problem.

My apologies David. It turned out to be hiding in plain sight and that is 
where I killed it.

> In the end I think you blamed the "few trillion gallons of 
> water [flowing] down the West Fork River" for a recollection problem.
>
That also is a definite possibility. My shorter term memory is suffering 
from oldtimers. Goes with both the 83 years, and I think from being a 
pulmonary embolism surviver 3 years back up the log.

> > > > On Monday, April 30, 2018 08:23:43 AM rhkra...@gmail.com wrote:
> > > >> On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> > > >>> Debian documentation NOT written for hoi polloi.
> >
> > And it needs to be.
>
> I can't understand why Debian would involve itself in writing
> tutorials for commands like mount, ls, and so on, or glossaries
> of terms like strictatime and device file.
>
> All this is standard linux/unix information, well catered for by
> libraries of books from several well-known publishers, O'Reilly
> being one of the best known. I spent 1997/8 immersing myself in such
> texts, at a time when these books had to be bought. (Public libraries
> only had Idiots' guides to W95, etc.) Now there are a wealth of
> free PDFs at every level of expertise on the web, there for the
> downloading.

> 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: Debian glossary?


On 04/30/2018 12:12 PM, Brian wrote:

On Mon 30 Apr 2018 at 10:01:13 -0500, Richard Owlett wrote:


On 04/30/2018 08:38 AM, rhkra...@gmail.com wrote:

On Monday, April 30, 2018 09:06:09 AM Richard Owlett wrote:
[snip]

A partial solution might include "Summer of Documentation" projects
along side of "Summer of Code".


Yes, or encouraging people to contribute to HowTos, wikis, the Linux
Documentation Project (which seems rather moribund at this point), and such.

BTW, write to google--you might get them interested in a SOD project--or some
other "flush" organization--maybe Amazon??


I avoid Google!

Having a strong preference for brick-n-mortar I've never had any contact
with Amazon. Do they have any history of involvement in tech issues?


You could say that:

https://aws.amazon.com/



mea culpa  mea culpa
Actually I didn't have in mind sales of technology, but more along the 
lines of Google's SOC claiming to foster the next generation of 
technologists.


A quick glance suggests that it is worth of further investigation.
I did immediately find one thing in their favor.
Having some visual, problems I surf with site defined colors AND 
backgrounds disabled. The site is ugly with that constraint active.


*HOWEVER* setting things to accept the designer's choices results in an 
attractive legible display.

A *RARE* and valuable occurrence.

Thanks for the link.
When corporations do "something right", they should be acknowledged.
I'll browse further.

Re: messed up release in apt

2018-04-30 Thread Curt

On 2018-04-30, Anil Duggirala  wrote:
> hello,
> I mistakenly added an etc/apt/sources.list line for "jessie"(backports)
> instead of "stretch", which is my current release. I proceded to update
> apt and installed Wine (along with many packages, some i386) from the
> jessie-backports source (i.e. apt install wine/jessie-backports).
> Please tell me how I can locate all wrongly installed packages and
> remove them, and install correct packages from stretch-backports,
> thank you,
>
>

The Debian English-language backports wiki FAQ suggests (to find
all backported packages on a given machine):

https://backports.debian.org/FAQ/

 dpkg -l  |awk '/^ii/ && $3 ~ /bpo[7-9]/ {print $2}'
 (works here--outputs the package name without version)

 aptitude search '?narrow(?version(CURRENT),?origin(Debian Backports))'-F 
'%100p'
 (produces no output here though I have one backported package).

The French (ah, the French) backports FAQ suggests:

https://wiki.debian.org/fr/Backports

 dpkg-query -W | grep ~bpo
 (works here--outputs package + version)

Then there is the '/var/log/apt/history.log' also, which might be of
great utility in this affair.

-- 
"Three prisoners were locked in a cell. When the largest of them finished his
food, he immediately ate the others. Too bad. An apostrophe in the right place
might have prevented a horrible crime." Joe Gunn

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

2018-04-30 Thread Thomas Schmitt

Hi,

Reco wrote:
> $ qemu-system-mips -m 2048 -nographic
> -cdrom /tmp/debian-7.4.0-mips-netinst.iso -boot d
> qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel
> argument was specified

Oops. I did not expect it to die so early.

> Also, that 'iso' is no way a conventional ISO9660 or UDF image:
> $ file -sL /tmp/debian-7.4.0-mips-netinst.iso
> /tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)

Oh, it is. But it is also a bit more than that.
It's only that the programmers of "file" did not account for that
combination as much as they did with x86 isohybrids:

  $ file debian-9.3.0-amd64-netinst.iso
  debian-9.3.0-amd64-netinst.iso: DOS/MBR boot sector ISO 9660 CD-ROM
  filesystem data 'Debian 9.3.0 amd64 n' (bootable); partition 2 : ID=0xef,
  start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 3760,
  832 sectors

With the mips ISO, we have to combine file's report with info like this

  $ isoinfo -i debian-7.4.0-mips-netinst.iso -d
  CD-ROM is in ISO 9660 format
  System id: 
  Volume id: Debian 7.4.0 mips 1
  Volume set id: 
  Publisher id: 
  Data preparer id: XORRISO-1.2.6 2013.01.08.103001, LIBISOBURN-1.2.6, 
LIBISOFS-1.2.6, LIBBURN-1.2.6
  Application id: 
  Copyright File id: 
  Abstract File id: 
  Bibliographic File id: 
  Volume set size is: 1
  Volume set sequence number is: 1
  Logical block size is: 2048
  Volume size is: 105591
  Joliet with UCS level 3 found
  Rock Ridge signatures version 1 found

xorriso can tell about the MIPS Volume Header which it created on demand
of debian-cd:

  $ xorriso -report_about warning -indev debian-7.4.0-mips-netinst.iso \
-report_system_area plain 
  System area options: 0x0004
  System area summary: MIPS-Big-Endian
  ISO image size/512 : 422364
  MIPS-BE volume dir :   N  Name   Block   Bytes
  MIPS-BE boot entry :   1  r4k-ip22   6343610876928
  MIPS-BE boot path  :   1  /install/r4k-ip22-boot.img

But i guess it will be hard to determine which machines react on this.
My cheat sheet for boot sectors says

   MIPS Volume Header
   for MIPS Big Endian, e.g. SGI Indigo2

  Sources:
 cdrkit-1.1.10/genisoimage/boot-mips.c
 by Steve McIntyre 
 which refers to
genisovh by Florian Lohoff 
and Thiemo Seufer 
who seem to have learned parameter settings from IRIX CD media
There are traces in the web which relate this to specs by
 MIPS Computer Systems, Inc. , 1985
 Silicon Graphics Computer Systems, Inc. , 2000
 Mail conversations with Natalia Portillo.

Have a nice day :)

Thomas

Re: messed up release in apt

2018-04-30 Thread Dejan Jocic

On 30-04-18, Brian wrote:
> On Mon 30 Apr 2018 at 11:49:33 -0500, Anil Duggirala wrote:
> 
> > hello,
> > I mistakenly added an etc/apt/sources.list line for "jessie"(backports)
> > instead of "stretch", which is my current release. I proceded to update
> > apt and installed Wine (along with many packages, some i386) from the
> > jessie-backports source (i.e. apt install wine/jessie-backports).
> > Please tell me how I can locate all wrongly installed packages and
> > remove them, and install correct packages from stretch-backports,
> > thank you,
> 
> Take a look at apt's log in /var/log.
> 
> Or let apt sort it out with the correct line in sources.list and then
> update and upgrade.
> 
> Or, both.
> 
> -- 
> Brian.
>  
> 

I would first use old sources.list to purge wine and follow it up with
autoremove. But after that new, this time intended and correct,
sources.list with apt-get should solve problem.

Re: Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

On Mon 30 Apr 2018 at 16:18:01 +0300, Abdullah Ramazanoglu wrote:

> On Mon, 30 Apr 2018 14:24:19 +0200 to...@tuxteam.de said:
> > On Mon, Apr 30, 2018 at 03:00:07PM +0300, Abdullah Ramazanoglu wrote:
> > > On Mon, 30 Apr 2018 06:43:03 +0200 to...@tuxteam.de said:  
> > 
> > [...]
> > 
> > > > It seems this issue is fixed upstream. Would you like to check that?
> > > > 
> > > > Tone down. Apply Hanlon's razor generously [...]  
> > 
> > > This is not about systemd or some bug or something. This is about
> > > attitude.  
> > 
> > Exactly my point :-)
> 
> Good one! :) :)
> 
> > On a more practical note: care to double-check whether the
> > issue is actually fixed upstream?
> 
> AFAIK it is still there untouched in git sources, as originally mentioned in
> the bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806
> 
> That aside, the question of whether it will ever get fixed in upstream or not,
> is of secondary importance. OTOH, the fact that official Debian developers and
> maintainers adopted a stance of neglecting users' privacy is of utmost
> importance.

systemd-resolved is not used and enabled by default. If a concerned user
changes that situation, it is not exactly hard to alter the fallback DNS
server(s).
 
> I had taken Debian Social Contract and DFSG for granted for a long time. This
> thing forced me to review my assumptions about Debian.

Questioning one's assumptions from time to time is never a bad thing.

-- 
Brian.

Re: Debian glossary?

On Mon 30 Apr 2018 at 13:23:38 -0400, Greg Wooledge wrote:

> On Mon, Apr 30, 2018 at 06:19:11PM +0100, Brian wrote:
> > On Mon 30 Apr 2018 at 10:34:23 -0500, David Wright wrote:
> > > info coreutils   came up with 18696.
> > 
> > Isn't 18696 the byte count?
> 
> No.
> 
> wooledg:~$ info coreutils | wc
>   18696  111230  863180

Just testing. :)

-- 
Brian.

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Hi.

On Mon, Apr 30, 2018 at 06:58:13PM +0200, Thomas Schmitt wrote:
> Hi,
>
> i wrote:
> > > Shouldn't there be a bootloader installed in debian_mips32b.img ?
>
> Reco wrote:
> > No. One of the oddities of QEMU's malta that nobody was able to
> > write a
> > working bootloader for it. OP is doing it the only way that's
> > possible.
>
> And he has luck to already have found somebody who has seen a MIPS
> more recently than 20 years ago.
>
> Would my idea to install from ISO work at all ?
> (I have a debian-7.4.0-mips-netinst.iso but feel not really in the
> mood
>  for trying what would happen.)

$ qemu-system-mips -m 2048 -nographic -cdrom
/tmp/debian-7.4.0-mips-netinst.iso -boot d
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no
-kernel argument was specified

Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.

Also, that 'iso' is no way a conventional ISO9660 or UDF image:

$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)

[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en


PS I should be more careful with e-mail headers.

Reco

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Hi.

In-Reply-To: <3824776101913512...@scdbackup.webframe.org>

On Mon, Apr 30, 2018 at 06:58:13PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> i wrote:
> > > Shouldn't there be a bootloader installed in debian_mips32b.img ?
> 
> Reco wrote:
> > No. One of the oddities of QEMU's malta that nobody was able to write a
> > working bootloader for it. OP is doing it the only way that's possible.
> 
> And he has luck to already have found somebody who has seen a MIPS
> more recently than 20 years ago.
> 
> Would my idea to install from ISO work at all ?
> (I have a debian-7.4.0-mips-netinst.iso but feel not really in the mood
>  for trying what would happen.)

$ qemu-system-mips -m 2048 -nographic -cdrom /tmp/debian-7.4.0-mips-netinst.iso 
-boot d
qemu-system-mips: Could not load MIPS bios 'mips_bios.bin', and no -kernel 
argument was specified

Of course if you happen to have that magic mips_bios.bin lying around -
it may even boot. Or not. Even the installation guide mentions TFTP as a
preferred way to install Debian on MIPS.

Also, that 'iso' is no way a conventional ISO9660 or UDF image:

$ file -sL /tmp/debian-7.4.0-mips-netinst.iso
/tmp/debian-7.4.0-mips-netinst.iso: SGI disk label (volume header)

[1] https://www.debian.org/releases/stable/mipsel/ch02s01.html.en

Reco

Re: messed up release in apt

On Mon 30 Apr 2018 at 11:49:33 -0500, Anil Duggirala wrote:

> hello,
> I mistakenly added an etc/apt/sources.list line for "jessie"(backports)
> instead of "stretch", which is my current release. I proceded to update
> apt and installed Wine (along with many packages, some i386) from the
> jessie-backports source (i.e. apt install wine/jessie-backports).
> Please tell me how I can locate all wrongly installed packages and
> remove them, and install correct packages from stretch-backports,
> thank you,

Take a look at apt's log in /var/log.

Or let apt sort it out with the correct line in sources.list and then
update and upgrade.

Or, both.

-- 
Brian.

Re: Debian glossary?

On Mon, Apr 30, 2018 at 06:19:11PM +0100, Brian wrote:
> On Mon 30 Apr 2018 at 10:34:23 -0500, David Wright wrote:
> > info coreutils   came up with 18696.
> 
> Isn't 18696 the byte count?

No.

wooledg:~$ info coreutils | wc
  18696  111230  863180

Re: Debian glossary?

On Mon 30 Apr 2018 at 10:34:23 -0500, David Wright wrote:

> On Mon 30 Apr 2018 at 11:16:46 (-0400), Greg Wooledge wrote:
> > On Mon, Apr 30, 2018 at 10:59:03AM -0400, Gene Heskett wrote:
> > > On Monday 30 April 2018 10:44:56 Greg Wooledge wrote:
> > > > wooledg:~$ man ls | wc
> > > > 233 9117823
> > > > wooledg:~$ info coreutils ls | wc
> > > > 8354551   34791
> > > >
> > > > In this example, the info page is about 4 times as large as the man
> > > > page.
> > > 
> > > That is not a fair comparison. The manpage covers one specific piece, a 
> > > single utility, where coreutils supposedly covers it all.
> > 
> > "info coreutils ls" is just the "ls" part.  Please actually try it.
> > (I suggest "info coreutils ls | less" as an alternative to the "info"
> > reader program.)
> 
> I stepped through   info coreutils ls   adding together the numbers of lines
> reported by less and ended up at 908.
> 
> info coreutils   came up with 18696.

Isn't 18696 the byte count?

-- 
Brian.

Re: Debian glossary?

On Mon 30 Apr 2018 at 10:01:13 -0500, Richard Owlett wrote:

> On 04/30/2018 08:38 AM, rhkra...@gmail.com wrote:
> > On Monday, April 30, 2018 09:06:09 AM Richard Owlett wrote:
> > [snip]
> > > A partial solution might include "Summer of Documentation" projects
> > > along side of "Summer of Code".
> > 
> > Yes, or encouraging people to contribute to HowTos, wikis, the Linux
> > Documentation Project (which seems rather moribund at this point), and such.
> > 
> > BTW, write to google--you might get them interested in a SOD project--or 
> > some
> > other "flush" organization--maybe Amazon??
> 
> I avoid Google!
> 
> Having a strong preference for brick-n-mortar I've never had any contact
> with Amazon. Do they have any history of involvement in tech issues?

You could say that:

https://aws.amazon.com/

-- 
Brian.

Re: Debian glossary?

On Mon 30 Apr 2018 at 09:27:02 -0500, Richard Owlett wrote:

> On 04/30/2018 08:20 AM, Brian wrote:
> > On Mon 30 Apr 2018 at 06:46:01 -0500, Richard Owlett wrote:
> > 
> > > Debian documentation NOT written for hoi polloi.
> > 
> > Strong words.
> 
> BUT true!

No they are not. Valid, perhaps.

> > 
> > [...]
> > > Output of "ls -Rdl /media/richard/rco1" is
> > > "drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".
> > > 
> > > { In "drwxr-xr-x 3", what do "d" and "3" tell me? }
> > 
> > At the end of ls(1) it says:
> > 
> >   Full documentation at: 
> >   or available locally via: info '(coreutils) ls invocation'
> 
> You have identified a documentation bug!

No, I haven't. You may think *you* have, but you haven't.

> The relevant line of the HTML of
> https://manpages.debian.org/stretch/coreutils/ls.1.en.html is
> 
> 
> GNU coreutils online help: < href="http://www.gnu.org/software/coreutils/";>http://www.gnu.org/software/coreutils/
> 
> and www.gnu.org/software/coreutils/ gives no navigational guidance.
> 
> Drilling down to
> https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html#What-information-is-listed
> does indeed identify "d".
> 
> > 
> > I think "Full" would imply more detail than in the manual. I'd use
> > 'pinfo ls' for something more friendly than info.
> 
> Hadn't heard of pinfo and it wasn't installed. Looks interesting.
> Will read man page online later.
> 
> > 
> > > https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
> > > /begin quote
> > > strictatime
> > >  Allows to explicitly request full atime updates. This makes it 
> > > possible
> > > for the kernel to default to relatime or noatime but still allow userspace
> > > to override it. For more details about the default system mount options 
> > > see
> > > /proc/mounts.
> > > /end quote
> > > 
> > > { Having used a file manager to look at /proc/mounts without 
> > > comprehension,
> > > I interpreted the context of "/proc/mounts" to indicate that there would 
> > > be
> > > a reference to it elsewhere in https://manpages.debian.org . Nope. }
> > 
> > 'cat /proc/mounts' doesn't necessarily improve your comprehension but it
> > is probably quicker. For a reference, you want proc(5);
> 
> You have identified ANOTHER bug.  "/proc/mounts" should read "proc(5)".

No, I haven't. And, no, it shouldn't.

> > that takes you to fstab(5).
> > 
> > > https://manpages.debian.org/stretch/mount/mount.8.en.html makes several
> > > references to "block special device".
> > > { "block special device" ??? }
> > 
> > I thought that was well explained.
> 
> I admit the author would claim so. But it left me head scratching.
> 
> > What does the internet say about it?
> 
> Various pages say various things while raising more questions clouding the
> issue.
> 
> > 
> > > Man pages by their nature/purpose assume a certain level of expertise.
> > > They can be daunting for the uninitiated.
> > 
> > Not a novel observation - but you are not uninitiated or a newcomer. Then
> > there is always a search engine at hand or the ever-helpful debian-user. >
> 
>  Unwarranted assumption implied by "but you are not uninitiated or a
> newcomer".
> 
> As to computers generally - true.
> 
> As an E.E. student in the 60's took "Introduction to Computers" followed by
> a semester of FORTRAN. In the 70's I did work for DEC. *BUT* I was in "Power
> Supply Engineering". My name (or at least my initials) appear on some H720-E
> documentation.
> 
> BUT, until abandoning WinXP for Squeeze I was only a USER without any OS
> background. Since then I've been self-taught, there not even being a local
> LUG.

You had access to computers when you were young? How fortunate! All we
had was a second-hand abacus with a bead missing and a manual written in
the Chinese language. Try dividing £112/13s/7d by £2/7s/11d with that.

-- 
Brian

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

2018-04-30 Thread Thomas Schmitt

Hi,

i wrote:
> > Shouldn't there be a bootloader installed in debian_mips32b.img ?

Reco wrote:
> No. One of the oddities of QEMU's malta that nobody was able to write a
> working bootloader for it. OP is doing it the only way that's possible.

And he has luck to already have found somebody who has seen a MIPS
more recently than 20 years ago.

Would my idea to install from ISO work at all ?
(I have a debian-7.4.0-mips-netinst.iso but feel not really in the mood
 for trying what would happen.)

Have a nice day :)

Thomas

messed up release in apt

2018-04-30 Thread Anil Duggirala

hello,
I mistakenly added an etc/apt/sources.list line for "jessie"(backports)
instead of "stretch", which is my current release. I proceded to update
apt and installed Wine (along with many packages, some i386) from the
jessie-backports source (i.e. apt install wine/jessie-backports).
Please tell me how I can locate all wrongly installed packages and
remove them, and install correct packages from stretch-backports,
thank you,

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Thanks Reco. The concept I missed is, I need to grab the initrd and
kernel from the installed system, specifically from the /boot
directory. I know that now for all future architectures I mess with!

There are lots of ways to do the same thing, I'm just sharing. To
mount a partition inside raw disk image, one can use the loopback
device.

1.  Determine the byte offset of the desired partition.
$ fdisk -lu
$offset=sector size * start sector

2.  Create the loopback link.
# losetup -o $offset /dev/loop0 image_file

3.  Mount as usual:
# mount /dev/loop0 directory

4.  Copy files, edit/make changes, etc.

5.  When done, umount as usual:
# umount /dev/loop0

6.  Detach the loopback device.
# losetup -d /dev/loop0

Alan

On 4/30/18, Reco  wrote:
>   Hi.
>
> On Mon, Apr 30, 2018 at 06:30:32PM +0200, Thomas Schmitt wrote:
>> > # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
>> > -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
>> > -append "root=/dev/sda1"
>>
>> Shouldn't there be a bootloader installed in debian_mips32b.img ?
>
> No. One of the oddities of QEMU's malta that nobody was able to write a
> working bootloader for it. OP is doing it the only way that's possible.
>
> Reco
>
>

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Hi.

On Mon, Apr 30, 2018 at 06:30:32PM +0200, Thomas Schmitt wrote:
> > # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> > -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> > -append "root=/dev/sda1"
> 
> Shouldn't there be a bootloader installed in debian_mips32b.img ?

No. One of the oddities of QEMU's malta that nobody was able to write a
working bootloader for it. OP is doing it the only way that's possible.

Reco

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Hi.

On Mon, Apr 30, 2018 at 07:54:56AM -0700, Alan Tu wrote:
> Hi, I'm having trouble bootting Debian 9.4 on a QEMU-emulated MIPS
> malta virtual machine. I know QEMU introduces some complexity, but I
> think my problem is more of a misunderstanding of Linux boot concepts.
> I've tried different permutations, and reading, but am stuck.

On the contrary. Compared to the hassle of dealing with the real
hardware, QEMU is the easy mode. If it works in that particular version,
that is.

Luckily for us, QEMU 2.8 they put in stable is in pretty good shape for
MIPS. Cannot say the same for SPARC64, for instance.


> I installed Debian inside a virtual disk image. Here is the output of
> "fdisk -lu" that shows the partition setup of this disk image. I think
> it shows a valid and recognized first partition, as set up at
> install-time.
> $ fdisk -lu debian_mips32b.img
> Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x6c0f31a2
> 
> Device   BootStart  End  Sectors  Size Id Type
> debian_mips32b.img1  2048 15992831 15990784  7.6G 83 Linux
> debian_mips32b.img2  15994878 16775167   780290  381M  5 Extended
> debian_mips32b.img5  15994880 16775167   780288  381M 82 Linux
> swap / Solaris
> 
> Booting this doesn't work. If I supply the same Debian initrd image I
> used to install, I see the installer language selection menu, not the
> system. Despite the fact I don't attach a virtual CD-ROM install
> media.

That's expected. Installer's initrd serves one purpose exactly - to run
debian-installer. It's not supposed to boot your installed Debian
system.


> If I don't point qemu at the initrd RAM disk, the kernel seems to
> start, but it has problems.
> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"

That's understandable too. Debian kernel does not have any filesystem
compiled in, they all come as modules. You don't supply initrd - kernel
is unable to mount your root filesystem.


> So two questions:
> 
> 1.  Am I supposed to tell the virtual machine where to find the initrd
> RAM disk, and do I use the same initrd downloaded from Debian as the
> installer, or a different initrd from somewhere? The kernel seems to
> go some way without this.

The most simple way to boot Debian in QEMU is - mount your first
partition of your debian_mips32b.img in the host OS. Unless I forgot how
to count, either:

mount -o offset=1048576 debian_mips32b.img /mnt

or (don't forget kpartx -d afterwards):

kpartx -a debian_mips32b.img
mount /dev/mapper/loop0p1 /mnt

should do it.
Then you copy vmlinuz *and* initrd from MIPS root filesystem, and use
those in QEMU. Rinse and repeat after each kernel update.


> 2.  It seems the kernel is somehow not recognizing the partition. I'm
> not sure what the problem is here.

See above.

Reco

Re: can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

2018-04-30 Thread Thomas Schmitt

Hi,

Alan Tu wrote:
> I installed Debian inside a virtual disk image. 

>From outside qemu ? That could be tricky because being unusual.

Last time i installed a virtual Debian, i did something like this:

  # Create virtual disk as data file
  qemu-img create debian_vm_disk.qemu 32G

  # Start qemu to install Debian from netinst ISO
  qemu-system-x86_64 -enable-kvm -m 512 \
   -net nic \
   -hda debian_vm_disk.qemu \
   -cdrom debian-9.3.0-amd64-netinst.iso \
   -boot d

I just tested this. A graphics window comes up, a boot loader menu appears
and offers "Graphical install", "Install", "Advanced options", ...

(I think i used "Install". It was a Debian 8 ISO which i then converted
 into a Debian Sid. More than two years ago ...)

> # qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
> -nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
> -append "root=/dev/sda1"

Shouldn't there be a bootloader installed in debian_mips32b.img ?

Maybe you first need to find somebody who has a Debian installed on mips.
Maybe via
  https://www.debian.org/ports/mips/
So you could learn how it roughly has to look like.
"qemu-system-mips" ... 32 bit big-endian ? A virtual SGI Iris ? Oh nostalgy.

Have a nice day :)

Thomas

Re: Debian glossary?

2018-04-30 Thread Felix Dietrich

Richard Owlett  writes:

> Debian documentation NOT written for hoi polloi.
>
> This morning's partial set of items I do not grok include:
> 
>
> Partial output of "mount -l" is
> "/dev/sdc1 on /media/richard/rco1 type ext4
> (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2) [rco1]".
>
> { (...) Although I can interpret many items, several I can't. I
> suspect (...) is trying to tell me something by which items are/aren't
> listed.}

Between the parentheses are listed the mount options that are set:

- rw   :: mounted read-write
- nosuid   :: do not allow setting of SUID bit
  (executables with set SUID are run as the
  owner of the file, not the executing user)
- nodev:: do not allow device files (i.e. files that
  act as an interface to a driver)
- relatime :: update file access time only when modification
  time is newer than access time (reduces number
  of writes to a drive)

The rest I do not know and therefore you have to look them up yourself.

„findmnt” provides a pretty display of mounted devices and displays a
header telling you what the data in the columns refers to.

> Output of "ls -Rdl /media/richard/rco1" is
> "drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".
>
> { In "drwxr-xr-x 3", what do "d" and "3" tell me? }

Programs that are part of the GNU software distribution usually have, in
addition to the terser man pages, more comprehensive info documents.
These can be accessed with the „info” program (if it is not already
installed: the Debian package goes by the same name).  For your specific
question the information can be found in the info document for the
„coreutils” package; the following command should display the
appropriate section: „info --index-search='-l <6>' coreutils”. [1]

In short: „d” denotes directories; „3” is the count of hard links.

That the man page for „ls” does not describe the output format I find
odd; might be worth a bug report (look at the „reportbug” program)?

> https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
> /begin quote
> strictatime
> Allows to explicitly request full atime updates. This makes it
> possible for the kernel to default to relatime or noatime but still
> allow userspace to override it. For more details about the default
> system mount options see /proc/mounts.
> /end quote
>
> { Having used a file manager to look at /proc/mounts without
> comprehension, I interpreted the context of "/proc/mounts" to indicate
> that there would be a reference to it elsewhere in
> https://manpages.debian.org . Nope. }

You can read „/proc/mounts” using an editor or within the shell using a
pager, e.g. „less /proc/mounts”, or simply get it output to your
terminal using „cat /proc/mounts”.  It will show you information of the
mounts currently known by the kernel.  The output, though, is not
especially user friendly, but seems to follow the same format as
„/etc/fstab”.

What the man page's author meant by „for more details about the default
system mount options see /proc/mounts” I am not certain.  Maybe he only
wanted to say that „/proc/mounts” displays the mount options currently
applied and if you do not specify some yourself you can deduce from the
displayed options the kernel's default options?

It is a rather confusing sentence: you could file a bug report (look at
the „reportbug” program) requesting clarification.

> https://manpages.debian.org/stretch/mount/mount.8.en.html makes
> several references to "block special device".
> { "block special device" ??? }

Devices are put in two rough categories: block devices and character
devices.  Block devices are those that are partitioned into individual
accessable blocks; discs are usually considered block devices.
Character devices are all the rest: mice, keyboards, printers,
terminals.  They provide a stream of information.

> Man pages by their nature/purpose assume a certain level of expertise.
> They can be daunting for the uninitiated.

As has been mention by rhkramer for the „uninitiated” there have been
written introductory texts, though suggestions I have also not right
now.

Using a search engine usually yields good results for the more common
terms and also on Wikipedia can be found helpful computer related
articles, e.g. for block devices:
.

[1] Also available on the web:

https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html#index-verbose-ls-format

--
Felix Dietrich

Re: Debian glossary?

On Mon, Apr 30, 2018 at 12:07:51PM -0400, rhkra...@gmail.com wrote:
> Well, I wouldn't say it's untrue--it is sometimes (and maybe often) true--I 
> don't have an example at hand, but back in the days when I did look at an 
> info 
> page after viewing a man page, I often found the exact same content (maybe 
> modulo some formatting differences or similar).

You might be thinking of programs for which no man page exists *at all*,
in which case the "man page" is literally a copy of a texinfo-to-ascii
output from the info page.  There are a few of those out there, though
I can't think of one off the top of my head.

But the more typical GNU case has a stub/minimalist man page, with the
note that the full documentation is in the info page.

Examples:

wooledg:~$ man rm | grep info
  output version information and exit
   or available locally via: info '(coreutils) rm invocation'

wooledg:~$ man grep | grep -A5 'Full Doc'
   Full Documentation
   A   complete   manual   ⟨http://www.gnu.org/software/grep/manual/⟩   is
   available.   If  the  info  and grep programs are properly installed at
   your site, the command

  info grep

Re: Debian glossary?

On Monday, April 30, 2018 10:44:56 AM Greg Wooledge wrote:
> On Mon, Apr 30, 2018 at 10:37:22AM -0400, Gene Heskett wrote:

> > as those files appear to be made by just copying the man
> > page into the info format.
> 
> That's untrue.  Compare a GNU info page to the same tool's GNU man page
> and you will see a huge difference.
> 
> wooledg:~$ man ls | wc
> 233 9117823
> wooledg:~$ info coreutils ls | wc
> 8354551   34791

Well, I wouldn't say it's untrue--it is sometimes (and maybe often) true--I 
don't have an example at hand, but back in the days when I did look at an info 
page after viewing a man page, I often found the exact same content (maybe 
modulo some formatting differences or similar).

Of course, I don't know whether the man pages copied the info pages or vice 
versa (in those cases).

Re: Debian glossary?

On Mon 30 Apr 2018 at 10:44:58 (-0400), Gene Heskett wrote:
> On Monday 30 April 2018 09:24:12 Richard Owlett wrote:

> > Sometimes automount and cousins are convenient. Other times %@%$^$!*()
> > ;/
> >
> Let me clarify that, to a right Pain In The Ass when trying to write an 
> armhf or arm64 systen to its boot u-sd card. They grab the card the 
> instant its plugged in and then dd has a hell of a time trying to write 
> to a mounted device.

Yes, I seem to remember pointing out that the cause might be Package: usbmount,
and being told that it wasn't there and I had an attitude problem.
In the end I think you blamed the "few trillion gallons of water [flowing] down
the West Fork River" for a recollection problem.

> > > On Monday, April 30, 2018 08:23:43 AM rhkra...@gmail.com wrote:
> > >> On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> > >>> Debian documentation NOT written for hoi polloi.
> 
> And it needs to be.

I can't understand why Debian would involve itself in writing
tutorials for commands like mount, ls, and so on, or glossaries
of terms like strictatime and device file.

All this is standard linux/unix information, well catered for by
libraries of books from several well-known publishers, O'Reilly
being one of the best known. I spent 1997/8 immersing myself in such
texts, at a time when these books had to be bought. (Public libraries
only had Idiots' guides to W95, etc.) Now there are a wealth of
free PDFs at every level of expertise on the web, there for the
downloading.

Cheers,
David.

Problem building boost 1.67.0 package

2018-04-30 Thread Aleksandar Valchev

Hi,

I forked boost and make some updates for version 1.67.0 and add asio and
beast libraries. The result is here:
https://salsa.debian.org/avalchev-guest/boost.

I have problems with dpk-buildpackage command:
https://salsa.debian.org/snippets/54.

Do you have any idea what's wrong ?

Re: Debian glossary?

On Mon 30 Apr 2018 at 11:16:46 (-0400), Greg Wooledge wrote:
> On Mon, Apr 30, 2018 at 10:59:03AM -0400, Gene Heskett wrote:
> > On Monday 30 April 2018 10:44:56 Greg Wooledge wrote:
> > > wooledg:~$ man ls | wc
> > > 233 9117823
> > > wooledg:~$ info coreutils ls | wc
> > > 8354551   34791
> > >
> > > In this example, the info page is about 4 times as large as the man
> > > page.
> > 
> > That is not a fair comparison. The manpage covers one specific piece, a 
> > single utility, where coreutils supposedly covers it all.
> 
> "info coreutils ls" is just the "ls" part.  Please actually try it.
> (I suggest "info coreutils ls | less" as an alternative to the "info"
> reader program.)

I stepped through   info coreutils ls   adding together the numbers of lines
reported by less and ended up at 908.

info coreutils   came up with 18696.

Cheers,
David.

Re: Debian glossary?

On Mon, Apr 30, 2018 at 10:59:03AM -0400, Gene Heskett wrote:
> On Monday 30 April 2018 10:44:56 Greg Wooledge wrote:
> > wooledg:~$ man ls | wc
> > 233 9117823
> > wooledg:~$ info coreutils ls | wc
> > 8354551   34791
> >
> > In this example, the info page is about 4 times as large as the man
> > page.
> 
> That is not a fair comparison. The manpage covers one specific piece, a 
> single utility, where coreutils supposedly covers it all.

"info coreutils ls" is just the "ls" part.  Please actually try it.
(I suggest "info coreutils ls | less" as an alternative to the "info"
reader program.)

Re: Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

On Monday 30 April 2018 10:09:44 Roberto C. Sánchez wrote:

> On Mon, Apr 30, 2018 at 04:18:01PM +0300, Abdullah Ramazanoglu wrote:
> > AFAIK it is still there untouched in git sources, as originally
> > mentioned in the bug report
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806
> >
> > That aside, the question of whether it will ever get fixed in
> > upstream or not, is of secondary importance. OTOH, the fact that
> > official Debian developers and maintainers adopted a stance of
> > neglecting users' privacy is of utmost importance.
>
> That is a rather serious charge to make and one which is not supported
> by the evidence in this matter. Without a doubt there are personality
> issues, misunderstandings, and miscommunications. However, accusations
> of malice should be made with the utmost of care or not at all.
>
> > I had taken Debian Social Contract and DFSG for granted for a long
> > time. This thing forced me to review my assumptions about Debian.
>
> In what way? Debian as a project is made up of ~1000 official
> developers and thousands more contributors enaged in a variety of
> different efforts. To expect perfect conformance and adherence is
> somewhat unreasonable. People make mistakes.
>
> It appears that the issue here (with systemd-resolved) is most likely
> an honest mistake or perhaps an oversight.  Had Martin (the reporter
> of the bug) ended his bug report with the sentence, "Unless all four
> conditions are true, the default Google DNS servers are not used." and
> left out the last few paragraphs, I suspect the reaction would have
> been somewhat different. The fact is, however, that the second half of
> the bug report is essentially a screed against Google, is focused
> entirely on the "wrongs" of Google, completely ignores the fact that
> Google makes a great deal of positive contribution to the community,
> and also ignores the fact that quite a number of past and present
> Debian developers work or have worked at Google.
>
> A far more effective approach would have been to include a patch to
> the Debian bug report that effected the desired change. Even better, a
> patch should have been submitted to upstream that added a configure or
> build option to disable the Google DNS servers. Then the Debian bug
> report could have a included a link to the proposed upstream patch.
>
> Speaking as someone who is involved in maintaining quite a few
> different packages, my preferences for making changes to a Debian
> package are odered like so:
>
> 1. New upstream release
> 2. Patch created from commit made to upstream source
> 3. Patch created from patch proposed to upstream project
> 4. Patch submitted to Debian BTS
> 5. Patch I have to conjure up myself
> 6. Somebody screaming at me that I need to fix something
>
> Additionally, as the level of inflamatory rhetoric in a bug report
> increases, the more difficult it is to get motivated to work on fixing
> it.
>
> Regards,
>
> -Roberto

You make an extremely valid point Roberto, and I shouldn't have to point 
out that each of us, including me and you, is inclined to walk away when 
the rhetoric gets inflamatory. So I'd say, like I say to a military 
veteran, thank you for your service, such thanks is well deserved.

-- 
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: Debian glossary?

On Mon 30 Apr 2018 at 06:46:01 (-0500), Richard Owlett wrote:
> Debian documentation NOT written for hoi polloi.
> 
> I've been trying to debug my usage of debootstrap.
> Therefore been reading many man pages - often with incomplete comprehension.
> E.G. In reply to one of my questions a gentleman replied with the
> proper syntax for one command. He followed it with several
> quotations from a man page [subtle hint to read same ;]. I replied
> that I had read the man page, but even after reading his excerpts I
> still didn't comprehend.
> 
> This morning's partial set of items I do not grok include:
> 
> 
> Partial output of "mount -l" is
> "/dev/sdc1 on /media/richard/rco1 type ext4
> (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2) [rco1]".
> 
> { (...) Although I can interpret many items, several I can't. I
> suspect (...) is trying to tell me something by which items
> are/aren't listed.}
> 
> Output of "ls -Rdl /media/richard/rco1" is
> "drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".
> 
> { In "drwxr-xr-x 3", what do "d" and "3" tell me? }
> 
> https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
> /begin quote
> strictatime
> Allows to explicitly request full atime updates. This makes it
> possible for the kernel to default to relatime or noatime but still
> allow userspace to override it. For more details about the default
> system mount options see /proc/mounts.
> /end quote
> 
> { Having used a file manager to look at /proc/mounts without
> comprehension, I interpreted the context of "/proc/mounts" to
> indicate that there would be a reference to it elsewhere in
> https://manpages.debian.org . Nope. }
> 
> https://manpages.debian.org/stretch/mount/mount.8.en.html makes
> several references to "block special device".
> { "block special device" ??? }
> 
> Man pages by their nature/purpose assume a certain level of expertise.
> They can be daunting for the uninitiated.
> 
> Comments?

Sure. You turn to page 108 of Running Linux 5th ed and read it there.

Don't have it? Download it. Type running-linux-5th-2006.pdf into
google and it's the first hit. Then type

$ wget 
https://the-eye.eu/public/Books/IT%20Various/running_linux_5th_edition.pdf

and read it.

Why "running-linux-5th-2006.pdf"? Because that's the name it has in my
filesystem. (I gave away my July 1995 paper copy to an enthusiastic
teenager who now works in IT.) Now get stuck into Unix Power Tools
3rd edition (replaces my October 1995 edition), Linux in a Nutshell
(ditto April 1997), and several others out there, all downloadable,
usually in slightly dated editions.

I thought you had a voracious appetite for reading in your retirement.
I just don't understand how you can hang out hereabouts for over six
years and not know that d stands for directory, or claim to be
"uninitiated".

Cheers,
David.

Re: Debian glossary?


On 04/30/2018 08:38 AM, rhkra...@gmail.com wrote:

On Monday, April 30, 2018 09:06:09 AM Richard Owlett wrote:
[snip]

A partial solution might include "Summer of Documentation" projects
along side of "Summer of Code".


Yes, or encouraging people to contribute to HowTos, wikis, the Linux
Documentation Project (which seems rather moribund at this point), and such.

BTW, write to google--you might get them interested in a SOD project--or some
other "flush" organization--maybe Amazon??


I avoid Google!

Having a strong preference for brick-n-mortar I've never had any contact 
with Amazon. Do they have any history of involvement in tech issues?


On a mailing list of an Oregon LUG, I once suggested that high school 
English teachers include tech writing as a possible assignment. Back in 
my day shop classes (woodworking, metal shop, auto mechanics) were used 
as motivation to stay in school - education being the desired side 
effect. Students today are fascinated with computers - a similar 
approach might be worthwhile. Also students with writing talent might be 
attracted to tech writing.

Re: stuck at Debian's text installer numerical Software Selection menu

2018-04-30 Thread john doe


Hi Alan,

On 4/30/2018 2:54 PM, Alan Tu wrote:

John, I do enjoy giving back by documenting and reporting bugs.



:)


Is there some way, at least theoretically, that you know of to get the
text installer to record the output and the responses it think its
receiving? There's going to be an issue if the media is read-only and
it can't write files, that's why I say "at least theoretically".

I know that if an installation is successful, one can do

debconf-get-selections --installer

to get all the variables but I was hoping for something a little more
low level. Thanks.

>

The only way I can think of would be to install debian through ssh and 
recorde your terminal session.
The below link don't use text mode but should give you an idea on how to 
install remotely! :)


https://blog.sleeplessbeastie.eu/2015/10/12/how-to-install-debian-remotely/

To enter expert mode in text mode you would pass 'priority=low' as 
kernel boot parameter ('install DEBIAN_FRONTEND=text priority=low'):


https://www.debian.org/releases/stable/i386/ch05s03.html.en

This part is untested; to recorde your terminal session you could use 
the script utility:


https://www.2daygeek.com/script-command-record-save-your-terminal-session-activity-linux/


As an aside:

The section 5.4.6 (reporting Installation Problems) might give some 
hints on where the issue lies!:


https://www.debian.org/releases/stable/i386/ch05s04.html

-John
--
John Doe

Re: Debian glossary?

On Monday 30 April 2018 10:44:56 Greg Wooledge wrote:

> On Mon, Apr 30, 2018 at 10:37:22AM -0400, Gene Heskett wrote:
> > The recommendation to get the full story via info/pinfo is a
> > running joke
>
> This is specific to the GNU project.  They're pushing their "info"
> reader and their "texinfo" documentation format for their own
> political reasons. (To be honest, the *roff format used by man pages
> *does* suck.  But still.)
>
> > as those files appear to be made by just copying the man
> > page into the info format.
>
> That's untrue.  Compare a GNU info page to the same tool's GNU man
> page and you will see a huge difference.
>
> wooledg:~$ man ls | wc
> 233 9117823
> wooledg:~$ info coreutils ls | wc
> 8354551   34791
>
> In this example, the info page is about 4 times as large as the man
> page.

That is not a fair comparison. The manpage covers one specific piece, a 
single utility, where coreutils supposedly covers it 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

can't boot a Debian on QEMU-mips virtual machine, could be initrd or root device problems

Hi, I'm having trouble bootting Debian 9.4 on a QEMU-emulated MIPS
malta virtual machine. I know QEMU introduces some complexity, but I
think my problem is more of a misunderstanding of Linux boot concepts.
I've tried different permutations, and reading, but am stuck.

I installed Debian inside a virtual disk image. Here is the output of
"fdisk -lu" that shows the partition setup of this disk image. I think
it shows a valid and recognized first partition, as set up at
install-time.
$ fdisk -lu debian_mips32b.img
Disk debian_mips32b.img: 8 GiB, 8589934592 bytes, 16777216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6c0f31a2

Device   BootStart  End  Sectors  Size Id Type
debian_mips32b.img1  2048 15992831 15990784  7.6G 83 Linux
debian_mips32b.img2  15994878 16775167   780290  381M  5 Extended
debian_mips32b.img5  15994880 16775167   780288  381M 82 Linux
swap / Solaris

Booting this doesn't work. If I supply the same Debian initrd image I
used to install, I see the installer language selection menu, not the
system. Despite the fact I don't attach a virtual CD-ROM install
media.

If I don't point qemu at the initrd RAM disk, the kernel seems to
start, but it has problems.
# qemu-system-mips -m 2048 -rtc base=localtime -boot order=c
-nographic -hda debian_mips32b.img -kernel vmlinux-4.9.0-6-4kc-malta
-append "root=/dev/sda1"

I've attached the console output, but note:
[0.00] Kernel command line: root=/dev/sda1 console=ttyS0,38400n8r

This suggests that the kernel has received my intention to look for
root on /dev/sda1. But then:

[0.644281] List of all partitions:
[0.644483] No filesystem could mount root, tried: [0.644669]
[0.644847] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(0,0)

So two questions:

1.  Am I supposed to tell the virtual machine where to find the initrd
RAM disk, and do I use the same initrd downloaded from Debian as the
installer, or a different initrd from somewhere? The kernel seems to
go some way without this.

2.  It seems the kernel is somehow not recognizing the partition. I'm
not sure what the problem is here.

I'd appreciate any hints. Even confirming how things are supposed to
work helps. Thanks.

Alan
[0.00] Linux version 4.9.0-6-4kc-malta (debian-ker...@lists.debian.org) 
(gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Debian 4.9.82-1+deb9u3 
(2018-03-02)
[0.00] earlycon: uart8250 at I/O port 0x3f8 (options '38400n8')
[0.00] bootconsole [uart8250] enabled
[0.00] Config serial console: console=ttyS0,38400n8r
[0.00] CPU0 revision is: 00019300 (MIPS 24Kc)
[0.00] FPU revision is: 00739300
[0.00] MIPS: machine is mti,malta
[0.00] Software DMA cache coherency enabled
[0.00] Determined physical RAM map:
[0.00]  memory: 1000 @  (usable)
[0.00]  memory: 6000 @ 9000 (usable)
[0.00] Kernel relocated by 0x00fd
 .text @ 0x810d
 .data @ 0x816a0c04
 .bss  @ 0x819e
[0.00] Initrd not found or empty - disabling initrd
[0.00] Reserving 0MB of memory at 0MB for crashkernel
[0.00] Primary instruction cache 2kB, VIPT, 2-way, linesize 16 bytes.
[0.00] Primary data cache 2kB, 2-way, VIPT, no aliases, linesize 16 
bytes
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x0fff]
[0.00] Initmem setup node 0 [mem 0x-0x0fff]
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64960
[0.00] Kernel command line: root=/dev/sda1 console=ttyS0,38400n8r
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Writing ErrCtl register=
[0.00] Readback ErrCtl register=
[0.00] Memory: 248996K/262144K available (5946K kernel code, 576K 
rwdata, 1328K rodata, 1420K init, 284K bss, 13148K reserved, 0K cma-reserved)
[0.00] NR_IRQS:256
[0.00] CPU frequency 200.00 MHz
[0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, 
max_idle_ns: 19112599307 ns
[0.000149] sched_clock: 32 bits at 100MHz, resolution 9ns, wraps every 
21474830331ns
[0.006413] Console: colour dummy device 80x25
[0.007713] Calibrating delay loop... [0.058167] 844.80 BogoMIPS 
(lpj=1689600)
[0.058380] pid_max: default: 32768 minimum: 301
[0.059468] Security Framework

Re: Debian glossary?

On Monday 30 April 2018 09:24:12 Richard Owlett wrote:

> On 04/30/2018 07:27 AM, rhkra...@gmail.com wrote:
> > Oh, and PS: it is not very clear to me in what you wrote what you
> > are having trouble understanding -- if you are seeking answers,
> > maybe you should ask more clearly.
> >
> >  From my peanut gallery observation of this thread, I think one of
> > your problems is that the device you are tying to use (to install
> > Linux, iirc?) is mounted with the nodev option, which, somebody
> > explained in a followup post, is not what you want to use.
> >
> > Are you familiar with the mstab, fstab, mount, and umount commands? 
> > I think it would be helpful if you were...
>
> *ROFL* Them be motivation for my post ;{
> When I wrote "... a gentleman replied with the proper syntax for one
> command", I was referring to that post. It solved _one_ of my
> problems.
>
> Based on 50+ years of hitting "corner cases" while trouble shooting in
> various disciplines, I've cleared hard disk space on another machine
> to avoid attempting to use a flash drive as a debootstrap target.
>
> Sometimes automount and cousins are convenient. Other times %@%$^$!*()
> ;/
>
Let me clarify that, to a right Pain In The Ass when trying to write an 
armhf or arm64 systen to its boot u-sd card. They grab the card the 
instant its plugged in and then dd has a hell of a time trying to write 
to a mounted device.

> > On Monday, April 30, 2018 08:23:43 AM rhkra...@gmail.com wrote:
> >> On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> >>> Debian documentation NOT written for hoi polloi.

And it needs to be.


-- 
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: Debian glossary?

On Mon, Apr 30, 2018 at 10:37:22AM -0400, Gene Heskett wrote:
> The recommendation to get the full story via info/pinfo is a 
> running joke

This is specific to the GNU project.  They're pushing their "info" reader
and their "texinfo" documentation format for their own political reasons.
(To be honest, the *roff format used by man pages *does* suck.  But still.)

> as those files appear to be made by just copying the man 
> page into the info format.

That's untrue.  Compare a GNU info page to the same tool's GNU man page
and you will see a huge difference.

wooledg:~$ man ls | wc
233 9117823
wooledg:~$ info coreutils ls | wc
8354551   34791

In this example, the info page is about 4 times as large as the man page.

Re: Debian glossary?

On Monday 30 April 2018 09:06:09 Richard Owlett wrote:

> On 04/30/2018 07:23 AM, rhkra...@gmail.com wrote:
> > On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> >> Debian documentation NOT written for hoi polloi.
> >
> > ...
> >
> >> Man pages by their nature/purpose assume a certain level of
> >> expertise. They can be daunting for the uninitiated.
> >>
> >> Comments?
> >
> > True.  Have you read one or more general introductions to Linux (I
> > have none to suggest at the momen).
>
> Yeah, but not recently.
> You just reminded me that I have ~1500 pages of dusty dead trees
> available.
>
> > Man pages are (or were, at least) intended to be more reminders for
> > people that have at least a basic understanding of the command (or
> > subject) rather than a tool to learn about it from scratch.
>
> PREACH it brother. I've made similar comments in the past.
> The problem on this list is that newbies are often told
>  "*READ THE MANUAL!*"
> as if it were a panacea.
>
> > (When I switched from Windows to LInux, I found it very frustrating
> > until I read several introductions to Linux (of various sorts,
> > including at least skimming some thick books full of commands), and,
> > I joined a local LUG.)
>
> I've followed a similar path abandoning WinXP for Squeeze.
> The local LUG folded before I retired a decade ago. Never had a chance
> to attend any meetings as they were on weekday evenings and I worked
> graveyard shift. The nearest LUG's I know of are ~200 miles away (I
> live in RURAL S.W. Missouri where individual species of livestock
> outnumber people ;)
>
> A partial solution might include "Summer of Documentation" projects
> along side of "Summer of Code".

Hear! Hear!! As a 20 year veteran of linux for the main stuff here at the 
coyote.den, I won't say exclusively linux because there were other 
machines, still are, and they run a simplified unix too, Nitros-9, but 
none of them ran windows longer than to note that it too was broken, 
usually detected within a day or so of acquireing the machine.

What I'm driving at is the message from on high, to those writing man 
pages for everything but bash, and even that can be less than ideal, 
seem to have been given orders that a man page is at maximum, 2 screen 
sized pages.  And that often doesn't give room to adequately cover what 
a given utility can do. Every option should have an example and its 
results. The recommendation to get the full story via info/pinfo is a 
running joke as those files appear to be made by just copying the man 
page into the info format. If you want to do a man-page, do it right and 
cover it all. Or collaborate with someone that can write it well.

My $0.02 on the subject. But adjust its worth by the inflation since 
1934.

-- 
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: Debian glossary?

On 04/30/2018 08:20 AM, Brian wrote:

On Mon 30 Apr 2018 at 06:46:01 -0500, Richard Owlett wrote:

Debian documentation NOT written for hoi polloi.

Strong words.

BUT true!

[...]

Output of "ls -Rdl /media/richard/rco1" is
"drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".

{ In "drwxr-xr-x 3", what do "d" and "3" tell me? }

At the end of ls(1) it says:

Full documentation at:
or available locally via: info '(coreutils) ls invocation'

You have identified a documentation bug!
The relevant line of the HTML of
https://manpages.debian.org/stretch/coreutils/ls.1.en.html is

GNU coreutils online help: http://www.gnu.org/software/coreutils/

and www.gnu.org/software/coreutils/ gives no navigational guidance.

Drilling down to
https://www.gnu.org/software/coreutils/manual/html_node/What-information-is-listed.html#What-information-is-listed
does indeed identify "d".

I think "Full" would imply more detail than in the manual. I'd use
'pinfo ls' for something more friendly than info.

Hadn't heard of pinfo and it wasn't installed. Looks interesting.
Will read man page online later.

https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
/begin quote
strictatime
Allows to explicitly request full atime updates. This makes it possible
for the kernel to default to relatime or noatime but still allow userspace
to override it. For more details about the default system mount options see
/proc/mounts.
/end quote

{ Having used a file manager to look at /proc/mounts without comprehension,
I interpreted the context of "/proc/mounts" to indicate that there would be
a reference to it elsewhere in https://manpages.debian.org . Nope. }

'cat /proc/mounts' doesn't necessarily improve your comprehension but it
is probably quicker. For a reference, you want proc(5);

You have identified ANOTHER bug. "/proc/mounts" should read "proc(5)".

that takes you to fstab(5).

https://manpages.debian.org/stretch/mount/mount.8.en.html makes several
references to "block special device".
{ "block special device" ??? }

I thought that was well explained.

I admit the author would claim so. But it left me head scratching.

What does the internet say about it?

Various pages say various things while raising more questions clouding
the issue.

Man pages by their nature/purpose assume a certain level of expertise.
They can be daunting for the uninitiated.

Not a novel observation - but you are not uninitiated or a newcomer. Then
there is always a search engine at hand or the ever-helpful debian-user. >

Unwarranted assumption implied by "but you are not uninitiated or
a newcomer".

As to computers generally - true.

As an E.E. student in the 60's took "Introduction to Computers" followed
by a semester of FORTRAN. In the 70's I did work for DEC. *BUT* I was in
"Power Supply Engineering". My name (or at least my initials) appear on
some H720-E documentation.

BUT, until abandoning WinXP for Squeeze I was only a USER without any OS
background. Since then I've been self-taught, there not even being a
local LUG.

Re: Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

2018-04-30 Thread Roberto C . Sánchez

On Mon, Apr 30, 2018 at 04:18:01PM +0300, Abdullah Ramazanoglu wrote:
> 
> AFAIK it is still there untouched in git sources, as originally mentioned in
> the bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806
> 
> That aside, the question of whether it will ever get fixed in upstream or not,
> is of secondary importance. OTOH, the fact that official Debian developers and
> maintainers adopted a stance of neglecting users' privacy is of utmost
> importance.
> 
That is a rather serious charge to make and one which is not supported
by the evidence in this matter. Without a doubt there are personality
issues, misunderstandings, and miscommunications. However, accusations
of malice should be made with the utmost of care or not at all.

> I had taken Debian Social Contract and DFSG for granted for a long time. This
> thing forced me to review my assumptions about Debian.
> 
In what way? Debian as a project is made up of ~1000 official developers
and thousands more contributors enaged in a variety of different
efforts. To expect perfect conformance and adherence is somewhat
unreasonable. People make mistakes.

It appears that the issue here (with systemd-resolved) is most likely an
honest mistake or perhaps an oversight.  Had Martin (the reporter of the
bug) ended his bug report with the sentence, "Unless all four conditions
are true, the default Google DNS servers are not used." and left out the
last few paragraphs, I suspect the reaction would have been somewhat
different. The fact is, however, that the second half of the bug report
is essentially a screed against Google, is focused entirely on the
"wrongs" of Google, completely ignores the fact that Google makes a
great deal of positive contribution to the community, and also ignores
the fact that quite a number of past and present Debian developers work
or have worked at Google.

A far more effective approach would have been to include a patch to the
Debian bug report that effected the desired change. Even better, a patch
should have been submitted to upstream that added a configure or build
option to disable the Google DNS servers. Then the Debian bug report
could have a included a link to the proposed upstream patch.

Speaking as someone who is involved in maintaining quite a few different
packages, my preferences for making changes to a Debian package are
odered like so:

1. New upstream release
2. Patch created from commit made to upstream source
3. Patch created from patch proposed to upstream project
4. Patch submitted to Debian BTS
5. Patch I have to conjure up myself
6. Somebody screaming at me that I need to fix something

Additionally, as the level of inflamatory rhetoric in a bug report
increases, the more difficult it is to get motivated to work on fixing
it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Debian glossary?

On Monday, April 30, 2018 09:06:09 AM Richard Owlett wrote:

> PREACH it brother. I've made similar comments in the past.
> The problem on this list is that newbies are often told
>  "*READ THE MANUAL!*"
> as if it were a panacea.

True, I guess I always (well, usually) tried to interpret that as read some 
documentation, which was often facilitated by a google search looking for, 
among other things, howtos, wikis, forums, mail lists and such, rather than, 
specifically man pages.

> The local LUG folded before I retired a decade ago. Never had a chance
> to attend any meetings as they were on weekday evenings and I worked
> graveyard shift. The nearest LUG's I know of are ~200 miles away (I live
> in RURAL S.W. Missouri where individual species of livestock outnumber
> people ;)

Too bad about the LUG, re the livestock: LOL!

> A partial solution might include "Summer of Documentation" projects
> along side of "Summer of Code".

Yes, or encouraging people to contribute to HowTos, wikis, the Linux 
Documentation Project (which seems rather moribund at this point), and such.

BTW, write to google--you might get them interested in a SOD project--or some 
other "flush" organization--maybe Amazon??

Re: Debian glossary?


On 04/30/2018 07:27 AM, rhkra...@gmail.com wrote:

Oh, and PS: it is not very clear to me in what you wrote what you are having
trouble understanding -- if you are seeking answers, maybe you should ask more
clearly.

 From my peanut gallery observation of this thread, I think one of your
problems is that the device you are tying to use (to install Linux, iirc?) is
mounted with the nodev option, which, somebody explained in a followup post,
is not what you want to use.

Are you familiar with the mstab, fstab, mount, and umount commands?  I think
it would be helpful if you were...


*ROFL* Them be motivation for my post ;{
When I wrote "... a gentleman replied with the proper syntax for one 
command", I was referring to that post. It solved _one_ of my problems.


Based on 50+ years of hitting "corner cases" while trouble shooting in 
various disciplines, I've cleared hard disk space on another machine to 
avoid attempting to use a flash drive as a debootstrap target.


Sometimes automount and cousins are convenient. Other times %@%$^$!*() ;/





On Monday, April 30, 2018 08:23:43 AM rhkra...@gmail.com wrote:

On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:

Debian documentation NOT written for hoi polloi.

Re: Debian glossary?

On Mon 30 Apr 2018 at 06:46:01 -0500, Richard Owlett wrote:

> Debian documentation NOT written for hoi polloi.

Strong words.

[...]
 
> Output of "ls -Rdl /media/richard/rco1" is
> "drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".
> 
> { In "drwxr-xr-x 3", what do "d" and "3" tell me? }

At the end of ls(1) it says:

 Full documentation at: 
 or available locally via: info '(coreutils) ls invocation'

I think "Full" would imply more detail than in the manual. I'd use
'pinfo ls' for something more friendly than info.

> https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
> /begin quote
> strictatime
> Allows to explicitly request full atime updates. This makes it possible
> for the kernel to default to relatime or noatime but still allow userspace
> to override it. For more details about the default system mount options see
> /proc/mounts.
> /end quote
> 
> { Having used a file manager to look at /proc/mounts without comprehension,
> I interpreted the context of "/proc/mounts" to indicate that there would be
> a reference to it elsewhere in https://manpages.debian.org . Nope. }

'cat /proc/mounts' doesn't necessarily improve your comprehension but it
is probably quicker. For a reference, you want proc(5); that takes you to
fstab(5).

> https://manpages.debian.org/stretch/mount/mount.8.en.html makes several
> references to "block special device".
> { "block special device" ??? }

I thought that was well explained. What does the internet say about it?

> Man pages by their nature/purpose assume a certain level of expertise.
> They can be daunting for the uninitiated.

Not a novel observation - but you are not uninitiated or a newcomer. Then
there is always a search engine at hand or the ever-helpful debian-user.

-- 
Brian.

Re: Debian glossary?


On 04/30/2018 07:23 AM, rhkra...@gmail.com wrote:

On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:

Debian documentation NOT written for hoi polloi.


...


Man pages by their nature/purpose assume a certain level of expertise.
They can be daunting for the uninitiated.

Comments?


True.  Have you read one or more general introductions to Linux (I have none
to suggest at the momen).


Yeah, but not recently.
You just reminded me that I have ~1500 pages of dusty dead trees available.



Man pages are (or were, at least) intended to be more reminders for people
that have at least a basic understanding of the command (or subject) rather
than a tool to learn about it from scratch.


PREACH it brother. I've made similar comments in the past.
The problem on this list is that newbies are often told
"*READ THE MANUAL!*"
as if it were a panacea.




(When I switched from Windows to LInux, I found it very frustrating until I
read several introductions to Linux (of various sorts, including at least
skimming some thick books full of commands), and, I joined a local LUG.)



I've followed a similar path abandoning WinXP for Squeeze.
The local LUG folded before I retired a decade ago. Never had a chance 
to attend any meetings as they were on weekday evenings and I worked 
graveyard shift. The nearest LUG's I know of are ~200 miles away (I live 
in RURAL S.W. Missouri where individual species of livestock outnumber 
people ;)


A partial solution might include "Summer of Documentation" projects 
along side of "Summer of Code".

Re: Inexplicable memory usage after move to Debian9

2018-04-30 Thread Selim T . Erdoğan

On Thu, Apr 26, 2018 at 03:09:15PM +0200, Simon Beirnaert wrote:
> Hi Recently I've started moving a fleet of Debian 7, 32-bit machines over to
> Debian 9, 64-bit. This migration is done by creating a fresh Debian 9 image
> with the necessary services, moving over user data (some wars and the
> content of /home) and rebooting into the new OS.
> 
> Relevant services (ones we manage and use) are:
> 
> - Jetty- Puppet - SSH - AutoSSH - NewRelic Infrastructure Through Puppet, we
> enforce system configuration is pretty much identical, save for stuff like
> host names and SSH keys. Now, we notice that on some systems, the RAM usage
> is way higher than expected, to the point where system memory is exhausted
> and processes (are) terminate(d). Investigation into what is causing this,
> leaves me at a dead end. I can't figure out where the memory is being
> consumed. Even after quitting all services we manage (leaving a "clean"
> installation), RAM usage on the system hovers just over 600MB, half a gig
> over what the same exact image consumes just after boot. The only fix I
> found so far is to reboot the system. The systems have ~1.8GB of system
> memory available. We don't use swap. Enabling swap gives the system some
> breathing room. On one system I enabled a swap volume of 512MB, which the
> kernel fills up and leaves filled up indefinitely. This points me to unused
> memory being allocated by mistake. A memory leak in the kernel, maybe? Below
> I've posted the output of some of the things I checked (with all services
> online). I also searched the internet and reached a topic about slab
> allocation (1). However, that didn't seem to solve anything. Can anyone here
> point me to some more stuff I can check out or try to debug this? Thanks!
> Simon root@mysystem:~# uname -a Linux mysystem 4.9.0-6-amd64 #1 SMP Debian
> 4.9.82-1+deb9u2 (2018-02-21) x86_64 GNU/Linux root@mysystem:~# free -m total
> used free shared buff/cache available Mem: 1831 1091 238 16 501 520 Swap:
> 511 511 0 root@mysystem:~# vmstat 1 procs ---memory--
> ---swap-- -io -system-- --cpu- r b swpd free buff cache si
> so bi bo in cs us sy id wa st 2 0 524268 244480 46044 467248 1 2 2137 36 97
> 35 9 3 85 3 0 0 0 524268 244092 46052 467244 0 0 0 16 1125 2406 3 3 94 1 0 0
> 0 524268 244092 46060 467284 0 0 4 208 1230 3906 4 3 93 0 0 0 0 524268
> 244084 46068 467256 0 0 0 32 1003 1990 1 2 97 0 0 0 0 524268 244180 46068
> 467256 0 0 0 0 1099 2121 4 1 95 0 0 0 0 524268 244204 46076 467272 0 0 0 20
> 1000 1978 1 2 97 1 0 0 0 524268 244080 46076 467272 0 0 0 0 1135 2315 2 2 96
> 0 0 0 0 524268 244080 46084 467264 0 0 0 16 1079 2103 1 3 96 1 0 0 0 524268
> 244080 46092 467272 0 0 0 56 1002 1973 2 2 96 0 0 1 0 524268 244080 46100
> 467264 0 0 0 16 997 1979 1 2 97 1 0 0 0 524268 244144 46100 467268 0 0 0 0
> 988 1957 1 2 97 0 0 0 1 524268 244228 46108 467260 0 0 0 980 1292 2700 4 5
> 81 9 0 root@mysystem:~# smem PID User Command Swap USS PSS RSS 528 root
> /sbin/agetty -f /etc/issue. 148 4 4 8 554 myuser /usr/lib/autossh/autossh -o
> 80 24 40 184 220 root /lib/systemd/systemd-udevd 552 108 140 688 10665 root
> /usr/lib/autossh/autossh -o 0 104 143 648 432 root /usr/sbin/cron -f 164 120
> 147 500 434 root /usr/sbin/irqbalance --fore 252 156 172 508 12042 mail
> /usr/sbin/nullmailer-send - 120 144 219 1228 382 systemd-timesync
> /lib/systemd/systemd-timesy 456 152 301 1060 439 messagebus
> /usr/bin/dbus-daemon --syst 272 280 348 1116 430 root
> /lib/systemd/systemd-logind 380 192 448 1224 557 myuser /usr/bin/ssh -o
> StrictHostK 564 360 515 1472 216 root /sbin/lvmetad -f 188 484 517 1028
> 10668 root /usr/bin/ssh -o StrictHostK 0 736 825 1112 14225 ntp
> /usr/sbin/ntpd -p /var/run/ 0 808 849 1404 435 root /usr/sbin/rsyslogd -n
> 716 896 980 2036 11612 root /usr/sbin/sshd -D 0 856 991 1560 500 root
> /sbin/dhclient -4 -v -pf /r 840 928 1010 2068 1330 root sudo -i 0 920 1375
> 3548 1234 myuser -bash 0 600 1407 3684 1331 root -bash 0 640 1447 3712 1233
> myuser sshd: myuser@pts/0 0 300 1697 4568 1 root /sbin/init 524 1568 1935
> 3524 1227 root sshd: posios [priv] 0 1372 2984 6380 193 root
> /lib/systemd/systemd-journa 312 4304 4521 5828 8885 root /usr/bin/python
> /usr/bin/sm 0 9100 9452 11292 14574 root /usr/bin/newrelic-infra 1440 17348
> 17378 17828 520 root /opt/puppetlabs/puppet/bin/ 20636 40140 40168 40592 566
> jetty /usr/lib/jvm/java-8-openjdk 493896 958124 958381 959804 [1] 
> https://unix.stackexchange.com/questions/244735/why-are-slab-objects-not-reclaimed-automatically

Hi,

The last line from smem sticks out with high usage figures:
566 jetty /usr/lib/jvm/java-8-openjdk 493896 958124 958381 959804

I don't use jetty (or java) so don't know if this normal but
googling "openjdk memory usage for jetty" (or "openjdk 8 jetty memory")
suggests a few ideas.  

In particular, some people wrote about "an issue in Java8/9 that 
manifests itself in Jetty due to the annotations module that scans the 
jars and has a memory l

Re: stuck at Debian's text installer numerical Software Selection menu

John, I do enjoy giving back by documenting and reporting bugs.

Is there some way, at least theoretically, that you know of to get the
text installer to record the output and the responses it think its
receiving? There's going to be an issue if the media is read-only and
it can't write files, that's why I say "at least theoretically".

I know that if an installation is successful, one can do

debconf-get-selections --installer

to get all the variables but I was hoping for something a little more
low level. Thanks.

Alan

On 4/30/18, john doe  wrote:
> On 4/30/2018 12:01 PM, Alan Tu wrote:
>> Thanks John for confirming how things are supposed to work, that helps
>> because it narrows things down and I don't need to wonder what is the
>> correct way. In MIPS it turns out choices 10 11 is the default.
>> Problem averted/bypassed.
>>
>> We're not going to solve it here, but its still weird. Entering 10 11
>> on x86 is the first thing I tried, and gnome and the rest were still
>> installed. The text installer is weird, sometimes I enter number,
>> Enter and am asked the same question again.
>>
>
> Looks like a bug , are you experiencing the same behavior with an older
> version?
>
> For testing purposes I would check if it is fixed in the below link and
> reported if needed:
>
> https://www.debian.org/devel/debian-installer/
>
> --
> John Doe
>
>

Re: Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

2018-04-30 Thread tomas

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Apr 30, 2018 at 03:00:07PM +0300, Abdullah Ramazanoglu wrote:
> On Mon, 30 Apr 2018 06:43:03 +0200 to...@tuxteam.de said:

[...]

> > It seems this issue is fixed upstream. Would you like to check that?
> > 
> > Tone down. Apply Hanlon's razor generously [...]

> This is not about systemd or some bug or something. This is about attitude.

Exactly my point :-)

On a more practical note: care to double-check whether the
issue is actually fixed upstream?

Cheers
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlrnCvMACgkQBcgs9XrR2kZD9QCdEI7zDR095Tl3jJJ75WepugAY
fmQAnjwlbPGH8wykcQYeyJP5XQl862mF
=MPfd
-END PGP SIGNATURE-

Re: Debian glossary?

Oh, and PS: it is not very clear to me in what you wrote what you are having 
trouble understanding -- if you are seeking answers, maybe you should ask more 
clearly.

From my peanut gallery observation of this thread, I think one of your 
problems is that the device you are tying to use (to install Linux, iirc?) is 
mounted with the nodev option, which, somebody explained in a followup post, 
is not what you want to use.

Are you familiar with the mstab, fstab, mount, and umount commands?  I think 
it would be helpful if you were...

On Monday, April 30, 2018 08:23:43 AM rhkra...@gmail.com wrote:
> On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> > Debian documentation NOT written for hoi polloi.

Re: Debian glossary?

On Monday, April 30, 2018 07:46:01 AM Richard Owlett wrote:
> Debian documentation NOT written for hoi polloi.

...

> Man pages by their nature/purpose assume a certain level of expertise.
> They can be daunting for the uninitiated.
> 
> Comments?

True.  Have you read one or more general introductions to Linux (I have none 
to suggest at the momen).

Man pages are (or were, at least) intended to be more reminders for people 
that have at least a basic understanding of the command (or subject) rather 
than a tool to learn about it from scratch.

(When I switched from Windows to LInux, I found it very frustrating until I 
read several introductions to Linux (of various sorts, including at least 
skimming some thick books full of commands), and, I joined a local LUG.)

Debian glossary?


Debian documentation NOT written for hoi polloi.

I've been trying to debug my usage of debootstrap.
Therefore been reading many man pages - often with incomplete comprehension.
E.G. In reply to one of my questions a gentleman replied with the proper 
syntax for one command. He followed it with several quotations from a 
man page [subtle hint to read same ;]. I replied that I had read the man 
page, but even after reading his excerpts I still didn't comprehend.


This morning's partial set of items I do not grok include:


Partial output of "mount -l" is
"/dev/sdc1 on /media/richard/rco1 type ext4 
(rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2) [rco1]".


{ (...) Although I can interpret many items, several I can't. I suspect 
(...) is trying to tell me something by which items are/aren't listed.}


Output of "ls -Rdl /media/richard/rco1" is
"drwxr-xr-x 3 root root 4096 Apr 28 23:49 /media/richard/rco1".

{ In "drwxr-xr-x 3", what do "d" and "3" tell me? }

https://manpages.debian.org/stretch/mount/mount.8.en.html says in part:
/begin quote
strictatime
Allows to explicitly request full atime updates. This makes it 
possible for the kernel to default to relatime or noatime but still 
allow userspace to override it. For more details about the default 
system mount options see /proc/mounts.

/end quote

{ Having used a file manager to look at /proc/mounts without 
comprehension, I interpreted the context of "/proc/mounts" to indicate 
that there would be a reference to it elsewhere in 
https://manpages.debian.org . Nope. }


https://manpages.debian.org/stretch/mount/mount.8.en.html makes several 
references to "block special device".

{ "block special device" ??? }

Man pages by their nature/purpose assume a certain level of expertise.
They can be daunting for the uninitiated.

Comments?

anacron mysteriously not working

2018-04-30 Thread Michael Lange

Hi,

on my laptop (with Stretch) anacron for some reason refuses to work, which
I only noticed initially when I discovered that the syslog had become
rather huge, so apparently logrotate had not been performed for months.

cron itself is working, which I can tell by a custom script
in /etc/cron.hourly which runs reliably.
anacron is installed with default configuration (to make sure I purged
and reinstalled anacron). 
anacron does not start the pending jobs after boot, regardless if the
device runs on battery or AC power.
What baffled me most is that when I manually invoke anacron with
# anacron -fnd
it does not seem to do anything except writing a message into the syslog,
apart from this the command immediately returns. I thought this command
should at least do *something* at any rate (at least on my desktop
machine when I run it two times in succession the second run also takes
its time to complete).

When I invoke the cron jobs manually with
# run-parts --report /etc/cron.daily (resp. -.weekly or -.monthly)
everything seems to work as expected (e.g. logs are rotated properly).

I looked up
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=stable;package=anacron
which actually showed some similar looking bug reports, however as far as
I can see none of these really matches the problem here.

Does anyone have an idea what else I could try?

Thanks in advance,

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8

Re: stuck at Debian's text installer numerical Software Selection menu

2018-04-30 Thread john doe


On 4/30/2018 12:01 PM, Alan Tu wrote:

Thanks John for confirming how things are supposed to work, that helps
because it narrows things down and I don't need to wonder what is the
correct way. In MIPS it turns out choices 10 11 is the default.
Problem averted/bypassed.

We're not going to solve it here, but its still weird. Entering 10 11
on x86 is the first thing I tried, and gnome and the rest were still
installed. The text installer is weird, sometimes I enter number,
Enter and am asked the same question again.



Looks like a bug , are you experiencing the same behavior with an older 
version?


For testing purposes I would check if it is fixed in the below link and 
reported if needed:


https://www.debian.org/devel/debian-installer/

--
John Doe

Re: stuck at Debian's text installer numerical Software Selection menu