Re: drive names and UUIDs, was Re: Intresting dd fsck grub uuid fstab action

[David Wright]

On Thu 01 Jun 2017 at 12:24:28 (-0400), Fungi4All wrote:

> Why don't just skip all this that we are in perfect agreement with and go to 
> the juicy part.
> After all uuids are unique and fstab are all correct, updating-grub would mix 
> match uuids in writing
> its grub.cfg
> Two uuids on the same entry! Over and over again till I edited it out to 
> the correct ones and it all worked.
> Why does everyone choses to skip on this issue and keeps explaining me over 
> and over
> what I have well understood by now?

Well, we don't have a lot of evidence. But we do have a tiny bit:

if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos3 
--hint-efi=hd0,msdos3 --hint-baremetal=ahci0,msdos3 --hint='hd0,msdos3' UUID on 
sda3 XXX
else
search --no-floppy --fs-uuid --set=root UUID on sda3 YYY
fi
insmod png

Not a lot of context, and also edited and unindented, so the best
I can do to try to find what wrote this is to grep "platform_search"
and that comes up with /usr/share/grub/grub-mkconfig_lib in grub-common.

Within this file are these lines (starting around l.169):

  # If there's a filesystem UUID that GRUB is capable of identifying, use it;
  # otherwise set root as per value in device.map.
  fs_hint="`"${grub_probe}" --device $@ --target=compatibility_hint`"
  if [ "x$fs_hint" != x ]; then
echo "set root='$fs_hint'"
  fi
  if fs_uuid="`"${grub_probe}" --device $@ --target=fs_uuid 2> /dev/null`" ; 
then
hints="`"${grub_probe}" --device $@ --target=hints_string 2> /dev/null`" || 
hints=
echo "if [ x\$feature_platform_search_hint = xy ]; then"
echo "  search --no-floppy --fs-uuid --set=root ${hints} ${fs_uuid}"
echo "else"
echo "  search --no-floppy --fs-uuid --set=root ${fs_uuid}"
echo "fi"
  fi
  IFS="$old_ifs"

I'll let the shell experts come up with ideas about how ${fs_uuid}
produces two different substitutions within three lines.
I have made one assumption, that these lines from grub.cfg are from
sections 00 throught 10.

Once you reach section 30, things are different. Although I still
would not expect to see the disagreement in UUIDs quoted above,
I wouldn't be surprised if the UUIDs in the lines   linux /boot/vmlinuz…
bore no relation to the other UUIDs because _this_ linux… line is
copied directly from grub.cfg files scattered elsewhere on the disks.

I can illustrate this with the following. Here's the first menuentry
(top level) in my wheezy partition, freshly generated, but then doctored
by inserting "doctored" in the title and zeroing the first two digits
of the UUID throughout this entry. (This grub.cfg is never actioned
because the MBR doesn't point to it.)


### BEGIN /etc/grub.d/10_linux ###
menuentry 'doctored Debian GNU/Linux, with Linux 3.2.0-4-686-pae' --class 
debian --class gnu-linux --class gnu --class os {
load_video
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set=root 
0097eef1-c934-4b8f-a76b-4b084d6cf6f0
echo'Loading Linux 3.2.0-4-686-pae ...'
linux   /boot/vmlinuz-3.2.0-4-686-pae 
root=UUID=0097eef1-c934-4b8f-a76b-4b084d6cf6f0 ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-3.2.0-4-686-pae
}


Now here are the first two menuentries in section 30 of my jessie
partition (which the MBR points to), generated after the above.
The first menuentry is the top-level one, the second is the
duplicate inside the submenu.

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Debian GNU/Linux (7.11) (on /dev/sda2)' --class gnu-linux --class 
gnu --class os $menuentry_id_option 
'osprober-gnulinux-simple-dd97eef1-c934-4b8f-a76b-4b084d6cf6f0' {
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 
--hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2'  
dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
else
  search --no-floppy --fs-uuid --set=root 
dd97eef1-c934-4b8f-a76b-4b084d6cf6f0
fi
linux /boot/vmlinuz-3.2.0-4-686-pae 
root=UUID=0097eef1-c934-4b8f-a76b-4b084d6cf6f0 ro quiet
initrd /boot/initrd.img-3.2.0-4-686-pae
}
submenu 'Advanced options for Debian GNU/Linux (7.11) (on /dev/sda2)' 
$menuentry_id_option 
'osprober-gnulinux-advanced-dd97eef1-c934-4b8f-a76b-4b084d6cf6f0' {
menuentry 'doctored Debian GNU/Linux, with Linux 3.2.0-4-686-pae (on 
/dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 
'osprober-gnulinux-/boot/vmlinuz-3.2.0-4-686-pae--dd97eef1-c934-4b8f-a76b-4b084d6cf6f0'
 {
insmod part_msdos
insmod ext2
set root='hd0,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint-bios=hd0,msdos2 

Re: HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

On 02/06/17 04:38 PM, Gary Dale wrote:
I have an HP Color Laserjet CP1215 printer attached to a Jessie server 
via USB. I'm trying to print to it from Stretch workstation. This has 
been failing for a long time now. It's not a new problem. I've tried 
removing the printer and re-finding it many times without success.


I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) 
driver on both the server and my workstation. However when I try 
printing anything from the workstation, it fails with a "Filter 
failed" message. The message appears on the CUPS Jobs page on both the 
workstation and server.


I can print directly from the server (e.g. test page using the CUPS 
Printers page or lp from the command line) but not from my workstation.


I can print to another printer (Samsung C410) attached to the server, 
also by USB, using the same protocol (dnssd:) and it works. The major 
difference is that the it's using the Samsung C410 Series (color) driver.


The cups error log on the server isn't helpful. The first message that 
it shows for a failing job is:


E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter 
errors; please consult the error_log file for details.


Further down it shows these interesting messages:

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-originating-host-name=192.168.1.24'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-originating-host-name=192.168.1.24.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-creation=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-creation=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-processing=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-processing=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in 
CUPS: Off

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 

D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: 
/var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process 
"/var/spool/cups/d02241-001": Unknown filetype.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could 
not print file /var/spool/cups/d02241-001

D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2


Any ideas?


BTW: the same thing happens when I use the hpcups driver.

How to delay resume after suspend to get disks ready, using kernel command line switch?

[Ram Ramesh]

Problem:

I am having a problem with ubuntu 14.04 resume from suspend. I suspect a 
race condition in boot process. I have a mpt2sas (LSISAS2008: 
FWVersion(20.00.07.00)) host adapter to which several of my disks are 
attached. On occasions, there is a delay before these devices become 
available. However, kernel tries to assemble RAID6 that includes these 
disks before they become available. As a result the array gets assembled 
in a degraded mode.


My question:

I like to tell kernel to delay resume until LSI card finishes its card 
identifying devices. Can I use resumedelay/rootdelay switches in 
grub.cfg to accomplish this? If so, which one I should use?


Ramesh

HP CP1215 - CUPS not printing from Stretch to Jessie server.

[Gary Dale]

I have an HP Color Laserjet CP1215 printer attached to a Jessie server 
via USB. I'm trying to print to it from Stretch workstation. This has 
been failing for a long time now. It's not a new problem. I've tried 
removing the printer and re-finding it many times without success.


I'm using the HP Color LaserJet CP1215 Foomatic/foo2hp (recommended) 
driver on both the server and my workstation. However when I try 
printing anything from the workstation, it fails with a "Filter failed" 
message. The message appears on the CUPS Jobs page on both the 
workstation and server.


I can print directly from the server (e.g. test page using the CUPS 
Printers page or lp from the command line) but not from my workstation.


I can print to another printer (Samsung C410) attached to the server, 
also by USB, using the same protocol (dnssd:) and it works. The major 
difference is that the it's using the Samsung C410 Series (color) driver.


The cups error log on the server isn't helpful. The first message that 
it shows for a failing job is:


E [02/Jun/2017:14:17:27 -0400] [Job 2241] Job stopped due to filter 
errors; please consult the error_log file for details.


Further down it shows these interesting messages:

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Printing system options:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-uuid=urn:uuid:33ae3777-92ed-3ade-5cc3-a52464b726bc.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'job-originating-host-name=192.168.1.24'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
job-originating-host-name=192.168.1.24.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-creation=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-creation=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Pondering option 
'time-at-processing=1496427439'
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Unknown option 
time-at-processing=1496427439.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] CM Color Calibration Mode in 
CUPS: Off

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Options from the PPD file:
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 


D [02/Jun/2017:14:17:27 -0400] [Job 2241] File: /var/spool/cups/d02241-001
D [02/Jun/2017:14:17:27 -0400] [Job 2241] 

D [02/Jun/2017:14:17:27 -0400] [Job 2241] Cannot process 
"/var/spool/cups/d02241-001": Unknown filetype.
D [02/Jun/2017:14:17:27 -0400] [Job 2241] Process is dying with "Could 
not print file /var/spool/cups/d02241-001

D [02/Jun/2017:14:17:27 -0400] [Job 2241] ", exit stat 2


Any ideas?

FYI: Stretch release party zaterdag 18 juni

[Geert Stappers]

Nu ook op deze mailinglist.

Vertel het ook verder.


On Fri, Jun 02, 2017 at 10:56:38PM +0200, Geert Stappers wrote:
> 
> Hoi,
> 
> Mensen achter het e-mail adres ontmoeten is altijd goed.
> 
> Deze keer gebruiken we de release van Stretch als reden  :-)
> 
> 
>  
> https://wiki.debian.org/ReleasePartyStretch#ReleasePartyStretch.2FNetherlands.2FAmsterdam.The_Netherlands:_Amsterdam
>  https://wiki.techinc.nl/index.php/Debian_Release_Party
> 
> 
> Dus als je wat met "Debian" hebt, in de breedste zin,
> kom dan zaterdag 17 juni naar Technologia Incognita.
> 
> 
> Groeten
> Geert Stappers
> 
> - Forwarded and edited message from Chris Lamb -
> 
> Date: Wed, 31 May 2017 21:16:16 +0100
> From: Chris Lamb
> To: debian-devel-annou...@lists.debian.org
> Subject: Bits from the DPL (May 2017)
> 
> 
> Dear fellow developers,
> 
> 
> Upcoming «stretch» release
> ==
> 
> In case you have missed it, the tireless Release Team have announced
> they plan to release «stretch» on June 17th![7]  Do re-read over
> their announcement as it contains some important deadlines.
> 
> We should celebrate all our effort however; please check the release
> party page[8] on the Debian Wiki for an event near you. If there are
> none currently arranged for your area, please jump in and arrange one.
> 
>   [7] https://lists.debian.org/debian-devel-announce/2017/05/msg2.html
>   [8] https://wiki.debian.org/ReleasePartyStretch
> 
> 
> 
> See you next month!
> 
> 
> Regards,
> 
> - -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> 
> - End edited message -
> 
> -- 
> Groeten
> Geert Stappers
> -- 
> Leven en laten leven
> 

