Bug#849625: ITP: engine-mode -- define and query search engines from within Emacs

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: engine-mode
  Version : 2.0.0
  Upstream Author : Harry R. Schwartz 
* URL : https://github.com/hrs/engine-mode
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : define and query search engines from within Emacs

`engine-mode' is a global minor mode for Emacs. It enables you to easily
define search engines, bind them to keybindings, and query them from the
comfort of your editor.

Re: unattended-upgrades by default?

[Ben Hutchings]

On Wed, 2016-12-28 at 04:13 +, Scott Kitterman wrote:
> 
> On December 27, 2016 11:10:55 PM EST, Adam Borowski  
> wrote:
> > On Wed, Dec 28, 2016 at 04:04:21AM +, Scott Kitterman wrote:
> > > > FTR, it's #739636.
> > > > 
> > > 
> > > Postfix has no way to know it's temporary, so I think a temporary
> > 
> > error
> > > would be wrong.
> > 
> > It's easy to tell apart "can't connect to SQL" from "query succeeded
> > and
> > returned 'no such user'".
> 
> That assumes it will eventually be turned back on.  Temporary versus
> permanent shutdown is what you can't distinguish.

MTAs should always assume a failure is temporary, if they can't tell. 
If the failure is really permanent this delays bouncing to the point
that the sender times-out, but that is much less bad than the opposite
error of bouncing on a temporary error.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot



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

Re: Can we kill net-tools, please?

[Marco d'Itri]

On Dec 29, Simon Richter  wrote:

> As long as there is still a way to have working "netstat" and "ifconfig"
> commands, that is fine.
I do not think that anybody sane wants to remove the package from the 
archive: the idea is to stop using it in script in other packages since 
iproute is a) better and b) going to be installed anyway.

(Still, using ifconfig is a bad idea because it shows an incomplete 
view of the system.)

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Simon Richter]

Hi,

On 29.12.2016 12:49, Marco d'Itri wrote:

>> As long as there is still a way to have working "netstat" and "ifconfig"
>> commands, that is fine.

> I do not think that anybody sane wants to remove the package from the 
> archive: the idea is to stop using it in script in other packages since 
> iproute is a) better and b) going to be installed anyway.

Yes, I'm totally in favour of that. Parsing the output of any of these
tools is wrong, and has been for far longer than iproute has even existed.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Can we kill net-tools, please?

[Marco d'Itri]

On Dec 26, Martín Ferrari  wrote:

> I am currently the Debian maintainer for net-tools, but note that I have
> not forked, nor I am developing net-tools. Upstream got active again,
> somehow.
Thank you for your clarification.

I think that we have a consensus about this: can you switch to optional 
priority for the next upload?
This way it will not be installed by default unless pulled in by 
a dependency.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Theodore Ts'o]

On Wed, Dec 28, 2016 at 01:38:48PM +1000, Russell Stuart wrote:
> 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.

This is really going to be a generational thing.  For those of us who
started programming in the BSD 4.x days (my first kernel programming
experience was with BSD 4.3), ifconfig and netstat are still the tools
that I use every day, and I only use the iproute2 tools in the
*extremely* rare circumstances that I need to do something exotic
which is only supported by the iproute2 tools.

This probably makes me a bad person, but it's how I operate, because I
grew up using the ifconfig and netstat.  From my perspective, it's the
height of arrogance to decide that we're being "kind" to Debian system
administrators by forcibly taking away the traditional BSD tools, and
forcing them to learn a new interface, just because we think it's the
right and moral choice for system administrators.

If you want to deprecate ifconfig and netstat, the kindest way to do
that is to (a) remove all of the progammatic dependencies on ifconfig
and netstat output, (b) add hints to ifconfig and netstat which look
at how they were invoked and adds a one-line hint:

   Ifconfig has been deprecated; you should probably use "ip a show
   dev lo" instad of the shorter and more convenient "ifconfig lo"
   because debian is going to arrogantly make "ifconfig" go away in
   the next stable release, because we believe this is in your best
   interests, and Debian always has the priorities of our users at heart.

OK, you can remove the last half, but keep in mind there are plenty of
people who aren't using the exotic features provided by iproute2, and
are very happy using the more convenient and shorter BSD-style
commands.  If you're going to remove it _becase_, the least you can do
is to make the transition a bit more gentle.

Regards,

- Ted

Re: Can we kill net-tools, please?

[Andrey Rahmatullin]

On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:
>Ifconfig has been deprecated; you should probably use "ip a show
>dev lo" instad of the shorter and more convenient "ifconfig lo"
... and often wrong

> OK, you can remove the last half, but keep in mind there are plenty of
> people who aren't using the exotic features provided by iproute2
... like two IPs on one iface.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Migration despite an RC bug?

[Ole Streicher]

Hi,

the python-numpy package in unstable has an RC bug:

https://bugs.debian.org/849196

however, today it migrated to testing, the migration status still says
however "valid candidate".

I thought that RC bugs would prevent packages from migration -- what is
the exception here?

Best regards

Ole

Re: Migration despite an RC bug?

[Emilio Pozuelo Monfort]

On 29/12/16 17:24, Ole Streicher wrote:
> Hi,
> 
> the python-numpy package in unstable has an RC bug:
> 
> https://bugs.debian.org/849196
> 
> however, today it migrated to testing, the migration status still says
> however "valid candidate".
> 
> I thought that RC bugs would prevent packages from migration -- what is
> the exception here?

Unforunately, the BTS exported a broken/incomplete RC bug list, and britney used
that and didn't see that some packages had an RC bug, so it allowed them to 
migrate.

Cheers,
Emilio

Re: Migration despite an RC bug?

[Ole Streicher]

Emilio Pozuelo Monfort  writes:
> On 29/12/16 17:24, Ole Streicher wrote:
>> Hi,
>> 
>> the python-numpy package in unstable has an RC bug:
>> 
>> https://bugs.debian.org/849196
>> 
>> however, today it migrated to testing, the migration status still says
>> however "valid candidate".
>> 
>> I thought that RC bugs would prevent packages from migration -- what is
>> the exception here?
>
> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney 
> used
> that and didn't see that some packages had an RC bug, so it allowed
> them to migrate.

Is there a way to get the old version back? At least, I am quite unhappy
with a buggy release candidate in testing.

Best regards

Ole

Re: Can we kill net-tools, please?

[Lars Wirzenius]

On Thu, Dec 29, 2016 at 10:30:26AM -0500, Theodore Ts'o wrote:
> OK, you can remove the last half, but keep in mind there are plenty of
> people who aren't using the exotic features provided by iproute2, and
> are very happy using the more convenient and shorter BSD-style
> commands.  If you're going to remove it _becase_, the least you can do
> is to make the transition a bit more gentle.

For stretch+1, what I'd like to see is a tool that a) works b) has
output that's nice for a human to read and c) has output that can be
easily processed by programs. None of the current tools comes anywhere
near. Bonus points if the command line syntax is reasonbly nice, and
the manpage doesn't start with a BNF syntax description.

Of, you know, I can continue to mostly ignore things since I'm in the
vast majority that doesn't do or need complicated network setups.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Bernd Zeimetz]

On 12/29/2016 07:04 PM, Lars Wirzenius wrote:
> For stretch+1, what I'd like to see is a tool that a) works b) has
> output that's nice for a human to read and c) has output that can be
> easily processed by programs. None of the current tools comes anywhere
> near. Bonus points if the command line syntax is reasonbly nice, and
> the manpage doesn't start with a BNF syntax description.

In my opinion ip provides all the things you are mentioning - what are
you missing? with -o as option the output is rather easy to parse.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Can we kill net-tools, please?

[Lars Wirzenius]

On Thu, Dec 29, 2016 at 08:17:01PM +0100, Bernd Zeimetz wrote:
> In my opinion ip provides all the things you are mentioning - what are
> you missing? with -o as option the output is rather easy to parse.

I find ip's output hard to read. I have to take time to visually parse
it every time, I can't just skim it. The ip -o output seems parseable,
but no easily extensible (I'd prefer something like YAML instead).

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Russ Allbery]

Bernd Zeimetz  writes:
> On 12/29/2016 07:04 PM, Lars Wirzenius wrote:

>> For stretch+1, what I'd like to see is a tool that a) works b) has
>> output that's nice for a human to read and c) has output that can be
>> easily processed by programs. None of the current tools comes anywhere
>> near. Bonus points if the command line syntax is reasonbly nice, and
>> the manpage doesn't start with a BNF syntax description.

> In my opinion ip provides all the things you are mentioning - what are
> you missing? with -o as option the output is rather easy to parse.

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 forever preferred_lft 
forever
1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
forever
3: wlan0inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0\ 
  valid_lft 598191sec preferred_lft 598191sec
3: wlan0inet6 fe80::a288:69ff:fe31:2b62/64 scope link \   valid_lft 
forever preferred_lft forever

The fields aren't labeled, you have to make a bunch of assumptions about
ordering, the backslash thing is just completely bizarre and makes the
parsing way harder (see the "lo\" on the first line)... this is really
rather dire.

And the output (without -o) is less human-readable than the current
ifconfig output, although neither of them are going to win any awards.
ifconfig at least understands how to use whitespace to try to present
data, which ip definitely does not, but both have a lot of cryptic
abbreviations and provide a lot of uninteresting noise in the default
output format that's only useful in unusual situations.

ip address also has one of the worst output UI decisions I've ever seen,
namely this line:

inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0

specifically "192.168.0.195/24", which is notation (IIRC) invented by this
command, used nowhere else in networking, and confusing to anyone who has
prior networking experience.

This is all probably a matter of opinion, but Lars is definitely not alone
in considering all this stuff to be quite bad.

-- 
Russ Allbery (r...@debian.org)   

Re: Can we kill net-tools, please?

[Sandro Tosi]

On Thu, Dec 29, 2016 at 2:38 PM, Russ Allbery  wrote:
> Also, this is not at all easy to parse:
>
> # ip -o address
> 1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
> preferred_lft forever
> 1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
> forever
> 3: wlan0inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic 
> wlan0\   valid_lft 598191sec preferred_lft 598191sec
> 3: wlan0inet6 fe80::a288:69ff:fe31:2b62/64 scope link \   valid_lft 
> forever preferred_lft forever
>
> The fields aren't labeled, you have to make a bunch of assumptions about
> ordering, the backslash thing is just completely bizarre and makes the
> parsing way harder (see the "lo\" on the first line)... this is really
> rather dire.

i recently had to parse it (in particular, `ip -s -s -s -s -o link
show up`) it's not that hard: split by \, remove the first line,
remove any spurious other lines, then parse by line pairs: the first
is the headers, the second the values, and so on (kinda OT but yeah a
YAML/JSON/anything would have been better, but it's doable)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: dput: Call for feedback: What should change? What should stay the same?

[Ben Finney]

Russ Allbery  writes:

> I have never managed to work out how to use dcut […] in fewer than
> five tries each time I've needed to use it. I'm not sure what it is
> with that command, but I find it completely baffling to use correctly.

This should be addressed by, at least, improving the ‘dcut(1)’ manual
page so that it properly describes how to use the existing interface.
I have reported bug#849687 for this.

A broader discussion can be had on changing the ‘dcut’ interface; I
leave that as an exercise for the future. Suggestions are welcome
though.

-- 
 \  “In case of fire, do your utmost to alarm the porter.” —hotel, |
  `\Vienna |
