Re: Linking coreutils against OpenSSL

[Bjørn Mork]

Luca Boccassi  writes:

> If we want to start nitpicking, then let's be exact: 0.61% of popcon.
> Whether that qualifies as "plenty" we'll leave as an exercise for the
> readers.

I wonder if this sort of arrogant "don't care about minorities" attitude
will ever stop?  Was sort of hoping that things would quiet down when
everyone just gave up on the systemd and usr-merge crazyness. But it
seems the bullies continue on and on and on and on.

I guess those 0.61% are run bt the most valuable Debian users out there.
I'm sorry to not be one of them, but that's the way things have become.
Not by choice.


Bjørn

Re: snapshot.d.o has been in a bad state for several months

[Bjørn Mork]

"Theodore Ts'o"  writes:

> I was curious about this, since I rely on snapshots.debian.org in
> order to create repeatable builds for a file system test appliance, so
> I started digging a bit.  Looking at the debian-bugs pseudo-package
> "snapshot.debian.org":
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=snapshot.debian.org
>
> the maintainer is listed as:
>
>   "snapshot.debian.org Team "
>
> But according to lists.debian.org, "debian-shaphots" is a dead list,

"debian-shaphots" != "debian-shapshot" :-)

https://lists.debian.org/debian-snapshot/


Bjørn

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

[Bjørn Mork]

nick black  writes:

> what
> does NetworkManager offer that makes it superior to
> systemd-networkd on the desktop

I don't know what systemd-networkd has to offer in this regard, but for
laptop usage I'm personally fond of the ModemManager integration along
with multihoming policies (eth0 preferred over wlan0 preferred over
wwan0 by default).

For the same reason I believe conman should not be default on any
hardware with a built-in modem, regardless of desktop choice.

For servers I agree with others here - I'm slowly migrating to
systemd-networkd. Makes stuff like DHCPv6-PD much easier to manage for
example. I've been a happy ifupdown user for ages, but now I believe it's
time to move on...

A standalone dhcp client is still important to me for one specific use
case: testing and debugging of DHCP services.  Been using the ISC client
a lot for this, both for IPv4 and for different DHCPv6 modes.  I guess
the busybox client is a good enough replacement for v4.  Not sure about
DHCPv6. The advantages of the ISC client for this use case has been the
terminal debug output and the scripting abilities, where you also could
use "/usr/bin/env" as "script" to dump all the vars.


Bjørn

Re: booststrapping /usr-merged systems

[Bjørn Mork]

Steve McIntyre  writes:
> Raphaël Hertzog wrote:
>>
>>In the same spirit, I'd like to throw an idea... could we decide that
>>base-files is the first package to be configured as part of the bootstrap
>>protocol and change base-files maintainer's scripts into statically linked
>>executables so that they can work even if we don't have the library loader
>>on the ABI-compliant path?
>
> What exactly do you mean here? You know that even a statically linked
> executable needs an interpreter defined in the ELF header?

Maybe I'm missing something, but can't you code a different interpreter
path insto such a special purpuse script?

#!/usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/dash
echo foo
[ -e /lib ] || /usr/lib/x86_64-linux-gnu/ld-2.31.so /usr/bin/ln -s /usr/lib /lib

or whatever?



Bjørn

Re: booststrapping /usr-merged systems

[Bjørn Mork]

Marco d'Itri  writes:

> as we all know every Debian maintainer can veto any systemic changes 
> that they do not like.

I don't think qusr-merge would not have happened if this was true.  And
I believe you know that very well.

I find your remark disrespectful. And I'm trying hard to assume good
faith here.  Please help me.  What are you trying to achieve by it?  Was
it meant as a joke?  If so, then it was a bit misplaced I'm afraid.

Maybe you should re-read https://www.debian.org/code_of_conduct ?


Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Ansgar  writes:

> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
>> Hmm.  I find the netboot installer archives very useful for rescue
>> purposes.  This sometimes involves PC hardware too old for amd64. I PXE
>> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
>> drive was part of the optional docking station) using a bullseye
>> netboot.tar not long ago.
>
> You can keep using the bullseye netboot.tar for the next 20+ years to
> rescue boot an ancient system, copy the data off of it, and then
> responsibly dispose the system.

That won't work, will it?  netboot must match the kernel version in the
archive to be useful.  Or am I missing something?


> I don't think this is a good argument to keep generating i386 install
> media.

Maybe not.  Just wanted to mention the use case so it can be
considered. I understand that it might not justify the resources
required.



Bjørn

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Bjørn Mork]

Steve McIntyre  writes:

> I had been thinking about doing similar for installer images too, but
> with other work going on too I think it got too late in the cycle to
> make that change. My plan is therefore to ship i386 installer images
> for bookworm as normal (including bookworm point releases going
> forwards), but to disable those builds for testing/trixie ~immediately
> after the release.

Hmm.  I find the netboot installer archives very useful for rescue
purposes.  This sometimes involves PC hardware too old for amd64. I PXE
booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
drive was part of the optional docking station) using a bullseye
netboot.tar not long ago.

Not a major thing, but if you're going to keep most of i386 anyway...


Bjørn

Re: transition to usrmerge to start around 2022-09-15 (next Thursday)

[Bjørn Mork]

Luca Boccassi  writes:

> Nothing was ignored.

In the spirit of good faith I'll assume you meant "Nothing new was
ignored".

It's a fact that you are ignoring a few issues caused by usrmerge.  This
is thoroughly documented in the BTS.

Arrogance is not on the bug list, but maybe it should be?  It's
definitely something Debian will have to work on before releasing with
usrmerge in the current state.

usrmerge adds bugs which you so far have been unable to fix. That's
nothing to be ashamed of.  Just try to be honest about it.

I assume that you plan to fix the bugs before the release. Note that the
CTTE did not request the addition of any bugs, or make any exceptions
for the usrmerge package.  What to do about usrmerge if it conflicts
with other goals is not decided yet.

So if you don't want another round of pointless discussions, then I
suggest that you start working on those bugs now. That's the smart thing
to do if you want to make *sure* usrmerge is part of the release.  If
there is no conflict between release goals, then there will be no need
for a discussion.

I find it quite disappointing to read https://bugs.debian.org/848622 . I
don't know if it is arrogance or ignorance, but this bug is undoubtedly
caused by usrmerge:

 frtest2:~# ls -l /usr/bin/bash 
 -rwxr-xr-x 1 root root 1283864 Aug 25 16:03 /usr/bin/bash
 frtest2:~# dpkg -S /usr/bin/bash 
 dpkg-query: no path found matching pattern /usr/bin/bash

Pointing at other maintainers/packages to fix your bugs is anti-social.

Don't force Debian decide whether the usrmerge bugs should be accepted
in the next release.  Just fix them.  The alternative is ugly. And I'm
not thinking about the actual bugs, but about the discussion...

It's fine to oversell the advantages of usrmerge.  It's not fine to try
to hide the disadvantages.


Bjørn

Re: adduser default for sgid home directories

[Bjørn Mork]

Philipp Kern  writes:
> On 25.07.22 08:46, Bjørn Mork wrote:
>> Matt Barry  writes:
>>>> - why has a change been made
>>>
>>> I think this is explained in excruciating detail.  The short version
>>> (from NEWS):
>>>
>>> "mode 0700 provides both the most secure, unsurprising default"
> [...]
>> And the claim that this is "most unsurprising" (less surprising?) is
>> obviously false. "No change" is always less surprising than any change,
>> whatever the rationale is.
>
> It can also be unsurprising from an end-user's perspective. For
> someone new to the system. So that line of argument does not really
> hold.

True.  Good point.

I was reading this as "unsuprising to the reader (system operator)", but
I see that it could mean "unsusprising to the system users".  Which
would make more sense.

Is there a limit to the size of these entries which makes it hard to be
more precise?



Bjørn

Re: adduser default for sgid home directories

[Bjørn Mork]

Matt Barry  writes:

>> - why has a change been made
>
> I think this is explained in excruciating detail.  The short version
> (from NEWS):
>
> "mode 0700 provides both the most secure, unsurprising default"

This is a self-referencing explanation.  It provides no value.  It's
only good if you already understand (and agree) that 0700 is more secure.

And the claim that this is "most unsurprising" (less surprising?) is
obviously false. "No change" is always less surprising than any change,
whatever the rationale is.


Bjørn

Re: What to do with merged /usr and dpkg-fsys-usrunmess

[Bjørn Mork]

Andrey Rahmatullin  writes:
> On Wed, Apr 06, 2022 at 04:02:23PM +0200, Bjørn Mork wrote:
>> > Sorry, blame the dpkg maintainer.
>> 
>> Is that how we discuss technical issues around here?
> This is not a technical issue.

Ah, sorry.  I mistook this for the "Discussion about technical
development topics" list.  My fault


Bjørn

Re: What to do with merged /usr and dpkg-fsys-usrunmess

[Bjørn Mork]

Marco d'Itri  writes:

> Sorry, blame the dpkg maintainer.

Is that how we discuss technical issues around here?


Bjørn

Re: Gmail bounce unauthenticated @debian.org addresses

[Bjørn Mork]

"LeJacq, Jean Pierre"  writes:

> There are standard best practices for forwarding support in SPF.
>
> http://www.open-spf.org/Best_Practices/Forwarding/

Well, if it only was that simple.

There is NO working SRS software/example config for sendmail in Debian
or anywhere else AFAICS.

The only thing we have is the python3-srs packages, which are still full
of python2 specific code. None of the included tools even run on
bullseye.  For example:

bjorn@canardo:~$ /usr/bin/srs2envtol 
Traceback (most recent call last):
  File "/usr/bin/srs2envtol", line 14, in 
from ConfigParser import ConfigParser, DuplicateSectionError
ModuleNotFoundError: No module named 'ConfigParser'
bjorn@canardo:~$ dpkg -S /usr/bin/srs2envtol 
pysrs-bin: /usr/bin/srs2envtol
bjorn@canardo:~$ apt-cache policy pysrs-bin
pysrs-bin:
  Installed: 1.0.3-2
  Candidate: 1.0.3-2
  Version table:
 *** 1.0.3-2 700
700 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status

(yes, I could fix that and the remaining issues - but that's not the
point)

IMHO, modifying postsrsd looks like a much better alternative if I were
to write something. Should be pretty easy to make it optionally use the
sendmail socketmap protocol instead of the postfix tcp_table protocol.
Or alternatively just write a simple proxy protocol translater.  Then it
could be plugged right into the example sendmail config from pysrs.

But as have been the result each time I've considered SRS:  I got bored
with it long before I got it running.  Why do I care whether google can
send a bounce back?  So I've just added owner-aliases for all my
forwarded accounts (only a handful), pointing to a /dev/null address.

That does it for me.  SRS and SPF can continue to burn in the hell where
it was invented.


Stay tuned for the next episode of Mail Server Frustrations, where we'll
look at Exim and mixed TLS (port 465) and STARTTLS (port 587) submission.



Bjørn

Re: The future of src:ntp

[Bjørn Mork]

Bernhard Schmidt  writes:

> - Since NTS leverages X.509, how does it work with a broken clock on
>   boot that is ticking outside of the certificate validity period?

I don't know how it is intended to work, but it seems pretty obvious
that NTS certificate validation must ignore the validity period.

If you have a validating DNS resolver with correct time, then you might
replace it with DANE validation (i.e if the certificate matches the
current DNS TLSA record then it is valid regardless of current
time). But I don't know if you can make that a requirement.



Bjørn

Re: etc/resolvconf/update-libc.d/ equivalent for systemd-resolved

[Bjørn Mork]

Scott Kitterman  writes:

> I believe I can solve this problem by adding Recommends: resolvconf if that's 
> the only way.  I had hoped there would be some "modern" way to do it from 
> within Debian's default package set.

Funny.  That seems to have been the solution to this bug almost 20 years
ago too: https://bugs.debian.org/154669


Bjørn

Re: merged-/usr transition: debconf or not?

[Bjørn Mork]

Michael Biebl  writes:
> Am 17.11.2021 um 19:57 schrieb Sam Hartman:
>> The question is whether we ever get to a place where people can update
>> files in a package currently installed to /bin/foo and instead install
>> them to /usr/bin/foo.
>> We have a consensus that dpkg bugs make that a bad idea.
>
> Is that really so? If I'm not mistaken, the problematic part was
> moving files from / to /usr and at the same time moving files between
> packages. So doing that at the same time can be problematic. If that
> would affect many packages is another question.
>
> AIUI simply moving files from / to /usr within the same package is not
> problematic.

