Re: Command /usr/bin/mv wrong message in German

[Russell Stuart]

On 1/4/24 10:18, gregor herrmann wrote:

% dpkg -S $(which mv > coreutils: /usr/bin/mv


On bookworm:

$ dpkg -S $(which mv)
dpkg-query: no path found matching pattern /usr/bin/mv

This is caused by the /bin -> /usr/bin shift.

The reason I'm replying is after one, probably two decades this still
annoys me:

   $ dpkg -S /etc/profile
   dpkg-query: no path found matching pattern /etc/profile

It was put their by the Debian install, and I'm unlikely to change it.
Its fairly important security wise.  It would be nice if "dpkg -S" told
me base-files.deb installed it.  It would be nice if debsums told me if
it changed.  There are lots of files like this, such as /etc/environment
and /etc/hosts.  There are some directories like /etc/apt/trusted.gpg.d/
which should only have files claimed by some .deb.

To put it another way, Debian's audit trail of files managed / used by
the distro has never been great.  There was a modest proposal ages ago
(by aj I think) to improve this, but it was rejected.  To me it looks
more important now than it was then, and it was pretty important then.


OpenPGP_0xF5231C62E7843A8C.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: A mail relay server for Debian Members is live

[Russell Stuart]

On 17/7/22 10:37, Ansgar wrote:

On Sun, 2022-07-17 at 10:29 +0200, Dominik George wrote:

tl;dr: DKIM-signed mail is verifiable, but only the headers; the body
can be tampered with;


This is just wrong. There is no reason to sign mails to ensure
authenticity if one can just change the body...


The goal of this isn't to provided end to end authentication.   It's to 
hold the domain in From: address accountable for the content the 
message.  Without DKIM the From: address can be easily forged, and any 
spammer can impersonate the From: address.


Despite what Dominick says the body is always included in the DKIM 
signature.  In fact the just about everything in the email can be 
covered by the signature.  In an ideal world you would cover everything, 
but in our world relaying SMTP servers regularly append stuff to bodies 
and mangle with headers (eg, spamassassin will shove stuff into the 
Subject:), and that breaks the signature.  DKIM "solved" this by 
allowing the sender to specify what headers in the message the signature 
covers.  You also get to specify a body length, so all characters after 
that length are ignored, thus "solving" the append problem.


rfc6376 does supply a recommended list of what to include in signature, 
but perhaps takes compatibility too far by allowing everything to be 
optional, bar the From: field.  No receiver would accept purely the 
From: field signed as that makes replay attacks trivial, so each 
receiver sets its own standards.  And yes, that's messy.


But in practice, what has to be signed to make it impractical for 
spammers to use existing signatures in replay attacks isn't much.  The 
From:, Date:, To:, Cc: is enough.  The fact that most email clients 
order your inbox by date means the Date: field will ensure an existing 
signature is only good for a few days before the spam appears too far 
down to be noticed.  So it all works out for it's intended purpose.


It's intended purpose isn't to replace gpg signed emails.  It can't 
really, as it's not signed by the sender, it's signed by the domain. 
That means a ISP can forge a signature from anybody using them.  That 
doesn't matter for DKIM, as it's intended purpose is to hold the ISP 
accountable for spam sent from it's domain.  That assumption is the ISP 
will police it's users.


Nonetheless, I personally use it as a form of authentication.  My wife 
once fell for a PayPal phishing attack that cost us well over $1,000 
from memory.  The curious thing is phishing the email had a valid DKIM 
signature from paypal.com.  I contacted them immediately and a full 
refund happened very quickly.  I'm pretty sure the refund would have 
happened anyway, but it was nice to have the DKIM signature on my side.


OpenPGP_0xF5231C62E7843A8C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Firmware - what are we going to do about it?

[Russell Stuart]

On 19/4/22 10:27, Steve McIntyre wrote:

  5. We could split out the non-free firmware packages into a new
 non-free-firmware component in the archive, and allow a specific exception
 only to allow inclusion of those packages on our official media. We would
 then generate only one set of official media, including those non-free
 firmware packages.


The motivation here for splitting non-free firmware into a separate 
component is so we can install Debian on modern hardware.  That's a good 
reason, but I've always thought there was at least one other good reason.


It doesn't belong in Debian.

Unlike everything else, we usually don't have the source, which neuters 
many of the nice security properties inherent with open source.  We 
don't compile it, because even if we did have the source it's probably 
for a CPU & silicon we don't support.  Ergo reproducible builds are out 
of the question: it could literally contain, copy or do anything the 
hardware allows and none of us would be the wiser.  Peculiarly, we don't 
care about the licence, beyond being allowed to distribute it in the 
first place.


One of Debian's foundations is the DFSG but when it comes to this stuff, 
freedoms?  We don't even have the freedom to avoid it.  I'm genuinely 
surprised the project has managed to be in denial and pretend it had a 
choice for this long.


In short non-free packages we have the source for is one thing.  These 
binary opaque blobs are quite another.  They should be in a different 
component.  Non-free-firmware sounds far too innocent to me.  How about 
"not-debian", or "under-sufference".


OpenPGP_0xF5231C62E7843A8C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Making Debian available

[Russell Stuart]

On 17/1/21 3:27 am, Russ Allbery wrote:

"Andrew M.A. Cater"  writes:
Wifi is the tough one: The companies that dominate laptop chipsets 
- Broadcom/Realtek/Qualcomm don't make it easy to find out which 
particular chipset it is. For USB Wifi connectors it's even harder 
- lots of Realtek chipsets in cheap dongles seem to require you to 
go and get a repository from git and build DKMS - RTL8812* springs 
to mind.


For the record, this is always the problem I have.  The last system I
installed didn't have an Ethernet port.  I think there was some way 
to make Ethernet work over USB, but I didn't have the right 
hardware.


To me, this is *the* problem. I always use netinst. Once the thing is
running editing /etc/apt isn't hard, so all netinst has to do is a base
image install. But, if I can't get the network up and see the disks I
can't install.

Seeing the disks is invariably caused by the kernel not recognising a
modern chipset, which means I must install with testing that has a
matching modern kernel. Working WiFi almost always requires firmware.
Testing doesn't produce netinst with non-free firmware and I'm normally
installing several of these things, so I have now become proficient in
rolling my own non-free netinst.

I guess it might be possible to make it harder to install Debian on a
new laptop, but rolling your own netinst sets a pretty high bar so you
would have to work at it. I occasionally get asked to install Debian,
and it's hard enough that I carry a USB with one of these netinst's on
me at all times, along with my GPG fingerprints.

So for me at least, the fix doesn't require putting all of non-free on
the install media. It just requires firmware-*. (Which brings me to
another whinge: why doesn't firmware-linux-nonfree include things like
firmware-iwlwifi so I don't have to go on a whumpus hunt for every
firmware package. Sigh.)

I happen to strongly agree with the sharp distinction between free and
non-free in the archive. But in this case, I think we should be carving
out an exception.

If you want a softener for those rigid ideals (I need one myself), try
this: these firmware blobs are peculiar. They don't run on the same CPU,
we talk to them with strictly open API's and protocols. In that way,
they aren't anything new. We already talk to and depend on megabytes of
nonfree software to get our laptop's booted, but we tolerate it because
it lives in ROM. We don't consider firmware in ROM to be part of Debian
even though it must be running for our Debian machines to run. It's true
the difference is these problematic firmware blobs do live in Debian
packages, but it's not because we package them in most of the usual
senses: we don't compile them, or modify them and no software packages
by Debian inspects their contents. For these firmware packages the
packaging system has been reduced to something that does a good
imitation of a copper wire: faithfully coping some bits from the
manufacturer to the hardware they made.

My suggestion is we could create a new section of the archive for
packages that places far stronger restrictions on what Debian is allowed
to do with the packages contents (to wit: be a conduit between two
external parties, and no nothing else), and in return we do tolerate it
on our install images.

We already tolerate something similar. fwupdate pulls down non-free
blobs onto our Debian boxes, and installs them so our Debian machines
can use the firmware therein. It's in free, and AFAICT no one has a
problem with that. This is a step beyond fwupdate of course, as the
firmware is coming from our servers rather than someone else's. But I
would have thought that would make the situation better, not worse. This
is software we can vet at our leisure, take down / revert if it turns
out it violates our sensibilities, like say discovering a new version
has critical CVE's.  Firmware coming from our own servers, signed by our
keys gives us far more say on what non-free software we allow on our
machines than fwupdate does now.


OpenPGP_0xF5231C62E7843A8C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: isc-dhcp-client sends DHCPDISCOVER *before* wpa_supplicant authenticates/associates/connects.

[Russell Stuart]

On Sat, 2020-07-11 at 22:12 -0400, The Wanderer wrote:
> I don't run either systemd or NetworkManager, and I'm not currently
> interested in changing either of those things, but I am interested in
> trying out an alternative to wpa_supplicant. Is there an appropriate
> similar procedure for such an environment, or would I have to
> experiment and play around trying to get things to work?

I don't use network manager, so I'm in a similar position.

From what I can see iwd lacks two features of wpa_supplicant.

Firstly, there doesn't seem to be a way to attach iwd to a particular
wireless interface.  Iwctl doesn't provide one, and I don't see any
other way to tell it.  Most people have just one wireless interface so
it may not be a huge issue but it is an impedance miss-match with
things like ifupdown that are focused on interfaces.  Maybe that's the
problem with network manager too.

Secondly, it doesn't support wpa_supplicant's priorities.  I use them a
fair bit.  For example, I tell wpa_supplicant to favour my phone WiFi
hotspot over others, so if I have a connectivity issue I can just turn
it on.  That said, I guess I could just use iwctl to manually connect
to the phone.


signature.asc
Description: This is a digitally signed message part

Re: Heads up: persistent journal has been enabled in systemd

[Russell Stuart]

On Tue, 2020-02-04 at 18:10 -0800, Russ Allbery wrote:
> It does take a bit of retraining to use journalctl instead (and I'm
> personally not horribly fond of its UI, although that's probably
> because I'm using it wrong), but it's a lot better at effectively
> narrowing log messages to the things of interest once you get used to
> it.

journald has nits I mention below, but I was prepared to put up with
them and drop rsyslog until one day a server stopped in a nasty way and
journalctl refused to display what lead up to the crash because it's
binary logs were corrupt.  As far as I was concerned this made journald
unfit for use on production servers.  (rsyslog's logs also get 4k lumps
of nulls and other garbage in them in similar situations, but they
remain usable.)

That was a long time ago, and it may well be fixed now.  But if it
isn't IMO turning off rsyslog by default is a bad idea.  My view is the
main reason Debian exists is to serve as a reliable base for production
machines.  Debian Desktop is what I use on my personal machine and yes,
dropping rsyslog hardly matters there, but I wouldn't be using Debian
Desktop if I wasn't using Debian in production.   

Another journald anti-feature (which is probably an unfair attribution
as it is almost certainly a consequence of systemd's design), is a
manually started service doesn't print the reason it refused to start
to stderr.  Having to fire up journald and wade through it's crappy UI
to get something sysV used to put under my nose is a step backwards.

Finally, it may be I just don't know how to use it well, but looking
for a needle in a haystack of logs is slower with journalctl that it is
with grep, and not by a small margin.  Journald making the thing you
spend most time doing with logs slower doesn't help it in the
slightest.  But I don't spend a lot of time searching logs, so it
wouldn't stop me from dropping rsyslog.

Get rid of those problems, and dropping rsyslog becomes a no-brainer
for me.


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Proposal for new source format

[Russell Stuart]

On Sun, 2019-10-27 at 20:29 -0700, Russ Allbery wrote:
> If you modify the upstream source, then by definition you do not have
> reproducibility of the upstream source, and you're now talking about
> something else (review of the changes, which I called audit in my
> previous message).

I think I'm guilty of a poor choice of words.

> I have no idea how you got that from my previous messages, but you
> have misunderstood.

Excellent.

> This is exactly my objection to reducing everything to patches rather
> than using the power of Git to represent the history and structure of
> the changes made for Debian.

Personally I don't see the "power of git" adds much apart from history,
but really it doesn't matter for this discussion.

> am completely baffled by your belief that this is inherently easier
> to do with quilt than with Git.

I don't believe that.  I guess we are talking past each other.  Out of
curiosity do you do maintain the changsets manually in git, or use
something like gquilt?



signature.asc
Description: This is a digitally signed message part

Re: [RFC] Proposal for new source format

[Russell Stuart]

On Wed, 2019-10-23 at 09:49 -0400, Theodore Y. Ts'o wrote:
> Generating a reproducible source package given a particuar git commit
> is trivial.  All you have to do is use "git archive".  For example:

It is indeed.  Almost a tautology.  But it's not what I'm interested in
doing.  The focus is on showing the connection between upstream's
source and Debian, not on reproducing Debian's source.

Repeating my earlier example, I want to show whether openssl (insert
name of fully audited package here) in Debian is a bit for bit
reproduction of upstream's openssl.  It won't be, of course, so I want
the next best thing: an audit trailing explaining exactly why it's
different.

Harking back to the time we removed the randomness generator from
openssl, it's very nice to have a single patch say "it was removed
because it wasn't exercised in the tests.  upstream didn't respond to
requests for comment" rather than having it interspersed with the 650
odd other lines of other changes we carry with no explanation.


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Proposal for new source format

[Russell Stuart]

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
> I define reproducibility as generating the same Debian source package
> from a signed Git tag of my packaging repository plus, for non-native 
> packages, whatever release artifacts upstream considers canonical
> (which may be a signed tarball or may be a Git tag or may be
> something else entirely).

That is a great definition of reproducibility if all you are interested
in is the Debian version of the package.  It is not so great if you
want is the upstream version of the package - ie, it is important to
you that it behaves identically or at least diverges in accountable
ways.  In that case you want a clear audit trail from the upstream
source to the Debian binary.

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
> All of this business with patches and whatnot is an implementation
> detail.

If you are thinking of patches in terms of .dpatch files in
debian/patches then we both agree, as I don't consider the
representation to be particularly important.  It could be branches
stored in git for all I care, perhaps managed by a tool like gquilt. 

What is important to me is the source contain an audit trail or how
Debian got from the upstream source to the Debian package.  If I
understand your position correctly, your proposal boils down adding a
(single) branch to the upstream .git for the debian changes.  My
problem isn't with using git - it's with the word "single".  It isn't
even with you using a single branch, as perhaps that's appropriate for
the packages you maintain (which it would be if the only change is to
add a debian directory).  My problem is the implication that since it
good enough for you, it's good enough for every package.  It's not. 
When you are carrying a lot of changes it's bloody horrible.

Perhaps an illustration may help.  I used to be a consumer of RedHat
kernels. Back in the 2.6 days they carried 100's if not thousands of
individual patches for stuff they backported form Linux 3.0.  (I gather
they still do carry a lot of patches for their LTS releases.) When you
wanted to add your own modification there was invariably conflicts, and
without knowing what patches it conflicted with and why it was just
impossible.  Then Oracle released their "own" Linux distribution.  It
was a copy of RedHat, something Oracle didn't go out of its way to
acknowledge.  Effectively Oracle was garnishing for themselves part of
RedHat's revenue stream (support fees) using a rebadged RedHat product.
RedHat responded by doing effectively what you are suggesting.  They
replaced source rpm's audit trail of every change they made and why
with one humongous, uncommented patch.  Technically they were operating
in accordance with the layers reading of the GPL I guess - they were
distributing the source.  But it sure as hell wasn't in accordance with
a programmers definition of "source" (which is along the lines of
something you can edit), as porting a patch from a the .orig kernel to
RedHat's became damned near impossible.

A second illustration is the kernel development process itself.  One
huge patch is not considered acceptable.  They must be smaller, easily
understood, digestible patches.  The quilt source format encouraged
that format - to the point of having lintian checks for it.  Nowhere do
you propose a similar mechanism - or even acknowledge it's important.

On Tue, 2019-10-22 at 23:20 -0700, Russ Allbery wrote:
> Checking reproducibility only back to a set of patches does *not*
> provide a real guarantee of reproducibility, since a supply-chain
> attack could still have introduced malicious code in the patch 
> generation process.

You are damming the good because it's not perfect.  It's true there are
still ways of attacking the code, it merely renders those attacks
visible and attributable.  In fact rendering all changes visible and
attributable by insisting they are signed is *precisely* the mechanism
the kernel uses to defend itself both from malware attacks of the type
you envisage and when someone attempts to add copyrighted code that
opens the kernel to legal attack later.  Turns out a bit of sunlight is
a great disinfectant.

On Tue, 2019-10-22 at 23:20 -0700, Russ Allbery wrote:
> like an argument for dropping all of the features that I want and 
> retaining only the feature that you want, when you can derive the 
> feature that you want (at some additional complexity cost, to be 
> sure) from the format that I'm arguing for.

I can see how you might think that.  The reality is a different.  At no
stage have I suggested you should be prevented from using git, or
indeed any other mechanism you desire.  I have said if you adopt a new
system like dgit please figure our a way of implementing one feature
the one you are replacing (quilt) - a way to audit changes.  But it has
been proposed that everybody be forced to drop whatever workflow they
might like in favour of dgit, and you look to be arguing in favour of
that idea.  If we 

Re: [RFC] Proposal for new source format

[Russell Stuart]

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
> This history has at least one commit per upload, although ideally 
> has the package maintainer's full revision history and upstream's 
> full revision history.

I understand you like the history.  A lot of people do.  But not
everyone values it, and I don't.  The only uses I've found for it are
git-bisect, reversing hasty deletes, and auditing who contributed what
which is a handy weapon in a court room copyright battle.  I can count
the number of times I've done all of those things in my life on one
hand.  Regular backups do those jobs almost as well, and I have to do
them anyway.

Source code control becomes a real time saver when you have a lot of
people working on the same source - I'd go so far as to say
indispensable for that case.  Such merging of histories needs a small
amount history to work with of course, and that makes that small amount
of history equally indispensable.  However the typical Debian Developer
scenario of the "lot of people" being you and upstream is a fairly
degenerate case, so their is understandably get some argument about
whether a heavyweight tool like git adds much.  If you like it that's
great - but others thinking it's not worth the bother is also great.  I
doubt anybody who just wants a one off copy of the source is going to
see much in the way of greatness.

On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote:
> I don't agree with this definition of reproducibility.  You're
> defining reproducibility from inputs that I consider build artifacts,
> which to me is rather weird.

That's a perfectly understandable perspective from a Debian Developer. 
But lets take a different perspective, or a Debian user installing
audited-crypto-program-x. What you are dismissing as "artefacts" is
exactly the information the person installing this needs to assure
themselves the Debian version of audited-crypto-program-x is a
reasonably faithful reproduction of the original.  If the packaging is
done well it will be broken down into small changes, each with a
documented purpose.

(None of this is rocket science or new, we are fairly close to it now. 
One the reasons I am writing this is it would be if better - and
definitely not get worse at it.)

The point of defining the process of constructing the Debian source
representation as a "pure function" is to guarantee it faithfully
reflects the original source for and documented changes _only_ - not
some random crap living in stale state carried across from years ago.

From my perspective there are lots of ways a Debian developer could
store this stuff.  Quilt patches with their headers are one and they
work well enough from this perspective - but a Git repository with
branches representing those same changes works equally well, although
it would be nice if a git branch (as opposed to a commit) could have a
rant associated with it about why it is there akin to the quilt patch
header.  (I guess this would be trivial to add by insisting each branch
adds a description file to the debian/branches directory.)  The Debian
developer is free to use whatever representation works best for them,
so long as when I download it, I can easily see the debian version of
openssl contained a patch that changed random number its generator to
getpid(), along with the reason why.

AFAICT, dgit does not address this, at all.  It's written purely from
the perspective of the Debian developer.


signature.asc
Description: This is a digitally signed message part

Re: [RFC] Proposal for new source format

[Russell Stuart]

On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote:
> That seems excessively pessimistic.  What about Git makes you think
> it's impossible to create a reproducible source package?

Has it been done?  Given this point has been raised several times
before if it hasn't been done by now I think it's reasonable to assume
it's difficult, and thinking that it's so is not excessively
pessimistic.

I personally wonder how the mirrors are expected to handle .git
repositories.  That would increase the number of files they have to
handle by a couple of orders of magnitude.  What are the plans for
that?  Maybe you think that can handle it?  Maybe you plan to abandon
the mirror network in favour of something else like the CDN?  Maybe
you plan to remove the source from the mirrors?

Finally, there are more consumers of the source format than the Debian
packagers.  For example, I regularly download Debian source packages
just to figure why the hell something isn't working as I expect.  When
I do that, there are two things that are important to me:

1.  The download is as small as possible, and doesn't require a
specialised tool.  (Github and gitlab go to the trouble of 
providing just such as thing, which I think is evidence it's
needed.)  The current format is pretty good in this area.  At
a pinch you can get away without using deb-source to unpack it. 

2.  The point that has been raised here - reproducible builds of the
source package.  By that I mean a reproducible build should be
pure function that is given the upstream source package and some
data in the form of patches or whatever, and ends up with the
source and build instructions.  Being a pure function it always
produces the same outputs give the same inputs.

Unfortunately Debian doesn't always do a good job of this 
currently, albeit for good reasons - we can't distribute the 
upstream source package so DD's rebuild it, but they are allowed
to do so in any way they please.

Any source format that handled the issues above would get the thumbs up
from me.  (Interestingly despite the hairs it has in other areas the
rpm source format have always done well on those issues.) 
Unfortunately Bastian's proposal doesn't address them directly.


signature.asc
Description: This is a digitally signed message part

Re: Init systems and docker

[Russell Stuart]

On Fri, 2019-10-11 at 19:25 -0400, Jose-Luis Rivas wrote:
> There's not much sense in using systemd inside a docker container, to
> be honest.

To put it another way, in the container world the init system belongs
outside of the container.

That is because the closest thing equivalent to a container is not a
box running Debian doing multiple things, it's a single process.  In
fact if you are Google it's actually simpler - it's a process whose
executable is a single statically linked file.  It pulls it's
configuration from something like etcd (something that lives in the
cloud), it uses the file system as an extension of it's RAM - temporary
storage that can be blown away when the process exits, if it needs
persistent storage comes in the form of a database it connects to using
TCP/IP.

It's utility doesn't arise because it's more powerful and flexible than
the environment Debian provides.  On the contrary, it is fare less
rich, and flexible than the environment Debian provides.  It's power
arises because reduces the dependencies to an absolute minimum.  It is
one file whose main configuration is the TCP endpoints its receives
commands from and sends results to, and TCP endpoints of services, log
storage and databases it depends on.  It's only dependency outside of
that list of endpoints is an amd64 machine with some amount of RAM and
CPU cycles and the Linux syscall API - something that can be replicated
1000's or millions of times automatically and on demand.

A major part of it's utility that unlike Debian dependencies (like say
a Web Server or a .so of the right version) that programmers tend to
assume is there or their program can break in weird and wonderful ways,
programmers tend to assume this one dependency, a TCP connection, is
unreliable and ephemeral.  So you can create these things and destroy
them to handle varying loads, and outages in any one data centre can be
handled by shifting the load to another one.  The consistency of
persistent data is not a problem because it's stored in a full ACID
database.

An init system of any sort in this is just unwanted complexity.  What
replaces the init system is something starts up these containers and
connects them together on an as needed basis. Kubernetes is one such
system, but there alternatives.  Docker Swarm is a much simpler thing
that creates something is closer to a Debian box (a collection of
containers running on one physical box).

In the most evolved container systems inside a container it's not just
the init system that's considered an anti-pattern, a distribution
Debian is also out of place.  None of the services Debian provides
(like packaging, dependencies, security upgraded) are helpful.  The
host box will have an OS - but it's just a support system for
Kubernetes and you don't really need an entire distribution just to run
one program.

However, that is the extreme edge.  It's where you have a team of
programmers creating a static app that includes all of the services it
needs, like a web server.  Us smaller guys will use pre-packaged
software provided by a distribution simply because we are familiar with
nginx or apache, and don't want to compile stuff to do off the shelf
functions.  The rest remains the same - a container is a single
process, configuration is primarily connecting TCP end points, things
are written to retry when a  TCP connection dies, security patches are
"installed" by rebuilding the container and restarting it, shells and
what not in containers are there merely to facilitate development,
debugging and fault analysis.

The most popular container distribution is I think Alpine Linux which
has an impressively small base install.  If Debian wanted to compete in
this area it would have to start by shrinking it's minbase install by a
factor or 10 or so.  Anybody arguing about what sort of init system
that install includes hasn't groked containers yet.  


signature.asc
Description: This is a digitally signed message part

Accepted pam-python 1.0.7-1 (source amd64 all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 18 Sep 2019 20:25:13 +1000
Source: pam-python
Binary: libpam-python libpam-python-dbgsym libpam-python-doc
Architecture: source amd64 all
Version: 1.0.7-1
Distribution: unstable
Urgency: high
Maintainer: Russell Stuart 
Changed-By: Russell Stuart 
Description:
 libpam-python - Enables PAM modules to be written in Python
 libpam-python-doc - Documentation for the bindings provided by libpam-python
Changes:
 pam-python (1.0.7-1) unstable; urgency=high
 .
   * New upstream.
Checksums-Sha1:
 13792bdb8286d2942a90e9e83cd6b8e427f108bd 1961 pam-python_1.0.7-1.dsc
 f2c303011b3cd61a88d3fcab845c30ceac46356c 47487 pam-python_1.0.7.orig.tar.gz
 328aac8c65742534bb70fffadc44b3ff39821bc4 1 pam-python_1.0.7-1.debian.tar.xz
 8169b63698dd49bdc72969d683925fa3c8194482 49544 
libpam-python-dbgsym_1.0.7-1_amd64.deb
 7342e17ce735c164b9ab51469924db1b02a2860e 54216 
libpam-python-doc_1.0.7-1_all.deb
 ad04838c6c47b83fc7684431a9b5a1b483ccd2fc 29736 libpam-python_1.0.7-1_amd64.deb
 fac1721938134d71f53e1612fc5cfaa5ecf1bad7 8375 
pam-python_1.0.7-1_amd64.buildinfo
Checksums-Sha256:
 a17b6b97a8595d2a7c675d2ad2ffcc5bdb758a1d110366e966928e7cea05a5b7 1961 
pam-python_1.0.7-1.dsc
 96ce72fe355b03b87c0eb540ecef06f33738f98f56581e81eb5bffbad1a47e07 47487 
pam-python_1.0.7.orig.tar.gz
 e0347d1fbd8ef513b0ffab295d9a21af85023db57570f4376ac0e14bd0f97b42 1 
pam-python_1.0.7-1.debian.tar.xz
 46895904cfca2594b5907c1df54ace39aeba2c4bfc16c8336b8c9745bff445d6 49544 
libpam-python-dbgsym_1.0.7-1_amd64.deb
 8b855eacf01205c7c0ebcb606d6263d0e9936b036f0a21e867949a48e5389b65 54216 
libpam-python-doc_1.0.7-1_all.deb
 b8ebf514996c4082e942a30c21e03408351454729b70a84724e567be39617ed4 29736 
libpam-python_1.0.7-1_amd64.deb
 892564dae6899af1704003a85b5e895d00330bb027a1dbd8fb4beeabd9b468ae 8375 
pam-python_1.0.7-1_amd64.buildinfo
Files:
 043ab8fd69c3bc5099c16e0bdaf24208 1961 admin optional pam-python_1.0.7-1.dsc
 55153c1a8015a7ede87985fa6816db78 47487 admin optional 
pam-python_1.0.7.orig.tar.gz
 1729d21155d32bd146088f4210f410ab 1 admin optional 
pam-python_1.0.7-1.debian.tar.xz
 2ab74a8d5fcd74b655b059b76b8d9670 49544 debug optional 
libpam-python-dbgsym_1.0.7-1_amd64.deb
 942bc7e6443aac9c0eaca34d89db04be 54216 doc optional 
libpam-python-doc_1.0.7-1_all.deb
 07d1730fbb343a85a8c52ce6d1c3d69f 29736 admin optional 
libpam-python_1.0.7-1_amd64.deb
 9e7c02ea01afe05cb1441ff137cd469c 8375 admin optional 
pam-python_1.0.7-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAl2GJgwACgkQrNSfiF5U
Um6qRw//YB6R1EoUlm6/Ox+JBrM8XdzupdBBlT94qtS3C68m9G9mkFBjLo/ANUNv
td4DpGewVHQPg8lUp9+gHvRFCNFyLwjo1xCk/1DCyfZuLvIic/WB279M/Ylsv0ay
GKLeEJyc6Beq6ISazgwD0ErdLC6S4SBJvaewz/7D/PnK8HeB2ZZOt5knwmELJq++
E870ZH8LDIzzkQ6DR/Ae0308ho7wVREOICM1lDIbuYaKro2+rmDPr3+cgCTfW7BM
hagaFG2SMmKnJ2oT35meLGGL6fFX2vuJ+9VVkObSmYrY1RyCnAAHbd8cPOtQ/sPP
97xUSKydJOdvuKWveKG2+1WkSpbwMAcAuoqPBAUKkVHWLMdw7vURNwM9RVPLxbea
noAU3aUzNTDidBNnkskTbGmu75XI2xqc6xJceXaXnszu70p8TUKwU9lDmLMNdUWj
UkHJsbl6mONojIoy9L9fLdINOb6TZNS7/kgiiE7eMHizRi8zVXtsmDRXDrnhom7A
ldAhc7091eT3XICLtk30g/FUHdubcDRCWnc3lpaKx3GNVcztS8UZhbhWMZGytkWe
GUlrRyRDTkyt+hStKc9t524h/WxSytFq8Pn+EKnleI+wWGbGs0h6FU3UortaCFZC
ngwEHFqdsPvRVAZPXKkvm/HNgSTkqdmlDv3LIkXTyxi04ktXMRI=
=sYh5
-END PGP SIGNATURE-

Re: duplicate popularity-contest ID

[Russell Stuart]

On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
> I am using Debian for two decades now, and I realized that necessity
> two days ago.

Ditto - except for me it was a few seconds ago.

signature.asc
Description: This is a digitally signed message part

Re: Programs contain ads - acceptable for packaging for Debian?

[Russell Stuart]

On Thu, 2019-06-20 at 13:15 +0700, Bagas Sanjaya wrote:
> Suppose that an upstream has released a program which its license 
> conforms to DFSG (named ZZZ), but when I test it, ads placed by the 
> upstream appear (such as pop up ads). Since ads can affect user 
> experience of ZZZ, but at the same time the upstream get paid by ad 
> networks which he place the ads into ZZZ, would it acceptable to
> package ZZZ for Debian?

I don't know whether it's relevant to your question, but we already
have software in Debian that displays pop-up ads.  Zoneminder displays
a pop-up nag for donations.  You can turn it oft, but unless you delve
into raw SQL hackery of the underlying DB you will see it at least
once.

signature.asc
Description: This is a digitally signed message part

Re: Preferred git branch structure when upstream moves from tarballs to git

[Russell Stuart]

On Tue, 2019-04-30 at 09:25 +0800, Paul Wise wrote:
> I like this option because it still works well if we ever decide to
> fix a fundamental flaw in the Debian source package layout.

I suspect whether that's a fundamentally is a matter or personal taste.
 On this point my taste aligns with yours.

I've used both rpm source format and the Debian one, and IMO the rpm
one is mostly better.  The primary reason is the one you've mention
here: they maintain the separation between the source, rpm spec, and
build areas's far more cleanly than Debian does.  This makes some
common flaws one often flaws in Debian packages just disappear: like
cleaning up the source directory after a build.

Where the rpm format goes wrong is it then beaks that separation in the
actually .srpm format by putting the upstream source in and rpm bits in
one file, which is of course what Debian gets right.  Sigh.

On the positive side, rpm and deb seem to be gradually converging in a
sort of co-evolution.



signature.asc
Description: This is a digitally signed message part

Accepted nagios4 4.3.4-3 (source amd64 all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu,  7 Feb 2019 19:35:53 +1000
Source: nagios4
Binary: nagios4-common nagios4-cgi nagios4 nagios4-core nagios4-dbg
Architecture: source amd64 all
Version: 4.3.4-3
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart 
Changed-By: Russell Stuart 
Description:
 nagios4- host/service/network monitoring and management system
 nagios4-cgi - cgi files for nagios4
 nagios4-common - support files for nagios4
 nagios4-core - host/service/network monitoring and management system core files
 nagios4-dbg - debugging symbols and debug stuff for nagios4
Closes: 902138 902216 905523 917160
Changes:
 nagios4 (4.3.4-3) unstable; urgency=low
 .
   * Fix CVE-2018-18245 (closes: #902138)
   * Fix CVE-2018-13441, CVE-2018-13457, CVE-2018-13458 (closes: #917160)
   * Removed /etc/nagios4/htdigest.users purge (closes: #905523)
   * Fix unknown RPM_ARCH (closes: #902216)
Checksums-Sha1:
 cd0cc71ba6978c40c07e4416502f6904e7fc2373 2029 nagios4_4.3.4-3.dsc
 c1530e7ac49a8c39be7bfd5d23f7a8c7955ffdac 11086829 nagios4_4.3.4.orig.tar.gz
 3d507eda53043dcb6670478825bf1c20df155eaf 451304 nagios4_4.3.4-3.debian.tar.xz
 7fe08577c4f42a4b0f943d08b81105023838ed28 1272762 nagios4-cgi_4.3.4-3_amd64.deb
 f088216745e9a153fbc38820279633ca73e37e3e 65174 nagios4-common_4.3.4-3_all.deb
 2b1c22028f5a9bc9cc87667e2149e913f17f2399 246352 nagios4-core_4.3.4-3_amd64.deb
 d36414d94d3f43c812fc521c22a028e1daeb6e07 6422044 nagios4-dbg_4.3.4-3_amd64.deb
 7b3a9cd8d8ea6703dc732ee497e06fddce304619 8551 nagios4_4.3.4-3_amd64.buildinfo
 50df7fbd13579f674e36ff008f77eec9bf499127 12812 nagios4_4.3.4-3_amd64.deb
Checksums-Sha256:
 b120b36d36899febc1eea480bfcb682337223feeab1ebc9382ae2d6309b05531 2029 
nagios4_4.3.4-3.dsc
 f2b54defb8ca648fa93fe1c81501cbd12c34d8eace96c6104678b27cd5dd203c 11086829 
nagios4_4.3.4.orig.tar.gz
 b7df19a5fb44e4ce145d9a85f5883a8199b7f9f8b16d26ac7772a1e66a1fd838 451304 
nagios4_4.3.4-3.debian.tar.xz
 dad08976dd579ee8f4c421bacfdd90192003e40c85e6b070129a266eeccd2064 1272762 
nagios4-cgi_4.3.4-3_amd64.deb
 52e772f3fe757215c4556894d24f44ab8a22d39c00ceb031852938f403be7e86 65174 
nagios4-common_4.3.4-3_all.deb
 c9e25aac9b4f904aad6a48486e7241aa1bc78e03ff39971e431203e88973b859 246352 
nagios4-core_4.3.4-3_amd64.deb
 b3e3a2e0c58b3ec9df8c398a8b8bd649e2dd49edd9d4a429670948c214a55c93 6422044 
nagios4-dbg_4.3.4-3_amd64.deb
 e1b26ce30a7716b29fb78527ffd1800072b1ffdc1e00c2ac5fd71924afec043b 8551 
nagios4_4.3.4-3_amd64.buildinfo
 d4d863b536d4ca6ced08f38b81e0d0c862ef2eb2383df2efe459e17175133b09 12812 
nagios4_4.3.4-3_amd64.deb
Files:
 0d13f7287e29e46670ba4ed880b93f8e 2029 net optional nagios4_4.3.4-3.dsc
 b965d41af790967e284c3f02f8a9948b 11086829 net optional 
nagios4_4.3.4.orig.tar.gz
 857c7b60a24e27c086242ee055c159e2 451304 net optional 
nagios4_4.3.4-3.debian.tar.xz
 2890d167b9ad5d71cb9273a97c2cc4eb 1272762 net optional 
nagios4-cgi_4.3.4-3_amd64.deb
 1e38002ac7c8d1406c4c16174fdefe9e 65174 net optional 
nagios4-common_4.3.4-3_all.deb
 d5079786c5eda6c67960cc5c571a9a7d 246352 net optional 
nagios4-core_4.3.4-3_amd64.deb
 f9c8d178d13b7753f23859067de0ddad 6422044 debug extra 
nagios4-dbg_4.3.4-3_amd64.deb
 8a2873b7689ac59aec433cb64dc91782 8551 net optional 
nagios4_4.3.4-3_amd64.buildinfo
 3394f3e7705ac045f9b87034bc8c1633 12812 net optional nagios4_4.3.4-3_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlxiYM0ACgkQrNSfiF5U
Um436g/6AtU0TJU0qXPOTck1Gvap9Sb10ECTQ3SNLUm4RBlaSete45vsuK8G5GA0
40OmY9vzL8dCprHlAR1Qan0B8U6qbL0ZgWTlmXFTyPZak9XctUz0BAS/nxWutPAj
XdF8xDENxU6rBmi2tLVXujJO8y/4Mu+3EmsIs1LYlqCDZ68UcECoxhzBZbl+pbSk
gttTcT30NOc4YiSO26fIUXpnUW+2NnW+8ogeGLqBKk+wN5nNwptr2QTjvRV1mC3X
3tHDrhRFyCNxJgClQP7ElKxVsG+2BVq6VYBGzQVA9DBxWGv0w4PRx45VejE0pOxR
zZlBkcjUMFPtODEdQEdIGZJ7Yj8rBSzqK8U2Xc8OHF4HYum1hfgqNHMdEXvReTIO
9Uf7Sjr5dk54oLRNZQmCl1evnGW96aa8So3t1cIFkOuy2q3iUP+ndnnJXAMmuDuE
iUw5dGA0Tu2Y9hn/gGdmrWTrbQliIR+ZN+fESPq4F1ta02BvfoLlITHQ2JH3X/Wy
mjIdAVBP3+LzWxFtWsvTIXJkUc46CNI99A16gztOfjlOauEG1A2ZDpCwXEDge9P7
AuWNgOUyZIndCMpjcquRhurH0HCdiNiQ2cEZTsKw0lSqnP/TNjmSdJGfwjMe8EPq
ffqSQj4EpyCzBfH8TN5cmUdDT6wBmUPx/0WIN6UTUNAqXplFmC0=
=1Jiw
-END PGP SIGNATURE-

Accepted fdb 2.0.0-1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu,  7 Feb 2019 20:43:34 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 2.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart 
Changed-By: Russell Stuart 
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Changes:
 fdb (2.0.0-1) unstable; urgency=low
 .
   * New upstream version
Checksums-Sha1:
 225ded0d11af6a7afa2c44bf11249ae5b316ba75 1982 fdb_2.0.0-1.dsc
 64286980dac009d5a1f3012dfe6a0781e898e591 896815 fdb_2.0.0.orig.tar.gz
 88bc0623135e198e09347393ca5d3b38a71e7e51 4748 fdb_2.0.0-1.debian.tar.xz
 3521f062800dd9bb98df748e66314b10f919fce3 7912 fdb_2.0.0-1_amd64.buildinfo
 1fc4b67aa17333d6e4a0527dbddfb6206158adf9 620580 python-fdb-doc_2.0.0-1_all.deb
 874937e29ceaeed2546e2ed302b35fc73f2a1dbf 124398 python-fdb_2.0.0-1_all.deb
 8388c6288db9b848a02921062675fed6ca0f1871 124242 python3-fdb_2.0.0-1_all.deb
Checksums-Sha256:
 9321e0366e1887f735c6d330800ebc9a65d24809c1c33e7d4b49a22b2c8d2258 1982 
fdb_2.0.0-1.dsc
 197313dad7d1f774c3c73ba7348a8b57c5c67eb50572bd352f0079696ee0cbdb 896815 
fdb_2.0.0.orig.tar.gz
 291440fab94be04c08fa183a7e04dac75a6ee0287fd29b4594865b275fdc7535 4748 
fdb_2.0.0-1.debian.tar.xz
 2bfd6f09b33039b90d984835257a865b1bb4676ed327fa2cf9b7fdf5999b693c 7912 
fdb_2.0.0-1_amd64.buildinfo
 663ab3e23d983c50e1d9d45bd12d0a92e20b82517bcf78960afdfd834011bc00 620580 
python-fdb-doc_2.0.0-1_all.deb
 5a2bfc46d4487a199c402258f3ba0711872cfd608794f91d652012d6b94ff73b 124398 
python-fdb_2.0.0-1_all.deb
 258db723dabf7f9973c85377ddcbf82c59479053c7c634e453a1db9a3ac353ef 124242 
python3-fdb_2.0.0-1_all.deb
Files:
 b3744d38a33215ec55cf87ffbd8064ae 1982 python optional fdb_2.0.0-1.dsc
 e60836e57d8dd9ab07a17b44be0d0797 896815 python optional fdb_2.0.0.orig.tar.gz
 efa4cc4922b7aa192e7338a9e57883a1 4748 python optional fdb_2.0.0-1.debian.tar.xz
 03aef701b6c5f6a40a6398311936f010 7912 python optional 
fdb_2.0.0-1_amd64.buildinfo
 1fde4866a46ec4dc23f77ab2c3976362 620580 doc optional 
python-fdb-doc_2.0.0-1_all.deb
 578062f53fbdb6948f450b8a30975965 124398 python optional 
python-fdb_2.0.0-1_all.deb
 c304072e9f140fb1000effa8e01820a5 124242 python optional 
python3-fdb_2.0.0-1_all.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlxcFnMACgkQrNSfiF5U
Um7lhQ/9GuDE8z/meNkkQ/URF81Go8ADsfBG0ucd7ZZ0R6IZplPM1Cppwq0X1lj7
oBaBcafMWRdCR41DyGTeXC7Y8FXI4E3tj5rRwbR40KXV26cAbnnOrC3OkedFc/BB
wi4ynYo8liQOB9KKMso0Z+MG+WHi+HBnT5IHWfHR/NnvVLSobNP+fkHwZD4RxN88
Hr/JbNK7rrQpKDBkcHLvYLLPXhNC6TLnLqbDZTl6mP3eJkTWDnca+uc+aTk9wkgd
ln5GNcRloz7T9+WjpIiBn0kCAT17Woy7J96T7QWhtaWL2Gqi+FT6rx0og6lvtcWW
W3CihHHDilAmFrVd1zJIn2I1HZx1oGmOE4Oqm9SLNhufW4t/xWU3uNMXcwsjU86Z
XH3bhiBtuCDY9ljQRO5CkCctVX+73A7Jdr3djvMob2x0JnPgHGRNGHnhJRfPO/+4
VJxw02PzzbOVj6HC+DQDNNr8TUivOZ+GXSidNCnF4z8dsHgKQ92lufezO14Ypqkp
bkAqnZvBPPpFYRKViKmqdCeYe94AOu6zb16uGcBNhobwzUVuBDpbRtCMFz9X5p3l
H608XliDXf/zp44oiVDzLrkAoRHqHQExf3V3t1/Yta8o0ZcnFSPuqFLw68c/pWLW
LFKLVl3i4v7wURjDohMxYh5Z3lkT+IMW8R4uF7MhY72EXWUaz00=
=d/lw
-END PGP SIGNATURE-

Re: Concerns to software freedom when packaging deep-learning based appications.

[Russell Stuart]

On Thu, 2018-07-12 at 18:15 +0100, Ian Jackson wrote:
> Compare neural networks: a user who uses a pre-trained neural network
> is subordinated to the people who prepared its training data and set
> up the training runs.

In Alpha-Zero's case (it is Alpha-Zero the original post was about)
there is no training data.  It learns by being run against itself. 
Intel purchased Mobileye (the system Tesla used to use, and maybe still
does) with largely the same intent.  The training data in that case is
labelled videos resembling dash cam footage.  Training the neural
network requires huge amounts of it, all of which was produced by
Mobileye by having human watch the video and label it. This was
expensive and eventually unsustainable.  Intel said they were going to
attempt to train the network with videos produced by game engines.  I
haven't seen much since the Intel purchased Mobileye however if they
succeed we are in the same situation - there is no training data.  In
both cases is is just computers teaching themselves.

The upshot is I don't think focusing on training data or the initial
weights is a good way to reason about what is happening here.   If Deep
Mind released the source code for Alpha-Zero anyone could in principle
reproduce their results if you define their result as I'm pretty sure
they do: produce an AI capable of beating any other AI on the planet at
a particular game.  The key words are "in principle" of course, because
the other two ingredients they used was 250 MW hour of power (a wild
guess on my part) and enough computers to be able to expend that in 3
days.

A better way to think about this is the AI they created is just another
chess (or Go or whatever) playing game, no different in principle to
chess games already in Debian.  However, it's move pruning/scoring
engine was created by a non human intelligence.  The programming
language that intelligence uses (the weights on a bunch of
interconnected polynomials) and the way it reasons (which is boils down
finding the minima of a high dimensional curve using newtons method to
slide down the slope) is not something human minds are built to cope
with.  But even though we can't understand them these weights are the
source, as if you give them to a similar AI it can change the program. 
In principle the DSFG is fulfilled if we don't discriminate again non-
human intelligences.

Apart from the "non-human" intelligence bit none of this is different
to what we _already_ accept into Debian.  It's very unlikely I could
have sensible contributions to the game engines of the best chess,
backgammon or Go programs Debian has now.  I have no doubt I could
understand the source, but it would take me weeks / months if not years
to understand the reasoning that went into their move scoring engines. 
The move scoring engine happens to be the exact thing Alpha-Zero's AI
(another thing I can't modify) replaces.   In the case of chess at
least they will have a database of end games they rely on, a database
generated by brute force simulations generated using quantities of CPU
cycles I simply could not afford to do.

Nonetheless, cost is an issue.  To quantify it I presume they will be
able to rent the hardware required from a cloud provider - possibly we
could do that even now.  But the raw cost of that 250 MW hour of power
is $30K, and I could easily imagine it doubling many times as it goes
through the supply chain so as another wild guess you are probably
looking at $1M to modify the program.  $1M is certainly not "free" in
any sense of the word, but then the reality no other Debian development
is free either.  All development requires computers and power which
someone has to pay for.  The difference is now is merely one of a few
added noughts, and those noughts exclude almost all of us from working
on the source.  But I'd be surprised if there isn't a Debian users out
there who *do* have the means to fiddle with these programs if they had
the weights and the source used to create them.  Which means anyone
could work on them if they had the means - but I don't have the means. 
*shrug*

Which is how I reach the opposite conclusion to Ian.  If Deep Mind
released Aplha-Zero source code under a suitable licence, plus some
example neural networks they generated with it (that happen to be bit
everyone uses) Debian rejecting the example networks as they "aren't
DFSG" free would be a mistake.  I view one of our roles as advancing
free software, all free software.  Rejecting some software because we
humans don't understand it doesn't match that goal.

signature.asc
Description: This is a digitally signed message part

Re: concerns about Salsa

[Russell Stuart]

On Sat, 2018-06-09 at 13:52 +0100, Ian Jackson wrote:
> As a service owner who has chosen to run the service out of git
> for other reasons, I don't really care.  But someone who wants to run
> the service from packages might have a different view.

In my very limited experience with containers they don't need
the host privileges that come with root.  The only reason containers
want root is to continue doing privilege separation (eg, prevent the
web from installing packages) in the way they've always done it.  For
example a fakeroot that persisted across reboots and somehow worked
with ldd / ld.so would be fine.  

It turns out if this is all you need its already available.  Some
container systems can already map root inside of the container to a
less privileged user outside of the container.  Docker for example [0].

And it is generally all you need. A container seems to reduce to:

- Program(s) that run in their own little ephemeral POSIX universe
  (ephemeral in the sense when it is stopped all internal state is
  lost, as if it was stored in RAM and the power was cycled) that
  has no connections with the outside world whatsoever, except:

- They listen to TCP/UCP ports inside the container.  But these are
  completely isolated from the outside world until the sysadmin
  connects an outside IP Address / port to them, and

- Stores data that should be persisted or perhaps just visible (eg
  logs) in a few well known directories, onto which the sysadmin can
  bind mount appropriate storage (the convention seems to be /data),
  and

- Has unfettered access to the network as a client. 

Root is either not required for these things or easily avoided.  For
example even though the external world connects to Salsa on port 80 and
it would require root privileges to listen on port 80, Salsa can listen
on port  inside the container and if the sysadmin wants it to serve
port 80, he maps some_ip_addr:80 to the container .

There are inefficiencies built into this system.  For example you may
end up with 100 containers all polling Debian for security updates and
installing them into ephemeral little worlds.  But these inefficiencies
don't seem like good reason to avoid using containers.

[0] 
https://docs.docker.com/engine/security/userns-remap/#user-namespace-known-limitations

signature.asc
Description: This is a digitally signed message part

Re: concerns about Salsa

[Russell Stuart]

On Fri, 2018-06-08 at 10:11 +0800, Paul Wise wrote:
> In my experience the Wordpress upstream auto-upgrade system is
> typically faster than the Debian's handling of Wordpress.

I didn't realise Wordpress had an auto-upgrade system.  That put's in
the same league as the Browsers like Chrome and Firefox.  I'm
impressed.

However, it's not the same service that Debian offers.  Wordpress has
an auto upgrade system to the new version.  Debian has auto application
of security patches to an existing system.  To see the difference, try
googling "Wordpress upgrade breaks".  Or look at the howls of anguish
on this list directed up the upcoming Firefox ESR update for stable. 
Both are examples of what happens when you update to the latest version
rather than just applying security patches.

The ultimate measure is the number of systems a person can maintain
using one system over the other.  For the Debian way of doing things
there really isn't a limit, or more accurately other limits (like
hardware failures, and dealing with network and power outages) will hit
you first.  In Wordpress's case there is a background rate of plugin
and theme breakage which will eventually overwhelm you.

The difference between the two is pretty obvious to the person paying
the bills.  I suspect that is the real reason Debian, a project that
has no income to speak of, somehow manages to have all the
infrastructure it does - 60TB servers for snapshots, a mirror network
and CDN, LWN subscriptions, free venues for its conferences and I
suspect lots other things.  I don't know of another open source project
that gets even remotely close to this level of support.  It would be
downright peculiar, if it weren't for the fact that the value of the
service Debian provides can be judged by RedHat's turnover, which is
about $3 Billion/year.  For the firms throwing the occasional piece of
chump change Debian's way it must look like the bargain of the century.

> I also get the impression that the number of CVEs (let alone all
> security issues) is scaling faster than the amount of folks in Debian
> who are handling them.

Is there some public proxy measure for this?  For example, the number
of outstanding CVE's, or average days it takes for a CVE to get fixed?

signature.asc
Description: This is a digitally signed message part

Re: concerns about Salsa

[Russell Stuart]

On Thu, 2018-06-07 at 18:14 +0200, Tollef Fog Heen wrote:
> Packages does not imply automation (lots of people maintain machines
> by logging into each one and running apt by hand and $EDITOR on their
> configuration files; I suspect this applies to the majority of
> desktops and laptops by people on this list), and git repositories do
> not imply not-automation.  Those are simply transport mechanisms for
> bits and the level of automation you use is not decided by git-vs-
> packages.

No, distros are not "just transport mechanisms".  In particular they
allow security patch upgrades to be automated by doing several things. 
On is automatically scanning for them and installing them which some
rare packages do provide (eg, browsers) and the second is supplying
back ported security patches which gives a good enough guarantee it
will be backward compatible that I let them through without testing.

I'll drive the point home with yesterdays (literally yesterdays)
headline: "Three months later, a mass exploit of powerful Web servers
continues".  The headline is referring to the 1000's of unpatched
Drupal servers out there, unpatched because patching required upgrading
to the latest version which is too hard.  Wordpress sites using the
Debian package with unattended upgrades installed would likely have
been patched before news of the exploit made the headlines.

In a nod to Salsa's team, they have taken the road you suggest and
automated everything they can with Ansible.  And yes, it's true the
burden of supplying these security back patches may fall on them, so
packaging it would not save them time.  But that's how it works for
DD's - we don't do this for our benefit, it's the rest of the world
that benefits.

> For debian.org hosts, the choice is primarily a matter of privilege
> separation: Service owners generally don't have root on the hosts,
> and so if they are to be able to update the service configuration,
> the service must run as a user they have access to or we need to
> build control planes with access controls which allow service owners
> to control their service.  DSA has root on the hosts and maintain
> those but  we don't run all our services, so we'd rather not be on
> the critical path for updating various services (which we'd need to
> be if those came from packages).

I accept that's doesn't leave the Salsa team with much choice, but it
still leaves me scratching my head.  Containers / VPS's / VM have been
a thing for years now.  They solve this separation problem in a way
that reduces the workload for everyone.

signature.asc
Description: This is a digitally signed message part

Re: concerns about Salsa

[Russell Stuart]

On Tue, 2018-06-05 at 15:44 +0100, Ian Jackson wrote:
> Packages are great for software which you can just install and use
> without much fuss.  That is often true for mature software.  But for
> services which are less mature, and more complex, and which have more
> tentacles, the admin is likely to need to change things.  This makes
> using packages awkward.

I think it's better to express the trade off in terms of consequences.

- Using software packaged by a distro requires very little effort,
  which makes packaged software the ultimate sysadmin force
  multiplier.  I know sysadmin's who exploit it to the extent they
  maintain literally 1000's of working boxes.

- Taking a package straight from the developer gives you flexibility
  using software packaged simply can't provide or worse you can't use
  it at all because it's not packaged.  The downside is you become a
  nurse maid for the box it's installed on.  Nurse maid's are literally
  orders of magnitude less productive than one sysadmin maintaining an
  automated assembly line, so the end product had better be orders of
  magnitude more useful than the packaged version.

To better understand the understand the consequences, compare Wordpress
and Drupal.  Both get their share of security issues.  However only
Wordpress is packaged for Debian, so a developer who uses Wordpress on
a Debian box with unattended-upgrades installed some does not have to
spend much time worrying about patching security issues.  Reading
Drupal developers comments on the net after the recent Drupal exploits
gets you a common theme: "I've put together lots of customer sites and
now they all need upgrading from a variety of versions, but no one will
pay to do it and there is no way I have the time to do it myself."

That's the consequence of choosing the wrong model for the task at
hand.  I expect they would argue they had a hard requirement for some
Drupal feature, so the consequence of not using Drupal was the web site
didn't happen at all.   That's hard to swallow for a web site, but it's
not so hard for Salsa given the state of its dependencies in Debian.

signature.asc
Description: This is a digitally signed message part

Accepted nagios4 4.3.4-2 (source amd64 all) into unstable, unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon,  9 Apr 2018 17:20:50 +1000
Source: nagios4
Binary: nagios4-common nagios4-cgi nagios4 nagios4-core nagios4-dbg
Architecture: source amd64 all
Version: 4.3.4-2
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart 
Changed-By: Russell Stuart 
Description:
 nagios4- host/service/network monitoring and management system
 nagios4-cgi - cgi files for nagios4
 nagios4-common - support files for nagios4
 nagios4-core - host/service/network monitoring and management system core files
 nagios4-dbg - debugging symbols and debug stuff for nagios4
Closes: 894696
Changes:
 nagios4 (4.3.4-2) unstable; urgency=low
 .
   * Remove lookup of nagios_check_command from nagios4.init.  It
 doesn't exist in nagios4.
 .
   * ITP (closes: #894696)
Checksums-Sha1:
 f92f05307cf74a6f3fca053d1c68e593b14b6ae6 2029 nagios4_4.3.4-2.dsc
 c1530e7ac49a8c39be7bfd5d23f7a8c7955ffdac 11086829 nagios4_4.3.4.orig.tar.gz
 47a11faa51d436aae061e76dc10e165e73c06250 450276 nagios4_4.3.4-2.debian.tar.xz
 692fc6148cae3ee30765c66c31f29a056a9f464e 1271608 nagios4-cgi_4.3.4-2_amd64.deb
 483b76d8a410b0a5127d22e32001d78e3ed5847b 65090 nagios4-common_4.3.4-2_all.deb
 1ff63d909bb7e3a1465635eeaf18cdbddef29a57 246322 nagios4-core_4.3.4-2_amd64.deb
 b1057a8700b1d4ab61f236e8ef5f7ac7d00736ce 6420462 nagios4-dbg_4.3.4-2_amd64.deb
 24bbcde3bfc713dcab9e31cf0b0da2d01ce1a0a5 8474 nagios4_4.3.4-2_amd64.buildinfo
 dfd164cab806a713514782f72e7ed92146895d80 12684 nagios4_4.3.4-2_amd64.deb
Checksums-Sha256:
 d77766e5c221747e6a3bcb69cb82f6e9a745afc9b1114c16ffc601172e1077eb 2029 
nagios4_4.3.4-2.dsc
 f2b54defb8ca648fa93fe1c81501cbd12c34d8eace96c6104678b27cd5dd203c 11086829 
nagios4_4.3.4.orig.tar.gz
 29f86d6caa470381bbad93f6e0c261b04ce8f428d2f69d0b6479886eabc30deb 450276 
nagios4_4.3.4-2.debian.tar.xz
 b81e6138cf8f983fac1697a048b2d89a8771e4ecd93b42c488a5f8d9178acf10 1271608 
nagios4-cgi_4.3.4-2_amd64.deb
 236e9b2d1953580a8e98db0b8c91276cec718edc221e83bb6dd1ad173858a485 65090 
nagios4-common_4.3.4-2_all.deb
 8330d0bddd5e3a7d6f9966f553d365e1ffd954f0b3c985b2c8ebec4a738dfe89 246322 
nagios4-core_4.3.4-2_amd64.deb
 e0e3e484bb0713c6eef21cc5f9f2b10e8901a7374292594f91a7e496967e6aa2 6420462 
nagios4-dbg_4.3.4-2_amd64.deb
 7390379ce25fb057c76279533f2d7707d8f7bebd5175bb8dc461078c1f9d7141 8474 
nagios4_4.3.4-2_amd64.buildinfo
 5dbf6c287fb9b2cdd00742e3ba03c69460684c587a41f0801e3f23acab4995cc 12684 
nagios4_4.3.4-2_amd64.deb
Files:
 43a582fd44949dec0ae02bcb38e1b962 2029 net optional nagios4_4.3.4-2.dsc
 b965d41af790967e284c3f02f8a9948b 11086829 net optional 
nagios4_4.3.4.orig.tar.gz
 d8d6294be1a53623da005f9952a88613 450276 net optional 
nagios4_4.3.4-2.debian.tar.xz
 c3e39500b9b9ac27acfe6f9541f6d93a 1271608 net optional 
nagios4-cgi_4.3.4-2_amd64.deb
 9447e89605a28e389bb32cbd651abfcf 65090 net optional 
nagios4-common_4.3.4-2_all.deb
 8a13dbd0dd0275852f615931b29e93aa 246322 net optional 
nagios4-core_4.3.4-2_amd64.deb
 a1da4cdfa90ea8dbec6adacf41f69401 6420462 debug extra 
nagios4-dbg_4.3.4-2_amd64.deb
 58fde3db359669ac73c8fba8a9a50243 8474 net optional 
nagios4_4.3.4-2_amd64.buildinfo
 5a39f7cc840ffcd8043b5f81fde44eee 12684 net optional nagios4_4.3.4-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlrLFsIACgkQrNSfiF5U
Um5WeQ//Y2/aBdPvU1qLiFz3/pG9GNtc00Uvui1ymlRZNG+rYyCgd5xUWptrljcr
4bJn7e9sxV0JVh5e3t7wDXppq/Kh+SkSQHW+mc47CRHs1flQfnOSMipJ7LgarhiP
4TwlxnC8RFGX0xFFOpEERcNvR61nSq94qgTJ/EyPyHg6I4NaQU5YL0Ye3caA8QVz
/IVk3scWcEv4CersclRpnsND2JweLw9Y1K8HUAH/UdqC0FPYE42iPlcTSf+geZnH
eEYk8iQewPdQdu1eP8oqKJHDGcEBQQ5o3AOadphxNmK67j3OxCtVpDsgwWkBoclC
biOUphkT61z7pX81KwNHsukB5qg/iYcgLKfNFjVKP98gy9MLXKJ1R2l5ulBKJrcT
2AP6DrG+t+JetSlpc3wMqb808rjtpuZhlEiEU2TBS3fCX/vmJQgZtCN5GlR9seBw
r9zLcSBziCkdcs6xKI35YtQZcZw7/+sJrth6IsumfsTQEKOQHWk6J/i2/ia63WIZ
02DDWWT2MCoPbPLqMGn/If6325AdMLR41O5a6B7Edi5uLE/8NgJLIlYBLlLfL8YR
JQQ9nEt6o23EXTb0J1O1a0LxR81Z1RuE9XtJoCQO3cTAA19iWFwf2qwzy9eAh4dK
YLsYXaOaBC7FiVYh8/NGbwcrd9qsXQQts6T8iJApfZL/vrSKTzs=
=EtdH
-END PGP SIGNATURE-

Bug#894696: ITP: nagios4 -- A host/service/network monitoring and management system

[Russell Stuart]

Package: wnpp
Severity: wishlist
Owner: Russell Stuart <russell-deb...@stuart.id.au>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: nagios4
  Version : 4.3.4
  Upstream Author : Ethan Galstad <nag...@nagios.org>
* URL : http://www.nagios.org/
* License : GPLv2
  Programming Lang: C
  Description : A host/service/network monitoring and management system

Nagios is a monitoring and management system for hosts, services and
networks.  This is a metapackage installing both the monitoring daemon
and the web interface.

Nagios' features include:

 *  Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP,
PING, etc.)
 *  Plugin interface to allow for user-developed service checks
 *  Contact notifications when problems occur and get resolved (via email,
pager, or user-defined method)
 *  Ability to define event handlers to be run during service or host events
(for proactive problem resolution)
 *  Web output (current status, notifications, problem history, log file, etc.)

nagios4 is the upstream replacement for nagios3.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlrDUkIACgkQrNSfiF5U
Um433hAAmDgTLfxlkDBLiRlFUOgmiVBqHarbnttWfgdQZEFO2yCtttic4/egc4E2
GMRokcFWDfNPJGlwezFUs9hOeE+6n/hnO//4O9UBt7n1zkoAEls1TrWjT6l6x/Cf
EbpGrBONEBm30F247ZPe/er6s3Fa5wOs5ja9cyGWDxdYS2I5iF8mxd9Jvkf7S0q1
YKJOnMW3+siON7sseZBFId2UqMMWszMDoXiNJkmI+kb2CKRPyp1dr8cTzX1guqf+
6qQbzBU3TSrAGptCUOHAEAniwhPZtIz+rLl35OXdXKPUdkIdfACneALOBCoK8GEy
NkOqjyvOe3dfIPRtjE2NbTadKVYyu5TdCtpBiU8YNmbDx9gQxPBtXGq3MW6wJhNQ
vsxXd4k51cB490LUsqyEjgDFKma1E8RQYlUzaVEwTmyknv98rSkTBOFuz7bdRYBX
S/ee/V4W0voAFueaPfJdm8Rn+o/XFdIPRHs2AMfxFqowXTb136N7gqGvm0UPvesh
59R5+nDEqDhIeZ52mBgTXupcNGvkCBqUAa1wjvPZP7ma/FLhEy+IAVhRJz5AMiJa
rNR6rYakd3XgqZ3BYeVfuiUgv+5x338wDA6M/pap2k4s5gPSPdm7FL///GaL6qN7
sSxS4Wwex+IWDsDHcziSFC2DpUHKfydiV1NpvZK4sclcDUnU7CQ=
=AGWq
-END PGP SIGNATURE-

Re: What can Debian do to provide complex applications to its users?

[Russell Stuart]

On Tue, 2018-02-27 at 14:13 +0100, Didier 'OdyX' Raboud wrote:
> > - we could ship those applications not as .deb but as container
> >   and let them have their own lifecycle
> 
> tl;dr: a new package format is needed, with a new non-suite-specific 
> repository is needed to bring the Debian added-value to these
> ecosystems.

To me 'container' is the right solution.  The problem is Debian doesn't
support building light weight containers well.  In fact nobody does. 
Docker makes an attempt, but distributing static file system images
that have to get their security updates installed by replacing the
entire image is ick.

If I were do the entire thing over again, I would break Debian up into
a series of rings.  In the inner most ring is like the inner most ring of 
Linux.  It's filesystem(s) is readonly to all other rings.  In it sits the code 
for dpkg,  But dpkg wouldn't do much beyond pulling down packages and their 
security upgrades into a /debian directory, which would look rather like /pool 
on the mirrors now, but the .deb's and .dsc's would being directories rather 
than tar archives.

Other containers would run above this.  They create their /usr file
systems by linking into dpkg's /debian directory (which is readonly to
them).  Maintainer scripts would run when these are containers are
built.  This means dpkg is no longer running maintainer scripts, so
just like an Android application a malicious package is limited in the
harm it could cause and in particular uninstall would always work.
These containers would be notified when packages they are running have
security upgrades installed, so they can swap to the new versions at a
convenient time.  We still get to keep the "one copy of each library so
we only have to fix a vulnerability once" advantage Debian has now (and
other current solutions notably lack).

Anybody who has fiddled with containers will have no trouble filling in
the rest of the picture.  It gives us two things: much better security
and a faster way to build containers (because the unpacking step has
already been done).

I realise it sounds grandiose and far fetched, however it can be broken
down into small(ish) steps.  Step 1 would be having dpkg unpack
everything to the /debian directory (including the state it currently
stores under /var) rather than installing it in place, and just placing
links in /usr, /etc and so on.   (I'm am optimist in that I think you
could pull that off without too many things noticing.)  Step 2 would be
to isolate /debian, so the rest of the world sits in its own container
and run the maintainer scripts from within that container.  (I'm such a
optimist that even I think doing this wouldn't require many changes
beyond dpkg.)  The next steps would be moving each application into
it's own container.  They would be much harder, but I suspect once
you've done the refactoring to make dpkg maintained containers
possible, the thing would take on a life of it's own.

In this world, vdeb's are just packages that apt will only permit to be
installed in a container the user has somehow marked as insecure (means
no Debian QA, ie no security patches).  Anybody thinking "yeah, but not
that insecure" should probably read this bug report:

https://github.com/npm/npm/issues/19883

The idea Debian would by default prevent that from trashing my laptop
is real appealing.

signature.asc
Description: This is a digitally signed message part

Re: Debian Stretch new user report (vs Linux Mint)

[Russell Stuart]

On Mon, 2017-12-04 at 21:01 +, Ben Hutchings wrote:
> I end up needing non-free firmware on most bare metal systems, but
> nothing else from non-free.  I never remember how to include it at
> installation time.  And I don't want us to gloss over the fact that
> it is non-free and therefore not part of the official Debian system.

Yes, that is the core issue, isn't it?  In this corner case we are
being used as a pipe to carry a non-free blob from the manufacturer to
hardware.  That blob isn't part of Debian, any more than a bittorrent
stream is part of ComCast.  Yet both of us are being forced to carry
stuff we find obnoxious.

Luckily for Comcast they will work perfectly fine without the content
they would to charge more for.  All they have to do is convince the
politicians to let them do it.

We aren't so fortunate.  If we want to use Debian as a tool to educate
people on what free software is about, they have to be able to install
the thing.  That means we must swallow our pride and allow non-free
blobs for network drivers, GPU's, mass storage and what not onto our
install media.  So we fine ourselves in a catch 22 - if we want to
promote DFSG to the masses, we must break the DFSG for our very own
install media.  Worse, we must get permission from ourselves to do
this, and it seems we aren't as easily to manipulate as some
politicians.  Or maybe we are, because we already do distribute non
DFSG images.

Personally, I find the cognitive dissonance created hard reason about,
let alone swallow.  It seems like the DFSG contains it's own antidote. 
If true the DFSG needs to change to accommodate this corner case,
otherwise it will remain a festering auto immune disease we pick at for
eternity.

That doesn't seem like an impossible ask given the pipe analogy.  The
DFSG is ultimately about letting anyone start with Debian, and build
something new from it as easily as we can.  If we can
acknowledge Debian packages can serve as a mere communication channel
for blobs of data without compromising the "as easily as we can" bit,
then we have a way forward.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Thu, 2017-07-27 at 10:05 +, Sam Morris wrote:
> You'd have to use BindsTo=sys-subsystem-net-devices-blah.device. But 
> BindsTo= and device units are a bit fiddly, see  systemd/systemd/issues/4413>.

I had a systemd enthusiast sitting beside me who recommended that.  I
was suspicious after reading the description of BindsTo
in systemd.unit(5).  It makes absolutely no mention of that behaviour. 
I thought I was vindicated when it failed.

Now you are telling it was merely buggy code and buddy doco.  That
means latent may have been right.  It's rare, but I guess it had to
happen sometime.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Sat, 2017-07-15 at 07:46 +0200, Tollef Fog Heen wrote:
> Doesn't something like:
> 
> [Unit]
> Description=My hook for foo.link
> After=foo.link
> BindsTo=foo.link
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/local/sbin/whatever
> RemainAfterExit=yes
> 
> [Install]
> WantedBy=multi-user.target
> 
> work to hook into when a link unit is activated?
> 
> (Or just a Wants and Before in the foo.link unit)

When I discovered .link and .network files the first thing I looked up
in the doco was whether that sort of thing was possible.  I decided it
wasn't and wrote it off as useless for me.

Now you've made me check for real.  After setting up the unit files you
suggested I get this message in journalctl:

  Failed to add dependency on foo.link, ignoring: Invalid argument

So now I'm fairly convinced the above isn't a thing.  systemd unit
files and udev unit files live in two different worlds - they can't
refer to each other.

That aside, it wouldn't work for my most advance use case anyway.  My
issue is I have boxes literally 1000's of km's away.  Occasionally it
all goes wrong, the only way to fix it is ssh in but "all" includes the
internet connection.

My fix was to detect when a mobile phone was plugged in via USB, then
create a vpn connection home. This is all doable with a few lines in
/etc/network/interfaces - the hard bit is detecting when some random
USB device is a mobile phone.  Standard udev rules can't do it, and so
systemd.link being less powerful doesn't have a hope.  This isn't a
reflection on either of them really - it's a very specialised use case.
  However, I do expect them to provide an escape route.  Udev does - it
can run a program to decide.  systemd.link can't.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Fri, 2017-07-14 at 18:31 -0700, Russ Allbery wrote:
> I didn't think anyone was claiming they would, so I'm not sure why
> you felt like it was necessary to say this.

It's the same reason you feel like it was necessary to say this, I
guess:

On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote:
> I just also don't particularly care; I've stopped using ifupdown and
> am using *.link units for network configuration

How is you stopping using ifupdown relevant to interface renaming?  It
isn't.  Nonetheless I find it interesting to learn how others solve the
same problems I face, and appreciated you taking the time to make the
comment.  But your approach doesn't work for me and I thought others
might be interested to know why that is so.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Fri, 2017-07-14 at 09:11 -0700, Russ Allbery wrote:
> Right, I'm completely happy with the current behavior.  I have no
> objections to the change.  I just also don't particularly care; I've
> stopped using ifupdown and am using *.link units for network
> configuration, which makes all of this trivial and uninteresting and
> means I don't care in the slightest what names are assigned to
> interfaces.

Which means that while true, this was largely irrelevant:

On Thu, 2017-07-13 at 09:07 -0700, Russ Allbery wrote:
> Er, I saw this all the time without udev persistent naming.  Every
> time we rebooted one of our servers, the four onboard NICs (of which
> we were only using one -- long story, but basically that's just what
> the systems came with out of the box and my employer at the time
> wasn't a big enough customer to customize the hardware) would get
> randomly different ethN device names assigned to them.  That's *why*
> udev persistent naming was so important when we were using ifupdown
> to manage static network configuration on servers.

As I saw it the discussion pertinent to two classes of people:

(a) Those who typed in the device names regularly.  As far as I can
tell those people either don't see kernels interface names changing
or don't care about it.  I gather from the responses here there 
quite a few people fit into this category.

I am sort of one.  I often use my laptop to configure some
recalcitrant device.  I like most don't see the kernel assigned
names change (because as Greg Kroah-Hartmanboth said, it's very
rare), and I wouldn't care if they did change because the are 
managed by Network Manager.  But when I'm doing the "bash (pun
intended) some device into submission" thing I use a USB dongle
which I have to manually configure and I detest having to enter
the new scheme's 16 character interface name multiple times.

(b) Those who enter the debian device names manually into config
files, and have machines that network device names even though
no one armed with a screw driver has been near the thing.
These people would very much care.  I was asking whether they
exist.  So far I've seen person say they are one.

To put it another way: there are a lot of opinions being expressed
here, but I suspect most aren't coming from people with skin in the
game.

As for *.link files, syntactically they like all systemd stuff are a
huge improvement on what came before them.  But the old ugly udev rules
have one thing over them - they provide hooks for scripts to cover
cases they haven't thought of.  Scripts seem to be an anathema to the
author's of systemd.  While that remains true they will never be able
to replace udev rules in all cases.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Fri, 2017-07-14 at 11:20 -0300, Henrique de Moraes Holschuh wrote:
> MOST PCI/PCIe NICs indeed use "ethX", etc.  But the naming scheme
> really is device driver-specific, and the "default" name used by a
> driver is considered part of the kernel stable ABI, and cannot be
> changed on the kernel side unless it is done opt-in at kernel config
> time (kconfig) or at boot time (kernel command line, device tree,
> etc).

Which is a PITA.  Even though udev does it's best to work around it,
the advice "don't clash with the kernel's naming scheme" is excellent
advice.  It's just a shame the kernel doesn't have a well defined
naming scheme, so it's impossible to follow in the general case.

The funny thing is the despite all the heat generated by this
persistent network interface discussion, it's not a huge problem
because the tools exists to work around it.  You just have to know
where to look.

What I do get regularly bitten by is other devices changing their
names, in particular tty's coming back as different names when someone
reconnects a USB cable.  If there is a general, scriptable way around
that problem that means I don't have to say "reboot the box" I haven't
found it.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Thu, 2017-07-13 at 09:07 -0700, Russ Allbery wrote:
> Er, I saw this all the time without udev persistent naming.  Every
> time we rebooted one of our servers, the four onboard NICs (of which
> we were only using one -- long story, but basically that's just what
> the systems came with out of the box and my employer at the time
> wasn't a big enough customer to customize the hardware) would get
> randomly different ethN device names assigned to them.  That's *why*
> udev persistent naming was so important when we were using ifupdown
> to manage static network configuration on servers.

Fair enough.  So now I have my example.

Possibly a compromise would be not to assign persistent names if you
have to use the mac address in the name.  I think it's only 73-usb-net-
by-mac.rules that does it this way.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Thu, 2017-07-13 at 11:21 +, Clinton Roy wrote:
> Unfortunately, others have (well, not the kernel, but PCI):
> 
> https://lists.freedesktop.org/archives/systemd-devel/2017-May/038924.
> html

If you plug new hardware devices in then of course things are going to
change.  The claim really is "I don't change the hardware, I don't
change the kernel version, but the hardware changes names".  It's hard
to swallow.  I've never seen it.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Thu, 2017-07-13 at 05:20 -0400, Tom H wrote:
> Stateless "/etc".
> 
> Systems with multiple NICs where the order in which they're
> recognized by the kernel can vary.

I asked for a person.  I guess I really asking for a use case. 
"Stateless /etc" isn't either.

I've never seen the kernel vary the order it enumerates a PCI bus. 
This isn't an accident.   Quoting "According to: "PCI Express System
Architecture" R. Budruk, D. Anderson, T. Shanley, ADDISON-WESLEY
DEVELOPER´S PRESS, 2003. ISBN: 0-321-15630-7, page 743":

The specification states that the enumeration software must
perform a depth-first search, so before proceeding to discover
additional functions/ devices on bus 0, it must proceed to search
bus 1.

I can imagine times where stateless etc is important - like embedded
boxes VM's configured by etcd.  But invariably in those environments
all devices are attached to PCI or similar.  Even if they aren't those
types of environments are managed by highly skilled people striving for
mass produced repeatability.  Tailoring systems to cope with /etc in a
ROM is their day job.  They aren't going to use Debian as it is served
up by netinst.

Personally I don't particularly care one way or the other.  But I've
seen a lot of complaints here about how frustrating the new system is
to use in real life, but I don't recall seeing any about how it helped.
 Maybe I missed it.

signature.asc
Description: This is a digitally signed message part

Re: IMPORTANT: Do live Debian images have a future?

[Russell Stuart]

On Wed, 2017-07-12 at 21:00 +0530, shirish शिरीष wrote:
> On 12/07/2017, Fernando Toledo  wrote:
> > Our Use-case:
> > 
> > We develop a derivated distro from Debian called Huayra GNU/Linux,
> > this is for educational program of government in Argentina. This
> > big program ship around 5 millons of netbooks to highschool
> > students.
> 
> 
>
> In short, this alone use-case answers Steve's original question which
> was primarily are there any users who use or would use this tool or
> his time would be better spent somewhere else. I think just the above
> use-case and number of users answers the need for a tool like
> live-wrapper. As has been pointed out by me and others, it just needs
> more testing (documentation and love by devs.) to drive more usage
> forwards.

I do a similar thing, although not on quite that scale.

However I thought Steve's question was about maintaining particular
live images, not live-wrapper itself. I too would be very disappointed
to see live-wrapper go.

signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Wed, 2017-07-12 at 17:35 +0200, Marc Haber wrote:
> I'd rather have breakage in this case than having to look for the
> interface every fscking time I need to run tcpdump, or having to
> adapt to an entirely new name schema like lanc0 and lanw0 to not
> stomp in the kernel's name space when using my own naming scheme.
> 
> My finger memory will still type tcpdump -i eth0 before the brain can
> intervene ten years from now.

I still don't understand what use case the current scheme is aimed at.

It's not Network Manager users - they don't care about names.  I know
because I used Network Manager on my laptop.

It's not sysadmin's managing fleets of machines.  They need persistent
names, but you rapidly go insane if the lan NIC isn't named "lan0" or
something regardless of the machine your platform is running on.  So
you end up dropping your own customer files in /etc/udev/rules.d
anyway.  At least that's what I do.

It's not cli user who have plugged in a box and want to configure it
with the keyboard.  Anything attached to a PCI bus is usually
"persistent enough" because something hand crafted can also be hand
maintained if it does change.  As Marc says for devices whose names do
change en48e244f61c1b is not a sane solution. Even just having a
template file in /etc/udev/rules.d to jog the memory on how to assign a
persistent name is a better idea.

So who is the person who actually likes typing en48e244f61c1b?

signature.asc
Description: This is a digitally signed message part

Re: UMASK 002 or 022?

[Russell Stuart]

On Fri, 2017-06-30 at 21:22 +1000, Scott Leggett wrote:
> If windows is different, it looks to be the outlier because macOS
> behaves the same way as Debian[0]:
> 
>   > For example, the default umask of 022 results in permissions of 644
>   > on new files and 755 on new folders. Groups and other users can read
>   > the files and traverse the folders, but only the owner can make
>   > changes.
> 
> [0] https://support.apple.com/en-us/HT201684

Windows being an outlier is a recent thing.  Earlier versions behaved
like the rest of us.  Such behaviour originated in a time when computer
users were once Uni students themselves.  They knew what file
permissions were and how to change them, and were smart enough to not
be scared of sharing as the default philosophy.  Unfortunately for gwmf
m...@openmailbox.org most Debian developers come from that cohort.

gwmf...@openmailbox.org is right in saying today's computer users don't
have the "sharing is what makes us bigger than the sum of the parts"
philosophy.  Where he goes wrong is in assuming they share their
computers.  While there was a time many people shared a single CPU,
today many CPU's share a person.  Or less obliquely, everyone has their
own phone / tablet / laptop, which they don't share with anyone except
US border agents.  In this environment umask is a quaint hallmark of a
bygone time.

The one example he gave of students sharing a University computer is a
furphy.  It's true it still such sharing still happens.  But the person
in charge of the machine isn't some naive first year pleb.  It's a
battle hardened university sysadmin who, god bless his black heart, has
faced down 1000's of aspiring university student training in the art he
long ago mastered. He knows how to wield a umask with power and
precision.  He doesn't whinge about pam_umask not being the default, he
fixes it and while he's at it alters the shell scripts in
/etc/X11/Xsession.d/ gets exactly the umask they deserve.

TL;DR - this complaint is 20 years too late.

signature.asc
Description: This is a digitally signed message part

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Russell Stuart]

On Thu, 2017-04-06 at 09:22 +1000, Russell Stuart wrote:
> Anyway, this discussion prompted me to get off my bum and look at why
> unattended-upgrades wasn't working.  Turns out the default install
> has "label=Debian-Security", and all these laptops are running
> testing.  I guess the assumption that people running testing have the
> wherewithal to configure their machines properly isn't unreasonable.

And ... that wasn't the full story.  The full story is when you install
unattended-upgrades it defaults to "off", or more precisely this
debconf setting default to "false":

unattended-upgrades/enable_auto_updates

This sort of thing drives me insane.  Unattended-upgrades doesn't do
anything if you don't set this to true, and why would you install it if
you didn't want it to run?  I guess it must be because some packages
depend on it, and maybe they run it themselves rather than relying on
anacron.  If that's the reason the solution is to split into two
packages, maybe "unattended-upgrades" which does do what it says on the
box and "unattended-upgrades-common" witch other packages can depend on
safely.

signature.asc
Description: This is a digitally signed message part

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Russell Stuart]

On Wed, 2017-04-05 at 12:38 +0100, Ian Jackson wrote:
> Me too.  I guess it depends very much on whether one can afford to
> buy a good laptop which works well with Linux.

Not in this case.  My laptop concerned is an Dell XPS 9550.  It wasn't
cheap and in the 12 months of ownership I'd describe the hardware as
better than "good".  Dell's part of the design is not big part of the
total of course, Intel, Sony, Broadcom, Samsung to name a few all have
their fingers in the pie, as they do in every laptop.  But bits Dell
did contribute are extraordinarily well done, with the exception of the
keyboard layout.  It's definitely the best laptop I've ever owned.

My pain is largely self inflicted: I covet shiny bits.  Lots of
companies sell new laptops with bits a couple of years old that work
with Debian stable.  Knowing this, I bought the XPS anyway.

Although there are components in this laptop, almost of the pain come
from one: Intel's Skylake CPU.  (The touchpad also contributed but the
libinput maintainers were fantastic, going way above and beyond the
call of duty and contacting me directly when I complained on LWN.  It
now works wonderfully; worth the early adopter pain then some.) 
Getting Intel's CPU and in particular it's internal GPU working took
far longer and involved more pain than that I bargained for.  Just to
put this into perspective: they didn't work on Windows either.  Intel
CPU's are not something you can avoid by buying a more expensive
laptop.

All this new hardware has meant I have had to run Debian Testing. 
Combine shiny new hardware with the shiny new software needed to drive
it, and random little surprises become part of ones life.  Coming close
to dropping your new laptop because of a burning sensation as you
retrieve it from it's bag wasn't surprising or even unexpected - not to
me anyway.

Anyway, this discussion prompted me to get off my bum and look at why
unattended-upgrades wasn't working.  Turns out the default install has
"label=Debian-Security", and all these laptops are running testing.  I
guess the assumption that people running testing have the wherewithal
to configure their machines properly isn't unreasonable.


signature.asc
Description: This is a digitally signed message part

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Russell Stuart]

On Wed, 2017-04-05 at 11:18 +0800, Paul Wise wrote:
> Not AFAIK. I would guess that needrestart would need to be promoted
> to standard priority and needrestart-session would need to be added
> to tasksel's task-desktop package, or to each of the task-*-desktop
> packages; this adds wxWidgets to the default install though. The
> latter would allow different desktops to add different
> implementations, for example if someone wrote a GNOME Shell extension
> to highlight windows of applications that need restarting.

The original thread HN thread that trigged this was more about personal
machines, ie laptops and tablets.  That is were I'm coming from anyway.
 As it happens, Steve McIntyre was looking at the server side and
specifically excluded laptop's from his auto install security patch
deliberations, so nominally there isn't an overlap.

As far as I can tell, for laptop's rebooting is a non-issue mainly
because suspend is not reliable enough to use safely [0] - so they are
rebooted every day.  Ergo just fixing bug #744753 would be the cure if
it is indeed the problem - but it doesn't sound like it to me as this
isn't a suspend issue.

The itch I'm trying scratch is I've convinced some co-workers to ditch
Windows for Linux.  All our infrastructure and development is done
under Linux, so it makes sense.  For the most part it works very well,
apart from the 3 issues I raised earlier.  Fortunately they don't use
the tablet mode and they don't have HDPI displays, so they aren't
issues for them.  But the not installing security updates thing means I
have to remember do it for them.


[0] By "not safe" I mean suspend can destroy hardware.  Not directly of
course.  The first issue is modern laptops have so much DRAM it
can drain the battery overnight, which makes suspend pretty useless
if you are expecting it to reliably save your work.  The solution
is put the laptop into hibernate mode if it's been suspended too
long.  This works mostly - but it has one disastrous failure mode.
It must wake the laptop up to put it into hibernate mode but
sometimes it doesn't wake successfully. The result is the
motherboard is powered up, the laptop is in the bag with no 
ventilation and the thing cooks.




signature.asc
Description: This is a digitally signed message part

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Russell Stuart]

On Mon, 2017-04-03 at 15:35 +1000, Brian May wrote:
> On 2017-04-03 10:10, Russell Stuart wrote:
> > The first is better HDPI handling.  This will require Wayland ...
> >  
>  
> Did I miss something? I thought Ubuntu was doing their own thing and
> not using Wayland.
>  
> https://wiki.ubuntu.com/Mir/Spec

Yep.  But I was referring to Debian.

signature.asc
Description: This is a digitally signed message part

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Russell Stuart]

On Fri, 2017-03-31 at 21:48 +0100, Chris Lamb wrote:
> There's a very active conversation happening on Hacker News right
> now entitled «What do you want to see in Ubuntu 17.10?»:
> 
>   https://news.ycombinator.com/item?id=14002821
> 
> I haven't read every comment yet, but are there any feature requests
> that seem particularly relevant to us?
> 
> (As a meta-comment, I was quite struck by the number of requests that
> should "obviously" be requested upstream instead. I wouldn't want to
> label this as "wrong" but I think this might speak to the different
> perception we have towards the upstream → distro → user
> relationship.)

I was fascinated to see the two top ones were also my two top ones. 
But both are upstream issues.

The first is better HDPI handling.  This will require Wayland as X11
simply can't handle connecting to monitors with wildly different DPI
settings. But even just handling HDPI is problematic - fixing it with
my 300 dpi screen took multiple manual hacks including in Gimp's case
installing an icon pack not available in Debian.

The second was better gesture recognition.  I'd put onscreen keyboard
into that basket too.  This in particular effects 2in1 laptops - those
a standard OS (ie, Windows / Linux) but can be both touch only or touch
+ keyboard.  At the low end things appear to be in the process of
wiping out tablets, which is good for us.  But because the onscreen
keyboard doesn't work and gestures aren't supported uniformly well by
all apps these things aren't usable currently, and they have to be
usable out of the box with a standard install - just like Windows
manages to do.

Note these two cover the largest growth groups - the very low end, and
laptops with HPDI monitors.

The third one that got my attention is security updates that can be
trusted to work on a standard desktop install.  Where we take the
approach that creating our own security patches is just too hard, this
means stable must just follow upstream (like Firefox ESR),
automagically.  They don't do this reliably now for the default
install, even with unattended-grades, on a machine that's
intermittently on. This one is definitely in our court, and it's an
absolute must IMO, but is been already been discussed to death here.

signature.asc
Description: This is a digitally signed message part

Re: Feedback on 3.0 source format problems

[Russell Stuart]

On Mon, 2017-01-09 at 17:33 +, Ian Jackson wrote:
> All of this applying and unapplying of patches around build
> operations is complete madness if you ask me - but I don't see a
> better approach given the constraints.  dgit sometimes ends up doing
> this (and moans about it), which is even madder given that dgit has
> git to help it out.

To state the bleeding obvious, it arises because on day 1 Debian
decided to do the builds in the original source tree, then tries to
recover the original source at the end by running "debian/rules clean".
 When I moved from rpm's to deb over a decade ago, I was surprised by
this.  Rpm's create temp build directory, so the "debian/rules clean"
step can be handled reliably 100% of the time by the rpm build tool.
Debian insisting you write it creates extra work.  But when in Rome do
as the Romans do and all that.

Later when I started to work on other peoples packages it became
apparent that many of the Romans didn't bother with it.  So the
debian/rules binary; dpkg --install; test; debian/rules clean; fix;
rinse and repeat cycle doesn't work at all for maybe 1/3 of packages,
and another 1/3 occasionally fail when something goes wrong during the
patch / build process.

When it goes wrong your only option is "rm -r; dpkg-source -x; manually
reapply your changes" which is tedious, error prone, and for me least
conducive to losing a days work.  It is indeed utter madness that over
a decade later we still allow this work flow. 

signature.asc
Description: This is a digitally signed message part

Re: Converting to dgit

[Russell Stuart]

On Wed, 2017-01-04 at 14:47 +1000, Russell Stuart wrote:
> The central
issue here appears to be that none of the proposed ways
> of using git
within Debian help with that task.

On Wed, 2017-01-04 at 04:42 +, Colin Watson wrote:
> 
> git-dpm does too, and I agree it's nice.
> 
> It produces a patches-applied tree *and* the separated upstream
> patches in debian/patches/.  You never actually touch the latter by
> hand; they're purely an export format.

I stand corrected.  It seems to be precisely what is needed.

signature.asc
Description: This is a digitally signed message part

Re: Feedback on 3.0 source format problems

[Russell Stuart]

On Tue, 2017-01-03 at 18:37 -0800, Russ Allbery wrote:
> Even if we never used tarballs, and instead our unit of operation was
> the upstream Git repository plus Debian branches, I would maintain a
> rebased branch of Debian changes to upstream

This is not a novel requirement.  Most projects I've worked with insist
you rebase your patches.  This is not new.  Before git they insisted
your patches applied cleanly - which amounts to the same thing. 
Breaking up large patches into a series of smaller independent patches
each with a simple and documented purpose isn't an unusual requirement
either.

To me this is just the software engineering 101 rule "break just large
software projects into smaller, easily understood and documented
modules" applied to change control.  The reason is identical - it's so
someone coming along behind you can easily understand what you have
done and why.   For those of us at a certain age, that someone else
coming along behind might be ourselves a few months later.

Whether it's mandatory seems to depend on how big the team is.  A large
DD team packaging who submits patches upstream to large project will
find it unavoidable.  (The Debian kernel currently carries 400 patches,
totalling 50K lines.  Managing that as a single lump would be
impossible.)  On the other hand a one person team who doesn't
contribute upstream could reasonably say it's pointless.  I know most
Debian packages are a one horse affair, but I am still surprised by the
number of DD's here claiming this software 101 process is _always_
pointless.

Source format "3.0 (quilt)" is a straightforward way of storing a
series of small documented patches.  This is in contrast to quilt(1)
the program, which is a way maintaining those patches.  I'm not fond of
quilt(1) as I regularly manage to get myself into states I can only get
out of using "rm -r; dpkg-source -x ...; reapply work done so far".

The kernel uses git as a better quilt (both are spin-offs from  the
kernel).  Gits adds some new tricks.  It doesn't get into impossible to
recover from states (yeh!).   The history it keeps allows it compare
and merge change sets - something that has to be done manually with
quilt.  That history also provides some extra features like git bisect,
and the ability to trace copyright - but they aren't so important.

What is important is git as it is used by the kernel devs still
produces small, rebased, documented patches.  If it didn't I doubt the
kernel would be using it.  The central issue here appears to be that
none of the proposed ways of using git within Debian help with that
task.  Debian packages that do use git and have patches don't use git
to generate the patches.  Eg, the kernel team appears[0] to use
quilt(!) to maintain its patch series, even though they use git too. 
If you are using quilt anyway because you like small documented
patches, but you are a one horse team and so aren't concerned about
parallel work flows a reasonable question is: why use git at all?


[0] I'm not on the kernel team, so I can't be sure about them using
quilt.  I guess they do because their debian/bin/test-patches tool
does use quilt.


signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Fri, 2016-12-30 at 16:09 +0100, Bjørn Mork wrote:
> Fix it instead :)

