Bug#882054: ITP: libapache-session-sqlite3-perl -- SQLite3 implementation of Apache::Session

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libapache-session-sqlite3-perl
  Version : 0.03
  Upstream Author : Autrijus Tang 
* URL : https://metacpan.org/release/Apache-Session-SQLite3
* License : Artistic or GPL-1
  Programming Lang: Perl
  Description : SQLite3 implementation of Apache::Session

Apache::Session makes maintaining user data across HTTP requests simple.

Apache::Session::SQLite3 is an implementation of Apache::Session that uses
an LDAP directory to store datas.

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Emilio Pozuelo Monfort]

On 12/11/17 11:25, Niels Thykier wrote:
> Hi,
> 
> 
> The debhelper compat level 11 is about to be finalized and we invite you
> to test it out.  There are no additional changes planned to compat 11 at
> the moment, but there might be changes in response to feedback from testers.

One thing with compat 10 that doesn't make a lot of sense to me is how
dh_missing is enabled by default but a no-op. It'd make more sense to me to
change that in compat 11 to be enabled by default and run with --list-missing
(--fail-missing is probably too much at this point), or make it run with --list
or --fail-missing, but not enabled by default, and make it an addon. So that one
can have:

No dh_missing:

%:
dh $@

Or for dh_missing:

%:
dh --with missing $@

I think one of those two options would make more sense than the status quo, and
I probably lean towards the first option (enabled by default with 
--list-missing).

Thoughts? Let me know if you want a bug report about this.

Cheers,
Emilio

alpha porterbox ?

[Jerome BENOIT]

Hello,

one of my package, normaliz not to mention it, fails a test on the alpha 
architecture:
I would like to dig the issue on a porterbox. Is there any porterbox for alpha 
architecture ?

Thanks in advance,
Jerome 


-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> One thing with compat 10 that doesn't make a lot of sense to me is how
> dh_missing is enabled by default but a no-op. It'd make more sense to me to
> change that in compat 11 to be enabled by default and run with --list-missing
> (--fail-missing is probably too much at this point), or make it run with 
> --list
> or --fail-missing, but not enabled by default, and make it an addon.

As I planned to create a related wishlist bug report about that issue:
Agreed.

The --fail-missing option saved my lower back many times in the past,
even when it was placed in dh_install. Therefore I'm certain it would
help other people as well. In other words, I was about to suggest to
make --list-missing the default in 11, and switch to --fail-missing
in 12. Those who somehow manage to trigger a false negative (possibly
dracut is one of these) would have to use a --ignore-missing override
(not yet implemented) then, or use a more elaborate ignore mechanism:

That is debian/not-installed which should no longer ignore file paths
then, also drop the warning on the usage of this file. There are often
files that should not go into a package, *.la files from library
packaging to begin with. Given the suggested policy change above, their
number will increase. Overriding dh_install defeats readability of
debian/rules, also -X might hit more files than intended.

Christoph

PS: Talking about "planned to create a wishlist bug report" ... after
losing several hours while fiddling with dh_systemd_* I saw the need for
a cleanup. Glad to see it's already underway.


signature.asc
Description: Digital signature

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Niels Thykier]

Emilio Pozuelo Monfort:
> On 12/11/17 11:25, Niels Thykier wrote:
>> Hi,
>>
>>
>> The debhelper compat level 11 is about to be finalized and we invite you
>> to test it out.  There are no additional changes planned to compat 11 at
>> the moment, but there might be changes in response to feedback from testers.
> 

Hi,

Thanks for the feedback. :)

> One thing with compat 10 that doesn't make a lot of sense to me is how
> dh_missing is enabled by default but a no-op.

Just a clarification; dh_missing is enabled by default in all compat
levels (being an no-op).  It is a no-op in all stable compat levels
(i.e. <= 10) because it mirrors the default in dh_install.

