Bug#883887: ITP: journalwatch -- Simple log monitoring utility for the systemd journal

[Ralf Jung]

Package: wnpp
Severity: wishlist
Owner: Ralf Jung 

* Package name: journalwatch
  Version : 1.1.0
  Upstream Author : Florian Bruhin 
* URL : https://github.com/The-Compiler/journalwatch
* License : GPL-3.0
  Programming Lang: Python
  Description : Simple log monitoring utility for the systemd journal

journalwatch regularily checks the systemd journal and reports all entries above
a given priority via email.  The tool supports a regexp-based per-service
whitelist.  It is similiar to tools like logwatch or logcheck, except it's much
more KISS and only works with the systemd journal.  In particular, since it can
take the message priority into account, it needs much less of a whitelist.

I want to package this tool because I am going to use it on my servers, and I
think it may be useful for others as well.  I am looking for a sponsor.

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

> That's precisely the point. If systemd is installed as default on every
> jessie system, since it ships its own time syncing client, what's the
> point of installing NTP (provided that the machine doesn't have to
> provide time services to other hosts) ? That's exactly what a well-known
> software company did to push its web browser by taking advantage of its
> dominant position on the OS market. And that's what systemd is doing
> with every component it intends to "offer" a replacement for.

As I already mentioned, I think the issue is very different with a
browser vs. some low-level system component. Or would you say that the
fact that we force every user to use GNU libc is comparable?
What you say could also be read as a plea against any kind of
integration, as this integration naturally provides a "best" combination
of tools, and it will be harder to exchange some of them. I would argue
that this is a trade-off. Personally, I am happy to know that the
combination of tools that make up a part of the low-level system, has
been tested and designed in exactly this constellation - as opposed to
the giant exploding test matrix that results from supporting several
variants of each tool. I appreciate that others have other preferences,
and hence I think it is crucial that people can choose. Jessie is the
first Debian release that offers a choice of init systems.

>>> No, it's not:
>> [...]
>>
>> Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
>> happen on my machine.
> 
> If you already ditched syslog, it obviously won't happen... You wouldn't
> be of such bad faith, would you ? ;)

Just to clarify, as you already suspected, I still have syslog
installed. ;-)

> Just kidding. More seriously, you avoided to comment on the real issues:
> is it a good sign of code quality (for the whole project) if the piece
> of code which is supposed to communicate with syslog doesn't even wait
> for it to be ready ? And more importantly, is it the quality level that
> Debian has accustomed us to ?

I didn't read the code. Depending on where and how this happens, I can
understand that someone doesn't want to make a call that blocks
arbitrary long. So if you get a timeout, what else could you do?

I also find it hasty to judge systemd's code quality from a single
example. The analysis of Russ and several others suggest that actually,
systemd has a fairly high code quality. That's not something I can
comment on; but they do seem to be eager to get rid of old cruft (many
say, too eager), which certainly helps keeping your code clean.
Considering the age and complexity of the software, I am also impressed
how well it works. And finally, what I can comment on is the amount of
documentation, and that's outstanding. I assume there is some
correlation between well-organized, well-documented code and
well-written (user-facing) documentation.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546765dc.50...@ralfj.de

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

>> How does having yet another NTP client shut off existing NTP clients?
>> How does having yet another way to configure your network shut off
>> existing alternatives?
> 
> How does having yet another web browser integrated in the OS shut off
> existing web browsers ? ;)

There's a difference between a browser popping into every kind of
launcher and starter and telling people it should be used; and something
like systemd-networkd that I wouldn't even know existed if I wouldn't
follow the news.
You have a point here. But I think that the case is different for
services that the average user hardly ever faces. People who do manual
network configuration beyond NetworkManager, are more than capable of
installing another suite for that if necessary (not that it looks like
/etc/network/interfaces will cease to function anytime soon). Everybody
else uses whatever Gnome/KDE/... provides and doesn't care how the magic
happens in the background.

>> Even syslog is still working!
> 
> No, it's not:
[...]

Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
happen on my machine.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467528a.80...@ralfj.de

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

>> Really, if all the energy that people put into complaining about systemd
>> and looking for proves to back their complaints (many of which are
>> certainly valid!) would be put into providing alternative
>> implementations of these interfaces that many desktop environments say
> 
> I *have* alternative implementations in the environment
> on my Debian desktop:
> 
> • X (well, XFree86 in MirBSD…)
> • evilwm (laptop) / icewm (desktop)
> • uxterm
> • screen
> • mksh
> • jupp
> • alpine
> • openntpd
> • inetutils-syslogd (currently)

