date:20141124

On Sun, Nov 23, 2014 at 06:20:42PM -0500, Jerry Stuckle wrote:
 This isn't only about patches to Debian packages.  This is also about
 custom code many people have installed and set up to work with sysv
 init.  These will fail with systemd,

These *might* fail with systemd.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124074508.gb1...@chew.redmars.org

Re: systemd-free alternatives are not off topic.

On Sun, Nov 23, 2014 at 09:20:52PM -0500, Jerry Stuckle wrote:
 What about all of those people with custom software running which relies
 on sysv init for starting?  There are a lot of those systems out there -
 and every one of them will need work to conform to systemd.

Some may well work without further modifications.

 Many of those users will find it less time consuming and costly to change to
 another distro.

I'm sure you're right, there will be people who think installing a new distro
is less work than apt-get install sysvinit-core. I'm not sure they're right,
but they're free to do what they wish.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124074722.gc1...@chew.redmars.org

Re: systemd-free alternatives are not off topic.

On 24/11/14 13:20, Jerry Stuckle wrote:
 On 11/23/2014 8:42 PM, Ric Moore wrote:
 On 11/23/2014 12:17 PM, Jerry Stuckle wrote:
  That is the huge majority of Debian users.
 Some will get a rude surprise when they upgrade and things don't work as
 expected.

Apropos of what? That surprise from unexpected results through failure
to read release notes (adequately prepare) is no surprise. It's always
been the case - and ever will be.


 Like what?? I first installed systemd back when it was announced. I have
 yet to have a single problem with it.

 
 What about all of those people with custom software running which relies
 on sysv init for starting?  

They should continue using sysv, don't you think?

It's illogical to upgrade and not expect change - even when electing (as
Debian allows) to retain the same init system.

I'll be upgrading to Jessie on my main workstation and retaining systemv
- but before that I will:-
;expect change
;read the release notes
;read authoritative posts to Debian User
;plan for the worst case scenarios
;carefully weight up the possible benefits against the possible losses

I expect to get from the exercise what I put into it - and I am only
*certain* that I won't know the results until I've completed the
exercise as I lack psychic abilities (or the psychosis that is mistaken
for them) or the concrete facts from which to accurately deduct the
outcome in my specific instance and particular fit-for-purpose.

snipped

 
 Yes, and while the Linux community continues, Debian will lose a lot of
 dedicated users due to this decision.  Possibly another fork, or
 possibly another distro.  But Debian will lose users.

1. At best that's pure speculation. With all due respect to Gypsy Rose
Lee (who is really just a naughty boy), some of us engineer types
place little stock in soothsaying.

2. It's false logic to conclude *only* losses from change (and
duplicitous to deny that systemd is your only choice) - it overlooks the
possibility that the additional *choice* of systemd will attract more
users (and more instances - you do know that many administrators
manage large numbers of instances, right?). There is no evidence to show
that other distros and projects that adopted systemd as the *only*
choice lost users - quite the reverse.

 
 Sure, people who only run software in .deb packages won't be hit as
 hard. 

At all. And then only if *they* don't elect to stay with sysv.

 But that is definitely not the entire Debian user base.

Those that deploy customisations in the Debian Way should file bug
reports if those customisations are not supported *if* they change init
systems.
Upgrades have *always* supported customisations done the Debian Way -
and I have every confidence they will continue to do so

 
 Jerry
 
 


Kind regards

--
The pure and simple truth is the truth is rarely pure and never simple


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5472e494.8050...@gmail.com

Re: Headless server just got suspended by updating systemd

On Sun, Nov 23, 2014 at 08:58:46PM -0800, Matt Ventura wrote:
 I think the bug here IMO is that a system simply shouldn't *do*
 things in general without me telling it to. If I close the lid of my
 laptop, unless I have told it to suspend when I do so, then it
 shouldn't suspend. I should be telling my machine to do the things I
 want it to do, not telling it to not do the things I don't want it
 to do.

That's not the precedent set in Debian for some time now. The approach
we take is sensible defaults, and suspend on lid close (at least
whilst on battery power) is a sensible default. The other issue here is
that if you've told your system how you want it to behave once, it would
be ideal if you didn't have to tell it the same thing again.


-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124075902.gd1...@chew.redmars.org

Re: Headless server just got suspended by updating systemd

On Mon, Nov 24, 2014 at 02:29:28PM +0900, Joel Rees wrote:
 I don't mind having yet another reason for telling the developers they
 should have made the systemd based debian a parallel internal fork
 with an independent release schedule.
 
 But since they chose not to, this kind of bug is just expected to show
 up, and the only way we can clear bugs like these is to report them.

I guess your argument makes sense if you are talking about all source packages
from the systemd stable, including logind; it's unlikely Patrick's init system
was switched to systemd-as-init as a result of upgrading. Either way though,
he's moved from a 'testing' system at some indeterminate point in the past to
a 'testing' system now; neither are 'releases' and so the release schedule has
little relevance to his situation.

-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124080150.ge1...@chew.redmars.org

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread Stephan Seitz


On Mon, Nov 24, 2014 at 08:16:29AM +0100, Didier 'OdyX' Raboud wrote:

systemd supports sysvinit init scripts (that have the LSB headers which
are already mandatory in wheezy) just fine. Not doing so would be a bug,
of course.


I have initscripts without LSB headers working just fine. There are 
warnings, but it works.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread Joel Rees

2014/11/24 17:18 Jonathan Dowland j...@debian.org:

 On Mon, Nov 24, 2014 at 02:29:28PM +0900, Joel Rees wrote:
  I don't mind having yet another reason for telling the developers they
  should have made the systemd based debian a parallel internal fork
  with an independent release schedule.
 
  But since they chose not to, this kind of bug is just expected to show
  up, and the only way we can clear bugs like these is to report them.

 I guess your argument makes sense if you are talking about all source
packages
 from the systemd stable, including logind; it's unlikely Patrick's init
system
 was switched to systemd-as-init as a result of upgrading. Either way
though,
 he's moved from a 'testing' system at some indeterminate point in the
past to
 a 'testing' system now; neither are 'releases' and so the release
schedule has
 little relevance to his situation.

So, are you saying he shouldn't report a bug?

Re: ntpd confusion

2014-11-24 Thread mad

Am 24.11.2014 um 06:13 schrieb Chen Wei:
 On Sat, Nov 22, 2014 at 09:57:50PM +0100, mad wrote:
 # ntpq -p
 remote  refidst t when poll reach   delay   offset  jitter
 
 fritz.box   X.Y.Z.A   3 u-   6411.8740.153   0.052

 I use the default ntp configuration and other Debian installations
 directly on the internet use all four clock sources
 (0.debian.pool, 1.debian.pool...).

 
 Why not
 
 1) double check /etc/ntp.conf, make sure lines such as
 server 0.debian.pool.ntp.org exist.

Already done that multiple times.

 2) verify remote ntp server is reachable,
 # nmap -sU -p123 0.debian.pool.ntp.org

# nmap -sU -p123 0.debian.pool.ntp.org
Host is up (0.027s latency).
Other addresses for 0.debian.pool.ntp.org (not scanned): 85.10.246.226
141.30.228.4 192.53.103.108
rDNS record for 37.120.166.3: olymp.auf-feindgebiet.de
PORTSTATE SERVICE
123/udp open  ntp

Nmap done: 1 IP address (1 host up) scanned in 1.70 seconds

 On my system, even the unreachable server shows in ntpq -p output.

That is my problem! Not on my internal home network systems. As
mentioned, other Debian installations not on my home network, with the
same configuration show as expected four clock sources. Even starting
ntpd on the command line doesn't show any more data and ntpd is compiled
without debugging. Probably that is what I will do, recompile ntpd with
debug enabled and then see what ntpd is actually doing.

Could it have something to do with upnp, zeroconf or something like that?

mad


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54730145.8020...@sharktooth.de

Re: How to mount an iPod Touch

On 24/11/14 11:36, Marc Shapiro wrote:
 ERROR: Pairing with device ea1f2a0800d76f91f9bc0d50d6620151d249e6a9
 failed with unhandled error code -3

That's a plist error.
What is the output of idevicepair -d pair (you may need to paste the
output to paste.debian.net and provide a link to it in your reply).


Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547307d6.7080...@gmail.com

Re: How to mount an iPod Touch

Thanks for the replies.