_o__)  |
Ben Finney

Re: dput: Call for feedback: What should change? What should stay the same? [and 1 more messages]

[Ben Finney]

"Paul R. Tagliamonte"  writes:

> FWIW, I don't think any of the dput-ng hackers particularly mind if it
> changes, changing API could just happen for both together, at the same
> time. Or maybe just consolidate :)

Much appreciated. Yes, one aspiration I eventually hope to achieve have
is to resolve the fork by merging the desirable features of both back
into ‘dput’, and discarding behaviour that we decide is no longer
helpful.

-- 
 \   “Corporation, n. An ingenious device for obtaining individual |
  `\   profit without individual responsibility.” —Ambrose Bierce, |
_o__)   _The Devil's Dictionary_, 1906 |
Ben Finney

Re: Can we kill net-tools, please?

[Christian Seiler]

On 12/29/2016 08:38 PM, 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.

Ack.

> Also, this is not at all easy to parse:
> 
> # ip -o address
> 1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
> preferred_lft forever
> 1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
> forever
> 3: wlan0inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic 
> wlan0\   valid_lft 598191sec preferred_lft 598191sec
> 3: wlan0inet6 fe80::a288:69ff:fe31:2b62/64 scope link \   valid_lft 
> forever preferred_lft forever
> 
> The fields aren't labeled, you have to make a bunch of assumptions about
> ordering, the backslash thing is just completely bizarre and makes the
> parsing way harder (see the "lo\" on the first line)... this is really
> rather dire.

Ack.

> And the output (without -o) is less human-readable than the current
> ifconfig output, although neither of them are going to win any awards.
> ifconfig at least understands how to use whitespace to try to present
> data, which ip definitely does not, but both have a lot of cryptic
> abbreviations and provide a lot of uninteresting noise in the default
> output format that's only useful in unusual situations.

I personally hate both outputs as well, but vastly prefer ip over
the traditional ifconfig output. (The new ifconfig appears to have
gotten better, after just trying it for the first time.)

> ip address also has one of the worst output UI decisions I've ever seen,
> namely this line:
> 
> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
> 
> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
> command,

Nope, that's RFC 4632, Section 3.1, where that was introduced
first, see
https://tools.ietf.org/html/rfc4632#section-3.1

And at least I find it vastly superior to the traditional netmask
notation - if I see /29 I can immediately deduce that there are
three bits available for the host part, so with broadcast address
subtracted that gives me 6 hosts in that range. The corresponding
netmask is 255.255.255.248 - that is far harder to process
mentally for me. Add in IPv6 and there's a reason why traditional
netmasks have never been used there.

That said: to me it would have been much more logical to count
the bits that are zero in the netmask (as that defines the size
of the network directly) than the bits that are one, so I believe
there was room for improvement when that syntax was introduced.
Unfortunately that ship has now sailed...

Regards,
Christian

Specification of FTP upload queue management commands

[Ben Finney]

Afif Elghraoui  writes:

> Hi, Ben,

Thanks for the feedback. One specific suggestion appears to already have
a bug report; I'm redirecting this sub-thread there.

> على الثلاثاء 27 كانون الأول 2016 ‫20:31، كتب Ben Finney:
> > The ‘dput-ng’ package is one alternative that is sometimes suggested
> > when people hit the limits in ‘dput’. I am not a user of ‘dput-ng’
> > or other alternatives, so am also seeking feedback from people who
> > have informed positions on choosing one over the other.
>
> I always have to use dput-ng in order to be able to use the dcut dm
> […] command and grant DMs upload permissions.

There is not ‘dm’ command is not mentioned at the upload queue Read Me
document ftp://ftp.upload.debian.org/pub/UploadQueue/README>.

As best I can tell, that document is the specification for queue
manipulation commands. What am I missing?

> So as far as I'm concerned, if the dput package had a dcut that supports
> the dm subcommand, I'd be very happy.

Where is the canonical specification of the commands accepted by ‘dak’?

Should ‘dcut’ support only one of those specifications, or should it be
attempting to support the ‘…/UploadQueue/README’ commands as well?

-- 
 \ “For myself, I am an optimist — it does not seem to be much use |
  `\  being anything else.” —Winston Churchill, 1954-11-09 |