I was specifically talking about interfaces (as in, dbus signatures),
not features.  That would deal with the GNOME dependencies, which your
alternatives do not.

> So, no need for anything systemd-ish.

Well, even better for you :) . Then you are even less affected by what
the git commit you referenced announces, than I am.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54663576.8030...@ralfj.de

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

>> How does having yet another NTP client shut off existing NTP clients?
> 
> https://github.com/systemd/systemd/commit/7b8b9686e050a2b19ed2a3686af187dffaab5c08

What do you think this commit does/announces? This is about removing
support from timedatectl to control other NTP clients. If you never used
"timedatectl set-ntp", this doesn't affect you at all.
This is not about removing support from systemd to start other NTP
services. "apt-get install ntpd" will continue to function to matter
what. Neither is it removing support for alternative implementations of
the timedated interface doing whatever they want.
There's obviously a con to such a change, but there's also a clear pro
from the maintenance perspective: less combinations to test.

So I stand by my question: How does adding yet another NTP client, (and
an implementation of a simple dbus interface that's tied to this
client), shut off existing NTP clients?

You may loose some of the desktop integration, but from your reaction to
the integration systemd is providing, that doesn't seem like it disturbs
you. And even that is only true until someone goes ahead and
re-implements the timedated interface.

Really, if all the energy that people put into complaining about systemd
and looking for proves to back their complaints (many of which are
certainly valid!) would be put into providing alternative
implementations of these interfaces that many desktop environments say
are really useful to them, the discussion could long be over. Nobody is
saying that implementing the logind interface is easy, but it's
certainly more sustainable than implementing the systemd-internal
interfaces systemd-logind is using, and running logind on top of that
(which, as far as I know [1], systemd-shim does). I've yet to see a
technical complaint about the *interfaces*, and that's really all Gnome
(and others) depend on.

[1]


Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546620a2.4060...@ralfj.de

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

> Isn't it so that systemd has changed a lot since the decision was made
> in February this year, and the rate of changes will not stop. In the
> meanwhile no stable API is defined



> and more and more functionality is
> integrated in the systemd software, effectively shutting off
> alternatives.

How does having yet another NTP client shut off existing NTP clients?
How does having yet another way to configure your network shut off
existing alternatives? Even syslog is still working! And so are cron and
lxc.

> When CoreOS is fully developed, there will a diminishing
> market for other distributions.

You seem to think that CoreOS will be so great that all users rush to
change there. That Debian would be unable to compete. I do not know what
you base this belief on, but I certainly think that Debian will continue
to stay relevant when yet another distribution emerges.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5464f146.6000...@ralfj.de

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Ralf Jung]

Hi,

>> I think the only workflow that newcomers and NMUers should be required
>> to learn is the one that involves quilt, they should not be expected to
>> learn (e.g.) dgit in addition. [...]
> 
> I certainly don't think people should be expected to learn dgit in
> addition to other tools.  I am trying to get to the point where
> 1. they can learn dgit _instead_ of _all_ other tools[1]  2. no-one else
> needs to know that this is going on unless they decide to start using
> dgit too.

I whole-heartedly agree - I still think quilt is obscure, and since I
only maintain few packages with little upstream activity, I doubt I will
ever learn it enough to stop reading the manpage each time I need it. On
the other hand, git is already widely known in the open source and free
software community. So being able to use dgit and nothing else, would
significantly reduce the barrier of entry. Once there is a version that
DMs can use, I'll give it a try :)

Kind regards,
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5464c6df.2090...@ralfj.de

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

[Ralf Jung]

Hi,

> On the other hand, it would break typical uses of using sound remotely.
> These days, shared computers are almost unheard of save for some school
> settings -- while loads of people have some raspi mediacenter or press
> some buttons on their phone to control sound coming from the big computer.

This usually happens via UPnP or similar, though - the actual audio is
ultimately done by a local user. So the audio group is unrelated to this
usecase.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545f8ff1.20...@ralfj.de

Re: Please more fish (was: so long and thanks for all the fish)

[Ralf Jung]

Hi,