> It'd make more sense to me to
> change that in compat 11 to be enabled by default and run with --list-missing
> (--fail-missing is probably too much at this point), or make it run with 
> --list
> or --fail-missing, but not enabled by default, and make it an addon. So that 
> one
> can have:
> 
> No dh_missing:
> 
> %:
>   dh $@
> 
> Or for dh_missing:
> 
> %:
>   dh --with missing $@
> 
> I think one of those two options would make more sense than the status quo, 
> and
> I probably lean towards the first option (enabled by default with 
> --list-missing).
> 
> Thoughts? Let me know if you want a bug report about this.
> 
> Cheers,
> Emilio
> 

I have received several requests to make --list-missing or
--fail-missing the default (#650129 and #858834) and I intend to do so
eventually.  I am a little concerned with adding more changes to compat
11 (the list is rather long already), but I am happy with making
--list-missing the default for compat 12.

As for the sequences; we can add those to the next version of debhelper
(a sequence change the parameters passed to a helper).  If you file a
bug for it with how you envision that, then I am happy to add it in one
of the next uploads of debhelper. :)

Thanks,
~Niels

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Emilio Pozuelo Monfort]

On 18/11/17 12:41, Niels Thykier wrote:
> I have received several requests to make --list-missing or
> --fail-missing the default (#650129 and #858834) and I intend to do so
> eventually.  I am a little concerned with adding more changes to compat
> 11 (the list is rather long already), but I am happy with making
> --list-missing the default for compat 12.

Fair enough, though it seems unlikely that --list-missing would cause any
trouble... but you are the debhelper expert ;)

> As for the sequences; we can add those to the next version of debhelper
> (a sequence change the parameters passed to a helper).  If you file a
> bug for it with how you envision that, then I am happy to add it in one
> of the next uploads of debhelper. :)

No need for a sequence if dh_missing starts doing something useful by default.

Cheers,
Emilio

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Maximiliano Curia]

¡Hola Niels!

El 2017-11-18 a las 11:41 +, Niels Thykier escribió:

Emilio Pozuelo Monfort:
It'd make more sense to me to 
change that in compat 11 to be enabled by default and run with --list-missing 
(--fail-missing is probably too much at this point), or make it run with --list 
or --fail-missing, but not enabled by default, and make it an addon. So that one 
can have:



No dh_missing:



%:
dh $@



Or for dh_missing:



%:
dh --with missing $@


I think one of those two options would make more sense than the status quo, and 
I probably lean towards the first option (enabled by default with --list-missing).



Thoughts? Let me know if you want a bug report about this.


I have received several requests to make --list-missing or 
--fail-missing the default (#650129 and #858834) and I intend to do so 
eventually.  I am a little concerned with adding more changes to compat 
11 (the list is rather long already), but I am happy with making 
--list-missing the default for compat 12.


Please consider adding wildcard support for the debian/not-installed files 
before making this the default. In the package pkg-kde-tools, the 
/usr/share/pkg-kde-tools/qt-kde-team/3/list-missing.mk make script implements 
a (rather primitive) support for wildcards in debian/not-installed which might 
be used as a base for dh_missing.


Otherwise, please make allow this functionality to be easily disabled.

Happy hacking,
--
"If it ain't broke, don't fix it" -- Bert Lance

"If we can't fix it, it ain't broke" -- Lieutenant Colonel Walt Weir
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#882071: ITP: compreffor -- CFF table subroutinizer for FontTools

[Jeremy Bicha]

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

Package Name: python3-compreffor
Version: 0.4.6
Upstream Authors : Google, Sam Fishman, Cosimo Lupo
License : Apache-2.0
Programming Lang: Python, C++
Homepage: https://github.com/googlei18n/compreffor

Description: CFF table subroutinizer for FontTools
 python3-compreffor is a tool to subroutinize a Compact Font Format (CFF)
 OpenType font.

Other Info
--
This is yet another Google font package required by fontmake. fontmake
is required to fully build several fonts from source.

I am packaging this as part of the Debian Fonts Team.

Packaging is at
https://anonscm.debian.org/git/pkg-fonts/compreffor.git/

Thanks,
Jeremy Bicha

Bug#882072: ITP: python-pydot3 -- interface to Graphviz's Dot

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pydot3
  Version : 1.0.9
  Upstream Author : Eric Chio 
* URL : https://www.github.com/log0/pydot3
* License : Expat
  Programming Lang: Python
  Description : interface to Graphviz's Dot

 Pydot3 is a Python 3 interface to Graphviz's Dot. It's compatible with both
 Python 2.7 and Python 3.x. Graphviz is a rich set of graph drawing tools.

Note: this is a build-depends for ironic-inspector, the part of OpenStack
Ironic that checks for new hardware before provisionning.

Bug#882084: ITP: elpa-mu4e-alert -- Desktop notifications and modeline display for mu4e.

[James Richardson]

Package: wnpp
Severity: wishlist
Owner: James Richardson 

* Package name: elpa-mu4e-alert
  Version : 1.0
  Upstream Author : Iqbal Ansari 
* URL : https://iqbalansari/mu4e-alert
* License : GPL v3
  Programming Lang: lisp
  Description : Desktop notifications and modeline display for mu4e.

mu4e-alert is an Emacs extension providing desktop notifications for mu4e,
Additionally it can display the number of unread emails in the mode-line.

This package requires emacs >= 24.1 and mu >= 0.9.9.7 (maildir-utils in debian).

This package is useful for emacsers that use mu4e for email ;) I use to 
get notified of unread emails in the emacs mode line. I use it several
personal and work machines. 