_o__)  |
Ben Finney 

Re: Can we kill net-tools, please?

[Russ Allbery]

Christian Seiler  writes:
> On 12/29/2016 08:38 PM, Russ Allbery wrote:

>> ip address also has one of the worst output UI decisions I've ever seen,
>> namely this line:
>> 
>> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
>> 
>> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
>> command,

> Nope, that's RFC 4632, Section 3.1, where that was introduced
> first, see
> https://tools.ietf.org/html/rfc4632#section-3.1

No, I'm not talking about CIDR notation, which of course is long-standing
and familiar.  I'm talking about randomly appending a CIDR suffix to
something that is obviously *not* the base for that CIDR block.

In other words, 192.168.0.0/24 is fine.  The problem is with deciding to
merge two completely different things (a CIDR network specification, and
an individual IP address) in this weird hybrid notation that, by RFC 4632,
would mean the network starting at 192.168.0.195 and extending for a /24.
Which is a nonsensical specification.

IIRC, this was done in ip to "save space" instead of using the natural
expression, namely:

192.168.0.195 net 192.168.0.0/24

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

It's possible that some other tool has abused CIDR notation in this way,
but ip is still the only place I ever see it.  It's definitely not common.

-- 
Russ Allbery (r...@debian.org)   

Re: Can we kill net-tools, please?