Won't you then end up with a package which cannot be split for the next
two releases?  Maybe not a big problem, but I think it will be so hard
to keep track of that it's better to not move the files.


Bjørn

Re: Q: Use https for {deb,security}.debian.org by default

[Bjørn Mork]

Jeremy Stanley  writes:

> While this does complicate it, a snooping party can still know the
> site they're connecting to via SNI happening unencrypted,

I believe this can be fixed with TLS 1.3?

> and packet sizes/pacing likely give away which pages or files are
> being retrieved based on their length.

Yes, probably looking into territory where you'd not want to directly
access any public service at all here..

> And that's not even getting into
> how "trusted" certificate authorities give away certificates for any
> hostname if your MitM knows the right people,

Debian is among the few who publish TLSA records (DANE).  Which is still
pretty useless for normal web srvices since the major browser vendors
refuse to support it.  But TLSA validation could easily be implemented
in apt-transport-https. Maybe it is?  That would prevent this problem.

> and CDNs are now in
> the business of snooping on everyone's traffic for sites where they
> handle SSL/TLS termination. HTTPS as deployed on the open Internet
> is a sip of security with several gulps of theater.

Not much to do if you don't trust your own servers, whether they are CDN
frontends or whatever.



Bjørn

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Bjørn Mork]

Adam Borowski  writes:
> On Wed, Feb 10, 2021 at 12:21:36PM +, Holger Levsen wrote:
>> On Wed, Feb 10, 2021 at 01:05:04PM +0100, Bjørn Mork wrote:
>> > I happen to disagree.  To me this is yet another step away from being a
>> > proper Unix system - to something else.  Which would be fine if it moved
>> > us forward.
>> 
>> As it's 2021 and 99% of the Linux user base has no idea what UNIX (or Linux)
>> is, maybe it's time for a src:proper-unix-system package for those who care?
>
> Define "proper Unix"...

The definition depends on whether you are a longhair or shorthair.


Bjørn

Re: Proposal: plocate as standard for bookworm

[Bjørn Mork]

Marvin Renich  writes:
> * Steinar H. Gunderson  [210209 14:27]:
>> On Tue, Feb 09, 2021 at 08:53:10PM +0200, Adrian Bunk wrote:
>> > And there are now also many non-technical Linux users who have never
>> > used a shell.
>> 
>> Well, why do we include netcat, telnet or hdparm? lsof? pciutils?
>> traceroute? host? All of these are irrelevant for a non-technical
>> non-shell user, yet a fairly common part of a Linux installation.
>
> These have come to be expected to be on a typical Linux system by almost
> every technically-knowledgeable Linux user.  Locate does not satisfy
> that criterion, and I think the dissension in this thread is evidence of
> that.

This is subjective.  I don't think arguing about the expectations of
"every technically-knowledgeable Linux user" is going to bring the
discussion anywhere.

FWIW, locate was "always" there.  Before Linux and before PCI.
See https://en.wikipedia.org/wiki/Locate_(Unix).

> However, I agree with others here that anyone who wants a locate
> implementation will know how to find all the packages with "locate" in
> their names and plocate looks to me, from the descriptions, to be the
> best choice.  I don't think it deserves "Priority: standard".

I happen to disagree.  To me this is yet another step away from being a
proper Unix system - to something else.  Which would be fine if it moved
us forward.

But removing functionality can hardly be argued to be a move in the
forward direction?

Sure, I can install mlocate or plocate.  But it's the kind of tool you
expect to be present, with an uptodate database, when you need it.  The
database makes locate different from all the other tools you mention.

I also use Linux systems I don't admininstrate.  I'd hate to have to ask
the admin for every basic Unix tool I need.  Some of the standard tools
you mention are only relevant for admins.  Those don't need to be
standard.  But the ones that are relevant for users should be.


Bjørn

Re: Fixed release dates are hurting quality

[Bjørn Mork]

John Paul Adrian Glaubitz  writes:

> If the packages in question are essential, then these packages should get a 
> proper
> maintainer with a maintenance release first before the freeze kicks in.

How does that happen?


Bjørn

Re: Making Debian available

[Bjørn Mork]

There is no one proposing that non-free should be mandatory.

The original topic was whether it should be possible to install Debian
at all, noting that there are situations where this now is so difficult
that it will be percevied as "impossible" by some users.

I believe it is an undisputed fact that there are computers which need
non-free firmware to access the Internet.  There is most likely also a
group of potentional Debian users who would prefer to use WiFi for
installation even if they have other options.

Should computers/users with WiFi-only Internet access be supported by
Debian?

I'll assume the answer is yes. After all, Debian is "The universal
operating system". 

It has been documented in this thread it is possible to install Debian
on such systems.  But the images which allow this without additional
steps is well hidden. And the procedure supported the default images is
so complicated that even expert longtime Debian users have a hard time
using it.

The procedure would obviously be simpler if the firmware was included in
the default installation image.

I don't think there is any dispute so far?

So we have established an upside. The dispute seems to be about the
downside.

Is there one?

The firmware we are discussing is avaliable to every Debian user with
Internet access.  Whether it is in the installation image or not does
not change that.

Availabilty does not imply that the firmware must be used.  The
installer can still ask about using "additional non-free drivers" for
installation.  The difference is that the user will have an actual
choice.

As mentioned before, the use of non-free for the installed system does
not depend on this at all.  And IMHO, it should be left as an unrelated
question.  Even allowing temporary usage of non-free firmware to install
Debian on a system with only free software.

No choice is taken from the user.

What we are left with is users who are offended by the mere existence of
non-free binaries on a Debian image, and who see this as significantly
worse than the non-free firmware in their NIC, SSD, EC, CPU etc.  And
worse than the existence of the same firmware on the Internet, including
any Debian morror serving non-free.

These users, if any, could be served by a non-default Debian image
where the non-free firmware has been removed.

Does that downside even compare to the upside?  Are there any users who
are offended by the mere existence of a file in an installation image
they are free to avoid?

Did I miss something?

Debian is "The universal operating system".  The implications are clear
in my opinion.



Bjørn

Re: Making Debian available

[Bjørn Mork]

Steve McIntyre  writes:

> However, in the latter case Debian has shipped non-free stuff. That is
> a big shift in our position. Don't get me wrong: I'm not saying this
> is an impossible place for us to go to. But before we do that we
> should have an open and honest debate about it.

I absolutely 100% agree to that!


Bjørn

Re: Making Debian available

[Bjørn Mork]

Steve McIntyre  writes:

> Marc Haber wrote:
>>
>>I was not aware of that feature. It is good to have that, but I would
>>be embarrassed to seriously suggest this way because we can't manage
>>to get WLAN working in the installer for political reasons.
>
> Are we seriously just going to describe our Free Software goals as
> "political reasons"? Should we just abandon them?

FWIW, I did not read Marc that way.

Somehow, the Free Software goals have been interpreted to mean that
there is a difference in "free" between firmware on device internal
flash and firmware on host ssd.  This makes no sense from a technical
point of view.  Which makes the interpretation political if we assume
that the decision is made by otherwise sane people ignoring technical
arguments.

No one has described the Free Software goals as "political reasons".

Perosnally, I believe the current Debian handling of firmware works
against the Free Software goals.  That should worry those who care more
about those goals than the political reasons for disliking some types of
hardware.



Bjørn

Re: Making Debian available

[Bjørn Mork]

Marc Haber  writes:

> My workaround is to plug in a network cable for installation. But
> alas, I have up to now been able to avoid hardware without built-in
> Ethernet. I guess that many USB Ethernet interfaces will work out of
> the box without non-free, right?

Yes, even integrated LTE/5G modems could "work out of the box without
non-free", if the GPLd userspace tools were included with the installer.

This demonstrates how ridiculous the WiFi firmware restrictons are.  All
these USB devices work only because they come with firmware on a largish
flash.  In the LTE modem case, the firmware is a complete source-less
Linux installation with big binary-only blobs for the radio/signal
processors.

This is obviously not more "free" than downloading a firmware blob for
the processor in the WiFi module would be. I believe it's about time
Debian gets rid of the double standard.  Just admit that non-free
firmware is required to run Debian on any modern system.  Making it hard
to install Debian over WiFi does not change anything. It just makes it
hard to install Debian.


Bjørn

Re: debian names

[Bjørn Mork]

Jonas Smedegaard  writes:

> I would consider it highly unlikely that (Disney would claim and a court 
> would agree with them, that) Pixar customers could confuse some Pixar 
> products with a Debian release.

I believe Disney lawyers are world famous for their ability to construct
a legal problem from thin air.  Or maybe they don't even need air if it
is licensed?  Evil tongues have claimed that Carl Barks modelled
Sylvester J. Sharky after one or more Disney lawyer:
https://en.wikipedia.org/wiki/List_of_Donald_Duck_universe_characters#Lawyer_Sharky

In any case, the problem will be solved when Disney buys Debian.  That's
how The Simpsons finally got away with all their Disney jokes.

Or you might want to reference Don Rosas drawing of "the hardest,
toughest, most impervious substances known to mankind" at the bottom of
https://duck.neamar.fr/DUCK/the_universal_solvent



Bjørn

Re: Nitrokey for DDs

[Bjørn Mork]

Zlatan Todorić  writes:

> In that regard, if DDs find Nitrokey interesting, I have contact with
> their founder and we could negotiate discount(s) on their products and
> also pursue similar effect as with Peertube - we (potentially) get
> what some (all?) DDs need while we help them grow as independent open
> source vendor.

I'd like to add that they are offering free "Nitrokey Start" to kernel
developers, in co-operation with the Linux Foundation.  I assume there
is some overlap with DDs there. All you need to qualify is an email
address in MAINTAINERS.

See
https://www.linux.com/news/nitrokey-digital-tokens-linux-kernel-developers/
for more info.  


Bjørn

Re: RFC: Replacing vim-tiny with nano in essential packages

[Bjørn Mork]

"Theodore Y. Ts'o"  writes:

> I've always considered /bin/ed the most basic system administration
> tool, since it doesn't require a working terminal or termcap entry.
> It works even if you are using an ASR-33 teletype.  :-)
>
> And at least for me, I find /bin/ed much more user friendly than vi,
> since it doesn't have as modal of a UI as vi.  (Vi has 3 modes, ed has
> only 2.)
>
> /bin/ed is also *much* smaller than even busybox.

And of course, it *is* the standard text editor.

https://www.gnu.org/fun/jokes/ed-msg.en.html



Bjørn

Re: pager and upgrades

[Bjørn Mork]

Thomas Goirand  writes:

> without a pager installed.

Is that really possible?  AFAICS, /bin/more is part of util-linux which
is essential. So you will always have at least one pager installed.

But something might have messed up the alternatives symlinks.  Falling
back to /bin/more is better han failing completely in this case.



Bjørn

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bjørn Mork]

Robert Edmonds  writes:

> The entire DNS root zone is only 1 MB compressed and is updated about
> once a day. It would be even better for privacy if the whole root zone
> were distributed via HTTPS, as the initiator would not reveal to the
> server any information about what TLD is being looked up.

Running a local root instance is possible and easy.  See
https://tools.ietf.org/html/rfc7706


Bjørn

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Bjørn Mork]

Ondřej Surý  writes:

> On the privacy topic...
>
> Slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
> Paper: https://dl.acm.org/authorize.cfm?key=N687437

And also section 8 of
https://tools.ietf.org/html/draft-reid-doh-operator-00


> And you can get to the video recording from the ANRW 2019 pages: 
> https://irtf.org/anrw/2019/program.html
>
> We can discuss (and it has been discussed) ad nauseam, but the point
> is that nobody (certainly I am not) is asking for crippling DoH, but I
> just strongly believe it’s in the line with other Debian work that we
> should not send data to 3rd party DNS service without explicit user
> consent.

I agree, FWIW. User consent is required.

I for one, do trust my ISPs a lot more than I trust Cloudflare or
Google, simply based on the jurisdiction.

> Otherwise it doesn’t make any sense to remove external links to logos
>and JavaScript from the documentation and then send everything to one
>single US-based provider.

Exactly. I'd be worried if anything in Debian came preconfigured with
DNS servers of any kind.


Bjørn

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Bjørn Mork]

Bernd Zeimetz  writes:
> On 8/11/19 12:01 PM, Adam Borowski wrote:
>>   restart|force-reload)
>> log_daemon_msg "Restarting $DESC"
>> do_stop
>> sleep 1
>> do_start
>> log_end_msg $?
>> ;;
>> 
>> Yes, this particular case might fail on a pathologically loaded box or with a
>> very slow chip, but I don't know of a way to ask firmware if something is
>> still winding down, thus what we ship is probably still sanest.
>
> yes, for firmware this makes sense, but I've also seen various sysv
> scripts where people tried to guess the time a service needs to
> shutdown, so some random sleep was added instead of handling it in a
> sane way. This issues are luckily fixed forever with systemd - it just
> knows, whats going on.

