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

[Ritesh Raj Sarraf]

Hello,

On Mon, 2016-12-26 at 14:56 -0200, Samuel Henrique wrote:
> I didn't know that, fortunately i didn't ended in a situation where i needed
> feedback from the bug submitter.
> 
> But the question is, shouldn't the bot forward to the submitter?
> 

I've run into this problem in the past. Quick and immediate fix was to add the
setting in reportbug to CC the reporter. If I remember correct, something like:
X-Debbugs-CC:


> Samuel Henrique 
> 
> 2016-12-26 14:29 GMT-02:00 Samuel Thibault :
> > 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.
> > 
> > I don't know how it happens that maintainers get to reply only to
> > n...@bugs.debian.org , my only guess is that they just don't know that
> > it's not sufficient to mail the bug, so I guess the only solution is to
> > repeat it over and over :/
> > 
> > Samuel
> > 
> > 
> 
> 
-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response

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

wanna-build doesn't email the maintainer on build failures by default

[Emilio Pozuelo Monfort]

On 26/12/16 17:29, Samuel Thibault wrote:
> 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.

Somewhat related, and something I think ought to be changed... wanna-build
doesn't email the maintainer when a package fails to build... you have to
explicitly subscribe to buildd failures in the PTS. I think we should change
that, and instead make this opt-out.

Doing release work, I usually find packages that have FTBFS issues on release
architectures where they built before (so RC bugs) for quite a while, with no
open bug report and no sign of activity. I think we should change this so
maintainers are aware of buildd issues early.

Thoughts?

Cheers,
Emilio

Re: wanna-build doesn't email the maintainer on build failures by default

[Philipp Kern]

On 12/31/2016 09:58 AM, Emilio Pozuelo Monfort wrote:
> Somewhat related, and something I think ought to be changed... wanna-build
> doesn't email the maintainer when a package fails to build... you have to
> explicitly subscribe to buildd failures in the PTS. I think we should change
> that, and instead make this opt-out.

It's not "explicitly subscribe to buildd failure" AIUI, but "subscribe
to the package". I.e. it's part of the default set of tags and anyone
who was subscribed to "default" when the buildd was added got it added
to their subscription.

Kind regards
Philipp Kern

Re: wanna-build doesn't email the maintainer on build failures by default

[Emilio Pozuelo Monfort]

On 31/12/16 10:40, Philipp Kern wrote:
> On 12/31/2016 09:58 AM, Emilio Pozuelo Monfort wrote:
>> Somewhat related, and something I think ought to be changed... wanna-build
>> doesn't email the maintainer when a package fails to build... you have to
>> explicitly subscribe to buildd failures in the PTS. I think we should change
>> that, and instead make this opt-out.
> 
> It's not "explicitly subscribe to buildd failure" AIUI, but "subscribe
> to the package". I.e. it's part of the default set of tags and anyone
> who was subscribed to "default" when the buildd was added got it added
> to their subscription.

Hmm. Maybe the issue is when you don't subscribe to the PTS because you're the
maintainer, or the maintainer is a team and you're subscribed to the team
mailing list. In those cases, neither the team nor you are subscribed to the PTS
directly because the BTS, dak, etc email the Maintainer directly... but then you
miss wanna-build mails... is that right?

Cheers,
Emilio

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

[Toni Mueller]

Hi Evgeni,

On Fri, Dec 30, 2016 at 10:44:50PM +0100, Evgeni Golov wrote:
> On Fri, Dec 30, 2016 at 12:58:02AM +0100, Toni Mueller wrote:
> > 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.
> 
> Which source is this built from?
> Do you basically want a mirror of https://docs.ansible.com/ansible/ in
> a Debian package?

I am building from a git clone of the ansible repository, and, more
specifically, from the tag v2.2.0.0-1.

> > Yours truly frequently suffers under bad network conditions, which make
> > reading the website infeasible or outright impossible, so I think the
> > package is useful.
> 
> If it is more than ansible-doc , then it certainly is.

My network conditions vary greatly, but too frequently, they are not
good enough to access anything on the Internet. Working on that, but
still, having a local copy of everything is very desirable from my POV.

> I just wonder whether it is sensible to built it from an own source,
> and not from the ansible source itself.

I found a very easy way to build everything from the ansible source, at
least for this tag.


Cheers,
--Toni++

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

[W. Martin Borgert]

On 2016-12-31 10:52, Toni Mueller wrote:
> I am building from a git clone of the ansible repository, and, more
> specifically, from the tag v2.2.0.0-1.