[Samuel Thibault]

Russ Allbery, on Thu 29 Dec 2016 12:24:28 -0800, wrote:
> >> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
> >> command,
> 
> It's possible that some other tool has abused CIDR notation in this way,
> but ip is still the only place I ever see it.  It's definitely not common.

/etc/network/interfaces uses it too.

Samuel

Re: Can we kill net-tools, please?

[Vincent Bernat]

 ❦ 29 décembre 2016 12:24 -0800, Russ Allbery  :

> No, I'm not talking about CIDR notation, which of course is long-standing
> and familiar.  I'm talking about randomly appending a CIDR suffix to
> something that is obviously *not* the base for that CIDR block.
>
> In other words, 192.168.0.0/24 is fine.  The problem is with deciding to
> merge two completely different things (a CIDR network specification, and
> an individual IP address) in this weird hybrid notation that, by RFC 4632,
> would mean the network starting at 192.168.0.195 and extending for a /24.
> Which is a nonsensical specification.
>
> IIRC, this was done in ip to "save space" instead of using the natural
> expression, namely:
>
> 192.168.0.195 net 192.168.0.0/24
>
> Saving space in UI output intended for humans by introducing new notation
> is almost never a good idea.
>
> It's possible that some other tool has abused CIDR notation in this way,
> but ip is still the only place I ever see it.  It's definitely not common.

