Re: Policy consensus on transition when removing initscripts.

[Ivan Shmakov]

> "Sam" == Sam Hartman  wrote:
> "Simon" == Simon Richter  writes:
> "Sam" == On 6/29/23 01:56, Sam Hartman wrote:

 Sam> It also seems a bit strange to require more from the maintainer
 Sam> when they are dropping an init script than we would if a
 Sam> maintainer started depending on a feature like socket activation
 Sam> such that their package simply would not work without systemd.

 Simon> This would be a case where the init script and the systemd
 Simon> unit deviate in functionality.  I don’t see a problem with
 Simon> that, and my expectation is generally that the people running
 Simon> sysvinit and the people running systemd have different
 Simon> expectations here anyway.

That’s my impression as well.  Personally, I’m not going to
expect for daemons started via different init mechanisms to
behave identically, either.

 Sam> It would be entirely permitted under GR 2019-002 for me to build
 Sam> a version of krb5-kdc that was compiled to depend on socket
 Sam> activation and would not work without systemd.

 Sam> I would not be required to provide any transition when doing that.
 Sam> (To be clear, I have no such plans, and in the case of krb5kdc
 Sam> don’t currently think it would be a good idea).

I’m not sure it’s solely within the scope of the GR.

When doing development and testing, I’ve found it useful to be
able to start server processes from my own code.  So, for example,
I’d have a wrapper that’d do initdb on a temporary directory,
start a PostgreSQL server process there, load the schema and
test data, run a test suite, kill the server and remove the
directory.  No system-wide PostgreSQL instance is ever started
on that system, so the choice of the init system is hardly
relevant.  (Never had a reason to start a KDC in such a way,
but I’m not going to swear no one will ever need it, either.)

I’d rather appreciate if this particular rug isn’t pulled from
under my feet at some future date.

Not that I’d expect it to be, mind.  So far my experience with
Debian packages has been that they tend to come with as much
upstream features enabled as possible (to the point where I
sometimes wish it weren’t the case.)

If there’re concerns that a package maintainer might decide to
deviate from such a practice for ill reasons, I suppose it should
be codified within the policy.  Otherwise, so long as as a
given daemon can be started via fork and exec, it can be started
from an init.d script just as well; while removing support for
such use might affect users beyond those who rely on init.d.

PS.  The orphan-sysvinit-scripts package now has my attention.

-- 
FSF associate member #7257  np. A Gentle Place by Lisa Lynne

[i386] adlibtracker2 and fp-units-i386

[Ivan Shmakov]

> On 2023-06-07, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise  wrote:

 >> I note that there are a number of packages available on i386 but not
 >> available on amd64, is anyone planning on an MBF about this issue?

 > I got curious.  Some of them are hurd specific.  Others are a i386
 > specific version, either for fewer processor capabilities or just a
 > specific one, like signed bootloader packages and such.  Lets remove
 > those and see what we have left.

[...]

 > Old soundblaster card related:

 >>  adlibtracker2 deb sound optional arch=i386

"Related," yet not "dependent."  This package allows one to
compose /and play/ music composed for the OPL3 FM synthesis
chip (and its clones), such as was (historically) used in
Adlib and compatible boards.  Naturally, it contains an OPL3
emulator and, in recent versions, has no support for hardware
OPL3 chips.

This package is similar in spirit to, e. g., goattracker for SID
(or the recently removed aylet for AY-3-8912.)

I've been meaning to check why it's i386-only for a while now.
As a (not particularly educated) guess, it might have something
to do with it being written in Free Pascal.

 >>  sb16ctrl-bochs deb otherosfs optional arch=any-i386

[...]

 > i386-version of something and helpers and hardware enablement:

 >>  fp-units-i386 deb devel optional arch=i386
 >>  fp-units-i386-3.2.2 deb devel optional arch=i386

... For instance, at [1], I only see "Kylix" mentioned for:

  fp-units-i386
Free Pascal - Kylix compatibility units dependency package

  fp-units-i386-3.2.2
Free Pascal - Kylix compatibility units

[1] http://packages.debian.org/sid/source/fpc

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: i386 in the future

[Ivan Shmakov]

> On 2023-05-19, Steve McIntyre wrote:
> Colin Watson wrote:
> On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
> LB == Luca Boccassi wrote:

 LB> +1 for stopping publishing installers for i386, it has been
 LB> mentioned many times but it's always worth repeating: electricity
 LB> costs to keep running i386 hardware are already way higher than
 LB> what it costs to buy a cheap, low-power replacement like a
 LB> raspberry pi, that also provides better performance.

I'm living within some 200 km distance from a major hydroelectric
plant, so I can afford being more concerned about freedom than
electricity costs [*].  I admit I haven't researched this question
properly, but my understanding is that while, say, the AMD SB740
chipset from c. 2008 (that my primary box is built on) is very
well-documented (and well supported by free software), many newer
ones are not nearly as much (regardless of their power efficiency.)

Granted, it's amd64, but it's still a 'retro' machine already.

Specifically, while I have little experience with RPis (and SBCs
in general), http://wiki.debian.org/CheapServerBoxHardware
suggests that RPis aren't all that well supported by Debian main.

 CSBH> Unsuitable
 
 CSBH> * RaspberryPi: requires nonfree software to start up
 CSBH> * RaspberryPi2: requires nonfree software to start up
 CSBH> * RaspberryPi3: requires nonfree software to start up

 [*] My electricity bill is under 20 USD / month.

 >>> Well, maybe not a strong view, but a sense of vague unease--possibly
 >>> an ill-informed one.  As someone who has used SIMH for "real"
 >>> work, I have to ask how someone would conduct an install to a 32-bit
 >>> x86 machine running under emulation, assuming no OS on the simulated
 >>> machine.

 >> I occasionally use 32-bit x86 even today (mostly for not very good
 >> historical reasons, but nevertheless), and I do it by using a 32-bit
 >> container on a 64-bit x86 machine instead.  It's much faster to run,
 >> and it doesn't depend on installer support.  There are doubtless
 >> edge cases where you need a completely separate kernel, but they
 >> aren't really ones I run into.

 > ACK.  For people needing/testing i386 stuff, even just a simple
 > debootstrap and {s,}chroot will cover the vast majority of needs.
 > That's how we've been building i386 software already for ages in
 > Debian already.

 > More complex things can be done if needed: loopback mount an image,

Or: attach a disk, partition it, mkfs and mount as needed...

 > debootstrap, install a kernel, etc.  I don't see this as something
 > we should be spending much effort on in the future.

FWIW, I'm using debootstrap to install Debian on my boxes for
something like a full decade now.  Personally, I wouldn't be
inconvenienced in the least were Debian to stop providing D-I
images for i386, or any other architecture for that matter.

But I'd rather appreciate if it'd still be possible to run i386
binaries on Debian, including running a full Debian install
on a i386 (i686) machine, real or emulated.

(For i586 and other older platforms, I've found I could happily
rely on NetBSD instead.)

-- 
FSF associate member #7257  np. Border Line by Paolo Pavan

Re: An email address for drive-by bug reports?

[Ivan Shmakov]

>>>>> On 2023-03-23 05:30:01 +0100, Don Armstrong wrote:
>>>>> On Fri, 17 Mar 2023, Ivan Shmakov wrote:

 >> It would’ve likely helped me if #1006801 were listed on
 >> http://bugs.debian.org/src:tinysshd .

 >> (I’m not entirely sure as to /why/ it got archived, TBH: it’s found in
 >> 20190101-1, which is still in the archive, and fixed in 20220305-1; as
 >> such, I’d expect it to remain open until Bullseye itself is archived.)

 > Bugs that are fixed in testing, unstable (and experimental) but
 > not RC severity (serious and above) are archived if they have
 > been closed for more than 28 days.

ACK, thanks.  Somewhere along the way I’ve picked a mistaken
understanding of the process.

The end result is that I should pay more attention to archived
bugs, I suppose.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: An email address for drive-by bug reports?

[Ivan Shmakov]

> On 2023-03-01 16:30:01 +0100, Sam Hartman wrote:

 > Honestly, if there is not currently a submitter behind a bug---someone
 > who cares about it and is willing to look into requests for more
 > information or to help confirm a fix---I'm not particularly interested
 > in working on such a bug.

We’re all volunteers here.  If someone doesn’t want to work
on a particular issue, they’re IMO at full liberty to not do
any such work.  (There are exceptions, but ultimately, it boils
down to whether the person does or doesn’t want to put effort
into a particular issue / package / etc., possibly to the
detriment of their other commitments.)

 > To me, that's often a sign the bug should be closed until someone
 > comes along who cares about the issue enough to interact with it.

 > There are exceptions.

 > So I'd be fine with a nosubmitter command or similar, but also with
 > the understanding that it's entirely reasonable for maintainers
 > to close nosubmitter bugs as wontfix-until-some-specific-person-cares.

 > Socially and culturally I do want to emphasize the idea that if you
 > aren't willing (any more) to put energy behind your problem report,
 > it's entirely fine if no one is going to put energy behind fixing it.

 > Having a bunch of problem reports that no one is interested in
 > cluttering up package pages has a cost.  Just for the same reasons
 > you don't want these reports cluttering up your bugs from page,
 > I perhaps don't want them cluttering up my bugs on my package
 > pages if you no longer care.

My long-time opinion is that so long as the bug is reproducible,
and does affect Debian users, it’s ought to be in the BTS, open.

The maintainer(s) can of course indicate their lack of desire
to invest effort into solving the issue via the wontfix tag;
no opposition to that.

For an example, I’ve once spent hours trying to determine the
cause of a particular problem I was having.  Turns out
tinysshd(8) from Bullseye has an interoperability issue with
openssh-client from the same.  It would’ve likely helped me
if #1006801 were listed on http://bugs.debian.org/src:tinysshd .

(I’m not entirely sure as to /why/ it got archived, TBH:
it’s found in 20190101-1, which is still in the archive, and
fixed in 20220305-1; as such, I’d expect it to remain open
until Bullseye itself is archived.)

The problem with the logic quoted above is that a bug that the
original submitter isn’t interested in can still be affecting
those who use Debian now; and, unless fixed, can still affect
those who will use Debian at some later point.  The absence of
a /record/ of a person interested in the issue is not the same
as the absence of such a /person/ themselves.

Personally, I find Debian BTS to be a valuable source of what
issues there /are./  On occasion, I’d choose between two
packages based on what bugs are filed for each.  Othertimes,
I’ll find workarounds there.  Or I might find why a particular
issue is infeasible to fix in a given package, and start
searching for another option for the task at hand.

It’d be sad to see Debian BTS devolve into a bunch of
maintainers’ personal TODO lists.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

possible MMBF regarding Depends: locales without | locales-all?

[Ivan Shmakov]

Сс: debian-b...@lists.debian.org

[Cross-posting to tasksel maintainers, debian-boot@; but please
keep the discussion on debian-devel@.]

Unless I deeply misunderstand how locales work in Debian,
I believe that any dependency on the ‘locales’ package is ought
to be satisfied with locales-all as well.

Could the maintainers of the packages below please check if the
‘| locales-all’ alternative can indeed be added to Depends:?
(I’ve tried to limit the list to testing, but some slippage from
stable might have occurred.  My apologies if that’s the case.)

Otherwise, would there be any problem with me mass-filing bug
reports on this issue?

TIA.

cloud-init  20.1-2  …, locales, …
collatinus  11-1+b2 …, locales, …
kopano-contacts 8.7.0-7 …, locales
kopano-l10n 8.7.0-7 locales
live-task-standard  11.0.2  …, locales, …
orthanc 1.6.1+dfsg-1…, locales, …
task-bosnian3.58…, locales
task-croatian   3.58…, locales
task-english3.58…, locales
task-norwegian  3.58…, locales
task-swedish3.58…, locales
task-turkish3.58…, locales, manpages-tr
x2gothinclient-displaymanager
1.5.0.1-5   …, locales, …
localehelper0.1.4-3 locales, perl:any
localepurge 0.7.3.8 …, locales, ucf, procps

The last two packages seemed like they could benefit from closer
inspection.  As it turns out, at least localehelper is just a
wrapper to run localedef on missing locales; presumably this code
path would simply never be followed with locales-all installed.


Background

I prefer locales-all over locales on my systems for the following
reasons:

 1. interest in languages in general; I want for any locale
provided by Debian to be at hand at all times;

 2. several of the systems I maintain are multi-user; I don’t
want to spend brain cycles deciding which locales they may
or may not want to use;

 3. on backup, I feel safe to ignore anything that matches its
md5sum – as recorded in the respective .deb --ctrl-tarfile;
locales-all have that aplenty; locales, not as much (IIUC.)

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Ivan Shmakov]

> Jonathan Dowland  writes:
> On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote:
> On Oct 23, Tollef Fog Heen  wrote:

 >>> Wouldn’t it make more sense for mutt to just go «oh, no GPG
 >>> installed, let’s note that there are signatures here, but they
 >>> can’t be verified, since there’s no GPG installed on the system»
 >>> and let the user know that?  No need to actually disable PGP
 >>> support.

 >> Yes. Because this way the default configuration will be useful both
 >> before and after gnupg will have been installed.

 > That is sort-of what is happening for neomutt (20171215+dfsg.1-1) at
 > least, it reports

 >sh: 1: gpg: not found

 > There’s room for improvement there.  mutt (1.9.2-1) is worse

 >Error: verification failed: Unsupported protocol

 > both with the default configurations.

What are the values of the crypt_use_gpgme setting in each case?
Could it be that mutt and neomutt actually have different defaults
(one using gpg(1) directly and the other using GPGME) here?

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Ivan Shmakov]

> Wouter Verhelst  writes:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:

[…]

 >>> I think the prerequisite for making a change like this would be for
 >>> the library to be able to surface this transitive requirement in
 >>> metadata so that debhelper could support automatically adding it
 >>> to the dependencies of all linked programs (and I’m not sure that
 >>> sort of collapse of our dependency structure is a good idea).

 >> That would be a bad idea – we don’t want gratuitous dependencies
 >> all around.  Just because I use xfce doesn’t mean I want a daemon
 >> for some old kinds of iApple iJunk

 > Why not?  What does it cost you, other than a few bits on your hard
 > disk, to have those things installed?

 > It is an actual cost for users who do not (want to) understand the
 > technical background in why their iSomething doesn’t communicate with
 > Debian properly, and it costs *us* time in support questions if we
 > have to explain to them that they just need to install this one
 > little thing here that takes a few MB (if that; haven’t checked).

It works both ways, actually.  I’ve recently seen a problem
with a newly installed system ending up with /two/ configured
IPv4 addresses (where one was expected.)  The cause of this
surprise?  Recommends:¹.

More specifically, the admin there installed isc-dhcp-client and
configured interfaces(5) accordingly.  He also installed lxqt,
which Recommends: cmst, which in turn Depends: connman (entirely
appropriately, I guess, as the former is a GUI for the latter),
which /also/ configures network interfaces.

  ¹ Not entirely, obviously.  But the claim that ‘more is better,’
and leads to ‘lack of surprise’ and a ‘more straightforward user
experience’ isn’t without a flaw when it comes to practice.

 > My laptop, which has a 240G SSD, is mostly full.  That is, however,
 > *not* because of the amount of software that’s installed; 90% of that
 > storage is in my /home.

 > I suspect that the same is true for most users, and therefore that we
 > just shouldn’t care about it.

The disk usage is indeed a concern, even if likely minor for an
average user.  Consider, for instance, that you run a dozens of
VMs and want Mutt installed on every single one.  Unless you use
LXC on Btrfs with transparent deduplication there, the gnupg and
its own dependencies may accumulate into a non-trivial disk usage.

Alternatively, if you perform incremental block-level backups of
the root filesystem (and I do), every update to the gnupg package
(within the archive retention time) – as well as each of its
unique dependencies – will add the respective Installed-Size: to
the archive size.

Another issue is that GnuPG, being called from Mutt automatically
by default, /does/ increase the attack surface.  Of course, you
can (remember to) turn it off in the configuration, but the more
/straightforward/ way to avoid that is /not to install/ the package
in the first place.  In general, the software that you do /not/
have installed, is most certainly /not/ going to break.

Then, there’s the issue of surprise.  The software which hooks
into other software that you use /can/ surprise you.  For example,
the bash-completion package makes Bash completion function
unusable to me; so I usually do not install it at all, and where
it is installed, I make sure to disable it with ‘complete -r’ in
my personal configuration.

To summarize, I’d expect for a non-trivial fraction of experienced
users to actually put effort into minimizing the amount of
/code/ installed – precisely to /ensure/ straightforward and
unsurprising behavior.

As for GnuPG, well, as Mario points out, – it’s useless unless
configured by the user, /and/ is prone to result in ‘cryptic’
error messages even if correctly installed.  In turn, to configure
GnuPG, the user will presumably have to invoke it directly, or
perhaps from some UI wrapper, at which point he either will notice
the absence of the command, /or/ the absence of said wrapper –
for which it /would/ be entirely reasonable to depend on gnupg.

So the particular point that Mutt is going to misbehave without
GnuPG installed is moot: the cause for its misbehavior wouldn’t
be the lack of GnuPG, but rather the lack of user’s knowledge of
it – or motivation to use.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: tinysshd dependency on systemd

[Ivan Shmakov]

>>>>> Jonathan Dowland  writes:
>>>>> On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:

 >> I disagree; to the best of my knowledge, anyone can do the testing
 >> and suggest any fixes he or she deems necessary.  As such, having an
 >> issue recorded in the BTS is preferable to not having it recorded,
 >> and having a (semi-correct)

 >

 > You win the prize for the most Orwellian spelling of "untested and
 > broken" that I've seen today. (so far.)

If this comment has some purpose conductive to free software
development, I’m afraid it has so far eluded me.  (Though I
suppose I can be glad for you if you’ve found my wording amusing.)

 > Whilst you wasted your time (and ours) on this side-show,

If reading my messages on debian-devel@ takes a non-trivial amount
of time for you, may I suggest that you filter them out?

As for the assessment of how productive my efforts are – please
don’t; I’m perfectly capable of doing that myself.

 > the actual maintainer has actually fixed the dependency problem
 > (a one line change in the control file)

