Re: Can we kill net-tools, please?

[Andrew Shadura]

On 27 Dec 2016 08:40, "Andreas Henriksson"  wrote:

Hello,

On Mon, Dec 26, 2016 at 09:55:14PM +0100, Geert Stappers wrote:
> Thing what Andreas Henriksson is doing
> in https://lists.debian.org/debian-devel/2016/12/msg00619.html
> providing patches how to get rit of net-tools,
> is what will make the killing of net-tools more easy.

I personally don't beleive in trying to patch us out of this mess
because it's chasing a moving goal. New crap gets uploaded to the
archive every day.

What I was trying to show was that the existing reverse dependencies of
net-tools are either not using it or are trivial to port, the real
question is if it makes any sense to spend time porting them?
Many things net-tool is used for is either useless or broken code.
Getting rid of it would be a service to our users.
Several times it's likely useful to get rid of the entire obsolete
package (that the package uses net-tools is just one symptom of
its outdatedness).

A better way than chasing a moving goal is in my opinion to declare
intent and then go in for the kill (taking all remaining rdeps with it).
Given not even the net-tools maintainer seems to suggest you should not
be using net-tools, I think we in this thread has declared that:

If you want your package to be part of Buster then make sure it doesn't
depend (solely) on net-tools!!!

(Atleast we should consider downgrading the priority so it only gets
installed when pulled in via dependency or manually installed.)


While I can certainly agree parsing net-tools output isn't a good idea,
please stop suggesting we should remove the package from Debian. It is
still useful and many people myself included use it.

-- 
Cheers,
  Andrew

help with execnet

[Daniel Stender]

Hi,