On 09/11/14 07:28, Michael Gilbert wrote:
> On Sun, Nov 9, 2014 at 12:01 AM, Christoph Anton Mitterer wrote:
>> On Sat, 2014-11-08 at 23:30 -0500, Michael Gilbert wrote:
>>> No accusation, just a statement of fact.  Four ctte members were
>>> complicit in the vote [0]
>>
>> Well maybe I read that ruling wrong, but didn't it more or less say
>> "we're not deciding anything right now"?
>>
>> And even if that decision would be the sole reason for Joey to leave
> 
> Please actually read Joey's message to understand his concern, which
> is not at all about content or systemd, but the harmful actions of
> some project members and the complicity of others in those actions
> over some significant time now.

Please forgive my naiveness, but I do not understand what you are saying
here. Now, I am just an "informed outsider" of this discussion, so maybe
that was actually intentional. But I agree with Christoph that it looks
to me like the decision in this case was not to have a decision. Also,
five CTTE members agreed on that, so I don't understand where you got
your number 4 from.
I read Joey's message over and over without getting any more clues. He
said the CTTE has "Decided it should make a decision", which it seems to
me it did not. So I probably misunderstood something more fundamental here.

Maybe you were intentionally vague, then please just disregard this
message. I don't want to heat the discussion, just understand.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545f83d3.90...@ralfj.de

Re: inconsistent versions of M-A: same packages

[Ralf Jung]

Hi,

> Dpkg and apt allow this just fine. Try to do:
> 
> apt-get install --simulate gcc-4.9-arm-linux-gnueabihf
> 
> And you will end up with a number of armhf packages on your system (you have 
> to
> enable armhf beforehand of course).

Interesting, I didn't know that syntax is already supported. As far as I
know, some packages still use the "(virtual) MA: foreign package" trick
to encode cross-architecture dependencies - on a first check, at least
primus and the proprietary NVidia drivers seem to do that. Does this
mean they could add direct dependency/recommendation like
"libgl1-nvidia-glx:i386" instead?

However, aptitude does not seem to support this completely at this
point: "aptitude show gcc-4.9-arm-linux-gnueabihf" omits the
architecture qualifiers. Is that a bug?

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545df4ae.60...@ralfj.de

Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files

[Ralf Jung]

Hi,

>>> - Debian should ship a default set of firewall rules. Are we the only
>>> distro which doesn't do this? I mean a basic ruleset which drops
>>> incoming, accepts outgoing and accepts related,establised is so easy to
>>> do... and it would help for all those cases where services are started
>>> but not yet finally configured/secured by the admin.
>>
>> Are all of our users admins that grasp firewalls?
> 
> Most likely not, and therefore I agree that with the current state of
> affairs, enabling a firewall on Debian by default is probably a bad idea.

One could also interpret this the other way - since many people don't
know how to manually configure a firewall, there should be something
there per default that protects them.

> However, it should be possible to create a tool which helps novice users
> in managing their firewall, and such a tool could be installed by
> default on at least a Desktop installation. If we go down that route,
> and if said tool is easy enough to use and understand for the most
> novice of users, I would absolutely agree that enabling a firewall with
> this tool on default installations is desirable.

There's firewalld that integrates into NetworkManager - at last for
Desktops using the latter (KDE, Gnome, Xfce, probably more) that may be
a sensible choice. I didn't have a closer look at it yet, though.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54561762.1060...@ralfj.de

Re: What is the policy on audio group? and, proposal of a new group for the jack audio server

[Ralf Jung]

Hi,

> Marco d'Itri:
>> On Oct 27, Tobias Frost  wrote:
>>
> Ok, so you are for removing audio group from user default groups?
 Eventually, yes.
>>> Did you mean "maybe" or "for sure, someone"
> 
> s/someone/sometime/
> 
>> No.
>>
> Then what *did* you mean?

Well, probably the correct English meaning of "eventually", which is,
"at some (unspecified) point in the future". :)

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5451695b.2090...@ralfj.de

Re: LSB headers and other junk, how do you hack a quick init script in debian these days?

[Ralf Jung]

Hi,

>> I write a systemd unit file. It’s smaller, faster to write, easier to
>> understand and works more reliably. 
> 
> And it is also a bug to not have an init script since we still have
> ports that do not use systemd.