From whence I’ve found it adequate to probe if an effort to fix
the apparent violation of Policy 9.11 (quoted below) would be
appreciated.

  […]  However, any package integrating with other init systems must
  also be backwards-compatible with sysvinit by providing a SysV-style
  init script with the same name as and equivalent functionality to any
  init-specific job, as this is the only start-up configuration method
  guaranteed to be supported by all init implementations.

  — http://debian.org/doc/debian-policy/ch-opersys.html#alternate-init-systems

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Ivan Shmakov]

>>>>> Jonathan Dowland  writes:
>>>>> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:

 >> It can be argued that libgpgme11 does not “provide a significant
 >> amount of functionality” (7.2) without gnupg.

 > It won’t function at all without gnupg.

As I’ve said before, having libgpgme11 installed enables me to
install (neo)mutt.  It’s all the functionality that I need from
that package.  If you know of a way to install the latter without
also installing the former – I’d appreciate if you’d share.

(There’s of course an easy way to install libgpgme11 without
installing gnupg, which is via the equivs package.)

 >> However, and it seems to be a common practice in Debian, for a
 >> shared library package that ‘functionality’ can be understood first
 >> and foremost as /allowing the packages dependent on said shared
 >> library package to run correctly./  (The ubiquity of said practice
 >> is evident from how libmariadbclient18 does /not/ depend on MariaDB

 > That’s because a MariaDB client can be installed on a different
 > machine to a MariaDB server.

Or not; it’s perfectly sensible to install libmariadbclient18
on one host and have no MariaDB server running anywhere at your
site.  It’s something I’ve been doing since before it was called
‘MariaDB.’

Similarly for, say, libaudio2: it was quite a while ago that
I ran nasd(1), but I still have the library installed – simply
because it allows me to install mpg123.  Or libavahi-client3,
libdbus-1-3, libpulse0, and probably several other packages
I cannot recall the names of right noow that I’m not interested
in running the respective servers for anywhere on my network.

[…]

 > The same is not true for libgpgme11.

I beg to differ, per the above.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Ivan Shmakov]

>>>>> Andrey Rahmatullin  writes:
>>>>> On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote:

 >>> "Every package must specify the dependency information about other
 >>> packages that are required for the first to work correctly."
 >>> Policy 3.5.

 >> The gnupg package is not required for (neo)mutt to work correctly,
 >> at least as of Debian Stretch.

 > That's why neomutt only Suggests gnupg.

Arguably, libgpgme11 should do the same.

It can be argued that libgpgme11 does not “provide a significant
amount of functionality” (7.2) without gnupg.  However, and it
seems to be a common practice in Debian, for a shared library
package that ‘functionality’ can be understood first and foremost
as /allowing the packages dependent on said shared library
package to run correctly./  (The ubiquity of said practice
is evident from how libmariadbclient18 does /not/ depend on
MariaDB, or how libxt6 does /not/ depend on an X server package,
and so on, and so forth.)

 >> Could you please clarify your point?

 > I was quoting you and saying that you are contradicting the Policy.

I think I’ve provided sufficient evidence to refute this claim.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: tinysshd dependency on systemd

[Ivan Shmakov]

