Re: Update to Sid, and cannot compile Nvidia module; PIC mode?

[Jimmy Johnson]

On 10/28/2016 08:11 PM, Dirk Laebisch wrote:

Anyone else run into this on Sid very recently?  Any hints or pointers?


Yup.
Providing some compile flags in:
/usr/src/linux/Makefile
around line 614 fixed it for me.

 614 # force no-pie for distro compilers that enable pie by default
 615 KBUILD_CFLAGS += $(call cc-option, -fno-pie)
 616 KBUILD_CFLAGS += $(call cc-option, -no-pie)
 617 KBUILD_AFLAGS += $(call cc-option, -fno-pie)
 618 KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)

After that, dkms succeeded and no further problems ... so far.

Regards
Dirk


Hi Dirk, what driver is that?  I have eight systems here using 304 and 
I'm having to use the Debian packages and then downgrade to 
jessie-backports works for me because the package from Nvidia would not 
install the module.


Maybe you can give a step by step?

Thanks for the info,
--
Jimmy Johnson

Debian Sid/Testing - KDE Plasma Version 5.8.2 - EXT4 at sda15
Registered Linux User #380263

Re: Update to Sid, and cannot compile Nvidia module; PIC mode?

[Dirk Laebisch]

> Anyone else run into this on Sid very recently?  Any hints or pointers?

Yup. 
Providing some compile flags in:
/usr/src/linux/Makefile 
around line 614 fixed it for me.

 614 # force no-pie for distro compilers that enable pie by default
 615 KBUILD_CFLAGS += $(call cc-option, -fno-pie)
 616 KBUILD_CFLAGS += $(call cc-option, -no-pie)
 617 KBUILD_AFLAGS += $(call cc-option, -fno-pie)
 618 KBUILD_CPPFLAGS += $(call cc-option, -fno-pie)

After that, dkms succeeded and no further problems ... so far.

Regards
Dirk

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Richard Owlett]

On 10/28/2016 5:17 PM, Brian wrote:

On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:


Be aware sir that you are the cause of:
multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
10^^Bels
an "innocent"[snicker] senior citizen is about to have many sleepless
nights
multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !

On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:

Did you take a look at the package pmount?
I use it to mount external disks.
It requires no changes to /etc/fstab.


Just in case you have not perceived this quiet discrete message:
   I have not come across pmount before


Yes you have. It is on the wiki page

  https://wiki.debian.org/Installation+Archive+USBStick

You read this page about a week or so ago (you told us so) but seemed
more concerned about its style rather than its substance.



*BULL*
Said page may have included the string "pmount".

But it gave no useful info!

Re: resolvconf troubles

[Igor Cicimov]

On 28 Oct 2016 12:21 pm, "Glenn English"  wrote:
>
> Does anyone know how to get rid of resolvconf?
>
> I'm putting a server together, and resovlconf keeps wiping my
/etc/resolv.conf file and replacing the nameserver IP with "# Created by
resolvconf" (approx). No nameserver, no anything.
>
> I removed it with Aptitude, and the file started talking about being
built with dhcpd. Nameserver still wiped, and Aptitude says there's no
package called dhcpd.
>
Thats the dhcp client, check
https://wiki.debian.org/NetworkConfiguration#Defining_the_.28DNS.29_Nameservers

It can also rewrite the /etc/resolv.conf file when in use. Look for
dhclient3 process, its usually started by NetworkManager.

> These things seem to be triggered by an ifupdown, to either state. I
removed some cruft that triggered it; now ifupdown doesn't any more, but a
reboot does. As best I can tell, there's nothing in man or on the 'Net
about removing it or just making it stop killing my nameserver file.
>
> This is a server. It will have a very stable nameserver IP. I'd like to
be able to create a file containing the IP and not have 'helpful' software
scribble on the file.
>
> Any and all suggestions will be appreciated...
>
> --
> Glenn English
>

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Brian]

On Fri 28 Oct 2016 at 15:42:27 -0500, Richard Owlett wrote:

> Be aware sir that you are the cause of:
>multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> 10^^Bels
>an "innocent"[snicker] senior citizen is about to have many sleepless
> nights
>multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !
> 
> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> >Did you take a look at the package pmount?
> >I use it to mount external disks.
> >It requires no changes to /etc/fstab.
> 
> Just in case you have not perceived this quiet discrete message:
>   I have not come across pmount before

Yes you have. It is on the wiki page

 https://wiki.debian.org/Installation+Archive+USBStick

You read this page about a week or so ago (you told us so) but seemed
more concerned about its style rather than its substance.

-- 
Brian.

Re: dependencies problem to install lightworks on jessie

[e Lpe]

Ok, thanks for the lesson.
I made a mistake. I apologize.
I din't saw how as changed Debian distribution and community since 2002.
It's so far...
Forget this thread, or mail, call it as you want.
I will found a solution by myself.

And thanks to people try to help.
End off.


2016-10-28 14:31 GMT-04:00 Greg Wooledge :

> On Fri, Oct 28, 2016 at 07:19:47PM +0100, Brian wrote:
> > 4. There is a way to get your error mesaages in English but I have
> >forgotten how. Someone will be along in a while to explain how it
> >is done.
>
> If you're working from a command shell, you can do:
>
> export LC_ALL=C
>
> and then the rest of your commands should all produce output in the
> "C" locale (traditional US English, ASCII characters only).
>
> If you're working with a GUI, then all bets are off.  You might be able
> to restart the GUI application with the locale variables set differently,
> but if it's something like a display manager invoked directly from
> /sbin/init then it could become difficult.  Or, the GUI application may
> have its own internal language selection.
>
>

Re: [SOLVED] Re: [jessie] recording line-in using ALSA?

[deloptes]

Ric Moore wrote:

> pavucontrol should have been a depend on pulseaudio since the beginning
> as you can't do squat without it. Try to remove firefox and you lose
> your entire desktop. Go figure. Ric

Thank you Ric.

I don't think pavucontrol depends on pulseaudio

apt-cache show pulseaudio
Package: pulseaudio
Suggests: pavumeter, pavucontrol, paman, paprefs

SAP Business One Updated Directory

[Jacy]

Hi,

Would you be interested in SAP Business One users list for you marketing
campaign?

List contains: Name, Company's Name, Phone Number, Job Title, Email
address, Complete Mailing address, Company revenue, size, Web address etc.