On 24/11/14 05:12, Marc Shapiro wrote:
 On 11/23/2014 12:23 AM, Scott Ferguson wrote:
 Briefly as it's been 40 degrees Celsius here and I've been outside
 working all day (almost beer o'clock)

 On 23/11/14 18:27, Marc Shapiro wrote:
 On 11/22/2014 04:09 PM, Scott Ferguson wrote:
 On 23/11/14 09:50, Marc Shapiro wrote:
 My daughter has recently purchased an iPod Touch and would like to be
 able to maintain it from our linux box running Wheezy.

snipped

 You mention two devices - in which case I'd:-
 ;suggest you turn on udev debugging (as root udevadm control
 --log-priority=debug)
 Sorry - did you apply the above, and if so - what do the logs show?
 (please post any relevant information for all to reference.).
 
 Yes, I did.  What log should I be looking in and what should I be
 looking for?

syslog.

e.g. as root:-
tail -n 100 /var/log/syslog | less

 
 I apologize for not making it clear that I had tried all of these
 suggestions.
 
 The first thing that post says to do is to get the device node. That is
 my problem.  I do not have a device node for the iPod (see the output
 from dmesg and my comments, above).
 It's possible that a fusefs has grabbed the device... I have little
 experience with Apple devices so this is a learning curve for me to. I'm
 guessing you run GNOME - something else I have (very) little experience
 with.
 
 I am using Mate.  I do not like the Gnome 3 paradigm.

I no nothing of GNOME - but I believe Mate is just the visual part of
the DE (i.e. the vfs is still GNOME3)

 

 Please try unplugging the device, them, while running as root, udevadm
 monitor --property and posting the results from plugging the Apple
 device back in (if any).

 
snipped
 
 I will try the  udevadm monitor --property command once I have the
 device available again.
 
 Marc
 
 


-- 

Please post only plain-text:-
https://www.debian.org/MailingLists/#codeofconduct

The simple two-click method to send plain-text from Gmail web-interface:-
https://wiki.debian.org/DebianMailingLists#Gmail


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54730ae5.3030...@gmail.com

Re: Jessie B2 Installer Not booting in Macbook Air

2014-11-24 Thread Darac Marjal

On Fri, Nov 21, 2014 at 09:17:09PM -0700, john.tiger wrote:
 Have followed both guided partitioning  as well as trying manual partitions
 with efi boot as first partition.   Install works fine but after completion
 does not boot (get ? folder image)  - tried to boot into rescue mode but
 target partition not found
 
 partitions :
 free space 1 gb
 /efi 1 gb

I think that 1 GB is huge for an EFI partition. Even Windows only uses a
few hundred MB at most. Grub needs only a few kilobytes.

Also, you probably need to mount it at /boot/efi, ensure that it's
fat32-formatted and has a GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

 / 30 gb
 swap  4 gb
 /home   80 gb
 free space  4 gb
 
 tried to put efi as first partition but installer automatically puts 1gb
 free space in front
 
 also tried Fedora 20 - it boots fine
 
 would prefer to use Jessie
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject
 of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/54700e45.8040...@gmail.com
 


signature.asc
Description: Digital signature

EXT4-fr error, ext4_find_entry: reading directory...

2014-11-24 Thread linuxmasterjedi

Hi,

  Since a couple of days, I have a bunch of EXT4-fr error device ... 
ext4_find_entry: reading directory errors. 
  For me, that's only a disk issue, I booted on a sysresccd and did a e2fsck. 
Everything was OK. Then, I rebooted and I still had those errors. I bought 
another hard drive and copied all data from the old HD to the new one, 
re-install grub and booted on it. Worked like a charme but I still have those 
awful errors. I did another e2fsck with check blocks : nothing abnormal...

  Any ideas ? Could be a SATA cable / SATA controller / motherboard issue? How 
to identify the right problem?

 Thanks


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/18567784.4398064.1416831449879.javamail.r...@zimbra32-e6.priv.proxad.net

Re: EXT4-fr error, ext4_find_entry: reading directory...

2014-11-24 Thread Karl E. Jorgensen

Hi

On Mon, Nov 24, 2014 at 01:17:29PM +0100, linuxmasterj...@free.fr wrote:
 Hi,
 
   Since a couple of days, I have a bunch of EXT4-fr error device
   ... ext4_find_entry: reading directory errors. 

Sounds like stuff in the kernel log?

   For me, that's only a disk issue, I booted on a sysresccd and did
   a e2fsck. Everything was OK. Then, I rebooted and I still had
   those errors. I bought another hard drive and copied all data from
   the old HD to the new one, re-install grub and booted on
   it. Worked like a charme but I still have those awful errors. I
   did another e2fsck with check blocks : nothing abnormal...

How was the data copied? dd of the underlying device or copied at the
file level...

The errors in the kernel log sound like file-system level
inconsistencies.  Copying the data by using dd of the underlying
device would also preserve the filesystem level inconsistencies...

   Any ideas ? Could be a SATA cable / SATA controller / motherboard
   issue? How to identify the right problem?

Possibly. If so, I'd expect other clues in the kernel log complaining
about hardware issues

It could even be a power issue - lack of sufficient voltage can have
all sorts of weird and counter-intuitive results. And inconsistently
so.

Hope this helps
-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124122313.GA12505@hawking

Re: Why focus on systemd?

2014-11-24 Thread Marty


On 11/24/2014 02:14 AM, Didier 'OdyX' Raboud wrote:

Le dimanche, 23 novembre 2014, 18.09:58 Marty a Ã©crit :

Did I miss something?

Yes.


Option 1: init policy stands *won by default* [1]
Option 2: change init policy *LOST*
Option 3: ask nicely to follow init policy *lost*
Option 4: policy stands, no statement needed *WON*
Option 5: null option, further discussion *won by default*

[1] depending on bug status of package dependence on PID 1, so maybe
this is the real issue


Iff you're using the same option numbers as those on the ballot, that's
a totally wrong reading of the GR results, IMHO.

Option 4 won all pairwise duels against all other options, and as such,
is the winning option. All other options besides 5 (FD) won their
pairwise duels against FD. Saying that Option 1 (â€¦) won by default is
factually wrong. It's summary was not init policy stands either.

OdyX


This is only my interpretation as an armchair observer, also in the US
called Monday morning quarterback.

It was a policy vote. The only results that matter are their effect
on Debian Policy, right? The rest is academic.

The vote invoked a clause in the TC init decision to allow modifying or
overturning the policy set by the TC init decision, in anticipation of
confusion or disagreement over its effect.

Option 1 only restates or clarifies the existing init policy, 9.11,
which is designed to preserve init system choices and prevent the kind
of problems posed by systemd:

However, any package integrating with other init systems must also be
backwards-compatible with sysvinit ...

So that leaves only the PID 1 question (hence my footnote). Note,
however, that there is no reasonable way to claim that any package that
only works with systemd as PID 1 could be regarded as backwards
compatible with sysvinit, so Option 1 was a non-controversial
interpretation of Debian Policy (as I read the -vote discussion).
The only (or main) issue was only that it should be put to a vote,
or at least put to a vote in this way, hence Option 4 was included.

Option 4 states that the policy is fine and no restatement about PID 1
is needed. It does not say Option 1 is the wrong interpretation of
policy. Only Option 2 overturns policy, by negating Option 1. Option 4
indirectly negates Option 2 and does not say anything about any other
options.

Option 1 therefore wins by default, especially if the (apparent)
consensus about init coupling being a bug is affirmed in practice.
The project seems to be saying that the issue should be resolved case
by case and not be subject to a blanket rule, which seems reasonable
to me. The vote also explains why the GR was rejected the first time
around.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54732c74.8090...@ix.netcom.com

[OT] alternative to dsndynamic.com?

2014-11-24 Thread Hugo Vanwoerkom


Hi,

It seems dsndynamic.com bit the dust this weekend of the 23 of November. 
Is there an alternative of a free dsn server?


Hugo


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/m4vc2h$3ue$1...@ger.gmane.org

Re: systemd-free alternatives are not off topic.

On 11/23/2014 11:25 PM, Ric Moore wrote:
 On 11/23/2014 09:20 PM, Jerry Stuckle wrote:
 On 11/23/2014 8:42 PM, Ric Moore wrote:
 On 11/23/2014 12:17 PM, Jerry Stuckle wrote:
   That is the huge majority of Debian users.
 Some will get a rude surprise when they upgrade and things don't
 work as
 expected.

 Like what?? I first installed systemd back when it was announced. I have
 yet to have a single problem with it.


 What about all of those people with custom software running which relies
 on sysv init for starting?  There are a lot of those systems out there -
 and every one of them will need work to conform to systemd.  Many of
 those users will find it less time consuming and costly to change to
 another distro.  It can be very expensive to bring someone up to speed
 on the systemd, then change and test all of their custom software (or
 pay a consultant to do it for you).

 Many will be able to fix those problems - but at a cost of time and
 manpower.  Others will have neither the time nor the money to fix the
 problems, and still others will not have the technical expertise to do
 so.

 And yet the Linux community continues to lurch from pillar to post, as
 always, surviving by our collective wits. That is our strength. That
 part you just don't seem to appreciate, that nothing is ever static and
 that change that is inherent within our little meritocracy and is our
 greatness.


 Yes, and while the Linux community continues, Debian will lose a lot of
 dedicated users due to this decision.  Possibly another fork, or
 possibly another distro.  But Debian will lose users.
 
 
 How will Debian lose users? Debian is one of the LAST distros to adopt
 systemd. Wheezy is good for another couple of years and it's still
 running systemv. You're not suggesting that your user base will run
 Jessie anytime soon?
 
 Sure, people who only run software in .deb packages won't be hit as
 hard.  But that is definitely not the entire Debian user base.
 
 Again, if you stick with wheezy, you have zero immediate concerns for
 your scripts and customers.
 
 

There are other distros which don't use systemd, such as Gentoo.  Then
there is always BSD.

And while Wheezy will still be supported for a couple of years, it's not
necessarily the answer.  While many people don't want the latest and
greatest, they also don't want the oldest and baddest.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54733023.3070...@gmail.com

Re: EXT4-fr error, ext4_find_entry: reading directory...

2014-11-24 Thread linuxmasterjedi

- Mail original -
De: Karl E. Jorgensen k...@jorgensen.org.uk
À: debian-user@lists.debian.org
Envoyé: Lundi 24 Novembre 2014 13:23:13
Objet: Re: EXT4-fr error, ext4_find_entry: reading directory...

On Mon, Nov 24, 2014 at 01:17:29PM +0100, linuxmasterj...@free.fr
wrote:
Hi,

Since a couple of days, I have a bunch of EXT4-fr error device
... ext4_find_entry: reading directory errors.

Sounds like stuff in the kernel log?

yes, displayed on every TTY...

For me, that's only a disk issue, I booted on a sysresccd and did
a e2fsck. Everything was OK. Then, I rebooted and I still had
those errors. I bought another hard drive and copied all data
from
the old HD to the new one, re-install grub and booted on
it. Worked like a charme but I still have those awful errors. I
did another e2fsck with check blocks : nothing abnormal...

How was the data copied? dd of the underlying device or copied at the
file level...

File level : to see if any read error occurs and avoid FS problem to be copied

It could even be a power issue - lack of sufficient voltage can have
all sorts of weird and counter-intuitive results. And inconsistently
so.
Gonna change the power supply SATA cables.
At the boot, the BIOS take ages to detect HDs now, that's another strange
behavior too...

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/523600333.4550209.1416836437914.javamail.r...@zimbra32-e6.priv.proxad.net

Re: [OT] alternative to dnsdynamic.com?

2014-11-24 Thread Hugo Vanwoerkom


Hugo Vanwoerkom wrote:

Hi,

It seems dsndynamic.com bit the dust this weekend of the 23 of November. 
Is there an alternative of a free dsn server?




I meant dnsdynamic of course...

Hugo



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/m4vcgq$9be$1...@ger.gmane.org

Re: systemd-free alternatives are not off topic.

On 11/24/2014 2:56 AM, Scott Ferguson wrote:
snip
 Yes, and while the Linux community continues, Debian will lose a lot of
 dedicated users due to this decision.  Possibly another fork, or
 possibly another distro.  But Debian will lose users.
 
 1. At best that's pure speculation. With all due respect to Gypsy Rose
 Lee (who is really just a naughty boy), some of us engineer types
 place little stock in soothsaying.
 

It is more than speculation.  Read the posts here - some people
(including me) are already looking for alternatives.  And so are many
companies I know of who have looked at jessie.

 2. It's false logic to conclude *only* losses from change (and
 duplicitous to deny that systemd is your only choice) - it overlooks the
 possibility that the additional *choice* of systemd will attract more
 users (and more instances - you do know that many administrators
 manage large numbers of instances, right?). There is no evidence to show
 that other distros and projects that adopted systemd as the *only*
 choice lost users - quite the reverse.
 