>>>>> Vincent Bernat  writes:
>>>>> ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :

 >>> so if you were an actual user, I would propose you file a bug
 >>> report against the package to let the maintainer knows the
 >>> dependency is too strong for your use (and maybe propose a patch to
 >>> integrate with inetd).

 >>> As you are not, please, do not.  Our resources are scarce and we
 >>> already cater for the need of many non-existent users.

 >> You know, in almost twenty years of using GNU/Linux, I think it’s
 >> the first time I’m requested /not/ to report bugs and contribute
 >> patches.  How times did change, indeed!

 > Well, reporting bugs about software you don’t care or patches you
 > don’t test is not always useful.  For example, you clearly didn’t
 > test your wrapper (shebang is #!/usr/sh) nor the init script
 > (/lib/init/init-d-script is expecting the daemon to fork.)

Indeed; I even said that much in my posting.  (Meanwhile, one
another issue I’ve found is that the wrapper lacks a trailing
‘exit 1’.)

AFAICT, the init.d script issue can be fixed by adding
START_ARGS=--background there.

 > The maintainer would have to do the testing, possibly the immediate
 > fixes and all the future maintenance.  Just for you to make a point.

I disagree; to the best of my knowledge, anyone can do the
testing and suggest any fixes he or she deems necessary.  As
such, having an issue recorded in the BTS is preferable to not
having it recorded, and having a (semi-correct) patch on file
is preferable to not having any patch at all.

If maintainer decides resolving the issue is not worth the
effort, the (wishlist) bug can stay in the BTS indefinitely.
The maintainer can as well make /that/ a point.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

tinysshd dependency on systemd

[Ivan Shmakov]

>>>>> Vincent Bernat  writes:
>>>>> ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
>>>>> ‘TFH’ == Tollef Fog Heen  writes:

[…]

 TFH> tinysshd only ships a systemd unit file; neomutt links against
 TFH> libgpgme11 which again Depends on gnupg.  It’s the kind of
 TFH> dependencies that individually make sense,

 >> I beg to differ; I suppose (though haven’t actually tried) I can
 >> start tinysshd straight from rc.local just as well, or even write my
 >> own init.d script, right?  Having the dependency in place just makes
 >> it harder to me to contribute an init.d script for the package.

 > tinysshd requires some kind of socket server to run.  It could run
 > from inetd,

Reading tinysshd(8), I see that it can also be started from
tcpserver(8) or BusyBox’ tcpsvd (which doesn’t seem to be
available in Debian yet.)  Or, I suppose, socat(1)?  Say:

# setsid -- socat  TCP6-LISTEN:22,fork \
  EXEC:"tinysshd -v /etc/tinyssh/sshkeydir" & 

Contrary to running from Inetd, the use of the likes of socat(1)
and tcpserver(8) can readily be adapted for an init.d script
(or, rather, init-d-script(5) DAEMON wrapper), which in turn
allows the user to control the daemon with the usual service(8).

Examples (untested) of such a wrapper and a corresponding init.d
script are MIMEd.

 > so if you were an actual user, I would propose you file a bug report
 > against the package to let the maintainer knows the dependency is too
 > strong for your use (and maybe propose a patch to integrate with inetd).

 > As you are not, please, do not.  Our resources are scarce and we
 > already cater for the need of many non-existent users.

You know, in almost twenty years of using GNU/Linux, I think
it’s the first time I’m requested /not/ to report bugs and
contribute patches.  How times did change, indeed!

-- 
FSF associate member #7257  http://am-1.org/~ivan/
#!/usr/sh
### tinysshd-wrapper  -*- Sh -*-
## Run tinysshd via socat(1) or tcpserver(8), whichever is available.

### Ivan Shmakov, 2018

## To the extent possible under law, the author(s) have dedicated
## all copyright and related and neighboring rights to this software
## to the public domain worldwide.  This software is distributed
## without any warranty.

## You should have received a copy of the CC0 Public Domain Dedication
## along with this software.  If not, see
## <http://creativecommons.org/publicdomain/zero/1.0/>.

### Code:

set -e

TINYSSHD=/usr/sbin/tinysshd
SSHKEYDIR=/etc/tinyssh/sshkeydir
PORT=22
PREFERENCE="socat tcpserver"

test  -r /etc/default/tinysshd-wrapper \
&& . /etc/default/tinysshd-wrapper

run_socat () {
## .
exec socat  TCP6-LISTEN:"$PORT",fork \
EXEC:"$TINYSSHD -l -v $SSHKEYDIR"
}

run_tcpserver () {
## .
exec tcpserver -HRDl0 0.0.0.0 "$PORT" \
"$TINYSSHD" -v "$SSHKEYDIR"
}

for p in ${PREFERENCE} ; do
type "$p" > /dev/null || continue
## .
run_"$p"
done

printf %s\\n "FATAL: Neither of ${PREFERENCE:-(none?)} are available" >&2

### tinysshd-wrapper ends here
#!/lib/init/init-d-script
### BEGIN INIT INFO
# Provides: tinysshd
# Required-Start:	$remote_fs $syslog
# Required-Stop: 	$remote_fs $syslog
# Default-Start: 	2 3 4 5
# Default-Stop:  	0 1 6
# Short-Description:minimalistic (subset of) SSHv2 server
### END INIT INFO
DESC="minimalistic (subset of) SSHv2 server"
DAEMON=/usr/sbin/tinysshd-wrapper

Re: no{thing} build profiles

[Ivan Shmakov]

>>>>> Andrey Rahmatullin  writes:
>>>>> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
>>>>> Tollef Fog Heen  writes:

 >>> tinysshd only ships a systemd unit file; neomutt links against
 >>> libgpgme11 which again Depends on gnupg.  It’s the kind of
 >>> dependencies that individually make sense,

 >> Semantically, Depends: declares that the package has to be installed
 >> to proceed.  It doesn’t specify whether the package has to actually
 >> be used.  Which kind of invalidates the point.

 > "Every package must specify the dependency information about other
 > packages that are required for the first to work correctly."  Policy 3.5.

The gnupg package is not required for (neo)mutt to work
correctly, at least as of Debian Stretch.

There’s evidence that neither is systemd required for tinysshd,
although I haven’t tested that myself.

 > "The Depends field should be used if the depended-on package is
 > required for the depending package to provide a significant amount of
 > functionality."  Policy 7.2.

Also doesn’t apply; I’ve used stretch/mutt alongside a dummy
‘Provides: gnupg (= 2.0)’ package rather extensively without
encountering any ill effects.  At the same time, tinysshd(8)
provides examples on how to run the daemon via tcpserver(8) and
inetd(8) (and hence without systemd.)

Could you please clarify your point?

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: Debian Buster release to partially drop non-systemd support

[Ivan Shmakov]

> Ian Jackson  writes:
> KatolaZ writes:

 >> The problem that spurred this thread is that sysvinit needs a
 >> maintainer.  That’s why some of us are here: our intention is to
 >> help with maintaining sysvinit in Debian if possible, since we will
 >> keep maintaining it in Devuan nevertheless.

 > Thank you.  That would be awesome.

Indeed; I’m going to seize this opportunity to express my
gratitude to those who now volunteer to take care of sysvinit
and related packages in Debian!  And I’m looking forward to
contribute to the effort myself.

[…]

 > Please come to debian-init-divers...@chiark.greenend.org.uk.

Do you plan to also make that list accessible via NNTP (perhaps
via either Gmane or the bofh.it gateway operated Marco d’Itri)?

TIA.

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Re: no{thing} build profiles

[Ivan Shmakov]

> Sune Vuorela  writes:
> On 2018-10-21, Jonas Smedegaard  wrote:
> Tollef Fog Heen  writes:

[I see I’ve managed to botch References: for the
news:linux.debian.devel readers; my apologies for that.]

 >>> tinysshd only ships a systemd unit file; neomutt links against
 >>> libgpgme11 which again Depends on gnupg.  It’s the kind of
 >>> dependencies that individually make sense,

I beg to differ; I suppose (though haven’t actually tried) I
can start tinysshd straight from rc.local just as well, or even
write my own init.d script, right?  Having the dependency in
place just makes it harder to me to contribute an init.d script
for the package.

Semantically, Depends: declares that the package has to be
installed to proceed.  It doesn’t specify whether the package
has to actually be used.  Which kind of invalidates the point.

 >>> but where libgpgme11 should probably have a Recommends: gnupg, not
 >>> Depends.

 >> I disagree that libgpgme11 should depend/recommend/suggest gnupg
 >> at all: As a library it cannot possibly declare how tight a
 >> relationship to declare - instead, all _consumers_ of the library
 >> must declare whether they depend/recommend/suggest gnupg.

I suppose I can agree with that.  AFAICR, the libgpgme11
maintainer was concerned that some of the users of the library
may break if gnupg is not available.  (Investigating that is
still in my to-do list.  Don’t hold your breath, however.)

 > libgpgme is completely useless without gnupg.

In the context of the present discussion, the libgpgme11 package
/is/ useful even in absence of gnupg: it allows neomutt to be
installed.  Much like libmariadbclient18 allows me to install
exim4-daemon-heavy, and libxt6 does the same for mpg123.

The fact that I’m not interested in transparent OpenPGP support
under NeoMutt, or that I don’t typically run mpg123(1) under X
(much less use NAS for audio output), or that I never use MariaDB
at all, – is utterly irrelevant.

 > I think it is perfectly fine for these kind of relations, unless we
 > really are in corner-case territory.  See for example fam.

Could you please elaborate on that?

-- 
FSF associate member #7257  np. Cybernoid 2 Piano Live — Noviello Pippo

no{thing} build profiles

[Ivan Shmakov]

> Bastian Blank  writes:
> On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt  writes:

 >>> Should Debian also support “noalsa”, “noavahi”, “nocups”,
 >>> “nopulseaudio”, “nosysvinit”, “nodbus”, “nopam”, “nowayland”,

So long as there’s sufficient interest among the developers?
Sure, why not?

 >> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland
 >> all similar in scope to systemd?  If not, then this question is a
 >> strawman.

 > Yes, they all completely took over their field and have a lot of haters.

AFAICT, that’s, for the most part, untrue.  For instance, I do
/not/ run Avahi (why for?), Cups (I use an ad-hoc wrapper around
foo2zjs instead), Pulseaudio (for there’s ALSA, but also NAS and
JACK should I need them), D-Bus (although I admit I’ve had to
implement a “no-dbus.perl” stub non-server to work around
Bug#868453), or Wayland (huh?)  And I suppose those who run
Systemd don’t run SysVinit just as well.

Granted, I know of no way to use audio on Debian GNU/Linux without
ALSA; and I know of no way to avoid running PAM, either.

Now, unless I be mistaken, “build profiles,” as suggested in
this subthread, are meant to allow for building packages with
specific changes to their run-time library dependencies?
Frankly, I don’t see much of a problem with that – assuming that
the libraries are “well-behaving,” that is.  I can see an
application's run-time dependency on the presence of client
PostgreSQL, MySQL and MS SQL libraries at run-time as necessary
evil.  Having that application pull one or more of the respective
servers per Depends: is something I tend to consider a bug.

(BTW, while we're at it, could someone please explain me what
tinysshd [1] does need systemd for?  Or why installing neomutt
has to invite gnupg along?)

[1] http://packages.debian.org/sid/tinysshd

-- 
FSF associate member #7257  np. Green Beret (title theme) — Johan Andersson

Re: debian/control file: how to selectively suppress recommends?

[Ivan Shmakov]

> Marcel Partap  writes:

 > Dear fellow Debianauts, right now I am in the process of migrating my
 > selection of manually installed packages to a freshly debootstrapped
 > install using a set of meta-packages built with equivs.  While that
 > works nice and well, in some instances, I would like to limit the
 > number of recommends being pulled in, without turning recommends off
 > completely (the meta-packages themselves use
 > Recommends:dependencies).  So the --no-install-recommends parameter
 > or APT::Install-Recommends "0" are of no help in this case.  Any
 > ideas how to block installation of only some packages'
 > recommendations?

Use apt_preferences(5)?  Like, say:

$ cat < /etc/apt/preferences.d/thanksbutnothanks.pref 

Explanation: Certain packages are not welcome here.
Package:
 systemd-sysv upstart
 dbus dbus-x11 gconf-service
 ssl-cert
 acpi-support-base tsconf
Pin: release c=main
Pin-Priority: -42

$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB

Re: make dpkg-buildpackage default locale UTF-8

[Ivan Shmakov]

>>>>> Tollef Fog Heen <tfh...@err.no> writes:
>>>>> Ivan Shmakov
>>>>> Hans-Christoph Steiner <h...@eds.org> writes:

 >>> Package: dpkg-dev

 >>> More and more packages are adding unicode files

 >> I assume you mean “UTF-8 filenames” here (per below), right?

 >>> as unicode support has become more reliable and available.

 >> What are the use cases for such filenames?

 > Accurate representation of what they contain.  wnorwegian contains a
 > file «bokmål» which is the word list for the form of Norwegian known
 > as bokmål.  There's a convenience link between it and bokmaal so that
 > people without Norwegian keyboard (or without compose keys) can type
 > it too, but the canonical name is bokmål, not bokmaal.

It does indeed seem natural, when it comes to packages providing
support for a specific language, to use filenames in that same
language; I’m not going to strongly object to that.  However,
I’d like to note that other wordlist packages appear to stick to
English (and ASCII) filenames.  For instance, wfrench uses
‘french’ (instead of français) and witalian uses ‘italian’
(instead of italiano.)

At the same time, were these files intended for mainly ‘machine’
use, I guess I’d rather prefer them to stick to ISO 639 instead.
Just like the ‘locale’ system already does.

I’m still curious, are there any other uses in the archive
beside the above?

 > (I see there's a small bug where the symlink is the wrong way around,
 > I'll get that fixed.)

 > å is in latin1, though so fonts should not be a problem in your
 > particular case.

Yes.

-- 
FSF associate member #7257  np. Graceful Flame — Radiarc   3013 B6A0 230E 334A

Re: make dpkg-buildpackage default locale UTF-8

[Ivan Shmakov]

> Hans-Christoph Steiner  writes:

 > Package: dpkg-dev

 > More and more packages are adding unicode files

I assume you mean “UTF-8 filenames” here (per below), right?

 > as unicode support has become more reliable and available.

What are the use cases for such filenames?

FWIW, I more than just occasionally use Debian in environments
with fonts lacking good (as in: ≥ 90%) Unicode, or even BMP,
coverage.  (Specifically, I’m for the most part interested in
Latin-1, -3, and Cyrillic characters only.)

Do you suggest that there’re filenames in Debian packages that
cannot be rendered in such environments?  If so, that’d
certainly be a nuisance for me.

 > The package building process is not guaranteed to happen in a unicode
 > locale since the Debian default locale is LC_ALL=C, which is ASCII
 > not UTF-8.  Reading UTF-8 filenames when the system is using ASCII
 > causes errors (Python makes them very visible, for example).

[…]

-- 
FSF associate member #7257  np. Fear of the Dark — Iron Maiden  B6A0 230E 334A

Naming of network devices

[Ivan Shmakov]

> Marvin Renich  writes:

[…]

 > The only benefit I have seen between the new scheme and the previous
 > one is that there is no state file.  While getting rid of the state
 > file is a nice goal, it is extremely minor compared to having short,
 > simple names in common use cases like inserting a wifi usb dongle.

 > And no, enp2s0f1 is neither short nor simple.  It requires
 > remembering three numbers and three letters that identify internal
 > parts of the hardware hierarchy that are irrelevant to the sysadmin.

 > With the previous scheme, an interface would be assigned a short,
 > simple name the first time it was seen.  The sysadmin could easily
 > edit the state file to give it a more meaningful name, if desired.
 > The state file already had all the other information needed to
 > identify the interface; a simple one-word change in the file was
 > sufficient.  Whatever name was in the state file was used for that
 > piece of hardware from then on.  The names were at least as
 > predictable as they are with the new scheme.

Somewhat recently I’ve got a bunch of nearly identical servers
to care about.  With the /persistent/ (pre-Stretch) interface
names, were I to, say, move an HDDs from one box and into
another, I'd likely to end up with some “new” ethN interface
names unaccounted to in interfaces(5), and possibly other
places.  Some manual intervention would be required.

With the /predictable/ (Stretch) interface names, I’d get a
fully operational system outright.

I admit that the new scheme makes considerably less sense for
the cases where you have /no/ spare identical hardware.

(As such, I’ve added a -persistent-net.rules to the udev
configuration on my few new Debian installs.)

 > With the new scheme, if I want to rename the interface to something
 > more meaningful, I have to go find an older machine that already has
 > a persistent-net.rules file or read through a lot of documentation to
 > figure out the correct syntax.  I then have to determine the correct
 > ATTR elements to identify the interface in question, and type all of
 > that information by hand, hoping I type everything correctly.

I concur that there ought to be some more user-visible
documentation concerning the differences and how to get the
behavior the user desires.

 > There is an easy fix to revert the default behavior while still
 > allowing knowledgeable sysadmins to get the new behavior.  On the
 > other hand, those who need to administer systems but are not
 > sysadmins by trade (and thus will have to do significantly more
 > research to even know that the older behavior is possible) are the
 > ones who need the older behavior as the default.

-- 
FSF associate member #7257  np. Home (Instrumental) — Jeff Burgess   230E 334A

Recommends-If-Manual: ?

[Ivan Shmakov]

>>>>> Russ Allbery <r...@debian.org> writes:
>>>>> Ivan Shmakov <i...@siamics.net> writes:
>>>>> Adam Borowski <kilob...@angband.pl> writes:

 >>> libtasn1-doc: libtasn1-6-dev

 >>> * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
 >>> pulled in by a very-widespread library (gnutls)

 >> That’s Abstract Syntax Notation One (or ASN.1), and while I use it
 >> all the time (notation, that is; not this specific library at the
 >> moment), I see no reason for a -dev package to depend on a -doc one
 >> any stronger than with a mere Suggests:.

 > We have some specific Policy about this:

 > https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional

[…]

 > package should declare at most a Suggests on package-doc.  Otherwise,
 > package should declare at most a Recommends on package-doc.

 > If you feel that this should cap the dependency at Suggests across
 > the board, feel free to submit a bug against debian-policy.

Actually, no, “transitively bad” above seems like a correct
assessment.

While I dislike adding any more complexity to APT dependencies,
can there perhaps be a separate Recommends-If-Manual: list of
packages to only be installed when the depending package is
marked as manually installed (as per apt-mark(8); and when
recommended packages are otherwise considered for installing, as
per APT::Install-Recommends)?

To ensure backward compatibility, this condition would have to
also apply for the packages also in the Recommends: list.
Moreover, for one release cycle, any packages with
Recommends-If-Manual: would have to have that same dependencies
duplicated in Recommends: as well.

[…]

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: Too many Recommends (in particular on mail-transport-agent)

[Ivan Shmakov]

> Adam Borowski  writes:
> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:

 >> Maybe someone has a list of things they view as Recommends inflation
 >> that have (a) been reported as bugs to the appropriate package
 >> maintainers, and (b) have been rejected by those package
 >> maintainers?  Those are the controversial ones that we'd need to
 >> talk about.

[…]

 > bash-completion: bash dput-ng licensecheck

 > * DEBATABLE: I like the Tab key to do something reasonable,
 > "bash-completion" means you never know what you'll get.

FWIW, I agree wholeheartedly with this one.  (The only reason I
don’t have ‘complete -r’ in my ~/.bashrc is that bash-completion
is rarely if ever installed on the systems I frequently use.)

[…]

 > freedoom | game-data-packager: prboom-plus

 > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets
 > missing for running pretty much anything Doom-related (and AFAIK its
 > license forbids add-ons).  On the other hand, this is an excuse for
 > Doom engines in main.

The latter seems like a good enough reason for this dependency.

 > freepats: libwildmidi-config timidity

 > * BAD: freepats is too ugly to live: abysmal quality, lacks
 > instruments for pretty much any .mid file in the wild.  We do have a
 > bunch of good alternatives.  timgm6mb-soundfont for one is 5.6 times
 > smaller yet is complete.

Probably a relic of the days long gone; I guess it should be
updated to include some more alternatives (in preference to
freepats) – so long as timidity can (be made to) actually use
any of them “out-of-box.”

Package: freepats
Version: 20060219-1
…
Description-en: Free patch set for MIDI audio synthesis
…
 It is, however, the sole DFSG-compliant patch set in existence so far.
 New patches (including those in better formats, such as SF2 SoundFont banks)
 are welcome.

[…]

 > gfortran-mingw-w64: gcc-mingw-w64

 > * BAD: seriously, Fortran?

Fortran is still widely used (in niche applications; WRF comes
to mind), but I see no good reason for this dependency.

 > ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm

 > * BAD: why would editing images care about a grossly obsolete
 > _document_ format?

So that one can $ convert  pic.ps pic.png?  Or (I suspect)
$ convert  file.pdf file.png, for that matter.

(Or perhaps more sensibly: $ display  pic.ps pic.pdf.)

Moreover, PostScript is a programming (code) language – not a
(data) format.

I’m neutral on this dependency, though.  I do like PostScript
for a document format as much as I do like JavaScript for the
same, but I see how it may be nice to support .ps (and .pdf?)
rasterization in ImageMagick and Gimp “out-of-box.”

[…]

 > gnat-mingw-w64: gcc-mingw-w64

 > * BAD: see Fortran.

Agreed.

 > gnupg-l10n: gnupg

 > * DEBATABLE: I don't think anyone tech skilled enough to use GPG
 > would have problems with English, but localization is important.
 > On the other hand, this is 4.5MB in the default install.

Well, ‘locales’ is about 9 MiB in the same, so…

[…]

 > libhtml-format-perl: libhtml-tree-perl libwww-perl

 > * : wut?

… Me neither.

 > libhttp-daemon-perl: libwww-perl

 > * TRANSITIVELY BAD: dependency comes from a client package; if I want
 > to run a http server I know where to find it

That’s only Installed-Size: 71, so I don’t see much of a
problem.  AIUI, libwww-perl (as per upstream) had the
HTTP::Daemon library for decades, thus not installing one by
default in Debian may easily surprise an unsuspecting user.

[…]

 > libpackage-stash-xs-perl: libpackage-stash-perl

 > * TRANSITIVELY BAD: dependencies pulling more dependencies, why?

I suppose that’s so one’s Perl script can be Architecture: all,
instead of depending on either pure-Perl or an XS (binary)
implementation of the package – depending on the architecture.

[…]

 > libpurple-bin: libpurple0

 > * BAD: a library has no reason to install programs

My exact reaction on seeing that Mutt transitively Depends: on
GnuPG – all thanks to libgpgme11 depending on the latter.

I do not know about this specific case, but I very much agree
with the principle.

[…]

 > libtasn1-doc: libtasn1-6-dev

 > * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
 > pulled in by a very-widespread library (gnutls)

That’s Abstract Syntax Notation One (or ASN.1), and while I use
it all the time (notation, that is; not this specific library at
the moment), I see no reason for a -dev package to depend on a
-doc one any stronger than with a mere Suggests:.

[…]

 > transfig: inkscape

 > * BLOAT: a badly obsolete image format, pulls in ghostscript and
 > other crap

Curiously enough, I still find 

Re: when should we esmtps our mxes?

[Ivan Shmakov]

>>>>> Ben Hutchings <b...@decadent.org.uk> writes:
>>>>> On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote:
>>>>> Ben Hutchings <b...@decadent.org.uk> writes:

[…]

 >>> Those certificates look as expected.  Since TLS encryption of SMTP
 >>> between servers is opportunistic, there's no particular reason to
 >>> use a widely trusted CA for server certificates.  A MITM can just
 >>> as easily block STARTTLS as substitute their own key.

My point is: the absence of ‘TLS’ in Received: is a cleaner
indication of the possible tampering of the message.  On the
contrary, its presence in the headers and (or) MX logs may turn
to be misleading when the sending side routinely disregards the
absence of a valid signature on the certificate.

The “opportunisticity” of ESMTPS does not seem relevant.

 >> That’s not necessarily any different to the HTTP(S) case.

 >> For instance, when the user first uses ‘example.com’ as the resource
 >> identifier, the Web user agent (usually) issues a GET request to the
 >> said host’s HTTP server in the plain.  At which point the server
 >> responds with a 302 redirect, pointing to the resource proper (say,
 >> https://example.com/.)

 >> That behavior is hardly any less opportunistic, and is prone to the
 >> very same attack, as demonstrated by ‘sslstrip’.

 > Although that's mitigated by HSTS and bookmarking of https: URLs.

It’s been argued that, as all the CAs are trusted equally (if at
all) by the user agent, it makes sense to minimize the number of
CAs trusted by any specific user – so to reduce the “attack
surface” – and, if necessary, rely on “security exceptions”
instead for the HTTPS sites that use X.509 certificates signed
by marginal (with respect to that same specific user) CAs.

Obviously, implementing RFC 6797 “No User Recourse” provision to
the letter makes that impossible.  Now, given that it seems way
easier to disable HSTS support altogether in the user agent than
to patch one up to get some more sensible behavior…

That said, I see no reason there can’t be some STRICTSECURITY
EHLO keyword, analogous in function to the HSTS header.
Of course, so long as non-TLS ESMTP remains functional –
something that, unfortunately, gradually goes away for HTTP.

[…]

PS.  Now, it makes me wonder, since when are we standardizing
applications to give more heed to the whims of the remote’s
administrator than to the application’s own user?  Free software
used to be better than that; or so I recall.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: when should we esmtps our mxes?

[Ivan Shmakov]

> Ben Hutchings  writes:

[…]

 > Those certificates look as expected.  Since TLS encryption of SMTP
 > between servers is opportunistic, there's no particular reason to use
 > a widely trusted CA for server certificates.  A MITM can just as
 > easily block STARTTLS as substitute their own key.

That’s not necessarily any different to the HTTP(S) case.

For instance, when the user first uses ‘example.com’ as the
resource identifier, the Web user agent (usually) issues a GET
request to the said host’s HTTP server in the plain.  At which
point the server responds with a 302 redirect, pointing to the
resource proper (say, https://example.com/.)

That behavior is hardly any less opportunistic, and is prone to
the very same attack, as demonstrated by ‘sslstrip’.

Yet, I’d find that quite an uncommon reason to argue that we
don’t need some widely trusted CAs for the HTTPS certificates.

On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’
files that contain the list of CNs of the remotes the MTA
permits relaying mail from (that is: acts as a smarthost for.)
Hence, TLS becomes rather mandatory in this case.  (Although I
have to admit that I don’t currently apply this approach in the
“downstream” direction with any consistency.)

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: when should we esmtps our mxes?

[Ivan Shmakov]

>>>>> Julien Cristau <jcris...@debian.org> writes:
>>>>> On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote:

[…]

 >> Speaking of which.  Does the gnutls-cli transcript MIMEd signify of
 >> an ongoing MitM attack, or is it just a misconfiguration?

 > Neither.

 > _25._tcp.bendel.debian.org. 3600 IN RRSIG TLSA 8 5 3600
 > 20161202211237 20161023203831 7866 debian.org.
 > uCQU3vi1LA/bhjW51xETwZn3wWsLPFUvvW4BU1uUE8uJqzsQTdzNBWgW
 > +aIE9gOphLZ+zMdni/16QvAV8FWqJ77RZm5RoZFBZ9NbvF/OBgYqlKx/
 > NpR79goHcI6NHMezAh6BF3PEE3gQjogAXlA9pLhf8hVyQh117sLHyVPt
 > sc/d+mJv9CTCiwSUqiG/e3V0je2dt7SpIcI+uxDL/pe/6dt3qSOE5hpH
 > xtvG1xaoYcF1UWGMP12j8LIK2V+sNRbq

 > _25._tcp.bendel.debian.org. 3600 IN TLSA 3 1 1
 > 7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D234

Makes sense, thanks.

Although I gather I won’t be seeing it actually working with my
MX anytime soon.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: when should we esmtps our mxes?

[Ivan Shmakov]

>>>>> Andrey Rahmatullin <w...@debian.org> writes:
>>>>> On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote:

 >> $ gnutls-cli --starttls -p 25 bendel.debian.org 

[…]

 >> Connecting to '82.195.75.100:443'...

 > I cannot reproduce gnutls-cli connecting to :443 when asked :25.

Indeed, my mistake; I somehow managed to MIME the wrong
transcript.  Here’s the correct one.

[…]

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A
Processed 173 CA certificate(s).
Resolving 'bendel.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:25'...

- Simple Client Mode:

220 bendel.debian.org ESMTP Postfix
EHLO test 
250-bendel.debian.org
250-PIPELINING
250-SIZE 3072
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
STARTTLS
220 2.0.0 Ready to start TLS
*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer 
`C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 
UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194'
Public Key ID:
a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61
Public key's random art:
+--[ RSA 2048]+
| |
|.|
|   . +.  |
|+ =  . . |
|   +S+. .|
|  o+.   .E  .|
| ...+  oo... |
| .+oo..  |
|.o.ooo.++.   |
+-+

- Certificate[1] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian 
SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh 
Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 
UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

when should we esmtps our mxes?

[Ivan Shmakov]

> Kristian Erik Hermansen  writes:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk  wrote:

[…]

 >> For the kind of attacks you are describing, https is just snake oil.

 > Profusely disagree and so do other members of this list.  I'll leave
 > it at that, but also I should point out that your email is being
 > routed insecurely via welho.com and lacks TLS in transit, so I also
 > probably shouldn't consider your TLS knowledge very highly…

Speaking of which.  Does the gnutls-cli transcript MIMEd signify
of an ongoing MitM attack, or is it just a misconfiguration?

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A
$ dig +nocomment mx lists.debian.org 
…
lists.debian.org.   3600IN  MX  0 bendel.debian.org.
…
$ gnutls-cli --starttls -p 25  bendel.debian.org 
Processed 173 CA certificate(s).
Resolving 'bendel.debian.org'...
Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:443'...
Connecting to '82.195.75.100:443'...

- Simple Client Mode:

*** Starting TLS handshake
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer 
`C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 
UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194'
Public Key ID:
a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61
Public key's random art:
+--[ RSA 2048]+
| |
|.|
|   . +.  |
|+ =  . . |
|   +S+. .|
|  o+.   .E  .|
| ...+  oo... |
| .+oo..  |
|.o.ooo.++.   |
+-+

- Certificate[1] info:
 - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian 
SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh 
Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP 
CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using 
RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 
UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5'
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** Handshake has failed

Re: client-side signature checking of Debian archives

[Ivan Shmakov]

> Eugene V Lyubimkin  writes:

[…]

 > I'm not sure that benefits outweigh the costs.  HTTPS requires that
 > I trust the third-parties – mirror provider and CA.  Gpgv doesn't
 > require third parties.

It does; you have to trust whatever source you’ve /initially/
got the public key from.  Also, TLS does /not/ actually preclude
the user from comparing the remote’s key with a copy stored
locally.  For Firefox/HTTPS, the respective functionality could
be found in the Certificate Patrol add-on [1], for instance.

 > To me, that makes HTTPS (even with HPKP) principally weaker than
 > offline medium-agnostic cryptographic content checks.  Or I am wrong
 > here, will the suggested HTTPS+HPKP+… scheme protect me from
 > government players?

My understanding is that the suggestion being discussed is to
use TLS /alongside/ the usual Debian/APT signatures – not
instead of them; and the primary goal is to improve user’s
privacy.  That is: only the mirror operator will remain
empowered to know the packages the user’s interested in.
(As opposed to: the operators of all the networks the APT HTTP
request passes through.)

My concerns would be along the lines of [2] (“Remember that all
mirror sites are donated to Debian: the hardware, […], and the
sysadmin work to keep it running.”)  Specifically, a plain-HTTP
server is easier to configure and maintain.  For one thing, when
your server does /not/ use TLS, you don’t need to be concerned
with the bugs and vulnerabilities of any TLS library whatsoever.

[1] http://patrol.psyced.org/
[2] 
https://lists.debian.org/msgid-search/20161017142819.72lbe3kh346c4h62@exolobe3

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: non-Debian software on ftp*.*.debian.org mirrors

[Ivan Shmakov]

>>>>> Lars Wirzenius <l...@liw.fi> writes:
>>>>> On Sun, Oct 16, 2016 at 11:50:46AM +, Ivan Shmakov wrote:

 >> Doesn’t the presence of the ‘non-free’ section in the official
 >> Debian Release (InRelease) files /already/ mislead inexperienced
 >> people into thinking that such software is either part of Debian or
 >> endorsed by the project (or both)?

 > https://www.debian.org/social_contract point 5.

 > We're not exactly unclear about non-free and contrib.

I'd say that those who can discern Debian non-free from Debian
proper are at low risk of confusing, say, [1] with the "software
[...] endorsed or even produced by Debian."

[1] http://ftp.se.debian.org/mirror/opensolaris.com/

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

non-Debian software on ftp*.*.debian.org mirrors

[Ivan Shmakov]

> Jakub Wilk  writes:

[…]

 > On a semi-unrelated note:

 > Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and
 > sometimes non-free) software that is not Debian[*].  This may mislead
 > inexperienced people into thinking that this software is endorsed or
 > even produced by Debian.  Should we insist that only Debian is served
 > from these domains?

 > [*] See e. g.: https://ftp.se.debian.org/

Ahem.  Speaking of non-Debian software…

$ head < ftp.debian.org/debian/dists/stable/Release 
Origin: Debian
Label: Debian
Suite: stable
Version: 8.6
Codename: jessie
Date: Sat, 17 Sep 2016 11:38:03 UTC
Architectures: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x
Components: main contrib non-free
Description: Debian 8.6 Released 17 September 2016
MD5Sum:
$ 

Doesn’t the presence of the ‘non-free’ section in the official
Debian Release (InRelease) files /already/ mislead inexperienced
people into thinking that such software is either part of Debian
or endorsed by the project (or both)?

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows

[Ivan Shmakov]

 Axel Wagner m...@merovius.de writes:

[…]

  I don't think Lennart personally would care, no, but I think *we*
  should care to paint the Opensource community as better than this.

As a member of the said community, I think that, however the
presence of either of the packages in Debian paints it, –
I could live with that.

Regarding the possible enhancement of XBill to allow for using a
user-specified set of sprites (whether packaged or not), –
it certainly feels like a proper solution to me.  I guess the
package could then be enhanced to include several such “themes,”
including the “classic” one, the newly proposed one, and perhaps
a few more, depending on the availability and relevance.

  From that point of view, if there was a vote and I'd get a vote I
  would also vote against having xbill in the archive as being a poor
  taste ad-hominem attack (I mean, for crying out loud, there is an
  actually blood-spatter squashing animation in the game, even if it is
  a poor one).  In my opinion it is certainly not an argument to also
  let xlennart in.

While not a full-scale ad-hominem attack, I’d say that the two
differences I know of between the vrms operation and the
official FSF position amount to a misrepresentation at best.
Are we going to drop that package, too?

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
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/87k30mtown@violet.siamics.net

Re: DE features dependent on Systemd

[Ivan Shmakov]

 Vincent Bernat ber...@debian.org writes:
 ❦ 3 décembre 2014 13:55 +0100, Adam Borowski kilob...@angband.pl :

[…]

  This “adduser first-user audio” was already useless in squeeze and
  it hasn’t changed.

  Only if you run logind or consolekit.  Without them (ie, on headless
  boxes or with classic-type WMs) you do need to access the devices
  which are mode 660 root:audio.

  A classic-type WM can make use of logind to get the appropriate ACL
  setup.

  The problem with those groups is that they are not fine grained
  enough.  For example, the video group gives access to the framebuffer
  device (the user can do a screenshot) or to a webcam (the user can
  spy another user).  By encouraging the use of those groups, we create
  big security hole.

Do these security considerations still apply to single-user,
single-seat systems?

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
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/878uioptmy@violet.siamics.net

Re: DE features dependent on Systemd

[Ivan Shmakov]

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

[…]

  We are talking about the anti-feature of adding UID=1000 to the audio
  group in the installer.  This is only relevant for desktop
  installations, and all desktop tasks in the same installer bring
  logind (formerly consolekit).

BTW, what about adding that same user to the ‘sudo’ group (which
D-I does; or formerly did, IIRC)?  Does Logind also take care of
that part nowadays?

  If you configure, by hand, a headless machine or a X session started
  with startx, I’m pretty sure you can also use adduser on your own.

(I guess this means that I should check if the current D-I
supports the likes of an Openbox/XDM-based destkop install?…)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
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/87d280ptrs@violet.siamics.net

Re: DE features dependent on Systemd

[Ivan Shmakov]

 Vincent Bernat ber...@debian.org writes:
 ❦ 3 décembre 2014 16:47 GMT, Ivan Shmakov i...@siamics.net :

  The problem with those groups is that they are not fine grained
  enough.  For example, the video group gives access to the
  framebuffer device (the user can do a screenshot) or to a webcam
  (the user can spy another user).  By encouraging the use of those
  groups, we create big security hole.

  Do these security considerations still apply to single-user,
  single-seat systems?

  Yes.

Namely?

  We don't chmod -R a+rwx / for a good reason.

That makes, like, an order of magnitude difference.

The former allows the machine’s owner access to audio devices
irrespective of /how/ he or she choose to initiate such access.
(Say, I may decide to start ogg123(1) via at(1) to wake me up in
the morning.)  Using Logind there is akin to only allowing user
access to $HOME while being “physically” logged in.  (Or do we
consider that a valid restriction as well?)

On the contrary, the latter would allow for purely accidental
damage to the system, with no big obvious advantages I could
readily think of.

-- 
FSF associate member #7257  np. Satellite 15… The Final Frontier — Iron Maiden


-- 
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/87vblso6o5@violet.siamics.net

DE features dependent on Systemd

[Ivan Shmakov]

 Josselin Mouette j...@debian.org writes:
 Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit :
 Josselin Mouette j...@debian.org writes:

[…]

  Desktops (not only GNOME) use a very tiny bit of systemd,
  interfaces that could be provided elsewhere.

  Is that “use” as in “if available” or is that actually “require and
  be sure to die unless provided”?

  Directly: DEs provide more useful features (especially power
  management) with systemd but will work correctly without.

I see nothing in the ‘apcupsd’ changelog [1] (which is about the
only package related to power management I have installed on my
systems) to suggest it ever having any Systemd integration.

Or does the above concerns the users of “normally
battery-powered” devices instead?

[1] 
http://metadata.ftp-master.debian.org/changelogs/main/a/apcupsd/apcupsd_3.14.12-1_changelog

  Indirectly through PolicyKit: lots of functionality will be missing
  if PolicyKit doesn’t have access to a console management interface.

Specifically?

-- 
FSF associate member #7257  np. Tree of Love — Jami Sieber   … B6A0 230E 334A


-- 
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/87ppc5ngm5.fsf...@violet.siamics.net

Re: DE features dependent on Systemd

[Ivan Shmakov]

 Vincent Bernat ber...@debian.org writes:
 ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov i...@siamics.net :

[…]

  Or does the above concerns the users of “normally battery-powered”
  devices instead?

  Previously, every DE would need to reimplement power management.
  Now, this is handled by systemd (and hence not by the DE anymore).
  Without any special configuration, closing the lid of a laptop will
  put it to sleep except if there is still an active user on an
  external display.

Just to be clear: I do not use any laptops myself.  (Or anything
else I’d need to put to sleep by closing its lid, for that
matter.)

I guess this means that this particular feature is of no use to
me, right?  (And, as a consequence, that I may safely ignore it
when deciding if I should retain my current init.)

[…]

  Indirectly through PolicyKit: lots of functionality will be missing
  if PolicyKit doesn’t have access to a console management interface.

  Specifically?

  PolicyKit rely on logind to know if a user is locally connected.  A
  non-local user won't be allowed things like network management, local
  device mounting or sound card access.

That looks like a problem to solve, not a feature.

For home installs, I see no reason for the owner of the device
to be /denied/ access to the sound card just because of using
SSH.  Why, it’s exactly what I do.  (I even did things like
$ ssh remote ogg123 /dev/stdin  local/file.ogg for various
reasons in the past.)

OTOH, for “workplace” installs, I see no reason for the user to
be /granted/ access to the things like network management just
because he or she happens to be logged in locally, – these
privileges should rather be granted only to the person(s)
responsible for that particular host.  (And then again, – SSH is
a perfectly valid way to access to these facilities.)

IIRC, D-I used to add the first non-root user it creates (which
more or less is bound to happen to be the owner, or the person
otherwise responsible for the host) to a number of groups (like
audio or plugdev) to grant access to certain devices.  I know of
no reason to abandon this practice.

I agree that the issue gets trickier for multiuser hosts, but
I’m pretty sure that there still will be at least one user for
whom no such access restrictions should apply, – irrespective of
his or her “login locality.”

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
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/873890onsa@violet.siamics.net

Re: DE features dependent on Systemd

[Ivan Shmakov]

 Josselin Mouette j...@debian.org writes:
 Le dimanche 30 novembre 2014 à 12:50 +, Ivan Shmakov a écrit :

[…]

  For home installs, I see no reason for the owner of the device to be
  /denied/ access to the sound card just because of using SSH.  Why,
  it’s exactly what I do.  (I even did things like $ ssh remote
  ogg123 /dev/stdin  local/file.ogg for various reasons in the past.)

  PolicyKit does not control access to devices.  The case you pointed
  out is already handled correctly by systemd:

  * Users needing full access can be added to the audio group.

Good to know the support for such groups isn’t going to be
dropped anytime soon.  (Along with, say, SysVinit support.)

  * Other users only have access to audio devices through ACLs when
  physically logged on.

Unless I be mistaken, ACLs are only applied at the time of
open(2).  What about the processes (if any) which opened an
audio device back when it was possible, but are still running at
the time the user logs out?

  OTOH, for “workplace” installs, I see no reason for the user to be
  /granted/ access to the things like network management just because
  he or she happens to be logged in locally, – these privileges should
  rather be granted only to the person(s) responsible for that
  particular host.  (And then again, – SSH is a perfectly valid way to
  access to these facilities.)

  The nice thing about PolicyKit is that it is configurable.  In this
  case, you might want to ship laptops to your users and still allow
  them to switch wifi networks without giving them root access.

Doesn’t “physical access” generally imply “root access”?  At the
very least, it /used/ to be, and if it still is, I’d rather
consider the above a mere inconvenience rather that a security
feature.

  But in the general case, there are things that make sense to forbid
  in a workplace environment.  It just takes a PKLA file to do so.

You’ve mentioned “the principle of least privilege” below; if I
understand your comment there correctly, doesn’t that also mean
that access to, say, network configuration should actually be
explicitly /granted/ (rather than explicitly forbidden)?

  IIRC, D-I used to add the first non-root user it creates (which more
  or less is bound to happen to be the owner, or the person otherwise
  responsible for the host) to a number of groups (like audio or
  plugdev) to grant access to certain devices.  I know of no reason to
  abandon this practice.

  This practice is still here, but it is absurd.

Actually, I have no strong preference on this issue.  I tend to
use a full-weight Debian system when installing Debian (that is:
# debootstrap … /mnt) whenever possible, which happens to be
almost every time.  Hence, I use D-I only occasionally.

Still, if that’s a bug, could you please provide examples of the
categories of users affected?

  It makes the first user created special for no reason,

I guess the reason is that that user is going to be either the
owner for the system, or the person responsible for installing
Debian there.  Why, I seriously doubt that the D-I user would
create an account for some random person at that point.

  failing the principle of least privilege.  If you need permanent
  access to this device or that feature for a given user, you can add
  it to the required groups only if needed.

Yes.

-- 
FSF associate member #7257  np. Coming Home — Iron Maiden 3013 B6A0 230E 334A


-- 
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/87r3wkmykq@violet.siamics.net

Re: Technical committee acting in gross violation of the Debian constitution

[Ivan Shmakov]

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

[…]

  Desktops (not only GNOME) use a very tiny bit of systemd, interfaces
  that could be provided elsewhere.

Is that “use” as in “if available” or is that actually “require
and be sure to die unless provided”?

(Please forgive my ignorance here, – my “desktop” runs Openbox
ever since I’ve switched off TWM c. 2008, and I’m pretty sure
that Openbox does not “use” Systemd or any related services.)

  The real purpose of systemd is to provide a modern init system.

I believe that the word “init” is misleading at best in this
context.

The SysVinit-based system traditionally used in Debian was
indeed /mostly/ concerned with bringing the system up – that is,
“initing” the system.  On the contrary, Systemd seems to try to
also encompass monitoring, time synchronization, user sessions,
and, I presume, a load of other tasks.

If anything, it seems to deserve something like Master Control
Program for its name, – not something as mundane as an “init
system.”

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
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/87a93aotd9@violet.siamics.net

Re: Technical committee acting in gross violation of the Debian constitution

[Ivan Shmakov]

 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:

[…]

  The second part, making systemd portable, has already been widely
  discussed.  There are significant technical reasons why systemd is
  Linux only.  And the potential recepients, like BSD, don't seem to
  be interested anyway.

Unless I be mistaken, that also /does/ mean Debian.  That is:
Debian GNU/kFreeBSD and Debian GNU/Hurd.

Sorry for jumping into this discussion without any thorough
reading, but I have mentioned this point a few times already at
(other) mailing lists and on IRC, so if I got it wrong, I’d like
to be corrected, so that I won’t spread confusion any further.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
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/8761dxq2k7@violet.siamics.net

Re: Technical committee acting in gross violation of the Debian constitution

[Ivan Shmakov]

 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:
 On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote:
 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes:

[…]

  The second part, making systemd portable, has already been widely
  discussed.  There are significant technical reasons why systemd is
  Linux only.  And the potential recepients, like BSD, don't seem
  to be interested anyway.

  Unless I be mistaken, that also /does/ mean Debian.  That is: Debian
  GNU/kFreeBSD and Debian GNU/Hurd.

  Yes, the technical reasons apply.  The other reasons apply too, I
  think: /kFreeBSD and /Hurd ports are interested in staying close to
  their upstream projects and certainly don't have the manpower to take
  on systemd porting on their own.

My point is that Debian is bound to support non-Systemd installs
as long as the two statements below remain true:

• Debian supports non-Linux installs;

• Systemd is Linux-only.

And this is about the only thing about Systemd I do care of.
(Curiously, from this point of view, being only available for
Linux is actually the Systemd feature of most importance to me.)

As for Systemd being the default (on Debian GNU/Linux,
specifically), – I guess I shouldn’t bother.  GNOME is also the
default, but I cannot readily recall ever having it running on
my Debian installs.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


-- 
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/871tolpz7z@violet.siamics.net

[OT] config file formats

[Ivan Shmakov]

 Игорь Пашев pashev.i...@gmail.com writes:
 2012/12/2 Vincent Lefevre vinc...@vinc17.net:

  No, that's not sufficient. You may want relations between key-value
  pair. For instance, if you have a line with a key foo, then a line
  with a key bar must also exist. Or a line with a key number must
  have a value that is a number (more generally matching some regexp).

  For such configs general programming languages are good.

  E. g. perl:

  $foo = wtf;

  if ($foo  !$bar) {

[…]

If and only if such “configuration files” will only /ever/ be
read by Perl-enabled tools.  Which may pose a problem, e. g.,
should a port of the software in question to a resource-limited,
embedded system be considered at some point.

The problem with programming languages is that one can't merely
read a file in such a language, and extract some kind of result
warranted to be sensible.  One has to /execute/ it instead.

(Some extra care is likely to be required for the “privileges'
gate” case as well.)

The same applies to *roff and TeX, BTW.

-- 
FSF associate member #7257


-- 
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/86hao4xod6.fsf...@gray.siamics.net

[OT] config file formats

[Ivan Shmakov]

 Vincent Lefevre vinc...@vinc17.net writes:
 On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote:
 On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote:

[…]

  You may want relations between key-value pair.  For instance, if
  you have a line with a key foo, then a line with a key bar must
  also exist.  Or a line with a key number must have a value that
  is a number (more generally matching some regexp).

  That's not validation of the format, that's validation of the data.

  That's validation of the config file.  This is what XML validation
  does: it checks whether the file is valid according to some schema.

That being said, I believe that the reason XML became so
widespread (and, conversely, it's ancestor SGML fell into
disuse) is precisely because the former decoupled the format
(representation, and its inherent semantics) itself from the
validation.  That way, we were able to forgo DTD and develop
such (arguably, much better) XML schema representations such as
XML Schema and RELAX NG.  (The latter is the one used by Emacs.)

I'm not aware of any “standard” schema representations for the
(sectioned) key-value file formats, however.

  I've never seen any config file with nested config blocks that
  didn't make the file more complex and less easy to understand.

  Wrong.  Nested blocks make config files easier to understand.
  Otherwise for the same feature (e. g. conditionals), one would need
  things like horrible state variables.  For instance, think about
  redesigning a procmailrc with the ini format...

On the second sight, the difference between, e. g.:

a
  b
cd/c
ef/e
  /b
  g
hi/h
  /g
/a

and, e. g.:

[a.b]
c = d
e = f
[a.g]
h = i

is mostly superficial.

-- 
!DOCTYPE thethe tensible ribbon=campaign /pAdvocating the
judicious use of XML applications on the Internet at large./p/the


-- 
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/868v9fy5rm.fsf...@gray.siamics.net

Re: Maildir vs. mbox in Debian

[Ivan Shmakov]

 Christoph Anton Mitterer cales...@scientia.net writes:

[…]

  But it also has disadvantages to the mbox formats which may be
  crucial for some people:

  - wasting a lot of storage, which can be significant even if you use
  small file systems block sizes...

Only as long as static mbox files are considered.  However,
removing a message from an mbox requires an amount of free space
equal to the size of the mbox in question, sans the message to
be removed.  OTOH, removing a message from Maildir requires no
additional filesystem space.

  - full text search will typically be slower, as one has to open/close
  many files

What are the estimates?  And wouldn't it be better to use some
kind of a specialized search engine if searching is deemed
“crucial”?  I guess that it may render the difference between
the formats somewhat irrelevant.

-- 
FSF associate member #7257


-- 
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/86d2yxyqjj@gray.siamics.net

Maildir vs. mbox in Debian

[Ivan Shmakov]

 Adam Borowski kilob...@angband.pl writes:

[…]

  Quoting from that page:

  # With the advent and now widespread adoption of the superior Maildir
  # format over the past several years, the entire mbox family of
  # mailbox formats is gradually becoming irrelevant, and of only
  # historical interest.

  which is no news.  And you can't really run a mail server in mbox if
  you ever receive mail from business users: for them, sending the text
  as an image wrapped in a Word document is the rule rather than an
  exception[1].

Unfortunately, it's not just the business users.  The so-called
“office productivity suites” are seemingly widespread in
academia and science, for instance.

[…]

  So, what's the reason mbox is still the default in Debian?

That's what I wonder about, too.

[…]

  With current disk sizes, no one should care about a few gigs here, a
  few gigs there.  Unless you need to read a mbox linearly, that is.

Seconded.

JFTR: I've switched my mailservers to Maildir c. 2006, for much
improved performance and manageability, and never had an issue
with that.

-- 
FSF associate member #7257


-- 
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/86haoa18tg.fsf...@gray.siamics.net

Re: [OT] XML

[Ivan Shmakov]

 Jakub Wilk jw...@debian.org writes:
 * Ivan Shmakov oneing...@gmail.com, 2012-11-26, 14:32:

  Seriously, XML takes a lot of concerns off an application
  programmer. It provides quoting, arbitrary hierarchical structure,
  support for different encodings, etc.  Why, don't you think that
  $ grep [[:lower:]]' FILE is ever supposed to work?  For surely it
  isn't: grep has no way to know the encoding of the input file, and
  relies on the locale instead.  On the contrary, XML allows for the
  encoding to be specified explicitly via a processing instruction.
  And then, there's XPath, which takes the input dataset structure
  into account.

  How do you search for a lowercase letter in XPath?

With fn:matches (WHERE, \p{Ll})?

Specifically, if you're interested in all ENTRY elements, whose
respective KEY's contain a lower-case letter, it may look
something like the following:

//x:entry[fn:matches (x:key/text (), \p{Ll})]

For instance, using xqilla(1) (xmlstarlet(1) doesn't seem to
support fn:matches ()):

$ cat  cf.xml 
!DOCTYPE cf
cf xmlns=urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10
  entry
keythere be an all-lowercase key/key
valueall-lowercase key's value/value
  /entry
  entry
keyTHERE BE AN ALL-UPPERCASE KEY/key
valueall-uppercase key's value/value
  /entry
  entry
keyThere be a Mixed-case Key/key
valuemixed-case key's value/value
  /entry
/cf
$ xqilla -i cf.xml \
  (printf %s\\n '\
declare namespace x=urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10;' \
'//x:entry[fn:matches (x:key/text (), \p{Ll})]') 
entry xmlns=urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10
keythere be an all-lowercase key/key
valueall-lowercase key's value/value
  /entry
entry xmlns=urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10
keyThere be a Mixed-case Key/key
valuemixed-case key's value/value
  /entry
$ 

-- 
FSF associate member #7257


-- 
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/86mwy34ojh@gray.siamics.net

[OT] XML

[Ivan Shmakov]

 Norbert Preining prein...@logic.at writes:

[...]

  Ever heard of grep, sed, awk,   all these nice things that make
  your life happy.  Trash them when you are doing XML.

JFTR: there's xmlstarlet(1), which is capable enough to replace
awk(1), sed(1), and grep(1) (which is more often than not gets
mixed with awk(1) and sed(1), even though its functions are
effectively embedded within the former two) on most uses.  And
then, every other high-level language has libraries for XML
processing.  Of which Perl is close enough to Awk to hardly ever
bother learning the latter at all.

Seriously, XML takes a lot of concerns off an application
programmer.  It provides quoting, arbitrary hierarchical
structure, support for different encodings, etc.  Why, don't you
think that $ grep '[[:lower:]]' FILE is ever supposed to work?
For surely it isn't: grep has no way to know the encoding of the
input file, and relies on the locale instead.  On the contrary,
XML allows for the encoding to be specified explicitly via a
processing instruction.  And then, there's XPath, which takes
the input dataset structure into account.  (Care to provide an
example of grepping out the VALUE for KEY of [SECTION]?)

… Oh how I'm glad that there're prominent TeX figures that are
actively using XML nowadays!

I take the point, however, that the XML toolset is not nearly as
mature and complete as that for “plain text.”  It /is/ an issue,
and I hope it will be resolved.  It /is/ reasonable to use the
two-level hierarchial [SECTION] KEY = VALUE format for
configuration files, for it has better readability (as long as
the common tools are considered.)  What is /not/ reasonable is
to label and shun XML for what it's not.

-- 
!DOCTYPE thethe tensible ribbon=campaign /pAdvocating the
judicious use of XML applications at the Internet at large./p/the


-- 
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/86vccs4y6f.fsf...@gray.siamics.net

Re: non-developer packages depending on gettext?

[Ivan Shmakov]

 Neil Williams codeh...@debian.org writes:
 Ivan Shmakov oneing...@gmail.com wrote:
 Neil Williams codeh...@debian.org writes:

[…]

  To note is that Source: gnunet has contrib/report.sh, which calls
  gettext(1), but it doesn't seem to be propagated to any of the
  binaries currently depending on gettext.

  You've misunderstood the gettext packaging.

  $ dpkg -S `which gettext`
  gettext-base: /usr/bin/gettext

  So packages/scripts which call gettext should not depend on gettext
  but on gettext-base instead — that's the point.

The point is that I haven't checked for gettext(1) the first
time I've examined the gnunet source package.  So, even though I
was sure that the dependency on gettext was unwarranted, I
didn't actually rule out gettext-base.

[…]

  Could be worth filing a wishlist bug against lintian because it
  should be quite easy to spot.

  ?  I see no easy way to discern between these three cases (the
  dependency is valid, depend on gettext-base instead, drop the
  dependency altogether.)

  0: Manipulating PO files directly should only happen during package
  builds, so either the package is itself a build tool (like po4a) or
  the dependency goes into Build-Depends.

I understand the logic.  What I can't understand is how to
implement it as a lintian check.  (There isn't really a “this
package is a build tool” flag.  There're Tags:, but they may
be misleading; consider, e. g., gnuplot bearing suite::gnu.)

  1: Depend on gettext-base but not gettext when the package calls
  /usr/bin/gettext, dgettext and/or ngettext directly (all from
  gettext-base) rather than the other executables in the gettext binary
  package which do stuff like manipulating or reporting on PO files.

I don't see an easy way to check for calls to gettext(1), etc.,
either.  Certainly, we can grep the source, but how reliably
(and specific) would that be for a lintian check?

  2: Drop any dependency when no calls to gettext can be found in the
  source and it isn't a build tool.  Languages other than shell have
  in-built ways of using the .mo file prepared through PO and gettext
  to output translated text at runtime.  This has nothing to do with
  running gettext itself.  Languages may also have their own packaging
  support for this, e. g. liblocale-gettext-perl (which itself uses the
  libc support, not gettext-base).

So, at least we could safely warn about a dependency on
gettext-base for a package containing no Shell scripts.

Still, it doesn't seem to rule out a dependency on gettext.

-- 
FSF associate member #7257


-- 
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/86sj91z3vg@gray.siamics.net

Re: non-developer packages depending on gettext?

[Ivan Shmakov]

 Neil Williams codeh...@debian.org writes:

[…]

  Check if the package contains a shell script which supports
  translated output strings — such packages should Depend: gettext-base
  rather than drop the dependency entirely.

  I've had a quick look at gnas and it does seem that this is a case
  where gettext-base is required, but not gettext.

ACK, thanks for the information.

To note is that Source: gnunet has contrib/report.sh, which
calls gettext(1), but it doesn't seem to be propagated to any of
the binaries currently depending on gettext.

  gettext should only be necessary for packages or tasks which
  *manipulate* PO files directly, rather than use the processed .mo
  files to generate translated output.  So, Build-Depends: yes,
  Depends: probably a bug.  gettext-base is only really needed when the
  package provides shell scripts with translated output because those
  evaluate the gettext process at runtime but that only requires
  gettext-base, not gettext.

  Could be worth filing a wishlist bug against lintian because it
  should be quite easy to spot.

?  I see no easy way to discern between these three cases (the
dependency is valid, depend on gettext-base instead, drop the
dependency altogether.)

-- 
FSF associate member #7257


-- 
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/86d30e8mco@gray.siamics.net

non-developer packages depending on gettext?

[Ivan Shmakov]

I find somewhat unusual for the following packages to depend on
gettext, given that the latter is a collection of utilities of
interest primarily to software developers and maintainers (as
stated in its own Description:.)  Could someone please clarify
on this?  TIA.

gnacaudio converter for GNOME
gosaWeb Based LDAP Administration Program
istanbulDesktop session recorder producing Ogg Theora video
poker-web   Web interface to a poker-network server

(I've also filed Bug#690860 against Source: gnunet, which, AIUI,
the maintainer intents to fix by dropping the dependency.)

-- 
FSF associate member #7257


-- 
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/861ugv9hef@gray.siamics.net

Re: Packages removing alternatives on upgrade

[Ivan Shmakov]

 Russ Allbery r...@debian.org writes:

[…]

  It's an improvement.  Guillem makes a good argument that you should
  drop deconfigure as well, which means that:

  if [ $1 = remove ] ; then
  update-alternatives --remove foo path-to-foo
  fi

  is probably the best thing to use right now.

[…]

  (Note that while common, I've never been fond of that case statement
  construction, since it means that we can't introduce new maintainer
  script actions without modifying lots of maintainer scripts that may
  not need to be modified otherwise.)

?  How is the ‘if’ statement above different to, say:

case $1 in
(remove)
update-alternatives --remove foo path-to-foo
;;
esac

-- 
FSF associate member #7257


-- 
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/86wqz1k2nb@gray.siamics.net

Bug#689572: nmu: packages linked against libhdf5-7 1.8.8-7.1

[Ivan Shmakov]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org

There're several packages currently in Debian testing having a
versioned dependency on the semi-virtual libhdf5-7 package
(apparently as the result of being built prior to Source: hdf5
1.8.8-7.1 propagating to testing on 2012-02-23.)

Consequently, these packages cannot be installed along with any
of the other libraries providing libhdf5-7 (check, e. g., [1].)
I'm therefore suggesting re-building these packages against the
now-current libhdf5-7, with binNMU's as specified below.

TIA.

nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 

The hdf-eos5_5.1.14+dfsg.1-1 currently in Debian unstable fixes
the issue (as well as a few others), but unless it's unblocked
(and enters Debian testing), it has to be re-built just as well:

nmu hdf-eos5_5.1.13.dfsg.1-3 . ALL . -m 'Rebuilt against libhdf5-7 = 
1.8.8-7.1' 

[1] http://packages.debian.org/wheezy/libhdf5-7

JFTR, the respective Source: hdf5 Debian changelog [2] entry is:

--cut: 
http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog --
hdf5 (1.8.8-7.1) unstable; urgency=low

  * Non-maintainer upload.
  * Stop building the c++ libraries, nothing uses them.  And don't version the
libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi
packages' Provides.
  * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules.
  * Don't require root for debian/rules clean.

 -- Julien Cristau jcris...@debian.org  Sat, 18 Feb 2012 12:25:35 +
--cut: 
http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog --

The PTS entries for the packages affected are as follows.

http://packages.qa.debian.org/h/hdf-eos5.html
• [2012-02-24] hdf-eos5 5.1.13.dfsg.1-3 MIGRATED to testing
  (Britney)

http://packages.qa.debian.org/libc/libcgns.html
• [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre
  Ledru)

http://packages.qa.debian.org/n/nexus.html
• [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias
  Stefan Richter)

(Although nexus was re-built once as 4.2.1-svn1614-1+b1, it was
on 2012-01-26, thus before hdf5_1.8.8-7.1, and still bearing a
possibly unwarranted versioned dependency on libhdf5-7.)

http://packages.qa.debian.org/r/r-cran-hdf5.html
• [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk
  Eddelbuettel)

http://packages.qa.debian.org/t/tessa.html
• [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette)

http://packages.qa.debian.org/u/udav.html
• [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore
  Bonaccorso)

-- 
FSF associate member #7257


--
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/86txuan2ki.fsf...@gray.siamics.net

Re: where is the DNSSEC root key?

[Ivan Shmakov]

 Philipp Kern pk...@debian.org writes:
 On Thu, Oct 04, 2012 at 03:10:01PM -0400, Chris Knadle wrote:

  Last I looked into this [which has admittedly been a while], Bind 9
  was the only DNS server that had actually implemented DNSSEC, and
  the others I looked at (PowerDNS, djbdns, tinydns) had stated (IIRC)
  that they were /not/ going to be implementing it.

  Obviously there are also recursive resolver implementations, like
  unbound.  To the client they look like DNS servers, too.  (And you
  really want to use one of them on your local machine to do the DNSSEC
  validation.)

  Generally plain servers do not care about the key, it's just the
  recursive resolvers that need it.

To note is that dig(1) (of dnsutils) implements such a resolver
(while not being a DNS server.)  With +sigchase and
+trusted-key=, it's perfectly capable of DNSSEC validation.

  The problem with this idea is that files installed by Debian
  packages must be unique in order to avoid file conflicts between
  packages.  One way around this issue is via 'alternatives'.

  Alternatives don't make sense.  A dedicated packages might make some.

Yes.

Such a package should also include the ISC DNSSEC Look-aside
Validation [1] trusted key, BTW.

[1] https://dlv.isc.org/

-- 
FSF associate member #7257


-- 
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/86pq4xldzz@gray.siamics.net

Re: mass bug filing about versioned dependency on the libhdf5-7 virtual package

[Ivan Shmakov]

 Julien Cristau julien.cris...@logilab.fr writes:
 On Sun, Sep 30, 2012 at 00:28:15 +0700, Ivan Shmakov wrote:

  I tend to think that a re-build (via binNMU or otherwise) will be
  sufficient for most of the packages affected.

  Unless there'll be objections, I'm going to file the respective bug
  reports regarding the versioned dependency on libhdf5-7 against the
  following packages.  (The affected versions and architectures
  [though only amd64 and i386 were tested] are shown, as well as the
  Depends: list items triggering the check.)

  NAK.  If a binNMU is all that's needed then please don't file bugs
  against the packages.  See http://wiki.debian.org/binNMU

ACK, thanks for the pointer!

The problem is that I'm yet unsure whether a binNMU will be
sufficient or not.  My analysis is below, and unless there'd be
objections, I'd be filing a bug against release.debian.org, with
the binNMU entries as follows.

  nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
  nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
  nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
  nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 
  nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 = 1.8.8-7.1' 

AIUI, the packages affected are exactly those built against
pre-1.8.8-7.1 versions of the Source: hdf5 libraries.  That may
explain the versioned dependency, and may be a good indication
for that a binNMU will be sufficient to get the issue fixed.

--cut: 
http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog --
hdf5 (1.8.8-7.1) unstable; urgency=low

  * Non-maintainer upload.
  * Stop building the c++ libraries, nothing uses them.  And don't version the
libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi
packages' Provides.
  * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules.
  * Don't require root for debian/rules clean.

 -- Julien Cristau jcris...@debian.org  Sat, 18 Feb 2012 12:25:35 +
--cut: 
http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog --

As per http://packages.qa.debian.org/, all the packages I've
listed before entered unstable prior to 2012-02-18 (except for
Source: tessa, which was uploaded a couple of days after.)

http://packages.qa.debian.org/libc/libcgns.html
• [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre
  Ledru)

http://packages.qa.debian.org/n/nexus.html
• [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias
  Stefan Richter)

NB: apparently, nexus was re-built once as 4.2.1-svn1614-1+b1 on
2012-01-26 (before hdf5_1.8.8-7.1, and still bearing a possibly
unwarranted versioned dependency on libhdf5-7.)

http://packages.qa.debian.org/r/r-cran-hdf5.html
• [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk
  Eddelbuettel)

http://packages.qa.debian.org/t/tessa.html
• [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette)

http://packages.qa.debian.org/u/udav.html
• [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore
  Bonaccorso)

TIA.

-- 
FSF associate member #7257


-- 
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/86fw5wp27b@gray.siamics.net

[OT] kernel modules

[Ivan Shmakov]

 Eric Valette eric.vale...@free.fr writes:

[…]

  I do not want to compile microcode tool as a module because module
  loading juts slows down the boot process and contrarilly to many
  other package requiring firmware, this one does not enable to load
  firmware when not compiled as a module.

  So it does not work for people compiling their own kernel and not
  using modules (when you tailor your kernel for a given machine,
  modules are just slowing the boot process and do not bring anything).

Unless under very specific circumstances, the use of a modular
kernel brings one the ability to replace the particular hardware
the system runs on at will.

Say, it's possible to replace a just burned motherboard with an
Intel CPU with a different one having an AMD CPU instead.  Or
one may take the HDD holding the system and put it into a wholly
different box, while often retaining the ability to boot.

For these reasons, in the majority of cases, compiling a
non-modular kernel doesn't worth the effort, and may also be
harmful to the system's operation.

-- 
FSF associate member #7257


-- 
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/86txuhqk91.fsf...@gray.siamics.net

Re: Processor microcode update packages

[Ivan Shmakov]

 Henrique de Moraes Holschuh h...@debian.org writes:
 On Fri, 28 Sep 2012, Eric Valette wrote:

  html
head
  
  meta http-equiv=content-type content=text/html; charset=UTF-8
/head
body bgcolor=#CC text=#00
  font size=-1Reading the thread about microcode, I wonder why

[…]

  1. No html, please.

And, especially, no /invalid/ HTML, please.

[…]

-- 
!DOCTYPE thethe e=tensible ribbon=campaign /pAdvocating the
judicious use of XML applications at the Internet at large./p
pStop the use of proprietary formats on the Web and e-mail!/p/the


-- 
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/86vcexsdsv@gray.siamics.net

Re: ${HOME} vs. g_get_home_dir ()

[Ivan Shmakov]

 Simon McVittie s...@debian.org writes:
 On 26/09/12 18:15, Ivan Shmakov wrote:
 Simon McVittie s...@debian.org writes:

  Please research previous discussion to check that you're not
  missing arguments that have happened in the past,

  Any particular pointers?

  Following the git history points to
  https://bugzilla.gnome.org/show_bug.cgi?id=2311, which raises
  interesting issues regarding running GUI applications from under
  su/sudo (which is generally a bad idea, but back then there was
  little alternative).

There's also the analysis at [1].

Unfortunately, it seems that the possibility of the user
/intentionally/ changing his or her own HOME was never
considered (and neither such concerns are reflected in the
documentation.)  E. g.:

--cut--
It turns out that most of this time, this is irrelevant.  login sets
$HOME and until you switch users, it will be left unchanged.  The case
where it becomes an issue is with some execute a program as another
user commands.  There is some difference in behavior here.
--cut--

Should the target user be a non-privileged one, my suggestion
(to only use HOME if it points to a directory which is both
accessible and owned by the “now-current” user) should relieve
the concerns listed.  On the other hand, when the target user is
‘root’ (UID 0), either of these behaviors may be valid
(depending on the exact circumstances, as was noted elsewhere in
this thread), so this check shouldn't be done (should we follow
the general principle of “root knows what it wants.”)

[1] http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html

-- 
FSF associate member #7257


-- 
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/86r4pls8w9@gray.siamics.net

Bug#688932: g_get_home_dir () should prefer ${HOME} over getpwuid ()-pw_dir

[Ivan Shmakov]

Package: libglib2.0-0
Version: 2.32.3-1
X-Debbugs-Cc: debian-devel@lists.debian.org

[Filing bug, as was suggested in the debian-devel@ discussion
[1].  I've also started a discussion in gtk-devel-list@ [2].]

Currently, it's not possible for the user to specify an
arbitrary home directory for most of the Glib-based packages
(such as, e. g., Gimp [3].)

I therefore suggest to change g_get_home_dir () to follow the
usual Unix convention of using ${HOME} as the user's home
directory, falling back to getpwuid ()-pw_dir should HOME be
non-existent or empty, or, additionally, should it point to a
directory not owned by the current user, or on which he or she
has no executable permission, unless the current user is ‘root’
(UID 0.)

An expanded rationale is at [4].

TIA.

[1] http://comments.gmane.org/gmane.linux.debian.devel.general/176973
[2] http://comments.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721
[3] http://bugs.debian.org/453711
[4] http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721

-- 
FSF associate member #7257


--
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/868vbwuhuj.fsf...@gray.siamics.net

${HOME} vs. g_get_home_dir ()

[Ivan Shmakov]

I do remember filing a bug or two against packages that refer to
the getent () data to find the user's “home” directory instead
of using the HOME environment variable.

The environment is the preferred place to check for this kind of
things: it's (usually) under the full control of the user, and
it's quite possible to run several instances of a single program
using different environments (with different executable file
search PATH's, locales, time zones, etc.), which occasionally
turns to be an immense aid to debugging.  (Want to use the
all-defaults configuration for a program?  Just start it like:
$ HOME=$(mktemp -dt -- foo.) foo)

Now, Glib has g_get_home_dir (), whose description reads [1]:

--cut--
Gets the current user's home directory as defined in the password
database.

Note that in contrast to traditional UNIX tools, this function
prefers passwd entries over the HOME environment variable.
--cut--

I believe that this behavior is buggy.  There's even a (yet
unresolved) bug report [2] against Gimp due to this behavior,
and my guess is that there may be quite a few packages more
affected by it.

While I understand some of the concerns regarding the “Unix”
behavior (also at [1]; quoted below), I'd like to note that the
software which both relies on g_get_home_dir () /and/ stores its
files under a subdirectory of the home directory returned (which
is, arguably, a common practice), is also likely to run into
issues should that /subdirectory/ be made non-writable (or
non-readable), and the current g_get_home_dir () behavior is not
a safeguard against it.

Therefore, I'd like to propose for this behavior to be changed
to match the usual Unix conventions.  To address the only
concern listed in [1] I deem valid, I'm also asking that the
value of HOME be disregarded, unless it points to a directory,
which is readable, writable, and owned, by the user.

Unless there be objections (or Glib be quickly patched), I'd be
filing a bug report against libglib2.0-0.

TIA.

--cut--
One of the reasons for this decision is that applications in many
cases need special handling to deal with the case where HOME is

Not owned by the user
Not writeable
Not even readable
--cut--

[1] 
http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html
[2] http://bugs.debian.org/453711

-- 
FSF associate member #7257


-- 
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/861uhowyp3@gray.siamics.net

Re: ${HOME} vs. g_get_home_dir ()

[Ivan Shmakov]

 Simon McVittie s...@debian.org writes:
 On 26/09/12 17:12, Ivan Shmakov wrote:

  (Want to use the all-defaults configuration for a program?  Just
  start it like: $ HOME=$(mktemp -dt -- foo.) foo)

  Debian's GLib has been patched, and actually has this precedence:
  G_HOME  getpwent  HOME.  This was originally intended for running
  things like regression tests on buildds, where the HOME specified in
  /etc/passwd typically doesn't exist or can't be written; so G_HOME
  gets set in debian/rules to force the issue.

ACK, thanks for the hint!

[…]

  I believe that this behavior is buggy.  There's even a (yet
  unresolved) bug report [2] against Gimp due to this behavior

  To be more precise, that bug report is that the man page contradicts
  what actually happens.  The maintainer appears to think the correct
  solution is to fix the man page.

If he didn't change his mind over the past four years, that is.

  To address the only concern listed in [1] I deem valid, I'm also
  asking that the value of HOME be disregarded, unless it points to a
  directory, which is readable, writable, and owned, by the user.

  That sounds like a good proposal...

  Unless there be objections (or Glib be quickly patched), I'd be
  filing a bug report against libglib2.0-0.

  ... but I don't think this is the right way to make it happen.
  Please research previous discussion to check that you're not missing
  arguments that have happened in the past,

Any particular pointers?

A scan over the past 2.5 years of gtk-devel-list@ archives
revealed nothing, and a brief Web search has only brought more
users disappointed by this behavior (e. g., [3]) and more
explicit work-arounds (e. g., [4].)

[3] http://bugs.irssi.org/index.php?do=detailstask_id=532
[4] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html

  then if you still think your proposal is the best option, take it
  upstream.

  I can see the value in having everything follow the same precedence,
  $HOME  getpwent - predictability is good.  However, having Debian's
  GLib contradict behaviour that is specifically documented upstream
  doesn't sound as though it promotes predictability.  If your proposal
  is good for Debian - which I think it is - then it's equally good for
  upstream.

Agreed.

I guess I should raise this issue on gtk-devel-list@.

-- 
FSF associate member #7257


-- 
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/86r4povh7e@gray.siamics.net

Re: Bug#688826: ITP: libarchive-rar-perl -- interface for the 'rar' command

[Ivan Shmakov]

 Joenio Costa joe...@colivre.coop.br writes:

  Package: wnpp
  Severity: wishlist
  Owner: Joenio Costa joe...@colivre.coop.br

  * Package name: libarchive-rar-perl
Version : 2.02
Upstream Author : jean-marc boulade jmbp...@hotmail.com
  * URL : http://search.cpan.org/dist/Archive-Rar/
  * License : Perl
Programming Lang: Perl
Description : interface for the 'rar' command

  This is a module for the handling of rar archives.
  ..
  Locates the rar command

AIUI, the Rar archiver is non-free.  Do I understand it
correctly that this package is thus intended for contrib?

  (from PATH or from regedit for Win32)

The W32 platform isn't worth mentioning, as Debian isn't
available for one.

  and encapsulate it to create, extract and list rar archives.

-- 
FSF associate member #7257


-- 
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/86y5jxwh64@gray.siamics.net

Re: Packages removing alternatives on upgrade

[Ivan Shmakov]

 Jakub Wilk jw...@debian.org writes:

[Cross-posting to packages@qa, for elvis is maintained by the QA
group.]

  Many packages remove alternatives on upgrade, only to re-add them
  later, potentially discarding manual choices of the user.

  See also bug #71621.

[…]

  Debian QA Group packa...@qa.debian.org
 elvis
 elvis-console
 elvis-tools
 ircii

[…]

BTW, do I understand it correctly that it's just a matter of
dropping the ‘upgrade’ case from .prerm?  (Possible patch
MIME'd.)

TIA.

-- 
FSF associate member #7257
--- debian/elvis-console.prerm.~1~	2012-09-23 13:34:49.0 +
+++ debian/elvis-console.prerm	2012-09-23 15:24:02.0 +
@@ -3,7 +3,7 @@
 set -e
 
 case $1 in
-upgrade|remove|deconfigure)
+remove|deconfigure)
 for app in editor ex input vi view; do
 update-alternatives --quiet --remove $app /usr/bin/elvis
 done
--- debian/elvis.prerm.~1~	2012-09-23 13:34:49.0 +
+++ debian/elvis.prerm	2012-09-23 15:24:02.0 +
@@ -3,7 +3,7 @@
 set -e
 
 case $1 in
-upgrade|remove|deconfigure)
+remove|deconfigure)
 for app in editor ex input vi view; do
 update-alternatives --quiet --remove $app /usr/bin/elvisnox
 done
--- debian/elvis-tools.prerm.~1~	2012-09-23 13:34:49.0 +
+++ debian/elvis-tools.prerm	2012-09-23 15:24:02.0 +
@@ -3,7 +3,7 @@
 set -e
 
 case $1 in
-upgrade|remove|deconfigure)
+remove|deconfigure)
 update-alternatives --quiet --remove ctags /usr/bin/elvtags
 ;;
 failed-upgrade)