LOL! Please try to be serious.

https://www.google.com/search?q=%22stop+job+is+running%22


Bjørn

Re: Apt-secure and upgrading to bullseye

[Bjørn Mork]

Julian Gilbey  writes:
> On Wed, Jul 10, 2019 at 12:31:51PM +0100, Julian Gilbey wrote:
>> Hooray, buster's released!  Congrats to all!
>> 
>> So I tried upgrading my machine to bullseye today, and
>> aptitude/apt-get update don't like this, giving me errors such as:
>> 
>> E: Repository 'http://ftp.uk.debian.org/debian testing InRelease' changed 
>> its 'Codename' value from 'buster' to 'bullseye'
>> N: This must be accepted explicitly before updates for this repository can 
>> be applied. See apt-secure(8) manpage for details.
>> 
>> So I read apt-secure(8), which gives no indication of how to "accept
>> this explicitly", and neither do any of the linked wiki pages.
>> 
>> Any suggestions?
>> 
>> (And obviously something needs changing so that people aren't stung
>> when bullseye is released.)
>
> Ah, turns out it's a known bug with aptitude.  The solution is to run
> "apt update", which interactively asks what to do with these changes.

If it's any comfort, I had the exact same problem.

It would be nice if the warning either pointed to the apt-get(8) man
page, where the solution can be found, or some hint was added to the
apt-secure(8) man page.

I found this section of the apt-secure(8) man page particularily
unhelpful:

  Since version 1.5 the user must therefore explicitly confirm changes
  to signal that the user is sufficiently prepared e.g. for the new
  major release of the distribution shipped in the repository (as
  e.g. indicated by the codename).


Those who cares which version this was added will read the changelog.
Those reading the man page are more likely looking for instructions, not
background info.


Bjørn

Re: Debian, so ugly and unwieldy!

[Bjørn Mork]

Adam Borowski  writes:

>   => Install gtk3-nocsd by default in all desktop tasks but Gnome.  It's not
>  perfect but it helps.

That's nice.  Thanks for the tip.  I enjoy nice tools like eog and
evince, but have always been annoyed by the missing window title and
associated window manager context menu.


Bjørn

Re: @debian.org mail

[Bjørn Mork]

Daniel Lange  writes:

> We have more people registered for DebConf ("the Debian Developers'
> conference") with @gmail.com than @debian.org addresses.

You can't fix @gmail.com.  It is deliberately broken for commercial
reasons, and that won't stop with SPF and DKIM.  Anti-spam is just the
current selling excuse for moving users to a closed, commercially
controlled, messaging service.

Document that @gmail.com doesn't work and ask anyone subscribed with
such an address to resubscribe using an Internet email service.

You might want to make a press announcement out of it, to prevent other
service providers from making the same mistake Google has made.



Bjørn

Re: usrmerge -- plan B?

[Bjørn Mork]

Marco d'Itri  writes:
> On Nov 26, Didier 'OdyX' Raboud  wrote:
>
>> Sorry to be blunt about this, but have you reported these? Sniping at (any) 
>
> No, they have not. There is a lot of handwaving in this thread but very 
> few results of actual tests.

"Migration is not (easily) reversible" was reported as important in
2016: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848626

It was immediately demoted to wishlist with this explanation:

"If and when the package will be automatically installed for some reason
 then a warning will be appropriate.
 usrmerge has extra priority, is not a dependency of anything and I am 
 not aware of anybody ever installing it by mistake."

The bug was later closed when a deconf question was added.

The fact that you redefined the topic of the bug does not mean that it
was solved. Your whining about missing bug reports on this subject is
simply arrogant.  Or ignorant.  Or both.


Bjørn

Re: Should tasks be considered harmful?

[Bjørn Mork]

Paul Wise <p...@debian.org> writes:
> On Mon, Dec 4, 2017 at 6:43 AM, Bjørn Mork wrote:
>
>> But how would a user without any previous knowledge of modemmanager or
>> Linux networking be able to figure this out?
>
> It sounds like you are looking for isenkram to be integrated into the
> installer so that the knowledge of which package maps to which
> hardware is available to the user when doing an install and for
> modemmanager to declare which devices it supports via AppStream and
> for installing modemmanager to pull in networkmanager and remove wicd:
>
> https://tracker.debian.org/pkg/isenkram
> http://people.skolelinux.org/pere/blog/tags/isenkram/
> https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware

No, not really.  I want the installation to end up with a *more*
predictable set of packages.  Attempting to do any sort of harware based
package selection will result in less predictability.  This is support
hell.  Imagine a Debian user trying to assist another Debian user.  If
you can't even establish a package set baseline, then where do you
start? 

No, I definitely don't want some magic guessing of what packages I need.
I want the default install to include a large enough set of packages
supporting as many use cases as reasonable.  If there are more than one
alternative package providing a given service, then the default should
be the one supporting most use cases.  At least if there is little or no
doubt. Which I believe covers the wicd vs NM case.

Hardware detection during installation will also fail for common use
cases like plugging in a USB modem after installation.  My example had a
built-in modem, but it could just as well be an external one.

And even if this example was related to hardware enablement, that is
only part of the problem.  Replacing any core system package with
something other users won't consider "default" is going to cause
confusion. I guess the definition of "core system package" is something
which can be discussed.  But it is a fact that all the DEs come with
their own set of system daemons, libraries and tools.  Take it to the
extreme and you end up with the kernel being the only shared package
between two different DE installations.

I just realized that this might appear as if I am opposing choice.  That
is not my intention.  What I am trying to say is that I found the
results of the task selection confusing, because it wasn't clear to me
that I was actually choosing a different Debian derivative by selecting
one of the desktop tasks.  If you are going to continue to provide these
variants, then it would have been better (for me at least) if every task
was packaged as a separate installer image.

This would also reduce the number of necessary questions during install.


Bjørn

Should tasks be considered harmful?

[Bjørn Mork]

tl;dr: Desktop tasks have unexpected (from the user point of view) side
effects due to dependencies. This can be considered harmful since the
installer task selection can easily can trick a user into installing a
"substandard" system.

Yesterday I did something I rarely do: I installed Debian from scratch
on a laptop.  This is not something I do a lot, simply because there is
no reason with the excellent upgrade support Debian has. Even when I
occasionally change hardware, I usually migrate as much configuration as
possible - including the list of installed packages.

I must admit that I had very high expectations based on my previous
experience with Debian. I expected a smooth install ending up with a
system where everything just worked.  And it was close. But not quite.
And the failure was so unnecessary, and potentionally so difficult to
figure out for new users, that I think it is worth considering as a much
larger problem than a simple installation bug.

This old laptop had a built-in 3G modem (an Ericsson F3507g - not that
it matters), which I "knew" would work fine in Debian. Aleksander, Dan
and all the contributors have done a very nice job with ModemManager.
But the modem did not work. Because ModemManager wasn't installed at
all!  How did that happen?

I had briefly looked at desktop task choices during installation, and
not being too fond of any of the DEs, I arbitrarily selected LXDE.
Figured it couldn't hurt having a lightweight DE on an almost 10 year
old laptop.  What I missed completely was that the lxde package, which
obviously is a dependency of task-lxde-desktop, has this in its
recommends:

 wicd | network-manager-gnome

So it drags in wicd instead of network-manager-gnome.  Which I can
perfectly understand from a lightweight point of view.  But the problem
is that these two packages don't support the same features, and
'lightweight' isn't a good selection criteria during installation. In a
perfect world, the installer could have had sufficient information about
the hardware and the users wishes to make this choice. But it has
not. So it should install the options which are most likely to work for
all users.  Which is clearly network-manager in this case.  Replacing
wicd with network-manager-gnome, which drags in network-manager and
modemmanger, fixed my modem issue.

But how would a user without any previous knowledge of modemmanager or
Linux networking be able to figure this out? As a new user, would you
even dare to rip out the core network tool which was installed by
default, to replace it with something else?  I don't think so.  Many
users would be stuck with a non-working 3G modem and not being able to
fix it.  Which I find terribly sad, knowing the hard work put into
making ModemManager work as well as it does.

Now, of anyone is still reading, you are probably wondering why I didn't
just open a bug instead of writing this long story here. Well, AFAICS
there is no bug.

There is nothing wrong with the installer.  It just did what I asked it
to, since I selected this specific task.  I don't think it is reasonable
to expect the installer to do any dependency validation or overrides.
That would be crazy.  T

There is also nothing wrong with the task-lxde-desktop.  It depends of
lxde, which it obviously must do.

I don't think there is anything wrong with lxde either.  Recommending
wicd is fine with me.  It's just not suitable for everyone, and
therefore unsuitable as an installation default.  But that should not be
a concern for lxde.

And there is certainly nothing wrong with wicd.  It serves its purpose,
and does it well. A limited feature set is a perfectly valid design
choice.

So the installation end result is bad, but every package and subsystem
does exactly what they are supposed to do. It is the overall system
design that fails.  Which is why I think this is more of a policy
question than a bug.  Thinking on how I went wrong, I have come to the
conclusion that I would have been much better off if there were no
desktop task choice at all.  If I just got Gnome or whatever would be
the default.  Then I would also get the one and only "default set of
Debian packages", without any unexpected replacements.  I would of
course still be free to change the default desktop selection after
installation, as well as anything else.  But then I would have had a
much better opportunity to see the consequences, if dependencies caused
important system packages to be replaced.

IMHO the task selection during installation is harmful. Unpredictable
(from user point of view) results cannot be avoided, since any
additional package selected during installation will modify the resolved
set of dependencies.

I believe there was a similar problem related to automatic package
selection based on detected network environment during install.  This
has been resolved.  But the underlying issue is still there: If you
allow the installer to select or deselect *any* package during
installation, then it is very 

Re: Help, I broke sso.debian.org for chrome - Found reason

[Bjørn Mork]

Enrico Zini  writes:

> On Tue, Sep 05, 2017 at 11:37:01AM +0200, Enrico Zini wrote:
>
>> I refactored the certificate generation code for sso.debian.org, and the
>> certificates it generates now still work in Firefox but not in Chrome.
>
> I found the reason: python-cryptography writes the certificate issuer
> as UTF8 String while the CA certificate has it as Printable String.
> Because of that, the subject names don't match bit-by-bit.
>
> For openssl, encoding does not matter for comparison, while for libnss3
> it does.
>
> I do not know if this is:
>
>  - a bug in openssl, which should be stricter in matching
>  - a bug in libnss3, which should deal with encodings
>  - a bug in python3-cryptography, which should do a bit-for-bit copy
>when copying attributes over:
>
> https://anonscm.debian.org/cgit/debian-sso/debian-sso.git/tree/ca/ca.py#n429

Disclaimer:  I don't know the first thing about this...

But reading

 https://tools.ietf.org/html/rfc5280#section-4.1.2.4
 https://tools.ietf.org/html/rfc5280#section-7.1

and

 https://tools.ietf.org/html/rfc4518#section-2

which the first refers to, I believe this must be a libnss3 bug.

PrintableString and UTF8String are both allowed encodings, and RFC5280
is pretty clear about name comparisons:

   Conforming implementations MUST use the LDAP StringPrep profile
   (including insignificant space handling), as specified in [RFC4518],
   as the basis for comparison of distinguished name attributes encoded
   in either PrintableString or UTF8String.  Conforming implementations
   MUST support name comparisons using caseIgnoreMatch.  Support for
   attribute types that use other equality matching rules is optional.




Bjørn

Re: Call for volunteers: FTP Team

[Bjørn Mork]

Abou Al Montacir  writes:
> On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote:
> ...
>> > If someone hypothetically joins, are they allowed to rename the FTP team
>> > 
>> > to something that doesn't include "FTP"?
>> 
>> Archive Team. Or the A-Team for short. The only Debian team with a theme 
>> song.
> Why Archive, maybe Queue is more accurate (Q-Team), isn't it?

An invitation to join the Q Continuum might be more attractive.



Bjørn

Re: Naming of network devices - how to improve it in buster

[Bjørn Mork]

Guus Sliepen  writes:

> Ok, it should be clear now that the new way of naming interfaces is not
> ideal, but the older ways weren't either. Let's have a look at what we
> want:
>
> - A simple name for systems with a single Ethernet and/or Wireless
>   interface (the simple desktop/laptop scenario).
> - A consistent naming scheme for interfaces in a system with multiple Ethernet
>   interfaces (the server scenario).
> - Not having interface names change after reboots.

I got to ask: Why?  We do not have stable names for e.g. disks.  Why do
we need it for network devices?

Yes, yes, I know you can screw up your system by configuring a dynamic
device name in /etc/network/interfaces.  But I believe you should be
allowed to.  Just like you can screw up your system by referring to a
dynamic block device name in /etc/fstab.

Leave the kernel network device names alone.  Let them be dynamic.  Just
document that fact.

"stable device name" is not the problem. The problem is associating
configuration with the correct physical device.  Note that this is not
an issue at all until you add some static network configuration. Which
makes it a non-issue for most end user systems, regardless of the number
or type of of network devices.

For static network configurations on systems with multiple interfaces,
the correct and only logical place for the device association is with
the rest of the network configuration. If you use NetworkManager, then
it is up to NetworkManager to match it with a specific network device -
if required.  The rest of the system does not need to care.

The remaining problem is to make ifupdown do device matching on other
(and hopefully more stable) attributes than the device name.



Bjørn

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Bjørn Mork]