wanna ask if somebody would like to help fixing the remaining three RC bugs of
execnet (https://packages.qa.debian.org/e/execnet.html).

Best,
DS

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
LPIC-1 (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/

Re: Can we kill net-tools, please?

[Josh Triplett]

Geert Stappers wrote:
> On Mon, Dec 26, 2016 at 02:50:50PM +0100, Marco d'Itri wrote:
> > ifconfig, route, etc...
>
>  From https://packages.debian.org/stretch/arm64/net-tools/filelist
>
>   * /bin/netstat

The rest of net-tools aside (which have sensible replacements), what
replaces netstat in the absence of net-tools?

lsof can do a subset of its functions, but only a subset, and with much
less useful output.

- Josh Triplett

Re: Can we kill net-tools, please?

[Ansgar Burchardt]

Josh Triplett writes:
> Geert Stappers wrote:
>> On Mon, Dec 26, 2016 at 02:50:50PM +0100, Marco d'Itri wrote:
>> > ifconfig, route, etc...
>>
>>  From https://packages.debian.org/stretch/arm64/net-tools/filelist
>>
>>   * /bin/netstat
>
> The rest of net-tools aside (which have sensible replacements), what
> replaces netstat in the absence of net-tools?

Which parts of netstat?

`ss` displays socket information.  And is more informative then netstat,
for example it shows correctly which programs(!) use a listening socket.
Compare:

+---
| # netstat -xlp | grep gpg-agent.ssh
| unix  2  [ ACC ] STREAM LISTENING 258881911/systemd   
  /run/user/1000/gnupg/S.gpg-agent.ssh
| # ss -lp | grep gpg-agent.ssh
| u_str  LISTEN 0  128/run/user/1000/gnupg/S.gpg-agent.ssh 25888
 * 0 
users:(("gpg-agent",pid=20584,fd=5),("systemd",pid=1911,fd=22))
+---

(which reminds me of `ip` vs. `ifconfig` on interfaces with multiple
 IPv4 addresses.  `ifconfig` will show only one of them...)

Ansgar

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: help with execnet

[Tobias Hansen]

Hi,

I just want to add that execnet is marked for autoremoval on January 17.
Also, sagemath depends indirectly on execnet.
The bugs should be fixed before January 7 to avoid stuff getting removed
from testing.

Best,
Tobias

Daniel Stender  wrote:
> Hi,
>
> wanna ask if somebody would like to help fixing the remaining three RC
bugs of
> execnet (https://packages.qa.debian.org/e/execnet.html).
>
> Best,
> DS

Re: Bug#820780: clarify syntax of ‘cancel’ command for queue control

[James Cowgill]

On 26/12/16 21:36, Ben Finney wrote:
> Is this constraint – the argument to ‘cancel’ *must* be a base
> filename only – imposed by the upload queue processor? If so, the
> response:
> 
>> .commands file has invalid Commands line: cancel 
>> ../pytest-django_2.9.1-2.1_amd64.changes
>> debsign: .commands file appears to be invalid. see:
>> ftp://ftp.upload.debian.org/pub/UploadQueue/README
>> for valid format
> 
> is not very helpful, because the referenced document does not make
> that constraint plain.
> 
> 
> I'm casting this to ‘debian-devel’ for confirmation whether this is
> actually the problem. Can someone with knowledge of the upload queue
> processing clarify this?

On the archive side, arguments to 'cancel' must match this regex:
https://anonscm.debian.org/cgit/mirror/dak.git/tree/tools/debianqueued-0.9/debianqueued#n71

which is used here:
https://anonscm.debian.org/cgit/mirror/dak.git/tree/tools/debianqueued-0.9/debianqueued#n1294

Forward slash is not in the regex, so paths are disallowed.

James




signature.asc
Description: OpenPGP digital signature

Re: help with execnet

[Daniel Stender]

On 27.12.2016 12:09, Tobias Hansen wrote:
> Hi,
> 
> I just want to add that execnet is marked for autoremoval on January 17.
> Also, sagemath depends indirectly on execnet.
> The bugs should be fixed before January 7 to avoid stuff getting removed
> from testing.
> 
> Best,
> Tobias

For the current state, I've just test build again without any errors on amd64 
incl. passing
the build time tests [1].

Three FTBFS resp. failing tests have been reported so far [2,3,4], another one 
- also from DEP-8 -
I've just added [5].

[2] is from another test build, [3] from the reproducible builds CI (where it 
currently doesn't appear),
[4] and [5] from DEP-8 testing (where it never passed).

Thanks for comments,
DS

[1] 
http://www.danielstender.com/uploads/execnet_1.4.1-3_amd64-2016-12-27T12:50:09Z.build

[2] https://bugs.debian.org/840823 
(testing/test_gateway.py::TestBasicGateway::test_gateway_status_busy[thread-popen]
 FAILED)

[3] https://bugs.debian.org/846951 
(testing/test_gateway.py::TestTracing::test_popen_stderr_tracing FAILED)

[4] https://bugs.debian.org/846952 
(testing/test_channel.py::TestStringCoerce::test_2to3 FAILED)

[5] https://bugs.debian.org/849466 
(testing/test_basics.py::test_stdouterrin_setnull[thread] FAILED)

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
LPIC-1 (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/

Bug#849475: ITP: python-mechanicalsoup -- a Python library for automating interaction with websites

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 

* Package name: python-mechanicalsoup
  Version : 0.6.0
  Upstream Author : Mirth Hickford 
* URL : https://github.com/hickford/MechanicalSoup
* License : Expat
  Programming Lang: Python
  Description : a Python library for automating interaction with websites

Long-Description:
 A Python library for automating interaction with websites. MechanicalSoup
 automatically stores and sends cookies, follows redirects, and can follow
 links and submit forms. It doesn't do Javascript.
 .
 MechanicalSoup provides a similar API to the Mechanize library using Requests
 (for http sessions) and BeautifulSoup (for document navigation).

This package is a build-dependency to src:python-pydap. It will be hosted and
maintained by the Debian Python Modules Team.

Regards,
Ghis

Bug#849477: ITP: python-pydap -- a Python library implementing the Data Access Protocol

[Ghislain Antony Vaillant]

Package: wnpp
Severity: wishlist
Owner: Ghislain Antony Vaillant 


* Package name: python-pydap
  Version : 3.2.0
  Upstream Author : Roberto De Almeida 
* URL : http://www.pydap.org/
* License : Expat
  Programming Lang: Python
  Description : a Python library implementing the Data Access Protocol

Long-Description:
 Pydap is an implementation of the Opendap/DODS protocol, written from
 scratch. You can use Pydap to access scientific data on the internet
 without having to download it; instead, you work with special array and
 iterable objects that download data on-the-fly as necessary, saving
 bandwidth and time. The module also comes with a robust-but-lightweight
 Opendap server, implemented as a WSGI application.

This package is an optional dependency to the hdf-compass.

Re: Crowd funding campaign to package browserify in debian

[Stéphane Blondon]

Le 25/12/2016 à 21:09, Vincent Bernat a écrit :
>  ❦ 25 décembre 2016 19:17 +0100, Stéphane Blondon 
>  :
> 
>> So, the final compiled file can be a mix of several languages but the
>> languages are separated in the sources.
>>
>> Sometimes yaml is transformed into HTML too; I saw that on the server side.
>>
>> Perhaps I missed something, so I'm curious to learn more about it (a
>> link or some keywords can be a good start).
> 
> Polymer mixes all three into a single source code to build reusable
> components.
> 

Ok, it's the same behaviour for ReactJS or Riot. They mixes html and
javascript for having reusable components too. Each each component can
be separated in a specific file.

Thank you Vincent.

-- 
Stéphane



signature.asc
Description: OpenPGP digital signature

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Adam Borowski]

On Mon, Dec 26, 2016 at 11:03:05PM +, Ian Jackson wrote:
> Samuel Thibault writes ("HEADSUP: mails sent to n...@bugs.debian.org are NOT 
> sent to the submitter"):
> > This happens again and again...  Quite a few maintainers don't seem to
> > realize that mails sent to n...@bugs.debian.org are not sent to the bug
> > submitter, and the bug tracking thus halts down completely when the
> > maintainer asks for information only to the bot, and not to the human.
> 
> When I decided that debbugs should work like this:
>  * The email environment was very different to today;
>  * I hadn't properly realised that a bug is actually like a special
>kind of mailing list (although I sort of got most of the way there);
>  * I was overly concerned that submitters ought not to be troubled by
>Debian-internal communications about their bug.
> 
> Maybe this decision was right at the time, but I think it is wrong
> now.  I suggest we change it.

Hell yeah!

While any change of this kind obviously can make people used to the old
default unhappy, having 123456@b.d.o not notify the submitter is so
unintuitive not only new users but even most of us who forget this keep
getting caught.  And having a bug stalled is much worse than an superfluous
mail.

Thus, let's move the current behaviour to 123456-maint@b.d.o or some such,
and have 123456@b.d.o notify at least both the maintainer/uploaders and the
submitter.

The BTS is notorious for sending duplicates if there are multiple reasons
someone should receive mail, but that deficiency shouldn't stop
improvements.


We could go further: I think GitHub got it right: by default, you get a mail
if you're either the maintainer, the submitter, or have commented on the
bug.  The BTS already tracks "with mail from".

The only snag I can think of is that there's currently no way to edit
addresses of old mails included in the bug.


Current procedure of subscribing to a bug is an abomination: you need FOUR
mails for something that could be done by default.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: unattended-upgrades by default?

[Samuel Thibault]

Ian Jackson, on Sun 25 Dec 2016 23:45:37 +, wrote:
> Samuel Thibault writes ("Re: unattended-upgrades by default?"):
> > SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
> > > If we replace postgresql with postfix, that is much more closer to the
> > > standard. And I guess, that postgresql is just a "misspelling".
> > 
> > Ew. Yes, sure :)
> 
> Oh!  Well, reading it again then, I think this is a bug (quite a
> serious bug, since it leads to incorrect bouncing of mail) in the
> postfix/mysql integration.

FTR, it's #739636.

Samuel

Fwd: Mail delivery failed: returning message to sender

[TOMAS MARTIŠIUS]

Hello,

Why I can't report bug using reportbug command? After reporting I get 
back e-mail with this message:


Best regards,

Tomas

 Persiųstas laiškas 
Tema:   Mail delivery failed: returning message to sender
Data:   Tue, 27 Dec 2016 19:41:49 +0200
Kas:Mail Delivery System 
Kam:to...@puga.vdu.lt



This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  sub...@bugs.debian.org
host buxtehude.debian.org [209.87.16.39]
SMTP error from remote mail server after end of data:
550 Invalid header syntax:

Reporting-MTA: dns; tarnas.vdu.lt

Action: failed
Final-Recipient: rfc822;submit@bugs.debian.org
Status: 5.0.0
Remote-MTA: dns; buxtehude.debian.org
Diagnostic-Code: smtp; 550 Invalid header syntax:

--- Begin Message ---
Package: reportbug
Version: 7.1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

reportbug GTK interface in fresh debian install with MATE is unusable. First it 
crashes with error:

Gtk-Message: Failed to load module "canberra-gtk-module"
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2233, in 
main()
  File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 2149, in user_interface
package, severity, mode, charset=charset, tags=tags)
  File "/usr/bin/reportbug", line 182, in handle_editing
editor, charset)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1561, in 
func
op = klass(parent)
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 539, in 
__init__
self.widget = self.create_widget()
  File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line 1173, in 
create_widget
expander = Gtk.Expander("Other system information")
TypeError: GObject.__init__() takes exactly 0 arguments (1 given)

Instaling libcanberra-gtk-module looks like solves this error, so I think 
reportbug must have libcanberra-gtk-module
as runtime depenedency. But other error rises trying report bug:

TypeError: Couldn't find foreign struct converter for 'cairo.Context'

Some other dependencies are missing?

Please fix reportbug runtime dependencies.

Best regards,

Tomas

-- Package-specific info:
** /home/tomas/.reportbugrc:
reportbug_version "7.1.1"
mode standard
realname "Tomas Martišius"
email "to...@puga.vdu.lt"
smtphost "tarnas.vdu.lt"

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.1
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88~RC6-2
ii  exim4-daemon-light [mail-transport-agent]  4.88~RC6-2
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.5-1
ii  gir1.2-vte-2.910.46.1-1
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
pn  python3-urwid  
ii  xdg-utils  1.1.1-1

-- no debconf information
--- End Message ---

Re: Thanks to ftpmasters for being so responsive

[Thorsten Alteholz]

Hi Thomas and Ian,

thanks a lot for your kind words.

On Mon, 26 Dec 2016, Thomas Goirand wrote:


However, after the deep freeze, we saw the queue getting bigger and
bigger. The graph for Jessie shows up to 600+ packages in the queue.


For good reasons the Release Team does not want to have packages 
(especially libs) with higher versions in unstable than in testing.
But as everybody still uploads everything to testing, the list of packages 
that are not processable increases. At some point it is no longer fun to 
wade through that list in search of stuff to process. So processing almost 
stops completely.



This was problematic for me. (upstream) Development doesn't stop when
then next stable freeze.


If everybody agrees that
 - new versions of packages shall be only uploaded to experimental
 - uploads to testing will only be done on request of the RT or with
   really new packages
 - everything else can be rejected
processing would be much easier and the fun could go on.

   Thorsten

Re: Can we kill net-tools, please?

[Josh Triplett]

Russell Stuart wrote:
> 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

Thanks, that looks perfect, and it even accepts many of the same option
letters with the same meanings (-t, -u, -4, -6, -a, -l, -p).

- Josh Triplett

Re: Bug#820780: clarify syntax of ‘cancel’ command for queue control

[Ben Finney]

On 27-Dec-2016, James Cowgill wrote:
> On 26/12/16 21:36, Ben Finney wrote:
> >> .commands file has invalid Commands line: cancel 
> >> ../pytest-django_2.9.1-2.1_amd64.changes
> >> debsign: .commands file appears to be invalid. see:
> >> ftp://ftp.upload.debian.org/pub/UploadQueue/README
> >> for valid format
> > 
> > is not very helpful, because the referenced document does not make
> > that constraint plain.

In fact, the “README” document does say:

[…] Except for the DELAYED queue (see below) filenames may not
contain slashes (so that they're restricted to the queue
directory). […]

embedded in the paragraph explaining the syntax of commands.

> On the archive side, arguments to 'cancel' must match this regex: […]
> Forward slash is not in the regex, so paths are disallowed.

Thanks.

-- 
 \   “Why, I'd horse-whip you if I had a horse.” —Groucho Marx |
  `\   |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849494: ITP: libproc-guard-perl -- process runner with RAII pattern

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libproc-guard-perl
  Version : 0.07
  Upstream Author : Tokuhiro Matsuno 
* URL : https://metacpan.org/release/Proc-Guard
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : process runner with RAII pattern

Proc::Guard runs a process, and destroys it when the calling perl script
exits.

This is useful for testing code working with e.g. server processes.

The package will be maintained under the umbrella of the Debian Perl Group.


signature.asc
Description: Digital Signature

Bug#849497: ITP: ruby-whitequark-parser -- Ruby parser written in pure Ruby

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: ruby-whitequark-parser
  Version : 2.3.3.1
  Upstream Author : Peter Zotov 
* URL : https://github.com/whitequark/parser
* License : Expat
  Programming Lang: Ruby
  Description : Ruby parser written in pure Ruby

 parser is a production-ready Ruby parser written in pure Ruby. It
 recognizes as much or more code than Ripper, Melbourne, JRubyParser
 or ruby_parser, and is vastly more convenient to use.
 .
 Among its keys features are: it provides precise source location
 reporting, it has a documented AST format which is convenient to work
 with, it parses 1.8, 1.9, 2.0, 2.1, 2.2 and 2.3 syntax with
 backwards-compatible AST formats and also parses MacRuby and
 RubyMotion syntax extensions. It also has improved clang-like
 diagnostic messages with location information.
 .
 Since it's written in pure Ruby, runs on MRI 1.8.7 or >=1.9.2, JRuby
 and Rubinius, it has excellent test coverage and the source code is
 readable and well commented.
 .
 Not to be confused with ruby_parser gem from Ryan Davis, of seattle.rb
 Ruby user group.

Needed as dependency of rubocop.
To be maintained in the Ruby team.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Bug#849496: ITP: ruby-ast -- Ruby library for working with abstract syntax trees

[Miguel Landaeta]

Package: wnpp
Severity: wishlist
Owner: Miguel Landaeta 

* Package name: ruby-ast
  Version : 2.3.0
  Upstream Author : Peter Zotov 
* URL : https://github.com/whitequark/ast
* License : Expat
  Programming Lang: Ruby
  Description : Ruby library for working with abstract syntax trees

 ast embraces immutability; each AST node is inherently frozen at
 creation, and updating a child node requires recreating that node
 and its every parent, recursively.
 .
 This is a design choice. It does create some pressure on
 garbage collector, but completely eliminates all concurrency
 and aliasing problems.
 .
 See also AST::Node, AST::Processor::Mixin and AST::Sexp classes for
 additional recommendations and design patterns.

Needed as a dependency of ruby-whitequark-parser.
To be maintained in the Ruby team.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: Digital signature

Re: Thanks to ftpmasters for being so responsive

[Ian Jackson]

Thorsten Alteholz writes ("Re: Thanks to ftpmasters for being so responsive"):
> On Mon, 26 Dec 2016, Thomas Goirand wrote:
> > This was problematic for me. (upstream) Development doesn't stop when
> > then next stable freeze.
> 
> If everybody agrees that
>   - new versions of packages shall be only uploaded to experimental
>   - uploads to testing will only be done on request of the RT or with
> really new packages
>   - everything else can be rejected
> processing would be much easier and the fun could go on.

Certainly I wouldn't upload an update to sid that I didn't intend for
what-is-currently-testing, even during the deep freeze.

And obviously any upload to sid, intended for testing, would only make
sense if I expected it to migrate, according to whatever applicable
freeze policies.  During the deep freeze that would often involve
release@ approval.  (An obvious exception is that I wouldn't usually
seek release@ preapproval for a properly minimal RC bugfix upload,
whether NMU or otherwise, but that's not what we're talking about
here.)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#849511: general: java and javac can't run , it said "java: error while loading shared libraries: libjli.so",

[Jason.katcom]

Package: general
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 8.6
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=zh_HK.UTF-8, LC_CTYPE=zh_HK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Re: Can we kill net-tools, please?

[Wookey]

On 2016-12-27 09:15 +0100, Andrew Shadura wrote:
> While I can certainly agree parsing net-tools output isn't a good idea, please
> stop suggesting we should remove the package from Debian. It is still useful
> and many people myself included use it.

Right, I use it most days. For those of us of a certain vintage this
is the networking tool we know. The chap who gave a talk at the UK
miniconf about updated functionality in /etc/network/interfaces and
ifconfig and friends got rapturous applause, so I'm not the only one
that finds this useful.

If we are supposed to change to something newer these days, a pointer
to a 'conversion' document would be nice. I am (vaguely) aware of
something caled 'ip' which does a similar job but have no idea how to
use it.

Like Andrew I don't like the tone of these 'get rid of this crap'
messages. It may not be your tool of choice, but it is some people's
(probbly quite a lot of people still) and I'm very happy that it's
there by default as networking-furtling is something one is often
doing on a bare system. If there is a desire to change the default
package I'd like to see a little more discussion about that.

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


signature.asc
Description: Digital signature

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: unattended-upgrades by default?

[Scott Kitterman]

On December 27, 2016 1:26:24 PM EST, Samuel Thibault  
wrote:
>Ian Jackson, on Sun 25 Dec 2016 23:45:37 +, wrote:
>> Samuel Thibault writes ("Re: unattended-upgrades by default?"):
>> > SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
>> > > If we replace postgresql with postfix, that is much more closer
>to the
>> > > standard. And I guess, that postgresql is just a "misspelling".
>> > 
>> > Ew. Yes, sure :)
>> 
>> Oh!  Well, reading it again then, I think this is a bug (quite a
>> serious bug, since it leads to incorrect bouncing of mail) in the
>> postfix/mysql integration.
>
>FTR, it's #739636.
>
Postfix has no way to know it's temporary, so I think a temporary error would 
be wrong.

Better to have postfix notice that a map type has been pulled out from under it 
and stop (what you have to do by hand now).

Scott K

Re: unattended-upgrades by default?

[Adam Borowski]

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

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: unattended-upgrades by default?

[Scott Kitterman]

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.

Scott K

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Steve M. Robbins]

Fully support Ian's proposed change.

I've been around Debian for 16 years and I STILL find this behaviour irritating 
because it is contrary to my expectations.

-Steve


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

Re: Can we kill net-tools, please?

[Scott Leggett]

On 2016-12-26.14:50, Marco d'Itri wrote:
> Can we stop shipping two network configuration CLI tools in the default 
> install?
> net-tools has long been deprecated and should not have important 
> priority, for a start.

Yes, please!

FWIW, Red Hat did this in 2014 for RHEL7. Discussion here:
https://bugzilla.redhat.com/show_bug.cgi?id=1119297

-- 
Regards,
Scott.


signature.asc
Description: PGP signature

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

[Ben Finney]

Howdy all,

I recently donned the mantle of maintaining ‘dput’ and am carefully
making improvements. I am conscious of the special need for backward
compatibility so I am taking care to understand how the Debian developer
community uses it today.

So I'm now familiar enough, but still fresh enough, that feedback from
people with different experiences is particularly valuable.


What does ‘dput’ do that you think really should not be changed?

What does ‘dput’ do that you wish it would stop doing?

What do other tools do better than ‘dput’? Do you think that ‘dput’
should change to do those tasks the same way?


The same questions can be asked of the ‘dcut’ program from the same
package.

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.

Both newcomers and old hands are welcome to give responses on these
questions.

-- 
 \“Good judgement comes from experience. Experience comes from |
  `\  bad judgement.” —Frederick P. Brooks |
_o__)  |
Ben Finney