conffiles

[Ivan Shmakov]

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

[…]

  BTW, conffiles is a pretty bad name.  It's confusing, as you can
  see once more.

  I thought about calling it dpkg-conffiles which has the advantage
  of underlying that we leave the handling of the file to the
  responsibility of dpkg, keeps the same old conffiles name.  But
  people will continue to use the older short version of it, so...

  Anyone with a better idea?

umdekfiles, perhaps?  (For “User modifies, dpkg keeps [the
changes.]”)  At the very least, I don't think anyone with half
the sane mind will confuse them with “configuration files.”

-- 
FSF associate member #7257


-- 
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/86zk4j237k.fsf...@gray.siamics.net

Re: status of eligibility of dug lists on lists.debian.org

[Ivan Shmakov]

 martin f krafft madd...@debian.org writes:

[…]

  So the solution was to get one or two additional people, and
  eventually I was even able to invest in more fail-proof hardware.

  … and then you ask yourself what to do with all the spare cycles and
  wouldn't other LUGs profit from your setup…  And you keep going and
  going and the dependence on you grows.

Yes.

[…]

  Now there are three ways forward:

  1. take back the mailing list, my infrastructure still exists and
 could handle it, but am I willing to give a guarantee for the next
 years to come?

  2. work with teams.debian.net to get it back up to speed.

  3. or use the official and professionally maintained infrastructure
 on alioth.d.o or lists.d.o, which can probably handle a couple
 dozens of additional lists.  I can understand that we don't want a
 new list for every formation or group in the Debian universe,