You would also be interested in user contacts list for: SAP AG,
BearingPoint, Amazon, Sun Microsystem, Dropbox, Success Factors, VMware,
Invensys and many more.

Let me know your thoughts or pass on the message to the right person in
your company.

Await your response!

Regards,
Jacy

Re: EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[John L. Ries]

Better than what Archimedes did (yes, I know I'm top posting).

--|
John L. Ries  |
Salford Systems   |
Phone: (619)543-8880 x107 |
or (435)867-8885  |
--|


On Fri, 28 Oct 2016, Richard Owlett wrote:

> Be aware sir that you are the cause of:
>multiple renditions of the "Alleluia Chorus" [courtesy Handle] at >
> 10^^Bels
>an "innocent"[snicker] senior citizen is about to have many sleepless
> nights
>multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !
>
> On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:
> > Did you take a look at the package pmount?
> > I use it to mount external disks.
> > It requires no changes to /etc/fstab.
>
> Just in case you have not perceived this quiet discrete message:
>   I have not come across pmount before
>   The links I've found so far suggest the original author(s) were thinking of
> *ME*!
>
> In case you haven't got "the drift",
> *THANK YOU*
> I currently suspect this will be the key to resolving MULTIPLE purportedly
> unrelated conundrums :> *YMMV*
>
>
>

EUREKA!!!! - was [Re: Permissions for an entire PARTITION]

[Richard Owlett]

Be aware sir that you are the cause of:
   multiple renditions of the "Alleluia Chorus" [courtesy 
Handle] at > 10^^Bels
   an "innocent"[snicker] senior citizen is about to have many 
sleepless nights

   multiple nay-sayers will suffer "EGG ON FACE"  *ROFL* !

On 10/28/2016 2:30 PM, Jörg-Volker Peetz wrote:

Did you take a look at the package pmount?
I use it to mount external disks.
It requires no changes to /etc/fstab.


Just in case you have not perceived this quiet discrete message:
  I have not come across pmount before
  The links I've found so far suggest the original author(s) 
were thinking of *ME*!


In case you haven't got "the drift",
*THANK YOU*
I currently suspect this will be the key to resolving MULTIPLE 
purportedly  unrelated conundrums :> *YMMV*

Re: resolvconf troubles

[Brian]

On Thu 27 Oct 2016 at 19:03:21 -0600, Glenn English wrote:

> Does anyone know how to get rid of resolvconf?
> 
> I'm putting a server together, and resovlconf keeps wiping my 
> /etc/resolv.conf file and replacing the nameserver IP with "# Created by 
> resolvconf" (approx). No nameserver, no anything. 

You are building a server? Is this from Lego?

What makes you think your planning requires resovlconf to be on it?

In case my point is not obvious - don't install resovlconf. Your problems
go away when you take control.

-- 
Brian.

Re: Permissions for an entire PARTITION

[Jörg-Volker Peetz]

Did you take a look at the package pmount?
I use it to mount external disks.
It requires no changes to /etc/fstab.

Regards,
jvp.

Re: Update to Sid, and cannot compile Nvidia module; PIC mode?

[Jörg-Volker Peetz]

Will wrote on 10/28/16 17:21:
> Greetings,
> 
> I usually have to run the NVIDIA installer after a kernel update, but
> something has changed that has broken the process to build the
> proprietary Nvidia kernel module.  I've searched around a bit on the
> Intarwebs before coming to the list, so here goes.
> 
> 
> Installer: NVIDIA-Linux-x86_64-367.44.run
> 
> If I simply run the installer, if fails with this message:
> 
> ERROR: Failed to run `/usr/sbin/dkms build -m nvidia -v 367.44 -k
> 4.7.0-1-amd64`:
>  Kernel preparation unnecessary for this kernel.  Skipping...
> 
>  Building module:
>  cleaning build area...
>  'make' -j8 NV_EXCLUDE_BUILD_MODULES=''
> KERNEL_UNAME=4.7.0-1-amd64 modules(bad exit status: 2)
>  Error! Bad return status for module build on kernel:
> 4.7.0-1-amd64 (x86_64)
>  Consult /var/lib/dkms/nvidia/367.44/build/make.log for more
> information.
> 
> And, the output of /var/lib/dkms/nvidia/367.44/build/make.log:
> 
>   CC [M]  /var/lib/dkms/nvidia/367.44/build/nvidia/nv-instance.o
> /var/lib/dkms/nvidia/367.44/build/nvidia/nv-frontend.c:1:0: error: code
> model kernel does not support PIC mode

This is due to the last hardening changes in gcc-6 after 6.2.0-7 see bug reports
#841368, #841500, and #841533.
There's also given workarounds. See message #51 in #841368 and #52 in #841500.

Regards,
jvp.

Re: dependencies problem to install lightworks on jessie

[Greg Wooledge]

On Fri, Oct 28, 2016 at 07:19:47PM +0100, Brian wrote:
> 4. There is a way to get your error mesaages in English but I have
>forgotten how. Someone will be along in a while to explain how it
>is done.

If you're working from a command shell, you can do:

export LC_ALL=C

and then the rest of your commands should all produce output in the
"C" locale (traditional US English, ASCII characters only).

If you're working with a GUI, then all bets are off.  You might be able
to restart the GUI application with the locale variables set differently,
but if it's something like a display manager invoked directly from
/sbin/init then it could become difficult.  Or, the GUI application may
have its own internal language selection.

Re: dependencies problem to install lightworks on jessie

[Brian]

I did not respond to your post because it seemed like too much trouble
to get information from you. Fortunately for you Lisi (bless her heart)
did not ignore it.

e Lpe, you are now going to get a lecture. Sit back and enjoy it. :)



On Fri 28 Oct 2016 at 13:10:18 -0400, e Lpe wrote:

> " What have you tried?"
> 
> nothing yet. The missings dependencies are here : http://dpaste.com/2BVN1S6
> I think i can dowload it from debian website and install tem with dpkg but
> I affraid to brake my system
> 
> 2016-10-28 10:53 GMT-04:00 Lisi Reisz :
> 
> > On Friday 28 October 2016 02:13:44 e Lpe wrote:
> > > Hello,
> > >
> > > all is in the title.
> > > I can't install Lightworks on Jessie.
> > >
> > > What is the right way to install it ?
> >
> > What have you tried?

-

The lecture starts here.