These are the ones who are abandoning Debian.  Some of them came to
Debian because it was one of the last holdouts.  But they see the way
Debian is going also, and don't like it.  They'll probably end up on BSD.


 Sure, people who only run software in .deb packages won't be hit as
 hard. 
 
 At all. And then only if *they* don't elect to stay with sysv.
 
  But that is definitely not the entire Debian user base.
 

I never said it was the entire Debian user base.  But even staying with
sysv is only a temporary situation.  They see the handwriting on the
wall - whether you agree with it or not.

 Those that deploy customisations in the Debian Way should file bug
 reports if those customisations are not supported *if* they change init
 systems.
 Upgrades have *always* supported customisations done the Debian Way -
 and I have every confidence they will continue to do so
 

And exactly what is the Debian way to add custom (NOT customized
pre-packaged) software to the system?

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547331ca.7000...@gmail.com

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread John Hasler

Matt Ventura writes:
 I think the bug here IMO is that a system simply shouldn't *do* things
 in general without me telling it to. If I close the lid of my laptop,
 unless I have told it to suspend when I do so, then it shouldn't
 suspend. I should be telling my machine to do the things I want it to
 do, not telling it to not do the things I don't want it to do.

There was a default configuration.  He changed it.  I think that what
happened here was that his configuration got written over on upgrade
with the new default one that came with the upgraded/replaced packages.
That is not supposed to happen, but it is the sort of bug that creeps in
when you move functions around among packages.

Please file the bug.  The worst they can do is close it.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mw7g4t7z@thumper.dhh.gt.org

Re: [OT] alternative to dnsdynamic.com?

2014-11-24 Thread Paul Scott

On Mon, Nov 24, 2014 at 07:40:42AM -0600, Hugo Vanwoerkom wrote:
 Hugo Vanwoerkom wrote:
 Hi,
 
 It seems dsndynamic.com bit the dust this weekend of the 23 of November.
 Is there an alternative of a free dsn server?
 
 
 I meant dnsdynamic of course...

You give no description but from the name it seems pretty clear that you 
want a dynamic dns service.

I have been using dyndns.org from dyn.com for years.

Paul Scott


 
 Hugo
 
 
 
 -- 
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject
 of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: https://lists.debian.org/m4vcgq$9be$1...@ger.gmane.org
 
 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124134528.GA30122@joy3

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread John Hasler

Jonathan Dowland writes:
 The other issue here is that if you've told your system how you want
 it to behave once, it would be ideal if you didn't have to tell it the
 same thing again.

It isn't just ideal.  It's Debian policy to respect configuration
changes on upgrade.  
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ioi44t2d@thumper.dhh.gt.org

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread The Wanderer

On 11/24/2014 at 02:56 AM, Scott Ferguson wrote:

 On 24/11/14 13:20, Jerry Stuckle wrote:
 
 On 11/23/2014 8:42 PM, Ric Moore wrote:

 Like what?? I first installed systemd back when it was announced.
 I have yet to have a single problem with it.
 
 What about all of those people with custom software running which
 relies on sysv init for starting?
 
 They should continue using sysv, don't you think?
 
 It's illogical to upgrade and not expect change - even when electing
 (as Debian allows) to retain the same init system.

It's illogical to upgrade and not expect *improvement*, but
improvement is much more narrow than change.

An upgrade can bring it runs faster, it doesn't crash in situations
where it would have crashed before, it can now do things which it
could not previously do (AKA new features) - and all of those things
are unambiguously improvements. Many projects - bash, grep, less, X,
nano, just to name a few - consistently provide only improvements on
upgrade; to do anything else would be considered a regression.

However, not all upgrades are limited to providing improvements. Some of
them also provide things which are not unambiguously improvements, but
which either are only arguably improvements, or are simple changes.
systemd seems to fall within that latter category.

Debian itself has not historically managed to achieve provide only
improvements on upgrade AFAIK - even for upgrades between stable
releases, much less upgrades within one - and it's not necessarily
reasonable to expect that it should, given the scope of the project and
the limited manpower available. However, it has come reasonably close in
some ways, and I think that the goal (for all software projects) should
be to be as close to achieving that as possible.

The transition to systemd, in its current form, seems to me to take
Debian farther away from that goal - if only because of the cases in
which systemd behaves differently from sysvinit in ways which are not
unambiguously better.

Maybe that's inevitable, but if so it should at least be recognized and
acknowledged regretfully as such. Sneering at people whose preferred /
expected upgrade model is improvements only as being illogical does
not do that.

 Sure, people who only run software in .deb packages won't be hit
 as hard.
 
 At all.

That depends on what you (or they) count as a hit.

They will certainly be hit with the change in boot-messages behavior,
unless they have previously removed Debian's default quiet from their
kernel command line, or they take extra action (beyond just only run
software in .deb packages) to explicitly retain the existing behavior.

They may very well be hit with the change in expectations about the
contents of /etc/fstab (in terms of when noauto or nofail is required).

Et cetera. You may not count such things as a hit, but other people
might, and it might not be unreasonable for them to do so.

 And then only if *they* don't elect to stay with sysv.
 
 But that is definitely not the entire Debian user base.
 
 Those that deploy customisations in the Debian Way should file bug
 reports if those customisations are not supported *if* they change
 init systems. Upgrades have *always* supported customisations done
 the Debian Way - and I have every confidence they will continue to
 do so

Is this impacted in any way by the discussion recently on (I think)
debian-devel about things under /etc which are now symlinks to
configuration files (some of them I think systemd-related) under /lib or
/usr/lib, which latter will be overwritten on upgrade even if local
modifications have been made?

At a glance, it certainly looks to me as if the Debian Way of
customizing things may now have changed at least somewhat, based on
differences in the way systemd expects / requires things to be done.
Previously, if you edit a config file under /etc, your edits will not be
automatically overwritten on upgrade; at the moment, those edits may be
transparently passed through to a config file in some other location,
and then automatically overwritten there on upgrade.

There have been suggestions made to mitigate that by setting these
symlinked-to config files as a-w, and modifying any editors that don't
already do so to warn (with requirement for override) on an attempt to
write to a read-only file, even if running as a user which could
actually do so (i.e., as root). Though it seems unlikely that that would
catch all possible editors that someone might reasonably use or want to
use for such a purpose, and it could not catch cases where a file is
replaced by mv or cp or the like...

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread Miles Fidelman


Jerry Stuckle wrote:

On 11/24/2014 2:56 AM, Scott Ferguson wrote:
snip

Yes, and while the Linux community continues, Debian will lose a lot of
dedicated users due to this decision.  Possibly another fork, or
possibly another distro.  But Debian will lose users.

1. At best that's pure speculation. With all due respect to Gypsy Rose
Lee (who is really just a naughty boy), some of us engineer types
place little stock in soothsaying.


It is more than speculation.  Read the posts here - some people
(including me) are already looking for alternatives.  And so are many
companies I know of who have looked at jessie.


2. It's false logic to conclude *only* losses from change (and
duplicitous to deny that systemd is your only choice) - it overlooks the
possibility that the additional *choice* of systemd will attract more
users (and more instances - you do know that many administrators
manage large numbers of instances, right?). There is no evidence to show
that other distros and projects that adopted systemd as the *only*
choice lost users - quite the reverse.


These are the ones who are abandoning Debian.  Some of them came to
Debian because it was one of the last holdouts.  But they see the way
Debian is going also, and don't like it.  They'll probably end up on BSD.


Sure, people who only run software in .deb packages won't be hit as
hard.

At all. And then only if *they* don't elect to stay with sysv.

  But that is definitely not the entire Debian user base.


I never said it was the entire Debian user base.  But even staying with
sysv is only a temporary situation.  They see the handwriting on the
wall - whether you agree with it or not.


Those that deploy customisations in the Debian Way should file bug
reports if those customisations are not supported *if* they change init
systems.
Upgrades have *always* supported customisations done the Debian Way -
and I have every confidence they will continue to do so


And exactly what is the Debian way to add custom (NOT customized
pre-packaged) software to the system?




Alien, checkinstall, and equivs come to mind.

Then again, Debian has, to date, been pretty friendly to the basic:
download to /usr/local/src; unzip; untar
./configure; make; make install


--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/547338a6.7010...@meetinghouse.net

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread Martin Read


On 24/11/14 13:25, Jerry Stuckle wrote:

And exactly what is the Debian way to add custom (NOT customized
pre-packaged) software to the system?


As far as I can tell, the obvious things that go into the Debian way 
for installing custom software are:


1) If your software isn't installed via Debian's packaging system, avoid 
conflicts with the packaging system by installing it in places that 
Debian's packaging system is not supposed to manipulate (e.g. /usr/local)


2) If your software needs an init script, make sure that your script 
includes a correct LSB header and supports at least the standard verbs 
with their expected meanings.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54733990.1010...@zen.co.uk

Re: EXT4-fr error, ext4_find_entry: reading directory...

2014-11-24 Thread linuxmasterjedi



- Mail original -
 
  It could even be a power issue - lack of sufficient voltage can
  have
  all sorts of weird and counter-intuitive results. And
  inconsistently
  so.
 Gonna change the power supply  SATA cables.
 At the boot, the BIOS take ages to detect HDs now, that's another
 strange behavior too...