Logically, I think it would be reasonable to be team maintained by the
Emacs Addons Packaging Team. I will need a sponsor.

Bug#882087: ITP: libcrypt-openssl-ec-perl -- Perl extension for OpenSSL EC (Elliptic Curves) library

[Xavier Guimard]

Package: wnpp
Severity: wishlist
Owner: Xavier Guimard 

* Package name: libcrypt-openssl-ec-perl
  Version : 1.31
  Upstream Author : Mike McCauley 
* URL : https://metacpan.org/release/Crypt-OpenSSL-EC
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl extension for OpenSSL EC (Elliptic Curves) library

Crypt::OpenSSL::EC provides a standard (non-OO) interface to the OpenSSL EC
(Elliptic Curve) library. It provides the Crypt::OpenSSL::EC class which
defines some high level functions and constants. Some OO Calls are supported.
Most of the functions described in openssl/ec.h are supported.

Re: Auto-update for sid? Auto-backport?

[Steffen Möller]

Hi Jeremy,

On 18.11.17 01:12, Jeremy Bicha wrote:
> On Fri, Nov 17, 2017 at 7:00 PM, Steffen Möller  
> wrote:
>> If the positive vibes I have felt are kept up then I propose the
>> individuals running relevant services in/around Debian (ftpmasters, web,
>> backports, mentors, ...) determine what team then takes that summary to
>> transform it into a white paper that proposes steps to address so we
>> eventually have something to have a vote about?!
> Why don't you (or someone) work on an opt-in service to help automate
> everything *except* for the actual upload to Debian part? Since that's
> the part that is controversial and complicated to set up in a trusted
> way. I don't think you need a vote to work on implementing and
> offering the rest.
I was impressed by the work that Guido has described (see
https://lists.debian.org/debian-devel/2017/11/msg00154.html).
He would certainly be one of the first individuals I feel like contacting
about something from where to grow.

My request was less about the technicality and more about learning
to what degree what kind of uploads would find general or partial
acceptance in our community.

But you are right, an external service is a safe bet as a first start that
we do not need to vote about - nor would I need to ask ;) However,
any such automation is something, if brought closer to Debian, that
has the potential to change us quite a bit. I felt that more than one
individual should be involved and at least should I myself be the
one to set it up, I would want (most of) you (all) to want it.

Best,

Steffen

Re: [apparmor] Let's enable AppArmor by default (why not?)

[John Johansen]