-- 
Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Issue with notebook (maybe the battery?)

[David Wright]

On Sat 27 May 2017 at 21:55:06 (-0300), Daniel Bareiro wrote:
> Hi, David.
> 
> On 24/05/17 22:23, David Wright wrote:
> 
> >> When you talk about "the numbers", do you mean to see by the console the
> >> values that are obtained for both batteries (voltage, for example) to
> >> make a comparison?
> 
> > Yes, the bash function I use is:
> > 
> > battery () 
> > { 
> > local BATTERYFILE="/sys/class/power_supply/BAT0/uevent";
> > [ ! -r $BATTERYFILE ] && printf '%s\n' "$BATTERYFILE not found!" && 
> > return 1;
> > date +%Y-%m-%d-%H-%M-%S;
> > cat $BATTERYFILE;
> > local FILEBATNOW="/sys/class/power_supply/BAT0/charge_now";
> > local FILEBATPREV="/sys/class/power_supply/BAT0/charge_full";
> > local CHARGE=$(( 100 * $(< $FILEBATNOW) / $(< $FILEBATPREV) ));
> > [ $CHARGE -lt 100 ] && printf '%s\n' "Charge: $CHARGE%"
> > }
> 
> Interesting... thanks for sharing :-)
> 
> I had to modify it because in my case I don't have "BAT0/charge_full"
> and "BAT0/charge_now". I have "BAT0/energy_now" and "BAT0/energy_full".
> Maybe you're using Stretch or a Backports kernel?

I get the same filenames on my systems with wheezy, jessie, and the
latter using a backported 4.9 kernel. But I've never investigated
where these decisions are made. Similarly it's a mystery to me why
wheezy gives one laptop two sound controls, whereas jessie gives
it five.

> > (I run a slightly more sophisticated version that also
> > reads the CPU temperature, has error trapping, and changes
> > the root window colour according to battery state and,
> > if frying, temperature.)
> 
> It would be interesting to see it :-)

Sure. Feel free to modify it to your taste. The laptop I wrote it
for has one critical temperature point (99), hence the two headroom
values which are arbitrary. The first would be reached at such
times as playing videos, so it warned me in case it was lying
on a soft surface, which interferes with its ventilation.

This laptop, which is older, appears to be more sophisticated,
having four trip point temperatures, and also a battery temperature.
But it doesn't overheat so I've never bothered to modify the code.

The charge colours are more useful most of the time, especially
when the batteries are as old as these are.

Cheers,
David.
#!/usr/bin/env python3
##
## background-changer.py for python 3.4
##
## Changes the X background according to various parameters.
## In this case, it's the thermal state and battery status according
## to the list below. Note that running with -? tests whether the
## colours are specified precisely (including correct capitalisation).
##
## Started from ~/.xsession-1-$HOST for appropriate machines and
## run in the background with &.
##
## Converted from a shell script because it seems to need error processing
## to work with 3.x kernels: /sys/class/power_supply/BAT0/current_now
## can disappear immediately after its existence has just been tested.
##
## Written by David Wright, Copyright © 2013--2015 David Wright