Samuel Thibault  writes:
> Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote:
>
>> Other major distributions are using this new scheme (notably Ubuntu
>> which has no reason to have users smarter than ours)
>
> The reasoning is the converse: non-techy users will just not be exposed
> to interface names anyway. Debian users, however, tend to be more techy,
> and do see these interface names. And basically *all* documentation
> before this interface name change is now incomprehensible to techy
> beginners.

Not only old docs, unfortunately.  The change makes it impossible to
describe system independent procedures involving a network device.

As an example, I happen to get a few questions regarding LTE modem
configuration.  Most of these users will have a single modem, so I know
the kernel network interface name is 'wwan0'.  Previously I could ask a
user to do e.g. 'ifconfig wwan0'.  Now?  Depending on how "techy" the
user is, I may have to write more about netdev naming policies than the
real issue.

This isn't something I just made up.  It is a real problem for me.  And
I only see a fraction of the problem.  I can imagine the issues for
those attempting to write any docs touching Linux networking..

> I'm really worried here: this change, like a lot others done recently,
> is making the Linux ecosystem yet more complex to understand, thus
> raising the barrier for techy beginners yet higher.

Yes.  And what is most worrying is all the excuses made, often claiming
the opposite.

We are all going to laugh at enp0s31f6.  But it looks like we are
looking at a couple of years of breakage first, before the advocates
move on to some other shiny project where they can solve a problem that
didn't exist before they entered the scene.


Bjørn

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Bjørn Mork]

m...@linux.it (Marco d'Itri) writes:
> On Jul 10, Adam Borowski  wrote:
>
>> Predictability is important, thus let's actually have _predictable_
>> interface names.  The kernel default, eth0 and wlan0, is good enough for
>> most users, why not keep that?  Even just ignoring the issue completely
> Because you cannot know how many interfaces a system has until all of 
> them will have appeared.

Just like you cannot know how many PCI buses a system has until all of
them have appeared.  But depending on the faulty assumption that PCI bus
numbers are static is apparently good enough for most users?

Yes, it *is* definitely a dead horse your are beating here. There is no
such thing as predictable network names.  Continuing to pretend
otherwise will not move this discussion forward.


Bjørn

Re: systemd, ntp, kernel and hwclock

[Bjørn Mork]

Adam Borowski  writes:

> On Tue, Feb 28, 2017 at 10:15:23AM +0100, Daniel Pocock wrote:
>> > But ntpd is also known to have a large amount of code written
>> > without as much regard for security as one would hope.  It seems
>> > like an unnecessary risk for most systems.
>> 
>> 
>> Thanks for that security tip, I'm tempted to get rid of some ntpd
>> instances now
>
> You'd be interested in NTPsec (https://www.ntpsec.org/) then, which is a
> project to review and sanitize ntpd without downsides prevalent in most
> replacements (such as same-week accuracy or no managing clock drift).
>
> Sadly, it's not a part of stretch or even unstable yet:
> https://bugs.debian.org/819806

I don't think there are enough people caring about ntp in Debian (or the
world) to maintain two code bases.  And the fork is still young and not
"obviously better" or "clearly the one true path forward".

See also https://lwn.net/Articles/713901/ for more background
information.

IMHO, it's very unfortunate that this fork was created, and I cannot see
anything good coming out of it.  It's just wasting developer resources
which could have been used to improve ntp.


Bjørn

Re: Bug#846002: Debian Installer Stretch RC 1 release

[Bjørn Mork]

Andreas Tille  writes:

>> Since this is still an open discussion in #846002, I would have
>> preferred if you would not try to force your own preference here before
>> the CTTE made its decision.
>
> While I'm not sure whether its a personal preference or whether some
> discussion I might have missed has lead to this result but I'm similar
> astonished as Ole about this result without a final decision of the
> CTTE.

If I can offer an view from the outside of this discussion:

To me it looks like a sandbox fight which started with the creative use
of "Priority: important". Now it appears that the party starting the
fight thinks the other party should stop throwing sand until "mommy"
(aka CTTE) decides who is right and who is wrong.

I have of course probably gotten all this wrong.  But that doesn't
really matter.  The above describes how *I* subjectively perceive the
situation.  That is not a subject for discussion.

My personal advice, since I'm out here providing opionions nobody asked
for anyway, would be to start co-operating with the tasksel/installer
developers instead of waiting for a CTTE decision.  That's not going to
solve your issues anyway.

Because, as has been pointed out by several people already: This whole
mess was pointless from the start. No new Debian user will ever
understand the meaning of the task menu.  And no experienced Debian user
will use it.  Adding anything there is futile.  You need to get into a
dialogue with the installer developers so that you can find a way to
properly integrate blends.  And possibly remove tasks.

This is of course way too late for Stretch.  Live with it. Or continue
wasting everybodys time on pointless discussions and be too late for the
next release as well


Bjørn

Re: Can we kill net-tools, please?

[Bjørn Mork]

Russell Stuart  writes:
> On Thu, 2016-12-29 at 11:38 -0800, Russ Allbery wrote:
>> It certainly doesn't provide a man page that doesn't start with a BNF
>> syntax description.  The iproute2 documentation is awful.
>> 
>> Also, this is not at all easy to parse:
>>
>> # ip -o address
>> 1: loinet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft 
>> forever
>
> All true.  In particular the documentation produced by kernel's
> networking group is a pet hobby horse of mine.

It's a collaborative project open for anyone with the slightest
interest in it. Sure it can need improvements.  But complaining doesn't
really work.  Fix it instead :)

FWIW, I find it much harder to document a new feature than implementing
it. And I believe many others feel the same.  Any help improving the
docs is greatly appreciated.  New networking features often have a
narrow target and are added by a person knowing the specific area pretty
well, but not necessarily everything else...  Writing good docs in this
context is difficult because your point of view is so different from the
readers.

> To me this thread looks like a bunch of old men grumbling that the
> young'ins have taken over what they created and turned the tools they
> were comfortable with into something unrecognisable.  It's true - they
> did do that, and it's true it was unnecessary. 

Note that the reason there are two sets of tools is exactly because they
*didn't* turn the existing tools into something unrecognisable.  The
existing tools were left alone when the kernel API went from ioctls to
netlink.

But I see no point in the subject of this discussion.  Leave net-tools
as they are for anyone used to them.  "Priority: important" seems wrong,
though.


Bjørn

Re: Can we kill net-tools, please?

[Bjørn Mork]

Russ Allbery  writes:
> Christian Seiler  writes:
>> On 12/29/2016 08:38 PM, Russ Allbery wrote:
>
>>> ip address also has one of the worst output UI decisions I've ever seen,
>>> namely this line:
>>> 
>>> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
>>> 
>>> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
>>> command,
>
>> Nope, that's RFC 4632, Section 3.1, where that was introduced
>> first, see
>> https://tools.ietf.org/html/rfc4632#section-3.1
>
> No, I'm not talking about CIDR notation, which of course is long-standing
> and familiar.  I'm talking about randomly appending a CIDR suffix to
> something that is obviously *not* the base for that CIDR block.
>
> In other words, 192.168.0.0/24 is fine.  The problem is with deciding to
> merge two completely different things (a CIDR network specification, and
> an individual IP address) in this weird hybrid notation that, by RFC 4632,
> would mean the network starting at 192.168.0.195 and extending for a /24.
> Which is a nonsensical specification.

I believe that is a mis-interpretation of that RFC.  The examples are
all network addresses, but I don't think there is anything there that
restricts the CIDR notation only to that class of IPv4 addresses.

FWIW, the notation is much older and has been used for IPv4 address +
mask long before that RFC or the introduction of the "ip" tool.  I am
unable to find the original first use, but here's at least one older
reference (from 1998):
https://tools.ietf.org/html/rfc2373#section-2.3

  "The text representation of IPv6 address prefixes is similar to the
   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
   address prefix is represented by the notation:

  ipv6-address/prefix-length
  "


The IPv4 CIDR notation was obviously already well enough known to be
used to explain the new IPv6 notation. I believe the above paragraph
would be very confusing, to the point of not making sense at all, if the
IPv4 notation was known to be used only for network address +
prefix-length.


> IIRC, this was done in ip to "save space" instead of using the natural
> expression, namely:
>
> 192.168.0.195 net 192.168.0.0/24


"save space" by removing redundant information was pretty much the only
reason to introduce the prefix-length, wasn't it?  Well, maybe not... It
also prevents anyone from trying to configure a netmask with holes in
it.

But if you always had to include the redundant network address, then you
wouldn't save any space.  What would the point of the CIDR notation be
then?  You might as well use one of the mask notations:
 
 192.168.0.195 0.0.0.255
 192.168.0.195 255.255.255.0

They are just as short (and commonly used, just like 192.168.0.195/24 is)

> Saving space in UI output intended for humans by introducing new notation
> is almost never a good idea.

True.  But in this case it makes the result easier to read by removing
duplicate information.  That is good.


Bjørn

Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

[Bjørn Mork]

Emilio Pozuelo Monfort  writes:
> On 09/07/16 22:31, Franciscarlos Santos Soares wrote:
>> Hi Emilio!
>> 
>> Thank you for contacting us. In fact, like independent application of any 
>> DE, 
>> but they were compatible with the traditional look of windows and based on 
>> the 
>> GTK library. So would provide a good working environment in the old 
>> computers 
>> that read daily in public schools that work.
>
> I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/,
> which makes things clearer. This seems to be a cross-desktop (Mate, 
> Cinnamon...
> XFCE?) project to provide some core apps. Which we wouldn't end up with 
> multiple
> forks of the same stuff, and that addresses my concerns.

That's the forking version of https://xkcd.com/927/ , isn't it?


Bjørn

Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]

[Bjørn Mork]

Tom H  writes:

> systemd isn't the first package to allow/promote shipping distro
> settings in "/lib" or "/usr/lib" and overriding them via "/etc"; udev
> and polkit/policykit have behaved like this for a long time. There's
> also "/usr/lib/sysctl.d/" where a distro ship settings that can be
> overridden via "/etc/sysctl.d/".

"/usr/lib/sysctl.d/" is systemd specific.  Dropping files there won't do
anything unless you run the  systemd-sysctl service.

"/etc/sysctl.d/" used to be owned by procps, and will still be used by
/etc/init.d/procps whether or not you run systemd-sysctl.

I don't think anyone wants another systemd thread, so I suggest you all
keep the systemd examples to a minimum.  It's a bloody mess.


Bjørn

Re: Putting default config files in /usr [was; (newbie) Disruptive LIRC package update.]

[Bjørn Mork]

Bjørn Mork <bj...@mork.no> writes:

> "/usr/lib/sysctl.d/" is systemd specific.  Dropping files there won't do
> anything unless you run the  systemd-sysctl service.

Sorry, should have researched this better first.  sysctl WILL use
"/usr/lib/sysctl.d/" if it exists.  procps won't create it, but it is
supported.

I'll keep quiet for a while now...


Bjørn

Re: Bug#777643: general: possibly, some keyboard layouts should use U+22C5 DOT OPERATOR instead of U+00B7 MIDDLE DOT

[Bjørn Mork]

Nikolaus Rath nikol...@rath.org writes:

 How dare you write ... instead of the proper … :-P

 I'm curious, how do you type that in conviently? I hope it's not copying
 and pasting from a template file, and remembering (and/or finding out)
 the X11 Compose sequence seems cumbersome too.