To be honest, it's the very reason I dislike mailing lists.  The
groups come and go, while mailing lists have to stay forever,
for their archive to be available for posterity.

Usenet is better (though still not ideal) in this respect, as
newsgroups aren't much more than just “tags”, which a single
message may bear an arbitrary number of.

Starting a “discussion group” should require no more skill and
time than tuning a radio to an agreed frequency.  And the
archive should persist for as long as there's anyone to care.

 but a list for large groups like the Debian users in and around of
 Munich should arguably be doable.

  My preference is clearly (3.).  Maybe one of the sysadmins who could
  host their own LUG list would be interested in helping the
  listmasters.  And should the hardware not be enough, then we can
  probably find ways to upgrade it.

I'd be fine going (2), either.  What exactly needs to be done?

-- 
FSF associate member #7257


-- 
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/86mx0l3qrv@gray.siamics.net

versioned dependency on the libhdf5-7 virtual package

[Ivan Shmakov]

This issue was already discussed [1], and I've filed the
respective bug report [2] (to which there was no reply so far,
though), but now I see that there's a few more packages in
Wheezy with a dependency on libhdf5-7.  Consider, e. g.:

$ bzcat \
   http.debian.net/debian/dists/wheezy/main/binary-amd64/Packages.bz2 \
  | gawk '/^Package: / { pkg = $2; } /Version: / { vers = $2; }
  / libhdf5-7 \(/ { printf(%-23s %s\n, pkg, vers); }' 
libhe5-hdfeos0  5.1.13.dfsg.1-3
libhdf5-7-dbg   1.8.8-9
libhdf5-dev 1.8.8-9
cgns-convert3.1.3.4-1
libnexus0   4.2.1-svn1614-1+b1
libnexus0-java  4.2.1-svn1614-1+b1
nexus-tools 4.2.1-svn1614-1+b1
r-cran-hdf5 1.6.10-1
tessa   0.3.1-6
tessa-mpi   0.3.1-6
udav0.7.1.2-3
$ 

Any chance this issue will be rectified?  (Or should I file bug
reports against these packages?)

TIA.

[1] news:udlvci28as8@dr-wily.mit.edu
http://permalink.gmane.org/gmane.linux.debian.science/5353
[2] http://bugs.debian.org/680400

-- 
FSF associate member #7257  http://sfd.am-1.org/


-- 
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/86a9wu9iky@gray.siamics.net

Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

[Ivan Shmakov]

 Simon McVittie s...@debian.org writes:

[…]

  hicolor-icon-theme is really the infrastructure for a theme, rather
  than *being* a theme: it does not contain any icons of its own.  It
  represents the fallback icon theme for all desktops that use
  freedesktop.org themes (GNOME, KDE, XFCE, etc.).  The name hicolor
  is for historical reasons - it was the default icon theme hard-coded
  into old versions of one of the major desktop environments (KDE 2 or
  3, I think?) and it stuck.

  Its purpose is to be the theme into which applications install their
  theme-neutral icons: anything that displays a themeable icon should
  search for it in the configured theme, and then fall back to hicolor.

ACK, thanks for the explanation, and apologies for a “false
alarm.”  (But why the other “theme” packages depend on it, BTW?)

Now, I wonder, could its Description: be amended so to explain
its function in more detail?  Stating that it's “the default
fallback theme” doesn't tell quite much to me, for instance.

Consider, e. g. (though the wording is flaky a bit):

Description: FreeDesktop.org default fallback theme infrastructure
 This package contains the necessary infrastructure for the applications
 to install their theme-neutral icons for the implementations of the
 Freedesktop.org Icon Theme specification to use.  It provides the
 respective directory layout, an index file, and a script to start
 gtk-update-icon-cache(1) as necessary.
 .
 This package is not an icon theme per se as it contains no icons of its
 own.  The hicolor name was hardcoded into an older version of a major
 desktop environment and is retained for historical reasons.

  Its only file outside /usr/share/doc is metadata describing the
  directories it provides (index.theme, 24K), and its postinst and dpkg
  trigger maintain a Gtk icon cache for icons added to it by
  applications.

Thus, its function also implies a couple of Shell scripts below
/var/lib/dpkg/info/, too.  (Which are simple enough to not worry
about, though.)

[…]

  I don't think we could potentially save 24K on those rare systems
  that have certain specific X apps, but no GUI menu is a very
  compelling reason to change packages' dependencies?

At the very least, it now doesn't bother me much more than
having libmysqlclient18 installed on my MX'es running
exim4-daemon-heavy (given that I never had to use MySQL with it
specifically.)

Still, using Depends: to depend on a (otherwise optional)
.postinst script doesn't seem quite right to me.  (And I'm
pretty sure that dependencies of such a kind are generally
Recommends: ones in Debian.)

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86ipcg1yzs@gray.siamics.net

Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

