Re: Any volunteers for lintian co-maintenance?

[Niels Thykier]

Soren Stoutner:

I would like to respectfully disagree will some of the opinions expressed in 
this email.



Hi Soren

Not sure if we disagree all that much to be honest. :)


First, I should say that I am painfully aware of how long it takes to run 
lintian on large
packages.  When working on qtwebengine-opensource-src it takes my system (Ryzen 
7
5700G) about 2 hours to build the package and about half an hour to run lintian 
against it.
I would be completely in favor of any efforts that could be made in the 
direction of making
lintian more efficient, either within lintian itself or in other packages that 
replicate some or
all of lintain’s functionality in more efficient ways.

However, I personally find lintian to be one of the most helpful tools in 
Debian packaging.
When going through the application process I found lintian to be a very useful 
tool in
helping me learn how to produce packages that conform to Debian’s standards.  
The
integration of lintian into mentors.debian.net was very helpful to me when I 
first started
submitting packages to Debian, and it is still helpful to me when reviewing 
other people’s
packages that have been submitted to mentors.debian.net.



I agree that lintian has useful features as stated in my original email. 
Though not with a very strong emphasis, so I can see how you might have 
not have given that remark much thought.


After a bit more reflection, I feel lintian is currently working in 
three different areas (to simplify matters a lot).


 1) Support on Debian packaging files.
- You have a comma in `Architecture`, which is space separated
- The `foo` license in `d/copyright` is not defined
- The order of the `Files` stanzas are probably wrong.
- The `Files` stanza in `d/copyright` reference `foo` but that file
  is not in the unpacked source tree.

=> This should *not* require a assembled package to get these
   results and should provide (near) instant feedback directly
   in your editor. This area should be designed around interactivity
   and low latency as a consequence.

 2) Checking of upstream source.
- Missing source checks
- Source files with known questionable licenses
- Here are some dependencies that might need to be packaged.
- The upstream build system seems to be `waf` so you should be
  aware of this stance in Debian on `waf`, etc.
- Maybe: "Advice for how to approach this kind of package".
  (like "This seems like a python package; consider looking at $TOOL
  for an initial debianization. The python packaging team might be
  relevant for you if you are a new maintainer, etc.)

=> This should *not* require a assembled package to get these
   results. However, it will take some time to chew through all
   of this. It would be a "before initial packaging" and maybe
   on major upstream releases (or NEW checks).  It will be a batch
   process but maybe with support for interactivity.


 3) Checking of assembled artifacts.
- Does the package place the systemd service in the right place?
- There is a trigger for shared libraries but no shared libraries.
  (etc.)

=> This (by definition) is for assembled packages. It will be a
   batch process.


Part 1) is something I feel would belong in a tool that provides on-line 
/ in-editor support (see my post script for details). This is partly why 
expanded `debputy` to into this field. You having a 2½ hour feedback 
loop here is crazy - the `acl2` one having 9+ hours is complete madness.


Part 2) is ideally something you would run before attempting to package 
a new upstream source tree. Many of these things have a high impact on 
whether you want to continue with the packaging (oh, I need to package 
20 dependencies first. It has non-free content, etc.). The fact that you 
need to build a package only to discover that your package cannot be 
distributed seems backwards to me. I feel this workflow should work from 
the basis of:


  $ git clone $UPSTREAM source-dir # (or tar xf ...)
  $ check-upstream-code source-dir

Note: This is not an area I am going to tackle. But if I was going into 
it, that would be my "vision" for the starting point.


Part 3) is where I feel lintian still has an area to be in (which also 
matches its mission statement). It could also include a subset of the 
results from part 1+2 as a "all-in-one-inclusive" wrapping to simplify 
archive-wide QA or sponsoring checks. But as I see it, most 
(non-sponsor) users would ideally get their 1) and 2) feedback from the 
more specialized tools.


These are the ballparks I would split lintian into given infinite 
developer time and resources. Ideally not a lot "smaller" than this to 
avoid drowning people with the "Run these 1000 tools"-problem to avoid a 
repeat of `check-all-the-things`. This is also why I am not again 
lintian aggregating from the other areas. For some of its users (such as 
sponsors) it will be a useful 

New editor integrations for Debian packaging files (LSP support)

[Niels Thykier]

Hi

Sent to d-devel and d-mentors, since the members of both lists are the 
target audience. If you reply, please consider whether both lists should 
see the message (and prune the recipient list accordingly as necessary).



In response to a recent thread on debian-devel about editor support for 
Debian packaging files, I have spend some time providing better 
experience when working with Debian packaging files. Concretely, I have 
added a Language Server (per LSP spec) to `debputy` that supports files 
like "debian/control" and "debian/copyright" (machine readable variant 
only).



With this language server and a LSP capable editor, you will get:


 * Online diagnostics (in editor linting result).
   - Instant gratification for common or simple errors. No need to wait
 for a package build to run `lintian`. Also, if `debputy` knows a
 solution, it will provide quick-fixes for the issue.


 * Online documentation ("hover docs") for relevant fields and values.
   - You do not have to remember what things mean nor context switch
 to look up documentation! It is served directly in your editor
 when you request it via your editors "hover doc" feature.


 * Context-based completion suggestions for known value or fields.
   - As an example, the completion will not suggest completion for a
 field already in the current stanza of debian/control (since
 that would lead to an error).


 * Automatic pruning of trailing white spaces!
   - If your editor supports the "on save" feature, the language server
 will trim away trailing white space in the Debian packaging files.
 (it is a small thing, but it is still one paper cut less!)


The diagnostics can also be used without the language server. Which can 
be used for CI or when you do not have an LSP capable editor. It works 
_without_ building the package first (unlike lintian) and it does have 
an --auto-fix option (also, unlike lintian).
  On the other hand, the diagnotics/linter is not a replacement for 
lintian. The `debputy` LSP/Linter is solely aimed at providing editor 
support Debian packaging files, which is a much narrower scope than lintian.



For those interested, there are some screenshots from emacs with this 
language server at: https://people.debian.org/~nthykier/lsp-screenshots/


As mentioned, any LSP capable editor should work. Which includes:
 * neovim
 * vim (with `vim-youcompleteme`)
 * atom/pulsar
 * VS Code (unsurpsingly, since Microsoft created the LSP spec)
 * Eclipse (via the `lsp4e` plugin)
 * ... and many other editors


# Getting started

To use these new features, you will need:

# Preferably, 0.1.26 (unstable)
# Though, dh-debputy/0.1.24 (testing) will do
$ apt install dh-debputy python3-lsprotocol python3-pygls

# If you want online spellchecking, then add:
$ apt install python3-hunspell hunspell-en-us

# Check if debputy has config glue suggestions for your editor
# - note: the output may contain additional editor specific
#   dependencies.
$ debputy lsp editor-config
$ debputy lsp editor-config EDITOR_NAME

# Once your editor is configured correctly, it should start the
# language server on its own when you open a relevant file.

# Using the diagnostics without the language server.
#  - Check --help for additional features.
$ debputy lint

Additionally, for the editor features, you will need an LSP capable 
editor and relevant editor configuration glue for said editor. The 
`debputy lsp editor-config` command will list known editors and `debputy 
lsp editor-config EDITOR` will provide an example editor glue. These 
examples are maintained on a "best-effort" basis.


At the moment, `debputy` knows about `emacs` with `eglot` (built-in in 
emacs/29) and `vim` with `vim-youcompleteme`. For other editors, you 
will have to figure out the glue config - though, feel free to submit a 
MR against the `debputy` repo, so others can benefit from it.


If you end up having to do your own editor config glue, you can start 
the language server via `debputy lsp server` (check `--help` if you need 
TCP or WS integration).




## Supported files

For the full list, please see `debputy lsp features`. The `diagnostics 
(lint)` lines also explain where `debputy lint` has support.


Version 0.1.26 of dh-debputy adds support for `debian/tests/control`. 
For `emacs`, the next version of dpkg-dev-el (RFS'ed in #1068427) is 
also needed for `debian/tests/control` support.



# Future work

 * There will be bugs. Lots of bugs.
   - Issues and MRs are welcome at
 https://salsa.debian.org/debian/debputy/-/issues
   - BTS bugs (with or without patches) also work. 

 * There are lot more diagnostics that could be triggered.  Feature
   requests welcome (see above).

 * Most of the hover documentation could probably use a review.

 * Most of the editor glue provided via `debputy lsp editor-config`
   should probably end up in packages somehow.

 * All this requires 

Re: [Summary]: Another take on package relationship substvars

[Niels Thykier]

tho...@goirand.fr:



[...]

Hi Niels,


Thanks a lot for your work on this, I very much agreed with the premiss that 
subst vars were a thing easy to fall into traps. It is a very welcomed 
improvement to automate them and avoid mistakes.


Is there a place where you wrote some kind of doc about how to use debputy or 
debhelper compat 14? Does one need to add debputy as build-depends, and that is 
it? Pointers to URLs welcome.


Cheers,


Thomas Goirand (zigo)




Hi Thomas

Thanks for the feedback. :)

I have added the information you requested below. For follow ups on how 
to migrate or `debputy` vs. `debhelper`, then I am happy to have 
discussions on those. However, please move it to a separate 
thread/channel/subject to ensure people can easily tell whether the 
discussion is relevant to them. :)



# For debhelper:

Usage of debhelper compat 14 can be done by replacing
the Build-Depends on `debhelper-compat (= 13)` with
`debhelper (>= 13.15.2~)` and then adding `X-DH-Compat: 14` to the 
source stanza of `debian/control`.


Remember to check the compat upgrade checklist in
`man 7 debhelper-compat-upgrade-checklist` before doing it and keep in 
mind that compat 14 is open for additional changes.




# For debputy:

On what debputy is, I would recommend the ITP bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029645



On how to use it at its minimum level (sufficient for getting automatic 
relationship substvars), the short story is:


   # Note: 0.1.22 is not a typo; it was uploaded to unstable earlier
   # today. It provides better documentation related to migration
   # plus some other unrelated bugfixes.
   $ apt satisfy 'dh-debputy (>= 0.1.22)`
   $ debputy migrate-from-dh \
  --migration-target dh-sequence-zz-debputy-rrr
  [--apply-changes]
   [... Read the output and handle any manual migration items ...]

The vast majority of packages should be able to use `debputy` at this 
level - some with more manual migration than others. The 
`dh-sequence-zz-debputy` migration target (note the missing `-rrr`) is 
more likely to have missing features that would be necessary for 
wide-spread adoption.


For additional information, you may want to read:

 * man debputy . Particularly the section on `migrate-from-dh` and
  `INTEGRATION LEVELS`
 * GETTING-STARTED-WITH-dh-debputy.md (/usr/share/doc/dh-debputy)
 * MANIFEST-FORMAT.md (/usr/share/doc/dh-debputy)



Though, either way (debhelper or `debputy`), you will be on fairly 
cutting edge features. :)


Best regards,
Niels

Re: [Summary]: Another take on package relationship substvars

[Niels Thykier]

Niels Thykier:

Hi

It seems the discussion on this topic has settled, so I am now doing a 
summary of the discussion as I understand it.


  * Generally, the original proposal seems to have been received
    favorably at a conceptual level.

[...]


A follow up on this:

 * The proposal is now implemented in debhelper compat 14 (as of version
   13.15+) and debputy (0.1.21+).

 * The `debputy` migration tool will flag any obsolete substvars that
   are 1:1 with what `debputy` would have applied for you. No tool for
   debhelper-based packages exist at this time.

 * Lintian is not updated yet and will still complain about missing
   relationship substvars. I have filed #1067653 to have that changed.

I expect this to be final on this topic for this round. :)

Best regards,
Niels

[Summary]: Another take on package relationship substvars

[Niels Thykier]

Hi

It seems the discussion on this topic has settled, so I am now doing a 
summary of the discussion as I understand it.


 * Generally, the original proposal seems to have been received
   favorably at a conceptual level.

 * Several people requested the scope to be expanded to extra fields.
   So far, no one seems to have questioned any of the extra fields
   proposed. Accordingly, I will expand the scope to all mentioned
   extra fields (such as Built-Using/Static-Built-Using and negative
   relationship).

 * My alternative proposal of making relational substvars mandatory
   did not have anyone supporting. Additionally, Simon McVittie provided
   a strong argument for why the alternative would scale poorly. Given
   the argument from Simon and no one openly supporting that proposal,
   I am considering it a dead-end with no support.

 * All the concerns raised related to promotion and demotion of
   substvars were related to the shlib subvars (such as
   ${shlib:Depends} vs Pre-Depends/Recommends). I have yet to see anyone
   concerned about a non-shlib related variable, which is great since
   dpkg-shlibdeps as the only substvars provider has infrastructure for
   promotion/demotion. No case presented seems to have been problematic
   nor controversial. I have included an extended section below on this
   topic for the details, should you be interested in those.

 * Guillem proposed some concrete ideas for moving parts of the
   implementation into the dpkg layer, which seems fine with me.
   I consider these implementation detail and will handle that
   bilaterally with Guillem.

In other words, it seems like there is consensus that this proposal at a 
conceptual level is acceptable. I will look into the implementation 
details with Guillem (as mentioned, in a smaller forum).


I fully anticipate that there will be a transition for this feature 
(such as a debhelper compat bump) to ensure we have a controlled 
migration. Notably substvar demotion does not work out of the box (see 
below) as one of my arguments to ensure it happens in a controlled manner.





   = Detailed explanations =

From here on, I will expand on the substvars cases and how they work. 
If you are not interested in those, you can stop reading as the 
remainder of the email is dedicated only to this topic.



# Promotion and demotion of substvars

For those, who are curious or concerned about promotion or demotion of a 
substvar, here is an extended coverage of cases presented in the 
discussion and how they work.


First, a bit of terminology as people might not have read the full 
thread. I use the word "promotion" when the substvar is used in a 
**stronger** field that the one it is named for. Example:


# The substvar in this example is promoted to Pre-Depends
Pre-Depends: ${shlib:Depends}

Demotion is the opposite. Here the substvars implies a strong field than 
the one it is used in:


# The substvar in this example is demoted to Recommends
Recommends: ${shlib:Depends}


For the case, where the tool can split the substvar into multiple 
substvars, I will use the phrase selective promotion or selective 
demotion of the content. The only known tool that supports this is 
`dpkg-shlibdeps` and the only known usage involves the ${shlib:*} namespace.



There are multiple cases to cover and how they would interact with this 
proposal:


 * Selective promotion/demotion of content (Unaffected)

 * Full substvar promotion (Unaffected)

 * Full substvar demotion  (Breaks)

 * Manual fiddling with substvars  (Unaffected)

Each will be expanded in their own subsection below. The `(Unaffected)` 
and `(Breaks)`-marker represents what happens in a rebuild of an 
unchanged source package with with this proposal suddenly active. As 
mentioned, I expect we will do this as an a opt-in style transition to 
avoid unexpectedly triggering any cases that might break.



## Selective promotion/demotion of content


Selective promotion and demotion of the content works out of the box 
with this proposal.


 * The logic for splitting a substvars will generally be in debian/rules
   via manual calls to dpkg-shlibdeps or dh_shlibdeps. This part remains
   unaltered.

 * The main difference is that you no longer have to manually any of the
   substvars in debian/control.

This method generally only works with dpkg-shlibdeps, since that is the 
only tool with infrastructure to do the splitting. At the same time, it 
is also the only substvar provider mentioned in the discussion so far, 
where anyone had an example of needing promotion or demotion.



Note in this case, the split off substvars will be named are the field 
they go in. Strictly speaking, none of the substvars have been promoted 
nor demoted in this particular case. This is also why it is promotion / 
demotion of **content** rather than of the substvar itself.



## Full substvar promotion

This is the case of doing 

Re: Another take on package relationship substvars

[Niels Thykier]

Gioele Barabucci:

On 24/02/24 11:26, Bernd Zeimetz wrote:

On Thu, 2024-02-22 at 20:52 +0100, IOhannes m zmölnig wrote:

I think there are some packages that even demote `${shlibs:Depends}`
to Recommends.


Absolutely. collectd for example - otherwise you would install *all*
plugin dependencies with collectd, which would be a big waste of space.

The other option would be to make one packe per plugin as redhat does,
but do we really want 20 packages with a single file?


Yes, please. So that installing package collectd-foo ensures that all 
the required dependencies are installed, instead of having to hunt them 
down (a task better left to the package maintainers rather than the end 
users).


PS: I volunteer to do the splitting.

Regards,



For the people following from home, collectd is a non-issue for this 
proposal since it uses dpkg-shlibdeps to split the substvars into the 
buckets it wants and therefore everything would "just work"(tm).


Whether collectd should be split might be a relevant conversation but 
please take it in a separate thread or in the BTS. Thank you! :)


Best regards,
Niels

Re: Another take on package relationship substvars

[Niels Thykier]

Steve Langasek:

Hi Niels,

On Thu, Feb 22, 2024 at 07:32:21PM +0100, Niels Thykier wrote:

[...]



I am omitting Breaks, Conflicts, and Replaces because I am not aware of any
users of these at the moment. I am open to adding them, if there is a strong
use-case.


One generic case that this doesn't handle is Essential: yes packages.  For
many of these, the ${shlibs:Depends} gets promoted in debian/control to
Pre-Depends, not to Depends.

Maybe it would make sense to auto-aggregate these substvars, *IFF* there is
not already a reference to the substvar in question in the package stanza in
debian/control?  This would provide adequate flexibility for any other
exceptions that might be out there, beyond the Pre-Depends case.

Cheers,


In case of a promotion, it does not matter if ${shlibs:Depends} is 
applied twice (once in Depends and in Pre-Depends}. You get the 
dependencies twice and then dpkg will clean up the duplicates in favor 
of the "strongest" dependency[1]. The hard part is a demotion because 
this duplication works against you.


Accordingly, the Essential: yes packages that leverage this technique 
can just keep doing it without any changes or consequences as far as I 
can tell.


Best regards,
Niels

[1] man:dpkg-gencontrol(1):


   dpkg-gencontrol reads information from an unpacked Debian source tree 
and generates a binary
   package control file (which defaults to debian/tmp/DEBIAN/control); 
during this process it will
   simplify the relation fields.

   Thus Pre-Depends, Depends, Recommends and Suggests are simplified in 
this order by removing
   dependencies which are known to be true according to the stronger 
dependencies already parsed.
   It will also remove any self-dependency (in fact it will remove any 
dependency which evaluates
   to true given the current version of the package as installed).  
Logically it keeps the
   intersection of multiple dependencies on the same package.  The order of 
dependencies is
   preserved as best as possible: if any dependency must be discarded due 
to another dependency
   appearing further in the field, the superseding dependency will take the 
place of the discarded
   one.

Re: Another take on package relationship substvars

[Niels Thykier]

Guillem Jover:

Hi!

On Thu, 2024-02-22 at 19:32:21 +0100, Niels Thykier wrote:

[...]


Right, this is annoying. This was actually brought up some time
ago (2010) in debian-devel as part of #597340. There was not much
reaction at the time (one good, a couple bad).



I reinvented a decade old idea that I forgotten existed, but very much 
remember having read in the past now that I see it again.



# How do we get here?