On 11/17/2017 05:34 PM, Ben Caradoc-Davies wrote:
> On 18/11/17 04:27, intrigeri wrote:
>> Thanks in advance, and sorry for any inconvenience it may cause (e.g.
>> the AppArmor policy for Thunderbird has various issues in sid; all of
>> those I'm aware of are fixed in experimental already).
> 
> Where "various issues" means no thunderbird external helpers work under xfce. 
> Not a single one, as far as I can tell. And there goes another one: what 
> happened to my .signature? I have filed as many bugs as I can given the time 
> available. I will file one more for the missing .signature, and then I am 
> disabling apparmor.
> 

thank you for taking time to file bugs and provide a report here to help make 
the apparmor experience better. You have several options for disabling parts of 
apparmor policy enforcement or its enforcement entirely.

You can disable individual profiles without editing them and messing up the 
packaging by using aa-disable

  sudo aa-disable /etc/apparmor.d/usr.bin.thunderbird

or by manually by manually removing the profile and dropping a symlink in

 /etc/apparmor.d/disable/

so for example to disable the thunderbird profile you can do
  sudo apparmor_parser -R /etc/apparmor.d/usr.bin.thunderbird
  sudo ln -s /etc/apparmor.d/usr.bin.thunderbird 
/etc/apparmor.d/disbale/thunderbird

it is important to do the removal before adding the symlink, and as in the 
example above the symlink does not have to be the same name as that of the 
profile file.
you can reverse the above by using
  sudo aa-enable /etc/apparmor.d/usr.bin.thunderbird

or manually by removing the symlink and loading the profile
  sudo rm /etc/apparmor.d/disable/thunderbird
  audo apparmor_parser -r /etc/apparmor.d/usr.bin.thunderbird


You can disable the apparmor service at the systemd level with

  sudo systemctl disable apparmor

You can remove the apparmor package

  sudo apt-get remove apparmor
or
  sudo dpkg --remove apparmor

and you can also set the kernel boot parameter
  apparmor=0

to disable apparmor on a particular boot, or set it as part of your grub config 
to permanently disable it without touching the packaging


* for the above examples I have used /etc/apparmor.d/ for the profile location 
but it could be configured to other locations like /var/lib/apparmor/ etc, it 
depends on the distro and sometimes the package eg. ubuntu has profiles 
configured to different locations depending on whether they are system 
profiles, snap profiles, etc.

Bug#882090: ITP: node-yamljs -- JavaScript YAML 1.2 Parser & Encoder

[Michael Lustfield]

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

* Package name: node-yamljs
  Version : 0.3.0
  Upstream Author : Jeremy Faivre 
* URL : https://github.com/jeremyfa/yaml.js#readme
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript YAML 1.2 Parser & Encoder

 YAML.js is a stand-alone YAML 1.2 parser and encoder. It works under
 node.js and all major browsers. This package also includes some command
 line YAML/JSON conversion utilities.
 .
 Example Usage:
   // load string to object
   nativeObject = YAML.parse(yamlString);
   // load file to object
   nativeObject = YAML.load('file.yml');


This is being packaged as a dependency of semantic-ui, which is a dependency
of gitea.


pgpVjHXCkPjKL.pgp
Description: OpenPGP digital signature

Re: [apparmor] Let's enable AppArmor by default (why not?)

[Marvin Renich]

* John Johansen  [171118 16:02]:
> You can disable individual profiles without editing them and messing up the 
> packaging by using aa-disable
[some really good beginner stuff snipped]

John, many thanks for these tidbits.  Can they be put in a text file in
/usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
that when the package is pulled in, the user has some idea where to
start?  Since Thunderbird seems to be one of the problem packages,
having it in a text file on the local system seems like a good idea.

Actually, a short beginner's guide as a text file in
/usr/share/doc/apparmor, which has more than just "how to disable a
profile" would be extremely helpful.  I don't have the apparmor
knowledge to write it, though.

Thanks...Marvin

Bug#882102: ITP: libcompress-lz4-perl -- Perl interface to the LZ4 (de)compressor

[gregor herrmann]

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

* Package name: libcompress-lz4-perl
  Version : 0.25+ds
  Upstream Author : gray 
* URL : https://metacpan.org/release/Compress-LZ4
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl interface to the LZ4 (de)compressor

The Compress::LZ4 module provides an interface to the LZ4 (de)compressor.

Besides functions for compression, high-compression, and decompression, it
also includes compatibility functions for the same purposes to handle raw
data in the official frame format.

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

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: [apparmor] Let's enable AppArmor by default (why not?)

[John Johansen]

On 11/18/2017 01:59 PM, Marvin Renich wrote:
> * John Johansen  [171118 16:02]:
>> You can disable individual profiles without editing them and messing up the 
>> packaging by using aa-disable
> [some really good beginner stuff snipped]
> 
> John, many thanks for these tidbits.  Can they be put in a text file in
> /usr/share/doc/apparmor, with a NEWS.Debian entry pointing to it, so
> that when the package is pulled in, the user has some idea where to
> start?  Since Thunderbird seems to be one of the problem packages,
> having it in a text file on the local system seems like a good idea.
> 

yes we can certainly create the text file, its a good idea. I'll leave it
up to the debian maintainer to decide on the NEWS.Debian entry but it
certainly sound like a good idea to me as well.

> Actually, a short beginner's guide as a text file in
> /usr/share/doc/apparmor, which has more than just "how to disable a
> profile" would be extremely helpful.  I don't have the apparmor
> knowledge to write it, though.
> 
yeah, I will start working on the doc. Make sure it has links to
more comprehensive info (the wiki, ml, some man pages, etc.)

Bug#882113: ITP: sqlcl -- Oracle SQL Developer Command-Line

[Lazarus Long]

Package: wnpp
Severity: wishlist
Owner: Lazarus Long 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sqlcl
  Version : 17.3.0
  Upstream Author : Oracle USA, Inc. 

* URL : 
http://www.oracle.com/technetwork/developer-tools/sqlcl/overview/
* License : Proprietary
  Programming Lang: Java
  Description : Oracle SQL Developer Command-Line

Oracle SQL Developer Command Line (SQLcl) is a free command line
interface for Oracle Database. It allows you to interactively or batch
execute SQL and PL/SQL. SQLcl provides in-line editing, statement
completion, and command recall for a feature-rich experience, all while
also supporting your previously written SQL*Plus scripts.


 - why is this package useful/relevant?

   It is a SQL*Plus (mostly) equivalent with the advantage of reduced
   requirements, dependencies and increased architecture compatibility.
   It offers a standard and classical interface to Oracle Database that
   every DBA knows and is used to.
 
 - is it a dependency for another package?

   No.

 - do you use it?

   Yes, on a daily basis.

 - if there are other packages providing similar functionality, how
   does it compare?

   sqldeveloper (a package created by a package wrapper:
   sqldeveloper-package) is a graphical application that is fully
   compatible to this one, however it has a higher level of
   requirements (i.e. a full JDK instead of simply a JRE) and isn't
   suited for servers or low end machines due to it's graphical nature.
   sqlline is a similar command line package, lacking the degree of
   specific SQL*Plus and Oracle Database compatibility that this one
   presents. 

 - how do you plan to maintain it?

   I don't intend to package it directly. I'm only opening this ITP to
   avoid duplication of effort by someone else. What I intend to do is
   create a package wrapper that in turn will create this package,
   making it possible to include that one in Debian (this one falls in
   category 2.2.3 of the Debian Policy Manual). I have the intention to
   have that package close this ITP, so no loose end will remain.

 - do you need a sponsor?
   
   No.

Thank you very much,

- -- 
Lazarus

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT6ja0o8lKdd1y4TPqd6/XxTNdf7wUCWhEI/AAKCRCd6/XxTNdf
74i4AJ95jKw/5fsWg488wRV5glhKIry5BQCeN7CQmuQ9UzphPc+v0HUrFBnEpwk=
=jDpT
-END PGP SIGNATURE-

Bug#882115: ITP: sqlcl-package -- Oracle SQL Developer Command-Line Debian package builder

[Lazarus Long]

Package: wnpp
Severity: wishlist
Owner: Lazarus Long 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: sqlcl-package
  Version : 0.1.0
  Upstream Author : Lazarus Long 
* URL : https://lazarusllong.github.io/sqlcl-package/
* License : GPL-3+
  Programming Lang: shell script
  Description : Oracle SQL Developer Command-Line Debian package builder

This utility makes it possible to build a Debian package from Oracle SQL
Developer Command-Line (SQLcl). The Oracle SQL Developer program is
governed by the copyright holder (Oracle USA, Inc.), so you may be
limited as to what you can do with the resulting package (i.e. no
redistribution, etc). This utility will simply help you create the
Debian package, it is your responsibility to use the resulting package
accordingly with the OTN license, a copy of which is included in the
created package, that you must agree on when downloading the source.

This utility will require you to download the architecture independent
archive from ,
identified as "Oracle SQL Developer Command-Line for All Platforms", to
create the Debian package from.

Due to a conflicting name with content of package "parallel" the
upstream binary "sql" will be renamed. Multiple versions can coexist so
"sql.[upstream version]" will invoke a specific version of Oracle SQL
Developer Command-Line, while "sqlcl" (the recommended way) and
"sql.standalone" take advantage of Debian's alternatives system and,
when left in auto mode, will always invoke the highest version installed.


 - why is this package useful/relevant?

   It's the way to permit integrating sqlcl (which falls in category
   2.2.3 of the Debian Policy Manual) in a Debian system. Most DBAs use
   SQL*Plus, and/or it's java based portable parent SQLcl, to interact with
   Oracle Database, hence the potential high number of interested users.

 - is it a dependency for another package?

   Yes. It builds the sqlcl.deb package.

 - do you use it?

   Yes.

 - if there are other packages providing similar functionality, how
   does it compare?

   There is no other package providing similar functionality, neverless,
   sqldeveloper-package will build a sqldeveloper.deb which has similar
   funcionalities to the sqlcl.deb package that this wrapper builds,
   however it has a higher level of requirements (i.e. a full JDK
   instead of simply a JRE) and isn't suited for servers or low end
   machines due to it's graphical nature.

 - how do you plan to maintain it?

   I'm the upstream author and it's a native package, it'll maintain
   itself. Please note that I've created another ITP (#882113)
   regarding packaging sqlcl just to avoid duplication of effort by
   someone else. This package will close both ITPs (I know it's weird
   and unusual, but the nature of this kind pf packages is prone to
   this specific situation).

 - are you looking for co-maintainers?

   No.

 - do you need a sponsor?

   Yes.