I have submitted patches for kernel the network stack to improve QoS
for ADSL (ie where ATM cells are the link layer carrier).  I'm not
terribly forgiving of the long drawn out initiation rites the kernel
dev's seem to demand, so I eventually gave up.  (It didn't help that
the kernel networking dev's all seemed to use cable and so didn't
notice the issue.  As I was a heavy ADSL user it was a very pertinent
itch for me.)  My co-conspirator, Jesper Brouer, did persevere in the
area and is now a name some in kernel development might recognise. 
Years later he re-submitted the patch.  When it was rejected by the
same people in much the same way he responded "please lets not go
through this again", and it was accepted.

> FWIW, I find it much harder to document a new feature than
> implementing it. And I believe many others feel the same.  Any help
> improving the docs is greatly appreciated.

As it happens I did write documentation.  Not stuff most people consume
directly, but in a effort to use QoS I pored through the kernel source,
documented what it did and put the result up in a public place.  That
documentation is now referenced in a number of places.  For example
it's in the "SEE ALSO" of the tc-u32 man page, I think because it
copied large chunks of it.

> New networking features often have a narrow target and are added by a
> person knowing the specific area pretty well, but not necessarily 
> everything else...  Writing good docs in this context is difficult
> because your point of view is so different from the readers.

I acknowledge it's hard to write good documentation.  But I wasn't
talking about language skills.  I was talking about writing a single
word.  There wasn't one for tc for a long while.  Some modules of tc
are still only mentioned in examples - like the ifb device (which sadly
because it's a key part of the traffic control puzzle).

Some get an introductory para only:

  atm - a scheduler for ATM VC's. 
  gact - probabilistic filter action.
  gred - generalised random early detection scheduler.
  hhf - Heavy-Hitter Filter scheduler.
  multiq - driver for multi queue devices, disguised as a scheduler
  rsvp - Match Resource Reservation Protocol filter.
  qfq - better version of pfifo, maybe.

At least a casual user can find the above and look up the kernel source
if they are desperate enough (I did it after all).  But there are other
parts still haven't attracted a single word:

  blackhole - a scheduler that always drops packets.
  canid - a filter that looks at CAN bus ID's.
  mq - the default scheduler used for virtual devices.
  plug - scheduler allowing user space start / stopping of flows.
  teql - link bonder disguised as a scheduler.
  text - filter matching strings of text in a packet.

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

You learn something new every day.  I had read the kernel devs had
rewritten net-tools.  I presumed that was because the ioctl interface
had gone, so they were doing it out of the kindness of their hearts to
reduce the impact of the change over. Now I've looked at the source I
see that isn't so.

> But I see no point in the subject of this discussion. 

It always puzzles me when I see someone make a point like this - right
after adding another 100 words to the very discussion they say is
pointless!

> Leave net-tools as they are for anyone used to them.

There are 2(!) versions of ifconfig available - one in inettools and
one in net-tools.  I don't recall anybody suggesting we remove either.

The issue is the new maintainer of net-tools is changing it's output. 
This could reasonably be expected to break scripts scraping it.  Since
its been superseded the suggestion is packages using it switch to
iproute2 rather than simply adapting to the change.  Re-wording that in
Debian terms: that means no packages should depend on it.

Granted this simple suggestion has prompted several people to charge
off on vaguely related hobby horses, and I'm a prime if not the major
offender.  Undoubtedly this has distracted from the original
discussion.  That is unfortunate as the original idea seemed sound to
me - and not at all pointless.

signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Fri, 2016-12-30 at 10:42 +0100, Vincent Bernat wrote:
> > I bet the bash authors use that argument when they add another
> > feature.  In reality all code has a cost.
> 
> The only additional cost is the cost to check if the routing entry is
> a blackhole (while the check for anything else already exists). Even
> FreeBSD supports this feature since a long time.

I wasn't talking about the merits of doing it in any particular place. 
It was about the same thing being done in multitudes of places - in a
different way in each case, with a different API, with different code
pulling apart the packet.

> The flexibility is also what people like with Linux.

True.

> hence the need to be able to drop earlier (even adding filters
> directly in the NIC).

Of course - bypassing the entire stack is always going to be faster.

The reason I have the irritates is because I don't bypass it.  I use
the multiple routing tables, the traffic control engine, iptables,
tunnels, bridges, tun/tap, ipsec, veth, vlan's.  I tried to collect
information on flows - but that slowed throughput to the point people
actually noticed it on a 10M bit/sec link.  Thus my complaining about
having to use a different syntax every time I recognise a packet, how I
have to set MARK's to communicate between different levels of the
stack.

And also thus my long and loud whining about the lack of documentation.

It turns out such whining isn't entirely pointless.  While looking  at
the kernel code again I came across the net/openvswitch.  Implemented
as yet another bolt on, of course.  But if it does what it says on the
box it may be the answer to my complaints.  This quote from the web
site is heartening: "The goal with Open vSwitch is to keep the in-
kernel code as small as possible (as is necessary for performance)". 
Indeed.

signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Fri, 2016-12-30 at 07:51 +0100, Vincent Bernat wrote:
> The same work is not repeated over and over again. The kernel keeps
> the needed information in a structure to avoid parsing the packet
> several times.

Yes, it does indeed keep the offset of the headers for the various
protocol layers (link, ip, transport) in the skbuff.  And yes, it uses
them where it can - for example when routing it knows it will be
looking at the destination ip address, and when routing it can use
those fields.  In netfilter (iptables) has a separate block of code for
each test, so it can use them so the test knows .  Unfortunately this
comes at a large cost - sequential execution.  In the traffic control
engine the main filter, u32, doesn't have a clue what you are looking
at, so it can't.  nftables could conceivably do it - but internally is
structured like u32 so it doesn't.  eBpf could also conceivably do it -
but it has less of an idea of what it is looking at than u32 so it
doesn't either.

Linux provides what 2(?) API's for manipulating files - read/write and
memory mapped io.  Want to count the number of ways it provides to
dissect and act upon network packets?  These aren't the esoteric things
the file system hides under ioctl's either (which is arguably how it
the main API remains so clean) - all these ways of pulling apart and
manipulating packets are in the fast path.