VERSION = '2015 May 08 10:00'

COLURGENTTHETA = 'brown' # Temperature emergency as very high
COLHIGHTHETA = 'red' # Temperature warning as quite high
COLACOK = 'green' # AC and OK; if charging, then only a trickle
COLLOPUMP = 'DarkTurquoise' # Charging a little
COLMEDPUMP = 'DarkGreen' # Charging
COLHIPUMP = 'blue' # Charging a lot
COLONBATTERY = 'yellow' # Plenty of charge, but running on battery power
COLLOWBATTERY = 'DeepPink' # Battery getting low
COLDEADBATTERY = 'DarkViolet' # Battery almost flat

REPETITION = 5
HEADROOMERR = 15 # this is bad and shouldn't ever be seen
HEADROOMWARN = 20 # this is normal when compiling kernel or playing video
HImA = 1000 # Charging a lot
MEDmA = 400 # Charging
LOmA = 150 # Charging a little
LOWBATT = 25 # Battery getting low
FLATBATT = 10 # Battery almost flat

## File locations and values to test:
THETAMON = '.theta-monitor'
BATTMON = '.charge-state'
FILETHETA = '/sys/class/thermal/thermal_zone0/temp'
FILETRIP = '/sys/class/thermal/thermal_zone0/trip_point_0_temp'
MINVALIDTHETA = 1 # make sure we're reading m°, not °
FILEBATNOW = '/sys/class/power_supply/BAT0/charge_now'
FILEBATPREV = '/sys/class/power_supply/BAT0/charge_full'
FILEBATCURR = '/sys/class/power_supply/BAT0/current_now'
FILEBATSTAT = '/sys/class/power_supply/BAT0/status'
STRMORE = 'Charging'
STRLESS = 'Discharging'

COLOURS = 'xcolors'
PAINT = 'xsetroot'
RGBFILE = '/etc/X11/rgb.txt'
FONT = '12x24'
SIZE = '500'

GETOPT = 'd?'

import getopt
import os
import shutil # skip testing for which when python3.2 is history
import subprocess
import sys
import tempfile
import time

# main program

opts = {}
try:
optlist, args = getopt.getopt(sys.argv[1:], GETOPT)
for (o, d) in optlist: opts[o] = d
except:
opts['-?'] = None

progname = os.path.basename(sys.argv[0])
debug = '-d' in opts

if '-?' in opts or len(args):
colours = open(RGBFILE).readlines()
colourdict = {}
for j in colours:
if j[0] == '!': continue
k = j.split(None, 

Re: Discovering alternative commands

[David Wright]

On Thu 01 Jun 2017 at 17:46:31 (+0200), to...@tuxteam.de wrote:
> On Thu, Jun 01, 2017 at 10:23:58AM -0500, David Wright wrote:
> > On Thu 01 Jun 2017 at 09:20:08 (-0500), Richard Owlett wrote:
> > > On 06/01/2017 08:14 AM, to...@tuxteam.de wrote:
> > > >-BEGIN PGP SIGNED MESSAGE-
> > > >Hash: SHA1
> > > >
> > > >On Thu, Jun 01, 2017 at 07:22:36AM -0500, Richard Owlett wrote:
> > > >>I'm working on a problem that requires as input an association of
> > > >>disk partitions and their "label" (in gparted sense).
> > > >>
> > > >>I already have blkid and lsblk. They are obviously designed for
> > > >>different purposes. They both _can_ supply the desired information.
> > > >>Neither is ideal for me.
> > > >
> > > >You're always so whimsical :)
> > > 
> > > *ROFL* I disagree.
> > 
> > I agree very much.
> > 
> > > My questions may be weird, obtuse, or convoluted. Rarely, if ever,
> > > whimsical ;)
> > > What people have said about my world view for >70 yrs best left ...
> > 
> > The problem with whimsical is that it has two meanings. From the web,
> > for ease of cut and paste,
> > 
> > 1.
> > playfully quaint or fanciful, especially in an appealing and amusing way.
> > "a whimsical sense of humor"
> > 
> > No, not that.
> > 
> > 2.
> > acting or behaving in a capricious manner.
> > "the whimsical arbitrariness of autocracy"
> > 
> > Yes, exactly that. You read people's answers and then pronounce upon
> > them in accordance with your thinking, which we're not party to
> > because you rarely if ever reveal it.
> 
> See? I meant it even slightly differently. From wiktionary:
> 
>   Given to whimsy; capricious; odd; peculiar; playful; light-hearted or 
> amusing.
> 
> For me, it's something between odd, peculiar, playful and amusing.
> I *know* it's some kind of emergent behaviour, and not ill-intentioned
> at all. It makes (for me) interaction more difficult, but more
> enriching at the same time. And somewhat joyful. So there you go.
> 
> > As an example, you wrote above:
> > 
> > > >>I already have blkid and lsblk. They are obviously designed for
> > > >>different purposes. They both _can_ supply the desired information.
> > > >>Neither is ideal for me.
> > 
> > with not a hint of what would be ideal.
> 
> Context. I once had a boss who functioned as Richard does. He had
> a very complicated context in his mind, and when posing a question,
> he offered lots of hints, but with some regularity not those his
> interlocutors needed. Once I got over that I learnt that this kind
> of interaction can be enriching and fun.

There's context here too: we're not meeting face to face,
nor in private, nor is Richard the boss and this list his employees.