It's quite common. For example, on JunOS, this is also how IP addresses
are expressed. This is quite like "192.168.0.195 netmask 255.255.255.0",
except this is "192.168.0.195 prefixlen 24" which then can be
abbrieviated to "192.168.0.195/24". You know this is not a prefix
because the prefix is "192.168.0.0/24" (and the prefix length is less
than 31).

This is also how it works with IPv6 (even on Cisco).
-- 
Extreme fear can neither fight nor fly.
-- William Shakespeare, "The Rape of Lucrece"


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Tollef Fog Heen]

]] Russ Allbery 

> It's possible that some other tool has abused CIDR notation in this way,
> but ip is still the only place I ever see it.  It's definitely not common.

I picked a few arbitrary networking platforms:

From
http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-es-jseries-quick-start/basic-connection-and-configuration-with-the-cli.html:

root# set interfaces ge-0/0/0 unit 0 family inet address 1.1.2.31/24

>From http://wiki.mikrotik.com/wiki/Manual:IP/Address :

[admin@MikroTik] ip address> add address=10.10.10.1/24 interface=ether2

From
http://stackoverflow.com/questions/11225681/interface-configuration-in-arista-eos
 :

localhost(config-if-Eth1)# ip address 172.16.204.4/24

(Arista's configuration manual is a PDF, hence linking to a random
stackoverflow description.)

From
http://dev-random.net/d-link-dgs-3324sr-management-ip-address-configuration/ :

config ipif System ipaddress 192.168.2.2/24

Cisco does it differently, and I'm sure some others do too, but the
$ip/prefixlen notation is pretty common in the networking world at
least.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Can we kill net-tools, please?

[Peter Samuelson]

[Russ Allbery]
> ip address also has one of the worst output UI decisions I've ever seen,
> namely this line:
> 
> inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic wlan0
> 
> specifically "192.168.0.195/24", which is notation (IIRC) invented by this
> command, used nowhere else in networking, and confusing to anyone who has
> prior networking experience.

Huh ... I have exactly the opposite reaction.  To me, this notation is
_far_ more readable than dotted quads, e.g., I know exactly what a /27
is, but it takes awhile to work out 255.255.255.224.  I don't think
this notation originated in iproute2, I've seen it in lots of other
contexts.

(Yes, it's a bit annoying to parse this, as you have to split on /
after splitting on whitespace, but to me that's a small price to pay.)

In fact in my interfaces(5) files I always use 'address a.b.c.d/nn' and
no 'subnet' line.  So tidy.  (ifupdown added this feature in wheezy.)

Re: Can we kill net-tools, please?

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Russ Allbery 

>> It's possible that some other tool has abused CIDR notation in this way,
>> but ip is still the only place I ever see it.  It's definitely not common.

> I picked a few arbitrary networking platforms:

Meh.  Okay, thanks, I'm apparently just not well-informed about this and
will have to get over it.

-- 
Russ Allbery (r...@debian.org)   

Re: Can we kill net-tools, please?

[Russ Allbery]

Bjørn Mork  writes:

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

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

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

>   ipv6-address/prefix-length
>   "

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

Yeah, I'm clearly incorrect about this, and I apologize for the noise (and
appreciate all the good information).  I'm also now remembering, to my
embarassment, that I'd already ranted about and been corrected on this
before and then didn't retain that.  I suppose that shows how little I
deal with the ip tool.  (I probably should alias ifconfig to something
that reminds me to use ip to force myself to do the mental conversion.)

I apparently haven't gotten over my initial confusion when I ran into it
for the first time, but that isn't a good idea not to use the notation,
and I do see the merits.  Hopefully this time I'll remember and learn and
not forget the whole conversation again!

-- 
Russ Allbery (r...@debian.org)   