> When you need to decide how to route the packet, you need to do a
> route lookup. If the route entry you find happens to be a blackhole
> route, you drop the packet. You didn't do any additional work.

I bet the bash authors use that argument when they add another feature.
 In reality all code has a cost.  Do you remember Van Jacobson's
suggestion for speeding up Linux's network stack?  (It's mentioned in
his Wikipedia page.)  I was lucky enough to be at linux.conf.au when he
first presented it.  He provided working code and some very impressive
benchmarks.  It went nowhere because of that cost thing - the code
doesn't have to be executed in order to slow down development.  I think
Linux's networking mob pretty much gave up after the ipchains to
iptables transition.  Now stuff doesn't get ripped out and replaced,
instead new ideas are bolted onto the side - creating a bigger ball of
wax that's even harder to move.  Which is how we got to having the
ability to drop packets added in so many different places.

> Those benchmarks show huge differences between Linux distributions
> for a kernel-related task. Like all phoronix benchmarks, it should
> not be trusted.

Maybe you trust Facebook's opinion instead (it's weird - that wasn't
easy to write):

   http://www.theinquirer.net/inquirer/news/2359272/f

signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Thu, 2016-12-29 at 11:38 -0800, Russ Allbery wrote:
> It certainly doesn't provide a man page that doesn't start with a BNF
> syntax description.  The iproute2 documentation is awful.
> 
> Also, this is not at all easy to parse:
>
> # ip -o address
> 1: loinet 127.0.0.1/8 scope host lo\ valid_lft foreverpreferred_lft 
> forever