Thank you very much,

- -- 
Lazarus

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQT6ja0o8lKdd1y4TPqd6/XxTNdf7wUCWhEPHwAKCRCd6/XxTNdf
79ZYAJwNSEU1/Ytuo4HxZNJDAM3arPfqigCeMBJDasTGFWN3kn75O4OPaaidr6s=
=xDZv
-END PGP SIGNATURE-

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Niels Thykier]

Maximiliano Curia:
> ¡Hola Niels!
> 
> El 2017-11-18 a las 11:41 +, Niels Thykier escribió:
>> Emilio Pozuelo Monfort:
>>> It'd make more sense to me to change that in compat 11 to be enabled
>>> by default and run with --list-missing (--fail-missing is probably
>>> too much at this point), or make it run with --list or
>>> --fail-missing, but not enabled by default, and make it an addon. So
>>> that one can have:
> 
>>> No dh_missing:
> 
>>> %:
>>> dh $@
> 
>>> Or for dh_missing:
> 
>>> %:
>>> dh --with missing $@
> 
>>> I think one of those two options would make more sense than the
>>> status quo, and I probably lean towards the first option (enabled by
>>> default with --list-missing).
> 
>>> Thoughts? Let me know if you want a bug report about this.
> 
>> I have received several requests to make --list-missing or
>> --fail-missing the default (#650129 and #858834) and I intend to do so
>> eventually.  I am a little concerned with adding more changes to
>> compat 11 (the list is rather long already), but I am happy with
>> making --list-missing the default for compat 12.
> 
> Please consider adding wildcard support for the debian/not-installed
> files before making this the default. In the package pkg-kde-tools, the
> /usr/share/pkg-kde-tools/qt-kde-team/3/list-missing.mk make script
> implements a (rather primitive) support for wildcards in
> debian/not-installed which might be used as a base for dh_missing.
> 

I am happy to consider it.  Please file a bug against debhelper for it,
so I do not forget about it. :)