Re: Can we kill net-tools, please?

[Bjørn Mork]

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

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

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

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

  ipv6-address/prefix-length
  "


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


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


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

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

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

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

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


Bjørn

Re: Migration despite an RC bug?

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> Unforunately, the BTS exported a broken/incomplete RC bug list, and britney 
> used
> that and didn't see that some packages had an RC bug, so it allowed them to 
> migrate.

Ouch, that's quite a nightmare. While I'm curious to learn how this
happened and what is done to prevent this from happening again -
please rather focus on restoring the correct state. Installations
running testing already might have got packages they shouldn't see.

Christoph


signature.asc
Description: Digital signature

Re: compression support in kmod

[Christoph Biedl]

Eduard Bloch wrote...

> I volunteer as test subject for that experiment. I would appreciate even
> small steps, considering the current laptop in front of me with average
> magnetic HDD. Over a minute boot time, which is insane and IMHO mostly
> caused by the storm of IO operations required nowadays.

At the risk of damping your expectations - I was surprised if there was
as noticeable improvement. Perhaps on broken (i.e. slow) bootloaders
where a smaller initrd gets loaded faster. Otherwise I'd expect the
reduced I/O doesn't count compared to everything else that happens.

> And seriously, today a kernel with a couple of extra modules takes about
> 200MB. I remember times when you could install a whole desktop
> installation in that space.

200MB? Luxury!

Christoph


signature.asc
Description: Digital signature

Re: Can we kill net-tools, please?

[Wookey]

On 2016-12-29 11:38 -0800, Russ Allbery wrote:
> Bernd Zeimetz  writes:
> > On 12/29/2016 07:04 PM, Lars Wirzenius wrote:
> 
> Also, this is not at all easy to parse:
> 
> # ip -o address
> 1: loinet 127.0.0.1/8 scope host lo\   valid_lft forever 
> preferred_lft forever
> 1: loinet6 ::1/128 scope host \   valid_lft forever preferred_lft 
> forever
> 3: wlan0inet 192.168.0.195/24 brd 192.168.0.255 scope global dynamic 
> wlan0\   valid_lft 598191sec preferred_lft 598191sec
> 3: wlan0inet6 fe80::a288:69ff:fe31:2b62/64 scope link \   valid_lft 
> forever preferred_lft forever
> 
> The fields aren't labeled,

> And the output (without -o) is less human-readable than the current
> ifconfig output, 

Yeah I think that mess is why I've never felt any need to move away
from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic
output and stayed with the rather more civilised /sbin/ifconfig.

So it seem that the output does actually label things, but the things
and labels look exactly the same. Would some colons really have hurt
too much?

i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 
is really
mtu: 1500  qdisc: mq  state: UP  mode: DEFAULT  group: default  qlen: 1000 