> People are quite different, and that is a Good Thing :)
> 
> > Right. So are we meant to spend time looking for different commands
> > which, importantly, must reveal must either reveal more information
> > or the same information in a different way, in order that perchance
> > it might be more ideal for you?
> 
> You always have the choice to throw up your hands (as I did in this
> case).
> 
> [...]
> 
> > Oh, so my question above was wrong. We're expected to find _all_
> > commands, regardless of whether they might be more ideal or not.
> 
> Don't take that personally. I don't think it's meant like that
> (Richard: I'm taking the liberty of second-guessing you. I hope
> you set me straight if I'm too wrong!).

Well, we're probably wasting our time anyway. If you take a look at
https://lists.debian.org/debian-user/2016/11/msg00234.html
there's a productive command there that the OP has already forgotten,
which AIUI reads the files that I mentioned (though I stand to be
corrected; does /run contain the db that udevadm interrogates,
or is there a yet deeper db?).

Cheers,
David.

Ñ

[Jesus José López]

Enviado desde mi iPhoneyjvogg

Re: [HS] si mon fichier contient la premiere ligne

[Étienne Mollier]

Charles Plessy, le 2017-06-02 :
> Bonjour, c'est vendredi !

Bonjour, béni soit le vendredi !

> pourquoi s'ennuyer avec des outils standards alors qu'on a Perl
> 6 ?

Pourquoi s'ennuyer avec des outils alors qu'il y a tout ce qu'il
faut, tout frais compilé, au sein même des shells bash 3 et
plus ?  :-D

Si le fichier à lire est `fichier`, alors les trois commandes
suivantes devraient marcher :

$ builtin mapfile lignes < "fichier"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok

Considérant les fichiers `fichier0` à `fichier3` suivants et leur
contenu :

$ xxd fichier0 # vide
$ xxd fichier1 # une ligne sans caractère de fin de ligne
: 6e6f 656f 6c noeol
$ xxd fichier2 # une ligne avec caractère de fin de ligne
: 656f 6c0aeol.
$ xxd fichier3 # deux lignes
: 6c31 0a6c 320a   l1.l2.

Les résultat des commandes pour chacun de ces fichier est
disponible dans la copie d'écran suivante :

$ builtin mapfile lignes < "fichier0"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
$ builtin mapfile lignes < "fichier1"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
ok
$ builtin mapfile lignes < "fichier2"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok
ok
$ builtin mapfile lignes < "fichier3"
$ builtin test 1 = "${#lignes[@]}" && builtin echo ok

Bonne fin de builtin vendredi et bon builtin week-end,
--
builtin Étienne Mollier 

Re: Upcoming transition to Stretch

[Gene Heskett]

On Friday 02 June 2017 10:11:40 Michael Milliman wrote:

> On 06/02/2017 08:52 AM, Fungi4All wrote:
> > A sneaky way to have fun and be safe, not a very responsible user
> > for testing and experimenting, but if you are so afraid of tgings
> > blowing up and not knowing how to fix them here is a trick.
>
> I really enjoy troubleshooting problems, and am not afraid to do so.
> Unfortunately, I simply do not have the time to do this on a regular
> basis.  I always learn a great deal when I do, and that is one of my
> favorite things do do :) .  I have always gotten very good information
> here on the list when I have had to troubleshoot.
>
> > Let's say once a day, at the time you turn on your pc, you usually
> > do updates and upgrades.  What if you reverse the order of things.
> > You read your list email, be forwarned of past 24hrs of trouble,
> > then do and upgrade, then do an update which will not be in effect
> > until you apply it the next day.  The next day the cycle continues.
>
> This is an excellent idea.  I already look through the proposed
> upgrades and pick and choose what I allow on a package by package
> basis, so I'm already implementing the most time consuming part of
> this process.  I also look pretty closely at what a particular package
> upgrade brings with it (i.e. libraries that may have an affect on the
> system as a whole) before I bring an upgrade in.  That way I can
> manage the risks involved.  I'm not bork-proof, but I haven't borked
> the system yet.
>
> > For me, I get really sad when there is nothing new to upgrade now,
> > even if I am the first to face the trouble.  But there is also a
> > backup system which is not yet updated, so work can still be done.
> >
> > Sid is real debian to me, the rest is just debian too refined to be
> > debian.
> >
> > On the other hand, resolv.conf is a package in even Jessie that
> > needs "manual" configuration to work.  Despite what you do it is
> > still linux in its finest.  No  matter what you do each day you may
> > never know what will you learn or have to learn to get things done
> > by the next morning.  Sleep is for windows morons.

Warning thread hijack...

My machines are all still on either wheezy or jessie because of kernel 
pinning, its a realtime rtai patched kernel and my app, linuxcnc won't 
run without it.

My home network is host based and all behind a dd-wrt based router.  So 
rather than fixing resolv.conf by making it immutable in my latest pi 
install, since I had the u-sd card still in the reader, I went thru it 
looking for anything that might want to scribble my resolv.conf into a 
one liner stating it was created by such and such and otherwise empty, I 
removed the exec bits from the those files attributes.  Then I fixed 
resolv.conf to do what its supposed to do.  Neither fix generates any 
error messages to spam my logs.


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: Proper sources list from Jessie > Stretch

[Fungi4All]

Sorry for the top-post but I think it is appropriate

all good advice below but returning on the initial question without advice,
sid/unstable does not have a security.debian.repository
so just the two deb.debian are enough.

For someone with an urge to try the latest and finest you can go to sid
now and then revert to testing and brace for the tsunami.

But read this example as a sample:
Arch Linux Security Advisory ASA-201705-22
Severity: High
Date : 2017-05-30
CVE-ID : CVE-2017-7494
Package : samba
Type : arbitrary code execution
Remote : Yes
Link : https://security.archlinux.org/AVG-279
The package samba before version 4.5.10-1 is vulnerable to arbitrary
code execution.

The version of Jessie is still 4.2 stretch and sid are on 4.5.8 in arch 
based distros 4.5.10 is what they call stable!! This does not mean that 4.2 may 
not already be patched due to this security issue on jessie.
This is one package as an example.

 Original Message 
Subject: Re: Proper sources list from Jessie > Stretch
Local Time: June 1, 2017 2:28 PM
UTC Time: June 1, 2017 11:28 AM
From: d...@randomstring.org
To: Dejan Jocic 
debian-user@lists.debian.org

On Thu, Jun 01, 2017 at 09:19:29AM +0200, Dejan Jocic wrote:
> On 01-06-17, Fjfj109 wrote:
> > Hi - wondering if with a standard sources list in Jessie (or any stable):

> It is usually enough to change it to stretch, if you follow it up with
> all those update and upgrade commands. And read release documentation.
> But it is not good to go from stable directly to unstable. If you want
> to go to unstable, you first go to testing. Then, when you are sure that
> everything went fine, you switch to unstable. And, you make backup of
> your important data. Just in case.

This is odd advice. (Not the bit about backups. Backups are
always important.)

Stretch will become the new stable in a few weeks. Changing
to "stretch" will make that transition early, but changing to
"unstable" will make that transition and then, after stretch
becomes stable, will incur a lot of package churn and breakage.

If this discussion happened a year ago, the question would be
whether you really wanted to go to testing or to unstable. They
have different purposes.

-dsr-

-dsr-

Re: Upcoming transition to Stretch

[Michael Milliman]

On 06/02/2017 08:52 AM, Fungi4All wrote:
> A sneaky way to have fun and be safe, not a very responsible user
> for testing and experimenting, but if you are so afraid of tgings
> blowing up and not knowing how to fix them here is a trick.
I really enjoy troubleshooting problems, and am not afraid to do so.
Unfortunately, I simply do not have the time to do this on a regular
basis.  I always learn a great deal when I do, and that is one of my
favorite things do do :) .  I have always gotten very good information
here on the list when I have had to troubleshoot.
> Let's say once a day, at the time you turn on your pc, you usually
> do updates and upgrades.  What if you reverse the order of things.  
> You read your list email, be forwarned of past 24hrs of trouble,
> then do and upgrade, then do an update which will not be in effect
> until you apply it the next day.  The next day the cycle continues.
> 
This is an excellent idea.  I already look through the proposed upgrades
and pick and choose what I allow on a package by package basis, so I'm
already implementing the most time consuming part of this process.  I
also look pretty closely at what a particular package upgrade brings
with it (i.e. libraries that may have an affect on the system as a
whole) before I bring an upgrade in.  That way I can manage the risks
involved.  I'm not bork-proof, but I haven't borked the system yet.
> For me, I get really sad when there is nothing new to upgrade now,
> even if I am the first to face the trouble.  But there is also a backup
> system which is not yet updated, so work can still be done.
> 
> Sid is real debian to me, the rest is just debian too refined to be debian.
> 
> On the other hand, resolv.conf is a package in even Jessie that needs
> "manual" configuration to work.  Despite what you do it is still linux
> in its finest.  No  matter what you do each day you may never know
> what will you learn or have to learn to get things done by the next
> morning.  Sleep is for windows morons.
> 
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Upcoming transition to Stretch