I did some cross-check with HD power and SATA cables : one of the 4 drives slow 
down the BIOS boot process and sometimes, does not appear. Boot without it make 
no EXT4-fr errors displayed. Errors was displayed on sda but the problem comes 
from sdb... This is crazy :-(


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/821216412.4628585.1416838842447.javamail.r...@zimbra32-e6.priv.proxad.net

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread The Wanderer

On 11/24/2014 at 02:59 AM, Jonathan Dowland wrote:

 On Sun, Nov 23, 2014 at 08:58:46PM -0800, Matt Ventura wrote:
 
 I think the bug here IMO is that a system simply shouldn't *do* 
 things in general without me telling it to. If I close the lid of
 my laptop, unless I have told it to suspend when I do so, then it
 shouldn't suspend. I should be telling my machine to do the things
 I want it to do, not telling it to not do the things I don't want
 it to do.
 
 That's not the precedent set in Debian for some time now. The
 approach we take is sensible defaults, and suspend on lid close (at
 least whilst on battery power) is a sensible default.

I seem to recall a discussion some years ago (I think on debian-devel)
where this question came up, and I do not recall the discussion having
settled out with the conclusion you have stated.

My strongest memory of that discussion is someone expressing
incomprehension at the idea of why someone might possibly want a laptop
to suspend when closing the lid, and of writing a post explaining one
possible reason why (involving parallelism with wake up on lid open).

Personally, I suspect that the only reason suspend on lid close is
thought of as a sensible default is because so many other (non-*nix)
systems already do it, not because of anything inherent to the behavior
or to lid-close themselves.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: [OT] alternative to dnsdynamic.com?

2014-11-24 Thread Ron Leach


On 24/11/2014 13:40, Hugo Vanwoerkom wrote:

Hugo Vanwoerkom wrote:

Hi,

It seems dsndynamic.com bit the dust this weekend of the 23 of
November. Is there an alternative of a free dsn server?





Two ideas:

First, If you are looking for (1) a free domain name with (2) the 
capability to automatically update the dns record whenever the IP 
address of a host changes, such as the dyndns free service previously 
did, then  I wonder if it may be possible to


1. use a free domain name from here:

http://www.dot.tk/en/index.html?lang=en

which is managed by Freenom, who also have 3 other TLDs to select from:

http://www.freenom.com/en/freeandpaiddomains.html

and

2. if you are good with scripts, whether it may also be possible to 
use a script to update the dns records in either

(a) the DNS servers managed by Freenom for you domain, or
(b) some DNS servers managed by yourself (though I am not sure you 
could run a DNS server on an IP that itself may be dynamically changing)


When I looked last at .tk (when dyndns stopped being free) I could not 
see how to update the dns records dynamically from my own host, but 
there may be some better guidance around, these days.



Second, If you are happy to pay for a domain, you could consider a 
registrar such as Gratis DNS ( https://web.gratisdns.dk/ ).  With this 
registrar, you can update the dns A record dynamically with a single 
http command.  I do this, using a wget http blah,blah command, for a 
host that we have on a dynamic IP that we use for some 
backup/alternate connectivity.



regards, Ron


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54733f58.2060...@tesco.net

Re: Headless server just got suspended by updating systemd

On Mon, Nov 24, 2014 at 06:01:45PM +0900, Joel Rees wrote:
 2014/11/24 17:18 Jonathan Dowland j...@debian.org:
  I guess your argument makes sense if you are talking about all source
 packages
  from the systemd stable, including logind; it's unlikely Patrick's init
 system
  was switched to systemd-as-init as a result of upgrading. Either way
 though,
  he's moved from a 'testing' system at some indeterminate point in the
 past to
  a 'testing' system now; neither are 'releases' and so the release
 schedule has
  little relevance to his situation.

I don't have anything to add to the above, but I just wanted to point out
that your mailer seems to be mangling the quoting here.

 So, are you saying he shouldn't report a bug?

I'm not saying that, no. He should report a bug, if he can remember enough of
the details to make it a worthwhile report. Right now we have no idea what
piece of software was performing the suspending prior to upgrade.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124142343.ga29...@chew.redmars.org

Re: Headless server just got suspended by updating systemd

On Mon, Nov 24, 2014 at 07:38:34AM -0600, John Hasler wrote:
 It isn't just ideal.  It's Debian policy to respect configuration
 changes on upgrade.  

That isn't the case, I'm afraid. At least if you are referring to [1], this
section refers specifically to *configuration files*, in the context of a
single package, rather than a wider notion of system-wide configuration. I
personally think a higher-level system-wide preservation would be a worthy
goal, but it isn't mandated by policy.

The problem in this case is most likely a mixture of some packages not
performing the same duties after upgrade, combined with possible changes of
dependencies resulting in different pieces of software taking on the job of
managing suspend/lid events. It's not a policy violation for a later-version of
a piece of software to perform fewer duties than an earlier one; it's also not
a policy violation for a package to not honour the configuration of an
unrelated one.


[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files


-- 
Jonathan Dowland


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124142854.gb29...@chew.redmars.org

Re: Headless server just got suspended by updating systemd

On Mon, Nov 24, 2014 at 09:03:31AM -0500, The Wanderer wrote:
 Personally, I suspect that the only reason suspend on lid close is
 thought of as a sensible default is because so many other (non-*nix)
 systems already do it, not because of anything inherent to the behavior
 or to lid-close themselves.

Why do you think the do it? Could they not have (also) come to the conclusion
that this is sensible default behaviour?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124142956.gc29...@chew.redmars.org

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread Patrick Wiseman

On Mon, Nov 24, 2014 at 9:23 AM, Jonathan Dowland j...@debian.org wrote:
On Mon, Nov 24, 2014 at 06:01:45PM +0900, Joel Rees wrote:
2014/11/24 17:18 Jonathan Dowland j...@debian.org:
I guess your argument makes sense if you are talking about all source
packages
from the systemd stable, including logind; it's unlikely Patrick's init
system
was switched to systemd-as-init as a result of upgrading. Either way
though,
he's moved from a 'testing' system at some indeterminate point in the
past to
a 'testing' system now; neither are 'releases' and so the release
schedule has
little relevance to his situation.

I don't have anything to add to the above, but I just wanted to point out
that your mailer seems to be mangling the quoting here.

So, are you saying he shouldn't report a bug?

I'm not saying that, no. He should report a bug, if he can remember enough of
the details to make it a worthwhile report. Right now we have no idea what
piece of software was performing the suspending prior to upgrade.

I don't think I can responsibly report a bug as I have no idea which
package I might report it against. This was a rather large upgrade of
a testing system which had not been upgraded in quite awhile. Any
number of things might have changed.

I do think, though, that defaults, however sensible they may be (and
suspending a laptop when the lid is closed and it is on AC power does
not strike me as particularly sensible), should not be allowed to
override settings I've made. Had I not had physical access to this
server, I would have been screwed!

Patrick

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/cajvvksohyoymuwrdpa1glc7daqdefkcphj_fdv3sxj3wus-...@mail.gmail.com

Re: [OT] alternative to dnsdynamic.com?

2014-11-24 Thread Ron Leach


On 24/11/2014 14:23, Ron Leach wrote:



First, If you are looking for (1) a free domain name with (2) the
capability to automatically update the dns record whenever the IP
address of a host changes, such as the dyndns free service previously
did, then I wonder if it may be possible to

1. use a free domain name from here:

http://www.dot.tk/en/index.html?lang=en

which is managed by Freenom, who also have 3 other TLDs to select from:

http://www.freenom.com/en/freeandpaiddomains.html

and

2. if you are good with scripts, whether it may also be possible to
use a script to update the dns records in either
(a) the DNS servers managed by Freenom for you domain, or
(b) some DNS servers managed by yourself (though I am not sure you
could run a DNS server on an IP that itself may be dynamically changing)

When I looked last at .tk (when dyndns stopped being free) I could not
see how to update the dns records dynamically from my own host, but
there may be some better guidance around, these days.



While checking around to see if much had changed since I last looked, 
I see that Wikipedia reports some unease around the usefulness of .tk, 
so the service may not be suitable for your requirements.


https://en.wikipedia.org/wiki/.tk

I've never used them, so I don't have any actual experience to offer.

regards, Ron



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/547349bb.1030...@tesco.net

Re: [OT] alternative to dnsdynamic.com?

2014-11-24 Thread Hugo Vanwoerkom


Paul Scott wrote:

On Mon, Nov 24, 2014 at 07:40:42AM -0600, Hugo Vanwoerkom wrote:

Hugo Vanwoerkom wrote:

Hi,

It seems dsndynamic.com bit the dust this weekend of the 23 of November.
Is there an alternative of a free dsn server?


I meant dnsdynamic of course...


You give no description but from the name it seems pretty clear that you 
want a dynamic dns service.


I have been using dyndns.org from dyn.com for years.



But they are no longer free are they?

Hugo



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/m4vhq8$aqi$1...@ger.gmane.org

Re: ntpd confusion

2014-11-24 Thread Chen Wei

On Mon, Nov 24, 2014 at 10:58:29AM +0100, mad wrote:
 mentioned, other Debian installations not on my home network, with the
 same configuration show as expected four clock sources. Even starting
 ntpd on the command line doesn't show any more data and ntpd is compiled
 without debugging. Probably that is what I will do, recompile ntpd with
 debug enabled and then see what ntpd is actually doing.
 

Besides recompile with debug level option, I would also suggest try the
NTP mailing list.

 Could it have something to do with upnp, zeroconf or something like that?
 

No idea.


-- 
Chen Wei


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124151104.GA16480@localhost

Re: systemd-free alternatives are not off topic.

On 11/24/2014 8:54 AM, Miles Fidelman wrote:
 Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote:
 snip
 Yes, and while the Linux community continues, Debian will lose a lot of
 dedicated users due to this decision.  Possibly another fork, or
 possibly another distro.  But Debian will lose users.
 1. At best that's pure speculation. With all due respect to Gypsy Rose
 Lee (who is really just a naughty boy), some of us engineer types
 place little stock in soothsaying.

 It is more than speculation.  Read the posts here - some people
 (including me) are already looking for alternatives.  And so are many
 companies I know of who have looked at jessie.

 2. It's false logic to conclude *only* losses from change (and
 duplicitous to deny that systemd is your only choice) - it overlooks the
 possibility that the additional *choice* of systemd will attract more
 users (and more instances - you do know that many administrators
 manage large numbers of instances, right?). There is no evidence to show
 that other distros and projects that adopted systemd as the *only*
 choice lost users - quite the reverse.

 These are the ones who are abandoning Debian.  Some of them came to
 Debian because it was one of the last holdouts.  But they see the way
 Debian is going also, and don't like it.  They'll probably end up on BSD.

 Sure, people who only run software in .deb packages won't be hit as
 hard.
 At all. And then only if *they* don't elect to stay with sysv.

   But that is definitely not the entire Debian user base.

 I never said it was the entire Debian user base.  But even staying with
 sysv is only a temporary situation.  They see the handwriting on the
 wall - whether you agree with it or not.

 Those that deploy customisations in the Debian Way should file bug
 reports if those customisations are not supported *if* they change init
 systems.
 Upgrades have *always* supported customisations done the Debian Way -
 and I have every confidence they will continue to do so

 And exactly what is the Debian way to add custom (NOT customized
 pre-packaged) software to the system?


 
 Alien, checkinstall, and equivs come to mind.
 
 Then again, Debian has, to date, been pretty friendly to the basic:
 download to /usr/local/src; unzip; untar
 ./configure; make; make install
 
 

Do you expect customers to build .deb files for every piece of software
they create?

It doesn't happen - and is not going to happen.  It's much faster to
just copy the files to the appropriate directories.  And since they have
complete control over the code, they know when changes are made and what
has to be done when the code is updated.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473474f.4080...@gmail.com

Re: systemd-free alternatives are not off topic.

On 11/24/2014 8:58 AM, Martin Read wrote:
 On 24/11/14 13:25, Jerry Stuckle wrote:
 And exactly what is the Debian way to add custom (NOT customized
 pre-packaged) software to the system?
 
 As far as I can tell, the obvious things that go into the Debian way
 for installing custom software are:
 
 1) If your software isn't installed via Debian's packaging system, avoid
 conflicts with the packaging system by installing it in places that
 Debian's packaging system is not supposed to manipulate (e.g. /usr/local)


Sometimes.  Often, though, they go in places like /bin or /sbin - as was
done in Unix 25 years ago.

 2) If your software needs an init script, make sure that your script
 includes a correct LSB header and supports at least the standard verbs
 with their expected meanings.
 
 