I see that you have got a number of methods, but just wanted to note
that … is simply AltGr + . on my default Norwegian keyboard layout.

That's only a Shift away from the middle dot BTW, to keep this on
topic :-)


Bjørn


-- 
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/87fvaa880h@nemi.mork.no

Re: DE features dependent on Systemd

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:

 We don’t support non-logind configurations.

You might not.  AFAICS, Debian does.

 We support non-systemd-as-pid-1 configurations, but they still run
 logind through systemd-shim. 

systemd-shim is not essential.  You can still install jessie without
systemd, and hence without running logind.


Bjørn


-- 
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/87lhmooqkj@nemi.mork.no

Re: DE features dependent on Systemd

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:
 Bjørn Mork bj...@mork.no wrote: 
  We support non-systemd-as-pid-1 configurations, but they still run
  logind through systemd-shim. 
 
 systemd-shim is not essential.  You can still install jessie without
 systemd, and hence without running logind.

 This is completely off-topic.

Yes, but you should expect being corrected when your off-topic posts are
wrong.

 We are talking about the anti-feature of adding UID=1000 to the audio
 group in the installer.

Are we?  I was talking about making audio work for the first-user.  I
see that as a feature.  So we disagree.  That's fine.  Can we discuss
facts instead of opinions?

 This is only relevant for desktop installations,

That's narrow minded.

Audio does work and is relevant for non-desktop installations. Making
audio support depend on some DE is definitely a regression.



Bjørn


-- 
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/87h9xcolih@nemi.mork.no

Re: Using USB serial device with a cdc-acm driver

[Bjørn Mork]

Dmitriy Fitisov dmit...@radier.ca writes:

 we have a small device of our own, which communicates through serial USB on 
 Windows.
 Now we need it to work on Raspberry (yes, I know this is Debian, which is 
 Raspberry based on).
 USB descriptors configured as a modem, so, when I connect it to Linux, 
 cdc-acm module is loaded.
 However, there is apparently some process which is watching modems, so on 
 connection
 I got some info on my device - on Ubuntu it is AT commands, for which I have 
 adapted firmware
 (seems ModemManager is running), but on Raspberry I cannot find out what 
 process attaches 
 to my modem and what it wants.

lsof /dev/ttyACM0


Bjørn


--
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/874mtesbmk@nemi.mork.no

Re: enforced systemd services

[Bjørn Mork]

Marc Haber mh+debian-de...@zugschlus.de writes:

 Indeed. Do we really have to pull that from a video or presentation
 slides? Is this part of the official systemd docs anywhere?

I don't know of any collection of all security related directives, but
you can find an index of all unit file directives in
systemd.directives(7) with pointers to the man pages where they are
described further. If anyone ever doubted that systemd is bloated with
far too many features, then I do recommend reading systemd.directives(7)
;-)

You'll find the Private* and Protect* directives described in
systemd.exec(5) for a start.

Container services are of course nice features to have, and it is so
elegant to just configure them with a few keywords in a configuration
file. But this mix-it-all-together design does not come for free...


Bjørn


--
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/878uiz8rgg@nemi.mork.no

Re: Being part of a community and behaving

[Bjørn Mork]

m...@linux.it (Marco d'Itri) writes:

 On Nov 17, Steve Langasek vor...@debian.org wrote:

  This is what many still (retorically) wonder about: we the systemd 
  maintainers did not reject that change,
   https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;bug=746578
 Please try to be less selective in your quoting: the issue was still 
 being discussed.

I see.  So any systemd bug with a 'wontfix' tag is still considered open
for discussion?  That's good to know.  Thanks.


Bjørn


--
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/87bno6f8h2@nemi.mork.no

Re: Being part of a community and behaving

[Bjørn Mork]

Brian May br...@microcomaustralia.com.au writes:
 On 14 November 2014 04:20, Carlos Alberto Lopez Perez clo...@igalia.com
 wrote:

 The last one that I read is that udev is going to stop working on
 non-systemd systems:

 http://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html


 I don't read anything in that post that says this.

 Am guessing you a referring to the Also note that at that point we intend
 to move udev onto kdbus as transport, and get rid of the
 userspace-to-userspace netlink-based tranport udev used so far quote.

 Which would suggest that udev might stop supporting the
 userspace-to-userspace netlink-based transport in the future. However,
 unless I am mistaken, I don't think this means it will no longer work on
 non-systemd systems.

The next sentence after the one you quote is: Unless the systemd-haters
prepare another kdbus userspace until then this will effectively also
mean that we will not support non-systemd systems with udev anymore
starting at that point.


Bjørn


--
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/87bnoagd0c@nemi.mork.no

Re: systemd - some more considerations

[Bjørn Mork]

Tollef Fog Heen tfh...@err.no writes:
 ]] Norbert Preining 

  systemd needs cgroups, that's pretty well established.  Arguably, it
  should die with a clearer message.
 
 No, NO  NOO
 
 *IT*SHOULD*NOT*DIE*!!! It is in PID 1. Please digest that.

 Am I understanding you correctly that you don't think there are any
 situations where compiling out features from the kernel can lead to pid1
 not working would be acceptable?

The main problem is how you resolve the not working.  Dying will never
a sane way to give up from pid 1.  Try exec'ing something else instead,
like a shell or a stripped down init not needing all those optional
kernel fatures.

And wrt the question about required kernel feaures: Why should the
systemd pid1 require more features than other init systems?  I have been
told before when complaining about putting additional complexity into
pid1 that this isn't true - that systemd really doesn't add dependencies
to pid1 compared to alternative init systems.  This doesn't seem to be
completely true.


Bjørn


--
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/877g768yhm@nemi.mork.no

Re: pulseaudio related problems....

[Bjørn Mork]

John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de writes:
 On 02/17/2014 01:37 PM, Norbert Preining wrote:
 Why can you not simply say something like: Well yes, there seem
 to be some problems and we will try to fix them if we can get hold
 of enough input. You DDs should be able to provide decent information
 to help track the problems down.

 Then why on earth aren't those people who are affected providing some
 more information?

 This is exactly what I was talking about: If your solution is
 unstalling an affected package, then you're obviously not
 interested in fixing it in the first place.

 If you want me to help you with your problem, you need to provide
 something I can work on. Just claiming it doesn't work isn't helping
 in this situation, I don't have a crystal ball I can consult in this
 case.

The goal of most users will be have sound, not install pulseaudio.
This defines both the problem and the solution, from the users
perspective.

A package which appear to be non-functional at install time is not
likely to receive any bug reports at all.  Feel free to whine about
that.


Bjørn


-- 
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/87k3ctc08e@nemi.mork.no

Re: systemd - getting started?

[Bjørn Mork]

Iain R. Learmonth i...@fsfe.org writes:

 Things I'd like to see are:

  * A systemd primer (like what is a service file?)
  * Packaging documentation for systemd (some has been started [1])
  * How to hack together a service (this is something I did quite a lot
 for homebrew scripts on servers)

 There are probably other things that others would like to see too.

 I can see a lot of enthusiastic systemd supporters on the list,

I'm not quite sure I qualify as one :)

But I'd still like to recommend Neil Brown's excellent article series on
LWN:
 http://lwn.net/Articles/584175/
 http://lwn.net/Articles/584176/

You'll have to subscribe to read those now (or wait).  But I assume the
Debian developers group subscription still applies? Ref
http://lwn.net/Articles/13797/

I'm not a DD, so I cannot verify that...  Anyway, LWN is certainly worth
paying for, even if you're not going to use systemd :-)




Bjørn


--
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/87txc448it@nemi.mork.no

Re: removal of the vacation package

[Bjørn Mork]

Ansgar Burchardt ans...@debian.org writes:
 Bjørn Mork bj...@mork.no writes:

 Care to provide a pointer to an example?

 RFC 5230, sections 4.2, 4.5, 4.6 and 8.

Thanks for the pointer.  Are there any implementations of RFC 5230 in
Debian?

Both apt-cache search 5230 and apt-cache search sieve vacation only
return libnet-sieve-script-perl, which is more of a toolbox than an
actual sieve enabled MDA.



Bjørn


--
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/87k3e15r1w@nemi.mork.no

Re: removal of the vacation package

[Bjørn Mork]

Ansgar Burchardt ans...@debian.org writes:
 Bjørn Mork bj...@mork.no writes:
 Is there such a beast with feature parity?  vacation has a few nice
 defaults, like ignoring list mails and only sending one message per week
 to each receiver.  Having every end user implement similar behaviour in
 sieve isn't likely to happen.

 The world has become a lot more stupid since vacation was written

 The statement in the second paragraph is false.

OK, then I got the wrong impression from the number of out of office
messages I see on public mailing lists.

 This also answers the first paragraph.

Care to provide a pointer to an example?


Bjørn


--
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/87ioto9s1p@nemi.mork.no

Re: removal of the vacation package

[Bjørn Mork]