[Michael Milliman]

On 06/02/2017 08:54 AM, Greg Wooledge wrote:
> On Fri, Jun 02, 2017 at 08:40:38AM -0500, Michael Milliman wrote:
>> Thank you Siard and Greg.  This does clear up this part of the process.
>> Currently, I have my sources.list pointed at Stretch, recently modified
>> from pointing to Testing in anticipation of potential issues.  I think
>> I'll go ahead and set it back to Testing (which is the same as Stretch
>> at the moment, so it is just a name change) and see what the ride is
>> like.  I can always point back to Stretch (then stable) and do some
>> serious work in Synaptic if there is too much blood flowing :)
> 
> Uh, no.  If you track testing, and receive new packages after the release,
> you will NOT be (guaranteed) able to go back to stretch.  Downgrading
> has never been supported, and is manual and messy at best, impossible
> at worst.
> 
I have had to downgrade (packages, not entire system) before. It is
indeed messy, and depending on the package, impossible as the downgrade
can affect almost the entire system (ala libc6).  But it is possible to
downgrade the whole systemthe process is very, very messy, no doubt.

> If you want to play around with testing in a reversible fashion, you
> should set up either a chroot or a virtual machine.  (Or a separate
> bootable partition, or a separate computer.)  Otherwise, once you bring
> in something like libc6 post-release, you are *committed* to the next
> testing cycle.
This sounds like a great learning opportunity. I don't have quite enough
hamsters in the cage to run a VM with any degree of performance (I need
to buy a few more hamsters :) ).  But using a chroot may well be a good
option.  I haven't done anything with chroot in the past (outside of
certain packages that do some of that behind the scenes).  This may be
an opportunity to learn how to set one up.
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Upcoming transition to Stretch

[Greg Wooledge]

On Fri, Jun 02, 2017 at 08:40:38AM -0500, Michael Milliman wrote:
> Thank you Siard and Greg.  This does clear up this part of the process.
> Currently, I have my sources.list pointed at Stretch, recently modified
> from pointing to Testing in anticipation of potential issues.  I think
> I'll go ahead and set it back to Testing (which is the same as Stretch
> at the moment, so it is just a name change) and see what the ride is
> like.  I can always point back to Stretch (then stable) and do some
> serious work in Synaptic if there is too much blood flowing :)

Uh, no.  If you track testing, and receive new packages after the release,
you will NOT be (guaranteed) able to go back to stretch.  Downgrading
has never been supported, and is manual and messy at best, impossible
at worst.

If you want to play around with testing in a reversible fashion, you
should set up either a chroot or a virtual machine.  (Or a separate
bootable partition, or a separate computer.)  Otherwise, once you bring
in something like libc6 post-release, you are *committed* to the next
testing cycle.

Re: Upcoming transition to Stretch

[Fungi4All]

A sneaky way to have fun and be safe, not a very responsible user
for testing and experimenting, but if you are so afraid of tgings
blowing up and not knowing how to fix them here is a trick.
Let's say once a day, at the time you turn on your pc, you usually
do updates and upgrades. What if you reverse the order of things.
You read your list email, be forwarned of past 24hrs of trouble,
then do and upgrade, then do an update which will not be in effect
until you apply it the next day. The next day the cycle continues.

For me, I get really sad when there is nothing new to upgrade now,
even if I am the first to face the trouble. But there is also a backup
system which is not yet updated, so work can still be done.

Sid is real debian to me, the rest is just debian too refined to be debian.

On the other hand, resolv.conf is a package in even Jessie that needs
"manual" configuration to work. Despite what you do it is still linux
in its finest. No matter what you do each day you may never know
what will you learn or have to learn to get things done by the next
morning. Sleep is for windows morons.

Re: Upcoming transition to Stretch

[Michael Milliman]

On 06/02/2017 07:03 AM, Greg Wooledge wrote:
> On Fri, Jun 02, 2017 at 12:35:12PM +0200, Siard wrote:
>> Michael Milliman:
>>> As I understand it, Stretch will become stable in a couple of weeks.
>>> At that time what is now Sid (unstable) will become Testing. Is this
>>> correct?
>>
>> No, that is not correct. :-)  Testing will be unaffected.
>> Depending on how you configure /etc/apt/sources.list, you can either
>> have Testing continue as Stable, or the new Testing.
> 
> To expand on this:
> 
> Debian developers upload the new versions of their packages into unstable.
> During normal times, when there is NOT a freeze in effect, packages
> which meet certain criteria (no release-critical bugs, all dependencies
> satisfied, etc.) will be copied automatically from unstable into testing.
> 
> That process is not taking place now, because of the freeze.
> 
> It is not accurate to say that unstable "becomes" testing.  It's more
> like closing/opening a dam to prevent a river from flowing.
> 
> Furthermore, there is a "slushy" effect which is preventing developers
> from uploading (most) new packages into unstable.  Doing so would
> distract from the efforts to clean up stretch for release.  In essence,
> unstable is also mostly-frozen right now.  (Nothing is 100% absolute,
> because these are developers we're talking about.  They're like cats.)
> 
> After the stretch release, there is going to be a tremendous influx of new
> packages in unstable, as developers want to play with all their new toys.
> The unstable->testing dam will also be opened, so after a couple days,
> when packages become eligible for copying, they'll start to appear in
> testing too.  Anyone who is tracking unstable or testing at this time
> should prepare for Extra Fun.
> 
Thank you Siard and Greg.  This does clear up this part of the process.
Currently, I have my sources.list pointed at Stretch, recently modified
from pointing to Testing in anticipation of potential issues.  I think
I'll go ahead and set it back to Testing (which is the same as Stretch
at the moment, so it is just a name change) and see what the ride is
like.  I can always point back to Stretch (then stable) and do some
serious work in Synaptic if there is too much blood flowing :)

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: RTL8812/8821 network cards

[Michael Milliman]