Some do, some don't.  Many times they are just simple scripts to start a
daemon because they don't depend on another system daemon starting.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473485d.4080...@gmail.com

Re: [OT] alternative to dsndynamic.com?

On 25/11/14 00:33, Hugo Vanwoerkom wrote:
 Hi,
 
 It seems dsndynamic.com bit the dust this weekend of the 23 of November.
 Is there an alternative of a free dsn server?
 
 Hugo
 
 

noip.com is one of many - it's possible to use it with the debian
package ddclient

Do I use it?  Yes.

Is it better than other alternatives? I have no idea - a search engine
will provide you with a list of free dns servers, only you can
determine what's fit-for-purpose.

Please note - with the greatest respect, as you haven't provided a
Debian User context I've set the reply to Debian Community Offlist[]*1,
please re-direct to this list if I've overlooked and un-stated context.

Small hint: ask the question in a Debian User context and get an onlist
reply. ddclient is a Debian package for use with dyndns.


Kind regards

[*1] My Return To: will send you to the list described here:-
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54734caf.7060...@gmail.com

Re: systemd-free alternatives are not off topic.

On 25/11/14 00:25, Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
 Yes, and while the Linux community continues, Debian will lose a 
 lot of dedicated users due to this decision.  Possibly another 
 fork, or possibly another distro.  But Debian will lose users.
 
 1. At best that's pure speculation. With all due respect to Gypsy 
 Rose Lee (who is really just a naughty boy), some of us engineer 
 types place little stock in soothsaying.
 
 
 It is more than speculation.  Read the posts here - some people 
 (including me) are already looking for alternatives.  And so are many
 companies I know of who have looked at jessie.

1. Like most things, that's relative. In this instance to the number of
readers and users:-
https://lwn.net/Articles/620441/
and, see my comments further down about churn (if I was overly tired
and emotional I might write they're your ball, you know where your home
is?, empty promises, and, what's second prize?. But I'm not 'that'
tired and emotional).

2. Fore-telling the future, especially when the basis for future
extrapolation is *not* based on *any* (supplied and confirm-able) facts
- is assumption (not presumption - which generally, pre-supposes 'some'
evidence, of which you provide none (which doesn't preclude the
possibility you will at a later stage).
Presumption is distinct from assumptions. (not to imply you are
cognitively impaired, just in awareness that this is not a 1:1
communication)

3. companies that you 'know 'have looked at Jessie (which is not yet
a Stable release) is like secret attorneys - not demonstrable facts
and of dubious relevance. An unintentional oversight on your part I
'suspect'.
I may be alone in the desire to not start jumping at shadows (or hanging
monkeys in sailor suits) - that 'may' (based on historical precedence)
only lead to burning witches and people that don't look like the tribal
patriarch.

 
 2. It's false logic to conclude *only* losses from change (and 
 duplicitous to deny that systemd is your only choice) - it 
 overlooks the possibility that the additional *choice* of systemd 
 will attract more users (and more instances - you do know that
 many administrators manage large numbers of instances, right?).
 There is no evidence to show that other distros and projects that
 adopted systemd as the *only* choice lost users - quite the
 reverse.
 
 
 These are the ones who are abandoning Debian.

Citation?  These is a, um, little vague.

 Some of them came to Debian because it was one of the last holdouts.

Is that a reference to a term used in a television show about the
fictitious Wild West? I can only apologise of my ignorance of popular
culture (long story - I haven't watched television in several decades
- did I miss something important?).

Never-the-less I suspect what you refer[*1] to is what is called
churn. Tyre-kickers, testers, those that don't want to/don't have the
time/capacity to learn sufficient skills, those that lack the
motivation/capacity to decide for them selves and go with the flow (of
the noisiest) - as some might say - like dead fish. None of which would
be clients of your business - though admittedly I'm guessing at your
business model and mean no undue disrespect to you as a Veteran Unix
Administrator. (it's late, I'm tired, please forgive any clumsy wording
and a total lack of editorial review, be assured I've endeavoured to
extend the same courtesy).

 But they see the way Debian is going also, and don't like it.

Objection - remains supposition *until* you supply evidence. I don't
doubt you don't like it (shades of Fffacefriend and primary
school??)But... there are many things I don't like, *I*'ll spare you,
and other readers further expansion on them.

 They'll probably end up on BSD.