Re: unattended-upgrades by default?

[Adam Borowski]

On Wed, Dec 28, 2016 at 04:13:13AM +, 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.

It should be treated akin to "no target MXes are reachable" -- ie, a
temporary error that is considered permanent once a timeout has been
reached.  Retries and the timeout are implemented and configured by the
sending server.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

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

[Afif Elghraoui]

Hi, Ben,

على الثلاثاء 27 كانون الأول 2016 ‫20:31، كتب Ben Finney:
> Howdy all,
> 
> I recently donned the mantle of maintaining ‘dput’ and am carefully
> making improvements. I am conscious of the special need for backward
> compatibility so I am taking care to understand how the Debian developer
> community uses it today.
> 

Many thanks for soliciting users' perspectives. I think this isn't done
as often as it should be, so I very much appreciate it.

> So I'm now familiar enough, but still fresh enough, that feedback from
> people with different experiences is particularly valuable.
> 
> 
> What does ‘dput’ do that you think really should not be changed?
> 
> What does ‘dput’ do that you wish it would stop doing?
> 
> What do other tools do better than ‘dput’? Do you think that ‘dput’
> should change to do those tasks the same way?
> 
> 
> The same questions can be asked of the ‘dcut’ program from the same
> package.
> 
> 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. That works well, but the dput
command from dput-ng does some spurious checks that fail and I've never
found worth the time to investigate. What I end up doing (since it
doesn't happen very frequently) is switching back to plain dput, which
simply does the job. If I ever have to grant upload permissions, I
install dput-ng, do the dcut dm, then install plain dput again.

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

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Harlan Lieberman-Berg]