[Ivan Shmakov]

  Abstract

The non-data packages currently having an absolute dependency on
hicolor-icon-theme should consider downgrading it to Recommends:
at the least.  The list, and the explanation, are below.


  Chapter I
  imagemagick

Recently, Depends: hicolor-icon-theme was added to the
imagemagick's control file, which triggered my curiosity: does
it provide something that wasn't needed (or was missed) by the
previous versions of the package, but is strictly necessary to
run the newer ones?

Indeed, it doesn't.

To prove it, I've made a trivial control file for
equivs-build(1):

--cut: k1o7mjuxokuwghktzugfno8qib.ctl --
Package: k1o7mjuxokuwghktzugfno8qib
Provides: hicolor-icon-theme
Description: Pretend that hicolor-icon-theme is installed (dummy)
 A dummy package pretending to provide hicolor-icon-theme.
--cut: k1o7mjuxokuwghktzugfno8qib.ctl --

Having hicolor-icon-theme removed and this one installed, I've
proceeded to install imagemagick.  Unsurprisingly, I've found
/no/ issues with either installing or running it.  (I've tried
display(1), but I'm quite sure that there won't be any issues
with convert(1), either.)


  Chapter II
  A few packages more

Well, I've wondered, is this a singular issue with Depends:
hicolor-icon-theme, somehow creeped into Debian Wheezy “just
prior” to its scheduled release?

Indeed, it isn't.

I've examined the reverse dependencies of hicolor-icon-theme:

$ apt-cache rdepends  --no-suggests --no-recommends \
  hicolor-icon-theme 
hicolor-icon-theme
Reverse Depends:
  viridian
  tango-icon-theme
  synaptic
  rabbitvcs-core
  perlpanel
  oxygen-icon-theme
  openteacher
  kdelibs5-data
  imagemagick
  gnome-phone-manager
  gnome-icon-theme-symbolic
  gnome-icon-theme-extras
  gnome-icon-theme
  flush
  d-feet
$ 

Well, it doesn't seem suspicious for anything *-icon-* and
*-data to depend on an icon theme, but what about the rest?

For a start, I've omitted rabbitvcs-core and viridian, and
considered d-feet, flush, openteacher, perlpanel, and synaptic.
Unsurprisingly, all of them were able to install and run, but
while openteacher is seemingly unaffected by the absence of the
data in question, the rest have had obvious issues: almost all
of the icons were absent, resulting in blank space on the GUI,
missing controls, and warnings to stderr (stdout?)


  Conclusion

Since there're (as it seems) virtually no issues with running
imagemagick without a “real” hicolor-icon-theme installed, my
suggestion would be to downgrade the dependency to Suggests: (or
Recommends:, if there's some point I've missed.)