Then why not make an additional binary package from the same
source package? This way ansible and its documentation would
not get out of sync.

> My network conditions vary greatly, but too frequently, they are not
> good enough to access anything on the Internet. Working on that, but
> still, having a local copy of everything is very desirable from my POV.

Bad network conditions are not the only reason to want to able
to access manuals locally: No network at all, expensive network,
privacy concerns, custom search over the local copy ("grep").

I found it always an advantage of Debian, that we have -doc
packages for almost everything.

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

Bug#849809: ITP: libtest-unixsock-perl -- test module for UNIX domain sockets

[Christopher Hoskin]

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

* Package name: libtest-unixsock-perl
  Version : 0.1
  Upstream Author : Fujiwara Shunichiro 
* URL : https://metacpan.org/release/Test-UNIXSock
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : test module for UNIX domain sockets

Test::UNIXSock is a test utility to test UNIX domain socket server programs.

It is based on Test::TCP.

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

Bug#849811: ITP: fonts-apropal -- Sans-serif font for decorative signs, one of the Warsaw Types

[Dominik Danelski]

Package: wnpp
Severity: wishlist
Owner: Dominik Danelski 

* Package name: fonts-apropal
  Version : 1.0
  Upstream Author : Rafał Buchner 
* URL : https://github.com/warszawskie-kroje/apropal
* License : SIL Open Font License
  Programming Lang: None
  Description : Sans-serif font for decorative signs, one of the Warsaw
Types

Apropal is a sans-serif display font for decorative signs (including vertical).
It contains one style variation - BOLD. Being one of the types included in the
Warsaw Types collection: a set made by professionals based on the Warsaw's
typography heirtage with a support of the Museum of Warsaw and the City of
Warsaw, it is inspired by the “Czytelnik” bookstore, the information signs
from Warsaw’s Zoo, and designs found in the “Lettering Techniques” book
manual, by Jan Wojeński. More information and the possibility to try the font
can be found on the web page (http://kroje.org/en/fonts/apropal/).

Why it should be included in Debian?
It is one of the types included in the Warsaw Types collection: a set made by
professionals based on the Warsaw's typography heritage with a support of the
Museum of Warsaw and the City of Warsaw, so they are not a simple remake of
some popular fonts.

Maintaining the package.
Font packages with none or little updates should be easy to maintain even for a
beginner.

Re: Can we kill net-tools, please?

[Joerg Jaspert]

On 14533 March 1977, Marco d'Itri wrote:

dak override net-tools net optional
I: Will change priority from important to optional
Continue (y/N)? y

dak override iproute2
iproute2 is in section 'net' at priority 'important'

Whoever wants net-tools can have it by simply installing it - or getting
it by one of its rev-deps/recommends, which isn't a short list either.

-- 
bye, Joerg

Bug#849812: ITP: requests-ntlm -- HTTP NTLM authentication using the requests library

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: requests-ntlm
  Version : 1.0.0
  Upstream Author : Ben Toews  et al
* URL : https://github.com/requests/requests-ntlm
* License : ISC
  Programming Lang: Python
  Description : HTTP NTLM authentication using the requests library

HttpNtlmAuth can be used in conjunction with a Session in order to make
use of connection pooling. Since NTLM authenticates connections, this
is more efficient. Otherwise, each request will go through a new NTLM
challenge-response.

This is a new dependency of pywinrm, and will be maintained as part of
the Python Modules Team.

Re: wanna-build doesn't email the maintainer on build failures by default

[Sean Whitton]

On Sat, Dec 31, 2016 at 10:46:51AM +0100, Emilio Pozuelo Monfort wrote:
> Hmm. Maybe the issue is when you don't subscribe to the PTS because you're the
> maintainer, or the maintainer is a team and you're subscribed to the team
> mailing list. In those cases, neither the team nor you are subscribed to the 
> PTS
> directly because the BTS, dak, etc email the Maintainer directly... but then 
> you
> miss wanna-build mails... is that right?

Yes.

Why not just have wanna-build e-mail the Maintainer: address, like
everything else does?  I was not even aware that wanna-build sent any
e-mails at all :)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: wanna-build doesn't email the maintainer on build failures by default

[Mattia Rizzolo]

On Sat, Dec 31, 2016 at 12:33:51PM +, Sean Whitton wrote:
> Why not just have wanna-build e-mail the Maintainer: address, like
> everything else does?  I was not even aware that wanna-build sent any
> e-mails at all :)

