Re: depending on libssl1.0-dev, buildd fails to find it

[Daniel Pocock]

On 17/12/16 17:40, Christian Seiler wrote:
> On 12/17/2016 04:49 PM, Daniel Pocock wrote:
>> In my reSIProcate control[1] file, I included the following:
>>
>> Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ...
>>
>> pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2]
>>
>> In the buildd[3] report, it says that libssl-dev is uninstallable on
>> every platform, it doesn't appear to try libssl1.0-dev
>>
>> Is buildd sensitive to the order of the dependencies when multiple
>> options are given?  Or is there some other glitch here?
> 
> sbuild will always use the first alternative of build
> dependencies. If you're doing this to make backporting easier,
> then I'm afraid that won't work - you'll have to manually
> change the B-D for backports.
> 

I'm really hoping to focus my energy on upstream dev and reduce the
effort for packaging.  Adding another extra step for supporting
backports doesn't feel good.

Multiply this extra effort over all the packages that people backport
and the net effect is that some people will stop backporting or will do
it more slowly and the number of up-to-date backports we have may be
slightly less than what it otherwise would be.

There are similar problems with the change from libmysqlclient-dev to
default-libmysqlclient-dev.

Is it possible for a stable update of the jessie version of openssl to
add something like this:

Provides: libssl1.0-dev

in the control file and would that ensure it works without tweaks?

Regards,

Daniel

Bug#848649: ITP: node-gulp-plumber -- Prevent pipe breaking caused by errors from gulp plugins

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-gulp-plumber
  Version : 1.1.0
  Upstream Author : Vsevolod Strukchinsky 