Not necessarily a bad thing. BSD (a generic for a diversity of
distributions, can use love - providing that those disenfranchised
refugees that you refer to:-
;exist
;provide love

 
 
 Sure, people who only run software in .deb packages won't be hit 
 as hard.
 
 At all. And then only if *they* don't elect to stay with sysv.
 
 But that is definitely not the entire Debian user base.
 
 
 I never said it was the entire Debian user base.

Nor did I say you did. Please don't put words in my mouth.

 But even staying with sysv is only a temporary situation.

In your prediction of *future* events. Which is dependant on Debian
ceasing to do what Debian has done for more than two decades - overcome
difficulties and adapt to change (an instructive guide to coping, and
profiting from change, don't you think?)

 They see the handwriting on the wall

Daniel[*2] or Omar Khayyám? [confused, but still keen to learn]

 - whether you agree with it or not.

For the record - 'I' don't. On the basis of I've seen no evidence, in
spite of extensive research and carefully open-minded view, of any
factual support for the proof of soothsaying or prophecy (I was
disappointed to discover that Uri Geller was a fraud, but I

Re: Headless server just got suspended by updating systemd

2014-11-24 Thread Christian Seiler


Am 2014-11-24 15:47, schrieb Patrick Wiseman:
On Mon, Nov 24, 2014 at 9:23 AM, Jonathan Dowland j...@debian.org 
wrote:

On Mon, Nov 24, 2014 at 06:01:45PM +0900, Joel Rees wrote:

2014/11/24 17:18 Jonathan Dowland j...@debian.org:
 I guess your argument makes sense if you are talking about all 
source

packages
 from the systemd stable, including logind; it's unlikely 
Patrick's init

system
 was switched to systemd-as-init as a result of upgrading. Either 
way

though,
 he's moved from a 'testing' system at some indeterminate point in 
the

past to
 a 'testing' system now; neither are 'releases' and so the release
schedule has
 little relevance to his situation.


I don't have anything to add to the above, but I just wanted to 
point out

that your mailer seems to be mangling the quoting here.


So, are you saying he shouldn't report a bug?


I'm not saying that, no. He should report a bug, if he can remember 
enough of
the details to make it a worthwhile report. Right now we have no 
idea what

piece of software was performing the suspending prior to upgrade.


I don't think I can responsibly report a bug as I have no idea which
package I might report it against. This was a rather large upgrade of
a testing system which had not been upgraded in quite awhile. Any
number of things might have changed.


The main difference is that logind (part of the systemd package) now
takes precedent over the previous suspend logic (pm-utils IIRC). This 
is

because pm-utils stops processing certain events if it detects that
logind is running.

In my eyes, the proper fix for this would be:

 - have the postinst script for systemd detect whether on dist upgrade
   pm-utils was installed and its configuration was modified by the 
user


 - if not, proceed with the current state (keep using defaults)

 - if the user changed configuration, it should just tell logind not to
   handle events at all

 - and it should tell pm-utils that it should continue processing all
   events
 - (not sure if that's possible just with configuration)

 - and it probably should show a debconf message that while the current
   configuration has been kept, the new way of doing things[tm] is
   different and offer people some guidance in this regard

Alternatively, systemd's postinst script could also try to parse
pm-util's configuration and adapt it, but I suspect that that's going 
to
be rather tricky, so I doubt that that's going to be a viable way 
forward.


So if you want to report this, this should be

 - a bug in Debian's systemd package for the postinst script

 - potentially another bug in Debian's pm-utils package (that blocks 
the
   systemd bug) that provides a means for the systemd postinst script 
to
   reenable pm-utils (if that is not already available anyway, I 
haven't

   checked)


(and
suspending a laptop when the lid is closed and it is on AC power does
not strike me as particularly sensible)


IIRC logind will NOT suspend if the system is on AC power AND an
external monitor is connected. Basically: as long as the laptop can 
show
something on a screen that's visible to the user, the system will not 
be

suspended.

Obviously, for your use case, this default doesn't work. But that's why
software can be configured. Your problem doesn't stem from this default
(which I think is rather sensible), but rather from the fact that your
locally modified configuration was not honored on update.

Christian


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/6edf23df0b656559c8da3dd255a8d...@iwakd.de

Re: systemd-free alternatives are not off topic.

On 25/11/14 00:53, The Wanderer wrote:
 On 11/24/2014 at 02:56 AM, Scott Ferguson wrote:
 
 On 24/11/14 13:20, Jerry Stuckle wrote:
 
 On 11/23/2014 8:42 PM, Ric Moore wrote:
 
 Like what?? I first installed systemd back when it was
 announced. I have yet to have a single problem with it.
 
 What about all of those people with custom software running
 which relies on sysv init for starting?
 
 They should continue using sysv, don't you think?
 
 It's illogical to upgrade and not expect change - even when
 electing (as Debian allows) to retain the same init system.
 
 It's illogical to upgrade and not expect *improvement*,

Good luck with that (expecting experience to triumph over optimism
might be difficult to reconcile with so many posts from those opposed
to a new default init).
I'd recommend weighting the outcomes before embarking on an adventure
with expectations. e.g. I admin systems that still run old-stable
because the advantages of moving to Wheezy do not provide a
compelling argument to do so. YMMV. Everyone has an opinion, no one
owns facts.

snipped
 
 That depends on what you (or they) count as a hit.

And whether the batter is swinging a fickle stick?

 
 They will certainly

hopefully, be doing a little research before banging the enter key...
Please note that dist-upgrade requires more action on the part of the
user than just that.

snipped

 Those that deploy customisations in the Debian Way should file
 bug reports if those customisations are not supported *if* they
 change init systems. Upgrades have *always* supported
 customisations done the Debian Way - and I have every
 confidence they will continue to do so
 
 Is this impacted in any way by the discussion recently on (I
 think) debian-devel about things under /etc which are now symlinks
 to configuration files (some of them I think systemd-related) under
 /lib or /usr/lib, which latter will be overwritten on upgrade even
 if local modifications have been made?

It's late, I'm tired, I cannot parse that. Perhaps if you replace I
thing with I know e.g. a reference, preferably to something
relevant to when Jessie becomes stable, I'll endeavour to answer that
question - until then it's (unintentionally?) a little too Glenn
Beck/Duane Gish.

 
 At a glance, it certainly looks to me as if the Debian Way of 
 customizing things may now have changed at least somewhat

What were you glancing at? (it would be helpful so I can respond to
your question - assuming you are asking a non-rhetorical question).

snipped

Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547350af.9090...@gmail.com

NFS homedirs and icon position

2014-11-24 Thread Paul van der Vlis

Hello,

I have a strange problem with homedirs on NFS (Wheezy), using Gnome3
Classic. With advanced settings I configured the desktop so that users
can place icons on it.

The problem is that after ordening the icons and rebooting the machine,
the position of the icons is the old position again...

This is only with users who store the homedir using NFS. Each machine
has a normal user too for maintenance, there is no problem.

I use LDAP, and Kerberos for authentication.

Who knows how the icon position is stored, or what to do against this
problem?

With regards,
Paul van der Vlis.



-- 
Paul van der Vlis Linux systeembeheer, Groningen
http://www.vandervlis.nl


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473542e.4000...@vandervlis.nl

Re: Headless server just got suspended by updating systemd

On 25/11/14 01:03, The Wanderer wrote:
 On 11/24/2014 at 02:59 AM, Jonathan Dowland wrote:
 
 On Sun, Nov 23, 2014 at 08:58:46PM -0800, Matt Ventura wrote:
 
 I think the bug here IMO is that a system simply shouldn't *do*
  things in general without me telling it to. If I close the lid
 of my laptop, unless I have told it to suspend when I do so,
 then it shouldn't suspend. I should be telling my machine to do
 the things I want it to do, not telling it to not do the things
 I don't want it to do.
 
 That's not the precedent set in Debian for some time now. The 
 approach we take is sensible defaults, and suspend on lid close
 (at least whilst on battery power) is a sensible default.
 
 I seem to recall a discussion some years ago (I think on
 debian-devel) where this question came up, and I do not recall the
 discussion having settled out with the conclusion you have stated.

Please be less vague - if you don't recall do the research instead
of expecting others to do it for you. No offense intended - we all
have don't recall days.

 
 My strongest memory of that discussion is someone expressing 
 incomprehension at the idea of why someone might possibly want a
 laptop to suspend when closing the lid, and of writing a post
 explaining one possible reason why (involving parallelism with
 wake up on lid open).
 
 Personally, I suspect that the only reason suspend on lid close
 is thought of as a sensible default is because so many other
 (non-*nix) systems already do it,

Or, perhaps a general rule for default settings - safest/do no harm?
[just a wild guess]
(i.e. laptops run on batteries  - that default doesn't apply if
laptop-detect is not installed)

 not because of anything inherent to the behavior or to lid-close
 themselves.
 

Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54735253.3040...@gmail.com

Re: systemd-free alternatives are not off topic.

On 25/11/14 01:57, Jerry Stuckle wrote:
 On 11/24/2014 8:54 AM, Miles Fidelman wrote:
 Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
 Yes, and while the Linux community continues, Debian will
 lose a lot of dedicated users due to this decision.  Possibly
 another fork, or possibly another distro.  But Debian will
 lose users.
 1. At best that's pure speculation. With all due respect to
 Gypsy Rose Lee (who is really just a naughty boy), some of us
 engineer types place little stock in soothsaying.
 
 It is more than speculation.  Read the posts here - some people 
 (including me) are already looking for alternatives.  And so are
 many companies I know of who have looked at jessie.
 
 2. It's false logic to conclude *only* losses from change (and 
 duplicitous to deny that systemd is your only choice) - it
 overlooks the possibility that the additional *choice* of
 systemd will attract more users (and more instances - you do
 know that many administrators manage large numbers of
 instances, right?). There is no evidence to show that other
 distros and projects that adopted systemd as the *only* choice
 lost users - quite the reverse.
 
 These are the ones who are abandoning Debian.  Some of them came
 to Debian because it was one of the last holdouts.  But they see
 the way Debian is going also, and don't like it.  They'll
 probably end up on BSD.
 
 Sure, people who only run software in .deb packages won't be
 hit as hard.
 At all. And then only if *they* don't elect to stay with sysv.
 
 But that is definitely not the entire Debian user base.
 
 I never said it was the entire Debian user base.  But even
 staying with sysv is only a temporary situation.  They see the
 handwriting on the wall - whether you agree with it or not.
 
 Those that deploy customisations in the Debian Way should
 file bug reports if those customisations are not supported *if*
 they change init systems. Upgrades have *always* supported
 customisations done the Debian Way - and I have every
 confidence they will continue to do so
 
 And exactly what is the Debian way to add custom (NOT
 customized pre-packaged) software to the system?
 
 
 
 Alien, checkinstall, and equivs come to mind.

Agreed (also fs guidelines)

 
 Then again, Debian has, to date, been pretty friendly to the
 basic: download to /usr/local/src; unzip; untar ./configure; make;
 make install

and checkinstall
 
 
 
 Do you expect customers to build .deb files for every piece of
 software they create?

No, I expect the admin to 'try' and do that (e.g. checkinstall) or
install the upstream package to the appropriate place where it *will*
withstand upgrade. But not everyone follows BP (e.g. ITIL, PCI, and
whatever relevant guidelines apply to their use-case). I don't know what
your use-case is...

 
 It doesn't happen - and is not going to happen.  It's much faster

Convenience is the antipathy of security? (security also mean reliability).

 to just copy the files to the appropriate directories.  And since
 they have complete control over the code, 

Complete control over the code? Are you sure you mean what you wrote? If
so don't conflate complete control over the code with no control over
whether the code will continue to function - as it would contradict
your previous complaints.

snipped

Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473543f.8080...@gmail.com

Re: systemd-free alternatives are not off topic.

On 25/11/14 02:01, Jerry Stuckle wrote:
 On 11/24/2014 8:58 AM, Martin Read wrote:
 On 24/11/14 13:25, Jerry Stuckle wrote:
 And exactly what is the Debian way to add custom (NOT customized
 pre-packaged) software to the system?

 As far as I can tell, the obvious things that go into the Debian way
 for installing custom software are:

 1) If your software isn't installed via Debian's packaging system, avoid
 conflicts with the packaging system by installing it in places that
 Debian's packaging system is not supposed to manipulate (e.g. /usr/local)

 
 Sometimes.  Often, though, they go in places like /bin or /sbin - as was
 done in Unix 25 years ago.

(newsflash?)
UNIX != Linux

and,dist-upgrades won't over-ride binaries or scripts *unless* the sys
admin has failed (BP and admin 101) by installing packages with names
that conflict with regular distro supplied binaries/scripts.
Dependencies for custom installs *should* be catered for by the
installing admin - apt is good, but it's not magical (neither is any
package manager). i.e. expect the impossible and prepare for failure
(and don't expect professional credits).

 
 2) If your software needs an init script, make sure that your script
 includes a correct LSB header and supports at least the standard verbs
 with their expected meanings.


 
 Some do, some don't.  Many times they are just simple scripts to start a
 daemon because they don't depend on another system daemon starting.

Agreed - but not useful in 'this' context. Does not parse. Please expand
- specifics would be useful (pretend you're writing a use-case for
change control). Your time is not less or more valuable than any one
else's (an hour is worth exactly one hour).

 
 Jerry
 
 

Kind regards


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5473566a.2090...@gmail.com

Re: systemd-free alternatives are not off topic.

On 11/24/2014 10:05 AM, Scott Ferguson wrote:
 On 25/11/14 00:25, Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
 Yes, and while the Linux community continues, Debian will lose a 
 lot of dedicated users due to this decision.  Possibly another 
 fork, or possibly another distro.  But Debian will lose users.

 1. At best that's pure speculation. With all due respect to Gypsy 
 Rose Lee (who is really just a naughty boy), some of us engineer 
 types place little stock in soothsaying.


 It is more than speculation.  Read the posts here - some people 
 (including me) are already looking for alternatives.  And so are many
 companies I know of who have looked at jessie.
 
 1. Like most things, that's relative. In this instance to the number of
 readers and users:-
 https://lwn.net/Articles/620441/
 and, see my comments further down about churn (if I was overly tired
 and emotional I might write they're your ball, you know where your home
 is?, empty promises, and, what's second prize?. But I'm not 'that'
 tired and emotional).
 
 2. Fore-telling the future, especially when the basis for future
 extrapolation is *not* based on *any* (supplied and confirm-able) facts
 - is assumption (not presumption - which generally, pre-supposes 'some'
 evidence, of which you provide none (which doesn't preclude the
 possibility you will at a later stage).
 Presumption is distinct from assumptions. (not to imply you are
 cognitively impaired, just in awareness that this is not a 1:1
 communication)


It is not an assumption nor a presumption or prediction.  Several people
here (including me) have already indicated they are abandoning Debian
for another distro or BSD.  So have most of my customers who are
currently using Debian.  It is a fact.

 3. companies that you 'know 'have looked at Jessie (which is not yet
 a Stable release) is like secret attorneys - not demonstrable facts
 and of dubious relevance. An unintentional oversight on your part I
 'suspect'.
 I may be alone in the desire to not start jumping at shadows (or hanging
 monkeys in sailor suits) - that 'may' (based on historical precedence)
 only lead to burning witches and people that don't look like the tribal
 patriarch.
 

By contract, I am not allowed to specify which of my customers are
running what.  If you've ever been a consultant, you should be aware of
non-disclosure agreements; they are a standard part of almost every
consulting contract I've ever signed.

But that does not mean they are not jumping ship.


 2. It's false logic to conclude *only* losses from change (and 
 duplicitous to deny that systemd is your only choice) - it 
 overlooks the possibility that the additional *choice* of systemd 
 will attract more users (and more instances - you do know that
 many administrators manage large numbers of instances, right?).
 There is no evidence to show that other distros and projects that
 adopted systemd as the *only* choice lost users - quite the
 reverse.


 These are the ones who are abandoning Debian.
 
 Citation?  These is a, um, little vague.
 

As I said - contracts forbid me from giving specifics.  But I'm sure
you'll use that to say they don't exist.  They do, however.

 Some of them came to Debian because it was one of the last holdouts.
 
 Is that a reference to a term used in a television show about the
 fictitious Wild West? I can only apologise of my ignorance of popular
 culture (long story - I haven't watched television in several decades
 - did I miss something important?).
 