m...@linux.it (Marco d'Itri) writes:
 On Jan 12, Stefano Zacchiroli z...@debian.org wrote:

 It still seems to have a fair number of loyal users though. I see your
 popcon says 1867 have it installed, but only 222 voted.

 If we do have such a
 replacement (I just don't know) please mention it in the removal bug
 report.
 I agree with waldi that the most simple replacement is a Sieve-enabled 
 LDA.  

Is there such a beast with feature parity?  vacation has a few nice
defaults, like ignoring list mails and only sending one message per week
to each receiver.  Having every end user implement similar behaviour in
sieve isn't likely to happen.

The world has become a lot more stupid since vacation was written

 On Jan 12, Ian Jackson ijack...@chiark.greenend.org.uk wrote:

 I might want to adopt it.  What's wrong with it not supporting
 MIME ?  AFAIAA it doesn't need to do much parsing of the incoming
 messages.
 As the last bug shows, it is supposed to parse the Subject header.

This doesn't look like a MIME bug to me.  It looks like vacation
truncates multiline subjects.  There is absolutely no reason it should
try to parse any MIME.

And the truncation doesn't really matter for most use cases (returning a
static message). IMHO this could just be documented and tagged as
wontfix if you wanted to.


 The set of bugs looks tractable to me.  Do you have a half-prepared
 upload somewhere or is the versionn in the archive the most recent ?
 No, I have really ignored it since december 2003.
 If you want it, it's yours.

Good to see that there are developers interested in keeping it alive.


Bjørn


--
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/87vbxoao4p@nemi.mork.no

Re: overriding udev rules

[Bjørn Mork]

Uoti Urpala uoti.urp...@pp1.inet.fi writes:
 Russ Allbery wrote:
Kay Sievers k...@vrfy.org writes:
  Hmm, why would upgrades break?
 
  The old file would still be there, rename the devices (if you keep the
  patch to swap names, which upstream does not support any more), and take
  precedence over tht new names; the old rules file would just not be
  updated anymore when new devices appear.
 
 Manually-deployed /etc/network/interfaces files that assume a specific
 device naming come to mind.  We have tons of those at work.

 Why would those break? Just having a manually-deployed
 /etc/network/interfaces file that uses names like eth0 should not
 break upgrades, because as mentioned in the part you quoted, the
 existing already-generated rules should still trigger and keep renaming
 the same card to eth0. So you need to assume something more to have an
 example of a problem case.

Things will break because the new scheme changes interface names which
never have been added to the generated rules.

As just one example, these names have been in use at some point in time
on my laptop:

bjorn@nemi:~$ egrep ^iface /etc/network/interfaces
iface lo inet loopback
iface eth0 inet manual
iface wlan0 inet manual
iface default inet dhcp
iface mbm0 inet dhcp
iface mb0 inet dhcp
iface wwan0 inet dhcp
iface wwan1 inet dhcp
iface test inet dhcp
iface debug inet dhcp
iface mob inet dhcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp


Only two of them have persistent entries and can be expected to continue
working: 

bjorn@nemi:~$ grep NAME /etc/udev/rules.d/70-persistent-net.rules 
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, 
ATTR{address}==00:21:86:a3:25:7d, ATTR{type}==1, KERNEL==eth*, NAME=eth0
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, 
ATTR{address}==0c:8b:fd:08:09:71, ATTR{dev_id}==0x0, ATTR{type}==1, 
KERNEL==wlan*, NAME=wlan0


I'm not claiming that I use all those entries, and some of them were
added due to breakage caused by the existing scheme.  But this doesn't
change the fact that converting to the new scheme will cause additional
breakage, e.g. by renaming my internal wwanX devices to wwsomething.

I'll leave up to others to decide whether such breakage is acceptable or
not.


Bjørn


--
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/87ob81t0u0@nemi.mork.no

Re: overriding udev rules

[Bjørn Mork]

Michael Biebl bi...@debian.org writes:

 The persistent network interface naming rules are already skipped if
 udev is run within a virtual machine.

Which made me look closer at
/lib/udev/rules.d/75-persistent-net-generator.rules 

I find it a bit strange that it has lots of logic involving different
OUIs, but doesn't seem to care at all about the addr_assign_type sysfs
attribute.  I believe you never should generate any persistent rules if
this attribute is different from 0 (NET_ADDR_PERM).

And I'll now go fix some drivers which doesn't set it as appropriate.



Bjørn


--
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/87ioyy3r6q@nemi.mork.no

Re: Survey answers part 1: systemd has too many dependencies, …

[Bjørn Mork]

Michael Stapelberg stapelb...@debian.org writes:

 since some people might not read planet debian, here is a link to my
 first blog post in a series of posts dealing with the results of the
 Debian systemd survey:

 http://people.debian.org/~stapelberg/2013/06/09/systemd-bloat.html

I was hoping you would cover my reason why I fear the too many
dependencies:

external dependencies obfuscates what code is part of pid 1 and what is
not.  Some (most?) of the external projects you depend on are probably
not developed with this use case in mind, and hence are not suitable for
being used like this.  This is not a critisism of the externel
libraries. There is quite a difference between writing code which can
exit and writing code which cannot.  No sane person will attempt to do
the latter unless strictly required.

You claim that the systemd code using these dependencies is simple, and
I have no reason do doubt that.  But you ignore the fact that you make
the external code part of systemd.  That code also needs to be audited
as if it were an integral part of systemd.  You could just write a
libpid1 and a 5 line application using that library.  It should be
obvious that auditing the 5 line application would be unsufficient.

The point is that it is not obvious that all these external dependencies
are suited for use by systemd, and that the responsibility for ensuring
that they are lies with the systemd project.  Not with the external
projects.

I understand that there are lots of developers having a hard time
understanding that there is a difference between
 - desktop application depending on libfoo, and
 - criticial (securitywise, stabilitywise, other) application depending
   on libfoo

You do of course not have to agree.  This is my personal opinion only.
But I believe it is useful to read Jamie Zawinski's view on screensavers
and toolkit library dependencies, and try to figure out how that can be
relevant to systemd and external dependencies:
http://www.jwz.org/xscreensaver/toolkits.html

Using a library in a critical application will make any harmless library
bug into a critical bug.  Are the maintainters of those dependencies
really ready to handle that?

This is the primary reason why the list of dependencies terrifies me.
Not any of the four reasons you list, which, although valid, are only
minor issues which could be outweighed by advantages offered by the
dependency.



Bjørn


--
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/87zjuzwrb9@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Jean-Christophe Dubacq jcduba...@free.fr writes:

 And in my experience, email tends to be much more fragile than dbus.

The warm fuzzy feeling you get when you don't know there is a
problem... 

 How many times have I suddenly looked
 at the queue of a computer that has been mis-configured and that
 accumulated thousands of email from its system trying to repeatedly warn
 the user that, well, the email smarthost cannot be contacted?

Yes, and dbus would have just dropped the messages that couldn't be
delivered instead of queueing them.


Bjørn


--
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/8761xzlg2n@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Ben Hutchings b...@decadent.org.uk writes:
 On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote:
 On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote:
  Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a
  écrit : 
   Take for example, smartmoontools [1]. Currently, if an end-user
   installs smartmoontools and a hard-disk fails (i.e. smartd detects a
   problem with one HD) he will *not* see any notification: the failure
   is sent through local e-mail.
  
  He will see a notification on his desktop. Clear, understandable and
  translated in his configured language:
  https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c
  (The code is different but already here in squeeze and wheezy.)
 
 What you propose requires:
 * adding desktop environment specific code to every facility that may need
   to send notifications
 * adding such notifications to every other desktop environment

 Wrong, we already have org.freedesktop.Notifications in GNOME,
 KDE and Xfce.

  So those two points become:

 * adding cross-desktop code to every facility that may need to send
   notifications
 * adding a notification daemon to task-lxde

 There are libraries to help with the first point, of course.

Wouldn't a daemon watching /var/mail/root and turning any mail into
desktop notifications solve most of this, while still allowing the same
notifications to reach a sysadmin on non-desktop systems?

The issue that worries me most about these desktop notification plans is
the possibility that some package may decide to unnecessarily drop
support for non-desktop systems, adding dependencies on the desktop
notification system. I believe we already have had a few examples of
such unnecessary dependencies on services which are nice to have, like
GNOME depending on NetworkManager for example.

The Clear, understandable and translated in his configured language
point is unrelated the notification system.  That requirement should be
at least as strict for any mail to root.


Bjørn


--
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/871u8opye0@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Marc Haber mh+debian-de...@zugschlus.de writes:
 On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman
 deb...@kitterman.com wrote:
Even if they are using a system 
that allows them to go back and review their notification history when they 
return to their system,

 It just occurred to me that you are describing a mail client.

Let's add biff and we have cross-desktop real-time notification in place
:)


Bjørn


--
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/8738t4oe7z@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:
 Le mardi 28 mai 2013 à 10:34 +0100, Jonathan Dowland a écrit : 
 There is an impedence mismatch between packages which consider an MTA and the
 sendmail interface to be standard and those desktop components that make no
 such assumption. If we are going to keep ensuring a local MTA/sendmail 
 interface
 going forward, I'd love to see it better integrated into the desktop stack. 
 (In
 fact I still battle debconf-stuff-on-top-of-exim from time to time, when I 
 have
 a system where I don't want any local mail.)

 I don’t think desktop components lack integration with the MTA. For
 example, evolution will use /usr/sbin/sendmail by default. The problem
 is that usually, the MTA will not be configured to do anything useful,

Moving the configuration from 1 package providing the MTA to N packages
is certainly not going to improve this...

 so users are better off using an external SMTP server, usually with
 authentication.

In what why does a local MTA prevent that?

The local MTA serves as a common configuration for the external SMTP
server, with a well known interface supported by every single package
which wants to send mail.

I don't see the point discussing this at all until there is an
alternative interface with a similar level of support.  Otherwise you
are just going to repeat the MIME support mess again.


Bjørn


--
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/87k3mj9xbo@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:
 Le mardi 28 mai 2013 à 13:07 +0200, Bjørn Mork a écrit : 
 The local MTA serves as a common configuration for the external SMTP
 server, with a well known interface supported by every single package
 which wants to send mail.

 Which packages are entitled to send mail to the outside without
 configuration from the sysadmin, exactly?

All packages are installed and configured by the sysadmin.  So that
would be none.

But there should be exactly one package asking the sysadmin about smtp
smarthost settings.  The other mail sending packages should just depend
on that package and reuse the settings already configured.

 We are talking about a default configuration, and the only useful thing
 in a default configuration is local mail. 

I disagree. The only useful default configuration is a default-mta
package asking how to deliver both local and remote mail, and holding
the sysadmin's hand while setting up delivery to a smarthost.  Possibly
mapping local accounts to a single remote address.

 Local mail not being read by anyone on most machines.

This we can agree on :)

 I don't see the point discussing this at all until there is an
 alternative interface with a similar level of support.  Otherwise you
 are just going to repeat the MIME support mess again.

 Just like for the MIME support mess, the damage is already done. Nobody,
 I repeat, nobody, ever reads local mail on most desktop systems, and
 even many server systems. For desktops, we need to rely on direct user
 notification. For servers, careful people rely on real-time monitoring. 

 Local mail is a quick solution for persistent notification of the system
 administrator, but it doesn’t scale at all when you have more than 3
 machines under your control.

 I don’t think the situation is that bad. We could probably work on
 alternative notification systems for cron jobs, but for the other
 important use cases of local mail, we already have what we need.

Sure.  Yes, I agree that local mail isn't necessarily the answer to any
notification requirement.  But I don't think that means that it never is
the answer.   There are situations where local mail notification is
fine.


Bjørn


--
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/8738t79h4i@nemi.mork.no

Re: default MTA

[Bjørn Mork]

Russ Allbery r...@debian.org writes:
 Bjørn Mork bj...@mork.no writes:

 The local MTA serves as a common configuration for the external SMTP
 server, with a well known interface supported by every single package
 which wants to send mail.

 And which requires storing passwords or other authentication credentials
 on disk if your external SMTP server requires authentication (increasingly
 common), which is bad security practice (not to mention awkward for a lot
 of people to configure).  Whereas using an external MTA directly in the
 mail client means the mail client has the ability to prompt you
 interactively for authentication credentials or use the system keyring to
 store them, which is somewhat more secure.

Yes, this is a problem common to any system wide authenticated service,
like for example a bluetooth keyboard or a PPP network connection.  I
still don't think it makes any sense delegating the configuration to
packages needing those services.  The keyboard and the network
connection are system services, even if they need credentials stored in
the file system.

IMHO, the same goes for SMTP.  There may not be as many packages needing
it as those needing a keyboard. But I'm guessing that there still are a
handful SMTP clients installed on an average single user desktop system.
And it does not make sense to have each and every one of those packages
configure external SMTP access independently.


Bjørn


--
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/87vc637y6s@nemi.mork.no

Re: Contributor agreements and copyright assignment

[Bjørn Mork]

Russ Allbery r...@debian.org writes:
 Bjørn Mork bj...@mork.no writes:

 IANAL, but I believe you are wrong there.  You give them much wider
 rights than this by assigning the copyright to the FSF.  The copyright
 owner is free to relicense the work in any way they want.

 Have you see the copyright assignment contract that you make with the FSF?

Seen and signed :-)

 It would be a breach of that contract for them to relicense the work in
 any way they want.  The contract really does try to address this issue.

 The assignment isn't a unilateral act.  The FSF promises to do things in
 return for the assignment.

Yes.  It is pretty clear that the FSF as such cannot redistribute your
work under another license.  I most certainly may be wrong, and likely
is, but I still believe there still is a tiny possiblity that the
copyright assignment is transferred as an asset, without being bound by
the other parts of the contract.

 Now, bankruptcy is indeed a potential problem, since bankruptcy courts can
 do all sorts of things, including dissolve or partly dissolve contracts.
 But even in that admittedly dangerous situation, I do think there's a fair
 amount of legal protection involved.  (And one gets some additional legal
 protection from the FSF being a non-profit under US law.)

Good.  Let's hope it won't be necessary.

 I still don't think issues like this should prevent anyone from
 contributing to any currently open source project.  Yes, it will be
 frustrating if your work ends up being part of some proprietary
 software, but it's even worse if you cannot contribute to these projects
 out of fear of that happening.

 The main issue for some of us is not so much the ethical objections to
 these sorts of agreements but rather the fact that our employers flatly
 are not interested in signing anything of the sort, ever, with anyone.
 Much of my free software work is done as part of my day job, and my
 employer is unwilling to sign any of these agreements (but is fine with me
 releasing my work under free software licenses).

Yes, that is an important problem with such policies.


Bjørn


--
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/87boe87vqv@nemi.mork.no

Re: Contributor agreements and copyright assignment (was Re: Really, about udev, not init sytsems)

[Bjørn Mork]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Barry Warsaw writes (Re: Contributor agreements and copyright assignment 
 (was Re: Really, about udev, not init sytsems)):
 FTR: http://www.canonical.com/contributors

 That allows Canonical to make proprietary forks of the code (eg, to
 engage in the dual licensing business model).  This is very
 troublesome for me; it's too asymmetric a relationship.

 This is a right that the FSF assignment doesn't give the FSF 

IANAL, but I believe you are wrong there.  You give them much wider
rights than this by assigning the copyright to the FSF.  The copyright
owner is free to relicense the work in any way they want.

The rights transferred in the Canonical agreement are very limited
compared to this.

 and which the FSF wouldn't exercise even if they had it.

No, the current FSF wouldn't do that.  But how about the company taking
over assets after the FSF lose a major lawsuit?  That company will then
own the copyright on your work, including the rights to relicense it.

I still don't think issues like this should prevent anyone from
contributing to any currently open source project.  Yes, it will be
frustrating if your work ends up being part of some proprietary
software, but it's even worse if you cannot contribute to these projects
out of fear of that happening.

BTW, never take any legal advice from me.


Bjørn


--
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/87k3sxlggu@nemi.mork.no

Re: Really, about udev, not init systems

[Bjørn Mork]