As for the other packages considered, my suggestion would be to
downgrade the dependencies to Recommends: (or, for openteacher,
to Suggests:, if it's indeed unaffected.)

Unless there'd be any objections, I'll consider filing a bug
against imagemagick, and perhaps the other aforementioned
packages as well.


  Post Scriptum

Curiously enough, the only “application” package having a
Recommends: dependency on hicolor-icon-theme is cheese.

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86ehn551jr@gray.siamics.net

[OT] ifconfig(8)

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Aug 08, Arno Töll a...@debian.org wrote:

  ifconfig and route were around already when everyone insisted on the
  separation of /bin and /sbin.  /bin/ip is slightly newer and
  supposed to replace ifconfig/route some day entirely.

  Just for the records, iproute entirely replaced ifconfig/route long
  ago.

Curiously enough, ifconfig(8) shows RX/TX byte counts, and,
somehow, I didn't manage to get a similar output from iproute.
Any pointers?  TIA.

  The only reason for keeping around the old programs is compatibility
  with other packages not yet updated and to not scare people who do
  not know better.

  (Does anybody want to try removing net-tools and see what breaks?)

I guess that $ apt-cache rdepends may be a safer check, like:

$ apt-cache rdepends --no-suggests net-tools 

However, it made me wonder, why ifupdown Suggests: net-tools?

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86k3x9k5xn.fsf...@gray.siamics.net

Re: [OT] ifconfig(8)

[Ivan Shmakov]

 Timo Juhani Lindfors timo.lindf...@iki.fi writes:
 Ivan Shmakov oneing...@gmail.com writes:

  Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow,
  I didn't manage to get a similar output from iproute.  Any pointers?
  TIA.

  $ ip -s link show lo
  1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN 
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  RX: bytes  packets  errors  dropped overrun mcast   
  1686679058 6901861  0   0   0   0  
  TX: bytes  packets  errors  dropped carrier collsns 
  1686679058 6901861  0   0   0   0  

At last, I can forget about ifconfig(8).  Thanks!

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86fw7xk548@gray.siamics.net

Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers

[Ivan Shmakov]

 The Fungi fu...@yuggoth.org writes:
 On 2012-07-26 14:29:14 +0100 (+0100), Ian Jackson wrote:

  We also need a general word for someone involved with Debian in a
  positive way.  Participant is clumsy; member of the community
  even more so.  Person might do but word with a more positive spin
  would be nice.

  As a long-time participant and non-DD, I've always liked the term
  contributor in that context.

As (hopefully) one of the affected, I'm fine with “contributor.”

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86wr1puk4q.fsf...@gray.siamics.net

Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Ivan Shmakov]

 Jonathan Nieder jrnie...@gmail.com writes:
 Goswin von Brederlow wrote:

  What I don't understand is why compilers (which probably means ld
  from binutils in all cases) won't use ld.so.conf to find the libs.
  It only does so to find libs linked into libs you link against.  So
  it is used execpt for the verry first level of recursion.

  The ld library path and compiler library path represent different
  things[*].

Somehow, I guess that “the ld.so(8) library path” and “the ld(1)
library path” were actually meant here.

[…]

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86pq7my9i5@gray.siamics.net

Re: Recommends for metapackages

[Ivan Shmakov]

 Jonas Smedegaard d...@jones.dk writes:

[…]

  It is a feature (which each user is free to avoid by not using it!)
  for Debian to include a meta-package that pulls in that vil n-m,
  not a bug.

… And what exactly this “feature” gives to the user?

[…]

-- 
FSF associate member #7257  http://sf-day.org/


-- 
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/86d3430zhm@gray.siamics.net

Re: CD sizes again (and BoF reminder!)

[Ivan Shmakov]

 Ben Hutchings b...@decadent.org.uk writes:

[...]

  - twm: no-one should have to suffer this

And, exactly, why not?  Before I've switched to Openbox, it was
one of the two WM's I've used, along with FVWM.  And they say
[1] that it still can be handy at times.

The “obscure” label may fit, though.

[...]

[1] news:1187451...@ddt.demos.su
(in Russian; and is garbled beyond recognition on Google Groups.)

-- 
FSF associate member #7257


-- 
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/86sjd13tzn@gray.siamics.net

Re: Packaging on GitHub ?

[Ivan Shmakov]

 Thorsten Glaser t...@mirbsd.de writes:
 Charles Plessy dixit:

  upstream source moved to GitHub, and we would like to try to
  maintain the Debian package there as well.

  This is not a good idea: http://mako.cc/writing/hill-free_tools.html

That's why I tend to advocate for the use of Gitorious instead.

--cut: http://en.wikipedia.org/wiki/Gitorious --
CAPTION: Gitorious

Developer(s)  Shortcut AS
Written inRuby
Operating system  Cross-platform
Available in  English
Type  Project management software
License   GNU Affero General Public License
Website   https://gitorious.org/gitorious/
--cut: http://en.wikipedia.org/wiki/Gitorious --

PS.  An RFP, perhaps?

-- 
FSF associate member #7257


-- 
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/861um2l4w9@gray.siamics.net

Re: Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL

[Ivan Shmakov]

 Alexander Kuznetsov a...@cpan.org writes:

[…]

(Some wording fixes and suggestions.)

  Description : A high speed data loading utility for PostgreSQL
  pg_bulkload is designed to load huge amount of data to a database.
  You can choose whether database constraints are checked and how many errors 
  are

If “You can…” here starts a new paragraph, there's ought to be
an empty (“.”) line.  And if not, the linebreak here came a bit
too early than necessary.

  ignored during the loading. For example, you can skip integrity checks for
  performance when you copy data from another database to PostgreSQL. On the
  other hand, you can enable constraint checks when loading unclean data.
  .

Are “constraint checks” different to “integrity checks” in the
above?  Unless they are, it should rather be, e. g.:

   … For example, you can skip integrity checks for performance when you
   copy data from another database to PostgreSQL, or have them in place
   when loading potentially unclean data.

  The original goal of pg_bulkload was an faster alternative of COPY command in

   … was /a/ faster…

Or, perhaps: … was to provide a faster…

  PostgreSQL, but version 3.0 or later has some ETL features like input data
  validation and data transformation with filter functions.
  .

   … but as of version 3.0 some ETL features… were added.

And what's ETL, BTW?

  In version 3.1, pg_bulkload can convert the load data into the binary file
  which can be used as an input file of pg_bulkload. If you check whether

Perhaps:

   As of version 3.1, pg_bulkload can dump the preprocessed data into a
   binary file, allowing for…

(Here, the purpose should be mentioned.  Is this for improving
the performance of later multiple “bulkloads”, for instance?)

  the load data is valid when converting it into the binary file, you can skip
  the check when loading it from the binary file to a table. Which would reduce
  the load time itself. Also in version 3.1, parallel loading works
  more effectively than before.

s/effectively/efficiently/.  But the whole sentence makes little
sense, as the earlier versions weren't packaged for Debian.

-- 
FSF associate member #7257


-- 
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/86wr3ujphk@gray.siamics.net

/tmp on multi-FS set-ups, or: block users from using /tmp?

[Ivan Shmakov]

 Weldon Goree wel...@b.rontosaur.us writes:
 On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:

  I think having / and /tmp share the same file system is a bad idea,
  because then writing lots of stuff to /tmp would potentially fill up
  the root file system (that typically also includes /var) and then
  cause a lot of breakage.

  However, if I put /tmp in a separate (on-disk) file system, I have
  to decide how much disk space to I want to permanently allocate for
  temporary data, in addition to the disk space permanently allocated
  for swapping.

[…]

Somehow, I feel that some of the participants of this discussion
are missing this very point: having /tmp on disk /doesn't/ mean
that /all/ the free disk space will be available for it at any
given time.

In particular, as Ext2+ filesystems can only be expanded, and
not reduced (without unmounting), I've got the habit of having
most of the disk space unallocated, and only expanding the
filesystems as they grow full.  (Unless, of course, considerable
amounts of cruft could be identified and removed at that time.)

  If only ext*fs supported quotas...

… But that makes me recall a solution to both the /tmp and quota
issues I've seen somewhere: use ~/tmp/ instead of /tmp.  This
way, user's temporary files will be subject to exactly the same
limits as all the other his or her files.

(Still, we may need to identify the software that ignores TMPDIR
and tries to write to /tmp unconditionally.)

  (Snark aside, does tmpfs support quotas yet/will it ever?)

-- 
FSF associate member #7257


-- 
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/86r4u7koc5.fsf...@gray.siamics.net

Re: Increasing minimum 'i386' processor

[Ivan Shmakov]

 Ben Hutchings b...@decadent.org.uk writes:
 On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote:

[…]

  While i might agree with the exclusion of 486 cpu classes (somewhere
  i have a Winchip C6 200 MHz but i consider it unusable except for
  very limited tasks), i think that excluding 586 could be too
  aggressive. AMD K6-2 processors doesn't have CMOV, because when i
  try to use various rescue CD on some of these machine, they don't
  boot with a messages informing of the missing instruction. These
  processors are about 15 years old but are still useful and usable
  today and maybe still for Wheezy+1.  I think that would be a pity if
  Debian will not provide anymore a kernel for this old cpus.

  Maybe you think it's a waste to replace old PCs, but in many cases
  it's a waste of money to keep them running.  Electricity isn't
  getting any cheaper and modern systems are much better at
  power-saving.

I'm not sure about ARM, but one of my K6-based systems
apparently has power consumption below or comparable to that of
one of my Intel Atom ones.  (Though the performance of the
former is obviously lower.)

One more observation is that the 80386-based systems and the
like didn't require any coolers.

That being said, I'm now considering moving to ARM-based
hardware, such as the Raspberry Pi computer, for the tasks that
don't require much CPU cycles.

-- 
FSF associate member #7257


-- 
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/86k46soboo@gray.siamics.net

Re: Advocating the use of RDF for Debian's published metadata

[Ivan Shmakov]

 Matthias Klumpp matth...@tenstral.net writes:

[…]

  It would be very nice, if ftpmasters could tell if they would accept
  a new format in the archive or if we should stay with RFC822 which is
  used for nearly everything else already.

  Note that the same rationale stands for all metadata to be
  eventually published on the Web by Debian servers.

  Hope this helps.

  Thank you for the information... I think RDF would be much more
  open for other people and apps to use, as the data wouldn't be in a
  Debian-specific format. (I can't imagine yet what others would do
  with this data, but if more people would use RDF, e.g. other
  distributors too, having it all in one standardized and extensible
  format would be something valuable)

Well, having this data aligned with the RDF model will help
interoperability, I guess.

One application I have in mind is that it becomes possible to
query the Debian Packages and Sources databases using the
powerful SPARQL language.  In particular, one may quickly check
if there're any packages that are transitively dependent on A,
while also immediately dependent on B.  (Yes, grep-dctrl(1)
helps, but it's not quite as powerful a language as the recent
edition of SPARQL, not to mention that it's yet another query
language to learn.)

However, I believe that it's infeasible to change the native
format the aforementioned databases, as both it isn't going to
be easy to implement, and it may bring considerable burden on
both the Debian users and maintainers.

Thus, my opinion is that there should be a tool performing
conversion from the Debian's native database format to some RDF
representation.  In particular, rdfproc(1) could become such a
tool, provided that Raptor will be extended to parse RFC 822.

That being said, I don't see such a conversion as a simple and
straight-forward process.  In particular, should a package
stanza be transformed into a named (as per Package:) or blank
node (with Package: as an explicit relation)?  The Depends: a, b
and Depends: a | b may both have an RDF list in the object
position, but how to distinguish between them?  And how a line
such as Depends: a ( 0.1) should be expressed?  Should the
package names be encoded as string literals, or should they be
transformed into URI's instead?  There're quite a few choices to
be made by the one volunteering for this.

These questions were in my TODO list for some time (filed under
Category: nifty hack, as I'm yet to see any serious practical
uses for such a thing), but I'm short of spare time these days,
and won't probably be able to do much, apart from participation
in the discussions on this subject.

-- 
FSF associate member #7257


-- 
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/86hb2ng5bt.fsf...@gray.siamics.net

Re: Bug#645656: network-manager in Gnome

[Ivan Shmakov]

 Jon Dowland j...@debian.org writes:
 On Tue, Nov 01, 2011 at 02:56:53PM +, Ian Jackson wrote:

  We should do it when we judge that the benefits are worth the costs.
  In this particular case the costs seem to be minimal.  There isn't
  even a direct patch-carrying cost, since the dependency is expressed
  in our own control files.

  What should it be called: gnome-without-network-manager?

  I really don't like evolution.  Can I have a gnome-without-evolution?

  (Only half-joking. I *really* don't like evolution).

  Where do you draw the line?

  (Of course, any Debian developer can freely create such a dependency
  package, it doesn't have to be the GNOME maintainers.)

  In case it isn't clear, I don't think it's a good idea.

Well, I seem to jump into the discussion without thoroughly
reading all the postings (and I've never tried to install the
gnome package, BTW), but the issue with network-manager seems to
me much easier to solve than the one with evolution, as the
former is in Recommends:, while the latter is in Depends:.

The difference is that there could be a «negapackage» (marked as
manually installed with APT), with the sole purpose of having a
Conflicts: network-manager line.  (Why, such a package could
simply be done with equivs!)  Then, it was my understanding that
APT will instantly remove network-manager (and its respective
dependencies) should the negapackage be installed, and will
never try to install the offending package until an explicit
user request.

Therefore, I'm curious if the Debian metapackages could be
switched to primarily use Recommends:, and not Depends:?  (So
that the users could then have a conflicting package installed,
or simply remove the offending package manually.)

-- 
FSF associate member #7257


-- 
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/86aa8fg3nn@gray.siamics.net

http://www.gnu.org/s/hello/manual/automake/ ?

[Ivan Shmakov]

 Adam Borowski kilob...@angband.pl writes:

[…]

  GNU's and the inventor of AM_MAINTAINER_MODE's stance:
  http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html

BTW, this URI seems to me like a thing to be reported to GNU
webmasters (Cc:'ed.)  The Automake manual should be (and it is)
accessible via, e. g.:

http://www.gnu.org/s/automake/manual/html_node/
http://www.gnu.org/software/automake/manual/html_node/

I was also surprised to find that the following URI's are also
valid (but not, e. g., bash/ or tar/):

http://www.gnu.org/s/hello/manual/autoconf/
http://www.gnu.org/s/hello/manual/gettext/
http://www.gnu.org/s/hello/manual/libc/
http://www.gnu.org/s/hello/manual/libtool/

If it was done on purpose, I'd suggest that the respective
“parent” page (http://www.gnu.org/s/hello/manual/) should have
them hyperlinked.

TIA.

[…]

-- 
FSF associate member #7257


--
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/86r521mn20.fsf...@gray.siamics.net

udev: what does it used for in Debian?

[Ivan Shmakov]

I've found that a few packages, contrary to my expectations,
have Depends: on udev.  I'm primarily concerned with alsa-base
and initramfs-tools, but also wonder about libcomedi0, dkopp,
python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp,
xserver-xorg-core, and midisport-firmware.

The backstory is that I'm about to install Debian (either stable
or testing) on a tiny Architecture: i386 system, and consider
excluding udev from the installation, as the hardware in
question has virtually no support for any pluggable devices
whatsoever.

-- 
FSF associate member #7257


-- 
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/86lisaprgz@gray.siamics.net

Re: udev: what does it used for in Debian?

[Ivan Shmakov]

 Neil Williams codeh...@debian.org writes:
 On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote:

  I've found that a few packages, contrary to my expectations, have
  Depends: on udev.  I'm primarily concerned with alsa-base and
  initramfs-tools, but also wonder about libcomedi0, dkopp,
  python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp,
  xserver-xorg-core, and midisport-firmware.

  The backstory is that I'm about to install Debian (either stable or
  testing) on a tiny Architecture: i386 system, and consider excluding
  udev from the installation, as the hardware in question has
  virtually no support for any pluggable devices whatsoever.

  udev isn't just for pluggable devices, packages can provide udev
  rules to ensure that devices appear with a consistent name,

It doesn't seem like a good reason for the aforementioned
dependency, does it?

And what the initramfs-tools package has to do with consistent
devices' filenames?

  e.g. /dev/input/event[0-9] does not include only pluggable or
  external devices, it can contain several internal input devices as
  HIDs but the actual number is not predictable. To make sure the
  package reads from the correct device, it is wiser to provide a udev
  rule which gives a particularly identified input device (by
  classification / type / interface or even vendor) a known /dev
  location as a name or symlink.

Indeed, thanks.

Somehow, I assume that given a relatively small number of
devices per bus, this wasn't a problem, say, a decade or so ago.
(Think of, say, 2 IDE or floppy drives per IDE or FDD
controller, one keyboard, one PS/2 mouse, two RS-232 ports per
UART, etc.)  Or was it rather that there was much less variation
between different instances Intel-based computers' hardware?

However, I wonder, how often these numbers will change given
that the system's hardware configuration will essentially be
fixed for all the foreseeable future?  I guess it won't be
something like “every (other) kernel's release”, right?

TIA.

-- 
FSF associate member #7257


-- 
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/86hb2ypj3i@gray.siamics.net

Re: udev: what does it used for in Debian?

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Oct 24, Ivan Shmakov i...@gray.siamics.net wrote:

  It doesn't seem like a good reason for the aforementioned
  dependency, does it?

  There are many other reasons, you can find them in /lib/udev/.

ACK, thanks.

  And what the initramfs-tools package has to do with consistent
  devices' filenames?

  udev is needed to automatically load all the modules you need, for a
  start.

So, the kernel won't try to autoload a module when the
corresponding device gets accessed?

It was my understanding that, e. g., should a 10, 1 character
device (/dev/psaux) be accessed, the kernel will spawn
modprobe(8) against char-major-10-1, which is then resolved to
‘psmouse’ thanks to modprobe.conf(5).  At the least, it was used
to do just that something like a decade ago (IOW, as of 2.4.)

$ /sbin/modprobe -c | grep -F -- 'char-major-10-1 ' 
alias char-major-10-1 psmouse
$ 

  However, I wonder, how often these numbers will change given that
  the system's hardware configuration will essentially be fixed for
  all the foreseeable future?  I guess it won't be something like
  “every (other) kernel's release”, right?

  Names could change even at every boot.

Any reasons for that other than the order in which the modules
get loaded?

  Anyway, you have equiv.  Try to use it and look what happens.

I've never heard of that (and Googling for “linux equiv” doesn't
seem to return anything relevant to the problem.)  What's it?

TIA.

-- 
FSF associate member #7257


-- 
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/86d3dmpgxr@gray.siamics.net

Re: udev: what does it used for in Debian?

[Ivan Shmakov]

 Timo Juhani Lindfors timo.lindf...@iki.fi writes:
 Ivan Shmakov i...@gray.siamics.net writes:

  And what the initramfs-tools package has to do with consistent
  devices' filenames?

  Initramfs runs udev.  This allows you to use e.g.

  root=/dev/disk/by-id/ata-WDC_WD3200AAJS-65B4A0_WD-WMAT13954017-part1

  instead of

  root=/dev/sda1

  to specify where your root filesystem is.

Indeed, it's a good option to have.  But isn't it something that
can be, in certain circumstances, however marginal, considered
an extra?

BTW, does the root=UUID= variant require udev as well?

TIA.

-- 
FSF associate member #7257


-- 
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/868voapgol@gray.siamics.net

Re: udev: what does it used for in Debian?

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Oct 24, Ivan Shmakov i...@gray.siamics.net wrote:

  So, the kernel won't try to autoload a module when the corresponding
  device gets accessed?

  Not for *hardware* drivers, since it cannot know which driver is
  needed.

Not even via modprobe.conf(5)?

  I've never heard of that (and Googling for “linux equiv” doesn't
  seem to return anything relevant to the problem.)  What's it?

  I meant equivs.