No, it has nothing to do with TV.

 Never-the-less I suspect what you refer[*1] to is what is called
 churn. Tyre-kickers, testers, those that don't want to/don't have the
 time/capacity to learn sufficient skills, those that lack the
 motivation/capacity to decide for them selves and go with the flow (of
 the noisiest) - as some might say - like dead fish. None of which would
 be clients of your business - though admittedly I'm guessing at your
 business model and mean no undue disrespect to you as a Veteran Unix
 Administrator. (it's late, I'm tired, please forgive any clumsy wording
 and a total lack of editorial review, be assured I've endeavoured to
 extend the same courtesy).
 

It is not churn.  Companies don't change distros on a whim; it is very
expensive to install and test new software.  If they have to train
people on that new software, the cost increases.  Therefore, every
software installation is carefully examined before even attempting to
install it.

For instance - in the case of upgrading a Debian package, it means
looking at the documentation with that package and, in the case of
release changes to the base product, the documentation to those changes.
 It them means installing on a test system and running a long series of
tests.  And when the system is being upgraded, every package being
upgraded has to be examined.  Then the new code is installed on test
servers and checked for interoperability with existing code.

A

Re: systemd-free alternatives are not off topic.

On 11/24/2014 10:52 AM, Scott Ferguson wrote:
 On 25/11/14 01:57, Jerry Stuckle wrote:
 On 11/24/2014 8:54 AM, Miles Fidelman wrote:
 Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
 Yes, and while the Linux community continues, Debian will
 lose a lot of dedicated users due to this decision.  Possibly
 another fork, or possibly another distro.  But Debian will
 lose users.
 1. At best that's pure speculation. With all due respect to
 Gypsy Rose Lee (who is really just a naughty boy), some of us
 engineer types place little stock in soothsaying.

 It is more than speculation.  Read the posts here - some people 
 (including me) are already looking for alternatives.  And so are
 many companies I know of who have looked at jessie.

 2. It's false logic to conclude *only* losses from change (and 
 duplicitous to deny that systemd is your only choice) - it
 overlooks the possibility that the additional *choice* of
 systemd will attract more users (and more instances - you do
 know that many administrators manage large numbers of
 instances, right?). There is no evidence to show that other
 distros and projects that adopted systemd as the *only* choice
 lost users - quite the reverse.

 These are the ones who are abandoning Debian.  Some of them came
 to Debian because it was one of the last holdouts.  But they see
 the way Debian is going also, and don't like it.  They'll
 probably end up on BSD.

 Sure, people who only run software in .deb packages won't be
 hit as hard.
 At all. And then only if *they* don't elect to stay with sysv.

 But that is definitely not the entire Debian user base.

 I never said it was the entire Debian user base.  But even
 staying with sysv is only a temporary situation.  They see the
 handwriting on the wall - whether you agree with it or not.

 Those that deploy customisations in the Debian Way should
 file bug reports if those customisations are not supported *if*
 they change init systems. Upgrades have *always* supported
 customisations done the Debian Way - and I have every
 confidence they will continue to do so

 And exactly what is the Debian way to add custom (NOT
 customized pre-packaged) software to the system?



 Alien, checkinstall, and equivs come to mind.
 
 Agreed (also fs guidelines)
 

 Then again, Debian has, to date, been pretty friendly to the
 basic: download to /usr/local/src; unzip; untar ./configure; make;
 make install
 
 and checkinstall



 Do you expect customers to build .deb files for every piece of
 software they create?
 
 No, I expect the admin to 'try' and do that (e.g. checkinstall) or
 install the upstream package to the appropriate place where it *will*
 withstand upgrade. But not everyone follows BP (e.g. ITIL, PCI, and
 whatever relevant guidelines apply to their use-case). I don't know what
 your use-case is...


These are system admins who have either started with Unix in the 1980's,
or people who learned from those sysadmins.  Back then you did put stuff
in /bin and/or /sbin, for instance.  And the company is not changing.


 It doesn't happen - and is not going to happen.  It's much faster
 
 Convenience is the antipathy of security? (security also mean reliability).


It is reliable.  And has been for many years.  That's what testing is
all about.

And even if they did create .deb files for everything, that would not
negate the need for testing.

 to just copy the files to the appropriate directories.  And since
 they have complete control over the code, 
 
 Complete control over the code? Are you sure you mean what you wrote? If
 so don't conflate complete control over the code with no control over
 whether the code will continue to function - as it would contradict
 your previous complaints.


Yes, complete control.  This is code they have written themselves and/or
contracted out.  They have complete control over the code.  When there
is an upgrade to their code, they know about it and install it.

And when there is an upgrade to the underlying OS and/or tools, there is
also extensive testing to see that the code will continue to work. If it
doesn't, either the code changes or the upgrade is cancelled and a new
solution is looked for.

Most of the time it's only a matter of recompiling the code (new libs,
etc.).  But there is much more concern with them now.

Jerry


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54735c1a.40...@gmail.com

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread The Wanderer

On 11/24/2014 at 10:37 AM, Scott Ferguson wrote:

 On 25/11/14 00:53, The Wanderer wrote:
 
 On 11/24/2014 at 02:56 AM, Scott Ferguson wrote:

 It's illogical to upgrade and not expect change - even when
 electing (as Debian allows) to retain the same init system.
 
 It's illogical to upgrade and not expect *improvement*,
 
 Good luck with that (expecting experience to triumph over optimism
 might be difficult to reconcile with so many posts from those
 opposed to a new default init).

I'm not sure I understand what you're getting at here.

My point was simply to disagree with your assertion about what it is and
is not logical to expect from an upgrade. Among possibly other things,
that's partly a philosophical point, and partly one about the
definitions of words.

 I'd recommend weighting the outcomes before embarking on an
 adventure with expectations. e.g. I admin systems that still run
 old-stable because the advantages of moving to Wheezy do not
 provide a compelling argument to do so. YMMV. Everyone has an
 opinion, no one owns facts.

And I'm sure I don't understand what you're getting at here. I'm at
least as confused by this as you seem to have been by parts of my own
post.

 That depends on what you (or they) count as a hit.

 They will certainly
 
 hopefully, be doing a little research before banging the enter
 key... Please note that dist-upgrade requires more action on the part
 of the user than just that.

...by what definition of requires?

It is certainly possible to dist-upgrade by simply running 'apt-get
dist-upgrade' and hitting Enter repeatedly. Thus, dist-upgrade does not
- in the literal sense - require any more action than that.

 Those that deploy customisations in the Debian Way should file
 bug reports if those customisations are not supported *if* they
 change init systems. Upgrades have *always* supported
 customisations done the Debian Way - and I have every
 confidence they will continue to do so
 
 Is this impacted in any way by the discussion recently on (I think)
 debian-devel about things under /etc which are now symlinks to
 configuration files (some of them I think systemd-related) under
 /lib or /usr/lib, which latter will be overwritten on upgrade even
 if local modifications have been made?
 
 It's late, I'm tired, I cannot parse that. Perhaps if you replace I
 thing with I know e.g. a reference, preferably to something
 relevant to when Jessie becomes stable, I'll endeavour to answer
 that question

I apologize. I presumed that anyone who is as invested in the
systemd-related discussions as you plainly are would be following the
various mailing lists where this might have been mentioned, and thus
would have already read this discussion just as recently as I have.

The discussion occurred on debian-devel, in the thread entitled init
system policy. The suggestion for a possible way to mitigate the
problem was made by Philip Hands, on November 22nd, in response to a
post by me on the same date.

I do not have links to specific messages, since I don't habitually work
with or enjoy browsing through Web archives of mailing lists, and since
I've never understood (or even understood how to make practical use of)
the message links - looking outwardly similar to complicated E-mail
addresses - which people sometimes use to identify a particular E-mail
message. I presume that you will be able to find the thread in your own
local archive of recent messages from debian-devel.

 - until then it's (unintentionally?) a little too Glenn Beck/Duane
 Gish.

I am insulted at being compared to Glenn Beck. (Though I don't know who
Duane Gish is, unless she's the referent for the phrase Gish Gallop -
and even then, I don't have more than a vague idea of what that is.)

 At a glance, it certainly looks to me as if the Debian Way of
 customizing things may now have changed at least somewhat
 
 What were you glancing at? (it would be helpful so I can respond
 to your question - assuming you are asking a non-rhetorical
 question).

At the discussion to which I had been referring, and at the related
parts of my own installed Debian system.

-- 
   The Wanderer

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



signature.asc
Description: OpenPGP digital signature

Re: systemd-free alternatives are not off topic.

On 11/24/2014 11:01 AM, Scott Ferguson wrote:
 On 25/11/14 02:01, Jerry Stuckle wrote:
 On 11/24/2014 8:58 AM, Martin Read wrote:
 On 24/11/14 13:25, Jerry Stuckle wrote:
 And exactly what is the Debian way to add custom (NOT customized
 pre-packaged) software to the system?

 As far as I can tell, the obvious things that go into the Debian way
 for installing custom software are:

 1) If your software isn't installed via Debian's packaging system, avoid
 conflicts with the packaging system by installing it in places that
 Debian's packaging system is not supposed to manipulate (e.g. /usr/local)


 Sometimes.  Often, though, they go in places like /bin or /sbin - as was
 done in Unix 25 years ago.
 
 (newsflash?)
 UNIX != Linux


Yes, I know.  However, that does not change the fact they started with
Unix years ago.  And Linux was basically built to be a free replacement
for Unix.

 and,dist-upgrades won't over-ride binaries or scripts *unless* the sys
 admin has failed (BP and admin 101) by installing packages with names
 that conflict with regular distro supplied binaries/scripts.
 Dependencies for custom installs *should* be catered for by the
 installing admin - apt is good, but it's not magical (neither is any
 package manager). i.e. expect the impossible and prepare for failure
 (and don't expect professional credits).
 

As I said - their custom code does not have packages associated with
them.  And the code is nowhere in any repository - Debian or otherwise -
except in their own systems.


 2) If your software needs an init script, make sure that your script
 includes a correct LSB header and supports at least the standard verbs
 with their expected meanings.



 Some do, some don't.  Many times they are just simple scripts to start a
 daemon because they don't depend on another system daemon starting.
 
 Agreed - but not useful in 'this' context. Does not parse. Please expand
 - specifics would be useful (pretend you're writing a use-case for
 change control). Your time is not less or more valuable than any one
 else's (an hour is worth exactly one hour).
 

They are useful in that they do their job, and someone doesn't have to
learn LSB headers (or pass it off to another programmer who does
understand the headers).  All that is needed is some basic dash skills.
 And that saves company time and money.

Jerry



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54735da2.2040...@gmail.com

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread Curt