All true.  In particular the documentation produced by kernel's
networking group is a pet hobby horse of mine.  To paraphrase an old
joke - you can't complain about most of it, because it doesn't exist.
[0]

When it comes to parsing they look equally bad once you have used them
for a while.  Worse from my point of view they are both unnecessarily
difficult to scrape in a script.  The "ip" does have one outstanding
attribute though - it is complete.  ifconfig doesn't list multiple ipv4
address (but does list multiple ipv6 addresses - what's up with that?).
 route can't handle multiple routing tables let alone routing rules. 
The equivalent of "ip tunnel" doesn't exist - and it goes on and on. 
net-tools might still be useful for configuring your laptop - but it's
now useless for any serious networking work.

To me this thread looks like a bunch of old men grumbling that the
young'ins have taken over what they created and turned the tools they
were comfortable with into something unrecognisable.  It's true - they
did do that, and it's true it was unnecessary.  They could have just
extended net-tools.  But this is how the young'ins have behaved for
time immemorial - when they take over the reins from the previous
generation and make it their own.  Look on the bright side.  They've
given the kernel's networking stack a large array of new tools that
weren't envisaged when net-tools was conceived - like QoS.


[0] Now I've started, the Linux kernel's networking stack is a mess.
From the outside it looks like a mob of warning tribes, each 
developing with their own way of doing the same thing.  To people 
not familiar with it this will sound like a hyperbolic claim.  So 
lets consider one simple task: dropping a packet.

- Did you know the routing table can drop a packet?
  "ip route add w.x.y.z/c blackhole" and
  "ip route add w.x.y.z/c prohibit" and
  "ip route add w.x.y.z/c unreachable" all do that.

- The traffic control engine can "police" packets.  You can "shot"
  a packet during policing.  (Being Australian, I find this odd,
  but I'm sure US citizens will be comfortable with it).

- Traffic control engine schedulers can also drop packets, (as well
  as move them like a bridge, create duplicates and a lot of other
  things).

- Iptables can drop packets.  This how most people do it.

- The new nftables can drop packets. 
  
Not only can they drop packets, each has their own way of figuring
out what packets to drop.  Which means each must pull apart the
packet to see it it matches, so the same work is being repeated
over and over again.

This has real impacts.  One is this spaghetti you see at the API 
level is reflected underneath, making for one large, complex, hard 
to understand and consequently fragile lump of code.  Another is 
the the BSD networking stack is faster than Linux - sometimes near 
an order of magnitude faster(!)

http://www.phoronix.com/scan.php?page=article=netperf-bsd-linux


signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Wed, 2016-12-28 at 03:08 +, Wookey wrote:
> If we are supposed to change to something newer these days

We've been discussing doing that for 8 years now:

https://lists.debian.org/debian-devel/2009/03/msg00780.html

> a pointer to a 'conversion' document would be nice.

https://wiki.debian.org/NetToolsDeprecation

(There are links on that page).

It's not a changeover document, but as I said earlier my favourite
resource is: http://baturin.org/docs/iproute2/

> Like Andrew I don't like the tone of these 'get rid of this crap'
> messages.

The issue is ifconfig was the tool up until Linux 2.2, but then the
kernel developers favoured iproute2.  The kernel has moved on and they
maintained iproute2, but ifconfig has remained static.  It now doesn't
support the most mundane things like multiple IP addresses per
interface, let alone multi routing takes, routing rules and the various
tunnelling protocols, or virtual ethernet devices needed by containers
to name but a few.
 
I don't know whether "crap" is the right word, but it is certainly
baggage from a bygone era.  "Baggage" here means that if we are nice to
our users (ie, Debian sysadmins), we should not force them to know two
tools.  We only have one complete tool set available: iproute2.  This means at 
the very least ifconfg can not appear in any conffile, nor can it really appear 
in documented shell scripts like dhclient-script.

Unfortunately this pain does not end at ifconfig. iwconfig has suffered
the same fate.  If you want to use Linux wireless in anger, then that's
the tool you have to use.  It's doubly annoying because of the "Do NOT
screenscrape this tool, we don't consider its output stable" warning it
issues.  It's not like you have much of a choice any more.

signature.asc
Description: This is a digitally signed message part

Re: Can we kill net-tools, please?

[Russell Stuart]

On Tue, 2016-12-27 at 01:02 -0800, Josh Triplett wrote:
> The rest of net-tools aside (which have sensible replacements), what
> replaces netstat in the absence of net-tools?

/bin/ss, which is part of iproute2

It's probably wise to 'dpkg -L iproute2 | grep bin/'.  They are the
tools provided by the current kernel network maintainers for
manipulating the kernel's network stack.  You will find some surprising
things in there, like tipc.

If you are contemplating moving to iproute2 this web page is
invaluable:

  http://baturin.org/docs/iproute2/



signature.asc
Description: This is a digitally signed message part

Re: Crowd funding campaign to package browserify in debian

[Russell Stuart]

On Sun, 2016-12-25 at 19:17 +0100, Stéphane Blondon wrote:
> Perhaps I missed something, so I'm curious to learn more about it (a
> link or some keywords can be a good start).

The buzz work mix is:

- vue-loader
- webpack
- webpack plugin for .vue files (mix of HTML, CSS/sass/stylus, and JS).

and some browser plugin that automagically reflected any source code
changes on disk in the browser immediately, including tool messages (eg
, compile errors).


signature.asc
Description: This is a digitally signed message part

Re: Crowd funding campaign to package browserify in debian

[Russell Stuart]

On Fri, 2016-12-23 at 21:36 +, Jonas Smedegaard wrote:
> This list is about development of Debian.
> 
> Not about how to raise money to ease developing Debian.

The first condition is fulfilled - the email is about getting
development done within Debian.  In fact given ITP's I've seen floating
by, it's about something that is getting a lot of development done
within Debian.

Obviously it's the asking for money that rankles.  If he was asking for
some rare hardware to test on, or documentation, or even assistance you
would be fine with it.  Any normally I'd agree - money is such a
difficult topic.  I also would intensely dislike seeing repeated posts
on this list begging for money on a promise of getting some work done. 
But it should be obvious by now that isn't what's happening here. He
hasn't raised much of his target, but the work is getting done anyway. 
Clearly his main passion is to get the JS development tools into
Debian.  Money is just lubricant to make the task easier.  

JS development; the techniques they use, the appalling version control,
the tendency to mash together various bits of code with no respect to
licences, the propensity to download code they are about to run from
random sites is must be contrary to the bulk of our standing
policies.  Twisting this mess into something that can be used within
Debian is understandably difficult.  But also necessary, given it is
the most active area development on the planet right now. [0]

So add he is cracking a very tough nut that no one else has much much
of a dint in so far, and maybe we can be a little flexible?



[0] I was proudly shown some production "web code" yesterday.  Cutting 
edge stuff, apparently.  A single file contained HTML, css, and JS.
 
The first thing that hit me is JS didn't contain any semicolon's - 
something I found disquieting.  I was told "no, we don't use them 
any more".  But what about the problems with that pointed out by 
"Javascript - The Good Parts", I asked.  The reply was, "oh, no 
one does this stuff without running it through an aggressive 
linter, so its completely safe - mostly strictly type safe in 
fact".  (That was nice - evidently at least some of the scars
carried by the C using forbears had been noticed.)

But how could a linter process that, I asked - it was some  unholy 
mess of 3(? maybe more) intermixed languages.  It gently explained 
this was the source code form.  A large tool chain would digest 
it, turning it into something no sane human would look at.  It was 
broken into single language modules that were digestible by a 
browser, downloaded by some dynamic linker created by the tool 
chain that GET's the requisite parts as the running code links to 
it while executing.  It was complete with debugging symbols packed 
into separate files, so they were there if needed.  From the 1000' 
view it was not unlike the m4 / cpp / gcc / ld / ldd GNU tool 
chain - but created in some parallel universe.