On 06/02/2017 04:03 AM, Michael Lange wrote:
> Hi,
> 
> On Thu, 1 Jun 2017 19:34:20 -0500
> Michael Milliman  wrote:
> 
>> Have you tried the package firmware-realtek??  I'm not absolutely
>> positive that the drivers available in this package will work with your
>> specific 8812/8821 chipset (there are more than one), but it does have
>> drivers for some 8812/8821 chipsets that may work.
> 
> from a quick glance at the page the OP has linked I doubt that any of the
> drivers that are currently included in the linux kernel will work with
> this chipset if you just add some firmware file(s), I guess this is the
> reason why the developers bothered to write that driver ;)
> 
> I have here a similar problem with a realtek8723bs chipset, the 8723ae
> and 8723be drivers are no good for that one.
> 
I've had a similar problem in the past (quite some time ago).  AIR, I
had to do some searching to find a driver that would compile under
Debian and install it myself.  I haven't used the device that required
that in quite a while, and it is not needed on my current system, but I
think that a usable driver did eventually find its way into the
Debian distribution.  One of the side-effects of Debian policy is that
it takes quite a while for these things to work their way through the
system to the distro.
>>From what the project page suggests, building and installing the 8821au
> driver seems to be easy enough (no patches and no additional firmware
> files required) so I think it should be possible to build a debian
> package which could be added to a custom debian iso.
> 
>>From what the OP writes however I am not sure if they meant to include the
> driver in the official debian distro instead. This would surely require
> the driver to be added to the official kernel first. Even if this happens
> there is no guarantee that debian will include it in their kernel
> packages (as is currently the case with the rtl8723bs driver which
> finally made it into the kernel but is not included in debian's 4.11
> kernel package).
> 
> Regards
> 
> Michael
> 
> 
>>
>> On 06/01/2017 05:49 PM, Jessica Litwin wrote:
>>>
>>>
>>> On Thu, Jun 1, 2017 at 6:31 PM, Wei-Shun Lo >> > wrote:
>>>
>>> Dear Debian,
>>>
>>> Is it possible to include below driver in the kernel for network
>>> installation?  
>>> Many cards are using this driver.
>>>
>>> https://github.com/abperiasamy/rtl8812AU_8821AU_linux
>>> 
>>>
>>> Best regards,
>>> Ralic 
>>> -- 
>>> 
>>> ************************************
>>> * _Contact Info_
>>> ** *
>>>  *US Mobile: 1-408-609-7628 >> 20609-7628>   * 
>>> Em
>>> ail: rali...@gmail.com
>>>  Line/ Skype :
>>> ralic_lo
>>> ************************************
>>> *
>>>
>>> *
>>>
>>>
>>>
>>> In the past I have made my own ISOs and included the contents of
>>> linux-firmware. Perhaps this may be something you can do also?
>>>
>>> // jkl
>>
>> -- 
>> 73's,
>> WB5VQX -- The Very Quick X-ray
>>
>>
> 
> 
> 
> .-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.
> 
> Uncontrolled power will turn even saints into savages.  And we can all
> be counted on to live down to our lowest impulses.
>   -- Parmen, "Plato's Stepchildren", stardate 5784.3
> 

-- 
73's,
WB5VQX -- The Very Quick X-ray

Re: Upcoming transition to Stretch

[Greg Wooledge]

On Fri, Jun 02, 2017 at 12:35:12PM +0200, Siard wrote:
> Michael Milliman:
> > As I understand it, Stretch will become stable in a couple of weeks.
> > At that time what is now Sid (unstable) will become Testing. Is this
> > correct?
> 
> No, that is not correct. :-)  Testing will be unaffected.
> Depending on how you configure /etc/apt/sources.list, you can either
> have Testing continue as Stable, or the new Testing.

To expand on this:

Debian developers upload the new versions of their packages into unstable.
During normal times, when there is NOT a freeze in effect, packages
which meet certain criteria (no release-critical bugs, all dependencies
satisfied, etc.) will be copied automatically from unstable into testing.

That process is not taking place now, because of the freeze.

It is not accurate to say that unstable "becomes" testing.  It's more
like closing/opening a dam to prevent a river from flowing.

Furthermore, there is a "slushy" effect which is preventing developers
from uploading (most) new packages into unstable.  Doing so would
distract from the efforts to clean up stretch for release.  In essence,
unstable is also mostly-frozen right now.  (Nothing is 100% absolute,
because these are developers we're talking about.  They're like cats.)

After the stretch release, there is going to be a tremendous influx of new
packages in unstable, as developers want to play with all their new toys.
The unstable->testing dam will also be opened, so after a couple days,
when packages become eligible for copying, they'll start to appear in
testing too.  Anyone who is tracking unstable or testing at this time
should prepare for Extra Fun.

Re: RTL8812/8821 network cards

[Greg Wooledge]

On Thu, Jun 01, 2017 at 10:53:08PM +, Wei-Shun Lo wrote:
> Yes, that is possible, however this card is supplied as a nano USB card
> that enable old computers that had no wifi card, so I would like to make a
> suggestion to include this card's firmware to Debian live's image.

Oh, you want it in debian-live, not in Debian.

The debian-live mailing list's web page is
.  I'd suggest posting debian-live
requests to that mailing list, instead of this one.

Re: [HS] si mon fichier contient la premiere ligne

[Lorenzo Bernardi]

On 06/02/2017 09:10 AM, David Martin wrote:

Tu avais raison, avec le \n ça fonctionne j'ai bien le compteur à 1


on peut utiliser l'astuce donnée par David Chalon faire un grep

[ "$(grep utilisateur BatchMajInfoUtilisateurEmargos20170602090001.log | 
wc -l)" ==  "1" ]  && echo 'ok' || echo 'KO'


devrait marcher.

Je vais remonter cette annomalie pour qu'il rajoute le \n dans le 
fichier généré,


en attendant on me demande de faire une moulinette qui vérifie que le 
script qui génère ce fichier

soit bien exécuter toutes les 15 mintues. voici son vrai nom :

voici : BatchMajInfoUtilisateurEmargos20170602090001.log

C'est ce fameux fichier qui doit contenir le \n

Je me demande bien comment faire ça, je peux rajouter dans le script 
en crontab, de générer un fichier

qui contiendrait la date du jour + heure et minute du genre

je ne comprends pas trop le problème. Je veux dire tu veux savoir si le 
fichier a été crée il y a moins de 15 minutes. En unix on ne connait pas 
la date de création d'un fichier mais en fait dans ton cas cela ne doit 
pas être un problème car j'imagine que la moulinette réécrit le meme 
fichier à chaque fois.


donc la commande stat doit pouvoir etre utiliser

par exemple

stat toto.txt

renvoie

  File: toto.txt
  Size: 0 Blocks: 0  IO Block: 4096   regular empty 
file

Device: fe01h/65025dInode: 537127084   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1001/ )   Gid: ( 1001/ )
Access: 2017-06-02 11:21:00.848700391 +0200
Modify: 2017-06-02 11:21:00.848700391 +0200
Change: 2017-06-02 11:21:00.848700391 +0200
 Birth: -

donc les date d'Acces de modification et de changement sont les meme. 
C'est la date de creation. Comme tu modifie pas le fichier à priori on 
doit pouvoir utiliser la date de modify.


On peut donc utiliser le script suivant.

# on recupere la valeur de modify et on extrait la date que l'on 
converti en timestamp (durée en seconde depuis 1970)

stattime=$(date -d "$(stat toto.txt | grep Modify | cut -c8-27)" +%s)

# on fait la différence entre la date courante et la date de 
modification de fichier.