Somehow, I've totally missed this one.  Which, indeed, I've a
plenty uses for.  Thanks!

  Anyway, I think that if you want to learn how udev works then you
  should send your questions to an users support mailing
  list/newsgroup/forum/etc.

Well, seems like there're little specific to Debian in how udev
works.  Thanks.

-- 
FSF associate member #7257


-- 
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/8639eipe2m@gray.siamics.net

Re: udev: what does it used for in Debian?

[Ivan Shmakov]

 Ben Hutchings b...@decadent.org.uk writes:
 On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote:

[…]

  BTW, does the root=UUID= variant require udev as well?

  Yes, currently the kernel filesystem code does not probe for filesystem
  UUIDs.  (However, it does support partition UUIDs as used in GPT.  You
  can use root=PARTUUID= to select from those.

ACK, thanks!

  But I doubt you're using a GPT.)

Actually, I do.  CHS addressing (as used in MBR, even if along
with LBA) seems to me a bit obsolete (for at least a decade),
thus I've moved to use GPT for all the new media almost as soon
as I've discovered it.

Sometimes, I have to use gptsync(8), though.

-- 
FSF associate member #7257


-- 
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/86ty6xoj76@gray.siamics.net

MUA's vs. local mail

[Ivan Shmakov]

 Henrique de Moraes Holschuh h...@debian.org writes:

[…]

  I do know many of the GUI MUAs are incomplete jack-jobs that fail to
  add a handler for local system folders (i.e. were only partially
  ported to Linux).  I am not sure which would be the better aproach to
  deal with this deficiency.

Recommends: dovecot-imapd, and let the MUA's use imap://[::1]/
by default?

Please also note that dovecot-imapd is perfectly runnable even
without special privileges, and even without a real network
socket (a pipe is just fine.)  In particular, my Gnus/Emacs
setup has the following server's definition:

(nnimap Maildir
(nnimap-stream shell)
;; FIXME: use nnimap-shell-program here
(imap-shell-program
 (MAIL=maildir:\$HOME\/Maildir /usr/lib/dovecot/imap)))

That way, Gnus is also unaware of my system's password.

Contrary to having a MUA access local mail directly, Dovecot
will cache certain headers, thus allowing the list of messages
to be prepared rather quickly.  For the larger mailboxes, there
may be a really huge difference between using Maildir + Dovecot
vs. a MUA that accesses a Unix mbox file directly.

-- 
FSF associate member #7257


-- 
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/86zkh0vv1k.fsf...@gray.siamics.net

Move mtab, etc. below /run

[Ivan Shmakov]

 Roger Leigh rle...@codelibre.net writes:
 On Wed, Oct 12, 2011 at 11:24:09AM +0700, Ivan Shmakov wrote:

  With all the sort of software continuously writing to /etc/?
  Consider, e. g., /etc/blkid.tab, which is updated almost every time
  a removable media is connected to the system.  Or /etc/mtab.  Or
  /etc/lvm/cache/.

  These should all be moved to /run.

Indeed.

  mtab will be moved shortly.  The LVM and block ID caches should also
  move there, with backups put under /var as required.

Are there any Bug# one could subscribe to to watch the progress?

-- 
FSF associate member #7257


-- 
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/864nz8xolo.fsf...@gray.siamics.net

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

[Ivan Shmakov]

 Michelle Konzack linux4miche...@tamay-dogan.net writes:
 Am 2011-10-13 12:13:56, hacktest Du folgendes herunter:

  The user will not be notified even if the daemons send a mail to
  them.  I don't think any of the desktops GUIs that we ship know
  anything about the local mail queue unless explicitly configured in
  an MUA, nor do they notify the user when there is new mail.

  I was using long time ago (8-10 years) a grafical MUA, which was
  accessing ~/mail or /var/mail/user. Since I use mutt, it is very
  good, that mutt use by default ~/mail and the standard spool.

  Maybe all MUAs in Debian should be configued by the Package
  Maintainers, to support ~/mail by default or /var/mail/user by
  default?

I'd second on that.

However, I should note that the Unix mbox format is quite
obsolete by now, so I'd vote for the MUA's to support Maildir
(~/Maildir/) at the least (and as the default), with Unix mbox
(/var/mail/, ~/mail) possibly left as an option.

-- 
FSF associate member #7257


-- 
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/86zkh4xm5v@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Philipp Kern tr...@philkern.de writes:
 On 2011-10-11, Ognyan Kulev o...@tower.3.bg wrote:
 На 11.10.2011 17:32, Marco d'Itri написа:

[…]

  /usr/src - /usr/share/src

  Probably depends if you want to support compile outputs there.  I
  guess some people compile their kernels there.

Which isn't a good practice, anyway.  For the kernel, it was my
preference to have a single source hierarchy, and a separate
hierarchy for each build, under, e. g., /var/tmp/, or /home/.
(I haven't build a kernel for a while, though.)

With /usr mounted read-only, it's still a suitable place for
sources, but hardly so for builds.

  /usr/local - /local

  Don't know what you want to say with that, apart from getting rid of
  FHS.

I did it this way, and I did it the other.  I feel no
difference.

As for the shared /usr, having local/ under /usr allows for
site-specific software to be seen by the NFS clients, which is
probably what one would want.

-- 
FSF associate member #7257


-- 
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/8639ey1uzq@gray.siamics.net

Re: / vs. /usr vs. fsck(8)

[Ivan Shmakov]

 Reinhard Tartler siret...@debian.org writes:
 On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote:

[…]

  AFAIUI Harald (the fedora maintainer for their initramfs tool
  dracut), he dislikes having a separate set of tools in /usr and the
  initramfs, i.e., he strongly favors putting glibc, bash, iproute and
  similar utilities directly in the initramfs.  The main motivation
  (again AFAIUI) seems to be behavioral consistency of tools between
  early userspace and the booted system.

Well, in the light of this, the original proposal now makes some
sense.  Indeed, they've made their initramfs their new /, and
now wonder why would they need two /?  Quite a sensible
question, as it seems.  Still, I don't think that it's
applicable at all to Debian.

  On the other hand, Debian has chosen against that and relies on
  klibc, ipconfig, etc. for early userspace and thus, the initramfs.  I
  suspect the main motivations behind these decisions were portability
  and size (please correct me and add references).

If anything, I'd vote for the Debian way.

And, I guess that makes Debian's initramfs and the system itself
less interdependent, to the point that one could boot a system
with a (kernel, initramfs) combination that's several revisions
behind (or ahead) of the system proper.

  I imagine it would be pretty challenging to improve the klibc based
  tools to become feature-par and sufficiently behaviorally consistent
  with their glibc based equivalents.  In any case, I think having this
  in mind is relevant for deciding whether the various fsck(8)
  utilities can or should go into the initramfs or not.

I believe that should fsck(8) be moved to initramfs, there would
essentially be no reason to keep the rest of the «big stuff» off
the latter.

[…]

-- 
FSF associate member #7257


-- 
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/86y5wqzk1i@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Daniel Baumann daniel.baum...@progress-technologies.net writes:
 On 10/11/2011 04:32 PM, Marco d'Itri wrote:

  I am still not 100% persuaded that this would be easy to do, but at
  least I think that it has more merit than the old move all to /...

  i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we
  can have the trichotomy /system, /local and /home.

My opinion would be for /system/distribution, /system/local, and
/home.  But, ouch, /system/distribution is essentially the
present /usr!  (While /system/local subsumes the current
/usr/local, which isn't used that much, anyway, and /etc and
/var.)

The motivation is that it's much more important to backup
/system/local (/etc, /var) than /system/distribution (/usr.)

As for dpkg(8), we could have both /var/lib/dpkg/packages (with
Package:, Version:, and everything modifiable) /and/
/usr/lib/dpkg/packages.d (with the full descriptions.)

I'd argue that /boot is to be left in place, for I like to think
of bootloader as /not/ belonging to any particular system
installed on box.

-- 
FSF associate member #7257


-- 
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/86ty7ezjhq@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Tollef Fog Heen tfh...@err.no writes:

  The problem, AIUI, is that we start udev(7) before /usr is mounted.
  As udev is prone to spawn all the sorts of software in turn, we're
  either going to move more and more from /usr to /, /or/ to invent
  more kluges so that udev scripts would actually wait for /usr to be
  mounted.  Both are indeed valid issues.

  I don't know for sure /why/ udev(7) should precede /usr in the boot
  order, though.  Could someone clarify on that?

  (With the assumption that /usr is on a separate fs from /): You might
  very well need to load some drivers (be it network, FC, USB, SATA or
  something else) and probe some bits (iSCSI auth?) to actually get to
  the right block device.

Yes.  But should the system be moved to /usr, the above would
still have to be done before it's mounted.  The only difference
is that instead of having all the software necessary to perform
such initialization on /, we'd have to have them on initramfs —
simply because no software is going to suddenly appear after
mounting /, but before /usr is also available.  (Assuming that
/usr is still to be pointed to from an fstab(5) entry.)

-- 
FSF associate member #7257


-- 
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/86lisqzark@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Tollef Fog Heen tfh...@err.no writes:
 ]] Ivan Shmakov 
 Tollef Fog Heen tfh...@err.no writes:

  (With the assumption that /usr is on a separate fs from /): You
  might very well need to load some drivers (be it network, FC, USB,
  SATA or something else) and probe some bits (iSCSI auth?) to
  actually get to the right block device.

  Yes.  But should the system be moved to /usr, the above would still
  have to be done before it's mounted.  The only difference is that
  instead of having all the software necessary to perform such
  initialization on /, we'd have to have them on initramfs — simply
  because no software is going to suddenly appear after mounting /,
  but before /usr is also available.  (Assuming that /usr is still to
  be pointed to from an fstab(5) entry.)

  Sure, and / might come from FC, USB, SATA, iSCSI or similar too.  A
  difference is that the initramfs isn't available once you start init
  in your real /.  The logical conclusion is then to start udev from
  the initramfs, something we already do.

Thanks, I wasn't aware of this.

But it makes the whole idea of moving “everything” below /usr
even less sensible.  Consider, e. g.:

--cut: news:20111012005824.gc11...@bongo.bofh.it --
And then there is the big argument in favour of it: booting without /usr
is becoming more and more difficult. The two current solutions for this
adopted by udev and the related tools are both suboptimal: waiting in a
loop for /usr to appear can fail due to the timeout (and I wonder when
we will hit the first deadlock), and moving even more stuff from /usr to
/ can work only up to a point.
--cut: news:20111012005824.gc11...@bongo.bofh.it --

Now, if udev(7) starts to start its scripts while neither of /
or /usr is mounted, how can moving anything to or from /usr help
us avoid udev(7) scripts waiting for /some/ «real» FS is
mounted?

-- 
FSF associate member #7257


-- 
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/864nzdzixm@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Oct 11, Sven Joachim svenj...@gmx.de wrote:

  Rather complex, I'm afraid.  Especially as not all architectures
  even support an initramfs, AFAIK.

  I doubt this, since the initramfs can be embedded in the kernel image
  itself (and indeed it always contains one, it just is empty).  But
  still, then these architectures would not support keeping /usr on a
  standalone file system, which may be an acceptable compromise.

I don't seem to understand.  / is used to be self-contained; one
was still able run a “bare bones” system with just / (say, if
/usr was badly damaged somehow.)  How an architecture could
/not/ support having /usr on a separate filesystem.

On the shore, I see no value in the whole idea of merging / and
/usr.  Somehow, it reminds me a recent trend of moving graphical
mode support (for the architectures generally capable of a text
mode, as in: amd64, i386) from userspace (as in: X server) to
kernelspace (as in: fbcon, Wayland.)

Saving a dozen of bytes in ${PATH} doesn't seem like an
astonishing idea, anyway.  What's the point, then?

[…]

-- 
FSF associate member #7257


-- 
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/868vor33yu@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Oct 11, Ivan Shmakov i...@gray.siamics.net wrote:

  Saving a dozen of bytes in ${PATH} doesn't seem like an
  astonishing idea, anyway.  What's the point, then?

  It is explained in the Red Hat wiki page. Try reading it again.

Indeed, I've just read it.  To summarize: our / and /usr/ became
quite tangled over the years, so let's use initramfs instead of
/, and / instead of /usr.

Honestly, I believe that Debian hasn't messed up that that
badly.  (In particular, I still think that it's possible to boot
without /usr being available.)  However, should initramfs really
be considered “Debian's brand new /”, I demand that both
e2fsck(8) and bash(1) be included into one by default, so that
one would still be able to boot and repair a damaged /usr/^W /
from there.

To me, going this way means that initramfs becomes subject to
unconstrained growth.  Somehow, I deem it less acceptable for
initramfs than for /.

-- 
FSF associate member #7257


-- 
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/864nzf32hn@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Marco d'Itri m...@linux.it writes:
 On Oct 11, Josselin Mouette j...@debian.org wrote:
 Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit : 

  I am still not 100% persuaded that this would be easy to do, but at
  least I think that it has more merit than the old move all to
  /...

  We already discussed the idea of dropping support for a separate
  /usr, and the outcome was a broad consensus for keeping things this
  way.

  No, we discussed the idea of merging /usr in / (to which I was
  opposed myself as well).  This is a different concept.

The only significant difference that I can see is that /etc
could be put on a filesystem distinct to the one holding the
binaries.  An end which, on a second though, I cannot readily
suggest on how to achieve any other way.

Essentially, we leave / for /etc/ (and mount points) only, while
/usr/ still serves roughly the same purpose as before.

-- 
FSF associate member #7257


-- 
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/86wrcb1jn1@gray.siamics.net

Re: Move all to /usr

[Ivan Shmakov]

 Mike Hommey m...@glandium.org writes:
 On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote:
 Marco d'Itri m...@linux.it writes:

[…]

  No, we discussed the idea of merging /usr in / (to which I was
  opposed myself as well).  This is a different concept.

  The only significant difference that I can see is that /etc could be
  put on a filesystem distinct to the one holding the binaries.  An
  end which, on a second though, I cannot readily suggest on how to
  achieve any other way.

  And /dev.

Which is on tmpfs most of the time, anyway.

  And /boot.

For the slightest chance that I may one day move away from
GNU/Linux, I keep bootloader's files on a separate FS.
(Presumably, even if I'd move to another system, I'll hardly
part with GRUB.)

To put it another way, I do not consider an installed bootloader
to be part of a system (while its installer may be such a part.)
And indeed, I've used to have a bootable floppy disk
(CompactFlash, USB Flash) image with GRUB installed, but
otherwise hardly related to GNU/Linux.  (Say, it might contain
Memtest86+, FreeDOS, and some random data.)

-- 
FSF associate member #7257


-- 
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/86obxn1him@gray.siamics.net

/ vs. /usr vs. fsck(8)

[Ivan Shmakov]

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

[…]

  So let's look at the reasons against merging /usr in / listed in my
  final summary.  All of them do not apply to merging / in /usr, and
  actually become arguments in favour of doing it:

  - NFS: sharing a read only system over NFS becomes much easier (I
  would say that it actually becomes possible...)

Agreed.  Being one who actually have experimented with such a
setup, I'd say that it makes an NFS boot environment much easier
to maintain.

[…]

However, please note that the current state of affairs (AIUI) is
that we rely on / to check all the other filesystems before
these are mounted.  If the / filesystem is itself modified in
the process, we're to reboot the system for safety.

With /usr being mounted by initramfs, either we'd need to allow
/usr to be checked /after/ it's mounted (by the filesystem
checkers residing on it, which doesn't seems all that sane),
/or/ we'd need to put all the filesystem checkers to initramfs.
This implies that the latter would've to be updated each time a
new filesystem check program is added to (and, perhaps, removed
from) the system.

[…]

-- 
FSF associate member #7257


-- 
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/86k48a26n7.fsf...@gray.siamics.net

/ vs. /usr vs. udev(7)

[Ivan Shmakov]

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

[…]

  And then there is the big argument in favour of it: booting without
  /usr is becoming more and more difficult.  The two current solutions
  for this adopted by udev and the related tools are both suboptimal:
  waiting in a loop for /usr to appear can fail due to the timeout (and
  I wonder when we will hit the first deadlock), and moving even more
  stuff from /usr to / can work only up to a point.

I don't seem to understand why is this supposed to change as we
shuffle the things around.  The problem is that we currently are
starting udev from /, which is mounted from initramfs.  Should
we move, we'd have to mount /usr from initramfs instead.

Now, if we're to keep udev starting /before/ /usr is mounted,
we'd have to start udev from initramfs.

OTOH, if this order isn't to be kept, why not just simply allow
udev to be started after /usr is mounted, while retaining /
vs. /usr distinction we currently use?

-- 
FSF associate member #7257


-- 
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/86fwiy26j2.fsf...@gray.siamics.net