Bonus if you can point to some existing cases where wildcard support
would have worked or where you had to use the above tool instead.

> Otherwise, please make allow this functionality to be easily disabled.
> 
> Happy hacking,

It can always be disabled by disabling the helper.  The procedure for
that (assuming no existing overrides exists) is in essence:

  echo '# Disable dh_missing' >> debian/rules
  echo 'override_dh_missing:' >> debian/rules


Thanks,
~Niels

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Niels Thykier]

Emilio Pozuelo Monfort:
> On 18/11/17 12:41, Niels Thykier wrote:
>> I have received several requests to make --list-missing or
>> --fail-missing the default (#650129 and #858834) and I intend to do so
>> eventually.  I am a little concerned with adding more changes to compat
>> 11 (the list is rather long already), but I am happy with making
>> --list-missing the default for compat 12.
> 
> Fair enough, though it seems unlikely that --list-missing would cause any
> trouble... but you are the debhelper expert ;)
> 

It is not that --list-missing in itself will cause a lot of issues.  It
is that the documentation from v10 -> v11 is dauntingly long already and
I want to avoid making it worse.
  In fact, I have already moved a handful of things to compat 12 to
reduce the scope of v11.

>> As for the sequences; we can add those to the next version of debhelper
>> (a sequence change the parameters passed to a helper).  If you file a
>> bug for it with how you envision that, then I am happy to add it in one
>> of the next uploads of debhelper. :)
> 
> No need for a sequence if dh_missing starts doing something useful by default.
> 
> Cheers,
> Emilio
> 