And this is also completely irrelevant as the question was about quickly
hacking something together for local use.
If it were about a package, then he would have to put stuff into
/etc/init.d anyway, and add LSB headers, etc. In other words, it would
work with systemd without him changing his habits.

Of course, Michael, you can also always choose not to use systemd,
should you wish to do so. It's not like that is complicated:
$ aptitude install systemd-sysv- sysvinit-core systemd-shim

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5446bb68.2030...@ralfj.de

Re: removable devices

[Ralf Jung]

Hi,

> I also use systemd.
> 
> The events are being generated because now I can see the 
> devices, but I get an "error" when I click to mount them.
> 
> It doesn't show more detail than that, so I don't know what's 
> happening.
> 
> I will try with an older version of udisks2 and see what 
> happens.

My shot in the dark would be that there's a problem with the
permissions, and PolicyKit doesn't allow you to mount. udisks2 2.1.3-2
enabled some stuff which makes more use of the systemd session/seat
features. Does "loginctl list-sessions" list your user session?

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543ad69b.1090...@ralfj.de

Re: removable devices

[Ralf Jung]

Hi,

>> I use KDE on Sid.
>>
>> Lately (but I can't pinpoint the exact moment), plugging an USB drive 
>> has stopped generating any reaction and I need to mount manually.
> 
> You need to grab udisks2 2.1.3-1 from snapshot.debian.org, any later version
> doesn't work.  This includes the current version that's slated for jessie.

I use KDE on testing, and mounting of removable devices works just as
fine as it always did.
I also use systemd, maybe that's related.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5438f46f.3060...@ralfj.de

Re: TLP package vs. pm-utils

[Ralf Jung]

Hi,

>> see [3] –, neither is pm-suspend called by systemd's sleep.target.
> 
> Not by systemd as pid 1, but if you run with upstart or sysvinit,
> systemd-shim will use pm-utils if it is installed, so that suspend
> quirks still work.
> 
> IMHO it is a bit unfortunate that all the suspend quirks and power
> management scripts were so lightly discarded upstream. I do understand
> their perspective of "fix stuff in the kernel", but in a distribution
> we have a slightly different perspective (e. g. consider an admin of a
> stable release -- what will he realistically be able to do: add a
> documented quirk to a text file, or fix the nvidia graphics driver?)

Is there actually any method left to hook into suspend/resume, that
works under systemd and other inits? I wouldn't know of any, which is a
problem for packages like, e.g., hdparm, which has to re-configure the
HDD parameters after resume (see [0]).

[0] 

I'm a bit puzzled what the current situation of power management in
Debian is, and which packages are actually useful when using systemd. I
removed pm-utils and acpi*, and everything is still working, so I
conclude their functionality is now handled by systemd.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5438f25c.6020...@ralfj.de

Re: Request when replying to bugs: include the package name / topic.

[Ralf Jung]

Hi,

>> Or even better: properly set In-Reply-To / References. You can easily
>> do this by downloading an email from the bug thread and replying to
>> that.
> 
> Good advice. It's as easy as:
> 
> $ bts show --mbox 
> 
> or add the ‘--mailreader=foo’ option if you want a MUA other than Mutt.

or click the "Reply" link above a previous (the last?) message in the
BTS web interface.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5422a057.4000...@ralfj.de

Re: Trimming priority:standard

[Ralf Jung]

Hi,

> Le Tue, Sep 23, 2014 at 07:22:11PM +0200, Marco d'Itri a écrit :
>> On Sep 23, Ralf Jung  wrote:
>>
>>> I've seen multiple machines, including older machines of myself, to be
>>> under full disk load for at least several minutes due to (some form of)
>>> locate - every time the cronjob runs. The slowdown was noticeable,
>> This is hard to believe, since the cron job uses ionice -c3.
> 
> I had a similar experience with ‘tracker’, GNOME's equivalent of locate, which
> also runs under ionice.  Unfortunately I can not recall if during the years I
> used the systems where the slowdown was noticeable I had changed something
> relevant in the configuration of the hard drive (like running a hdparm 
> command)
> or if it was pristine.  The common thing between these machines was a loud and
> slow hard drive: I never had this problem with a SSD (but again, on SSD I run
> more recently installed systems where I am sure that I never used hdparm).
> 
> Anyway, the point I want to make is that we should trust Ralf when he reports
> that full disk load slows his machine despite cron jobs using ionice, although
> this is probably a corner case.

Just to clarify, it should be "slowed" my machine - my current machine
has an SSD and no form of locate installed, all this is experience from
2 or more years ago. Since then I made sure that the experience does not
repeat ;-)

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54228df7.4050...@ralfj.de