(https://github.com/floatdrop)
* URL : https://github.com/floatdrop/gulp-plumber
* License : Expat
  Programming Lang: JavaScript
  Description : Prevent pipe breaking caused by errors from gulp plugins



signature.asc
Description: OpenPGP digital signature

Bug#848650: ITP: node-kew -- lightweight promise library for node

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-kew
  Version : 0.7.0
  Upstream Author : FIX_ME upstream author
* URL : https://github.com/Medium/kew
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : a lightweight promise library for node



signature.asc
Description: OpenPGP digital signature

Bug#848651: ITP: node-gulp-newer -- Only pass through newer source files

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-gulp-newer
  Version : 1.3.0
  Upstream Author : Tim Schaub (http://tschaub.net/)
* URL : https://github.com/tschaub/gulp-newer
* License : Expat
  Programming Lang: JavaScript
  Description : Only pass through newer source files



signature.asc
Description: OpenPGP digital signature

which JavaScript dependencies really need a separate package?

[Daniel Pocock]

I had a look at packaging homer-ui (ITP[1]) for HOMER[2].  It is a
powerful web application based on AngularJS for troubleshooting SIP
applications.  It is particularly useful for troubleshooting many of the
SIP products we include in Debian and also for learning about SIP, SDP
and RTP.

There are a lot of JavaScript libraries included, most from the
AngularJS world, and it is unlikely I would personally make a package of
every one that doesn't already exist in Debian.

I opened an RFP bug for each and used those to block the HOMER ITP bug
so I will see if other people package any of the dependencies for other
projects.  If the list of outstanding things becomes smaller I may step
in to get the remaining ones packaged.

- While looking through the list, I noticed that some of them (or at
least files with similar names) are also included within other web
packages.  What is the latest opinion on when JavaScript libs can be
included in a web application package?

- For those JavaScript libs that have complicated build systems that are
not (yet) supported on Debian, is it reasonable for a package like
homer-ui to simply include the intermediate product of the build, just
before it is minified, into the Debian source package?  This may not be
the "preferred form of modification", but it is not difficult to make
modifications to it.

- The FTP masters have also expressed concern about the standalone
packaging of very small[3] JavaScript dependencies.  Is that still the
same for stretch and beyond?

Regards,

Daniel



1. https://bugs.debian.org/837662
2. http://sipcapture.org/
3.
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2015-June/010692.html

Re: which JavaScript dependencies really need a separate package?

[Paul Gevers]

Hi Daniel,

On 19-12-16 09:30, Daniel Pocock wrote:
> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into the Debian source package?  This may not be
> the "preferred form of modification", but it is not difficult to make
> modifications to it.

The ftp-masters have been very clear on this¹.

> - The FTP masters have also expressed concern about the standalone
> packaging of very small[3] JavaScript dependencies.  Is that still the
> same for stretch and beyond?

And have accepted that having these small packages is the price that has
to be paid for their firm statement.

Paul
¹ https://lists.debian.org/debian-ctte/2016/10/msg00066.html



signature.asc
Description: OpenPGP digital signature

Re: which JavaScript dependencies really need a separate package?

[Joerg Jaspert]

On 14526 March 1977, Daniel Pocock wrote:

> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into the Debian source package?  This may not be
> the "preferred form of modification", but it is not difficult to make
> modifications to it.

Thats simple to answer by reading
https://lists.debian.org/debian-ctte/2016/10/msg00066.html

What you proposed is not source (first point), so has no place in main.
You may be able to follow the second point.

> - The FTP masters have also expressed concern about the standalone
> packaging of very small[3] JavaScript dependencies.  Is that still the
> same for stretch and beyond?

Small packages are bad. Sometimes they may make sense, sometimes another
environment sucks really bad and the best way for us is to deal with it.

-- 
bye, Joerg

Re: which JavaScript dependencies really need a separate package?

[Sean Whitton]

Hello Daniel,

There has been extensive discussion of this on debian-devel over the
past few months.  Though it was mainly about nodejs libs, the discussion
applies to libjs-* packages too.

The outcome of the discussions:

- the advantages of packaging these libs separately outweigh the
  disadvantages

- you must package the "complicated build systems" to which you refer.
  The ftp-masters have been explicit about this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: which JavaScript dependencies really need a separate package?

[Ben Finney]

Daniel Pocock  writes:

> - While looking through the list, I noticed that some of them (or at
> least files with similar names) are also included within other web
> packages.

Those packages would be similarly buggy in Debian, if so.

> What is the latest opinion on when JavaScript libs can be included in
> a web application package?

In addition to the FTP Master position statement discussed elsewhere in
this thread, there is also the principle that separate works with their
own separate release schedules should not be in a single Debian source
package.

-- 
 \ “Are you pondering what I'm pondering?” “I think so, Brain, but |
  `\why would anyone want a depressed tongue?” —_Pinky and The |
_o__)   Brain_ |
Ben Finney

Bug#848658: ITP: r-cran-prettyunits -- GNU R pretty, human readable formatting of quantities

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-prettyunits
  Version : 1.0.2
  Upstream Author : Gabor Csardi 
* URL : https://cran.r-project.org/package=prettyunits
* License : MIT
  Programming Lang: GNU R
  Description : GNU R pretty, human readable formatting of quantities
 Pretty, human readable formatting of quantities.
 Time intervals: 1337000 -> 15d 11h 23m 20s.
 Vague time intervals: 2674000 -> about a month ago.
 Bytes: 1337 -> 1.34 kB.


Remark: This package is a precondition for r-cran-progress which
in turn is needed to upgrade r-cran-rncl to its latest upstream
version.  The package will be maintained by the Debian Med team at

svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-prettyunits/trunk/

Bug#848659: ITP: r-cran-progress -- GNU R terminal progress bars

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-progress
  Version : 1.1.2
  Upstream Author : Gábor Csárdi 
* URL : https://cran.r-project.org/package=progress
* License : MIT
  Programming Lang: GNU R
  Description : GNU R terminal progress bars
 Configurable Progress bars for GNU R, they may include percentage,
 elapsed time, and/or the estimated completion time. They work in
 terminals, in 'Emacs' 'ESS', 'RStudio', 'Windows' 'Rgui' and the
 'macOS' 'R.app'. The package also provides a 'C++' 'API', that works
 with or without 'Rcpp'.


Remark: This package is a precondition to upgrade r-cran-rncl to
the latest upstream version.  It will be maintained by the Debian
Med team at
   svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-progress/trunk/

Re: which JavaScript dependencies really need a separate package?

[Paul Wise]

On Mon, Dec 19, 2016 at 4:30 PM, Daniel Pocock wrote:

> - For those JavaScript libs that have complicated build systems that are
> not (yet) supported on Debian, is it reasonable for a package like
> homer-ui to simply include the intermediate product of the build, just
> before it is minified, into the Debian source package?  This may not be
> the "preferred form of modification", but it is not difficult to make
> modifications to it.

As well as what other folks mentioned in the thread, this is probably
unsupportable by the security team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

Hi Guillem,

2016-12-19 1:34 GMT+01:00 Guillem Jover :
> On Sat, 2016-12-17 at 09:20:40 +0100, Bálint Réczey wrote:
>> 2016-12-17 3:14 GMT+01:00 Guillem Jover :
>> > On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote:
>> >> 2016-12-13 9:29 GMT+01:00 Bálint Réczey :
>> >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey :
>> >> >> Lucas already performed the archive-wide rebuild with bindnow
>> >> >> enabled by dpkg and we have not observed breakages specific to
>> >> >> bindnow. IMO this is mostly due to packages already disabling
>> >> >> bindnow through dpkg-buildflags.
>> >
>> > But you didn't do the requested archive-wide autopkgtest run (because
>> > "it was hard"), and even though the coverage is not great it would
>> > be better than nothing. Requested in this case because bindnow changes
>> > the *run-time* behavior, which is not visible or noticable in normal
>> > circumstances by just *building* packages.
>>
>> I'm surprised you raise the autopkgtest run question.
>
> I mentioned it explicitly on a private mail Lucas sent to me, Niels and
> Kurt, which prompted me to update the dpkg FAQ, and then again a week
> after in .
>
> In addition on that private conversation I also mentioned this:
>
>   And this still leaves many packages that might fail at run-time (not
>   to mention the startup slow down), so this option seems potentially
>   dangerous to enable globally. OTOH at least both Gentoo and Fedora
>   seem to have done so:
>
> 
> 
>
>   And some known issues:
>
> 
> 
> The Gentoo wiki also mentions that X is not happy about this, but
> I'm not sure how current that is.
>
> Which then updated  with some of
> those relevant links, but maybe that was too subtle.

Note that you did not list autopkgtest as  a strong requirement:

 https://lists.debian.org/debian-devel/2016/08/msg00384.html
...
 From dpkg PoV enabling both, would at least require a full-archive
 rebuild, for bindnow ideally also a full autopkgtest run (as the
 updated dpkg FAQ states now, after Lucas Nussbaum approached me some
 weeks ago mentioning he was willing to do such archive-wide rebuild).
...

Note the word "ideally".
Those emails were the exact reasons why I asked a proper clarification on
10 October to be able to at least give autopkgtest a try in time:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12

>
>> I asked for clarification then because the on 13 Aug you added the
>> following line to dpkg FAQ which does not seem to be a strong
>> requirement:
>> * For flags that change run-time semantics, ideally an additional run
>> of the autopkgtest for packages that ship them (although this cannot
>> be deemed conclusive as our coverage is not great yet).
>> ( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=28&rev2=29 )
>
> It certainly is not going to be conclusive as a way to verify it correct,
> as even with no failures would not mean there's no potential problems;
> this would merely apply the principle of "falsificationism" to the
> proposal. So it might be helpful as an additional data point to try to
> gauge the possible fallout, but not as a way to say "everything ok, no
> problems found". Which I guess does not play in your favor, I'll
> update the FAQ to makes this more clear.

I agree with that.

>
>> I would like to kindly ask the Release Team to share its position on the
>> bindnow question since Guillem don't seem to let this move forward
>> without that.
>
> BTW, in contrast to PIE, to be able to use bindnow globally on your
> system you don't even have to recompile anything. You can simply add
> LD_BIND_NOW=1 in your /etc/environment for example (man ld.so(8)).

It may work for a some systems but this would also set bindnow for
programs not working properly with bindnow in contrast to enabling bindnow
in dpkg globally and disabling it per problematic package.


>
> Also according to the release schedule, it appears to me people still
> have up to 10 days before 2017-02-05 to enable bindnow in their
> packages?

True, I have updated my blog post with that later date. Thanks for
pointing that out.

>
> And in any case, I've written down to propose enabling this at the
> beginning of the dpkg 1.19.x release cycle (which will match the buster
> release cycle) in .

Thanks. If I could perform the autopkgtest run with bindnow this year would it
be convincing enough given only a small amount of breakages to enable
bindnow early in January?

Thanks,
Balint

>
> Regards,
> Guillem

Bug#848667: ITP: trabucco -- a launcher for people that are nostalgic about katapult

[Salvo Tomaselli]

Package: wnpp
Severity: wishlist
Owner: Salvo Tomaselli 

* Package name: trabucco
  Version : 1.0.0
  Upstream Author : Salvo 'LtWorf' Tomaselli 
* URL : https://github.com/ltworf/trabucco#trabucco
* License : GPL3
  Programming Lang: C++
  Description : a launcher for people that are nostalgic about katapult

I started writing trabucco (trebuchet in Italian), because I was not very
happy with krunner and I had been happier with katapult, on KDE3.

So the idea is to have a similar user experience.

Trabucco is more deterministic, it creates a search tree when it starts and
as the user types, it shows the best suggestion.

It only shows 1 suggestion per string.

If the user doesn't add new programs/bookmarks, the same search string will
always result in the same suggestion. This means that it makes it easy to
acquire muscle memory and do things without even looking at the screen.

These are the main differences with krunner. Krunner will do the search as
the user types in, try to be smart and sort multiple suggestions, and have
timeouts, so depending on the load of the system, you might get a different
set of suggestions. These are things I found annoying, hence the decision of
writing trabucco.

It uses modern Qt things and QML to render, and I have made an effort to be
compliant with freedesktop specifications.

I am the main upstream author, I plan to keep the debian directory on the same
git repository as the upstream code.

Re: depending on libssl1.0-dev, buildd fails to find it

[Johannes Schauer]

Hi,

Quoting James McCoy (2016-12-18 16:04:47)
> On Sun, Dec 18, 2016 at 02:26:09PM +0100, Ondrej Novy wrote:
> > Hi,
> > 
> > 2016-12-18 14:14 GMT+01:00 James McCoy :
> > 
> > Well, sbuild's man page documents that the aptitude resolver will check
> > alternatives. If it doesn't in practice, that sounds like a bug.
> > 
> > 
> > you need to run sbuild with "--resolve-alternatives" or add same option in
> > sbuildrc. Imho bug in manpage.
> 
> Quoth the man page:
> 
> --build-dep-resolver=resolver
>… The aptitude resolver is very similar, but smarter and
>slower, and it will consider all alternatives by default; it
>is  suited to more complex situations, such as building
>packages for the experimental distribution, where packages
>need installing from multiple suites (unstable and
>experimental). …
> 
> --resolve-alternatives
>Allow the use of alternatives in Build-Depends,
>Build-Depends-Arch and Build-Depends-Indep.  This is the
>default for the aptitude dependency resolver.
> 
> so there shouldn't be a need to use --resolve-alternatives with
> --build-dep-resolver=aptitude.

oh, that's interesting. I actually wasn't aware of that (I barely use the
aptitude resolver).

Do you think it makes sense for the RESOLVE_ALTERNATIVES configuration value to
be different from the default for the aptitude resolver? Somehow I find this
rather unexpected.

If yes, then RESOLVE_ALTERNATIVES should be set to "true" for the aspcud
resolver as well...

Thanks!

cheers, josch


signature.asc
Description: signature

Re: depending on libssl1.0-dev, buildd fails to find it

[Johannes Schauer]

Hi,

Quoting Mattia Rizzolo (2016-12-18 11:38:24)
> On Sat, Dec 17, 2016 at 09:27:12PM -0500, James McCoy wrote:
> > As Arno hinted at, it's to have reliable builds.  A transient inability
> > to install the first arm of an alternation should caused a dep-wait
> > state, not building with the alternate Build-Depends.
> 
> which is kinda bullshit, as a different set of transitive
> build-dependencies can happen due to alternatives in the dependencies of
> any transitive build-dep, so the "have stable builds by removing
> alternatives in the build-dep list" is really pointless.
> For example ubuntu considers them to, there is just a switch in sbuild
> to have it consider them.

exactly my opinion as well. But it's even worse:

Imagine you even directly build-depend on a virtual package. There is currently
no way to somehow "reliably" always pick the same real provider of that virtual
package.

I consider it very much as a nuisance to have this special mangling of
build-depends activated by default in sbuild. For example for dose3 we
introduced the --deb-emulate-sbuild option just because it was such a common
problem that dose3 would find a solution but sbuild was unable to because it
throws away all but the first alternative of the build dependencies.

Given that there exist transitive alternatives and virtual packages I'm also
questioning the effectiveness of this rule. I rather find it quite unexpected
and as Daniel's puzzlement shows rather a source of problems.

Can somebody remind me why we still want to have this behaviour as the default?
And why whatever arguments speak *for* this behaviour being the default are
weighing more than the "unreliability" that is already introduced by transitive
build dependencies and multiple providers of virtual build dependencies?

In my opinion we should either:

 - define a way that tells resolvers which "defaults" it should use for
   resolving transitive alternatives and virtual packages for the purpose of
   "stable" build dependency resolution

 - accept that dependency resolution given alternatives and virtual packages is
   always "unstable" and deal with the resulting bugs through changes in the
   respective package metadata

> > Now, backports are a different story because they use a different resolver
> > which will pull in alternates.
> 
> afaik sbuild strips the alternatives while parsing the .dsc (or
> d/control or whatever), before passing the information to the resolvers,
> so even if you use another resolver for -bpo you still get the same
> behaviour.

That is correct.

cheers, josch


signature.asc
Description: signature

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Julien Cristau]

On 12/19/2016 11:37 AM, Bálint Réczey wrote:
> Thanks. If I could perform the autopkgtest run with bindnow this year would it
> be convincing enough given only a small amount of breakages to enable
> bindnow early in January?
> 
I thought I was clear earlier.  No, enabling bindnow globally is
something which, if it's going to happen (it's not clear to me that's a
good idea), can only happen at the beginning of the release cycle, not
when we're getting close to freeze, let alone during freeze.

Cheers,
Julien

Re: depending on libssl1.0-dev, buildd fails to find it

[Adam D. Barratt]

On 2016-12-19 12:12, Johannes Schauer wrote:
Imagine you even directly build-depend on a virtual package. There is 
currently
no way to somehow "reliably" always pick the same real provider of that 
virtual

package.


I'm not sure how that isn't exactly what you're doing by depending on 
"provider-of-virtual-package | virtual-package", as suggested by Policy 
7.5


Regards,

Adam

Re: [RFC] Enabling bindnow by default in dpkg-buildflags?

[Bálint Réczey]

2016-12-19 14:58 GMT+01:00 Julien Cristau :
> On 12/19/2016 11:37 AM, Bálint Réczey wrote:
>> Thanks. If I could perform the autopkgtest run with bindnow this year would 
>> it
>> be convincing enough given only a small amount of breakages to enable
>> bindnow early in January?
>>
> I thought I was clear earlier.  No, enabling bindnow globally is
> something which, if it's going to happen (it's not clear to me that's a
> good idea), can only happen at the beginning of the release cycle, not
> when we're getting close to freeze, let alone during freeze.

OK.

Bug#848695: ITP: telegram -- Official desktop client for the Telegram instant messaging protocol

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: "Nicolas Braud-Santoni" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: telegram
  Version : 0.10.20
  Upstream Author : The Telegram Developers
* URL : https://desktop.telegram.org/
* License : GPL-3
  Programming Lang: C++
  Description : Official desktop client for the Telegram instant messaging 
protocol

Telegram is a popular, multi-platform, open, instant messaging protocol,
which seems especially popular on mobile, but has a desktop client.

While the protocol probably shouldn't be relied on for confidentiality
[0,1], the UI pushes users towards insecure communication as the default,
and the developers have made quixotic attempts at arguing why their
protocol is secure rather than fixing it [2], I believe that there is
value in packaging Telegram rather than having users download and
install unsigned binaries [3].

I plan to maintain the package inside collab-maint.


Best,

  nicoo


[0] https://core.telegram.org/mtproto#general-description
[1] https://gizmodo.com/why-you-should-stop-using-telegram-right-now-1782557415
[2] 
https://core.telegram.org/techfaq#q-why-don-39t-you-go-for-a-standard-encrypt-then-mac-approach
https://core.telegram.org/techfaq#q-do-you-use-ige-ige-is-broken
[3] https://desktop.telegram.org/

-BEGIN PGP SIGNATURE-

iQJNBAEBCgA3FiEEiWEbFKE2h/s1SpJPnU+IAQz+GeMFAlhYAr0ZHG5pY29sYXNA
YnJhdWQtc2FudG9uaS5ldQAKCRCdT4gBDP4Z4zztD/4+xoHIcewrb5YcfBwgN18T
lyTEp/95AXxO3lKIC08Etg6R7Y4bzrOwV3MK/sYhcyNP41RE5A6wYGTLquNff7vY
LnmS4nwMMhrTaWe/voblkfnVCJs1Auzi6Xns21Sh+abiyHu2jaPk5Z8mfi1Wusrc
T8Ab4qMYW0CkfZlyCc7NjPhF8mIm8pZPyTakWYkRJarssfuqwR0ty6IuC6+Xs1cH
L60fNYzgkqc6CvnswC5+i7qzsJlIutCqTjpcyDN4NtwlzL1NUmpugpIhD1C+l96A
7leDB/v/6kjBrZoJ/VWJISkFRMIOcmSvUYHetIkf+Jd4KrpyccUR4lleRmhRkNCf
YOZpo9mNwZ6msAVLwgWjqxj3nnOSS1+S6ymyTZKeCRsikpC7aBgHguJ9YwcJbUUN
bpBuU9nQ6JbHsW1H/mgQzrAXw5P2TG/43N47+1PxFpMh6k4UAnQhsEJ9YjKDNcqz
HouSCnmuytyPQKm/OruVoAdI6R2oVMCAvcuMZv7Bg/5UjLd69T3TgZDJCfyd5LOa
YIZV2MZbK16PZTKomsYSQgP0nExlutAD2lynUGR32g44ygdKHZ6ze1Ag8NkVRN3/
AESadMu5Gy1Mm+fzU52IFPlTatZY/jrmFaGIThYoioCXQLhe80H9qek6rrG2feXG
7r0UQSu4rleI/fJsvo0kIA==
=ty8M
-END PGP SIGNATURE-

Re: Bug#848695: ITP: telegram -- Official desktop client for the Telegram instant messaging protocol

[Boyuan Yang]

在 2016年12月19日星期一 SGT 下午4:55:24，Nicolas Braud-Santoni 写道：
> Package: wnpp
> Severity: wishlist
> Owner: "Nicolas Braud-Santoni" 
> 
> * Package name: telegram
>   Version : 0.10.20
>   Upstream Author : The Telegram Developers
> * URL : https://desktop.telegram.org/
> * License : GPL-3
>   Programming Lang: C++
>   Description : Official desktop client for the Telegram instant
> messaging protocol
> 
> Telegram is a popular, multi-platform, open, instant messaging protocol,
> which seems especially popular on mobile, but has a desktop client.
> 
> While the protocol probably shouldn't be relied on for confidentiality
> [0,1], the UI pushes users towards insecure communication as the default,
> and the developers have made quixotic attempts at arguing why their
> protocol is secure rather than fixing it [2], I believe that there is
> value in packaging Telegram rather than having users download and
> install unsigned binaries [3].

Protocol reliability has been discussed before. [4] Personally I don't really
care about it, though. Please go ahead.

Just one (and maybe the biggest) question: how would you handle the patched 
Qt?

[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767418

Sincerely,
Boyuan Yang

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

Re: Bug#848695: ITP: telegram -- Official desktop client for the Telegram instant messaging protocol

[Daniel Pocock]

On 19/12/16 17:05, Boyuan Yang wrote:

> Just one (and maybe the biggest) question: how would you handle the
> patched Qt?
> 



Note there is also telepathy-morse[1], the Telegram Connection Manager
for the Telepathy framework (and Empathy client)

Regards,

Daniel


1. https://github.com/TelepathyIM/telepathy-morse

Bug#848700: ITP: golang-github-bep-gitmap -- map all filenames to info objects for a given git revision

[Dr. Tobias Quathamer]

Package: wnpp
Severity: wishlist
Owner: Dr. Tobias Quathamer 

* Package name: golang-github-bep-gitmap
  Version : 0.0~git20161029.0.a1a71ab-1
  Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/gitmap
* License : Expat
  Programming Lang: Go
  Description : map all filenames to info objects for a given git 
revision


A fairly fast way to create a map from all the filenames to
info objects for a given revision of a Git repo.
.
This library uses os/exec to talk to Git in order to
avoid dependencies.



This package is needed for the new release of hugo, the static website 
generator.


Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Re: fine-grained permissions on alioth git repositories? (aka Debian gitlab)?

[Pirate Praveen]

On വെള്ളി 09 ഡിസംബര്‍ 2016 12:21 രാവിലെ, Alexander Wirt wrote:
> Help on the pagure itp (#829046 ) and things will arrive faster. 

Need help with #844943 to proceed further.



signature.asc
Description: OpenPGP digital signature

Re: contacting all bug reporters for a package?

[Adrian Bunk]

On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote:
> 
> Is there any easy way to contact everybody who made a bug report against
> a package and ask them to check if the latest upload fixes it?  Or is
> there any script for maintainers to do this?

I would expect the majority of your users observed the bug on an 
(often production) system running jessie or older stable.

It is not possible for such users to try random packages from unstable.

> If somebody has opened 2 ore more bugs maybe they may prefer to only
> receive a single email summarizing all their bugs for that package.
> 
> For example, nfs-utils has over 100 active bug reports and although I
> spent some time updating it I'm not keen to go through all the bugs one
> by one.
>...

Are you fully committed to spend time debugging every problem where
a user confirmed that it is still present?

It might take a user hours (or even days) to verify whether a problem is 
still present.

It would be a very evil if a user would spend effort after such an 
email, but the next he hears from the maintainer would be another
such request to try the then-latest version a year later.

> Regards,
> 
> Daniel

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: contacting all bug reporters for a package?

[Daniel Pocock]

On 19/12/16 21:57, Adrian Bunk wrote:
> On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote:
>>
>> Is there any easy way to contact everybody who made a bug report against
>> a package and ask them to check if the latest upload fixes it?  Or is
>> there any script for maintainers to do this?
> 
> I would expect the majority of your users observed the bug on an 
> (often production) system running jessie or older stable.
> 
> It is not possible for such users to try random packages from unstable.
> 

Well, if it really deserves to graduate from unstable to the next stable
release, somebody is going to have to test it sooner or later.
Hopefully sooner.  In my own environment I observed that NFS on jessie
was less reliable than on wheezy.

>> If somebody has opened 2 ore more bugs maybe they may prefer to only
>> receive a single email summarizing all their bugs for that package.
>>
>> For example, nfs-utils has over 100 active bug reports and although I
>> spent some time updating it I'm not keen to go through all the bugs one
>> by one.
>> ...
> 
> Are you fully committed to spend time debugging every problem where
> a user confirmed that it is still present?
> 

I don't think I ever promised that.  However, if users confirm problems
that should really be release critical, then that gives the release team
greater visibility about which packages are really ready going into the
freeze.

> It might take a user hours (or even days) to verify whether a problem is 
> still present.
> 
> It would be a very evil if a user would spend effort after such an 
> email, but the next he hears from the maintainer would be another
> such request to try the then-latest version a year later.
> 

I hope the people who try things will engage with the community as a
whole (including upstream) and not only rely on a single maintainer.

Regards,

Daniel

Re: contacting all bug reporters for a package?

[Adrian Bunk]

On Mon, Dec 19, 2016 at 10:15:33PM +0100, Daniel Pocock wrote:
> 
> 
> On 19/12/16 21:57, Adrian Bunk wrote:
> > On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote:
> >>
> >> Is there any easy way to contact everybody who made a bug report against
> >> a package and ask them to check if the latest upload fixes it?  Or is
> >> there any script for maintainers to do this?
> > 
> > I would expect the majority of your users observed the bug on an 
> > (often production) system running jessie or older stable.
> > 
> > It is not possible for such users to try random packages from unstable.
> 
> Well, if it really deserves to graduate from unstable to the next stable
> release, somebody is going to have to test it sooner or later.
> Hopefully sooner.  In my own environment I observed that NFS on jessie
> was less reliable than on wheezy.

People running production systems with hundreds of thousands of users 
are definitely not the ones who should test packages from unstable in
these environments.

> >> If somebody has opened 2 ore more bugs maybe they may prefer to only
> >> receive a single email summarizing all their bugs for that package.
> >>
> >> For example, nfs-utils has over 100 active bug reports and although I
> >> spent some time updating it I'm not keen to go through all the bugs one
> >> by one.
> >> ...
> > 
> > Are you fully committed to spend time debugging every problem where
> > a user confirmed that it is still present?
> 
> I don't think I ever promised that.

If you are not willing to promise that, what is the point in asking 
people to spend their time on reproducing?

> However, if users confirm problems
> that should really be release critical, then that gives the release team
> greater visibility about which packages are really ready going into the
> freeze.

Talking about release critical bugs only distracts from the majority of 
bugs that might be pretty fatal in some environments but are not release 
critical.

> > It might take a user hours (or even days) to verify whether a problem is 
> > still present.
> > 
> > It would be a very evil if a user would spend effort after such an 
> > email, but the next he hears from the maintainer would be another
> > such request to try the then-latest version a year later.
> 
> I hope the people who try things will engage with the community as a
> whole (including upstream) and not only rely on a single maintainer.

Asking submitters to reproduce only makes sense if *you* intend to 
further debug all problems confirmed to still be present in the latest
version.

When *you* ask someone to spend effort to reproduce a problem, then that
person can expect that *you* will also spend some effort on that problem
afterwards.

Never forget that due to your request to reproduce people might be 
spending days on setting up an environment for testing whether the bug 
you asked them to re-test is still present in the version you asked them 
to test.

> Regards,
> 
> Daniel

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#848844: ITP: node-globals -- Global identifiers from different JavaScript environments

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-globals
  Version : 9.14.0
  Upstream Author : Sindre Sorhus 
(http://sindresorhus.com)
* URL : https://github.com/sindresorhus/globals#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Global identifiers from different JavaScript
environments



signature.asc
Description: OpenPGP digital signature

Re: contacting all bug reporters for a package?

[Daniel Pocock]

On 19/12/16 22:47, Adrian Bunk wrote:
> On Mon, Dec 19, 2016 at 10:15:33PM +0100, Daniel Pocock wrote:
>>
>>
>> On 19/12/16 21:57, Adrian Bunk wrote:
>>> On Thu, Dec 15, 2016 at 11:11:27AM +0100, Daniel Pocock wrote:

 Is there any easy way to contact everybody who made a bug report against
 a package and ask them to check if the latest upload fixes it?  Or is
 there any script for maintainers to do this?
>>>
>>> I would expect the majority of your users observed the bug on an 
>>> (often production) system running jessie or older stable.
>>>
>>> It is not possible for such users to try random packages from unstable.
>>
>> Well, if it really deserves to graduate from unstable to the next stable
>> release, somebody is going to have to test it sooner or later.
>> Hopefully sooner.  In my own environment I observed that NFS on jessie
>> was less reliable than on wheezy.
> 
> People running production systems with hundreds of thousands of users 
> are definitely not the ones who should test packages from unstable in
> these environments.
> 

So who should test and how should they do it?

Should Debian stop distributing packages like this if they don't get
tested sufficiently?


 If somebody has opened 2 ore more bugs maybe they may prefer to only
 receive a single email summarizing all their bugs for that package.

 For example, nfs-utils has over 100 active bug reports and although I
 spent some time updating it I'm not keen to go through all the bugs one
 by one.
 ...
>>>
>>> Are you fully committed to spend time debugging every problem where
>>> a user confirmed that it is still present?
>>
>> I don't think I ever promised that.
> 
> If you are not willing to promise that, what is the point in asking 
> people to spend their time on reproducing?
> 

Here is the message I sent:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793661#10

I didn't ask people to reproduce, I asked them to help review their bugs
against the upstream changelog and "if you have time to test the new
package, your help would be very welcome".  If I asked "please confirm
you can still reproduce the bug on the newest nfs-utils" then that would
be a much stronger statement, but that is not what I asked.



>> However, if users confirm problems
>> that should really be release critical, then that gives the release team
>> greater visibility about which packages are really ready going into the
>> freeze.
> 
> Talking about release critical bugs only distracts from the majority of 
> bugs that might be pretty fatal in some environments but are not release 
> critical.
> 

If they are fatal for all NFS server environments (like the crashes with
the jessie kernel) or they are fatal for a specific type of NFS
configuration then they are release critical for this package.  As
already suggested, Debian would have to consider dropping any package in
that situation if we knew about stability problems and nobody was
volunteering to fix and volunteering to test it.


>>> It might take a user hours (or even days) to verify whether a problem is 
>>> still present.
>>>
>>> It would be a very evil if a user would spend effort after such an 
>>> email, but the next he hears from the maintainer would be another
>>> such request to try the then-latest version a year later.
>>
>> I hope the people who try things will engage with the community as a
>> whole (including upstream) and not only rely on a single maintainer.
> 
> Asking submitters to reproduce only makes sense if *you* intend to 
> further debug all problems confirmed to still be present in the latest
> version.
> 
> When *you* ask someone to spend effort to reproduce a problem, then that
> person can expect that *you* will also spend some effort on that problem
> afterwards.
> 
> Never forget that due to your request to reproduce people might be 
> spending days on setting up an environment for testing whether the bug 
> you asked them to re-test is still present in the version you asked them 
> to test.
> 

After the first round of feedback, I did another upload on the weekend.
I believe each upload has provided an incremental improvement over the
previous version in sid and in each case it has been shaped by the
feedback through the BTS.

Regards,

Daniel