Ian Jackson  writes:
>  * I was overly concerned that submitters ought not to be troubled by
>Debian-internal communications about their bug.

I think part of the confusion and dissent here is that there are two
intersecting-but-non-equal mental models of who the submitters are that
lead to two different solutions.

One model is that the submitters are purely "users" --- people who may
not have an interest in the inner workings of a technical issue but
simply want it fixed.  These people are best served by the current
behavior of debbugs: they get mail specifically directed to them, and
they get mail when the problem is fixed.  If they want to check up on
the progress, they are able to check the web-UI, or intentionally opt-in
to the (potentially) higher-volume of email by subscribing.

The second model is that submitters are "contributors" --- that bug
filing is, itself, part of the development cycle.  These people are more
likely to want to be involved in the process itself, and may actively be
working towards solutions.

Both of these models are, to some degree, strawmen; I frequently file
bugs which are simply FYIs to the maintainer of some problem I ran into
and was able to work around somehow, but I equally often are filing bugs
I care deeply about and want to help shepherd towards resolution.

Perhaps there's some happy medium here?  An easier way to opt-in to
subscription to a bug at submission time?  Automatic subscription to a
bug of those who mail @b.d.o, rather than -quiet@
or submit@?

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Re: HEADSUP: mails sent to n...@bugs.debian.org are NOT sent to the submitter