Re: Trimming priority:standard

[Ralf Jung]

Hi,

>> s/daemon/cron job/g
> 
> Then I disagree with your claim about «very significant overhead».  Even
> on spinning rust, mlocate is pretty quick since it does a good bunch of
> optimisations to avoid re-indexing unchanged directories.  Maybe your
> perception has been marred by slocate and the original locate, which at
> least used not to have such optimisations?

I've seen multiple machines, including older machines of myself, to be
under full disk load for at least several minutes due to (some form of)
locate - every time the cronjob runs. The slowdown was noticeable,
whenever locate did it's job, tasks like starting Firefox or listing
large directories got significantly slower. If this were done on
battery, the remaining runtime would drain much quicker than necessary.
Has mlocate already been the default in Squeeze? Maybe there were some
improvements during the last year or so - uninstalling (all forms of)
locate is pretty much the first thing I do on any Debian machine someone
not experienced in Debian puts in front of me (together with exim, nfs,
rpcbind). Hence I wouldn't even notice if this improved.

Finally, even if mlocate improved the situation significantly, many
people installing Debian (if not most of them) will have mlocate
installed (if you don't know exactly what you are doing, you *will*
select something called "standard tools") without ever using it. So even
the slightest amount of work it does, is wasted.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54211f01.3070...@ralfj.de

Re: Trimming priority:standard

[Ralf Jung]

Hi,

from personal experience, I agree that the packages with priority
standard need to be reconsidered. I don't really care about bc, dc, w3m
and similar tools - I never use then, but then, they only need a few KiB
so I wouldn't mind if they were installed nontheless. However, there are
4 packages which, I think, are actively problematic: at, exim, nfs, and
locate.

> - at.  Trivially installed by anyone actually using it, but we don't
>   need one more daemon running on everyone's system just to watch for
>   jobs via a service that almost nobody uses.

Exactly. There's no point in this daemon running all the time on
machines where they will never be used. It's not significant, but it's
just a complete waste.

> - exim4.
> - nfs-common and rpc-bind.

Just like at, these packages just install processes that will needlessly
sit around and do nothing at all on most machines. Those admins that
actually want mail and/or NFS can easily get them anyway (and they may
choose another MTA), most people won't even know they have them running.
Unlike at, these two additionally open ports, thereby increasing the
attack surface of newly installed systems. I don't think it is a good
idea to have open ports (and no firewall) on a newly installed system.
However, I don't know enough about their respective default
configuration to judge how large the risk of an attack is.
Besides, the considerations regarding at apply here as well.

> - mlocate.  We don't need a "locate" in standard; anyone who actually
>   uses locate (and wants the very significant overhead of running a
>   locate daemon) can easily install this.

Finally, I think this one is actively harmful. I've had to tell a bunch
of my friends to remove this package after they asked me why their
Debian system, from time to time, triggered huge bursts of disk
activity. That's the opposite of the "feeling of control" many like
about Linux, and Debian in particular: The system is doing "something"
it was not asked for, for no good purpose (as far as the user is
concerned), and without an obvious way to figure out what's going on and
how to stop it. I sure hope there is at least something in place to stop
this from running when the machine is on battery...

I removed these four packages from a bunch of systems where they were
installed accidentally, and either served no purpose or were actually
annoying the user (i.e., locate). They are also the reason why I tell
everybody *not* to select "Standard system utilities" during the Debian
installation: It's better to start without some basic utilities and
install them as needed, than to have a bunch of stuff doing things on
the system that you don't know about...

So, please, restrict "Standard system utilities" to packages that don't
open ports or regularly create significant system load without obvious
gain for the average user. If possible, avoid everything that runs a
daemon which does nothing if the user doesn't know about it (unlike
daemons like, for example, ntp - which I'd be happy to see in
"standard"). From my experience, nothing like this is what people expect
when selecting "Standard system utilities".

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54155f58.4060...@ralfj.de

Re: PackageKit cleanup: Do you use these functions?

[Ralf Jung]

Hi,