On 2014-11-24, Scott Ferguson scott.ferguson.debian.u...@gmail.com wrote:

 Some of them came to Debian because it was one of the last holdouts.

 Is that a reference to a term used in a television show about the
 fictitious Wild West? I can only apologise of my ignorance of popular
 culture (long story - I haven't watched television in several decades
 - did I miss something important?).


I think you're confusing holdups and hideouts (people who commit the
former repair to the latter) with holdouts.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnm76nkt.25d.cu...@einstein.electron.org

Re: moving from 3.16-3-486 to 686

2014-11-24 Thread Harry Putnam

Pascal Hambourg pas...@plouf.fr.eu.org writes:

 Harry Putnam a écrit :
 
 My question is whether continuing to use the 486 versions of kernels
 has any down sides?

 The -486 kernel lacks support for multiprocessing/hyperthreading and PAE
 (which is required for NX/XD bit).

I see in my latest `full-upgrade' that I've now gone to a 586 kernel:

 uname -r 3.16.0-4-586 

I did nothing purposely to make that happen but there it is.

Does your comment about multiprocessing/hyp ... hold true for 586 as
well?

Oh, and what is `NX/XD'?



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d28cec25@reader.local.lan

Re: systemd-free alternatives are not off topic.

On 25/11/14 03:13, Jerry Stuckle wrote:
 On 11/24/2014 10:05 AM, Scott Ferguson wrote:
 On 25/11/14 00:25, Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
 Yes, and while the Linux community continues, Debian will 
 lose a lot of dedicated users due to this decision.
 Possibly another fork, or possibly another distro.  But
 Debian will lose users.
 
 1. At best that's pure speculation. With all due respect to 
 Gypsy Rose Lee (who is really just a naughty boy), some of us 
 engineer types place little stock in soothsaying.
 
 
 It is more than speculation.  Read the posts here - some people 
 (including me) are already looking for alternatives.  And so are 
 many companies I know of who have looked at jessie.
 
 1. Like most things, that's relative. In this instance to the 
 number of readers and users:- https://lwn.net/Articles/620441/ 
 and, see my comments further down about churn (if I was overly 
 tired and emotional I might write they're your ball, you know 
 where your home is?, empty promises, and, what's second 
 prize?. But I'm not 'that' tired and emotional).
 
 2. Fore-telling the future, especially when the basis for future 
 extrapolation is *not* based on *any* (supplied and confirm-able) 
 facts - is assumption (not presumption - which generally, 
 pre-supposes 'some' evidence, of which you provide none (which 
 doesn't preclude the possibility you will at a later stage). 
 Presumption is distinct from assumptions. (not to imply you are
 cognitively impaired, just in awareness that this is not a 1:1 
 communication)
 
 
 It is not an assumption nor a presumption or prediction.  Several 
 people here (including me) have already indicated they are
 abandoning Debian for another distro or BSD.  So have most of my
 customers who are currently using Debian.  It is a fact.

Lacking evidence - it remains *not* a fact. Feel free to amnend the
world's dictionaries to adjust to you stated belief.

 
 3. companies that you 'know 'have looked at Jessie (which is 
 not yet a Stable release) is like secret attorneys - not 
 demonstrable facts and of dubious relevance. An unintentional 
 oversight on your part I 'suspect'. I may be alone in the desire
 to not start jumping at shadows (or hanging monkeys in sailor
 suits) - that 'may' (based on historical precedence) only lead to
 burning witches and people that don't look like the tribal
 patriarch.
 
 
 By contract, I am not allowed to specify which of my customers are 
 running what.  If you've ever been a consultant, you should be aware 
 of non-disclosure agreements; they are a standard part of almost 
 every consulting contract I've ever signed.

I'm familiar with the concepts - and won't indulge in juvenile urinary
sports that don't further the basic contention of what is an is not a
demonstrable fact.

 
 But that does not mean they are not jumping ship.


Agreed. Nor does plans for fighting an invasion of Martians. The only
relevance is that they are both speculation of what is allegedly
possible - conflated with likely, and having no relevance to *2.*

 
 
 2. It's false logic to conclude *only* losses from change (and 
 duplicitous to deny that systemd is your only choice) - it 
 overlooks the possibility that the additional *choice* of 
 systemd will attract more users (and more instances - you do 
 know that many administrators manage large numbers of 
 instances, right?). There is no evidence to show that other 
 distros and projects that adopted systemd as the *only* choice 
 lost users - quite the reverse.
 
 
 These are the ones who are abandoning Debian.
 
 Citation?  These is a, um, little vague.
 
 
 As I said - contracts forbid me from giving specifics.  But I'm sure
  you'll use that to say they don't exist.  They do, however.

Like secret attorneys and Santa Claus. I don't/won't cite clients with
similar contractual obligations because:-
; it's not relevant
; it's unsubstantiated-able (probably not a work, I'm jet-lagged)
; it denigrates those without a financial consideration as a major
factor in their motivations

 
 Some of them came to Debian because it was one of the last 
 holdouts.
 
 Is that a reference to a term used in a television show about the 
 fictitious Wild West? I can only apologise of my ignorance of 
 popular culture (long story - I haven't watched television in 
 several decades - did I miss something important?).
 
 
 No, it has nothing to do with TV.

Then it just doesn't translate into English English.

 
 Never-the-less I suspect what you refer[*1] to is what is called 
 churn. Tyre-kickers, testers, those that don't want to/don't
 have the time/capacity to learn sufficient skills, those that lack
 the motivation/capacity to decide for them selves and go with the 
 flow (of the noisiest) - as some might say - like dead fish. None 
 of which would be clients of your business - though admittedly 
 I'm guessing at your business model and mean no undue disrespect
 to you as a Veteran Unix

Re: systemd-free alternatives are not off topic.

2014-11-24 Thread Martin Read


On 24/11/14 16:30, The Wanderer wrote:

I do not have links to specific messages, since I don't habitually work
with or enjoy browsing through Web archives of mailing lists, and since
I've never understood (or even understood how to make practical use of)
the message links - looking outwardly similar to complicated E-mail
addresses - which people sometimes use to identify a particular E-mail
message.


Those message links use the Message-ID header, which is supposed to 
contain a globally unique identifier which can be used to unambiguously 
refer to the message in question, without worrying about different 
archives using different sequence numbers etc.


Mail user agents should provide some means of viewing the Message-ID 
field of individual messages, and should also provide a means of 
searching locally archived mail for a specific Message-ID.


The Debian mail archive also has a by-Message-ID search facility 
available at https://lists.debian.org/msgid-search/



I presume that you will be able to find the thread in your own
local archive of recent messages from debian-devel.


I wouldn't make that presumption myself, because I wouldn't expect 
others to keep a local archive of debian-devel given that I don't do so 
myself.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54736a21.2050...@zen.co.uk

Re: systemd-free alternatives are not off topic.

On 25/11/14 03:26, Jerry Stuckle wrote:
 On 11/24/2014 10:52 AM, Scott Ferguson wrote:
 On 25/11/14 01:57, Jerry Stuckle wrote:
 On 11/24/2014 8:54 AM, Miles Fidelman wrote:
 Jerry Stuckle wrote:
 On 11/24/2014 2:56 AM, Scott Ferguson wrote: snip
snipped

 Do you expect customers to build .deb files for every piece of
 software they create?

 No, I expect the admin to 'try' and do that (e.g. checkinstall) or
 install the upstream package to the appropriate place where it *will*
 withstand upgrade. But not everyone follows BP (e.g. ITIL, PCI, and
 whatever relevant guidelines apply to their use-case). I don't know what
 your use-case is...

 
 These are system admins who have either started with Unix in the 1980's,
 or people who learned from those sysadmins.  Back then you did put stuff
 in /bin and/or /sbin, for instance.  And the company is not changing.

Good luck with that (whoever you really are). The triumph of optimism
over experience will no doubt be one hell of a party. Shame I'll likely
not have an invite.
Historically Overcome (difficulties) and Adapt (to change) works for
survivors.

 

 It doesn't happen - and is not going to happen.  It's much faster

 Convenience is the antipathy of security? (security also mean reliability).

 
 It is reliable.  

Imagine that I used a time machine to make the same point previously
(whoever you really are).

 And has been for many years.  That's what testing is
 all about.

Apropos of what? You (whoever you are) shouldn't be running Testing if
you want stability (Stable). I'm unable to conceive of how any minimally
qualified Veteran UNIX Administrator doesn't get that (though
admittedly I have been accused of lacking imagination).

Please stop shifting goal posts - you'll not only hurt your back but
also blow your cover.

 
 And even if they did create .deb files for everything, that would not
 negate the need for testing.

Agreed - I'm glad you (who ever you are) have finally grasped some of
the basics of the Debian Way, and also, basic change control. My
only question is - what is your point? (aside from argument for the sake
of argument).

I am pleased that some to what I've said earlier has helped your
understanding - it somewhat compensates for my time.

snipped

Yours in Debian solidarity.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54736ce3.4090...@gmail.com

Debootstrap and Multistrap - instructional material?

2014-11-24 Thread Richard Owlett

I attempting to do some heavily customized installs. It was 
suggested I investigate
debootstrap. My initial attempts were only a partial success. 
While searching for more information I came across multistrap 
which appears more suitable for me.


The man pages and tutorials I've found so far demonstrate gaps in 
my background.


The material I'm looking for would likely have been prepared for 
formal coursework.


Suggestions?

Thank you


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54736e05.1010...@cloud85.net

Re: moving from 3.16-3-486 to 686

2014-11-24 Thread Reco

 Hi.

On Mon, Nov 24, 2014 at 12:35:46PM -0500, Harry Putnam wrote:
 Pascal Hambourg pas...@plouf.fr.eu.org writes:
 
  Harry Putnam a écrit :
  
  My question is whether continuing to use the 486 versions of kernels
  has any down sides?
 
  The -486 kernel lacks support for multiprocessing/hyperthreading and PAE
  (which is required for NX/XD bit).
 
 I see in my latest `full-upgrade' that I've now gone to a 586 kernel:
 
  uname -r 3.16.0-4-586 
 
 I did nothing purposely to make that happen but there it is.
 
 Does your comment about multiprocessing/hyp ... hold true for 586 as
 well?

That kernel's config file has:

# CONFIG_SMP is not set

That means no multiprocessor support (i.e. a single CPU core will be
used all the time regardless of their actual number).


 Oh, and what is `NX/XD'?

https://en.wikipedia.org/wiki/NX_bit

It's considered a good thing to have one in CPU generally, as
implementing said bit in-kernel will hurt performance.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141124180435.GA27880@x101h

Re: systemd-free alternatives are not off topic.