[Russ Allbery]

Harlan Lieberman-Berg  writes:

> One model is that the submitters are purely "users" --- people who may
> not have an interest in the inner workings of a technical issue but
> simply want it fixed.  These people are best served by the current
> behavior of debbugs: they get mail specifically directed to them, and
> they get mail when the problem is fixed.  If they want to check up on
> the progress, they are able to check the web-UI, or intentionally opt-in
> to the (potentially) higher-volume of email by subscribing.

> The second model is that submitters are "contributors" --- that bug
> filing is, itself, part of the development cycle.  These people are more
> likely to want to be involved in the process itself, and may actively be
> working towards solutions.

I agree in the abstract, but I do think it's also worth noting that
basically every other bug reporting system I'm aware of defaults to
sending all updates to the bug reporter.  So while a good theoretical case
can be made for both models, the weight of expectation around how bug
reports work is pretty overwhelmingly towards the second.

That doesn't mean we need to follow everyone else, but I think it does
mean we should have good reasons for not following everyone else.  It will
be a point of ongoing surprise and confusion, so we should probably do the
same thing everyone else does unless we have some clear and defensible
reason to not do so.

(We do have the problem that, unlike nearly all other bug tracking
systems, we don't manage any sort of "account" for the bug submitter.  I
think that's a huge feature of debbugs, but it means that people can't
easily change their email address on their account and have that affect
all subsequent updates, or delete their account to unsubscribe from all
bugs in one go.)

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

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