Then I noticed some JS/Typescript/? syntax I hadn't seen before.  
Not wanting to let any more grey show through I decided to chase 
it down myself.  It took a while - it was some variant of the 
new JS spreader syntax - but it wasn't in ECMAScript 2015 and 
wasn't recognised by any shipping browser.  I knew this new 
generation of our profession didn't share my aversion to 
releasing production code developed in a language that hasn't been 
standardised yet - but it wasn't in ECMAScript 2017 either.  
Turned out it was a proposed addition to ECMAScript 2017 
implemented by a grand total of 2 transpilers.  In production 
code!  (The mere existence of those bloody transpilers makes the 
statement "written in Javascript" near inscrutable.)

    Many of bed rock of rules I built my career on are viewed as road
blocks to progress by this new generation, and treated accordingly.
It made me feel like I had been run over by the generation gap
bus.  They feel similarly I think - now they have containers they
configure with makefiles and rebuild nightly, they are 
understandably wondering where a monolithic solution like Debian 
fits in.  Pirate has evidently decided to work full time on
bringing these two worlds together.  Yes, he is using a rather
"novel" approach, but the entire situation is novel.  I say cut
him some slack.

signature.asc
Description: This is a digitally signed message part

Accepted fdb 1.6.1+dfsg1-1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue,  6 Dec 2016 16:56:00 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 1.6.1+dfsg1-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Changes:
 fdb (1.6.1+dfsg1-1) unstable; urgency=low
 .
   * New upstream version
Checksums-Sha1:
 c071b57f9574eee81807a6bb2e5416fe2d88845b 1978 fdb_1.6.1+dfsg1-1.dsc
 f64c19b3e30b4bd4ffb828c178a34fd7827e2047 616747 fdb_1.6.1+dfsg1.orig.tar.gz
 e15ced3108821f0937b181d7c343d0b05fd2a15c 4524 fdb_1.6.1+dfsg1-1.debian.tar.xz
 811305c7049b029dd6096dde851f5aa9f0880e5c 6500 fdb_1.6.1+dfsg1-1_amd64.buildinfo
 eae324055ab4ff949d58ad138a5b1556b598f4a7 190314 
python-fdb-doc_1.6.1+dfsg1-1_all.deb
 1e0adf1017c6c9153d3129887590ad11f1d283c7 104094 
python-fdb_1.6.1+dfsg1-1_all.deb
 1f0c515787ea95ec4b0a9c9c2aa4566d595b51b2 104018 
python3-fdb_1.6.1+dfsg1-1_all.deb
Checksums-Sha256:
 1d555d0def4c49afb9fb09285de8637c7d0b8a13e94ce0f06edba79b5b37d57e 1978 
fdb_1.6.1+dfsg1-1.dsc
 9d83e04a42e3f56181ba2fcfbb1dfc394cffee1ae16d7e84e886bb26ea10cfb2 616747 
fdb_1.6.1+dfsg1.orig.tar.gz
 f36ad04d82793b694c4ff67509382e62d49f8f91e8f4d495bcc2fbb05ccefecc 4524 
fdb_1.6.1+dfsg1-1.debian.tar.xz
 260c4a59a343e96c90af5b430228e870a26463b4ea3fbdf372fba2f4a0d7466a 6500 
fdb_1.6.1+dfsg1-1_amd64.buildinfo
 e55541f281f614a88ce5559f9dac846391437479ea28538aa049aa08de321fbf 190314 
python-fdb-doc_1.6.1+dfsg1-1_all.deb
 5285f7dee44253cb399559e3958767bfa0a2e072e438133cae158e4fafa2 104094 
python-fdb_1.6.1+dfsg1-1_all.deb
 d157ffa8b0a17e776c6879a197cda356fae2310c4f714ecdfef66ed9b8e0a8b1 104018 
python3-fdb_1.6.1+dfsg1-1_all.deb
Files:
 321ea934545fc3429aa160b71ec43bc7 1978 python optional fdb_1.6.1+dfsg1-1.dsc
 c4eeb82462764adc00fdfbed890c5d81 616747 python optional 
fdb_1.6.1+dfsg1.orig.tar.gz
 7cddf70c32e7965124ecfc9e6f19ddff 4524 python optional 
fdb_1.6.1+dfsg1-1.debian.tar.xz
 7f4251703e40dffadbf1cfc7bda0f446 6500 python optional 
fdb_1.6.1+dfsg1-1_amd64.buildinfo
 18e3a28bc0ccd40e81fd7c18fc0a2470 190314 doc optional 
python-fdb-doc_1.6.1+dfsg1-1_all.deb
 55e819bd7c94c2c248d5c56a6b5051b9 104094 python optional 
python-fdb_1.6.1+dfsg1-1_all.deb
 88e1cf9a6b04d79b4b7a3a320cc01950 104018 python optional 
python3-fdb_1.6.1+dfsg1-1_all.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlhGYU8ACgkQrNSfiF5U
Um4Kmg//XyyjUcdZY/wgepBSaLZJbklKSv6vLTIPObYnlHGetMdOXtxtmPjvzF/+
NzPELxQZ3tTNrHbwiU5A4BgyGUADMp6y3zRSX27BGa6AcbpnYDLfIEwrs4sqnqob
h4ipUJtMkqhG0f4e0ykN+qVhz/+dTDAeZWpxIsJXu9SfdNEIcudTi5urDWYnI9+K
5kUDd2GSYLd3dNtRnfYfWsr5dRmI404c2x8OLp6+uLTBRSWeynS3/d3uuw+4wFlC
corubsP7atzWlPJjoyPlsBs3uwelH4x2vW855QLqXPBiwx+uBWyzkZ2P0HGlnjK6
cst4E3xqFYDl5+yjcOZb8R21AGjEfJkTu2e91kBvh1ajczDqjyrP6XXVuCddMvUA
wmTcJuuoD4LWEwMbdB8iWAdWR+Ew82CVaAG8dSsCbeYQuet6pGSqDt4J9CHlgJpX
E5GPrbClGI8fbpwXJ4OTBcJpvjDINHc2UFWEt5NQrnHl3O4wQ6fyvXHUOadp7w/O
XqoWOra2jRShxjyTC9JJhSact2C36msap5f/PZKMISvSFJ5/W8cqazOAmidogF5m
HkeaBu/EAlmkNMpz575BjlAV4edE2i2n3SG4wTpkz5zN9paxMRzcO8455DhLj9m9
/Bv9bHdN7sn/mtxt/3iOXTUNg4q0zmi7TwqL+IQGR84DvOIy6aI=
=6QJA
-END PGP SIGNATURE-

Re: unattended-upgrades by default?

[Russell Stuart]

On Thu, 2016-11-03 at 18:47 +, Steve McIntyre wrote:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

I am amazed we don't do this already.  Effectively it makes us insecure
by default.

signature.asc
Description: This is a digitally signed message part

Re: When should we https our mirrors?

[Russell Stuart]

On Thu, 2016-10-27 at 08:35 +0200, Vincent Bernat wrote:
> Moreover, the download speed can be very slow, either from work or
> from home (100M fiber connection). Sometimes 100kbytes/s. That's a
> pain.
> 
> I am a bit worried for deb.debian.org to become a default as it
> doesn't work well for me. Am I alone to have such problems?

It's *far* better than httpredir.  But given adding httpredir as a
backup has become a net negative for me, that's not saying much. 
deb.debian.org so far has been net positive.