Ack.  I mainly proposed it for enabling easier dh_missing already in
compat 11.  That said, we might get enough compat 12 items that it would
make sense to release compat 12 before the release of buster.

Thanks,
~Niels

Re: Open beta of debhelper compat level 11 (debhelper/10.10.7)

[Niels Thykier]

Christoph Biedl:
> Emilio Pozuelo Monfort wrote...
> 
>> One thing with compat 10 that doesn't make a lot of sense to me is how
>> dh_missing is enabled by default but a no-op. It'd make more sense to me to
>> change that in compat 11 to be enabled by default and run with --list-missing
>> (--fail-missing is probably too much at this point), or make it run with 
>> --list
>> or --fail-missing, but not enabled by default, and make it an addon.
> 
> As I planned to create a related wishlist bug report about that issue:
> Agreed.
> 
> The --fail-missing option saved my lower back many times in the past,
> even when it was placed in dh_install. Therefore I'm certain it would
> help other people as well. In other words, I was about to suggest to
> make --list-missing the default in 11, and switch to --fail-missing
> in 12.

Noted. :)

> Those who somehow manage to trigger a false negative (possibly
> dracut is one of these) would have to use a --ignore-missing override
> (not yet implemented) then, or use a more elaborate ignore mechanism:
> 

They have two options (both are already implemented):

 dh_missing --exclude 
 echo '' >> debian/not-installed

> That is debian/not-installed which should no longer ignore file paths
> then, also drop the warning on the usage of this file.

What made you consider the use of debian/not-installed discouraged?

I am not aware of any intentional warning against using
debian/not-installed.  The only two "warnings" related to not-installed are:

 * Wildcards are not supported.
 * It is not a fancy global "--exclude" mechanism; only a list of files
   that are (intentionally) missing.  I.e. it will not make dh_install
   ignore the file.


> There are often
> files that should not go into a package, *.la files from library
> packaging to begin with. Given the suggested policy change above, their
> number will increase. Overriding dh_install defeats readability of
> debian/rules, also -X might hit more files than intended.
> 
> Christoph
> 

Your concrete example suggests this could be solved by wildcard support
in debian/not-installed.  Would that work for you? :)

> PS: Talking about "planned to create a wishlist bug report" ... after
> losing several hours while fiddling with dh_systemd_* I saw the need for
> a cleanup. Glad to see it's already underway.
> 

You are welcome. :)

I was considering to punt this until compat 12, but then I found several
bugs in the interaction between dh_systemd_enable and dh_installinit.
The fixes caused a handful of RC bugs in other packages, which made me
realise that we should fix this sooner rather than later.

Thanks,
~Niels