[Russ Allbery]

Ben Finney  writes:

> What does ‘dput’ do that you think really should not be changed?

> What does ‘dput’ do that you wish it would stop doing?

> What do other tools do better than ‘dput’? Do you think that ‘dput’
> should change to do those tasks the same way?

I'm not the best person to give feedback on dput since I switched over to
dput-ng completely and have never looked back.  But I suppose that's a
data point from one user who greatly appreciates the changes in dput-ng
and would be happy to have that be the default dput.

I am kind of meh on the JSON configuration format for dput-ng, though.

I have never managed to work out how to use dcut (from either dput or
dput-ng) 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.  Usually I manage to find some way to name the wrong
thing in the command, refer to it incorrectly, or pick the wrong way to do
whatever I'm trying to do.  And I use it so rarely that I never remember
what mistakes I made the next time I try.

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

Re: Fwd: Mail delivery failed: returning message to sender

[Andreas Metzler]

On 2016-12-27 TOMAS MARTIŠIUS  wrote:
> Hello,

> Why I can't report bug using reportbug command? After reporting I get back
> e-mail with this message:

[...]
> Remote-MTA: dns; buxtehude.debian.org
> Diagnostic-Code: smtp; 550 Invalid header syntax:

The From header does not look too good:

> From: =?utf-8?b?VG9tYXMgTWFydGnFoWl1cyA8dG9tYXNAcHVnYS52ZHUubHQ+?=

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'