diff=$(( $(date +%s) - $stattime ))


# on calcule si cette difference est superieur a 15*60 secondes
[ $diff -gt 600 ] && echo "more than 600" || echo "less than 600"



Tu mets ces lignes et tu lance un cron toute les x minutes qui verfie 
que tout est bon et si cela dépasse 15 minutes (le truc more than 600) 
tu fais quelque chose (envoi d'un courriel ou autre).


Bien sur il faut tester le truc et faire attention au fait que je teste 
le fichier toto.txt et pas ton fichier.


Le | grep Modify récupére la chaine de caractères Modify de la commande 
stat et le cut -c8-27 récupére la chaine de caractères entre la 8 et la 
27 eme position de la chaine initiale. Il faut bien regarder si cela 
colle avec la sortie de stat sur ta machine.
Le timestamp est utile car comme cela on ne fait qu'une soustraction en 
seconde.


Je suis pas très bon en bash et il faut peut être rajouter des tests 
pour être sur que le fichier existe ou autre subtilités.


Desolé si j'ai pas bien compris le problème


L.

Re: Upcoming transition to Stretch

[Siard]

Michael Milliman:
> As I understand it, Stretch will become stable in a couple of weeks.
> At that time what is now Sid (unstable) will become Testing. Is this
> correct?

No, that is not correct. :-)  Testing will be unaffected.
Depending on how you configure /etc/apt/sources.list, you can either
have Testing continue as Stable, or the new Testing.

Re: [A bit OT] Diagnosing home network

[Dan Purgert]

Mark Fletcher wrote:
> On Thu, Jun 01, 2017 at 10:39:07AM -, Dan Purgert wrote:
>> Curt wrote:
>> > On 2017-05-26, Mark Fletcher  wrote:
>> >>> 
>> >> It seems like you read my original problem as slowness accessing the 
>> >> internet. That isn't the problem, I'm concerned about intra-LAN speeds. 
>> >> Haven't even got the length of worrying about internet speeds yet, since 
>> >> there are so many variables that can impact that, I have to be sure my 
>> >> end is in tip-top shape before I start poking at that.
>> >
>> > Intra-LAN speeds; I thought you were speaking of transferring a movie
>> > file(?) between two computers on your LAN [...]
>> 
>> Think he goofed the word, but intranet ("LAN") speeds would affect
>> transferring a movie.
>> 
>
> No "goof"ing involved, thank you very much -- at least not at this end. 
> Intra-LAN means exactly what it says -- inside the LAN. "Inter" means 
> "between" -- "intra" means "inside". You seem like a native speaker of 
> English, I would have expected you to know that. Apologies if I am 
> wrong.

The reason I said you "goofed" is that there is no word "intra-LAN" used
in networking.  The closest (common) word would be "intranet", meaning
precisely what you wanted to convey with your word choice.

>
>> > [...] which couldn't proceed any faster than the receiving end could
>> > write that file to disk? I mean, would that not be a limiting factor,
>> > even with a quantum link?
>> 
>> I/O speeds of the drives are definitely a factor -- but pretty much
>> anything relatively decent (i.e. not those godawful 5400 RPM laptop
>> drives) can read fast enough to saturate a wifi link.  On the "writing"
>> side, it's buffered to RAM first, so that'll help (even with a godawful
>> slow 5400 RPM laptop drive).
>> 
>> SSD's shouldn't have much trouble (though, does kind of depend on the
>> SATA bus).
>> 
>
> Receiver is a high-end laptop hard disk. Based on regular usage of the 
> laptop I am extremely confident it is fast enough to not be a factor.  

Yeah, my comment was more directed at Curt, to explain that while disk
I/O "may" come into play, it really will only do so if the drive's
sustainable speeds are significantly lower than that of the network
link.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

Re: RTL8812/8821 network cards

[Michael Lange]

Hi,

On Thu, 1 Jun 2017 19:34:20 -0500
Michael Milliman  wrote:

> Have you tried the package firmware-realtek??  I'm not absolutely
> positive that the drivers available in this package will work with your
> specific 8812/8821 chipset (there are more than one), but it does have
> drivers for some 8812/8821 chipsets that may work.

from a quick glance at the page the OP has linked I doubt that any of the
drivers that are currently included in the linux kernel will work with
this chipset if you just add some firmware file(s), I guess this is the
reason why the developers bothered to write that driver ;)

I have here a similar problem with a realtek8723bs chipset, the 8723ae
and 8723be drivers are no good for that one.

>From what the project page suggests, building and installing the 8821au
driver seems to be easy enough (no patches and no additional firmware
files required) so I think it should be possible to build a debian
package which could be added to a custom debian iso.

>From what the OP writes however I am not sure if they meant to include the
driver in the official debian distro instead. This would surely require
the driver to be added to the official kernel first. Even if this happens
there is no guarantee that debian will include it in their kernel
packages (as is currently the case with the rtl8723bs driver which
finally made it into the kernel but is not included in debian's 4.11
kernel package).

Regards

Michael


> 
> On 06/01/2017 05:49 PM, Jessica Litwin wrote:
> > 
> > 
> > On Thu, Jun 1, 2017 at 6:31 PM, Wei-Shun Lo  > > wrote:
> > 
> > Dear Debian,
> > 
> > Is it possible to include below driver in the kernel for network
> > installation?  
> > Many cards are using this driver.
> > 
> > https://github.com/abperiasamy/rtl8812AU_8821AU_linux
> > 
> > 
> > Best regards,
> > Ralic 
> > -- 
> > 
> > ************************************
> > * _Contact Info_
> > ** *
> >  *US Mobile: 1-408-609-7628  > 20609-7628>   * 
> > Em
> > ail: rali...@gmail.com
> >  Line/ Skype :
> > ralic_lo
> > ************************************
> > *
> > 
> > *
> > 
> > 
> > 
> > In the past I have made my own ISOs and included the contents of
> > linux-firmware. Perhaps this may be something you can do also?
> > 
> > // jkl
> 
> -- 
> 73's,
> WB5VQX -- The Very Quick X-ray
> 
> 



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

Uncontrolled power will turn even saints into savages.  And we can all
be counted on to live down to our lowest impulses.
-- Parmen, "Plato's Stepchildren", stardate 5784.3

Re: [HS] si mon fichier contient la premiere ligne

[David - DCPC]

Bonjour,

Si tu as un mot ou phrase clé unique dans ta ligne ET dans ton fichier,
pourquoi ne pas faire un simple grep -c  ?

ça te diras combien de fois ta chaîne existe dans le fichier, et si c'est
unique, du coup tu as l'occurrence de ta ligne.

David

Le 2 juin 2017 à 08:50, David Martin  a écrit :

> Lorenzo,
>
> merci pour ton annalyse, je ne construit pas le fichier, c'est une
> application métier.
>
> Je vais essayer de le rajouter le \n pour voir
>
> --
> david martin
>
>


-- 
Salutations,
David CHALON

Re: [HS] si mon fichier contient la premiere ligne