>> And at least I would prefer offline updates over my web browser crashing
>> or shell completion breaking (until re-exec of the shell to be
>> compatible with plugins).
> 
> I would much prefer to not have to reboot the entire system and lose
> all state for the sake of a couple of userland application updates. If
> things don't work, file bugs. If the latest shiny desktop stuff can't
> cope with re-exec etc. well, then I'm glad to not be using it. :-/

Then just not use this feature, and do your updates as you always did.
It's entirely optional, after all.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412085c.10...@ralfj.de

Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)

[Ralf Jung]

Hi,

> So, with what you're proposing, we'll have something like this:
> 
>│[*] Desktop environment │
>│[*] ... Xfce│
>│[ ] ... GNOME   │
>│[ ] ... KDE │
>│[ ] Debian pure blends  │
>│[ ] ... Debian Edu  │
>│[ ] ... Debian Med  │
>│[ ] ... DebiChem│
>│[ ] Openstack   │
>│[ ] ... Compute Node│
>│[ ] ... Proxy Node  │
> 
> This looks awesome already, a way better than what we had before. Not
> only this provides real choices to the user, but also suggest usage
> features which some of our users may have missed. Someone already
> proposed, in the wiki, to add "Games". I like the idea a lot, and it
> perfectly makes sense to select all games at once.

I agree, this is a great improvement. I wonder though whether it is
justified to add SSH again? It is of course just a single package being
dragged in, but it is "special" in the sense that it's often used to
provide the very access to the machine. Installing SSH already during
system installation avoids the need of ever logging in usually.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540dde11.7090...@ralfj.de

Re: More tasks option in Tasksel: what tasks do you want there?

[Ralf Jung]

Hi,

>> Having separate tasks for mail and NFS servers, would IMHO be a good
>> step in the right direction.
> 
> Yes. Though the design idea behind tasksel is to have generic "theme"
> and not technical words which a user wont understand. (note: it's not
> that I agree (or not) with this design choice, this is just a fact that
> I am mentioning here...)

As you pointed out by quoting the packages, these are already separate
tasks in current jessie, which I think is right. What remains unchanged
is "standard system tools", which I now understand is special. I assume
making NFS and MTAs non-"standard" is getting political, so I don't want
to open that can of worms ;-)

>> "SSH Server" is the only task I consider actually useful.
> 
> Don't you also find that "print-server" is also useful?

I don't run any machine as a dedicated print server ;-) and my desktop
machines got cups through some other dependency, it seems. I agree it
can be useful. As mentioned elsewhere, this is "just" because cups and
openssh are the only widely used options here.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540ddd4b.2020...@ralfj.de

Re: More tasks option in Tasksel: what tasks do you want there?

[Ralf Jung]

Hi,

> At this point
> the only viable option is to uncheck everything, install as a bare base
> system and then deal with package inclusion post-install reboot.

This is also my experience. It's also something I repeatedly had to
explain to friends installing Debian, who had false expectations based
on this task selection.  They are often surprised to find Exim on their
system just because they checked "standard system utilities", or an NFS
server (which IIRC is installed unconditionally).
Having separate tasks for mail and NFS servers, would IMHO be a good
step in the right direction. I tried to find out what tools are pulled
in by "standard system utilities", but couldn't find the package in
aptitute.