Cyril Brulebois k...@debian.org writes:
 Thomas Goirand z...@debian.org (28/11/2012):
 That's not truth anymore, since AFAIK rules of udev moved to /usr.

 May I suggest some fact checking? Try “dpkg -L udev” for a start.

Yes, the Debian package is OK and I assume it will continue to be.  But
I believe Thomas was referring to the recently (udev 176) changed
upstream default.  See e.g. 
http://www.freedesktop.org/software/systemd/man/udev.html : 

  udev configuration files are placed in /etc/udev and /usr/lib/udev.

Upstream has explained it this way in the changelog:

  The default 'configure' install locations have changed. Packages for
   systems with the historic / vs. /usr split need to be adapted,
   otherwise udev will be installed in /usr and not work
   properly. Example configuration options to install things the
   traditional way are in INSTALL.

Just stating the facts.  I see no reason to discuss these issues any
further.


Bjørn


--
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/871ufd3nfx@nemi.mork.no

Re: Really, about udev, not init systems

[Bjørn Mork]

Tollef Fog Heen tfh...@err.no writes:
 ]] Bjørn Mork 

   The default 'configure' install locations have changed. Packages for
systems with the historic / vs. /usr split need to be adapted,
otherwise udev will be installed in /usr and not work
properly. Example configuration options to install things the
traditional way are in INSTALL.
 
 Just stating the facts.  I see no reason to discuss these issues any
 further.

 «default location» vs «architecture of udev».  Reality check, please?

OK.  Reality check came back with:  Nothing of this really matter to me
at all.  I am sure a working udev branch will continue to exist, one way
or the other.

I started feeling a bit nervous back when Mauro desperately tried to
make the linux media drivers conform with the new udev firmware loading
restrictions.  But I managed to stay calm, and it all turned out quite
well.  One of the nice effects of open source is that there are absolute
limits to crazyness.  People are free to do whatever crazy stuff they
want.  Someone else will step forward and fork it back to sanity if
necessary.  This system works very well.


Bjørn


--
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/87a9u11u7f@nemi.mork.no

Reply-To munging (was: Re: Do not CC me)

[Bjørn Mork]

Thomas Goirand z...@debian.org writes:

 The solution to this is very simple. Have the
 mailing list manager to add a Reply-To: header
 on each messages.

 I've done this on few of the lists I manage, and since
 then, nobody sends double-messages.

 But, probably, mailman is too stupid to have such
 kind of options (I use (and maintain in Debian) MLMMJ,
 which is used by big distros like Gentoo and SUSE).

 Thomas

 P.S: I know that the list manager adding a Reply-To:
 header breaks the RFC, and people setting-it up
 explicitly on their mail client, but it works very well...

Fascinating.  Did I miss the announcement of
Repeat-Every-Controversial-Discussion month or what? Anyway, to save
us some time, could everybody please just read

 http://www.unicom.com/pw/reply-to-harmful.html
 http://www.metasystema.net/essays/reply-to.html
 http://woozle.org/~neale/papers/reply-to-still-harmful.html

and agree that we are not going to agree on this subject either?

There is absolutely no reason to repeat any of the arguments found in
those three documents here.  Anyone reading this list should be capable
of googling.


Bjørn


--
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/87wqx8qx47.fsf...@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Serge sergem...@gmail.com writes:
 2012/8/30 Wouter Verhelst wrote:

 How do you suppose it's possible to undo arbitrary network
 configuration done by arbitrary set of tools when there's no central
 place to hold such information (and can't possibly be)?

 Actually, the kernel holds that information. Any tool can just query the
 kernel for information, and decide what to do with what's returned.

 Not sure. Will it work for user-space configuration too? I.e. `ifdown`
 may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible
 to detect such cases automatically?

If you start dhclient or wpa_supplicant on ifup, then you naturally need
to query and deconfigure those tools on ifdown too.  There is a perfect
symmetry here:

 up use rtnetlink = down queries/deconfigures rtnetlink
 up use wpa_supplicant = down queries/deconfigures wpa_supplicant
 up use dhclient = down queries/deconfigures dhclient
 up use pppd = down queries/deconfigures pppd

etc.  Layered combinations of the above is of course common and must be
supported.

But I fail to see the point of this discussion.  Post patches for NM
and/or ifupdown implementing the features you'd like to see.  No need
for all the theoretical mumbo-jumbo, implying that someone else should
do the job.


Bjørn


--
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/878vcu3yhi@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Christoph Anton Mitterer cales...@scientia.net writes:
 On Sun, 2012-08-19 at 19:41 +0200, Marco d'Itri wrote:
 NM, as a design goal, is not supposed to be able to manage every 
 possible configuration.
 Well but then it shouldn't be kind of a default package.

No it shouldn't.  And it isn't either.  gnome-core is not default.

 And yes, I
 know, strictly speaking it's neither required nor essential.
 But as I mentioned before, more and more uses it... and one usually
 get's it already with gnome-core.

Except for GNOME, what other unrelated packages depends on NM?

The GNOME dependencies are deliberately broken to bring in as much cruft
as possible, but GNOME is neither required nor default so what's the
problem?  Why do you install gnome-core if you don't want the resulting
package mess?

 And to be honest, I don't think that it's impossible that NM would
 integrate well with ifupdown (and the others).

I believe it already does.  Any problems with this integration should be
reported as bugs.

Neither NM nor ifupdown is currently capable of dealing with every
possible networking setup (NM fails on complex static configurations,
ifupdown fails on dynamic stateful configurations).  And I expect this
is how it will be for the foreseeable future.  At least that's how I
understand the current scopes of those packages.

Debian need *both*, and any efforts in this area should be put into
making them interoperate.

Never mind wireless lan where you've got a well defined kernel API.  Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the
usefulness of a framework like NM and it's companion ModemManager. Yes,
there are of course bugs and missing features. But let's fix them then.
NM upstream is very active and easy to co-operate with.

And before someone asks: There won't be any standard wireless
extensions for wan connections. That sort of thing is just not
considered appropriate for the kernel anymore. Drivers export the device
native control channel(s), and leave the rest of the job for userspace
libraries.  This means that you will need something like ModemManager,
oFono or similar to provide a common device independent application
interface.


Bjørn


--
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/871uj1kegq@nemi.mork.no

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

[Bjørn Mork]

Stephan Seitz stse+deb...@fsing.rootsland.net writes:
 On Mon, Aug 20, 2012 at 01:08:53PM +0200, Bjørn Mork wrote:
Never mind wireless lan where you've got a well defined kernel API.  Try
to configure a modern 3G/LTE modem using ifupdown, and you will see the

 Is this something different from an UMTS usbstick?

No.

 I plug it in, get a
 /dev/ttypUSB0 and do a „pon umts”. No need for NM and Co.

Sure. But you didn't actually configure the device here, did you?  And
you didn't notice that the device fell back from LTE to UTMS.  Or that
it suddenly started roaming to the network on the other side of the
border. Etc.

You didn't even notice that the connection failed because the PIN code
was wrong.  Or did you?  OK, then your chat script has started looking
like a small ModemManager application...

Oh, yeah, and of course /dev/ttyUSB0 wasn't the AT port.  It was the
QCDM port so the chat script just timed out.

The connections provided by these devices are dynamic by nature, and
they typically have management protocols supporting notifications from
device to host.  You may of course ignore this and state that the device
works in a static configuration, but most users will want some
monitoring daemon allowing them to make intelligent decisions based on
current available devices and networks.  A little like what
wpa_supplicant does for wireless LANs. That's what ModemManager
provides.

But yes, if „pon umts” is enough for you then you don't need NM (or even
ifupdown - pppd and vim will do).

By modern 3G/LTE modem I mean a device supporting CDC MBIM or a vendor
specific management protocol like QMI.  The firmware of most of these
devices will export a basic AT command set and support PPP on one or
more serial ports, but that only supports a very limited usage pattern
IMHO.  And when it comes to LTE, also limited speed.  Some vendors
implement AT commands for initiating NDIS connections, but these are
exceptions and are likely to go away over time as more and more devices
get a intented for Windows 8 label or somthing like that.  And it
didn't work with your pon in any case.


Bjørn


--
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/87pq6liwmw@nemi.mork.no

Re: Recommends for metapackages

[Bjørn Mork]

Jean-Christophe Dubacq jcduba...@free.fr writes:
 On 11/07/2012 11:12, Andrei POPESCU wrote:
 On Mi, 11 iul 12, 10:55:16, Jonas Smedegaard wrote:

 The feature of _allowing a subset of packages to be removed that was 
 _ensured_ to be installed: Impossible without defeating the feature of 
 _ensuring_ those same package are installed.
 
 Agreed. However, unless I missed something I haven't seen any arguments 
 for why gnome-core really needs to _ensure_ that network-manager-gnome 
 is installed, other than upgrade issues without any other details.

 If my memory does not fail me, support from upstream (since
 network-manager is a core component of Gnome). I may be wrong.

That must be an upstream *Gnome* bug then.  But it is most certainly a
bug.  Network Manager is not intended as an one-size-fits-all
application.

I have never been a great fan of Network Manager, but for various
reasons I've taken some time to actually get to know it lately. And that
has been enlightening. Turns out that it works really well for the use
cases it supports, and it isn't *meant* to be used for every possible
use case.  Contrary to what you would be led to believe by the strict
Gnome dependency.

I do recommend everybody, especially the Debian Gnome maintainers, to
read what Dan Williams said here yesterday:
https://mail.gnome.org/archives/networkmanager-list/2012-July/msg00168.html

quote
Instead, I believe our goal is to make NM useful enough, easy enough,
and understandable enough, that people *want* to use NM rather than
wading through a bunch of scripts.  We don't want to force NM upon
people; instead we need to make NM *better* than the existing options so
that it's a no-brainer choice.  There will always be people that want to
tinker and do something else or have so totally crack-rock use-cases
that we have no hope of easily supporting them, and that's fine.  That's
what software is about.
Instead, I believe our goal is to make NM useful enough, easy enough,
and understandable enough, that people *want* to use NM rather than
wading through a bunch of scripts.  We don't want to force NM upon
people; instead we need to make NM *better* than the existing options so
that it's a no-brainer choice.  There will always be people that want to
tinker and do something else or have so totally crack-rock use-cases
that we have no hope of easily supporting them, and that's fine.  That's
what software is about.
/quote

I just wish every piece of software was based on a philosophy like that.


Bjørn


--
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/87hasonzt2@nemi.mork.no

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Serge sergem...@gmail.com writes:

 Since tmpfs+swap is mostly slower than regular filesystem

And the world is flat.


Bjørn


--
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/874nqfn0af@nemi.mork.no

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Aneurin Price aneurin.pr...@gmail.com writes:

 In anything resembling a 'normal' system (ie. the kind where one might
 be using the defaults) I would say that the tmpfs correlation is so
 strong as to be very nearly 1:1, and this seems like the crux of the
 matter; that is after all the reason that these applications are
 failing when /tmp is switched to tmpfs.

I agree that's likely for any system using a default disk layout, so my
comment was irrelevant for this discussion.

I still think that the easy tmpfs resizing (no meta data update, no LVM
requirements, can use available space on other file systems) makes it
superior for /tmp.  But most users won't know that they can do this, so
we might need a daemon monitoring /tmp and doing ondemand resizing.


Bjørn


--
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/87lijsok60@nemi.mork.no

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Aneurin Price aneurin.pr...@gmail.com writes:

 (Note that we are talking about applications which fail gracefully
 when confronted with ENOSPC, 

Are we? What's the problem then?

 but which are likely to do so more often when the size of /tmp is
 restricted.)

Yes, but the tmpfs correlation is weak.  There is absolutely no
guarantee that there will be more space available on the root file
system than a default tmpfs.



Bjørn


--
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/87d355pl0v@nemi.mork.no

Re: Summary: Moving /tmp to tmpfs makes it useless

[Bjørn Mork]

Serge sergem...@gmail.com writes:
 2012/6/10 Adam Borowski wrote:

 Some people asked for a thread summary. So here it is.
 Seriously, can't you even read what's written to you?

 Yes, I know it was a biased summary.

I think you might start to piss off a few people now...

Look at what you are quoting above. You introduced your biased summary
like this:

  Some people asked for a thread summary. So here it is..

I will refrain from further comments.  People can judge for themselves.


Bjørn


--
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/87txyjp85k@nemi.mork.no

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Petter Reinholdtsen p...@hungry.com writes:

 I've happily been using tmpfs on /tmp/ for probably ten years now, and
 can list some more benefits:

  - It allow diskless setups like LTSP to work the same way the default