Yes, it's slow.  But for those of us who live on the east cost of
Australia our choices are ftp.au.debian.org (rock solid but 5Mm away,
connected to the east by wet string or carrier pigeon - pabs will
advise) or an Eastern mirror (fast but unpredictable and unreliable,
possibly because pabs doesn't live here[0]) it's the reason we need a
backup.  I was hoping for better given fastly has POP's in Australia,
but apparently the nearest fastly POP for Debian is in the US.

The real problem is mirroring infrastructure for Debian badly needs
some love.  As Raphael spelt out when explaining the current state of
httpredir - the problem lies deeper than httpredir itself. 
deb.debian.org can bypass most the mess because they control both ends
- debian and the "mirror".

I'm sure Debian is riddled with people who could fix the mirror
network.  In the usual Debian way (why does heart bleed spring to
mind?) it will become an impossible to ignore itch before one of us
gets off our fat arses to does something about it. [1]



[0] pure speculation.

[1] Antarctic penguins spring to mind.  All hungry, all standing on the
ice starring at the sea wondering if there are leopard seals waiting
for dinner to deliver itself, all hoping someone else will be hungry
enough to be the test the dinner theory before them. 

signature.asc
Description: This is a digitally signed message part

Accepted pam-python 1.0.6-1 (source amd64 all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 27 Aug 2016 21:37:03 +1000
Source: pam-python
Binary: libpam-python libpam-python-doc
Architecture: source amd64 all
Version: 1.0.6-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 libpam-python - Enables PAM modules to be written in Python
 libpam-python-doc - Documentation for the bindings provided by libpam-python
Closes: 833411
Changes:
 pam-python (1.0.6-1) unstable; urgency=low
 .
   * New upstream.
   * Add debian specific patch to link sphinx to python-doc instead
 of online version.  (Closes: #833411).
   * Bump standards version.
Checksums-Sha1:
 c0e9eda56fbafc46200a359fa031e35dc8a890dc 1885 pam-python_1.0.6-1.dsc
 560136bdc64bf35e37d42d245e9f910fb1448e20 47119 pam-python_1.0.6.orig.tar.gz
 1e554fe6b6324700a5772df39b368e0880595294 14272 pam-python_1.0.6-1.debian.tar.xz
 e335c3cc9c135b2dd95302d2bb77b0937056a216 42660 
libpam-python-dbgsym_1.0.6-1_amd64.deb
 badb0ba918d2dba26c8c8706bf8347859f7aa0fc 54190 
libpam-python-doc_1.0.6-1_all.deb
 731822f0b7ad2fbe48dc3deb6878d8aa0fc3587a 29496 libpam-python_1.0.6-1_amd64.deb
Checksums-Sha256:
 0498b05bd9832723cec38b378591f8aa46c733a08a1385076259174495925352 1885 
pam-python_1.0.6-1.dsc
 0ef4dda35da14088afb1640266415730a6e0274bea934917beb5aca90318f853 47119 
pam-python_1.0.6.orig.tar.gz
 183349312d067b7f1c56116a90f28df73afd4e31824fad700e795bb0c660220a 14272 
pam-python_1.0.6-1.debian.tar.xz
 2a241b2372066282c06118b2916248626849f17c8bf7fe62ca0e249c29eb15c4 42660 
libpam-python-dbgsym_1.0.6-1_amd64.deb
 009392b58a008017cabdbf0737c15ab32c4db3b9079d7e005c6a3d60edc43b54 54190 
libpam-python-doc_1.0.6-1_all.deb
 7ef2ea0fb59119732472f568e4745f2407e6b07c0da0dfd980de1fb0b1932a8b 29496 
libpam-python_1.0.6-1_amd64.deb
Files:
 62bfd94c7972394db30d71c6f9758beb 1885 python extra pam-python_1.0.6-1.dsc
 2da730f15d62b10b87e1f18c21e16fb4 47119 python extra 
pam-python_1.0.6.orig.tar.gz
 21369ff8240c2d4787bb933832f34c34 14272 python extra 
pam-python_1.0.6-1.debian.tar.xz
 a445a7c530a2f9fad73cf17f733fa48e 42660 debug extra 
libpam-python-dbgsym_1.0.6-1_amd64.deb
 92c755abb554d7065bd0eeb530250518 54190 doc extra 
libpam-python-doc_1.0.6-1_all.deb
 15eae62b2b85b59d4dfe183706e2111f 29496 python extra 
libpam-python_1.0.6-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBV8GHJKzUn4heVFJuAQp5Pw/9EvieBK+y9Lmqs1t/vgiOpNlV9EtCDHet
XoKWkZEdcHeQK9uJehRDHjdmidvm2YQGgVBmhvjIHv8h1DISdecwusVV4Abz2YnE
Y1LdA09/tBZXH89td+kOG/cnui7WPg+jHMgLQzZU38G6ECdzTtAZyUqzoSX1pjXE
8JuJHicl/eG5dfH5IzAZW2ilMk6MAl5YoZoLwgQr2xbtcdmyZau/6w6HXo5wcOR4
d/qCdEJcnqgkxnkpNRNPrii1DLA2We9pqmzDtg8JiZUu8o4eP24lbe4xhd1Su0vm
7OHuNMek3GydrKCrIlNxsVG7Xb/Q58nUPayqeXnMCE95lLqRSNxLMAZS/3y45u/a
WT+fBORH/tdm0fGK/omxPp+RBHhFUBZQeT9waDng8QkjjR1VYKHFb6V73pHmIpI3
lk16KMGU/zNa3eB8u9O8MA+Hf4nKUdH3GcmLbmJXZVopqQtliso5sVKUZrZIQuik
ISS2EHEj0yrqbc6Xfa1xw13rxlGrL5wVPOkkY/4OH9uLSmVJcMiiWQRY2G7NHnwD
YEwRlQ1ziATeCZKqgU48jtBigablFZdC/oT5jAoU0DUQXPP1y/U+4+ZUdem+UqQq
eXfFpl5EnewMKmS4//yqEEHe8BufCH8VtTMK7VbGzLaxS6vZ1iw9cBSa0nqRYpdD
NK4fccHUgHI=
=t25e
-END PGP SIGNATURE-

Re: GR: Declassifying debian-private: First call for votes

[Russell Stuart]

On Sun, 2016-08-07 at 01:48 +0200, Debian Project Secretary - Kurt
Roeckx wrote:
> Hi,
> 
> This is the first call for vote on the General Resolution about
> declassifying debian-private.
> 
>  Voting period starts  2016-08-07 00:00:00 UTC
>  Votes must be received by 2016-08-20 23:59:59 UTC
> 
> The following ballot is for voting on declassifying parts of -private
> of
> historical interest.
> 
> This vote is being conducted as required by the Debian Constitution.
> You may see the constitution at https://www.debian.org/devel/constitu
> tion.
> For voting questions or problems contact secret...@debian.org.
> 
> The details of the general resolution can be found at:
> https://www.debian.org/vote/2016/vote_002
> 
> Also, note that you can get a fresh ballot any time before the end of
> the vote by sending a signed mail to
>    bal...@vote.debian.org
> with the subject "gr_private".
> 
> To vote you need to be a Debian Developer.
> 
> 
> BALLOT OPTIONS
> 
> Choice 1: Allow declassifying parts of debian-private
> =
> 
> Title: Declassifying parts of -private of historical interest
> 
> 1. The 2005 General Resolution titled "Declassification of debian-
> private
>    list archives" is repealed.
> 
> 2. Debian listmasters and/or other individuals delegated by the DPL
> to
>    do so are authorized to declassify excerpts of -private of
> historical
>    interest by any process which at minimum provides sufficient time
> and
>    opportunity for Debian Developers to object by GR prior to
>    declassification.
> 
> 3. In keeping with paragraph 3 of the Debian Social Contract, Debian
>    Developers are strongly encouraged to use the debian-private
> mailing
>    list only for discussions that should not be disclosed.
> 
> Choice 2: Further Discussion
> 
> 
> This is the default option. Rank this option higher than the
> unacceptable
> choices.
> 
> 
> HOW TO VOTE
> 
> To cast a vote, it is necessary to send this ballot filled out to a
> dedicated e-mail address, in a signed message, as described below.
> The dedicated email address this ballot should be sent to is:
> 
>   gr_priv...@vote.debian.org
> 
> The form you need to fill out is contained at the bottom of this
> message, marked with two lines containing the characters
> '-=-=-=-=-=-'. Do not erase anything between those lines, and do not
> change the choice names.
> 
> There are 2 choices in the form, which you may rank with numbers
> between
> 1 and 2. In the brackets next to your preferred choice, place a 1.
> Place a 2 in the brackets next to your next choice. Continue until
> you
> reach your last choice. Do not enter a number smaller than 1 or
> larger
> than 2.
> 
> You may skip numbers, leave some choices unranked, and rank options
> equally. Unranked choices are considered equally the least desired
> choices, and ranked below all ranked choices.
> 
> To vote "no, no matter what", rank "Further Discussion" as more
> desirable
> than the unacceptable choices, or you may rank the "Further
> Discussion"
> choice and leave choices you consider unacceptable blank. (Note: if
> the
> "Further Discussion" choice is unranked, then it is equal to all
> other
> unranked choices, if any -- no special consideration is given to the
> "Further Discussion" choice by the voting software).
> 
> Finally, mail the filled out ballot to: gr_priv...@vote.debian.org.
> 
> Don't worry about spacing of the columns or any quote characters
> (">") that
> your reply inserts.
> 
> NOTE: The vote must be GPG signed (or PGP signed) with your key that
> is
> in the Debian keyring. You may, if you wish, choose to send a signed,
> encrypted ballot: use the vote key appended below for encryption.
> 
> The voting software (Devotee) accepts mail that either contains only
> an
> unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
> (RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
> 
> 
> VOTING SECRECY
> 
> This is a non-secret vote.  After the voting period is over the
> details on
> who voted what will be published.  During the vote itself the only
> information that will be published is who voted. 
> 
> You can encrypt your message to the voting system to keep your vote
> secret
> until the end of the voting period.  The software will also try to
> keep
> your vote secret and will encrypt the reply it sends to you.
> 
> 
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-
> =-=-=-
> 4896c7a8-1d45-49db-ba5e-490da5ed275c
> [  1 ] Choice 1: Allow declassifying parts of debian-private
> [  2 ] Choice 2: Further Discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-
> =-=-=-
> 
> ---
> ---
> 
> The responses to a valid vote shall be signed by the vote key created
> for this vote. The public key for the vote, signed by the Project
> secretary, is appended 

Accepted spyne 2.12.11-1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 24 Jul 2016 21:08:56 +1000
Source: spyne
Binary: python-spyne
Architecture: source all
Version: 2.12.11-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 python-spyne - Python library for writing and calling soap web service
Closes: 831937
Changes:
 spyne (2.12.11-1) unstable; urgency=low
 .
   * Get rid of bad $(DH_INTERNAL_OPTIONS) in rules.  Closes: 831937
   * New upstream version
Checksums-Sha1:
 afcde220a9fa348bead362730731c057c467b59c 1751 spyne_2.12.11-1.dsc
 6cf6c0660352cb17d075e87b0fe8b2ce4ff25f5e 299262 spyne_2.12.11.orig.tar.gz
 2417bbc2a96babab92f8dee240847545bc0135a6 2256 spyne_2.12.11-1.debian.tar.xz
 5cddd42651ab2def3b6fe7f7d18f1211dc6dac89 224954 python-spyne_2.12.11-1_all.deb
Checksums-Sha256:
 4d7057a67dd017b800c1812a0f7b354ed5e3ffa00ce9373203008d463a327495 1751 
spyne_2.12.11-1.dsc
 1fac2c4ca5414da34d66af4dd199640f661da92833c3979706431035fa3adced 299262 
spyne_2.12.11.orig.tar.gz
 093e8b733eea14258d4768d064a290e36e4b9fcc76eecc736ab1c86031f29eb1 2256 
spyne_2.12.11-1.debian.tar.xz
 a7a3e4228c4d6872f5a861b69483a8c2f1aecf61e87b13bc563a114bd7af88b3 224954 
python-spyne_2.12.11-1_all.deb
Files:
 bde13ecbf69a209bf4dba0b7e7594060 1751 python optional spyne_2.12.11-1.dsc
 6073a472efa3e44647811a596b88cb4a 299262 python optional 
spyne_2.12.11.orig.tar.gz
 b63d61ed7a0e8934fa225a9f5629a3a1 2256 python optional 
spyne_2.12.11-1.debian.tar.xz
 8f4cc33773976b5a50f35bd20d6a365b 224954 python optional 
python-spyne_2.12.11-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBV5SiD6zUn4heVFJuAQqtSRAAmn6DfadConnUKmzn2mxKxdYd3xpMx4ys
LbcjGyHadRv1rzdiH+w82+DOuC5PeS9G6t2s/Wz4IVOxmsAIb5bSf4wW4qyTx2Vo
tsrximKyS51rx0YORx6UortKhci1anHxuQK7WEcdv05X9dXX+n+MUSODdWlIrWjE
NhacY30ZdNU1DoH3uk6BShxrAW44sU8cnc+dg+pW9PjoRBIRKo1i3T5oCw0NVcNX
aFAMB4DESfRaU6UpxjxnjymhIqnZ7ITaoDBnO3enaTnQFY2mFa8axKpy86evXd7S
iNGkMiRYuT8s8wq3cs+TUn4JzqjgbneA/J8nKiNxwi+nmsDbGmAXdgkFmMDOZHSW
K/B3Dsr4x+QE3f0WnXr3w8Eg4LLoK9hRvQ/QMpqPTwdBAWsHeNJAWZLaqbllKDK4
FtCdEJbyDsuzXSY7gGESXDM6vMfCHWrOJg/L8RdYZK1h1/kdjp/3u7u5ZzJYG2iX
kwTtiqJn68rF76qV9ZP/tIEpBMlMRJqaCgTSxhm0bcgp0orgY4KfY7XC8FKPdiVu
o5UVkA/sBryqAiphutaMXYze1I0MrUrVmRYvKMocQh+J+tZtkqzjGOP/a8HVJbpv
is09AvcUZsVWthyZuxkyaXMiTyo39y+kBhv3sCgmQ8q33i05oSJjtVlYnJMPL9aB
o/jxJzrrzNc=
=uiUB
-END PGP SIGNATURE-

Accepted fdb 1.6+dfsg1-1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 24 Jul 2016 19:52:54 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 1.6+dfsg1-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Closes: 831940
Changes:
 fdb (1.6+dfsg1-1) unstable; urgency=low
 .
   * Get rid of bad $(DH_INTERNAL_OPTIONS) in rules.  Closes: 831940
   * New upstream version
Checksums-Sha1:
 4baed74adadd6ecf9c852a2dc2ce46a107a4d8fc 1942 fdb_1.6+dfsg1-1.dsc
 f07012cd27155135ed9911dc852faa563f888e7f 616243 fdb_1.6+dfsg1.orig.tar.gz
 a81e9e24dfa6b2ccc08e57fb8caed28bdd4af620 4508 fdb_1.6+dfsg1-1.debian.tar.xz
 17db13b8db5f029b54c89a30f1348848a6ed54f9 192136 
python-fdb-doc_1.6+dfsg1-1_all.deb
 0a06cbbc2f52088e92c4e2073388af92774372a2 103990 python-fdb_1.6+dfsg1-1_all.deb
 35959f101899c6315e8ac0bbd031a5025ae46fbf 103858 python3-fdb_1.6+dfsg1-1_all.deb
Checksums-Sha256:
 c5920b814f9bdcac4a92bebf4a8c3889eaa9966cb3ead32fbdab1a09ff454519 1942 
fdb_1.6+dfsg1-1.dsc
 faf582f33f707454bbfb9bfd3f57eb10cd2fa21a824b9bd1961c2dc4a52106d8 616243 
fdb_1.6+dfsg1.orig.tar.gz
 aea42b8b7f5655cda8887e7b5c7b30d68cd3b96444e423e164a9f62c8a743f1e 4508 
fdb_1.6+dfsg1-1.debian.tar.xz
 20997fe33c80afd5dc5074f0822d8c7faacfadfb77e9498142f5ee5cf02ccfc7 192136 
python-fdb-doc_1.6+dfsg1-1_all.deb
 9eaa5ae75b97082c4622bfecbab3e0f4b52ce57c2b61779ed3823663a9fc59f0 103990 
python-fdb_1.6+dfsg1-1_all.deb
 a42c2d227e4d47f71fb8addbe08b4c76bdb41abe41a0965c3bb9566b1eeb730d 103858 
python3-fdb_1.6+dfsg1-1_all.deb
Files:
 61f2742d65ece90ae115c9aa13104284 1942 python optional fdb_1.6+dfsg1-1.dsc
 6ab987a373f1ac57dd33e2295f5b3709 616243 python optional 
fdb_1.6+dfsg1.orig.tar.gz
 f33fbe1cf98d235579268adacc2c3bce 4508 python optional 
fdb_1.6+dfsg1-1.debian.tar.xz
 386713f49d7afa1af3f4cd06bff95abf 192136 doc optional 
python-fdb-doc_1.6+dfsg1-1_all.deb
 0967570a31a8e08b6722adb2b4ad234c 103990 python optional 
python-fdb_1.6+dfsg1-1_all.deb
 98874117a28f1eba4afabc48a43046d9 103858 python optional 
python3-fdb_1.6+dfsg1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBV5SeUqzUn4heVFJuAQrkSw//SpeEVmz/NFcCJedw8wEJt6RyP4G4RQBn
Bkp0O0OgNH8mNd+mpjtKNhkiAnorLjmiDpzTiedOAQhM1U5mp/h+Uzrz1gSpuigf
fFqL3LSnAhUSZyyzOzq+ozZnKDgG69LK+GB9oS51ssBIwNdRPJDQlZX2fd69evYw
DuUalQ2ailxxlZE3yPZOTzUTnoDZw9jpa2dPMuRC51lnimVels0DskRSkkTNrAs0
X/t2lwhiZLF9geGvbinjyX+xEtMRd7jcI9oJPyoSfMKFgBSJOl8FYcxRtezCaBwz
wq5KWZTewhqpg5z/CkeY3YtpStOFYJ+2gWwKMk+/qwHXYVGJq51FyA3vK0miCiQY
5jM0C+w7USwDRSmAkKpk4Vj3+5YOnatUC+BW5PsCP5DW5+Ao2kNQ3LWsIW6ZGHBk
6rgtIVGT29GcqMwJ2+VTsraO5eK9XuL+kxhYdaNTVlDoj2P8qPf2XbvjcnfG5kTL
2x4bKB3N+fY21O0c6R8zUfs9JFxZLO7N8NM/XasSpheR3r8pbDYp9a1+UeXFq+y8
2NNsk0V4NQrfyoiBKbTj5mXrtkMw0F1isEaSQ3ErTKEX5+7X9SILKWPSiVzymho5
iL5d36PpaQX6Yc6QTgGZuzlOpcd0vySSABdN33Ss1tqBNDiED5ljiyNReHIgf/wv
4U5geOGROgs=
=yTww
-END PGP SIGNATURE-

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Thu, 2016-07-14 at 14:13 +1000, Russell Stuart wrote:
> The second component is that apparently tapping doesn't work when
> > enabled. That's most probably a bug, file one against libinput at
> > bugs.freedesktop.org and it'll get fixed.
> 
> Done.

For anyone still following along it is possible to get libinput to work
as least as well synaptics on my laptop (and I presume all others):

    https://bugs.freedesktop.org/show_bug.cgi?id=96925#c6

Short form: there are bugs somewhere, but you can work around them.

signature.asc
Description: This is a digitally signed message part

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Thu, 2016-07-14 at 13:41 +1000, Peter Hutterer wrote:

Thanks for the thorough analysis.

> The second component is that apparently tapping doesn't work when
> enabled. That's most probably a bug, file one against libinput at
> bugs.freedesktop.org and it'll get fixed.

Done.  Having to filing it against a Wayland component was novel, and
encouraging.

signature.asc
Description: This is a digitally signed message part

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Tue, 2016-07-12 at 10:07 +0300, Lars Wirzenius wrote:
> I've been using the following script, with variations on the
> parameters to find a working setup. The values below are the best I
> could manage, and they aren't any good.
> 
> #!/bin/sh
> 
> synclient \
>   TapButton1=1 \
>   TapButton2=2 \
>   TapButton3=3 \
>   PalmDetect=1 \
>   PalmMinWidth=50 \
>   PalmMinZ=10 \
>   VertSCrollDelta=-41 \
>   HorizScrollDelta=-41 \
>   TouchpadOff=0 \
> "$@"

For what it's worth, for me on stretch synclient isn't too reliable.
 Eg, "synclient TapButton1=0" has no effect - it should disable one
fingered taps.  The libxinput equivalent (xinput --set-prop) doesn't
work for libxinput either.

The only thing that has proved reliable is putting a file in
/etc/X11/xorg.conf.d/touchpad.conf:

Section "InputClass"
  Identifier"Touchpad twofinger scroll"
  MatchIsTouchpad "yes"
  Driver"synaptics"
  Option"ZAxisMapping"  "4 5"
  Option"HorizTwoFingerScroll"  "true"
  Option"VertTwoFingerScroll"   "true"
  Option"FastTaps"  "on"
  Option"PalmDetect""on"
  Option"AccelFactor"   "0.1028806" #2x
  Option"AdaptiveDeceleration"  "10"
  Option"MinSpeed"  "0.5"
  Option"MaxSpeed"  "4.75"
  Option"TapButton1""1"
  Option"TapButton2""3"
  Option"TapButton3""2"
EndSection

I would happily use libxinput if it extricated me from this mess, but
right now it seems to be bugs all the way down.

signature.asc
Description: This is a digitally signed message part

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Tue, 2016-07-12 at 07:48 +0300, Lars Wirzenius wrote:
> After Raphael's mail yesterday, I switched from the synaptics driver
> to the xinput one (by removing xserver-xort-input-synaptics) and
> since then, I've not had a single case of moving the mouse or
> clicking by tapping by accident. When the opposite change happened a
> few weeks ago, the accidents started happening with such frequency
> that I could barely finish a sentence in the same window I started
> it.

For me at least the problem isn't palm detection, because in the end
it's a kludge that can at best only partially work.  For synaptics the
solution for this is syndaemon, and the problem it's broken right now:

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818471

Maybe libinput does the typing detection syndaemon does, but I can't
find any evidence for it.

> Tapping and two-finger scrolling work perfectly fine with the xinput
> driver, too.

As a touchpad that doesn't move the mouse as I type is hugely
attractive, I tried libxinput again.  Same result.  Palm detection
works wonderfully, but only because it doesn't recognise a tap from
finger either.  Clicking (ie a tap heavy enough to activate the
mechanical switch underneath) does work.

If I configure synaptics to ignore TapButton1 taps (as opposed to
clicks), it also has faultless palm detection.

signature.asc
Description: This is a digitally signed message part

Re: synaptics vs libinput and GNOME 3.20 no longer supporting synaptics

[Russell Stuart]

On Mon, 2016-07-11 at 23:51 +0200, Raphael Hertzog wrote:
> Well, if some KDE/XFCE/etc. packages work only with synaptics and not
> with libinput, then we should get those packages updated to depend on
> xserver-xorg-input-synaptics, no?

I don't know about KDE/XFCE, but in the etc category is LXDE, and it
works with both.  I'd be surprised if KDE and XFCE didn't work with
both too as libinput and synaptics are drivers, and as such are hidden
by the X API these window managers use.  The surprising thing for me is
GNOME evidently isn't using the X API, but instead talking to the
driver directly.

In my case, the thing that broke when xserver-xorg briefly switched to
using libinput instead of synaptics wasn't LXDE, it was me.  The
reasons are spelled out in the bug that was filed when the change was
made:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822835

Briefly: synaptics is much better touchpad driver than libinput.
 Libinput treats a touchpad as a mouse.  Modern MAC like touchpads are
great input devices, but when you strip them of multitouch and gesture
recognition they become so unwieldly people give up and plug in a real
mouse.

signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Russell Stuart]

On Tue, 2016-07-05 at 08:25 +0100, Rebecca N. Palmer wrote:
> Have you reported this bug (with the full warnings)?  If not, please
> do so.

I haven't.  If I got a response at all to "My monitor doesn't work" it
looks to me it would be: compile latest source with instrumentation
turned on and send log.  I've tried compiling the Intel drivers before
- I could not get patches to apply.

Fortunately, others get the same backtrace:

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1523088

It probably isn't related to my monitor not displaying, but I won't be
able to tell until 4.8, when the patch addressing that report is
scheduled to make it to a released kernel.  Like I said, progress is
slw.

My point is really the 4.4 kernel is nothing special for amd64.
 Laptop's with Intel chipsets that started shipping over 6 months ago
don't work 100% with it.  Actually from memory the Intel GPU driver
opps's on occasion in 4.4.

signature.asc
Description: This is a digitally signed message part

Re: Thinking about a "jessie and a half" release

[Russell Stuart]

On Tue, 2016-07-05 at 00:38 +0200, Ben Hutchings wrote:
> As I understand it, xserver-xorg-video-modesetting should be used
> instead of xserver-xorg-video-intel, for chips supported by the i915
> kernel driver.  So the latter should be changed to limit the device
> IDs it claims, then both of them should be backported.

Currently 4.6.0 doesn't work with skylake for me when I plug in a
3440x1440 monitor on a Dell XPS 9550, both with and without xserver-
xorg-video-intel installed.  It never has worked reliably on any kernel
version.  Currently, the monitor works maybe 20% of the time - so if
you persist for 5 boots you've got a reasonable chance of getting
lucky. The only noticeable change from 4.5 to 4.6 is in the kernel
backtraces produced - they have got fewer, and they are only warnings
now.

So from my point of view Intel still hasn't produced a working kernel
driver for hardware they released a year ago.  I sincerely hope they
get the thing stable before we get to stretch, but to date progress has
been very slow.

signature.asc
Description: This is a digitally signed message part

Re: trying to use wireless not from gnome... what's the incantation?

[Russell Stuart]

On Thu, 2016-05-26 at 12:15 -0800, Britton Kerin wrote:
> On Thu, May 26, 2016 at 4:35 AM, Andrew Shadura 
> wrote:
> > There's no need in any of this, ifupdown already supports this mode
> > without anything apart from wpa-conf.
> > 
> > See /usr/share/doc/wpasupplicant/README.Debian.gz for more detals.

It does say that.  Maybe on Debian stable it even works.  However on my
laptop something was starting wpa_supplicant as a service at boot, and
I had to stop it in order to make it work from ifupdown.

> Ok, this approach does work if rfkill is added to the equation.  I
> tried it originally and it didn't seem to.  The problem is that my
> card boots up with rfkill activated, and ifup doesn't seem to know
> about this and reacts strangely.

I had the same problem on a machine running hostapd.  I thought it was
very odd the system booted with rfkill softly enabled.  Unlike you I
didn't believe the card or the driver would do something so daft, so I
went hunting for the culprit.  It turned out NetworkManager soft
turning rfkill on at boot, even though the interface was listed in
/etc/network/interfaces.  The ifupdown stanza for that interface is now
(somewhat elided):

auto wlan0
iface wlan0 inet manual
pre-up  nmcli radio wifi off || :
pre-up  rfkill unblock wifi || :
        hostapd /etc/hostapd/hostapd.conf

Both the nmcli and rfkill lines are absolutely required, and this is on
Jessie.  They may only be two extra lines, but it took me hours to
chase down what was happening so I could get hostapd running and while
giving the user pretty GUI interface for the other networks.

Given the NetworkManager.conf is as appears below, it seems to be
happing despite what the doco says.  It is this sort of crap that gives
these GUI interfaces a bad name among sysadmins.

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

signature.asc
Description: This is a digitally signed message part

Re: trying to use wireless not from gnome... what's the incantation?

[Russell Stuart]

On Thu, 2016-05-26 at 10:24 +0200, Michael Biebl wrote:
> It's hard to say though. For this we'd need proper debug logs to
> further investigate this.

You shamed me into doing something about it.  But now I test it,
network-manager works.  It's been 3 months and a similar number of
kernels, so who knows what it was.

Wicd still doesn't work.  If the interface hasn't been initialised with
ifupdown, it doesn't seem to realise the laptop has a wifi card.  When
it does know it has a Wifi card, it can't successfully connect.

signature.asc
Description: This is a digitally signed message part

Re: trying to use wireless not from gnome... what's the incantation?

[Russell Stuart]

On Mon, 2016-05-23 at 08:28 +0200, Adam Borowski wrote:
> Using low-level tools can indeed be tricky, so while they're more
> powerful than anything NM or wicd can do, they're an overkill and a
> waste of learning time if what you want is regular use of a single
> interface.

I have a new laptop on which only Stretch worked - and then only
partly.  Among the things that didn't work were wicd (kept on
reinitialising the interface every 10 seconds or so) and network-
manager (didn't recognise the interface at all).  This initially caused
a lot of head scratching and wasted time because I blamed the drivers
of new hardware.  But it worked 100% reliably when in desperation I
configured it manually.

If you are posting to debian-devel manual configuration should not be
hard for you.  Ensure ifupdown and ifplugd are installed.  Add this
into /etc/network/interfaces:

auto wifi_interface
iface wifi_interface inet dhcp
pre-up  systemctl stop wpa_supplicant || :
post-down   systemctl start wpa_supplicant || :
wpa-driver  nl80211,wext,wired 
wpa-conf/etc/wpa_supplicant/wpa_supplicant.conf

And add stanza's like this to /etc/wpa_supplicant/wpa_supplicant.conf
for each WiFi network you want to use:

network={
ssid="a-network-i-use"
psk="super-secret"
}

network={
        ssid="another-network-i-use"
psk="another-secret"
}


Doing it like this drops the amount of code between you and the metal
by an order of magnitude.  Reliability goes up accordingly.  Day to day
usage is identical - it just works wherever you are, connecting you to
the local network at boot without you having to raise a finger.  Ease
of configuration is a matter of taste - I happen to prefer to being
able to see all my wifi networks in a text editor, so I won't be using
wicd or network-manager for wifi again.

signature.asc
Description: This is a digitally signed message part

Accepted conspy 1.14-1 (source amd64) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 16 Feb 2016 20:41:44 +1000
Source: conspy
Binary: conspy
Architecture: source amd64
Version: 1.14-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 conspy - Remote control of Linux virtual consoles
Closes: 813034 813035
Changes:
 conspy (1.14-1) unstable; urgency=low
 .
   * Describe kernel limitations in man pages.
 Closes: #813034.
   * Infer size of large consoles.
 Closes: #813035.
Checksums-Sha1:
 63e3be178114252a2ec690602c3f8c7444326d30 1704 conspy_1.14-1.dsc
 f307101460a6ca94f75296ee669645d7c9a019a1 26637 conspy_1.14.orig.tar.gz
 157ea98880dee9fafb96ca96bae8c983f59ab3c7 13452 conspy_1.14-1.debian.tar.xz
 869b087260a28ad41d0aab89c97a2aef647c08b8 13574 conspy-dbgsym_1.14-1_amd64.deb
 7cccd4dc2e42abf24c57d6765724e70d2932b3ff 22518 conspy_1.14-1_amd64.deb
Checksums-Sha256:
 1e9a6c2a2609c431801ec1a48eb92e439a4f8e2c7c9074ea69a659837648d679 1704 
conspy_1.14-1.dsc
 4e2f05c9e19a6673a323127711ff007f7f9244f3a5c793c2b079eb7fbb113319 26637 
conspy_1.14.orig.tar.gz
 0022a331f64c6e8be16f9686d1623c8ca159a35f3ee53872d4f1324e86ba4313 13452 
conspy_1.14-1.debian.tar.xz
 0f1812a979fececd9a17e04f1a7c143a6410513f5fd2f488c0d3c7a2a748c443 13574 
conspy-dbgsym_1.14-1_amd64.deb
 711e95039a5afe586f2054160656bb8f7835a4bd0aff1c88d0a85217f57ed24d 22518 
conspy_1.14-1_amd64.deb
Files:
 27a9dccab96b705c20d74d1af0f21151 1704 admin optional conspy_1.14-1.dsc
 04f2fade610104c3d5e952d0221ac028 26637 admin optional conspy_1.14.orig.tar.gz
 49d3bfebde07e9e1b35d9601adbac08e 13452 admin optional 
conspy_1.14-1.debian.tar.xz
 58150cca4d394058f26bc03455ebfda4 13574 debug extra 
conspy-dbgsym_1.14-1_amd64.deb
 e098a1794c7acc078effa0c22297d232 22518 admin optional conspy_1.14-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVsL8+6zUn4heVFJuAQoppRAAijE5963RKEypYViJ4JJW0DjinHqP67YD
kf1lvnI7SNVsucrO9B/1M9F2TgoeAj97gWqI8zuqkAvwzx98+gxgxihiz4OC+qe6
r8206WEA+z7ph5jZq63cOjsInnQBIBrxNpVfye/w0rStITVFjionAlkRew4RAD26
dzvTuecx5t2t4PY1wgTwER81KpcUna/1Nx62ho71zY/QQ5DbmOmso3ddO6kZDNfZ
zC7loCaoY5qOrNAZuh2/mYXcZPWheohd94Ue34N3dzD/43nS++uea+CcuUj2W6V/
AVYDlWt6QdnHtlzKX2egD4VVAAWtSytLvaC63H1s3RxY0IvXX1jRgNnlE1AF+m2g
nTbIlJZx63+Zqn8yPeH1cWdQVEIVp0fs91EPkC5lspVtvpsxe6gJsDgnk4FxZyUS
sL7Ew3yzAOBIybcP04CXx1pvouzbVOkrsSm1lYNCL7sID8VS8ZUCofopYwJz9+ST
Q1JalsBz2IlSR5yyD6yYmV6Zqv3V1k5sd+HmH8n+Yywq1gcGt3gK+L0DpeU05pnN
0oj6AIAV5KP9oAtyga0xK89yQED465mv5ztanwRv57roPCzjvKFD3gOJMN8yBE86
mf1g8BRL+8K6BGE2dHCQPX4KZ7Rcw1yR3TH84TsPfemDf5kUepZeG12Gj4+98xef
oevhGCNZ3xw=
=OAd1
-END PGP SIGNATURE-

Re: An abrupt End to Debian Live

[Russell Stuart]

On Mon, 2015-11-09 at 17:47 +0100, Daniel Baumann wrote:
> An abrupt End to Debian Live

As a person who recently used Debian Live to set up a PXE boot image
after trying several different alternatives including debian-cd, I am
sorry to hear this and sad to see debian-live go.  It will be missed, by
me at least.  It saved me a lot of time.

Not only that, but it was an impressive piece of software that as a DD I
was proud to point to.  I've built live boot systems from RedHat,
debian-installer, DSL and a number of others over the years.  Nothing
else came close to debian-live in flexibility.  It was literally a
breath of fresh air to me - the tool everyone in working in that space
should be emulating.  Despite it's flexibility it also managed to be
simple to use - it did what it said on the box, the documentation was
good and the interface was straightforward to use.

All in all, a credit to those who designed it and worked on it.  I wish
you all well.


signature.asc
Description: This is a digitally signed message part

Accepted conspy 1.13-1 (source amd64) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 21 Sep 2015 09:41:02 +1000
Source: conspy
Binary: conspy
Architecture: source amd64
Version: 1.13-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 conspy - Remote control of Linux virtual consoles
Changes:
 conspy (1.13-1) unstable; urgency=low
 .
   * New upstream release.
Checksums-Sha1:
 cb8720a007fa934ccf8e4347721692a17e5980bb 1704 conspy_1.13-1.dsc
 026fd15274b5df8eec5c49f0164bf96d2379fae5 26057 conspy_1.13.orig.tar.gz
 8a846ef89c00219b930c726f3caa099b640cf653 13400 conspy_1.13-1.debian.tar.xz
 1524ebb9d65735ad05c7e0a638b3761d57ad3d89 21894 conspy_1.13-1_amd64.deb
Checksums-Sha256:
 d7ec4e33bff2237f9ae80c343d16c3b1a8fb0a162bff9afb5356d1b9f120f87a 1704 
conspy_1.13-1.dsc
 82c2f2034456463f079858dea4505ef3cf1140d72086d55af0095871c6533a15 26057 
conspy_1.13.orig.tar.gz
 481a05599e4134e51caae60462495eac2ca0fa2abf2ae98f26340d1b0596cef8 13400 
conspy_1.13-1.debian.tar.xz
 fc6fb56e2a5536630496fb75f04580e0dbef15ce7330580575c8b083c9ee6da3 21894 
conspy_1.13-1_amd64.deb
Files:
 3a18b78b8d0660e93d8e4b55f67b604d 1704 admin optional conspy_1.13-1.dsc
 8caed1f64a618917d5143a4a5ebb48d8 26057 admin optional conspy_1.13.orig.tar.gz
 3c4edcb5bc27b9195fabbb86bf554548 13400 admin optional 
conspy_1.13-1.debian.tar.xz
 d35fb0459675170c1feaba0d4352c3e0 21894 admin optional conspy_1.13-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVf9EdqzUn4heVFJuAQqk7BAAuxZjyGbuSwJfJFCseEUShdKDpniLirO5
StzfXiPcDvbgtoUlnLH0LLE3+klhQC3sR/Dp6i03lzqTI+oNx9tl8N3pf8n/b7X7
yoqIXu8vPopIeWTzaDO7D+LxXH7CmSxJlnftUCy3tbtBzvxHi9a0jPVAis+Ra7JW
H67Beu3wW/V/Dq5wm8CJuX3atBl/wWYkN90HvRz5XyXZggs9SLIic4LEoGpdL87L
TPMfzFrlYbSHbwBy7As+1SRJNQ7ZxXbt0+CGmVdb33qVy0SPH8PTVh5VVkJg8vL5
S+oxfO+j6bKrpfIEaWyJXvIQ5IO3FDE9p3jX+fCpvNn3f6IkPfrxU7o3mvc5nFZV
wekMcd/9VpE6LXeabh3DqQ6JVulQuO/ta0HkVNzOo31lXTkrx2MuqUGZPYHzgJWH
ZunGvgNHrlWYWlBdVITRe/o0vo1n6uc6UMO8ALOUCvO6bhzBFZ3aGPP0wrYymQ4M
I/PdcM4cVetkDY1gUVdFiMCJlt/Eq5Bq1O0rg/WAG96Cz5+BuIL+2oE6J3Ocz0GX
BWVtqyzIgtM+XUoou2daikXYQDRV5DZn+diho4Zq3awp2lkWSf8iBOeUQj4x52R0
HdRM6GRuItHrMxol9x7bkeYqdrUYE7JmWt8zGKBoaJDXjRFcGk1U2D1KnBIYtqE7
PleUnRxagjY=
=ZdGI
-END PGP SIGNATURE-

Accepted conspy 1.12-1 (source amd64) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 16 Sep 2015 21:23:59 +1000
Source: conspy
Binary: conspy
Architecture: source amd64
Version: 1.12-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart <russell-deb...@stuart.id.au>
Changed-By: Russell Stuart <russell-deb...@stuart.id.au>
Description:
 conspy - Remote control of Linux virtual consoles
Changes:
 conspy (1.12-1) unstable; urgency=low
 .
   * New upstream release rebasing for sourceforge.
Checksums-Sha1:
 83c64776d73cbbd31665e7005f1414b2cdfaa6af 1704 conspy_1.12-1.dsc
 5cbbe9b6f20cc530d320a27464e40dc67a208412 26009 conspy_1.12.orig.tar.gz
 96d07be6d5b6a56f45b062265a8a76da169eca6e 13388 conspy_1.12-1.debian.tar.xz
 501e78e4efa71af4c6d0c639a1645bbf87e038ac 21834 conspy_1.12-1_amd64.deb
Checksums-Sha256:
 5b065fd9c2feae0f1e1441d87f7859be5177e2965c854bca3b6dfb90e71c2c01 1704 
conspy_1.12-1.dsc
 ffa3678b30450c754d8ccc6e4b5cc2a3eb4cd2a2239783002063763df8591102 26009 
conspy_1.12.orig.tar.gz
 64407977420d721bf03371912cf79ffb5ce15c71e42ea46675f3660c38682fed 13388 
conspy_1.12-1.debian.tar.xz
 9c0d3944ed69c539cc3ec3ff174042ef2389f144922a13de18cd60826917cc10 21834 
conspy_1.12-1_amd64.deb
Files:
 63d0418abfae124b7b467fcab7a69316 1704 admin optional conspy_1.12-1.dsc
 4c07ab53ccf01ff608ec4705a443edcc 26009 admin optional conspy_1.12.orig.tar.gz
 4170e5aec2377ab7d5b7c8eebf91b875 13388 admin optional 
conspy_1.12-1.debian.tar.xz
 a03752391dbf2dbef1c45cbbec9e35b8 21834 admin optional conspy_1.12-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVflSy6zUn4heVFJuAQpCTw/+NbB4fKwfAQ0eQeSWZTgMGMgpb7IAPB7G
5yGsh26Agj+/19zWw1UjO7Ro+HYQerichxUuA2XItCBsz7afPcuzF2O/9PKGDRB2
hQZ6klVKqL9tWWso84nYDuhyomCfENBUCHUd//0MS1EmIWTKst5DQaQ1MUrk/wKQ
tWzdAkyYEBq/n/jOrc9235tD0g6peTKUz/JqOeFOi87oDHWdhSW4zbE4fkM+/rZu
0tOszQ7+wRzidybf4Z+dryYPbS2V78msdVPq8PHf4frCZDO9QFH1MGWwyFIW3fAQ
Rb8qJXE8gF0ra6kVevMosC7H1XtSXw5YJix0Uet5FFSFAcD8RcmEQ2gmCo2lZSAM
OFqJbgrRW/2lEKnUtmWQTcmpwNPHkzWQO52rVmvz0BGyhl2VMDJKg3bhW5K9nexE
xaJ5didRIEq/OLXFW5rLxV4Rm67AZ4u9+5ixgwT5p7JeBkcfw3YnlvJlBaK+kErk
Nu/T//H7pjA79NQ4BNKsezRJpP593tztEDVPwnfMsr963pYNrZhz8pjH02+sX5I5
eitEf6eM9ZS+oCDK1K4QzDDkTBkze7ZaiCDm/qWc32LP3DT4+KJlhedpG2nIvcIt
ka8l9y7AFRuU0dISwzACjGpUOxoBYk+8qivPKcd5mbmb3tX4+xZO31VRbs6EIwbd
yWBwWxNT9DI=
=akEx
-END PGP SIGNATURE-

Accepted fdb 1.4.9+dfsg1-2 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 13 Aug 2015 21:49:08 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 1.4.9+dfsg1-2
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart russell-deb...@stuart.id.au
Changed-By: Russell Stuart russell-deb...@stuart.id.au
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Changes:
 fdb (1.4.9+dfsg1-2) unstable; urgency=low
 .
   * Fix uscan.
Checksums-Sha1:
 5e9af45bc9009896b9f8352f022809436d71a56b 1956 fdb_1.4.9+dfsg1-2.dsc
 810aa1c66b9040db91a26df4557fb95745a951be 605989 fdb_1.4.9+dfsg1.orig.tar.gz
 822aa847b395aa538ab739d45892ba441a3a15a8 4484 fdb_1.4.9+dfsg1-2.debian.tar.xz
 345abcd9d6a6fc0e72e920d8b70b2151b1084083 181834 
python-fdb-doc_1.4.9+dfsg1-2_all.deb
 56df2d4a225d10ac5385494762b886c64fe7fd51 96466 python-fdb_1.4.9+dfsg1-2_all.deb
 dc030f0ba6d9de25e53f33b3aaf23d194f0e927b 96356 
python3-fdb_1.4.9+dfsg1-2_all.deb
Checksums-Sha256:
 10a5b0edb0e1d75e1ee697313bd6bef1d51187b162b34b4b07d36fd0b70ee2ea 1956 
fdb_1.4.9+dfsg1-2.dsc
 fc365b083ad0121bf77016fb6a6a9bd16261da431f24cb77c6441c8318f239cd 605989 
fdb_1.4.9+dfsg1.orig.tar.gz
 5a558205e0df5e4611accc574a34c4e7c4dabbe3c29c7e52e25bdb95714f0411 4484 
fdb_1.4.9+dfsg1-2.debian.tar.xz
 1f3ca0e7583eedccdd50fca9567eed7accece8080fb57dd85f9b50054a494586 181834 
python-fdb-doc_1.4.9+dfsg1-2_all.deb
 faa8279b3bf39561064d0b6bfcd58821b85adaa96d81c617ed2eede82eb2aada 96466 
python-fdb_1.4.9+dfsg1-2_all.deb
 129b1368d7a28bee3113325c82e8910525e4374e49917421cc60eedd1e20db81 96356 
python3-fdb_1.4.9+dfsg1-2_all.deb
Files:
 2b3cef823f0601649102c4808a278955 1956 python optional fdb_1.4.9+dfsg1-2.dsc
 3f9e6a19dbf000eb971c156ccfaa985a 605989 python optional 
fdb_1.4.9+dfsg1.orig.tar.gz
 3c93882a9f28425296a9b8ba89d7f3dc 4484 python optional 
fdb_1.4.9+dfsg1-2.debian.tar.xz
 f3a1441d058ef0e44b2b9464a1370841 181834 doc optional 
python-fdb-doc_1.4.9+dfsg1-2_all.deb
 21b3cd1514ad1c379c2142f5f0972144 96466 python optional 
python-fdb_1.4.9+dfsg1-2_all.deb
 9aad7f2bc29c1fb0c12823e532b05860 96356 python optional 
python3-fdb_1.4.9+dfsg1-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVdMtaKzUn4heVFJuAQotZA/+PsY9mlHKX9ZzqJZcOHn01SL/lDQUfeZg
QawMRQkuGAsjgITzGvx/GJ9SV7yDyahjpUXkUnKPdHhotJKkBq0DoFZT+LExjhdh
RlrRVrGXQz95JfwikQPd0Svb7YGpCic1b2sXZ1mFvBP5Uyhq4oULrpMmGZcHap1g
nshO6xyPHfLhKnJjZ4Ij3Lmsl1GtleGgwlrMnfYhu9yUjnqy14/NyuGlC0n8nFkN
Tl9QJkY6mZxzKvuEV7nfoxMNVsq4hClqW0UIoF6V/WVGs9bn2RrKdBJ7YDHZBhtT
6uWiVz7r/M+OKtVbaRUK1sPhytZp4a/xLrprXTJj5RK1rd7ciwRfFb3Uj5N8kJK5
/g/77IlfbLY30tKp4AKF2UVUkiW6/G1Gg+vHXj1MIbhQ7bG/eXCpRQe2eUD4K6BU
V3QjAeXH0P8LbpbiMLw74IgZfdgEXItJO0qcFMvDOE0RRx5dG1vlq78SU4CtI1Tn
MIeywatfeX/lNhb48hGdctgun4bjpVNwyrvA1F0sF6fcHN7z9vnsugMHS7GUePpp
mYRA5R/wipXrv6othlnSJbG4ViyJYmRgYFUp9J92cHahKB5UUkzc8Wra7MY0ntZJ
wGb0y6nHD/SyTMuo8NQ5PYJIwIHN3KIKtVu3W6PsH0D4xMyhzAgscMfFPxpVfDeC
KHCzCozZySw=
=7GUW
-END PGP SIGNATURE-

Accepted fdb 1.4.9+dfsg1-1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 11 Aug 2015 16:45:29 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 1.4.9+dfsg1-1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart russell-deb...@stuart.id.au
Changed-By: Russell Stuart russell-deb...@stuart.id.au
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Closes: 794128
Changes:
 fdb (1.4.9+dfsg1-1) unstable; urgency=low
 .
   * New upstream version.
 .
   * Remove python-nose dependency so dh-python doesn't run nose.
 closes: 794128
Checksums-Sha1:
 1434921d57d853c347dd6b62908fcd570bfad48d 1956 fdb_1.4.9+dfsg1-1.dsc
 810aa1c66b9040db91a26df4557fb95745a951be 605989 fdb_1.4.9+dfsg1.orig.tar.gz
 6c7bf3b989bf6626b56f6b13dab4bac744a349e5 4404 fdb_1.4.9+dfsg1-1.debian.tar.xz
 6de4c75276e92e6b7bbb3e9c3120b280f036bdad 185130 
python-fdb-doc_1.4.9+dfsg1-1_all.deb
 6d306ac8d578e056380e7acc0a43bc80dae0df64 96446 python-fdb_1.4.9+dfsg1-1_all.deb
 738eb140c5d55d2cd535d2a7995432cf21134db0 96354 
python3-fdb_1.4.9+dfsg1-1_all.deb
Checksums-Sha256:
 14395d01e21fd0c6e2c6100747f085693fd2324edd65ff8fd2ef2e6260d41850 1956 
fdb_1.4.9+dfsg1-1.dsc
 fc365b083ad0121bf77016fb6a6a9bd16261da431f24cb77c6441c8318f239cd 605989 
fdb_1.4.9+dfsg1.orig.tar.gz
 73acf9aa3f89b4e1abd84fcd7786ae2551015d985797683bd99b6d87533644cc 4404 
fdb_1.4.9+dfsg1-1.debian.tar.xz
 654380c640e86dda9cc90c6c589e2402d7304bdf7b196c95d73ec0704215d4f6 185130 
python-fdb-doc_1.4.9+dfsg1-1_all.deb
 8163addbfa0deeb4ac99c30e423d68f3e442879022c63da16d98053dd2bb65f6 96446 
python-fdb_1.4.9+dfsg1-1_all.deb
 0d97f88db17cd772e008a6e46a6b1e62fab18d61341b4fdb611aa051fd436594 96354 
python3-fdb_1.4.9+dfsg1-1_all.deb
Files:
 7bc92be44a9b1b7f1245dc5a5a794a05 1956 python optional fdb_1.4.9+dfsg1-1.dsc
 3f9e6a19dbf000eb971c156ccfaa985a 605989 python optional 
fdb_1.4.9+dfsg1.orig.tar.gz
 8cb7e8ac7a10bdefc4b17d3a46da7d2a 4404 python optional 
fdb_1.4.9+dfsg1-1.debian.tar.xz
 bb495bde780c6a275d8df3a47cb2bf1a 185130 doc optional 
python-fdb-doc_1.4.9+dfsg1-1_all.deb
 5aeefe134224a3d9a0fc7a4e84d64cda 96446 python optional 
python-fdb_1.4.9+dfsg1-1_all.deb
 70dce713a1d6cf8250cf774b0f8fafc8 96354 python optional 
python3-fdb_1.4.9+dfsg1-1_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVcmefazUn4heVFJuAQpMMg/+IwcYNh45VsPWfKI0m7e8ArSYBarILdfO
IgeCnmjX1voGb9O7JF/eKi6S2ZQ7pI9habnhJJMi9DFoDdFBNPkv0dR2DYSi2nqI
9PWgkxidsqJkRwj12+K/ZNy0sdOAm+xzUx+3olX+aPbrlSGe4hWr2QRpG3K9DEu8
QPKoUQEYGsRHs8bMvBtDNzqxJANfOTZjLM3w84XhrSOWa0f9gqKDwrrIyrE/V319
tmwmQjC10vP23PObYVRQ+norgWo0lEV2M6z1+U9I3mh+H6u1QpwH+Sj/vRGQv/qC
P+eyYe/5Helb2WCjpVf5UJ4H4BGvwCJHPm3Y8ugZs3MxRIAK5LGhgoOVSAByr55Z
m2V+Dz9LuERa+367Ni8bjTM1BA3HTa5YOhLWTbXP54EF1iDxPOWc3SqAjfj8WG9e
zVCMuuQW1WZphcWDyKEpbuEcBzvvpfcFAeIsmsrkdOsK9Qdq+m/DeMFpJPLlBZnO
6hlKb1MY7g1XhtG09jvEWKicDjF9wsJmAUhc13QCo6zXaxIqlzcBQa7LqJyPnSzk
YUFiwesmSn79v5Gxem4P0Ab0DKgEzgjCvurVoQ7UMd5G5mnK3RdcSNAaicxn6Vj9
ErvVN2elv2sV65T0ncmiVxhS3no8xJdfaVTz5xJywdr6p1rNCbkAR0FbvCbYVLMI
R+8Ixg6MwvM=
=/X+T
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1zp5xv-0001ts...@franck.debian.org

Re: Metapackage dependencies: Depends or Recommends?

[Russell Stuart]

On Thu, 2015-07-30 at 08:57 +0200, David Kalnischkies wrote:
 This example makes it quite obvious that your requirements are keep
 a minimal set of packages installed while the requirement of libapt's
 autoremove is suggest only packages for removal which are completely
 safe to remove.

If Suggest only packages for removal which are completely safe to
remove  is supposed to be list all which are completely safe to
remove then it doesn't manage to do that either.  It fails given
circular references, ie A depends on B depends on C depends on A.

I guess it's designed for the cleanup packages I played with for a
short while on my laptop use case.  It does a sort of OK job at that.
Only sort of, because when you move across flag days the dregs left
libapt leaves behind can get it confused over which packages should
removed so the upgrade can proceed.

For my servers it's different.  The inherent ambiguity of Debian
dependency system that libapt tries hide becomes intolerable, meaning I
don't want something to just choose between the possibilities on my
behalf, I want to be informed so I can see the choices and have my
decision explicitly recorded to I can repeat it.  Leaving garbage
packages (think garbage as in garbage collector) lying around on
servers that are supposed to be clones left alone to maintain themselves
for a while is equally unacceptable.

In the end I gave up up on libapt and wrote my own dependency resolver.
Fortunately libapt makes that relatively easy because it's API gives you
access to all its internal working so you can re-use most of it.


signature.asc
Description: This is a digitally signed message part

Re: git and https

[Russell Stuart]

On Fri, 2015-05-29 at 22:21 +1000, Riley Baird wrote:
  LetsEncrypt will save us!
 
 I just looked that up. What a wonderful idea!

I don't know how you missed it.  My tongue has been hanging out for a
year now.  Finally, sanity prevails.

A https cert is supposed to certify www.someone.com is the person who
controls the servers managing www.someone.com.  Traditionally, the
certifiers have relied on business names, trademarks, directors names -
all sorts of things that have one thing in common - they don't actually
prove you control www.someone.com.  The more things unrelated to whether
you controlled www.someone.com they asked you to prove, the more they
charged for the certificate.  If you wanted an example of marketing
triumphing over engineering, the CA system is it.

LetsEncrypt is a pure embodiment of the you control it you own it
principle.

They could do better.  A lot better.  For example they could insist you
control www.someone.com for a while - say repeatedly confirm over a
month.  This would thwart the guy who took over www.hotmail.com for a
while [0].  And they could allow people to register an interest in
someon.com or someon.co, so if someone registered a cert with it they
would know.

Regardless, when LetsEncrypt works we will have made a step forward.



[0] 
http://news.cnet.com/Good-Samaritan-squashes-Hotmail-lapse/2100-1023_3-234907.html
Fortunately for Microsoft it was a Linux nutter.  When he couldn't
access his hotmail account he diagnosed it, registered the domain,
and then gave it back to Microsoft.



signature.asc
Description: This is a digitally signed message part

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Russell Stuart]

On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
 (I am shocked, shocked that there is no flood of people here rushing to 
 save ifupdown... :-) )

Until systemd-networkd can run scripts on events no defence is required.
It would be like comparing a calculator to a computer.  Sure, the
calculator is simple and lightweight, but there are some things you just
can't do with a calculator.

Right now systemd-networkd looks like a wasted opportunity - maybe it's
work in progress.  It has some wonderful pattern matching stuff but once
it matches the pattern ... there is very little you can do.  All the
dependency processing packaged with systemd.unit is oddly missing.


signature.asc
Description: This is a digitally signed message part

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Russell Stuart]