1. In your first mail you said:

   > all is in the title.

   The title is for a brief description of the problem. *Never* rely on
   it (as you have done) to substitute for a good, clear expression of
   the issue. Like this:

  I downloaded www from  and tried to install www with
  'dpkg -i www'. But then I got yyy. Help!

   Of course, all of that may be incorrect. So you put in your own words.

2. Point 2 is that in the response to Lisi you gave a dpaste URL. The
   amount of information is so little it could easily be posted directly
   in your response. It makes people do something extra to help you.
   This could put them off responding. Don't use these paste thingies.
   Post everything here.

3. Here is a guessed solution to your problem. I hate guessing. Please
   post again with more detail if it does not fit what you want to do.

Install:

dpkg -i filename.deb

apt-get -f install

   This cannot break your system.

4. There is a way to get your error mesaages in English but I have
   forgotten how. Someone will be along in a while to explain how it
   is done.

-- 
Brian.

Re: dependencies problem to install lightworks on jessie

[e Lpe]

" What have you tried?"

nothing yet. The missings dependencies are here : http://dpaste.com/2BVN1S6
I think i can dowload it from debian website and install tem with dpkg but
I affraid to brake my system

2016-10-28 10:53 GMT-04:00 Lisi Reisz :

> On Friday 28 October 2016 02:13:44 e Lpe wrote:
> > Hello,
> >
> > all is in the title.
> > I can't install Lightworks on Jessie.
> >
> > What is the right way to install it ?
>
> What have you tried?
>
> Lisi
>
>

Re: iptables advice

[Dan Ritter]

On Thu, Oct 27, 2016 at 01:36:23PM +0200, Pol Hallen wrote:
> Hello all :-)
> 
> I've 2LAN (192.168.1/24 and 192.168.2/24) with these rules:
> 
> iptables -A FORWARD -s 192.168.1/24 -d 0/0 -j ACCEPT
> iptables -A FORWARD -m state --state ESTABLISHED,RELATED -d 192.168.1/24 -j
> ACCEPT
> 
> and same rules for 192.168.2/24: this allow each lan see other lan.
> 
> Can I deny only lan2 (192.168.2/24) to see lan1 (192.168.1/24) but allow
> lan1 see lan2?

It depends on what you mean by "see".

Do you mean 192.168.1/24 should be able to start connections to
192.168.2/24 and receive replies, but not the reverse?

If so, you want:

# .1 can send anything anywhere
-A FORWARD -s 192.168.1/24 -d 0/0 -j ACCEPT
# .2 can send back answers to .1
-A FORWARD -s 192.168.2/24 -d 192.168.1/24 \
 -m state --state ESTABLISHED,RELATED -j ACCEPT
# .2 is not allowed to establish new sessions to .1
-A FORWARD -s 192.168.2.24 -d 192.168.1/24 \
 -m state --state NEW -j DROP
# .1 can receive anything else
-A FORWARD -d 192.168.1/24 -d 0/0 -j ACCEPT

-dsr-

Re: Permissions for an entire PARTITION

[Greg Wooledge]

On Fri, Oct 28, 2016 at 10:28:54AM -0500, Richard Owlett wrote:
> I'll attempt to refine my problem definition.
> My primary use case is a laptop:
>   1. purchased explicitly for use as a test bed.
>   2. whose HD has been erased multiple times in ONE day.
>   3. is isolated from ANY network.
>   4. has multiple installs of Debian, primarily classed as:
>  a. a full GUI install - what one would get choosing all 
> installer defaults.
>  b. a GUI install limited to the tools I use routinely.
>  c. an install oriented to whatever my current experiment needs.
>   5. has 2 classes of "DATA Partitions":
>  a. those which UID 1000 may mount without entering any 
> password.
>  b. those which *ANY* user may mount only by using root 
> password.
> The second use case is an existing machine with WinXP which is 
> why I do not wish these "DATA Partitions" to be Windows readable.

Simply creating a Linux file system (ext3 or whatever) on the partition
should be enough to prevent Windows from mounting it (or "mapping" it,
or whatever Windows calls the act of opening up a file system for
use by applications).