"SSH Server" is the only task I consider actually useful. I don't have
"Laptop" installed on my laptop, as I don't need either acpi nor
pm-utils (since I'm on systemd). Also, what's laptop-specific about ACPI
or wireless-tools or pm-utils? Desktop computers can just as well have
wireless, or use suspend.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540d96d7.5090...@ralfj.de

Re: logcheck rules for systemd

[Ralf Jung]

Hi,

couldn't logcheck get much more clever on a systemd-enabled system?
After all, the priorities are preserved, so everything of priority
"info" or lower could be ignored automatically - and only warnings and
errors considered further. Actually that's one of the reasons why I am
looking forward to running systemd on my servers.

Kind regards
Ralf

On 28/08/14 17:22, Russ Allbery wrote:
> Ondřej Surý  writes:
> 
>> I have started to collect logcheck/ignore.d.server/systemd rules for
>> systemd:
> 
>> https://wiki.debian.org/systemd/logcheck
> 
>> I think it might be a good idea to fine tune the rules before submitting
>> them for inclusion into logcheck default ruleset...
> 
> Should we include rules that match lines like:
> 
> Aug 28 07:30:01 lothlorien systemd[1]: Starting Run anacron jobs...
> Aug 28 07:30:01 lothlorien systemd[1]: Started Run anacron jobs.
> 
> or should those be in the anacron package / rule set?  I could see an
> argument either way.
> 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54010645.7060...@ralfj.de

Re: internationalized domain name (IDN) in Debian

[Ralf Jung]

Hey Noël,

> I'm collecting the status of IDN in Debian on
> https://wiki.debian.org/IDN 

Nice :D

> Summary: webbrowser support it in general but email clients still lack
> the support of it.

Why do you list Icedove as non-supporting? I just sent a mail to your
echo service, and got a reply. Is there anything else I should check?

Kind regards
Ralf



signature.asc
Description: OpenPGP digital signature

Re: Standardizing the layout of git packaging repositories

[Ralf Jung]

Hi,

> I do think that this is quite common, and my preferred way of doing
> things. It is easy for newcomers to handle, easy for me to handle, no
> need to learn a lot of git specific tools or helpers, you can mostly
> ignore git if you want to.
> 
> I've a couple of times tried to get myself to actually learn various of
> these newfangled tools like git-buildpackaeg and such, and each time I
> end up feeling they get much more in my way that they actually help me.

Being a newcomer to packaging, I have to disagree on this. I use gbp for
my packages and found, so far, no other way of dealing with packages
that's even remotely as convenient. In particular, handling the upstream
tarball and whatever is necessary when there's a new upstream version is
an absolute no-brainer.
I was not aware of got-overlay until recently, maybe that helps to make
the debian/-only structure more usable. But for all I'm concerned, git
is not helping at all here, it's like dealing with a "raw" package
without any helper.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f23980.8080...@ralfj.de

Re: systemd service and /etc/default/

[Ralf Jung]

Hi,

>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices on
>> the system (including new ones that show up dynamically) and
>> automatically handle all of them unless configured to do otherwise,
>> making configuration usually unnecessary.
> 
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?

It seems the upstream package lacks basic means of configuration (like,
parsing a list of interface identifiers) and is not able to cope with
network interfaces that come or go at run-time. Of course every
distribution can re-create their own (and probably differing) solutions
to this problem - but fixing the issue upstream should really be preferred.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f09739.9000...@ralfj.de

Bug#687711: ITP: osspd -- OSS Proxy Daemon: Userland OSS emulation

[Ralf Jung]

Package: wnpp
Severity: wishlist
Owner: Ralf Jung 

* Package name: osspd
  Version : 1.3.2
  Upstream Author : Tejun Heo 
* URL : http://sourceforge.net/projects/osspd/
* License : GPL
  Programming Lang: C
  Description : OSS Proxy Daemon: Userland OSS emulation

OSS Proxy Daemon is a Linux userland OSS sound device (/dev/[a]dsp and
/dev/mixer) implementation using CUSE. Currently it supports
forwarding OSS sound streams to PulseAudio and ALSA.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120915113359.12794.53381.reportbug@r-schnelltop

Bug#684053: ITP: lightdm-kde -- a LightDM greeter using KDE libraries

[Ralf Jung]

Package: wnpp
Severity: wishlist
Owner: Ralf Jung 

* Package name: lightdm-kde
  Version : 0.2.1
  Upstream Author : David Edmundson 
* URL : https://projects.kde.org/projects/playground/base/lightdm
* License : GPL
  Programming Lang: C++
  Description : a LightDM greeter using KDE libraries


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120806144451.22550.24717.reportbug@r-schlepptop

Bug#668656: ITP: plotter -- Simple Qt-based mathematical function plotter

[Ralf Jung]

Package: wnpp
Severity: wishlist
Owner: Ralf Jung 

  Package name: plotter
  Version : 2.2
  Upstream Author : Ralf Jung 
  URL : http://mathespiele.ralfj.de/programm.php?id=25
  License : GPL
  Programming Lang: C++
  Description : Simple Qt-based mathematical function plotter

Version 2.2 is not yet released upstream, but an RC available for download from
http://mathespiele.ralfj.de/programme/plotter-2.2-rc1.tar.gz . If there are any
more changes which could go upstream necessary to make this better suited for
Debian, I'd like to include them in version 2.2.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120413204303.18234.14906.reportbug@r-schlepptop