On Wed, 2015-05-27 at 19:27 +0800, Paul Wise wrote:
 Your mail is missing some things:
 
 To: 786...@bugs.debian.org
 Control: retitle -1 ITA: ifupdown -- high level tools to configure
 network interfaces
 Control: owner -1 !

If you mean it has been orphaned, it will work for while yet even if it
is unmaintained.  As the bug notes:

In current state ifupdown is probably good enough for what it is
used for

That's an understatement.  It's plugin based architecture that makes it
such a flexible tool for sysadmin's has also meant it's been able to
adapt to newer technology for 15 years now.  So there is no rush.

I agree there is room for improvement.  Systemd-networkd's pattern
matching make ifupdown's mapping look like a hack, it lacks any
dependency processing, I suspect the shell script's architecture
responsible for it's flexibility is also responsible for it's bugs and
it only provides tools for address assignment - other tasks like
firewalls and traffic control aren't there.

But they aren't there in the proposed replacements either, so we are a
long way from having a new solution.  Fortunately we have do time.


signature.asc
Description: This is a digitally signed message part

Re: Proposal: enable stateless persistant network interface names

[Russell Stuart]

On Wed, 2015-05-13 at 17:16 +0200, Vincent Lefevre wrote:
 Well, having some of the network traffic (more precisely, connections
 to machines that have an IPv6 address) re-routed to some unknown
 machine on the local network is not a nice feature.
 
 IMHO, such a feature should be enabled only by the network management
 system, not by default at the kernel level.

Now I've looked up what Marc is referring to in an earlier reply, SLAAC
and DHCP look pretty similar to me.  Both have the re-route your NIC to
some unknown machine feature.  I'm sure everybody here will be the
victim of a rouge router sending NDP responses, just as everybody has
already been the victim of a rouge DHCP server.

Not having the automatically make my NIC usable on bootup feature
enabled by default would seem like a major omission to me.

The one difference between the two right now is dhclient make it easy
for the client to watch for changes using scripts.  AFAICT, there is no
off the shelf way of doing it for SLAAC.  It's easy enough to do - just
have a daemon listen to kernel netlink messages and fire off a script.
The right place to put that now would be in systemd, but if they are
opposed to scripts as Marc says that ain't going to happen.  Sigh.


signature.asc
Description: This is a digitally signed message part

Re: Proposal: enable stateless persistant network interface names

[Russell Stuart]

On Mon, 2015-05-11 at 09:29 +0200, Marc Haber wrote:
 For example, it doesn't know dependencies between Interfaces, which is
 rather common for a server jockey (consider a VLAN on a bridge which
 is connected to the network via a bonding device)

I haven't had to solve that example, but I have had a problem again
involving bridges that sounds similar.  It was solvable with ifup/down -
by calling ifup in the /etc/network/interfaces pre-up.  I'll grant you
it's not pretty, but I've only had to do it once so I forgive aj.


 [ifupdown] it doesn't handle IP addresses that come and go
 at run time (as it is to be expected on IPv6 networks).

Could you explain when IPv6 addresses come and go?  You are talking to a
IPv6 neophyte here.  In the IPv4 world addresses handed out by DHCP do
come and go.  It's true that isn't handled by ifupdown, but that's not a
problem because if you want to do something about it, you do it in the
dhclient hook.  It seems the right place to me.

That aside, I don't see anything in man systemd.network that allows
you to watch for IPv6 addresses coming and going, or for that matter
anything else coming and going except devices.

 And, when it comes to scriptability and flexiblity, systemd-networkd
 is vastly superior. It was made with a server in mind.

This para is the real reason I'm responding.  I must be missing
something, because nowhere in man systemd.network do I see to a way to
run a script of any sort.  For me the acid test is can it do totally
manual configuration, ie the equivalent of ifupdown's manual method.
(I occasionally use manual - it's a great way of ensuring there are no
surprises.)  systemd.network's [Match] section combined with the sort of
demonstrated by ifupdown's manual method would be a match made in
heaven.  But if it exists I've missed it.  You could perhaps emulate it
if it were possible to make a systemd.service depend on a
systemd.network, but that appears to be right out of scope.  As it
stands, networkd looks to be one of the least scriptable networking
configuration options I've seen since ... oh redhat 7.0 or so.

 Otoh, it is much harder to debug, extend and modify than ifupdown,
 which has a _very_ flexible script interface.

Up until recently I thought the systemd mob had solved the visibility
problem by logging everything written to stdout and stderr with
journald.  I was disabused of that notion just this weekend, when
apache2 failed to start after an apt-get dist-upgrade.  journalctl -xn
helpfully told me:

$ ssu journalctl -xn
-- Logs begin at Mon 2015-05-11 21:16:17 AEST, end at Mon 2015-05-11 
22:22:42 AEST. --
May 11 22:21:43 russell-laptop systemd[1]: apache2.service: control 
process exited, code=exited stat
May 11 22:21:43 russell-laptop systemd[1]: Failed to start LSB: Apache2 
web server.
-- Subject: Unit apache2.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit apache2.service has failed.
-- 
-- The result is failed.

Which is about as useful as a hip pocket in a singlet.  In the end this
told me what was going on:

$ _SYSTEMCTL_SKIP_REDIRECT=true /etc/init.d/apache2 start
[FAIL] Starting web server: apache2 failed!
[warn] The apache2 configtest failed. ... (warning).
Output of config test was:
apache2: Syntax error on line 141 of /etc/apache2/apache2.conf: Could 
not open configuration file /etc/apache2/mods-enabled/php5_cgi.conf: No such 
file or directory
Action 'configtest' failed.
The Apache error log may have more information.

Having to troll through scripts in /var/lib/lsb in order to figure out
how to disable the systemd redirect in order to see the error message
the sysV init script sent to stdout is NOT an improvement.  (The Apache
error log was empty.)

If debugging networkd stuff is harder, then ... *shudder*.


signature.asc
Description: This is a digitally signed message part

Re: Proposal: enable stateless persistant network interface names

[Russell Stuart]

On Sun, 2015-05-10 at 17:11 +0200, Vincent Bernat wrote:
 The disease is that actual servers running actual free software can
 break at each boot because we cannot have both a persistent naming
 scheme and use the eth* prefix is worse that the cure because old
 versions of Novell ZENworks may stop to work on upgrade?

Speaking as someone who runs Debian on his servers and laptop, I don't
care about what you guys choose.

I don't care on the laptop mostly because of the reasons Josh Triplet
pointed out earlier.  I manage the network through GUI interfaces, and
it doesn't care what the interfaces are called.

For servers the interfaces are all assigned fixed, well known names.
The reason is their configuration is completely automated through 100's
of scripts.  In all instances I've seen it done like this well known
interface names are used.  It's not difficult to understand why if
you've done it - you can sort out what NIC is supposed to be doing at
install or boot up and rename it accordingly, or you can do it in every
script that deals with the network.  The choice is obvious.

You have the disease wrong.  These scripts have been around for over a
decade.  In that time various fashions in interface naming have come and
gone.  This is yet another one.  The disease isn't the kernel choosing
different names on boot up, it's people inventing new interface naming
schemes every few years, just as being done here.  Everyone who has had
to support many servers over a long period gets sick of this and writes
yet another script that does in the renaming in the way they want, in a
way that will be stable forever more.  Thus they don't care what choice
is made here - as they have already given up relying on Debian to do it,
because Debian isn't stable enough.

That said when writing our own scripts most of us long ago came to the
conclusion the bus path to the interface was the most useful way to
identify it.  Again the reason is straight forward - if you have an
image tuned for a piece of hardware that you have deployed en-masse the
one thing that is the same on all of them is the paths to the NIC's.
Note that when, long ago, the kernels actually managed to repeatability
name the NIC's eth0, eth1 etc, it was because the buses were enumerated
in a repeatable order so the NIC's got seen in a repeatable order.  So
in effect the name was determined by the bus path.  Ergo, nothing has
changed in 20 years.

I get the distinct feeling some people posting here consider ifup/down
old fashioned.  Granted it doesn't have a nice GUI, but from the point
of view of someone who deploys lots of similar machines a GUI of any
sort is a negative, and it has a far nicer property - it is easily
scriptable.  In fact underneath the hood it's driven by scripts.  If
there is a network configuration it isn't capable of setting up, I
haven't seen it.  In my very brief look at networkd it didn't provide
anything like the same amount of flexibility.


signature.asc
Description: This is a digitally signed message part

Re: debian github organization ?

[Russell Stuart]

First a Mel Cupa.  I called the SourceForge system Apollo.  It's actual
name is Apache Allura.  Brain fart.

On Thu, 2015-04-16 at 23:13 -0700, Russ Allbery wrote:
 Er, they did, didn't they?  I could have sworn that they only supported
 CVS initially, and then only added Subversion, and getting Git support
 took forever.

Pretty much.  Of course that may have something do with the respective
VCS being born in that order.  For comparison in the speed of addition,
GutHub opened for business in April 2008.  SourceForge added support for
git in March 2009.

 However, I still stand by the decision to only support a single VCS, at
 least when you start, because you can move a lot faster and implement a
 lot more functionality that people care a great deal about.

Woo, slow down there.  Here I was thinking the discussion was about
spinning up a server using exist software.  Has the discussion moved to
writing our own or even modifying something to suit Debian's needs?  If
so, is that justified by history?  Was there a period when not only was
Alioth's bug queue serviced, but we actually did some heavy lifting?  If
not than any discussion of adding functionality is probably fanciful.

In any case using an existing project and contributing any changes
upstream sounds like a much better plan to me - particularly if the
project is packaged in Debian.  They means we can just install auto
upgrades to keep it secure.

As for one DVCS to rule the world - that also sounds like a bit of a
stretch.  If we are going to do that, can we also settle on a preferred
computer language and force everyone to use a single debian packaging
method?  It would make life sooo much easier.


signature.asc
Description: This is a digitally signed message part

Re: debian github organization ?

[Russell Stuart]

On Thu, 2015-04-16 at 19:37 +0200, Sven Bartscher wrote:
 On Thu, 16 Apr 2015 09:04:07 -0600
 Dimitri John Ledkov x...@debian.org wrote:
 
  I'd rather see gitlab.debian.net :)
 
 I don't  a reason to have gitlab/github/someother git stuff for debian,
 since we already have alioth.
 Maybe someone can enlighten me.

Probably not.  UI's are a personal thing and if you've looked at the
others and still the UI provided by FusionForge, that's unlikely to
change.

But do acknowledge that makes you unusual.  Github has all but
annihilated SourceForge in the hosting market place, and the stand out
change is it's UI.  That is in spite of SourceForge's impressive mirror
network and SourceForge being VCS agnostic.  So it's not surprising some
DD's want to move away from the FusionForge UI.

I'm on SourceForge now.  [0]  I'd prefer to be on Debian's
infrastructure of course, but Alioth is so poorly maintained it was
unusable for me [1].

Of the suggestions so far only Kallithea is VCS agnostic, but Kallithea
only supports source code hosting - no Ticketing (eg bug tracking), no
web project web page, no release hosting (binaries).  Maybe that's an
advantage for Debian projects because it forces you to use Debian's
existing infrastructure for everything else, but for me it makes it a
no-go.

Gogs looks to be similar, but is unstable.  Gitlab is git only and
doesn't support releases.

SourceForge's Apollo is an open source project supporting all those
features plus a heap more, but the UI is not code centric like the
others - it feels more like FusionForge.  That said, unlike FusionForge
modern work flows (forking, pull requests and the like) - it's just they
aren't a prominent in the UI.



[0]  http://sourceforge.net/u/rstuart/

[1]  https://lists.debian.org/debian-devel/2014/05/msg00463.html

 That triggered this response, but it read like someone in denial
 rather than acknowledging the problem:

 https://lists.debian.org/debian-devel/2014/06/msg00435.html

 Acknowledging the problem is always the first step in fixing it,
 and I think it's significant the number of open bugs has gone up by
 20% since then.



signature.asc
Description: This is a digitally signed message part

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Russell Stuart]

On Wed, 2015-01-21 at 21:10 -0500, Michael Gilbert wrote:
 So anyway, nn-subscribe can be used to spam confirmation messages
 currently, and general mail to the bts from an unknown address will
 end up doing the same, but it's basically a non-issue because it's a
 rather uninteresting thing to do for anyone that might consider
 wanting to do it.

I don't know how interesting it would be on an absolute scale, it
certainly would be more interesting than it is now if we remove the
authentication we have.

The reason is all that happens now is you get one unwanted email and
that is the end of it.  In particular the attacker can't force you do to
something to prevent the bugs.debian.org from sending further unwanted
emails.  If you get rid of authentication then the victim, be it you, or
your mother, or your local police constable, will have to tell the
Debian bugs system to unsubscribe them from a list they never subscribed
to in the first place.

Perhaps you can suggest a way of explaining the situation to our mothers
or local law enforcement agents so they don't end up blaming the Debian
bugs system for putting them in this predicament.  I struggling to come
up with something they would swallow once they learn we could have
designed the system to avoid it, but chose not to because we found it
convenient to inconvenience them.


signature.asc
Description: This is a digitally signed message part

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Russell Stuart]

On Mon, 2015-01-19 at 16:57 -0500, Michael Gilbert wrote:
 Isn't the spam vector already wide open for
 nn-subscr...@bugs.debian.org, which isn't much (ab)used today?
 
 I fail to see how any of the discussed changes open an abuse vector
 that doesn't already exist.

OK, so let me help you see.

The vector you are pointing to doesn't exist.  You can _not_ subscribe
to a bug by sending email to -subscr...@bugs.debian.org.  You
subscribe to a bug by sending an email to an address that looks like
this:

  
701234-subyes-8aba1368a9ac33362ea1f68c28446c15-65bf3bd3886fb8abfe59d40709c84...@bugs.debian.org

I presume this invite address is unforgeable (because Ian Jackson's
expertise is in crypto, and he said earlier he designed the system).

Sending an email to -subscr...@bugs.debian.org just asks the system
to send an invite containing such an address to someone.  I'm not sure
what email address gets the invite - it could be the envelope MAIL FROM,
or the Reply-To, or the From.  But really who doesn't matter.  All the
matters is the only a person controlling an email address is able to
subscribe it to a bug, not some random noob.

For what it's worth, the invitation contains full text of the
subscription request, including all the RFC5322 headers.  If it was
someone doing something unpleasant it gives you some hope of tracking
them down, or blocking them.

In other words the current system contains robust defences against such
an attack.  All I (and I presume Ben) are saying is removing those
defences is not a good idea, given it's easy enough to design a system
that keeps them.  Currently most of the auto subscription proposals
appearing here do remove them.


signature.asc
Description: This is a digitally signed message part

Re: Who gets an email when with bugreports [was: Re: Unauthorised activity surrounding tbb package]

[Russell Stuart]

On Mon, 2015-01-19 at 10:03 +0100, Tomas Pospisek wrote:
 Am 19.01.2015 um 02:03 schrieb Ben Hutchings:
  No, this would turn the BTS into a (worse) spam vector.
  
  But the acknowledgement mail should tell you how to subscribe, if you
  aren't already subscribed.
 
 But isn't subscribing participants natural?

It may be natural, but IMO you are underestimating the spam vector
problem.

Debian's bug submission mechanism does not try to verify you control the
email address you are submitting from.  Most other bug tracking systems
do such authentication, usually by requiring you to create an account.
Since there is no verification it becomes trivial to sign someone up to
1000's of bugs using a script.

Treating every bug submission as a subscribe request (by putting a
subscribe link in the ack) is one compromise. (I am sort of surprised
that doesn't happen already.)  Automatically subscribing a DD to any bug
he sends a signed message to is another.

I am partial to the latter, even though it is a partial solution.  It
encourages DD to sign their bug reports.  IMHO anything we can do to
encourage DD's to sign their emails to the project improves our
security.


signature.asc
Description: This is a digitally signed message part

Re: policy regarding redistributable binary files in upstream tarballs

[Russell Stuart]

On Fri, 2014-11-21 at 17:39 +0800, Paul Wise wrote:
 On Fri, Nov 21, 2014 at 5:25 PM, Matthias Urlichs wrote:
 
  These days, they might just push their repo to github and let its machinery
  generate the tarballs, which TTBOMK aren't guaranteed to be 1:1 identical to
  another tarball of the same commit that's downloaded a week later. Or a
  year.
 
 I tried downloading a tarball just now and got identical results. I
 guess they are just using git archive, which produces identical
 results for me too.
 
 https://github.com/whohas/whohas/archive/0.29.tar.gz

It doesn't matter whether git supplies a tool that provides reproducible
tar balls.  If there was a target in debian/rules responsible for it
something like this would work:

pristine-source:
rm -rf debian/pristine-source.tmp
mkdir debian/pristine-source.tmp
git clone http://... debian/pristine-source.tmp
cd debian/pristine-source.tmp  \
  git checkout $(get commitish from debian/changelog somehow)
dpkg-pristine-source --format=git pristine-source.tmp

The spec for dpkg-pristine-source is roughly:

- Inputs: source directory(s) and their formats.
- Outputs:
 .orig.tar, and
 hashes written to debian/pristine-source.hashes

Which is not what I said before, but this is WIP.

Now that I think about if dpkg-pristine-source is possibly an overkill.
Any repeatable process would do.  Even:

  find debian/pristine-source.tmp \
-path debian/pristine-source.tmp/.git -prune ! -type d | \
LANG=C sort debian/x
  cpio -o -H ustar debian/x | \
gzip -9 ../$(sed 's/\(.*\) (\(.*\).*/\1_\2/;q' 
debian/changelog).orig.tar.gz
  rm -f debian/pristine-source.hashes
  xargs -d '\n'  debian/x cat | sha256sum | \
sed s/-/URL/ debian/pristine-source_sha256.hash

All of the above was written after a couple of glasses of wine and has
never been tested.  Regardless, I hope is demonstrates the point: it is
possible to compute a immutable hash if upstream provides a
reproduceable way to retrieve the same sources.  As far as I know every
SCM post CVS does. 

That was a statement of the obvious I guess.  But it show what I am
proposing is not pie-in-the-sky.  It's achievable, and not even that
hard.


signature.asc
Description: This is a digitally signed message part

Re: policy regarding redistributable binary files in upstream tarballs

[Russell Stuart]

On Thu, 2014-11-20 at 13:46 +0800, Paul Wise wrote:
 On Thu, Nov 20, 2014 at 1:14 PM, Ben Finney wrote:
 
  But a growing number of upstreams disagree, so those upstreams are
  likely to be actively opposed to your recommendation to patches 
  which remove non-source files from the VCS repository.
 
 I wonder about the basis for that disagreement.

In the GNU model the tarball doesn't just provide sources.  It is a
complete packaging system.  It checks for build prerequisites, does the
build, checks for install prerequisites, does the install, and does
uninstall.  It does all that because upstream wants people to use their
project - regardless of whether their distro packages it.  Combine that
with wanting to keep the perquisite list small including things like
minified jquery libraries is exactly the right thing to do.

 Putting all third-party libraries into a separate place (tarball,
 repo, branch or dir).
 
 Putting all pre-built files into a separate place (tarball, repo,
 branch or dir).

Those suggestions may make things easier for Debian, but they do so by
making life harder for upstream's other users.  That isn't going to
happen, or at least for me it wouldn't.  If my DD alter ego asked my
upstream ego to make things much harder for his other users, he would be
politely told where he could shove his suggestion.

Personally, I think Debian passing judgement on what is upstream
pristine tarballs is over the top.  It's upstream's original work, not
Debian's.  Ideally we are just mirroring it.  (That we often aren't is
part of the problem.)  We should be happy enough to accept their
assurances on having obtained whatever licenses they need for what is in
them. [0]