> My original question had (apparently incorrectly assume that 
> partitions handled user/group/world permissions in the same 
> manner as file systems.

If you want to write files on this partition, it has to be formatted
with some kind of file system, and then mounted.  If the file system
is a unix-like one, then it will have unix file metadata like ownership,
group ownership and permissions.

> I gather that I can approximately solve the problem with 
> appropriate entries in /etc/fstab (pointer to good tutorial 
> please). That approach has short comings:

man fstab

Consider using file system labels so that you don't have to put cryptic
UUIDs into the fstab, or potentially volatile device names.

man e2label

>1. requires custom editing of /etc/fstab for each install.
>2. requires custom editing of /etc/fstab for each install
>   whenever a partition is added.

There is absolutely no way you're going to be able to mount a file system
as an ordinary user (UID 1000 or whatever) without putting a line in the
/etc/fstab file.  So then the goal becomes to make this process as easy
and foolproof as possible for yourself, or for whoever's doing these
hourly wipes and reinstalls.  I'd recommend e2label for this.

I don't know why you need users to be able to mount the file system via
commands, instead of just having them automatically mounted at boot time.
/etc/fstab would also be used for the latter.  That's how most file systems
work (/, /usr, /var, /home, etc.).

Re: Permissions for an entire PARTITION

[Richard Owlett]

On 10/25/2016 11:42 AM, Greg Wooledge wrote:

On Tue, Oct 25, 2016 at 11:33:23AM -0500, Richard Owlett wrote:

On 10/25/2016 10:40 AM, Greg Wooledge wrote:

The simplest way would be to synchronize your UID across all your
installed operating systems.  If your UID is, let's say, 1000 on every
system, and the files on the partition are owned by user 1000, then
user 1000 (you) will have ownership of the files whenever you mount
the partition.


That sounds like what I want.
I had previously created a ext2 partition on /dev/sda10 and a
label of jessie-dvds .
How do I inform the "WORLD" that it belongs to UID 1000?


Err... what?  I don't understand what you're asking.

You boot into an installed operating system.  Let's say it's Debian
wheezy.

You login as some user account.  Let's say it's "richard" with UID 1000.

Now you are richard, and you are UID 1000.

When the partition is mounted, any files on it that are owned by UID
1000 are yours for the taking.  You are UID 1000, even if the files
were created by UID 1000 from a different operating system.


Right now when I attempt to mount it, I am asked for root password.
Not acceptable.


So your actual question is how to *mount* the partition?  In the fstab
file, include the "user" option to allow non-root users to mount the
partition.  Better still, just make the partition mount automatically
at boot time (defaults).

Is there a particular reason you wanted the partition NOT to be mounted
by default, and to require the logged-in user to enter a command?




I have just re-read this entire thread and have my thought 
process joggled by some apparently unrelated posts.


I'll attempt to refine my problem definition.
My primary use case is a laptop:
  1. purchased explicitly for use as a test bed.
  2. whose HD has been erased multiple times in ONE day.
  3. is isolated from ANY network.
  4. has multiple installs of Debian, primarily classed as:
 a. a full GUI install - what one would get choosing all 
installer defaults.

 b. a GUI install limited to the tools I use routinely.
 c. an install oriented to whatever my current experiment needs.
  5. has 2 classes of "DATA Partitions":
 a. those which UID 1000 may mount without entering any 
password.
 b. those which *ANY* user may mount only by using root 
password.
The second use case is an existing machine with WinXP which is 
why I do not wish these "DATA Partitions" to be Windows readable.


My original question had (apparently incorrectly assume that 
partitions handled user/group/world permissions in the same 
manner as file systems.


I gather that I can approximately solve the problem with 
appropriate entries in /etc/fstab (pointer to good tutorial 
please). That approach has short comings:

   1. requires custom editing of /etc/fstab for each install.
   2. requires custom editing of /etc/fstab for each install
  whenever a partition is added.

Clearer than mud? ;/
TIA

Update to Sid, and cannot compile Nvidia module; PIC mode?

[Will]

Greetings,

I usually have to run the NVIDIA installer after a kernel update, but
something has changed that has broken the process to build the
proprietary Nvidia kernel module.  I've searched around a bit on the
Intarwebs before coming to the list, so here goes.


Installer: NVIDIA-Linux-x86_64-367.44.run

If I simply run the installer, if fails with this message:

ERROR: Failed to run `/usr/sbin/dkms build -m nvidia -v 367.44 -k
4.7.0-1-amd64`:
 Kernel preparation unnecessary for this kernel.  Skipping...

 Building module:
 cleaning build area...
 'make' -j8 NV_EXCLUDE_BUILD_MODULES=''
KERNEL_UNAME=4.7.0-1-amd64 modules(bad exit status: 2)
 Error! Bad return status for module build on kernel:
4.7.0-1-amd64 (x86_64)
 Consult /var/lib/dkms/nvidia/367.44/build/make.log for more
information.

And, the output of /var/lib/dkms/nvidia/367.44/build/make.log:

  CC [M]  /var/lib/dkms/nvidia/367.44/build/nvidia/nv-instance.o
/var/lib/dkms/nvidia/367.44/build/nvidia/nv-frontend.c:1:0: error: code
model kernel does not support PIC mode
 /* _NVRM_COPYRIGHT_BEGIN_

  CC [M]  /var/lib/dkms/nvidia/367.44/build/nvidia/nv.o
/usr/src/linux-headers-4.7.0-1-common/scripts/Makefile.build:294: recipe
for target '/var/lib/dkms/nvidia/367.44/build/nvidia/nv-frontend.o' failed
make[3]: *** [/var/lib/dkms/nvidia/367.44/build/nvidia/nv-frontend.o]
Error 1
make[3]: *** Waiting for unfinished jobs
/var/lib/dkms/nvidia/367.44/build/nvidia/nv.c:1:0: error: code model
kernel does not support PIC mode
 /* _NVRM_COPYRIGHT_BEGIN_


Searching on "error: code model kernel does not support PIC mode" yields
a few pages that are interesting, such as:
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-361/+bug/1574838

and
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574982?comments/19

>From Comment #19, if I add this to the Kbuild file included with the
Nvidia installer, it might compile:

EXTRA_CFLAGS += -fno-pie -fno-stack-protector

So, I unpack the Nvidia installer:
./NVIDIA-Linux-x86_64-367.44.run -x

Change directory into the installer directory, and modify the Kbuild file:
cd NVIDIA-Linux-x86_64-367.44/kernel

Modify the Kbuild file (line 59), with:
EXTRA_CFLAGS += -fno-pie -fno-stack-protector

Run the nvidia-installer from the extracted directory:
cd NVIDIA-Linux-x86_64-367.44 ; ./nvidia-installer

And I get this message:
ERROR: Unable to load the 'nvidia-drm' kernel module.

And from the log file, /var/log/nvidia-installer.log:

creation time: Thu Oct 27 16:29:35 2016
installer version: 367.44

PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

nvidia-installer command line:
./nvidia-installer

Unable to load: nvidia-installer ncurses v6 user interface

Using: nvidia-installer ncurses user interface
-> Detected 8 CPUs online; setting concurrency level to 8.
-> License accepted.
-> Installing NVIDIA driver version 367.44.
-> There appears to already be a driver installed on your system
(version: 367.44).  As part of installing this driver (version: 367.44),
the existing driver will be uninstalled.  Are you sure you want to
continue? (Answer: Continue installation)
-> Would you like to register the kernel module sources with DKMS? This
will allow DKMS to automatically build a new module, if you install a
different kernel later. (Answer: Yes)
-> Installing both new and classic TLS OpenGL libraries.
-> Installing both new and classic TLS 32bit OpenGL libraries.
-> Install NVIDIA's 32-bit compatibility libraries? (Answer: Yes)
-> Will install GLVND GLX client libraries.
-> Uninstalling the previous installation with /usr/bin/nvidia-uninstall.
Looking for install checker script at
./libglvnd_install_checker/check-libglvnd-install.sh
   executing: '/bin/sh
./libglvnd_install_checker/check-libglvnd-install.sh'...
   Checking for libglvnd installation.
   Checking libGLdispatch...
   Can't load library libGLdispatch.so.0: libGLdispatch.so.0: cannot
open shared object file: No such file or directory
Will install libglvnd libraries.
-> Searching for conflicting files:
-> done.
-> Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64'
(367.44):
   executing: '/sbin/ldconfig'...
-> done.
-> Driver file installation is complete.
-> Installing DKMS kernel module:
-> done.
ERROR: Unable to load the 'nvidia-drm' kernel module.
ERROR: Installation has failed.  Please see the file
'/var/log/nvidia-installer.log' for details.  You may find suggestions
on fixing installation problems in the README available on the Linux
driver download page at www.nvidia.com.


Anyone else run into this on Sid very recently?  Any hints or pointers?

Thanks in advance,
Will

[CFP] FOSDEM 2017, RTC devroom, speakers, volunteers neeeded

[David Niklas]

## BTW: You may already have received a copy as
## this message requests people to forward.

Begin forwarded message:

Date: Mon, 24 Oct 2016 11:09:12 +0200 (CEST)
From: FOSDEM RTC Team 
To: ekiga-l...@gnome.org
Subject: [Ekiga-list] [CFP] FOSDEM 2017, RTC devroom, speakers,
volunteers neeeded


FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year.  FOSDEM 2017
takes place 4-5 February 2017 in Brussels, Belgium.  https://fosdem.org

This email contains information about:
- Real-Time communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- related events around FOSDEM, including the XMPP summit,
- social events (the legendary FOSDEM Beer Night and Saturday night
dinners provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs

Call for participation - Real Time Communications (RTC)
===

The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption.  The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.

The dev-room is only on Saturday, 4 February 2017.  The lounge will
be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored
Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc

To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce

Speaking opportunities
--

Note: if you used FOSDEM Pentabarf before, please use the same
account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 17 November.
Please use the Pentabarf system to submit a talk proposal for the
dev-room.  On the "General" tab, please look for the "Track" option and
choose "Real-Time devroom".  https://penta.fosdem.org/submission/FOSDEM17/

Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room.  It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the
form. You can find the full list of dev-rooms at
   https://www.fosdem.org/2017/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC
31 October.  Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit

First-time speaking?


FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before.  Please feel free to contact the dev-room
administrators personally if you would like to ask any questions about it.

Submission guidelines
-

The Pentabarf system will ask for many of the essential details.  Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators.  As the two previous dev-rooms have been
combined into one, we may decide to give shorter slots than in previous
years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.

Volunteers needed
=

To make the dev-room and lounge run successfully, we are looking for
volunteers:

- FOSDEM provides video recording equipment and live streaming,
  volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
  participants) for the evening of Saturday, 4 February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
  Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

See the mailing list discussion for more details about volunteering:
https://lists.fsfe.org

Re: resolvconf troubles

[Brian]

On Fri 28 Oct 2016 at 15:48:27 +0100, Lisi Reisz wrote:

> On Friday 28 October 2016 15:15:36 Brian wrote:
> > On Fri 28 Oct 2016 at 16:10:31 +0200, to...@tuxteam.de wrote:
> > > On Fri, Oct 28, 2016 at 02:51:56PM +0100, Brian wrote:
> > > > On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:
> > > > > On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > > > > > This was back in the day when removing it took half the system with
> > > > > > it.
> > > > >
> > > > > ...  and Gene was using Ubuntu??? ;-)
> > > > >
> > > > >  I have never, over many years, had any trouble removing N-M, which
> > > > > for years I did automatically at installation time.
> > > >
> > > > On the whole I would never argue about what a user chose to have on his
> > > > or her machine for networking. My own preference is for ifupdown or
> > > > connman, However, the many thousands of happy users of N-M are highly
> > > > likely to ignore advice to remove it based on some dim recollection
> > > > from ten years ago.
> > >
> > > Hm. I didn't take any of the mails in this thread as advising any of
> > > the "many thousands of happy users of N-M" to remove anything.
> > >
> > > Whatever floats your boat.
> >
> > This is not a quote from a private mail:
> >  > At high risk of starting another flame war about network-manager, nuke
> >  > that puppy with extreme prejudice.
> 
> It is not a quote from a private mail, but you have taken it out of context.  

That's the nature of quoting. And it was the first item in the mail (the
OP never mentioned N-M) so it sets the tone for the remainder of it.

> It was advice on list to an individual and solved that individual's problem.

The OP was not seeking advice on N-M, was he? Leaving out references to
N-M (and not mis-naming it) would not have detracted from the usefulness
of the post.

> It might well solve the problem of anyone else in the same position as the 
> OP.  My comment was not advice to anyone, merely pointing out that if you 
> happen to want to remove N-M, it is easy in Debian and does not require 
> removing half the system, (another quote).

That is useful to know.

-- 
Brian.

Re: resolvconf troubles

[David Wright]

On Fri 28 Oct 2016 at 15:15:36 (+0100), Brian wrote:
> On Fri 28 Oct 2016 at 16:10:31 +0200, to...@tuxteam.de wrote:
> 
> > On Fri, Oct 28, 2016 at 02:51:56PM +0100, Brian wrote:
> > > On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:
> > > 
> > > > On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > > > > This was back in the day when removing it took half the system with 
> > > > > it.
> > > > 
> > > > ...  and Gene was using Ubuntu??? ;-)  
> > > > 
> > > >  I have never, over many years, had any trouble removing N-M, which for 
> > > > years 
> > > > I did automatically at installation time.
> > > 
> > > On the whole I would never argue about what a user chose to have on his
> > > or her machine for networking. My own preference is for ifupdown or
> > > connman, However, the many thousands of happy users of N-M are highly
> > > likely to ignore advice to remove it based on some dim recollection from
> > > ten years ago.
> > 
> > Hm. I didn't take any of the mails in this thread as advising any of
> > the "many thousands of happy users of N-M" to remove anything.
> > 
> > Whatever floats your boat.
> 
> This is not a quote from a private mail:
> 
>  > At high risk of starting another flame war about network-manager, nuke
>  > that puppy with extreme prejudice.

And, tomas, don't overlook potential factoids such as these:

"Now this of course isn't going to work if you are carrying a lappy
and expecting to tap the wifi at any Starbucks you pull into.  Then
you are truly at the mercy of network-mangler, which might work but
usually doesn't."

and

"I have indeed used wicd, 3 or 4 times, []. But the last time I tried
it on a ubu 10-04 lts install, it had apparently been re-written, and
totally emasculated."

Cheers,
David.

Re: dependencies problem to install lightworks on jessie

[Lisi Reisz]

On Friday 28 October 2016 02:13:44 e Lpe wrote:
> Hello,
>
> all is in the title.
> I can't install Lightworks on Jessie.
>
> What is the right way to install it ?

What have you tried?

Lisi

Re: resolvconf troubles

[Lisi Reisz]

On Friday 28 October 2016 04:16:14 Glenn English wrote:
> > On Oct 27, 2016, at 8:39 PM, Cindy-Sue Causey 
> > wrote:
> >
> > BUT... Based on wandering through those pages, it looks like maybe
> > some searches related to "how do I add a dns server" (without quotes)
> > might land something. One thing I saw that sounded good *to me* was a
> > reference about declaring DNS nameserver information in
> > /etc/network/interfaces. If yours is/are staying the same, it sounds
> > like a possible solution.
>
> No, they aren't staying the same. That's my problem.
>
> But adding the nameserver to the interface configuration sounds like yet
> another good idea. I'll try that. Might bewilder resolvconf a lot.
>
> But Gene's idea of "nuking that puppy" has a nice sound to it.

Sorry, I thought that you had solved this bit.  Mea culpa.

Lisi

Re: resolvconf troubles

[Lisi Reisz]

On Friday 28 October 2016 15:15:36 Brian wrote:
> On Fri 28 Oct 2016 at 16:10:31 +0200, to...@tuxteam.de wrote:
> > On Fri, Oct 28, 2016 at 02:51:56PM +0100, Brian wrote:
> > > On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:
> > > > On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > > > > This was back in the day when removing it took half the system with
> > > > > it.
> > > >
> > > > ...  and Gene was using Ubuntu??? ;-)
> > > >
> > > >  I have never, over many years, had any trouble removing N-M, which
> > > > for years I did automatically at installation time.
> > >
> > > On the whole I would never argue about what a user chose to have on his
> > > or her machine for networking. My own preference is for ifupdown or
> > > connman, However, the many thousands of happy users of N-M are highly
> > > likely to ignore advice to remove it based on some dim recollection
> > > from ten years ago.
> >
> > Hm. I didn't take any of the mails in this thread as advising any of
> > the "many thousands of happy users of N-M" to remove anything.
> >
> > Whatever floats your boat.
>
> This is not a quote from a private mail:
>  > At high risk of starting another flame war about network-manager, nuke
>  > that puppy with extreme prejudice.

It is not a quote from a private mail, but you have taken it out of context.  
It was advice on list to an individual and solved that individual's problem.  
It might well solve the problem of anyone else in the same position as the 
OP.  My comment was not advice to anyone, merely pointing out that if you 
happen to want to remove N-M, it is easy in Debian and does not require 
removing half the system, (another quote).

Lisi

Re: resolvconf troubles

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 28, 2016 at 03:15:36PM +0100, Brian wrote:
> On Fri 28 Oct 2016 at 16:10:31 +0200, to...@tuxteam.de wrote:

[...]

> > Hm. I didn't take any of the mails in this thread as advising any of
> > the "many thousands of happy users of N-M" to remove anything.
> > 
> > Whatever floats your boat.
> 
> This is not a quote from a private mail:
> 
>  > At high risk of starting another flame war about network-manager, nuke
>  > that puppy with extreme prejudice.

Ho hum. I clearly saw a tongue in cheek somewhere. Richard?

:-P

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

iEYEARECAAYFAlgTZDkACgkQBcgs9XrR2kb5owCeIxGfxdzOZFUPBzJIs5t4VO0I
IBgAnime0m4Gw5PDU7McoWZX+x0eqpZ4
=THkf
-END PGP SIGNATURE-

Re: resolvconf troubles

[Brian]

On Fri 28 Oct 2016 at 16:10:31 +0200, to...@tuxteam.de wrote:

> On Fri, Oct 28, 2016 at 02:51:56PM +0100, Brian wrote:
> > On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:
> > 
> > > On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > > > This was back in the day when removing it took half the system with it.
> > > 
> > > ...  and Gene was using Ubuntu??? ;-)  
> > > 
> > >  I have never, over many years, had any trouble removing N-M, which for 
> > > years 
> > > I did automatically at installation time.
> > 
> > On the whole I would never argue about what a user chose to have on his
> > or her machine for networking. My own preference is for ifupdown or
> > connman, However, the many thousands of happy users of N-M are highly
> > likely to ignore advice to remove it based on some dim recollection from
> > ten years ago.
> 
> Hm. I didn't take any of the mails in this thread as advising any of
> the "many thousands of happy users of N-M" to remove anything.
> 
> Whatever floats your boat.

This is not a quote from a private mail:

 > At high risk of starting another flame war about network-manager, nuke
 > that puppy with extreme prejudice.

-- 
Brian

Re: resolvconf troubles

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, Oct 28, 2016 at 02:51:56PM +0100, Brian wrote:
> On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:
> 
> > On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > > This was back in the day when removing it took half the system with it.
> > 
> > ...  and Gene was using Ubuntu??? ;-)  
> > 
> >  I have never, over many years, had any trouble removing N-M, which for 
> > years 
> > I did automatically at installation time.
> 
> On the whole I would never argue about what a user chose to have on his
> or her machine for networking. My own preference is for ifupdown or
> connman, However, the many thousands of happy users of N-M are highly
> likely to ignore advice to remove it based on some dim recollection from
> ten years ago.

Hm. I didn't take any of the mails in this thread as advising any of
the "many thousands of happy users of N-M" to remove anything.

Whatever floats your boat.

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

iEYEARECAAYFAlgTXFcACgkQBcgs9XrR2kaVfwCcDgespAEUDWj7kI/82qfgXqic
BqAAnjvFjRitNiOSQK7AwtV+jD4Uhdsf
=PJEo
-END PGP SIGNATURE-

Re: resolvconf troubles

[Brian]

On Fri 28 Oct 2016 at 14:07:39 +0100, Lisi Reisz wrote:

> On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> > This was back in the day when removing it took half the system with it.
> 
> ...  and Gene was using Ubuntu??? ;-)  
> 
>  I have never, over many years, had any trouble removing N-M, which for years 
> I did automatically at installation time.

On the whole I would never argue about what a user chose to have on his
or her machine for networking. My own preference is for ifupdown or
connman, However, the many thousands of happy users of N-M are highly
likely to ignore advice to remove it based on some dim recollection from
ten years ago.

-- 
Brian.

Re: resolvconf troubles

[Lisi Reisz]

On Friday 28 October 2016 10:19:16 Gene Heskett wrote:
> This was back in the day when removing it took half the system with it.

...  and Gene was using Ubuntu??? ;-)  

 I have never, over many years, had any trouble removing N-M, which for years 
I did automatically at installation time.

Lisi

Re: Best practices for updating systems over extremely slow links

[Richard Owlett]

On 10/28/2016 4:14 AM, Karl E. Jorgensen wrote:

On Thu, Oct 27, 2016 at 03:45:21PM +, rbraun204 . wrote:

I have a couple of debian boxes in very remote areas that are connected back to
our wan via a 56kbps satellite link.  Most of the time we have a constant
stream of data coming/going to that machine so the link is saturated quite a
bit.

[snip]

Normally, I'd suggest looking into running a private mirror and
rsyncing it, but with only one machine at each location, that's
overkill.

I think you may want to look into apt-zip: This will decouple the
download from apt, allowing you to get the data xferred by whatever
method works (rsync?), and picking up the xferred file on the remote
location with apt...

Unfortunately, apt-zip has been discontinued - last appears in wheezy,
but it may still work or be made to work?  It seems aimed at your
exact use case...

Failing that I can imagine other (hand-crafted) solutions with these
components:

- make sure /etc/sources.list (and /etc/sources.list.d) are identical

- rsync /var/lib/apt/* across

- on the remote end: run:

 apt-get upgrade --print-uris  # or similar

- grab the URLs

- download the *.debs and rsync them into /var/cache/apt/archives/

- on the remote end:

 apt-get upgrade

This is entirely off the top of my head, but with a bit more thought
and scripting, it _should_ work...

Hope this helps
--
Karl


Would apt-offline be appropriate? It is a maintained Debian package.

offline APT package manager
   https://packages.debian.org/jessie/apt-offline
Welcome to Offline APT Package Manager project!
   http://apt-offline.alioth.debian.org/
Offline Package Management for APT

https://debian-administration.org/article/648/Offline_Package_Management_for_APT
Using APT Offline
   https://www.debian.org/doc/manuals/apt-offline/index.en.html

Re: Having problem with Debian's Installation Guide Preparing Files for USB Memory Stick Booting

[Stephan Beck]

Hi,

billwill onggo:
> I was trying to create a bootable USB flash disk following this guide :
> 4.3.3.2. Preparing Files For USB Memory Stick Booting > the flexible way >
> adding installer image
> https://www.debian.org/releases/stable/amd64/ch04s03.html.en#usb-copy-flexible
> 
> 
> Booting the USB installer gives me a 'kernel panic - vfs unable to mount
> root fs' booting the USB installer
> 
> This is strange, because several months ago i did successfully create a
> debian installer, using the same cd-image, following this same guide, and
> installed this Debian (i'm currently using to write this mail) into this
> machine.
> 
> After struggling almost an hour, i got it working. I found that the content
> of the syslinux.cfg is the culprit since I cant boot without the
> syslinux.cfg file and manually provide the boot parameter at boottime
> 
> boot: vmlinuz initrd=initrd.gz

I can't follow you here. If you really follow the installation guide
ch04s03.html.en#usb-copy-flexible, you have to create a syslinux.cfg
yourself, there is no existing syslinux.cfg (content), as you seem to be
telling us. Be aware that within 4.3. there are several ways:
syslinux.cfg does exist as a file using 4.3.2 as part of the
hd-media/boot.img.gz.
Did you select that? If not, there is no existing syslinux.cfg file.

[...]

Doing it the flexible way, the content of the syslinux.cfg to be created
should be (it's from the stick I used for a real installation, so
priority=medium is optional) :

default vmlinuz initrd=initrd.gz priority=medium

If you want to have the installer boot with that, but additionally want
to add some parameters at boot time, add a

prompt 1

line to the syslinux.cfg.
Please check that you haven't done steps that actually do not belong to
"the flexible way".

> 
> This is content of the syslinux.cfg the from installation guide :

Yes, you're talking about a not so flexible way.
> 
>> default vmlinuz
>> append initrd=initrd.gz
>>
>> Shouldn't it be something like this?
> 
>> default debi
>>
>> label debi
>> kernel vmlinuz
>> append initrd=initrd.gz
>>
Can't tell you anything about whether your observation here is right or
wrong.

Cheers

Stephan

Re: resolvconf troubles

[Gene Heskett]

On Friday 28 October 2016 03:30:30 to...@tuxteam.de wrote:

> On Thu, Oct 27, 2016 at 09:59:37PM -0400, Gene Heskett wrote:
> > On Thursday 27 October 2016 21:03:21 Glenn English wrote:
>
> [...]
>
> > At high risk of starting another flame war about network-manager,
> > nuke that puppy with extreme prejudice.
>
> I did that ~7 years ago. This was the day I plugged my laptop into the
> Ethernet at a customer's site and NM went "Oh, shiny, a wlan!" and
> *poof* I was out of the customer's network and in a captive coffeeshop
> WLAN.
>
> Enough was enough.
>
> To be fair, though, in my case it's dhclient overwriting my
> resolv.conf at boot. And it's supposed to do it (mobile laptop).
>
> [...]
>
> > sudo chmod +i /etc/resolv.conf
> > So nothing can scribble over it.
>
> This is a trick I use often to answer the question "who is scribbling
> over XXX?". Set immutable and see 'em complain in the logs :-)

In my case, n-m was denied that pleasure, and had the great good sense to 
just STHU.  I could see it bouncing around in the htop output as it 
struggled, but no logs were spammed and my network worked 100%. ISTR 
dhcpd wasn't even installed. This was then a trio of ubu 6-04 lts 
installs 10 years ago. Now there are 5 wheezy installs here, soon to be 
6 I think. I am expecting a raspi-3 Saturday.

This was back in the day when removing it took half the system with it.  
Now all the dependencies are gone, and it is removeable, so I thank 
$DIETY at every install around the coyote.den.  And my local network 
Just Works. Any of them has full, unrestricted access to ALL them 
innertubes. Whats not to love? :)

> regards
> -- tomás


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: Best practices for updating systems over extremely slow links

[Karl E. Jorgensen]

Hi

On Thu, Oct 27, 2016 at 03:45:21PM +, rbraun204 . wrote:
> I have a couple of debian boxes in very remote areas that are connected back 
> to
> our wan via a 56kbps satellite link.  Most of the time we have a constant
> stream of data coming/going to that machine so the link is saturated quite a
> bit.

Ouch. I guess that the data isn't for looking at cat videos then!

> I'm having all sorts of trouble getting apt to play nicely with the extremely
> slow link.  When I try to do an apt-get update,  it seems to work for a while,
>   then will start to download whichever list it's currently on all over 
> again. 
> I tried running apt-get update for about 24h and it would never completely
> download the amd64 main Packages.gz (around 7.5M).  It would just keep trying
> to start over and over again. Maybe sometimes it will work, but +50% of the
> time it will crap out.  Apt is configured to use a proxy server, aswell as
>  http::timeout is set to 300 via apt.conf
> 
> FWIW,  I can reliably rsync files over the sat link without issue.  It takes a
> while for sure,  getting about .75 - 1.5KB/s.   So the files do get there.  So
> it seems like whatever magic is baked into the rsync protocol to handle these
> slow links is working alot more reliably for me then the http gets that apt is
> using.  Running rsync with bwlimit will work all day I've found.

That's very odd. So TCP connections stay alive then.

> I'm currently trying to build a list of debs that the system wants using
> something like 
> 
> apt-get dist-upgrade --allow-unauthenticated -y --print-uris | grep -o '\
> 'http.*\' | tr "\'" " " > downloads
> 
> then wget'ing them locally and rsyncing them up the remote.  Seems to be
> working so far,  but the last failed apt-get update seemed to blow away the
> lists on the remote and I can no longer see any pending package upgrades on 
> the
> system.  
> 
> I've also tried tarring up /var/lib/apt/lists/* from a known working system 
> and
> rsyncing that up to the remote,  to try and update the lists manually I 
> guess. 
> But that didn't seem to work either.  After dropping the list files in 
> /var/lib
> /apt/lists and running apt-get dist-upgrade,  still showed no pending 
> updates. 
> So not sure why that would be.
> 
> So after all that,  here are my questions :)
> 
> 1.  Is there some crappy link tweaks I can use in apt to help apt with
> transferring data over a 1.5KB link?
> 
> 2.  In theory,  if I wanted to transfer the apt-get update data via rsync,
>  should I be able to tar up /var/lib/apt/lists/* and send that manually?  It
> didn't seem to work,  but I would imagine there's more going on behind the
> scenes.

if the sources.list are identical, yes: I believe that should work.

> 3.  Generally just curious what others have done when trying to keep systems 
> up
> to date in very remote places with limited pipes.
> 
> 
> Worst case scenario,  If we had to burn a cd full of debs monthly and ship it
> out to the remote I guess that would work.  We also have our own custom repos
> with software that gets updated aswell. But sometimes we would need to push
> those updates out asap.  Also,  there is only 1 machine at each remote,  so
> it's not an issue of running approx to save X machines all updating over the
> network at once.

Normally, I'd suggest looking into running a private mirror and
rsyncing it, but with only one machine at each location, that's
overkill.

I think you may want to look into apt-zip: This will decouple the
download from apt, allowing you to get the data xferred by whatever
method works (rsync?), and picking up the xferred file on the remote
location with apt...

Unfortunately, apt-zip has been discontinued - last appears in wheezy,
but it may still work or be made to work?  It seems aimed at your
exact use case...

Failing that I can imagine other (hand-crafted) solutions with these
components:

- make sure /etc/sources.list (and /etc/sources.list.d) are identical

- rsync /var/lib/apt/* across

- on the remote end: run:

apt-get upgrade --print-uris  # or similar

- grab the URLs

- download the *.debs and rsync them into /var/cache/apt/archives/

- on the remote end:

apt-get upgrade 

This is entirely off the top of my head, but with a bit more thought
and scripting, it _should_ work...

Hope this helps
--
Karl

Re: resolvconf troubles

[Mart van de Wege]

Glenn English  writes:

> Does anyone know how to get rid of resolvconf?
>
> I'm putting a server together, and resovlconf keeps wiping my
> /etc/resolv.conf file and replacing the nameserver IP with "# Created
> by resolvconf" (approx). No nameserver, no anything.
>
> I removed it with Aptitude, and the file started talking about being
> built with dhcpd. Nameserver still wiped, and Aptitude says there's no
> package called dhcpd.

Have you tried 'apt-cache search dhcpd'?

And if you are installing a server, why didn't you pick manual (static)
configuration during the install?

Mart

-- 
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.

Re: Ensure service keeps running with systemd

[Tobias Brink]

Michael Biebl  writes:

> Am 28.10.2016 um 00:50 schrieb Tobias Brink:
>> Hello!
>>
>> tl;dr: When a daemon exits "normally" (for example due to signal 15)
>>although it should not exit (because I did not call "systemctl
>>stop"), systemd does not consider it a failure.
>
> [..]
>
>> How do I tell systemd that it is a failure if the daemon is not running,
>> except if I explicitly killed it via "systemctl stop" or similar? I
>> either can't seem to find the right google query or this is not the
>> right way to go about this.
>
> There is also Restart=always
>
> See
> https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=

Whoops, that part should have been obvious. Thanks.

> and
> https://www.freedesktop.org/software/systemd/man/systemd.service.html#SuccessExitStatus=

I'm not sure if this helps. According to the documentation, an exit code
of 0 and termination by unhandled SIGHUP, SIGINT, SIGTERM, and SIGPIPE
is always treated as a successful exit. Assigning the empty string only
seems to reset it to this default. Apart from that, fetchmail may also
return "1" during a successful shutdown. If I don't add that, systemd
will complain during "systemctl stop" that shutdown of the daemon was
not clean. This is not what I want.

So, Restart=always works, but I still can't get systemd to notify me if
the service is restarted after exiting with a code of "0". The solution
may be to send a notification every time the service starts, but I want
to avoid being notified every time the computer is rebooted or if I
restart the service manually.

Thanks,

Tobias

Re: resolvconf troubles

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Oct 27, 2016 at 09:59:37PM -0400, Gene Heskett wrote:
> On Thursday 27 October 2016 21:03:21 Glenn English wrote:

[...]

> At high risk of starting another flame war about network-manager, nuke 
> that puppy with extreme prejudice.

I did that ~7 years ago. This was the day I plugged my laptop into the
Ethernet at a customer's site and NM went "Oh, shiny, a wlan!" and
*poof* I was out of the customer's network and in a captive coffeeshop
WLAN.

Enough was enough.

To be fair, though, in my case it's dhclient overwriting my resolv.conf
at boot. And it's supposed to do it (mobile laptop).

[...]

> sudo chmod +i /etc/resolv.conf
> So nothing can scribble over it.

This is a trick I use often to answer the question "who is scribbling
over XXX?". Set immutable and see 'em complain in the logs :-)

regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlgS/pYACgkQBcgs9XrR2kbpuwCeL32zGFNW9J39BD1jEmUglP4I
i+EAn1whRMAMR7q5wWDsEBO5gWF48ceQ
=kfEz
-END PGP SIGNATURE-