High level, any helper framework above dpkg can provide this feature if it
wants to. It is basically a question of parsing d/*.substvars to figure out
which substvars are relevant, compute a new field from substvars file + the
static provided data from d/control, and then passing -DField=<...> to
dpkg-gencontrol.

There are probably a bunch of nitty gritty implementation details in
practice, but the overall approach stands.

I think each helper stack (debhelper, cdbs, debputy, etc.) would define
their own rule set for how to get there. As an example, I could see this be
the new default in the next debhelper compat level, possibly with a way to
be early adopter on existing compat levels.


If we agree we want this implicit mechanism of adding some substvars
to fields, then doing it in helpers seems like a suboptimal path, as
each one would need to replicate the logic, and implement substvar
substitution logic. I think if this is to be done, it should be done
at the dpkg-dev level.

[...]



I am happy to look into moving parts of the responsibility of this into 
dpkg. Though, I would like to move that part of the discussion to 
debian-dpkg as for the vast majority this is implementation detail.


For the hand-full of people that wants to be in the discussion, I don't 
think it is a major ask to have them track debian-dpkg for a short while.



## Alternative solutions

We could also make unused substvars a hard failure (FTBFS). Personally, I
feel auto-managing them will be less painful for users. But if the consensus
goes down this direction, then I would be behind it as it is still better
than the status quo in my book.


I also implemented in that branch another operator !=, which marks a
substvar as required, so failure to use it will generate an error. I
might have to move the error emission into some other function that
is not called warn_about_unused() though… :)



Ok.

Based on Simon's follow up, I suspect we will not be going down this 
route. Obviously, dpkg can still support the feature either way. :)



That is my proposal for how Debian contributors can spend less mental effort
tracking relationship substvars and use their new spare mental capacity
providing value for our users. Thanks for reviewing the proposal and any
feedback you might have for making relationship substvars be less annoying
for users and Debian as a whole.


Personally I think I agree with this being a problem and with a
potential solution for this based on implicit substvars. [...]

Thanks,
Guillem



Thanks for the feedback.

(The snipped part I believe I already answered above)

Best regards,
Niels

Re: Another take on package relationship substvars

[Niels Thykier]

IOhannes m zmölnig:

[...]

While I like the idea in general, I wonder how I could override these automatic 
additions.
I think there are some packages that even demote `${shlibs:Depends}` to 
Recommends.


mfh.her.fsr
IOhannes



I had the same conceptual concern when I originally thought about this 
proposal. However, first off, I am not aware of wide-spread usage of 
people demoting entire substvars.


If it was to happen, I suspect that ${shlibs:Depends} would not be the 
best argument. First off, dpkg-shlibdeps has infrastructure to 
selectively demote scanned elf binaries to a different substvar. 
Secondly, I struggle to think of a real world case, where demoting 
${shlibs:Depends} would matter a lot. That is, a case where the right 
answer is not just splitting these binaries into a separate package if 
they are that consuming in dependencies.


Additionally, Colin replied with the solution of "tweaking" the 
substvars file. I was aware of that solution, but I did not want to 
promote it as a general solution, so I omitted it from my ideal email.


If we find ourselves regularly "correcting" substvars in every package, 
then I think we owe ourselves to consider if we have a bug that needs 
fixing. Not sure we are there yet given a single example (the one in 
Colin's email). However, I be interested to know how frequent this 
pattern is and whether we therefore should look at fixing this at a 
different layer.


Best regards,
Niels

Re: Another take on package relationship substvars

[Niels Thykier]

Simon McVittie:

On Thu, 22 Feb 2024 at 20:43:21 +0100, Niels Thykier wrote:

Simon McVittie:

On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:

We could also make unused substvars a hard failure (FTBFS).


I'd prefer not this


Reminder: My proposal only covers ${foo:Depends} and similar substvars. The
first example you present uses substvars that do not match that pattern.


Sorry, did you mean that your alternate proposal is: we could make unused
substvars **that match *:Depends** (and the other related patterns) a hard
failure, without affecting substvars not matching that pattern? If so,
that wasn't obvious to me!



Indeed, that is what I meant. I see that others had the same confusion, 
which could probably avoided if I had said "relationship substvars" 
instead. Sorry for the confusion.



If the scope of "unused substvars => hard failure" is limited to
foo:Depends and so on, then yes, I agree that the concern I described
doesn't apply.



Thanks for confirming.


Another reason to be cautious about making missing foo:Depends a hard
failure is that it would mean tools usually can't add new :Depends without
either gating it behind a debhelper compat level bump (or equivalent),
or making potentially large numbers of dependent packages regress
(usually discouraged). So I still prefer your initial proposal.

 smcv



Thank you. I agree with this counter argument. That seems like a very 
annoying problem to deal with that will likely cause a lot of extra 
"infrastructure" that I think nobody wants.


Thanks for the feedback. It was very useful :)

Best regards,
Niels

Re: Another take on package relationship substvars

[Niels Thykier]

Boyuan Yang:

[...]

Can we also consider ${*:Built-Using} as typically seen in 
${sphinxdoc:Built-Using}?
This is another field that people keep forget adding. While missing
this field is not severely harmful, having it automatically handled
would be beneficial.

Thanks,
Boyuan Yang


Personally, I see no problem with adding this provided the current use 
of it correctly matches that of the Built-Using field (which is for 
license requirements and not just static-linking as far as I know).


By the same argument, we can add Static-Built-Using as well (or whatever 
field people are using to record static linking relationships), if any 
tool provides such a variable.


Best regards,
Niels

Re: Another take on package relationship substvars

[Niels Thykier]

Simon McVittie:

On Thu, 22 Feb 2024 at 19:32:21 +0100, Niels Thykier wrote:

I think our package helper tooling should just automatically aggregate all
provided substvars of the format ${*:Depends} and append it the Depends
field. Rinse and repeat for other relationship fields.


I recently added ${gir:Provides} to dh_girepository, and the proposed
feature would have meant instant wide adoption without source changes.
So I like this plan!



Thanks for the feedback.

I was not aware that ${gir:Provides} was new. :) But indeed, I was 
hoping the proposal would simplify this kind of roll out in the future!



The only thing I'm wary of is that if the helper tools might sometimes
generate a substvar that is well-meaning but inappropriate (even in corner
cases), we might need an off-switch for this behaviour. At the moment you
can just not add the substvar (and silence or ignore the lint warnings),
but the proposed change would make that impossible.



In my original proposal, I did cover how to make all sorts of exceptions 
for this case. But I am not aware of a real case where this matters.


So before I invest in a corner case that might not even exist, is anyone 
aware of this being a regular case that might warrant general tool 
support? Or we are trying to plug a hole that never was?



On the dependency side, dpkg-shlibdeps already has -dRecommends, -dSuggests
and so on, but not all other helpers have this (e.g. #934893), and
maybe it would be useful to have a conventional option to turn off the
dependency-generation altogether in the hopefully rare cases where it
does more harm than good?



Again, before we invest a lot in creating an API for features for this, 
do we see cases that need fixing that cannot "just" be solving by 
improving the tool providing the substvars itself?



On the Provides side, I don't think there's any similar convention.


We could also make unused substvars a hard failure (FTBFS).


I'd prefer not this, because this would be really painful if you're
using substvars for something other than a simple list of dependencies,
like gobject-introspection does:

[...]




Reminder: My proposal only covers ${foo:Depends} and similar substvars. 
The first example you present uses substvars that do not match that 
pattern. Therefore initial reaction is that this effectively ends up 
being a straw man argument because it does not correctly account for the 
scope of this proposal.



I'd prefer not to put lots of glue into debian/rules to generate these
substvars for precisely the packages that use them, because that's
another thing to keep in sync between d/control and d/rules (so at the
moment I'm ignoring dpkg-gencontrol's complaints about these substvars
being mentioned in some but not all binary packages).

Conversely, I could have implemented most of this by generating per-package
${local:Provides} and ${local:Depends}, but if I did that, then I'd have to
encode half of each binary package's dependencies in d/rules.
I'd prefer to be able to look at d/control and see the overall "shape" of
the interdependencies - "this Depends on binutils-something:any,
gcc-something, ..." - rather than having that information in d/rules.

 smcv



Could you please clarify if the rest of this argument is still relevant 
given the example seemed to be off? I am happy to entertain it, but I 
would prefer working from a state where we both agree that it is 
relevant, before I invest effort to understand it.


Best regards,
Niels

Another take on package relationship substvars

[Niels Thykier]

Our current way of dealing with package relationship substvars such as 
${misc:Depends} has been annoying me for a while. As it is, we are stuck 
in this way setup where the "Depends" field in debian/control is de 
facto mandatory. It is an RC bug (waiting to happen) if you omit 
${misc:Depends} or, for arch:any packages, ${shlib:Depends} from the 
dependency field.


Personally, I feel we have this weird setup where we have tooling that 
will scream at you if you forget. But I lack a compelling reason for why 
we need tooling to remind us when we could just as well have tooling 
solve this problem for us.
  Additionally, our tooling for reminding us rarely knows about 
anything but the 2-3 standard substvars everyone uses even though we 
should get reminders for other substvars like ${python3:Depends}, 
${gir:Depends}, etc. Particularly the rules for when a substvars is 
applicable turns out to be quite non-trivial.


I have given this some thought and I think I have a conceptually idea 
for how to solve this, which I will go over in this email.


# Scope

Just to ensure we are on the same page.

When I am talking about package relationship substvars, I mean basically 
any substvar of the format ${*:} where Field is a relationship 
field such as Depends, Pre-Depends, etc.


Other subvars like ${binary:Version} are out of scope for this proposal. 
This also includes other variables such as ${gnome:Version}.



# The proposal

I think our package helper tooling should just automatically aggregate 
all provided substvars of the format ${*:Depends} and append it the 
Depends field. Rinse and repeat for other relationship fields.


The list of fields where this is applied would be curated, so it only 
applies to known relationship fields where we feel it makes sense. My 
starting list would be:


 * Any dependency field, that is: Pre-Depends, Depends, Recommends, and
   Suggests

 * The Provides field.

I am omitting Breaks, Conflicts, and Replaces because I am not aware of 
any users of these at the moment. I am open to adding them, if there is 
a strong use-case.


# The advantages

Thanks for humoring me so far. Obviously, this is a change and there 
should be a benefit to changing the status quo that outweighs the cost 
of the change itself.


I see the following advantages:

 1) As a consumer of a tool, I would no longer have to remember if and
when to add a custom substvars. Tools providing dependencies or
provides will provide them automatically without requiring me to
do anything. This means I spend less time maintaining d/control
files where tool can and should just solve this problem for me.
(see the next section for how many substvars we are sporting)

 2) As a provider of a substvar generating tool, I would be able to
focus my documentation on other things than "Please, pretty please,
remember this subtvars!". Instead, I can focus on what problems my
tool will solve for you and then push the substvar into a footnote.

 3) As a distribution, it becomes a lot easier to do archive-wide
changes. Remember the "multiarch-support" a decade ago where all
shared libraries had to be updated to add
`Pre-Depends: ${misc:Pre-Depends}`? How about all the
`Provides: ${t64:Provides}` that are added now that people have to
remember to remove on their next soname bump? Would have been an
non-issue if these substvars were applied automatically.

 4) As a provider of linting tool, I no longer have to remind people
about idiosyncratic rules of Depends being pseudo-mandatory. Nor
spend hours figuring out whether I should mind people to add
${foo:Depends} plus ${bar:Provides}. Nor do I have to learn when
those substvars are applicable to a package. Instead, I can
recommend users to migrate to the new tool stack that gives them
the advantages listed above. Much better use of my time and gives
more benefits for everyone.

The first advantage would apply immediately per package for consumers 
that has migrated to this flow. For the other items, as adoption 
increases the pain point decreases.


# Is there really a problem?

You might be of the belief that substvars are easy to manage. There are 
just the two, ${misc:Depends} and ${shlib:Depends}, right? No, we have a 
lot of substvars that we have to remember and they different rules for 
when they apply.


 * ${misc:Depends} and ${misc:Pre-Depends} should *always* be added to
   Depends and Pre-Depends respectively.

 * ${shlib:Depends} should be added to Depends for arch:any but not
   arch:all. Additionally, if you use dpkg-shlibdeps with -d you have
   to remember to add a new shlib sustvar to other fields as well.

 * ${t64:Provides} should be added to shared library packages that are
   a part of the ongoing time_t transition.

 * The ${gir:Depends} and ${gir:Provides} should be used for packages
   that use dh_girepository. Though I think it only provides them for
   packages that 

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Otto Kekäläinen:

Hi!

Thanks for the tip, Niels!

It would be cool if dh_assistant had some kind of generic command like
"dh_assistant validate" which would attempt to introspect all
information silently and emit output only if it fails to parse
something.


That might be an option. The question is what more would you expect here 
that is actually feasible to implement. :)


Feel free to propose concrete ideas and I will have a look at them. 
Sadly, debhelper was never designed to be introspect-able, but depending 
on the ask it might be doable or doable with some limitations.



Additionally it could emit a non-zero exit code on errors.
I tested your latest command and it works as you expected, though it
does not use exit code.
> # dh_assistant detect-unknown-hook-targets
The hook target override_dh_car_configure in debian/rules does not
seem to match any known commands.
# echo $?
0



Adding an exit 2 as a "linter" exit code in the next version with a 
"--no-linter-exit-code" (open for better names) to have it always return 
0 (which I suspect will be easier for some users).



Also if the JSON included the filename and line number of the finding
it would be handy:

{
"unknown-hook-targets": [
   {
  "candidates": [],
  "filename": "debian/rules",
  "target-name": "override_dh_car_configure"
   }
]
}



I would be happy to include that. Unfortunately, I only have the 
information available from:


  LC_ALL=C make -Rrnpsf debian/rules debhelper-fail-me 2>/dev/null

Which seems to have the following limitations:

 * filename/line is *not* included for "empty" targets

 * When a line number is present, it is for the first line of the recipe
   and not the target definition itself. One might be tempted to do
   (lineno - 1) but it is not accurate[0].

I am open to suggestions for this that does not involve parsing the 
makefile itself. I will leave ad-hoc parsing of Turing complete 
languages to other programs.




I don't know how much ambition you have for expanding the scope of
dh_assistant.


The dh_assistant tool is growing organically based on requests, or 
things I need, or when I notice people needing to introspect something 
and I can easily provide it via dh_assistant. :)


I did not aim for it to be a full-fledged linter, though I do not mind 
adding debhelper related linting where possible.




We already have Lintian which has a massive amount of
checks, including ones related to debian/rules. It is just a pity
Lintian does not support checking a single file or the debian/
directory contents without building the package.. [1]

[1] https://bugs.debian.org/262783


The infrastructure and design choices of lintian is working against 
lintian here. I doubt #262783 will ever be solved as there is a major 
difference between a 'clean assembled packages' and the '"mess" you call 
a git checkout".
  Even if we get #262783, a lot of lintian checks are written to check 
.deb packages because that is the final result and you avoid a lot of 
"what if d/rules decided to do X - what if it does *not* do X" 
ambiguity. Which the person who does #262783 would probably also spend a 
lot of effort porting binary checks in to the ("dirty") source context 
where you have less context.




I looked into better tooling/editor support in general for Debian 
languages in general. I think the industry answer is that "someone" 
ought to build a "language (LSP) server" for the Debian languages, which 
would enable editors with LSP support[1] to get the same basic features.


Among features that LSP servers can provide are:

 * Configurable on save actions (such as wrap-and-sort)
 * Format file on user request (wrap-and-sort, again)
 * Diagnostics (linting)
 * Text highlighting / inline documentation / inlay hints
 * Auto-completion

The first half is basically what you are looking for and the latter half 
is what I have been focusing on in my plugin, so it does seem to cover 
our interests.


I might have a stab at writing a prototype for a LSP for Debian formats. 
But it will not be in `dh_assistant`.


Best regards,
Niels

--

[0]: Sample makefile

"""
my-target:
# Some makefile level comment (not indented)
first line of the target definition
"""

Here the line number reported by make would be 3, but the target 
definition is actually line 1 (so doing a -1 would be "off by one per 
line of comment")


[1]: Which allegedly includes:
 * emacs via eglot (?), which comes built-in these days
 * neovim
 * atom/pulsar via plugin (?)
 * IDEA via open source plugin or builtin via their paid subscription

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Niels Thykier:

[...]

Btw, `debhelper` has a `dh_assistant` command that can do some very 
basic analysis as well. Not sure any of it is useful for editor 
integration (especially because some of the features requires that it 
receives the same arguments as `dh` or/and `dh_auto_configure`).
   Personally, I have used `dh_assistant detect-hook-targets` to detect 
which overrides that `dh` would pick up (relies heavily on 
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not 
in an editor context but if you can combine it with something that reads 
known make file targets, you could get a "override_typo looks like an 
override target but `dh` does not recognize it"-style warning out of it.


Maybe I should just add that feature directly to `dh_assistant`. Then 
you can have one more command for your checklist! :D


Best regards,
Niels




Ok, added this to debhelper/13.11.10:

$ apt satisfy 'debhelper (>= 13.11.10), libtext-levenshtein-perl'
$ dh_assistant detect-unknown-hook-targets [--output-format=json]

The code can have false positives - especially if you use `dh ... --with 
...`.  In that case, you have to pass the same `--with ...` to 
`dh_assistant` to avoid the false positive. All the more reason to use 
declarative `Build-Depends: dh-sequence-foo`.


For machine output use the JSON format (lintian/lintian-brush, etc.). 
The text output is subject to change. MRs for improvements welcome at 
https://salsa.debian.org/debian/debhelper/


End sidebar/thread hijack.

Best regards,
Niels

Re: Editor extensions to help editing debian/* files?

[Niels Thykier]

Otto Kekäläinen:

Hi!

What editors and extensions are you using to augment your productivity
and minimize mistakes when editing debian/* files?

I am aware of dpkg-dev-el for Emacs mentioned in the DD reference[1].
I am a big fan of Pulsar[2] and recently found a 'language-debian'
plugin for Pulsar[3], but didn't get it to emit any errors/messages.

I would be interested to learn what editors and integrations others
use specifically for debian/* files. I've witnessed several old DDs
stop their Debian work, and many aspiring ones give up on becoming a
DD, because the Debian packaging work is so laboursome. One small
thing that could ease the burden could be better editor integrations
that help people write and maintain the debian/* files with less
effort.

- Otto

[...]


Hi Otto

Personally, I use PyCharm/IDEA with the IDEA-debpkg plugin (the latter I 
wrote because there was no existing plugin) or emacs with dpkg-dev-el 
depending on the context.


I think my use of PyCharm/IDEA started for similar reasons that you are 
praising Pulsar - if I need to work on another file, it would have an 
integration for that (like the preview pane with markdown, support for 
shellcheck, etc.).
  In most cases, PyCharm (and I presume Pulsar as well) has basic 
support out of the box or can hint you to a plugin based on the filename 
(extension based) - I do not have to hunt it down. Sadly, except for my 
own Debian plugin because d/control and d/changelog does not have 
extensions... oh well.


Thanks for the command list. I have added a few of them to my todo list 
for my plugin. Like `wrap-and-sort` is due now that it supports comments 
and has better defaults out of the box.


Btw, `debhelper` has a `dh_assistant` command that can do some very 
basic analysis as well. Not sure any of it is useful for editor 
integration (especially because some of the features requires that it 
receives the same arguments as `dh` or/and `dh_auto_configure`).
  Personally, I have used `dh_assistant detect-hook-targets` to detect 
which overrides that `dh` would pick up (relies heavily on 
"Build-Depends: dh-sequence-foo" style add ons though). Admittedly, not 
in an editor context but if you can combine it with something that reads 
known make file targets, you could get a "override_typo looks like an 
override target but `dh` does not recognize it"-style warning out of it.


Maybe I should just add that feature directly to `dh_assistant`. Then 
you can have one more command for your checklist! :D


Best regards,
Niels

Re: Running Lintian against a debian/ directory?

[Niels Thykier]

Otto Kekäläinen:

Hi!

Currently Lintian requires a (source or binary) package to check[1].
However, many of the Lintian source package checks (e.g. spelling of
debian/changelog entries) don't strictly depend on anything being built.

Is anyone aware of a way to run lintian directly on a debian/ directory
contents as-is without doing a source build first?

I am exploring this in order to get my text editor to nag about findings
immediately without separate source build steps.

Otto

[1] https://manpages.debian.org/bookworm/lintian/lintian.1.en.html



Paul already answered the lintian part, so I will skip that. But I also 
wanted to suggest looking into integrated spell-checking in your editor 
if possible. Having integrated spell-check will enable a much faster 
feedback loop.
  As an example, if you are using a Jetbrains IDE (such as CLion or 
PyCharm Community Edition), then I added a plugin (`Debian Packaging 
Support`), which among other has spell-checking of d/changelog + the 
description fields inside d/control.


Alternatively, for spell-checks, I think someone once wrote a 
"spellintian" that could use lintian's dataset for spell checking 
without running the full lintian program. Not sure what became of it.


Best regards,
Niels

Re: dropping Priority field from binary packages for most packages

[Niels Thykier]

Ansgar:

Hi,

could we drop the Priority field from most packages? Most packages use
"Priority: optional" and this is just noise in d/control (source
package). Tools should just assume "optional" when no other value is
set.

[...]

I would like to drop it pretty much everywhere, most importantly
debian/control in source packages (as often humans edit these).



I support this.

I am happy to look into having debhelper clear the `Priority` field in 
the deb if it is redundant early after the release.  Additionally, if 
the missing field breaks tools that cannot easily updated, I can have 
dehelper inject the field again (even if it is missing from d/control), 
so people can benefit in d/control already and we fix the .deb version 
when the infrastructure/tooling is ready.


The debhelper tooling already did something this for "Multi-Arch: no", 
which caused problems at some point. In that sense, there is already 
"prior art" for debhelper managing asymmetry between d/control and 
DEBIAN/control.



But it
could be dropped in other places (CONTROL in .deb and Packages indices)
as well.



Yes please!

Best regards,
Niels

Re: 32bit arch packages are built with wrong ownership due to fakeroot bug

[Niels Thykier]

Simon McVittie:

On Fri, 10 Feb 2023 at 03:18:16 +0100, Johannes Schauer Marin Rodrigues wrote:

Quoting Santiago Vila (2023-02-09 17:32:08)

- No intervention from individual maintainers is required for fixing this, as
we already have a binNMU mechanism which we already use for transitions.


Once fakeroot is fixed, binNMUs can be used to fix packages, yes. Without the
fakeroot fix in place, individual maintainers could do things to fix their
packages on the affected architectures but I do not think doing so is a good
idea.


There is one thing that maintainers can do to fix their packages on the
affected architectures that I think *might* be a good idea: if their
package builds correctly with Rules-Require-Root: no, they could add that
field, resulting in fakeroot not being used.

[...]

 smcv



Packages that need static non-root ownership cannot do that at the 
moment using debhelper / dpkg. These are in turn the most likely 
packages to exhibit this problem that triggered this discussion.


For everything else, you can pretty much always migrate to 
"Rules-Requires-Root: no". It is "just" a question of:


 1) Stop the accidental root usage in d/rules. E.g., remove -o root
-g root passed to install and left over chown calls.
 2) Convince the upstream build system to stop using root during
installation in the rare cases they do that.

Example from sudo: 
https://salsa.debian.org/sudo-team/sudo/-/merge_requests/13/diffs?commit_id=fa2a3a3ce37eb356b79ce31838e8b415a7dc31d2


It is not very difficult to do. However, it does take human time and 
effort, which is a scares resource.



But the moment you see a non "root/root" line in the data.tar listing, 
it is checkmate and game-over.  I think we may be able to provide better 
debian package tooling for the next release that can solve the static 
ownership problem, but not the human time/effort part.


Thanks,
~Niels

Bug#1029645: ITP: debputy -- Manifest style debian package builder

[Niels Thykier]

Package: wnpp
Severity: wishlist
Owner: Niels Thykier 
X-Debbugs-Cc: debian-devel@lists.debian.org, ni...@thykier.net

* Package name: debputy
  Version : 0.1.1
  Upstream Contact: Niels Thykier 
* URL : https://salsa.debian.org/debian/debputy/
* License : GPL-2+
  Programming Lang: Python
  Description : Manifest style debian package builder


Binary package being dh-debputy:
  Package builder that provides a declarative manifest for building
  debian packages.

  This version integrates with the debhelper sequencer dh and will
  replace several of debhelper's tools that are covered by debputy.

  The debputy package builder aims to reduce cognitive load for the
  packager and provide better introspection to better support to
  packagers, linters and the Debian janitor.


The early versions will integrate into the debhelper sequencer dh and 
will replace several of debhelper's tools that are covered by debputy. 
However, the goal is that debputy will be a standalone tool capable of 
packaging work from start to end.


In the early phase, I plan to keep debputy in experimental to allow for 
more aggressive prototyping.


Rationale:
==
My work on debputy is aimed at exploring an alternative packaging format 
that focuses on a single manifest (think Kubernetes helm charts or 
docker compose files).  A key goal is introspection and, for errors, a 
clear link to the part of the configuration that was involved or 
triggered the error.



Maintenance:

I am looking for people, who are interested in exploring this area with 
me and are:


  1) Interested in trying the prototype, or/and
  2) Interested in helping me design the manifest format, or/and
  3) Interested in helping me develop the tool, or/and
  4) Interested in integrating with the tool.
 - Whether third-party plug-in (a la dh add-ons) or linters/fixers

As some concrete suggestions for what a contributor might be helping me 
with. The list is not exhaustive and you are welcome to help regardless 
of whether your interest is mentioned above. :)


Trying out debputy:
===

There is a getting started guide at 
https://salsa.debian.org/debian/debputy/-/blob/main/GETTING-STARTED-WITH-dh-debputy.md.


If you do not use any overrides/hook targets, it is question of running:

 # (Remove --no-act to actually perform the change)
 $ debputy migrate-from-dh --no-act

And then add `dh-sequence-zz-debputy` to Build-Depends (the `zz-` is a 
hack for ordering debputy after other addons).


Key features:
-

Some high lighted features in debputy that are currently not available 
in other Debian packaging tools that might be interesting for you :)


 1) debputy supports setting static ownerships inside the debs without
relying on fakeroot.  This means that packages never need fakeroot
for the Debian packaging side (i.e., you should always be able to
use `Rules-Requires-Root: no` as long as the upstream build system
behaves).

This feature is mentioned in the GETTING-STARTED-WITH-dh-debputy.md
document, so you can see how to use it / try it out.

 2) If a binary package does not have a Multi-Arch field, debputy will
automatically deduce if it is safe to set "Multi-Arch" to "same".
The mechanics are based on rules by Helmut Grohne, who proposed this
feature on IRC.  In the rare cases, that debputy is wrong here,
you can explicitly set "Multi-Arch: no"

On the flip side, there are tons of features *not* supported by debputy 
at the moment.


Thanks,
~Niels

Re: dh_auto_test fails and I do not understand why

[Niels Thykier]

Andrius Merkys:

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:
I have uploaded a package yesterday. That package does not have any 
dh_auto_test

target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?


I have just stumbled on the same while building a new package with 
javahelper:


install: cannot change owner and permissions of 
‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d 
debian/_jh_build.lucene9-9.4.2 returned exit code 1


However, I have no idea why '-o 0 -g 0' options are used. They do not 
seem to be used before.


Andrius



Long story short:

 * Bug in fakeroot (#1023286 + #1024544)
 * Me thinking it was a bug in debhelper so I tried to fix it
   (which did not work and broke on the way in)
 * Me realizing it was a bug in fakeroot and my change did not
   even function as a work around, so I undid it (it broke on
   the way out as well).

And the winners are: All the people that have (and are) able to use 
"Rules-Requires-Root: no" as packages with that flag would have been

completely unaffected by this entire ordeal!

Your options include:

 * Migrate to "Rules-Requires-Root: no" if you can
 * Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
   debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even more 
packages buildable with "Rules-Requires-Root: no".


Thanks,
~Niels

Re: Automated backports based on Janitor work?

[Niels Thykier]

Jelmer Vernooij:

Hi Lucas,

On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:

[...]
Jelmer, did you already think about that? Is there a way one could help
you?


Reviving this thread that's more than a year old...

[...]

Known issues that still need to be addressed:

  * backport from testing rather than unstable
  * rename the suite from bullseye-backports to something that does't
clash with the official backports (version strings are already different)
  * finish processing the rest of the archive
  * better sanity checking to prevent too many dependencies from being
pulled in

I haven't decided on a name yet. "auto-bullseye-backports", perhaps?

Cheers,

Jelmer




To save the janitor some compute power, would make sense to skip 
packages that have already been backported?  E.g., I noted there is an 
auto-backport for debhelper even though debhelper is "in sync" between 
stable-backports and testing (or even sid at the moment).


Other than that, I think this looks great and I hope this will help make 
backporting more smooth.


Thanks,
~Niels

Re: Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Niels Thykier]

Simon McVittie:

On Sat, 08 Oct 2022 at 11:00:30 +0200, Niels Thykier wrote:

On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
 wrote:

I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
packages should have explicit parent package arch dependency
Depend: foo:${Arch} (=${binary:Version})
instead of
Depend: foo (=${binary:Version})


So as a concrete example, for sed:amd64 (which is Multi-Arch: foreign),
sed-dbgsym:amd64 currently depends on sed (= 4.8-1) which can be satisfied
by sed:i386, and the request is for it to explicitly depend on
sed:amd64 (= 4.8-1) instead?



In essence, yes.

Though, I think it is better to read OP's email as a "functional 
requirement" rather than the exact way to implement it.



I was under the impression that the Debian archive does not allow
dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any). Am I basing this
on outdated information?

Policy §7 doesn't currently document multiarch qualifiers at all.
deb-control(5) documents foo:any and foo:amd64.

 smcv



It is not clear to me that the archive supports it (or that apt, dak and 
dpkg are all aligned on what "foo:amd64" means).  However, as noted in 
my debian-devel mail, I am not willing to spend time figuring out 
whether "foo:amd64" works and much less provide patches if it does not.


Accordingly, I am not planning to do any research in that area.

Thanks,
~Niels

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Niels Thykier]

Hi,

I have BCC'ed debian-devel on this email to ask for input on this bug 
(#903158) and ask parties that are interested to follow up there.  I am 
considering to remove the dependencies for -dbgsym packages on the 
grounds that:


 1) They are too weak when M-A: foreign is involved and they are not
always help (see the partial email quote from the bug below)
 2) We now have a debuginfod service, so you do not even have to install
dbgsym packages anymore (if you configure gdb to use it).  For the
cases where you do install the dbgsym, you still have to manage
inter-source dbgsym dependencies manually.

As a debhelper maintainer, I willing to either keep the status quo and 
close the bug as wontfix or close the bug by removing the dependencies. 
If you hoping for another outcome, I expect you to be ready to put the 
effort and patches required to reach the outcome.


Thanks,
~Niels

On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne  wrote:

Hi Niels,

On Sat, Aug 04, 2018 at 08:38:00AM +, Niels Thykier wrote:
> On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy"
>  wrote:
> > I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
> > packages should have explicit parent package arch dependency
> >Depend: foo:${Arch} (=${binary:Version})
> > instead of
> >Depend: foo (=${binary:Version})
> > Untested patch against debhelper 11.3.5 attached (please review 
> > carefully, I'm neither M-A nor debhelper expert).


Yes, this makes somewhat sense.

Personally, I disagree with the Depends though. I've often been in the
situation of wanting to debug a foreign core file or remotely attaching
to a process on a different system. These dependencies were not helpful
at all in these situations. Personally, I'm in favour of making -dbgsym
packages dependency-less. I acknowledge that others see things
different.

In any case, we agree that if we want the dependency, then it is
presently too weak.

[...]

Re: Automatic trimming of changelogs in binary packages

[Niels Thykier]

Paul Wise:

On Tue, 2022-09-06 at 07:13 +0200, Gioele Barabucci wrote:


* Packages not meant to be included in Debian (and without access to a
changelog server): Creators that want to preserve the full history can
use the `--no-trim` option to disable the trimming.


Most derivatives aren't going to have a changelog server so I don't
think it makes sense to enable it by default on all derivatives.

Perhaps the dpkg vendor could be used as guidance for when the trimming
should occur by default? Unless Debian/Ubuntu, disable by default.

Then have a way for vendors to enable it by default if they want.


* Third-party repositories: Their administrators can provide access to
the full changelogs by setting `Changelogs:` in the `Release` file, or
can use `--no-trim` in the packages that they distribute.


Modifying every single package to add --no-trim would be tedious for
some repositories, perhaps allow a config option to disable it?



Sounds like a job for (not yet implemented) DEB_BUILD_OPTIONS=notrimdch 
(or some other name).


Thanks,
~Niels

Re: releasing major library change to unstable without coordination

[Niels Thykier]

Sandro Tosi:
> and lets use once again numpy: 2 days ago i've uploaded 1.21.5 to
> replace 1.21.4 in unstable. [...]
> 
> Regards,

Hi,

If you feel discussing patch releases is worth a topic of its own, I
think we should start a separate thread for that because the process is
likely to be considerably different compared to a *major library change*
(which is what Jonas asked for).

Thanks,
~Niels

Re: dh_clean fails with diagnostics involving cp, checksums, and a "bucket"

[Niels Thykier]

G. Branden Robinson:
> Hi folks,
> 
> It's been a while since I've done any packaging.  I was baffled when
> presented with the following.
> 
>dh_clean
> cp: cannot stat 
> 'debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c':
>  No such file or directory
> dh_clean: error: cp -an --reflink=auto 
> debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c
>  
> debian/.debhelper/bucket/files/19c12bb2ca19e68724c2854ed0512469518df19b0710cc2011a5ca540810979c.tmp
>  returned exit code 1
> make: *** [debian/rules:3: clean] Error 25
> 
> 1.  What is the debhelper "bucket"?  A web search turns up no
> documentation of this architectural feature, one evidently important
> enough that its identification is permitted to leak into diagnostic
> messages.

The "bucket" is an implementation detail of debhelper used by the
feature explained below.

> 2.  Why is dh_clean trying to copy files around at all?  Nothing about
> this is disclosed in dh_clean(1).

1-2 debhelper tools mark certain files as "restore on clean" and then
replace them (such files are saved in the "bucket").  The most notorious
example is dh_update_autotools_config which does this for config.sub and
config.guess files.

What you are seeing here is dh_clean failing to restore those files on
clean.  This case looks like something improperly messed around in
debhelper's implementation details and left it in an invalid state.
When dh_clean handles this removal, it does so in a way that ensures
that error cannot occur even if dh_clean is interrupted half-way through.

You can remove debian/.debhelper/bucket (and everything inside it) and
that will reset debhelper's own state to avoid that error.  It will not
restore the affected files - but then, they can be restored from git or
the orig source as needed. You can see the list of files in
debian/.debhelper/bucket/index (mind the order of operations here).  The
index file also contains a SHA256 checksum of the file, so you can
ensure you have found the original.

> 3.  Why is dh_clean's own diagnostic message pretty much a
> recapitulation of the one before?  [...]

That is standard for debhelper error messages that involves external
programs. Except for a few places inside dh_auto_*, which have been
enriched to dump related log files from upstream build systems), then
this is what you get from debhelper.

> 4.  The exit status "25" is fairly unusual, suggesting that it has
> significant semantics.  Yet I find no documentation of such
> significance in dh_clean's own man page nor in debhelper(7).  Why?
> "Exit status" is a common and well-known section heading.
> 

That is probably caused by the very "fun" feature in perl .  The exit
code from perl will be set to errno if there is a non-zero errno value
and the program did not explicit set an exit value due to an uncaught
exception.  That errno can be completely unrelated to the actual problem
(perl does not know when errno was set when perl pulls this stunt).

> Can someone shed some light on these matters?
> 
> Please CC me on replies--many years ago I kept up obsessively with
> debian-devel traffic, but not any more, I'm sorry to say.
> 
> Thank you in advance.
> 
> Regards,
> Branden
> 
> [...]
> 

Done and done.

In summary:

  * Ensure you do not have anything messing around with debhelper's
internals inside debian/.debhelper.  You can break plenty of
features by deleting or changing random files inside that
directory.

  * Restore affected fines manually
(read debian/.debhelper/bucket/index for a list of files)

  * Run 'rm -fr debian/.debhelper/bucket' to get dh_clean "unstuck".

  * Complete a clean of the package.

  * Continue what you were doing.

Thanks,
~Niels

Re: How to use remove-on-upgrade to remove a configuration file?

[Niels Thykier]

Niels Thykier:
> Ludovic Rousseau:
>> Hello Niels,
>>
>> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>>> Ludovic Rousseau:
>>>> [...]
>>>
>>> Hi Ludovic,
>>>
>>> You cannot use that feature yet as it would break during upgrade. The
>>> dpkg version in stable does not support the feature.  Which is also why
>>> there is no debhelper feature to support it yet.
>>
>> OK. I was searching for something that does not (yet) exist :-)
>>
>> My plan was to upload the package in Bullseye +1 so after the (soon)
>> release of Bullseye.
>> Bullseye will then be the new stable and will have dpkg 1.20.9. So that
>> should work. No?
>>
>> Thanks
>>
> 
>>From an upgrade/low-level tech perspective, yes, it would work.
> 
>>From an "how do I use this feature" perspective, I would recommend that
> you/people wait until relevant wiring has been added to debhelper.
> 
> ~Niels
> 

Hi,

I just uploaded debhelper/13.5 that adds support for the new feature via
the following methods:

 * Use of "rm_conffile" in debian/.maintscript will now be
   optimized into the "remove-on-upgrade" feature in cases where I
   believe I could do it safely and reliably.
   - This is easiest to use for most people; you can just keep doing
 what you have been doing and it will "just work(tm)".
   - This method also have the advantage that we can "roll it back"
 centrally if it turns out that some critical piece of
 infrastructure does not support the new vales in DEBIAN/conffiles.

 * debian/.conffiles is now installed again in all compat levels
   for the case you want to use the feature directly.
   - This method provides the highest degree of freedom/control but you
 will in general want ensure you are using debhelper (>= 13.5~) and
 that is currently not available in -backports.

For bullseye, my recommendation would be to stick with "rm_conffile" in
debian/.maintscripts.

Also note that DEBIAN/conffiles has been a list of files since
"forever".  Most likely some bits of code assumed this would never
change and we will probably see the effects of that soon.

Thanks,
~Niels

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Sam Hartman:
>>>>>> "Niels" == Niels Thykier  writes:
> 
> Niels> If the project consensus of this discussion is aligned with
> Niels> the belief that we should block decentralized volunteer work
> Niels> on the transition, I will respect the decision.
> 
> I was really frustrated reading that, and I hope that my reading is more
> loaded than you meant.

Hi Sam,

I am sorry that my email caused you frustration.  That part was loaded
with my own frustration over the situation and how we - as a project -
are handling the transition, which I failed to weed out in my
self-review of my outgoing email.

Since I do not know to what extend you took it personally, I want you
know that none of that frustration was aimed at you as an individual.
Once again, if you in any way felt that, then I apologies for that part.


> If what you're saying is that you'll respect it if the project consensus
> is that  individual package maintainers should not move paths around at
> this time, then I think that's the key question.
> 

That is what I wanted to say.

> I'll point out that we get a lot of value even if we don't move paths
> around in packages.
> In particular, we get a uniform environment where we can  depend on a
> single directory layout.
> That removes classes of bugs even if we don't get to update canonical
> paths.
> 

I believe we both agree on those statements being true (like many of the
previous ones).  Where we seem to disagree is what should have priority
over other things.  I sense that the timeliness of completion is of less
importance to you compared to other values and I respect that.


However, I will be considerably more demotivated by what I feel is a
never-ending transition than I am motivated by all of the points you
listed above.  Which makes it a net-loss for me in years to come even if
it is a net-win for many others if the transition is not resolved in a
timely fashion.

> 
> 
> What I originally heard in your statement was  a consensus that volunteers 
> are not needed,
> and I don't think anyone support that.
> 

My frustration had a different direction than the one what you seemed to
have understood it as, which is why I will not answer your extended
follow up to that part in detail - nor do I intend to expand on my
original words because I doubt it will make any of us happy.  Once
again, my sincerest apologies for frustration.



Finally, I will retract myself from this debate for the time being. I do
not feel I have anything additional of constructive value to add to it
nor have enough spoons to invest to become a constructive participant.
  I will await the evaluation of the consensus. I kindly ask that you CC
that to debhel...@packges.debian.org (or, at your choosing, report it as
a bug if it involves reverting the change) as I am not sure I will keep
track of this thread any more.

~Niels

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Simon Richter:
> Hi,
> 
> On 25.08.21 21:45, Sam Hartman wrote:
> 
>> The dpkg maintainer hasn't been happy with the discussions here, and
>> I think facilitating to a level where Guillem is part of the
>> consensus is beyond my skill.
> 
> The discussion so far has been around the question whether there is
> actually a problem and whether it is actually required for the dpkg
> database to be consistent with the file system. It is unsurprising that
> the dpkg maintainer has an opinion about that.
> 
>> So I don't actually know how to get to something actionable.  I do
>> believe the chance of breakage if we move around paths inside
>> packages is high enough that we should block path canonicalization on
>> a dpkg that can handle that, even if that takes a long time.
> 
> We have a few half-baked solution proposals.
> 
> Combining the parts from Ted Ts'o (for usrmerged systems) and mine (for
> not-yet usrmerged systems) would be the complex and generic approach.
> 
> I think I've also seen some ideas along the lines of "have the usrmerge
> package patch the dpkg database", which would be simpler.
> 
> Would it make sense to start a wiki page?
> 
>    Simon
> 

As I understand it, the "have usrmerge package patch the dpkg database"
approach will only work if we ensure that each and every package stop
using / in bookworm+1.  Else we are back to the same problem that Sam
listed with package splits (just with the paths inverted).

That is, a solution based on that plan should also involve a plan for
getting each and every package affected by the usrmerge updated in
bookworm+1.

Thanks,
~Niels

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Sam Hartman:
>>>>>> "Niels" == Niels Thykier  writes:
> 
> Niels> As I understand it, the issue does not depend on whether
> Niels> "usrmerge" is run before or after installing the "/lib"
> Niels> version of "foo".  On that assumption, running "usrmerge" as
> Niels> a part of the upgrade and "cleaning up" in bookworm+1 is
> Niels> liable to exactly the same risk as before.
> 
> I don't think so.
> My assumption is that we will eventually  produce a dpkg that handles
> this situation better.

I can appreciate the allure of assuming that "a fixed dpkg" appears and
solves the entire problem.  It would certainly make all the problem go
away *if* it appears.

I am not ready to believe in that dpkg as a solution to the bookworm
release because the dpkg development flow has never been "fast" due to a
strong focus on "a generic solution that gets it right in every case" -
and I expect it to be even slower than usually given how demotivated
Guillem feels and the complexity involved in such a change to dpkg.

And until the "fixed" dpkg materializes, every package shipping
something has to keep files in /lib - even if that is a decade after the
bookworm release - or risk breaking if they later need to split the
package in the same release cycle.
  To me, that sounds like we will drag the transition on "until the
fixed dpkg comes along" no matter how long it takes.  Finishing the
transition is a key element for me in the transition.

> [...]
> So my hope is that debhelper and maintainers refrain from moving files
> from / to /usr prior to  being able to depend on an as yet unwritten
>  dpkg.
> 

For me, this reads as "until = eventually", which I stated I would find
unconvincing.

For the record, I did not immediately expect a better answer which is
also why I am waiting with moving forward in case a better answer
materializes "soon".

> I think that if debhelper moves systemd units and later a maintainer
> moves units between packages, we can run into trouble with today's
> dpkg.  So we could potentially run into trouble as soon as someone
> installs such a package from testing onto a bullseye system.
> 
> If debhelper were to hold off until after a fixed dpkg exists and we can
> guarantee it is available,
> I think that we avoid the risk of files disappearing.
> So, based on my understanding, I think the risk is worse today than it
> would be if we rolled back the debhelper change.
> 
> 
> [...]
> 
> 
> It's possible I'm missing something .
> If so, I'd appreciate help understanding what it is.
> 

On the assumption that a "fixed" dpkg will appear in bookworm, I would
agree with you.  However, I do not believe in that assumption/timeline -
to explain why I believe we fundamentally disagree on the priority/solution.


>  This strongly depends on:
> 
>>  * Who volunteered to be the
>> "we" that provide this plan?
>>  * When is "until" we have a
>> defined plan?
> 
> So, I think that the discussions here have been converging on things
> that  would work.
> I'm happy to volunteer to assist in trying to find what consensus there
> is if that helps.
> 

I appreciate you volunteering to a part of it.  My interest in a
detailed transition plan with a fixed end date where we are *done* with
the "clean up" no later than bookworm+1.  I do not see that directly in
these discussions - but certainly, a consensus is probably the first
step there.  Maybe the consensus will motivate someone to volunteer to
create the plan.

(Side-note my desired timeline implies that a "fixed" dpkg lands in
bookworm.)

> [...]
> 
> So I don't actually know how to get to something actionable.  I do
> believe the chance of breakage if we move around paths inside packages
> is high enough that we should block path canonicalization on a dpkg that
> can handle that, even if that takes a long time.
> 

I would strongly prefer a timely actionable transition plan that does
not involve assuming a "fixed" dpkg will show up and magically fix
everything when the volunteer working dpkg is strongly demotivated by
this transition.  In the absence of such a transition plan ...

If the project consensus of this discussion is aligned with the belief
that we should block decentralized volunteer work on the transition, I
will respect the decision.

~Niels

Re: Debhelper and /lib/systemd vs /usr/lib/systemd

[Niels Thykier]

Sam Hartman:
> 
> TL;DR: Should we hold off on moving stuff from / to /usr in packages
> until we develop our plan?
> If so, how do we communicate that to people?
> 
>> "Russ" == Russ Allbery  writes:
> 
> Russ> Simon Richter  writes:
> >> It is less nonsensical because usrmerge exists, since we
> >> presumably don't want to keep the /bin paths in the packages, so
> >> at some point we need to move /bin/foo to /usr/bin/foo inside a
> >> package.  That is safe with current dpkg, as dpkg will not delete
> >> /bin/foo if it has the same inode as a just-unpacked file.
> 
> Russ> [...]
> 
> Russ> I think this implies that writing something in Policy about
> Russ> this would be premature.  The issues you raise are related to
> Russ> something new that is being discussed and would be part of a
> Russ> migration plan to a merged /usr world.
> 
> Russ, I agree with you that it's premature to document this in policy.
> 
> However, Simon has raised what I think is a credible argument that it
> is harmful to perform both / -> /usr transitions and to move files
> between packages in the same release.
> My take away from that is that it may be harmful to move a bunch of
> stuff from / -> /usr until we have a plan, and that maintainers should
> actively be discouraged from doing so.
> 
> I think we should get people to hold off at least until we have a
> consensus on that point.
> 
> And this is by no means theoretical.
> 
> As was discussed here, recent debhelper (has or at least had) changed
> from installing systemd units in /lib/systemd/system to
> /usr/lib/systemd/system.
> 
> That is totally fine interms of  usermerged stuff, but sets up a
> potential problem .
> 
> Suppose we have a program foo that ships a daemon and also a systemd
> unit to run it.
> 
> Later we discover that foo is kind of useful in desktop situations and
> other situations where it wants to be started as needed  and possibly
> not even by systemd.
> So, we want to split out the foo package into foo containing the daemon
> binary and foo-system (recommended by foo) containing the systemd unit.
> 
> The maintainer may not even be thinking about how debhelper moved around
> the unit file.
> 
> foo-system  replaces/breaks the old version of foo.
> 
> I think the following series of operations would result in the unit file
> disappearing on a usermerged system:
> 
> * user has  old foo with /lib/systemd/system/foo.service
> 

As I understand it, the issue does not depend on whether "usrmerge" is
run before or after installing the "/lib" version of "foo".  On that
assumption, running "usrmerge" as a part of the upgrade and "cleaning
up" in bookworm+1 is liable to exactly the same risk as before.

Which means that we are likely "just" debating on when we want to risk
to occur. The difference for me being that people would forgot about
this issue in bookworm+1 and assume that migration is over with no risk
left.

On that front, I prefer to take my chances with breaking bookworm while
it is fresh in our minds rather than breaking bookworm+1 when every body
forgot about it.

That said ...

> * user attempts to upgrade and installs foo-system as part of upgrade
> 
> * foo is deconfigured because of the breaks on foo-system
> 
> * foo-system is unpacked, including
>   /usr/lib/systemd/system/foo.service.  On the usrmerged system, that
>   overwrites the existing foo.service since dpkg doesn't know about the
>   aliasing
> 
> * foo is upgraded.  From dpkg's standpoint it looks like
>   /lib/systemd/system/foo.service disappeared, but since the file still
>   exists it is removed.
> 
> So the user ends up with no unit.
> 
> I think this is particular insidious because the maintainer might not
> even know that they had moved files from / to /usr, or if they knew they
> might have not been paying enough attention to provide special care.
> 
> Do people agree that we want to hold off on this sort of thing until we
> get a plan?
> 

This strongly depends on:

 * Who volunteered to be the "we" that provide this plan?
 * When is "until" we have a defined plan?

For concrete values of those definitions, I can be convinced to stop
further changes and rollback the systemd / -> /usr change.  However, as
long as these definitions are variations of "somebody" or "everyone" or
"the project" and "eventually" or "when it is ready", then I am not
convinced that waiting is the right option.

For now, I will hold on further "/ -> /usr" changes in debhelper, but I
am not convinced that I should actively rollback the changes already made.

Thanks,
~Niels

PS: Guesstimates suggests that there 16.5 months until the transition
freeze assuming the release team keeps the current cadence.

Re: Debian package manager privilege escalation attack

[Niels Thykier]

Timothy M Butterworth:
> All,
> 
> I just ran across this article
> https://blog.ikuamike.io/posts/2021/package_managers_privesc/ I tested
> the attacks on Debian 11 and they work successfully giving me a root
> shell prompt.
> 
> Tim
> 

Hi Tim,

All of the attacks presented assumes that the local user has "sudo"
permissions to run apt and use that as the basis for escalating
privileges (not commenting on yum or snap).

I think it is a good demonstration of how some sudo policies are too
lenient and can be exploited.  Though I am not sure this is a bug in
apt, as I do not think apt ever promised to be "safe" to use from a
constrained sudo policy.

Note that the blog post itself also mentions this:

"""
[...] In certain cases the user should not be a root/admin user but has
been assigned sudo permissions to run the package manager only for
package management purposes.

We’ll look at how this permission can be abused to gain root access to
the machine via a root shell.
"""
(from the "Introduction")

My reading is that "this permission" refers to the "assigned sudo
permissions".

Thanks,
~Niels

Re: How to use remove-on-upgrade to remove a configuration file?

[Niels Thykier]

Ludovic Rousseau:
> Hello Niels,
> 
> Le 08/08/2021 à 09:09, Niels Thykier a écrit :
>> Ludovic Rousseau:
>>> [...]
>>
>> Hi Ludovic,
>>
>> You cannot use that feature yet as it would break during upgrade. The
>> dpkg version in stable does not support the feature.  Which is also why
>> there is no debhelper feature to support it yet.
> 
> OK. I was searching for something that does not (yet) exist :-)
> 
> My plan was to upload the package in Bullseye +1 so after the (soon)
> release of Bullseye.
> Bullseye will then be the new stable and will have dpkg 1.20.9. So that
> should work. No?
> 
> Thanks
> 

>From an upgrade/low-level tech perspective, yes, it would work.

>From an "how do I use this feature" perspective, I would recommend that
you/people wait until relevant wiring has been added to debhelper.

~Niels

Re: How to use remove-on-upgrade to remove a configuration file?

[Niels Thykier]

Ludovic Rousseau:
> Hello,
> 
> I am fixing Debian bug #990154.
> 
> After some work I am able to remove the obsolete conf file using:
> rm_conffile /etc/reader.conf.d/0comments 1.9.3-2~ pcscd
> in debian/pcscd.maintscript
> 
> Nice.
> Now I would like to use the method documented in deb-conffiles
> https://manpages.debian.org/unstable/dpkg-dev/deb-conffiles.5.en.html
> 
> I would need to add in the DEBIAN/conffiles of the pcscd package the line:
> remove-on-upgrade /etc/reader.conf.d/0comments
> 
> But how do I generate a .deb package with this extra line?
> What is the magic dh command or file to do that?
> Where is it documented?
> 
> I tried to use a file debian/pcscd.conffiles but this file is no more
> used with debhelper version 12
> https://manpages.debian.org/buster/debhelper/dh_installdeb.1.en.html
> 
> I searched for occurrences of "remove-on-upgrade" in
> https://codesearch.debian.net/ but I only find references to dpkg source
> code.
> No Debian package is using or has used "remove-on-upgrade"?
> 
> Thanks
> 

Hi Ludovic,

You cannot use that feature yet as it would break during upgrade. The
dpkg version in stable does not support the feature.  Which is also why
there is no debhelper feature to support it yet.

Thanks,
~Niels

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Niels Thykier]

Johannes Schauer Marin Rodrigues:
> Quoting Michael Biebl (2021-07-19 15:10:42)
>> [...]
>>
>> According to
>> apt-file search -x '^/(lib|bin|sbin)'
>> on my Debian sid/amd64 system, we have 1747 packages shipping 24583 
>> files in those directories.
> 
> more precisely, on amd64 unstable:
> 
> /bin 247 files
> /lib{32,64,x32} 83 files
> /lib/firmware 2379 files
> /lib/live 115 files
> /lib/modules 17500 files
> /lib/systemd 2221 files
> /lib/udev 614 files
> /lib/x86_64-linux-gnu 343 files
> /lib/* 441 files
> /sbin 547 files
> 
> So most files come from /lib/modules, where only 14 packages are involved,

and debhelper's dh_installmodules that will need to be tweaked to look
into /usr/lib/modules as well.
  But I have no idea if/when we would be ready for that and I will not
be changing debhelper until we are ready to move these bits to /usr.

Likewise for udev, here dh_installudev still uses /lib/udev and will
continue to do so until I know that udev also checks /usr/lib/udev.


If you are involved in udev or/and /lib/modules and know that they are
ready to move to the relevant directory under /usr, then please feel
free to file a bug against debhelper requesting that the /usr directory
will be used in the future.
  Please do also note in that bug report whether you also want debhelper
to automatically migrate existing files from /lib to /usr/lib.  This
should only be the case where we expect (almost) zero breakage from an
automatic "unordered" transition.

(NB: Please use a bug report as I will first be implementing this after
the bullseye release and rely to this thread is likely to be lost in my
inbox)

> /lib/systemd which will be fixed by an update to dh_installsystemd, and

Indeed, I have heard this request and the systemd maintainers confirmed
to me that systemd in bullseye checks both /lib/systemd and
/usr/lib/systemd.

I have a branch lying around trying to support this.  The main key
feature missing is the migration of /lib/systemd -> /usr/lib/systemd
(which needs to handle that both exist and merge them into one somehow).

> /lib/firmware where only 36 packages are involved. The remainder then doesn't
> sound so scary anymore as it only involves 656 unique packages and not 1747.
> And again many of those remaining packages will be fixed by an update to
> debhelper, correct? Given that 90% of source packages use dh, that would 
> reduce
> the number to a very manageable size.
> 

Indeed, about 90% of all packages uses dh according to trends.

Though for good measure I thought I would explicitly answer the proposal
(from another mail in this thread) that debhelper could move everything
from /lib to /usr/lib:

  No, I will not support an unconditional move from /lib to /usr/lib
  via debhelper during bookworm.

There are already two distinct examples in this thread for how this
could break things. I will be sticking to "targeted" migrations where
the major consumers have informed me that they are ready to support the
migration.


>> [...]
>>
>> Once we have this global switch to merged-usr, packages can bit by bit, 
>> completely independent, update their debian/rules to use --prefix=/usr 
>> and after a few years, we don't have any packages anymore installing any 
>> files in /. We could aid this process with a lintian check that flags
>> packages that install files in /(sbin|bin|lib)/.
> 
> So what what is actually the roadmap after the bullseye release? What is the
> way forward? Should I rather file bugs with patches against individual 
> packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/ or do we
> already have a debhelper patch to do that move for us?
> 

For some, debhelper will your problem but there will packages that will
need manual migration. As I see it, there will *not* be "the debhelper
patch to fix them all" - even if there will /some/ debhelper patchers
that will fix "most of them".

Related, I have no intention of supporting / maintaining a rewrite of
"--prefix/PREFIX" parameters to configure/make/cmake or whatever.  (Not
saying anyone proposed it - but mentioning it as another "there will
definitely be manual clean up" data point).

~Niels

Re: Cancel "culture" is a threat to Debian

[Niels Thykier]

Hi participants,

If you follow up on this thread, then please move it to mailing lists
that are more politically focused such as -vote (given it is a response
to vote).

The topic certainly off-topic for debian-devel, which has the following
tag line for content:

   Discussion about *technical development* topics.

(emphasis mine).

Best regards,
~Niels

Re: Possible DEP proposal - contribution preferences

[Niels Thykier]

Russ Allbery:
> Jonas Smedegaard  writes:
> 
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting point:
> 
>>   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.
> 
> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).
> 

Personally, I would be fine with a variant of wrap-and-sort (-bastk or
there abouts) being a Debian-wide recommendation/default *if*
wrap-and-sort would preserve comments.

A case where comments are important to me is the d/control of debhelper,
where I document the rationale for many of the versioned
(build-)dependencies.  It would be a non-starter for me to maintain
those comments elsewhere simply because wrap-and-sort keeps steam
rolling them into oblivion.

~Niels

Re: deduplicating jquery/

[Niels Thykier]

Russ Allbery:
> The root problem, at least as I understand it, is that the two relevant
> upstreams (and probably lots more) have followed those practices to vendor
> and pin versions of jQuery, and are not regularly updating those pins, so
> the current version in Debian may or may not work.

As I recall, in the doxygen case the "jQuery" is in fact jQuery +
modifications.  So it is not even trivial to fix this with symlinking
even if the version "match".

~Niels

Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS

[Niels Thykier]

Christian Kastner:
> On 2020-09-06 23:27, Mattia Rizzolo wrote:
>> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
>> The thing is, according to the build profile spec, if you specify nodoc
>> or nocheck in _PROFILES you *MUST* also specify it on _OPTIONS (talking
>> about when you do the build), so…
> 
> That's why I find this part odd:
> 
>>> Looking at random packages, newer packages seem to favor just checking
>>> DEB_BUILD_PROFILES
> 
> Given what was said above for the major use cases nodoc and nocheck,
> _OPTIONS > _PROFILES, so I wonder why _PROFILES is favored.
> 
>>From Niels' response, I guess one can conclude why this isn't an issue
> for the nodoc case.
> 
>> You should read the manpages for more details.
> 
> I did, and while _OPTIONS and_PROFILES are both explained, the
> relationship between them (if any) is not.
> 

Fundamentally, the difference between the two are:

 * _PROFILES is a "new"[0] thing with a specific purpose to reduce
   build-dependencies (at least in this case).  It ends up in d/rules
   for skipping builds of specific packages (e.g. "nopython")

 * _OPTIONS is the thing that has been here since the "dawn of time" to
   enable the builder to tweak the build in a standardized way.

(Note that their definitions do not overlap)

Basically, we ended up in the situation like this with nocheck[1]:

 * We had _OPTIONS with nocheck for at least a decade and probably more.
   - I.e. _OPTIONS is what everyone wrote in their d/rules file to
 implement policy.

 * We invented _PROFILES and supported nocheck to assist cross-builders
   and bootstrappers, who generally want as few build-depends as
   possible even at the expense of running tests (cross-builders often
   cannot run them anyway).
   - I.e. _PROFILES is what the dependency resolvers look for when
 deciding which build-depends to install.

And that is how you end up with WET Debian packaging.

I hope that cleared the relationship between _OPTIONS and _PROFILES and
how we got here.


At this level, it might look deceptively easy to "fix" this problem
("Couldn't we just do X and then it will solve everything?").  However,
I have deliberately avoided to dive into "X" - among other because I am
not sure I can accurately represent the /current/ views of everyone.  If
you are interested in that, I would recommend some off-list research first.

~Niels

Re: debian/rules and DEB_BUILD_PROFILES vs _OPTIONS

[Niels Thykier]

Mattia Rizzolo:
> On Sun, Sep 06, 2020 at 10:53:05PM +0200, Christian Kastner wrote:
> [...]
>> Or do dpkg or debhelper apply some kind of mapping logic from _OPTIONS
>> to _PROFILES for the popular options nocheck, nodoc, noopt?
> 
> debhelper does.  various helpers do things differently with such
> options.  You should read the manpages for more details.
> 

It does not in the general case.  It does for nodoc because
$HISTORICAL_REASONS.

>> Or are we supposed to transition to just _PROFILES in the long term?
> 
> There were talks around that with the people involved in writing up the
> _PROFILES spec, not sure where that go (nowhere I think).
> 

I think it would make sense for us (Debian) to look at migrating some of
these use cases to rely solely on _PROFILES.  I dislike us having to
stick with a permanent papercut because we invented _PROFILES after
_OPTIONS (as one of many "semi-permanent papercuts" in Debian packaging
that I would like to remove eventually).

~Niels

Intend to remove obsolete debhelper compat levels 5 and 6 before the release of bookworm (bullseye + 1)

[Niels Thykier]

Hi,

This is a heads up about my intention to remove debhelper compat levels
5 and 6.  This is also an intention to do a MFB for this removal now at
severity important, which will be bumped to RC later.

With the current rate of migration as well as the current number of RC
bugs in testing, I expect the removal will happen after the release of
bullseye but before the release of bookworm.

I have attached a package list and a dd-list of affected packages and
maintainers based on data from trends.d.n with a few additional packages
added manually based on a codesearch for DH_COMPAT.  Please have a look
at your packages and consider migrating them sooner rather than later.

With the release of debhelper/13.2, debhelper now supports a special
DEB_BUILD_OPTIONS variable to aid with detecting usage of soon to be
removed compat levels.  This can be useful for automated testing as well
as detecting "indirect" usage - either via the DH_COMPAT variable or in
test suites that rely on debhelper[1].

> $ DH_COMPAT=6 dh_clean
> dh_clean: warning: Compatibility levels before 10 are deprecated (level 6 in 
> use)
> $ DEB_BUILD_OPTIONS=dherroron=obsolete-compat-levels DH_COMPAT=6 dh_clean
> dh_clean: error: Compatibility levels before 7 are scheduled for removal and 
> DH_COMPAT_ERROR_ON_PENDING_REMOVAL was set (level 6 requested)
> $ DEB_BUILD_OPTIONS=dherroron=obsolete-compat-levels DH_COMPAT=7 dh_clean
> dh_clean: warning: Compatibility levels before 10 are deprecated (level 7 in 
> use)

The option is documented in "Supported flags in DEB_BUILD_OPTIONS" in
"man 7 debhelper"[2].

The option is intended as a debug aid to detect "soon to be" removed
compat levels in a simple automated fashion (manual review of
codesearch.d.o results has its limits).

~Niels

PS: The data is based on trends.d.n for testing as it is the most
reliable and up to date source that I have for this at the moment.  That
said, it is now about 10 days old and will incorrectly contain any
package that has been fixed within the last ~10 days.

[1] To those of you that rely on debhelper in test suites, please
remember to ensure the test suite runs with this set.  Some test suites
reset most of the environment to ensure the tests are deterministic.
Notably options like nostrip causes debhelper to skip dbgsym packages,
which can obviously affect the result of tests that expect dbgsym to be
present.

[2] Relevant typo in the released documentation that has been fixed in
git already:
 * "This environment variable" -> 833f59bbfa17c8561980e759c46

aa3d
abicheck
acfax
aconnectgui
afuse
aldo
alsamixergui
amideco
and
apsfilter
archmbox
as31
asmix
asmixer
aspell-am
aspell-hr
aspell-hy
aspell-ro
aspell-sv
asql
asterisk-prompt-de
asterisk-prompt-fr-armelle
asterisk-prompt-fr-proformatique
autodns-dhcp
automysqlbackup
aview
avr-evtd
avr-libc
awardeco
barada-pam
baycomusb
beancounter
bfbtester
bfm
biabam
bidiui
binutils-avr
binutils-msp430
blcr
boolector
bplay
brandy
byacc
byacc-j
cadaver
camlidl-doc
cappuccino
catdvi
cdrkit
cernlib
checksecurity
chiark-tcl
chiark-utils
chise-base
chntpw
choosewm
chrootuid
cksfv
cl-sql
clamassassin
cli-common
clif
cntlm
coinor-flopc++
coinor-ipopt
concalc
configure-debian
conspy
cowbell
crossfire-client-images
crossfire-maps
crossfire-maps-small
cryptcat
cue2toc
culmus
culmus-fancy
curlftpfs
cvsdelta
cvsutils
d52
dailystrips
datapacker
dbench
dbmix
ddclient
debian-builder
delimmatch
dia2code
dictconv
dictdlib
dis51
dlocate
dns-browse
dnshistory
docbook-utils
dpkg-cross
drac
drbdlinks
dsdp
dvbsnoop
dvbstreamer
dvhtool
dvi2ps
dvi2ps-fontdata
dvi2ps-fontdesc-morisawa5
edac-utils
editline
efax-gtk
epic4
epic5
etherpuppet
extra-xdg-menus
ez-ipupdate
falselogin
fapg
fastjar
fdflush
fig2sxd
filler
flamethrower
flexbackup
flobopuyo
fluid-soundfont
fortunes-bofh-excuses
freehdl
freepats
fstrcmp
ftjam
fuse-umfuse-ext2
fuse-umfuse-fat
fvwm1
fxload
g2p-sk
gaim-themes
gap-ctbllib
gatos
gav
gbase
gcc-3.3
gcc-avr
gcc-h8300-hms
gcc-m68hc1x
gcc-msp430
gcl
gdb-avr
gdb-msp430
geant321
gems
geronimo-ejb-3.0-spec
geronimo-j2ee-connector-1.5-spec
geronimo-jms-1.1-spec
gkrellm-reminder
gkrellm-thinkbat
gkrellm-xkb
gkrelltop
glbsp
glurp
gmp
gnome-audio
gnome-extra-icons
gnome-icon-theme-yasis
gnome-mime-data
gnome-nds-thumbnailer
gnome-phone-manager
gnu-standards
gnuit
gplcver
gramophone2
graphmonkey
grub-splashimages
grub2-splashimages
gsfonts
gtans
gtk-nodoka-engine
gtk-sharp2
gtklp
gtkpool
hasciicam
haskell98-tutorial
hawknl
hdate-applet
hpsockd
hsqldb1.8.0
htag
hugs98
hunspell-ar
hunspell-se
hunt
hyphen-show
iat
icom
iitalian
imgsizer
impose+
info2www
initz
installation-guide
ipkungfu
ippl
ips
itop
jack-tools
java2html
jcal
jesd
jigl
jline
jpeginfo
jpegpixi
jpnevulator
kdc2tiff
keytouch-editor
kmfl-keyboards-mywin
konwert
kunststoff
labrea
lam
latencytop
latex209
leds-alix
libalgorithm-checkdigits-perl
libalgorithm-numerical-sample-perl
libapache-mod-auth-radius
libapache2-mod-authz-unixgroup
libapache2-mod-defensible
libapache2-mod-lisp
libbase

[Summary]: RFC: Standardizing source package artifacts build paths

[Niels Thykier]

Guillem Jover:
> Hi!
> 
> We currently have many built artifacts being dropped directly under
> debian/ or under tool specific directories such as debian/.debhelper/.
> These have at least the following problems:
> 
>   - Make cleaning, an operation that requires executing code from the
> source package itself.
>   - Require keeping up updating things like .gitignore or artifacts
> might end up being committed into a VCS.
>   - Can stomp over existing files or other tools files, as these are
> generally not namespaced.
>   - Clutter the source tree, with debian/ mixing generated and manual
> files.
>   - dpkg-dev tools cannot assume the location of the binary package
> to be built, as that depends on the packaging logic and how that
> might drive the various commands.
> 
> [...]
> 
> Thanks,
> Niels and Guillem
> 

Hi,

It seems that the discussion on this topic has stopped and I will now
attempt to summarize the discussion and related consensus as I
understand it.

 1) No one seem to have voiced concerns about the general concept of the
proposal - only particular choices for path names and their
default visibility.

 2) The primary concern seem to be that the directory debian/.build is
hidden.  For some, this was a concern in general, for others the
concern appeared to be that paths they thought useful were being
"hidden by default" (concrete voiced examples include debian/tmp,
debian/ and upstream build directories).

 3) We followed up with an [update to the proposal] were debhelper would
optionally expose some of the relevant directories (some by default,
others on request) with symlinks while still supporting the new
layout. It did not attempt to change the debian/.build directory.


 4) There is not been any visible feedback on our updated proposal from
people, who raised concerns about the path, on whether this
alleviated their concern.  Nor any visible feedback on the choice of
paths being exposed by default.


*My interpretation of where we are*


>From what I can gather:

 * The proposal in concept has consensus.

 * Lack of visible feedback on the amendment make it hard to tell if the
   amendment alleviates the concern of people wanting certain
   directories to remain visible.

The lack of feedback on our amendment can sadly mean anything from
people accepting the amendment, people not being invested in the topic
or even people silently giving up on the discussion - neither documents
consensus in a good way, which is unfortunate as it leaves us in a
stalemate.


*What happens now*
Guillem and I will give another week for follow ups in the hope that
people will provide feedback on the amendment - either that the
amendment alleviates their concern or they would like a different
trade-off on the proposal.

In the absence of any update in the next week, Guillem and I will have
to consider an alternative way of resolving the stalemate.  Should that
happen, my personal take would be to apply the "Do'ers decide"-rule from
the constitution and move forward.

Thanks,
~Niels

[update to the proposal]:
  https://lists.debian.org/debian-dpkg/2020/04/msg5.html

Re: RFC: Standardizing source package artifacts build paths

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote:
> 
>> Guillem and I have debated this and come to a solution, which we believe
>> will be able to address the concerns about the path being "hidden". It
>> also enables us to simplify parts of the migration in some cases.
> 
> Thank you for your continued efforts!
> 

Thanks. :)

>> The short version of that solution is to enable debhelper to expose the
>> relevant directories where you want it and under debian/.build at the
>> same time (the latter being a symlink to the former)[1].
> 
> Sorry, but don't you mean the former (non-dotdirs) being a symlink to
> the latter (.build)?
> 

Originally, no.  Though I think I will leave it unspecified while we
experiment to see if I become wiser on the topic than I am today.


My thought was this would enable debhelper to see that the directory was
exposed and look it up without additional state tracking (which would in
turn enable debhelper to ensure that we clean up properly since both
"ends" must be removed during clean).

But worst case, it will cost me a compat level to flip the order of the
two if the epiphany comes to me after initial deployment.

~Niels

Re: RFC: Standardizing source package artifacts build paths

[Niels Thykier]

Sam Hartman:
> I'm concerned about a leading . at least for:
> 
> * the debian/tmp replacement
> * the replacement for the package install directories under debian.
> 
> I think that maintaining those directories such that ls shows them will
> be more friendly for new maintainers.
> So I'd prefer something like debian/build rather than debian/.build for
> at least those directories.
> 
> I don't care as much about substvars, debhelper intermediates, debhelper
> logs and the like.
> 

Hi,

Guillem and I have debated this and come to a solution, which we believe
will be able to address the concerns about the path being "hidden". It
also enables us to simplify parts of the migration in some cases.

The short version of that solution is to enable debhelper to expose the
relevant directories where you want it and under debian/.build at the
same time (the latter being a symlink to the former)[1].
  This can be made to cover the directories you mention above, but also
e.g. the build directory for upstream builds, which was mentioned
elsewhere in this thread.

Based on the feedback so far, I will go with the following defaults in
debhelper:

 * build directories are exposed if -B/--builddirectory is used to
   request it.  If there is no explicit -B/--builddirectory, it will
   (in a new compat level) be hidden by default.

 * The staging directories a la d/tmp will be exposed if --destdir is
   used with dh_auto_install.
   - I will expose d/tmp by default for now but "parallel" d/tmp-X dirs
 are not (they currently require a --destdir to work as it is now).

 * d/ are exposed by default for now.


Any other debhelper artifact will move to a new path in a future compat
level (at this stage, we are talking debhelper/14 rather than debhelper/13).

~Niels

[1] Note that dpkg will migrate to always use the paths under
debian/.build.  This should not matter in practise unless you fiddle
with the symlinks that debhelper creates.

Re: trends.debian.net updated

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Sat 04 Apr 2020 at 09:28AM +02, Lucas Nussbaum wrote:
> 
>> Well, no, there doesn't seem to be any serious user-visible issues.
>>
>> That's why I keep wondering whether it makes sense to just keep all this
>> technical debt around.
> 
> It could be useful to someone, and it is not clear that it is doing us
> any harm, though, right?
> 


Some of the technical debt is "doing harm" in the sense that we will
have work around and deprecated code that linger and slow down our work
on improving Debian.


Some of the recent improvements in debhelper was vastly complicated by
the fact that I had to deal with compat 9 and earlier that does
something considerably different.
  Even after expediting the obliteration of manual sequence control
parameters in dh, the sequence-handling in dh is difficult to understand
because of fundamental differences between compat 5-9 vs. compat 10-13.


The dpkg tooling is keeping a now 8 year old (?) work around for
packages not having a build-arch/build-indep target.  That work around
is not gratis - neither in performance nor in the cognitive burden of
improving the packaging stack.


Helmut has been continuously filing patches against patches to have them
use debhelper's dh_auto_* tooling instead of calling
./configure|cmake|... directly without setting up cross tooling
correctly for cross-builds.


Therefore, I would like us to acknowledge the fact that technical debt
is doing harm in that it has a cost for our contributors.  But at the
same time, I know it is hard to compare objectively to the cost of the
alternatives (such "janitorial uploads to fix technical debts" or
"removals").  If it was easy, we would probably have computed the
optimal trade-off and solved this very old issue long ago. :)


~Niels

Re: Bug#954313: dh_installchangelogs: provide option to strip off old changelog entries

[Niels Thykier]

Control: tags -1 moreinfo

Michael Biebl:
> Package: debhelper
> Version: 12.9
> Severity: wishlist
> 
> Hi,
> 

Hi,

Thanks for the suggestion. :)

(CC'ing d-devel because I think this is relevant to the discussion there)

> some packages have a very detailed debian/changelog which goes back
> years or even decades.
> 
> Given that we nowadays have the ability to get changelogs on-demand via
> "apt changelog", I think it would make sense if the changelog.Debian
> that is installed on disk can be trimmed down.
> 
> While I surely can do that via some sed hacks in debian/rules, a nicer
> option would be, if dh_installchangelogs would provide an option like
> say --trim=365d / --trim=2y / etc, which would only install changelog
> entries that are newer then 365 days / 2 years / etc.
> 
> 2 or 3 years sounds like a good compromise to me, as this would cover
> changelog entries dating back to the last stable release.
> 
> For the time being, I would make that opt-in, i.e. packages have to
> override dh_installchangelogs. Maybe at some point in the future,
> something like --trim=3y could be made the default behaviour with a new
> compat bump.
> 
> I vaguely remember that Ubuntu does something similar in that regard.
> I've CCed Julian, maybe he can provide some input.
> 
> Regards,
> Michael
> 
> [...]
I think we owe ourselves to be honest and agree whether we do this or
not.  The proposed opt-in solution will almost certainly end up being a
slow translation to saying "yes we are going to do this" - it will just
defer the answer 5 - 10 years with a lot of extra work.

And if we are going to that, I would rather do it fully automatic from
the start.  Either "flag day"-style or "next compat level"-style.

This would save everybody else time and energy learning and unlearning a
command option that you have to sprinkle into your package to have
debhelper "DTRT".
  And would save me from adding an option and then spend a decade
removing it again because it has become obsolete[1].


Lets not add "yet another papercut" to our packaging process.


On the topic of derivatives: I am happy to hear from derivatives that
have different needs for changelog trimming.  As mentioned in the d-d
thread, there is Ubuntu which is currently the only one I am aware of.

~Niels


[1] The time spent removing features from debhelper is literally
measured in decades.

Standardized way of extracting additional build-time artefacts (was: Re: RFC: Standardizing source package artifacts build paths)

[Niels Thykier]

Simon McVittie:
> On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote:
>> Simon McVittie:
>>> For example, dpkg-buildpackage could perhaps read one glob per
>>> line from debian/artifacts and hardlink matched files (if any) into
>>> debian/.build/artifacts for collection by a "larger" framework like
>>> sbuild or pbuilder, or individual packages could copy/link files into there
>>> as they go, or debhelper build-system classes like Autotools and Meson
>>> could know the names of common log files from their build system, or
>>> some combination of those.
>>
>> Though, can you elaborate a bit on why the above approach would be
>> better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
>> easy way to declare additional artifacts to be extracted?
> 
> Mainly, I'd prefer something declarative with glob patterns (a bit like
> debian/clean or Gitlab-CI's artifacts:paths) rather than having to write
> logic like these pseudo-patches:
> 
> [...]
> 

Ack, I get the part of having a declarative mechanism for selecting files.

Just to clarify something related.  Should debhelper and other tools by
default archive "certain files of possible interest" (e.g. config.log)?
Or should we limit it to "on request only"?

The former makes it simpler for people that are interested in the
"default" parts but also bloats the archive for people that are
interested in just one file.

> I don't have any particular opinion on whether artifacts should be
> collected into debian/.build/artifacts/, into $DPKG_ARTIFACTS/, or
> directly into some sort of archive (Gitlab and Jenkins seem to use zip
> files, which have the advantage of being seekable, so web frontends
> can presumably read individual logs directly out of the zip file if
> that's desirable).
> 
> smcv
> 

Thanks for clarifying.  This answered the question I was trying to write. :)

~Niels

Re: RFC: Standardizing source package artifacts build paths

[Niels Thykier]

Simon McVittie:

Hi :)

> On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote:
>> We'd like to standardize on a new set of artifact build pathnames
>> for our deb toolchain. These would have the following form:
>>
>>   - debian/.build/upstream*
>>
>> These could be used for out-of-tree builds replacing current
>> build-tree/ and similar directories.
> 
> Presumably the '*' means it's considered OK for packages that do separate
> production/debug/udeb builds to use multiple directories matching that
> glob?
> 
> For example, a simple debhelper build might eventually (in a future compat
> level) default to "dh $@ --builddirectory=debian/.build/upstream",
> but because src:glib2.0 does separate deb and udeb builds
> (with non-essential features disabled in the udeb), it
> would use "--builddirectory=debian/.build/upstream-deb"
> and "--builddirectory=debian/.build/upstream-udeb" instead
> of its current "--builddirectory=debian/build/deb" and
> "--builddirectory=debian/build/udeb"?
> 

Yes.  :)

Among other, it will hopefully also enable debhelper to support multiple
builds natively or better, when we have a standardized path for these
things.

>>   - We could just (say) .gitignore a single pathname.
>>   - Cleaning the Debian artifacts would imply doing just
>> «rm -rf debian/.build/» (even though this could be abstracted via a
>> new dpkg-clean command).
>>   - Namespacing would avoid any collisions.
>>   - Would make parallelization way easier and faster.
>>   - dpkg-dev tools could start defaulting to use package specfific
>> directories, instead of requiring the user/tool to specify them.
> 
> This all seems good to have.
> 
> The Salsa-CI pipeline (which runs in a git clone of a package, and
> currently uses debian/output/ for intermediate build stuff) could maybe
> also move its scratch directory to debian/.build/salsa-ci.
> 
> Have you seen  and
> related discussions in the context of sbuild and pbuilder? It seems
> like a related topic. [...]
> 
> For example, dpkg-buildpackage could perhaps read one glob per
> line from debian/artifacts and hardlink matched files (if any) into
> debian/.build/artifacts for collection by a "larger" framework like
> sbuild or pbuilder, or individual packages could copy/link files into there
> as they go, or debhelper build-system classes like Autotools and Meson
> could know the names of common log files from their build system, or
> some combination of those.
> 
> smcv
> 

I could see how having a well-defined method for extracting artifacts
will be useful (also for CI purposes).

Though, can you elaborate a bit on why the above approach would be
better than a standard ENV variable a la AUTOPKGTEST_ARTIFACTS and some
easy way to declare additional artifacts to be extracted?
  I am fine either way, but I could image that the
debian/.build/artifacts will feature interact with e.g.
"dpkg-buildpackage -tc" where a AUTOPKGTEST_ARTIFACTS replacement would not.

~Niels

Re: News about the debhelper toolchain

[Niels Thykier]

Hideki Yamane:
> On Mon, 10 Feb 2020 21:37:05 +0100
> Niels Thykier  wrote:
>> Remember to *remove* "--with python3" from d/rules as well. An explicit
>> "--with python3" will cause issues with Build-Depends-Indep and other
>> conditional usage (e.g. build-profiles).
> 
>  And does lintian warns it?
> 
> 

Not sure; I have not tracked the lintian side of things.  Though if it
does not, please file a bug against lintian.

~Niels

Re: News about the debhelper toolchain

[Niels Thykier]

Hideki Yamane:
> On Sat, 1 Feb 2020 15:38:14 +0100
> Niels Thykier  wrote:
>>  * The "dh-sequence- build-dependency" to replace the
>>"--with " parameter to dh in the debian/rules.
>>- Note that third-party add-ons may not have added the relevant
>>  Provides to support this change.
> 
> Build-Depends: debhelper (>= 10~), dh-python3,
> ↓
> Build-Depends: debhelper-compat (= 12),
> Build-Depends-Indep: dh-sequence-python3,
> 
>  like this?
> 
> 

Yes, this is now possible in general. :)  I have not tested concretely
whether dh-sequence-python3 supports being put into Build-Depends-Indep
(but it probably does).

Remember to *remove* "--with python3" from d/rules as well. An explicit
"--with python3" will cause issues with Build-Depends-Indep and other
conditional usage (e.g. build-profiles).

~Niels

Re: call for ftpmaster's transparency

[Niels Thykier]

Michael Lustfield:
> [...]
> 
> I too would love to engage in a civil discussion about ways to improve the
> situation. Let's start with this-
> 
> Why do reviews take so long?
> - The team is tiny
> - Much of the team seems very burned out
> - The ones that are active tend to stick to source or "unloved" tasks
> - There are some very large and/or messy packages that need review
> - There are a lot of redundant tasks and frequently-made mistakes
>   + A little more automation could help that
> - (my opinion) The tools are archaic, cumbersome, and inefficient
>   + Fixing this would be a very (non-technically) difficult task
>   + An idea I have would help to bring transparency to the process...
> ^ it's missing an interest requirement :(
> 

For the parts involving tooling, are there bugs/salsa issues describing
the issue so a "non-FTP-team"-member can take a stab at fixing them?

~Niels

Re: News about the debhelper toolchain

[Niels Thykier]

Paul Wise:
> On Sat, Feb 1, 2020 at 2:39 PM Niels Thykier wrote:
> 
>>  * debhelper generate a temporary writable directory for $HOME
>>and $XDG_RUNTIME_DIR plus clear all remaining XDG_* variables.
>>This simplifies packaging of tools that insist on writing to
>>$HOME.
> 
> What is the right approach for disabling this locally (in
> sbuild/pbuilder rather than in the package) in case someone wants to
> detect and fix such problems rather than papering over them with this
> workaround?
> 

Currently, there is no way do this for package using compat 13.  I am
happy to review patches for adding such a feature (e.g. via
DEB_BUILD_OPTIONS).

Accepted debhelper 12.9 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 27 Jan 2020 20:45:05 +
Source: debhelper
Architecture: source
Version: 12.9
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 568897 885994 949396 949538 949635
Changes:
 debhelper (12.9) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * debhelper.7: Clarify how DH_OPTIONS works and that some
 third-party tools may ignore it if they do not support
 it.  Thanks to Andrej Shadura for reporting the issue
 over IRC.
   * doc/PROGRAMMING: Introduce a section on the NOOP PROMISE
 comment.
   * dh: In compat 13, skip calls to hook and override targets
 for dh_auto_test, dh_dwz and dh_strip.  Thanks to
 Mike Hommey for suggesting it.  (Closes: #568897)
   * Dh_Getopt.pm: Remove support for "--ignore".  No package
 uses it any more.  For most parts, it has been replaced
 by the "3.0 (quilt)" source format.
   * debian/changelog: Clarify that substitutions change in
 12.8 only apply to the maintscript file (and not
 maintainer scripts) for dh_installdeb.
   * debhelper.7: Improve text in compat 13 section.
   * autoconf.pm: Only consider "configure" as an autoconf
 script if it is a file (and not a directory).  Thanks to
 Andrius Merkys for reporting the bug and providing a
 patch.  (Closes: #949396)
   * debian/control: Bump Standards-Version to 4.5.0 - no
 changes required.
   * dh_shlibdeps: Pass "--" in front of filenames passed to
 file(1).  Thanks to Christoph Biedl for the suggestion.
 (Closes: #949538)
   * dh_strip: Ditto
   * dh.1: Improve documentation for override targets and
 include a section on the new hook target.
 (Closes: #885994)
   * Dh_Lib.pm: Make it possible to disable the command
 logging by passing "inhibit_log => 1" to the init sub.
 Furthermore, the logging is now only enabled when init
 is called (and not disabled by that option or
 inhibit_log()).  This prevents Dh_Lib from triggering
 a log write just by being loaded.
   * dh: Refactor addon loading.  As a side-effect, dh no
 longer leaks as many functions into the scope of addons.
 Addons depending on the previous behaviour may now fail
 due to calls to undefined subroutintes and will need to
 be fixed.
   * dh_installinitramfs.1: Correct the name of localized
 versions of dh_installinitramfs so that man can find
 them.
 .
   [ Thorsten Glaser ]
   * dh_auto_*: Make it possible to disable build systems by
 passing --buildsystem=none.  Previously this would
 require overriding each and every dh_auto_* tool.
 (Closes: #949635)
Checksums-Sha1:
 d6760cfaea25b56d0b3d235d33e64db07e9e1729 1835 debhelper_12.9.dsc
 f6deb32e6c3983371baa4bdda0e327506b4ba5a8 521116 debhelper_12.9.tar.xz
 f325d2834f397c56da86205c9d29f0b04ca8ca00 4613 debhelper_12.9_source.buildinfo
Checksums-Sha256:
 7db1ce578c248d92824af25638fea8c0c02595ecfb4be1445ac18bd76cee5f54 1835 
debhelper_12.9.dsc
 d627404c45a9f4012624fd38f1dac22cb66bbae6c0d158abf01a9785d2154a97 521116 
debhelper_12.9.tar.xz
 497fa5cd6034bc5c392b0938681ad94ec305a161f78f3ebeded5bb101e60d223 4613 
debhelper_12.9_source.buildinfo
Files:
 566fc7cc7cd59c36073234b29ff29a20 1835 devel optional debhelper_12.9.dsc
 b3cf3a7d68a98299f9a11bc4370d43f7 521116 devel optional debhelper_12.9.tar.xz
 6963248dc97bf4db79d1b0682e825271 4613 devel optional 
debhelper_12.9_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl4vUB0SHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsrRUQAJDPIBWPKKSLow81PR7LKbYGmoSkMMlx
wNi9U9ntqcfw90bH/7Q19WGv2g0wd1IfE4/NanQymDVK19/5zZTvoBvGmcGuZb/m
HTPt4PwCgWqTt7bVhcTm/XydGIpRPzn0MyO+A82u7g1rrQYQodDVMXIVhaOgonmu
7mQDfnCKQ85jW4dvh60/66ggdRlNjl9q9ZxxNH6P2OwL5rVGV1ouJwGCkx+8Ya6y
mLMNtaICdAtDZ+4eCtngdLbrslcuLoQ8k55qWKfu7JGeFBQysdtxL5WpKdBYOtSj
i6+7lgYtrIM8idrDKKvCy3wPxisDnnVkS1dSCpmQs3bnNNJBNIntpz/eRvUBVNrC
3vagb8ojzkwQcbSt0XKaBsoadDab4kHtOayvAWovkEKDxZcMFZNftQneirAMneSV
JwbSsmzc3aGOxFq0ke0cjOvm8vuhaWK9uGq5LF06eBPng5JgLBfs4nCpIREFp4lX
FqQOO2RPLD/Ig9CJLw6Tkhe9jFnRcckbm9AmyK5GSOJKS1hPSj7L7x+fPvCR8KGm
lpVH2ayYfEq7kKndoZk0NFDVjCXXOYYxnbV+o3vTSGtMoSs7ITZ2gTvIpExVG2We
kc+6NTgXyd7d/5rFXz2EDPHiEUaS7HNCcE9cc+oys6oH1+Yjg2xbO3MK/KRPmzRZ
ImqkPwi2a7cc
=4IQZ
-END PGP SIGNATURE-

Accepted debhelper 12.8 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 19 Jan 2020 10:02:16 +
Source: debhelper
Architecture: source
Version: 12.8
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 198507 885994 906723 917368 944478 944691
Changes:
 debhelper (12.8) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * Dh_Lib.pm: Simplify internal loggning of which commands
 have been run.  We are no longer interested in whether
 it was an override target or not.
   * dh: Support "execute_before_X" and "execute_after_X"
 targets in debian/rules.  This is useful for injecting
 commands before or after the command "X" that dh runs.
 Note this feature requires compat 10 or later due to
 internal limitations in debhelper.  Attempts to use
 it in compat 9 will trigger an error.  Thanks to
 Christoph Berg for the suggestion.  (Closes: #885994)
   * dh: Detect and warn about override and hook targets
 for known obsolete commands.  In compat 13, this will
 be an error instead of a warning.
   * dh: Reset umask to 0022 as a consistent default value.
 Thanks to Thorsten Glaser for the suggestion.
 (Closes: #944691)
   * dh_missing: The --fail-missing parameter is now default
 in compat 13.  Thanks to Mattia Rizzolo for the
 suggestion.  (Closes: #917368)
   * dh_installtmpfiles: New command extracted from
 dh_installsystem that will handle tmpfiles.d
 configuration.  Thanks to Michael Biebl for the
 suggestion.  (Closes: #944478)
   * dh_installsystemd: In compat 13, this command will no
 longer manage tmpfiles.d configuration.
   * dh: Run dh_installtmpfiles by default in compat 13.
   * Dh_Lib.pm: Emit "error" and "warning" with error and
 warning messages.  Thanks to Paul Wise for the
 suggestion.  (Closes: #906723)
   * Dh_Lib.pm: Support colored output for warnings and
 errors (enabled by default).  The colors can be
 controlled by setting DH_COLORS or DPKG_COLORS.  The
 latter will also affect dpkg-related tools.
 Note: NO_COLOR is respected in the absence of
 DH_COLORS and DPKG_COLORS.
   * Dh_Lib.pm: Support substitution variables in files
 handled by filearray and filedoublearray in compat 13.
 This also applies to executable configuration files.
 As the substitution occurs after splitting the files
 into tokens, it can be used to include spaces in the
 tokens (often file names).  (Closes: #198507)
   * dh_install: Support substitution configuration files.
   * dh_clean: Ditto.
   * dh_installcatalogs: Ditto.
   * dh_installdeb: Ditto (maintscripts only).
   * dh_installdirs: Ditto.
   * dh_installdocs: Ditto.
   * dh_installexamples: Ditto.
   * dh_installinfo: Ditto.
   * dh_installman: Ditto.
   * dh_installwm: Ditto.
   * dh_link: Ditto.
   * dh_missing: Ditto.
   * dh_ucf: Ditto.
   * debian/rules: Remove override for dh_missing as the
 --fail-missing parameter is default now.
 .
   [ Helmut Grohne ]
   * Warn about missing perl-xs-dev for perl_* buildsystems.
Checksums-Sha1:
 d7d6166a4b0adef3ff1fd09d0b8ca162c1c928c0 1835 debhelper_12.8.dsc
 fa9331630bc7414d2af3251c61b7d6bf47758714 517508 debhelper_12.8.tar.xz
 bab5a3ecb0ff79835ce8b8e6bce3c3e42c81cf0b 4578 debhelper_12.8_source.buildinfo
Checksums-Sha256:
 5e586386833e5bc5a8307ba36c4fdb5a3e965756e92ac7a91ca9752a18416fdf 1835 
debhelper_12.8.dsc
 8ef5c8eae677b98d826405d0c323df7f74eba7fe4716545abf507235a86e8b5d 517508 
debhelper_12.8.tar.xz
 5d07a89fe4f4629dafd22bdd67c678dd40a3551133092975273613ec762d0a7a 4578 
debhelper_12.8_source.buildinfo
Files:
 dc997eef9382e8828617e150498b38f4 1835 devel optional debhelper_12.8.dsc
 eafc304b3c69848e204e5eadf41e1f2a 517508 devel optional debhelper_12.8.tar.xz
 25a631399bb0b3d12be2e8a23b663c8b 4578 devel optional 
debhelper_12.8_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl4kKasSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqstaUQAJmzBdm6FOaYneMYYIQFEuUWQEk0cSv+
0X72ik2pM8jCLHCJMvfa0fKMAc3KHsIqkeXaPbouuD/StdJCO4dIQI3GL7RNp03A
7z7e2IFi3FKg+9ExYU57JO8faSPWrnn4MVzmS6WlqYvce6A9hL5evqELoK+I8akn
RtWQnu03dzH/xBEdvvA5zVRa65A5uuvNfKy+pODqj6J1mrrz4cO93iqVgN6X7L64
9aGKE3MhkHqNxEoggqwDW2y9bVJCVJAlD4ctrxgmmn3lnOnA8aC4EMsSb3CwAOMb
d76VFpbW7eadxTTlti7HF2apJaP9iXqYUvw58s90ueVYKa18BNC894p/TUKn2LCE
/UsOGai3TZlvFfFlqwssXim3Mmi0kgjF1RAWROhO1/MxwnbjwHsln9R1s6QDwXLN
d+xTKGnBBqtFaKh6ryf18MSQDn/OU5Kuo73jbW4MzWN3IfC5dOIKiV54vWo6u/Hs
iTzeVsd8e5Mi0OPpTuFWuvMVsq4BOmYyyCZcS1k0pohJ9wcZe4387av5JKc7S0Cp
zi3rb/Ydu+8UCIgWFfnRYyKc58NJQPkhEMPIaMlVoRMPPTWCKXGcnlngkx9eHSxR
V66vOKwSDc033KtZuZJSlz1XOdgHPohEkaDb3/V08HaEx+uUCREjYvWV+zVSU6mA
P9MQsz4sOsV0
=cOIK
-END PGP SIGNATURE-

Re: opentmpfiles & opensysusers, and its use in the Debian policy

[Niels Thykier]

Simon McVittie:
> [...]
> 
> The opentmpfiles and opensysusers packaging will need to arrange to do
> something analogous, most likely in cooperation with dh_installsystemd
> or some other debhelper step for the first two points, and with LSB init
> scripts for the tasks where systemd uses one-shot services.
> 
> [...]

Re: tmpfiles:

There is already a bug for extracting tmpfiles.d handling from
dh_installsystemd and put it in a separate helper for unrelated reasons
(see #944478).

Improvements/ideas welcome on #944478.

Re: sysusers:

I am happy to implement a helper for that as well assuming there is
consensus that this is a better approach over adduser.  Just file a
wishlist bug with instructions on what that helper is supposed to do and
how the maintscript should look.


Russ Allbery:
> [...]
> 
> I really want to get rid of maintainer scripts as much as possible in
> favor of pure declarative syntax in the packages.  [...]

Hear, Hear!

Bonus points for anyone with a solution *without* maintscripts!

(But in the absence of perfection, a debhelper tool with a autoscript
snippet can do).

Thanks,
~Niels

Accepted debhelper 12.7.3 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 29 Dec 2019 17:59:47 +
Source: debhelper
Architecture: source
Version: 12.7.3
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 946655 947506
Changes:
 debhelper (12.7.3) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * dh_perl: Use perl:any for perl module in addition to perl
 programs.  Thanks to Helmut Grohne and Niko Tyni for the
 suggestion and analysis.  (Closes: #946655)
   * dh_gencontrol: Clear the "Built-Using" flag for dbgsym
 packages.  It is irrelevant as the original binary will
 have the field plus the field can cause lintian warnings.
 (Closes: #947506)
   * lintian-overrides: Override no-dh-sequencer as it is a
 false-positive that lintian cannot be expected to know.
 .
   [ Debian Janitor ]
   * Fix day-of-week for changelog entry 4.0.0.
Checksums-Sha1:
 cb96a25c888bb0aac81e4686ceb7507ba52f2823 1843 debhelper_12.7.3.dsc
 4799bb4fd25309c85f84b3a1f604b7c88bb6ff07 511396 debhelper_12.7.3.tar.xz
 a5a7ef89f2b884cdff72819f0c6019fe9c1fc942 4499 debhelper_12.7.3_source.buildinfo
Checksums-Sha256:
 c7ce2ba248a461af1b184c5c0c7ac11a5f2c82d887c81ad071f8a79d751b661b 1843 
debhelper_12.7.3.dsc
 a4244abc372180a62dc83ea48f3c244f4a3a6ed676c4eda5b131083b82b35bb1 511396 
debhelper_12.7.3.tar.xz
 2e99e5766838143cf4f02eb88fcb499eb1e34ff4922b680a3875fce3bc937ff4 4499 
debhelper_12.7.3_source.buildinfo
Files:
 086c42350444133b82fda8396543bad3 1843 devel optional debhelper_12.7.3.dsc
 e591367ffe79a056d4e560c38f27bb1a 511396 devel optional debhelper_12.7.3.tar.xz
 e21eef30bc5e2ce9e851e705dfd89939 4499 devel optional 
debhelper_12.7.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl4I6oYSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsKwAQANng9jdJYjy7PraoRwxirWxLpqSgrMr/
h6XJkMF4tCGejTClAZcwZyFhXvorcF32Gyfn09rKDV1acX6EezM8iBtT6FGtOZlj
o4oEvX1esZX1Sv3BvRCK5iOWhuKxH2wjOBkF2WddYLopHZU1qL0LcRIs2EWwh6Yj
d/X4Et3lbs1xY42GK/hnteUolRvboAkm2Nhsp3Ui2dlQwaYJ3F9SlJBKo35nyj/O
8NFLcsAs3oWodf9yYANj6oJM0SBup13lhw2myaqkUS7iJKpJ5YvwkoDbZWlhTwW7
lVbmEf3+ihs4F/rba30McD5gBu4/PTEUUA/2lBGpfz0KDMugBNr1seLasFmJiedJ
nSi6zPOI8GSVN5gCir0aAhRrWtheFEa8W6Fzgcp3Yg9duwSi2T4l1edOLnx7M6JD
2+E8DfurGdSYjhVM+TBC5rxhrPwjP22Vurcedu1FkMx/JgFzNBPkQ82j1q7fNO/6
pOyS1vdK6dP0C9mkpG6/LMfwbSD/Ezm6JGXiCREIR9rhBzDwvq8kJ8BFXOK9+YrL
kHreTf4XoebrmUJZqikeXrs933pOO3mPTSGb5WVjqCIZIBZ4f/31XtOKLQYG2UwK
cksdhYqIA081r+mv9FOVhGmJW0qOk3SNlcFF1Xh1165c0bL/xzBPKf2yI5YpiWhf
7E/JFQyjWwuO
=EjOR
-END PGP SIGNATURE-

Accepted debhelper 12.7.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 07 Dec 2019 17:44:32 +
Source: debhelper
Architecture: source
Version: 12.7.2
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 933799 942111 943705 943853 944225 945149
Changes:
 debhelper (12.7.2) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * dh: Skip conditional dh sequence addons in the clean target.
 This avoids FTBFS with conditional addons where the
 build-dependency is not satisfied.  (Closes: #944225)
   * meson.pm: Fix bug where dh_auto_test would break horribly
 under compat 13 due to an uninitialized variable.  Thanks to
 Benjamin Jacobs for reporting the issue.  (Closes: #945149)
   * dh_installman: Fix non-deterministic behaviour when there
 multiple definitions of the same manpage in a package.
 In compat 13, this is resolved by aborting with an error.
 In older compat levels, dh_installman will deterministically
 pick a canonical version (via sort) along with emitting a
 warning.  Thanks to Colin Watson for reporting the issue.
 (Closes: #943705)
   * dh_auto_*: In compat 13+, reset HOME and XDG_* environment
 variables.  Some are cleared and some are set to a writable
 directory that persist until dh_clean.  Thanks to
 Simon McVittie for reporting the issue.
 (Closes: #942111)
   * dh_auto_*:  As a side-effect of the above, debhelper in compat
 13+ no longer trips a FTBFS in sbuild for meson packages when
 ccache is installed but not configured/used explicitly.
 Thanks to Simon McVittie for reporting the issue.
 (Closes: #933799)
   * d/control: Bump Standards-Versions to 4.4.1 - no changes
 required.
 .
   [ Andrius Merkys ]
   * debhelper.pod: Document chagnes to the gradle third-party
 build system in compat 13.
 .
   [ Translations ]
   * Update German translation (Chris Leick)  (Closes: #943853)
Checksums-Sha1:
 f899a9c35d96880fa86e10efd964a49ab35c71ae 1843 debhelper_12.7.2.dsc
 16de18893706d2679cb3e45ecfcd834feb18b380 511800 debhelper_12.7.2.tar.xz
 7b5ddaa9829e00e196c9ac22c0d2dc479a5c636b 4503 debhelper_12.7.2_source.buildinfo
Checksums-Sha256:
 af438985becb7b19a5cb6794e465910bab90efab3706d49edb2700dde1dd696b 1843 
debhelper_12.7.2.dsc
 29f3f199c052adf7314323e3b2a5ffeb93459217437b756f129f25419686513a 511800 
debhelper_12.7.2.tar.xz
 e797fb2943f92f8ad3894ac4ca8950f5e6bc7d44a486a81a87848144ce400db9 4503 
debhelper_12.7.2_source.buildinfo
Files:
 adf1237d049b5256d145a5ff0d3fca33 1843 devel optional debhelper_12.7.2.dsc
 cdabf464926b9381c32a0bde76d9b00b 511800 devel optional debhelper_12.7.2.tar.xz
 401e26a00264856ee25625d0879f651f 4503 devel optional 
debhelper_12.7.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl3r5fQSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsCnIQALNsMUN3NThAcrQxv44OfkoGV4D5/FV1
3t8Pu3i1amM4k/umBoAoJ0g4UjChb+aY88EmNEw+UKHDdoY45oq2AZNhLShSxdza
NqSXQEXkGGRhi4X4cwpHWvpYpAi/qNz+PwuhV8+CMqKGdj6xLrMBovUq35VePX9z
FRHT9RQVf5TxiJbugW8h2VgNNdVTfkv9NTUKChZjdkMGxht4V2QCT+WbU64VqEhe
KiVsL0gTPQMp+n2kNjqbVU5QfvtDgID/naF5mnG5b+zblQgr30VYfMiNayH/IKrV
MytKCTSYa/FvRS4VL7zGSncfw3P3SKj2bj/yXXm8/tzCkyYFMNl2EnNxVAHt0U0W
B0yM1lq2QmBoQW4hJRTcpcVzDoZ6IVvdvxpMIQU/Tp9VXaHc1pCf00XHHvfUIdB+
CJJu05tOa4ts1bTG/9DiWQEWNExhGBmsDM6nJBFt3aAD1LzTIs9TwqiYYUDSUDTo
xFwmAtPbslx6Phyhw+0hvmulwAUNj1pLco7a3eBtwQRf7Kl0aYR0FKtwL03UCaYW
wNTJfD1cXkvtaYBVOmwhdq52x8Z0HeSMzmABhKC5/61lI259leOvzah/hCaC3+UY
ZuebabVO7+ZTSS0JqtwDNEoSyskHnk51LeJMmnbhm5vTE6ek1P1cJFJ62AeloPjw
Y0XU1fIbnRDf
=7CS1
-END PGP SIGNATURE-

Accepted debhelper 12.7.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 26 Oct 2019 06:42:04 +
Source: debhelper
Architecture: source
Version: 12.7.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 943376
Changes:
 debhelper (12.7.1) unstable; urgency=medium
 .
   [ Colin Watson ]
   * dh_installman: Correctly handle compressed manpages when
 dh_installman uses man-recode.  (Closes: #943376)
Checksums-Sha1:
 0c047e84cad369dc153c40d36dc1b90f00907ded 1843 debhelper_12.7.1.dsc
 20194da3f777ef1f82361052ffd1c81c2273c6f4 503768 debhelper_12.7.1.tar.xz
 c009de741e818dc3230cc0288a5399aec80cc107 4477 debhelper_12.7.1_source.buildinfo
Checksums-Sha256:
 d6ab3f6f0ed13544604be847ebd55e0382e52ff7ca0a8017caee9220f8cba71a 1843 
debhelper_12.7.1.dsc
 a84d07307229cbbf7dcaa472383d0c40bdb4b8828365007ef69b05fdca1d5a6f 503768 
debhelper_12.7.1.tar.xz
 59a8ab8443267b90907c201c96a75fbfcbb846a01ed4c34830c20c4fdb883f5f 4477 
debhelper_12.7.1_source.buildinfo
Files:
 58a7992c1ec0382a8e8166a0405feffb 1843 devel optional debhelper_12.7.1.dsc
 f120f9635d37f571dc9c767126053905 503768 devel optional debhelper_12.7.1.tar.xz
 71cd67df2700de69d4163d5aad8d5bc7 4477 devel optional 
debhelper_12.7.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl2z6vkSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsVlkP/RLgT2hgYsmLncbx3aVlZ1mHnUInPGGG
DdTe4Lbani9hp7c+FVxJH9mkelANHZ2ynM0CDXqnxdMSfRQCskAD58+G7H1TV9b4
wWzKZBaRf5QPJxLgfEDzxZQk+H03ngiux4wKXH5YK61U+E4npaLDVTylEsL6DbAz
YHYQGk1l+wzDtzBgC0BxdbuUdHLQfAUo7LB0ksmDuMoLAMEBVh8rysUDlqRBGF5/
DcgSWBn2JpJ5RuKihVgqJY5O0AlmhPWSN6Wzt0szqsCLGCSMaJooGnxoYMsmO01a
+zLELfV8/U7Tw4eK7mcefNHi4ksEdJ8a6C9FocRntui/YgyI2UgUg60uPC7/mYCd
38DEABKOB9Prhio6N1KPsWv7hMPo2WLImEQ/GqldinLqKuyiaQ4Yrcll/RumxuUO
WlVzTSHtsFpgiiNnlEzYkEcvNUQwMDQyLWgSXjL1/0jYwW2YcdyDAugTCnol/8dI
TfSJDaqnMi/acOEblQgVrJ/dmu/vZO7Bj3KXUjlTEvK++c8TMwVP5w33jLJa7Mca
AeFMm+yZG1NlniopwxMJpsVikNaIdl6ZAOp8m90BR+66jzjlaBGclPEb5mxGxla+
LHjwRDAzfF2xOxSvIBCCwOo6fSUi++H6Vj6VA8TWN+51zEieS+ceULb4hUYor9bx
pLxViKkjP8qu
=4lgf
-END PGP SIGNATURE-

Accepted debhelper 12.7 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 20 Oct 2019 17:48:06 +
Source: debhelper
Architecture: source
Version: 12.7
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 933576 941245 942454 942690
Changes:
 debhelper (12.7) unstable; urgency=medium
 .
   [ Niels Thykier ]:
   * dh_installman: Avoid error message when man-db is not installed
 (only occurs in debhelper's own build as man-db is a mandatory
 dependency).
   * dh_installman: Use man-recode(1) when available to massively
 speed up re-encoding performance for any package with a non-
 trivial amount of manpages.  Thanks to Robert Luberda for
 reporting the issue and Colin Watson for writing man-recode
 (Closes: #933576)
   * debhelper.pod: Actively discourage compat 11 as it has an
 issue that causes services not to start correctly in all cases
 (e.g. install, remove-but-not-purge, install again), which
 cannot be fixed.
   * dh_auto_*: Support a new --reload-all-buildenv-variables
 option for resetting the cache (of e.g. dpkg-buildflags).
 This is needed by e.g. parted which does two builds with
 different CFLAGS.
   * dh_makeshlibs: Suggest/Document that --no-add-udeb can be
 relevant for some udebs where the shared library for the udeb
 is embedded in a different package (e.g. the main udeb
 package).  Thanks to Nicolas Braud-Santoni for reporting the
 issue.  (Closes: #942454)
   * meson.pm: Fix invalid call under compat 13.  Thanks to
 Jeremy Bicha for testing it.  (Closes: #942690)
 .
   [ Helmut Grohne ]:
   * cmake buildsystem: Fix CMAKE_SYSTEM_PROCESSOR for 32bit arms.
 (Closes: #941245)
 .
   [ Niko Tyni ]
   * Basic support cross building XS modules:
 + perl_makemaker: run Makefile.PL with host arch Config.pm
 + perl_build: run Build.PL and Build with host arch Config.pm
 + dh_perl: scan host arch include directories for Perl plugins
Checksums-Sha1:
 20b0c1c8950deb931fb9c4be20c00f6dc6abceeb 1771 debhelper_12.7.dsc
 3391cdda0f237bcdca426c65330e4edc914dc8a6 503244 debhelper_12.7.tar.xz
 018ab1e9702a7cc0a4dd58671ea19b3154f972c7 4457 debhelper_12.7_source.buildinfo
Checksums-Sha256:
 0bdcad0d24bc4fb813f1d3339e03ef9ddff7ec78241d42c55b3d8c7251032b05 1771 
debhelper_12.7.dsc
 35b95dae4cb1714b559652be91f4cc66143e8c9adb4fced59b8a5284738e0ea0 503244 
debhelper_12.7.tar.xz
 77ae8a1cc694dda99a2ce0c6c240292a0d5214f90990e3d09108d887220c1408 4457 
debhelper_12.7_source.buildinfo
Files:
 f1697eefda2cdaa155c680d15da186d5 1771 devel optional debhelper_12.7.dsc
 63e9006c2822e3c00947fee0f031522d 503244 devel optional debhelper_12.7.tar.xz
 b94a1b7487b0b83740265b6c82126758 4457 devel optional 
debhelper_12.7_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl2snfcSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsJPYP/29tosYBILz2Z42WvQo23lFSV0tCsM7/
sjC3zS8oY+b+LNbnkohrZMuH1ctPjIofnlNXj22xtuqrqWKOMiqiXSo1o447JoTg
Cw2AdJ2i5iHeNw84AW/GQjQx6BLoi88f0vpjwiY43RJ4klu4EKR56NPpmRo1NS1A
fUKlRK0gLrKP8D1nRCE2YNUj23pe2cRlltgQMeLQacIkZm1z0vKeB9MroSlSa7c4
B+whoMCnsV3lv6rSeqnAYsQnlliB12nKostyz57yoNHkdTU0x6DlxW97I588BJzE
olCcOh1mNcGwIXp95DIn2TcyxoZ2WFCxMfiB5GE1a1e0cDeDspTWkR5qcOsD44+5
w3BO3IilInkwlQnYOqdBRmRc8DGzuOdVc63dS35Z3Wl2W0zqmF6G42AOdNm/Fi8C
YteonLfi0K4HfHOHNhd4WeRtOGYtXffHZxUhmVMwxKrS3HFhdvwGkRasvzcQWY90
lZQ4jjakoboMIGK2Rqsru9/JZWYRG+gxvnQjAOwcIr4z9syg0mWhEV6xohVKXqoZ
icGzpZ7cTG5WvgQXBRCRqtVyNCnaUo/LoVGN21cmvlS3xACAgJdo6DkQcbqswUdn
lb2pO1UJ1fi9TD7SKiDRu3YXjzL0LFy6i4VrvJi+DBr9Rl8kHFjQKPBx+uLDEG/j
tnZJkfbCkWzl
=s4Ze
-END PGP SIGNATURE-

Accepted debhelper 12.6.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 15 Sep 2019 10:08:53 +
Source: debhelper
Architecture: source
Version: 12.6.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Changes:
 debhelper (12.6.1) unstable; urgency=medium
 .
   * Upload to unstable now that libdebhelper-perl has been through
 the NEW queue.
Checksums-Sha1:
 a463c2b87746a6cd71913f9a075bbdab95ae4b2d 1779 debhelper_12.6.1.dsc
 9b15339fc5c2a11fcb2a82f68c80bd8a14716e97 501180 debhelper_12.6.1.tar.xz
 5c1f7765c577370144f2d1a798ff586df3941c07 4588 debhelper_12.6.1_source.buildinfo
Checksums-Sha256:
 41dfff90ff72e501ca5263b5c37707ffbfadf1e1a24a80ef98a12534835961b4 1779 
debhelper_12.6.1.dsc
 375677a50fa6455a0e81d335c0d5cc3f00f426ba9b11e6c046fb1cc1df4e40dc 501180 
debhelper_12.6.1.tar.xz
 46fcd0558003e6bd846ff391730bc727e7850318d2985a8a51546f912c64cf5a 4588 
debhelper_12.6.1_source.buildinfo
Files:
 3e419aaf1698c4d4f2a61f615acf9d88 1779 devel optional debhelper_12.6.1.dsc
 741fa798a9d8e60441224e287003982b 501180 devel optional debhelper_12.6.1.tar.xz
 5e8a05535f4a423a8c63ff213a343972 4588 devel optional 
debhelper_12.6.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1+DeUSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsUHkQAJjMNvK2bMRAqJiR19wGnfMG956PEE4o
8hj+KLBEbXvcc0oeO+m0O3c9Ioud4XMxYLipt9ZJBOgxIjs9XpouUQTEIjw8AdhR
YHvPvsmnurW2q7qr0JxiQd2KIYzsZYu/o0nIVJ1+acED3vasAEXXp59R6Tj8oMyd
nqN7UpaZZfc7AeComHaQjXx4ZnnZSPwE/qb+5wy3+szYNyboyp+QmgLBVuSevlNO
eTmn5yy5BbPqubY7tiEuMYgDxMBzHomVF+pfs+usjz7YNZbaSdipYzUmG6/fSt31
OO60Kg3AUUsTBiukxnIBSUaBs0i4OOLdBN4fWQ905hkAqOKjjW2vu9bB1kMKL2jY
pByd3O5/bn+8rK6RSuCW6tc6IR2572Sip037p+orfA+tnvHEGD2KAGKcImvVO1iV
D69lhQIk35baZ6KZLWiVGfKzuz19ddXpKmGTJB2T1QBkIvg4ycPh6GReyZcLtob7
F0mTDlFVwS+KjMcrgd/HOyCwNy+zwdT3iHvfH6H/K425VMQTBSzzBB+x59dyclaS
D1afHcor80oSJz4F20IQNS6UkVhn7SnwBQ3bMDcWS6KTsK7S56ExZ2e2fuQJjN3P
f7HTZEzpJdCpbYUeSnrCrMQ20N/BSTujBVpSnLq3P/+6OZU6BqpP1ikFxvQ2RplB
Yc3FWOFvTlDa
=z0ue
-END PGP SIGNATURE-

Accepted debhelper 12.6 (source all) into experimental, experimental

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 14 Sep 2019 06:37:44 +
Source: debhelper
Binary: debhelper dh-systemd libdebhelper-perl
Architecture: source all
Version: 12.6
Distribution: experimental
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Description:
 debhelper  - helper programs for debian/rules
 dh-systemd - debhelper add-on to handle systemd unit files - transitional pack
 libdebhelper-perl - debhelper perl modules
Closes: 821130 939164 939635
Changes:
 debhelper (12.6) experimental; urgency=medium
 .
   [ Niels Thykier ]
   * dh_makeshlibs: Fix regression where versionless SONAMEs could
 trigger a rejection of the "generated" shlibs file (despite
 dh_makeshlibs not generating any "shlibs" files).
 (Closes: #939635)
   * dh_strip: Avoid impossible copy of .../debug/.dwz/ to itself
 when a manual debug package contained ELF files and was
 processed by dh_dwz before dh_strip.  (Closes: #939164)
 .
   [ Sven Joachim ]
   * Split debhelper into debhelper (the tools) and libdebhelper-perl
 (the Perl libraries).  (Closes: #821130)
   * d/rules: Call dh_missing --fail-missing to catch bugs where files
 are not installed anywhere.
Checksums-Sha1:
 fe148890bd01f96e37d02a46be2f663dca218cf2 1771 debhelper_12.6.dsc
 b237ed6b64d20936f15f9c3a7e3f6f4d3a9c51bc 501184 debhelper_12.6.tar.xz
 cc730adcdc8a4e3f6d9a1a670d78ed21bc9984d3 993204 debhelper_12.6_all.deb
 d7af46ad2378583aa17ed5185654a305d3ea16e5 5226 debhelper_12.6_amd64.buildinfo
 be84087a230dc973b1e3ef2868642ff688db2242 125364 dh-systemd_12.6_all.deb
 392eb55413c6c228c302e56a9d75a57c2a5142b8 171732 libdebhelper-perl_12.6_all.deb
Checksums-Sha256:
 699209df464aa9bf162bf853627121cbe3e917ca05f181a45e39ba0a3824131e 1771 
debhelper_12.6.dsc
 5bd4d23fd0708c6c4a711c502f83576850e8358820ca017bb5b369ed03bc8717 501184 
debhelper_12.6.tar.xz
 434ba0796d32307e7d26e53ef97df7b97d6be0fd94951afd5eb8cfbed130bb9e 993204 
debhelper_12.6_all.deb
 c5d807e6290d85d4bf873f80a1d5f46565b43de1879e0e5e905e5a4f590c865a 5226 
debhelper_12.6_amd64.buildinfo
 21d7ee7542d2ef65058e966b4e88fecfb49cbe0d0f7de731e7ea9147ac81612c 125364 
dh-systemd_12.6_all.deb
 b8a482726ce0de74fbeb71572fa15c3ba1590d0eaaedd52eadbaa853fc13763a 171732 
libdebhelper-perl_12.6_all.deb
Files:
 4c256839937970c7e66749535b0449e3 1771 devel optional debhelper_12.6.dsc
 1b7809ea4a4f40618170430f8c68e283 501184 devel optional debhelper_12.6.tar.xz
 2bc637825e3aaf473d2620b3d9a3d0a1 993204 devel optional debhelper_12.6_all.deb
 4844c6221fdd779c4161d466a02f277b 5226 devel optional 
debhelper_12.6_amd64.buildinfo
 2703bab899267e2797b7266671b43ab9 125364 oldlibs optional 
dh-systemd_12.6_all.deb
 0f81a2308ddf1f1c40474631cf9d39eb 171732 perl optional 
libdebhelper-perl_12.6_all.deb

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl18i6ESHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqskk4QANt8jo+dRLYBGEiG6g72Ashd5ax5WEay
mat2JTJv3excYkOfjYtgsidXKmtrF+lNvIJC1lzK1VooamSwZcbWkFVgAwiqP6cp
VY9LLtITdiHI/Deoefa8RyaG+tj27YsY6f0BY2Zd7nnZreD9rfibgsQawfG+8/Uo
3W9kZLNpJjfVLlLPhrWHlEHmUBzUp0smpeUYzg5+csw7yQJyWMfUQATwr62AlL2f
3KRzl9Fbcdat7Fr6QKeiGDJWGYXlsdhuiMYl2vrkzakqp/PgrlVCf7KegpYnF2L/
V2i+PFzW6papzt2ybAXlS4vaZ6C9RuHHXiFj9agn2wJSM2/wkxeX/QfG/rgBhvAO
aQqDBrKn3kKHMFBJx6q+MmfU+Urb2a4p6y3l+XwIGWwIgtHJL+SNI8okeYQTXiTE
FgIBFFi5i2+b81U5dKBMA2zZT1pobRUO0eg8B2IVAxHrmJgqz57eVSMFWpaRoHto
h6I+ZRn9Lyl2zwBGGw+FDBheFpQw2x1q05ZQdfjdr1syL5/3oNLffoKMbm9MT4/Q
WanSYHWz2ZW4nVqxv5bXyejxEFfdFsathoKmgv89mktpZJCiQnQtY14mq4gfj0Lj
EtX8RAi0LXp57lXI5R6scuKH5et9qpDZ1ICyEPbOPd7pAGi9IHA6QX8IpQ3iQLWZ
VRMcoa6hf4/h
=jEoB
-END PGP SIGNATURE-

Accepted debhelper 12.5.4 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 01 Sep 2019 07:23:05 +
Source: debhelper
Architecture: source
Version: 12.5.4
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 935577 935780
Changes:
 debhelper (12.5.4) unstable; urgency=medium
 .
   * dh_installxfonts: Remove version in dependency on xfonts-utils
 added to ${misc:Depends}.  The version requirement has been
 satisfied for the past 3-4 releases.
   * dh_makeshlibs: Correct a control check that was only intended
 for automatic udeb detection, which incorrectly also checked
 when --add-udeb was passed.  Thanks to Andreas Metzler for
 reporting the issue.  (Closes: #935577)
   * dh: Fix bug where overrides for dh_dwz, dh_strip, dh_makeshlibs
 or dh_shlibdeps could be triggered via binary-indep in compat
 12 and earlier.  Thanks to Andreas Beckmann for reporting the
 issue.  (Closes: #935780)
Checksums-Sha1:
 65fbc2414e6d3b386b9e37dd06c80d29bc9d0e06 1714 debhelper_12.5.4.dsc
 61c1a8b635a14362171ae5f8bc900efc92a2c938 500788 debhelper_12.5.4.tar.xz
 ae7ffac5597627590bdfd6e0a1a73939165faeb2 4508 debhelper_12.5.4_source.buildinfo
Checksums-Sha256:
 94f3cd69fba7dc32803665cbce5fe2c9668b052c0beebb041d0bc42c00c53e13 1714 
debhelper_12.5.4.dsc
 6f109f78fc7b24b23caf1db56d66712b3f5a0a0964b0d16e610eeb0c1b92896b 500788 
debhelper_12.5.4.tar.xz
 30c3d7f843b74bc315eba44dacef03a4390f0e3fee4410f340dff4ac4a4cd4b7 4508 
debhelper_12.5.4_source.buildinfo
Files:
 e6703228089bdc24472744e60fe88af4 1714 devel optional debhelper_12.5.4.dsc
 8211a6b275fa0c019b02ddb5f5e0a197 500788 devel optional debhelper_12.5.4.tar.xz
 1a48de63e109cef2ab6b31b54b24606c 4508 devel optional 
debhelper_12.5.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1rd6ISHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsZl8QAMBI2vybzrHfCxQfmIaSgdzdhfGLeb8L
71NtVtDUwM6taRTKISdmEjfoYeELPImwPen0Fj30POJy8y/0ZG6e/yUj16ZQyTx4
ctLOpxK5EFKk+Dtzgb/gTfiM012V+k7j2qF88k6Qw95pvNoV1cx8aInakhZEOzO4
HK+bbQvTvCDazL3620Na34rjMUpL6tHeZMVFhtU+dpLhU2VzLli9ezADZQbwgeoO
PGa35IPFPhsPEkIXRx5JXsVFVJ6aMm56zxfpwd9iHJJrtepCA2NsvtLX2L8UVGsG
KfXCseluMr/14TLXK3xwfhPoVbS2e8vN5VszLVrAGwuSB9Rms+IksEIGkZFtf4KT
F7RCf74QyRR8bxfqnzcXkr/U5lGOUw/3uqL5VO6BDKdJ8Pr9hHjY7+5AaIVKq1CX
oj5Q3pUmEppAxtvDdlAnvP1XMHtXd+jQZtpc21N8f5UlXXoMOTdoKwnCyUKeB31v
tO6pZCUvqiB3gKOHfCgecMB3p7R1bXCFliC6DM//HT0mrvMNaHa5uwC4oRDbIW/O
rTgcffxYGVYdEFvms0vnXTWOEdG9k2ttkP8/dKo7JU/XlmPjnJAygtHvoCgf98vu
W3eFXOtn/EnkJ4ldw2a2ThIlLO0x3h1rQX7eBsPS1V07b4J0uj98em82CCMYPj0U
YjMtzCjevsb9
=7245
-END PGP SIGNATURE-

Accepted wily 0.13.41-8 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 21 Aug 2019 10:11:18 +
Source: wily
Architecture: source
Version: 0.13.41-8
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Niels Thykier 
Closes: 438263 882542
Changes:
 wily (0.13.41-8) unstable; urgency=medium
 .
   * QA upload.
   * Set Rules-Requires-Root to "no".
   * Drop calls to dh_test due to Rules-Requires-Root.
   * Replace calls to dh_clean -k with dh_prep.
   * Drop long obsolete debian/rules targets.
   * Bump debhelper compat to level 8.  No changes required.
   * Add missing ${misc:Depends} dependency to wily.
   * Remove tools/win/config.log during clean.
 .
   [ Helmut Grohne ]
   * Fix FTCBFS: (Closes: #882542)
 + Pass a cross compiler to ./configure.
 + Defer stripping to dh_strip.  (Closes: #438263)
Checksums-Sha1:
 bf350a6a9404a5fdb3750c0257a8b1c8b67a8089 1693 wily_0.13.41-8.dsc
 8d71365883a3a2a54bb943f19007b060b3c7c4ee 26194 wily_0.13.41-8.diff.gz
 2068f31b1c295464f33f8926e4f22a72ce070c1a 5773 wily_0.13.41-8_source.buildinfo
Checksums-Sha256:
 5556433528a359c74d116c78a8c7fc0af4d1e713272795cb460edce8eb46d406 1693 
wily_0.13.41-8.dsc
 9de7ee4dbdaddda31c032e5ea979f8e61cdd610ea18181e8f9729cdce7396156 26194 
wily_0.13.41-8.diff.gz
 e4b1e97ea24e4f0d024c1d48c6d2ba702927a6cd901a1e0b23cb014fa31b39fa 5773 
wily_0.13.41-8_source.buildinfo
Files:
 d80bfa13336d0433f68b5e1a7f29160c 1693 editors optional wily_0.13.41-8.dsc
 25a33f2c1aac69d6c4a88a0df3c00a61 26194 editors optional wily_0.13.41-8.diff.gz
 e05b8e147833943ef56862d348bd6652 5773 editors optional 
wily_0.13.41-8_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1dH+gSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsUAoP/3j+dSo1PPlucmpN0d/Qf4u6WqpzjzJq
b+LV7bC231uf0J5MuC3IGgpAa98fAb4gBf6axZ02ItQKKB43AUjRb9bn/rQEtjZ+
OiH86zHzXr7WDsDGbD0JrDOeHxp17cwrSlkKcyoFKeiH1RL2z3hVXKroWrfnhVTE
stDppixFPCEAWw0DnYVPrABahEFWe7YRQqpHAF6WtgDdwA0L4nUwNBsdw2ZTd1Ah
hIPVp0yRP1GM3cHdzqoFcVWRHgqipASA+08Vmsw0cnPEB2B6jB43dESAaAzOFi0t
AZ+nCngUpCb/4rJUkHfVMA/WlA0lXXMUhAlj6CNTx2ItSrjbq0b+DvZ85w6zLimw
Cfe62DrB6UYJ/dep1hJxC0bZ1I6FeoDKgAMaN5iQMQtynegiR/47ezosOaarWBV1
BwBZcWW4O+dQvupII/1z42q6o5x6kdYldtKTKDFOxTFyknHoy47iz4qgasJVDFpB
KxxGN77IL4PwhhURpDI1HlL0Y6KzWgxcZ/BhuZgc3XQOOIBh7nRdYs/fHX6FmxWI
txBCp3KczAXFzGa3kkQJi32MTPijVtfiXRgaJ7//7PtuLc179BMHyqyd60WeZTfT
kBA22C+UglJ6H7PRvrF+hoSFeKsZql6dYsYlP2SOBod046QH+xQhjcoE1/eFDuMT
NZaQ5jVxCOQh
=FK3r
-END PGP SIGNATURE-

Accepted debhelper 12.5.3 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 19 Aug 2019 09:50:19 +
Source: debhelper
Architecture: source
Version: 12.5.3
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 934999 935017
Changes:
 debhelper (12.5.3) unstable; urgency=medium
 .
   * Dh_Getopt.pm: Skip compat call if d/control cannot be found
 and just assume that auto-abbreviation can be disabled in that
 case.  This avoids breaking options such as --help and --list.
 (Closes: #935017)
   * Dh_Lib.pm: Jump to hoops to only parse the Build-Dependency
 field in dh without breaking dh's own --list or --help
 parameter.  This fixes a regression since 12.5 where dh's
 --help and --list options were broken.
   * dh_builddeb: Revert removal of --destdir for now.  It is in
 fact used to hardcode paths in some cases e.g. v4l2loopback's
 debian/rules.modules.
   * dh_makeshlibs: Disable auto-filtering of udeb libraries.  It
 cannot be implemented without violating the requirements for
 the noudeb build-profile.
   * dh_makeshlibs: Fix invalid error under the noudeb profile
 where the absence of udeb content is expected rather than an
 in issue.  (Closes: #934999)
Checksums-Sha1:
 b2c5fccf044ab3876f91e3699acf310ea80cb5e7 1714 debhelper_12.5.3.dsc
 6bb1daa9e2b9fffa358b9af203940a81cdd10860 500304 debhelper_12.5.3.tar.xz
 12e70d971597157315b7d30f56edf302c9eec2e2 4469 debhelper_12.5.3_source.buildinfo
Checksums-Sha256:
 56c601ebe8ed914ebd18b2a6d971d17e1f9274da516ad6972b65b554fee50de9 1714 
debhelper_12.5.3.dsc
 ee70aa302270f6235b9603c5707faed5ec1d19234705567c5c1cf27a690d8020 500304 
debhelper_12.5.3.tar.xz
 e529bf1b0f35bd30cf84abcb0b95afb5ba5da95bb21dc53c4b10476dd1908a50 4469 
debhelper_12.5.3_source.buildinfo
Files:
 002618d8407e205972d02d43c319d474 1714 devel optional debhelper_12.5.3.dsc
 a55915509786a375f8c00e3314af7a4b 500304 devel optional debhelper_12.5.3.tar.xz
 6bf2500e4d2ecfe82bf5ddbf0367bc14 4469 devel optional 
debhelper_12.5.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1acQYSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqs/qIP/RVCIxfx5vlB05fxyPZMITWgVMcVBvvQ
E010rJ8fRVzU6drAiDlSTl6KNwv7mE8u6fC6VivP1KkE7Kw/QWUgxloQPFkTKfSA
DZvYsLvo+I1UcYV5N39TxIzicwmWMQazzyk1lL3ZiBBRku68ArdLzJ6RdlCGBetp
qpxTgYjwSQQbA2KhQQu/AH8McZO4psFSgWAKKmALE1Ez+IN8JR4CI75/zQrqa1NR
wlT4XRzN1LMobeqoSQdYu7XL6AUUiGL/Xq8JJkKisHPtnHxwOIVViyx3N0gwqDfZ
oIgYstLUkewtK/X9HT7lDGHuJ6+0KGIe2znhSvDp117F3XMyQKjHAoc5tbxxvDKM
ifa3ZjDInNd0MVbw4g2ZdqKNp9KQ6K/gq3EYDKZsO8I1uPuHu5pYnIFExkzX8AZG
z06dwiCtEErKQvSS+UkTy/ynewKUmzUL/dMrKDhbIW8gqOWW14g86PboYY7T8KuX
/RU/hqCeVwiwvNNwdH0mBpWgzoEr19hX4Sg04VaXO8vgf09Y1PVvYlAIVanpTDIX
ZVrgmXXm73fABRw9apPCWty83eslsasfqOSAF7CnmzAnyctXsG5svDJVgc1/UMOa
2ybQqjolNKWSZyitHlNCD61HWgwEnkp9HUdK2NUFi+agai8TNWiSpNz7tCUfhxwL
jOQYEInYM2+Y
=oMzq
-END PGP SIGNATURE-

Accepted debhelper 12.5.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 18 Aug 2019 07:36:20 +
Source: debhelper
Architecture: source
Version: 12.5.2
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Changes:
 debhelper (12.5.2) unstable; urgency=medium
 .
   * dh_makeshlibs: Fix regression in compat 10 and earlier where
 dh_makeshlibs now failed on error.  This safety check was
 intended to be a compat 11 or later feature.
   * dh: Ensure addon API functions return 1 to avoid gratious
 breakage of addons due to perl's idiosyncrasy of requiring a
 truth value at the end of modules.  (See #935016)
Checksums-Sha1:
 2670f3f8c6b89963ea5dac5c31698c3dafffee0f 1714 debhelper_12.5.2.dsc
 bb7e509984e4d7d7c1ac246cc38cfe584dfc976d 499832 debhelper_12.5.2.tar.xz
 51ca2c5a67db57426218b0f98c233619602a8d29 4469 debhelper_12.5.2_source.buildinfo
Checksums-Sha256:
 a182c98a70312b27fdb5b2c9933199b2d85ee7a02636342c50163a437f1c8d19 1714 
debhelper_12.5.2.dsc
 221dd480cbb8407cec9843929af94be5c72a8af4a78b9907c1bb602a30df97b9 499832 
debhelper_12.5.2.tar.xz
 4e70ea74fb75fab1c0aacd749a0efbe5196c8590b7a78dff4d2346366b2e0f79 4469 
debhelper_12.5.2_source.buildinfo
Files:
 0214959a97681a2858a9d4c0bceed2ce 1714 devel optional debhelper_12.5.2.dsc
 65ebf215a61a85cb922fb2d9649ee63d 499832 devel optional debhelper_12.5.2.tar.xz
 1a6819d65d74c0055133289e9c8b9a7c 4469 devel optional 
debhelper_12.5.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1ZABUSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsrfMP/0nQn4xOVl2nyrTcp1tNwksUES3n4BhQ
UzXUxNEDlbKttcwNxKvD0KkAOgyk2RgF1JDqte03LeKoYEFchfu+wFiIZ6yf14ib
2FsGPAxTfMKq2C30IKOtRVL4oBR2Fu2aWAVIaueyVDi0aBwxCJlba/MHu0BQMIM3
r7enVuNnJJJ4trYm62kDT3luYHVx0ZLdceZBzUePR4t2JzevkIqf3df7BmIQjTCw
ztBDIq7SiQYlNTFmwVyxUI+X6ytNDsI+4X+WBqF/QUBMk5hQEzf0BtBEbwJw1MIR
rqFBgFxp12OJGD6dBYKfBH1ico3SnD+edXwFHejRuFphX95xb+DNDsYQ47NVvg/0
+/OrST/F/arKGsGDzIxnUbKD48GZicDnGR0dzDdz8h6YCyPk01YuhEHMHxwuzxk2
d3L0APD96hGpR5ZPtGXEToEFW0zBqe+H0zHBOxHx29AWQJLlDqawXg0PfrvXu3T2
VVOu2LTcOBFL0fAZLdQij1DT2GLhub12QvtNhAaDTj5OtG9xYOXNi6PHMVQ8Scps
0do7Mf9jqEBpEgIJBFo2M/U0+hq7jzeMgX8xgdejMtM6IJgKAh59qt6gu6BNSX39
xys8F96VeZf6eyplnnIQxZhRCO9bi8YIBvqPNZMk7StqfRAK8TkORgSOhAf+HiKn
IHdedP42jmaM
=W/pL
-END PGP SIGNATURE-

Accepted debhelper 12.5.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 17 Aug 2019 15:09:07 +
Source: debhelper
Architecture: source
Version: 12.5.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Changes:
 debhelper (12.5.1) unstable; urgency=medium
 .
   * dh_installdeb: Allow "+" to appear in token names as it is
 a valid character for package names.
   * dh_installdeb: Reject invalid token names passed to -D or
 --define (in most cases).
   * dh_makeshlibs: Fix bug in -X where it would no longer match
 as expected.  A regression since 12.5 - thanks to  Aurelien
 Jarno for reporting the issue over IRC.
Checksums-Sha1:
 a9ee4208b87bfbc9a6e9d67c8ecb0cc44a9a1537 1714 debhelper_12.5.1.dsc
 572dbf42bc45c1eacd5baeb7f1ed01079c18e0be 499660 debhelper_12.5.1.tar.xz
 b6219f5738953743f3d96805997d82472c653df1 4469 debhelper_12.5.1_source.buildinfo
Checksums-Sha256:
 4c1b2160e91642a70347c05a6df0d50fca95a4c7793d0517620261a998648992 1714 
debhelper_12.5.1.dsc
 a4a0caaedd5c47609ddab2de56ed22c312530838ffcefcf9fee377d324e56204 499660 
debhelper_12.5.1.tar.xz
 6f90c7f077ff684cb6e46a1b5ef5344d8667da22b448bccd8d555b12a746fcd2 4469 
debhelper_12.5.1_source.buildinfo
Files:
 ee3d526765332ec1296ca389f136293a 1714 devel optional debhelper_12.5.1.dsc
 31376048e6c342311418a1295844b842 499660 devel optional debhelper_12.5.1.tar.xz
 ca8ab7a21bb7c898039d5e6031f267af 4469 devel optional 
debhelper_12.5.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1YGLMSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsQo0P/1zFgxBOWItKQJnPF1sD0dhHSEg6lbNt
ELQUr/w0HDgVwOj/KcTf1TtZ7q7ZAcI4BhZiYANQw9Nn2Ht6jFohX5e9VMPrl4iv
DiTYqoYAhyCH5gKVyrIxIxNEpXeiTWHjUogLIdQmLopoLBKSMCE6xzQYkDyWFQE4
UIt8neCaa329mLFYI1wAWjeOJ04SLeLPSZTRqkcDD0wFldTE14GdRW5BzrYen2rB
p9PCUe9mefRq4B7WAGbh1uj4vfku7SWsrORUbliqCinJrG9ybDMMTPRmmlBwUBaQ
Vnog2Hgp+lw4xamnDm2MyNihjh1dxswE2yTSFQp1ucSoBDpXHCqvKC3HxxvziuUY
W8j+wRsM5zbNL6eDDqF6muc0rVJbBsn6qnJNIZvDcLwZWbcJ0J5b3PFGLg7Zat+A
4Ths6h4U6YVgxqH8TV7DUACKUvFziMzN4LsIB2b4PsJSdwdfk55/MiLEE5AXVFoz
UXAjZu6V2pG2eo2UHsu4OyvLfx4D3M62+5160wFgb9xNKa9jiadxQBmNx8Hv7Sd8
HbaY9JD9D2A4sq0jF0ifjdJ+yDQY17GK0neGRHVhne9kgPgCTVO26F/bQGqax5/A
USbPivIeXk9wryJvwkrgtYN1FlrwQ+bIMdhjhJjPuDxCKiV5E81LoqVyBB5UfVZJ
7AoJVvyXr1Nf
=IxBc
-END PGP SIGNATURE-

Accepted debhelper 12.5 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 17 Aug 2019 10:54:08 +
Source: debhelper
Architecture: source
Version: 12.5
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 836699 907061 934889 934891
Changes:
 debhelper (12.5) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * dh_strip: Skip stripping of guile-2.2 files by skipping all
 all files matching "/guile/.*\.go$".  Thanks to Jeremy Bicha
 and Rob Browning.  (Closes: #907061)
   * dh_auto_*: Officially adopt --sourcedir and --builddir as official
 parameters.  They have always worked since debhelper defaulted to
 supporting auto-abbreviated parameters, so this is simply documenting
 fait accompli for the most common abbreviation.
   * dh_*: Disable auto-abbreviation of command line parameters in compat
 13.
   * dh: Optimize out redundant helpers even when passed long options in
 compat 13.
   * dh_builddeb: Remove --destdir.  It has never been useful as everyone
 excepts the debs to be placed in "..".
   * Dh_Lib.pm: Add a hint to resolve the error caused by having the
 compat level specified both as a build-dependency and in
 debian/compat.  Thanks to Alessandro Grassi for reporting the issue
 on IRC.
   * dh_makeshlibs: Fix bug where --no-add-udeb could trigger the
 auto-detection code.  (Closes: #934891)
   * dh_makeshlibs: When using the auto-detection of udeb, automatically
 exclude "udeb:" lines for libraries omitted from the udeb.  At the
 same time, verbosely fail if the udeb contains a library not present
 in the deb (overridable with --add-udeb).  (Closes: #934889)
   * dh: Support making "dh-sequence-ADDON" Build-Depends relation
 conditional on build-profiles (etc.).  If the relation is ignored due
 to the current build-profiles (etc.), then addon is silently skipped.
   * dh: Support running addons in "arch-only" or "indep-only" mode by
 adding "dh-sequence-ADDON" in Build-Depends-Arch or
 Build-Depends-Indep (respectively).  Not all addons support this and
 will trigger an error at load time.  Addon providers should ensure
 that their package provde "dh-sequence-ADDON" and review the
 doc/PROGRAMMING document (in the debhelper source) if they are
 considering to make their addon compatible with these requirements.
 (Closes: #836699)
   * dh,elf_tools.pm: Extract the ELF related debhelper tools (dh_strip,
 dh_dwz, dh_makeshlibs, dh_shlibdeps) into their own addon called
 "elf-tools" enabled by the default.
   * debian/control: Provide dh-sequence-elf-tools.
   * dh: In compat 13, the "elf-tools" addon is considered an implicit
 "arch-only" addon (i.e. they are only available in "-arch" sequences
 and are always passed a "-a").  If you need the ELF tools for arch:all
 packages, please add an explicit Builds-Depends on dh-sequence-elf-tools.
 .
   [ Frank Schaefer ]
   * dh_installmodules: Also look for compressed kernel modules
 in addition to uncompressed kernel modules (gz, bz2 or xz).
 .
   [ Adam Borowski ]
   * d/s/lintian-overrides: Override lintian warning about debhelper
 not using debhelper.
Checksums-Sha1:
 1e788d83f228b1e6036fa8bdeb14a67ddb93a900 1706 debhelper_12.5.dsc
 9f5bf39bd8168c95f7c1a465eb8b693d4403e2e0 499340 debhelper_12.5.tar.xz
 adc5df29c6da442085b72a4c9fefaa79a7fac59a 4461 debhelper_12.5_source.buildinfo
Checksums-Sha256:
 ff33e48bbed7871b330285a1f60236be970a91619f6f78d63a1b46154b808f0b 1706 
debhelper_12.5.dsc
 ec7570ce1b1cd7007403505babcf9b66710231bdf35a0348dc69a8aa41f6d765 499340 
debhelper_12.5.tar.xz
 37fec0d2b47221838beee963210ab80f6cd9520a5d3e0a9a3be82f05dafdf96f 4461 
debhelper_12.5_source.buildinfo
Files:
 8ff4d3018b8b5a6c9f5718e6d10a079d 1706 devel optional debhelper_12.5.dsc
 fcd0ff36ded195fd362868d4679064af 499340 devel optional debhelper_12.5.tar.xz
 0a2289652f3c046b45c7d00d3d5e8a19 4461 devel optional 
debhelper_12.5_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1X3QUSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqs1U8P/2lxs27cVkdG/RM4xvJU2igi3InkgbLa
E6zWikIFBteEnwZzem67/nn0qq+XbRgJrL7wmS7ucGI+kvrBm/naHldqp258BJ8o
0P40LmBZKi1pneoBNbpi6A+ZzYr68L1smgIH1fiTXKF9hkrffXd9DqO/FEYmv1VH
hNaQzp6j1SHIqYVmzo/jUoqaJs0MyuhPbvlMAIUyaxemsc+/DkEEPU6AKCpkzZzH
YkZn/XSYolDmC/x/MsIRow/9TELfu81OastHZo0fpy1cN1iLIySGXjWUsMhtEBXf
6mvuLPzFWb0qCcP2vuZtqjSdPeSSQs86KuKUeYVJ6GQHT80lF/y9UnF2MgNEaGIF
8N7imUmwSOecmUXTIbVaSennCo0koHLR+JBK5+omhpkV41hb93bkBRga/jQqOdLz
mm/Bf7xNZ64KcHtZsD9KJ0L3rOQhgwCuO8wNggUAXOAOZZs7iIDwnJdnI/2jHYz/
QoncG0fRSLK7C17L7W0bSmJiPrNcJbktvo8NUc6IRfjv/bxtUVdH4muCePlkHkwE
l5Nqx7RoJXihyrTXacQlR3LAGLLVHWPo7S1SNsyo0oAV2+EBy2ijfOH8UcKdr5kY
E6iQCNhJa3YDjwupiaEJUzGMjaDj+I19vHNkNjAaCoqtOQOseSPYLb+UVhwQfnl4
mOvl9dz8Tm2b
=QBQM
-END PGP SIGNATURE-

Accepted debhelper 12.4 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 12 Aug 2019 15:07:01 +
Source: debhelper
Architecture: source
Version: 12.4
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 932537
Changes:
 debhelper (12.4) unstable; urgency=medium
 .
   * dh: Retroactively remove support for manual dh sequence
 operators (--until, --after, --before and --remaining).
 This breaks about 8 source packages that still rely on this
 feature and have not yet migrated away.  (Closes: #932537)
 Please see the debhelper bug for relevant bug numbers and
 package names.
Checksums-Sha1:
 86f126da010884eb38ca604050f4c20447abe53a 1681 debhelper_12.4.dsc
 0946b5a1f6c3af3cc37b88ee358180c52e61ded8 493916 debhelper_12.4.tar.xz
 62b096e7fd5be2b0ab3965a67fa81b2612add615 4502 debhelper_12.4_source.buildinfo
Checksums-Sha256:
 32f8d7e36869404bdd42cdfdcdcc0d7003ecc3e620f3ea91bf9f6712b8c5677e 1681 
debhelper_12.4.dsc
 7049b262baff5decef90cdbdb21cf530bcde2562122534a2410cd104377f1505 493916 
debhelper_12.4.tar.xz
 654e6e55e0a39074a8cf5c8a3291b1feed9d48e5fe3c229df7d1347e2479f9ab 4502 
debhelper_12.4_source.buildinfo
Files:
 643c31b47d00349487b2d490f79ff3a1 1681 devel optional debhelper_12.4.dsc
 1983730a25064af76983a964bb74027a 493916 devel optional debhelper_12.4.tar.xz
 20c7a878afce6a4bebfcc6ac5fc82f2b 4502 devel optional 
debhelper_12.4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1Rgb0ACgkQplt42+Z8
eqxU7g/+OzNTa4KKTQr2tpKBDEhYIZHBaGYv12RlVl4dQDjUGJAaStXC+dqPI/rG
4I9S3tG+eytDbptAlrR1l5hOVKcaCo/+sJyuZ6xyGcF3YK8+kvTIVhhG7Seqj95V
dwidL69Cm/3JlNz0Hi33xm2mnFAMmL/7AuNpRDEvvR+pSZGa8WThUnH/F6pHH53g
JGfN5GtvSVdWIuvVh4r8tGwDFC78IoscgKrC3LkAcHM39OfsiSN6sGRy1G9vHETJ
qcpGpTqJR9LPfE6nsV1819W6XsRQxVJGuxsuKkc/mc2aLaZpqbdqwuUIT5MQBlC6
o8SBjcRVpH8V8WUzOVdyJFPwetofTJr0zB5ZzOF/bNjYQL7/eroTNWgFItLvE1L/
BjSJKmtEuZjteWQTp9aUJnT+/HY01KZaedSFqNvD0RTUW8FjJb7P1kf+/uWXKbmD
I+4JJazeKorMEDbdt0nUVOXGX7wFhku3rZiogb+6UKAilTL317cS8FpbQ0Nwlyl1
qrxRZM7i7Uc+IlHbw/qGlc/r+fAgRf51si2HQdrl8qUT9EuxaeFSuGwBEN0qV/jX
zli4PjJU7h6dymbiVqP+comkUQyXag8c0Q455vHn76tx7xzv1yOrjvuj9mTCx1qC
SCznNzUKVA8RFMYaIjUmY5ivQr0hOfvmfMSMrjNiMmaKkCFWbLg=
=WwPg
-END PGP SIGNATURE-

Accepted debhelper 12.3 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 06 Aug 2019 16:55:26 +
Source: debhelper
Architecture: source
Version: 12.3
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 927394 931792 932646 933212 933541 933561
Changes:
 debhelper (12.3) unstable; urgency=medium
 .
   [ Translations ]
   * Update Portuguese translation (Américo Monteiro)  (Closes: #927394)
 .
   [ Niels Thykier ]
   * dh_installsystemduser: Fix bug that would neuter sorting of unit
 files and make the resulting maintscripts unreproducible.  Thanks
 to Daniel Kahn Gillmor for reporting the bug.  (Closes: #932646)
   * dh_dwz: Remove the -q flag when calling dwz(1).  It is
 sufficiently silently with -q and aids with debugging for others.
 (Closes: #933561, #931792)
   * dh_dwz: Gracefully handle when dwz fails to create a multifile
 but succeeds anyway by default.  The previous behaviour of
 insisting on a multifile can be obtained by explicitly passing
 --dwz-multifile.  (Closes: #933541)
   * dh_dwz: Skip multifile generation for udeb packages.
 (Closes: #933212)
   * dh_makeshlibs: Attempt to automatically detect udeb packages
 for a given (non-udeb) library package.  In simple cases, it
 can replace the need for an explicit --add-udeb parameter.
 However, there are many cases where the auto-detection falls
 short and --add-udeb is still needed (see dh_makeshlibs(1)
 for details).  Packagers are advised to verify the resulting
 shlibs file before removing --add-udeb in an upload.
Checksums-Sha1:
 45be4db697d30856c7564d64496bebd53f1c6cdf 1681 debhelper_12.3.dsc
 8fb3973c20114f8e7ad4c8bf21ed958859a1935b 493796 debhelper_12.3.tar.xz
 b6cf30fcdec31c20edecc4675fc302eb6f6ea2ea 4565 debhelper_12.3_source.buildinfo
Checksums-Sha256:
 cdbf4cbb701a43c75e73e1514b0fb32eeaa09ae8e0777616b4ab12c98c193804 1681 
debhelper_12.3.dsc
 c9b016603580d5b9c87e26f841555e79e97f3b0045823de4608b937f90fb556d 493796 
debhelper_12.3.tar.xz
 1b19597e6f5afe5c06966467d8b1eb7de8c1b46ebb36896ada2029f524593266 4565 
debhelper_12.3_source.buildinfo
Files:
 c07c3e55a77ac30830a94e28ea138187 1681 devel optional debhelper_12.3.dsc
 8ed1d5c061f531bbf95122f8f521eaf8 493796 devel optional debhelper_12.3.tar.xz
 288fdc90e5272089180d290bacc1d2ed 4565 devel optional 
debhelper_12.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl1Js/QACgkQplt42+Z8
eqzkwg/8CR5QbE8B5cqsf7ZRRB0PbujAIwsINm/jRoYn/1y4F7h4TEEBoGOIE9KY
XVpzrLl3mNmkBmUp+SmH1ehsRCrt76y1cHQblMHsISoxLinIOhT5c46mkfYPBJ7z
9+gLIS2XTOwkyzpwYWqPFymiKEVED/vh+dtatql84cwsuAFLzs8lzo8RMrZFitGu
z+W08ccPFoXH0wcey6Ay7V4jk4LB0EuFFxrtCORttDqU54apTW8MPqYgq3X+Fa66
Z802NIvZ0yE6pSu7Fs8dj09apmD/hW601Kx+7hEBIHjSqhEhfLYzbD0boDc2JLy8
tBR2wcd/QRPpgBi02e7eYhe5tI1Xu5JIdXWyouw0K6ieJpeJmM9uP4d6Uo9TbkeR
T3/ofni41YrumxfdyXC002tQbOMyiNkESd3bqbirq1A6pUpwgOFjazKUoJ4cBwVr
9274Rowo6yhMsD1wbdeorkcEkNanaevLpAlh5EAmYE2n9HqNQZJjVIJ37XCShYto
QKxQV3EDfKkcVubSkAoS4ZdSCGO9iW7dLTqB0AFSKlm/+cH+Dr4UFgWaiTK6AvMW
A1N07cpKEaRfUBHYvWjP5l7xGxo+EzcOcPBo8XIq70WeOwL/UqL7WcEjKyyc0KoR
cU/u8aKF2ofK9UfhbVHqxAIk6JSz3tSQM0ajPUg2vVgof5xrGNY=
=jBsm
-END PGP SIGNATURE-

Accepted debhelper 12.2.3 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 19 Jul 2019 19:18:03 +
Source: debhelper
Architecture: source
Version: 12.2.3
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 932073 932262
Changes:
 debhelper (12.2.3) unstable; urgency=medium
 .
   * dh_installinit: Revert "Fail with an error if --name is given but
 there is no matching init script.".  (Closes: #932073,
 Reopens: #462389)
   * Dh_Getopt.pm: Produce a better error message when -p is
 ignored in an architecture constrained override (e.g. during an
 architecture specific build and the -p argument refers to an
 arch:all package).  Thanks to Helmut Grohne for reporting the
 issue.  (Closes: #932262)
Checksums-Sha1:
 902ec533af0cb42ba595b2b32000495bfdf9787d 1714 debhelper_12.2.3.dsc
 456a7fc7cb7ca584c666170c1410c50d55870e53 492468 debhelper_12.2.3.tar.xz
 d4553001881abddaf52a4a0c3e11b1a5515c4ef8 4535 debhelper_12.2.3_source.buildinfo
Checksums-Sha256:
 a35d8d45097478325976207d2ba71d85bacc3d289f01d1880f7b695f5ba916f1 1714 
debhelper_12.2.3.dsc
 4c279d7ad09b843ca29e45d5134197e700814c95e46f5c45673790d77be6eaa1 492468 
debhelper_12.2.3.tar.xz
 deaab4cd92b7875da85443f4302ce2897795d3f60785aabca0ae08cbdd74de25 4535 
debhelper_12.2.3_source.buildinfo
Files:
 691147822125c3c57bfc7508c77a8d72 1714 devel optional debhelper_12.2.3.dsc
 64a18f45afe1f621cd6fb5a01bb9c89e 492468 devel optional debhelper_12.2.3.tar.xz
 8b0bf295be5fbda023e92807ef7e3f1e 4535 devel optional 
debhelper_12.2.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl0yGWQSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqs8WwP/3DKbtjsE0c4zDpCC6p6XGivW2A1BgLe
Wa25UIukPr2g8TSj3eBI0077ZkNFNnhOWYt6OnOvUOsygqXc6qaxkfRRM5o3MMU+
m9A/I90XEgaN7/Pjr9Z41/SFP8VWYuu6qKirZqy73tUq30tmXOnidmaL3G83R+oD
DULjfSC8RlyMQXIlo+OS7XCPAt2O/uV84ds6A6oA/c7tIjGVVQUy6MoITulv7eEm
X6sUXA//4WSbnxU7nS1UdJQ21EL8ifRAIVcpSPuk0LbuwCy1Ea23uHtZXKVqLcDG
KOCGVr+vJW52eizaWIQa47MAybA8Yd6pKBwN9pOMatdhzev4ChPbY7kVBLwThHdE
tXOX6E9rWo4lvdBKlXDLuHgQlsNOYM+DbOX8KTZO394xdWikQk7Lf3rBFPmvyyHy
KK5mmYkZ1OUDtZpOBWrMmfFUwZcnUDaq9CLu2lbytqt/Hd1P44w+QK+DKQsza6Us
QzYw3EIbCk1c1vNQqgpnCsZ/IWim4FfuFrbqV9ErROy2gbeUJ8RNiNj5NgJkUxmT
+cD3wOWFSFXUFxAl/qRuc689SPsduQhIz3TKGynvMOug7SSc4wn1mlQjshs0Dvug
Xbc8cAzasvX9fK3i+EO75YD3iJYjJCtuhxhFiDBahAsEqGc6gGoKm2QnVj55lLUM
2UbUCBmNFAfK
=DW+C
-END PGP SIGNATURE-

Accepted debhelper 12.2.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 16 Jul 2019 21:03:38 +
Source: debhelper
Architecture: source
Version: 12.2.2
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 932240
Changes:
 debhelper (12.2.2) unstable; urgency=medium
 .
   * dh_shlibdeps: Remove regex anchor when parsing file(1) to aovid
 regressions with setuid/setgid binaries.  Thanks to James
 Cowgill for reporting the issue.  (Closes: #932240)
   * dh_strip: Ditto.
Checksums-Sha1:
 e875ec786defcb13aea25dbad68181c8854e22c7 1714 debhelper_12.2.2.dsc
 4aa7abde5087e7e6c2081150358dea94489bc120 492284 debhelper_12.2.2.tar.xz
 223c3ff5e66f731440720e410338912c426c8943 4516 debhelper_12.2.2_source.buildinfo
Checksums-Sha256:
 be45943a2600dad23fa7c4a66879ccf0f1521521fb4162da68559eb2f20c3a05 1714 
debhelper_12.2.2.dsc
 a204262849c8c98411214ff58f132b3c3525d46e08f500ec4d44bce8ba23e0cd 492284 
debhelper_12.2.2.tar.xz
 6716a1fad0858d6902d03bc5560180c0174fe82ff6ead5c13f22a3c178344df2 4516 
debhelper_12.2.2_source.buildinfo
Files:
 743ce8959dec3ed849fe353a2a4a7135 1714 devel optional debhelper_12.2.2.dsc
 2538e578d178a9ff112bf88be5cf885c 492284 devel optional debhelper_12.2.2.tar.xz
 d9cbd22382659c264e3bb9b20f6cc6b0 4516 devel optional 
debhelper_12.2.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl0uO98SHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsQb4P/05nQ92DsuLKlMJaWTTJtJEIMDu2o4vz
4j4Bkh3G43az7REzxdCPFTBz8i7VfHuWud6/9vOrtjyD+uCLXAvq1y5Z1AkzvTvV
CUBQy56Ixy9TwcP73dV40IwxGfCs5Kszc1MtMnGyjcABzsS4OCQVAwlV4flpLsZe
mREi308mkNJUG2017A0WN2cEKJLIB5T2LfFZkwdwQVNKh/qvwgFrXzE3ePrt+d6R
rpfLaFb4FR0PoN7X2KCaXKIwrLTwNie7ksbnUn12QOXfL4HAgnkgzGkohVolhWSR
8ilFGAuHG/prr+qDwIUDSLoNpXnhdCsM9JoF0qNQMYPtHe7hsj/pFpNBtJUsvv1u
QRSySpIVI3UwyQG7Vgii4jTm5j8U07fPwcP+YNX4D8q4OaiHE/dlecHzSXbHbBsf
V0bDxZONkxf3+jRquZUZskaF08SrpgZpN3VqjXgfhxnudNLNUn4kNfR6B7yRIuer
z740tZIJ/L805pcaEj3gcLdTPm/FbPy+/U9UwzGUGVUe22JYinFJRFsjv9RE1hsq
CDlk6ZylwpC4p7xlXB6CBs+8R9iRP42vkCgPGxn9C2t6S3awvIC0zmoNvn4aWCsc
yFYw3WmlZXdxygS/Yb5iYzdfaoSkYQy9NrhR4va2Z9Oiw6FeSPk8N3Go7rc5kfmj
OjnhLSUZx6sD
=bU7Z
-END PGP SIGNATURE-

Accepted debhelper 12.2.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 16 Jul 2019 20:21:32 +
Source: debhelper
Architecture: source
Version: 12.2.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 932073
Changes:
 debhelper (12.2.1) unstable; urgency=medium
 .
   [ Dmitry Bogatov ]
   * dh_installinit: Fix regression where dh_installinit bailed
 out on --name if only one of the acted on packages had an
 init script file.  Thanks to Helmut Grohne for reporting
 the issue.  (Closes: #932073)
Checksums-Sha1:
 5f0c27fa37dfe31901f610c025e04ab78d96e7f6 1714 debhelper_12.2.1.dsc
 a7f65af2406827ed11db012d12087bc1d4301f6c 492196 debhelper_12.2.1.tar.xz
 23105c8c5d1e7ad154a9e7405b262ab87b91be62 4516 debhelper_12.2.1_source.buildinfo
Checksums-Sha256:
 2774ef4e1ca9e41972a1d738858db6d807215fdd77dfe6d9217ad9e7b938f960 1714 
debhelper_12.2.1.dsc
 3a78727908547a66b1bb179963fcb2a9692c1cdb480d3d31497f4abdf81351d4 492196 
debhelper_12.2.1.tar.xz
 894c144e4c6c1931bcc8c1e14a93f0500f9dce105528bd3423d92eb1b9276ceb 4516 
debhelper_12.2.1_source.buildinfo
Files:
 ff89d00df6d62dfba9585551b303d186 1714 devel optional debhelper_12.2.1.dsc
 b35ba701cb3e6af50bf333586a60ed16 492196 devel optional debhelper_12.2.1.tar.xz
 eadfad79aa16e7bcf173d15d1743cedd 4516 devel optional 
debhelper_12.2.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl0uMiQSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsRH8P/A+4Elukac/FkwqZX+OK0mfIlxnEKaYq
sRiK0D3B3f17UIzPNn6AYPKnIVaVc/hVqcrD77X11bsHOjhDvjt7gsMRFn0AgMWe
KG+nVSGb/yYuVBzloZD9rz5NbgrogMihOlJw1KnplvuUNhQdUr8vWVq2Qq4rOAAT
6uoPaj7HGisJIhFD/BPHmIW6ZLSf407kUmsHaoKT0oaYnIapDBnGE0bcFp9fRuqJ
c1fzk1cf8n0mjxdbn2XDVSK0Kcjc+T87+I4vZFO3Od3qfwhqL9LNeUEyF7c3sKK/
f7O7sqwFQYkEKPsIbT+GM+vVO/hYszoMaZTalIjtR8GSQFrj86qsmtNJk2q9fCFV
zJmQnlnmmXyqfgvEqpvoiK9Z3o88pYVL2TZkh+ebovyNsZDljZxrwaRsQG34qNvq
qiPU4CiJQ9wFJGWxBd8VdksGV5F43Xgp9/mPTOOZr4OkDp8SKLguN8nHv4VaxlvI
qIYKW1MUi9JYNOiH5KJsgNqpGMf1Sh1qtsST8F4mtpI+DUZniV9lq1C4bSrfOfWS
wBQmcgoogDo2PxjZSfkMBe0J9CEvxnIyXUdV789GRUz6+4jOZmjdSJcGobhIxr0G
APm7PKTYD0bAWjKZSDNdX/i6nFVDn9U8IRvCuXVPUovNN8R8ombTY7GryTjhHEr9
SfZ+ewjCvVBt
=JfDF
-END PGP SIGNATURE-

Accepted docbook-xml 4.5-9 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 14 Jul 2019 12:37:11 +
Source: docbook-xml
Architecture: source
Version: 4.5-9
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Niels Thykier 
Changes:
 docbook-xml (4.5-9) unstable; urgency=medium
 .
   * QA upload.
   * Set Rules-Requires-Root to no.
   * Rewrite rules file to use dh.
   * Bump debhelper compat to 12.  Only difference is the order of
 two (non-conflicting) maintainer script snippets.
   * Remove obsolete lintian-overrides file.
Checksums-Sha1:
 f565d565db5a7479bef5dc7f0b40d512a828aa80 1937 docbook-xml_4.5-9.dsc
 9146a4ccd0cce37ef6b243db38ecc78973710e9e 19700 docbook-xml_4.5-9.debian.tar.xz
 7012022f7b6c02f73f32248891ca4f4eb51b1181 5236 
docbook-xml_4.5-9_source.buildinfo
Checksums-Sha256:
 426e3abfb26d9e4a0ebddf3d786423b6c60d2b195a0811ba4ed0fb78e760 1937 
docbook-xml_4.5-9.dsc
 8ebfd7ba1849b637d69d7701c77565e3f31c2d94ae8eca6d9c4d39ba0db710f2 19700 
docbook-xml_4.5-9.debian.tar.xz
 a26f82024683704213d8375bd51f1bebb1963111e15d0c4ffdebd7233e17a13e 5236 
docbook-xml_4.5-9_source.buildinfo
Files:
 0641a1aef96b2e7bba95c44ff2e0bb1c 1937 text optional docbook-xml_4.5-9.dsc
 96b1b73b3bbfb2c89900d8846dea1122 19700 text optional 
docbook-xml_4.5-9.debian.tar.xz
 4dd8279ed75b4bf2cebe989a8a7bcc0b 5236 text optional 
docbook-xml_4.5-9_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl0rIhkSHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsrCAQALLH6lrh7lbXQJSrb3hgJLt6IbOv4tF3
ObSb1TWl98OsthxXINPcvR6Az/uW0cpzK3cXsj/tawK4nhtNvtCCRpO789g/XKDI
yuMc076BY8PZqBE7LiZmY/lQ8kmfZ5FGkdDDqhnwbiRjiTzm2Y1rtj7rIeoHMJds
p4pwgsXxy6z3EzLUikgCos17mO02ME9UEvI+R4j5cekCLeivfKoqOPWPeK9LFVLR
jRbaBntGldNBKhtUB41gXSIybwQy7I1gxseYeOWXneB2JvPkuD7y4GB4cTmGGyr8
IAS5sH2Ot+H94VJtPPfI1TEiApo553SEtynP3+atJTODUi+Asuo5U86ztYIZmK34
x/4P8NWGxFi90CjKr/SKAFTRF6fXNkfIJRq83Qir0FBNd9HtXChEuHYJ1KF1oWoh
4MJGkc2PiFjaD/S+DaGtzEkZWB2MFx4NHzvCnkP/wJGviiZMhbJidGDo4BFaf6IW
Q2apv4TKJ0pTy4J1mvYpYIEA3+B1x01LjdLUtAL4FZRwPcU9P6KHIYCd/jz0Da3/
uMrdmkREGlpYQ+n/PUL4PiqnMzydQQcAcHJ655gsm0zs50ibY46GC1koWcCM8vHC
XyxqOr99fu1Qq96IKHNdGGsKs+16npzgf/nuwqz6MQ1ygYpfB8K97k4Rcsbbga59
Dz38UkmqkWaU
=N3+l
-END PGP SIGNATURE-

Accepted debhelper 12.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 14 Jul 2019 10:29:20 +
Source: debhelper
Architecture: source
Version: 12.2
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 25235 462389 886279 912999 923626 925175 925281 926815 930689 931995 
931996 932006
Changes:
 debhelper (12.2) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * Dh_Lib: Ensure the error function always triggers the same
 exit code on termination.  Previously, it depended on the
 value of the last error (if any).
   * Buildsystem/make: Fix regression where cross-flags were
 passed in a non-cross build.  (Closes: #925175)
   * dh_perl: Fix code to prune (skip) /usr/share/doc which
 never worked.
   * doc/PROGRAMMING: Document that the environment variable
 DH_AUTOSCRIPTDIR can be used for testing purposes to
 shadow existing or test new autoscript snippets.  Thanks
 to Dmitry Bogatov for the suggestion.  (Closes: #925281)
   * dh_compress: Exclude .haddock and .hs files (as this is
 customary for haskell packages).
   * dh_installinfo: Update NOOP PROMISE to account for
 dh_missing's needs.  Thanks to Daniel Kahn Gillmor for
 reporting the issue.  (Closes: #930689)
   * debhelper.pod: Document that debhelper will use
 dpkg-buildflags for setting CFLAGS et al and that it is
 recommended to rely on dpkg-buildflags's features for
 extending the default.  (Closes: #923626)
   * dh_strip: Make dh_strip more robust with issues from
 file(1).  Thanks to Christoph Biedl for reporting the
 issue.  (Closes: #931995)
   * dh_shlibdeps: Pass --brief to file(1) and anchor the
 output parsing regex to avoid false-positive
 misdetections.  Thanks to Christoph Biedl for the
 suggestion.  (Closes: #931996)
   * dh_strip: Ditto.
   * dh_installman: Improve documentation to be more clear
 about exactly which new features dh_installman got in
 compat 11.  Thanks to Laurent Bigonville for pointing
 out the issue.  (Closes: #912999)
   * dh_strip: Pass --no-sandbox to file(1) when run under
 fakeroot and file(1) appear to support the option.
 Thanks to Christoph Biedl for requesting the feature.
 (Closes: #932006)
   * Dh_Lib.pm: Support substituting additional variables
 into the generated maintainer scripts.  These include
 DEB_(BUILD|HOST|TARGET)_* and ENV.* which point to the
 variables from dpkg-architecture(1) and variables from
 the environment (respectively).
   * dh_installdeb: Support additional substitution variables
 on the commandline via -DTOKEN=VALUE to replace #TOKEN#
 with VALUE.  (Closes: #25235)
   * d/control: Bump Standards-Version to 4.4.0 - no changes
 required.
 .
   [ Helmut Grohne ]
   * Buildsystem/cmake: Fix CMAKE_SYSTEM_PROCESSOR for mips64el.
 (Closes: #926815)
 .
   [ Dmitry Bogatov ]
   * dh_installinit: Fail with an error if --name is given but
 there is no matching init script.  Thanks to A Mennucc
 for reporting the issue.  (Closes: #462389)
 .
   [ Translations ]
   * Update Portuguese translation (Américo Monteiro)  (Closes: #886279)
Checksums-Sha1:
 2c66ffce40a1bf0c6fcc8f7b9922807e673cc05c 1681 debhelper_12.2.dsc
 ac4282388b28c4c05aa7f61c1f194e5d354b8d4c 492180 debhelper_12.2.tar.xz
 47ed401f1bc0593f993498180a6fb9861694e234 4490 debhelper_12.2_source.buildinfo
Checksums-Sha256:
 b6d1d682fa91738b1d9b90365bd75458b735b06984334d68c2c3f2fa0765792d 1681 
debhelper_12.2.dsc
 914b2dd897dfcbe364a2a56f925e6c835a49c94482bf56859abc87ca881e76b5 492180 
debhelper_12.2.tar.xz
 6aced103bae96218b7561f17d692f4861d541b500139557fccb683ac2a24f9fe 4490 
debhelper_12.2_source.buildinfo
Files:
 5a18ded6e6ce7b52e065517512a70690 1681 devel optional debhelper_12.2.dsc
 41b1000262101b8ab00d4d386fbdb182 492180 devel optional debhelper_12.2.tar.xz
 7b6bb771ea98082bc971dbc58c0d35de 4490 devel optional 
debhelper_12.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl0rBBoACgkQplt42+Z8
eqysbw//dFCXm6o5mNxBMNi02SgC0CCOMYV3dAnQlDKfBnc8HTM6/+7kxZGqMn7R
ghMP7oD1s5OS2CX95GFfQ1jNtlsgNsLN7cIEg+dPNO8wcg2SdbN67A1tW1FSsguF
7peQyGkV7g91u9vmMjFgyW8iDmcIVhENuMrsxnqDJUuPV/X64ecgqFPf9N4cKUfW
wf5a3XrGL7tUBMe6O4O140xTpTtKtW4p085h7jRGQBkewfOjL2GeDUqFZ2vE2EWc
dcD+yedXJXzcVdxEobZjldQou4HQINIeFAAK/yuLKY+6HSqB/CYuNywfvaHGs887
T+0eTCBys8YtpspTx3zVKCxgV9AznGMwUoj/DzVMY4yr4gX/islHzqdtj3Cu+pVX
JwAAJiWYSqIKUDTiPYDdpN4YI5GTvJWHX+iZj3YIXqD68MJ3QI8YNN9LKPm75hG5
kNYNrVroNt5x0mhz0X1prB+VhncGEfyyC/wr78xuUOmh2hjtyWWfdIRRH7yC/s4X
HoSTh1k/8BYjfCzV0d3g+ZxB8N4utRyFyV/gFjH3RnA9h4MlBON2K6Muy6C1i+eR
j6axMeEB0gzsGgFHcXWQmRONT+xQLhA/37vrES/9m7VmWRU7RITGfjIf61Hp/z/9
B3XWUufWDBfCii2zZtCDM8U/5cqGnDGIZSdj/AQsQFBWgVQyKdQ=
=3b1e
-END PGP SIGNATURE-

Re: Is it the job of Lintian to push an agenda?

[Niels Thykier]

Russ Allbery:
>> Thanks to this new Lintian tag, the current situation is that packages
>> won't pass NEW without a SysV init script (unless a FTP-masters ignore
>> this specific tag despite its severity).
> I haven't worked on Lintian in several years, so perhaps my information is
> stale, but at least previously ftp-master rejects were not based on
> severity, but rather on a hard-coded list of tags maintained by
> ftp-master.

For reference, Russ is correct.  For the people curious about the
concrete tags, please see [1].

Thanks,
~Niels

[1] https://ftp-master.debian.org/#lintianrejects

Could we generate d/control instead of working with "assembly level code" directly (was: Re: The noudeb build profile and dh-only rules files)

[Niels Thykier]

Simon McVittie:
> On Mon, 08 Jul 2019 at 19:23:39 +0100, Colin Watson wrote:
> [...]
>> If the udeb stanzas in debian/control have "Build-Profiles: ",
>> then debhelper will honour that when deciding which packages to build,
>> so yes, anything built into debhelper should just work.
> 
> Treating udebs as implicitly having Build-Profiles:  might be a
> reasonable feature request for debhelper, but I don't think it implements
> that right now. Like everything else in udebs, it might be too niche to
> be considered a worthwhile investment of effort.
> 
> [...]
I have been tempted to do something like this but have decided against
it.  The debhelper tools are not the only tools reading d/control, so
there is a limit to how many packaging papercuts we can work around in
debhelper (e.g. see the "related" issue for Rules-Requires-Root in
#884999).  This one "just might work with a bit of abuse", but the next
one will probably fall flat on its face (or, indeed, the previous
request did).


Instead, I have been toying with the idea of treating d/control as
something we generate. While not entirely novel in itself, once you
start generating d/control, you can do interesting rewrites such as:


Input file (fiction):
"""
Source: foo
...

Package: new-package


Package: old-package
Replaced-By: new-package (= 1.0)

Package: new-udeb
Package-Type: udeb
"""


Generated output:
"""
Source: foo
...

Package: new-package

Breaks: old-package (<< 1.0~)
Replaces: old-package (<< 1.0~)

Package: old-package
Priority: optional
Section: oldlibs
Architecture: all
Depends: new-package (>= 1.0~)
Description: transitional package - replaced by new-package
This package is for transitional purposes and can safely be removed.

Package: new-udeb
Package-Type: udeb
Build-Profiles: 
Section: debian-installer
Priority: optional

"""


It is not perfect for packages that uses dpkg-control/dh_control with -v
to set a "per-binary" version, but I still think it would be a great
reduction in cognitive burden for the maintainer to work with a
d/control that is on a higher level than "assembly".

Unfortunately, the whole act of generating d/control introduces its own
set of papercuts/learning curve as most tools need a d/control or a .dsc
(which itself needs a d/control).

The alternative would be to have *all* tools working on d/control have a
shared interface on deciding the defaults.  But that becomes a mess as
because we probably have thousands of places to update in/around the
Debian infrastructure alone.


Comparison with debdry (which I assume someone would bring up in
response): debdry had the goal of relying on tools to generate the
d/control along with most other packaging files (e.g. d/rules rewriting
would also be in scope).  Most of its changes to the d/control syntax
revolved around merging manual changes with the automatic ones.  The
rewrites I propose above and debdry's approach can be combined/composed
(including by adding this feature directly to debdry and have it be the
reference implementation for these rewrites)

Thanks,
~Niels

Re: dh_systemd_enable and instances of unit-file templates

[Niels Thykier]

Andrej Shadura:
> Hi,
> 
> On Sat, 6 Jul 2019 at 20:02, Konrad, Martin  wrote:
>> I'm packaging a logging service for buster. Users typically only need to
>> run one instance but power users might want to run multiple instances.
>> This sounds like a perfect use case for systemd templates [1] to me.
>> However, I'm struggling to get my package to install + enable + start a
>> default instance (ioclogserver@default.service) of a service template
>> (ioclogserver@.service).
> 
> <...>
> 
>> I tried to encourage dh_systemd_enable to enable my template automatically:
> 
> dh_systemd_enable has been deprecated,
> dh_installsystemd/dh_installsystemduser need to be used instead.
> 

FYI dh_installsystemd does *not* handle templated unit files either (see
#889635).

I do not remember if dh_installsystemduser does off-hand and I did not
check.

Thanks,
~Niels

Re: Debian, so ugly and unwieldy!

[Niels Thykier]

Thomas Goirand:
> On 6/10/19 8:46 AM, Niels Thykier wrote:
>> However, at no point in this, can I understand how highlighting disdain
>> for certain people (or what their "title") would help with anything in
>> this endeavour (or any other cause for that matter).  From my PoV, it
>> just seems needlessly unprofessional and hostile towards others - plus
>> now we get to spent time dissecting that rather than focusing on what
>> you wanted to change.
> 
> In general, IMO we're on a trend of too much policing. This sub-thread
> is a good example of what I'd like not to happen.
> 
> Adam explained why he hated the "UX designers", explaining what he
> disliked in their creations. I don't think the goal was to be "hostile
> towards others" but rather "hostile towards a style of design".
> Therefore, I'm very much fine with what he wrote.
> 
> Please get past the words he used to get his real meaning: I found the
> way he expressed it very powerful. It made me understand why I so much
> hate the Material design trend, which I didn't get until I read these lines.
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 


If the initial mail had focused on "Material design" as its object of
concern rather than "UX designers" then:

 * It would still have help you understand your concerns about Material
   design.
   - I note that your hate is about Material design and not UX people.
 This distinction makes a huge difference for me.

 * It would not have alienated every UX designer in the world including
   those that use other principles than "Material design".

 * It would have reduced or avoided this sub-thread, which would have
   lead to considerable better focus of our energies and less wasted
   time discussing its content.
   - While I do not personally understand the need for using "I hate X",
 the use of "I also hate with a passion Material design" in itself
 would not have triggered a mail from me.

If we do not agree on the above, then consider this a "agree to
disagree" remark from me (to save a round trip costing time from every
subscriber on d-d).

Thanks,
~Niels

Re: Debian, so ugly and unwieldy!

[Niels Thykier]

Adam Borowski:
> On Sun, Jun 09, 2019 at 09:46:37AM +0100, Chris Lamb wrote:
>> [...]
>  
>> As others have mentioned, I hope that Debian remains a project that
>> makes it evermore welcoming to individuals
> 
> Yeah but one of our core values is "we do not hide problems".  I'd rather
> lash out and voice my gripes _with actionable ideas_ than to stay silent to
> avoid hurting someone's ego.
> 
> [...]
> 

Hi Adam,

You have some technical improvements that may be useful and they may
very well be actionable or simple to implement.

However, at no point in this, can I understand how highlighting disdain
for certain people (or what their "title") would help with anything in
this endeavour (or any other cause for that matter).  From my PoV, it
just seems needlessly unprofessional and hostile towards others - plus
now we get to spent time dissecting that rather than focusing on what
you wanted to change.


Consider the opening part of the mail (2nd + 3rd paragraph):

> I'll concentrate at XFCE, as I consider GNOME3's UI a lost cause, thus I'd
> find it hard to bring constructive arguments there.
> 
> I also hate with a passion so-called "UX designers".  Those are folks who
> created Windows 8's Metro tiles, lightgray-on-white "Material Design" flat
> unmarked controls, and so on.  They work from a Mac while not having to
> actually use what they produce.

Rewritten as:

"""
My suggestions below will concentrate on XFCE because I use that myself.
 Though most of these changes are probably useful to other desktop
environments as well.
"""

(Replace "use" with "tested" if you do not actually use XFCE regularly;
I assumed you did but apologies if I guessed wrong)


This rewrite would have made a world of difference for how I perceived
the email.

Thanks,
~Niels

Re: Difficult Packaging Practices

[Niels Thykier]

Vincent Bernat:
>  ❦ 28 mai 2019 06:30 +00, Niels Thykier :
> 
>> I.e. with the proper implementation of "make-it-work" (in the lack of a
>> better name - maybe something "fetch-and-build"), the following should
>> be possible
>>
>> """
>> #!/usr/bin/make -f
>>
>> # DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
>> export VERSION=1.5.16
>> # PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
>> export TARBALL = memcached-$(VERSION).tar.gz
>> export URL = https://www.memcached.org/files/$(TARBALL)
>>
>> %:
>> dh $@ --with make-it-work
>>
>> # override_dh_gencontrol:
>> # dh_gencontrol -- -v$(PACKAGEVERSION)
>> """
>>
>> This could inject a tool to run the wget + tar extraction (incl. the
>> distro version sed'ing) after dh_testdir and before
>> dh_update_autotools_config.  From there, the dh's standard tools would
>> "just work(tm)" until dh_gencontrol where we have to inject the full
>> version (the commented lines works around that if re-enabled).
>>
>> @Vincent: Do you feel something like this would be helpful, useful and
>> doable? My only reference in the memcached, so the above is tailored to
>> the above.
> 
> That would be very useful as it would reduce the boilerplate but also
> solve some of the problems of hijacking the clean target, notably the
> fact it is executed twice by some tools (like pbuilder, once outside,
> once inside). I didn't propose anything like that as I was thinking it
> was very likely to be rejected as it is of no use for proper Debian
> packages. While my Perl is a bit rusty, I can propose some "dh_fetch"
> helper for this if there is no huge opposition against this approach.
> 

I think it would be fine for a stand-alone debhelper utility/add-on
package to contain such a tool and a dh-sequence to enable it. :)  I am
happy with assisting with the technical bits of this utility.

>> Would it help if we could remove the dependency on having a d/changelog
>> (i.e. make it optional)?  I have not fully checked if it is doable, but
>> I can look into it if it makes sense and if someone wants to help me
>> test this.
> 
> Yes, it would help too.
> 

I had a stab at it and the results are not too positive.  Already before
you reach dh, dpkg-buildpackage goes "I want a d/changelog".
Furthermore, dpkg-gencontrol also insist on a changelog (but the
dh_fetch/dh_uscan tool could have generated it is by then).

Thanks,
~Niels

Re: Difficult Packaging Practices

[Niels Thykier]

Vincent Bernat:
>  ❦ 28 mai 2019 08:59 +08, Paul Wise :
> 
>>> People using tools like fpm will never get familiar with our tools and
>>> will never be contributors.
>>
>> I enjoyed your blog post about pragmatic packaging using Debian's
>> tools instead of fpm, it seems like a good approach if one is
>> committed to using Debian, especially since it allows for incremental
>> improvement towards a package that could even enter Debian.
>>
>> https://vincent.bernat.ch/en/blog/2019-pragmatic-debian-packaging
>>
>> OTOH I get the feeling that most FLOSS upstreams are interested in
>> cross-OS and cross-distro packaging rather than Debian-specific
>> packaging. I don't have a good feeling for how "sticky" OS/distro
>> choices are for folks who are building non-FLOSS services on top of
>> FLOSS distros.
> 
> Yes, upstreams are more likely to prefer one tool. However, if you
> contribute a native implementation that works accross the same set of
> Debian-derivative distributions, in my experience, they are usually
> eager to accept it it stays simple enough to not be a maintenance
> burden. Of course, it helps if they didn't start with fpm.
> 

It seems to me that it should be doable to write one or two helper tools
that could handle the fetch and then pass the downloaded code on to
dh_auto_* which would then DTRT (in case of standard build systems).


I.e. with the proper implementation of "make-it-work" (in the lack of a
better name - maybe something "fetch-and-build"), the following should
be possible

"""
#!/usr/bin/make -f

# DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
export VERSION=1.5.16
# PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
export TARBALL = memcached-$(VERSION).tar.gz
export URL = https://www.memcached.org/files/$(TARBALL)

%:
dh $@ --with make-it-work

# override_dh_gencontrol:
# dh_gencontrol -- -v$(PACKAGEVERSION)
"""

This could inject a tool to run the wget + tar extraction (incl. the
distro version sed'ing) after dh_testdir and before
dh_update_autotools_config.  From there, the dh's standard tools would
"just work(tm)" until dh_gencontrol where we have to inject the full
version (the commented lines works around that if re-enabled).

@Vincent: Do you feel something like this would be helpful, useful and
doable? My only reference in the memcached, so the above is tailored to
the above.

Would it help if we could remove the dependency on having a d/changelog
(i.e. make it optional)?  I have not fully checked if it is doable, but
I can look into it if it makes sense and if someone wants to help me
test this.

Thanks,
~Niels

Accepted marble 4:17.08.3-3.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 18 May 2019 07:16:42 +
Source: marble
Architecture: source
Version: 4:17.08.3-3.2
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Niels Thykier 
Closes: 923592
Changes:
 marble (4:17.08.3-3.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
 .
   [ Frédéric Bonnard ]
   * Add Comment fields to the .desktop files as they are now
 required by the Appstream generator.  (Closes: #923592)
Checksums-Sha1:
 22c8ba548a798679a7f2283f33d1d08b0b8cfabe 3681 marble_17.08.3-3.2.dsc
 e3b21986d23cad77f1f6bc2082d55e605d5245bf 73804 marble_17.08.3-3.2.debian.tar.xz
 3be1740b92c4e0cbc10160d87c67fde7152fdce8 5199 
marble_17.08.3-3.2_source.buildinfo
Checksums-Sha256:
 f54642207b7e4bfea09a4b2a66ee3a0e1b767809ac9acc4d7064b909ec07e29b 3681 
marble_17.08.3-3.2.dsc
 2a4ca592c1359f26fbde2eb374ca0961d100330abf4ce34d8fb1cdb5fbfac4be 73804 
marble_17.08.3-3.2.debian.tar.xz
 46b6758f8414b2c680ebf320a2621498d5d9835bb7957e796dc07d7055eba54f 5199 
marble_17.08.3-3.2_source.buildinfo
Files:
 c942662a6207bffb13b00756a98737af 3681 kde optional marble_17.08.3-3.2.dsc
 1cb241ccc53ac9d2f7ced42087f1235a 73804 kde optional 
marble_17.08.3-3.2.debian.tar.xz
 a0d19e964ff3d101becb2318d004857c 5199 kde optional 
marble_17.08.3-3.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlzfskMACgkQplt42+Z8
eqwlDA//SGQ8Fs3vw+ZBshIF2J6Iq3RKOHXnz5A1WMXSt3yCN8nigHqZNAyB/vFe
dwIABhQqmRZf6cQo2qejozsbpEkfyCjDiupDC4Sm3IGprT7y6l6Gz7jMUt1Uf1/V
nzyYysSymUMBDFCMBgNdpkLvu93GjBv6B2k9fMREhw/nYQM9i456qC/b7Y1zA0DF
JEqBJYkhqXslsLzlMmtAYEm8ekbvN5iuqyJkacxT1RfNQD29VzPWLIYjp/DPTBEK
mghRgG2NCdLRgFH/UcfEtrCExwPXlbHcUGGx0ch6gnw6tfsZD5itIWLfEAWR6WuH
l+OXtYJIn7zCfbK2DrTHvp9xmZm8fsm399b65l0CWCRVGGbBePGANUUthtAnefPE
5PAGefHgykLaKecSN12ZFRjgMRvGaosqFUzc56MM0Yz8CWZ20QkyBsdsaUPfrDln
7+NDeftBs2EU82+t9bjim0SiiJcLGmHMGjdYBfewYrafYWRA3bgXgBjHTV34jLNU
4Sn4+oSnZseEHO+iBWWD60h9BKaktUztG0HCm7ZaVgK2KCL3EZN0wbzT2P0VBob/
8ZfYSJB/lOll75q7QmwAI4k6jSua5x4zXBRWhHwhzMJNohnwbHzwpnh3H0+W9ojO
lx5Jk/TJLT1rsa/fsYkZuPbJzmf6jnWimdxQZhmj8ru7Rkk3FNI=
=G1N/
-END PGP SIGNATURE-

Accepted tilda 1.4.1-2.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 11 May 2019 13:04:23 +
Source: tilda
Architecture: source
Version: 1.4.1-2.1
Distribution: unstable
Urgency: medium
Maintainer: Sebastian Geiger 
Changed-By: Niels Thykier 
Closes: 904309
Changes:
 tilda (1.4.1-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Import patch from upstream to set ensure tilda is run
 under the X11 backend.  This prevents crashes when the
 window manager uses Wayland by default.
 (Closes: #904309)
   * Ret Rules-Requires-Root to no as tilda does not need
 (fake)root for building the debs.
Checksums-Sha1:
 97e2a78bb001075b197962473957f6d1fc881e31 1855 tilda_1.4.1-2.1.dsc
 4a5fcfdf71f936da8925b8cf0e292bbb7e08202f 6260 tilda_1.4.1-2.1.debian.tar.xz
 8d8b4429bb2b945c9ae70f1ab02b4a69bd99e034 13797 tilda_1.4.1-2.1_source.buildinfo
Checksums-Sha256:
 56f4dc6b5ec114b77420ac2a9c0ecc90fc7f1ad6009c939f6b40627b65bceeed 1855 
tilda_1.4.1-2.1.dsc
 eff44da64055d1ae047b737c82b4bee23e2e1ea975a12fc1dfc82eff4c60a6f3 6260 
tilda_1.4.1-2.1.debian.tar.xz
 eb1f76651f55933c1f715d9c63ce502cb10471b24fa523476680dcea83bf0e5a 13797 
tilda_1.4.1-2.1_source.buildinfo
Files:
 9fc30903c9116567d2b8bb4016c34353 1855 x11 optional tilda_1.4.1-2.1.dsc
 dcc78dfead592b7c7c0afd8dd7ff3158 6260 x11 optional 
tilda_1.4.1-2.1.debian.tar.xz
 250e18cf39c4a659d7734839b0357ba1 13797 x11 optional 
tilda_1.4.1-2.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlzWyJQACgkQplt42+Z8
eqycDBAAxkXgytcp2P+PNmQpJD/xUx0zOJQv6YbzP0iZPcuka1ZhwYMLLDUK2N8M
8YnJEWkTNv2YPoZuB3KEwDoPdK+MkC5dDZy5/FY2yzmytN2lP7VYyJdwx73R5M/u
P67AmzBta6tNWmLA+z3ksmxtS7I2UwF4ee/1VA8PnBYFkKu0U70SL6wu09lOtZRA
4iHICH3Af4B3aYt2HBO1QJpfVK/n4q/zAC/yS2OzQivHDqpAmC4lX18LtcRnQoFk
ZIAYT9B3AMeIhxN4b7nBxW4WppHfV0oXJLs8RbGvZo0no7U0yNaM3Iri28mNEKPY
0cnXuzSv5Qg6z0HpnAChdb+U6gQZQS6uyIHTHlTZtGK0UNjPY8hYljSNGf8RWKAy
o7xEuB3TDJ6uiefRNPiiiWkFTfw6AqmXeHAErwCF9msxkCv+q7XzaAfAl4JSJGKP
OSDJC1v1SnC8XaEYTtgl5FbbHaaGOa7ZBdozd8U6RZQmZWne7UIWrp8EqxMyRHSJ
URnWLLp7pql/+ghdYQaL08++zMJIbueH3C9bD33lArHYbzhFqp47DWuCd0bpd5tk
BrrOHqZj6H4+uZJWpDzy24mSvyTOIUIuCGMvjvhrV9Loe132p3edvsl2xLZM6QPS
kYcTuUBATV2wP4fYoe4UwaVTaIZ3vJBP/chT3YUvn/8UQvg4PjM=
=PyJk
-END PGP SIGNATURE-

Accepted dh-exec 0.23.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 18 May 2019 12:44:04 +
Source: dh-exec
Architecture: source
Version: 0.23.2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Niels Thykier 
Changes:
 dh-exec (0.23.2) unstable; urgency=medium
 .
   * QA upload.
   * Remove redundant Build-Depends on fakeroot as this weakens a
 bootstrapping cycle.
   * Set Rules-Requires-Root to no as dh-exec does not need
 (fake)root to build.
   * Explicitly pass dh --builddirectory instead of implicitly using
 -B (via DH_OPTIONS) as this enables dh to optimize out some
 redundant helpers.
   * Bump priority to optional as extra has been deprecated.
Checksums-Sha1:
 af1dc5e56315425e2d8a857f4a8633e95c08f565 1671 dh-exec_0.23.2.dsc
 218215d7f10a95ee318cde84ca80b36701874279 34140 dh-exec_0.23.2.tar.xz
 1a05dfa40d7079466af877ecef5b66359b0c51ad 5027 dh-exec_0.23.2_source.buildinfo
Checksums-Sha256:
 607c931b8b1953a12ae8bad2c80e9bf30caa2adbd98c4610e15e20e853f84075 1671 
dh-exec_0.23.2.dsc
 10c28f658aa952cc1b3cac8ddd746ff787eca269aebffe64e1a4f05b2f8b1268 34140 
dh-exec_0.23.2.tar.xz
 7d6722a9ccd3e2b9094a89241756536d570f1c813df1034429c81bfe23d2b1a0 5027 
dh-exec_0.23.2_source.buildinfo
Files:
 90a840df5ba96f9e1c7556bee16e9524 1671 devel optional dh-exec_0.23.2.dsc
 fdd9b872e170edf3a7d79bdd020082bd 34140 devel optional dh-exec_0.23.2.tar.xz
 e5117a38cba3e2b7d6b47453e6eed925 5027 devel optional 
dh-exec_0.23.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlzf/yYACgkQplt42+Z8
eqx9YhAAkm8D83qA5bcWIr5gxWbsrgKqlkcgGOlIRRElAgRZKgtdn8W3Y8tGxVjm
R7k8s+H0bLH2huOKB4b2QaZ6eHHiwEHJq8cL/R9zxkDrAykDhjfRUQCv+SErtPXl
DeiQKe7uBMG5GeFXS45zTlM0DW9dVPB8ZJfFCHXMHbC61Byn7mUJ+sfCI7WVWR4Y
wmVCTW86GTLuKmFBHsVtPRnFiE8An1NEjlTLm/stKZn4PZVjBTNUsMFcwgOFSMu5
kq5Mw0u1kjoME2QYZWpzP+ONjJA/nzyJhSPTwQ22XQkP/geVVfgTCbdb6g76R/rI
RbMWNxwu3YIu8Ymv7qfBCFt9iicXO0zu7wFbC2cylm0RbtbzhDaqqyapnNPWcKpr
aPq701/+KAqWppty1JFpScdRo1Y1uozhLwDo4/7xaP57EF/oZFtByOFdmiFHirqx
kx/jCaDCoL5FPkR4dsrk7arWTat07qfg6laZQggLM5D5FxhgHUfA7aaHGhwJsRf2
MOMrIhMGN29FGtaq9q8IcVEsyE6VDKyHDL9WJEYQ8YMXvORisalCiuLMhfjmYZ31
ovE55KBonIDfVXcSvlTDh6t13t1oI9QSjmuDt38vfurzZ+zD9/m1xFGTd/ueotE0
DU1KjqfdiJ5a0HGSUGiy0oXgry9Ag/AnXpOn9xLuc0J5HZxPG78=
=EMFO
-END PGP SIGNATURE-

Re: fixing debian-security-support upgrades from stretch (for good)

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote:
> 
>> [re-sent with debian-release list address corrected...]
> 
> Also resending.  Sorry.
> 
>> so there is "#928172 debian-security-support: fails to upgrade from 
>> 'testing':
>> dpkg: error: error executing hook" which happens when base-files is upgraded
>> before debian-security-support (but doesnt happen if d-s-s is upgraded 
>> first...)
>>
>> So I think this can only be fixed properly (=without asking people to
>> upgrade to the latest stretch pointrelease but instead allowing upgrades
>> to buster from *any* stretch pointrelease) by adding a "pre-depends:
>> debian-security-support (>= 2019.04.25)" to base-files in buster.
> 
> I didn't think we supported upgrades from anything but the latest point
> release of the previous stable release?
> 
> My belief is based on the release notes saying that you should upgrade
> to the latest point relesae first.
> 

My understanding is that we prefer that upgrade paths works regardless
of which minor version of the stable release you upgrade from (to the
extend possible).

Thanks,
~Niels

Accepted debian-archive-keyring 2019.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 23 Apr 2019 13:42:28 +0200
Source: debian-archive-keyring
Architecture: source
Version: 2019.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Release Team 
Changed-By: Niels Thykier 
Closes: 912214 917535 917536 927765
Changes:
 debian-archive-keyring (2019.1) unstable; urgency=medium
 .
   [ Adam D. Barratt ]
   * Ensure separated keyrings for Wheezy's keys are removed.  Thanks
 to Sven Joachim.
 (Closes: #912214)
 .
   [ Jonathan Wiltshire ]
   * Add my own key to the team-members keyring
   * Add Debian Stable Release key (10/buster) (ID: DCC9EFBF77E11517)
 (Closes: #917536)
   * Add Debian Archive Automatic Signing Key (10/buster)
 (ID: BCDDDC30D7C23CBBABEE) and Debian Security Archive Automatic
 Signing Key (10/buster) (ID: C5FF4DFAB270CAA96DFA)
 (Closes: #917535)
   * Refresh the signature over keyrings/debian-archive-keyring.gpg
 .
   [ Niels Thykier ]
   * Add myself as uploader (Closes: #927765)
Checksums-Sha1:
 db78b034a5ca21d7f62a6f3b36c1e23b66adc692 1808 debian-archive-keyring_2019.1.dsc
 c28d4f6254b1a1e4671cabb1b9a36b10faf689e0 116772 
debian-archive-keyring_2019.1.tar.xz
 7eb3c14047b1fd0f4bb25a89dabba8ccb051bfe9 5958 
debian-archive-keyring_2019.1_source.buildinfo
Checksums-Sha256:
 c41d15f22974aa3c8b2a6535327f8c4b6bdeea050e3bf070c4bc6c4d8860f598 1808 
debian-archive-keyring_2019.1.dsc
 cdb12d8b78889593dc9a37f639cbd9efd164cfc058c07b039f74581dc22a4b6e 116772 
debian-archive-keyring_2019.1.tar.xz
 582a60eadd41798575d4608e984810341385f0ed2d9cdb83baf787851ba5a599 5958 
debian-archive-keyring_2019.1_source.buildinfo
Files:
 43e88aa9c4014a3c8739f1c5d2e0bd61 1808 misc important 
debian-archive-keyring_2019.1.dsc
 002a37c91d58f9cda51a2560636239d2 116772 misc important 
debian-archive-keyring_2019.1.tar.xz
 046c3bd593fc1b9ebfe9d860bf52d39f 5958 misc important 
debian-archive-keyring_2019.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAly++7gACgkQplt42+Z8
eqxHmw/+NHWX5ZwAunIvrK3XQxWUmwQyHKV8O5/09cj88Gj6/LVWk9dqHjVUn2Kz
nySo2RXze5QNAdDPypfZqS0E4XCybwESkoEDmaHSUJNxvndI3zzUzVLxFPJKgNbb
E3dXbvdNbiUkwkUo1laEkSpXPDxoeNpjC5xScF97kv+by3ZptNGPW37gEb+W60vd
jzOcg/bTSbK1Jy4OAfsHKD7m2M9Gd1IqOTVKItwgpkADMbqgE11lBlKGLjbURFvc
g50QurtMroCVlGOmMIAD99WE5i36vrbOr9bPTwJmkTB0aR59nVa5Mcd0yBYVGNk7
sTdQNoGQyKsgyRmpCLD6xLOee3pBIUTFBLQWygj81snffQIPk4vxzYI2ko6zmJkP
TPJBx8mEKVxzjDTne28GJ6KGfZjEI8n7EW4XFbMH/9LcblZC4ZSRv9EMPlgMKMii
pNe7pbPqyLYMdNPU9eg+72bDE/7PoWehVlodgUCOQ62puTFIDYP5myvFOwCpOCNb
R5vn6JT3drPyOn/ASIx6gF5q9RpfsP4y4UcaKA7TemsroIY/17bFopFdyYH5CbTH
LiAxrNmfol2bmT8+35Xq9BH/xvRKMykfks4QhTv0bst4jQeo3WvGOaPY9OxwUvKX
9SzYNub3Fx5oHg3+Cw4yoNNWbQ/JE/JLgnIO6tvpCPxxKyylST4=
=ATLY
-END PGP SIGNATURE-

Accepted javatools 0.72.9 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 21 Apr 2019 06:43:12 +
Source: javatools
Architecture: source
Version: 0.72.9
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Niels Thykier 
Closes: 927676
Changes:
 javatools (0.72.9) unstable; urgency=medium
 .
   * Team upload.
   * jh_build: Fix conflicting definition of --no-javadoc, which
 caused it to not work as intended.  (Closes: #927676)
Checksums-Sha1:
 a76a73aef59c75717f5cb33d821a8b9bf043c74a 1869 javatools_0.72.9.dsc
 3d03caf9ad0a17b0660f22341408af93633a33a0 54220 javatools_0.72.9.tar.xz
 417df0392a671d644564072090a528a9c6f23669 9874 javatools_0.72.9_source.buildinfo
Checksums-Sha256:
 8c49bf209951a95e5d1a4b330c85c2fbd4ae06c615dbd8d9f0a197888d650b9a 1869 
javatools_0.72.9.dsc
 808590951314fbf0b3a8f438c8c6939dafd0f3f498e1721e2afe3856e2ccd094 54220 
javatools_0.72.9.tar.xz
 3f8bb0827bf0aaf1d4e3fc688f7281eaae3ccb223bf55485274f37565be1dc33 9874 
javatools_0.72.9_source.buildinfo
Files:
 213c11d20fca607f059a63ebfe7237bd 1869 java optional javatools_0.72.9.dsc
 3adff6f6e74c78dbefb7c4debe7a1802 54220 java optional javatools_0.72.9.tar.xz
 b1d5c15323d2504a6dd11314ac905a5a 9874 java optional 
javatools_0.72.9_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAly8EmcACgkQplt42+Z8
eqw90RAA4Q1tt/Of4OaLH2kM1TNS/EyOUDPzIOVJSBnuePyP5xIcP+3IcmmUzPSa
PpcIYmiq9RN5kKvIB/d7syQepiUdvvKXxAxkyIRTsdHmVIz0XBeTpNx+FnReO+it
5olPapfk1enIECyGq0OXk9XRMjVDchdiOqqcIzdHweMvzlZVwBbkqBHmHCSKPA6J
Xi8BUNxhYZJvAAks7vx4hk3LD7MXzRZG2K+gR1ZFNM7ZCQ5d4Qi6u69hN2XJ5LAA
CwDL6hypHlNlJLtL3nmNo36m9X75qgmhErsq+koZcz4/ViImBpEfFIr9FE8ty1tY
mu1xwuILfpMWnmwe7R9kJm5eCLJe3dCzIkYfu174oCEqN2eogXB0Jq7MTCtm7bOe
0r4FEZTAuG3lk4uWTB+bBqeJnpIFpPVPhcBI/6TvRAPS961JbepWjJLyGkIM+ndR
1qMM+bSfko/SZOOLf3z7oE2EcZoxPpH4bxLHF6vI7f+Uj/HkpXGazD87f++pMV5H
AXqpBHsXeIqS2ciwEl3tqM+z+Gij7vJ7hiZiHvxY9BGmJmikavCXtpzQja7CkDJG
MsEIRtZq8Ywvm/ZoP6EKO0D4p+uhDoFPuZVKrN+uZBB1lSXNRIxAhXiFU/cdLZC6
+b0maEXRQYiDgUyyFA+VXLNxhJLA3Rv5RtvQw5Ba35QnTVlmPR0=
=Poy5
-END PGP SIGNATURE-

Accepted jtb 1.4.12-2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 17 Apr 2019 13:43:38 +
Source: jtb
Architecture: source
Version: 1.4.12-2
Distribution: unstable
Urgency: medium
Maintainer: Debian QA Group 
Changed-By: Niels Thykier 
Closes: 927243
Changes:
 jtb (1.4.12-2) unstable; urgency=medium
 .
   * QA upload.
   * Set maintainer to Debian QA to match #922601.
   * Remove obsolete javabuild file and call to jh_build.  The
 real jar file has been generated by upstream's build system
 since stretch.  (Closes: #927243)
   * Set Rules-Requires-Root to "no" as the package does not need
 (fake)root.
   * Update code for cleaning the package to ensure the package
 can be built twice in a row without failures.
Checksums-Sha1:
 3e45e6010bdee038a1906d36751f0607b9e6fbf4 1911 jtb_1.4.12-2.dsc
 28dd6410495b77c25223c3321d745c5356a20a47 5696 jtb_1.4.12-2.debian.tar.xz
 e78d4642bbf944e64c11fa1fdc6ab0a34f3ea72a 7712 jtb_1.4.12-2_source.buildinfo
Checksums-Sha256:
 4dd442f02b74b28ab99f930958c906daf5ca1ea903dc2e7499cfea1dfbe6f614 1911 
jtb_1.4.12-2.dsc
 a200cfa37f1e1c2f2d86342f867254e08e00ca616106d2a522f650e374e8cc82 5696 
jtb_1.4.12-2.debian.tar.xz
 934f20cc0f8be469a7016cf2e41d6df5930ab5a5cf2e80275fbae7f7b5086641 7712 
jtb_1.4.12-2_source.buildinfo
Files:
 abe04ea9326d38b224b4b8d13eab1219 1911 devel optional jtb_1.4.12-2.dsc
 09b43e77b8ea8405b67ca8f9c736cc63 5696 devel optional jtb_1.4.12-2.debian.tar.xz
 3093a7371a4fff2657f01c939e125936 7712 devel optional 
jtb_1.4.12-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAly3L/oACgkQplt42+Z8
eqz/rA//dlIvjULSIOiRS6KDJsNefGmI81FWSH+QqSQJ4Aa1Y6Ij1Vt47yJ/8H8c
cV4QoEMxzRbAMQPGAbYND1RX5IjbSDC68KyXCDxKz9XYMdZUcwdQRmbcCSzTKnWv
thQFBUCM/G/9FZc6nFoRJrv26NVJWJgkaPkH+ENgv6wbBWCV1wHKrTwRSxMsXtCh
pMGCt3XDNDQUahYTTEJvyGx09cspHq2dyvMElm8kR9eUHPt4Di/Dk9bCgQPPojZe
YWlmmXQIeJuYvdBa8wZ/hONznLj8d2M17n4F58FXx6b+nM+b39fjAat5LSts02H/
6JjBiMPV1MkxxLpJVsAHn5SdcxEy+zJE5PhKQ12lq5NSfEBFF1CZbi90q/5iQOQX
IWzIbsr3dC6tvRAgOusowfSi9Z21NiBCVrj9JrxU30sUKCMTVF+A3suqHJwE+IHf
Y1OfGmYxidHNXtSuSrL1yWJO+E8+zaHvf/gkAbS6FElflpeJuFRy9MQflVGPBUXD
25vGMlgPXRj7gyOq/rfkETRD79wogJoCOJWR16Z7Pku5xRMucLElMdYmYQ2uLm3z
9NjJgiALX3n6h1hQagy3MhJFuj0X4dRdrVW2J3S68Nxr3yWQ7eBBlhbMoRyu98QN
aIKHjWk2ArGUX4arl89u7sri8ygQkRjuNZJZwUEyjJQgzpr+Irk=
=I/LI
-END PGP SIGNATURE-

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Niels Thykier]

Andreas Tille:
> Hi Niels,
> 
> On Tue, Apr 16, 2019 at 12:54:00PM +0000, Niels Thykier wrote:
>>> speaking about false positives:
>>>
>>>libhmsbeagle (U) should switch to dh. Current build system: 
>>> debhelper (source version: 3.1.2+dfsg-5)
>>>
>>> I have no idea what might have triggered this on the current d/rules
>>> file[1].
>>>
>>> Kind regards
>>>
>>>Andreas.
>>>
>>> [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules
>>
>> Try:
>>
>>   lintian  -L =classification 
>>
>> And you will probably see something like:
>>
>>   C:  source: debian-build-system other
>>
>> I.e. most likely a false-positive in lintian.  Once confirmed, please
>> file a bug against lintian or/and provide a MR on salsa for fixing the bug.
>>
>> For reference, given that trends.d.n relies solely on a lintian (with a
>> handful of patches to add a few tags), the issues are most likely in
>> lintian or in the particular patches (for the latter, please follow up
>> on the relevant bugs filed by Lucas against lintian to add those tags).
> 
> As far as I understood Lucas is talking about a patched lintian and
> 
>   grep -R "should switch to dh" /usr/share/lintian/*
> 
> has no results so this warning is not part of lintian. 

Hi Andreas,

While Lucas is talking about a patched lintian, the concrete case is
almost certainly a part of "standard" lintian.  I remember implementing
the tag to detect the "debian build system" and I pretty sure it does
*not* cope with "VAR=VALUE dh" calls.

You are right that "should switch to dh" does not occur in the lintian
codebase.  This is because lintian does not assign this value to the
missing of a classification tag - this is where Lucas code takes the
lintian output and translates the result to "package smells".  As a part
of this, he basically translates (among other):

  C: ...: debian-build-system X

into

  ... should switch to dh. Current build system: X (...)

When X != 'dh'.

> Similarly
> 
> prottest (U) should switch to dh. Current build system: debhelper 
> (source version: 3.4.2+dfsg-3)
> python-pyfaidx (U)   should switch to dh. Current build system: debhelper 
> (source version: 0.5.5.2-1)
> 
> are false positives of this lintian fork.
> 
> Kind regards
> 
>   Andreas.
> 

They might be a false-positive, but I am pretty sure this particular bug
is not in Lucas's fork.  To my knowledge, that patch simply adds 4
classification tags that have been posted to the lintian BTS and those
have no conditional logic of their own (they emit tags via existing
branches inside lintian AFAIR).

Thanks,
~Niels

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Niels Thykier]

Andreas Tille:
> Hi again,
> 
> speaking about false positives:
> 
>libhmsbeagle (U) should switch to dh. Current build system: 
> debhelper (source version: 3.1.2+dfsg-5)
> 
> I have no idea what might have triggered this on the current d/rules
> file[1].
> 
> Kind regards
> 
>Andreas.
> 
> [1] https://salsa.debian.org/med-team/libhmsbeagle/blob/master/debian/rules
> 


Try:

  lintian  -L =classification 

And you will probably see something like:

  C:  source: debian-build-system other

I.e. most likely a false-positive in lintian.  Once confirmed, please
file a bug against lintian or/and provide a MR on salsa for fixing the bug.

For reference, given that trends.d.n relies solely on a lintian (with a
handful of patches to add a few tags), the issues are most likely in
lintian or in the particular patches (for the latter, please follow up
on the relevant bugs filed by Lucas against lintian to add those tags).

Thanks,
~Niels

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Niels Thykier]

Lucas Nussbaum:
> On 16/04/19 at 08:52 +0200, Andreas Tille wrote:
>> On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote:
>>> On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote:
 biococoa (U) does not use Debhelper (no compat level found) 
 (source version: 2.2.2-4)
 biococoa (U) should switch to dh. Current build system: cdbs 
 (source version: 2.2.2-4)
>>>
>>> | % grep cdbs -r biococoa-2.2.2 
>>> | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk
>>> | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk
>>> | biococoa-2.2.2/debian/control:Build-Depends: cdbs,
>>> | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's 
>>> a cdbs issue)
>>> | biococoa-2.2.2/debian/changelog:  * debian/control (Build-Depends): Add 
>>> cdbs and quilt.  Drop gnustep-make
>>
>> This explains the cdbs smelling (and I loved to get rid of this but
>> this needs to be fixed by gnustep.mk).  But in how far is
>>
>> "no compat level found"
>>
>> sensible?
> 
> That's because, once lintian sees that the package does not use debhelper
> or cdbs, it returns from debhelper.pm and thus doesn't reach the point
> where the tag for debhelper-compat-level (which is an addition in my
> lintian fork) is emitted.
> 
> L.
> 

Here "cdbs" being "a part of cdbs known to use debhelper".  At the
moment, these cdbs snippets are (to lintian) known to use debhelper:

 * /usr/share/cdbs/1/rules/debhelper.mk
 * /usr/share/R/debian/r-cran.mk

Patches/MR are welcome at https://salsa.debian.org/lintian/lintian/ or
in the BTS.

At the moment, the code you are looking for will be:

https://salsa.debian.org/lintian/lintian/blob/master/checks/debhelper.pm#L180

Thanks,
~Niels

Accepted javatools 0.72.8 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 07 Apr 2019 13:18:04 +
Source: javatools
Architecture: source
Version: 0.72.8
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Niels Thykier 
Closes: 925507 926542
Changes:
 javatools (0.72.8) unstable; urgency=medium
 .
   * Team upload.
   * jh_build: Fix a regression in 0.72.7 where the first
 parameter of debian/javabuild was incorrectly interpreted
 as a glob that had to match something (rather than the
 name of the output file).  Thanks to Ole Streicher for
 reporting this issue.  (Closes: #925507)
   * jh_build: Deprecate -N as short form of --no-javadoc and
 add a work around to make -N work reliably.  This fixes
 -N being either --no-package or --no-javadoc with a 50/50
 probability.  Thanks to Gilles Filippini for reporting
 the issue.  (Closes: #926542)
Checksums-Sha1:
 1531a80b14961df76cd7e75042c1b34f516d7898 1869 javatools_0.72.8.dsc
 5cfc42e15a932107b53c7d30471baf5f1782de9a 54200 javatools_0.72.8.tar.xz
 d7982c1e7ae383e4693c079c4fb8e94cc4112e39 9874 javatools_0.72.8_source.buildinfo
Checksums-Sha256:
 de581a3a952404e5b3f9b1d877f3e0961624c82bc093b140362e16e976a0a7d9 1869 
javatools_0.72.8.dsc
 d858d72bb4233f49d1bc14a147625b090cd32295704ee51a7cfdb035176a2ff2 54200 
javatools_0.72.8.tar.xz
 3ffb65bfede877ccec18e5761bcce7c1316557b1da0b9951a97675cd3d3780e9 9874 
javatools_0.72.8_source.buildinfo
Files:
 1e56f6ad3391bdf3ff05031c40cd2227 1869 java optional javatools_0.72.8.dsc
 91c5e8010b4dd9145e99ee0d3892014a 54200 java optional javatools_0.72.8.tar.xz
 301812202d67e1841359695b151e3670 9874 java optional 
javatools_0.72.8_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlyp+OUACgkQplt42+Z8
eqy8Bg/+IYTxaJdQ3tjVmzCVEcN7+z/4ZBa3hI8S5clp2zKXPMrICp2p4u9i81Rl
3fOiYGA6adFFmAVkA9bKl/8e7/1UUaLZWxJKZkyso/fSMGqjOh/42PMbexWVhQCS
x2ADF8eI7qRKZRqOvkOLiXaY6wKdVINnjcFJwnlK9Vck6dXKTq+AhqUMjuX2fXVY
B/gFqOvFshdDigltn4IFLAP53S1FzwKSk00Tq8ABxUH1OJnI/NlOeAPi6x7BvmAF
GNnS8oMMglM900sVFF+liAk1fhsCTP/rohU/c7jc2Dra9bHHJLzp8ynmxmLNVAS+
4qXAhepnCAlrWUeDSYiqwYZm8IndhXxriDgJwCWJgUP6zdmRCUbdt7u8yp8qTnc4
zgO0uIEndYR95PkU1DqyLOMxR9eCitUftci6gO8G6H2vjKiuPj3s21ZcMxlP9QZ2
5nQqkeOq3Tfj2dCZzQDY7sOF5aPczndKjneIMh9NB199Rxukhr8OfsWqU/ZyhXgO
/LQhO0CZhAjtYq/REDPFBU6idLBcgPCcB63e0TIExFjyrIm3ABN7G7mC+jpDr1F4
Of2ArERHdP10LamU+NL+Ks7V0Su+P+EgEX0aDVoEP/LJhYiMdaCVa6nh3WZ36/q2
mmrnqacbsYGOINU/HzaoByU8+olrKb65CoMExrQrj507ZTj09GE=
=ZGEq
-END PGP SIGNATURE-

Re: Seeking hardening flag / blhc expoert

[Niels Thykier]

Otto Kekäläinen:
> So apparently the 'D_FORTIFY_SOURCE=2' is in CPPFLAGS (not read by
> cmake) but not in CXXFLAGS (read by cmake)[1].
> 
> So maybe I should define?
> CXXFLAGS=$(CXXFLAGS) $(CPPFLAGS)
> 

You have to with cmake, yes.  I believe debhelper carries a similar work
around (for CXXFLAGS + CFLAGS with cmake).

> This is the current state of mysqld, should I be happy with this or is
> it relevant that all functions are protected?
> 
> hardening-check --verbose --color  mysqld
> [...] 
> 
> 
> [1] https://cmake.org/Bug/view.php?id=12928
> 

This is where blhc log check (where possible) is better as it will tell
you if all compiler invocations had the hardening flags.  If they do,
then you are good.
  It is "perfectly" normal for a correctly hardened binary to have
unhardened functions as the compiler *can* in some cases prove the
hardening is unnecessary.

On a related note, lintian has a list of symbols that it ignores for the
purpose of assuming/checking if a binary is hardened or not and it has
no hardened functions.  Mind you, that list is an accuracy trade-off (to
prefer false-negatives over false-positives due to the number of
false-positive complaints).

Thanks,
~Niels

Accepted javatools 0.72.7 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 31 Mar 2019 10:25:16 +
Source: javatools
Architecture: source
Version: 0.72.7
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Niels Thykier 
Closes: 924328 925507
Changes:
 javatools (0.72.7) unstable; urgency=medium
 .
   * Team upload.
   * jh_build: Fix processing of --no-javadoc plus correctly
 interpret --javacopts as javac options rather than javadoc
 options.  (Closes: #924328)
   * jh_build: Expand globs in debian/javabuild like the previous
 version of jh_build did.  Issue also reported in #925507.
   * jh_build: Remove stray "-quiet" option in the javac parameter
 list for single files ("-quiet" is only for the javadoc command).
 (Closes: #925507)
   * jh_build: Fix some perlcritic issues that now fail the build.
Checksums-Sha1:
 58ccc3d8d6992f81a86b32a000abd3c4f52f6f09 1869 javatools_0.72.7.dsc
 8eedf482b7bbe9509c839fa3993a47b3efd9bc67 53892 javatools_0.72.7.tar.xz
 67ff63d60d538ca6d6ec0e33b52c9e3ea7526fd6 9874 javatools_0.72.7_source.buildinfo
Checksums-Sha256:
 27a0db8e2b3aed15a0a379d9a10167ee2dd9ece1bfe9e3fe555a8c89312c5443 1869 
javatools_0.72.7.dsc
 3e7234d1a3819726f9ef88d96fb88de917b3596805e926fe5ee228f50798d3ea 53892 
javatools_0.72.7.tar.xz
 68a2ed7b966700c4297c27cd238822fc8409eb1980bd8aad6b46be55b8c11c73 9874 
javatools_0.72.7_source.buildinfo
Files:
 17d5b31478e97e1268ee785014d35afe 1869 java optional javatools_0.72.7.dsc
 17ff45af11c9ed5d008843a1818211d1 53892 java optional javatools_0.72.7.tar.xz
 be3e4e433cc4e90d1454309b0da1679c 9874 java optional 
javatools_0.72.7_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlyglcQACgkQplt42+Z8
eqzqxxAAsDcewCP4jSg8S0kOCtLOawDBqo8BylYPFOe/gANUaoyU7VLO/nkQTqYq
0qiWHbgscISM/tYHyRxVqEirA3rAbuLdrB5PRAyumIn/0Sktiug2R5zIyc0yVC/1
wQhekjZVqypciZTV4XePfZtoZxb+q9oqlPm6uympT+5NT+yywhM8pz8O9nXEYBAT
wd1IZYh6nr8ie9E3U3zw3j/l06XhPhxzIDv1HC/ODNMJ3aUE40YcFKiOdjkCpgpF
B+KtPyp6D+XpiqOlqQO30m8v2fmJEIYznLVUDimG36UWXMkkjp4U5BqZSRkwd1LF
9C8krFhrmBUiA+4MJsrXb8VB5HMPB3fOe8WrlITYhl16nIlvdkn1hQxI1OZy4XyG
HfLXREQYJNZgk9BhU43OW4pxNlcD7mtXXcf679wUI4IEexrkru4qgaEkK6e+0Uu+
2t7XsXSurcuBVQSIO7+ZRWgIaVQY1QZzFwINMgmzUqAkqLQLo2D670LEnaQnFs64
1weLaITXopUZwhCI5cAf6CUEovm5tAXucB5pRYxH7xEwYmvOQ5iWFXn+j0Emwapy
YZYZU6AWTT0Sy6BRHdpH9CJNkqWrrR3NAodRBqAL0ZrIzagvB0nqgS67VMIMVGNM
kxTHfY9y6jcbZz0QSgz5J1xbij07cr7TcVJHMxxNR1tOFk05gTo=
=OGYY
-END PGP SIGNATURE-

Accepted javatools 0.72.6 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 17 Mar 2019 09:20:20 +
Source: javatools
Architecture: source
Version: 0.72.6
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Niels Thykier 
Closes: 924653
Changes:
 javatools (0.72.6) unstable; urgency=medium
 .
   * Team upload.
   * jh_build: Fix wrong path for jar command when the jar was path
 was specified without a slash.  Thanks to Gilles Filippini for
 reporting the bug.  (Closes: #924653)
Checksums-Sha1:
 e670f63dda4ed163924340ccd1510e8f6e114b62 1869 javatools_0.72.6.dsc
 004c2470dcc680b9843008e2d113a8ea811e6148 53652 javatools_0.72.6.tar.xz
 eb61793747a9f2abe72b5b134efb2beaa9759ef1 11169 
javatools_0.72.6_source.buildinfo
Checksums-Sha256:
 a4ec7c876c8c1be2b1082d133c9295090b7bf3edb567014ac1c63a4ba3908ec6 1869 
javatools_0.72.6.dsc
 8f05b3a83598164b3d60267bec81f6a0283090b5c84ba22a24d2d535bb65a082 53652 
javatools_0.72.6.tar.xz
 5adbba67583528ad15815eb35827f1f5b1e0b7fc2681e9a7122c129d760f5f8c 11169 
javatools_0.72.6_source.buildinfo
Files:
 48f6b9220f6cc357d5c07026bd3c1ba3 1869 java optional javatools_0.72.6.dsc
 4b539a81a7eed294dae60698c6081d71 53652 java optional javatools_0.72.6.tar.xz
 a1969b48cf8b53308b0a79a063cd8751 11169 java optional 
javatools_0.72.6_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlyOFPYACgkQplt42+Z8
eqzzHw//a9K0WrPTtm+fY/egXyq5IU8T2k9gb0Iqj6JNZPjnz5o4mEf9MhE4CGgn
8rQlDYqey8XXMccX0k/Z2L8mmX3/zNHMp3P8Wscfb3ePUMfb0091vn6Urm4vMPBa
O4rCegw4YAkX2bPuB0YPz0UDnhKwNKr1mpmYJKzAgi3tZRD0oJngSFcvNVs8aYVO
bEMkQLu2uOux6GmBqKGZI7d4rv7PhfAKZeDPffktge35+nd7RS4SGom9Xi1Ll9j8
cLVWfPe/AZxfxONDVVeWMJb1p0qosGY3geqNo0MoxtoSurUD8OMMCyzf4MPjvSwO
tJcyERr0HAw+5H7sSIKY9YBlnqzokcxZpzBifmqs0/KBg9+MThNyGNQEjKAZ5J0l
fwBeEcrLucPFkbfgRuksy5t4hrj2XnjN21q3YBZHhaPwE/zTmFSyzzUWp9lvQDXz
7g8u28sb/5VxoqxPTSvRs/NvIilA0i+Ph4scfqyExSX1tclP+0r0zembBxFQ9juS
z5xWL3pQpTYPetXSzh6ZY4jiCLtaR5Z+UE45KkJYGbU6j6SY5H1/FG5h7YRppSGp
u9SB4LSy1tSt/qL6ItA1kbicdAo77GnmOz1CjvYiVNwrzglbqAHtSkrObtgIVk+g
WMeE9kCTAW9HeRWoM+25J9Hffqvs+vH4EOulJOeucIf9C8w0hVQ=
=qNgz
-END PGP SIGNATURE-

Accepted javatools 0.72.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 24 Feb 2019 10:20:17 +
Source: javatools
Architecture: source
Version: 0.72.2
Distribution: unstable
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Niels Thykier 
Changes:
 javatools (0.72.2) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Apollon Oikonomopoulos ]
   * jh_classpath: handle multiple package tmpdirs.
Checksums-Sha1:
 f11c8e6a21734a299bc8ecc59f93c49e0bfb9fc1 1869 javatools_0.72.2.dsc
 3ec23b435a783a407c5a723397a69e832c40420e 52800 javatools_0.72.2.tar.xz
 b15195348480e43b1d0b9e99b68b53d8086cf9b3 11184 
javatools_0.72.2_source.buildinfo
Checksums-Sha256:
 8673852bd26f1dbc9eff21d14b4e85065fa031ee9a16bd11a32888ec606fbf12 1869 
javatools_0.72.2.dsc
 898e298ff4ca5964c67217be5baede8d15eb3e06ef0b61e622600aa3d2f7a2ab 52800 
javatools_0.72.2.tar.xz
 869b7a3b78bd8fa89ef79df06cea458eec9f104e247c91547060a3e2273ba701 11184 
javatools_0.72.2_source.buildinfo
Files:
 09ae2df4bbe1d8c6f24402c6b580c38f 1869 java optional javatools_0.72.2.dsc
 18de385afa4299c5ee26a8ee91e40c76 52800 java optional javatools_0.72.2.tar.xz
 ff906e54b5246164b2c43f98381680d9 11184 java optional 
javatools_0.72.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlxycXwACgkQplt42+Z8
eqwV5Q/9FUvPWgyfDJbUHGOQ27debC2PEUPGsDk4Zw31LoQ1IHomReom7gBzBNPt
W7OByGUMZ6ZTrHoZhwyBdZW934vMhtjstl4QmEdV9CSopnOkbAavX6cEvFJ0+cjp
OEGXpgCz5yWjM7Ee6dcEbgyuRsFokFAYlRRYvA/9UJhH1UGBHnGkRH5RXE7ibbGA
wf96Wh/st0d0bjd4kElyaP0qKIeJyLMIbHHa2YELbwaQh1+rudPy7bqb44x7O7F4
yoCvY2Pwvo0O/TDWEbh+IPk+5ueccioLzM8e913AAW2nZP/mGzAK4Lal5+1IP5VN
agko8LJPt0w67DQjRsXX3A8vTMhjm3ymeVsn4RUlKwEa5vN1DcHMXcrH0epBdBr8
7hE7Skv66orD0pOSez77wgL8Me9FsjMGGy6hEbaBnRgd3ET8w9H27UsuLxA7JrbT
w/Czzk6pBLkiMPEDzmYV4R6UfwbSAK23BA0RTlti816PwUfmpXnDcPZ3oALwJwTo
VdrD3ddCTnPkg3TcIR1fxkN3CfkwQ2iR2v85sxn0DUhL9SuotcTgI488/YIVU73M
Z5llsvDM59+/1ZdRpWE+C3Hf34W6qMNyDkTdTWem9e+Zw7wi06X3ykrUj0yTU2r3
eDJo8ISuJgzogd7MCgfXji9KEiODUApbmDrjowHrZK5GTD65C78=
=5UhP
-END PGP SIGNATURE-

Accepted debhelper 12.1.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 23 Feb 2019 13:24:47 +
Source: debhelper
Architecture: source
Version: 12.1.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 922267 922990
Changes:
 debhelper (12.1.1) unstable; urgency=medium
 .
   * dh_installinitramfs: Install hooks as executable rather than
 plan files.  Thanks to Thorsten Glaser for the report.
 (Closes: #922990)
   * dh_compress: Fix bug where examples where compressed when a
 doc package shipped examples for another package.  Thanks to
 Christian Kastner for reporting this.  (Closes: #922267)
Checksums-Sha1:
 0eec45153ed56f46152a397273c8365476a98867 1689 debhelper_12.1.1.dsc
 65f923375ec479276f44ac9a82ff1b99b8047f20 483732 debhelper_12.1.1.tar.xz
 8cd243e8c8ab0e659e361043727b5357f725be64 4419 debhelper_12.1.1_source.buildinfo
Checksums-Sha256:
 50f8cfad5c55480c0b189f154ba1223ded9101af1ac6dd8fceb7011beaa78ad1 1689 
debhelper_12.1.1.dsc
 60e2a4be5eff9517e09e05ef5ab6a618007d7f0f8e2b5e32682a628ae226bd91 483732 
debhelper_12.1.1.tar.xz
 a382ed3133751768d58d1492b8523be09bbf735c10d82a86f53ba657c39e4f7c 4419 
debhelper_12.1.1_source.buildinfo
Files:
 9553c056e5ed1629487ff727a0c3c73e 1689 devel optional debhelper_12.1.1.dsc
 e3ad52afd4ee89db38ad27747e851a7c 483732 devel optional debhelper_12.1.1.tar.xz
 9c3455f8e4c6c1c71af7b7a719c737ee 4419 devel optional 
debhelper_12.1.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlxxVf0ACgkQplt42+Z8
eqySuw//fJc2bkODhVqx02Cjddlp1+JeOtaD7W0pdWjsTuA14KGvZKeJumVoZPPE
Xy+q6HuU6bfUpQbnI9+9vn6RPa6689fWsqfwNUb8R24S6x6wnOIGCfBCgjMcpgxN
eUzfGaoeofnNq92GQNlQvo54mxNQXupaBv9yICsZMBib3fHCmuT9OCN4YajyMgFM
mHDWxS/w/gLIDc+B45eDkd9/tRIxt+O0PIemz2yOZuMLwOoPJzvv9Xla/2NLIZvs
73SDuVjLNpj8srF8I4DKltCpxLdDmOjPOf8yN6l2Iwb5vFYMH+x39Ech0RUoxodW
YH05lmdcdwJeI3zF9ATOocKYXiUerNrme3E0z95bpwsFjb6uPwzIqLfYuycz3SoD
WsBk9oU5F6W0fWwKpKv3Kv0WTElgq2st6Jpifn9rf3j52mSmwv77i8Th5emPsIBJ
d4s3gklLI3GiMb6SEhEl3Z7V/aHJhsqfhAm2wofXjR/2d3XvuZAO1mv5AU99IIB/
Gtcb6M36+MUEnswHb12P6oZve5lo9y41xP5F/460eidzgAw9whFIJkCfrREm42xZ
b/iIWJcJMvGR/XqIY+RzIWWLBvAcgh38aZRE0o64OwGb1+t8PD12zJwZnFfAZpNI
EV5vdi3MP7oftJ1ubdzEefvwSBn3nwcXYNmK7dx+z7wRC1y1zO8=
=cRbo
-END PGP SIGNATURE-

Accepted debhelper 12.1 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 10 Feb 2019 20:33:53 +
Source: debhelper
Architecture: source
Version: 12.1
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers 
Changed-By: Niels Thykier 
Closes: 917362 918066 919853 921254
Changes:
 debhelper (12.1) unstable; urgency=medium
 .
   [ Xavier Guimard ]
   * dh_fixperms: add .node in mode_0644_patterns.
 .
   [ Sylvestre Ledru ]
   * dh_strip: Print a warning when an ELF binary does not have a
 build-id (or when dh_strip cannot find it).
 .
   [ Niels Thykier ]
   * Dh_Lib.pm: Strip leading and trailing whitespace from lines in
 regular debhelper config files.  Whitespace-only lines from
 executable config files are now explicitly detected and triggers
 a human readable error message early rather than warnings/errors
 about uninitialized variables.   Thanks to Ben Finney for the
 suggestion and the initial patch.  (Closes: #919853)
   * meson.pm: Dump "meson-logs/testlog.txt" if testing fails with
 an error.  Thanks to Jeremy Bicha for the suggestion.
 (Closes: #918066)
   * dh_missing: Clarify the documentation about when -X with other
 helpers can may dh_missing ignore paths that are not installed.
 Thanks to Hilko Bengen for reporting the original documentation
 was unsufficient.  (Closes: #917362)
   * d/control: Bump Standards-Version to 4.3.0 - no changes required.
 .
   [ Baptiste Jammet ]
   * fr.po: Update French translation.  (Closes: #921254)
Checksums-Sha1:
 7575cab473a56568770ac07f811cb3230e3ed21a 1681 debhelper_12.1.dsc
 aa2eee5772eb0d82cf8a5ea6e64de51084c5b5ad 483568 debhelper_12.1.tar.xz
 6cd000bdb36194b786f81657d37b24841bc42829 4417 debhelper_12.1_source.buildinfo
Checksums-Sha256:
 a8e5e9363206ad92d0e5d5bc77ca2bbf790d99f7d3a6324a10cfbbe1131adb24 1681 
debhelper_12.1.dsc
 3384699a0fa54c46a7f063fa6c649656e2891981057931dfe470bee555762527 483568 
debhelper_12.1.tar.xz
 8a7c64b27cac8bfc90637724683f491980e5a16a0a046bfa2030949aed655415 4417 
debhelper_12.1_source.buildinfo
Files:
 0efae277b5d6a7db5a05fc1bcf0e70fd 1681 devel optional debhelper_12.1.dsc
 216b1ec2f1c2552c54ed8f52f53931dc 483568 devel optional debhelper_12.1.tar.xz
 c3a2c8359ff3e2727a28c70a0db8be82 4417 devel optional 
debhelper_12.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlxgi2wACgkQplt42+Z8
eqxxCg/9G5Yh5lIT7zQiHf+TSVtx7lPOZKhziINkL5rNEw3jzsNnGKhi37DrjMPH
MUozlTym9MclToKaTQGOemoaCEHkF39Lhixx7S6PhgtTkU81CghNJWgH4/nDno+c
+LXwNRbiymfo1Sknat7pmZEJaHS10kEpzWQ8n/A6qhtF+TppWyb70s+2pQ/H76Jt
8MDgV1vdiFfLyoYT/LpqaO0hdbgPmY3ULEyhLjU/BvFZxOAYPyVpZZnDOuuBavHt
IPRFqmSNKhKkZwzgyaqghVm8Y8nfieidf/jLIAnfaZAe3qbIUJooV9M2JniZnQIE
t/wMIrKICu5D52KNd5FLjlqWgipq9xTtU6heyCzSM2NaUSOdOqYrAmY7NrS6wpgP
bJzQfJjC6Wb9jbVwHWlDzwgQiU+zbX+OsGNSCO+IuJ38FqA/t16gguRU2/4GsY8d
NriMyxq3OKDBeT8nae9igtR1sBisXfmkKZ3h8J7Qjx/cXKWnFtz8flpQGVpaPUng
R8+QI6fAMzJpqIvbJpHZ2bF1inNnSEUB+wxiebwHXXINv20Iy1UJzLULJ/Op3GOl
pOk6PrR1bn9n/1HDWSXBT6JRUyMKktQanPlmEz0i7OV9NQpAEIN/0I78I9ra24+H
13TFfkQxyVN3BlzAWOBjsXc5nuvglw8W6ZdHidhg7VfkaWvX+v8=
=aUNn
-END PGP SIGNATURE-

Accepted apt-file 3.2.2 (source) into unstable

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 09 Feb 2019 09:20:04 +
Source: apt-file
Architecture: source
Version: 3.2.2
Distribution: unstable
Urgency: medium
Maintainer: APT Development Team 
Changed-By: Niels Thykier 
Closes: 921115
Changes:
 apt-file (3.2.2) unstable; urgency=medium
 .
   * Fix bug where the progress indicator was still been using
 under debug mode (despite the intention for it to be
 disabled as it clashes with the debug messages).
   * README.md: Update links to Julian's blog.  (Closes: #921115)
   * Optimize imports to reduce start up time a bit.
Checksums-Sha1:
 2624351e97c661d8b59e52a8a07a01c9d311dbd8 1783 apt-file_3.2.2.dsc
 25e8595a2513cac68c856ca93b81d47ce863bfd9 42160 apt-file_3.2.2.tar.xz
 b000a7cd1b3075f82f93c1de6ed0e05dfaea961b 6868 apt-file_3.2.2_source.buildinfo
Checksums-Sha256:
 4217dc6811b34b1424edfa75cfda1509a36894f6b4060a34d537a0a68d0bb646 1783 
apt-file_3.2.2.dsc
 bacbfb038dca6d2f0b740dcd05064d0b81fd0f086ce2eb59c5157d13ef064edf 42160 
apt-file_3.2.2.tar.xz
 dd4b9e32a3a460d4f0de211a6b32b39201a60bd9af8856e722d1031ef92c40cc 6868 
apt-file_3.2.2_source.buildinfo
Files:
 dba0d28e0f5d24c4df458d679168994f 1783 admin optional apt-file_3.2.2.dsc
 af15b09d9a31c35bdbd18b2fb730cc5a 42160 admin optional apt-file_3.2.2.tar.xz
 e9e445e52c0b868647e3755c7f230013 6868 admin optional 
apt-file_3.2.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAlxen0gACgkQplt42+Z8
eqxppg/7Bn6L8yloIIhC0yn+fgiNpF63AOGk4gAGOyMhDGw0hdzMowR7bXnl5bdy
UavvUhQwZIPj7spLl7iDj4/5bBrxZE9V82X1xD4l2StubhyTnhj4BESNhcdR9sNH
bsPSdjCLorYy89zQSrGVtUWVBGU08WkW2JEXijo74u729O4MpWUQ8/EWeMhfUq/o
PjcBbUtOIaZkxWFznyCuuRMW0w65jMty91gycGDOtUGUHEoLzcb+l+TthuNnxYYr
1lejn5keMz3mO9toabwoqTHVE4dHuPezuF9IGBtiV1xHtCRgzuvlPkDIYBNJQf+u
v5t9BYcb+uIxVCfDfQZa63LXy/2ug/sCkl1Mdpa4ICfDk0IxUc3yVBYBqPYQtDQ7
nPulkw6thBjh1T/y/IfFiZ0BkbGlmndeOEGSRAmbFxxyQY7UUojW5Exl/qsic+Y+
177c0ONje4hU2jfZ5APXYrkl+FTGWJ6E/vu8z7ZbxLMLRDpae+gsj233NisO86ql
OJBPI0D17bxYD4mHWfA3ls8Z14k6hCpbNHa0apFLbWoWUJhrpMpDKWH/m/PgG0Zw
YLk2YUH7cPvhCg9Tm82ijZdpaoVmoGb1lYa906NKX2IwRYyMeRIffC3o4fYMJCrR
aPWtc3HUjJTlmWReSS4iMMOwj7Q2WggcqQt1cWpd0vz1i7DlCac=
=u0iJ
-END PGP SIGNATURE-