installation in Debian work.  They use read-only NFS-mounted file
systems and a writable tmpfs mounted on /tmp/.

  - It reduces the number of disk writes on a laptop, allowing it to
spin down the disk a bit longer.


I'd like to add another one:

- a tmpfs is always easy to grow without requiring any special
  preparations.  Just add more swap.  The swap could be on different
  disks, and could even be files hosted on other file systems.

Any file system will run out of space given the broken applications
mentioned in this thread.  tmpfs is the only one which will allow all
systems to dynamically add more space, only limited by the available
disks. That's why tmpfs should be the default for both new and old
systems, unless the administrator has explicitly made a more limited
choice.


Bjørn


--
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/87lijyqd2l@nemi.mork.no

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Petter Reinholdtsen p...@hungry.com writes:

 [Bjørn Mork]
 I'd like to add another one:

 - a tmpfs is always easy to grow without requiring any special
   preparations.  Just add more swap.  The swap could be on different
   disks, and could even be files hosted on other file systems.

 This sound very similar to what I am doing already with LVM and online
 file system growing.  A simple 'lvresize' and 'ext2resize' (or just
 debian-edu-fsautoresize for those of us with that tool available)
 later the full file systems have more free space again. :)

 Did I misunderstand you?

No, but those require LVM and available raw disk space.  Swap can always
be added without any such preparation.


Bjørn


-- 
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/87d359qyxb@nemi.mork.no

Re: Moving /tmp to tmpfs makes it useless

[Bjørn Mork]

Vincent Lefevre vinc...@vinc17.net writes:
 On 2012-05-30 12:08:29 +0200, Josselin Mouette wrote:
 Le samedi 26 mai 2012 à 23:02 +0200, Carlos Alberto Lopez Perez a
 écrit : 
  With tmpfs on /tmp you are breaking many applications that assume that
  they have enough space to write on /tmp like the flash player ( see
  Debian bug #666096 ) or cdrecord software ( see #665634 ).
 
 Seriously, this is madness. You can’t expect to have “enough” space on
 *any* filesystem.

 I think that the point is that in general, there is more space on
 the local disk than on some tmpfs. What I mean is that if /tmp is
 on the right partition on the disk, it will have more space than
 any reasonable tmpfs.

Does that make any difference at all?  If an application is unable to
handle the out-of-space condition, then it will be unable to handle the
out-of-space condition no matter how big the file system is.  Increasing
the file system size is futile.  Fix the bug in the application instead.


Bjørn


--
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/87fwah96n9@nemi.mork.no

Re: Wheezy release: CDs are not big enough any more...

[Bjørn Mork]

Timo Juhani Lindfors timo.lindf...@iki.fi writes:
 Wookey woo...@wookware.org writes:
 And the USB-stick process is not as simple as it might be because you
 have to find the HD-media files and then _also_ find an iso image to
 put on. It's no wonder newbs are still downloading CD/DVD images. 

 You also need to have root access to some machine to create the USB
 media.

No, you don't.  On a default Debian system you need to be a member of
the floppy group. From  /lib/udev/rules.d/91-permissions.rules :

 # default permissions for block devices
 SUBSYSTEM==block, GROUP=disk
 SUBSYSTEM==block, ATTRS{removable}==1,  GROUP=floppy

 This means you can't create the installation media at most
 university or library machines unlike with CDs.

You mean that they allow you to burn a CD but not write to a USB stick?
Sounds like they have a support problem which I don't think Debian can
solve for them.


Bjørn


--
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/87zk98a480@nemi.mork.no

Re: Wheezy release: CDs are not big enough any more...

[Bjørn Mork]

Timo Juhani Lindfors timo.lindf...@iki.fi writes:
 Bjørn Mork bj...@mork.no writes:
 No, you don't.  On a default Debian system you need to be a member of
 the floppy group. From  /lib/udev/rules.d/91-permissions.rules :

 Yeah but you are not a member of that group by default surely?

No, that decision should be left to the adminstrator.  The point was
that you don't need to be root, and you probably never should be when
doing something like that (to prevent being only one typo away from
disaster).

 You mean that they allow you to burn a CD but not write to a USB
 stick?

 Yes, I understood this was the default. If you put users to floppy group
 then remote users can read usb sticks of local users.

I fail to see how burning to a local user's CD is any better, but yes,
if that is a consideration then they need some system to tie the rights
to console access.  I believe ConsoleKit and the replacement
systemd-loginctl attempts to solve such problems.


Bjørn


--
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/87fwb0a0fj@nemi.mork.no

Re: RFC: OpenRC as Init System for Debian

[Bjørn Mork]

Uoti Urpala uoti.urp...@pp1.inet.fi writes:

 Machine-specific configuration belongs in /etc. The default behavior of
 the tools doesn't.

Agree.  Copying a large set of default policies into /etc just because
they *can* be overridden is not user friendly.  And it does not make the
defaults any more configuration either. It just hides important local
changes and makes it difficult both for the user and the application
itself to distinguish between defaults and configuration overrides.

A default setting does not count as configuration until it is changed,
IMHO. 


Bjørn


--
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/87397844h3@nemi.mork.no

Re: Removing the MTA from the default install

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:

 Is this the right time to do it?

Wasn't this just recently discussed?  Just replay the thread:
http://lists.debian.org/debian-devel/2011/10/msg00227.html


Bjørn


-- 
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/87k40u4s1g@nemi.mork.no

Re: Default display manager should not be gdm3

[Bjørn Mork]

Josselin Mouette j...@debian.org writes:

 This feature was in squeeze and so far we didn’t reinstate it in 3.x on
 upstream request. This is because they complained people used this
 feature to shoot themselves in the foot and then accused gdm of being
 broken. 

So they choose to break gdm and ignore all those now *rightfully*
accusing gdm of being broken?

That makes no sense at all.

I'm not going to call it crazy.  It's merely insane.


Bjørn


-- 
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/87sjhvdrew@nemi.mork.no

Re: [Long] UEFI support

[Bjørn Mork]

Tanguy Ortolo tanguy+deb...@ortolo.eu writes:
 Paul Wise, 2012-01-09 00:44+0100:
 Sounds like he was asking you to name these new 32-bit only x86
 systems that are still being produced and sold.

 That is right. In fact, I do not doubt there are some 32 bits only
 processors sold today, but I am not sure that they are using an UEFI. 

There are.  STFW

 It is very possible, but it may not be a very common case.

Neither is UEFI on 64bit systems.  Yet.  So let's just ignore it then.
No?  Well, then I don't see how the common case argument is relevant
for 32bit systems either.


Bjørn


-- 
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/878vlhfei7@nemi.mork.no

Re: /tmp as tmpfs and consequence for imaging software

[Bjørn Mork]

Chow Loong Jin hyper...@ubuntu.com writes:

 On 16/11/2011 22:43, Salvo Tomaselli wrote:
 Most netbooks and small laptops (such as Thinkpads) do not. 
 My thinkpad has it...

 Mine doesn't. The smaller Thinkpads (less than 14?) don't.

This discussion is getting more and more weird, but for the sake of
continuing it: My Thinkpad X301 has a DVD-burner even if it only has a
13 screen and weighs in at less than 1.5kg.  It also has 8GB RAM, to
add some more useless numbers.  But the last item is non-default..

And BTW, the Sun tmpfs(7fs) man page seems to be last updated in 1990,
so the /tmp on tmpfs usage must be older than that.  See e.g. 
http://download.oracle.com/docs/cd/E19455-01/806-0636/6j9vq2bui/index.html

Personally I find the whole idea of some application *assuming* anything
about where to put multi-GB files ridiculous.  You cannot.



Bjørn


-- 
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/87lire95i7@nemi.mork.no

Re: RFC: Making mail-transport-agent Priority: optional

[Bjørn Mork]

Josh Triplett j...@joshtriplett.org writes:

 What would it take to make this change?

Changing the LSB.  Or you need to keep the sendmail interface.  Which is
what mail-transport-agent provides.

  Have I missed any important points?

You forgot to explain the upside, reason, why, gain, whatever.

  Would any other packages need changes, other than the ones I've
 mentioned above?

all packages with cron jobs, all 3rd party applications assuming an UNIX
environment, ++

The reasons are all explained in the release notes.

Why not remove syslog as well?  I'm pretty sure there are plenty of end
users never ever looking at a log file.


Bjørn


-- 
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/871uuhhly0@nemi.mork.no

Re: ifupdown 0.7~alpha4 in experimental

[Bjørn Mork]

Stephan Seitz stse+deb...@fsing.rootsland.net writes:

 So how do you do the auto configuration? Do you have radvd running or
 a DHCPv6 server? If I understand correctly, radvd won’t give you DNS
 servers. 

radvd *can* give you DNS servers.  See the RDNSS option in radvd.conf(5).

rdnssd is a client implementation for Linux.  Other than that, the
client support is not very widespread.



Bjørn


-- 
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/87k4cmkpo9@nemi.mork.no

Re: Getting good bug reports

[Bjørn Mork]

Brian May br...@microcomaustralia.com.au writes:

 Some don't even have Internet access.

So, how do you propose reportbug should handle those?  Send a fax?

Seriously, what problem do you have that isn't solved by 
 reportbug --offline --output=foo
?



Bjørn


-- 
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/8762oyx3t3@nemi.mork.no

Re: How to solve race condition between IPv6 ifup and start of services?

[Bjørn Mork]

Marc Haber mh+debian-de...@zugschlus.de writes:
 On Sat, 21 May 2011 15:42:51 -0700, Steve Langasek vor...@debian.org
 wrote:
With an event-based init system such as upstart, you could also set up the
service not to start until the specified interface is fully configured.

 Issue (1): We don't have event-based init system yet
 Issue (2): When is an IPv6 interface fully configured?

Or: When is *any* interface fully configured?

The subject does not really have anything to do with IPv6.  Interfaces
may have any addresses added or removed, and you may want to define
service policies depending on some specific network state.  This applies
just as much to IPv4 as to IPv6.

I believe Debian as a distribution should be extremely careful about
predefining policies, but preferably give the administrators the tools
necessary to define them.  So please don't try to define fully
configured for me.  

It would of course be nice to have the ability to say: Run service foo
when interface bar has an address matching baz, but I believe these
kinds of policies quickly will become too complex to have generic
solutions.  You can usually script something, using existing tools
like laptop-net, udev, dhcp clients, wpa_supplicant etc.

And if someone wants a scriptable solution for SLAAC, then writing a
small daemon listening for netlink events and running scripts based on
them should be piece-of-cake.  In fact, it is so easy that it is
probably already done.


Bjørn


-- 
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/87mxifynbx@nemi.mork.no

Re: this list archive spoils e-mails + strange Enigmail typos

[Bjørn Mork]

Stanisław Findeisen s...@eisenbits.com writes:

 Well but the quoted text *is* there... (at least in the copy I received
 from liszt.debian.org).

Both problems (missing text and visible =20) are caused by MIME headers
missing from the first part of your message.  The quoted text is hidden
because there is no empty line after the boundary marker, which makes a
MIME client interpret the text as unknown header lines.

The =20 is displayed because you send quoted printable content without
stating so.


Bjørn



-- 
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/87oc3f1xol@nemi.mork.no

Re: network-manager as default? No!

[Bjørn Mork]

Fernando Lemos fernando...@gmail.com writes:
 On Fri, Apr 15, 2011 at 6:50 PM, Felipe Sateler fsate...@debian.org wrote:

 Preparing to replace network-manager 0.8.3.999-1 (using .../network-
 manager_0.8.3.999-1_amd64.deb) ...
 Unpacking replacement network-manager ...
 Setting up network-manager (0.8.3.999-1) ...
 Reloading system message bus config...done.
 Stopping network connection manager: NetworkManager.
 ps, wifi connection gone
 Starting network connection manager: NetworkManager.
 Processing triggers for man-db ...

 As it was said before (*multiple* times, unfortunately), that's
 expected.

For the record: *I* don't expect it, since this behaviour is completely
unnecessary and only a result of bad design.  Leaving wpa_supplicant
running on stop and re-interfacing with it on start would be simple to
do if you wanted to fix this bug.

But it's of course always much easier to claim that it's not a bug at
all.  Pigs can fly.  The moon is made of green cheese.  etc.

 Your *wired* connection won't go down...

Why not?  That seems very inconsistent.  How do I know which interfaces
I should expect to go down?  Any interface without a wire?  Can I make
the wlan interface stay up if I use a longer antenna cable?  Why not? 

Only a Network Manager developer can possibly know what to expect of
Network Manager...



Bjørn


-- 
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/87mxjitj3r@nemi.mork.no