Admittedly this meshes well with my experience that they are often
fairly lax about what they put in those tarballs.  Their make
distclean scripts are often not as good as they could be, which means
all sorts of crap it left lying around. Vim .swp files and compiler
intermediates spring to mind.  I have no idea what license would apply
to a .swp file, but I do know that for all practical purposes it doesn't
matter and I'd rather Debian didn't insist I find out. [1]

That's just me being lazy I guess.  But there is a deeper issue.  For me
it is vital there be an audit trail from the pristine upstream tar ball
to the binaries we distribute. [2]  In pursuing licensing purity we have
been gradually destroying what little of that audit trail we used to
provide.  To put it bluntly: as a DD I do care about licensing, but when
it comes to day job where I have to ensure hundreds of computers are
reliable and secure so the licensing of of tarballs I don't download let
alone use takes a distant second place to security.  So in my view we
are making life difficult for our users on the altar of FSF style
idealism.

Maybe if we were forced to choose between the two that would be right
choice to make.  But technically there are a ways to be FSF idealists
and provide something akin to an audit trail.  So we aren't forced to
choose - but we just deprive our users of the audit trail anyway.  That
is bad.

What follows is something I am sure has been covered before by someone
somewhere, before I started following the project in earnest.  I can't
find it - so I apologise in advance for the repetition.

I start my Linux life as a RedHat user, and I wrote RPM packages for my
own use.  Then about a decade ago I moved to Debian, and of course
started writing Debian packages.  During the transition I was struck by
how much better Debian's binary packaging was compared to RPM, and yet
RPM's source packaging was so much better than Debian's.

To explain why I'll step back a bit.  If I were writing a book on how to
design a packaging system it would start by introducing these 5 steps:

A.  The process is ideally [3] a pure function.  It's input is the
pristine source.  It's output is the binary packages.  So the 1st
step is to obtain the input - the pristine source, and record it
in the output so anyone else can reproduce what you have done.

B.  These inputs are fed to packaging process a program, written by the
packager, that implements the function doing the transformation.
In debian, this is debian/rules.  This function is split into
standardised steps.  The second step is unpacking sources from
whatever format they are in into a build directory. [4]

C.  The third step is to tailor the pristine sources to match the
requirements of the distribution.  This is done in a standardised
way: by applying a series of patches in a well defined format, each
with a clearly documented purpose.

D.  Run the build process as supplied by upstream, but perhaps modified
by step (C).

E.  Collecting the output of the build process into binary packages. [5]

And that is exactly what RPM's did over a decade ago.  Debian mashed
steps (A), (B) and (C) into what could only be described as a mess.

Time has moved on, and things have changed.  

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

[Russell Stuart]

On Thu, 2014-10-30 at 01:40 -0400, Michael Gilbert wrote:
 There are also end-of-life announcements, which maybe the
 debian-security-support package now addresses in a somewhat automated
 fashion.

I wasn't aware of that.  Thanks.

 Anyway, it is entirely understandable that reading can be hard, but at
 a minimum the truly security-conscious need to be to do so.

Yes, fine.  But a truly security conscious distribution doesn't depend
on its users being truly security conscious.

And on that note, I applaud the Debian Security Team for  demonstrating
their awareness of this by releasing debian-security-support.


signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Thu, 2014-10-30 at 16:06 +0100, Wouter Verhelst wrote:
 On Thu, Oct 30, 2014 at 03:59:33PM +1000, Russell Stuart wrote:
  Yes, fine.  But a truly security conscious distribution doesn't depend
  on its users being truly security conscious.
 
 I would hope Debian never becomes a truly security conscious
 distribution by that definition. It implies the distribution thinks it
 knows better than its users what the right security trade-off is, and
 that way lies disaster.

You are reading way too much into it.  It's meant to express something
uncontroversial.

There is the spectrum ranging from: The default install priorities
should be (...put your fetishes here - eye candy, small, have
everything, [not] run systemd...).  If the user wants security they can
customise it later.  To: The default install should be as secure as
possible.  If the user wants to weaken that in favour of (...put your
fetishes here...), they can customise the system later.  IMO, on the
spectrum Debian must be heavily biased towards favouring security.

So it just expresses what I presume to be the consensus.  As such I
really should not have wasted your time by writing it, but there was an
element of conceit involved - I was taken with the turn of phrase.


signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Wed, 2014-10-29 at 19:39 -0700, Russ Allbery wrote:
 But we shouldn't confuse that with the right way to check 
 for security updates for Debian systems.  People who
 care about security updates need to be subscribed to
 debian-security-announce and reading the DSAs.

If there are two ways and one requires a human and the other is
completely automatic, all other things being equal for me the right
way is the automated one.  I know my limitations - not being
conscientious when doing manual repetitive labour is one of them.

 It seems to me that if you want to lower the chances of a downgrade attack
 for your systems, setting the validity period on your systems is exactly
 the tool that you need.  There's no need for anything to change on the
 server side for you to get that protection.

Yes, I agree.  But for me apt.conf/Max-ValidTime is useless unless the
release file is guaranteed to be updated more frequently than its
Valid-Until: header implies.  Is it, and is that undertaking
documented somewhere?


signature.asc
Description: This is a digitally signed message part

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

[Russell Stuart]

On Wed, 2014-10-29 at 21:58 -0700, Russ Allbery wrote:
 Also, this means that you completely miss security advisories that *don't*
 involve changing a package in the archive, like this thing is a disaster,
 so we're pulling it from the archive entirely and suggest you stop using
 it.

If it is so that much of a disaster that it warrants pulling a package
from stable, surely a little more notification than an email to a list
most people don't monitor would be warranted?  Something like replacing
it with an package that sends email daily to root explaining the
situation would be the very least you could do.

But then the bash function bug made my local TV news, and bash remains
in the archive.  If it warranted pulling a package from stable I'd wager
you would have to be living under a rock not to hear about it.


signature.asc
Description: This is a digitally signed message part

Re: GPL-3 openssl: provide a -nossl variant for a library

[Russell Stuart]

On Thu, 2014-10-23 at 12:46 +1100, Brian May wrote:
 On 23 October 2014 04:03, Russ Allbery r...@debian.org wrote:
 It's usually more immediately useful to just
 upload the package with an explanation of the issues in
 debian/copyright
 and see what the ftp-master team says.
 
 
 This is probably getting off-track, however I have a package that has
 been stuck in NEW for over a month because ftp-master won't give
 feedback on what they see as a legal issue with my package. I
 disagreed with their verdict, gave good reasons, indicated that
 another package already in Debian would have the same issues, and got
 no response.

Yeah, that's been my experience too.  I waited a week for a reply, but
none was forthcoming.  I took that as a no.  They are busy people
after all, and probably don't have time to engage in what could be long
discussions.  Particularly now when everyone is rushing to get in before
the freeze.

I wasn't happy at the time, but in retrospect it seems like a reasonable
process to me.  I assume they are consistent as they can be, so their
decisions reflect Debian's current consensus (written or otherwise) on
what is allowed into Debian.  If you disagree strongly enough to want a
debate that changes it, that debate should be held here on debian-devel
where everyone can participate.

You don't need a debate or a reply to reach a compromise - just
re-submit with your compromises.  It has the advantage of forcing them
to give you an answer :D.  If you aren't prepared to compromise, either
have the debate or drop the package.



signature.asc
Description: This is a digitally signed message part

Accepted fdb 1.4.1+dfsg1-4 (source all) into unstable, unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 22 Oct 2014 08:50:10 +1000
Source: fdb
Binary: python-fdb python3-fdb python-fdb-doc
Architecture: source all
Version: 1.4.1+dfsg1-4
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart russell-deb...@stuart.id.au
Changed-By: Russell Stuart russell-deb...@stuart.id.au
Description:
 python-fdb - Python2 DB-API driver for Firebird
 python-fdb-doc - Python DB-API driver for Firebird documentation
 python3-fdb - Python3 DB-API driver for Firebird
Changes:
 fdb (1.4.1+dfsg1-4) unstable; urgency=low
 .
   * debian/copyright: acknowledge BSD license for
 sphinx/fdbtheme/static/epub.css and
 sphinx/fdbtheme/static/fdbtheme.css_t
   * Rename repacked .orig.tar to show files have been
 removed.
Checksums-Sha1:
 ce27dff9a00ce4e6b1e053ff312badd55a382bf5 1983 fdb_1.4.1+dfsg1-4.dsc
 e86a328f0a2358ceea9c283100ee8b5c6805aa5c 597026 fdb_1.4.1+dfsg1.orig.tar.gz
 0342bda1317232858fbcf1cdba6deb38e5979d9c 4360 fdb_1.4.1+dfsg1-4.debian.tar.xz
 8ba3348c1b43998a227fbaec693d7f9024a5d9fb 96258 python-fdb_1.4.1+dfsg1-4_all.deb
 3518938bb50f25e631d082e495c11579437794ac 96176 
python3-fdb_1.4.1+dfsg1-4_all.deb
 19d6a710c9f1d3696e908544d41c00e47f4c22f1 184244 
python-fdb-doc_1.4.1+dfsg1-4_all.deb
Checksums-Sha256:
 3897e8597db896359ef2d5c3be0e446da499af8aa6b565c820e9852323a1247b 1983 
fdb_1.4.1+dfsg1-4.dsc
 34a1db241cb9dc04207790b9c0a4b9ff868a5607965878b7ff693788dea29408 597026 
fdb_1.4.1+dfsg1.orig.tar.gz
 0a727035c131984f4eecc6a02f0a15d0a0efcb7bed81fafd83ff545b26aa 4360 
fdb_1.4.1+dfsg1-4.debian.tar.xz
 ec75c070735412a63a666001b6ae88893a933da418e7c8eb74799c026bdb2ce1 96258 
python-fdb_1.4.1+dfsg1-4_all.deb
 0a016c1c5b2bdbdbf79c4d2e634c83a3220520f1375b5d5465b76d2b688bace8 96176 
python3-fdb_1.4.1+dfsg1-4_all.deb
 9e0e9058ed6f9dc8db83077c1620ae1c916720a8c6829fa98974e640e413496d 184244 
python-fdb-doc_1.4.1+dfsg1-4_all.deb
Files:
 e3957e2992ee7de6ac254500b418f1ef 96258 python optional 
python-fdb_1.4.1+dfsg1-4_all.deb
 13ea9fc49703594deb978bcac7e0fa89 96176 python optional 
python3-fdb_1.4.1+dfsg1-4_all.deb
 11c9d1af6273ce1bef120a771789a634 184244 doc optional 
python-fdb-doc_1.4.1+dfsg1-4_all.deb
 db50233cc4a99d034938bb24f7815657 1983 python optional fdb_1.4.1+dfsg1-4.dsc
 9725fcef1d31a9b29fb90d1ee6c538c7 597026 python optional 
fdb_1.4.1+dfsg1.orig.tar.gz
 156b73a1e28cc62454a3d9a3c5067f5e 4360 python optional 
fdb_1.4.1+dfsg1-4.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVEblMazUn4heVFJuAQpT6A//dZQUVOLcVSGhbdfGp0uUYYdMxyqGQr9J
asTPhlCqrQlQ4lb+na4EQXYKSgU46iOILuZOQ9K3KnbRySiAw/ECUvIPv2aiTgaZ
tXD6KAboYG7cfuCog7KGvh3kc+EjHGmwlm96hWfLrvc4Nhl4UMX3g6ubH48S43JB
Lu45p8VllcZk+Trt4ENqerWnPQlWNUkUdNbjyPTD3mCcmE4MM9XVwr7no60ASb5M
S2gxwzHvnYSV8kyslySBLwd82Rtiy1CQHqRv6mhgPEFobZpzMGx4CpF0Zqc7EGV9
24EVHC2YJAJ+VeCdRSa/gVSbG5C4HlMeRWq+tABXNSsD1uSe43TPpgX0pm0yXs0o
a/IXyMX9VyzeIOtDtncB70NdNUGfX1WzbJKhVF2ZA71qDj2ydhk4yeiFAfBPKMVM
OHHnbl+qU5lb4/ePIpWsVUwqIR85cfyUQsfzhS6/bse1CKhGOrb5KM3M0pXNPxqH
7PCDiy/SG+JQh23mYyT5SqCvfxsjnAxrqkJNf8JLFE1HV0cfKLMDWh5Ehji67omV
RlpZQGbpJbSnovqxUiD2myRya5UtUTi7+P8pk3Jznijpj7pN9fCHqlxFU/AEzsnL
lIOhSxbX1vmvp+2Zo57rOw6fjlWte4Mn252m/HV3KUFSBYq9hhvETzPxofaour4d
Rdaso4dHtMU=
=+2Sd
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xgykz-0001sn...@franck.debian.org

Accepted smstools 3.1.15-1.1 (source amd64) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu,  9 Oct 2014 17:07:32 +1000
Source: smstools
Binary: smstools
Architecture: source amd64
Version: 3.1.15-1.1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart russell-deb...@stuart.id.au
Changed-By: Russell Stuart russell-deb...@stuart.id.au
Description:
 smstools   - SMS server tools for GSM modems
Closes: 750350
Changes:
 smstools (3.1.15-1.1) unstable; urgency=low
 .
   * NMU - preventing smstools from entering jessie.
   * Fix syntax error in src/Makefile, override in wrong place.
 debian/patches/fix-makefile-override.patch
 (Closes: #750350)
Checksums-Sha1:
 c94c10ce6716db058e8574d6ce04aeb076e2d551 1892 smstools_3.1.15-1.1.dsc
 8b9d6e1d94479a17056751aa0288f87a48cf6062 297100 smstools_3.1.15.orig.tar.gz
 9adce3c545052e65aedf403fd0a8153765fad2e2 33918 smstools_3.1.15-1.1.diff.gz
 f6fbc626679ef3c78dfcb658b35d8074b2b33c3f 274278 smstools_3.1.15-1.1_amd64.deb
Checksums-Sha256:
 61133c177384697fd03c321a918c12eb89e58966fcc4883c06336f4a982b382f 1892 
smstools_3.1.15-1.1.dsc
 2421813279ad7d0f2125cd4a3e5f3fabb53dd50b669e5c188f78f8ec2f1b8fbc 297100 
smstools_3.1.15.orig.tar.gz
 905e317c700aa2acbc018dec8bfaf6702e499f0caac490ceb912e0bf027deb7c 33918 
smstools_3.1.15-1.1.diff.gz
 7df9fd039895058ca61bd4d408c7bdfa4ce9f71c4a6cfe669466d4cf2e2455b3 274278 
smstools_3.1.15-1.1_amd64.deb
Files:
 737379d61fa62544fb88040206204f39 274278 comm optional 
smstools_3.1.15-1.1_amd64.deb
 587965bb0027b92323dbffb788c6ed58 1892 comm optional smstools_3.1.15-1.1.dsc
 8147bbbe6fe85408dc2ed9d292cc240e 297100 comm optional 
smstools_3.1.15.orig.tar.gz
 e360455943ccfffb124ac96bee0bb676 33918 comm optional 
smstools_3.1.15-1.1.diff.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVDY74azUn4heVFJuAQol0g/+JxhmgrSGsvaVGKXjD+S9Af4+H9ZuIvas
YYfJF9qE3BCNubYls32+bP3VqIMpk9koZSrFEC5WxTZQ+z4+gNcOQ14fvsdYPV4X
CwEl7i43LD3DMA8rUxcJSiKrIoVfMULI3DfxxkA6dCr6lc4xlws5s+PzbYiNI27P
C47uzhBK8Z9r11IlpF80VwAZ4ryOzE8C6K9Fe9bsqsOPzJhiGT657kw+YG3zQmfb
PNT0hSrvqGH6p+mskmJ8A6hlEEyZVQf/SPVK1C9rJrvuvYhiP6AbjkQgAjFPImut
WhxH12Z9VtGNWorWPfcjFSzoONmMGWDJrjy+JwLYNklfZu/LcTY95COdWmRY5UYx
/drg4Sh/Uxnrd/fcztyILWdQIhfg4sD1uRH0A1y7wc0eHbwcfHG7w/ItVo4SI5iu
NyHXoRAElGCT/Nb7WJ0OmZGH1cjx8uMvDuL7WSGyjCIIXQq16BWQwuh2S+nyGXWl
ZfLGRN6W9ym2LampiI7NgUIyFVJXOP2tMkorY9r7qB1MGYM7km02ov/CAjYVNlwa
TF30QRgGu5/178wRpK/hDnsp94N7/xqmutLSBuVhr7Xk7gd08JftzywEnKQw+iJe
GbBo4y9EG6n6XTjhm3/JJKiEWuC2abhfcIehBfZ2r5tft5a98wPdaCH7W5lFYD1K
u/RAknlscms=
=vB3Z
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xg4xs-0007vz...@franck.debian.org

Re: bash exorcism experiment ('bug' 762923 763012)

[Russell Stuart]

On Wed, 2014-10-15 at 23:36 +0100, Ian Jackson wrote:
 Actually, the problem is indeed in policy.  In its resolution of
 #539158 the TC decided unanimously (but unfortunately slightly
 implicitly) that printf ought to be provided by our /bin/sh.

 Unfortunately the policy has not been properly clarified.  This leaves
 us in the somewhat unsatisfactory situation where our real
 compatibility requirement is de facto rather than de jure.
 
 As the maintainer of a minority shell, Thorsten has the most interest
 in regularising this.  Perhaps Thorsten would like to propose a
 suitable policy wording (with a view to changing posh to match).
 
 Obviously that wording ought to be consistent with the TC's decision
 in #539158 - ie, it should specify printf as a builtin.

The arguments about printf in #539158 also applies to '['.  POSIX does
not say '[' must be a built in (in POSIX's terminology is part of the
'Special Built-In Utilities').  Thus if the shell didn't implement '['
udev would fail since uses [ and sets PATH to be /bin:/sbin.

The reality is in a POSIX (or a minimal Policy 10.4) world shell scripts
must have access to bulk of the stuff that is both covered in the man1p
pages and is required in Debian.  Turns out only three commands fall
into that category: [, printf, and test.

And yes, to me the obvious fix is say in policy /bin/sh have those
commands as builtins.


signature.asc
Description: This is a digitally signed message part

Accepted roundcube 0.9.5+dfsg1-4.1 (source all) into unstable

[Russell Stuart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 15 Oct 2014 09:51:17 +1000
Source: roundcube
Binary: roundcube-core roundcube roundcube-mysql roundcube-pgsql 
roundcube-sqlite3 roundcube-plugins
Architecture: source all
Version: 0.9.5+dfsg1-4.1
Distribution: unstable
Urgency: low
Maintainer: Russell Stuart russell-deb...@stuart.id.au
Changed-By: Russell Stuart russell-deb...@stuart.id.au
Description:
 roundcube  - skinnable AJAX based webmail solution for IMAP servers - metapack
 roundcube-core - skinnable AJAX based webmail solution for IMAP servers
 roundcube-mysql - metapackage providing MySQL dependencies for RoundCube
 roundcube-pgsql - metapackage providing PostgreSQL dependencies for RoundCube
 roundcube-plugins - skinnable AJAX based webmail solution for IMAP servers - 
plugins
 roundcube-sqlite3 - metapackage providing SQLite dependencies for RoundCube
Closes: 736782
Changes:
 roundcube (0.9.5+dfsg1-4.1) unstable; urgency=low
 .
   * NMU - rc bug preventing roundcube from being included in jessie.
   * Changed debian/watch  debian/copyright so uscan repackage
 upstream tarball to remove files without source.
 Closes: #736782.
   * Added sources for jquery-ui and jstz.js to debian/missing-sources.
   * Modified debian/copyright to acknowledge copyrights of
 files in debian/missing-sources.
   * Added debian/create-jquery-ui-custom.sh that creates the
 jquery-ui-1.9.1.custom.min.js from upstream source.
   * Modified debian/rules to create jstz.min.js and
 jquery-ui-1.9.1.custom.min.js form the versions we have
 sources for.
Checksums-Sha1:
 9d45321ef8321a8a73892560d13b8a712a8e3322 2352 roundcube_0.9.5+dfsg1-4.1.dsc
 1f3a8db2ed6760f09bdeb94176de0a2dddb40172 3279887 
roundcube_0.9.5+dfsg1.orig.tar.gz
 f07985669021170eb371513462569d26d9162076 1996496 
roundcube_0.9.5+dfsg1-4.1.debian.tar.xz
 da73f0b2d20fa1a73b9a5b6eec9095c424c1b862 1176558 
roundcube-core_0.9.5+dfsg1-4.1_all.deb
 c60c1264aa1025b9a14a18bd305833691d6238dc 30592 
roundcube_0.9.5+dfsg1-4.1_all.deb
 e54aedaf5c478c1854620809820d1d88188012b0 30526 
roundcube-mysql_0.9.5+dfsg1-4.1_all.deb
 ea74fc8e4c637c798f68863e10f3ac4d2d51a46b 30490 
roundcube-pgsql_0.9.5+dfsg1-4.1_all.deb
 6b1f79f0a63c21feaa1994ae7fe4fa7fdffc756d 30482 
roundcube-sqlite3_0.9.5+dfsg1-4.1_all.deb
 293be1e6031cc78d5e5721ed7d0f6fc4c5657112 488248 
roundcube-plugins_0.9.5+dfsg1-4.1_all.deb
Checksums-Sha256:
 ef934e3867352d691c1af652e06e63dbb2a284080f985314d26304cfa916975e 2352 
roundcube_0.9.5+dfsg1-4.1.dsc
 82d40597df11a14811e95fb937a234bec7b26c57a7abc7b5c746eb44687f4a68 3279887 
roundcube_0.9.5+dfsg1.orig.tar.gz
 3a86c010ab7f3e76f683f696928775e1b5f28df5c125fa8d2ffc10ac485f1c5b 1996496 
roundcube_0.9.5+dfsg1-4.1.debian.tar.xz
 bd591d6c9825a3f0589212d885a8dfd05ce4d87d1df939c7dbb1a87127f33bdb 1176558 
roundcube-core_0.9.5+dfsg1-4.1_all.deb
 1b3f7fefd5ca73fc1e53d28e1e174caa9e47aeb63da9b73649bbe3cb9b8a6abd 30592 
roundcube_0.9.5+dfsg1-4.1_all.deb
 38841d60e797aacc00b54209dd8edb39e8075949edef2a4d952e19d514f04277 30526 
roundcube-mysql_0.9.5+dfsg1-4.1_all.deb
 cf3d8dabe8b7eda3d60cabd55595fb02489612150014b7339af2a3c06b41a66f 30490 
roundcube-pgsql_0.9.5+dfsg1-4.1_all.deb
 20192832639259d0e963dd81199ca804ad166c6043d90befc309279af5d512b6 30482 
roundcube-sqlite3_0.9.5+dfsg1-4.1_all.deb
 70380e0287263eb39ecaac896aa42864f22095e3561bbe9679e3b66e2f8a900b 488248 
roundcube-plugins_0.9.5+dfsg1-4.1_all.deb
Files:
 4213047b20128107dcc9097bf8bf4ac0 1176558 web extra 
roundcube-core_0.9.5+dfsg1-4.1_all.deb
 5e073e9e86fb0b9b192a72800b1d900b 30592 web extra 
roundcube_0.9.5+dfsg1-4.1_all.deb
 f5ba8494231fc4143846478eee478aaa 30526 web extra 
roundcube-mysql_0.9.5+dfsg1-4.1_all.deb
 adc520997325420ea27adea6c209f5c9 30490 web extra 
roundcube-pgsql_0.9.5+dfsg1-4.1_all.deb
 dcea41021b97ed36c4d1737d6858cfa8 30482 web extra 
roundcube-sqlite3_0.9.5+dfsg1-4.1_all.deb
 ec57181fbe07ef225eb3d33e54e932ea 488248 web extra 
roundcube-plugins_0.9.5+dfsg1-4.1_all.deb
 5be2db933203c935bceb6d14fb0ad3eb 2352 web extra roundcube_0.9.5+dfsg1-4.1.dsc
 f1204b86ac5d3829fe7cc40959a416e4 3279887 web extra 
roundcube_0.9.5+dfsg1.orig.tar.gz
 3e39316a3e338a77f496ac965b96e939 1996496 web extra 
roundcube_0.9.5+dfsg1-4.1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIVAwUBVD3grKzUn4heVFJuAQqq3hAAkMNTszzUw5TghDa9PwkDXPa8ny1euf1V
SgXqs2WV/WsuN5NmlJr2Z2fI7FGAQ8WMSuOaHS2FXd7pJ3FN26nSKWxUnaRNdoSA
y84pmD0KepPmAWDqi2pUPBGjkHdmkCC6Yon/F7aZa6B0M5V6Ze2C1UbBpSdfVpag
YAvarCBBD8f2cc9SFCsV0L4HxD+H2PMBWPdX/X+f/tXFvEclB4ne8BhN32k2FWG2
abShv0rg+s2sQGNYSGc5IkV7LNmjor8BsQWW2Vb/TFt78ismHDQy+KmCF7X5vN4z
Elv/zs5uq32znzBZ8sSq8igxGWkMywBOJQCvHejdh4EYFI3GgBRKK7FsrSu0Rd32
YocUECKitWvjh8L3xT0ZPAa14l5FatPDRNhOAJmKSL0yWhlGkBkBcMqoGnsK1kRq
sca203YawIZhuW9/LKbR0wXRRlUvEAbyog6c3m60ZXZxlQwe3GX5dQBinY9tY8tC
zFZZiCeFSWvHFzEiENAJTmq+XsBZN92kzd2luW351vWMMTCqmfMWu8dnLSc7J9yP
WXabziytLvkfYZeOHIxCG/iIZyM/AO4zCmizGgpacYcpKsSXvNuVdexB5ow9LsKe
V0Y7IgJFX0YqRsDHgr29IrnERoex8PmXOzvssliU