Anyone think the latter is a tad clearer? I still don't know what a
qdisc is or a default group, but it's a lot easier to find things I do
recognise. Before this discussion I just saw it as a mysterious jumble
of 10 things (after a set of things in CAPITALS that were somewhat
mysterious too (what's a LOWER_UP, I wonder) - who knows what it might
mean.

The choice to use the former rather than the latter is presumably why
people who saw ifconfig's rather more civilised output first have not
shifted in 15 years. Some people are forcefully pointing out in this
thread that ifconfig is _wrong_, but I can't say I've ever noticed
enough to care. It's fine for normal, simple, network config where the
fanciest thing one ever does is create a bridge or mess with the
masquerading/nat tables.

Anyway, this discussion has produced some helpful links (cheers) which
I, and no doubt others, will peruse. (I do at least not have to prefix
ip with /sbin/, which is nice, so it's not all worse).

But I reckon this is a little lesson in UI design and adoption, which
it's worth remembering.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Specification of FTP upload queue management commands

[gregor herrmann]

On Fri, 30 Dec 2016 06:49:07 +1100, Ben Finney wrote:

> > I always have to use dput-ng in order to be able to use the dcut dm
> > […] command and grant DMs upload permissions.
> 
> There is not ‘dm’ command is not mentioned at the upload queue Read Me
> document ftp://ftp.upload.debian.org/pub/UploadQueue/README>.
> 
> As best I can tell, that document is the specification for queue
> manipulation commands. What am I missing?

Not sure if there is a formal spec besides
https://lists.debian.org/debian-devel-announce/2012/09/msg8.html
(I suppose ftp-masters and -assistants might be more helpful.) 

Cheers,
gregor
-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

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&item=netperf-bsd-linux


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

Re: Can we kill net-tools, please?

[Russ Allbery]

Russell Stuart  writes:

> 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.

That's a fair point.  :)  I'm probably going to force myself to learn ip
and ss and whatnot, since that's the direction of the future and it's not
really that much worse on the output front, and arguable.  I'm not really
complaining about the changes so much as I'm complaining about the changes
that *weren't* made: even better command-line UI, better documentation,
JSON or YAML output format.

Of course, just as with the people who complain about missing features in
Debian, I could always go implement such things if I cared that much about
them.  :)

-- 
Russ Allbery (r...@debian.org)   

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Toni Mueller]

Package: wnpp
Severity: wishlist
Owner: Toni Mueller 

* Package name: ansible-doc
  Version : 2.2.0.0-1
  Upstream Author : RedHat 
* URL : http://www.ansible.com/
* License : GPL-3
  Programming Lang: HTML, JavaScript
  Description : Documentation for Ansible

Currently, the Ansible package in Debian lacks proper offline
documentation. This package aims to supply the documentation in HTML
form offline, so one should not need to go to the aoupstream website to
read it.

Yours truly frequently suffers under bad network conditions, which make
reading the website infeasible or outright impossible, so I think the
package is useful.

I hope I can collaborate with the maintainer of the ansible package to
maintain this package.
 

Re: Can we kill net-tools, please?

[Gabor Gombas]

On Thu, Dec 29, 2016 at 09:01:51PM +0500, Andrey Rahmatullin wrote:

> > OK, you can remove the last half, but keep in mind there are plenty of
> > people who aren't using the exotic features provided by iproute2
> ... like two IPs on one iface.

Actually, that is only a problem if you re-use labels (including empty
ones). If you give distinct labels to all IPs, then ifconfig has no
trouble displaying/manipulating the addresses.

The issue is really at a lower level - ioctl() vs. netlink (*). Anything
which uses the SIOCGIF*/SIOCSIF* ioctl()s will have the same limitations
as ifconfig.  So if you _really_ care about having multiple IPs sharing
the same label, then replacing the ifconfig command with ip is just the
beginning - you'll need to find all applications and libraries which use
the ioctl() interface, and replace/re-write them to use netlink instead.
The problem is, using netlink is more complicated than using ioctl(), so
that may not be a simple task.

If you don't have any legacy applications which would use ioctl()s, then
you're lucky. Otherwise, assigning unique labels to IP addresses could
turn out to be simpler.

Gabor

(*) This is all about IPv4, IPv6 is different

Bug#849716: ITP: weresync -- A program to easily clone linux drives incrementally.

[Daniel Manila]

Package: wnpp
Severity: wishlist
Owner: Daniel Manila 

* Package name: weresync
  Version : 0.2
  Upstream Author : Daniel Manila 
* URL : https://github.com/DonyorM/weresync
* License : Apache2
  Programming Lang: Python3 
  Description : A program to easily clone linux drives incrementally.

Using rsync and various partitioning tools, weresync simulates a normal clone 
and creates a drive that is almost exactly the same as the original drive. 
However it is able to do this from a running drive or to a drive smaller than 
the original drive. This is written in Python but makes use of many aspects of 
the Linux ecosystem.

Hopefully, you think this package looks amazing and you want to try it right 
away. However, you may be skeptical about the usefulness of weresync. You may 
be thinking, I can do this exact same thing using gparted or ddrescue. Hear me 
out! There are a few reasons to use weresync over the other tools.

First and foremost, most other cloning tools require confidence in one's 
technical skill. dd will easily destroy your drive, gparted requires knowing 
what flags and partition types to use, and CloneZilla is just about the 
opposite of user friendly. weresync primarily attempts to help people who don't 
want to spend the time and effort to learn how to safely use a cloning tool.

But weresync also has some of its own features. It contains the ability to 
properly copy a partition table to a new drive and format the new drive. It 
uses rsync to copy so, unlike most other cloning tools, it will update 
incrementally – saving time. weresync has good default directory exclusions 
(such as /dev or /proc) so it won't copy parts of your system which should not 
be copied. On top of this weresync will create new UUIDs for the partitions on 
the cloned drive, allowing the clone to be used alongside the original drive. 
But the clone will still be bootable because weresync updates the fstab and 
reinstalls the boot loader. Not to mention it can complete the entire clone 
while leaving the original drive running ("hot cloning"), unlike dd or 
CloneZilla.

All of this is accomplished with one button click.

--

I am the upstream author of this package and I will be maintaining it as I
produce updates on the upstream code. I will need a sponsor to post this package
to Debian.

Re: Can we kill net-tools, please?

[Vincent Bernat]

 ❦ 30 décembre 2016 09:47 +1000, Russell Stuart  :

> [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.

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.

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. The same applies for
all your examples. Those are different subsystems for different
tasks. They all happen to have a way to drop packets but that's not
their sole purpose.

> 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&item=netperf-bsd-linux

Those benchmarks show huge differences between Linux distributions for a
kernel-related task. Like all phoronix benchmarks, it should not be
trusted.
-- 
In the first place, God made idiots; this was for practice; then he made
school boards.
-- Mark Twain


signature.asc
Description: PGP signature

Re: Can we kill net-tools, please?

[Vincent Bernat]

 ❦ 29 décembre 2016 23:09 GMT, Wookey  :

> I still don't know what a qdisc is or a default group, but it's a lot
> easier to find things I do recognise. Before this discussion I just
> saw it as a mysterious jumble of 10 things (after a set of things in
> CAPITALS that were somewhat mysterious too (what's a LOWER_UP, I
> wonder) - who knows what it might mean.

iproute is developed in lockstep with the kernel (you can use all the
features from the kernel X.Y if you have at least version X.Y) and
exposes all the information the kernel knows about an interface.

LOWER_UP is a flag (like UP, BROADCAST), hence the use of upper case. It
means that the lower interface is up. For a physical interface, it means
the driver says the interface is operatively up (while UP is an
administrative flag). For a virtual interface, like a VLAN, it is the
status of the lower interface.

A qdisc is a "queuing discipline". It is related to QoS and you can
change it with "tc" (another tool from iproute).

Each interface can be assigned a group (a number). This is not much
used. It can be used to make "ip link" operate on a group of
interface. It can be used with Netfilter too (devgroup).
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Allow mirroring new -dbgsym packages?

[Boyuan Yang]

Hello all,

I am wondering if it is possible for a downstream mirror site to mirror files 
in the debian-debug repository. [1] (of course, via rsync not http)
I searched the Internet but could not find any instruction or explanation about 
mirroring that repo.

A quick access to -dbgsym packages may be useful to developers and bug 
reporters of Debian.

[0] https://wiki.debian.org/AutomaticDebugPackages
[1] http://debug.mirrors.debian.org/debian-debug/

--
Sincerely,
Boyuan Yang

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

Re: Can we kill net-tools, please?

[Andrey Rahmatullin]

On Thu, Dec 29, 2016 at 11:09:35PM +, Wookey wrote:
> Yeah I think that mess is why I've never felt any need to move away
> from ifconfig. I ran ip something a few times, went 'huh?' at the cryptic
> output and stayed with the rather more civilised /sbin/ifconfig.
> 
> So it seem that the output does actually label things, but the things
> and labels look exactly the same. Would some colons really have hurt
> too much?
> 
> i.e. mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 
> is really
> mtu: 1500  qdisc: mq  state: UP  mode: DEFAULT  group: default  qlen: 1000 
> 
> Anyone think the latter is a tad clearer? I still don't know what a
> qdisc is or a default group, but it's a lot easier to find things I do
> recognise. Before this discussion I just saw it as a mysterious jumble
> of 10 things (after a set of things in CAPITALS that were somewhat
> mysterious too (what's a LOWER_UP, I wonder) - who knows what it might
> mean.

Do you really think that

wlp3s0: flags=4163  mtu 1500
inet 192.168.**  netmask 255.255.255.0  broadcast 192.168.**
inet6 fe80::**  prefixlen 64  scopeid 0x20
ether e4:**:ca  txqueuelen 1000  (Ethernet)
RX packets 66323088  bytes 90518262611 (84.3 GiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 18425793  bytes 2920636610 (2.7 GiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

is clearer than 

3: wlp3s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether e4:***:ca brd ff:ff:ff:ff:ff:ff
inet 192.168**/24 brd 192.168.** scope global dynamic wlp3s0
   valid_lft 70216sec preferred_lft 70216sec
inet6 fe80:**/64 scope link 
   valid_lft forever preferred_lft forever

?


To me they are the same. Note that ifconfig too has cryptic uppercase jumble
and cryptic lowercase jumble and doesn't have any separators between field
names and values.

-- 
WBR, wRAR


signature.asc
Description: PGP signature