[David Martin]

ah je ne connais pas... je vais regarder.



Le 2 juin 2017 à 09:15, Daniel Huhardeaux  a écrit :

> Le 02/06/2017 à 09:10, David Martin a écrit :
>
>> [...]
>>
>> Je me demande bien comment faire ça, je peux rajouter dans le script en
>> crontab, de générer un fichier
>> qui contiendrait la date du jour + heure et minute du genre
>>
>> /tmp/time
>>
>> 20170905 (pour 9h05)
>>
>> mais comment et avec quoi faire la comparaison pour savoir qu'à la
>> prochaine génération du fichier /tmp/time c'est bon ou pas.
>>
>>
> Utilise incron qui est un cron like permettant de gérer les événements
> concernant la gestion d'un système de fichier.
>
> --
> Daniel
>
>


-- 
david martin

Re: [HS] si mon fichier contient la premiere ligne

[Daniel Huhardeaux]

Le 02/06/2017 à 09:10, David Martin a écrit :

[...]

Je me demande bien comment faire ça, je peux rajouter dans le script 
en crontab, de générer un fichier

qui contiendrait la date du jour + heure et minute du genre

/tmp/time

20170905 (pour 9h05)

mais comment et avec quoi faire la comparaison pour savoir qu'à la 
prochaine génération du fichier /tmp/time c'est bon ou pas.




Utilise incron qui est un cron like permettant de gérer les événements 
concernant la gestion d'un système de fichier.


--
Daniel

Re: [HS] si mon fichier contient la premiere ligne

[David Martin]

Tu avais raison, avec le \n ça fonctionne j'ai bien le compteur à 1

Je vais remonter cette annomalie pour qu'il rajoute le \n dans le fichier
généré,

en attendant on me demande de faire une moulinette qui vérifie que le
script qui génère ce fichier
soit bien exécuter toutes les 15 mintues. voici son vrai nom :

voici : BatchMajInfoUtilisateurEmargos20170602090001.log

C'est ce fameux fichier qui doit contenir le \n

Je me demande bien comment faire ça, je peux rajouter dans le script en
crontab, de générer un fichier
qui contiendrait la date du jour + heure et minute du genre

/tmp/time

20170905 (pour 9h05)

mais comment et avec quoi faire la comparaison pour savoir qu'à la
prochaine génération du fichier /tmp/time c'est bon ou pas.

Je suis en panne sèche...

Je vais remonter de suite le problème d'anti-slash n




Le 2 juin 2017 à 08:50, David Martin  a écrit :

> Lorenzo,
>
> merci pour ton annalyse, je ne construit pas le fichier, c'est une
> application métier.
>
> Je vais essayer de le rajouter le \n pour voir
>
> --
> david martin
>
>


-- 
david martin

Re: [HS] si mon fichier contient la premiere ligne

[David Martin]

Lorenzo,

merci pour ton annalyse, je ne construit pas le fichier, c'est une
application métier.

Je vais essayer de le rajouter le \n pour voir

-- 
david martin

Heads Up! Stretch RC4 non-free netinstall iso has no non-free firmware.

[Jimmy Johnson]

Stretch-RC4-non-free-netinstall-iso has no non-free firmware, nor is it 
installing contrib. Both contrib and non-free are missing for main 
sources. Also I found the regions messed up/incorrect and corrected them 
in systemsettings.


No problems with RC3-non-free-netinstall-iso so use it if you are doing 
an install.

--
Jimmy Johnson

Debian Stretch - KDE Plasma 5.8.6 - Intel G3220 - EXT4 at sda11
Registered Linux User #380263

Re: Upcoming transition to Stretch

[Jimmy Johnson]

On 06/01/2017 05:38 PM, Michael Milliman wrote:

Hi folks,  I'm currently running Stretch, and have been for a couple of
months.  As I understand it, Stretch will become stable in a couple of
weeks.  At that time what is now Sid (unstable) will become Testing.  Is
this correct? If so, how disastrous might it be for me to upgrade from
Stretch to the new Testing?  Will this be a usable distribution, or
would it be advisable to wait for a little while before doing so?  I
don't have a problem with running on the "bleeding edge" as long as
there is not too much blood :)


I've been running Sid on sda15 since Etch, sometimes upstream will lower 
a version, making the installed version obsolete, it's nice to have 
synaptic installed to see these things, fixing Sid is rewarding. This 
ride with Stretch has been bumpy too, my Nvidia was out for a longtime 
due to kernels and KDE Plasma problems causing an install of XFCE4 to 
keep updated and repair the problem, I'm still doing a workaround on 
i965 but it maybe fixed now, I have it patched and working for the time 
being using a Ubuntu 16.04 kernel, anyways if this sounds fun crank up 
gparted and slice off about 14Gb's, install Stretch and add Sid and 
change Stretch to Testing. It's always a learning experience. :)

--
Jimmy Johnson

Debian Stretch - KDE Plasma 5.8.6 - Intel G3220 - EXT4 at sda11
Registered Linux User #380263

Re: problemas de conexion red lan linux mint 17

[Dixan Rivas]

El 02/06/17 a las 01:30, Oscar Martinez escribió:
> buenas noches lista vengo presentando problemas en mi red lan donde
> tengo diferentes equipos, hoy por lo menos en las oficinas sufrimos
> problemas de desconeccion constantes del servicio de red.
>
> inmediatemente nos fuimos a swiche y empesamos a desconectar a
> diferentes departamentos hasta que al desconectar al departamento
> numero 4 se restablecio la conectividad con toda normalidad.
>
> volvimos a conectar al departamento 4 y volvio a caer la red.
> inmediatemente nos fuemos a las oficinas del departamento 4 y
> empezamos a desconectar equipo por equipo y almismo tiempo probando la
> conectividad.
>
> haste que llegamos a un equipo que cada ves que lo desconectabamos se
> restablecia la conectividad.
>
> quien sabe de un proceso o un scrip de alguna pagina web que me pueda
> generar tal conflicto en la red 
>
> ayuda jejejeje gracias

Esto no es una lista de Redes, es de Debían, pero bueno ya que estamos
lo mas seguro una tarjeta de red defectuosa haciendo un bucle de trafico
y no tienes switch administrados así que no hay spanning tree que
bloquee el enlace.



signature.asc
Description: OpenPGP digital signature

Re: problemas de conexion red lan linux mint 17

[Felix Perez]

El día 1 de junio de 2017, 21:39, remgasis remgasis
 escribió:
> La causa subyacente no es esa, hicieron un trabajo totalmente impírico,
> eficaz, pero perjudicaron a los usuarios enlazados en el proceso. Para eso,
> una de las varias tareas que se debían hacer era observar el tráfico de ese
> segmento, protocolos, cables en corto ... Experimentaron donde debieron
> aplicar un conocimiento teórico objetivo sobre las capas ...
>
> Digo esto como sugurencia ... Que les vaya bien.

Por favor no contestes al privado y sin top posting.

Gracias.

-- 
usuario linux  #274354
normas de la lista:  http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html