I'd rather have wanna-build to keep its current behaviour¹ to email
dispa...@tracker.debian.org²³, and have BTS, dak, and all other tool
stop to email Maintainer directly, eventually finally implementing
DEP-2⁴.



¹ which, btw, is not reliable; it seems to me it emails only for few
  architectures and even important ones like 'all' cause emails
² wow, I didn't notice this was already updated from the old PTS!
³ 
https://www.debian.org/doc/manuals/developers-reference/ch04.en.html#pkg-tracker
⁴ http://dep.debian.net/deps/dep2/

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: wanna-build doesn't email the maintainer on build failures by default

[Philipp Kern]

On 12/31/2016 02:05 PM, Mattia Rizzolo wrote:
> I'd rather have wanna-build to keep its current behaviour¹ to email
> dispa...@tracker.debian.org²³, and have BTS, dak, and all other tool
> stop to email Maintainer directly, eventually finally implementing
> DEP-2⁴.
> 
> ¹ which, btw, is not reliable; it seems to me it emails only for few
>   architectures and even important ones like 'all' cause emails

I can't parse this. Spot checking
wuiet:/srv/buildd.debian.org/log/inject looks fine to me (ingested
failed logs vs. run-mqueue's output). The excludes are configured in
/srv/buildd.debian.org/etc/buildlogs.conf and do not list all (but
various unofficial ports). Maybe you could argue that kfreebsd-* should
be in there as well, but that's a different discussion.

Kind regards
Philipp Kern

Re: wanna-build doesn't email the maintainer on build failures by default

[Mattia Rizzolo]

On Sat, Dec 31, 2016 at 02:15:46PM +0100, Philipp Kern wrote:
> On 12/31/2016 02:05 PM, Mattia Rizzolo wrote:
> > I'd rather have wanna-build to keep its current behaviour¹ to email
> > dispa...@tracker.debian.org²³, and have BTS, dak, and all other tool
> > stop to email Maintainer directly, eventually finally implementing
> > DEP-2⁴.
> > 
> > ¹ which, btw, is not reliable; it seems to me it emails only for few
> >   architectures and even important ones like 'all' cause emails

[ here I missed a 'not', as in I 'all don't cause emails' ]

> I can't parse this. Spot checking
> wuiet:/srv/buildd.debian.org/log/inject looks fine to me (ingested
> failed logs vs. run-mqueue's output). The excludes are configured in
> /srv/buildd.debian.org/etc/buildlogs.conf and do not list all (but
> various unofficial ports).

umh, indeed.  And according to the log I see that failures for 'all' are
sent as well.  I'll double check my subscription again, as I'm sure I
didn't get arch:all failures email that I'd have expected.

> Maybe you could argue that kfreebsd-* should
> be in there as well, but that's a different discussion.

well, I'm very much fine with kbsd not being in that list (and
personally I'd be happy to not have any arch excluded).
But you should probably remove mips64el, which is a release arch now.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#849820: ITP: libnet-cisco-mse-rest-perl -- REST interface for Cisco MSE

[Christopher Hoskin]

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

* Package name: libnet-cisco-mse-rest-perl
  Version : 0.2
  Upstream Author : Fabrice Durand 
* URL : https://metacpan.org/release/Net-Cisco-MSE-REST
* License : GPL-3+
  Programming Lang: Perl
  Description : REST interface for Cisco MSE

Net::Cisco::MSE::REST provides a Perl interface for communication with Cisco
Mobility Services Engine (MSE) using the REST interface.

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

Re: auto-removal and alternative dependencies

[Sergei Golovan]

Hi!

On Thu, Dec 8, 2016 at 3:22 PM, Emilio Pozuelo Monfort  wrote:
> On 08/12/16 13:02, Daniel Pocock wrote:
>> I have two packages that depend on: nagios3 | icinga
>>
>> nagios3 is being removed[1], but icinga[2] is still available, so why
>> can't my packages continue to list nagios3 as a possible dependency for
>> the convenience of those people who continue to use it?
>
> I would need to check the code, but the auto-remover probably checks the first
> dependency and ignores the rest (just like e.g. wanna-build and britney). So 
> you
> could just swap them and make that: icinga | nagios3.

Looks like there's another consequence of this: libtk-img and itk3 are
now marked
for autoremoval from stretch because they depend on the virtual package libtk
which is provided by libtk8.4, libtk8.5 and libtk8.6, and likely only
the first dependency
in lexicographic order is checked.

Should I report a bug? Where?

Cheers!
-- 
Sergei Golovan

Re: auto-removal and alternative dependencies

[Sven Joachim]

On 2016-12-31 17:42 +0300, Sergei Golovan wrote:

> On Thu, Dec 8, 2016 at 3:22 PM, Emilio Pozuelo Monfort  
> wrote:
>> On 08/12/16 13:02, Daniel Pocock wrote:
>>> I have two packages that depend on: nagios3 | icinga
>>>
>>> nagios3 is being removed[1], but icinga[2] is still available, so why
>>> can't my packages continue to list nagios3 as a possible dependency for
>>> the convenience of those people who continue to use it?
>>
>> I would need to check the code, but the auto-remover probably checks the 
>> first
>> dependency and ignores the rest (just like e.g. wanna-build and britney). So 
>> you
>> could just swap them and make that: icinga | nagios3.
>
> Looks like there's another consequence of this: libtk-img and itk3 are
> now marked
> for autoremoval from stretch because they depend on the virtual package libtk
> which is provided by libtk8.4, libtk8.5 and libtk8.6, and likely only
> the first dependency
> in lexicographic order is checked.
>
> Should I report a bug? Where?

No need to do so, this has been filed[1] quite some time ago already.

Cheers,
   Sven


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

Re: wanna-build doesn't email the maintainer on build failures by default

[Paul Wise]

On Sat, Dec 31, 2016 at 9:23 PM, Mattia Rizzolo wrote:

> But you should probably remove mips64el, which is a release arch now.

Not hard-coding the list of release architectures would be best.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[Harlan Lieberman-Berg]

"W. Martin Borgert"  writes:
> Then why not make an additional binary package from the same
> source package? This way ansible and its documentation would
> not get out of sync.

Unfortunately, we don't build ansible off of the git repository, but
rather from the released tarballs.  (The version in upstream's git
requires much more extensive dfsg cleanup, and would until recently have
required the bundling of multiple upstream repositories together.)

It's been a while since we made the decision not to pull from upstream's
git; Toni, I'd be happy to work with you on seeing if it's doable now.

Sincerely,
-- 
Harlan Lieberman-Berg
~hlieberman

Re: Migration despite an RC bug?

[Don Armstrong]

On Sat, 31 Dec 2016, Ian Jackson wrote:

> Don Armstrong writes ("Re: Migration despite an RC bug?"):
> > I'm still not quite sure how the script was failing. The outer shell
> > invocation which calls a perl script to do the versioning database
> > update is run with set -e, and the perl script should exit with non-zero
> > if it fails to work properly. However, it appears that when buxtehude is
> > restarted, the perl script is killed before the outer bash script
> > completes but the exit state isn't properly handled?
> 
> I've debugged a lot of this kind of thing.  Point me at your
> (pre-just-fixed) code and I might spot it ?

These two are how I think I've fixed it:

http://git.donarmstrong.com/?p=debbugs.git;a=commitdiff;h=29b55e4d5535a68cc6d2294f5c362d271b53c6d2
http://git.donarmstrong.com/?p=debbugs.git;a=commitdiff;h=d83ffb68f75ae98ad5005eee9b173d5dac08c343

[I believe I exposed this bug because I switched to IO::Uncompress,
which is incredibly slow; I've now switched relevant pieces of code
back.]

> That may well help. Or maybe the bug is in a higher layer somewhere.
> Are HTTP and CGI involved ?

No; it's happening at the updating the versioning database level.


-- 
Don Armstrong  https://www.donarmstrong.com

All bad precedents began as justifiable measures.
 -- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust

yf(6):

[CHESTER PHILLIPS]

http://lagiostradelmonaco.it/epaialy.php






























A people that values its privileges above its principles soon loses 
both.Margareta Oregon

Bug#849842: ITP: ykush-control -- control application for Yepkit YKUSH Switchable USB Hub board

[Christoph Biedl]

Package: wnpp
Severity: wishlist
Owner: Christoph Biedl 

* Package name: ykush-control
  Version : 1.0.0
  Upstream Author : 2015-2016 Yepkit Lda
* URL : https://github.com/Yepkit/ykush
* License : MIT
  Programming Lang: C++
  Description : control application for Yepkit YKUSH Switchable USB Hub 
board

 The Yepkit USB Switchable Hub (YKUSH) boards allow the user to
 selectively switch ON and OFF each of the USB devices connected to the
 hub downstream ports. This package provides the ykushcmd program to
 control the switches of all connected boards.



signature.asc
Description: Digital signature